Fileless Malware Already Targeting Holiday Suppliers

It gets earlier and earlier. The first Yuletide-related malware campaign has already been spotted. There’s always an expected and monumental amount of consumer spam and phishing in the run-up to Black Friday and then Christmas itself, but we’ve found one malware author getting into the Christmas “spirit” in late October by targeting backdoor-delivering emails at the Yuletide supply chain, specifically Christmas goods suppliers whose preparations for the year-end commercial convulsion are well underway.

According to the National Retail Federation, for some retailers the holiday season can represent as much as 30 percent of annual sales, and goods manufacturers and wholesalers in general are keen to take advantage, not to mention seasonal merchandise suppliers.

Fileless Malware from Known Author 

The email being sent for this campaign (Figure 1) uses the subject line “Christmas Order” with a made-up reference number, and proceeds to ask for pricing and delivery terms for items allegedly listed in an attachment, with the admonition that delivery is needed by November 20th. This last detail is a classic social engineering tactic, intending to give a sense of urgency to the recipient.

Opening the (apparently) .doc attachment, the user is asked to double-click an icon in order to view the contents. In doing so, a standard Windows security warning appears about running unverified software, and, unfortunately for those who ignore the warning, proceeding further detonates a RAR SFX (self-extracting archive), which runs a first-level AutoIt Script Loader Module. This in turn is used to decode and load a second-level payload. A step-by-step analysis of the deployment sequence is provided further below.

The final executable payload is a variant of the NetwiredRC backdoor. This payload uses the same custom Caesar Cipher and key used in a variant we recognized, as we covered it in one of our blog articles earlier this year, so it is safe to assume that the same culprit is behind this attack wave. Once installed, the backdoor has many capabilities, including but not limited to logging key strokes, stealing cookied login credentials stored in multiple browsers, and stealing email login credentials.

Since the entire installation sequence is injected to a target process and is not saved to disk, it can be classified as a fileless malware.

“Fileless malware” is a technique that has been a growing topic in security circles, and according to Cyren detection stats there has been a 350 percent increase in its use since 2016. Even though it’s a bit of a misnomer and not actually literally fileless, and is overhyped as “undetectable,’ it is part of a general trend in increasing malware “evasiveness.”Although fileless methods have a lengthy history, it’s appearing more now because detection methods have been catching up with other techniques, application whitelisting won’t stop it, and it makes attribution more difficult. If you need a good overview on fileless malware, we recommend this recorded webinar from a colleague of ours, which looks at the concept applied to ransomware, but the techniques described apply to malware generally, or this blog, which summarizes the concept.

Figure 1: Email soliciting proposals

Figure 2: Bait document that induces a click

Supply Chain Hack: Target Isn’t Necessarily You

The target of the email would appear to be smaller potential suppliers, but keep well in mind that that isn’t necessarily the ultimate target. The massive 2014 hack into Home Depot (resulting in 56 million stolen credit and debit card details and 53 million stolen email addresses), was credited to inadequate security at a small third-party vendor, as were the more recent hacks into Amazon Web Services and Wendy’s, as well as last July’s massive car manufacturers’ data leak.

A 2017 study by the Ponemon Institute, found that 56% of large breaches were the result of an initial breach into a third-party vendor, possible because many smaller suppliers are often granted access to their customer’s corporate data and even network login credentials. Another well-known manufacturing industry example was examined here.

How it Works: Self-extracting RAR Archive

As alluded to above, the loaded software is actually a RAR SFX, which contains several files having random filenames. Viewing the contents, we can see the files along with the SFX description and configuration settings:

Figure 3: Self-extracting archive with variable settings highlighted

Highlighted in the screenshot are the variable settings for the self-extraction process:

Update=U7WS52
Path=%temp%42057438

Setup=jsr.exe cec=rmq

The Path variable tells the SFX to extract the archive contents into the folder %temp%42057438, while the Setup variable auto-executes the file jsr.exe, with the argument cec-rmq. The auto-executed file, jsr.exe, in this case is a copy of the AutoIt stand-alone script interpreter, which loads the file cec-rmq, which is a malicious AutoIt script.

To make the AutoIt script difficult to read, cec=rmq is filled with a lot of comments, which in this case could be considered as plain garbage. Once the garbage is cleaned up, we can see that the actual code is just around 70 lines.

Figure 4: Comparative screenshots, showing script after removal of obfuscating “garbage code”

First Level Script: AutoIt Script Loader Module

The first level script is a loader module, which is used to decode and load a 2nd level payload, summarized as follows:

1. Upon execution of the AutoIt script, cec=rmq, it searches for a file named qch.pdf, which upon further inspection is actually a configuration (INI) file containing several variables used by the malicious script. The configuration file also includes two (2) pieces of encoded data, which are decoded at run-time. Shown below is a snippet of the cleaned up configuration file.

2. The first piece of encoded data, marked by [sData] and [esData], is decrypted by the script using an arbitrary shellcode embedded in the script. This arbitrary shellcode is an ARC4-based decryption algorithm, loaded by the script using the CallWindowProc API. The cipher key, 869, used in the decryption process is read by the script from the sK variable in the configuration file.

3. The decrypted data, which is another AutoIt script, is updated to replace the string “Settings File Name” to the file name of the configuration file (qch.pdf) before saving it to a randomly named file in the same directory as itself and executing it afterwards with the AutoIt interpreter (jsr.exe) as shown in the code snippet below.

AutoIt Script Payload Deletes Itself When Done

The decrypted script is responsible for the actual malicious behavior which could be summarized as follows:

1. For persistence, it creates an Auto-Start registry entry for jsr.exe and cec=rmq, to ensure that its loader module automatically runs even after the system is restarted.

2. Decrypts the second piece of encoded data from the configuration file marked by [Data] and [eData] with ARC2 decryption algorithm using the ADVAPI32 APIs. The cipher key, nkk, is fetched from the Keys variable in the configuration file.

3. The script then searches for a target host executable, where the malicious payload will be injected. If Microsoft .NET Framework is installed in the system, the script would choose RegSvcs.exe as it’s host and will fallback to the default web browser if neither v2.0.50727 or v4.0.30319 is found in the system. Additionally, if the variable eos is set in the configuration file, the script runs a copy of the target host executable in the Windows temporary directory using either RegSvcs.exe or firefox.exe as the file name.

4. Using an arbitrary shellcode embedded in the script, the target host executable is run in suspended mode where the malicious payload executable is then injected and executed, via the CallWindowProcW API.

Finally, after performing all needed operations, the script deletes itself to hide its presence in the system.

Indicators of Compromise and Cyren Detection