Category Archives: Ics

US Treasury imposes sanctions on a Russian research institute behind Triton malware

US Treasury Department announced sanctions against Russia’s Central Scientific Research Institute of Chemistry and Mechanics behind Triton malware.

The US Treasury Department announced sanctions against a Russian research institute for its alleged role in the development of the Triton malware.

“Today, the Department of the Treasury’s Office of Foreign Assets Control (OFAC) designated, pursuant to Section 224 of the Countering America’s Adversaries Through Sanctions Act (CAATSA), a Russian government research institution that is connected to the destructive Triton malware.” reads a press release published by the Department of the Treasury.

Triton is a strain of malware specifically designed to target industrial control systems (ICS) system that has been spotted by researchers at FireEye in December 2017.

The malware was first spotted after it was employed in 2017 in an attack against a Saudi petrochemical plant owned by the privately-owned Saudi company Tasnee. According to the experts, the infection caused an explosion.

“In August 2017, a petrochemical facility in the Middle East was the target of a cyber-attack involving the Triton malware. This cyber-attack was supported by the State Research Center of the Russian Federation FGUP Central Scientific Research Institute of Chemistry and Mechanics (TsNIIKhM), a Russian government-controlled research institution that is responsible for building customized tools that enabled the attack.” continues the press release.

The Triton malware is designed to target Schneider Electric’s Triconex Safety Instrumented System (SIS) controllers that are used in industrial environments to monitor the state of a process and restore it to a safe state or safely shut it down if parameters indicate a potentially hazardous situation.

“Mandiant recently responded to an incident at a critical infrastructure organization where an attacker deployed malware designed to manipulate industrial safety systems. The targeted systems provided emergency shutdown capability for industrial processes.” reads the analysis published by FireEye in 2017.

“We assess with moderate confidence that the attacker was developing the capability to cause physical damage and inadvertently shutdown operations. This malware, which we call TRITON, is an attack framework built to interact with Triconex Safety Instrumented System (SIS) controllers.”

Triton malware

Once gained access to the SIS system, the threat actor deployed the TRITON malware, a circumstance that indicates that attackers had a knowledge of such systems. According to FireEye the attackers pre-built and tested the tool which would require access to hardware and software that is not widely available. TRITON is also designed to communicate using the proprietary TriStation protocol which is not publicly documented, this implies that the attackers reverse engineered the protocol to carry out the attack.

The Triton malware interacts with Triconex SIS controllers., it is able to read and write programs and functions to and from the controller.

Triton Malware Triconex

The hackers deployed the Triton malware on a Windows-based engineering workstation, the malicious code added its own programs to the execution table. In case of a failure, the malware attempts to return the controller to a running state, it also overwrites the malicious program with junk data if the attempt fails, likely to delete any track of the attack.

The US Treasury Department imposed sanctions on the State Research Center of the Russian Federation FGUP Central Scientific Research Institute of Chemistry and Mechanics (also known as CNIIHM or TsNIIKhM).

In October 2018, FireEye experts discovered a link between the Triton malware, tracked by the company as TEMP.Veles, and the Central Scientific Research Institute of Chemistry and Mechanics (CNIIHM), a Russian government research institute in Moscow.

FireEye collected strong evidence suggesting that the Russian CNIIHM institute has been involved in the development of some of the tools used in the Triton attack.

“FireEye Intelligence assesses with high confidence that intrusion activity that led to deployment of TRITON was supported by the Central Scientific Research Institute of Chemistry and Mechanics (CNIIHM; a.k.a. ЦНИИХМ), a Russian government-owned technical research institution located in Moscow. The following factors supporting this assessment are further detailed in this post.” reads the analysis published by FireEye.

  1. FireEye uncovered malware development activity that is very likely supporting TEMP.Veles activity. This includes testing multiple versions of malicious software, some of which were used by TEMP.Veles during the TRITON intrusion.
  2. Investigation of this testing activity reveals multiple independent ties to Russia, CNIIHM, and a specific person in Moscow. This person’s online activity shows significant links to CNIIHM.
  3. An IP address registered to CNIIHM has been employed by TEMP.Veles for multiple purposes, including monitoring open-source coverage of TRITON, network reconnaissance, and malicious activity in support of the TRITON intrusion.
  4. Behavior patterns observed in TEMP.Veles activity are consistent with the Moscow time zone, where CNIIHM is located.
  5. We judge that CNIIHM likely possesses the necessary institutional knowledge and personnel to assist in the orchestration and development of TRITON and TEMP.Veles operations.” 

Experts pointed out that Triton is linked to Russia, the CNIIHM, and an individual located in Moscow. Some of the TEMP.Veles hacking tools were tested using an unnamed online scan service. A specific user of the service who has been active since 2013 has tested various tools across the time.

The user also tested several customized versions of widely available tools, including Metasploit, Cobalt Strike, PowerSploit, the PowerShell-based WMImplant, and cryptcat.

In many cases, the custom versions of the tools were used in TEMP.Veles attacks just days after being submitted to the testing environment.

The experts discovered that a PDB path contained in a tested file included a string that appears to be an online moniker associated with a Russia-based individual active in Russian information security communities since at least 2011.

According to a now-defunct social media profile, the individual was a professor at CNIIHM.

FireEye also discovered that one IP address registered to the Russian research institute was involved in the Triton attacks.

The sanctions prohibit US entities from engaging with CNIIHM and also seize any asset on the US soil belonging to the research institute.

“The Russian Government continues to engage in dangerous cyber activities aimed at the United States and our allies,” said Secretary Steven T. Mnuchin. “This Administration will continue to aggressively defend the critical infrastructure of the United States from anyone attempting to disrupt it.”

TsNIIKhM is being designated pursuant to Section 224 of CAATSA for knowingly engaging in significant activities undermining cybersecurity against any person, including a democratic institution, or government on behalf of the Government of the Russian Federation.” concludes the press release.

“As a result of today’s designation, all property and interests in property of TsNIIKhM that are in or come within the possession of U.S. persons are blocked, and U.S. persons are generally prohibited from engaging in transactions with them. Additionally, any entities 50 percent or more owned by one or more designated persons are also blocked. Moreover, non-U.S. persons who engage in certain transactions with TsNIIKhM may themselves be exposed to sanctions.”

On Thursday, the Cybersecurity and Infrastructure Security Agency (CISA) and the Federal Bureau of Investigation (FBI) issued a joint report that provides details about a hacking campaign of a Russian hacking group known as Energetic Bear.

The EU Council also imposed sanctions on two Russian intelligence officers for their role in the 2015 Bundestag hack.

Pierluigi Paganini

(SecurityAffairs – hacking, Triton)

The post US Treasury imposes sanctions on a Russian research institute behind Triton malware appeared first on Security Affairs.

Monitoring ICS Cyber Operation Tools and Software Exploit Modules To Anticipate Future Threats

There has only been a small number of broadly documented cyber attacks targeting operational technologies (OT) / industrial control systems (ICS) over the last decade. While fewer attacks is clearly a good thing, the lack of an adequate sample size to determine risk thresholds can make it difficult for defenders to understand the threat environment, prioritize security efforts, and justify resource allocation.

To address this problem, FireEye Mandiant Threat Intelligence produces a range of reports for subscription customers that focus on different indicators to predict future threats. Insights from activity on dark web forums, anecdotes from the field, ICS vulnerability research, and proof of concept research makes it possible to illustrate the threat landscape even with limited incident data. This blog post focuses on one of those source sets—ICS-oriented intrusion and attack tools, which will be referred to together in this post as cyber operation tools.

ICS-oriented cyber operation tools refer to hardware and software that has the capability to either exploit weaknesses in ICS, or interact with the equipment in such a way that could be utilized by threat actors to support intrusions or attacks. For this blog post, we separated exploit modules that are developed to run on top of frameworks such as Metasploit, Core Impact, or Immunity Canvas from other cyber operation tools due to their exceedingly high number.

Cyber Operation Tools Reduce the Level of Specialized Knowledge Attackers Need to Target ICS

As ICS are a distinct sub-domain to information and computer technology, successful intrusions and attacks against these systems often requires specialized knowledge, establishing a higher threshold for successful attacks. Since intrusion and attack tools are often developed by someone who already has the expertise, these tools can help threat actors bypass the need for gaining some of this expertise themselves, or it can help them gain the requisite knowledge more quickly. Alternatively, experienced actors may resort to using known tools and exploits to conceal their identity or maximize their budget.


Figure 1: ICS attacker knowledge curve

The development and subsequent adoption of standardized cyber operation tools is a general indication of increasing adversarial capability. Whether these tools were developed by researchers as proof-of-concept or utilized during past incidents, access to them lowers the barrier for a variety of actors to learn and develop future skills or custom attack frameworks. Following this premise, equipment that is vulnerable to exploits using known cyber operation tools becomes low-hanging fruit for all sorts of attackers.

ICS Cyber Operation Tool Classification

Mandiant Intelligence tracks a large number of publicly available ICS-specific cyber operation tools. The term "ICS-specific," as we employ it, does not have a hard-edged definition. While the vast majority of cyber operation tools we track are clear-cut cases, we have, in some instances, considered the intent of the tool's creator(s) and the tool's reasonably foreseeable impact on ICS software and equipment. Note, we excluded tools that are IT-based but may affect OT systems, such as commodity malware or known network utilities.  We included only a few exceptions, where we identified specialized adaptations or features that enabled the tool to interact with ICS, such as the case of nmap scripts.

We assigned each tool to at least one of eight different categories or classes, based on functionality.


Table 1: Classes of ICS-specific intrusion and attack tools

While some of the tools included in our list were created as early as 2004, most of the development has taken place during the last 10 years. The majority of the tools are also vendor agnostic, or developed to target products from some of the largest ICS original equipment manufacturers (OEM). Siemens stands out in this area, with 60 percent of the vendor-specific tools potentially targeting its products. Other tools we identified were developed to target products from Schneider Electric, GE, ABB, Digi International, Rockwell Automation, and Wind River Systems.

Figure 2 depicts the number of tools by class. Of note, network discovery tools make up more than a quarter of the tools. We also highlight that in some cases, the software exploitation tools we track host extended repositories of modules to target specific products or vulnerabilities.


Figure 2: ICS-specific intrusion and attack tools by class

Software Exploit Modules

Software exploit modules are the most numerous subcomponents of cyber operation tools given their overall simplicity and accessibility. Most frequently, exploit modules are developed to take advantage of a specific vulnerability and automate the exploitation process. The module is then added to an exploit framework. The framework works as a repository that may contain hundreds of modules for targeting a wide variety of vulnerabilities, networks, and devices. The most popular frameworks include Metasploit, Core Impact, and Immunity Canvas. Also, since 2017, we have identified the development of younger ICS-specific exploit frameworks such as AutosploitIndustrial Exploitation Framework (ICSSPLOIT), and the Industrial Security Exploitation Framework.

Given the simplicity and accessibility of exploit modules, they are attractive to actors with a variety of skill levels. Even less sophisticated actors may take advantage of an exploit module without completely understanding how a vulnerability works or knowing each of the commands required to exploit it. We note that, although most of the exploit modules we track were likely developed for research and penetration testing, they could also be utilized throughout the attack lifecycle.

Exploit Modules Statistics

Since 2010, Mandiant Intelligence has tracked exploit modules for the three major exploitation frameworks: Metasploit, Core Impact, and Immunity Canvas. We currently track hundreds of ICS-specific exploit modules related to more than 500 total vulnerabilities, 71 percent of them being potential zero-days. The break down is depicted in Figure 3. Immunity Canvas currently has the most exploits due in large part to the efforts of Russian security research firm GLEG.


Figure 3: ICS exploit modules by framework

Metasploit framework exploit modules deserve particular attention. Even though it has the fewest number of modules, Metasploit is freely available and broadly used for IT penetration testing, while Core Impact and Immunity Canvas are both commercial tools. This makes Metasploit the most accessible of the three frameworks. However, it means that module development and maintenance are provided by the community, which is likely contributing to the lower number of modules.

It is also worthwhile to examine the number of exploit modules by ICS product vendor. The results of this analysis are depicted in Figure 4, which displays vendors with the highest number of exploit modules (over 10).


Figure 4: Vendors with 10 exploit modules or more

Figure 4 does not necessarily indicate which vendors are the most targeted, but which products have received the most attention from exploit writers. Several factors could contribute to this, including the availability of software to experiment with, general ease of writing an exploit on particular vulnerabilities, or how the vulnerability matches against the expertise of the exploit writers.

Some of the vendors included in the graph have been acquired by other companies, however we tracked them separately as the vulnerability was identified prior to the acquisition. One example of this is Schneider Electric, which acquired 7-Technologies in 2011 and altered the names of their product portfolio. We also highlight that the graph solely counts exploit modules, regardless of the vulnerability exploited. Modules from separate frameworks could target the same vulnerability and would each be counted separately.

ICS Cyber Operation Tools and Software Exploitation Frameworks Bridge Knowledge and Expertise Gaps

ICS-specific cyber operation tools often released by researchers and security practitioners are useful assets to help organizations learn about ongoing threats and product vulnerabilities. However, as anything publicly available, they can also lower the bar for threat actors that hold an interest in targeting OT networks. Although successful attacks against OT environments will normally require a high level of skills and expertise from threat actors, the tools and exploit modules discussed in this post are making it easier to bridge the knowledge gap.

Awareness about the proliferation of ICS cyber operation tools should serve as an important risk indicator of the evolving threat landscape. These tools provide defenders with an opportunity to perform risk assessments in test environments and to leverage aggregated data to communicate and obtain support from company executives. Organizations that do not pay attention to available ICS cyber operation tools risk becoming low-hanging fruit for both sophisticated and unexperienced threat actors exploring new capabilities.

FireEye Intelligence customers have access to the full list and analysis of ICS cyber operation tools and exploit modules. Visit our website to learn more about the FireEye Mandiant Cyber Physical Threat Intelligence subscription.

Ransomware Against the Machine: How Adversaries are Learning to Disrupt Industrial Production by Targeting IT and OT

Since at least 2017, there has been a significant increase in public disclosures of ransomware incidents impacting industrial production and critical infrastructure organizations. Well-known ransomware families like WannaCry, LockerGoga, MegaCortex, Ryuk, Maze, and now SNAKEHOSE (a.k.a. Snake / Ekans), have cost victims across a variety of industry verticals many millions of dollars in ransom and collateral costs. These incidents have also resulted in significant disruptions and delays to the physical processes that enable organizations to produce and deliver goods and services.

While lots of information has been shared about the victims and immediate impacts of industrial sector ransomware distribution operations, the public discourse continues to miss the big picture. As financial crime actors have evolved their tactics from opportunistic to post-compromise ransomware deployment, we have observed an increase in adversaries’ internal reconnaissance that enables them to target systems that are vital to support the chain of production. As a result, ransomware infections—either affecting critical assets in corporate networks or reaching computers in OT networks—often result in the same outcome: insufficient or late supply of end products or services.

Truly understanding the unique nuances of industrial sector ransomware distribution operations requires a combination of skillsets and visibility across both IT and OT systems. Using examples derived from our consulting engagements and threat research, we will explain how the shift to post-compromise ransomware operations is fueling adversaries’ ability to disrupt industrial operations.

Industrial Sector Ransomware Distribution Poses Increasing Risk as Actors Move to Post-Compromise Deployment

The traditional approach to ransomware attacks predominantly relies on a “shotgun” methodology that consists of indiscriminate campaigns spreading malware to encrypt files and data from a variety of victims. Actors following this model will extort victims for an average of $500 to $1,000 USD and hope to receive payments from as many individuals as possible. While early ransomware campaigns adopting this approach were often considered out of scope for OT security, recent campaigns targeting entire industrial and critical infrastructure organizations have moved toward adopting a more operationally complex post-compromise approach.

In post-compromise ransomware incidents, a threat actor may still often rely on broadly distributed malware to obtain their initial access to a victim environment, but once on a network they will focus on gaining privileged access so they can explore the target networks and identify critical systems before deploying the ransomware. This approach also makes it possible for the attacker to disable security processes that would normally be enough to detect known ransomware indicators or behaviors. Actors cast wider nets that may impact critical systems, which  expand the scale and effectiveness of their end-stage operations by inflicting maximum pain on the victim. As a result, they are better positioned to negotiate and can often demand much higher ransoms—which are commonly commensurate with the victims’ perceived ability to pay and the value of the ransomed assets themselves. For more information, including technical detail, on similar activity, see our recent blog posts on FIN6 and TEMP.MixMaster.


Figure 1: Comparison of indiscriminate vs. post-compromise ransomware approaches

Historical incidents involving the opportunistic deployment of ransomware have often been limited to impacting individual computers, which occasionally included OT intermediary systems that were either internet-accessible, poorly segmented, or exposed to infected portable media. In 2017, we also observed campaigns such as NotPetya and BadRabbit, where wiper malware with worm-like capabilities were released to disrupt organizations while masquerading as ransomware. While these types of campaigns pose a threat to industrial production, the adoption of post-compromise deployment presents three major twists in the plot.

  • As threat actors tailor their attacks to target specific industries or organizations, companies with high-availability requirements (e.g., public utilities, hospitals, and industrial manufacturing) and perceived abilities to pay ransoms (e.g., higher revenue companies) become prime targets. This represents an expansion of financial crime actors’ targeting of industries that process directly marketable information (e.g., credit card numbers or customer data) to include the monetization of production environments.
  • As threat actors perform internal reconnaissance and move laterally across target networks before deploying ransomware, they are now better positioned to cast wide nets that impact the target’s most critical assets and negotiate from a privileged position.
  • Most importantly, many of the tactics, techniques, and procedures (TTPs) often used by financial actors in the past, resemble those employed by high-skilled actors across the initial and middle stages of the attack lifecycle of past OT security incidents. Therefore, financial crime actors are likely capable of pivoting to and deploying ransomware in OT intermediary systems to further disrupt operations.

Organized Financial Crime Actors Have Demonstrated an Ability to Disrupt OT Assets

An actor’s capability to obtain financial benefits from post-compromise ransomware deployment depends on many factors, one of which is the ability to disrupt systems that are the most relevant to the core mission of the victim organizations. As a result, we can expect mature actors to gradually broaden their selection from only IT and business processes, to also OT assets monitoring and controlling physical processes. This is apparent in ransomware families such as SNAKEHOSE, which was designed to execute its payload only after stopping a series of processes that included some industrial software from vendors such as General Electric and Honeywell. At first glance, the SNAKEHOSE kill list appeared to be specifically tailored to OT environments due to the relatively small number of processes (yet high number of OT-related processes) identified with automated tools for initial triage. However, after manually extracting the list from the function that was terminating the processes, we determined that the kill list utilized by SNAKEHOSE actually targets over 1,000 processes.

In fact, we have observed very similar process kill lists deployed alongside samples from other ransomware families, including LockerGoga, MegaCortex, and Maze. Not surprisingly, all of these code families have been associated with high-profile incidents impacting industrial organizations for the past two years. The earliest kill list containing OT processes we identified was a batch script deployed alongside LockerGoga in January 2019. The list is very similar to those used later in MegaCortex incidents, albeit with notable exceptions, such as an apparent typo on an OT-related process that is not present in our SNAKEHOSE or MegaCortex samples: “proficyclient.exe4”. The absence of this typo in the SNAKEHOSE and MegaCortex samples could indicate that one of these malware authors identified and corrected the error when initially copying the OT-processes from the LockerGoga list, or that the LockerGoga author failed to properly incorporate the processes from some theoretical common source of origin, such as a dark web post.


Figure 2: ‘proficyclient.exe’ spelling in kill lists deployed with LockerGoga (left) and SNAKEHOSE (right)

Regardless of which ransomware family first employed the OT-related processes in a kill list or where the malware authors acquired the list, the seeming ubiquity of this list across malware families suggests that the list itself is more noteworthy than any individual malware family that has implemented it. While the OT processes identified in these lists may simply represent the coincidental output of automated process collection from target environments and not a targeted effort to impact OT, the existence of this list provides financial crime actors opportunities to disrupt OT systems. Furthermore, we expect that as financially motivated threat actors continue to impact industrial sector organizations, become more familiar with OT, and identify dependencies across IT and OT systems, they will develop capabilities—and potentially intent—to disrupt other systems and environments running industrial software products and technology.

Ransomware Deployments in Both IT and OT Systems Have Impacted Industrial Production

As a result of adversaries’ post-compromise strategy and increased awareness of industrial sector targets, ransomware incidents have effectively impacted industrial production regardless of whether the malware was deployed in IT or OT. Ransomware incidents encrypting data from servers and computers in corporate networks have resulted in direct or indirect disruptions to physical production processes overseen by OT networks. This has caused insufficient or late supply of end products or services, representing long-term financial losses in the form of missed business opportunities, costs for incident response, regulatory fines, reputational damage, and sometimes even paid ransoms. In certain sectors, such as utilities and public services, high availability is also critical to societal well-being.

The best-known example of ransomware impacting industrial production due to an IT network infection is Norsk Hydro’s incident from March 2019, where disruptions to Business Process Management Systems (BPMS) forced multiple sites to shut down automation operations. Among other collateral damage, the ransomware interrupted communication between IT systems that are commonly used to manage resources across the production chain. Interruptions to these flows of information containing for example product inventories, forced employees to identify manual alternatives to handle more than 6,500 stock-keeping units and 4,000 shelves. FireEye Mandiant has responded to at least one similar case where TrickBot was used to deploy Ryuk ransomware at an oil rig manufacturer. While the infection happened only on corporate networks, the biggest business impact was caused by disruptions of Oracle ERP software driving the company temporarily offline and negatively affecting production.

Ransomware may result in similar outcomes when it reaches IT-based assets in OT networks, for example human-machine interfaces (HMIs), supervisory control and data acquisition (SCADA) software, and engineering workstations. Most of this equipment relies on commodity software and standard operating systems that are vulnerable to a variety of IT threats. Mandiant Intelligence is aware of at least one incident in which an industrial facility suffered a plant shutdown due to a large-scale ransomware attack, based on sensitive sources. The facility's network was improperly segmented, which allowed the malware to propagate from the corporate network into the OT network, where it encrypted servers, HMIs, workstations, and backups. The facility had to reach out to multiple vendors to retrieve backups, many of which were decades old, which delayed complete restoration of production.

As recently as February 2020, the Cybersecurity Infrastructure and Security Agency (CISA) released Alert AA20-049A describing how a post-compromise ransomware incident had affected control and communication assets on the OT network of a natural gas compression facility. Impacts to HMIs, data historians, and polling servers resulted in loss of availability and loss of view for human operators. This prompted an intentional shut down of operations that lasted two days.

Mitigating the Effects of Ransomware Requires Defenses Across IT and OT

Threat actors deploying ransomware have made rapid advances both in terms of effectiveness and as a criminal business model, imposing high operational costs on victims. We encourage all organizations to evaluate their safety and industrial risks related to ransomware attacks. Note that these recommendations will also help to build resilience in the face of other threats to business operations (e.g., cryptomining malware infections). While every case will differ, we highlight the following recommendations.

For custom services and actionable intelligence in both IT and OT, contact FireEye Mandiant Consulting, Managed Defense, and Threat Intelligence.

  • Conduct tabletop and/or controlled red team exercises to assess the current security posture and ability of your organization to respond to the ransomware threat. Simulate attack scenarios (mainly in non-production environments) to understand how the incident response team can (or cannot) detect, analyze, and recover from such an attack. Revisit recovery requirements based on the exercise results. In general, repeatedly practicing various threat scenarios will improve awareness and ability to respond to real incidents.
  • Review operations, business processes, and workflows to identify assets that are critical to maintaining continuous industrial operations. Whenever possible, introduce redundancy for critical assets with low tolerance to downtime. The right amount and type of redundancy is unique for each organization and can be determined through risk assessments and cost-benefit analyses. Note that such analyses cannot be conducted without involving business process owners and collaborating across IT and OT.
  • Logically segregate primary and redundant assets either by a network-based or host-based firewall with subsequent asset hardening (e.g., disabling services typically used by ransomware for its propagation, like SMB, RDP, and WMI). In addition to creating policies to disable unnecessary peer-to-peer and remote connections, we recommend routine auditing of all systems that potentially host these services and protocols. Note that such architecture is generally more resilient to security incidents.
  • When establishing a rigorous back-up program, special attention should be paid to ensuring the security (integrity) of backups. Critical backups must be kept offline or, at minimum, on a segregated network.
  • Optimize recovery plans in terms of recovery time objective. Introduce required alternative workflows (including manual) for the duration of recovery. This is especially critical for organizations with limited or no redundancy of critical assets. When recovering from backups, harden recovered assets and the entire organization's infrastructure to prevent recurring ransomware infection and propagation.
  • Establish clear ownership and management of OT perimeter protection devices to ensure emergency, enterprise-wide changes are possible. Effective network segmentation must be maintained during containment and active intrusions.
  • Hunt for adversary intrusion activity in intermediary systems, which we define as the networked workstations and servers using standard operating systems and protocols. While the systems are further away from direct control of physical processes, there is a much higher likelihood of attacker presence.
  • Note, that every organization is different, with unique internal architectures and processes, stakeholder needs, and customer expectations. Therefore, all recommendations should be carefully considered in the context of the individual infrastructures. For instance, proper network segmentation is highly advisable for mitigating the spread of ransomware. However, organizations with limited budgets may instead decide to leverage redundant asset diversification, host-based firewalls, and hardening as an alternative to segregating with hardware firewalls.

What About the Plant Floor? Six Subversive Concerns for ICS Environments

Industrial enterprises such as electric utilities, petroleum companies, and manufacturing organizations invest heavily in industrial control systems (ICS) to efficiently, reliably, and safely operate industrial processes. Without this technology operating the plant floor, these businesses cannot exist.

Board members, executives, and security officers are often unaware that the technology operating the economic engine of their enterprise invites undetected subversion.  

In this paper, FireEye iSIGHT Intelligence prepares risk executives and security practitioners to knowledgeably discuss six core weaknesses an adversary can use to undermine a plant's operation:

  • Unauthenticated protocols
  • Outdated hardware
  • Weak user authentication
  • Weak file integrity checks
  • Vulnerable Windows operating systems
  • Undocumented third-party relationships

Download the report to learn more. To discuss these six subversive vulnerabilities threatening today’s industrial environments, register for our live webinar scheduled for Tuesday, April 25 at 11:00am ET/8:00am PT. Explore the implications and how to address them firsthand with our ICS intelligence experts.

Overload: Critical Lessons from 15 Years of ICS Vulnerabilities

In the past several years, a flood of vulnerabilities has hit industrial control systems (ICS) – the technological backbone of electric grids, water supplies, and production lines. These vulnerabilities affect the reliable operation of sensors, programmable controllers, software and networking equipment used to automate and monitor the physical processes that keep our modern world running.

FireEye iSIGHT Intelligence has identified nearly 1,600 publicly disclosed ICS vulnerabilities since 2000. We go more in depth on these issues in our latest report, Overload: Critical Lessons from 15 Years of ICS Vulnerabilities, which highlights trends in total ICS vulnerability disclosures, patch availability, vulnerable device type and vulnerabilities exploited in the wild.

FireEye’s acquisition of iSIGHT provided tremendous visibility into the depth and breadth of vulnerabilities in the ICS landscape and how threat actors try to exploit them. To make matters worse, many of these vulnerabilities are left unpatched and some are simply unpatchable due to outdated technology, thus increasing the attack surface for potential adversaries. In fact, nation-state cyber threat actors have exploited five of these vulnerabilities in attacks since 2009.

Unfortunately, security personnel from manufacturing, energy, water and other industries are often unaware of their own control system assets, not to mention the vulnerabilities that affect them. As a result, organizations operating these systems are missing the warnings and leaving their industrial environments exposed to potential threats.

Click here to download the report and learn more.

IRONGATE ICS Malware: Nothing to See Here…Masking Malicious Activity on SCADA Systems

In the latter half of 2015, the FireEye Labs Advanced Reverse Engineering (FLARE) team identified several versions of an ICS-focused malware crafted to manipulate a specific industrial process running within a simulated Siemens control system environment. We named this family of malware IRONGATE.

FLARE found the samples on VirusTotal while researching droppers compiled with PyInstaller — an approach used by numerous malicious actors. The IRONGATE samples stood out based on their references to SCADA and associated functionality. Two samples of the malware payload were uploaded by different sources in 2014, but none of the antivirus vendors featured on VirusTotal flagged them as malicious.

Siemens Product Computer Emergency Readiness Team (ProductCERT) confirmed that IRONGATE is not viable against operational Siemens control systems and determined that IRONGATE does not exploit any vulnerabilities in Siemens products. We are unable to associate IRONGATE with any campaigns or threat actors. We acknowledge that IRONGATE could be a test case, proof of concept, or research activity for ICS attack techniques.

Our analysis finds that IRONGATE invokes ICS attack concepts first seen in Stuxnet, but in a simulation environment. Because the body of industrial control systems (ICS) and supervisory control and data acquisition (SCADA) malware is limited, we are sharing details with the broader community.

Malicious Concepts

Deceptive Man-in-the-Middle

IRONGATE's key feature is a man-in-the-middle (MitM) attack against process input-output (IO) and process operator software within industrial process simulation. The malware replaces a Dynamic Link Library (DLL) with a malicious DLL, which then acts as a broker between a PLC and the legitimate monitoring software. This malicious DLL records five seconds of 'normal' traffic from a PLC to the user interface and replays it, while sending different data back to the PLC. This could allow an attacker to alter a controlled process unbeknownst to process operators.

Sandbox Evasion

IRONGATE's second notable feature involves sandbox evasion. Some droppers for the IRONGATE malware would not run if VMware or Cuckoo Sandbox environments were employed. The malware uses these techniques to avoid detection and resist analysis, and developing these anti-sandbox techniques indicates that the author wanted the code to resist casual analysis attempts. It also implies that IRONGATE’s purpose was malicious, as opposed to a tool written for other legitimate purposes.

Dropper Observables

We first identified IRONGATE when investigating droppers compiled with PyInstaller — an approach used by numerous malicious actors. In addition, strings found in the dropper include the word “payload”, which is commonly associated with malware.

Unique Features for ICS Malware

While IRONGATE malware does not compare to Stuxnet in terms of complexity, ability to propagate, or geopolitical implications, IRONGATE leverages some of the same features and techniques Stuxtnet used to attack centrifuge rotor speeds at the Natanz uranium enrichment facility; it also demonstrates new features for ICS malware.

  • Both pieces of malware look for a single, highly specific process.
  • Both replace DLLs to achieve process manipulation.
  • IRONGATE detects malware detonation/observation environments, whereas Stuxnet looked for the presence of antivirus software.
  • IRONGATE actively records and plays back process data to hide manipulations, whereas Stuxnet did not attempt to hide its process manipulation, but suspended normal operation of the S7-315 so even if rotor speed had been displayed on the HMI, the data would have been static.

A Proof of Concept

IRONGATE’s characteristics lead us to conclude that it is a test, proof of concept, or research activity.

  • The code is specifically crafted to look for a user-created DLL communicating with the Siemens PLCSIM environment. PLCSIM is used to test PLC program functionality prior to in-field deployment. The DLLs that IRONGATE seeks and replaces are not part of the Siemens standard product set, but communicate with the S7ProSim COM object. Malware authors test concepts using commercial simulation software.
  • Code in the malicious software closely matched usage on a control engineering blog dealing with PLCSIM (https://alexsentcha.wordpress.com/using-s7-prosim-with-siemens-s7-plcsim/ and https://pcplcdemos.googlecode.com/hg/S7PROSIM/BioGas/S7%20v5.5/).
  • While we have identified and analyzed several droppers for the IRONGATE malware, we have yet to identify the code’s infection vector.
  • In addition, our analysis did not identify what triggers the MitM payload to install; the scada.exe binary that deploys the IRONGATE DLL payload appears to require manual execution.
  • We have not identified any other instances of the ICS-specific IRONGATE components (scada.exe and Step7ProSim.dll), despite their having been compiled in September of 2014.
  • Siemens ProductCERT has confirmed that the code would not work against a standard Siemens control system environment.

Implications for ICS Asset Owners

Even though process operators face no increased risk from the currently identified members of the IRONGATE malware family, IRONGATE provides valuable insight into adversary mindset.

Network security monitoring, indicator of compromise (IoC) matching, and good practice guidance from vendors and other stakeholders represent important defensive techniques for ICS networks.

To specifically counter IRONGATE’s process attack techniques, ICS asset owners may, over the longer term, implement solutions that:

  • Require integrity checks and code signing for vendor and user generated code. Lacking cryptographic verification facilitates file replacement and MitM attacks against controlled industrial processes.
  • Develop mechanisms for sanity checking IO data, such as independent sensing and backhaul, and comparison with expected process state information. Ignorance of expected process state facilitates an attacker’s ability to achieve physical consequence without alarming operators.

Technical Malware Analysis

IRONGATE Dropper Family

FireEye has identified six IRONGATE droppers: bla.exe, update.exe1, update_no_pipe.exe1, update_no_pipe.exe2, update_no_pipe.exe2, update.exe3. All but one of these Python-based droppers first checks for execution in a VMware or Cuckoo Sandbox environment. If found, the malware exits.

If not found, the IRONGATE dropper extracts a UPX-packed, publicly available utility (NirSoft NetResView version 1.27) to audiodg.exe in the same directory as the dropper. The dropper then executes the utility using the command audiodg.exe /scomma scxrt2.ini. This command populates the file scxrt2.ini with a comma-separated list of network resources identified by the host system.

The dropper iterates through each entry in scxrt2.ini, looking for paths named move-to-operational or move-to-operational.lnk. If a path is found, the dropper first extracts the Base64-encoded .NET executable scada.exe to the current directory and then moves the file to the path containing move-to-operational or move-to-operational.lnk. The path move-to-operational is interesting as well, perhaps implying that IRONGATE was not seeking the actual running process, but rather a staging area for code promotion. The dropper does not execute the scada.exe payload after moving it.

Anti-Analysis Techniques

Each IRONGATE dropper currently identified deploys the same .NET payload, scada.exe. All but one of the droppers incorporated anti-detection/analysis techniques to identify execution in VMware or the Cuckoo Sandbox. If such environments are detected, the dropper will not deploy the .NET executable (scada.exe) to the host.

Four of the droppers (update.exe1, update_no_pipe.exe1, update_no_pipe.exe2, and update.exe3) detect Cuckoo environments by scanning subdirectories of the %SystemDrive%. Directories with names greater than five, but fewer than ten characters are inspected for the subdirectories drop, files, logs, memory, and shots. If a matching directory is found, the dropper does not attempt to deploy the scada.exe payload.

The update.exe1 and update.exe3 droppers contain code for an additional Cuckoo check using the SysInternals pipelist program, install.exe, but the code is disabled in each.

The update.exe2 dropper includes a check for VMware instead of Cuckoo. The VMWare check looks for the registry key HKLM\SOFTWARE\VMware, Inc.\VMware Tools and the files %WINDIR%\system32\drivers\vmmouse.sys and %WINDIR%\system32\drivers\vmhgfs.sys. If any of these are found, the dropper does not attempt to deploy the scada.exe payload.

The dropper bla.exe does not include an environment check for either Cuckoo or VMware.

scada.exe Payload

We surmise that scada.exe is a user-created payload used for testing the malware. First, our analysis did not indicate what triggers scada.exe to run. Second, Siemens ProductCERT informed us that scada.exe is not a default file name associated with Siemens industrial control software.

When scada.exe executes, it scans drives attached to the system for filenames ending in Step7ProSim.dll. According to the Siemens ProductCERT, Step7ProSim.dll is not part of the Siemens PLCSIM software. We were unable to determine whether this DLL was created specifically by the malware author, or if it was from another source, such as example code or a particular custom ICS implementation. We surmise this DLL simulates generation of IO values, which would normally be provided by an S7-based controller, since the functions it includes appear derived from the Siemens PLCSIM environment.

If scada.exe finds a matching DLL file name, it kills all running processes with the name biogas.exe. The malware then moves Step7ProSim.dll to Step7ConMgr.dll and drops a malicious Step7ProSim.dll – the IRONGATE payload – to the same directory.

The malicious Step7ProSim.dll acts as an API proxy between the original user-created Step7ProSim.dll (now named Step7ConMgr.dll) and the application biogas.exe that loads it. Five seconds after loading, the malicious Step7ProSim.dll records five seconds of calls to ReadDataBlockValue. All future calls to ReadDataBlockValue return the recorded data.

Simultaneously, the malicious DLL discards all calls to WriteDataBlockValue and instead calls WriteInputPoint(0x110, 0, 0x7763) and WriteInputPoint(0x114, 0, 0x7763) every millisecond. All of these functions are named similarly to Siemens S7ProSim v5.4 COM interface. It appears that other calls to API functions are passed through the malicious DLL to the legitimate DLL with no other modification.

Biogas.exe

As mentioned previously, IRONGATE seeks to manipulate code similar to that found on a blog dealing with simulating PLC communications using PLCSIM, including the use of an executable named biogas.exe.

Examination of the executable from that blog’s demo code shows that the WriteInputPoint function calls with byte indices 0x110 and 0x114 set pressure and temperature values, respectively:

IRONGATE:

         WriteInputPoint(0x110, 0, 0x7763)
WriteInputPoint(0x114, 0, 0x7763)

 Equivalent pseudo code from Biogas.exe: 

        S7ProSim.WriteInputPoint(0x110, 0, (short)this.Pressure.Value)
     S7ProSim.WriteInputPoint(0x114, 0, (short)this.Temperature.Value)

We have been unable to determine the significance of the hardcoded value 0x7763, which is passed in both instances of the write function.

Because of the noted indications that IRONGATE is a proof of concept, we cannot conclude IRONGATE’s author intends to manipulate specific temperature or pressure values associated with the specific biogas.exe process, but find the similarities to this example code striking.

Artifacts and Indicators

PyInstaller Artifacts

The IRONGATE droppers are Python scripts converted to executables using PyInstaller. The compiled droppers contain PyInstaller artifacts from the system the executables were created on. These artifacts may link other samples compiled on the same system. Five of the six file droppers (bla.exe, update.exe1, update_no_pipe.exe1, update_no_pipe.exe2 and update.exe3) all share the same PyInstaller artifacts listed in Table 1.

Table 1: Pyinstaller Artifacts

The remaining dropper, update.exe2, contains the artifacts listed in Table 2.

Table 2: Pyinstaller Artifacts for update.exe2

Unique Strings

Figure 1 and 2 list the unique strings discovered in the scada.exe and Step7ProSim.dll binaries.

Figure 1: Scada.exe Unique Strings

Figure 2: Step7ProSim.dll Unique Strings

File Hashes

Table 3 contains the MD5 hashes, file and architecture type, and compile times for the malware analyzed in this report.

Table 3: File MD5 Hashes and Compile Times

FireEye detects IRONGATE. A list of indicators can be found here.

Special thanks to the Siemens ProductCERT for providing support and context to this investigation.

Havex, It’s Down With OPC

FireEye recently analyzed the capabilities of a variant of Havex (referred to by FireEye as “Fertger” or “PEACEPIPE”), the first publicized malware reported to actively scan OPC servers used for controlling SCADA (Supervisory Control and Data Acquisition) devices in critical infrastructure (e.g., water and electric utilities), energy, and manufacturing sectors.

While Havex itself is a somewhat simple PHP Remote Access Trojan (RAT) that has been analyzed by other sources, none of these have covered the scanning functionality that could impact SCADA devices and other industrial control systems (ICS). Specifically, this Havex variant targets servers involved in OPC (Object linking and embedding for Process Control) communication, a client/server technology widely used in process control systems (for example, to control water pumps, turbines, tanks, etc.).

Note: ICS is a general term that encompasses SCADA (Supervisory Control and Data Acquisition) systems, DCS (Distributed Control Systems), and other control system environments. The term SCADA is well-known to wider audiences, and throughout this article, ICS and SCADA will be used interchangeably.

Threat actors have leveraged Havex in attacks across the energy sector for over a year, but the full extent of industries and ICS systems affected by Havex is unknown. We decided to examine the OPC scanning component of Havex more closely, to better understand what happens when it’s executed and the possible implications.

OPC Testing Environment

To conduct a true test of the Havex variant’s functionality, we constructed an OPC server test environment that fully replicates a typical OPC server setup (Figure 1 [3]). As shown, ICS or SCADA systems involve OPC client software that interacts directly with an OPC server, which works in tandem with the PLC (Programmable Logic Controller) to control industrial hardware (such as a water pump, turbine, or tank). FireEye replicated both the hardware and software the OPC server setup (the components that appear within the dashed line on the right side of Figure 1).

 

 

havex1

Figure 1: Topology of typical OPC server setup

The components of our test environment are robust and comprehensive to the point that our system could be deployed in an environment to control actual SCADA devices. We utilized an Arduino Uno [1] as the primary hardware platform, acting as the OPC server. The Arduino Uno is an ideal platform for developing an ICS test environment because of the low power requirements, a large number of libraries to make programming the microcontroller easier, serial communication over USB, and cheap cost. We leveraged the OPC Server and libraries from St4makers [2] (as shown in Figure 2). This software is available for free to SCADA engineers to allow them to develop software to communicate information to and from SCADA devices.

havex2

Figure 2: OPC Server Setup

Using the OPC Server libraries allowed us to make the Arduino Uno act as a true, functioning OPC SCADA device (Figure 3).

havex3

Figure 3: Matrikon OPC Explorer showing Arduino OPC Server

We also used Matrikon’s OPC Explorer [1], which enables browsing between the Arduino OPC server and the Matrikon embedded simulation OPC server. In addition, the Explorer can be used to add certain data points to the SCADA device – in this case, the Arduino device.

havex4

Figure 4: Tags identified for OPC server

In the OPC testing environment, we created tags in order to simulate a true OPC server functioning. Tags, in relation to ICS devices, are single data points. For example: temperature, vibration, or fill level. Tags represent a single value monitored or controlled by the system at a single point in time.

With our test environment complete, we executed the malicious Havex “.dll" file and analyzed how Havex’s OPC scanning module might affect OPC servers it comes in contact with.

Analysis

The particular Havex sample we looked at was a file named PE.dll (6bfc42f7cb1364ef0bfd749776ac6d38). When looking into the scanning functionality of the particular Havex sample, it directly scans for OPC servers, both on the server the sample was submitted on, and laterally, across the entire network.

The scanning process starts when the Havex downloader calls the runDll export function.  The OPC scanner module identifies potential OPC servers by using the Windows networking (WNet) functions.  Through recursive calls to WNetOpenEnum and WNetEnumResources, the scanner builds a list of all servers that are globally accessible through Windows networking.  The list of servers is then checked to determine if any of them host an interface to the Component Object Models (COM) listed below:

 

 

 

Screen Shot 2014-07-17 at 12.31.56 PM

 

 

Figure 5: Relevant COM objects

Once OPC servers are identified, the following CLSIDs are used to determine the capabilities of the OPC server:

Screen Shot 2014-07-17 at 12.33.22 PM

            Figure 6: CLSIDs used to determine capabilities of the OPC server

When executing PE.dll, all of the OPC server data output is first saved as %TEMP%\[random].tmp.dat. The results of a capability scan of an OPC server is stored in %TEMP%\OPCServer[random].txt. Files are not encrypted or deleted once the scanning process is complete.

Once the scanning completes, the log is deleted and the contents are encrypted and stored into a file named %TEMP%\[random].tmp.yls.  The encryption process uses an RSA public key obtained from the PE resource TYU.  The RSA key is used to protect a randomly generated 168-bit 3DES key that is used to encrypt the contents of the log.

The TYU resource is BZip2 compressed and XORed with the string “1312312”.  A decoded configuration for 6BFC42F7CB1364EF0BFD749776AC6D38 is included in the figure below:

Screen Shot 2014-07-17 at 12.27.24 PM

Figure 7: Sample decoded TYU resource

The 4409de445240923e05c5fa6fb4204 value is believed to be an RSA key identifier. The AASp1… value is the Base64 encoded RSA key.

A sample encrypted log file (%TEMP%\[random].tmp.yls) is below.

 

 

 

 

 

 

 

 

 

 

 

 

 

00000000  32 39 0a 66 00 66 00 30  00 30 00 66 00 66 00 30 29.f.f.0.0.f.f.000000010  00 30 00 66 00 66 00 30  00 30 00 66 00 66 00 30 .0.f.f.0.0.f.f.000000020  00 30 00 66 00 66 00 30  00 30 00 66 00 66 00 30 .0.f.f.0.0.f.f.000000030  00 30 00 66 00 66 00 30  00 30 00 66 00 37 39 36 .0.f.f.0.0.f.79600000040  0a 31 32 38 0a 96 26 cc  34 93 a5 4a 09 09 17 d3 .128..&.4..J....00000050  e0 bb 15 90 e8 5d cb 01  c0 33 c1 a4 41 72 5f a5 .....]...3..Ar_.00000060  13 43 69 62 cf a3 80 e3  6f ce 2f 95 d1 38 0f f2 .Cib....o./..8..00000070  56 b1 f9 5e 1d e1 43 92  61 f8 60 1d 06 04 ad f9 V..^..C.a.`.....00000080  66 98 1f eb e9 4c d3 cb  ee 4a 39 75 31 54 b8 02 f....L...J9u1T..00000090  b5 b6 4a 3c e3 77 26 6d  93 b9 66 45 4a 44 f7 a2 ..J<.w&m..fEJD..000000A0  08 6a 22 89 b7 d3 72 d4  1f 8d b6 80 2b d2 99 5d .j"...r.....+..]000000B0  61 87 c1 0c 47 27 6a 61  fc c5 ee 41 a5 ae 89 c3 a...G'ja...A....000000C0  9e 00 54 b9 46 b8 88 72  94 a3 95 c8 8e 5d fe 23 ..T.F..r.....].#000000D0  2d fb 48 85 d5 31 c7 65  f1 c4 47 75 6f 77 03 6b -.H..1.e..Guow.k

 

--Truncated--Probable Key Identifierff00ff00ff00ff00ff00ff00ff00fRSA Encrypted 3DES Key5A EB 13 80 FE A6 B9 A9 8A 0F 41…The 3DES key will be the last 24 bytes of the decrypted result.3DES IV88 72  94 a3 95 c8 8e 5d3DES Encrypted Logfe 23 2d fb 48 85 d5 31 c7 65 f1…

Figure 8: Sample encrypted .yls file

Execution

When executing PE.dll against the Arduino OPC server, we observe interesting responses within the plaintext %TEMP%\[random].tmp.dat:

 

 

Screen Shot 2014-07-17 at 12.41.27 PM

 

 

Figure 9: Sample scan log

The contents of the tmp.dat file are the results of the scan of the network devices, looking for OPC servers. These are not the in-depth results of the OPC servers themselves, and only perform the initial scanning.

The particular Havex sample in question also enumerates OPC tags and fully interrogates the OPC servers identified within %TEMP%\[random].tmp.dat. The particular fields queried are: server state, tag name, type, access, and id. The contents of a sample %TEMP%\OPCServer[random].txt can be found below:

 

 

Screen Shot 2014-07-17 at 12.43.48 PM

 

 

Figure 10: Contents of OPCServer[Random].txt OPC interrogation

While we don’t have a particular case study to prove the attacker’s next steps, it is likely after these files are created and saved, they will be exfiltrated to a command and control server for further processing.

Conclusion

Part of threat intelligence requires understanding all parts of a particular threat. This is why we took a closer look at the OPC functionality of this particular Havex variant.  We don’t have any case study showcasing why the OPC modules were included, and this is the first “in the wild” sample using OPC scanning. It is possible that these attackers could have used this malware as a testing ground for future utilization, however.

Since ICS networks typically don’t have a high-level of visibility into the environment, there are several ways to help minimize some of the risks associated with a threat like Havex. First, ICS environments need to have the ability to perform full packet capture ability. This gives incident responders and engineers better visibility should an incident occur.

Also, having mature incident processes for your ICS environment is important. Being able to have security engineers that also understand ICS environments during an incident is paramount. Finally, having trained professionals consistently perform security checks on ICS environments is helpful. This ensures standard sets of security protocols and best practices are followed within a highly secure environment.

We hope that this information will further educate industrial control systems owners and the security community about how the OPC functionality of this threat works and serves as the foundation for more investigation. Still, lots of questions remain about this component of Havex. What is the attack path? Who is behind it? What is their intention? We’re continuing to track this specific threat and will provide further updates as this new tactic unfolds.

Acknowledgements

We would like to thank Josh Homan for his help and support.

Related MD5s

ba8da708b8784afd36c44bb5f1f436bc

6bfc42f7cb1364ef0bfd749776ac6d38

4102f370aaf46629575daffbd5a0b3c9

References