2023
LONDON
4 - 6 October, 2023 / London, United Kingdom

TEASING THE SECRETS FROM THREAT ACTORS:MALWARE CONFIGURATION EXTRACTORSMark Lim & Zong-Yu Wu
Palo Alto Networks, Singapore & UK
malim@paloaltonetworks.com
zwu@paloaltonetworks.com

www.virusbulletin.com

TEASING THE SECRETS FROM THREAT ACTORS: MALWARE CONFIGURATION EXTRACTORS LIM & WU

ABSTRACT
Malware, like most complex software systems, utilizes the concept of software configuration. Configurations provide
directives for how the malware should behave and they are pervasive across the various malware families we analyse. Thisconfiguration data embedded in malware can be a goldmine of information about what the malware authors are up to. The
main problem is that configuration data in malware is usually difficult to parse statically from the file by design. Malware
authors know the intelligence value of these configurations because they give away the marching orders for each instanceof the malware, so they’re almost always statically armoured.
During the past few years, we have been building a malware configuration extractor system internally at Palo Alto
Networks. We are now open-sourcing extractors for several malware families in order to share it with the researchcommunity. The extractors are written in Python and are designed to scan and extract configuration data from the memory
dumps of specific malware samples during dynamic execution.
In this paper we will dive into selected configuration protection techniques that have been utilized by several different
malware families. There will be case studies from analysing major families like Trickbot (TheTrick), IcedID (Bokbot) and
Emotet (Geodo). There will also be a demonstration of an infostealer (RedLine) compiled in MSIL (.NET). There iscommon protection design among families as well as customized anti-analysis, both of which we had to tackle in our
extractors. Additionally, malware compiled to MSIL (.NET) follows a different Instruction Set Architecture (ISA) and data
storage. We will highlight the evolution of the analysis techniques utilized by two malware families: Guloader and Emotet.
Configuration parsing can be fun and useful but it has never been easy. In this paper, we will start from the ground up by
introducing what malware configurations are, then taking a deep dive into parsing and extraction. The case studies arecomprised of malware families with different purposes that leverage various anti-analysis techniques. Unfortunately, as thiscat-and-mouse game goes, this research definitely will not be the end. We hope that by sharing information about thesemalware configurations we will help everyone prepare for the next uphill battle.

INTRODUCTION
Malware configurations play a critical role in the functionality and behaviour of malicious software. These configurations,also known as command-and-control (C2) configurations, contain important settings that govern how the malware operates,
communicates, and carries out its malicious activities.
Malware configurations typically include essential information such as C2 server addresses, port numbers, encryption keys,
communication protocols and other settings specific to the malware’s intended purpose. These configurations serve as a
blueprint for the malware’s operations, allowing it to establish communication channels with external entities, receive
commands from threat actors, and exfiltrate stolen data.
The C2 configurations are often encrypted or obfuscated to prevent easy detection and analysis by security researchers andanti-virus solutions. Malware authors employ various techniques to hide and protect these configurations, making it
challenging for defenders to understand the inner workings of the malware and devise effective countermeasures.
In recent years, the study of C2 configurations has become increasingly important as cybercriminals and advanced threat
actors continue to develop sophisticated techniques to evade detection and establish persistence of their malware.
Cybersecurity professionals continuously strive to uncover the hidden secrets within C2 configurations to better understandthe tactics, techniques and motives behind these malicious campaigns.
In this paper we will delve into the various methods to uncover the secrets hidden within these configurations, providing
insights into the evolving nature of malware and the ongoing battle to protect against its threats.
Table 1 lists the malware families and the key protections for their configurations that we will discuss in this paper.
FamilyProtection

GuloaderCiphertext splitting and control flow obfuscation

IcedIDXOR cipher

Trickbot

Erasing configuration after use, mixing decoys with actual C2 IP addresses
and XOR cipher

Emotet – v5 in mid-2020

Plaintext C2 list and XOR cipher

Emotet – v6 in late-2021

O-LLVM protected and emulation is required

RedLineBase64 and XOR cipher

WarZone RAT

RC4 and a variant with customized RC4+
Table 1: Malware families and their key protections.

2

VIRUS BULLETIN CONFERENCE OCTOBER 2023

TEASING THE SECRETS FROM THREAT ACTORS: MALWARE CONFIGURATION EXTRACTORS LIM & WU

1. EVOLUTIONARY JOURNEY OF GULOADER’S CONFIGURATION TACTICS
In this section we delve into the progressive evolution of the anti-analysis mechanisms implemented for Guloader’s C2
configuration and we undertake the challenge of decrypting the encrypted C2 configuration, overcoming the complex
defensive measures implemented in the latest iterations of Guloader.

1.1 Guloader’s initial approach to protecting C2 configuration
Guloader is a prominent instrument employed by cybercriminals to propagate and implant diverse forms of malware onto
targeted systems. Guloader was first active in 2020, as reported by CrowdStrike [1]. All the strings that included thisthreat’s C2 configuration1 were originally decrypted together in memory. A simple search for the substring ‘http’ would
reveal the C2 configuration.

Figure 1: Searching the C2 configuration using the substring ‘http’.

1.2 Additional protections
Since 2022, however, the Guloader authors have gone to great lengths to obfuscate the C2 configuration. Conducting asimple search for ‘http’ in the memory dumps of Guloader samples no longer yields the C2 configuration because, after
decryption, the configurations no longer start with ‘http’. Instead, Guloader’s authors have added code that dynamicallyreplaces the first eight random characters of the decrypted C2 configuration with the substring ‘http://’ or ‘https://’ duringruntime.
Due to the absence of direct memory dump search capabilities for the C2 configuration, decrypting the C2 configuration
requires knowledge of the following:
1.

Encryption routine

2.

Encryption key

3.

Ciphertext (encrypted C2 configuration)

The encryption routine is a simple XOR loop for decrypting the ciphertext. Presumably, this approach was chosen for its
ease of implementation. Furthermore, the offset to the bytes of the encryption key and ciphertext remained constant. As aresult, brute-force techniques could be employed to retrieve the C2 configuration, as demonstrated in our blog post [2].

1.2.1 Use of ciphertext splitting
In the latter part of 2022, we observed modifications to the storage of ciphertext, rendering the previously discussed
brute-force method ineffective.
In Figure 2, the left side illustrates the previous method of storing the ciphertext. The ciphertext was stored as a continuous
sequence of bytes. On the right side, the diagram shows the new method of storing the ciphertext. In this new approach, theciphertext is computed from a function. In this function, the ciphertext is first divided into four-byte DWORDs. Each
DWORD is individually encrypted using randomized mathematical operations.

Figure 2: Comparing old and new methods of storing ciphertext.
1

Guloader SHA256: bfa5dba46db1253587058b0392c04c8403846fa55d7dcf1044e94e6a654d4715

VIRUS BULLETIN CONFERENCE OCTOBER 2023

3

TEASING THE SECRETS FROM THREAT ACTORS: MALWARE CONFIGURATION EXTRACTORS LIM & WU

For example, to retrieve the first DWORD of the ciphertext in Figure 2, we have to compute the following mathematicaloperations:Figure 3: An example of computing a DWORD of the ciphertext.
To acquire the complete ciphertext, we would need to perform a series of operations, similar to the one mentioned above,for each individual DWORD. Subsequently, we would proceed to concatenate these DWORDs together, resulting in theformation of the ciphertext.

1.2.2 Control flow obfuscation
Not only did the storage of the ciphertext change, a control flow obfuscation technique was also progressively applied to
Guloader samples. In September 2022, we observed many 0xCC bytes (INT 3 instructions) littered throughout a Guloader
sample. These INT 3 instructions would trigger the EXCEPTION_BREAKPOINT exception, as shown in Figure 4.

Figure 4: A disassembly of Guloader with instructions triggering EXCEPTION_BREAKPOINT.
In Figure 4, the disassembly has been manually improved to highlight the instructions that have been added foranti‑analysis. Subsequent to the presence of 0xCC bytes, extraneous or meaningless instructions were introduced. These
additional bytes deliberately disrupted the disassembly process employed by static analysis tools, leading to an incorrectdisassembly listing. To address this particular challenge, we provided a solution in the form of an IDA processor module
extension. In a detailed blog post [3], we outlined the steps and techniques necessary for writing and implementing thisextension, enabling accurate disassembly results.
At the beginning of 2023, we discovered a Guloader sample2 that had an advancement in the implementation of the control
flow obfuscation technique. In addition to the previously observed 0xCC bytes, the malware authors incorporated instructions
that deliberately resulted in a null pointer. These instructions would trigger the EXCEPTION_ACCESS_VIOLATION exception
during runtime. Figure 5 shows the specific instructions that were introduced as part of the anti-analysis measures. The
disassembly shown in this image has been manually improved to highlight the instructions added for anti-analysis.

Figure 5: A disassembly of Guloader with instructions triggering EXCEPTION_ACCESS_VIOLATION.
2

4

Guloader SHA256: 32ea41ff050f09d0b92967588a131e0a170cb46baf7ee58d03277d09336f89d9

VIRUS BULLETIN CONFERENCE OCTOBER 2023

TEASING THE SECRETS FROM THREAT ACTORS: MALWARE CONFIGURATION EXTRACTORS LIM & WU

During our research for this paper, we encountered a Guloader sample3 that exhibited zero VirusTotal (VT) detections. In
addition to the instructions that caused the EXCEPTION_BREAKPOINT and EXCEPTION_ACCESS_VIOLATION exceptions,
instructions that enabled the trap flag to trigger the EXCEPTION_SINGLE_STEP exception were also incorporated. Similar
to the case of the 0xCC bytes, redundant bytes were introduced here as well. Figure 6 illustrates how all these instructions
were placed together for anti-analysis.

Figure 6: A disassembly of Guloader with control flow obfuscation, with instructions triggering EXCEPTION_ACCESS_VIOLATION, EXCEPTION_BREAKPOINT and EXCEPTION_SINGLE_STEP.
As a consequence of the addition of instructions that trigger access violations and single-step exceptions, the previous
solution of writing an IDA processor module extension to counter the anti-analysis technique became ineffective. This isbecause, whilst in our IDA Process Module extension we could detect the INT 3 (0xCC) instruction, due to the variable
length nature of Intel x86 CPU instructions, we could not detect the huge combination of instructions that triggers accessviolation and single-step exceptions.
In the next section, we will comprehensively outline our approach which successfully circumvents the anti-analysis
mechanisms, allowing for the automated decryption of the C2 configuration from the Guloader memory dump.
Before delving into the intricacies of our solution for decrypting Guloader’s C2 configuration, let’s provide a concise
overview of the anti-analysis measures recently implemented by the Guloader authors to safeguard their C2 configuration:

3

1.

Ciphertext splitting: The encrypted C2 configuration is divided into multiple DWORDs, which are individual
four-byte data units. Each DWORD is then subjected to encryption using randomized mathematical operations. Thisfragmentation and encryption technique adds an extra layer of complexity to the analysis process.

2.

0xCC (INT 3) instructions: Guloader incorporates 0xCC instructions, also known as INT 3 instructions, within its
code. These instructions trigger an EXCEPTION_BREAKPOINT at runtime, causing the execution of the malware tohalt. This deliberate interruption serves as an anti-analysis measure, preventing static analysis tools from accurately
disassembling the code.

3.

Null pointer access instructions: The malware authors introduced instructions that intentionally cause null pointeraccess violations during runtime. These instructions lead to an EXCEPTION_ACCESS_VIOLATION, where the

Guloader SHA256: beda408709feea7d2023f328e9c97bf4d090bcfb3948fc4e4d9c5c580d8f5858a

VIRUS BULLETIN CONFERENCE OCTOBER 2023

5

TEASING THE SECRETS FROM THREAT ACTORS: MALWARE CONFIGURATION EXTRACTORS LIM & WU

program attempts to access a memory location that is invalid or uninitialized. This technique aims to disrupt the
program flow and impede analysis by introducing runtime errors.
4.

CPU trap flag instructions: Guloader also employs instructions that enable the CPU trap flag during runtime,
resulting in an EXCEPTION_SINGLE_STEP exception. This flag triggers an interrupt after each executed instruction,
making the analysis process more challenging as it complicates the normal execution flow and introduces additional
breakpoints.

Understanding these anti-analysis measures is crucial in appreciating the complexity and evolving nature of Guloader’s
defence mechanisms. With this knowledge, we can proceed to explore our solution for decrypting the elusive C2
configuration and overcoming these formidable obstacles.

1.3 Our solution to automatically decrypt C2 configuration from Guloader memory dumps
We begin with our analysis of how the Guloader sample intricately handles three exceptions (EXCEPTION_BREAKPOINT,
EXCEPTION_ACCESS_VIOLATION and EXCEPTION_SINGLE_STEP). Let us focus on the Vector Exception Handler (VEH)
function within the Guloader sample. The diagram in Figure 7 presents a pseudocode representation of the VEH function,
carefully annotated and modified for clarity.

Figure 7: Pseudocode of the VEH function in Guloader.

1.3.1 Analysing EXCEPTION_BREAKPOINT
When confronted with the EXCEPTION_BREAKPOINT exception, the VEH function starts by inspecting the utilization of
hardware breakpoints. In the absence of hardware breakpoints, the function examines the address pointed to by the EIP for
the presence of a 0xCC byte. To decrypt the offset, the byte following the EIP is XOR’ed with a single-byte key, which
varies from sample to sample (in this sample, it’s 0xBB). Subsequently, a loop scans for software breakpoints that could beplaced by debuggers (0xCC byte) after the EIP-addressed location. If no software breakpoint is detected, the offset is added
to the EIP, allowing code execution to resume from the updated EIP position. The updated EIP will be after the extraneous
instructions.

1.3.2 Analysing EXCEPTION_ACCESS_VIOLATION and EXCEPTION_SINGLE_STEPThe EXCEPTION_ACCESS_VIOLATION and EXCEPTION_SINGLE_STEP exceptions share the same handling code. Following
the examination of hardware breakpoints, the offset undergoes decryption by XOR’ing the second byte after the EIP with asingle-byte key, which is the same one as used for EXCEPTION_BREAKPOINT. The resulting offset is then added to the EIP,
allowing code execution to proceed from the updated EIP position. The updated EIP will be after the extraneous instructions.

6

VIRUS BULLETIN CONFERENCE OCTOBER 2023

TEASING THE SECRETS FROM THREAT ACTORS: MALWARE CONFIGURATION EXTRACTORS LIM & WU

1.3.3 Walking through our solution
For our solution, we utilized the Unicorn CPU emulator framework [4] to automatically decrypt the C2 configuration from the
Guloader sample memory dump. By leveraging the capabilities of the Unicorn framework, we were able to replicate thenecessary mathematical operations required to overcome the ciphertext splitting technique employed by the Guloader authors.
One key advantage of using the Unicorn framework is its ability to handle multiple exceptions generated by instructions
during code execution. We incorporated hooks into our implementation to intercept and handle these exceptions effectively.
The handler code within the hooks enables us to update the instruction pointer with the decrypted offset, allowing us tobypass extraneous instructions and continue code execution at the correct decrypted location.
Let’s delve into the code snippet that specifically handles the EXCEPTION_BREAKPOINT exception. In this snippet, theprovided code is registered as a hook for the EXCEPTION_BREAKPOINT exception. When this particular exception occurs,
the hook function is triggered. The code first checks if the interrupt number is 3, which corresponds to the EXCEPTION_
BREAKPOINT exception. If it is, the function proceeds to read the byte after the instruction that triggered the exception. By
performing an XOR operation between this byte and the key value 0xBB, we obtain the decrypted offset value. Finally, thefunction updates the EIP by adding the decrypted offset, effectively redirecting code execution to the correct decrypted
location.

Figure 8: Python code snippet that handles the EXCEPTION_BREAKPOINT exception.
The next code snippet addresses the EXCEPTION_SINGLE_STEP exception. This exception is handled in a similar mannerto the EXCEPTION_BREAKPOINT exception, with a few notable differences. Instead of reading the byte immediately after
the triggering instruction, it reads the second byte after that instruction. This difference in byte offset is specific to handling
EXCEPTION_SINGLE_STEP.

Additionally, in order to prevent the exception from being re-triggered by subsequent instructions, it is necessary to clear
the trap flag before continuing with code execution. Clearing the trap flag ensures that the exception is not continuously
triggered by subsequent instructions, allowing the program to proceed without interruptions.

Figure 9: Python code snippet that handles the EXCEPTION_SINGLE_STEP exception.
In the final code snippet, we address the EXCEPTION_ACCESS_VIOLATION exception. Due to limitations in the Unicorn
framework’s memory access handling, we employed a work-around to handle this exception in a somewhat crude manner.
The hook_code() function contains code to replace the memory address of a null pointer with an inaccessible memory
address. This modification causes the instructions that originally relied on the null pointer to trigger the EXCEPTION_ACCESS_VIOLATION exception when executed. This is a way to simulate the behaviour of accessing invalid memory.

Figure 10: Python code snippet in the hook_code() function.

VIRUS BULLETIN CONFERENCE OCTOBER 2023

7

TEASING THE SECRETS FROM THREAT ACTORS: MALWARE CONFIGURATION EXTRACTORS LIM & WU

When the EXCEPTION_ACCESS_VIOLATION exception is encountered, the code snippet presented next serves to update theEIP with the decrypted offset, much like the previous code snippets. However, in order for the execution to proceedsmoothly, it becomes imperative to allocate memory at the previously inaccessible memory address. This allocation ensuresthat the execution can continue without encountering any further memory access problems or interruptions.
It’s important to note that this approach is a work-around and may not be the most elegant solution. It addresses the specificlimitations of the Unicorn framework when it comes to handling memory access with null pointers. A more robust andaccurate memory handling mechanism would be preferable.

Figure 11: Python code snippet that handles the EXCEPTION_ACCESS_VIOLATION exception.

1.4 Summary
In this section, we have explored the continuous evolution of anti-analysis techniques employed by the creators of
Guloader to safeguard its C2 configuration. We have discussed the challenges faced in decrypting the encrypted C2
configuration and how we have successfully overcome the complex defensive measures implemented in the latest versionsof Guloader.

2. LOCATING ICEDID’S CONFIGURATIONS USING YARA
In this section, we document a case study using YARA rules to locate IcedID’s encrypted configurations in memory.
IcedID, a financially motivated threat, has garnered our attention due to its dynamic nature and continuous evolution. Thissophisticated malware operates as a botnet and has established connections with other notorious malware families such as
Trickbot and Emotet. Given its malicious intent and interconnectedness, it is crucial for IcedID to effectively hide its C2
configurations.

2.1 IcedID’s attack chain
We focused on a common attack chain [5] employed by the authors of IcedID, shown in Figure 12.

Figure 12: Attack chain of IcedID.
The two-stage attack chain employed by the authors of IcedID served as a clever strategy to conceal their configurations.
The IcedID Stage 1 only had a single C2 URL in its configuration, while Stage 2 had more information, such as multiple
C2 URLs and campaign IDs. IcedID Stage 2 would only be downloaded if the victim’s machine met specific criteria set by
the threat actors, adding an additional layer of secrecy. This also allowed the threat actors to have multiple sets of C2
infrastructures, which added complexity to the analysis process. This complexity makes it more difficult for defenders tounderstand the operation of the threat actors.
While the encryption routines used by both stages of IcedID remained consistent, the authors implemented measures to
obscure the locations of the ciphertext. In the following sections, we will focus on using YARA rules to extract the
ciphertext. The details of the encryption routines have already been documented in [6].

8

VIRUS BULLETIN CONFERENCE OCTOBER 2023

TEASING THE SECRETS FROM THREAT ACTORS: MALWARE CONFIGURATION EXTRACTORS LIM & WU

2.2 IcedID Stage 1
The address of the ciphertext of IcedID Stage 1 is located in the decryption loop for its configuration. We wrote a YARA
rule to locate the pointer to the ciphertext, together with instructions of the decryption loop.
The following diagrams show examples of the various implementations of the decryption loop. Our YARA rule had to beflexible enough to locate the pointer to the ciphertext and have low false positive rates.

Figure 13: First implementation of IcedID Stage 1 decryption loop.

Figure 14: Second implementation of IcedID Stage 1 decryption loop.
We wrote the following YARA rule to locate the ciphertext in IcedID Stage 1:

Figure 15: YARA rule to locate the ciphertext in IcedID Stage 1.
This rule also located the ciphertext in a recent IcedID Stage 1 sample4 discovered by a fellow researcher [7] in May
2023.
4

IcedID SHA256: 6df2ece892c9192c90d4d9fdec768beb17aecfb17d44adc69a11cb50721fa68e

VIRUS BULLETIN CONFERENCE OCTOBER 2023

9

TEASING THE SECRETS FROM THREAT ACTORS: MALWARE CONFIGURATION EXTRACTORS LIM & WU

Figure 16: IcedID Stage 1 decryption loop of a recent IcedID Stage 1 sample.

2.3 IcedID Stage 2
The configurations within IcedID Stage 2 encompass crucial elements such as C2 URLs and campaign IDs. The campaign
IDs serve as essential links, connecting IcedID samples to specific threat actors, enabling further investigation andattribution.
The following diagram shows examples of the various implementations of the pointer to ciphertext. The instructions to load
both the pointer to ciphertext and its length as arguments to the description function are deliberately mixed among otherfunction calls.

Figure 17: First implementation of IcedID Stage 2 pointer to ciphertext.

Figure 18: Second implementation of IcedID Stage 2 pointer to ciphertext.
We wrote the following YARA rule to locate the ciphertext in IcedID Stage 2:

Figure 19: YARA rule to locate the ciphertext in IcedID Stage 2.
The above rule also located the ciphertext in a recent IcedID Stage 2 sample5 discovered by a fellow researcher in May
2023 [7].
510

IcedID SHA256: f85d883717d113fcf20afab161470ef2911c729d4d6b04382da0de746b53f0f2

VIRUS BULLETIN CONFERENCE OCTOBER 2023

TEASING THE SECRETS FROM THREAT ACTORS: MALWARE CONFIGURATION EXTRACTORS LIM & WU

Figure 20: Recent implementation of IcedID Stage 2 pointer to ciphertext.

2.4 Summary
By locating the ciphertext from the memory dumps of IcedID Stages 1 and 2 we could extract their configurations. Some ofthese C2 URLs in their configurations may not be readily unveiled during the execution of the IcedID binaries. These C2
URLs and the campaign IDs allowed defenders to piece together a network of knowledge on the threat actors using the
IcedID malware.

3. REVEALING THE TRICKERY OF TRICKBOTIn this section, we investigate the measures taken by Trickbot to protect its configurations. Trickbot is a highlysophisticated banking trojan and modular malware framework that has been active since 2016. It has evolved over time,
incorporating new features and techniques to evade detection and persist on infected systems.

3.1 Flashback to 2018
Back in 2018, the authors of Trickbot left their configuration in memory after decrypting it, allowing it to be easily locatedvia a YARA rule. Figure 21 shows how easy it is to locate Trickbot’s configuration from the memory dump of a Trickbot
sample6 first seen in 2018.

Figure 21: Trickbot configuration left in the memory.

3.2 Bags of tricks
In 2022, a Trickbot sample7 added many more measures to protect its configurations. A function was added to erase thedecrypted configurations once utilized. Figure 22 shows the configuration being overwritten with null bytes.
The threat actors then mixed genuine and decoy C2 IP addresses in the configuration. The decoy IP addresses were taggedwith ‘<srva>’, while the genuine ones were tagged with ‘<srv>’. Figure 23 shows the decoy C2 IP addresses (in the greenbox) among the genuine IP addresses.
The purpose of the decoy IP addresses was to conceal the genuine IP addresses. To reveal the genuine IP addresses, we
utilized a script that decodes the decoy addresses. This script starts by separating the port number from the IP address andconverting each octet of the IP address into an integer value. The script then performs a series of XOR operations, similar
to the malware code, to decode the values in each octet of the IP address. After decoding the octets, the script computes theport number. Finally, the script constructs the genuine IP address using the decoded octets and port number.
6
7

Trickbot SHA256: 2153be5c6f73f4816d90809febf4122a7b065cbfddaa4e2bf5935277341af34c
Trickbot SHA256: 0374bb627e51aa5fa5df0640a5468939cf190a1a1bc0c8a0f3df4bc9b3e92171

VIRUS BULLETIN CONFERENCE OCTOBER 2023

11

TEASING THE SECRETS FROM THREAT ACTORS: MALWARE CONFIGURATION EXTRACTORS LIM & WU

Figure 22: Trickbot authors nulling configurations after use.

Figure 23: Mixing decoy and real C2 IP addresses in the configuration.

Figure 24: Python script to decode actual C2 IP addresses.

12

VIRUS BULLETIN CONFERENCE OCTOBER 2023

TEASING THE SECRETS FROM THREAT ACTORS: MALWARE CONFIGURATION EXTRACTORS LIM & WU

Fast forward to late 2022, the authors of Trickbot made major changes and adopted the AnchorMail framework [8]. For
these samples8, we decrypted the configuration using the script shown in Figure 25.

Figure 25: Script to decrypt recent Trickbot sample C2 configuration.

3.3 Summary
We have shown the various techniques used by the authors of Trickbot to protect their configurations from analysis anddetection by security researchers. Overall, the authors of Trickbot have demonstrated a significant level of sophistication in
their efforts to protect their malware from analysis and detection.

4. DISSECTING THE EVERYDAY HUSTLER: EMOTET (AKA GEODO)
Emotet is an example of a piece of malware for which a configuration extractor can be powerful, but also painful to
implement. Back in 2019 when Emotet became a prominent threat, we were able to identify the botnet infrastructure
design [9] by clustering the RSA key and the C2 endpoints extracted from the configurations. A configuration extracted
from Emotet contained a set of C2 IP addresses plus an RSA key (in the older version) or ECDH key (in the newer
version). The C2 IPs were compromised hosts on which a proxy that redirected incoming traffic to the next layer ofbotnet infrastructure was installed. Once a host was infected by an Emotet sample, a UPnP module was dropped [10]and it became part of the first tier of C2 infrastructure. The C2 IPs were reused for days to weeks, which meant that if
the configuration extractor had caught them at time zero, there was a good chance that we would be able to provide
protection in the future. This is a success story of configuration extraction that benefited both detection and threat
intelligence.
During the time the botnet was active it changed network protocol, configuration protection and obfuscation on a weekly
basis. Additionally, the botnet disappeared from time to time, coming back each time with a brand new protocol or a brandnew protection.

4.1 Version 5 samples in mid-2020
In the version 5 samples seen in mid-2020, both the configuration and the encrypted resources used by the binary werestored in the .data section. We needed to locate the pointer that referenced the encrypted C2 payload and RSA key. The
encrypted C2 payload was stored in sequential byte strings that ended in four bytes of \x00. We were able to leverage thecode pattern shown in Figure 26 to locate the pointer (0x40A328 in this case).
8

Trickbot SHA256 52901478b6fb8c1ae7803997708648eaff9e32a93d017fd6945464fb41f3f9a1

VIRUS BULLETIN CONFERENCE OCTOBER 2023

13

TEASING THE SECRETS FROM THREAT ACTORS: MALWARE CONFIGURATION EXTRACTORS LIM & WU

Figure 26: The code block that loaded the C2 from the binary in Emotet’s main binary in mid-2020.
Once we located the pointer and read out the payload, we noticed that the C&C lists were not encrypted at all. Next, we
moved on to the RSA key. The RSA public key embedded in the file was used to encrypt the communication protocol,
which is only decryptable with the possession of the private key. The version of Emotet in this period used CryptImportKey[11] to load the decrypted RSA key and used the handle to encrypt data later. Our goal was to quickly locate the pointer tothe RSA by searching the APIs used. Unfortunately, the Windows APIs used by the Emotet main module were obfuscated.
The APIs were dynamically loaded using API name hash matching. The following decompiled code snippet shows how
HeapFree was dynamically invoked.

Figure 27: The decompiled code snippet that dynamically loaded the API. The comments are labelled automatically by our
IDA Pro script.
Now, let’s talk about how to automatically identify these encrypted APIs. Navigating to the function we labelled as

lib_get_api_by_hash, we found that the hash algorithm was fairly simple. Note that there is a simple XOR against arandom DWORD in both lib_get_dll_va_by_hash and lib_get_api_by_hash.

Figure 28: The equivalent hash function implemented in Python.
Given that every dynamically loaded API had to call these two functions, our first goal was to get the argument passed to
the function. First, we manually labelled the lib_get_dll_va_by_hash and lib_get_api_by_hash functions within
IDA Pro. We then iterated through the xrefs [12] of lib_get_dll_va_by_hash and lib_get_api_by_hash to get all
the arguments that were passed to the functions. These arguments were the hashed API or DLL name the Emotet sample
was looking to invoke. Since hashing is a one-way function, it is designed to digest the input and be irreversible. The best
way we could find out what the inputs were was through brute forcing. Given that the Windows APIs Emotet needed were
those provided by default in a Windows system, our approach was to list all the DLLs and their export names in the
Windows system, compute the hash and check if the output matched any arguments that were passed to the functions
lib_get_dll_va_by_hash and lib_get_api_by_hash. The Python code shown in Figure 29 does the trick to list andcompute the export name.

Figure 29: An example of a Python script that gets the exports from a given DLL.

14

VIRUS BULLETIN CONFERENCE OCTOBER 2023

TEASING THE SECRETS FROM THREAT ACTORS: MALWARE CONFIGURATION EXTRACTORS LIM & WU

For example, we got an argument for lib_get_api_by_hash with value 0x12345678 and the VirtualAllocEx function
also hashed to the same value. This means that the code snippet was dispatching Kernel32.dll.VirtualAllocEx. If the
API is clear for us, it becomes easy to locate where the CryptImportKey is used. Interestingly, the encrypted RSA key islocated just above the first C2.

Figure 30: The encrypted RSA public key binary payload in IDA Pro screenshot.

Figure 31: Structure of the encrypted RSA public key in C code format.

4.2 Version 6 samples in late-2021 and 2022
To respond to rapid updates in the detection capabilities of security products against Emotet, the developer behind
Emotet adopted agile development and released a new version of the trojan on a weekly basis. In addition, an
Obfuscator-LLVM compiler was used to obfuscate the main binary. The frequent changes to Emotet thanks to thesource-code level obfuscation raised the cost of analysing new versions and made it impossible to extract configuration
statically from the binary. Given that Emotet has become so difficult to analyse, we will share some tips on extracting
configuration.
Take a look at the following decompilation of the code snippet where the C2s are set. Each C2 endpoint is computed
dynamically from a separate function.

Figure 32: An example of Emotet version 6 setup endpoint configuration in the Decompile view in IDA Pro.

VIRUS BULLETIN CONFERENCE OCTOBER 2023

15

TEASING THE SECRETS FROM THREAT ACTORS: MALWARE CONFIGURATION EXTRACTORS LIM & WU

Figure 33: There are pieces of junk code within each function and none of the functions are identical. This causes a big
problem for decrypting the payload statically.
This is where the emulation framework came into play. An emulation engine emulates CPU instructions without actually
executing them. This is what we used to compute the returned value of each function. There are choices for the tools we
could use, such as Qiling [13] and Unicorn [4]. We used Unicorn, but they would both work.
First, we had to locate the function to be emulated. This was not too difficult if we flipped to the Assembly view in IDA Pro
as we saw repeated and consecutive instructions that stored the function pointer. These function pointers were later invoked
to decrypt the actual C&C server.

Figure 34: The code block that set the function pointers that decrypted C2s in the configuration setup function in an Emotet
v6 binary.

16

VIRUS BULLETIN CONFERENCE OCTOBER 2023

TEASING THE SECRETS FROM THREAT ACTORS: MALWARE CONFIGURATION EXTRACTORS LIM & WU

Figure 35: Preparing the stack and the code to be executed by the emulator.

Figure 36: The deobfuscated C2 IP address was saved in register ECX, and the port was saved in EDX respectively. We
have to allocate the memory for the emulator to write the output.

Figure 37: Once every argument is ready, launch the emulator. This will get you a list of IPs and ports from the emulation
results.

4.3 Summary
Emotet has always offered a good exercise for tracking botnets, from a technical perspective. We have shown that it storedconfiguration in plaintext in version 5 and then suddenly changed to a configuration format that is impossible to extract
without a CPU emulator. There were further challenges in identifying the customized protocol compression and the tricks
threat actors used to filter out emulated communication.

5. STUMBLE UPON A NEW SPECIES: WARZONE RAT STEALER
It would take a lot of effort to distinguish WarZone RAT from its close association with AveMaria, since the builder has
been leaked several times. We will focus instead on how to extract the configuration from two WarZone RAT variants.
The first variant has existed in the wild for years. The second variant was found when we were developing theconfiguration extractor for the first one. This is another example of where a configuration extractor can add intelligencevalue, especially for security product companies that have billions of samples being analysed every day.

5.1 The first species – sample used RC4
WarZone RAT stored a lot of unprotected strings in the payload itself. Once we had unpacked the real payload, we wereable to identify the malware easily.

VIRUS BULLETIN CONFERENCE OCTOBER 2023

17

TEASING THE SECRETS FROM THREAT ACTORS: MALWARE CONFIGURATION EXTRACTORS LIM & WU

Figure 38: Example of a generic YARA rule to identify the first variant of the family.
WarZone RAT was developed in C++, which made reverse engineering a bit harder. A small trick here is to press
SHIFT+F12 to list all the strings from the sample and find the code referencing ‘.bss’. This function reads in the encrypted
data at the beginning of the .bss section, decrypts it, and sets up the configuration. More of the in-depth analysis can befound in [14].

Figure 39: A decompiled view of a function that reads in binary from the .bss section in WarZone RAT.
The format of the encrypted configuration of WarZone RAT is demonstrated in C code in Figure 40. It starts with an
unsigned INT that gives out the size of the key. With the size of the key, we were able to read the full content of theciphertext. The encrypted payload was stored right after the key with a size of 0x40 bytes.

Figure 40: The structure of encrypted resources in WarZone RAT in C code.
Having located the configuration, now we have to figure out what protection has been used by the malware. With the helpof IDA Pro decompiled code and additional knowledge of common cryptography algorithms, we were able to identify theencryption routine as a standard RC4 [15] implementation. There was a symbolic for-loop to initialize the session key arrayand swap elements in the array based on the key. This procedure is called the key-scheduling algorithm (KSA). After thesession key is initialized, a pseudo-random number generator (PRNG) is used to encrypt the plaintext.

Figure 41: The common decompiled structure seen in RC4 implementation from IDA Pro when the source code was not
optimized.

18

VIRUS BULLETIN CONFERENCE OCTOBER 2023

TEASING THE SECRETS FROM THREAT ACTORS: MALWARE CONFIGURATION EXTRACTORS LIM & WU

Once the cryptographic algorithm was identified, we had to locate the ciphertext. PEfile provided us with a handy interface
to get the payload from the .bss section. One important thing we checked was that the input file should be in disk format.

Figure 42: The code snippet that reads in data in the .bss section by PEfile.

5.2 The second species – RC4+
While we had a WarZone RAT configuration extractor in the RC4 decryption scheme implementation, we noticed there
were still many configurations that were not correctly extracted. Diving deep into the sample, we found that there was avariant encrypted in a customized RC4+ encryption scheme. Malware authors usually try to implement either customized
or not-so-well-known encryption algorithms. There are different approaches to identify the algorithm. A fun approach was
to try our luck on every encoding and encryption algorithm in CyberChef [16]. In this case, we learned it might be amember of the RC4 family because it looked similar to RC4 from the decompiled code. We identified that the algorithm
was a variant of RC4+ by looking through every variant of RC4 on the RC4 Wikipedia page.

Figure 43: Screenshot of the variant implemented decryption based on a customized RC4+. There is one additional XOR
0xAA added to the standard RC4+.

Figure 44: Screenshot of a Python implementation for the PRNG routine of the WarZone RAT Plus customized RC4+.

5.3 Summary
Here we have shared how we discovered the second variant of the WarZone RAT using a configuration extractor.
Implementing a configuration extractor is useful for tracking malware updates. It usually breaks the extractor when there isa new update found in the wild.

VIRUS BULLETIN CONFERENCE OCTOBER 2023

19

TEASING THE SECRETS FROM THREAT ACTORS: MALWARE CONFIGURATION EXTRACTORS LIM & WU

6. MSIL – MALWARE’S MICROSOFT INTERMEDIATE LANGUAGE: REDLINE STEALER
So far throughout this article we have been discussing configuration extractors for native PE files. Now is a good time tointroduce the first configuration extractor for MSIL executables. The case study we will look at is RedLine stealer9 – itis straightforward, but a different approach is needed. The RedLine payload was packed in an executable. We can either
unpack it manually or dump the process memory when executing the malware. The RedLine stealer payload itself wasan MSIL executable10, which can be found on VirusTotal.
Just like writing configuration extractors for every other family, the first step is to identify the sample. To do this, wechose to match the code that RedLine stealer uses to check if the victim is located in a post-Soviet state.

Figure 45: Decompiled code snippet of blocklisted countries in which RedLine will not execute.
The YARA rule shown in Figure 46 is shared as an example that can be used to identify the malware family. Note that theconfiguration extractor is running against in-memory payloads. We would avoid checking PE headers (like uint16be(0)== 0x4d5a or pe.is_pe) as PE headers might be wiped for detection evasion.

Figure 46: Example YARA rule to identify RedLine stealer.
Once the family is identified, we have to analyse the sample manually and identify where the configuration is. The sample
we had was not name-stripped or obfuscated, and we were able to quickly navigate through each class and discover that theconfiguration was located inside the class called ‘Arguments’.
Figure 47 is a screenshot from dnSpy showing the encrypted RedLine configuration block.
The configuration seems to be encrypted, so now we have to locate the decryption function. Our preferred approach isalways to decrypt the ciphertext using an analyser written in a language we are familiar with. To do this in the dnSpy tool,right-click on the IP field and click analyse. By going through the result, we were able to find the code snippet that is trying
to decrypt and parse the configuration.
9

The sample we are using for this demo is SHA256 a4cf69f849e9ea0ab4eba1cdc1ef2a973591bc7bb55901fdbceb412fb1147ef9
RedLine stealer payload: SHA256 8b2ee4656bc26913c5a85415e8638a9eb8e3f63d352911eae73faeaea009b49f

10

20

VIRUS BULLETIN CONFERENCE OCTOBER 2023

TEASING THE SECRETS FROM THREAT ACTORS: MALWARE CONFIGURATION EXTRACTORS LIM & WU

Figure 47: Screenshot from dnSpy showing the encrypted RedLine configuration block.

Figure 48: Arguments.IP is decrypted by the function StringDecrypt.Read with key as an argument.
Digging into StringDecrypt.Read(), we found a function that reads in two arguments. The first argument comes with a
Base64-encoded string as the ciphertext, and it is followed by a string that is used as the key. The function checks whether
the ciphertext b64 is empty (null or a white space, ‘ ’) and if it is not, the ciphertext is decoded from Base64 and decrypted.

Figure 49: The decryption function used in RedLine stealer.

VIRUS BULLETIN CONFERENCE OCTOBER 2023

21

TEASING THE SECRETS FROM THREAT ACTORS: MALWARE CONFIGURATION EXTRACTORS LIM & WU

Figure 50: The decryption function is straightforward. It is an XOR cipher.

Figure 51: The equivalent code in Python can be implemented as this. Feel free to manually grab example ciphertexts andkeys to test if it decrypts correctly.
Next, we locate the configuration and prepare the decrypt function in Python.
For now, we still have to grab the ciphertext and key manually from the decompiled result of dnSpy. The next step is toobtain them automatically. When we are writing C code, we access the memory directly, so we sometimes refer to native
executables. However, in .NET MSIL, everything is managed. We have a pointer that points to the char array that isstored somewhere in the binary in native C code, but all we see in compiled MSIL are tokens. When these tokens areaccessed, the runtime library (CLR) parses out where the token is actually stored and the user does not have to worry
about it.

Figure 52: The comments generated by dnSpy showed that the string IP is a token number, 0x04000013.
Figure 53 shows the result of opening the sample in IDA Pro and navigating to the same function. We see the ldstr [17]command push several metadata strings onto the stack (tokens are enclosed by red rectangles) and the tokens (enclosed bypurple rectangles) are assigned to corresponding fields by stsfld [18]. Both of the strings and fields are referenced as
tokens.

22

VIRUS BULLETIN CONFERENCE OCTOBER 2023

TEASING THE SECRETS FROM THREAT ACTORS: MALWARE CONFIGURATION EXTRACTORS LIM & WU

Figure 53: Result of sample being opened in IDA Pro and navigating to the same function.
The .NET framework added an additional mechanism for storing and referencing its token. One additional data directory
can be found from the PE header. It points to the CLR (also known as Cor20) header. You will get several stream tablesfrom referencing the metadata header, where you will find the mdToken stored.

Figure 54: .NET-specific structures and the data they hold.
As shown in Figure 55, the IP field, as well as other fields belonging to the Arguments class, are stored in the metadata
stream (#~). These fields are set by stsfld commands. Once you click on the token of the IP field, dnSpy shows the
structure of how the token can be indexed.
Though we have located the IP field, it is still not enough to extract the configuration statically. The source of the string thatwas pushed onto the stack has not yet been figured out. The operand type of the instruction ldstr is a string token
according to [19]. The string tokens are stored in the #US (User-Stream) table.

VIRUS BULLETIN CONFERENCE OCTOBER 2023

23

TEASING THE SECRETS FROM THREAT ACTORS: MALWARE CONFIGURATION EXTRACTORS LIM & WU

Figure 55: The IP field, as well as other fields belonging to the Arguments class, are stored in the metadata stream (#~).

Figure 56: The documentation of ldstr command usage.
There is a useful open-source library called dnfile [20], which is like the .NET version of PEfile [21]. The tool allows us toeasily access the #US tokens [22] just by giving the RID. It also provides an interface to access the user streams and a lot
more [23].

Figure 57: An example implementation using dnfile to get the resource of a given .NET MSIL token.
We used a YARA rule to locate the code snippet where configuration is set up in Figure 53. Then, you can choose yourfavourite way to parse the 32-bit unsigned integer from the matched code and apply the mask (0xFFFFFF) on the token
RID. For example, the first five bytes from the matched YARA rule are 72 11 09 00 70.
opcode0x72

Token RID

11 09 00 70 = 0x70009011

Table 2: The opcode and token RID for the command ldstr.

24

VIRUS BULLETIN CONFERENCE OCTOBER 2023

TEASING THE SECRETS FROM THREAT ACTORS: MALWARE CONFIGURATION EXTRACTORS LIM & WU

Token RID & RID_MASK = 0x9011. This is the value you can pass to the function implemented above. It returns a Base64
string that is encrypted by the key.

Figure 58: The YARA rule to locate the code snippet that sets up the configuration.
This is it! We have a YARA rule to identify the family, then we manually analyse the sample to locate the configuration anddetermine how the main program reads it in. Later, we figure out there is a simple Base64 encoding plus XOR cipher forthe purpose of protection. Once we have everything drawn up, we use another YARA rule (or you can use a regex) to locate
the code snippet that contains the token referencing the key and ciphertext. Parse all of the data with the help of dnfile andfeed them to the decryptor. Boom, you got the configuration.

CONCLUSION
This paper has explored the crucial role of malware configuration extractors in uncovering the hidden secrets within the C2
configurations of various malware families. By delving into the methods used, we have shed light on the process oflocating and extracting C2 configurations from six different malware families.
Moreover, in a collaborative effort to contribute to the research community, we have taken the initiative to open-source thePython code and YARA rules that were utilized in our analysis process. We hope this collaborative approach will help theresearch community and cybersecurity practitioners in their preparation for the inevitable uphill battle against malware.
By leveraging the insights gained from analysing malware configurations, we can enhance our ability to detect, analyse anddevelop effective countermeasures against malicious software. Through continuous collaboration and knowledge sharing,
we can collectively stay ahead of cybercriminals and safeguard our digital systems and networks.

REFERENCES[1]

Wanve, U. GuLoader: Peering Into a Shellcode-based Downloader. Crowd Strike Blog. 25 June 2020.
https://www.crowdstrike.com/blog/guloader-malware-analysis/.

[2]

Rao, A.; Idrizovic, E.; Rokka Chhetri, S.; Jung, B.; Lim, M. Machine Learning Versus Memory Resident Evil. Unit
42 Palo Alto Networks. 31 January 2023. https://unit42.paloaltonetworks.com/malware-detection-accuracy/.

[3]Lim, M. Defeating Guloader Anti-Analysis Technique. Unit 42 Palo Alto Networks. 28 October 2022.
https://unit42.paloaltonetworks.com/guloader-variant-anti-analysis/.

[4]

Unicorn. https://www.unicorn-engine.org/.

[5]

https://twitter.com/Unit42_Intel/status/1588524735368937484?s=20&t=YXkHyDy_wX1vbbynVm9R6A.

[6]Lim, M.; Raygoza, D.; Jung, B. Teasing the Secrets From Threat Actors: Malware Configuration Parsing at Scale.
Unit 42 Palo Alto Networks. 3 May 2023. https://unit42.paloaltonetworks.com/teasing-secrets-malwareconfiguration-parsing.

[7]

https://twitter.com/Unit42_Intel/status/1657014096200343554.

VIRUS BULLETIN CONFERENCE OCTOBER 2023

25

TEASING THE SECRETS FROM THREAT ACTORS: MALWARE CONFIGURATION EXTRACTORS LIM & WU

[8]

Hammond, C.; Villadsen, O. Trickbot Group’s AnchorDNS Backdoor Upgrades to AnchorMail. Security
Intelligence. 25 February 2022. https://securityintelligence.com/posts/new-malware-trickbot-anchordns-backdoorupgrades-anchormail/.

[9]

Trend Micro. Exploring Emotet’s Activities. https://documents.trendmicro.com/assets/white_papers/
ExploringEmotetsActivities_Final.pdf.

[10]

Global Research & Analysis Team, Kaspersky Lab. Emotet modules and recent attacks. Secure List. 13 April 2022.
https://securelist.com/emotet-modules-and-recent-attacks/106290/.

[11]

Microsoft. CryptImportKey function (wincrypt.h). https://learn.microsoft.com/en-us/windows/win32/api/wincrypt/
nf-wincrypt-cryptimportkey.

[12]

Hey-rays. IDA Help: Xrefs. https://hex-rays.com/products/ida/support/idadoc/313.shtml.

[13]

Qiling Framework. https://qiling.io/.

[14]

Harakhavik, Y. Warzone: Behind the Enemy Lines. Check Point Research. 3 February 2020.
https://research.checkpoint.com/2020/warzone-behind-the-enemy-lines/.

[15]

Wikipedia. RC4. https://en.wikipedia.org/wiki/RC4.

[16]

CyberChef. https://github.com/gchq/CyberChef.

[17]

Microsoft. OpCodes.Ldstr Field. https://learn.microsoft.com/en-us/dotnet/api/system.reflection.emit.opcodes.
ldstr?view=net-7.0[18]

Microsoft. OpCodes.Stsfld Field. https://learn.microsoft.com/en-us/dotnet/api/system.reflection.emit.opcodes.
stsfld?view=net-8.0.

[19]

Dnfile. https://github.com/malwarefrank/dnfile.

[20]

Pefile. https://github.com/erocarrera/pefile.

[21]

Dnstrings.py. https://github.com/malwarefrank/dnfile/blob/master/examples/dnstrings.py#L10.

[22]

Stream.py. https://github.com/malwarefrank/dnfile/blob/master/src/dnfile/stream.py#L59.

INDICATORS OF COMPROMISE (IOCS)
Samples
SHA-256

Malware Family

BFA5DBA46DB1253587058B0392C04C8403846FA55D7DCF1044E94E6A654D4715

Guloader32ea41ff050f09d0b92967588a131e0a170cb46baf7ee58d03277d09336f89d9
beda408709feea7d2023f328e9c97bf4d090bcfb3948fc4e4d9c5c580d8f5858å

Guloader
Guloader6df2ece892c9192c90d4d9fdec768beb17aecfb17d44adc69a11cb50721fa68e

IcedID

f85d883717d113fcf20afab161470ef2911c729d4d6b04382da0de746b53f0f2

IcedID2153be5c6f73f4816d90809febf4122a7b065cbfddaa4e2bf5935277341af34c

Trickbot

0374BB627E51AA5FA5DF0640A5468939CF190A1A1BC0C8A0F3DF4BC9B3E92171

Trickbot

52901478b6fb8c1ae7803997708648eaff9e32a93d017fd6945464fb41f3f9a1

Trickbotaea7a35212e49f49012cdfffd1439eb1ad9e6e761345b17ebcfbc5a8dd9dd7a5

WarZone RAT

67e04fe16e647e86b2226bae73b17349dfc8c4e8c9521e6caf08557714c2326e

WarZone RAT

a4cf69f849e9ea0ab4eba1cdc1ef2a973591bc7bb55901fdbceb412fb1147ef9

RedLine Stealer

8b2ee4656bc26913c5a85415e8638a9eb8e3f63d352911eae73faeaea009b49f

RedLine Stealer

1a18fcac97501f8482f6d8cfa22c124524b49b11f4b133ce2de51b9196798665

Emotet Version 5808e8247efd685bdbae3ea0e55de1e8ed8aecd1359a213b0c6291b73f007fdaf

Emotet Version 6

Network Indicators
Guloaderhttps://drive.google[.]com/uc?export=download&id=1THD-itP7iOm05w_6SQSb-C3tgd3cLMzO
https://gemelw[.]tk/bbb/nhttps://blog.nacex[.]es/wp-content/plugins/DRCOOOL/JtPpWnyvrb11.bin

26

VIRUS BULLETIN CONFERENCE OCTOBER 2023

TEASING THE SECRETS FROM THREAT ACTORS: MALWARE CONFIGURATION EXTRACTORS LIM & WU

IcedID
Campaign ID = 10663848
C2 url = nedgogolinh.com
Bot ID = 4049493703 URI = /news/
C2 URLs =treylercompandium[.]com
gabrikxuira[.]com
Trickbot<mcconf><ver>1000158</ver><gtag>ser0328</gtag><servs><srv>109.95.113.130:449</srv><srv>87.101.70.109:449</
srv><srv>31.134.60.181:449</srv><srv>85.28.129.209:449</srv><srv>82.214.141.134:449</
srv><srv>81.227.0.215:449</srv><srv>31.172.177.90:449</srv><srv>185.55.64.47:449</srv><srv>78.155.199.225:443</
srv><srv>92.63.103.193:443</srv><srv>85.143.175.248:443</srv><srv>185.159.129.31:443</
srv><srv>194.87.237.178:443</srv><srv>195.123.216.12:443</srv><srv>54.38.56.154:443</
srv><srv>82.146.60.85:443</srv><srv>185.228.232.139:443</srv></servs><autorun><module name=”systeminfo”
ctl=”GetSystemInfo”/><module name=”injectDll”/></autorun></mcconf>{‘bot_ver’: ‘100015’, ‘gtag’: ‘mon169’, ‘autorun’: ‘pwgrab’, ‘c2_list’: [‘67.48.36.18:449’, ‘46.254.128.174:449’,’41.216.166.142:449’, ‘181.143.251.154:449’, ‘77.232.163.203:449’, ‘87.97.178.
92:449’,’185.94.172.15:449’, ‘185.230.5.43:443’, ‘91.243.125.5:443’, ‘185.242.168.118:443’,‘201.23.76.18:443’, ‘180.178.109.222:443’,‘202.131.227.229:443’, ‘163.53.83.117:443’, ‘45.235.5.162:443’, ‘185.189.55.207:449’,‘103.36.48.159:449’,‘168.253.208.234:449’, ‘41.60.233.170:449’, ‘170.79.181.188:449’, ‘177.101.15.65:449’,‘194.156.81.206:443’,‘103.66.72.217:443’, ‘113.161.174.240:443’, ‘185.164.41.190:443’, ‘181.112.188.78:443’,‘103.82.146.212:443’, ‘186.183.184.218:443’, ‘78.158.171.245:443’]}[‘batman@naxzs.com|Asdqwe123!!!|box.naxzs.com:993*|box.naxzs.com:465*’, ‘aquaman@naxzs.com|Asdqwe123!!!|box.
naxzs.com:993*|box.naxzs.com:465*’, b’joker@naxzs.com’]

WarZone RAT
rajsavindia.hopto[.]org:5067
192.3.111[.]154:5200

RedLine Stealer
37.220.87[.]13:40676

Emotet Version 5
173.73.87.96:80
71.222.233.135:443
60.250.78.22:443
80.86.91.91:8080
104.236.28.47:8080
162.241.92.219:8080
74.208.45.104:8080
178.20.74.212:80
85.105.205.77:8080
190.220.19.82:443
78.24.219.147:8080
47.26.155.17:80
110.44.113.2:80
113.52.123.226:7080
120.151.135.224:80

VIRUS BULLETIN CONFERENCE OCTOBER 2023

27

TEASING THE SECRETS FROM THREAT ACTORS: MALWARE CONFIGURATION EXTRACTORS LIM & WU

108.191.2.72:80
70.127.155.33:80
98.156.206.153:80
47.6.15.79:443
104.131.44.150:8080
60.231.217.199:8080
70.184.9.39:8080
223.197.185.60:80
121.88.5.176:443
211.192.153.224:80
5.196.74.210:8080
70.187.114.147:80
190.143.39.231:80
24.164.79.147:8080
110.36.217.66:8080
24.94.237.248:80
47.156.70.145:80
125.207.127.86:80
108.6.140.26:80
173.24.68.195:80
105.27.155.182:80
189.212.199.126:443
47.153.183.211:80
75.114.235.105:80
160.16.215.66:8080
190.55.181.54:443
95.128.43.213:8080
190.146.205.227:8080
101.187.197.33:443
174.53.195.88:80
190.114.244.182:443
31.172.240.91:8080
100.6.23.40:80
76.104.80.47:443
103.86.49.11:8080
200.21.90.5:443
104.236.246.93:8080
139.130.242.43:80
181.126.70.117:80
188.0.135.237:80
217.160.182.191:8080
181.13.24.82:80
87.106.139.101:8080
205.185.117.108:8080
210.6.85.121:80
78.189.180.107:80
202.175.121.202:8090
88.249.120.205:80
209.141.54.221:8080
182.176.132.213:8090
136.243.205.112:7080
173.21.26.90:80
62.138.26.28:8080
209.97.168.52:8080

28

VIRUS BULLETIN CONFERENCE OCTOBER 2023

TEASING THE SECRETS FROM THREAT ACTORS: MALWARE CONFIGURATION EXTRACTORS LIM & WU

207.177.72.129:8080
41.60.200.34:80
211.63.71.72:8080
178.153.176.124:80
90.69.145.210:8080
152.168.248.128:443
85.152.174.56:80
47.155.214.239:443
31.31.77.83:443
139.130.241.252:443
115.65.111.148:443
37.187.72.193:8080
190.12.119.180:443
190.117.126.169:80
46.105.131.87:80
101.100.137.135:80
87.106.136.232:8080
201.184.105.242:443
201.173.217.124:443
177.239.160.121:80
74.108.124.180:80
218.255.173.106:80
24.105.202.216:443
76.104.80.47:80
173.16.62.227:80
195.244.215.206:80
45.55.65.123:8080
47.6.15.79:80
65.184.222.119:80
37.139.21.175:8080
46.105.131.69:443
101.187.134.207:8080
200.116.145.225:443
149.202.153.252:8080
108.190.109.107:80
78.142.114.69:80
179.13.185.19:80
222.144.13.169:80
66.34.201.20:7080
176.9.43.37:8080
45.33.49.124:443
186.6.245.26:443
93.147.141.5:443
78.186.5.109:443
47.155.214.239:80
62.75.187.192:8080
101.187.237.217:80
68.114.229.171:80
209.146.22.34:443
62.75.141.82:80
78.101.70.199:443
95.213.236.64:8080
91.205.215.66:443
76.86.17.1:80

VIRUS BULLETIN CONFERENCE OCTOBER 2023

29

TEASING THE SECRETS FROM THREAT ACTORS: MALWARE CONFIGURATION EXTRACTORS LIM & WU

181.143.126.170:80
5.32.55.214:80
60.142.249.243:80
70.180.35.211:80

Emotet Version 6
51.178.61.60:443
168.197.250.14:80
45.79.33.48:8080
196.44.98.190:8080
177.72.80.14:7080
51.210.242.234:8080
185.148.169.10:8080
142.4.219.173:8080
78.47.204.80:443
78.46.73.125:443
37.44.244.177:8080
37.59.209.141:8080
191.252.103.16:80
54.38.242.185:443
85.214.67.203:8080
54.37.228.122:443
207.148.81.119:8080
195.77.239.39:8080
66.42.57.149:443
195.154.146.35:443

30

VIRUS BULLETIN CONFERENCE OCTOBER 2023