These are quick first looks and trend and threats


Read More >>
Written by the security and AV professionals from team K7, meant for the general audience
Read More >>
These are usually articles that go into internals of a virus or deal with security issues
Read More >>
Senior managers speak on areas of interest to them, inside and outside the industry
Read More >>

Interesting Persistence Technique

Here is an interesting persistence technique, which I have not seen before, used by a malware which I analyzed last week at K7 Threat Control Lab. It uses a simple RunOnce registry entry to maintain its persistence but in a unique way. I would like to post a complete analysis, albeit brief, of its functionality.

Functionality in a Nutshell

  • Push-Pop-Call
  • Misuse of Process Environment Block (PEB)
  • API Hashing Technique
  • Anti-Debug & Anti-Emulation Techniques
  • Strings Obfuscation Mechanism
  • Registry Abuse
  • Hidden DLL with multiple entrypoints (Export & DLL main) and its role
  • Multiple Injections into explorer.exe
  • Rootkit-like Behavior
  • Persistence Mechanism – RunOnce entry
  • Final Injection to IExplore.exe to act as downloader

Push-Pop-Call

This malware uses a Push-Pop-Call sequence at the Entrypoint to change the execution flow of the program as shown in Figure 1. This is not a clever technique since it can be used by Anti-Virus software to flag the malware immediately given that this sequence is unlikely to be found in clean programs.

Figure 1

Misuse of Process Environment Block (PEB)

Not an uncommon technique, this malware uses PEB_LDR_DATA, a member of the PEB structure, to locate InMemoryOrderModuleList LinkedList, which is then used to retrieve names of the loaded modules. It calculates the hash for each of the retrieved module names and compares with that of Kernel32.dll (hardcoded in the code), and extracts the base address of Kernel32.dll when the hashes match as shown in Figure 2.

Figure 2

API Hashing Technique

Using the retrieved Kernel32.dll base address, it enumerates export function names and calculates their hashes, which, in turn, are compared with predefined API hashes (in the data section) to identify the addresses of preferred APIs that are listed below. This common technique is to avoid heuristic detection on import APIs.

  • ConvertThreadToFiber
  • CreateDirectoryA
  • CreateFiber
  • CreateFileA
  • CreateMutexA
  • CreateProcessA
  • CreateThread
  • DeleteFileA
  • GetFileSize
  • GetFileTime
  • GetModuleFilenameA
  • LoadLibraryA
  • MoveFileExA
  • ReadFile
  • ReleaseMutex
  • RemoveDirectoryA
  • SetFileAttributesA
  • SetFilePointer
  • SetFileTime
  • SwitchtoFiber
  • WaitForMultipleObjects
  • WriteFile
  • WritePrivateProfileStringA

The hash calculation algorithm is shown in Figure 3 below.

Figure 3

Anti-Debug & Anti-Emulation Techniques

It implements Anti-Debug & Anti-Emulation techniques to prevent or misguide the reverse engineering process. This malware creates a thread which possesses an Anti-Debug technique of Memory Access Violation Exception (shown in Figure 4 below), thus complicating the analysis flow for researchers.

Figure 4

It also adds additional Exception Handlers in the existing SEH chain, which would be triggered by a memory access violation as shown in Figure 5.

Figure 5

It also uses undocumented ntdll.dll APIs which could act as an anti-emulation technique

  • ZwCreateThread
  • ZwResumeThread

Strings Obfuscation Mechanism

It employs an uncomplicated obfuscation mechanism to hide strings to dodge its presence from Anti-Virus products. Figure 6 shows how it decrypts a string to be used as its mutex.

Figure 6

Registry Abuse

It uses the registry to find the default path of “user\%AppData%” by querying the following registry key:

Subkey : “Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders”
Value    : “AppData”

It uses the registry to find the default browser path:

Subkey : “http\shell\open\command”

It also escalates its privilege under Internet Explorer by adding its path to the following registry key:

SubKey : “Software\Microsoft\Internet Explorer\LowRegistry”
Value    : “ms-ldr”
Data     : “%Malware Path%”

Hidden DLL with Multiple Entrypoints (Export & DLL Main) and its Role

It drops its main payload, ntuser.cpl (a DLL file), extracted and decrypted from its ‘data’ section, under a randomly named folder in the retrieved %APPDATA% directory as exemplified below:

USER/%APPDATA%/ {6JJ0C2I2-2W3D-2P70-7999-9N8KF3N5}/ntuser.cpl

The decryption logic used is shown below in Figure 7:

Figure 7

It tries harder to misguide analysis by executing the DLL with multiple entrypoints. Initially with the help of rundll32 it executes the dropped ntuser.cpl using its export function “_4CDFA75B”. This export function “_4CDFA75B” then injects the entire ntuser.cpl to explorer.exe with “DLLMain” as its new entrypoint. Injection technique 1 uses the following APIs:

  • CreateProcessA
  • GetModuleFileNameA
  • CreateFileMappingA
  • MapViewOfFile
  • UnmapViewOfFile
  • ZwMapViewOfSection
  • CreateRemoteThread

Multiple Injections into Explorer.exe

As ntuser.cpl loads into the memory space of explorer.exe, it uses the ‘ZwQuerySystemInformation’ API to get the snapshot of the current running processes. Now ntuser.cpl injects itself to the running processes that have access to ‘CREATE_THREAD & VM_OPERATION & VM_WRITE & QUERY_INFORMATION’ permissions, including explorer.exe.  But, this time with a new entrypoint being one of its functions. Injection technique 2 uses the following APIs:

  • OpenProcess
  • VirtualFreeEx
  • VirtualAllocEx
  • VirtualQueryEx
  • VirtualProtectEx
  • WriteProcessMemory
  • VirtualQueryEx
  • CreateRemoteThread

The latest injected code in explorer.exe now injects code into IExplore.exe, again with a new entrypoint being one of its functions using a similar injection technique to that described above.

These multiple injections are done just to halt the flow of analysis and to use system processes to download malicious content which will not trigger any alert by Anti-Virus Software, including Firewall.

Rootkit Behavior

It injects all system processes when attempting to act as a rootkit by hooking the following APIs, to maintain its stealth status:

  • NtCreateThread
  • NtEnumerateValueKey
  • NtQueryDirectoryFile
  • NtResumeThread

Persistence Mechanism

The latest injected code in explorer.exe also has the task of maintaining its persistence. This is achieved by creating a thread which checks the availability of mutex (MSCTF.Shared.MUTEX.LDR) and if this fails, it adds the following RunOnce entry:

SubKey : “Software\Microsoft\Windows\CurrentVersion\RunOnce”
Data      : “rundll32 “%APPDATA%\{6JJ0C2I2-2W3D-2P70-7999-9N8KF3N5}\ntuser.cpl”,_4CDFA75B”

Hence during reboot, the mutex gets killed and immediately a RunOnce entry is registered to maintain persistence.

Final Injection into IExplore.exe to Act as Downloader

Using IExplore.exe injected code, it checks for internet connectivity every 5 minutes, and if it has access to the internet, it uses ‘URLDownloadToFileA’ to download malicious content from the following URL

“hxxp: / /business-links-today.org/ldr/admin/feed.php?i=6JJ0C2I2-2W3D-2P70-7999-9N8KF3N5&o=2&v=1.0.8″

Post downloading it executes the downloaded content using CreateProcessA.

On final analysis this turns out to be just a mere Downloader, with a high level of obfuscation, injection techniques, and Anti-Debugging/Anti-Emulation tricks along with rootkit behavior.

Sample analyzed:

MD5: 6F14315A8875B1CF04E9FDB963E12966
SHA256: B129D92F6C62B7C81B5EF69FA38194AB3886BA7F18230581BC2D241C997F7FA6

Shiv Chand.K
Senior Threat Researcher

If you wish to subscribe to our blog, please add the URL provided below to your blog reader: http://blog.k7computing.com/feed/

Comments are closed.