BOOK THIS SPACE FOR AD
ARTICLE ADIn the last year Equation Group group was hacked by another hacking group called Shadow Brokers, who claimed that got access to secret sources of NSA cyber toolkits. As we already know, SB released some exploits and backdoors for routers/network devices of some vendors that belong to EG. The last leak from SB was dedicated to set of PE-files, which used by Equation Group for cyberespionage and named EquationDrug. Analyzed driver mstcp32.sys was taken from this leak.
The driver mstcp32.sys
(SHA256:26215BC56DC31D2466D72F1F4E1B6388E62606E9949BC41C28968FCB9A9D60A6) masked as "Microsoft TCP/IP driver".
Authors also took some steps to mask malicious purpose of this driver. For example, if you look to its imports or dump strings from file, you can't find something really suspicious. The driver imports API from NDIS kernel mode library called NDIS.SYS to work with network packets on physical level (that fully corresponds to its purpose). Actually, authors hid malicious indicators inside driver into encrypted data. Below you can see decrypted strings from driver's body.
As you can see from dumped strings above, the rootkit attaches itself to Windows network stack for capturing packets on NDIS level. Also, it is clear that the rootkit implements injection of malicious code into trusted Windows processes - Services.exe (SCM) & Winlogon.
Below you can see compilation date of this driver, which indicates that it was compiled already almost 10 years ago. This means that cyber espionage group used the rootkit and was active already in 2007. Also authors were interested to make their operations stealthy from user eyes, putting code into Ring 0.
Timestamp from debug directory matches with its analog from IMAGE_FILE_HEADER.
Below you can see screenshot of start rootkit code.
Malicious data decryption is a first step that takes the driver. After that it creates device object with name \Device\Mstcp32 and performs initialization steps. The device name doesn't hard coded into driver's body, it forms on base of driver service name (Mstcp32 as original name).
As you can see from image above, driver dispatches following IRP requests:
IRP_MJ_CREATEIRP_MJ_CLOSEIRP_MJ_READIRP_MJ_WRITEIRP_MJ_DEVICE_CONTROLIRP_MJ_CLEANUP.
The driver registers itself as NDIS filter. It checks interface with GUID {4d36e972-e325-11ce-bfc1-08002be10318} (that located into encrypted part of data) and gets list of instances that already registered in Windows. It tries to find specific instance with value LowerRange == "ethernet" into HKLM\SYSTEM\CurrentControlSet\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}\000X\Ndi\Interfaces. After driver code found it, it appends own value to this parameter as shown on image below.
As I already mentioned above, the rootkit was written by authors in 2007, so range of supported Windows versions is extremely small comparing with nowadays malware. Moreover, like other rootkits authors in that time, they use a lot of undocumented fields in kernel mode objects for retrieving the data they need. Next Windows NT versions are supported by the rootkit.
Windows NT 4.0 (1381)Windows 2000 (2195)Windows XP (2600)Windows Server 2003 (3790)You can see that the rootkit uses various undocumented offsets in EPROCESS and ETHREAD kernel objects for some purposes, including, enumerating running processes and threads, checking thread alertable state, retrieving pointer to PEB and etc.
Injection of malicious code into processes is made in usual for such rootkits manner: Attach_To_Process->Allocate_Virtual_Memory->InsertApc.
Conclusion
Unlike authors of other state-sponsored rootkits that were already mentioned in my blog, authors of mstcp32.sys don't rely on Windows native API for performing some operations, for example, for enumeration processes and threads. Instead this, they use undocumented kernel objects offsets for retrieving some data mentioned above. A significant portion of code in rootkit body is NDIS-oriented and dedicated to communication with network. There are a lot of Windows kernel rules for correctly organizing communication between NDIS driver and other parts of OS.
The rootkit driver supports IOCTL for sending data over network on NDIS level. This means that network logic of communicating with remote host is located into user mode part that use driver for this purpose.