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 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:


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.


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.


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.


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.


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’.


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


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.


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


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:


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.

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’).


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


That last line contains a backwards http. If we keep tracing it backwards, we can see the rest of the http://162.218… 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:


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.


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.


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”.


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.


@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 Looking at that IP in VirusTotal, we only a few hits (at the time of this writing).


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

Thanks for reading!