The Colonial Pipeline attack in May 2021 caused tremendous damage, disrupting 45% of the oil supply for the east coast of the United States for nearly a week [1, 2]. FireEye provides a great overview of the threat actors involved in this attack and the types of tactics used [3]. According to FireEye, DarkSide played a key role, but the threat actors and campaign involved are quite complex. In particular, the tools and services span multiple threat actor groups with various targets beyond the Colonial Pipeline Company. In this blog, we partnered with Trinity Cyber to demonstrate and analyze the full execution of one piece in the broader campaign: a dropper that leads to SMOKEDHAM malware deployment.
As illustrated in the Figure 1, the SMOKEDHAM dropper starts with a shared file on Google Drive. The victim is tricked into clicking on the shared file, leading to a downloaded ZIP file. From there, the victim must extract an LNK file (commonly referred to as a Window's Shortcut) from the ZIP file and then double click it to initiate the remaining steps in the attack. We began our analysis with a sample LNK file while the threat actor infrastructure was still active. As detailed below, we worked to unravel the remaining stages of SMOKEDHAM. The chain was surprisingly long and complex, using URL redirection, multiple powershell scripts and ultimately C# source code for the payload. Since the infrastructure was still operational, REnigma provided a safe way for the analysts to capture key pieces to the dropper all the way to attempting to establish command and control.
The key take away from this report is that modern droppers have become very complex. In the early days of phishing attacks, the malicious binary was attached to an email. As cyber defender tools evolved, threat actors have adapted and introduced droppers in various forms that worked as two-stage attacks. The dropper would do nothing but download the main payload. For example, one of the major malware campaigns over the last few years, generally referred to as Emotet after the original banking-Trojan malware, uses a malicious Microsoft Word document for the dropper and then uses macros to download the payload and run it. What is striking about the SMOKEDHAM analysis, in comparison, is the number of stages and redirection involved. Our goal with this report is to help defenders understand the world of possibilities for how these stages can be chained together. You can take this knowledge to think about ways to secure your own enterprise network or develop new technologies to help other companies defend against future threats. See the end of this report on ways that Trinity Cyber and DTRSEC can help.
Previous blogs observed UNC2465 sending a user link to a shared file on Google Drive, so we'll use that observation and extrapolate the first stage in a SMOKEDHAM campaign is a Google Drive link (in some cases at least) [3]. Google Drive is a common delivery stage for a dropper because defenders have a difficult time blocking malicious content while also allowing access to legitimate content. Typical network controls allow a SOC team to block a domain or an IP but blocking specific pieces of content on Google Drive is beyond the capabilities of most cyber defense teams. Also, as discussed in the next section, it is it difficult for Google to immediately block this type of content on their Google Drive service.
Using Google Drive for the first stage is a common tactic, but to imagine alternatives, ask the question: "What are all possible ways to get basic execution on the target's host that can lead to the next stage?" Other common options are email attachments, Dropbox links, or a compromised third-party server, but there are many possibilities. For example, a surprisingly effective tactic is to call the victim and claim to be from the IT department and have the user manually alter their computer to initiate the attack.
Previous reporting shows that the initial shared file is a ZIP file in some observed attacks, so we'll extrapolate that the second stage of a SMOKEDHAM campaign is a ZIP file hosted in Google Drive [3]. The threat actor could also serve the raw file or embed the file in some other container format, but a ZIP file remains one of the common tactics. The reason threat actors use ZIP files is that it makes it harder for automated defense tools to detect and block the content.
For the SMOKEDHAM campaign, we do not have data on how often the ZIP file is delivered to targets versus a raw LNK file, but we can discuss why a threat actor would chose to wrap the LNK in a ZIP file. In particular, one interesting thing to point out is that the ZIP file can be password protected with strong encryption. Then, the password is delivered to the user via email. This makes it easy for the threat actor to vary the payload (e.g., by changing to password to permute the hash) and difficult for the defender to block. For this scenario, short of cracking the password, the best case is to create automated tooling to try to figure out what the password is by scanning the email and linking that password to the payload. In contrast, the goal for the threat actor is that only a human can figure out the password and open the ZIP file.
In the worst case for a password-protected ZIP file, the tooling does not have access to both the password and the ZIP file. For example, Google may see the password-protected ZIP file whereas they do not have access to an email with the password. So, as alluded to in the discussion for the previous stage, this kind of scenario is one piece of the problem that makes it hard for Google to automatically identify malware hosted on their servers.
The third stage of SMOKEDHAM is the LNK file inside the ZIP file. After the victim extracts the LNK file, they need to double click on it to start the automated installation sequence for the malware. The LNK file listed in Table 1 is where we started our analysis for this report.
| Name | md5sum | Size |
|---|---|---|
| sample.lnk | 6c9cda97d945ffb1b63fd6aabcb6e1a8 | 3622 Bytes |
Normally, an LNK file is used to create a shortcut to a program on the desktop or start menu and is commonly referred to as a Windows Shortcut. But, it turns out that threat actors have repurposed LNK files as a method to initiate basic execution on the target system. LNK files have the ability to execute an arbitrary command, which opens up a virtually unlimited set of options. This tactic has been in use for many years [4, 5].
The first command in Figure 2 shows the decoded LNK file. LNK files have several properties, but the most important two properties are the Target and Start in properties. For normal LNK files, if the target is an executable, then Target is set to the full path of the executable. Start in defines the initial working directory. For this malware sample, Target is set to cmd.exe followed by a garbled string and Start in is set to "C:\Program Files\Internet Explorer". As for the garbled string in the Target property, that is a typical malware tactic to make analysis more challenging.
To unravel the garbled string, the second command in Figure 2 shows the deobfuscated (and also defanged) version of the Target that is executed. We used REnigma to deobuscate the LNK and also performed static analysis to get the same result (not shown). The command that runs when a victim double clicks the LNK is "mshta [url]". The mshta command is a built-in Windows utility to execute Microsoft HTML Applications (HTA) files, and it includes the ability to download and execute files using a URL as the argument. This is another tactic that is used by other malware samples [6]. The end result of this stage is that it has the ability to download an arbitrary script from the Internet and execute it.
After decoding the URL obfuscated in the LNK, we used REnigma to investigate the URL. Normally, this stage of the attack would happen automatically after the user double clicks the LNK because the mshta.exe target described in stage 3 would load the URL and execute it. However, we investigated it manually for our analysis. Specifically, we loaded the URL in the browser to examine the content. The page immediately redirects to the following URL:
hxxps://cdn[.]shopify[.]com/s/files/1/0562/9568/6349/t/1/assets/srv-ind.html
We call this redirection the fourth stage of SMOKEDHAM. It's common for malware samples to use one or more redirects because it makes the download process more resilient. The threat actor can redirect to an alternate URL on the server side. What is interesting, in this case, is the threat actors use a legitimate site called shopify to host their malware. It's unclear if the actor had registered as a legitimate user on shopify or if they gained unauthorized access to host their malicious content. Either way, the end result is effective because it is challenging for defenders to block this type of resource since shopify is a legitimate site. Further, if it is blocked, then the threat actor can simply use a different resource and update their redirect.
To continue our investigation, after following the redirect in REnigma, Google Chrome showed a blank page. Recall that the contents of this page would normally be downloaded and executed automatically by mshta, so to examine the content, we used the view source option. Figure 3 shows the result. The infrastructure was still active at the time of analysis and we observed obfuscated VBScript embedded in the HTML file, which is called an HTML Application [7]. It is interesting to note that HTML Applications can use Microsoft VBScript for the code and that Microsoft designed this format to run as trusted code with unlimited rights. Since this is yet another stage of abstraction, we call this technique of hosting VBScript in HTML the fifth stage of SMOKEDHAM.
We used these steps to slowly unravel the chain. What would normally happen is that when the victim double clicks on the LNK from stage 3, the mshta.exe program would follow the redirect from stage 4, download the content in stage 5, and then execute it. Then, the automated chain would continue onto the next stage.
Continuing the investigation, we exported the VBScript in Figure 3 and analyzed it. The VBScript creates a winmgts object impersonating root privileges that executes a line of obfuscated powershell. The embedded powershell acts as the downloader for the next stage of powershell, which is obfuscated. Since this powershell is embedded inside the VBScript and required another round of deobfuscation, we call this powershell the sixth stage of SMOKEDHAM. After performing the deobfuscation, we determined that the powershell uses the following URL to download the next stage:
hxxps://cdn[.]shopify[.]com/s/files/1/0562/9568/6349/t/1/assets/oZUBDcYSBljl.html
To unravel the next stage, we loaded the URL obtained from stage 6 into REnigma. Figure 4 shows the result of what we found. The raw data in the web browser is shown in the background. During the recording, the analyst copy-and-pasted the contents into notepad as a quick triage of the data before exporting for follow-on analysis. It turns out that this was yet another stage of powershell, though much larger than the other powershell pieces. Most of the code is base64 encoded, so an analyst needs to decode that with static or dynamic analysis to understand what is happening in this stage. As we will see in the next stage, it turns out that this powershell is used to launch the main payload, so we call this seventh stage of SMOKEDHAM the Powershell Launcher component.
To uncover the final stage of SMOKEDHAM, we detonated the powershell obtained from stage 7 in REnigma. The sample was loaded into a new recording, and we manually detonated it (not shown). After capturing the behavior, we used REnigma's process analysis feature to analyze the execution.
The top of the Figure 5 shows the details of the powershell.exe process, which has a PID of 5116 (column labels are not shown in the figure). REnigma shows the command-line parameters for this process, which includes the target file "C:\stage_2.ps1". Below the command line, we have expanded the created files listing for the powershell process to show what's happening with this process. In particular, the powershell script creates two files called cie2frab.0.cs and cie2frab.0.cmdline. The "cie2frab" part of these filenames is simply a random string that the malicious powershell script uses to create temp files. What's more interesting is that the ".cs" extension stands for C# and as we'll detail below, the ".cmdline" file is used to build the C# program.
Figure 6 provides a bit more detail on the cie2frab.0.cs file. The file is about 13.7k in size, so we do not show the entire listing here (the hash and file details are provided in the indicator section), but we show part of the file here to illustrate that it is a heavily obfuscated C# file. The obfuscation not only makes analysis more difficult but the threat actor can also generate a new obfuscated C# file that is essentially the same thing but looks different, making it difficult to block.
Figure 7 provides the full listing of the cie2frab.0.cmdline file. Referring back to bottom of Figure 5, note that the cie2frab.0.cmdline file is passed to a process named csc.exe, which is Microsoft's Visual C# Command-Line Compiler. The csc.exe process has a PID of 4264 and a parent PID of 5116, meaning that the powershell process created the csc.exe process, passing in this cie2frab.0.cmdline file as one of the arguments. So, what's happening here is the malicious powershell included an embedded C# file and compilation flags. It first writes the C# file out to disk and also creates a C# cmdline file. Then, is compiles the C# file based on the parameters detailed in Figure 7.
Interestingly, by reading the command-line file, we observed that the compiled file is a DLL file. Specifically, the output for the binary component of SMOKEDHAM is specified by this parameter:
/out:"C:\Users\bob\AppData\Local\Temp\cie2frab.dll"
After the DLL file is compiled, it gets loaded and executed. The DLL component is the piece of SMOKEDHAM that attempts to connect to the command and control server. Figure 8 shows the traffic we captured. This piece of the infrastructure did not respond with much interesting data, however, so we did not see the full command and control traffic. Nonetheless, it is interesting to see that the sample is attempting to talk to a Microsoft domain. It's unclear from our analysis, but perhaps the threat actor leased computing on Microsoft's cloud services to host its command and control infrastructure.
The threat actors behind SMOKEDHAM use a very complex set of stages to get execution on the target system. The range of tactics is broad spanning from LNK files to VBScript embedded in HTML along with several powershell components and all the way to delivering and compiling the C# payload. These stages appear to be combined in different ways but have very similar looking patterns. For example, FireEye has a related post where elements of the same attack chain appear in their analysis with slightly different details [8]. In that FireEye report, the initial vector appears to be delivered via Trojanized software but a later stage pulls in a similar looking chain described in detail in this report.
Basic defense tactics for this attack include adding rules to block related indicators from this particular threat and also to scan your organizations logs to see if any user activity matches the indicators. The utility of this varies as the shopify and Microsoft related URL indicators are harder to block whereas the sol-doc[.]xyz domain appears to have no business value and is easier to block. Also, the specifics of this attack have likely changed since the initial research was done, but the general concept of blocking indicators and reviewing logs remains valuable.
For more advanced defense tactics, you can create deeper network rules to look for fuzzy matches in your network traffic. If you have the ability to observe process activity, you can investigate any computer running the standard Microsoft cmd.exe, mshta.exe, powershell.exe, and csc.exe utilities. However, the cmd.exe and powershell.exe in particular are likely to have wide legitimate use so it can be difficult to separate malicious use versus legitimate use. Tuning this search may require searching for more specific things such as mshta.exe with a URL argument or an LNK file calling cmd.exe. These suggestions are only meant to provide you with general ideas, however, as the specifics depend on your environment. To develop specific defenses, the question you need to ask is: "What are the potential choke points for this type of attack that are easy for me to see but hard for the threat actor to change?".
A layered defense is key to defeating threat actors behind SMOKEDHAM. Two very important parts of that defense are being able to identify and prevent activity. REnigma gives analysts the capability to identify, detonate, record, and replay attacks like this as a detective control, while Trinity Cyber prevents multiple stages of this attack from happening at a network level. This leaves basic defenses like IOC blocking and endpoint log triage in the dust. For more information on how Trinity Cyber and DTRSEC can help improve your defenses, see the section below on How We Can Help.
| Description | URL |
|---|---|
| Obfuscated URL in LNK File | hxxp://sol-doc[.]xyz/sol/ID-482875588 |
| VBScript via Redirection | hxxps://cdn[.]shopify[.]com/s/files/1/0562/9568/6349/t/1/assets/srv-ind.html |
| Powershell Launcher with Payload | hxxps://cdn[.]shopify[.]com/s/files/1/0562/9568/6349/t/1/assets/oZUBDcYSBljl.html |
| Command and Control Server | hxxps://r20swj13mr[.]microsoft[.]com |
| Name | md5sum | Size |
|---|---|---|
| sample.lnk | 6c9cda97d945ffb1b63fd6aabcb6e1a8 | 3622 Bytes |
| srv-ind.html | eb396bdca524542823c47a5592406bc7 | 1820 Bytes |
| oZUBDcYSBljl.html | 626493f7f5e6bd93aed7277181852dd3 | 146756 Bytes |
| cie2frab.0.cs | 929641c3828ed3c27eece2b2f4878ace | 13690 Bytes |
| Name | sha1sum |
|---|---|
| sample.lnk | ee55d03033a255747e015a601400072dd0e6a361 |
| srv-ind.html | 6ea4dd0a2c080127282ddd5007c161b2c4b2d47e |
| oZUBDcYSBljl.html | 6dea03c11aa60d116a3cf210ad469d4cb960a0eb |
| cie2frab.0.cs | b4d988cdc0dc5e3afb2db062fe73b43a7ad88dc8 |
| Name | sha256sum |
|---|---|
| sample.lnk | e5c94b799ad91049f97305b4ccff6e92e66f4da4d302177a8b578c3bb3f7cb43 |
| srv-ind.html | 2d597a179b9ba492aa1225576b1a61e8a0fd32642f3f4fbcb531341bbb4083a5 |
| oZUBDcYSBljl.html | 2248c7725df1ce033902e7560da7c99050bbb6d706646a634874f2dc151f40bc |
| cie2frab.0.cs | 5dbf604757f510432dccb7501e78e53cc75d97046333bbd0b4112943b66a33c7 |
Trinity Cyber is on the forefront of the cybersecurity industry, dramatically increasing the security of enterprises and governments by focusing on the tactics, techniques and procedures (TTPs) used by attackers. Trinity Cyber invented the industry’s first automated preventive control capability to prevent and defeat attacks by editing network traffic inline to make threats disappear. Their patented technology deeply inspects internet traffic in real time, bi-directionally, with full session-level awareness. At the same time, using powerful automated response actions developed by Trinity Cyber, malicious content is removed, replaced or modified to prevent attacks and protect customer networks - without adding perceptible latency or alerting adversaries – while still maintaining business continuity.
Recently, Trinity Cyber's Threat Analysis team conducted a step-by-step detonation of the SMOKEDHAM LNK dropper with the REnigma platform. They captured and replayed multiple stages of the attack and used the intelligence collected by REnigma to build the formulas to prevent this multi-stage attack for Trinity Cyber customers. When DarkSide techniques such as SMOKEDHAM droppers or PowerShell/VBS attacks are detected, the Trinity Cyber Flagship service automatically removes them from the network session, preventing SMOKEDHAM DLL payloads from exploiting customers.
Trinity Cyber can apply preventive actions to protect your business, networks, and users from DarkSide, SMOKEDHAM, and many other malicious threats before they infiltrate your networks. To learn more about why defeating attacker TTPs is key to preventing attacks and our groundbreaking preventive approach, please visit www.trinitycyber.com.
DTRSEC offers REnigma as a cutting edge technology to help operational teams (SOCs, MSPs, MSSPs, hunt, and CERT teams) and cyber security technology development teams investigate new threats and create countermeasures. For operational teams, threats similar to SMOKEDHAM are targeting your organization. REnigma provides you a safe place to investigate alerts, suspicious links, and emails to get more information and take action. The output of REnigma helps you quickly understand the threat to add new rules for blocking and monitoring your network, along with an API for automation of common work flows. REnigma also helps you understand potential choke points for new threats by providing a deeper understanding of the attack. For example, if a malicious LNK file similar to the one used by SMOKEDHAM is emailed to your employees, you can detonate it in REnigma to observe hashes, IPs, and system behavior. You can then not only add rules to block those indicators but can develop generalized rules based on a deeper understanding.
For technology development teams, REnigma enables your team to research cutting edge threats to enhance your tools. This gives you the critical data needed to improve your technology, thereby keeping your clients safe. REnigma provides a platform for analysis that offers a unique record and replay capability that drastically reduces the analysis effort to save costs and increase analysis capabilities. For example, by recording many variants of a new dropper like SMOKEDHAM, you can easily analyze the malware recordings in detail to find choke points to stop entire families of similar attacks.
DTRSEC can provide your business with access to our REnigma technology that uses a unique record and replay capability to help your analysts dig in deep and understand new threats quickly. The results feed into your tools and processes to help keep your network safe. For learn more about REnigma, please visit dtrsec.com.