Fileless malware has been gaining increased attention in the malware forensics community as of late. Accordingly, I have been paying particular attention to indicators and forensic analysis of threats such as Poweliks. These malware variants typically leverage the Windows registry to maintain persistence, and they avoid leaving executable files on disk. I recently had an encounter with one such malware family - Kovter.
Kovter was originally discovered as a particularly nasty type of ransomware, but has recently been adapted to instead cash in via ad/click fraud.
In the sections below I will walk through some basic static analysis of one such sample. Additional analysis of later stages of this malware will follow in another writeup.
In case you want to follow along, the sample being analysed in this discussion is: 6ca41538ae9c25b259e6fcfce565b89b (many thanks to Kafeine for the sample).
After initial infection, the run key shown below in Figure 1 will be present.
|Figure 1: Run key
*Note that this particular malware will write to both HKLM and HKCU if it is able. The content written is identical in either case.
Taking a look at the HKCU\Software\2efd7e07 key revealed the following:
|Figure 2: HKCU\Software\2efd7e07 key content
|Figure 5: Script to execute
|Figure 6: Powershell script to launch shellcode
Once the shellcode is loaded, the overall actions are pretty standard, with a couple of interesting exceptions.
- Locate Kernel32.dll using hashing on the BaseDLLName member of the InMemoryOrderModuleList for the current process thread.
- Locate the offsets for LoadLibraryA, GetProcAddress, VirtualAlloc, and ExitProcess via ordinal lookups
- Load advapi32.dll and then do an ordinal lookup for RegOpenKeyExA, RegQueryValueExA
|Figure 7: Loading the string variable matching the registry key
|Figure 8: Reference to randomly generated key
|Figure 9: Registry value which contains next stage, encrypted shellcode
- Load the content of this registry key (HKCU\Software\2efd7e07\fecae03a in our example) into memory.
|Figure 10: RC4 key length
|Figure 11: RC4 key
This key is then copied (using an included 'memcpy' function) to a local variable for later use:
|Figure 12: copy RC4 key to local variable
- Decrypt the executable and perform required memory mapping (headers, copying sections to correct addresses, apply any relocs, etc.)
- Call the newly mapped file.
* Note: not only do the encryption key and length change each time the initial infector is run, but if the registry key is deleted, a watchdog process reinserts the values immediately - and each time the data is reinserted, the encryption key is modified.