Malicious OT Project Files within Reach of Attackers

Executive Summary

• Google's Threat Analysis Group reveals that North Korean hackers are using social engineering campaigns to entice victims to install backdoors via compromised Visual Studio project files.

• There are parallels between Visual Studio project files and OT project files

• Visual Studio is an IDE where code is written, compiled, and executed, similar to an engineering workstations

• EWS are used to upload and download data from PLCs and other control systems; if compromised, an EWS can be leveraged to disrupt industrial processes

Google's Threat Analysis Group (TAG) recently put vulnerability researchers on notice that a state-sponsored threat actor had been using convincing social engineering campaigns to introduce backdoors to, in some cases, fully patched Windows 10 machines running up-to-date versions of the Chrome browser.

The path to compromise was involved and well thought out. A network of phony Twitter, LinkedIn, Discord, Telegram, and Keybase accounts were used to communicate with potential victims. Victims were enticed through these decoy accounts into collaborating on supposed research projects and were ultimately sent a Microsoft Visual Studio project file that included a malicious (dynamic-link library) DLL. The DLL was a backdoor that beaconed out to an attacker-controlled command-and-control (C2) server awaiting further commands.

Other victims were led via links in tweets to a blog hosted by the attacker that installed a malicious service and an in-memory backdoor that communicated with the attacker's C2. These victims, Google said, were fully patched, leading to speculation that the attackers could have either a Chrome or Windows 10 zero-day exploit at their disposal.

The attackers—allegedly North Korea's Lazarus Group according to Google and others—worked hard to establish their fraudulent personas, going so far as to create videos of exploits that were proven to be fakes, Google TAG said in its report. Multiple attacker-owned social media accounts would retweet and repost these fraudulent claims in order to boost their credibility. The end result was a proposed collaboration on vulnerability research where the VS project file was distributed to the target, who would compile the code and execute it through Visual Studio Build Events.

Targeting Visual Studio and OT Project Files

From an industrial cybersecurity perspective, the exchange of Visual Studio project files is most interesting. Visual Studio is an integrated development environment (IDE) where code is written, compiled, and executed, similar to an engineering workstation that connects to programmable logic controllers (PLCs) and other control systems running on an operational technology (OT) network.

We found many similarities between the Google TAG Attack Scenario and other possible OT attack scenarios:

	Google TAG Attack Scenario	OT Attack Scenario
Environment	Visual Studio	Engineering Workstations (EWS) software
Target	Researchers	OT engineers
Attack Delivery	Social engineering	Social engineering
What is Delivered	Project files (Visual Studio project)	Project files (EWS project)
Trigger	Open the project file and compile	Open the project
What is Abused	Legitimate use of the Visual Studio build-system, no exploits are involved	Exploiting 0-day / 1-day vulnerabilities in EWS
Payload	Malicious DLL	Malicious DLL / shellcode
Result	Takeover of the target machine (usually a VM dedicated for exploit development)	Foothold in the OT network

Skipping a Step with Malicious OT Project Files

The industrial cybersecurity parallel to the attacks described by Google TAG would be through an OT project file. These are usually archive file formats that contain OLE files, SQLite databases, proprietary binary formats, text files, and directories created within engineering workstations. These programs are used by engineers to monitor, configure, and communicate with programmable logic controllers (PLCs) and other control systems. The program logic contained in a project file governs ICS devices and oversees processes, and it also may include network configuration data and—at times—a complete OT network layout.

For attackers targeting industrial networks—and many of late have been state actors—weaponized project files would likely be central to such a campaign. Team82, for example, has disclosed vulnerabilities in OT engineering workstations that not only have been fixed, but also demonstrate the real-world applicability of such exploits and the need to prioritize them as a critical risk that must be patched or mitigated immediately.

Adding some urgency to the flaws reported by Claroty that were addressed by their respective vendors, a malicious project file would execute by merely opening the file, skipping the step described by Google where a project file would first need to be compiled in an IDE.

Similarly, there would need to be a distribution channel for such an attack against an engineering workstation and OT network that involved social engineering. An attacker could solicit "help" in a forum and share their malicious project file. A victim who downloads the project file in a vulnerable engineering workstation application could execute the exploit by merely opening the file; the payload could be anything from a backdoor that communicates with the attacker's server to malware such as ransomware that could disrupt an industrial process.

This type of attack would bypass existing network security parameters, because the code would be executed—in theory—on the OT network. Unlike a remote access Trojan or other type of backdoor mechanism, such an attack would not beacon externally, thus evading detection.

Real-World OT Project File Attacks

In January 2020 at the Pwn2Own Miami competition, researchers presented multiple attack vectors using SCADA engineering project file weaponization. The researchers showed how to get to code execution by providing a malicious file opened by a user. Once opened, the attacker could execute any given payload to compromise a target machine.The vulnerabilities the researchers used included a directory traversal flaw that would be used to escape the software's standard DLL directory and instead use a DLL supplied by the attacker. The second bug in the chain enables the attacker to manipulate SQLite database features to lead the software to load the attacker's DLL from the malicious project file.

A similar vulnerability was found by Claroty and patched in July of last year in Phoenix Contact's PLCnext Engineer version 2020.3.1 and earlier versions, shown below. An attacker could manipulate the build settings of a PLCnext Engineer project file in order to execute code, affecting the availability and safety of the affected control system.

This particular exploit is very similar to what happened in the recent events described by Google TAG. For comparison, here is the malicious command that was executed through the build-system when compiling the weaponized Visual Studio project:

Team82's Recommendations

Google's description of these attacks by a state actor against researchers reinforces the real-world applicability of these exploits, as well as the need for vigilance.

Vulnerability researchers are targets of nation-state actors keen on gaining intelligence on exploitable software flaws they can leverage to attack adversaries or turn a profit, as has been alleged of North Korea's Lazarus Group in attacks against the SWIFT financial network and several cryptocurrencies.

IT and OT operators must reinforce that staff be cautious about engaging on public forums and social media with individuals they may not know. In particular, extra caution must be exercised when downloading project files and other information from third parties. Executing such files inside the network perimeter could put industrial processes at risk and affect the safety of critical infrastructure and manufacturing processes, for example.