Summary

tl;dr

This post explores some of the TTPs employed by a threat actor who was observed deploying ShadowPad during an incident response engagement.

Below provides a summary of findings which are presented in this blog post:

• Initial access via CVE-2022-29464.
• Successive backdoors installed – PoisonIvy, a previously undocumented backdoor and finally ShadowPad.
• Establishing persistence via Windows Services to execute legitimate binaries which sideloads backdoors, including ShadowPad.
• Use of information gathering tools such as ADFind and PowerView.
• Lateral movement leveraging RDP and ShadowPad.
• Use of 7zip for data collection.
• ShadowPad used for Command and Control.
• Exfiltration of data.

ShadowPad

This blog looks to build on the work of other security research done by SecureWorks and PwC with firsthand experience of TTPs used in a recent incident where ShadowPad was deployed. ShadowPad is a modular remote access trojan (RAT) which is thought to be used almost exclusively by China-Based threat actors.

Attribution

Based on the findings of our Incident Response investigation, NCC Group assesses with high confidence that the threat actor detailed in this article was a China-based Advanced Persistent Threat (APT).

This is based on the following factors

• ShadowPad – Public reporting has previously indicated the distribution of ShadowPad is tightly controlled and is typically exclusive to China-based threat actors for use during espionage campaigns.
• TTPs – Specific TTPs observed during the attack were found to match those previously observed by China-based threat actors, both within NCC Group incident response engagements and the wider security community.
• Activity pattern analysis – The threat actor was typically active during the hours of 01:00 – 09:00 (UTC) which matches the working hours of China

TTPs

Initial Access

A recent vulnerability in WSO2, CVE-2022-29464 [3], was the root cause of the incident. The actor, amongst other attackers, was able to exploit the vulnerability soon after it was published to create web shells on a server.

The actor leveraged a web shell to load a backdoor, in this case PoisonIvy. This was deployed via a malicious DLL and leveraged DLL Search Order Hijacking, a tactic which was continuously leveraged throughout the attack.

Execution

Certutil.exe was used via commands issued on web shells to install the PoisonIvy backdoor on patient zero.

The threat actor leveraged command prompt and PowerShell throughout the incident.

Additionally, several folders named _MEI<random digits> were observed within the Windows\Temp folder. The digits in the folder name change each time a binary is compiled. These folders are created on a host when a python executable is compiled. Within these folders were the .pyd library files and DLL files. The created time for these folders matched the last modified time stamp of the complied binary within the shimcache.

Persistence

Run Keys and Windows services were used throughout in order to ensure the backdoors deployed obtained persistence.

Defense Evasion

The threat actor undertook significant anti-forensic actions on ShadowPad related files to evade detection. This included timestomping the malicious DLL and applying the NTFS attributes of hidden and system to the files. Legitimate but renamed Windows binaries were used to load the configuration file. The threat actor also leveraged a legitimate Windows DLL, secur32.dll, as the name of the configuration file for the ShadowPad backdoor.

All indicators of compromise, aside from backdoor modules and loaders, were removed from the hosts by the threat actor.

Credential Access

The threat actor was observed collecting all web browser credentials from all hosts across the environment. It is unclear at this stage how this was achieved with the evidence available.

Discovery

A vast array of tooling was used to scan and enumerate the network as the actor negotiated their way through it, these included but were not limited to the following:

• AdFind
• NbtScan
• PowerView
• PowerShell scripts to enumerate hosts on port 445
• Tree.exe

Lateral Movement

Lateral movement was largely carried out using Windows services, particularly leveraging SMB pipes. The only interactive sessions observed were onward RDP sessions to customer connected sites.

Collection

In addition to the automated collection of harvested credentials, the ShadowPad keylogger module was used in the attack, storing the keystrokes in encrypted database files for exfiltration. The output of which was likely included in archive files created by the attacker, along with the output of network scanning and reconnaissance.

Command and Control

In total, three separate command and control infrastructures were identified, all of which utilised DLL search order hijacking / DLL side loading. The initial payload was PoisonIvy, this was only observed on patient zero. The threat actor went on to deploy a previously undocumented backdoor once they gained an initial foothold in the network, this framework established persistence via a service called K7AVWScn, masquerading as an older anti-virus product. Finally, once a firm foothold was established within the network the threat actor deployed ShadowPad. Notably, the ShadowPad module for the proxy feature was also observed during the attack to proxy C2 communications via a less conspicuous server.

Exfiltration

Due to the exfiltration capabilities of ShadowPad, it is highly likely to have been the method of exfiltration to steal data from the customer network. This is further cemented by a small, yet noticeable spike in network traffic to threat actor controlled infrastructure.

Recommendations

• Searches for the documented IOCs should be conducted
• If IOCs are identified a full incident response investigation should be conducted

ShadowPad Technical Analysis

Initialisation phase

Upon execution, the ShadowPad core module enters an initialisation phase at which it decrypts its configuration and determines which mode it runs. In summary, we identified the following modes:

Table 1 – ShadowPad Modes

ANALYST NOTE: The shellcode is decrypted using a combination of bitwise XOR operations.

Configuration storage and structure

ShadowPad comes with an embedded encrypted configuration, which it locates by scanning its own shellcode (core module) with the following method (Python representation):

for dword in range( len(data) ):
  first_value = data[dword :dword+4]
  second_value = data[dword+4:dword+8]
  third_value = data[dword+8:dword+12]
  fourth_value = data[dword+12:dword+16]
  fifth_value = data[dword+16:dword+20]
  sixth_value = data[dword+20:dword+24]

  xor1 = int.from_bytes(second_value,'little') ^ 0x8C4832F1
  xor2 = int.from_bytes(fourth_value,'little') ^ 0xC3BF9669
  xor3 = int.from_bytes(sixth_value,'little') ^  0x9C2891BA

  if xor1 == int.from_bytes(first_value,'little') and xor2 ==    int.from_bytes(third_value,'little') and xor3 == int.from_bytes(fifth_value,'little'):
     print(f"found: {dword:02x}")
     encrypted = data[dword:]
     break

After locating it successfully, it starts searching in it for a specified byte that represents the type of data (e.g., 0x02 represents an embedded module). In total, we have identified the following types:

Table 2 – Shadowpad Data Types

Once one of the above bytes are located, ShadowPad reads the data (size is defined before the byte identifier) and appends the last DWORD value to the hardcoded byte array ‘1A9115B2D21384C6DA3C21FCCA5201A4’. Then it hashes (MD5) the constructed byte array and derives an AES-CBC 128bits key and decrypts the data.

In addition, ShadowPad stores, in an encrypted format, the following data in the registry with the registry key name being unique (based on volume serial number of C:\) for each compromised host:

1. ShadowPad configuration (0x80) data.
2. Proxy configuration. Includes proxy information that ShadowPad requires. These are the network communication protocol, domain/IP proxy and the proxy port.
3. Downloaded modules.

ShadowPad Network Servers

ShadowPad starts two TCP/UDP servers at 0.0.0.0. The port(s) is/are specified in the ShadowPad configuration. These servers work as a proxy between other compromised hosts in the network.

In addition, ShadowPads starts a raw socket server, which receives data and does one of the following tasks (depending on the received data):

1. Updates and sets proxy configuration to SOCKS4 mode.
2. Updates and sets proxy configuration to SOCKS5 mode.
3. Updates and sets proxy configuration to HTTP mode.

Network Communication

ShadowPad supports a variety of network protocols (supported by dedicated modules). For all of them, ShadowPad uses the same procedure to store and encrypt network data. The procedure’s steps are:

1. Compress the network data using the QuickLZ library module.
2. Generates a random DWORD value, which is appended to the byte array ‘1A9115B2D21384C6DA3C21FCCA5201A4’. Then, the constructed byte array is hashed (MD5) and an AES-CBC 128bits key is derived (CryptDeriveKey).
3. The data is then encrypted using the generated AES key. In addition, Shadowpad encrypts the following data fields using bitwise XOR operations:
4. Command/Module ID: Command/Module ID ^ ( 0x1FFFFF * Hashing_Key – 0x2C7BEECE )
5. Data_Size: Data_Size ^ ( 0x1FFFFFF * 0x7FFFFF * ( 0x1FFFFF * Hashing_Key – 0x2C7BEECE ) – 0x536C9757 – 0x7C06303F )
6. Command_Execution_State: Command_Execution_State ^ 0x7FFFFF * (0x1FFFFF * Hashing_Key – 0x2C7BEECE) – 0x536C9757

As a last step, ShadowPad encapsulates the above generated data into the following structure:

struct Network_Packet
{
 DWORD Hashing_Key;
 DWORD Command_ID_Module_ID;
 DWORD Command_Execution_State; //Usually contains any error codes.
 DWORD Data_Size;
 byte data[Data_Size];
};

If any server responds, it should have the same format as above.

Network Commands and Modules

During our analysis, we managed to extract a variety of ShadowPad modules with most of them having their own set of network commands. The table below summarises the identified commands of the modules, which we managed to recover.

Table 3 – Modules Network Commands

Below are listed the available modules, which do not have network commands (Table 3).

Table 4 – Available modules without network commands

Below are listed the modules that we identified after analysing the main module of ShadowPad but were not recovered.

Table 5 – Non-Recovered ShadowPad Modules

Misc

1. ShadowPad uses a checksum method to compare certain values (e.g., if it runs under certain access rights). This method has been implemented below in Python:

ror = lambda val, r_bits, max_bits: \
((val & (2**max_bits-1)) >> r_bits%max_bits) | \
(val << (max_bits-(r_bits%max_bits)) & (2**max_bits-1))
rounds = 0x80

data = b""
output = 0xB69F4F21
max_bits = 32
counter = 0

for i in range( len(data) ):
 data_character = data[counter]
 if (data_character - 97)&0xff <= 0x19:
  data_character &= ~0x20&0xfffffff
  counter +=1
  output = (data_character + ror(output, 8,32)) ^ 0xF90393D1
  print ( hex( output ))

• Under certain modes, ShadowPad chooses to download and inject a payload from its command-and-control server. ShadowPad parses its command-and-control server domain/IP address and sends a HTTP request. The reply is expected to be a payload, which ShadowPad injects into another process.

ANALYST NOTE: In case the IP address/Domain includes the character ‘@’, ShadowPad decrypts it with a custom algorithm.

[1] https://www.secureworks.com/research/shadowpad-malware-analysis

[2] https://www.pwc.co.uk/issues/cyber-security-services/research/chasing-shadows.html

[3] https://nvd.nist.gov/vuln/detail/CVE-2022-29464