CCleaner Stage 2: In-Depth Analysis of the Payload

Overview

Technical Analysis

Stage 2 Dropper

• If XP x86:
  • location is C:\Windows\System32\spool\prtprocs\\w32x86\\localspl.dll

• If XP x64:
  • location is C:\Windows\System32\spool\x64\localspl.dll

• If Windows 7 or higher:
  • location is C:\Windows\System32\TSMSISrv.dll

Dropped Binary Information

32-bit

64-bit

• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WbemPerf\001 → 2b 31 00 00. This is a hardcoded value. This is the size in bytes of the next registry key, which contains an obfuscated PE.
• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WbemPerf\002 → The dropper inserts a data blob in this key. The following explains the structure of the blob:

• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WbemPerf\003 → 21 00 00 00. Hardcoded value. Size in bytes of the next registry key
• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WbemPerf\004 → Contains the following structure

Leveraging Legitimate Services

• hService = Service Handle
• ServiceType = SERVICE_KERNEL_DRIVER|SERVICE_FILE_SYSTEM_DRIVER|SERVICE_ADAPTER|
  SERVICE_RECOGNIZER_DRIVER|SERVICE_WIN32_OWN_PROCESS|SERVICE_WIN32_SHARE_PROCESS|
  SERVICE_INTERACTIVE_PROCESS|FFFFFEC0
• StartType = SERVICE_AUTO_START
• ErrorControl = SERVICE_NO_CHANGE
• BinaryPathName = NULL
• LoadOrderGroup = NULL
• pTagId = NULL
• pDependencies = NULL
• ServiceStartName = NULL
• Password = NULL
• DisplayName = NULL

File Modifications

VirtCDRDrv.dll 32-bit

EFACIi64.dll 64-bit

Dropped Binary

Shellcode

Payload

 

Following are the decoded URLs:

• get.adoble<.>net
• https://en.search.wordpress<.>com/?src=organic&q=keepost
• https://github<.>com/search?q=joinlur&type=Uses&utf8=%E2%9C%93

Before connecting to any of the above, the payload first attempts to connect to https://www.microsoft.com. If that fails, the payload then attempts to connect to http://update.microsoft.com. This is to perform a connectivity test to ensure that the victim computer is connected to the internet. The payload also ensures that the received data contains the string "Microsoft" or "Internet Explorer"; apart from a connectivity test, this could also be seen as an anti-sandbox technique. If the test passes, a global variable Connectivity_Flag is set to 1, after which the malware attempts to connect to either the WordPress or the Github URL. At the time of analysis, the Github URL was not available. The following is the data returned by the WordPress URL: If the connection is a success, the malware parses the retrieved data for the string "ptoken=".

 

As the above image shows, the ptoken value is "000000006B48622B0000000000000000&". The malware converts the string value to a long integer value in base 16 by calling strtoul. The result is the DWORD 0x6B48622B, which is then XORd with the value 0x31415926 (value of Pi) to get the value 0x5A093B0D, which translates to the IP address 13.59.9.90. If the payload fails to connect to both the Github and WordPress URLs, it will attempt to connect to get.adoble<.>com to calculate an IP address. It gets the hostent structure by calling gethostbyname on the domain, which then gives it a NULL terminated list of IP addresses associated with the domain. The first 2 IP addresses will then be used to calculate the IP address using the algorithm reproduced in Python below:

import struct import socketa1 = 0x659C2A88

 

# Addresses are returned in network byte order a2 = 0x6B442ABF

 

# These are just for example purposesdef mod_record(rr):

 

 

 

rr1 = (((rr & 0xff000000) / 0x1000000) ^ (rr & 0xff)) * 0x1000000

 

 

 

rr2 = (((rr & 0xff0000) / 0x10000) ^ ((rr & 0xff00) / 0x100)) * 0x10000

 

 

 

rr3 = rr & 0xff00

 

 

 

rr4 = rr & 0xff

 

 

 

return (rr1 | rr2 | rr3 | rr4)newa1 = mod_record(a1) newa2 = mod_record(a2) newIP =

 

(newa2 & 0xffff0000) | (newa1 >> 0x10)

 

# newIP = 0xD46EEDB6 print socket.inet_ntoa(struct.pack("<L", newIP))

 

# Output is 182.237.110.212

 

Next, the malware calculates a checksum of the victim computer name using the following algorithm:

import structcompname = "WIN-CHB5K9B5QOM"

 

#example of computer name checksum = 0 hss = compname.encode('hex') indata = <> i = 0 def swap(d):

 

 

 

return struct.unpack("<I", struct.pack(">I", d))<0> while 1:

 

 

 

idata = hss

 

 

 

if len(idata) < 8:

 

 

 

 

 

 

 

numz = 8 - len(idata)

 

 

 

 

 

 

 

strz = '0' * numz

 

 

 

 

 

 

 

idata = idata + strz

 

 

 

indata.append(idata)

 

 

 

i += 8

 

 

 

if i >= len(hss):

 

 

 

 

 

 

 

break for i in indata:

 

 

 

i_ = int(i, 16)

 

 

 

i_ = swap(i_)

 

 

 

i_ = (i_ * 0x5E1F1AE) & 0xffffffff

 

 

 

checksum = (checksum +

 

i_) & 0xffffffffprint hex(checksum)

 

This checksum value is then added to the volume serial number of the victim computer. The LOWORD of the resultant DWORD is then added to the value 0x2DC6C0 to get a unique value. Next, the malware creates a socket and sets up the following packet to send to the newly calculated IP via a DNS query:

Type	Value
Transaction ID	LOWORD of the unique value calculated earlier using the checksum and volume serial number.
Flags	0x100. Denotes that the message is a query.
Questions	0x1. Number of queries.
Query	ds.download.windowsupdate.com
Type	0x1. Type A (Host Address)
Class	0x0001. IN (Internet)

Following is the actual UDP stream seen during analysis:

0000000: d47a 0100 0001 0000 0000 0000 0264 7308 .z...........ds. 0000010: 646f 776e 6c6f 6164 0d77 696e 646f 7773 download.windows 0000020: 7570 6461 7465 0363 6f6d 0000 0100 0100 update.com.....

 

At the time of analysis, the IP address was not available; however, analysis shows that the malware performs the following checks on the received response from the IP to ensure its authenticity.

• Transaction ID is 0xD47A (same as the query)
• Total Answer RRs field is 4. Number of entries in the resource record list.
• The 38th word is the value 0x06A4
• The 48th word is the value 0x0A8C

Stage 3

The malware takes values from the response stream at various positions, and calculates the Stage 3 C2 in the following manner:

• First octet → 59th byte ^ 62nd byte
• Second octet → 76th byte ^ 78th byte
• Third octet → 93rd byte ^ 94th byte
• Fourth octet → 110th byte

Once the 3rd stage C2 has been calculated, the malware calls out to it expecting to receive an obfuscated blob. The first DWORD of the blob is the CRC32 hash of the decoded blob. The blob is decoded using the same scheme that is used to decode the URLs, and the CRC32 hash of the decoded data is compared with the first DWORD of the received data to ensure its integrity. Analysis shows that the data is supposed to be yet another DLL, which is then loaded in memory and executed.

Recommendations

CrowdStrike will notify you of any additional activity through the Falcon Intelligence™ detections. CrowdStrike recommends blocking the IP and URLs mentioned in this blog post and the previous one to prevent any communication to the server. In addition, CrowdStrike recommends only using the latest version of the Avast CCleaner software to ensure that the infection does not occur. Learn more about the CrowdStrike Falcon Intelligence offerings, and read the white paper,

 

“Threat Intelligence, Cybersecurity’s Best Kept Secret.”