Malware analysis

Fileless Windows Error Reporting (WER) malware attack: Technical overview and walkthrough

In October 2020, a newly uncovered malware named Kraken was observed in the wild. This malicious piece of malware is abusing the Windows Error Reporting service to evade detection.

This article covers the principal details of the Kraken attack: how it works, in-depth details on how the shellcode is injected into the memory and some preventive measures to mitigate this kind of threat.

Become a certified reverse engineer!

Get live, hands-on malware analysis training from anywhere, and become a Certified Reverse Engineering Analyst.

Start Learning

From macro file to memory injection

Experts from Malwarebytes have identified a new attack chain named Kraken, a fileless injection into the Windows Error Reporting service.

The threat is probably disseminated via social engineering, and the malicious file is inside a ZIP file distributed along with the malicious email in the wild. The malicious file is a Word document dubbed “Compensation manual.doc” that contains fake content to lure the victims. The document pretends to include information about compensation rights for workers.

Figure 1: Word doc with the malicious content of the Kraken attack

Inside the malicious document, a modified version of CactusTorch (shellcode launcher) is available. In detail, the VBA module uses the DotNetToJscript technique to load a .NET-compiled binary into memory and execute it from VBScript.

By analyzing the macros hardcoded on it, we can observe two initial triggers: AutoOpen() and AutoClose() calls. The AutoOpen() just shows an error message, while AutoClose() is the function that performs the entire activity.

As observed in Figure 2, we can find a function that decodes the hardcoded payload from hexadecimal.

Figure 2: First stage of the Kraken attack.

By analyzing the code, we can understand that the hex payload is a .NET serialized object after decoding it. The serialized object contains a DLL called “kraken.dll” that is injected into the memory, using a technique known as DLL injection.

Looking at Figure 3 below, we can see some calls related to serialized objects and the beginning of the malicious DLL (MZ header).

Figure 3: Identification of serialization functions and the start of the malicious DLL — Kraken payload

Let’s analyze the malicious payload and find the name of the target DLL: Kraken.dll.

Figure 4: The name of the target DLL can be found by walking through the payload

During this task, the payload creates a serialization BinaryFormatter object and then uses the deserialize functions to “recover” the original payload deserialized. After that, the final DLL is built inside a MemoryStream object called stm and injected byte by byte. Finally, the entire DLL (a .NET object) is injected into the memory using the DynamicInvoke function.

Figure 5: Process of building the object injected into the memory via DynamicInvoke call and that contains the malicious DLL

Digging into the Kraken loader (Kraken.dll)

After running in memory, the Kraken.dll executes an embedded payload into the memory by using a handle from the WerFault.exe process. This is not the first time that shellcode is injected into the WerFault.exe process; NetWire RAT and Cerber ransomware were previously seen using this specific process to perform their tasks.

In detail, the WerFault.exe is a service that shows some error happened with the operating system, Windows features or applications. Victims would assume some error happens, but attackers stealthily execute malware using the process.

As can be observed in Figure 6, the loader contains two main classes: “Kraken” and “Loader“.

Figure 6: Main classes of Kraken.dll

The class Kraken contains inside it a specially crafted payload that is then injected into the WerFault.exe process, as previously mentioned. The shellcode is a variant of a Cobalt Strike payload, and it pretends to evade its detection by using this legitimate process from Windows.

Figure 7: Kraken shellcode and the target process used during the shellcode injection

According to Malwarebytes, “the Loader class is responsible for injecting shellcode into the target process by making Windows API calls”.

Figure 8: Load function — where the shellcode is injected into the memory

By analyzing this piece of code, we can conclude that the process injection technique is performed by using a handler of a created section. The target shellcode is then added via the CopyShellcode function and finally executed in memory through the WriteProcessMemory and ResumeThread calls (a technique well-documented here).

The shellcode analysis

After executing the shellcode in memory in the context of the WerFault.exe process, some tasks are performed in multiple threads in order to make difficult its analysis.

One of the operations executed is whether the process is being debugged. In detail, this task is performed by checking the existence of a debugger calling the native GetTickCount call from Windows.

Figure 9: Anti-analysis technique used by Kraken loader (source).

Other techniques are also used to perform anti-debug and anti-analysis, including checking the following calls: IsProcessorFeaturePresent(), NtGlobalFlag() and isDebuggerPresent().

After performing these checks to guarantee the payload is running in a real machine and not inside a virtualized environment, the Import Address Table (IAT) is resolved dynamically and a final shellcode is executed in a new thread.

List of resolved calls:

VirtualAlloc

VirtualProtect

CreateThread

VirtualAllocEx

VirtualProtectEx

WriteProcessMemory

GetEnvironmentVariableW

CreateProcessW

CreateRemoteThread

GetThreadContext

SetThreadContext

ResumeThread

In detail: after resolving the IAT, a new region in memory is created using the native call VirtualAlloc, which calls the function DecryptContent_And_WriteToAllocatedMemory hardcoded inside the shellcode and responsible for decrypting the shellcode that will be injected.

Next, the call VirtualProtect is used to change the protection of the newly allocated memory to make it executable. A new thread using the call CreateThread is then created in the context of the initial process to execute the shellcode.

Figure 10: Final shellcode executed in a new thread

After executing this new shellcode in memory, it executes an HTTP request to get another payload — probably the last stage of Kraken. As mentioned by Malwarebytes, the final stage was not obtained, as the external URL was down at the moment of the research.

Final thoughts

Although the techniques, tactics and procedures used by Kraken are not new, abusing the WerFault process can bring advantages to adversaries to evade detection, as this process was not often hooked and analyzed by antivirus and EDRs.

In addition, the Windows Error Reporting service werfault.exe is a process that allows Microsoft to track and address errors relating to the operating system, Windows features and applications.

Back to this threat, there is no effective mitigation measure to combat it. However, there are some steps to make your system as resilient as possible against malware:

• Ensure that your operating system and software are up to date
• Use an antivirus engine and updated anti-spam software
• Do not trust emails from untrusted sources. For this, social engineering training should be taken into account as a good way to educate employees and people in general
• Back up data and store it outside of the network connection
• Turn off the file sharing if not needed. Several pieces of malware are wormable and can infect adjacent computers on the same network (e.g., ransomware or WannaCry)
• Keep a check on bank access and login activity in your accounts regularly. Always use multi-factor authentication to prevent stolen credentials from being used to access your secrets

At last but not least, if you notice something strange or uncommon, share your suspicion with someone — and, if possible, with your company's cybersecurity team.

 

Sources

Kraken analysis, Malwarebytes

Break news Kraken, ZDNet