One of our customers recently asked us to take a look at the inner workings of the Zero Access rootkit. After analyzing it in Responder Pro, I decided to blog about a few of the interesting pieces. I'll start with its use of a known but not often used method of loading a kernel driver from kernel mode. The core of this method is to use the ZwSetSystemInformation function with SYSTEM_INFORMATION_CLASS number 0x36 (SystemLoadGdiDriverInSystemSpaceInformation). As the name implies, this allows a driver to load and map a PE file into system space (instead of session space). Essentially, it just calls MmLoadSystemImage and MmPageEntireDriver.

Malware detection is a complex game of cat and mouse. Yet every time the cat finds a way to catch the mouse, ten new mice are created that know how to avoid the cat. This constant back and forth has driven the development of malware in a convoluted direction. Advanced malware often uses multiple techniques in an attempt to hide its behavior. For example, some attempt to detect if they are being debugged or virtualized. Some encode strings, hide the use of certain API functions, or wrap themselves in legitimate looking code. The list of malware techniques is nearly endless and always evolving. Here is a look at how memory-only malware evolved and adapted.

Memory-only malware

One technique that cropped up many years ago was memory-only malware. It was used to avoid writing to disk and creating artifacts that could be detected by anti-virus software and hard drive forensics. Eventually the cat learned to detect the mouse and the memory-only technique became just another entry in the list of detectable techniques.

Chunked memory-only malware

In 2010 we began to see a new spin on the memory-only technique. Some malware would split its functionality across multiple single page allocations, thus spreading its behavior into many pieces and making it more difficult to determine what the malware was attempting to do. The pinnacle of this technique was a malware that split into 18 separate chunks. Separately, most of these chunks looked innocuous. They were often hand written assembly that resembled shellcode. Most used indirect calls through registers + offsets to obscure what function was being called. A single block contained data and arrays of function pointers. A pointer to this data block would be passed around with every internal call.

01100000   loc_01100000:
01100000       push ebp  
01100001       mov ebp,esp  
01100003       add esp,0xFFFFFA30  
01100009       mov esi,dword ptr [ebp+0x8]  
0110000C       lea eax,[esi+0x000003FB]  
01100012       push eax  
01100013       push 0x0  
01100015       push 0x0 
01100017       call dword ptr [esi+0x00000085]  // Module32NextW

In the above example, a passed parameter [ebp+0x8] is moved into esi, then esi + 0x85 is used for an indirect call. The function called is Module32NextW, but how would an anti-virus program determine that when statically analyzing a section of memory?

Obviously malware doesn't need to spread itself all over memory to use indirect calls, but when all the code, data, and function pointers are contained in a single module it is easier to determine if something is malicious.

This particular malware is now detected by a majority of anti-virus products on the market, although I suspect some use byte-based signatures to detect it (easy to avoid). But this malware is old news, what is the next step?

Cross process, chunked, memory-only malware

The latest variant we have seen involves spreading the malware chunks across multiple processes. Memory is allocated in multiple processes and small pieces of the malware are copied to each. One process contains the code for installing and surviving reboot. Another process (usually the browser) contains the code for sending communications, while another monitors the communication process and can re-inject or restart the process if needed. Yet another process does keylogging. Every major behavior of the malware is injected into a separate process. They all communicate using a single shared page of memory accessed through a randomly named global file mapping. Access is synchronized using the InterlockedXXX API calls to behave like a spinlock.

Creating cross process, chunked, memory-only malware definitely takes more time and more skill than most other malware (though not as much as kernel based malware). It adds overhead and makes debugging more difficult. It increases the chance of failure due to OS differences or permission restrictions. It is complex, yet just another step in the evolution of this type of malware.

The future of memory-only malware

Perhaps the next step in memory-only malware evolution is a separation of components so that you have to be infected with multiple distinct pieces of the malware before the malicious behavior is functional and/or decrypted. Or perhaps we have reached the end of memory-only malware evolution. All I know for sure is that future malware will find a way to surprise us.

- Martin Pillion

Malware is constantly finding obscure ways to hide hooks within the OS so that it can remain active after a reboot. One approach that we encountered recently involved using the Local Group Policy. Group Policy is a set of rules and settings that can be used to manage the Operating System and environment.

Local Group Policy is a simpler version of Group Policy. Group Policy is a complicated beast. It is not well understood by many system administrators or thoroughly examined by many security applications. Both are a prime location for malware to hide in plain sight.

Local Group Policy summary

Figure 1: Component Architecture ¹

In our example, we will focus on the Local Group Policy. Prior to Windows Vista, a system had a single Local Group Policy object (except Windows NT which has none). Newer Windows OS versions support Multiple Local Group Policy objects, but are still backwards compatible with the single object model.

As their name implies, Local Group Policy objects are stored locally on a system. It does not matter if the system is part of Active Directory or even in a network environment. However, Group Policy objects can override Local Group Policy objects. ²

You can edit the Local Group Policy object using an MMC snap-in. The quickest way is to open the Run Dialog and type "gpedit.msc". ³

Figure 2: The Local Group Policy Editor in Windows 7

The Local Group Policy data is stored at %SystemRoot%\system32\GroupPolicy. In this directory you will find gpt.ini, which contains version and synchronization information for each required file component.

There are many things you can do with a Local Group Policy object, but we will focus on Scripts. Scripts allow the execution of code when specific events occur. Scripts of particular interest include User Logon or Logoff, and Computer Startup or Shutdown ⁴. These scripts are referred to as Client-Side Extensions (CSE).

Client-Side Extensions

CSE information is stored in the registry at:

HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon\ GPExtensions

Under this Registry key you will find a list of CLSID subkeys for each installed CSE. Malware interested in Script execution will utilize the object CLSID {42B5FAAE-6536-11D2-AE5A-0000F87571E3} which is the object responsible for processing Group Policy scripts.

Figure 3: The GPExtensions Scripts subkey in Windows 7

Programmatically Adding a Logon/Logoff Script

Step 1: Modify %SystemRoot%\system32\GroupPolicy\gpt.ini

Figure 4: Malware Example

To add a logon/logoff script you have to add the Script CSE to gpt.ini. We do this by adding the following line in the [General] section:

gPCUserExtensionNames=[{42B5FAAE-6536-11D2-AE5A-0000F87571E3}{40B66650-4972-11D1-A7CA-0000F87571E3}]

This tells the CSE engine that the Script CSE (42B5FAAE-6536-11D2-AE5A-0000F87571E3) and the Logon/Logoff MMC extension (40B66650-4972-11D1-A7CA-0000F87571E3)have data in the Local Group Policy object.

Figure 5: Malware Example

We should also update the version information. There is an official method for incrementing the version based on what we changed: add 1 if we made a machine specific change, add 65536 if we made a user specific change.

Version=65536

Step 2: Create the full path for your scripts

For Logon scripts the path is

%SystemRoot%\system32\GroupPolicy\User\Scripts\Logon

For Logoff:

%SystemRoot%\system32\GroupPolicy\User\Scripts\Logoff

Within the directory, create the script file that you want to be executed. Something like

Badmalware.cmd

Note: This does not have to be a script! It can be an executable instead.

Step 3: Modify %SystemRoot%\system32\GroupPolicy\User\Scripts\scripts.ini

This is where you point the CSE to your script and provide it command line parameters. For logon scripts modify the [Logon] section, for logoff scripts the [Logoff] section:

[Logon]
CmdLine=Badmalware.cmd
Parameters={whatever options I need}

Figure 6: Malware Example

User Logon/Logoff scripts run under the specific user/domain account. Computer startup/shutdown scripts run as SYSTEM. Both of these security contexts can be used by malware to do evil things such as keylogging, screen capture, installing botnets, or searching through sensitive corporate data. The SYSTEM context is especially dangerous because it grants unrestricted access to the entire machine, which can be used to install rootkits and bypass most computer security products.

All of the above directories and files should be restricted to Administrators only by default, so this Persistence Technique only works for malware that already has Administrator access. The real value to the attacker is that most users and many IT administrators do not look for malware hiding in these places. It is a lot more involved and less understood that the typical Windows Service or Run key method.

If you are an IT Admin, it would be wise to review the Local Group Policy settings on machines in your enterprise and verify that they are configured correctly. As of version 11.0, the Autoruns ⁵ tool from Microsoft (SysInternals), which many Administrators rely on, does not detect Local Group Policy script settings. This is because the Autoruns tool primarily searches the Windows Registry, but all the Local Group Policy script settings are stored on the file system in the gpt.ini and scripts.ini files.

-- Martin Pillion

¹ - http://technet.microsoft.com/en-us/library/cc736967(WS.10).aspx

² - http://technet.microsoft.com/en-us/library/cc775702(WS.10).aspx

³ - http://technet.microsoft.com/en-us/library/cc787064(WS.10).aspx

⁴ - http://technet.microsoft.com/en-us/library/cc757265(WS.10).aspx

⁵ - http://technet.microsoft.com/en-us/sysinternals/bb963902