By Nathaniel Raymond

A relatively small malicious car insurance/financial-themed email campaign has been landing in inboxes since late January of this year. These basic malicious emails promise the user a large financial sum via an invitation to click the embedded marketing or Google Ad link that leads to a believed compromised website, blawx[.]com, where they can download the instructions to claim their lump sum of money. The website was re-designed to support the theme of the email and supply another link to download the “instructions.” However, the link on the website delivers a JavaScript file that begins infecting the victim’s Windows machine with a modified version of the legitimate software known as NetSupport RAT to gain unauthorized remote access to the user’s machine. These emails are unique because they are basic in their creation, use legitimate marketing and ad links, and do not deliver the payload immediately to avoid detection and increase the chance of landing in a user’s inbox.

Key Points

• A small, basic, straightforward financial/insurance-themed email campaign has been observed landing in inboxes that deliver users to the compromised site blawx[.]com through a URL shortener, gg[.]gg/carzzz. 
• The link consists of legitimate marketing and Google ad service URLs with the shortened URL attached as the secondary redirect. 
• The infection starts with downloading a JavaScript file from the website that retrieves, downloads, and runs NetSupport RAT through several stages of other JavaScript payloads. 

Keep It Simple Silly

Regarding malicious email campaigns, it seems that threat actors only use “advanced tactics” to bypass secure email gateways (SEGs) and other email security suites today. While that has some truth, malware infection often starts from more basic emails that make it past SEGs. What is meant by being basic? Threat actors often use advanced obfuscation techniques inside their emails to help get past SEGs and to help defend against other detection methods, such as YARA rules. The NetSupport RAT emails analyzed in this strategic analysis are as basic as they come and still manage to bypass email security. They do not use images, either embedded or attached, or use any obfuscation to deter detection. The emails in Figure 1 showcase the simplicity of using a text block and an embedded link to avoid detection. 

Figure 1: Email samples. 

Even though the body of the email is basic and contains a spam and scam-like wording structure, these emails still make it through spam filters, SEGs, and other email security. This shows that no matter the threat actor’s skill level, even a novice-skilled threat actor can create malicious emails and have the potential to become a serious threat to businesses and assets. Basic and simplistic emails such as those in Figure 1 can also help threat actors become flexible as there are fewer moving parts, less to think about and obfuscate, and it makes it easier to switch to other types of malware thanks to the generic nature and simplicity of the email. 

Adding A Veil of Legitimacy 

While the simplicity of these emails helps them go undetected, they still need to deliver the link and the payload, which can get these emails detected by email security. However, the campaign uses primarily legitimate Google ad links to avoid detection and improve the email’s chances of reaching the inbox while delivering the link to the payload.

Figure 2: Embedded link examples.  

Although the links used are from Adjust and Google’s DoubleClick ad marketing services, Figure 2 shows another URL at the end of the marketing URL strings, gg[.]gg/carzzz. Marketing links can get long and often filled with information in the URL that gets reported back for campaign tracking purposes. Threat actors can use this to their advantage and attempt to hide other URLs within them so it is not readily apparent where the link goes. Often, marketing links may also obfuscate the target URL, hiding it from the user entirely and giving threat actors who use it a significant advantage. 

So, You Clicked the Link 

Clicking the embedded link does not start the infection process. However, it gets the user closer to that threat actor’s objective. Clicking the link takes you to a compromised website named blawx[.]com. It has been determined through historical and archival evidence that blawx[.]com used to be used for legitimate purposes. However, the website was redesigned to perpetuate the email’s theme of delivering financial relief. Such themes are always enticing to users, especially during major financial crises, adding to the chance of a user clicking on the link in the email.  

Figure 3: Redesigned blawx[.]com to fit the email theme. 

Upon clicking the link, the user arrives at the landing page showcased in Figure 3. Here, the user is met with more enticement of financial payouts from the American federal government and a link to download the instructions on how to claim the payout. However, clicking this link downloads a JavaScript file that will download several other JavaScript files that will ultimately download, extract from an archive file, and run the NetSupport RAT.  

The Infection Chain

Digging into the initially downloaded JavaScript file, we can see a URL address in the source code shown in Figure 4 as the second stage payload. Once executed, the file reaches out to blawx[.]com/letter[.]php to download the next stage.  

Figure 4: Second stage payload URL in stage one source code. 

The next stage consists of another JavaScript file named “update.js,” which contains PowerShell code to be executed by the first stage JavaScript file in memory. Note that the code in Figure 5 is the first half of the second stage code and has been modified to best showcase the PowerShell code being executed during the third stage. During the second stage execution of PowerShell, a final URL is reached out to download the final payload.  

Figure 5: First half of stage two JavaScript file containing PowerShell code. 

In Figure 5, boxtechcompany[.]com/1/GetData[.]php is the last of the payload URLs. The final payload is a ZIP archive file containing all the necessary files to run NetSupport RAT, shown in Figure 6. 

Figure 6: Archive file containing NetSupport RAT and all supporting files. 

NetSupport RAT

We must remember that while NetSupport RAT is used for malicious purposes in this instance, NetSupport is a legitimate remote software company. This means that not all files in the archive are malicious, and care must be taken when reporting indicators of compromise. However, at least two files stand out the most in this archive, “client32.exe” and “Client32.ini”. When searched by hashes in places like VirusTotal, the executable’s hash is revealed to be our malicious program. To ensure this program is malicious, we can look back into stage two and see the other half of the file and the executable executed by our PowerShell code in Figure 7. 

Figure 7: Stage two JavaScript file running downloaded executable. 

Indeed, the “client32.exe” application is run by the PowerShell code when stage one JavaScript file executes stage two. The PowerShell commands also introduce persistence onto a victim’s machine as well. The “HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run” registry key is set to execute the malicious application every time the user logs on. 

Once NetSupport RAT runs on a victim computer, it will beacon out to a command and control (C2) to notify threat actors that the PC is ready for unauthorized access either by the threat actors themselves or the access to be sold on the dark web. This can lead to further infections and persistence, stolen assets, and even ransomware. A typical NetSupport RAT C2 comes in a file mentioned earlier, “Client.ini” shown in Figure 6. The “Client.ini” file is a configuration file that contains multiple keys and values that initialize the NetSupport RAT connection to its C2, as showcased in Figure 8.

Figure 8: Client.ini remote connection initialization config.

The “Gateway Address” highlighted in the file tells us where the C2 will likely be. We can double-check this by running the executable and observing the Wireshark output. In Figure 9, we have matched the output from Wireshark’s IP address to the one in the config. Also, in the Wireshark output, we can see that “/fakeurl.htm” has been appended to the IP address, further solidifying this IP address as our C2 for this NetSupport RAT sample. 

Figure 9: Wireshark C2 communication.