It’s rare these days that actual phishing malware makes it past commercial filters. And yet, earlier this week, a gift landed in my inbox. Actual, factual malware, sent right to my doorstep. I’ll admit that the first feeling I had was not shock or anger, but gratitude.
Because every malware sample is an opportunity to share. Now you, my dear Ifinians (still workshopping that one), get to come along on this journey. But first, the IOCs. I’m not selling you anything so I can just put these up top and let you decide whether you want to read the narrative.
DISCLOSURE: An LLM assisted in the decryption of these artifacts. Each stage and IOC has been manually verified and is reproducible.
IOCs
| Value | Type | Description |
|---|---|---|
632fedf848845f2eea63687d0ed01742163849d492fa9700d156729966a73fbd |
SHA256 | Initial zip file |
mggsjvip[.]com |
Domain | Download site |
AuroraLeslie16081959pg@outlook[.]com |
Sender | |
860f3e7c6633f5e83a812ea0626cb5362df641a720ef50d490dedad883642ea3 |
SHA256 | First stage executable |
digital-document.exe |
Filename | First stage executable |
91130281MAET3CD19W1 |
Certificate Serial | Authenticode certificate serial number |
de9f9f9a53fe1c1df5e229b2105cc84f9adb409ecc618f7a0ef9cf9fd7501118 |
SHA256 | First-stage encoded DLL |
D:\\CFILES\\Projects\\WinSSL |
String | Path to custom WinSSL build in loader |
Config.db |
Filename | First-stage encoded DLL |
C:\Windows\System32\TimeBrokerClient.dll |
Filename | Dropped malicious version of legit DLL |
C:\Windows\System32\BrokerClientCallback.dll |
Filename | Renamed real version of TimeBrokerClient.dll |
765bcc811fccc1d69d92055b2ab65a04a938d077838e6b749d437c78f912a36c |
SHA256 | Hash of evil TimeBrokerClient.dll |
C:\Windows\System32\msvchost.dat |
Filename | 2nd stage dropped file |
556b96e5bf91c48445eeca4ece0f2ee4fff8db8a02cc0b1b47ff033583bcb92c |
SHA256 | Hash of msvchost.dat |
C:\Windows\System32\system.dat |
Filename | 2nd stage dropped file |
f0a1c2b4266fb9ca2d09609186e1c367076c96a7968091adc8505ac56819a9ca |
SHA256 | Hash of system.dat |
206.238.199[.]22:10086 |
IPv4 | C2 Destination:Port |
HKCU\SOFTWARE\HHClient |
Registry Key | Persistence Key set |
The Lure
A cool thing about being a malware researcher is that you get to disobey phishing awareness training. At least, in a safe environment.
First thing to do when receiving a phish is to review the email headers. Alas, with an Outlook sender (and a rather random-looking one, at that), I had little to go on. No discrepancies or spoofing popped out.
The email I received had a fake invoice and a domain to visit. With a lab machine setup, I fired away at the domain.
Nothing too interesting up front. The source code mostly showed placeholder comments in Chinese. Nothing particularly interesting here either. Vibe coded? Maybe. The one thing of note is that the comments mention a filename of swjk.zip, whereas the downloaded file was digital document.zip.
The Loader
The zip file itself container two files: digital document.exe and Config.db. It’s always interesting when an executable comes with a friend. Usually that is a DLL with all the juicy malicious behaviors, separate from the executable itself in an attempt to confound endpoint detection. However, when I looked at Config.db, I was suprised to find…UUIDs? Just a single-row CSV of like 11,000 UUIDv4s.
So that’s weird. More on that later.
The binary, it’s worth noting, was signed with Authenticode, with a cert from Certum. An extended validation cert, no less—don’t see those too often, and they require business entities to acquire. So there’s some organization behind this effort.
What do we do first when analyzing a binary? That’s right: strings! Very few readable strings, which itself is a bit of a tell that there’s not much to the binary itself, or that it’s encrypted in some way. What I did see was a reference to Config.db, so obviously there was some connection there, and also paths for what appears to be a custom build of WinSSL.
Another interesting tidbit from static analysis was the string The file is corrupted !, which was used in a MessageBox call. But that was by no means the end of the process, so it was a headfake for the user.
The “feel” of the binary was heavy obfuscation, so I looked for stack-assembled strings. Looking for mov word and mov dword patterns, I was able to find several useful strings related to listed IoCs. Additionally, a set of AV products (Norton/Kaspersky/Avast) were present to evade detection. Injection targets of winlogon.exe and TrustedInstaller.exe were also present.
I was also able to find what were almost certainly an AES key/IV pair. So we’re decrypting something, just not sure what yet. Weird that these were not stack-assembled as well, but I’ll take it!
The binary took advantage of Control Flow Flattening, making it extremely difficult to trace. I knew there had to be a decryption mechanism in here somewhere, but not an easily-followed one.
Dynamic Analysis
With so little to go on in the static analysis, I hopped over to dynamic analysis, where I confirmed the popup behavior, and then identified additional dropped files. TimeBrokerClient.dll, msvchost.dat, and system.dat were created in C:\Windows\System32. The original TimeBrokerClient.dll was renamed to BrokerClientCallback.dll. The two .dat files were encrypted, but it seemed likely they were DLLs.
When pulling artifacts from Velociraptor, I didn’t notice any common persistence mechanisms beyond those dropped files, nor any bizarre network activity from Sysmon data. Nevertheless, I grabbed the dropped files and now had some more filenames to search the web for.
Prior Work
That’s when I discovered winos 4.0 and HoldingHands. Despite being in English, and being sent to my email address, the malware sample I received was nearly (but not entirely) identical to this campaign tracked by Fortinet.
Eh? Look familiar? The prior work on this campaign is solid and I won’t rehash it here. But we still have some puzzles to solve.
Back to Config.db.
What was this thing? Based on the pattern I expect from winos 4.0, this should have been a DLL. But it was UUIDs. Granted, a lot of UUIDs. Originally I had hypothesized that this was a list of SMBIOS IDs for sandbox evasion, but that didn’t really make sense based on the number. But what if…the UUIDs were encoding shellcode somehow?
Yeah, turns out that’s a thing:
With a new hypothesis and some help from Claude on the decoding algorithm, I was able to use the previously-discovered AES key/IV to decode and decrypt Config.db into the DLL we expected. In fact, the result is the TimeBrokerClient.dll we saw dropped in C:\Windows\System32. What’s that about anyway?
TimeBrokerClient.dll
This is a real DLL, or at least it can be. It’s used by the Windows Task Scheduler Service. In fact, the first indicator on my lab machine that something had changed was a failure of Get-ScheduledTask when investigating persistence. Straight-up error. Whatever they’re trying to do with the DLL, it didn’t quite work fluidly.
TimeBrokerClient.dll (evil edition) forwards legit function calls to the renamed TimeBrokerClient.dll (original recipe), which has been renamed BrokerClientCallback.dll. All entries in the Export Address Tables are just forwarders to that DLL.
But in DLLMain, we once again encounter the insanity of CFF. Because it’s funny, here’s a function graph of just that function, zoomed to fit my rather high-res screen:
So yeah, that sucks. Again with some Claude assistance, this mess was parsed and an encryption algorithm discovered. With the clue from Fortinet that svchost was the key for descrypting msvchost.dat, I was able to decrypt that file. This led to some fun strings.
Thanks for that. But also plainly visible inside the control flow, another key made of two parts:
With the key 5E4D3C2B1A in hand, the final DLL was decryptable. This is, as far as I can tell, the Holdinghands RAT. It even has an IP address for C2 that’s present in the Fortinet post!
Amazing to see reused infra. It’s unfortunately a residential IP space, which also gives us some solid hints on sourcing. Also the registry key listed above for persistence/marking infection. The rest follows the prior Fortinet research.
New Findings
The UUID encoding and encryption of the DLL appears to be new. But what’s even more interesting is that the same infrastructure is now being used to target non-Asian email addresses. This email was sent to my domain specifically. I’m sure it was part of a spray, because it was sent to a catchall address. Nevertheless, that suggests a more widespread campaign from this threat actor.
Recommendations
Definitely search for the file write of TimeBrokerClient.dll in your environment. That should be a very high-fidelity signal of this infection. The IP addresses, since they’re being used still, should be hunted for and blocked.
Some of these items have been profiled, but not all. We will be uploading these IoCs to VirusTotal as well. Happy hunting!