Winnti is a family of malware used by multiple Chinese threat actors like APT41. Carbon Black’s Threat Analysis Unit (TAU) is providing this technical analysis, YARA rules, IOCs and product rules for the research community.

Behavioral Summary

Winnti malware is installed manually with stolen privileged credentials or by exploiting system vulnerabilities since it requires an AES key string to decrypt a DAT file.

CB Threat Hunter will show the natural progression of this malware execution.

Additionally CB Defense will display TTPs created by the malware.

If you are a Carbon Black customer looking to learn how to defend against this attack, click here. 

Technical Analysis

Winnti Analysis History

Winnti malware has been analyzed by several security vendors dating back to at least 2013.

2013

Kaspersky reported Winnti version 1.0-2.0.

2015

Novetta analyzed the start-up sequence and C2 protocol of version 3.0 in detail.

2016

Symantec presented at HITCON 2016 about version 3.0 server variants with NDIS kernel rootkits for covert communication channels.

2017

Some Winnti samples decoding C2 address strings on legitimate websites were observed (e.g., PlugX-like encoded strings on GitHub reported by TrendMicro, Base58 and XOR encoded strings on Google+).

2018

TKCERT released the code and Nmap script to detect version 3.0 server variant infections based on the unique packets handled by the kernel rootkits.

2019

Chronicle documented Winnti Linux variants.

Recent Variants Since 2016

TAU observed that the recent implementation (especially the start-up sequence) have changed from version 3.0. In public presentations, Macnica Networks first described the new variants at JSAC 2018. Here we refer to the variants as version 4.0 to differentiate from other previous versions.

The differences from version 3.0 are below:

AES encryption for 4.0 DAT file

The Winnti 4.0 variants require a command line structured in the manner listed in the table below, in order to fully execute.

The loader requires two arguments: 

1. An AES key string 
2. The file path whose extension is “dat”

The DAT file is encrypted using AES in CTR mode (the initial counter value is an integer value of “q@3$%hy*&u” in little endian). 

The third party library libtomcrypt is used for the decryption. The library is also utilized for decrypting other hack tools like AceHash. By creating Yara rules which focus on the code sequences utilizing libtomcrypt, researchers can hunt for these and other related samples using this library. 

Some loader samples decrypt an inline DLL with the same encryption method and key then create a rundll32 process with the following arguments. 

One of the decrypted DLLs decodes the inline shellcode/DLL with XOR then runs the shellcode which is the same as the PlugX Type I LdrLoadShellcode function. The role of the DLL is UAC bypass by using the IARPUninstallStringLauncher COM object. 

Other loader samples directly decrypt and run a DAT file. In this case, the dropper calls the PlugX Type I shellcode decrypted from the DAT file then the shellcode extracts an inline payload to call the entrypoint.

DAT Payload Behavior

In regards to the decrypted DAT payload behavior, we introduce the following two sample cases compiled in 2017 and 2018. The Winnti 4.0 variants utilize DPAPI (Data Protection API) for worker metadata/component encryptions. DPAPI is available as a built-in component in Windows and the encryption keys are generated based on secrets in the system such as user passwords. This makes the decryption more difficult unless you have additional context about the sample’s acquisition location.

Macnica also reported that worker components were encrypted with host-specific AES keys, which are generated from computer name and ProductId from the registry.

2017 Sample Case

The DAT payload contains service and worker components. The payload encrypts the inline worker component by using CryptProtectData API then copies the encrypted worker into the service component. The specific GUID 66C56AF7-A572-4E08-B421-7A453CA2D372 is used to search the destination offset. After that, the service component is saved to the system.

The payload also adds a new IAT entry to wbemcomn.dll (specified in a configuration block) to load the service component for persistence. The technique is the same as that used by Winnti “VSEC variants” in Symantec presentation referenced above.

The service component just decrypts the inline worker component by using CryptUnprotectData API then calls the entrypoint. The worker code is most similar to version 3.0 except where decoding C2 address strings included in legitimate websites. The configuration block contains a GitHub URL for the decoding, which appears to be one of variants previously reported by Trendmicro.

2018 Sample Case

The payload saves service and DPAPI-encrypted worker components as separated files. The persistence for the service component is set by registering a new service. The worker component code has less than 50% similarity with the 2017 sample and the C2 protocol had been changed from version 3.0. The worker configuration block structure is detailed below:

As the structure shows, it supports TCP/HTTP/HTTPS/TLS/UDP including a server mode. The latest C2 protocol will be detailed in a later report.

Wrap-up

Winnti malware 4.0 is carefully implemented to make the worker code acquisition harder. This is why there is limited public information about this variant even though it was first observed in 2016. Our hope is that practitioners and researchers will continue to focus on this malware and the threat actors using it.

MITRE ATT&CK TIDs  

YARA Rules

The rules are available publically here.

Indicators of Compromise (IOCs)