When we come across a persistent foothold, it’s often just the tip of the iceberg. The Huntress SOC team flagged a user Run Key value with the name “xmNusBQH4865,” which in and of itself was suspicious. The command executed was equally suspect:
regsvr32.exe /s C:\ProgramData\xmNusBQH4865.dll
As for the DLL payload, we cross-referenced its hash in VirusTotal and discovered it hadn’t been seen before:
Considering these three anomalies, it was pretty easy to conclude that this was a malicious foothold.
When we hunt for footholds, our partners depend on us to provide detailed remediation recommendations—which include a high-level summary about the threat, the risk it poses and step-by-step instructions to remove the infection. This is where our ThreatOps team steps in with deeper forensic analysis.
For this particular malware, we started inspecting the basics: file properties, strings and imports. Although the file properties provided no additional insight, the strings/imports suggested this DLL was some sort of loader:
- Allocates memory
- Loads a library
- Resolves a function’s address
- Declares victory?
A call graph shows the DLL doesn’t do very much:
High-level call graph overview
At this point, we decided to dynamically analyze the payload in an isolated VM. Using a trick we picked up from the great Practical Malware Analysis book, we converted the DLL to an executable to make it a bit easier to work with. This was done with a hex editor by setting the IMAGE_FILE_DLL flag in the IMAGE_FILE_HEADER to 0 and renaming the file with an .exe extension.
Next, we fired up ProcMon, set our filters on the file name, launched the new executable and waited to see what actions were performed:
Based on this quick analysis, it looked like the DLL loaded WinSock and tried to connect to the IP address 91.234.34.44 on port 30970. A quick Google search revealed this IP address was previously affiliated with Troj/Agent-AOZZ and the Vawtrak banking trojan.
Considering the similarities to Vawtrak’s persistence mechanism—which also used a Run Key value to call regsvr32.exe and load a randomly named DLL from C:\ProgramData—it’s extremely likely this was our culprit.
At this point, we had more than enough information to notify our partner about the incident, educate them on the risks posed and provide instructions on how to remove the foothold.
But Where’s That Connection Coming From?
From time to time, curiosity gets the better of us. In this case, we wondered, “where was the code that made that network connection?” After notifying our partners of the infection, we jumped back to the disassembler.
The last instruction in the disassembly is a “call EBX”. The malware must decode a payload and call it from that register (a great place for the network communication code to hide).
We pulled WinDbg out of the toolbox to see if we could find what was at EBX when it’s called. We loaded the file, searched for the opcode FFD3 (call ebx), and set the breakpoint at that address. Now it was time to execute!
As soon as the breakpoint was hit, we viewed EBX in a memory window:
And there was our decoded payload. Sure enough, we saw WinSock functions and the IP address the malware tried to connect to.
Case Closed?
Like most things in IT, diving deeper into a problem allows you to gain a better understanding of what you’re up against. In this case, we went from a potentially suspicious event to a step-by-step remediation recommendation.
However, most businesses can’t afford to staff Security Operation Centers with forensic experts like the Huntress ThreatOps team. In the world of cybersecurity, things move quickly—and our team is actively growing to ensure we can meet the needs of our partners and their customers.
If you enjoy cybersecurity and problem-solving as much as we do, you can join our team! We’re always on the hunt for threat analysts with solid IT skills. Check out our open positions.
