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.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s