👜

Malware Delivery (Part 2)

In the previous post, we’ve talked about how 1st stage loaders which are typically in the form on a word document or a PDF file.
These 1st stage loaders would execute commands to download the 2nd stage loaders, which may come in a packed or unpacked form.
This post follows what happens after unpacking of the 2nd stage loader.
2nd stage loaders may either unpack to a binary that downloads the final malware, or the final malware itself.
In the case of unpacking to a downloader, the unpacked binary may contain configuration files that has a list of URLs to download the final malware from, or contain keys for decryption of the downloaded final malware.

Analyzing 2nd stage loaders

We may follow these steps to deal with a 2nd stage loader
notion image
  1. We first determine if the 2nd stage loader is packed or not
  1. Perform static/dynamic analysis of the loader to locate any config files or keys for decryption
  1. Extract the configuration files
  1. Develop a comms emulator so that the stager does not communicate directly to the C2 server

IceID Loader Analysis

IceID is a packed loader
We set breakpoints on VirtualAlloc, VirtualProtect and isDebuggerPresent
There are multiple calls to VirtualAlloc, which is the malware allocating memory to write the malware program into. We see the compressed executable in Dump 3
The compressed executable is seen in Dump3. This will likely be written out to the memory space that was reserved by VirtualAlloc
The compressed executable is seen in Dump3. This will likely be written out to the memory space that was reserved by VirtualAlloc
Stepping through the program more, we see that the executable has been decompressed
notion image
At this stage, we can dump out the decompressed executable for analysis by selecting the memory region and Save to File
notion image
Opening the dumped program in PE Bear, we need to fix the Raw Addresses and Raw Size
notion image
Opening the dumped program in IDA, it calls a single function before exiting. That’s likely the function we need to step through to see what the 2nd stage loader is doing.
notion image
It creates a file photo.png, possibly writing the payload contents to it
notion image
It also checks if the file already exists. If it does, it will execute the file directly. If not, it will attempt to download the payload from the C2
notion image
notion image
The loader then checks if the file starts with IDAT, which is a body identifier for PNG files, before calling rc4 decrypt. We can speculate that the loader checks if the photo.png has a valid photo header, and the payload is rc4 encrypted in the body, even though it’s not a valid image
notion image
notion image
The loader also performs some a tick-count anti-analysis technique, which checks the time taken for the binary to run. If the binary is being debugged, chances are the tick count will be much longer as manually stepping through the code is much slower than a machine executing it.
notion image
The information is then used to create parameter values to the string photo.png?id=
notion image
On line 24, we see the check if sub40164B(a2) is equals to 200, which could possibly be a HTTP return status code OK. Stepping into the function, we indeed see it’s creating a HTTP connection and sending a GET request, and it’s checking if the C2 server is alive.
notion image

Dynamic Analysis

We want to run the program to see the values of the keys or C2 address being decrypted in memory
notion image
By stepping over the RC4 decryption function, we see the configuration strings being decrypted in memory
notion image
Stepping further down in the binary, we see the full URL string being constructed
notion image

Conclusion

At this stage, we’ve seen how the 1st stage loader is sent in the form of a word document or PDF.
The 1st stage loader then downloads a 2nd stage loader through executing shell code or exploiting a userland reader program like Adobe or Office.
The 2nd stage loader, in this example, dynamically decrypts the C2 server program which we can dump out. That in turn dynamically decrypts the C2 information like the URLs to connect to.