We may follow these steps to deal with a 2nd stage loader
We first determine if the 2nd stage loader is packed or not
Perform static/dynamic analysis of the loader to locate any config files or keys for decryption
Extract the configuration files
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
Stepping through the program more, we see that the executable has been decompressed
At this stage, we can dump out the decompressed executable for analysis by selecting the memory region and Save to File
Opening the dumped program in PE Bear, we need to fix the Raw Addresses and Raw Size
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.
It creates a file photo.png, possibly writing the payload contents to it
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
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
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.
The information is then used to create parameter values to the string photo.png?id=
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.
Dynamic Analysis
We want to run the program to see the values of the keys or C2 address being decrypted in memory
By stepping over the RC4 decryption function, we see the configuration strings being decrypted in memory
Stepping further down in the binary, we see the full URL string being constructed
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.