Malware Disguised as a "Coding Challenge"
The Setup & The Hook
A friend of mine received a suspicious email recently and reached out to me to see if I wanted to investigate a potential phishing attempt.
Let's Download the File
Contents of Python_Developer_Job_Description.zip, which was hosted via Dropbox:
The PDF described the "coding challenge" and had the password for CodingChallenge.rar:
A password-protected .rar file is pretty suspicious. Felt like there must be something malicious here...
The Payload
It did in fact contain a coding challenge, which used tkinter for the GUI. But it included the entire tkinter library within the rar which was strange.
Instead of combing through the source I just spun up a sandboxed vm and tried running it to see what it would do (probably not the best idea). I had to fix some hard-coded Windows-specific "\" characters in a bunch of file paths (never a good sign 🚩), but eventually got this error message:
...I don't think tkinter includes a windows PE called config.exe 👽
Static Analysis of Config.exe
A quick exiftool analysis shows that it's a 32-bit PE.
DesktopOK is interesting, and there's a version number too: 11.1.8
After some googling it looks like this is a real piece of software: https://www.softwareok.com/?seite=Freeware/DesktopOK
I found an installer for v11.18 floating around, and ran a diff on config.exe vs. DesktopOK_v11.18.exe. Upon diffing them I found out that they were very similar!
There weren't very many different sections of bytes, so I inspected them in more detail with Binary Ninja and made notes on each:
| Diff Start | Size | Note |
|---|---|---|
0x400150 |
3 bytes | modified checksum value in PE32_Optional_Hedear |
0x400194 |
2 bytes | decreased the size of certificateTableEntry |
0x42f01e |
1393 bytes | functions between blocks of encrypted bytes? |
0x43a1c9 |
13372 bytes | more functions between blocks of encrypted bytes? |
0x449fa5 |
4 bytes | maybe redirecting execution flow here? |
0x453d2c |
88 bytes | looks like an encrypted chunk |
0x4546e9 |
15 bytes | VirtualProtect string added here |
0x454804 |
12 bytes | deleted H:mm:ss for \x00 dddd |
0x4a17b8 |
62 bytes | random bytes in a zeroed out section? |
0x4d9000 |
9560 bytes | overwrote the cert with evil cert to sign the EXE |
Static analysis didn't get me much further. Time to spin up a Windows sandbox and see what it does.
Dynamic Analysis
Debugging with x64dbg revealed that it decrypts two URLs and attempts to fetch an image file, then place it in C:\Users\User\AppData\Local\Temp with a random file name.
https://iili.io/JweFMYP.png
The image it fetches looks strange...maybe it uses the pixel data to build a malicious binary or shell code?
After letting the EXE run with ProcessHacker spying in the background, I noticed it spawns netsh.exe, which then drops a second smaller file in C:\Users\User\AppData\Local\Temp with another random file name.
I examined both files in a hex editor and noticed that the second file has a similar structure to a portion of the pixels in the PNG image. After further examination and some trial-and-error, I figured out how it generates the second file
-
Converts the PNG pixel color data to binary data by converting each pixel's R, G, and B values into three bytes, one after the other from left to right and top to bottom.
-
Cuts a portion of the resulting bytes, from
0x1d7c96to0x2d0f50 -
Applies an XOR repeating 4-byte key of
b5 bf 2f b2to the bytes, and writes to the second file.
Next Steps
I haven't been able to figure out what it does with this second file yet. I've run config.exe through a few sandboxes (including my own Cuckoo sandbox locally), which have given me some hints, but I have a hunch that config.exe employs some evasion which is why I haven't observed malicious behaviour yet.
Links to the sandbox runs:
The VirusTotal scan is especially interesting, because Zenbox noticed a third dropped file that none of the other sandboxes recorded! That file was also submitted to VirusTotal, and identified as probably being a version of Lumma Stealer malware: VirusTotal scan for third dropped file
In one of the Zenbox screenshots for this third file, there is a dialog that seems to match a specific dialog that LummaC2 Stealer displays when executed in its unpacked form (for instance, if a cryptor wasn't used; I found this out from googling the dialog's message). Apparently, the malware developer introduced this dialog box warning to make sure the unpacked LummaC2 binary never gets leaked. I wish I had access to this file that Zenbox recorded, because it's possible that it is an unobfuscated version of the LummaC2 binary:
more soon