Category Archives: Malware Analysis

Analyzing Dark Crystal RAT, a C# backdoor

The FireEye Mandiant Threat Intelligence Team helps protect our customers by tracking cyber attackers and the malware they use. The FLARE Team helps augment our threat intelligence by reverse engineering malware samples. Recently, FLARE worked on a new C# variant of Dark Crystal RAT (DCRat) that the threat intel team passed to us. We reviewed open source intelligence and prior work, performed sandbox testing, and reverse engineered the Dark Crystal RAT to review its capabilities and communication protocol. Through publishing this blog post we aim to help defenders look for indicators of compromise and other telltale signs of Dark Crystal RAT, and to assist fellow malware researchers new to .NET malware, or who encounter future variants of this sample.

Discovering Dark Crystal RAT

The threat intel team provided FLARE with an EXE sample, believed to contain Dark Crystal RAT, and having the MD5 hash b478d340a787b85e086cc951d0696cb1. Using sandbox testing, we found that this sample produced two executables, and in turn, one of those two executables produced three more. Figure 1 shows the relationships between the malicious executables discovered via sandbox testing.

Figure 1: The first sample we began analyzing ultimately produced five executables.

Armed with the sandbox results, our next step was to perform a triage analysis on each executable. We found that the original sample and mnb.exe were droppers, that dal.exe was a clean-up utility to delete the dropped files, and that daaca.exe and fsdffc.exe were variants of Plurox, a family with existing reporting. Then we moved to analyzing the final dropped sample, which was dfsds.exe. We found brief public reporting by @James_inthe_box on the same sample, identifying it as DCRat and as a RAT and credential stealer. We also found a public sandbox run that included the same sample. Other public reporting described DCRat, but actually analyzed the daaca.exe Plurox component bundled along with DCRat in the initial sample.

Satisfied that dfsds.exe was a RAT lacking detailed public reporting, we decided to perform a deeper analysis.

Analyzing Dark Crystal RAT

Initial Analysis

Shifting aside from our sandbox for a moment, we performed static analysis on dfsds.exe. We chose to begin static analysis using CFF Explorer, a good tool for opening a PE file and breaking down its sections into a form that is easy to view. Having viewed dfsds.exe in CFF Explorer, as shown in Figure 2, the utility showed us that it is a .NET executable. This meant we could take a much different path to analyzing it than we would on a native C or C++ sample. Techniques we might have otherwise used to start narrowing down a native sample’s functionality, such as looking at what DLLs it imports and what functions from those DLLs that it uses, yielded no useful results for this .NET sample. As shown in Figure 3, dfsds.exe imports only the function _CorExeMain from mscoree.dll. We could have opened dfsds.exe in IDA Pro, but IDA Pro is usually not the most effective way of analyzing .NET samples; in fact, the free version of IDA Pro cannot handle .NET Common Language Infrastructure (CLI) intermediate code.

Figure 2: CFF Explorer shows that dfsds.exe is a .NET executable.

Figure 3: The import table for dfsds.exe is not useful as it contains only one function.

Instead of using a disassembler like IDA Pro on dfsds.exe, we used a .NET decompiler. Luckily for the reverse engineer, decompilers operate at a higher level and often produce a close approximation of the original C# code. dnSpy is a great .NET decompiler. dnSpy’s interface displays a hierarchy of the sample’s namespaces and classes in the Assembly Explorer and shows code for the selected class on the right. Upon opening dfsds.exe, dnSpy told us that the sample’s original name at link time was DCRatBuild.exe, and that its entry point is at <PrivateImplementationDetails>{63E52738-38EE-4EC2-999E-1DC99F74E08C}.Main, shown in Figure 4. When we browsed to the Main method using the Assembly Explorer, we found C#-like code representing that method in Figure 5. Wherever dnSpy displays a call to another method in the code, it is possible to click on the target method name to go to it and view its code. By right-clicking on an identifier in the code, and clicking Analyze in the context menu, we caused dnSpy to look for all occurrences where the identifier is used, similar to using cross-references in IDA Pro.

Figure 4: dnSpy can help us locate the sample's entry point

Figure 5: dnSpy decompiles the Main method into C#-like code

We went to the SchemaServerManager.Main method that is called from the entry point method, and observed that it makes many calls to ExporterServerManager.InstantiateIndexer with different integer arguments, as shown in Figure 6. We browsed to the ExporterServerManager.InstantiateIndexer method, and found that it is structured as a giant switch statement with many goto statements and labels; Figure 7 shows an excerpt. This does not look like typical dnSpy output, as dnSpy often reconstructs a close approximation of the original C# code, albeit with the loss of comments and local variable names. This code structure, combined with the fact that the code refers to the CipherMode.CBC constant, led us to believe that ExporterServerManager.InstantiateIndexer may be a decryption or deobfuscation routine. Therefore, dfsds.exe is likely obfuscated. Luckily, .NET developers often use obfuscation tools that are somewhat reversible through automated means.

Figure 6: SchemaServerManager.Main makes many calls to ExporterServerManager.InstantiateIndexer

Figure 7: ExporterServerManager.InstantiateIndexer looks like it may be a deobfuscation routine


De4dot is a .NET deobfuscator that knows how to undo many types of obfuscations. Running de4dot -d (for detect) on dfsds.exe (Figure 8) informed us that .NET Reactor was used to obfuscate it.

> de4dot -d dfsds.exe

de4dot v3.1.41592.3405 Copyright (C) 2011-2015
Latest version and source code:

Detected .NET Reactor (C:\...\dfsds.exe)

Figure 8: dfsds.exe is obfuscated with .NET Reactor

After confirming that de4dot can deobfuscate dfsds.exe, we ran it again to deobfuscate the sample into the file dfsds_deob.exe (Figure 9).

> de4dot -f dfsds.exe -o dfsds_deob.exe

de4dot v3.1.41592.3405 Copyright (C) 2011-2015
Latest version and source code:

Detected .NET Reactor (C:\Users\user\Desktop\intelfirst\dfsds.exe)
Cleaning C:\Users\user\Desktop\intelfirst\dfsds.exe
Renaming all obfuscated symbols
Saving C:\Users\user\Desktop\intelfirst\dfsds_deob.exe

Figure 9: de4dot successfully deobfuscates dfsds.exe

After deobfuscating dfsds.exe, we ran dnSpy again on the resulting dfsds_deob.exe. When we decompiled SchemaServerManager.Main again, the results were much different, as shown in Figure 10. Contrasting the new output with the obfuscated version shown previously in Figure 6, we found the deobfuscated code much more readable. In the deobfuscated version, all the calls to ExporterServerManager.InstantiateIndexer were removed; as suspected, it was apparently a string decoding routine. In contrast, the class names shown in the Assembly Explorer did not change; the obfuscator must have irrecoverably replaced the original class names with meaningless ones obtained from a standard list. Next, we noted that ten lines in Figure 10 hold base64-encoded data. Once the sample was successfully deobfuscated, it was time to move on to extracting its configuration and to follow the sample’s code path to its persistence capabilities and initial beacon.

Figure 10: Deobfuscating dfsds.exe shows that the method begins with some path manipulation and then accesses Base64-encoded data

Configuration, Persistence and Initial Beacon

Recall that in Figure 10 we found that the method SchemaServerManager.Main has a local variable containing Base64-encoded data; decoding that data revealed what it contains. Figure 11 shows the decoded configuration (with C2 endpoint URLs de-fanged):

> echo TUhvc3Q6aHR0cDovL2RvbWFsby5vbmxpbmUva3NlemJseGx2b3Uza2NtYnE4bDdoZjNmNGN5NXhnZW
VXRYeEo5bjl5ZixUQUc6VU5ERUY= | base64 -d


Figure 11: Decoding the base64 data in SchemaServerManager.Main reveals a configuration string

Figure 11 shows that the data decoded to a configuration string containing four values: MHost, BHost, MX, and TAG. We analyzed the code that parses this string and found that MHost and BHost were used as its main and backup command and control (C2) endpoints. Observe that the MHost and BHost values in Figure 11 are identical, so this sample did not have a backup C2 endpoint.

In dnSpy it is possible to give classes and methods meaningful names just as it is possible to name identifiers in IDA Pro. For example, the method SchemaServerManager.StopCustomer picks the name of a random running process. By right-clicking the StopCustomer identifier and choosing Edit Method, it is possible to change the method name to PickRandomProcessName, as shown in Figure 12.

Figure 12: Assigning meaningful names to methods makes it easier to keep analyzing the program

Continuing to analyze the SchemaServerManager.Main method revealed that the sample persists across reboots. The persistence algorithm can be summarized as follows:

  1. The malware picks the name of a random running process, and then copies itself to %APPDATA% and C:\. For example, if svchost.exe is selected, then the malware copies itself to %APPDATA%\svchost.exe and C:\svchost.exe.
  2. The malware creates a shortcut %APPDATA%\dotNET.lnk pointing to the copy of the malware under %APPDATA%.
  3. The malware creates a shortcut named dotNET.lnk in the logged-on user’s Startup folder pointing to %APPDATA%\dotNET.lnk.
  4. The malware creates a shortcut C:\Sysdll32.lnk pointing to the copy of the malware under C:\.
  5. The malware creates a shortcut named Sysdll32.lnk in the logged-on user’s Startup folder pointing to C:\Sysdll32.lnk.
  6. The malware creates the registry value HKCU\Software\Microsoft\Windows\CurrentVersion\Run\scrss pointing to %APPDATA%\dotNET.lnk.
  7. The malware creates the registry value HKCU\Software\Microsoft\Windows\CurrentVersion\Run\Wininit pointing to C:\Sysdll32.lnk.

After its persistence steps, the malware checks for multiple instances of the malware:

  1. The malware sleeps for a random interval between 5 and 7 seconds.
  2. The malware takes the MD5 hash of the still-base64-encoded configuration string, and creates the mutex whose name is the hexadecimal representation of that hash. For this sample, the malware creates the mutex bc2dc004028c4f0303f5e49984983352. If this fails because another instance is running, the malware exits.

The malware then beacons, which also allows it to determine whether to use the main host (MHost) or backup host (BHost). To do so, the malware constructs a beacon URL based on the MHost URL, makes a request to the beacon URL, and then checks to see if the server responds with the HTTP response body “ok.” If the server does not send this response, then the malware unconditionally uses the BHost; this code is shown in Figure 13. Note that since this sample has the same MHost and BHost value (from Figure 11), the malware uses the same C2 endpoint regardless of whether the check succeeds or fails.

Figure 13: The malware makes an HTTP request based on the MHost URL to determine whether to use the MHost or BHost

The full algorithm to obtain the beacon URL is as follows:

  1. Obtain the MHost URL, i.e., hxxp://domalo[.]online/ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91dueu3qa54
  2. Calculate the SHA1 hash of the full MHost URL, i.e., 56743785cf97084d3a49a8bf0956f2c744a4a3e0.
  3. Remove the last path component from the MHost URL, and then append the SHA1 hash from above, and ?data=active. The full beacon URL is therefore hxxp://domalo[.]online/ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91dueu3qa54

After beaconing the malware proceeds to send and receive messages with the configured C2.

Messages and Capabilities

After performing static analysis of dfsds.exe to determine how it selects the C2 endpoint and confirming the C2 endpoint URL, we shifted to dynamic analysis in order to collect sample C2 traffic and make it easier to understand the code that generates and accepts C2 messages. Luckily for our analysis, the malware continues to generate requests to the C2 endpoint even if the server does not send a valid response. To listen for and intercept requests to the C2 endpoint (domalo[.]online) without allowing the malware Internet access, we used FLARE’s FakeNet-NG tool. Figure 14 shows some of the C2 requests that the malware made being captured by FakeNet-NG.

Figure 14: FakeNet-NG can capture the malware's HTTP requests to the C2 endpoint

By comparing the messages generated by the malware and captured in FakeNet-NG with the malware’s decompiled code, we determined its message format and types. Observe that the last HTTP request visible in Figure 14 contains a list of running processes. By tracing through the decompiled code, we found that the method SchemaServerManager.ObserverWatcher.NewMerchant generated this message. We renamed this method to taskThread and assigned meaningful names to the other methods it calls; the resulting code for this method appears in Figure 15.

Figure 15: The method that generates the list of running processes and sends it to the C2 endpoint

By analyzing the code further, we identified the components of the URLs that the malware used to send data to the C2 endpoint, and how they are constructed.


The first type of URL is a beacon, sent only once when the malware starts up. For this sample, the beacon URL was always hxxp://domalo[.]online/ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91dueu3qa54/46kqbjvyklunp1z56txzk
hen7gjci3cyx8ggkptx25i74mo6myqpx9klvv3/<hash>.php?data=active, where <hash> is the SHA1 hash of the MHost URL, as described earlier.

GET requests, format 1

When the malware needs to send data to or receive data from the C2, it sends a message. The first type of message, which we denote as “format 1,” is a GET request to URLs of the form hxxp://domalo[.]online/ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91dueu3qa54/46kqb
3b34w/<hash>.php? type=__ds_setdata&__ds_setdata_user=<user_hash>&__ds_setdata_ext=<message_hash>&__ds_setdata_data=<message>
, where:

  • <hash> is MD5(SHA1(MHost)), which for this sample, is 212bad81b4208a2b412dfca05f1d9fa7.
  • <user_hash> is a unique identifier for the machine on which the malware is running. It is always calculated as SHA1(OS_version + machine_name + user_name) as provided by the .NET System.Environment class.
  • <message_hash> identifies what kind of message the malware is sending to the C2 endpoint. The <message_hash> is calculated as MD5(<message_type> + <user_hash>), where <message_type> is a short keyword identifying the type of message, and <user_hash> is as calculated above.
    • Values for <message_type> exist for each command that the malware supports; for possible values, see the “msgs” variable in the code sample shown in Figure 19.
    • Observe that this makes it difficult to observe the message type visually from log traffic, or to write a static network signature for the message type, since it varies for every machine due to the inclusion of the <user_hash>.
    • One type of message uses the value u instead of a hash for <message_hash>.
  • <message> is the message data, which is not obscured in any way.

The other type of ordinary message is a getdata message. These are GET requests to URLs of the form hxxp://domalo[.]online/ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91dueu3qa54/46kqb
3b34w/<hash>.php? type=__ds_getdata&__ds_getdata_user=<user_hash>&__ds_getdata_ext=<message_hash>&__ds_getdata_key=<key>
, where:

  • <hash> and <user_hash> are calculated as described above for getdata messages.
  • <message_hash> is also calculated as described above for getdata messages, but describes the type of message the malware is expecting to receive in the server’s response.
  • <key> is MD5(<user_hash>).

The server is expected to respond to a getdata message with an appropriate response for the type of message specified by <message_hash>.

GET requests, format 2

A few types of messages from the malware to the C2 use a different format, which we denote as “format 2.” These messages are GET requests of the form hxxp://domalo[.]online /ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91dueu3qa54/46kqbjvyklunp1z56txzkhen7gj
, where:

  • <user_hash> is calculated as described above for getdata messages.
  • <message_hash> is also calculated as described above for getdata messages, but describes the type of message the malware is expecting to receive in the server’s response. <message_hash> may also be the string comm.

Table 1 shows possible <message_types> that may be incorporated into <message_hash> as part of format 2 messages to instruct the server which type of response is desired. In contrast to format 1 messages, format 2 messages are only used for a handful of <message_type> values.


Response desired


The server sends a non-empty response if a screenshot request is pending


The server sends a non-empty response if a microphone request is pending


The server responds directly with keystrokes to replay


The server responds directly with other types of tasking

Table 1: Message types when the malware uses a special message to request tasking from the server

POST requests

When the malware needs to upload large files, it makes a POST request. These POST requests are sent to hxxp://domalo[.]online/ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91dueu3qa54/46kqb
, with the following parameters in the POST data:

  • name is <user_hash> + "." + <message_type>, where <user_hash> is calculated as described above and <message_type> is the type of data being uploaded.
  • upload is a file with the data being sent to the server.

Table 2 shows possible <message_type> values along with the type of file being uploaded.


Type of File




Cookie stealer log


Microphone recording


Uploaded file


Webcam image


Remote control screenshot

Table 2: Message types when files are uploaded to the server


By analyzing the code that handles the responses to the comm message (format 2), it was possible for us to inventory the malware’s capabilities. Table 3 shows the keywords used in responses along with the description of each capability.




Execute a shell command


Recursively delete all files from C:, D:, F:, and G:


Close the CD-ROM drive door


Change the background wallpaper


Send TCP and UDP packets to a given host or IP address


Log off the current user


Replay keystrokes as if the user had typed them


Create a new folder


Rename or move a file


Hide desktop icons


Start logging keystrokes


Compile and execute C# code


Open a Windows MessageBox


Transfer a file from the C2 to the client


Re-spawn the malware running as an administrator


Build a ZIP file from a directory tree and transfer it from the client to the C2


Take a webcam picture


Unzip a ZIP file to a given path on the client


Stop logging keystrokes


Enumerate drive letters


Transfer cookies and browser/FileZilla saved credentials to the C2


Recursively delete a given directory


Hide desktop icons and taskbar


Transfer a file from the C2 to the client


Start a process


Rotate screen


Run shell command and send standard output back to C2


Show taskbar


Set clipboard contents


Save cookies and credentials to a local file


Create a new local user account


Beep for set frequency and duration


Use speech synthesizer to speak text


Open chat window


Hide the taskbar


Start remote control over user’s desktop


Close chat window


Stop remote control over user’s desktop


List directory contents


Remove the malware from the client


Kill a process


Endlessly spawn instances of cmd.exe


Transfer a file from the client to the C2


Show desktop icons


Transfer clipboard contents to C2


Play a sound file


Open the CD-ROM drive door


Shut down the machine


Restart the machine


Open a web URL in the default browser

Table 3: Capabilities of DCRat

Proof-of-Concept Dark Crystal RAT Server

After gathering information from Dark Crystal RAT about its capabilities and C2 message format, another way to illustrate the capabilities and test our understanding of the messages was to write a proof-of-concept server. Here is a code snippet that we wrote containing a barebones DCRat server written in Python. Unlike a real RAT server, this one does not have a user interface to allow the attacker to pick and launch commands. Instead, it has a pre-scripted command list that it sends to the RAT.

When the server starts up, it uses the Python BaseHTTPServer to begin listening for incoming web requests (lines 166-174). Incoming POST requests are assumed to hold a file that the RAT is uploading to the server; this server assumes all file uploads are screenshots and saves them to “screen.png” (lines 140-155). For GET requests, the server must distinguish between beacons, ordinary messages, and special messages (lines 123-138). For ordinary messages, __ds_setdata messages are simply printed to standard output, while the only __ds_getdata message type supported is s_comm (screenshot communications), to which the server responds with the desired screenshot dimensions (lines 63-84). For messages of type comm, the server sends four types of commands in sequence: first, it hides the desktop icons; then, it causes the string “Hello this is tech support” to be spoken; next, it displays a message box asking for a password; finally, it launches the Windows Calculator (lines 86-121).

Figure 16 shows the results when Dark Crystal RAT is run on a system that has been configured to redirect all traffic to domalo[.]online to the proof-of-concept server we wrote.

Figure 16: The results when a Dark Crystal RAT instance communicates with the proof-of-concept server

Other Work and Reconnaissance

After reverse engineering Dark Crystal RAT, we continued reconnaissance to see what additional information we could find. One limitation to our analysis was that we did not wish to allow the sample to communicate with the real C2, so we kept it isolated from the Internet. To learn more about Dark Crystal RAT we tried two approaches: the first was to browse the Dark Crystal RAT website (files.dcrat[.]ru) using Tor, and the other was to take a look at YouTube videos of others’ experiments with the “real” Dark Crystal RAT server.

Dark Crystal RAT Website

We found that Dark Crystal RAT has a website at files.dcrat[.]ru, shown in Figure 17. Observe that there are options to download the RAT itself, as well as a few plugins; the DCLIB extension is consistent with the plugin loading code we found in the RAT.

Figure 17: The website files.dcrat[.]ru allows users to download Dark Crystal RAT and some of its plugins

Figure 18 shows some additional plugins, including plugins with the ability to resist running in a virtual machine, disable Windows Defender, and disable webcam lights on certain models. No plugins were bundled with the sample we studied.

Figure 18: Additional plugins listed on the Dark Crystal RAT website

Figure 19 lists software downloads on the RAT page. We took some time to look at these files; here are some interesting things we discovered:

  • The DCRat listed on the website is actually a “builder” that packages a build of the RAT and a configuration for the attacker to deploy. This is consistent with the name DCRatBuild.exe shown back in Figure 4. In our brief testing of the builder, we found that it had a licensing check. We did not pursue bypassing it once we found public YouTube videos of the DCRat builder in operation, as we show later.
  • The DarkCrystalServer is not self-contained, rather, it is just a PHP file that allows the user to supply a username and password, which causes it to download and install the server software. Due to the need to supply credentials and communicate back with dcrat[.]ru (Figure 20), we did not pursue further analysis of DarkCrystalServer.

Figure 19: The RAT page lists software for the RAT, the server, an API, and plugin development

Figure 20: The DarkCrystalServer asks for a username and password and calls back to dcrat[.]ru to download software, so we did not pursue it further

YouTube Videos

As part of confirming our findings about Dark Crystal RAT capabilities that we obtained through reverse engineering, we found some YouTube demonstrations of the DCRat builder and server.

The YouTube user LIKAR has a YouTube demonstration of Dark Crystal RAT. The author demonstrates use of the Dark Crystal RAT software on a server with two active RAT instances. During the video, the author browses through the various screens in the software. This made it easy to envision how a cyber threat would use the RAT, and to confirm our suspicions of how it works.

Figure 21 shows a capture from the video at 3:27. Note that the Dark Crystal RAT builder software refers to the DCRatBuild package as a “server” rather than a client. Nonetheless, observe that one of the options was a type of Java, or C# (Beta). By watching this YouTube video and doing some additional background research, we discovered that Dark Crystal RAT has existed for some time in a Java version. The C# version is relatively new. This explained why we could not find much detailed prior reporting about it.

Figure 21: A YouTube demonstration revealed that Dark Crystal RAT previously existed in a Java version, and the C# version we analyzed is in beta

Figure 22 shows another capture from the video at 6:28. The functionality displayed on the screen lines up nicely with the “msgbox”, “browseurl”, “clipboard”, “speak”, “opencd”, “closecd”, and other capabilities we discovered and enumerated in Table 6.

Figure 22: A YouTube demonstration confirmed many of the Dark Crystal RAT capabilities we found in reverse engineering


In this post we walked through our analysis of the sample that the threat intel team provided to us and all its components. Through our initial triage, we found that its “dfsds.exe” component is Dark Crystal RAT. We found that Dark Crystal RAT was a .NET executable, and reverse engineered it. We extracted the malware’s configuration, and through dynamic analysis discovered the syntax of its C2 communications. We implemented a small proof-of-concept server to test the correct format of commands that can be sent to the malware, and how to interpret its uploaded screenshots. Finally, we took a second look at how actual threat actors would download and use Dark Crystal RAT.

To conclude, indicators of compromise for this version of Dark Crystal RAT (MD5: 047af34af65efd5c6ee38eb7ad100a01) are given in Table 4.

Indicators of Compromise

Dark Crystal RAT (dfsds.exe)

Handle artifacts


Mutex name


Registry artifacts


Registry value


Registry value


File system artifacts







Start Menu\Programs\Startup\Sysdll32.lnk


Start Menu\Programs\Startup\dotNET.lnk


%APPDATA%\<random process name>.exe


C:\<random process name>.exe

Network artifacts


HTTP request


HTTP request

a7.php? type=__ds_getdata&__ds_getdata_user=<user_hash>&__ds_getdata_ex

HTTP request

hxxp://domalo[.]online /ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91dueu3qa54/46kqbjvyklunp

TCP connection


TCP connection


DNS lookup


DNS lookup




Static string


Table 4: IoCs for this instance of DCRat

FireEye Product Support for Dark Crystal RAT

Table 5 describes how FireEye products react to the initial sample (MD5: b478d340a787b85e086cc951d0696cb1) and its Dark Crystal RAT payload, or in the case of Mandiant Security Validation, allow a stakeholder to validate their own capability to detect Dark Crystal RAT.

FireEye Product

Support for Dark Crystal RAT

FireEye Network Security (NX)

Backdoor.Plurox detection

FireEye Email Security (EX & ETP)

Backdoor.MSIL.DarkCrystal, Backdoor.Plurox, Malware.Binary.exe, Trojan.Vasal.FEC3, Win.Ransomware.Cerber-6267996-1, fe_ml_heuristic detections

FireEye Endpoint Security (HX)

Trojan.GenericKD.32546165, Backdoor.MSIL.DarkCrystal detections

FireEye Malware Analysis (AX)

Backdoor.Plurox.FEC2 detection

FireEye Detection on Demand (DoD)

Backdoor.Plurox.FEC2, FireEye.Malware detections

Mandiant Security Validation

Built-in Action coming soon

Table 5: Support in FireEye products to detect Dark Crystal RAT or validate detection capability

Thinking Outside the Bochs: Code Grafting to Unpack Malware in Emulation

This blog post continues the FLARE script series with a discussion of patching IDA Pro database files (IDBs) to interactively emulate code. While the fastest way to analyze or unpack malware is often to run it, malware won’t always successfully execute in a VM. I use IDA Pro’s Bochs integration in IDB mode to sidestep tedious debugging scenarios and get quick results. Bochs emulates the opcodes directly from your IDB in a Bochs VM with no OS.

Bochs IDB mode eliminates distractions like switching VMs, debugger setup, neutralizing anti-analysis measures, and navigating the program counter to the logic of interest. Alas, where there is no OS, there can be no loader or dynamic imports. Execution is constrained to opcodes found in the IDB. This precludes emulating routines that call imported string functions or memory allocators. Tom Bennett’s flare-emu ships with emulated versions of these, but for off-the-cuff analysis (especially when I don’t know if there will be a payoff), I prefer interactively examining registers and memory to adjust my tactics ad hoc.

What if I could bring my own imported functions to Bochs like flare-emu does? I’ve devised such a technique, and I call it code grafting. In this post I’ll discuss the particulars of statically linking stand-ins for common functions into an IDB to get more mileage out of Bochs. I’ll demonstrate using this on an EVILNEST sample to unpack and dump next-stage payloads from emulated memory. I’ll also show how I copied a tricky call sequence from one IDB to another IDB so I could keep the unpacking process all in a single Bochs debug session.


My sample (MD5 hash 37F7F1F691D42DCAD6AE740E6D9CAB63 which is available on VirusTotal) was an EVILNEST variant that populates the stack with configuration data before calling an intermediate payload. Figure 1 shows this unusual call site.

Figure 1: Call site for intermediate payload

The code in Figure 1 executes in a remote thread within a hollowed-out iexplore.exe process; the malware uses anti-analysis tactics as well. I had the intermediate payload stage and wanted to unpack next-stage payloads without managing a multi-process debugging scenario with anti-analysis. I knew I could stub out a few function calls in the malware to run all of the relevant logic in Bochs. Here’s how I did it.

Code Carving

I needed opcodes for a few common functions to inject into my IDBs and emulate in Bochs. I built simple C implementations of selected functions and compiled them into one binary. Figure 2 shows some of these stand-ins.

Figure 2: Simple implementations of common functions

I compiled this and then used IDAPython code similar to Figure 3 to extract the function opcode bytes.

Figure 3: Function extraction

I curated a library of function opcodes in an IDAPython script as shown in Figure 4. The nonstandard function opcodes at the bottom of the figure were hand-assembled as tersely as possible to generically return specific values and manipulate the stack (or not) in conformance with calling conventions.

Figure 4: Extracted function opcodes

On top of simple functions like memcpy, I implemented a memory allocator. The allocator referenced global state data, meaning I couldn’t just inject it into an IDB and expect it to work. I read the disassembly to find references to global operands and templatize them for use with Python’s format method. Figure 5 shows an example for malloc.

Figure 5: HeapAlloc template code

I organized the stubs by name as shown in Figure 6 both to call out functions I would need to patch, and to conveniently add more function stubs as I encounter use cases for them. The mangled name I specified as an alias for free is operator delete.

Figure 6: Function stubs and associated names

To inject these functions into the binary, I wrote code to find the next available segment of a given size. I avoided occupying low memory because Bochs places its loader segment below 0x10000. Adjacent to the code in my code  segment, I included space for the data used by my memory allocator. Figure 7 shows the result of patching these functions and data into the IDB and naming each location (stub functions are prefixed with stub_).

Figure 7: Data and code injected into IDB

The script then iterates all the relevant calls in the binary and patches them with calls to their stub implementations in the newly added segment. As shown in Figure 8, IDAPython’s Assemble function saved the effort of calculating the offset for the call operand manually. Note that the Assemble function worked well here, but for bigger tasks, Hex-Rays recommends a dedicated assembler such as Keystone Engine and its Keypatch plugin for IDA Pro.

Figure 8: Abbreviated routine for assembling a call instruction and patching a call site to an import

The Code Grafting script updated all the relevant call sites to resemble Figure 9, with the target functions being replaced by calls to the stub_ implementations injected earlier. This prevented Bochs in IDB mode from getting derailed when hitting these call sites, because the call operands now pointed to valid code inside the IDB.

Figure 9: Patched operator new() call site

Dealing with EVILNEST

The debug scenario for the dropper was slightly inconvenient, and simultaneously, it was setting up a very unusual call site for the payload entry point. I used Bochs to execute the dropper until it placed the configuration data on the stack, and then I used IDAPython’s idc.get_bytes function to extract the resulting stack data. I wrote IDAPython script code to iterate the stack data and assemble push instructions into the payload IDB leading up to a call instruction pointing to the DLL’s export. This allowed me to debug the unpacking process from Bochs within a single session.

I clicked on the beginning of my synthesized call site and hit F4 to run it in Bochs. I was greeted with the warning in Figure 10 indicating that the patched IDB would not match the depictions made by the debugger (which is untrue in the case of Bochs IDB mode). Bochs faithfully executed my injected opcodes producing exactly the desired result.

Figure 10: Patch warning

I watched carefully as the instruction pointer approached and passed the IsDebuggerPresent check. Because of the stub I injected (stub_IsDebuggerPresent), it passed the check returning zero as shown in Figure 11.

Figure 11: Passing up IsDebuggerPresent

I allowed the program counter to advance to address 0x1A1538, just beyond the unpacking routine. Figure 12 shows the register state at this point which reflects a value in EAX that was handed out by my fake heap allocator and which I was about to visit.

Figure 12: Running to the end of the unpacker and preparing to view the result

Figure 13 shows that there was indeed an IMAGE_DOS_SIGNATURE (“MZ”) at this location. I used idc.get_bytes() to dump the unpacked binary from the fake heap location and saved it for analysis.

Figure 13: Dumping the unpacked binary

Through Bochs IDB mode, I was also able to use the interactive debugger interface of IDA Pro to experiment with manipulating execution and traversing a different branch to unpack another payload for this malware as well.


Although dynamic analysis is sometimes the fastest road, setting it up and navigating minutia detract from my focus, so I’ve developed an eye for routines that I can likely emulate in Bochs to dodge those distractions while still getting answers. Injecting code into an IDB broadens the set of functions that I can do this with, letting me get more out of Bochs. This in turn lets me do more on-the-fly experimentation, one-off string decodes, or validation of hypotheses before attacking something at scale. It also allows me to experiment dynamically with samples that won’t load correctly anyway, such as unpacked code with damaged or incorrect PE headers.

I’ve shared the Code Grafting tools as part of the flare-ida GitHub repository. To use this for your own analyses:

  1. In IDA Pro’s IDAPython prompt, run or import it as a module.
  2. Instantiate a CodeGrafter object and invoke its graftCodeToIdb() method:
    • CodeGrafter().graftCodeToIdb()
  3. Use Bochs in IDB mode to conveniently execute your modified sample and experiment away!

This post makes it clear just how far I’ll go to avoid breaking eye contact with IDA. If you’re a fan of using Bochs with IDA too, then this is my gift to you. Enjoy!

FakeNet Genie: Improving Dynamic Malware Analysis with Cheat Codes for FakeNet-NG

As developers of the network simulation tool FakeNet-NG, reverse engineers on the FireEye FLARE team, and malware analysis instructors, we get to see how different analysts use FakeNet-NG and the challenges they face. We have learned that FakeNet-NG provides many useful features and solutions of which our users are often unaware. In this blog post, we will showcase some cheat codes to level up your network analysis with FakeNet-NG. We will introduce custom responses and demonstrate powerful features such as executing commands on connection events and decrypting SSL traffic.

Since its first release in 2016, we have improved FakeNet-NG by adding new features such as Linux support and content-based protocol detection. We recently updated FakeNet-NG with one of our most requested features: custom responses for HTTP and binary protocols.

This blog post offers seven "stages" to help you master different FakeNet-NG strategies. We present them in terms of common scenarios we encounter when analyzing malware. Feel free to skip to the section relevant to your current analysis and/or adapt them to your individual needs. The stages are presented as follows:

  1. Custom File Responses
  2. Custom Binary Protocols
  3. Custom HTTP Responses
  4. Manual Custom Responses
  5. Blacklisting Processes
  6. Executing Commands on Connection Events
  7. Decrypting SSL Traffic

Read on to upgrade your skill tree and become a FakeNet-NG pro!

Before You Start: Configuring FakeNet-NG

Here is a quick reference for FakeNet-NG configurations and log data locations.

  1. Configuration files are in fakenet\configs. You can modify default.ini or copy it to a new file and point FakeNet-NG to the alternate configuration with -c. Ex: -c custom.ini.
  2. Default files are at fakenet\defaultFiles and Listener implementations are at fakenet\listeners.
  3. The fakenet\configs\default.ini default configuration includes global configuration settings and individual Listener configurations.
  4. Custom response configuration samples are included in the directory fakenet\configs in the files, sample_custom_response.ini, and sample_raw_response.txt.
  5. The install location for FakeNet-NG in FLARE VM is C:\Python27\lib\site-packages\fakenet. You will find the subdirectories containing the defaultFiles, configs, and listeners in this directory.
  6. In FLARE VM, FakeNet-NG packet capture files and HTTP requests can be found on the Desktop in the fakenet_logs directory

Stage 1: Custom File Responses

As you may have noticed, FakeNet-NG is not limited to serving HTML pages. Depending on the file type requested, FakeNet-NG can serve PE files, ELF files, JPG, GIF, etc. FakeNet-NG is configured with several default files for common types and can also be configured to serve up custom files. The defaultFiles directory contains several types of files for standard responses. For example, if malware sends an FTP GET request for evil.exe, FakeNet-NG will respond with the file defaultFiles\FakeNetMini.exe (the default response for .exe requests). This file is a valid Portable Executable file that displays a message box. By providing an actual PE file, we can observe the malware as it attempts to download and execute a malicious payload. An example FTP session and subsequent execution of the downloaded default file is shown in Figure 1.

Figure 1: Using FTP to download FakeNet-NG's default executable response

Most requests are adequately handled by this system. However, malware sometimes expects a file with a specific format, such as an image with an embedded PowerShell script, or an executable with a hash appended to the file for an integrity check . In cases like these, you can replace one of the default files with a file that meets the malware’s expectation. There is also an option in each of the relevant Listeners (modules that implement network protocols) configurations to modify the defaultFiles path. This allows FakeNet-NG to serve different files without overwriting or modifying default data. A customized FakeNet.html file is shown in Figure 2.

Figure 2: Modify the default FakeNet.html file to customize the response

Stage 2: Custom Binary Protocols

Many malware samples implement custom binary protocols which require specific byte sequences. For example, malware in the GH0ST family may require each message to begin with a signature such as "GH0ST". The default FakeNet-NG RawListener responds to unknown requests with an echo, i.e. it sends the same data that it has received. This behavior is typically sufficient. However, in cases where a custom response is required, you can still send the data the malware expects.

Custom TCP and UDP responses are now possible with FakeNet-NG. Consider a hypothetical malware sample that beacons the string “Hello” to its command and control (C2) server and waits for a response packet that begins with “FLARE” followed by a numeric command (0-9). We will now demonstrate several interesting ways FakeNet-NG can handle this scenario.

Static Custom Response

You can configure how the TCP and/or UDP Raw Listeners respond to traffic. In this example we tell FakeNet-NG how to respond to any TCP raw request (no protocol detected). First uncomment the Custom configuration option in the RawTCPListener section of fakenet/configs/default.ini as illustrated in Figure 3.

Enabled:     True
Port:        1337
Protocol:    TCP
Listener:    RawListener
UseSSL:      No
Timeout:     10
Hidden:      False
# To read about customizing responses, see docs/
Custom:    sample_custom_response.ini

Figure 3: Activate custom TCP response

Next configure the TcpRawFile custom response in fakenet\configs\sample_custom_response.ini as demonstrated in Figure 4. Make sure to comment-out or replace the default RawTCPListener instance.

InstanceName:     RawTCPListener
ListenerType:     TCP
TcpRawFile:       flare_command.txt

Figure 4: TCP static custom response specifications

Create the file fakenet\configs\flare_command.txt with the content FLARE0. TCP responses will now be generated from the contents of the file.

Dynamic Custom Response

Perhaps you want to issue commands dynamically rather than committing to a specific command in flare_command.txt. This can be achieved programmatically. Configure the TcpDynamic custom response in fakenet\configs\sample_custom_response.ini as demonstrated in Figure 5. Make sure to comment-out or replace the existing RawTCPListener instance.

InstanceName:     RawTCPListener

Figure 5: TCP dynamic custom response specifications

The file fakenet\configs\ can be used as a template for our dynamic response file We modify the HandleTcp() function and produce the new file fakenet\configs\ as illustrated in Figure 6. Now you can choose each command as the malware executes. Figure 7 demonstrates issuing commands dynamically using this configuration.

import socket

def HandleTcp(sock):

    while True:
            data = None

            data = sock.recv(1024)
        except socket.timeout:

        if not data:

        resp = raw_input('\nEnter a numeric command: ')
        command = bytes('FLARE' + resp + '\n')

Figure 6: TCP dynamic response script

Figure 7: Issue TCP dynamic commands

Stage 3: Custom HTTP Responses

Malware frequently implements its own encryption scheme on top of the popular HTTP protocol. For example, your sample may send an HTTP GET request to /comm.php?nonce=<random> and expect the C2 server response to be RC4 encrypted with the nonce value. This process is illustrated in Figure 8. How can we easily force the malware to execute its critical code path to observe or debug its behaviors?

Figure 8: Malware example that expects a specific key based on beacon data

For cases like these we recently introduced support for HTTP custom responses. Like TCP custom responses, the HTTPListener also has a new setting named Custom that enables dynamic HTTP responses. This setting also allows FakeNet-NG to select the appropriate responses matching specific hosts or URIs. With this feature, we can now quickly write a small Python script to handle the HTTP traffic dynamically based upon our malware sample.

Start by uncommenting the Custom configuration option in the HTTPListener80 section as illustrated in Figure 9.

Enabled:     True
Port:        80
Protocol:    TCP
Listener:    HTTPListener
UseSSL:      No
Webroot:     defaultFiles/
Timeout:     10
#ProcessBlackList: dmclient.exe, OneDrive.exe, svchost.exe, backgroundTaskHost.exe, GoogleUpdate.exe, chrome.exe
DumpHTTPPosts: Yes
DumpHTTPPostsFilePrefix: http
Hidden:      False
# To read about customizing responses, see docs/
Custom:    sample_custom_response.ini

Figure 9: HTTP Listener configuration

Next configure the HttpDynamic custom response in fakenet\configs\sample_custom_response.ini as demonstrated in Figure 10. Make sure to comment-out or replace the default HttpDynamic instance.

ListenerType:     HTTP
HttpURIs:         comm.php

Figure 10: HttpDynamic configuration

The file fakenet\configs\ can be used as a template for our dynamic response file We modify the HandleRequest() function as illustrated in Figure 11. FakeNet-NG will now encrypt responses dynamically with the nonce.

import socket
from arc4 import ARC4

# To read about customizing HTTP responses, see docs/

def HandleRequest(req, method, post_data=None):
    """Sample dynamic HTTP response handler.

    req : BaseHTTPServer.BaseHTTPRequestHandler
        The BaseHTTPRequestHandler that recevied the request
    method: str
        The HTTP method, either 'HEAD', 'GET', 'POST' as of this writing
    post_data: str
        The HTTP post data received by calling `` against the
        BaseHTTPRequestHandler that received the request.


    response = 'Ahoy\r\n'

    nonce = req.path.split('=')[1]
    arc4 = ARC4(nonce)
    response = arc4.encrypt(response)

    req.send_header('Content-Length', len(response))

Figure 11: Dynamic HTTP request handler

Stage 4: Manual Custom Responses

For even more flexibility, the all-powerful networking utility netcat can be used to stand-in for FakeNet-NG listeners. For example, you may want to use netcat to act as a C2 server and issue commands dynamically during execution on port 80. Launch a netcat listener before starting FakeNet-NG, and traffic destined for the corresponding port will be diverted to the netcat listener. You can then issue commands dynamically using the netcat interface as seen in Figure 12.

Figure 12: Use ncat.exe to manually handle traffic

FakeNet-NG's custom response capabilities are diverse. Read the documentation to learn how to boost your custom response high score.

Stage 5: Blacklisting Processes

Some analysts prefer to debug malware from a separate system. There are many reasons to do this; most commonly to preserve the IDA database and other saved data when malware inevitably corrupts the environment. The process usually involves configuring two virtual machines on a host-only network. In this setup, FakeNet-NG intercepts network traffic between the two machines, which renders remote debugging impossible. To overcome this obstacle, we can blacklist the debug server by instructing FakeNet-NG to ignore traffic from the debug server process.

When debugging remotely with IDA Pro, the standard debug server process for a 32-bit Portable Executable is win32_remote.exe (or dbgsrv.exe for WinDbg). All you need to do is add the process names to the ProcessBlackList configuration as demonstrated in Figure 13. Then, the debug servers can still communicate freely with IDA Pro while all other network traffic is captured and redirected by FakeNet-NG.

# Specify processes to ignore when diverting traffic. Windows example used here.
ProcessBlackList: win32_remote.exe, dbgsrv.exe

Figure 13: Modified configs/default.ini to allow remote debugging with IDA Pro

Blacklisting is also useful to filter out noisy processes from polluting Fakenet-NG captured network traffic. Examples include processes that attempt to update the Windows system or other malware analysis tools.

Additional settings are available for blacklisting ports and hosts. Please see the README for more details about blacklisting and whitelisting.

Stage 6: Executing Commands on Connection Events

Fakenet-NG can be configured to execute commands when a connection is made to a Listener. For example, this option can be used to attach a debugger to a running sample upon a connection attempt. Imagine a scenario where we analyze the packed sample named Lab18-01.exe from the Practical Malware Analysis labs. Using dynamic analysis, we can see that the malware beacons to its C2 server over TCP port 80 using the HTTP protocol as seen in Figure 14.

Figure 14: Malware beacons to its C2 server over TCP port 80

Wouldn’t it be nice if we could magically attach a debugger to Lab18-01.exe when a connection is made? We could speedrun the sample and bypass the entire unpacking stub and any potential anti-debugging tricks the sample may employ.

To configure Fakenet-NG to launch and attach a debugger to any process, modify the [HTTPListener80] section in the fakenet\configs\default.ini to include the ExecuteCmd option. Figure 15 shows an example of a complete [HTTPListener80] section.

Enabled:     True
Port:        80
Protocol:    TCP
Listener:    HTTPListener
UseSSL:      No
Webroot:     defaultFiles/
Timeout:     10
DumpHTTPPosts: Yes
DumpHTTPPostsFilePrefix: http
Hidden:      False
# Execute x32dbg –p to attach to a debugger. {pid} is filled in automatically by Fakenet-NG
ExecuteCmd: x32dbg.exe -p {pid}

Figure 15: Execute command option to run and attach x32dbg

In this example, we configure the HTTPListener on port 80 to execute the debugger x32dbg.exe, which will attach to a running process whose process ID is determined at runtime. When a connection is made to HTTPListener, FakeNet-NG will automatically replace the string {pid} with the process ID of the process that makes the connection. For a complete list of supported variables, please refer to the Documentation.

Upon restarting Fakenet-NG and running the sample again, we see x32dbg launch and automatically attach to Lab18-01.exe. We can now use memory dumping tools such as Scylla or the OllyDumpEx plugin to dump the executable and proceed to static analysis. This is demonstrated in Figure 16 and Figure 17.

Figure 16: Using FakeNet-NG to attach x32dbg to the sample (animated)

Figure 17: Fakenet-NG executes x32dbg upon connection to

Stage 7: Decrypting SSL Traffic

Often malware uses SSL for network communication, which hinders traffic analysis considerably as the packet data is encrypted. Using Fakenet-NG's ProxyListener, you can create a packet capture with decrypted traffic. This can be done using the protocol detection feature.

The proxy can detect SSL, and "man-in-the-middle" the socket in SSL using Python's OpenSSL library. It then maintains full-duplex connections with the malware and with the HTTP Listener, with both sides unaware of the other. Consequently, there is a stream of cleartext HTTP traffic between the Proxy and the HTTP Listener, as seen in Figure 18.

Figure 18: Cleartext streams between Fakenet-NG components

In order to keep FakeNet-NG as simple as possible, current default settings for FakeNet-NG do not have the proxy intercept HTTPS traffic on port 443 and create the decrypted stream. To proxy the data you need to set the HTTPListener443 Hidden attribute to True as demonstrated in Figure 19. This tells the proxy to intercept packets and detect the protocol based on packet contents. Please read our blog post on the proxy and protocol detection to learn more about this advanced feature.

Enabled:     True
Port:        443
Protocol:    TCP
Listener:    HTTPListener
UseSSL:      Yes
Webroot:     defaultFiles/
DumpHTTPPosts: Yes
DumpHTTPPostsFilePrefix: http
Hidden:      True

Figure 19: Hide the listener so the traffic will be proxied

We can now examine the packet capture produced by Fakenet-NG. The cleartext can be found in a TCP stream between an ephemeral port on localhost (ProxyListener) and port 80 on localhost (HTTPListener). This is demonstrated in Figure 20.

Figure 20: Cleartext traffic between HTTPListener and Proxy Listener

Conclusion (New Game+)

Fakenet-NG is the de facto standard network simulation tool for malware analysis. It runs without installation and is included in FLARE VM. In addition to its proven and tested default settings, Fakenet offers countless capabilities and configuration options. In this blog post we have presented several tricks to handle common analysis scenarios. To download the latest version, to see a complete list of all configuration options, or to contribute to Fakenet-NG, please see our Github repository.

Is APT27 Abusing COVID-19 To Attack People ?!


We are living hard time, many countries all around the world are hit by COVID-19 which happened to be a very dangerous disease. Unfortunately many deaths, thousands of infected people, few breathing equipment, stock burned Billion of dollars and a lot of companies are entering into a economic and financial crisis. Governments are doing their best to mitigate such a virus while people are stuck home working remotely using their own equipment.

In that scenario, jackals are luring people using every dirty way to attack their private devices. At home it’s hard to have advanced protection systems as we have in companies. For example it’s hard to have Intrusion Prevention Systems, proxies, advanced threat protection, automated sandbox and again advanced end-point protections letting personal devices more vulnerable to be attacked. In this reality ruthless attackers abuse of this situation to attack digitally unprotected people.

Today many reports are describing how infamous attackers are abusing such an emergency time to lure people by sending thematic email campaign or by using thematic IM within Malware or Phishing links. Following few of them that I believe would be a nice reading:

Today I want to contribute to such a blog-roll analyzing a new spreading variant that hit my observatory. I want to “spoil” the conclusions now, but it’s getting pretty sad if an APT group makes use of its knowledge to take advance from today’s situation.

Stage 1

The first stage is a fake PDF file. It looks like a real PDF, it has a hidden extension and a nice PDF icon, but it really isn’t a PDF, it’s actually a .lnk file, or in other words a “Microsoft Linking File”.

ThreatDropper and Execution
DescriptionFake PDF file used to run initial infection chain

Opening up the .lnk file we might appreciate a weird linking pattern. Two main sections: one is a kind of header where it is possible to observe commands, and the other section is a big encoded payload.

.lnk file

Once beautified the first section it looks easier to understand what it does. It basically copies itself into a temporary folder (through cmd.exe), it extracts bytes from its body (from section two), it decodes such a bytes from Byte64 (through msoia.exe ) and it places the extracted content into the temporary user folder. It deflates the content (through expand) and it finally it executes a javascript file (through wscript) which was included into the compressed content. The following image shows the beautified code section of the analyzed file.

Beautified .lnk file

It is quite nice to see how the attacker copied certutils from local system, by using (*ertu*.exe) in order to avoid command line detection from public sandboxes. Indeed many sandboxes have signatures on certutils, since it’s quite a notorious tool used by some attackers, so that avoiding the behavior signature match it would take a lower score from public sandboxes.

Stage 2

Stage 1 carved Stage 2 from its body by extracting bytes and decoding them using base64 encoding. The new stage is a Microsoft compressed CAB file described in the following table.

ThreatMalware Carrier/Packer/Compressor
DescriptionMicrosoft CAB bringing contents

Extracting files from Microsoft CAB we observe 6 more files entering in the battlefield:

  • 20200308-sitrep-48-covid-19.pdf. The original PDF from WHO explaining the COVID-19 status and how to fight it.
  • 3UDBUTNY7YstRc.tmp. PE32 Executable file (DLL)
  • 486AULMsOPmf6W.tmp. PE32 Executable (GUI)
  • 9sOXN6Ltf0afe7.js. Javascript file (called by .lnk)
  • cSi1r0uywDNvDu.tmp. XSL StyleSheet Document
  • MiZl5xsDRylf0W.tmp. Text file including PE32 file

Stage 1 executes the Javascript included in the CAB file. 9sOXN6Ltf0afe7.js performs an ActiveXObject call to WScript.Shell in order to execute Windows command lists. Once” deobfuscated” and beautified the command line looks like the following (9sOXN6Ltf0afe7.js payload beautified) . The attacker creates a folder that looks like a “file” by calling it cscript.exe trying to cheat the analyst. Then the attacker populates that folder with the needed files to follow the infection chain.

9sOXN6Ltf0afe7.js payload “deobfuscated”

A special thought goes to WINRM.VBS which helped the attacker to execute Signed Script Proxy Execution (T1216). According to Microsoft: “WINRM is the CLI interface to our WS-MGMT protocol. The neat thing about this is that you can call it from PowerShell to manage remote systems that don’t have PowerShell installed on them (including Server Core systems and Raw hardware).” The attacker also places a file called Wordcnvpxy.exe on the OFFICE12 folder. We will analyze it in a few steps but at that stage we might observe that is the “last call” before luring the victim by showing the good PDF file (also included in the CAB). But according with 9sOXN6Ltf0afe7.js the first run is on WsmPty.xsl which is the renamed version of cSi1r0uywDNvDu.tmp.

Stage 3

Stage 3 is run by stage 2 and it is a XSL (StleSheet Office file) wrapping a VBScript object.

ThreatPayload Extractor and Command Executor
DescriptionDecode Additional Stage by using coding charsets and XOR

The following VBScript is run through cscript.exe, It’s an obfuscated and xor-encrypted payload. The encryption is performed by a simple xor having as key the single byte 0 while the encoding procedure is a multi conversion routine which could be summarized as follows:


VBScript Stage3

The attacker tried to confuse the analyst by reusing variable names in private or local contexts, but after a couple of minutes, you might eventually come out with the following decryption loop.

Decryption Loop

If you run it against the embedded payload you will eventually see a new stage: Stage 4. A brand new script targeting old version of MSOffice.

Stage 4

Stage 4 is decoded and run by Stage 3. That stage runs an attacker version of MSOSTYLE.exe copied from Stage 2. It hijacks method on an old office 2007 component (Office Data Provider for – MSOSTYLE.exe).

ThreatPersistence and Execution
DescriptionSet persistence on the target system (Script File)

The following image shows the decrypted and decoded Stage. It’s quite clear the attacker wants to get persistence on the target machine and to run additional payload by abusing MSOSTYLE.exe (old component) placed in the “right folder” from stage 2. The persistence is guaranteed by adding a link called Accessories.lnk inside the startup windows folder pointing to: MiZl5xsDRylf0W.tmp.

Powershell Stage 4

Stage 5

Stage 5 is activated by Stage 2 but only after the execution of Stage 3 and Stage 4. Stage 5 is a multi-step session composed by the following additional artifacts: (i) 3UDBUTNY7YstRc.tmp renamed by Stage 2 into OINFO12.OCX and (ii) MiZl5xsDRylf0W.tmp renamed by Stage 2 into Wordcnvpxy.exe . Every single artifact is available after the execution of Stage 2 into the crafted folder called: OFFICE12 from the user home.

ThreatRemote Control, depending on usage
DescriptionOffice Data Provider for WBEM, not malicious but accountable.

MSOSTYLE.EXE is an old Microsoft Office Data Provider for WBEM. Web-Based Enterprise Management (WBEM) comprises a set of systems-management technologies developed to unify the management of distributed computing environments. So it could not be considered malicious, but it could be considered accountable of the entire infection chain.

ThreatPlugX, Command Execution
DescriptionA runner plus Command Execution, Pluging Manager

At the time of writing only three AVs detect OINFO12.OCX as a malicious file. Rising AV is actually the only company which attributes it to a well-known PlugX sample. According with Trend Micro, the PlugX malware family is well known to researchers having samples dating back to as early as 2008. PlugX is a fully featured Remote Access Tool/Trojan (RAT) with capabilities such as file upload, download, and modification, keystroke logging, webcam control, and access to a remote cmd.exe shell.

OINFO12.OCX VT coverage

Taking it on static analysis it will expose three callable functions: DeleteOfficeData (0x10001020), GetOfficeData (0x10001000) and EntryPoint 0x100015ac).

Both of the methods DeleteOfficeData and GetOfficeData looks like recalling a classic method to hijacking old Office Parser (take a look to here and figure 3 in here ) to execute commands.

DeleteOfficeData (0x10001020)
GetOfficeData (0x10001000)

Indeed if run from its Entry Point, the DLL executes Wordcnvpxy.exe (as it is the default plugin component). The executable DLL must be in the same path of Wordcnvpxy.exe and it needs to have such a filename (imposed by Stage 2 and hardcoded into the library). On the other side of the coin if commands are passed through stdin, it executes the given parameters as commands.

No Input Commands, Wordcnvpxy execution

The following image shows when parameters are given and Commands are executed.

Commands Execution

Finally we have Wordcnvpxy.exe which is run in the same stage (Stage 5) by OINFO12.OCX . At the time of writing, it is well-known from static engines, it looks like a standard backdoor beacon-ing to own command and control installed as PlugX module.

ThreatPlugX, Backdoor
DescriptionProbably one of the last stages, beaconing VS C2 and executing external commands
Wordcnvpxy VT coverage

The sample uses dynamic function loading avoiding static enumeration and guessing. It grabs information on the victim, PC-name, username, IP-location and send them to C2 as a first beacon.

Dynamic Loading function calls

The used Command and Control resolves to the following URL hxxp://motivation[.]neighboring[.]site/01/index.php

Command and Control

Unfortunately the attacker has shut down everything few hours after I started my analysis, so that I do not have more information about network, commands and additional Plugins. However the overall structure reminds me PlugX RAT as nicely described here.


According to MITRE (BTW thank you @Arkbird_SOLG for the great suggestions on attribution) PlugX is a well known RAT attributed to China’s APT. APT27 (aka Emissary Panda) are the mostly notable APT group that used it. Moreover (thanks to @Arkbird_SOLG) “[…] on China culture, hijacking method are a mandatory knowledge for a job like pentesting […]” which could enforce the theory of APT27

UPDATE: I am aware that PlugX is today an opensource RAT, and I am aware that this is not enough for attribution. Indeed the intent of the title is to put doubts on that attribution by the usage of “?” (question mark). On one hand PlugX historically has been attributed to APT27 but on the other hand it’s public. So it’s hard to say Yes or Not, for such a reason the intent of this blog post is: Is APT27 Abusing COVID-19 To Attack People ?!. It’s an Open question not a position.

We all are passing a bad time. COVID-19 caused many death and is threatening entire economies. Please, even if you are an attacker and you gain profit from you infamous job, stop cyber attacks against peoples that are suffering this pandemic and rest. Ethics and compassion should be alive – even behind you monitors.


  • 95489af84596a21b6fcca078ed10746a32e974a84d0daed28cc56e77c38cc5a8 (original .lnk)
  • f74199f59533fbbe57f0b2aae45c837b3ed5e4f5184e74c02e06c12c6535f0f9 (Stage 2)
  • 9d52d8f10673518cb9f19153ddbe362acc7ca885974a217a52d1ee8257f22cfc (Stage 3)
  • 7f230a023a399b39fa1994c3eaa0027d6105769fffaf72918adebf584edc6fe0 (Stage 4)
  • a49133ed68bebb66412d3eb5d2b84ee71c393627906f574a29247d8699f1f38e (Stage 5/a)
  • 002c9e0578a8b76f626e59b755a8aac18b5d048f1cc76e2c12f68bc3dd18b124 (Stage 5/b)
  • hxxp://motivation[.]neighboring[.]site/01/index.php (C2)

Yara (auto)

import "pe"

rule MiZl5xsDRylf0W {
      description = "yara - file MiZl5xsDRylf0W.tmp"
      date = "2020-03-17"
      hash1 = "b578a237587054f351f71bd41bede49197f77a1409176f839ebde105f3aee44c"
      $s1 = "%ls\\%S.exe" fullword wide
      $s2 = "%XFTpX7m5ZvRCkEg" fullword ascii
      $s3 = "SK_Parasite, Version 1.0" fullword wide
      $s6 = "SKPARASITE" fullword wide
      $s7 = "default" fullword ascii /* Goodware String - occured 709 times */
      $s8 = "59xf4qy-YXn-pkuXh=x3CXPHCcs3dXFlCtr3Cc4H4XufdZjmAZe3Ccxuibvm592g" fullword ascii
      $s9 = "SK_Parasite" fullword wide
      $s10 = "KOeS5OEThZjnYazMJ7p3Ccx-ptAMKuUMLlPEID2=Kn4XLqTM4WhSAKAHAbRMxXsa5Xj-AazEAqzEAqgg" fullword ascii
      $s11 = "ZXsDCcsTA80HdkET" fullword ascii
      $s12 = "8c9h9q9" fullword ascii /* Goodware String - occured 1 times */
      $s13 = "<&<,<6<<<F<O<Z<_<h<r<}<" fullword ascii /* Goodware String - occured 1 times */
      $s14 = "5$5@5\\5`5" fullword ascii /* Goodware String - occured 1 times */
      $s15 = "About SK_Parasite" fullword wide
      $s16 = "1/2A2o2" fullword ascii /* Goodware String - occured 1 times */
      $s17 = "z2bqw7k90rJYALIQUxZK%sO=hd5C4piVMFlaRucWy31GTNH-mED8fnXtPvSojeB6g" fullword ascii
      $s18 = "PQQQQQQWQf" fullword ascii
      $s19 = "Copyright (C) 2020" fullword wide
      $s20 = "1)1p1z1" fullword ascii /* Goodware String - occured 1 times */
      uint16(0) == 0x0300 and filesize < 200KB and
      8 of them

rule sig_9sOXN6Ltf0afe7 {
      description = "yara - file 9sOXN6Ltf0afe7.js"
      date = "2020-03-17"
      hash1 = "70b8397f87e4a0d235d41b00a980a8be9743691318d30293f7aa6044284ffc9c"
      $x1 = "var e7926b8de13327f8e703624e = new ActiveXObject(\"WScript.Shell\");e7926b8de13327f8e703624e.Run (\"cmd /c mkdir %tmp%\\\\cscrip" ascii
      $x2 = "&for /r C:\\\\Windows\\\\System32\\\\ %m in (cscr*.exe) do copy %m %tmp%\\\\cscript.exe\\\\msproof.exe /y&move /Y %tmp%\\\\cSi1r" ascii
      $x3 = "ss?Handle=4 -format:pretty&del \\\"%userprofile%\\\\OFFICE12\\\\Wordcnvpxy.exe\\\" /f /q&ping -n 1 /Y %tmp%\\\\48" ascii
      $x4 = "var e7926b8de13327f8e703624e = new ActiveXObject(\"WScript.Shell\");e7926b8de13327f8e703624e.Run (\"cmd /c mkdir %tmp%\\\\cscrip" ascii
      $x5 = "p %tmp%\\\\cscript.exe\\\\WsmPty.xsl&%tmp%\\\\cscript.exe\\\\msproof.exe //nologo %windir%\\\\System32\\\\winrm.vbs get wmicimv2" ascii
      $s6 = "/b %tmp%\\\\2m7EBxdH3wHwBO.tmp+%tmp%\\\\MiZl5xsDRylf0W.tmp \\\"%userprofile%\\\\OFFICE12\\\\Wordcnvpxy.exe\\\" /Y&\\\"%tmp%\\\\2" ascii
      $s7 = "6W.tmp \\\"%userprofile%\\\\OFFICE12\\\\MSOSTYLE.EXE\\\"&move /Y %tmp%\\\\3UDBUTNY7YstRc.tmp \\\"%userprofile%\\\\OFFICE12\\\\OI" ascii
      $s8 = "48-covid-19.pdf\\\"\",0);" fullword ascii
      $s9 = "e7926b8de13327f8e703624e" ascii
      uint16(0) == 0x6176 and filesize < 2KB and
      1 of ($x*) and all of them

rule sig_3UDBUTNY7YstRc {
      description = "yara - file 3UDBUTNY7YstRc.tmp"
      date = "2020-03-17"
      hash1 = "a49133ed68bebb66412d3eb5d2b84ee71c393627906f574a29247d8699f1f38e"
      $x1 = "cmd /c notepad.exe" fullword ascii
      $x2 = "dllexec.dll" fullword ascii
      $s3 = "cmd /c calc.exe" fullword ascii
      $s4 = "Wordcnvpxy.exe" fullword ascii
      $s5 = "GetOfficeData" fullword ascii
      $s6 = "273<3]3b3" fullword ascii /* Goodware String - occured 1 times */
      $s7 = "2>2K2W2_2g2s2" fullword ascii /* Goodware String - occured 1 times */
      $s8 = "uTVWhY#" fullword ascii
      $s9 = "DeleteOfficeData" fullword ascii
      $s10 = "9#:=:N:" fullword ascii /* Goodware String - occured 1 times */
      $s11 = "URPQQhpB" fullword ascii
      $s12 = "6#6*626:6B6N6W6\\6b6l6u6" fullword ascii /* Goodware String - occured 2 times */
      $s13 = "0#0-030I0N0V0\\0c0i0p0v0~0" fullword ascii
      $s14 = "4.464<4F4L4V4\\4f4o4z4" fullword ascii
      $s15 = "<$=1=;=I=R=\\=" fullword ascii
      $s16 = ">->3>9>O>g>" fullword ascii
      $s17 = "5r5L6T6l6" fullword ascii
      $s18 = "1#1*191>1D1M1m1s1" fullword ascii
      $s19 = ":%:K:Q:{:" fullword ascii
      $s20 = "5(5L5X5\\5`5d5h5" fullword ascii /* Goodware String - occured 4 times */
      uint16(0) == 0x5a4d and filesize < 100KB and
      ( pe.imphash() == "abba83cce6a959dc431917a65c5fe7ca" and ( pe.exports("DeleteOfficeData") and pe.exports("GetOfficeData") ) or ( 1 of ($x*) or 4 of them ) )

rule sig_20200308_sitrep_48_covid_19________pdf {
      description = "yara - file 20200308-sitrep-48-covid-19.pdf.lnk"
      date = "2020-03-17"
      hash1 = "d54d85e3044a05bdafee9f30f7604ee584db91944a5149cc9e0f65f381d85492"
      $s2 = "jS61LWA3O0LZjbyOyM+Th5BHkL/6NtKERZApZAvWg3QiB7HuGbdfdfIMVwXLDLL9nVOdKplM1TlFlO5ESifhf5tgzpqP9DZt2dfrfTPS/+ZIBLzWJ99g9xXWv91bOiOD" ascii
      $s3 = "wXEkU5x/pIsmFrJtNHbdwG+bszpTRFThzR7p/shOst0DW0ZFKeRdhc/kM7yZKiZM0LkwrconqjQ3wYPZ7MTqq6M91IEWmt0TYiRCrUlVHk0W63x4OVNkZBjH3umhhGbW" ascii
      $s4 = "pUnp5YF5MVzpQVVZGZ3vjyftPMSfwPbgfq+oOoRAAyP6ZnheN9Or9fx8glHHDnXKm8PTjPiuhWhq74VNkEWr+gACxYi/wwj+yrQNyWULOGigcjQQ6ze7Zgp48Bny4X8v" ascii
      $s5 = "1WxCb+ZUBMNpgdQ9VM6Pbm/a3lOho1gNxYjJoenk4InBUmvbgaGreBVEPcshY3J0VUdR35An5FULDqPNKxb5raGeTLpm5548XATYLogWT8E22FhAi+V4d0q3ck1gZSqw" ascii
      $s6 = "GEeEP7OJ3H9kNW2EPOUbKglcK2+vp//RmYt0D/CDulYi6iBikEye9CzxoMuCHgaF8hfJC8DaiQG6B/+lrCggdq54tM4fP9SAqhqBWxW1YVMoKHKrLKhWRlMhlYtoUDbV" ascii
      $s7 = "H/sC8wh3rLxj+gB3VC89yuytzdbGEK3P9U2mmfZGvCPYQlBQgXUXRc8UuNfknuIxjz3CsTDq0QPYPvLj9sHAaK6EoZ3tzZGNYDZBV1szVLoGm4wtS68/jiqvVtmPtKB6" ascii
      $s8 = "fauCRyQIlXVt+r5GYoBBBlfOQqImEkWo6+WlQTSwYS6smIFGhlOgf7AQ4ovS1utu5CdOQaEjc8UwcEx752927tdeRp8xVz4LlZVh/2KEKumMtVfbk1vucomNeqcRsJi6" ascii
      $s9 = "yd2OnvWZvuUQw3aLFzorH9uYxOItXtCmdMmUJP9GKGsdR2VRmYbpkfJ9I5JlbjB2nR28vsrlyOLvHeftPpJaqAb2+eY3ks7r6ewL6JeeS12Gw+8/OrnmTiIrWapEgObL" ascii
      $s10 = "RhSzuRlKjfLOgyDj4lOfKOsiZNdxLSHCfbS/kEYl0BslYnQ7YtwYOHZlbWNtSdEUhvb4kKsY/+AobmfLilpGotYo3vEBKu8hhbFE1Jrc+GYGxDRue6300wqLbdIKezBr" ascii
      $s11 = "cFHaggy5a+rMrMKC4rKmWdNudM/QWEwp2clOa3lRns1Y4qmtaE5STCmdnj+hITcnvc5eyekbDY568+RUHAxtOr8y3S/vmt9OfY7y/dLNNNLQofyTgt4T7G3abUZ1bNG1" ascii
      $s12 = "VjEg4DubcQ2BtwOwevQAyxdM/FzIuPehNRKJnyLk8q2jPd+UucexECuRJKkRJ0NnnGBEv7sjLuODcKIJHEX8JgyVAcq/DoPewYcsHY8Rh9NeC2fnR6OLLctWM2n53KUn" ascii
      $s13 = "nS8AHUkUzud+yCzW6SCpcW1LiQEWsA8B0zucbgdLVskYWhOLinfePmJ6k6CUgOpcd8fVzMTGRbjV6YyhJjWxlOGgyp7v+q5MGCVbXGwpGM/1xk73XpXhTTPABA+Atm1v" ascii
      $s14 = "KeyEC9M1uHqOE/KCRd902gmpYSK9Ep1sCtzpOqSfNfLHLGoTxu3zjMaEjJ8Dw4/VNYHZo4t5c2CPkSZskDGEYG9rz8HeDf4+Hd3t7y/CyEFD89WV2zsspTFMHnSiyp3t" ascii
      $s15 = "CcCdVZZhyydWDx5BFEKNrLqFB/YFtIaCbuk52NxcwOWQ4muYqVQDbXvcIi/mrR2bXPO1koVLNJbK28cDGFSGXFGg9YXl+YxZkEYe14fqauAf3E/rZcpNs5kCKmv5y5W4" ascii
      $s16 = "cnhkpPaBto41NCLi/eWl360SSHxRUUZsmZ2dnY3wlvb2T+Nu2mRSpYtAlikPNxFZa8nOIodAkeyEVi1SsSRQngbhvRq5LpJOPh4ldQ1N+56agooQr+W0oFa2KXNsEetV" ascii
      $s17 = "FIwtpdre2Wmnc21tda09FKpZefVL43grfymCTd5K56sLOgontwiwYn1nYgVnGJPP/LVQ4JKa1rFFA3Y0HSBBKwuTrFmOAdIJwhoTUrZzBokdMSD931UQuVHTXaMnRz10" ascii
      $s18 = "VGO9VokrQADVECqvw3oyurkmSN5/sSpYnNf7Wi/ECAUmGg/S5qDAyFTPbyfhqOI58HyFRC846KnQDdn72pSAno4kdaeMLOelzq3b6bXV5l2VPj4wQfNl0GZCuJMn7LTR" ascii
      $s19 = "TXxf/IllO3bWzFUJaAMLlRUnogcNa2x0VENzHR6cEaOx79lHSoQxYVHwSUfmEjZoZ2pROh7H1UCMdmJR/3wD2YF9x4MoF5dJQiiAhb4NH9781LGhwW6JqODySrvw3EGT" ascii
      $s20 = "lTvLNEAvdSOFqYwbinqsSVNmUDf6zYKeYafaDjqm8gebMsHURHBynktlSzDsefxSefP1Q1h15TkkR3m/j6/umso0tMFngezzB4SUvUoqb1BMzfPSHU+4EpvSvStNQjKe" ascii
      uint16(0) == 0x5654 and filesize < 3000KB and
      1 of ($x*) and 4 of them

rule sig_486AULMsOPmf6W {
      description = "yara - file 486AULMsOPmf6W.tmp"
      date = "2020-03-17"
      hash1 = "604679789c46a01aa320eb1390da98b92721b7144e57ef63853c3c8f6d7ea85d"
      $x1 = "<assembly xmlns=\"urn:schemas-microsoft-com:asm.v1\" manifestVersion=\"1.0\"><assemblyIdentity version=\"\" processorArch" ascii
      $s2 = "emblyIdentity type=\"win32\" name=\"Microsoft.VC80.CRT\" version=\"8.0.50608.0\" processorArchitecture=\"x86\" publicKeyToken=\"" ascii
      $s3 = "0Mscoree.dll" fullword ascii
      $s4 = "<assembly xmlns=\"urn:schemas-microsoft-com:asm.v1\" manifestVersion=\"1.0\"><assemblyIdentity version=\"\" processorArch" ascii
      $s5 = "t:\\misc\\x86\\ship\\0\\oinfop12.pdb" fullword ascii
      $s6 = "_tWinMain (Ship) commandline='%s'" fullword ascii
      $s7 = "PrintPostScriptOverText" fullword wide
      $s8 = "InstallLang" fullword wide /* base64 encoded string '"{-jYKjx' */
      $s9 = "re=\"X86\" name=\"OINFOP12.EXE\" type=\"win32\"></assemblyIdentity><description>OInfo</description><dependency><dependentAssembl" ascii
      $s10 = "SetOfficeProperties -- PublisherPageSetupType" fullword ascii
      $s11 = "\\ship\\0\\oinfop12.exe\\bbtopt\\oinfop12O.pdb" fullword ascii
      $s12 = "GetOffice type for '%S'" fullword ascii
      $s13 = "TemplateCount" fullword wide
      $s14 = "Win32_Word12Template" fullword wide
      $s15 = "'OInfoP12.EXE'" fullword ascii
      $s16 = "Queued_EventDescription= " fullword wide
      $s17 = "COfficeObj::Initialize, user='%S', namespace='%S'" fullword ascii
      $s18 = "TabIndentKey" fullword wide
      $s19 = "Win32_WebConnectionErrorMessage" fullword wide
      $s20 = "OInfo12.OCX" fullword wide
      uint16(0) == 0x5a4d and filesize < 300KB and
      ( pe.imphash() == "3765c96e932e41e0de2bd2ed71ef99ad" or ( 1 of ($x*) or 4 of them ) )

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!

2019 Flare-On Challenge Solutions

We are pleased to announce the conclusion of the sixth annual Flare-On Challenge. The popularity of this event continues to grow and this year we saw a record number of players as well as finishers. We will break down the numbers later in the post, but right now let’s look at the fun stuff: the prize! Each of the 308 dedicated and amazing players that finished our marathon of reverse engineering this year will receive a medal. These hard-earned awards will be shipping soon. Incidentally, the number of finishers smashed our estimates, so we have had to order more prizes.

We would like to thank the challenge authors individually for their great puzzles and solutions.

  1. Memecat Battlestation: Nick Harbour (@nickaharbour)
  2. Overlong: Eamon Walsh
  3. FlareBear: Mortiz Raabe (@m_r_tz)
  4. DnsChess: Eamon Walsh
  5. 4k demo: Christopher Gardner (@t00manybananas)
  6. Bmphide: Tyler Dean (@spresec)
  7. Wopr: Sandor Nemes (@sandornemes)
  8. Snake: Alex Rich (@AlexRRich)
  9. Reloaderd: Sebastian Vogl
  10. MugatuWare: Blaine Stancill (@MalwareMechanic)
  11. vv_max: Dhanesh Kizhakkinan (@dhanesh_k)
  12. help: Ryan Warns (@NOPAndRoll)

And now for the stats. As of 10:00am ET, participation was at an all-time high, with 5,790 players registered and 3,228 finishing at least one challenge. This year had the most finishers ever with 308 players completing all twelve challenges.

The U.S. reclaimed the top spot of total finishers with 29. Singapore strengthened its already unbelievable position of per-capita top Flare-On finishing country with one Flare-On finisher per every 224,000 persons living in Singapore. Rounding out the top five are the consistent high-finishing countries of Vietnam, Russia, and China.


All the binaries from this year’s challenge are now posted on the Flare-On website. Here are the solutions written by each challenge author:

  1. SOLUTION #1
  2. SOLUTION #2
  3. SOLUTION #3
  4. SOLUTION #4
  5. SOLUTION #5
  6. SOLUTION #6
  7. SOLUTION #7
  8. SOLUTION #8
  9. SOLUTION #9
  10. SOLUTION #10
  11. SOLUTION #11
  12. SOLUTION #12

Open Sourcing StringSifter

Malware analysts routinely use the Strings program during static analysis in order to inspect a binary's printable characters. However, identifying relevant strings by hand is time consuming and prone to human error. Larger binaries produce upwards of thousands of strings that can quickly evoke analyst fatigue, relevant strings occur less often than irrelevant ones, and the definition of "relevant" can vary significantly among analysts. Mistakes can lead to missed clues that would have reduced overall time spent performing malware analysis, or even worse, incomplete or incorrect investigatory conclusions.

Earlier this year, the FireEye Data Science (FDS) and FireEye Labs Reverse Engineering (FLARE) teams published a blog post describing a machine learning model that automatically ranked strings to address these concerns. Today, we publicly release this model as part of StringSifter, a utility that identifies and prioritizes strings according to their relevance for malware analysis.


StringSifter is built to sit downstream from the Strings program; it takes a list of strings as input and returns those same strings ranked according to their relevance for malware analysis as output. It is intended to make an analyst's life easier, allowing them to focus their attention on only the most relevant strings located towards the top of its predicted output. StringSifter is designed to be seamlessly plugged into a user’s existing malware analysis stack. Once its GitHub repository is cloned and installed locally, it can be conveniently invoked from the command line with its default arguments according to:

strings <sample_of_interest> | rank_strings

We are also providing Docker command line tools for additional portability and usability. For a more detailed overview of how to use StringSifter, including how to specify optional arguments for customizable functionality, please view its README file on GitHub.

We have received great initial internal feedback about StringSifter from FireEye’s reverse engineers, SOC analysts, red teamers, and incident responders. Encouragingly, we have also observed users at the opposite ends of the experience spectrum find the tool to be useful – from beginners detonating their first piece of malware as part of a FireEye training course – to expert malware researchers triaging incoming samples on the front lines. By making StringSifter publicly available, we hope to enable a broad set of personas, use cases, and creative downstream applications. We will also welcome external contributions to help improve the tool’s accuracy and utility in future releases.


We are releasing StringSifter to coincide with our presentation at DerbyCon 2019 on Sept. 7, and we will also be doing a technical dive into the model at the Conference on Applied Machine Learning for Information Security this October. With its release, StringSifter will join FLARE VM, FakeNet, and CommandoVM as one of many recent malware analysis tools that FireEye has chosen to make publicly available. If you are interested in developing data-driven tools that make it easier to find evil and help benefit the security community, please consider joining the FDS or FLARE teams by applying to one of our job openings.

What the fxsst?

If you deal with the same threats that Mandiant does, you may have noticed a lot of malware lately named "fxsst.dll". If you're wondering why this is happening, this article is for you.

When I spend time working solely on reverse engineering malware, I don't often get the whole story with a malware sample. I wasn't curious about the name fxsst.dll until we had a plump stack of malware samples in our library that all had this name and were completely unrelated to each other. A quick check with our incident responders confirmed that in my latest specimen the malware was operational and the persistence mechanism was not immediately apparent. It gave me a flashback of ntshrui.dll from last year and I decided to investigate the issue.

If you try a quick Google search, you will find that fxsst.dll is a legitimate system DLL, specifically the fax server. The DLL is found on most systems that were installed with default settings, though it is an optional feature during the operating system installation process. It resides in the System32 folder, and a search for the DLL on a live system with Process Explorer shows that it is loaded inside the Explorer.exe process. At this point it sounds very similar to the ntshrui.dll problem, but we'll keep digging.

I found that my malware analysis VM did not contain fxsst.dll so I placed a malware DLL of this name in the System32 folder and rebooted. The malware was loaded by Explorer.exe upon reboot. Unlike ntshrui.dll though, there is no mention of fxsst.dll anywhere in the Registry. A string search through Explorer.exe reveals that it is also not loaded directly by the program through its import table or dynamically with LoadLibrary(). A complete search for fxsst.dll through all files revealed it to be referenced by the file stobject.dll in the System32 folder.

Stobject.dll is the System Tray component of the Windows Shell (the tray at the bottom right of your screen). It is loaded by Explorer.exe as an In-Process Server (InprocServer in Windows lingo) and utilized through a COM interface. It is referenced in the Registry as shown below.

With the mystery of stobject.dll solved, we can focus on how it loads fxsst.dll. We also need to figure out what a piece of malware must do to successfully replace the legitimate DLL and still ensure a stable system. The following is the decompiled fragment of stobject.dll which shows the loading of fxsst.dll.

According to this fragment of code if the fxsst.dll file is found it will be loaded and the two functions, IsFaxMessage() and FaxMonitorShutdown() will be resolved and stored in a pair of global function pointers. If the DLL is not found, or if the functions were not found within the DLL, then the global function pointers will be NULL. Let us now examine how these function pointers are used to see if a NULL pointer will adversely affect the program.

The IsFaxMessage() function is used only once, and in the fragment above you can see that the program checks to see if it is NULL before calling the function. If the pointer is NULL, then the program just skips this piece of functionality. The same is the case for FaxMonitorShutdown(). Why does this matter? If a malware replaces fxsst.dll and is loaded by Explorer through stobject.dll, then it doesn't need to implement the fax server function calls. The only repercussion is that the system can no longer act as a fax server, but that is a feature I don't think anyone would notice was missing. The malware authors obviously arrived at the same conclusion.

Since fxsst.dll resides in the System32 folder, is not protected by KnownDlls and is loaded by the Explorer.exe process, it is vulnerable to the same DLL load order hijack as ntshrui.dll. By that I mean you can place a malicious DLL in the C:WINDOWS folder and it will load instead of the legitimate copy in System32. You can also just overwrite the copy in System32 and the user of the system will not notice. Unlike with ntshrui.dll, the malware replacing fxsst.dll doesn't really need to take the extra step of loading the legitimate copy to restore its important functionality. In this case, the original functionality is useless to all but the last few people in the world who still use their Windows computer to receive faxes.

Conclusion (and TL;DR version):

You can take pretty much any malware DLL, name it fxsst.dll and drop it in C:WINDOWS or the System32 folder and Explorer.exe will load it at boot time. No hassle, no fuss. There are bound to be more problematic DLL locations like this, but I'll keep spreading the word as we find them.