PanelView Plus devices are graphic terminals, also known as human machine interface (HMI) and are used in the industrial space. These vulnerabilities can significantly impact organizations using the affected devices, as attackers could exploit these vulnerabilities to remotely execute code and disrupt operations.

We shared these findings with Rockwell Automation through Coordinated Vulnerability Disclosure (CVD) via Microsoft Security Vulnerability Research (MSVR) in May and July 2023. Rockwell published two advisories and released security patches in September and October 2023. We want to thank the Rockwell Automation product security team for their responsiveness in fixing this issue. We highly recommend PanelView Plus customers to apply these security patches.

The discovered vulnerabilities are summarized in the table below:

In this blog post, we will focus on the technical details of the CVE-2023-2071 remote code execution vulnerability and how it was discovered, as well as provide an overview of the protocol used for both the RCE and DoS vulnerabilities. Additionally, we will offer technical details about the vulnerability and demonstrate the exploitation method. By sharing this research with the larger security community, we aim to emphasize the importance of collaboration in the effort to secure platforms and devices.

Suspicious remote registry query

One of the primary responsibilities of the Microsoft Defender for IoT research team is to ensure that the product properly analyzes various operational technology (OT) and Internet of Things (IoT) protocols. During this process, we observed a legitimate packet capture of two devices communicating using the Common Industrial Protocol (CIP), with one device sending a request containing a path to a registry value named “ProductCode,” and the other device responding with what appeared to be the product code value. The lack of encryption and absence of prior authentication in the communication raised concerns, as it appeared to involve a remote registry query. Further investigation revealed that the requesting device was an engineering workstation, and the responding device was an HMI – specifically, PanelView Plus.

We hypothesized that this remote registry querying functionality could be abused by querying system keys to access secrets or even gain remote control. To validate this hypothesis, we needed to locate the code responsible for this functionality. Since the two devices communicated using the CIP, our first step was to understand the protocol in depth.

Object-oriented protocol for industrial automation applications

CIP is an industrial protocol designed for industrial automation applications. Various vendors in the industrial sector utilize this protocol, and the communication we observed took place over Ethernet/IP – a protocol that adapts CIP to standard Ethernet.

According to the official CIP documentation: “A CIP node is modeled as a collection of Objects. (…) A Class is a set of Objects that all represent the same kind of system component. An Object Instance is the actual representation of a particular Object within a Class.”

From this description, we can deduce that CIP is an object-oriented protocol, where messages are directed towards specific objects, identified by their Class ID and Object Instance ID. Additionally, the term “Service Code” is defined as: “An integer identification value which denotes an action request that can be directed at a particular object instance or object attribute”. Therefore, when messaging an object, we should also specify a Service Code, which informs the object what action it should perform.

The CIP specification outlines common Class IDs and Service IDs, as well as ranges for vendor-specific IDs.

Returning to the packet capture, we observed that both Service ID and Class ID values were vendor specific. This means that to understand the meaning of these Class and Service IDs and locate the code responsible for the functionality, we must analyze the HMI firmware.

Firmware analysis

According to Rockwell Automation’s online resources, PanelView Plus HMIs operate on the Windows 10 IoT (or Windows CE for older versions) operating system. We were able to extract the DLLs and executables related to Rockwell Automation from the most recent firmware. There are several DLLs responsible for receiving different Class IDs and processing their requests, one of which is responsible for processing the Class ID we observed in the packet capture.

Upon examining the functionality associated with this Class ID, we confirmed that it is indeed responsible for querying the registry and sending the value in the response. However, we also discovered that the code managing this functionality performs input verification, allowing the reading of registry values only from specific Rockwell keys.

Potentially exploitable custom class

Although our initial hypothesis was proven incorrect, this finding allowed us to gain valuable insights into Rockwell’s process of handling different CIP classes. Additionally, we learned how to identify the classes that a specific DLL is responsible for processing. This knowledge leads us to our second hypothesis: there might be another custom class, managed by the same DLL as the one responsible for the registry class, that could be exploited to gain remote control of the device.

Remote code execution

We began analyzing the DLL that handles the custom CIP class for reading and writing registry keys and discovered that this DLL also manages two other undocumented custom CIP classes from Rockwell. We decided to investigate these classes further to determine if they could be exploited for our attack and help validate our hypothesis.

Custom class 1

The first class we examined had an intriguing functionality: it accepts a path to a DLL file, a function name, and a third parameter as input. It then loads the DLL using LoadLibrary and calls the specified function using GetProcAddress, passing the third parameter as an argument.

This seemed like a possible avenue for executing arbitrary code. However, there was a catch: the class included a verification function that checked if the DLL name was remotehelper.dll and if the function name was one of the predefined values. If these conditions were not met, the class would return an error and not execute the function.

Custom class 2

Next, we examined the second class found within the same DLL. This class allowed reading and writing files on the device. It also included a verification function, but it was more permissive: it only checked whether the path for reading/writing began with a specific string. We realized that this class could potentially be exploited by uploading a malicious DLL to the device and place it in almost any location.

Exploitation approach

Having gained a comprehensive understanding of the vulnerabilities, we had an idea of how an attacker could utilize the two custom classes to launch code remotely on the device. The idea was to compile a DLL compatible with Windows 10 IoT, the operating system of the device. This DLL would contain the code we wanted to run on the device and would be exported under the name GetVersion, which is one of the valid function names that can be invoked by custom class 1. We would then use custom class 2 to upload our DLL to the device, placing it in a random folder and naming it remotehelper.dll. Finally, we would execute it using custom class 1.

To further explore how the vulnerability can be exploited, we decided to leverage an existing function in the original remotehelper.dll file. We discovered that this file had an export called InvokeExe, which allowed running any executable file on the device. However, this function was not in the list of valid function names for custom class 1, so we could not use it directly. To overcome this obstacle, we patched the remotehelper.dll file and altered one of the valid export names to point to the InvokeExe function. We then uploaded our patched DLL to the device, placing it in a different folder than the original. Subsequently, we used custom class 1 to invoke our patched DLL and run cmd.exe, which granted us a command shell on the device. We confirmed that the exploit was successful and that we had gained full control of the device.

Mitigation and protection guidance

Microsoft recommends the following measures to help protect organizations from attacks that take advantage of the PanelView Plus vulnerabilities shared in this blog post:

• Apply patches to affected devices in your network. FactoryTalk View ME v12/v13 and FactoryTalk® Linx v6.20/v6.30 on PanelView Plus are vulnerable to the discovered vulnerabilities. It is recommended to first identify the devices in your network that are impacted by those vulnerabilities. It is also recommended to install the following patches on the device:
  • PN1645 | FactoryTalk View Machine Edition Vulnerable to Remote Code Execution
  • PN1652 | FactoryTalk® Linx Vulnerable to Denial-of-Service and Information Disclosure
• Make sure all critical devices, such as PLCs, routers, PCs, etc., are disconnected from the internet and segmented, regardless of whether they run Rockwell’s FactoryTalk View.  
• Limit access to CIP devices to authorized components only. 

To assist with identifying impacted devices, Microsoft released a tool for scanning and performing forensics investigation on Rockwell Rslogix devices as part of its arsenal of open-source tools available on GitHub.

Microsoft Defender for IoT detections

Microsoft Defender for IoT provides the following protection measures against these vulnerabilities, associated exploits, and other malicious behavior:  

• Defender for IoT detects and classifies devices that use CIP.  
• Defender for IoT raises alerts on unauthorized access to devices using CIP, and abnormal behavior in these devices.  
• Defender for IoT raises alerts if a threat actor attempts to exploit these vulnerabilities. Alert type: “Suspicion of Malicious Activity”.

Yuval Gordon
Microsoft Threat Intelligence Community

References

• https://www.odva.org/wp-content/uploads/2020/06/PUB00123R1_Common-Industrial_Protocol_and_Family_of_CIP_Networks.pdf
• https://www.rockwellautomation.com/en-us/trust-center/security-advisories/advisory.PN1652.html
• https://www.rockwellautomation.com/en-us/trust-center/security-advisories/advisory.PN1645%20.html

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://twitter.com/MsftSecIntel.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.

The post Vulnerabilities in PanelView Plus devices could lead to remote code execution appeared first on Microsoft Security Blog.

OT systems, which control real-world critical processes, present a significant target for cyberattacks. These systems are prevalent across various industries, from building heating, ventilation, and air conditioning (HVAC) systems, to water supply and power plants, providing control over vital parameters such as speed and temperature in industrial processes. A cyberattack on an OT system could transfer control over these critical parameters to attackers and enable malicious alteration that could result in malfunctions or even complete system outages, either programmatically via the programmable logic controller (PLC) or using the graphical controls of the human machine interface (HMI).

Adding to the potential damage of attacks on OT systems are their often-lacking security measures, which make OT attacks not only attractive for attackers but also relatively easy to execute. Many OT devices, notwithstanding common security guidelines, are directly connected to the internet, making them discoverable by attackers through internet scanning tools. Once discovered by attackers, poor security configurations, such as weak sign-in passwords or outdated software with known vulnerabilities, could be further exploited to obtain access to the devices.

The attractiveness of OT systems and attackers’ capabilities against systems with weak configurations were demonstrated in the Israel-Hamas war, which was accompanied by a spike in cyberattacks, including from OT-focused actors. Shortly after October 7, the Telegram channels of several such actors broadcasted their attacks against OT systems associated with Israeli companies. These publications were often accompanied by images of purportedly compromised systems, which the threat actors presented as alleged evidence for the attacks.

Microsoft’s analysis of multiple attacks by these actors revealed a common attack methodology: focusing on internet-exposed, poorly secured OT devices. This report will illustrate this attack methodology using the high-profile case of the November 2023 attack against Aliquippa water plant, for which CISA released an advisory in December 2023. CISA attributed the attack to the Islamic Revolutionary Guard Corps (IRGC)-affiliated actor “CyberAv3ngers”, tracked by Microsoft as Storm-0784. Microsoft assesses that the same methodology has been utilized by other OT-focused threat actors in multiple other attacks as well.

The attacks conducted by OT-focused actors were not limited to public sector facilities but also affected private companies in various countries. While the public sector has been implored to implement proper risk management and protection of OT systems, the diversity of target profiles illustrates that ensuring OT security in the private sector is equally crucial. Recommendations for organizations to protect against similar attacks and improve the security posture of their OT systems can be found at the end of this report.

Spike in activity of OT threat actors

Shortly after the outbreak of the Israel-Hamas war, Microsoft has seen a rise in reports of attacker activity against OT systems with Israeli affiliation. This included activity by existing groups such as the IRGC-affiliated “CyberAv3ngers”, and the emergence of new groups such as the “CyberAv3ngers”-associated “Soldiers of Solomon”, and “Abnaa Al-Saada”, a cyber persona presenting itself as Yemeni. Microsoft tracks both “CyberAv3ngers” and its associated group “Soldiers of Solomon” as Storm-0784.

The systems targeted by these groups included both OT equipment deployed across different sectors in Israel, including PLCs and HMIs manufactured by large international vendors, as well as Israeli-sourced OT equipment deployed in other countries. The attacks were made public by the actors using their Telegram channels, on which they also posted images of the target systems to enhance purported credibility and present evidence for the attack.

Researching the threat actors in question, Microsoft has identified a typical target profile that attackers appeared to focus on: internet-exposed OT systems with poor security posture, potentially accompanied by weak passwords and known vulnerabilities.

The Aliquippa case: A high-profile OT attack

In late November 2023, the Aliquippa water plant was affected by a cyberattack that resulted in the outage of a pressure regulation pump on the municipal water supply line in Aliquippa, Pennsylvania. In addition to impairing functionality, the attack, which targeted a PLC-HMI system by Israeli manufacturer Unitronics, also defaced the device to display a red screen with the name and logo of the “CyberAv3ngers” actor. The US Department of Treasury sanctioned officials in the Iranian Islamic Revolutionary Guard Corps Cyber-Electronic Command (IRGC-CEC) in relation to the attack.

Around the same time, multiple other attack cases on Unitronics systems were reported across the industry in other parts of the world, with targeted equipment displaying the same message: “Every equipment ‘made in Israel’ is a Cyber Av3ngers legal target“.

Microsoft analyzed the publicly available data on the Aliquippa incident to find the victim system and assess how it was compromised. Leveraging researchers’ intimate OT knowledge to interpret the limited details known to the public has enabled the identification of a specific machine that Microsoft believes to be the victim.

According to publicly accessible sources, the targeted system was exposed to the internet, and it suffered both defacement and the shutdown of the pump it controlled. Designated engines that map internet-connected devices and their associated services allowed Microsoft researchers to compile a list of internet-exposed Unitronics devices of the relevant model, which also had a dedicated control port open. This configuration could potentially allow to reprogram the device reprogramming, leading to the observed defacement and shutdown.

The analysis of contextual data narrowed the device profile list, identifying a specific system that could be the victim. This system was geographically situated near the Aliquippa station, with its PLC Name field set to “Raccoon Primary PLC”, consistent with the Aliquippa water station serving Potter and Raccoon townships, and also aligning with a photograph disseminated by the media, depicting a sign that reads “PRIMARY PLC” on the targeted system.

The data gathered throughout the research of the Aliquippa attack case highlights a trend: a common target profile of internet-exposed OT systems with a weak security posture that mirrors other attack cases.

Attacks representing a broader concerning trend

The CISA advisory that was released following the attacks in November 2023 described the profile of the targeted OT systems as being internet-exposed and having weak sign-in configurations. In May 2024, CISA released another advisory following the more recent attacks against the water sector, which showed that the victims had a similar profile. Again, OT systems that were left internet-exposed and had weak passwords were targeted by nation-state attackers, this time by pro-Russia activists.

While attacks on high-profile targets, especially in the public sector, often receive significant media attention, it’s important to recognize that the private sector and individual users may also be impacted. Notably, the Aliquippa water plant was just one victim in a series of attacks on Unitronics by “CyberAv3ngers”, which also expanded to the private sector. Screenshots of affected systems with the same red screen and message have been posted by users on the Unitronics forum claiming their equipment was attacked, with similar reports also showing on social media platform X. Following the incidents, a vulnerability was assigned for the Unitronics default password configuration (CVE-2023-6448), and a patch was issued by Unitronics to require users to fix the issue.  

The common target profile for the attack cases analyzed reflects what attackers do to pick an easily accessible and appealing target in the first place. Attackers can, and do, obtain visibility on OT devices that are open to the internet using search engines, identify vulnerable models and open communication ports, and then use the contextual metadata to identify devices that are of special interest, such as ICS systems in water plants or other critical facilities. At that point, a weak password or an outdated system with an exploitable vulnerability is all that stands between them and remote access to the system.

The growing attention from attackers towards OT systems, observed across various sectors, is particularly concerning due to inadequate security practices on these systems. The Microsoft Digital Defense Report 2023 highlights that 78% of industrial network devices on customer networks monitored by Microsoft Defender for IoT have known vulnerabilities. Among these, 46% utilize deprecated firmware, for which patches are no longer available, while the remaining 32% operate outdated systems with unpatched vulnerabilities. For devices that are patched, many still use default passwords or have no passwords at all. Microsoft collects statistics on the prevalence of username and password pairs seen used in Microsoft’s sensor network, as was shared in the Microsoft Digital Defense Report 2022. Such outdated and vulnerable systems present attractive targets for future attacks, particularly when coupled with internet connectivity and default passwords. In the next sections, we share recommendations for improving the security posture of OT systems to help prevent attacks.

Mitigation and protection guidance

The analysis of the attack claims in question reveals diverse target profiles. It is therefore vital for organizations of all different sectors to ensure security hygiene for their OT systems to prevent similar threats.

• Adopt a comprehensive IoT and OT security solution such as Microsoft Defender for IoT to allow visibility and monitoring of all IoT and OT devices, threat detection and response, and integration with SIEM/SOAR and XDR platforms such as Microsoft Sentinel and Microsoft Defender XDR.
• Enable vulnerability assessments to identify unpatched devices in the organizational network and set workflows for initiating appropriate patch processes through  Microsoft Defender Vulnerability Management and Microsoft Defender for Endpoint with the Microsoft Defender for IoT add-on.
• Reduce the attack surface by eliminating unnecessary internet connections to IoT devices and OT control systems. Verify that no OT system is directly connected to the internet, for example, through IoT routers or Cellular bridged (LTE or 3G). Close unnecessary open ports and services on their equipment, eliminating remote access entirely when possible, and restricting access behind a firewall or VPN when full elimination cannot be achieved.
• Implement Zero Trust practices by applying network segmentation to prevent an attacker from moving laterally and compromising assets after intrusion. OT devices and networks should be isolated from IT with firewalls. Extend vulnerability and exposure control beyond the firewall with Microsoft Defender External Attack Surface Management. Turn on attack surface reduction rules in Microsoft Defender for Endpoint to prevent common attack techniques such as those used by ransomware groups.

Microsoft Defender for IoT detections

Microsoft Defender for IoT provides detections for suspicious behaviors of OT and IoT devices. Alerts related to internet access and modification of PLC behavior will detect activity of this type, such as:

• External address within the network communicated with Internet
• Internet Access Detected
• Unauthorized Internet Connectivity Detected
• Unauthorized PLC Program Upload
• Unauthorized PLC Programming

References

• IRGC-Affiliated Cyber Actors Exploit PLCs in Multiple Sectors, Including U.S. Water and Wastewater Systems Facilities | CISA
• Municipal Water Authority of Aliquippa hacked by Iranian-backed cyber group – CBS Pittsburgh (cbsnews.com)
• Aliquippa Water Authority – Municipal Water Authority of Aliquippa
• Cyber group backed by Iran is taking credit for Pennsylvania water system cyberattack
• PLC Hacking – More Commonplace Than You Might Think – Best Programming Practices – Unitronics Support Forum: Programmable Controllers (PLC + HMI All-in-One)
• Full Pint Beer on X: “Ugh – the brewery control system received a CYBER ATTACK over the weekend!!! We are working to restore things to working order, kudos to the crew at @Brewmation for working with us over the Thanksgiving weekend! Thank goodness for backups! #cyberattack #automation #ransomware https://t.co/SNdXY9ne4h” / X
• NVD – CVE-2023-6448 (nist.gov)
• Unitronics-Cybersecurity-Advisory-2023-001-CVE-2023-6448.pdf (unitronicsplc.com)
• Iranian cyber attack targets Israeli tech used by several US bodies | The Times of Israel

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://twitter.com/MsftSecIntel.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.

The post Exposed and vulnerable: Recent attacks highlight critical need to protect internet-exposed OT devices appeared first on Microsoft Security Blog.

CODESYS is compatible with approximately 1,000 different device types from over 500 manufacturers and several million devices that use the solution to implement the international industrial standard IEC (International Electrotechnical Commission) 611131-3. A DoS attack against a device using a vulnerable version of CODESYS could enable threat actors to shut down a power plant, while remote code execution could create a backdoor for devices and let attackers tamper with operations, cause a PLC to run in an unusual way, or steal critical information. Exploiting the discovered vulnerabilities, however, requires user authentication, as well as deep knowledge of the proprietary protocol of CODESYS V3 and the structure of the different services that the protocol uses.

Microsoft researchers reported the discovery to CODESYS in September 2022 and worked closely with CODESYS to ensure that the vulnerabilities are patched. Information on the patch released by CODESYS to address these vulnerabilities can be found here: Security update for CODESYS Control V3. We strongly urge CODESYS users to apply these security updates as soon as possible. We also thank CODESYS for their collaboration and recognizing the urgency in addressing these vulnerabilities. 

Below is a list of the discovered vulnerabilities discussed in this blog: 

In this blog, we provide an overview of the CODESYS V3 protocol structure, highlighting several key components, and describe the main issue that led to our discovery of the vulnerabilities. The full research and the results can be found in our report on Github. We also provide an open-source forensics tool to help users identify impacted devices, security recommendations for those affected, and detection information for potentially related threats.

CODESYS: A widely used PLC solution

CODESYS is a software development environment that provides automation specialists with tools for developing automated solutions. CODESYS is a platform-independent solution that helps device manufacturers implement the international industrial standard IEC 611131-3. The SDK also has management software that runs on Windows machines and a simulator for testing environments, allowing users to test their PLC systems before deployment. The proprietary protocols used by CODESYS use either UDP or TCP for communication between the management software and PLC.

CODESYS is widely used and can be found in several industries, including factory automation, energy automation, and process automation, among others. 

Discovering the CODESYS vulnerabilities

The vulnerabilities were uncovered by Microsoft researchers while examining the security of the CODESYS V3 proprietary protocol as part of our goal to improve the security standards and create forensic tools for OT devices. During this research, we examined the structure and security of the protocol that is used by many types and vendors of PLCs.  We examined the following two PLCs that use CODESYS V3 from different vendors: Schneider Electric Modicon TM251 and WAGO PFC200.

CODESYS V3 protocol

The CODESYS network protocol works over either TCP or UDP:

• Ports 11740-11743 for TCP
• Ports 1740-1743 for UDP

The CODESYS network protocol consists of four layers:

1. Block driver layer: The layer that creates the capability to communicate over a physical or software interface, over TCP or UDP.
2. Datagram layer: The layer that enables communication between components and endpoints through physical or virtual interfaces. 
3. Channel layer: The layer that is responsible for creating, managing, and closing communications channels.
4. Services layer: Represents a combination of several layers of the ISO/OSI model session layer, presentation layer, and application layer. It consists of components, each of which is responsible for a portion of functionality of the PLC and has services that it supports. Other tasks of the Services layer include encoding/decoding and encrypting/decrypting the data transmitted on that layer. Additionally, the Services layer is also responsible for tracking the client-server session. Each component is identified by a unique ID, such as:

These components use the Tags layer for data transmission and encoding, which is transmitted over the Services layer.

There are two types of tags: parent and data. Both tags have identical structure but different sizes and purposes. The following table provides the basic structure of tags:

Tags can represent any type of data, and it is extracted by the component. The difference between a parent tag and a data tag is that a parent tag is used for linking several tags into one logical element.

Tags contain several important structures, including BTagReader and BTagWriter, which include the following fields:

• Data
• Current position in data
• Size of data

These structures are allocated for each request and exist only in the context of the request. Each request handler creates BTagWriter and BTagReader tags and uses them to parse and handle requests. Tag IDs are not unique across services, meaning each service may have its own definition for a tag ID. Tag IDs are handled in the context of each service.

The following figure provides an example of a Tag layer and relevant fields.

This example contains the following tags:

• Tag1 – )TAG ID 0x01( 10 00 00 00
• Tag2 – (TAG ID 0x23) Authentication method type
• Tag3 – (TAG ID 0x81) Parent tag that contains two sub tags
• Tag4 – (TAG ID 0x10) Username tag
• Tag5 – (TAG ID 0x11) Hash of a password tag

CODESYS components

CODESYS consists of components and each component is responsible for a portion of functionality of the PLC. The following is a list of example components:

• CmpAlarmManger – Manages alarm events, registers clients that receive events, etc.
• CmpApp – Manages running applications and application event usage.
• CmpAppBp – Manages breakpoints in IEC tasks.
• CmpCodeMeter – Manages the CodeMeter License containers.
• CmpCoreDump – Manages creating, reading, and printing to file coredumps.
• CMPTraceMgr – Enables tracing of information inside the IEC tasks.

Each component includes a number of services that the client can ask to use. For example, CMPTraceMgrincludes the following:

• TraceMgrPacketCreate – Creates a new trace packet
• TraceMgrPacketDelete – Deletes a trace manager packet
• TraceMgrPacketStart – Starts tracing, which is triggered by the TraceTrigger
• TraceMgrRecordUpdate – Records the current value of the TraceVariable together with the current timestamp
• TraceMgrRecordAdd – Creates a new TraceRecordConfiguration and adds it to a specific trace packet for a specific IEC task/application

Each service is identified by a unique number for the specific component.

Tags layer vulnerability

A security issue was discovered inside the tag decoding mechanism that led to multiple vulnerabilities that could put devices at risk of attacks such as RCE and DoS.  

In order to understand the security issue, let’s analyze the service TraceMgrRecordAdd of the component CMPTraceMgr by examining the code that activates the relevant service.

The TraceMgrRecordAddByTag appears to correspond to TraceMgrRecordAdd.

As displayed in Figure 5, the following code initializes structure from tags that are sent to the service.  

The following figure looks at the code for the TraceMgrAddNewRecordPartByTag method, which copies data from different tags into an output buffer.

The whole tag is copied into the buffer without validating the size, causing buffer overflow.

Fifteen places in CODESYS V3 SDK were found with the same issue in different components that could lead to remote attackers gaining full control over the device.

Exploitation approach

We were able to apply 12 of the buffer overflow vulnerabilities to gain RCE of PLCs. Exploiting the vulnerabilities requires user authentication as well as bypassing the Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR) used by both the PLCs. To overcome the user authentication, we used a known vulnerability, CVE-2019-9013, which allows us to perform a replay attack against the PLC using the unsecured username and password’s hash that were sent during the sign-in process, allowing us to bypass the user authentication process.

IEC tasks

IEC tasks are the execution unit of CODESYS runtime. It is the equivalent to thread in operating systems. A single component can have more than one task and will have at least one IEC task. The tasks are managed by CODESYS runtime. 

Each IEC task has a memory segment with read, write, and execute permissions. If a threat actor writes code there, it could be run without the data execution prevention mitigation being applied.

The IEC task segment is also where the stack is defined, meaning we don’t need to handle DEP.

Since the IEC tasks are part of the CODESYS code, they are present on all PLCs of all vendors that utilize CODESYS.

Full exploit

By looking for gadgets, we can bypass the ASLR. In the examples below, we can see part of the gadgets that we used in our exploit.

The complete exploit steps:

1. Steal credentials with CVE-2019-9013.
2. Create a new channel for the attack.
3. Sign-in to the device with the stolen credentials.
4. Exploit the vulnerabilities with a malicious packet that triggers buffer overflow.
5. Gain full control of the device.

We were able to exploit the two PLCs that we researched.

Demo video:

Critical importance of ICS security 

With CODESYS being used by many vendors, one vulnerability may affect many sectors, device types, and verticals, let alone multiple vulnerabilities. All the vulnerabilities can lead to DoS and 1 RCE. While exploiting the discovered vulnerabilities requires deep knowledge of the proprietary protocol of CODESYS V3 as well as user authentication (and additional permissions are required for an account to have control of the PLC), a successful attack has the potential to inflict great damage on targets. Threat actors could launch a DoS attack against a device using a vulnerable version of CODESYS to shut down industrial operations or exploit the RCE vulnerabilities to deploy a backdoor to steal sensitive data, tamper with operations, or force a PLC to operate in a dangerous way.

Mitigation and protection guidance

CODESYS V3 versions prior to 3.5.19.0 are vulnerable to the discovered vulnerabilities. It is recommended to first identify the devices using CODESYS in your network and check with device manufacturers to determine which version of the CODESYS SDK is used and whether a patch is available. It is also recommended to update the device firmware to version to 3.5.19.0 or above. 

General recommendations: 

• Apply patches to affected devices in your network. Check with the device manufacturers for available patches and update the device firmware to version to 3.5.19.0 or above. 
• Make sure all critical devices, such as PLCs, routers, PCs, etc., are disconnected from the internet and segmented, regardless of whether they run CODESYS.  
• Limit access to CODESYS devices to authorized components only. 
• Due to the nature of the CVEs, which still require a username and password, if prioritizing patching is difficult, reduce risk by ensuring proper segmentation, requiring unique usernames and passwords, and reducing users that have writing authentication.   

To assist with identifying impacted devices, the cyberphysical systems research team has released an open-source software tool on GitHub that allows users to communicate with devices in their environment that run CODESYS and extract the version of CODESYS on their devices in a safe manner to confirm if their devices are vulnerable. In addition, the cyberphysical system research team also released a tool for performing a forensics investigation on CODESYS V3 devices as part of its arsenal of open-source tools available on GitHub.

Microsoft 365 Defender detections 

Microsoft 365 Defender is becoming Microsoft Defender XDR. Learn more.

Microsoft Defender for IoT 

Microsoft Defender for IoT with all versions of the sensor and TI package after April 2023 provides the following protections against these vulnerabilities and associated exploits and other malicious behavior:  

• Defender for IoT detects and classifies devices that use CODESYS.  
• Defender for IoT raises alerts on unauthorized access to devices using CODESYS, and abnormal behavior in these devices.  
• Defender for IoT raises alerts if a threat actor attempts to exploit these vulnerabilities. Alert type: “Suspicion of Malicious Activity”

Microsoft Defender Threat Intelligence 

Microsoft Defender Threat Intelligence shows devices running CODESYS that are exposed to the internet by searching for “CODESYS” components on IPs.  

Vladimir Tokarev

Microsoft Threat Intelligence Community

References 

• https://www.codesys.com/the-system/codesys-inside.html
• https://store.codesys.com/engineering/codesys.html
• https://github.com/microsoft/CoDe16/tree/main
• https://store.codesys.com/en/alarm-manager.html
• https://content.helpme-codesys.com/en/libs/CmpApp/Current/index.html
• https://content.helpme-codesys.com/en/libs/CmpAppBP/Current/index.html
• https://content.helpme-codesys.com/en/libs/CmpCodeMeter/Current/index.html
• https://content.helpme-codesys.com/en/libs/CmpTraceMgr/Current/index.html
• https://content.helpme-codesys.com/en/libs/CmpApp/Current/AppStartApplication.html
• https://help.codesys.com/webapp/TraceMgrPacketCreate;product=CmpTraceMgr;version=3.5.16.0
• https://help.codesys.com/webapp/TraceMgrPacketDelete;product=CmpTraceMgr;version=3.5.16.0
• https://help.codesys.com/webapp/TraceMgrPacketStart;product=CmpTraceMgr;version=3.5.16.0
• https://help.codesys.com/webapp/TraceMgrRecordUpdate;product=CmpTraceMgr;version=3.5.16.0
• https://help.codesys.com/webapp/TraceMgrRecordAdd;product=CmpTraceMgr;version=3.5.17.0
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9013
• https://customers.codesys.com/index.php?eID=dumpFile&t=f&f=12943&token=d097958a67ba382de688916f77e3013c0802fade&download=
• https://www.codesys.com/download
• https://download.schneider-electric.com/files?p_Doc_Ref=SEVD-2023-192-04&p_enDocType=Security+and+Safety+Notice&p_File_Name=SEVD-2023-192-04.pdf&_ga=2.25212925.1579834642.1689503846-267712980.1687697317
• https://cert.vde.com/de/advisories/VDE-2023-026/
• https://ics-cert.kaspersky.com/publications/reports/2019/09/18/security-research-codesys-runtime-a-plc-control-framework-part-1/
• https://ics-cert.kaspersky.com/publications/reports/2019/09/18/security-research-codesys-runtime-a-plc-control-framework-part-2/
• https://ics-cert.kaspersky.com/publications/reports/2019/09/18/security-research-codesys-runtime-a-plc-control-framework-part-3/

Further reading

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on Twitter at https://twitter.com/MsftSecIntel.

The post Multiple high severity vulnerabilities in CODESYS V3 SDK could lead to RCE or DoS  appeared first on Microsoft Security Blog.

Utilizing an established criminal infrastructure that has incorporated the use of a Southeast Asian financial institution’s subdomain as a command and control (C2) server, the threat actors behind the attack use a backdoor that deploys a wide array of tools and components such as rootkits and an IRC bot to steal device resources for mining operations. The backdoor also installs a patched version of OpenSSH on affected devices, allowing threat actors to hijack SSH credentials, move laterally within the network, and conceal malicious SSH connections. The complexity and scope of this attack are indicative of the efforts attackers make to evade detection.

In this blog post, we present our analysis of the tools and techniques used in this attack and the efforts made by the threat actor to evade detection on affected devices. We also provide indicators of compromise and relevant Microsoft Defender for IoT and Microsoft Defender for Endpoint detections, as well as recommendations for defenders to protect devices and networks.

Attack chain

The threat actors initiate the attack by attempting to brute force various credentials on misconfigured internet-facing Linux devices. Upon compromising a target device, they disable shell history and retrieve a compromised OpenSSH archive named openssh-8.0p1.tgz from a remote server. The archive contains benign OpenSSH source code alongside several malicious files: the shell script inst.sh, backdoor binaries for multiple architectures (x86-64, arm4l, arm5l, i568, and i686), and an archive containing the shell script vars.sh, which holds embedded files for the backdoor’s operation.

After installing the payload, the shell script inst.sh runs a backdoor binary that matches the target device’s architecture. The backdoor is a shell script compiled using an open-source project called Shell Script Compiler (shc), and enables the threat actors to perform subsequent malicious activities and deploy additional tools on affected systems.

Custom backdoor deploys open-source rootkits

Once running on a device, the shell script backdoor tests access to /proc to determine whether the device is a honeypot. If it can’t access /proc, it determines the device is a honeypot and exits. Otherwise, it exfiltrates information about the device, including its operating system version, network configuration, and the contents of /etc/passwd and /etc/shadow over email to the hardcoded address dotsysadmin[@]protonmail[.]com, and to any email address provided by the threat actor as an argument to the script.

On supported systems, the backdoor downloads, compiles, and installs two open-source rootkits available on GitHub, Diamorphine and Reptile. The backdoor configures Reptile to connect to the C2 domain rsh.sys-stat[.]download on port 4444 and to hide its child processes, files, or their content. Microsoft researchers assess that the Diamorphine rootkit is used to hide processes as well.

To ensure persistent SSH access to the device, the backdoor appends two public keys to the authorized_keys configuration files of all users on the system.

The backdoor obscures its activity by removing records from Apache, nginx, httpd, and system logs that contain the IP and username specified as arguments to the script. Additionally, it has the capability to install an open-source utility called logtamper to clear the utmp and wtmp logs, which record information about user sign-in sessions and system events.

The backdoor eliminates cryptomining competition from other miners that may exist on the device by monopolizing device resources and preventing communication with a hardcoded list of hosts and IPs related to these activities. It accomplishes this by adding iptables rules to drop communication with the hosts and IPs and configuring /etc/hosts to make the hosts resolve to the localhost address. It also identifies miner processes and files by their names and either terminates them or blocks access to them, and removes SSH access configured in authorized_keys by other adversaries.

Patching OpenSSH source code

The backdoor uses the Linux patch utility to apply the patch file ss.patch, which is embedded in vars.sh, to the OpenSSH source code files included in its package. Once the patches are applied, the backdoor compiles and installs the modified OpenSSH on the device.

The compromised OpenSSH grants the attackers persistent access to the device and to the SSH credentials the device handles. The patches install hooks that intercept the passwords and keys of the device’s SSH connections, whether as a client or a server. The passwords and keys are then stored encrypted in a file on the disk. Moreover, the patches enable root login over SSH and conceal the intruder’s presence by suppressing the logging of the threat actors’ SSH sessions, which are distinguished by a special password.

The modified version of OpenSSH mimics the appearance and behavior of a legitimate OpenSSH server and may thus pose a greater challenge for detection than other malicious files. The patched OpenSSH could also enable the threat actors to access and compromise additional devices. This type of attack demonstrates the techniques and persistence of adversaries who seek to infiltrate and control exposed devices.

Botnet operation

The backdoor runs a secondary payload embedded in the shell script vars.sh, which is a slightly modified version of ZiggyStarTux, an open-source IRC bot based on the Kaiten malware. Among its features is executing bash commands issued from the C2 and possessing distributed denial of service (DDoS) capabilities.

The backdoor employs various mechanisms to set up ZiggyStarTux’s persistence on compromised systems. It copies the ZiggyStarTux binary to several locations on the disk and establishes cron jobs to invoke it at regular intervals. Moreover, it runs a bash script that registers ZiggyStarTux as a systemd service by creating and configuring the service file /etc/systemd/system/network-check.service.

Analysis of ZiggyStarTux revealed that the threat actors stripped the binary of logging-related strings and incorporated a function that writes the bot’s process ID to /var/run/sys_checker.pid, allowing the backdoor to read that file and conceal that process ID using the installed rootkits.

The ZiggyStarTux bots communicate with the C2 via an IRC server hosted on various domains and IPs located in different geographical regions. Evidence indicates that the threat actors disguise their traffic by utilizing the subdomain of a Southeast Asian financial institution that is hosted on one of their own servers.

To receive commands, the ZiggyStarTux bots connect to the IRC server and join a hidden password-protected channel named ##..##. The server was observed issuing bash commands that instruct bots to download and launch two shell scripts from a remote server. The first script, lscan, retrieves lssh.tgz from the server, an archive of scripts that scan each IP in the subnet for SSH access using a password list. The scripts record the results of each connection attempt in a log file.

The second script, zaz, fetches the compromised OpenSSH package with the embedded backdoor from the remote server. The installation is carried out using the email address ancientgh0st@yahoo[.]com as an argument to serve as an additional exfiltration point for device information. Additionally, zaz retrieves an archive called hive-start.tgz which contains mining malware crafted for Hiveon OS systems, a Linux-based open-source operating system designed for cryptomining.

Indications of criminal cooperation

Microsoft researchers have traced the campaign to a user named asterzeu on the hacking forum cardingforum[.]cx, who offered multiple tools for sale on the platform, including an SSH backdoor. The domain madagent[.]tm was registered in 2015 with an email address matching the username and shared numerous servers over a four-year period with madagent[.]cc, one of the C2 domains of ZiggyStarTux. Furthermore, the distribution of the shell script backdoor between threat actors has been identified, adding to the evidence of a network of tools and infrastructure shared or sold on the malware-as-a-service market.

Mitigation and protection guidance

Microsoft recommends the following steps to protect devices and networks against this threat:

• Harden internet-facing devices against attacks
  • Ensure secure configurations for devices: Change the default password to a strong one, and block SSH from external access.
  • Maintain device health with updates: Make sure devices are up to date with the latest firmware and patches.
  • Use least-privileges access: Use a secure virtual private network (VPN) service for remote access and restrict remote access to the device.
  • When possible, update OpenSSH to the latest version.
• Adopt a comprehensive IoT security solution such as Microsoft Defender for IoT to allow visibility and monitoring of all IoT and OT devices, threat detection and response, and integration with SIEM/SOAR and XDR platforms such as Microsoft Sentinel and Microsoft 365 Defender.
• Use security solutions with cross-domain visibility and detection capabilities like Microsoft 365 Defender, which provides integrated defense across endpoints, identities, email, applications, and data.

Detections

Microsoft Defender for IoT

Microsoft Defender for IoT uses detection rules and signatures to identify malicious behavior. Microsoft Defender for IoT has alerts for the use of open-source tools and exploits that may be tied to this attack.

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects this threat as the following malware:

• Trojan:Linux/SamDust!MTB
• Trojan:Linux/SamDust.D!MTB
• Trojan:Linux/SamDust.B!MTB
• Trojan:Linux/SamDust.A!MTB
• Trojan:Linux/SamDust.N!MTB
• Trojan:Linux/Reptile.A
• Trojan:Linux/Reptile.B
• Trojan:Linux/Reptile.C
• Trojan:Linux/Reptile.D
• Trojan:Linux/Diamorphine.A!MTB

Microsoft Defender for Endpoint

The following Microsoft Defender for Endpoint alerts can indicate associated threat activity:

• Unusual number of failed sign-in attempts

The following alerts might also indicate threat activity related to this threat. Note, however, that these alerts can be also triggered by unrelated threat activity.

• Suspicious file property modification occurred
• Suspicious termination of security tool
• Suspicious service launched
• Suspicious Linux service created
• File masquerading

Hunting queries

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace. More details on the Content Hub can be found here:  https://learn.microsoft.com/azure/sentinel/sentinel-solutions-deploy.

In addition, customers can use the SSH Brute force detection template in the Syslog solution package to monitor for brute force attempts against their exposed SSH endpoints.

Indicators of Compromise

Rotem Sde-Or, Microsoft Threat Intelligence Community

Further reading

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on Twitter at https://twitter.com/MsftSecIntel.

The post IoT devices and Linux-based systems targeted by OpenSSH trojan campaign appeared first on Microsoft Security Blog.

Zerobot, a Go-based botnet that spreads primarily through IoT and web application vulnerabilities, is an example of an evolving threat, with operators continuously adding new exploits and capabilities to the malware. The Microsoft Defender for IoT research team has been monitoring Zerobot (also called ZeroStresser by its operators) for months. Zerobot is offered as part of a malware as a service scheme and has been updated several times since Microsoft started to track it. One domain with links to Zerobot was among several domains associated with DDoS-for-hire services seized by the FBI in December 2022.

Microsoft has previously reported on the evolving threat ecosystem. The shift toward malware as a service in the cyber economy has industrialized attacks and has made it easier for attackers to purchase and use malware, establish and maintain access to compromised networks, and utilize ready-made tools to perform their attacks. We have tracked advertisements for the Zerobot botnet on various social media networks in addition to other announcements regarding the sale and maintenance of the malware, as well as new capabilities in development.

In this blog post, we present information about the latest version of the malware, Zerobot 1.1, including newly identified capabilities and further context to Fortinet’s recent analysis on the threat. Zerobot 1.1 increases its capabilities with the inclusion of new attack methods and new exploits for supported architectures, expanding the malware’s reach to different types of devices. In addition to these findings, we’re sharing new indicators of compromise (IOCs) and recommendations to help defenders protect devices and networks against this threat.

What is Zerobot?

Zerobot affects a variety of devices that include firewall devices, routers, and cameras, adding compromised devices to a distributed denial of service (DDoS) botnet. Using several modules, the malware can infect vulnerable devices built on diverse architectures and operating systems, find additional devices to infect, achieve persistence, and attack a range of protocols. Microsoft tracks this activity as DEV-1061.

April 2023 update – Microsoft Threat Intelligence has shifted to a new threat actor naming taxonomy aligned around the theme of weather. DEV-1061 is now tracked as Storm-1061.

To learn about how the new taxonomy represents the origin, unique traits, and impact of threat actors, and to get a complete mapping of threat actor names, read this blog: Microsoft shifts to a new threat actor naming taxonomy.

The most recent distribution of Zerobot includes additional capabilities, such as exploiting vulnerabilities in Apache and Apache Spark (CVE-2021-42013 and CVE-2022-33891 respectively), and new DDoS attack capabilities.

How Zerobot gains and maintains device access

IoT devices are often internet-exposed, leaving unpatched and improperly secured devices vulnerable to exploitation by threat actors. Zerobot is capable of propagating through brute force attacks on vulnerable devices with insecure configurations that use default or weak credentials. The malware may attempt to gain device access by using a combination of eight common usernames and 130 passwords for IoT devices over SSH and telnet on ports 23 and 2323 to spread to devices. Microsoft researchers identified numerous SSH and telnet connection attempts on default ports 22 and 23, as well as attempts to open ports and connect to them by port-knocking on ports 80, 8080, 8888, and 2323.

In addition to brute force attempts on devices, Zerobot exploits dozens of vulnerabilities, which malware operators add on a rolling basis to gain access and inject malicious payloads. Zerobot 1.1 includes several new vulnerabilities, such as:

Since the release of Zerobot 1.1, the malware operators have removed CVE-2018-12613, a phpMyAdmin vulnerability that could allow threat actors to view or execute files. Microsoft researchers have also identified that previous reports have used the vulnerability ID “ZERO-32906” for CVE-2018-20057, “GPON” for CVE-2018-10561, and “DLINK” for CVE-2016-20017; and that CVE-2020-7209 was mislabeled as CVE-2017-17106 and CVE-2022-42013 was mislabeled as CVE-2021-42013.

Microsoft researchers have also found new evidence that Zerobot propagates by compromising devices with known vulnerabilities that are not included in the malware binary, such as CVE-2022-30023, a command injection vulnerability in Tenda GPON AC1200 routers.

Upon gaining device access, Zerobot injects a malicious payload, which may be a generic script called zero.sh that downloads and attempts to execute Zerobot, or a script that downloads the Zerobot binary of a specific architecture. The bash script that attempts to download different Zerobot binaries tries to identify the architecture by brute-force, attempting to download and execute binaries of various architectures until it succeeds, as IoT devices are based on many computer processing units (CPUs). Microsoft has observed scripts targeting various architectures including ARM64, MIPS, and x86_64.

Depending on the operating system of the device, the malware has different persistence mechanisms. Persistence tactics are used by malware operators to obtain and maintain access to devices. While Zerobot is unable to spread to Windows machines, we have found several samples that can run on Windows. On Windows machines, the malware copies itself to the Startup folder with the file name FireWall.exe (older versions use my.exe). Microsoft Defender for Endpoint detects this malware and related malicious activity on both Windows and Linux devices. See detection details below.

To achieve persistence on Linux-based devices, Zerobot uses a combination of desktop entry, daemon, and service methods:

Desktop entry:

Zerobot copies itself to $HOME/.config/ssh.service/sshf then writes a desktop entry file called sshf.desktop to the same directory. Older Linux versions use $HOME/.config/autostart instead of $HOME/.config/ssh.service.

Daemon:

Copies itself to /usr/bin/sshf and writes a configuration at /etc/init/sshf.conf.

Service:

Copies itself to /etc/sshf and writes a service configuration at /lib/system/system/sshf.service, then enables the service (to make sure it starts at boot) with two commands:

• systemctl enable sshf
• service enable sshf

All persistence mechanisms on older Linux versions use my.bin and my.bin.desktop instead of sshf and sshf.desktop.

New attack capabilities

In addition to the functions and attacks included in previous versions of the malware, Zerobot 1.1 has additional DDoS attack capabilities. These functions allow threat actors to target resources and make them inaccessible. Successful DDoS attacks may be used by threat actors to extort ransom payments, distract from other malicious activities, or disrupt operations. In almost every attack, the destination port is customizable, and threat actors who purchase the malware can modify the attack according to their target.

The following are the previously known Zerobot capabilities:

Previously undisclosed and new capabilities are the following:

How Zerobot spreads

After persistence is achieved, Zerobot scans for other internet-exposed devices to infect. The malware randomly generates a number between 0 and 255 and scans all IPs starting with this value. Using a function called new_botnet_selfRepo_isHoneypot, the malware tries to identify honeypot IP addresses, which are used by network decoys to attract cyberattacks and collect information on threats and attempts to access resources. This function includes 61 IP subnets, preventing scanning of these IPs.

Microsoft researchers also identified a sample that can run on Windows based on a cross-platform (Linux, Windows, macOS) open-source remote administration tool (RAT) with various features such as managing processes, file operations, screenshotting, and running commands. This tool was found by investigating the command-and-control (C2) IPs used by the malware. The script, which is used to download this RAT, is called impst.sh:

Defending devices and networks against Zerobot

The continuous evolution and rapid addition of new capabilities in the latest Zerobot version underscores the urgency of implementing comprehensive security measures. Microsoft recommends the following steps to protect devices and networks against the threat of Zerobot:

• Use security solutions with cross-domain visibility and detection capabilities like Microsoft 365 Defender, which provides integrated defense across endpoints, identities, email, applications, and data. Microsoft Defender Antivirus and Microsoft Defender for Endpoint detect Zerobot malware variants and malicious behavior related to this threat.

• Adopt a comprehensive IoT security solution such as Microsoft Defender for IoT to allow visibility and monitoring of all IoT and OT devices, threat detection and response, and integration with SIEM/SOAR and XDR platforms such as Microsoft Sentinel and Microsoft 365 Defender.
  • Ensure secure configurations for devices: Change the default password to a strong one, and block SSH from external access.
  • Maintain device health with updates: Make sure devices are up to date with the latest firmware and patches.
  • Use least privileges access: Use a secure virtual private network (VPN) service for remote access and restrict remote access to the device.

• Harden endpoints with a comprehensive Windows security solution:
  • Manage the apps your employees can use through Windows Defender Application Control and for unmanaged solutions, enabling Smart App Control.
  • Perform timely cleanup of all unused and stale executables sitting on yours or your organizations’ devices.

Detections

Microsoft Defender for IoT

Microsoft Defender for IoT uses detection rules and signatures to identify malicious behavior. Microsoft Defender for IoT has alerts for the following vulnerabilities and exploits which may be tied to Zerobot activity:

• CVE-2014-8361
• CVE-2016-20017
• CVE-2017-17105
• CVE-2017-17215
• CVE-2018-10561
• CVE-2018-20057
• CVE-2019-10655
• CVE-2020-7209
• CVE-2020-10987
• CVE-2020-25506
• CVE-2021-35395
• CVE-2021-36260
• CVE-2021-42013
• CVE-2021-46422
• CVE-2022-22965
• CVE-2022-25075
• CVE-2022-26186
• CVE-2022-26210
• CVE-2022-30023
• CVE-2022-30525
• CVE-2022-31137
• CVE-2022-33891
• CVE-2022-34538
• CVE-2022-37061
• ZERO-36290
• ZSL-2022-5717

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects the malicious files under the following platforms and threat names:

• Zerobot (Win32/64 and Linux)
• SparkRat (Win32/64 and Linux)

Microsoft Defender for Endpoint

Microsoft Defender for Endpoint alerts with the following titles can indicate threat activity on your network:

• DEV-1061 threat activity group detected
• An active ‘PrivateLoader’ malware process was detected while executing
• ‘Morila’ malware was prevented
• ‘Multiverze’ malware was detected

Microsoft Defender for Endpoint also has detections for the following vulnerabilities exploited by Zerobot:

• CVE-2022-22965 (Spring4Shell)

Microsoft Defender for Endpoint’s Device Discovery capabilities discover and classify devices. With these capabilities, Microsoft 365 Defender customers using Microsoft Defender for IoT have visibility into security recommendations for devices with the following vulnerabilities:

• CVE-2014-8361
• CVE-2019-10655
• CVE-2020-25506
• CVE-2021-36260
• CVE-2021-42013
• CVE-2022-30525
• CVE-2022-31137
• CVE-2022-37061

Devices with these vulnerabilities are also visible in the Microsoft Defender Vulnerability Management inventory.

Microsoft Defender for Cloud

Microsoft Defender for Cloud alerts with the following titles can indicate threat activity on your network:

• VM_ReverseShell
• VM_SuspectDownloadArtifacts
• SQL.VM_ShellExternalSourceAnomaly
• AppServices_CurlToDisk

Advanced hunting queries

Microsoft 365 Defender

Microsoft 365 Defender customers can run the following query to find related activity in their networks.

Zerobot files

This query finds the file hashes associated with Zerobot activity.

let IoCList = externaldata(TimeGenerated:datetime,IoC:string,IoC_Type:string,ExpirationDateTime:datetime,Description:string, Action:string, ConfidenceScore:real, ThreatType:string, Active:string,Type:string, TrafficLightProtocolLevel:string, 
ActivityGroupNames:string)[@"https://raw.githubusercontent.com/microsoft/mstic/master/RapidReleaseTI/Indicators.csv"] 
with(format="csv", ignoreFirstRecord=True);
let shahashes = IoCList
| where IoC_Type =~ "sha256" and Description =~ "Dev-1061 Zerobot affecting IoT devices"
| distinct IoC;
DeviceFileEvents
| where SHA256 in (shahashes)

Zerobot HTTP requests

This query finds suspicious HTTP requests originated by the IOCs associated with Zerobot activity.

DeviceNetworkEvents
| where RemoteIP in("176.65.137.5","176.65.137.6")
| where ActionType == "NetworkSignatureInspected"
| where Timestamp > ago(30d)
|extend json = parse_json(AdditionalFields)
| extend SignatureName =tostring(json.SignatureName), SignatureMatchedContent = tostring(json.SignatureMatchedContent), SignatureSampleContent = tostring(json.SamplePacketContent)
|where SignatureName == "HTTP_Client"
|project Timestamp, DeviceId, DeviceName, RemoteIP, RemotePort, LocalIP, LocalPort, SignatureName, SignatureMatchedContent, SignatureSampleContent

Zerobot port knocking

This query finds incoming connections from IOCs associated with Zerobot activity.

DeviceNetworkEvents
| where RemoteIP in("176.65.137.5","176.65.137.6")
| where ActionType == "InboundConnectionAccepted"
| where Timestamp > ago(30d)
|project Timestamp, DeviceId, DeviceName, RemoteIP, RemotePort, LocalIP, LocalPort, InitiatingProcessFileName

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace. More details on the Content Hub can be found here:  https://learn.microsoft.com/azure/sentinel/sentinel-solutions-deploy

Indicators of compromise (IOCs):

Domains and IP addresses:

• zero[.]sudolite[.]ml
• 176.65.137[.]5
• 176.65.137[.]5:1401
• 176.65.137[.]6
• ws[:]//176.65.137[.]5/handle
• http[:]//176.65.137[.]5:8000/ws

New Zerobot hashes (SHA-256)

• aed95a8f5822e9b1cd1239abbad29d3c202567afafcf00f85a65df4a365bedbb
• bf582b5d470106521a8e7167a5732f7e3a4330d604de969eb8461cbbbbdd9b9a
• 0a5eebf19ccfe92a2216c492d6929f9cac72ef37089390572d4e21d0932972c8
• 1e7ca210ff7bedeefadb15a9ec5ea68ad9022d0c6f41c4e548ec2e5927026ba4
• 05b7517cb05fe1124dd0fad4e85ddf0fe65766a4c6c9986806ae98a427544e9d
• 5625d41f239e2827eb05bfafde267109549894f0523452f7a306b53b90e847f2
• c304a9156a032fd451bff49d75b0e9334895604549ab6efaab046c5c6461c8b3
• 66c76cfc64b7a5a06b6a26976c88e24e0518be3554b5ae9e3475c763b8121792
• 539640a482aaee2fe743502dc59043f11aa8728ce0586c800193e30806b2d0e5
• 0f0ba8cc3e46fff0eef68ab5f8d3010241e2eea7ee795e161f05d32a0bf13553
• 343c9ca3787bf763a70ed892dfa139ba69141b61c561c128084b22c16829c5af
• 874b0691378091a30d1b06f2e9756fc7326d289b03406023640c978ff7c87712
• 29eface0054da4cd91c72a0b2d3cda61a02831b4c273e946d7e106254a6225a7
• 4a4cb8516629c781d5557177d48172f4a7443ca1f826ea2e1aa6132e738e6db2
• bdfd89bdf6bc2de5655c3fe5f6f4435ec4ad37262e3cc72d8cb5204e1273ccd6
• 62f23fea8052085d153ac7b26dcf0a15fad0c27621f543cf910e37f8bf822e0e
• 788e15fd87c45d38629e3e715b0cb93e55944f7c4d59da2e480ffadb6b981571
• 26e68684f5b76d9016d4f02b8255ff52d1b344416ffc19a2f5c793ff1c2fdc65
• e4840c5ac2c2c2170d00feadb5489c91c2943b2aa13bbec00dbcffc4ba8dcc2d
• 45059f26e32da95f4bb5dababae969e7fceb462cdeadf7d141c39514636b905a
• 77dd28a11e3e4260b9a9b60d58cb6aaaf2147da28015508afbaeda84c1acfe70
• cf232e7d39094c9ba04b9713f48b443e9d136179add674d62f16371bf40cf8c8
• 13657b64a2ac62f9d68aeb75737cca8f2ab9f21e4c38ce04542b177cb3a85521
• eb33c98add35f6717a3afb0ab2f9c0ee30c6f4e0576046be9bf4fbf9c5369f71
• e3dd20829a34caab7f1285b730e2bb0c84c90ac1027bd8e9090da2561a61ab17
• 3685d000f6a884ca06f66a3e47340e18ff36c16b1badb80143f99f10b8a33768
• cdc28e7682f9951cbe2e55dad8bc2015c1591f89310d8548c0b7a1c65dbefae3
• 869f4fb3f185b2d1231d9378273271ddfeebb53085daede89989f9cc8d364f5f
• 6c59af3ed1a616c238ee727f6ed59e962db70bc5a418b20b24909867eb00a9d6
• ef28ee3301e97eefd2568a3cb4b0f737c5f31983710c75b70d960757f2def74e
• 95e4cc13f8388c195a1220cd44d26fcb2e10b7b8bfc3d69efbc51beb46176ff1
• 62f9eae8a87f64424df90c87dd34401fe7724c87a394d1ba842576835ab48afc
• 54d1daf58ecd4d8314b791a79eda2258a69d7c69a5642b7f5e15f2210958bdce
• 8176991f355db10b32b7562d1d4f7758a23c7e49ed83984b86930b94ccc46ab3
• 8aa89a428391683163f0074a8477d554d6c54cab1725909c52c41db2942ac60f
• fd65bd8ce671a352177742616b5facc77194cccec7555a2f90ff61bad4a7a0f6
• 1e66ee40129deccdb6838c2f662ce33147ad36b1e942ea748504be14bb1ee0ef
• 57f83ca864a2010d8d5376c68dc103405330971ade26ac920d6c6a12ea728d3d
• 7bfd0054aeb8332de290c01f38b4b3c6f0826cf63eef99ddcd1a593f789929d6

SparkRat hashes (SHA-256):

• 0ce7bc2b72286f236c570b1eb1c1eacf01c383c23ad76fd8ca51b8bc123be340
• cacb77006b0188d042ce95e0b4d46f88828694f3bf4396e61ae7c24c2381c9bf
• 65232e30bb8459961a6ab2e9af499795941c3d06fdd451bdb83206a00b1b2b88

Rotem Sde-Or, Ilana Sivan, Gil Regev, Microsoft Defender for IoT Research Team
Meitar Pinto, Nimrod Roimy, Nir Avnery, Microsoft Defender Research Team
Ramin Nafisi, Ross Bevington, Microsoft Threat Intelligence Center (MSTIC)

The post Microsoft research uncovers new Zerobot capabilities appeared first on Microsoft Security Blog.

April 2023 update – Microsoft Threat Intelligence has shifted to a new threat actor naming taxonomy aligned around the theme of weather. DEV-1028 is now tracked as Storm-1028.

To learn about how the new taxonomy represents the origin, unique traits, and impact of threat actors, and to get a complete mapping of threat actor names, read this blog: Microsoft shifts to a new threat actor naming taxonomy.

Malware operations continue to rapidly evolve as threat actors add new capabilities to existing botnets, increasingly targeting and recruiting new types of devices. Attackers update malware to target additional operating systems, ranging from PCs to IoT devices, growing their infrastructure rapidly. The Microsoft Defender for IoT research team recently analyzed a cross-platform botnet that originates from malicious software downloads on Windows devices and succeeds in propagating to a variety of Linux-based devices.

The botnet spreads by enumerating default credentials on internet-exposed Secure Shell (SSH)-enabled devices. Because IoT devices are commonly enabled for remote configuration with potentially insecure settings, these devices could be at risk to attacks like this botnet. The botnet’s spreading mechanism makes it a unique threat, because while the malware can be removed from the infected source PC, it could persist on unmanaged IoT devices in the network and continue to operate as part of the botnet.

Microsoft tracks this cluster of activity as DEV-1028, a cross-platform botnet that infects Windows devices, Linux devices, and IoT devices. The DEV-1028 botnet is known to launch distributed denial of service (DDoS) attacks against private Minecraft servers.

Our analysis of the DDoS botnet revealed functionalities specifically designed to target private Minecraft Java servers using crafted packets, most likely as a service sold on forums or darknet sites. A breakdown of the systems affected by the botnet over the three months from the time of this analysis also revealed that most of the devices were in Russia:

This type of threat stresses the importance of ensuring that organizations manage, keep up to date, and monitor not just traditional endpoints but also IoT devices that are often less secure. In this blog post, we share details on how this botnet affects multiple platforms, its DDoS capabilities, and recommendations for organizations to prevent their devices from becoming part of a botnet. We also share Minecraft server version information for owners of private servers to update and ensure they are protected from this threat.

Cross-platform botnet targets SSH-enabled devices

Microsoft researchers observed that the initial infection points related to the botnet were devices infected through the installation of malicious cracking tools that purport to acquire illegal Windows licenses.

The cracking tools contain additional code that downloads and launches a fake version of svchost.exe through a PowerShell command. In some cases, the downloaded file is named svchosts.exe.

Next, svchost.exe launches malicious.py, the main Python script that contains all the logic of the botnet, whichthen scans the internet for SSH-enabled Linux-based devices (Debian, Ubuntu, CentOS, and IoT workloads such as Raspbian, which are commonly enabled for remote configuration) and launches a dictionary attack to propagate. Once a device is found, it downloads the file Updater.zip from repo[.]ark—event[.]net onto the device, which creates the file fuse. The fuse file then downloads a copy of malicious.py onto the device. Both svchost.exe and fuse are compiled using PyInstaller, which bundles all the Python runtime and libraries necessary to initiate malicious.py.

While malicious.py has specific functionalities depending on whether the file launches on a Windows or Linux-based device (for Windows, the file establishes persistency by adding the registry key Software\Microsoft\Windows\CurrentVersion\Run with the executable as the value), the executable is compiled to operate on both Windows and Linux-based devices. The file communicates with its command-and-control (C2) server to launch the following commands:

• Establish TCP connection to repo[.]ark-event[.]net on port 4676.
• Send initial connection string.
• Receive a key from the server for encryption and decryption, and then encrypt further communication using the Fernet symmetric algorithm.
• Send version information to the server:
  • Windows device: The current Windows version
  • Linux device: Hardcoded version (2.19 in the sample we analyzed)
• Continue receiving encrypted commands from the server

Based on our analysis, the botnet is primarily used to launch DDoS attacks against private Minecraft servers using known server DDoS commands and unique Minecraft commands. Below is the list of commands established in the code:

While most of the commands are methods of DDoS, the most notable command run by the botnet is ATTACK_MCCRASH. The command sends ${env:random payload of specific size:-a} as the username in order to exhaust the resources of the server and make it crash.

TCP payloads on port 25565 have the following binary structure:

• Bytes [0:1] – Size of packet
• Bytes [1:2] – Login Start command
• Bytes [2:3] – Size of username
• Bytes [3:18] – Username string

The usage of the env variable triggers the use of Log4j 2 library, which causes abnormal consumption of system resources (not related to Log4Shell vulnerability), demonstrating a specific and highly efficient DDoS method.

A wide range of Minecraft server versions could be affected

While testing the impact of the malware, researchers found that the malware itself was hardcoded to target a specific version of Minecraft server, 1.12.2. However, all versions between 1.7.2 and 1.18.2 can be affected by this method of attack. There is a slight modification in the Minecraft protocol in server version 1.19, which was released earlier in 2022, that prevents the use of the Minecraft specific commands, the ATTACK_MCCRASH, ATTACK_[MCBOT|MINE] and ATTACK_MCDATA, without modification of the attack code.

The wide range of at-risk Minecraft servers highlights the impact this malware could have had if it was specifically coded to affect versions beyond 1.12.2. The unique ability of this threat to utilize IoT devices that are often not monitored as part of the botnet substantially increases its impact and reduces its chances of being detected.

Protecting endpoints from cross-platform DDoS botnets like MCCrash

To harden devices networks against threats like MCCrash, organizations must implement the basics to secure identities and their devices, including access limitation. Solutions must detect downloads of malicious programs and malicious attempts to gain access to SSH-enabled devices and generate alerts on anomalous network behavior. Below are some of our recommendations for organizations:

• Ensure employees are not downloading cracking tools as these are abused as an infection source for spreading malware.

• Increase network security by enforcing multi-factor authentication (MFA) methods such as Azure Active Directory (now part of Microsoft Entra) MFA. Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.
  
  Microsoft 365 Defender protects against attacks related to botnets by coordinating threat data across identities, endpoints, cloud apps, email, and documents. Such cross-domain visibility allows Microsoft 365 Defender to comprehensively detect and remediate end-to-end attack chains—from malicious downloads to its follow-on activities in endpoints. This rich set of tools like advanced hunting let defenders surface threats and gain insights for hardening networks from compromise.

• Adopt a comprehensive IoT security solution such as Microsoft Defender for IoT to allow visibility and monitoring of all IoT and OT devices, threat detection and response, and integration with SIEM/SOAR and XDR platforms such as Microsoft Sentinel and Microsoft 365 Defender. Defender for IoT is updated regularly with indicators of compromise (IoCs) from threat research like the example described in this blog, alongside rules to detect malicious activity.
  
  On the IoT device level:
  • Ensure secure configurations for devices: Change the default password to a strong one, and block SSH from external access.
  • Maintain device health with updates: Make sure devices are up to date with the latest firmware and patches.
  • Use least privileges access: Use a secure virtual private network (VPN) service for remote access and restrict remote access to the device.

• For users hosting private Minecraft servers, update to version 1.19.1 and above.

• Adopt a comprehensive Windows security solution
  • Manage the apps your employees can use through Windows Defender Application Control and for unmanaged solutions, enabling Smart App Control.
  • For commercial customers, enable application and browser controls such as Microsoft Defender Application Guard for enhanced protection for Office and Edge.
  • Perform timely cleanup of all unused and stale executables sitting on your organizations’ devices.
  • Protect against advanced firmware attacks by enabling memory integrity, Secure Boot, and Trusted Platform Module 2.0, if not enabled by default, which hardens boot using capabilities built into modern CPUs.

Indicators of compromise (IOCs)

• e3361727564b14f5ee19c40f4e8714fab847f41d9782b157ea49cc3963514c25 (KMSAuto++.exe)
• 143614d31bdafc026827e8500bdc254fc1e5d877cb96764bb1bd03afa2de2320 (W10DigitalActivation.exe)
• f9c7dd489dd56e10c4e003e38428fe06097aca743cc878c09bf2bda235c73e30 (dcloader.exe)
• 4e65ec5dee182070e7b59db5bb414e73fe87fd181b3fc95f28fe964bc84d2f1f (updater.zip)
• eb57788fd2451b90d943a6a796ac5e79f0faf7151a62c1d07b744a351dcfa382 (svchosts.exe)
• 93738314c07ea370434ac30dad6569c59a9307d8bbde0e6df9be9e2a7438a251 (fuse)
• 202ac3d32871cb3bf91b7c49067bfc935fbc7f0499d357efead1e9f7f5fcb9d1 (malicious.py)
• repo[.]ark-event[.]net

Detections

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects the malware used in this attack as the following:

• TrojanDownloader:MSIL/MCCrash.NZM!MTB
• Trojan:Win32/MCCrash.MA!MTB
• TrojanDownloader:Python/MCCrash!MTB
• Trojan:Python/MCCrash.A
• TrojanDownloader:Linux/MCCrash!MTB
• Trojan:Python/MCCrash.RPB!MTB
• Trojan:Python/MCCrash.RPC!MTB

Microsoft Defender for Endpoint

Microsoft Defender for Endpoint alerts with the following titles can indicate threat activity on your network:

• Emerging threat activity group DEV-1028 detected
• System file masquerade
• Anomaly detected in ASEP registry
• Suspicious process launched using cmd.exe
• Suspicious file launch

Microsoft Defender for IoT

MCCrash-related activity on IoT devices would raise the following alerts in Microsoft Defender for IoT:

• Unauthorized SSH access
• Excessive login attempts

Microsoft Defender for Cloud

Microsoft Defender for Cloud raises the following alert for related activity:

• VM_SuspectDownload

Advanced hunting queries

Microsoft 365 Defender

Run the following queries to search for related files in your environment:

DeviceFileEvents
| where SHA256 in ("e3361727564b14f5ee19c40f4e8714fab847f41d9782b157ea49cc3963514c25","143614d31bdafc026827e8500bdc254fc1e5d877cb96764bb1bd03afa2de2320","f9c7dd489dd56e10c4e003e38428fe06097aca743cc878c09bf2bda235c73e30","4e65ec5dee182070e7b59db5bb414e73fe87fd181b3fc95f28fe964bc84d2f1f","eb57788fd2451b90d943a6a796ac5e79f0faf7151a62c1d07b744a351dcfa382","93738314c07ea370434ac30dad6569c59a9307d8bbde0e6df9be9e2a7438a251","202ac3d32871cb3bf91b7c49067bfc935fbc7f0499d357efead1e9f7f5fcb9d1")

DeviceFileEvents
| where FolderPath endswith @":\windows\svchost.exe"

DeviceRegistryEvents
| where RegistryKey contains "CurrentVersion\\Run"
| where RegistryValueName == "br" or RegistryValueData contains "svchost.exe" or RegistryValueData contains "svchosts.exe"

DeviceProcessEvents
| where FileName in~ ("cmd.exe", "powershell.exe")
| where ProcessCommandLine has_all ("-command", ".downloadfile(", "windows/svchost.exe")

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytic to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace. More details on the Content Hub can be found here:  https://learn.microsoft.com/azure/sentinel/sentinel-solutions-deploy

To supplement this indicator matching, customers can use the following queries against data ingested into their workspaces to help find devices with exposed SSH endpoints, and devices that might be under SSH brute force attempts.

Potential SSH brute force attempt: https://github.com/Azure/Azure-Sentinel/blob/master/Detections/Syslog/ssh_potentialBruteForce.yaml

Exposed critical ports in Azure: https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/AzureDiagnostics/CriticalPortsOpened.yaml

David Atch, Maayan Shaul, Mae Dotan, Yuval Gordon, Microsoft Defender for IoT Research Team

Ross Bevington, Microsoft Threat Intelligence Center (MSTIC)

The post MCCrash: Cross-platform DDoS botnet targets private Minecraft servers appeared first on Microsoft Security Blog.

We assessed the vulnerable component to be the Boa web server, which is often used to access settings and management consoles and sign-in screens in devices. Despite being discontinued in 2005, the Boa web server continues to be implemented by different vendors across a variety of IoT devices and popular software development kits (SDKs). Without developers managing the Boa web server, its known vulnerabilities could allow attackers to silently gain access to networks by collecting information from files. Moreover, those affected may be unaware that their devices run services using the discontinued Boa web server, and that firmware updates and downstream patches do not address its known vulnerabilities.

In this blog, we detail the risks affiliated with vulnerable components, highlighting the Boa web server, and how we suspect these components could be exploited to target critical industries. We also discuss the difficulties with identifying these components in device supply chains. To provide comprehensive protection against such attacks, we offer detection information to identify vulnerable components and guidance for organizations and network operators to improve their security posture.

Investigating the attack activity

The attack detailed in the Recorded Future report was one of several intrusion attempts on Indian critical infrastructure since 2020, with the most recent attack on IT assets confirmed in October 2022. Microsoft assesses that Boa servers were running on the IP addresses on the list of IOCs published by Recorded Future at the time of the report’s release and that the electrical grid attack targeted exposed IoT devices running Boa.

Microsoft further identified that half of the IP addresses published by Recorded Future returned suspicious HTTP response headers, which might be associated with the active deployment of the malicious tool identified by Recorded Future. The combination of Boa and suspicious response headers was identified on another set of IP addresses, displaying similar behavior to those found by Recorded Future. While these IP addresses are not confirmed as malicious, we recommend they be monitored to ensure no additional suspicious activity. Users of Microsoft Defender Threat Intelligence will find these IP addresses in the portal labeled as block-listed or suspicious:

• 122[.]117[.]212[.]65
• 103[.]58[.]93[.]133
• 125[.]141[.]38[.]53
• 14[.]45[.]33[.]239
• 14[.]55[.]86[.]138
• 183[.]108[.]133[.]29
• 183[.]99[.]53[.]180
• 220[.]94[.]133[.]121
• 58[.]76[.]177[.]166

Investigating the headers further indicated that over 10% of all active IP addresses returning the headers were related to critical industries, such as the petroleum industry and associated fleet services, with many of the IP addresses associated to IoT devices, such as routers, with unpatched critical vulnerabilities, highlighting an accessible attack vector for malware operators. Most of the suspicious HTTP response headers were returned over a short timeframe of several days, leading researchers to believe they may be associated with intrusion and malicious activity on networks.

Since the report’s publication, Microsoft researchers tracking the published IPs hosts have observed that all IP addresses have been compromised by a variety of attackers employing different malicious methods. For example, some of the IP addresses were further leveraged to download a variant of the Mirai malware family shortly following the report’s release. Microsoft also found evidence that across different devices on the IP addresses, there were attempts to connect with default credentials through brute force methods and attempts to run shell commands. Microsoft continues to see attackers attempting to exploit Boa vulnerabilities beyond the timeframe of the released report, indicating that it is still targeted as an attack vector.

Boa widespread through SDKs

The Boa web server is widely implemented across a variety of devices, including IoT devices ranging from routers to cameras, and is often used to access settings and management consoles as well as sign-in screens. The popularity of Boa web servers is especially concerning as Boa has been formally discontinued since 2005. Data from the Microsoft Defender Threat Intelligence platform identified over 1 million internet-exposed Boa server components around the world over the span of a week, as depicted in the below figure:

Boa web servers remain pervasive in the development of IoT devices, one reason for this could be its inclusion in popular SDKs, which contain essential functions that operate system on chip (SOC) implemented in microchips. Vulnerable components like Boa and SDKs are often distributed to customers within devices, contributing to supply chain vulnerabilities. Popular SDKs like those released by RealTek, are used in SOCs provided to companies that manufacture gateway devices like routers, access points, and repeaters. Critical vulnerabilities such as CVE-2021-35395, which affected the digital administration of devices using RealTek’s SDK, and CVE-2022-27255, a zero-click overflow vulnerability, reportedly affect millions of devices globally and allow attackers to launch code, compromise devices, deploy botnets, and move laterally on networks.

While patches for the RealTek SDK vulnerabilities are available, some vendors may not have included them in their device firmware updates, and the updates do not include patches for Boa vulnerabilities. Boa servers are affected by several known vulnerabilities, including CVE-2009-4496, which could allow attackers to execute code remotely. Additional vendor and device specific vulnerabilities exist across a range of devices including routers.

The popularity of the Boa web server displays the potential exposure risk of an insecure supply chain, even when security best practices are applied to devices in the network. Updating the firmware of IoT devices does not always patch SDKs or specific SOC components and there is limited visibility into components and whether they can be updated. The known CVEs impacting such components can allow an attacker to collect information about network assets before initiating attacks, and to gain access to a network undetected by obtaining valid credentials. In critical infrastructure networks, being able to collect information undetected prior to the attack allows the attackers to have much greater impact once the attack is initiated, potentially disrupting operations that can cost millions of dollars and affect millions of people.

Recommendations

As attackers seek new footholds into increasingly secure devices and networks, identifying and preventing distributed security risks through software and hardware supply chains, like outdated components, should be prioritized by organizations. This case displays the importance of proactive cyber security practices and the need to identify vulnerable components that may be leveraged by attackers.

Microsoft recommends that organizations and network operators follow best practice guidelines for their networks:

• Patch vulnerable devices whenever possible to reduce exposure risks across your organization.
• Utilize device discovery and classification to identify devices with vulnerable components by enabling vulnerability assessments, which identifies unpatched devices in the organizational network and set workflows for initiating appropriate patch processes with solutions like Microsoft Defender Vulnerability Management and Microsoft Defender for Endpoint with Microsoft Defender for IoT .
• Extend vulnerability and risk detection beyond the firewall with platforms like Microsoft Defender External Attack Surface Management. Customers can identify internet-exposed infrastructure running Boa web server components in their inventory and use the insights tile under the Attack Surface Summary dashboard to surface assets vulnerable to CVE-2009-4496. The insight can be found under High Severity Observations.
• Reduce the attack surface by eliminating unnecessary internet connections to IoT devices in the network. Apply network segmentation to prevent an attacker from moving laterally and compromising assets after intrusion. IoT and critical device networks should be isolated with firewalls.
• Use proactive antivirus scanning to identify malicious payloads on devices.
• Configure detection rules to identify malicious activity whenever possible. Security personnel can use our snort rule below to configure security solutions to detect CVE-2022-27255 on assets using the RealTek SDK.

alert udp any any -> any any (msg:"Realtek eCOS SDK SIP Traffic Exploit CVE-2022-27255"; content: "invite"; depth: 6; nocase;  content: "sip:"; content: "m=audio "; isdataat: 128,relative;   content:!"|0d|"; within: 128;sid:20221031;)

• Adopt a comprehensive IoT and OT solution like Microsoft Defender for IoT to monitor devices, respond to threats, and increase visibility in order to detect and alert when IoT devices with Boa are used as an entry point to a network and protect critical infrastructure. 

Adam Castleman, Jordan Herman, Microsoft Defender Threat Intelligence
Rotem Sde Or, Ilana Sivan, Gil Regev, Microsoft Defender for IoT Research Team
Ross Bevington, Microsoft Threat Intelligence Center

The post Vulnerable SDK components lead to supply chain risks in IoT and OT environments appeared first on Microsoft Security Blog.

The attack brings to light the risk of threat actors gaining access to industrial control system (ICS) environments. According to reports, a group associated with the Cl0p ransomware claimed responsibility for the attack, which followed a familiar extortion model wherein attackers extort the target for exfiltrated data without encrypting the organization’s files. After the attack, confidential documents, along with screenshots of the supervisory control and data acquisition (SCADA) system used by water treatment plants were leaked.

As details of the attack and the vector used to access South Staffordshire PLC’s networks are limited, the Microsoft Defender for IoT research team did further research on techniques used by threat actors in similar attacks. Microsoft researchers have previously observed activity relating to internet-exposed IoT devices across different industries, which may be used as a potential foothold into OT networks. Threat actors gain access by deploying malware on information technology (IT) devices and then crossing the boundary to the operational technology (OT) part of the network to target high-value operational assets, or by compromising unmanaged, usually less secure IoT and OT devices.

IoT devices in critical infrastructure networks

IoT devices offer significant value to organizations and extend beyond environmental monitoring sensors to common office equipment and network devices. However, IoT devices in critical infrastructure networks, if not properly secured, increase the risk of unauthorized access to operational assets and networks. Improper configurations such as default credentials and unpatched vulnerabilities are often abused by threat actors to gain network or device access. Once access is established, attackers could identify other assets on the same network, perform reconnaissance, and plan large-scale attacks on sensitive equipment and devices.

In monitoring threats against critical infrastructure and utilities, Microsoft researchers investigated water utility providers in the United Kingdom with exposed IoT devices within their networks. Using open-source intelligence (OSINT) and Microsoft Defender Threat Intelligence data, the team searched for exposed IoT devices integrated into the networks of water utility providers and found that such facilities were using Draytek Vigor routers, which are intended for home use.

With difficult-to-patch devices such as printers, cameras, routers, and gateway devices overlooked as potential footholds into networks, they are often left exposed. In analyzing Microsoft threat intelligence, Microsoft researchers observed threat actors abusing a known remote code execution vulnerability in Draytek Vigor devices (CVE-2020-8515) to deploy the Mirai botnet. Once attackers establish device access, remote code execution vulnerabilities such as CVE-2020-8515 can then allow attackers to run malicious commands on devices, move laterally within the network, and access other vulnerable devices which were not directly exposed to the internet such as SCADA systems. 

In water treatment applications, SCADA systems allow water plants to monitor levels of specific chemicals and toxins and to collect records of the systems. While the attack against South Staffordshire PLC does not appear to have included the abuse of these devices, the release of files pertaining to OT systems constitutes a high-risk to operations and highlights the importance of network segmentation to protect devices and networks from lateral movement.

Defending critical networks

Attacks on utility providers’ OT networks and devices are high-risk events that can range from data theft to the manipulation of devices controlling the operations. Such events can lead to the interruption of operations, or in severe cases, potential harm to individuals and customers (For example, when hackers gained access to the water system of one Florida city as reported in February 2021).

Given the severity of these attacks and their potential impact on the utility providers’ operations and even the safety of their customers, it becomes crucial to recognize the importance of proper security practices around IoT & OT unmanaged devices to ensure that such attacks do not happen. Defenses set up for OT networks must be comprehensive, able to prevent unauthorized system access and should include detections for abnormal, unfamiliar, and malicious behaviors after a breach.

It is important to protect assets and have strict security protocols in place for how and when devices and data can be accessed. We recommend the following defense strategies for organizations with both IoT and OT devices within their networks:  

• Adopt a comprehensive IoT and OT security solution such as Microsoft Defender for IoT to allow visibility and monitoring of all IoT and OT devices, threat detection and response, and integration with SIEM/SOAR and XDR platforms such as Microsoft Sentinel and Microsoft Defender 365.
• Enable vulnerability assessments to identify unpatched devices in the organizational network and set workflows for initiating appropriate patch processes through  Microsoft Defender Vulnerability Management and Microsoft Defender for Endpoint with the Microsoft Defender for IoT add-on.
• Reduce the attack surface by eliminating unnecessary internet connections to IoT devices and OT control systems. Implement Zero Trust practices by applying network segmentation to prevent an attacker from moving laterally and compromising assets after intrusion. IoT devices and OT networks should be isolated from IT and OT networks with firewalls. Extend vulnerability and exposure control beyond the firewall with Microsoft Defender External Attack Surface Management. Turn on attack surface reduction rules in Microsoft Defender for Endpoint to prevent common attack techniques such as those used by ransomware groups.
• Increase network security by enforcing multi factor authentication (MFA) methods such as Azure Active Directory MFA. Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.

David Atch, Ilana Sivan, and Mae Dotan, Microsoft Defender for IoT Research Team
Ross Bevington, Microsoft Threat Intelligence Center (MSTIC)
Jaclyn Blumenfield, Microsoft Defender Threat Intelligence

The post Securing IoT devices against attacks that target critical infrastructure appeared first on Microsoft Security Blog.

This continuous evolution has seen Trickbot expand its reach from computers to Internet of Things (IoT) devices such as routers, with the malware updating its C2 infrastructure to utilize MikroTik devices and modules. MikroTik routers are widely used around the world across different industries. By using MikroTik routers as proxy servers for its C2 servers and redirecting the traffic through non-standard ports, Trickbot adds another persistence layer that helps malicious IPs evade detection by standard security systems.

The Microsoft Defender for IoT research team has recently discovered the exact method through which MikroTik devices are used in Trickbot’s C2 infrastructure. In this blog, we will share our analysis of the said method and provide insights on how attackers gain access to MikroTik devices and use compromised IoT devices in Trickbot attacks.

This analysis has enabled us to develop a forensic tool to identify Trickbot-related compromise and other suspicious indicators on MikroTik devices. We published this tool to help customers ensure these IoT devices are not susceptible to these attacks. We’re also sharing recommended steps for detection and remediating compromise if found, as well as general prevention steps to protect against future attacks.

How attackers compromise MikroTik devices for Trickbot C2

The purpose of Trickbot for using MikroTik devices is to create a line of communication between the Trickbot-affected device and the C2 server that standard defense systems in the network are not able to detect. The attackers begin by hacking into a MikroTik router. They do this by acquiring credentials using several methods, which we will discuss in detail in the following section.

The attackers then issue a unique command that redirects traffic between two ports in the router, establishing the line of communication between Trickbot-affected devices and the C2. MikroTik devices have unique hardware and software, RouterBOARD and RouterOS. This means that to run such a command, the attackers need expertise in RouterOS SSH shell commands. We uncovered this attacker method by tracking traffic containing these SSH shell commands.

Accessing the MikroTik device and maintaining access

Attackers first need to access the MikroTik shell to run the routing commands. To do so, they need to acquire credentials. As mentioned earlier, based on our analysis, there are several methods that attackers use to access a target router:

• Using default MikroTik passwords.
• Launching brute force attacks. We have seen attackers use some unique passwords that probably were harvested from other MikroTik devices.
• Exploiting CVE-2018-14847 on devices with RouterOS versions older than 6.42. This vulnerability gives the attacker the ability to read arbitrary files like user.dat, which contains passwords.

To maintain access, the attackers then change the affected router’s password.

Redirecting traffic

MikroTik devices have a unique Linux-based OS called RouterOS with a unique SSH shell that can be accessed through SSH protocol using a restricted set of commands. These commands can be easily identified by the prefix “/”. For example:

/ip
/system
/tool

These commands usually won’t have any meaning on regular Linux-based shells and are solely intended for MikroTik devices. We observed through Microsoft threat data the use of these types of commands. Understanding that these are MikroTik-specific commands, we were able to track their source and intent. For example, we observed attackers issuing the following commands:

/ip firewall nat add chain=dstnat proto=tcp dst-port=449   to-port=80 action=dst-nat to-addresses=<infected device> dst-address=<real C2 address>

From the command, we can understand the following:

• A new rule, similar to iptables, is created
• The rule redirects traffic from the device to a server
• The redirected traffic is received from port 449 and redirected to port 80

The said command is a legitimate network address translation (NAT) command that allows the NAT router to perform IP address rewriting. In this case, it is being used for malicious activity. Trickbot is known for using ports 443 and 449, and we were able to verify that some target servers were identified as TrickBot C2 servers in the past.

This analysis highlights the importance of keeping IoT devices secure in today’s ever evolving threat environment. Using Microsoft threat data, Microsoft’s IoT and operational technology (OT) security experts established the exact methods that attackers use to leverage compromised IoT devices and gained knowledge that can help us better protect customers from threats.

Defending IoT devices against Trickbot attacks

As security solutions for conventional computing devices continue to evolve and improve, attackers will explore alternative ways to compromise target networks. Attack attempts against routers and other IoT devices are not new, and being unmanaged, they can easily be the weakest links in the network. Therefore, organizations should also consider these devices when implementing security policies and best practices.

An open-source tool for MikroTik forensics

While investigating MikroTik and attacks in the wild, we observed several methods of attacking these devices in addition to the method we described in this blog. We aggregated our knowledge of these methods and known CVEs into an open-source tool that can extract the forensic artifacts related to these attacks.

Some of this tool’s functionalities include the following:

• Get the version of the device and map it to CVEs
• Check for scheduled tasks
• Look for traffic redirection rules (NAT and other rules)
• Look for DNS cache poisoning
• Look for default ports change
• Look for non-default users

We have published the tool in GitHub and are sharing this tool with the broader community to encourage better intelligence-sharing in the field of IoT security and to help build better protections against threat actors abusing IoT devices.

How to detect, remediate, and prevent infections

Organizations with potentially at-risk MikroTik devices can perform the following detection and remediation steps:

• Run the following command to detect if the NAT rule was applied to the device (completed by the tool as well):

/ip firewall nat print

If the following data exists, it might indicate infection:

chain=dstnat action=dst-nat to-addresses=<public IP address> 
to-ports=80 protocol=tcp dst-address=<your MikroTik IP> dst-port=449 
chain=srcnat action=masquerade src-address=<your MikroTik IP>

• Run the following command to remove the potentially malicious NAT rule:

/ip firewall nat remove numbers=<rule number to remove>

To prevent future infections, perform the following steps:

• Change the default password to a strong one
• Block port 8291 from external access
• Change SSH port to something other than default (22)
• Make sure routers are up to date with the latest firmware and patches
• Use a secure virtual private network (VPN) service for remote access and restrict remote access to the router

Protect IoT devices and IT networks with Microsoft Defender

To harden IoT devices and IT networks against threats like Trickbot, organizations must implement solutions that detect malicious attempts to access devices and raises alerts on anomalous network behavior. Microsoft Defender for IoT provides agentless, network-layer security that lets organizations deploy continuous asset discovery, vulnerability management, and threat detection for IoT, OT devices, and Industrial Control Systems (ICS) on-premises or in Azure-connected environments. It is updated regularly with indicators of compromise (IoCs) from threat research like the one described on this blog, and rules to detect malicious activity.

Meanwhile, Microsoft 365 Defender protects against attacks related to highly modular, multi-stage malware like Trickbot by coordinating threat data across identities, endpoints, cloud apps, email, and documents. Such cross-domain visibility allows Microsoft 365 Defender to comprehensively detect and remediate Trickbot’s end-to-end attack chain—from malicious attachments and links it sends via emails to its follow-on activities in endpoints. Its rich set of tools like advanced hunting also lets defenders surface threats and gain insights for hardening networks from compromise.

In addition, working with the Microsoft Defender for IoT Research Team, RiskIQ identified compromised MikroTik routers acting as communication channels for Trickbot C2 and created detection logic to flag devices under threat actor control. See RiskIQ’s article.

To learn more about securing your IoT and OT devices, explore Microsoft Defender for IoT.

David Atch, Section 52 at Microsoft Defender for IoT
Noa Frumovich, Section 52 at Microsoft Defender for IoT
Ross Bevington, Microsoft Threat Intelligence Center (MSTIC)

The post Uncovering Trickbot’s use of IoT devices in command-and-control infrastructure appeared first on Microsoft Security Blog.

Natalia: What tools do you use to monitor and govern your OT environment?

Chris: First, you can use the control system itself, which already offers some level of visibility into what’s happening. It looks like NASA control. Operators sit and watch the process all day. You can see what looks normal and what doesn’t look normal.

What’s new is not just looking at the system itself but at OT network security. Especially in the last five or six years, the focus has been on getting network visibility sensors into the control network. There are several vendors out there that understand the protocols, like MODBUS, Siemens S7, and DNP3, and have developed sensors that are purpose-built to analyze OT network traffic rather than IT traffic.

With a newer control system, it’s much easier. Many times, they’ll use virtual machines to manage OT, so you can put agents in those areas. If it’s a Windows 10 or Windows 7 environment, you can even use Microsoft Defender Antivirus and collect the Windows event logs and switch logs. If you don’t look at the logs, you’re not going to know what’s there, so you need to monitor behavior at the network layer using technologies like deep packet inspection (DPI) to identify compromised devices.

Natalia: What are some best practices for securing remote access to the OT network?

Chris: Number one, if you don’t need it at all, don’t have it. That’s the most secure option.

Number two, if you have to have it, make sure it’s engineered for why it’s needed and tightly control who can use it. It’s also important to make sure it’s monitored and protected with multifactor authentication (MFA) unless it’s just for read-only access to the control network, in which case it’s less of a risk. A lot of times, these OT equipment vendors require in their warranty contracts that they have remote access with full control and the ability to change configurations, which means you’ve given someone a high level of privileged access to your control systems.

Number three, have a process and procedure for when that remote access is used and when it’s turned off. You should at least know who was there and for how long, and who did what, using audit logs, for example.

I want to highlight that the Water ISAC, the international security network created for the water and wastewater sector, published a free document called 15 Cybersecurity Fundamentals for Water and Wastewater Utilities. It’s a reminder to consider where remote access is coming from.

Natalia: What percentage of organizations are continuously monitoring their OT networks?

Chris: Today, it’s the exception, not the rule. The only ones monitoring are the ones that have to do it, such as nuclear companies, and the 3,000 or so largest electric utilities that are under North American Electric Reliability Corporation Critical Infrastructure Protection Standards (NERC CIP) regulation, as well as any companies that might have been attacked in the past. But even NERC CIP doesn’t require continuous network security monitoring, just monitoring event logs in a SIEM, for example, which means you can still miss stuff.

So percentage-wise, it’s not very many, especially in non-regulated sectors like manufacturing, pharmaceuticals, chemicals, oil and gas, mining, and warehousing and logistics.

Companies don’t like to spend money on security if they don’t have to. Unfortunately, it’s going to take an attack. We didn’t have electric reliability standards until we had two Northeast blackouts that affected millions of people in 1965 and in August 2003. After that, they said, “Oh, we should probably have some electric reliability standards.” When I started at the power company, one of the lineman safety instructors said, “Safety rules are written in blood.” The only reason why we have reliability rules is because we’ve had darkness.

Natalia: How can teams break down IT and OT silos?

Chris: Communication. It’s the only thing you can do. If you’re in IT, go take a box of doughnuts down to the operators and ask, “What are the pain points here? How can I learn more about what you do so I can understand and so you won’t slap my hand every time I say, ‘Please patch.’” They will be overjoyed that someone came and visited them to learn about what they do.

Generally, if an IT guy with a white hard hat that has never had a scratch on it comes in, operators think, “Don’t touch anything.” But if you build that trust and communication, that strengthens an organization, and you can start training and knowledge sharing.

Natalia: What should roles and responsibilities look like?

Chris: Now, anything that’s on a network, even in the control system environment, can report up through the chief information officer (CIO) or chief information security officer (CISO). Even in power companies, they’re putting everyone, even the folks who do SCADA for the power grid, under the CIO or CISO instead of under operations. At smaller companies, like water and wastewater, it’s still the old situation, where you have an IT guy and an OT engineer or operator. At larger companies, OT is coming through the IT organization under the CIO or IT is under the CIO and operations is still under operations, and the link is under the CISO. You might have security people in IT and security people in OT.

If you’re wondering whether the CISO should be responsible for both IT and OT security, it’s a simple answer. You can’t have enterprise-wide security unless you include OT. Security needs to be applied to it all, but go to a provider that says they provide enterprise-wide security and ask, “Do you know anything about OT networks in power plants?” “Nope.” OK, then, you don’t do enterprise-wide security. You’re not protecting what makes money.

Natalia: Should companies unify IT and OT security in the security operations center (SOC)?

Chris: I’ve seen it implemented as one unified SOC, but I’ve also seen two separate ones because if they have physically separate systems, they have to have physically separate SIEMs. For instance, a nuclear plant will have its own SOC, and corporate will have its own SOC. If a power company has a nuclear power plant, that plant will have its own SOC because it’s air-gapped and not connected to the outside world or the IT network. But if you have an oil and gas environment, it may have both combined into one.

There are pros and cons. If you have the money and the budget and the people, you can do it either way. Just put your people in a room, give them a lunch of pizza, and let them come up with the best solution. There are advantages of having a unified SOC. You don’t even need an OT-specific SOC analyst. Just have a good IT security person learn from the control engineers or operators, and then create those alerts, and do hunting, tool tuning, and rule tuning.

Natalia: What would you say to a board of directors to get them to prioritize OT security?

Chris: I’d keep it short and sweet: “What would happen if you couldn’t make hammers anymore?” If the CISO can’t answer that question, you know the person needs to gain that awareness. Do we have visibility of the network? Do we have offsite backups for our control systems? Do we have security awareness training?

Board members are not concerned with the latest and greatest advanced persistent threat (ATP), but they do care about risk to the business. They’ll say, “We don’t have any security because we don’t have enough people. If we don’t have security implemented, we have a small risk of having downtime.” If you talk to any manager, they’ll know exactly how much money they lose per day if production goes down. We look at business risk in terms of the equation: risk equals impact times probability. Since we don’t have enough data about cyberattacks in OT to have a probability, we tie cybersecurity to the risk register and substitute probability with exploitability. How easy is it to exploit? Can a script kiddie do it? Could my 13-year-old son do it?

If you’ve got an operating system exposed to the Internet, discoverable via Shodan, it is exploitable within minutes. What is the impact of that? If it’s in a chemical, pharmaceutical, food factory, or refinery, that’s a problem not just for downtime but more importantly because it could cause a safety or environmental incident. If it’s a temperature gauge, that’s much less risk. Companies will have a risk register for everything else, including natural disasters. They should have one for OT cybersecurity risk too.

Learn more

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.

The post Mitigate OT security threats with these best practices appeared first on Microsoft Security Blog.