MuddyWater (11-23-2019) – Part 2: Macro analysis and dropped file

Continuing from part one, we can now use Microsoft Visual Basic for Applications to step through the macro and see how it works.

First things first, the macro starts here with Workbook_Open().

muddywater_11.png

It calls a function called irnqdecjko. In this function, we see multiple calls to another function called irnqdxjwko which is fed a number.

muddywater_12.png

Function irnqdxjwko takes the parameter fed and uses it to query a form named F. It will take that text from form F and split it on the periods and toss it into an array called h.

muddywater_14.png

muddywater_13.png

In this case, the fifty-second item in array is chosen and saved to variable g. Here is the fifty-second item in that array:

0147016101460185019101320125013601620117010001060140

That value is then tossed into another function called irnqdkjdkoIrnqddjdko will then decode that string. It takes four characters of the array at a time, does an xor a few times amongst some other manipulations and outputs it to variable g. This loops again and again until it is done.

muddywater_15.png

Those two functions are called over and over again throughout the entire macro. Below is the main function that does most of the heavy lifting for this macro.

muddywater_16.png

The first part sets up the WScript.Shell object and some other variables. I’ve added the decoded values.

muddywater_17.png

We can see that the CallByName is used throughout this macro. It gets fed parameters such as RegWrite and to what those registries should be set.

muddywater_18.png

The next section edits the \CurrentVersion\Run\ registry to have wucj.exe execute a file called zdrqgswu that gets dropped in the TEMP folder. According to this article, wucj.exe is just a copy of wscript.exe.

muddywater_19.png

Ultimately, this macro makes use of wscript.exe to run the dropped file named zdrqgswu. What does this file do? (by the way, you can download it —-> HERE <—-)

muddywater_20.png

I’m not going to go into too much detail here, but a quick overview…

  • Variable blhcqkvwge gets decoded in line 14 and stored in variable hdupqjaiot.
  • The strings in lines 23 and 24 get decoded using function jhohvgaemi. They decode to “ScriptControl” and “JScript” respectively.
  • This means that line 29 is really “JScript.Eval(hdupqjaiot)”.

And what exactly is in hdupqjaoit? Here’s a partial output:

muddywater_21.png

And we can finally see the URL to which it reaches out.

Thanks for reading!

 

MuddyWater (11-23-2019) – Part 1: VBAProject password and .xls documents

tl;dr – Use compatibility mode  to turn an .xls document into an .xlsm. Then you can unlock the VBAProject at your leisure.


What follows isn’t that difficult, but I thought I’d step through it anyway. It might save someone else some pain (or at least a self-induced forehead slapping moment).

This document came across my feed the other day and thought I would take a look.

muddywater_02.png

You can find that document on any.run. Click on the link below to get a copy for yourself.

————–>  HERE IS THE LINK TO THE DOCUMENT. RIGHT HERE  <——————-

Anyway (lol), the macros could be extracted from it quite easily. I’ll look at them more carefully in a bit. The next thing I did was open the document and enable the macros to see if any new processes like cmd.exe or powershell pop up anywhere. It was unusual that nothing did.

This means we need to take a more careful look at the macros and see what they’re all about. However, opening the document, hitting ALT+F11 to open Visual Basic for Applications gives us its demand for a password.

muddywater_01.png

Of course, that’s no big deal. We’ve dealt with this before. All we need to do is turn the .xls file into a .zip, open it up, extract the vbaProject.bin file, edit it with a hex editor and we’re good.

But no. If we treat this file as a .zip, we end up seeing these next to useless files:

That is because this is an .xls document. Pre-2007, .doc and .xls documents used Microsoft’s proprietary binary format. After 2007, Microsoft used their Open Office XML format to represent documents, charts, and more.

How does this help us? If we can open this .xls document and convert it to an .xlsx (or .xlsm) document, it should allow us to unzip the file and edit that vbaProject.bin file to get around that pesky password. We cannot, however, just change the format of the file by adding an x at the end of .xls. We need to open the document and convert it this way.

muddywater_07.png

muddywater_09.png

Open the document as an archive, navigate down into the \xl\ subfolder and you’ll see vbaProject.bin. Extract that file, open it up with a hex editor, search for the string DPB, replace it with DPx, save changes, and toss the .bin file back into the .xlsm document.

muddywater_08.png

Open the document, ignore errors, hit ALT+F11, right-click on the project, choose VBAProject Properties, click on the Protection tab, and uncheck the “Lock project for viewing” box. Save the document one more time, open it back up, hit ALT+F11 and you’ll see…

muddywater_10.png

Now couldn’t we have just looked at the macros that we dumped earlier? Yes, but the benefit of being able to do this is that we can use the debugging capabilities here to interact and watch how the macros work.

That will be the next post. Thanks for reading!

Formbook (11.18.2019) – Unprotecting a sheet in an Excel workbook

In order to make analysis tougher, your typical attacker will obfuscate the macro code in some way. Attackers will also set up other road blocks to slow you down in your analysis. We’ve seen that attackers will password protect some portion of the document, whether it is the macro or something else.

There are ways to get around these password protections. A simple google search will bring back tons of results, but which will actually work?

The document we’ll be working on in this post was a bit unique. It downloads an executable that Any.run identified as Formbook. How it gets to that point is kind of interesting. It turns out that you can add links to a spreadsheet and when you “Enable Content”, the document will try to reach out to those URLs and download things.

How convenient.


Round 1: Me – 0   Document – 1

First things first. The normal analysis I do on documents didn’t yield any results. OfficeMalScanner didn’t dump out any macros at all. If you open the document and go to VIEW -> Macros -> View Macros you still won’t see anything. And if you really want to make sure that your eyes aren’t deceiving you, hit ALT+F11 and you’ll just see the three worksheets and a whole lot of empty space where there are no macros. Just like the tools said.

formbook01.png

Right-click on the sheets, choose ‘Project Properties’ and nothing is locked or password protected at all.


Round 2: Me – 0   Document – 2

Next, let’s try treating the .xlsx document as a .zip file. We can do this by simply changing the extension to .zip, extracting the contents, and we should be able to explore all of the .xml files and see what’s going on under the hood.

Nope. Here’s what we get instead. Dig all you want through these folders/files, you won’t find anything useful.formbook02.png


Round 3: Me – 1   Document – 2

After a hefty bit of googling and poking around at the document, you would get directed to this part of the document. We can see that this is where you would protect the document with a password. If you click on ‘Unprotect’, the password dialogue box will pop up.

formbook03.png

And all we would need is that darn password. Aside from using some sort of password cracker (which, admittedly, would be fun), I tried a method that added a new macro to the document which will brute force the password and present it in a dialogue box. And it actually worked!

Yeah, I was surprised, too.

So, open the document and hit ALT+F11 to open up Microsoft Visual Basic for Applications. Double-click on Sheet1(????1) to get a blank macro going. Copy and paste the code below into the macro window thingy:

Sub PasswordBreaker()

Dim i As Integer, j As Integer, k As Integer
Dim l As Integer, m As Integer, n As Integer
Dim i1 As Integer, i2 As Integer, i3 As Integer
Dim i4 As Integer, i5 As Integer, i6 As Integer
On Error Resume Next
For i = 65 To 66: For j = 65 To 66: For k = 65 To 66
For l = 65 To 66: For m = 65 To 66: For i1 = 65 To 66
For i2 = 65 To 66: For i3 = 65 To 66: For i4 = 65 To 66
For i5 = 65 To 66: For i6 = 65 To 66: For n = 32 To 126
ActiveSheet.Unprotect Chr(i) & Chr(j) & Chr(k) & _
Chr(l) & Chr(m) & Chr(i1) & Chr(i2) & Chr(i3) & _
Chr(i4) & Chr(i5) & Chr(i6) & Chr(n)
If ActiveSheet.ProtectContents = False Then
MsgBox "One usable password is " & Chr(i) & Chr(j) & _
Chr(k) & Chr(l) & Chr(m) & Chr(i1) & Chr(i2) & _
Chr(i3) & Chr(i4) & Chr(i5) & Chr(i6) & Chr(n)
Exit Sub
End If
Next: Next: Next: Next: Next: Next
Next: Next: Next: Next: Next: Next
End Sub

It should end up looking like this. All you need to do is run the macro by pressing ‘play’ or hit F5.

formbook04.png

Once you do…

formbook05.png

… you find out the password used to protect the worksheet! Plus, it does the added job of unprotecting the worksheet for you. You’d have to save the document at this point to keep the worksheet unprotected. Or you could choose to discard the changes in order to test out the password.


Round 4: Me – 2   Document – 2

With the document worksheets now unprotected, we can take the document, change the extension from .xlsx to .zip, extract the contents, and analyze the files therein. Doing so gives us something that looks like this:

formbook06.png

I highlighted the \xl\externalLinks\_rels subfolder because that’s where we’re going to find the URL that downloads the executable.

formbook07.png

And this is why there were no macros. Even though enabling content just screams, “You’ve got macros!” it doesn’t necessarily mean that is the case.


Postscript

The rest of that unzipped folder structure still deserves more investigating. By poking around I did find an easier way to find the URL. If you look at the Info tab of the document, you can see a button (?) called “Edit Links to Files”. Click on it and you’ll see the URL right there.

formbook08.png

Now I’ve seen other malicious documents where the base64 encoded string is sitting in the document properties. So this location is definitely a place to look for strange things. But there are no guarantees that strange things will always be there.

As always, thanks for reading!

Dreambot (11.13.2019) – Document analysis

A few days ago, this tweet by @w3ndige came across my feed:

dreambot01.png

FINALLY. Something that isn’t Emotet! Thought I’d take a look at it and see what it looks like under hood. It did not disappoint.

If you’d like to play along, the document can be found here.


MACROS

After extracting the macros, I noticed that there were more than a typical Emotet document. And two of them were rather large.

dreambot02.png

A cursory look at the files shows them to be heavily obfuscated. There’s just garbage all over the place.

dreambot04dreambot05dreambot03

However, some of those strings kind of look like they are base64 encoded. This means it is worth paying attention to them and see how they’re being used. We can do this by following the variables and seeing where they lead us.

dreambot_combo01.png

And it ends up in a line with a ‘ShellExecute’? Looks like we definitely want to pay attention to that.


BEHAVIORAL ANALYSIS

At this point we can go one of two ways. We could open Process Hacker and use that to monitor what happens when we open the document and ‘enable content’. Some new process should start up. Emotet uses WmiPrvSE.exe so I’d be surprised if this one did, too. It could be also be a child process of WINWORD.EXE. Powershell, perhaps? CMD.EXE? Once something pops up we could double-click on that process to see what command line is being run with it.

Or we could open the document and inspect the macros using Microsoft Visual Basic for Applications. We could then set a breakpoint on the line with “Document.Application.ShellExecute”, run the macro and wait for it to stop at the breakpoint. This will allow us to inspect the variables and see how this command is being run. Doing so gives us the output below.

dreambot09.png

And what do we see? Looks like some base64 encoded fun to me.

lpZlNxkkO.Document.Application.ShellExecute powershell.exe -enco JAB4A...

However, that’s not the whole line of base64. It seems to me that the rest of that line (with all of the StrReverse, nested functions, and a ton of 3’s) will create the remainder of it. Feel free to step through the rest of those nested functions by pressing F8 a couple hundred times.

As I mentioned earlier, you can just enable macros and wait for something to pop up. In this case it is powershell. Just double-click on it and you’ll see the full command line.

dreambot10.png


CODE ANALYSIS

The first thing I noticed about that string is that it is about twice as long as your typical encoded Emotet string.

dreambot11.png

But a little Cyberchef later (‘From Base64’ + ‘Remove null bytes’) and you get this output. As usual, there is a bunch of extra lines of garbage. But we can see that the URL pops out.

dreambot12.png

The rest of code isn’t overly complicated. But it is beneficial to go through it so we can see how the downloaded executable gets renamed, where it lands, and how it gets executed. Here’s the code all cleaned up. I found the use of regsvr32.exe to be unusual.

dreambot13.png

Here’s the downloaded executable being run in Any.run (please excuse my lame typing). Any.run calls it Ursnif/Gozi, but @W3ndige believes that it is Dreambot as the configuration uses TOR DLL entries. For a more thorough write-up of Dreambot, I’ll direct you to @W3ndige’s blog where he looks at a sample from 11.13.2019. In my opinion, it is a very well done write-up.

Thanks for reading!

Vidar maldocs (11.6.2019) – Extracting the shellcode and finding the URL

We will be working off of this document today. It is another document that ends up downloading an executable that any.run identifies as vidar. But how do we get from the document to downloading the executable? Let’s find out.

After extracting the macros, we can see that they are very similar to the document we saw the other day. However, there is a significant difference. In this case, the strings that become the shellcode are hidden elsewhere in the document.

How then can we get at that shellcode? If you’ll recall, the macros in these documents create some space in memory, place the shellcode there, and then execute it. If we can set a breakpoint in the macro after the shellcode is placed in memory but before it executes, we should be able to extract it. See below:

vidar11.png

Remember, s2 contains the memory address of variable s1. In our instance, s2 = 235423969 (0x0E0848E1).  vp stands for VirtualProtect and will change that memory space to read/write/execute.


Extracting the code from memory: Process Hacker

Opening Process Hacker, we can double-click on the WINWORD.EXE process to look at it’s properties. Choose the Memory tab and we can see all of the regions of memory used by WINWORD.EXE. All we need to do is scroll down to the appropriate base address and expand it.

In this case, the hex address we’re looking for is 0x0E0848E1. This would fall between 0xdd00000 and 0xe100000. Expand 0xdd00000 and we can see 0xe08400. Note also how the Protection column notes that section of memory as RWX.

vidar12.png

Double-clicking 0xe084000 shows us the actual information in that section of memory. Scroll down to 8E1 and you can see the code. You can save this entire section and inspect it later at your leisure.

vidar13.png


Extracting the code from memory: x32dbg

Another way to get at the shellcode is to extract it by using a debugger like x32dbg. There are probably multiple and more efficient ways than how I will be proceeding. But I will be setting a breakpoint at 0x0E0848E1 in order to get to that location and find the shellcode.

To do this, open x32dbg.exe and attach it to WINWORD.EXE.

vidar14.png

It will take a few moments for x32dbg to attach itself to the process. But when it does you will see assembly in all of its glory.

vidar15.png

We would like to jump to the code stored in 0x0E0848E1. Type the following in the Command line near the bottom of the screen and hit ‘enter’.

vidar16.png

We can then click on the “Breakpoints” tab near the top of the screen and see that a breakpoint has been set at 0x0E0848E1.

vidar17.png

Double-click on that location and you will be brought back to the main screen. However, down in the memory dump section, you will see the address of 0x0E0848E1 and the resulting code stored after it. You can then copy and paste that code and store it for examination.

vidar18.png

But what can we do with the results? Here is the ASCII from above stored as a .bin file.

vidar19.png

Upon visual inspection, we can see what looks like might be a URL of sorts… but everything is all jumbled up. How can we make sense of this?


Disassembler to the rescue! (sort of)

A disassembler can take an executable (or the binary above) and translate it into assembly language. I will be using IDA Pro (the free version). Toss ascii.bin into it IDA Pro, choose all of the defaults, and you will be presented with something like this:

vidar20.png

If we had a billion dollars (give or take), there is a wonderful plugin that can be purchased to turn all of this assembly into actual readable code. However, I don’t have a billion dollars.

Therefore, we will have to be a bit more manual with this one. Scrolling down a bit, we can see a long series of push commands. Each push command takes the data after it and pushes it down onto the stack. Once it is done, it can be called by some other function.

vidar21.png
Push it real good.

In this case, all of the information that is being pushed are a bunch of hex characters. To convert them to a readable string, we can click on them and hit the R button (or right-click and choose the line starting with ‘x’).

vidar22.png

Continuing down the line we get to the end where we see this pop out:

vidar23.png

That last line contains a backwards http. If we keep tracing it backwards, we can see the rest of the http://162.218&#8230; and so on. Some manual copy/paste could be done at this point and you could reconstruct the URL. I took it and used CyberChef to remove the single apostrophes and reverse the string. However you choose to do it, this string gets assembled into:

hxxp://162.218.210.202/WQRrAzdICaGh7THV/DbegcjODZNhoeY10.php?fUwWF7e6PoMQXA~~=GQ3zv9e44z7-my6fV4QTvsCr8fYItc6ubAjqaahhBF9E_KTa7ck6uZkLb0C6EpAoKus~

And as we saw earlier, it downloads vidar.

Thanks for reading.

Vidar (11.1.2019): Document Analysis

This document came slip-streamed as a reply to a previously existing email conversation. I’m always surprised when a malicious document isn’t Emotet and this was no exception.

Also, shout-out to @malwaresoup for help with the macro and pointing me in the right direction!


Part 1: Quick overview

Extract the macros however you see fit. I’m always a fan of OfficeMalScanner. However you get them, I noticed that the main macro commands weren’t obfuscated at all. We can see that variable s contains a large string of some sort. But it is rather strange that everything else is out in the open.

A quick attempt at behavioral analysis doesn’t give much information either. There was no powershell.exe or cmd.exe processes spawning from WINWORD.exe where we could quickly grab a command line or two. WmiPrvSE.exe wasn’t used in any way, either. This just means we’ll have to do a little more work in order to understand what variable s is hiding.


Part 2 – Unlocking document

To investigate the macros and see what they’re doing, we can open the document and press Alt+F11 to open Microsoft Visual Basic for Applications. Double-clicking on the project shows that it is locked.

vidar05.png

Remember, this means that the vbaProject.bin file inside the malicious document is password protected. I wrote before on the steps to get around this here. Basically, it involves changing the document to a .zip file, copying the vbaProject.bin file elsewhere, editing the .bin file with a hex editor, copying the edited file back into the appropriate .zip folder location, and finally changing the extension back to .docm.

You’ll see some errors pop up when you open the document, but they’re safe to ignore. Hit Alt+F11 again to get back to the project. Right-click on it, choose Project Properties, and uncheck “Lock project for viewing”. Save your changes, re-open the document and you should be good to continue.


Part 3 – Macros explained

The main portion of the macro is below. This is where string s gets transformed and then executed. How exactly does this work? Please, correct me if I don’t get this right.

vidar06.png

Line 249-250: Take characters from s two at a time; prefix them with “&H”; Val() transforms it to decimal; subtract that from 255; add to array called s1.

Line 257: This line is interesting. “VarPtr will always return the address to the content of the variable itself. What is stored there depends on the type of the variable…” So this command is finding the memory address of variable s1.

Line 258: vp is short for VirtualProtect. This command “changes the protection on a region of committed pages in the virtual address space of the calling process”.

vidar07.png

Matching this up with what we see, lpAddress is the location of s2, dwSize is 2000 bytes, and flNewProtect is 64. 64 is 0x40 in hex, which means that memory space is set to Page_Execute_ReadWrite. Lucky us!

Line 259: SetTime creates a timer. In this case, the time-out value is set to 10 milliseconds and the function to be called is located at s2.

Line 261: DoEvents will “yield execution so that the operating system can process other events.” It seems to me that other event will be the one located at s2.


Part 4 – Extracting shellcode (almost)

So what exactly is living at the address space listed in s2? In this case, the memory address in s2 is 236183625. Translate this to hex and you get 0xE13E049.vidar08.png

ProcessHacker allows us to look at the memory space used by WINWORD.EXE. Digging down into address 0xe13e000, we can find the beginning of what is stored in 0xe13e049. We can then save this data out to a file and inspect it at our leisure. I’m warning you that it isn’t very pretty.

vidar09.png

@malwaresoup suggested to attach a debugger (Ollydbg, x64dbg), set a breakpoint at 0xe13e049, run the code up to that point and dump the output… but I haven’t gotten to that yet. Maybe later. Although, if you inspect what gets dumped above, you’ll sort of see the URL for what gets called next. However, it is a bit jumbled up.


Part 5 – After the document

Way back at the top, I had a link to the document we are investigating. It showed one single connection to 64.188.25.166. Looking at that IP in VirusTotal, we only a few hits (at the time of this writing).

http://64[.]188[.]25[.]166/dOKqVBkkFlT38ayb/DPBlYhgYpVZ20QbL.php?j1VngrKMpL2TAQ~~=PHoqfTy3oiRTCXqVeVNSAKbZAj4cLHXA4HsZetg4GMDUjIzrReJ2XqiSh8VR-cKPhMY~

That URL downloads a file called “wisptis3.exe“. And any.run tags “wisptis3.exe” as vidar!

Thanks for reading!