Wingbird rootkit analysis

7 years ago 115

BOOK THIS SPACE FOR AD

ARTICLE AD

In previous blog posts I've described rootkits that have been used by so-called state-sponsored actors for infecting their victims, providing malware persistence and achieving SYSTEM privileges into a system. I've mentioned Remsec (Cremes) rootkit that was used by Strider (ProjectSauron) cybergroup and Sednit rootkit of APT28 (Fancy Bear) group. While Remsec rootkit has been used by operators for executing its code in kernel mode with SMEP bypass and developed in its original style, Sednit authors developed rootkit to hide their malware activity and footprints from user eyes in "usual rootkit manner".

Recently one security company that investigates activity of various cybergroups, has shared with me droppers of rootkits. I've been surprised during its analysis, because the rootkit is well protected from the analysis as well as its dropper. Analysis of both rootkits took enough time, because it contain various anti-research capabilities. Size of rootkit and dropper files was significantly increased due to using code obfuscation and the presence of much garbage instructions. Moreover, both rootkits belong to one cybergroup, were developed in targeted manner and are intended for specific victims.

Concept of "targeted" already long time discussed in AVers & security community as attribute of sophisticated cyberattacks, which often have state-sponsored origins. In past we saw a lot of cyberespionage operations in which have been used unique executable files that were developed for specific victims and software they use. Described in this blog post pieces of malware satisfy all the requirements, which researchers impose to highly targeted cyberattacks and possibly state-sponsored origins. I'm sure that this malware is a part of larger cyberespionage platform.

This malware as well as cyber espionage group, which leverages it, was mentioned by Microsoft MMPC in their blog post and Security Intelligence Report Volume 21 here. The group is called NEODYMIUM, while the malware is called Wingbird, Wingbird shares similarities with another famous commercial cyber espionage toolkit called Finfisher that detected by Symantec as Backdoor.Finfish.

Dropper 1

First dropper has following characteristics.
The dropper is well protected from various methods of static and dynamic analysis. It contains various anti- disasm/debug/VM/dump features.The dropper contains very obfuscated code with jumps to middle of instructions, garbage instructions, useless checks, useless jumps, etc.Because of using a lot of garbage instructions, size of dropper is large enough (1,3MB).The dropper is designed so that to delay its analysis as long as possible.It installs the rootkit into a system.It drops rootkit into file with name logonsrv.dat.It is intended only for rootkit dropping.

High entropy level of .text section is an indicator that code is encrypted and obfuscated.

The dropper and rootkit contain timestamp inside PE header that looks like legitimate.

Typical end of function in dropper.

All functions lead to one code.

That is very obfuscated and contains useless jumps.

Below are listed characteristics of Ring 0 rootkit.

The rootkit code is very obfuscated, making its statical analysis almost impossible.The rootkit contains encrypted code and data inside.It does not create device object and does not communicate with Ring 3 code.It does not set any hooks in Windows kernel.It is intended only for hidden injection of malicious code into trusted Winlogon process.The rootkit creates its copy in allocated pool region that is also contains very obfuscated code.It uses self-modifying code, for example, it can modify important call or jmp instructions with another address or another register.It is designed to be hidden as far as it is possible and unloads its driver after code into Winlogon was injected.It checks presence of ESET Helper Driver (ehdrv.sys) in a system and removes its SSDT (KiServiceTable) hooks.

Before doing main work, the rootkit prepares own code for execution.

It allocates two non-paged buffers. One with size 0x56000 for its driver and second with size 0x10000.First buffer is used for storing newly created driver (in memory) that will do all necessary work and second buffer with some trampolines to NT kernel API.The rootkit builds its IAT with 0x2F items that are located into section of new driver. But instead of using this IAT directly, the rootkit code takes these addresses and uses it for modifying instructions and variables in the code from second pool region.

It is worth to note that authors of rootkit took all possible steps to make rootkit analysis in memory much complicated. Advanced users also will have troubles with its detection via anti-rootkit tools.
The rootkit does not use its original image logonsrv.dat for performing main malicious tasks.The rootkit does not rely on continuous IAT buffer in memory that can be used to simplify its analysis.The rootkit does it main work from two allocated memory (pool) blocks with self-modifying code. One of these blocks is used as special trampoline for NT kernel API calls.It uses KeDelayExecutionThread function before doing main work, i. e. before injection code into Winlogon.Below you can see code from second allocated buffer with size 0x10000 that contains trampolines to imported by rootkit NT API. Another code from created driver (from first buffer) rewrites instructions in these trampolines with addresses from IAT.

After the end of preliminary actions, the rootkit calls ZwOpenKey for opening its registry key and reads value of ImagePath parameter with help of ZwQueryValueKey. Between two calls rootkit modifies own instructions as shown below.

After calling ZwQueryValueKey, the code has been modified again for calling PsCreateSystemThread.

The rootkit creates two threads with PsCreateSystemThread API and one of them is used for performing main malicious work. Below you can see the scheme of rootkit execution. It prepares code that will be injected into Winlogon and reads \KnownDlls\ntdll.dll section that represents content of Ntdll library for easy access. The rootkit also imports KeServiceDescriptorTable variable for getting address of KiServiceTable and restore items in this table.

It seems only one function in rootkit body was not obfuscated. This function specializes in enumeration of system modules. The rootkit code calls it several times, for getting NT kernel base address, Ntdll base address and for checking presence of ESET helper driver (ehdrv.sys). As you can see above, authors take interest in NT kernel files, because they need to restore original SSDT functions.

Interesting to note that authors have been used same scheme for obfuscating rootkit driver like they did in case of dropper. We can find same functions construction inside rootkit body.

As you can see on image above, all functions again lead to one code that is obfuscated with garbage instructions.

Also interesting that startup code in both dropper and driver didn't contain obfuscation. Considering above information and this fact, it seems that for obfuscation driver and dropper has been used one tool that launches process of obfuscation before compiler will generate code. i. e. on source code level.

The rootkit allocates three buffers into Winlogon process. First with size 0x100000, second 0x3000 and third 0x48000. The following Ntoskrnl functions are used by the rootkit.

Dropper 2

Next characteristics are related to second dropper.

Like first dropper, this dropper is well protected from various methods of static and dynamic analysis.The dropper has same size 1.3MB.The dropper drops Ring 0 rootkit into a file with name ndisclient.dat.

Some information about dropper behaviour.

Some characteristics of driver.
Designed to communicate with user mode client with help of device \Device\PhysicalDrive00 and symbolic link to it \DosDevices\PhysicalDrive00.It has a smaller size than driver from first dropper (43 KB vs 372 KB).It registers three IRP dispatch entry points for IRP_MJ_CREATE, IRP_MJ_CLOSE and IRP_MJ_DEVICE_CONTROL requests.The rootkit checks presence of driver \Driver\diskpt (Shadow Defender shadowdefender.com) and \Driver\DfDiskLow DfDiskLow.sys (Deep Freeze Faronics Corp).It contains code for parse object manager name space via functions ZwOpenDirectoryObject, ObQueryNameString.It contains obfuscated, self-modificated code that is hard for both static and dynamic analysis.Authors have provided DriverUnload function.The rootkit is intended for FS sandbox bypassing and for modifying files directly on low hard disk level.The rootkit allocates pool block in DriverEntry that is used for already familiar to us trampoline to NT kernel API (like in first driver).

Below you can see image with major steps of execution flow of rootkit's DriverEntry.

Part of IRP_MJ_DEVICE_CONTROL handler code is presented below.

The rootkit code in DriverEntry retrieves pointer to device object that represents hard disk(s) by port-driver (atapi). This information is used subsequently in code that dispatches IRP_MJ_DEVICE_CONTROL operation for sending synchronous requests to port-driver with standart set of functions:
MmMapLockedPagesSpecifyCache, IoAllocateMdl for work with non-paged memory and direct I/O.IoBuildSynchronousFsdRequest, IofCallDriver to build a correponding IRP and send it to driver. MmUnmapLockedPages, IoFreeMdl for releasing resources.

Below you can see table with characteristics of both analyzed drivers.

Conclusion

Authors of this malware took almost all efforts to hamper both the static and dynamic analysis. The first rootkit serves only for one purpose - to inject malicious code into Winlogon system process. It checks presence of ESET Helper Driver due to it ability to block rootkit malicious actions and attackers seems sure that their victim uses this security product. As you can see from the analysis due to high level of code obfuscation, it is useless to show images of rootkit code, because it do not help for building logic of its execution. Malware authors have used special instrument for droppers and rootkits obfuscation. It's not clear, why attackers did not care about rootkit persistence into a system and why it not guards own registry key.

Both rootkits are targeted on executing only one specific task: first is used for data/code injection into Winlogon and second to communicate with hard drive on low level. The rootkit from second dropper doesn't care about own persistence: the dropper removes its driver from disk once it was loaded into memory. It is worth to note that checking of presence of specific security products are correspond with the goals of both rootkits. For example, first driver checks presence of AV driver, when second driver is targeted only on system utilities that specialize on guarding a system from critical modifications.

Both security/system products Shadow Defender and Faronics Deep Freeze to leverage FS sandbox methods for blocking potential malicious actions for protected files in a system. This is an answer why attackers need low level disk access - they need to bypass FS sandbox and modify required files directly.

Read Entire Article