Deep Dive: Investigating a Foothold & Uncovering the Payload
Recently, we 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 this was a malicious foothold. However, our partners depend on 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 the Huntress ThreatOps team steps in with with deeper forensic analysis :)
For this 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:
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 partners 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, 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 op code FFD3 (call ebx), and set the break point at that address. Now it was time to execute!
As soon as the break point was hit, we viewed EBX in a memory window:
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. To address this issue, we developed a brand new layer of detection (focusing on hacker footholds) and deliver this highly automated service for a fraction of the cost of in-house experts. This enables our partners to discover endpoint breaches and quickly move from compromise to containment.
Enjoy security and problem solving as much as we do but new to the field? Come learn from an experienced team in a friendly environment! We’re on the hunt for aspiring enthusiasts with solid IT skills to join our team. Check out the details in the image below and email careers@huntresslabs.com with your resume to apply.
