A CB customer recently provided a series of commands that they had observed for analysis. The customer felt that the associated attacker activity may have been attempting to tamper with the Carbon Black product. It turned out they were not, but the attackers were specifically looking for the presence of Carbon Black and, if present, would not perform any additional malicious actions and their script would exit.

Note: If you are a Carbon Black customer looking for information on how CB solutions defend against this campaign, click here.

After analysis, TAU determined that this activity appears to be related to a DLTMiner campaign which was primarily targeting Asian corporations. This campaign appears to be an evolution of a campaign that was initially reported in January of 2019. The campaign in the past has incorporated both crypto-mining and crypto-jacking aspects. The customer did not provide any context to how they suspected that the attackers initially gained entry into the network, however previously disclosed DLTMiner campaigns exploited the Eternal Blue vulnerability (MS17-010 and CVE-2017-0143 - 0148) as well as RDP brute forcing. The portion of this attack that specifically pertained to Carbon Black products, was not an attack on the product itself or a vulnerability in the product. However, the attacker was specifically looking for the presence of Carbon Black products and if located the script would then exit, before performing any additional malicious actions. The initial commands issued by the attacker would decode several layers or obfuscated PowerShell code, which ultimately downloaded additional PowerShell scripts from two different embedded C2 sites. One of the C2 sites is non responsive, and is believed to be parked. __

Figure 1: Attack Overview

Technical Analysis

PowerShell Command - Carbon Black Enumeration

The original command that was provided is displayed below and was slightly altered to make viewing the contents easier to read. The area highlighted in the red box, is the portion of the command that the customer felt was targeting Carbon Black products.

__

Figure 2: PowerShell Command

The command appears to have backslashes (**) removed from the file paths, before being submitted. However this PowerShell command would look to see if the directoryC:\Windows\CarbonBlackexisted, this is the default installation path for Carbon Black Response. If the directory exists it would modify theAppMgmtservice’s binary path toC:\Windows\System32\svchost.exe**.The script will then exit before performing any further actions that would be detected by CarbonBlack Products. These actionsdo not interact, modify, or tamper with the Carbon Black Response sensor or associated process or service.

PowerShell Command - Payload Execution

The payload for this attack was zlib compressed and base64 encoded before being embedded into the PowerShell command. The image below highlights the truncated payload, which is executed using the Invoke-Expression (iex) cmdlet.

__Figure 3: PowerShell payload

TAU was able to base64 decode and partially decompress the payload, The payload was another PowerShell command, that was obfuscated using standard techniques that have been observed in numerous different types of campaigns. The metadata for the payload as it was decoded is listed below, however this was for the truncated data

File Name : payload

File Size : 3,266 bytes

MD5 : b6fdbadea4dda2c54e51a16e18ca4e00

SHA256 : d85096783eac330e575278ecef2a4ab1bde9ca9b5426edafaf5c425f3defd789

---

Table 2: Payload Metadata

Secondary Payload

The body of the PowerShell command is depicted in the image below. The obfuscation will build the final PowerShell command from an array of strings, and a custom order which is listed in brackets at the beginning.

__

Figure 4: Secondary PowerShell Payload

Building the array from this truncated data, will not result in a properly formatted PowerShell script. However another sample was located, which was the same and could be properly formatted, which resulted in the following script, depicted below. This script serves as a loader or cradle which will download additional malicious code or script, that will then be entrenched on the system as a scheduled service, dependent upon other variables.

__

Figure 5: Secondary PowerShell Payload

Secondary Payload Analysis

The script above will perform several different checks and create different variables, which are used for C2 communications. In the image below the script will gather and format the MAC address for the system and set that as a variable, highlighted in red. The script will then set the $flag variable (whose name is reused later) to a non-existent variable, which is then set to True in line 5, if script is able to create the mutex ‘Global\PSEXEC’. All of that activity is highlighted in blue.

__

Figure 6: Variables Set and System information

From the area highlighted in green above, the script will create a string that is composed of different hard coded variables and basic system information. The variables and their descriptions are listed in the table below.

System Parameters

---

Variable Name

|

Notes

mac

|

MAC address of the current system

av

|

This variable is not set in this version of the script. In previous iterations of this script, there may have been code that enumerated if AV was running on the system.

version

|

This retrieves the MS Windows Version number (ex. 10.1.XXXX or 6.2.XXXX)

bit

|

This retrieves the OS architecture (ex. 32-bit of 64-bit)

flag2

|

This is the flag variable that was set in the previous section. This will be listed as True if the Mutex was created and False if that operation failed. This and the PS argument should always match.

domain

|

This retrieves the domain that the system is joined to.

user

|

This retrieves the current user account name

PS

|

This is the flag variable that was set in the previous section. This will be listed as True if the Mutex was created and False if that operation failed. This and the flag2 argument should always match.

Table 3: System Information

The script will then set another set of variables and conduct some additional checks. The current date will be stored as the $dt variable, and used in C2 communications, highlighted in green. The $flag and $flag2 variables are set depending on whether or not certain files exist on the current system, highlighted in blue. The final check is for the variable $permit, which determines if the current process is running with Administrator privileges.

__

Figure 7: Second Variables Set and System information

The variables and checks that were conducted in the previous steps are then used to determine which embedded C2 to communicate with, as well as what resource to request from the C2. The script will check, via the $flag variable, to see if the file ccc.log exist in the user’s temp folder. If not, then it would create that file, which is highlighted in red in the image below.

The next check would determine if the current process was running with Administrator privileges, via the $permit variable. Regardless of whether or not the process was running with Administrator privileges, the script would contact the C2 hXXP://cdn.chatcdn[.]net. If running with Administrator privileges the request would contain “p?hig” and the date from the $dt variable. If not the request would contain “p?low” and the date. The response was expected to be a string, that was base64 encoded. A scheduled task, namedWinnet, is then created to run every 45 minutes, which will execute PowerShell and the base64 encoded payload from the C2 site. The only difference in the two instances is whether the scheduled task runs as under the context of the “system” or not. All of this activity is highlighted in blue below.

__

Figure 8: C2 Communications

At the time of this analysis the C2 site hXXP://cdn.chatcdn[.]net was not actively responding to request. It should be noted that originally this domain was resolving to the IP Address 134[.]209.103.152, which was the secondary C2 in this specific script, beginning on April 29, 2019. On approximately May 14, 2019, this domain was parked at 0[.]0.0.0, which is a common technique. However on approximately May 15, 2019 the domain began resolving to 74[.]119.239.234, which appears to be either a public-domain parking IP Address or less likely a sinkhole. TAU was unable to find a sample of the response from the server when it was originally responding to request. However directly making request to the original IP address, where the C2 resolved will return a payload which is described in a later section.

Resolved IP

|

First Observed

—|—

74[.]119.239.234

|

5/15/19 20:41

0[.]0.0.0

|

5/14/19 1:58

134[.]209.103.152

|

4/29/19 5:33

Table 4: Domain Name Resolution

If the ccc.log file exists on the system, which from the flow of the script will always occur as the previous conditional statement creates the file it did not exist, then the script will reach out to a secondary C2. This activity is highlighted in green in the image above. The script will reach out to 134[.]209.103.152 and request “update?” with the system information string that was created in the first portion of the analysis. The response as of this testing was an additional PowerShell script that would be executed, via cmd.exe, which will launch PowerShell and the third stage payload. It should be noted that TAU was able to locate a payload that was being provided from that same C2 on May 16, 2019. In both those instances the metadata for the file was the same, which is listed in the table below.

File Name : Third_Stage

File Size : 3,110,651 bytes

MD5 : 500a3b178af4d066a88a27edf1a278c0

SHA256 : 1756723b89788ba0f53ce9752e40ae50c7545c8993d4ca08768463289a73a53b

---

Table 5: Third Stage Payload

Third Stage Payload

A small subset of the third stage payload that is downloaded from 134[.]209.103.152, is depicted in the image below. The script uses reverse order, character replacement, and other standard obfuscation techniques to deter analysis.

__

Figure 9: Third Stage Payload

TAU was able to decode the script (to a reasonable degree), which appears to be a variant of an open source script used to exploit SMB vulnerabilities for lateral movement, commonly referred to as Invoke-SMBExec. The script contains an embedded PE file, that is base64 encoded, that appears to be a version of Mimikatz. Due to some of the errors in the decoding process that could not be confirmed.

Campaign

Initial Campaign

The initial campaign that is related to this incident was disclosed in January of 2019 by 360.cn. In that campaign there was overlap in the manner in which PowerShell scripts were formatted and variables set. Additionally the manner in which the request and data was being sent to the C2 server aligns with what was observed in the current campaign. This initial campaign appears to have been active from January 2019 throughout February of 2019, and targeting organizations in China.

Additionally there was a campaign that was documented in April, that was also attributed to the original campaign. In this campaign organizations in Japan, Australia, Taiwan, Vietnam, Hong Kong, and India were being targeted for Monero cryptocurrency mining. In this campaign different artifacts from the PowerShell scripts being used, the exploitation of SMB vulnerabilities, reflective injection of payloads, and C2 communication structure aligns with what was observed in the ongoing campaign. This portion of the larger campaign occurred in the March and April 2019 time frames.

Ongoing Campaign

TAU was able to track an ongoing campaign that was related to the truncated command that was submitted in this escalation. In this latest portion of the campaign organizations in Asia were being targeted. TAU identified two potential victims, which were both hospitals one located in Vietnam and the United States. The script that was submitted overlaps in C2 infrastructure to at least 3 others scripts that were located in public repositories. In the image below, the submitted script is located at the top left of the image. C2 communications are depicted in dotted red lines, while URL resolutions are in orange lines. Files that are being served up by different C2s are list in dotted blue lines.__

Figure 10: Campaign Overview

Remediation:

MITRE ATT&CK TIDs

TID

|

Tactic

|

Description

—|—|—

T1110

|

Credential Access

|

**Brute Force:**It was previously reported that DLTMiner campaigns was utilizing RDP brute forcing for initial access.

T1190

|

Initial Access

|

Exploit Public-Facing Application: Eternal Blue vulnerability was also reported to be used in connection with this campaign

T1086

|

Execution

|

PowerShell: PowerShell is heavily leveraged

T1053

|

Persistence

|

Scheduled Tasks: Persistence is maintained via scheduled tasks

T1210

|

Lateral Movement

|

SMB: One of the additional payloads will enumerate lateral systems and attempt to exploit the eternal blue vulnerabilites

IOCs

Related Sample Hashes

---

0c3f63af1e35d1b384a01d8caa8c49d6c7946affe1386a697079c352b76eaeef

|

Related PowerShell Script

21d783d08299b73f24a7cc20c3e5b43b13c06aea1bf9caca66aef09799719598

|

Related PowerShell Script

1b987ba4983d98a4c2776c8afb5aebbe418cdea1a7d4960c548fb947d404e4b2

|

Related PowerShell Script

1756723b89788ba0f53ce9752e40ae50c7545c8993d4ca08768463289a73a53b

|

Lateral Movement Script

134.209.103.152

|

C2

cdn.chatcdn.net

|

C2

206.189.87.176

|

Potential Parking IP Address

explorer.sombewallet.tk

|

C2

134.209.103.236

|

C2

p.estonine.com

|

C2

128.199.99.33

|

C2

The post CB TAU Technical Analysis: DLTMiner Campaign Targeting Corporations in Asia appeared first on Carbon Black.