Introduction
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).
Initial Infection
Upon execution of the initial infector, several checks are performed to look for security tools such as Fiddler and Wireshark, as well as for standard indicators of virtual environments (registry keys common to VirtualBox, Sandboxie, and VMware). If none are found, the malware proceeds to create a random looking registry key (using hex chars) under HKCU\Software and HKLM\Software. Within this parent key are six values which are also named using apparently random hex characters. These registry values and their parent key appear to be named in a deterministic manner, likely generated on characteristics of the victim system (such as product id, guid, etc). One of these registry values contains obfuscated javascript which ultimately unpacks and executes shellcode. This shellcode is responsible for decrypting the data stored in a second registry value and executing it. Interestingly, the encryption key for this activity appears to be generated uniquely upon execution of the initial infection binary.
Fileless Persistence
After initial infection, the run key shown below in Figure 1 will be present.
Figure 1: Run key |
This run key makes use of the mshta.exe application to execute a few simple javascript commands. Deobfuscated, this became (in the case under examination):
y=new ActiveXObject("WScript.Shell");x=y.RegRead("HKCU\\Software\\2efd7e07\\7b5fa1aa");eval(x);
*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 3: Obfuscated javascript block |
Figure 4: Deobfuscated javascript |
Figure 5: Script to execute |
Figure 6: Powershell script to launch shellcode |
Shellcode Analysis
Once the shellcode is loaded, the overall actions are pretty standard, with a couple of interesting exceptions.
Overall steps:
- 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.