Blog

Archive for January 14th, 2021

Throwback Friday: An Example of Rig Exploit Kit, (Fri, Jan 15th)

Introduction

As this week winds down, I wanted to highlight a threat that’s significantly diminished in recent years.  For today’s #ThrowbackFriday, I’m reviewing an example of Rig exploit kit (EK) generated yesterday on Thursday 2021-01-14.

History of Rig EK

EKs are a malware distribution method.  They’re channels to send malware to vulnerable Windows hosts.  An EK’s payload is Windows-based malware.

Rig EK was discovered in 2014, back when EKs were much more common than today.  Like other EKs in 2014, Rig exploited Internet Explorer (IE) and browser-based applications that worked with IE like Java, Flash, and Silverlight.  Since then, people have increasingly moved to other browsers like FireFox and Chrome.  Because of this, EK activity began to decline.

Windows 10 was introduced in 2015 with Microsoft Edge as its default browser.  As more people switched to Windows 10, some EKs disappeared.  Rig EK continued to decline, with a substantial drop in 2017.  By 2018, Rig EK was one of only a few remaining EKs.  Today, people still discover examples of Rig EK, but it’s only effective against out-of-date hosts running Windows 7 and using IE.

To prepare for throwback Friday, I fired up a vulnerable Windows 7 host, opened IE 11, and entered a URL that led to Rig EK.

Gate to Rig EK

An HTTPS gate that leads to Rig EK has been active since December 2020:

  • hxxps://anklexit[.]online/twDGMjtfsacfa3e

On 2020-12-24, @nao_sec tweeted an example of Rig EK pushing SmokeLoader that contained the above URL.  Earlier this month, Rig EK from the same gate pushed Dridex.

URLs like this act as a gate to an EK.  This gate wouldn’t direct me to Rig EK when I tried it through a VPN.  However, tethering through my phone worked.  These gates are somewhat picky.  Use the gate once, and it might work.  But try it again from the same IP address, and it prevents you from reaching the EK again.  You generally have to wait 12 to 24 hours before the gate will work again, if you’re coming from the same IP address.

Traffic from an infection

See the below images for traffic from the infection.


Shown above:  Traffic from the infection filtered in Wireshark.


Shown above:  Rig EK landing page shown in an HTTP stream.


Shown above:  Dridex installer EXE sent by Rig EK as an encrypted binary.


Shown above:  Certificate issuer data for HTTPS traffic generated by Dridex installer.

To get a better understanding of Dridex infection traffic, see this Wireshark tutorial I wrote about it last year.

Forensics on an infected Windows host

While the Rig EK payload (an EXE to install Dridex) generated HTTPS command and control (C2) traffic, it wasn’t able to install Dridex on the victim host.  So I only saw the Dridex installer EXE.  I also captured a small file (approx 1 kB) of JavaScript text used by Rig EK before it was deleted during the infection process.


Shown above:  Artifacts from the infection caused by Rig EK.

Indicators of Compromise (IOCs)

The following are indicators from this infection.

Traffic from an infected Windows host:

  • 188.225.75[.]54 port 443 – anklexit[.]online – HTTPS URL – gate to Rig EK
  • 188.227.106[.]164 port 80 – 188.227.106[.]164 – Rig EK
  • 162.241.44[.]26 port 9443 – HTTPS traffic caused by Dridex installer
  • 185.184.25[.]234 port 4664 – attempted TCP connection caused by Dridex installer
  • 138.201.138[.]91 port 3389 – attempted TCP connection caused by Dridex installer

Certificate issuer data from Dridex HTTPS traffic to 162.241.44[.]26 over TCP port 9443:

  • id-at-countryName=DS
  • id-at-stateOrProvinceName=Tholend finck4
  • id-at-localityName=Khartoum
  • id-at-organizationName=Antymasu PEEC
  • id-at-commonName=anompatof.rip

Malware/artifacts from the infected Windows 7 host:

SHA256 hash: 209093c71d0e87df00a290c588a5147e1e14023402f317d7903c6402d52a87ee

  • File size: 98,819 bytes
  • File location: hxxp://188.227.106[.]164/?MzA1NTIz&pwDDc&AcAZl=pinny.866&shghfg[long string]
  • File description: HTML for Rig EK landing page

SHA256 hash: f14c7ba0240be3456164dd63f53dd4bc7eb34bcdb1ac26e98a623edc0390b56b

  • File size: 1,152 bytes
  • File location: C:Users[username]AppDataLocalTemp3.tMp
  • File description: JavaScript text file dropped by Rig EK

SHA256 hash: 0376f97c21d2f00bc9c0919ce108ef14a2b3b1b356b2caa502a6cae81c7798f2

  • File size: 1,198,592 bytes
  • File location: C:Users[username]AppDataLocalTempjv9qx.exe
  • File description: Rig EK payload, Windows EXE to install Dridex malware

Final Words

Pcap and malware/artifacts for this diary can be found here.

I wonder how it long this method of malware distribution will remain profitable.  Apparently, enough people currently use out-of-date vulnerable Windows hosts.  I guess this presents a big enough target base for the people behind Rig EK.

Every time I find Rig EK, I think back to all the entries I posted on my blog from 2013 through 2016 featuring Rig and other EK infections.  That’s why I consider today’s diary a #ThrowbackFriday.


Brad Duncan
brad [at] malware-traffic-analysis.net

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Dynamically analyzing a heavily obfuscated Excel 4 macro malicious file, (Thu, Jan 14th)

Recently I had to analyze an Excel malicious file that was caught in the wild, in a real attack. The file was used in a spear phishing attack where a victim was enticed into opening the file with Excel and, of course, enabling macros.

The image below shows what the file looks like when opened in Excel:

Malicious document

As you can see, it is a very common malicious Excel file where the victim is supposed to click on the Enable content button to see the document. Of course, once the victim does that it is game over and the machine gets infected. My goal was to analyze the malicious Excel file to identify what exactly it is doing.

Typically, the first step to analyze such a document would be verify macros with Didier’s oledump.py tool, which is the de-facto standard malicious document analysis tool (the FOR610 instructors are joking that Day 3 of FOR610 is Didier’s day, since he wrote so many useful tools).

However, as you can see below, I was a bit disappointed to see that there are no macros – this normally means that the attacker is using Excel 4 macros – an old way of creating active content:

$ python3 oledump.py ~/source.xls 
  1:      4096 ‘x05DocumentSummaryInformation’
  2:      4096 ‘x05SummaryInformation’
  3:    162264 ‘Workbook’

Both Didier and Xavier wrote a number of diaries about analyzing Excel 4 macros (available here and here), so the next step was to use the BIFF plugin Didier wrote, which allows output of BIFF records – these hold Excel 4 macros (formulas really), so let’s do that:

BIFF plugin outputOk, we’re getting somewhere, however there were thousands of lines like this in the output:

ErrorsNot nice. This means that Didier’s BIFF plugin does not know how to parse these bytes, which define a currently unknown formula. Didier also wrote about another tool that can be used to deobfuscate malicious Excel files, XLMMacroDeobfuscator (read the diary here) so I thought about trying that as well:

XLMDeobfuscatorHmm, a bit better but we still do not know what exactly this file is doing. There are two important things we can see in XLMMacroDeobfuscator’s output though:

  1. First, we can see that there is a cell with the name of Auto_Open. The contents of this cell will be executed (if it is a formula) automatically when this Excel file is open, after the user has clicked on the Enable content button, of course.
  2. Second, we can see that the last two functions that are called are WORKBOOK.UNHIDE and WORKBOOK.HIDE. These do exactly as their names say – they will hide one workbook and unhide another – this will result in the final, decoy content to be shown to the victim (no screenshot, sorry, as it contains sensitive information about the target).

Armed with this knowledge I wanted to dig further into the file. While most researchers might prefer static analysis since it is safer, in this case such analysis might be very difficult or time consuming. The main reason is that the tools we have on our disposal failed to completely parse the document (as shown above) and, besides this, the file is heavily obfuscated with a number of formulas and calculations that are performed automatically by Excel.

So, I decided to go with dynamic analysis of the file – cool thing is that, at least for this case, we do not need any other tools but Excel. Of course, by running malicious code we will be putting ourselves to risk, so if you ever need to perform a similar analysis, make sure that you do it in a VM, without Internet access (or you will be really living on the edge).

Since this malicious document does not have a VBA macro, it relies on executing formulas. Excel will generally execute formulas top to bottom in a column, then move to the next column and so on. This does not necessarily has to be in this order, but in all cases I have checked it was. Our first step will be to find the cell (formula) that gets executed first – XLMMacroDeobfuscator already told us that it is a cell in the “Sheet_vrg” tab of this document, and that the cell is $HV$19420 (column HV, row 19420). We can also see this by opening the malicious file in Excel (notice I am not enabling content yet!) and then going to Formulas -> Name Manager. We will see this very same cell displayed, as shown in the figure below:

Excel Name Manager

Let’s scroll now to this cell to see what its contents look like:

Cell

Aha – this is actually what XLMMacroDeobfuscator showed to us, but it partially evaluated the contents so we still do not know what this code actually does. So let’s see how we can dynamically analyze this document. Excel actually allows us to manually evaluate any formula shown in the document. All we have to do is right click on a cell, but the catch-22 here is that we have to click on Enable content in order to do that, and by doing this we will execute the malicious macro.

The solution is, luckily, relatively simple. A function called HALT() exists that does exactly what the name says, so we can manually insert this function in a free cell and then change the Auto_Open name to point to our cell. What’s even better – in the image above you can see that there is already a cell with the =HALT() function (it’s the last one), so let’s just change Auto_Open to that cell:

Halted

Now we can safely click on the Enable content button and nothing will happen! We will stop at the =HALT() function but we can now inspect other cells and contents around this file.

Since the document is heavily obfuscated, we will want to somehow debug it – single step through it. In this particular case, this was not all that difficult, but keep in mind that with a very complex and obfuscated document, the following activities might be more difficult to perform (but still easier than performing static analysis).

What we will want to do here is (ab)use the =HALT() function to execute a formula in a single cell and then stop the execution. This will allow us to examine what happened, evaluate the formula and continue. In the example below, you can see that I copied contents of all cells under the first one (the original Auto_Open cell) and put =HALT() in the cell immediately after the first one. This will cause Excel to stop processing formulas:

We can now use Excel’s built-in evaluation. In order to do that we will right click on the first cell, select Run and then Step Into. This is what we will get:

Pretty cool! Notice that nice “Evaluate” button? Let’s see what it does:

So this is what the first cell does! Depending on how complex this is, we might need to click on “Step Into”, which will take us further down the rabbit hole (Hi Neo!) and we will start evaluating whatever is under this particular function. Since I was impatient I clicked on “Continue” – remember that I put our “breakpoint” with the =HALT() function and this will be kind of similar to pressing F9 in your debugger.

In this document there was a bunch of functions called by the top one – most of them actually deobfuscated various content which is now populated in “new” cells in this worksheet. Keep this in mind – a nasty document could actually change contents of our =HALT() cell, which would lead to the payload fully executing.

Since it was not the case here, we continue by shifting the =HALT() breakpoint to the next row, like this:

You can probably guess what we’ll do next – right click on the =REGISTER() cell, click on Run then Step Into, and this is what we get:

Let’s Evaluate this again – it should work because the cell that got executed before populated what this (currently executing) cell needs:

Interesting! The REGISTER() function allows us to create a defined name which will point to a function in an external DLL. Sounds fantastic for the attacker – what they are doing here is create a name called “bBpmgyvS” which will point to the CreateDirectoryA function in the Kernel32.dll library. It is quite clear that the attacker will want to create a directory on the local machine.

And now it is rinse and repeat – we use the same method to evaluate all other cells until we figure out what the document is doing. The one I was analyzing uses the same mechanism to create another name that points to URLDownloadToFileA from the URLMON.dll library, which is used to download the second stage binary.
The same mechanism is again used to create a name that points to ShellExecuteA function from the Shell32.dll library which executes the downloaded binary.

At the end, the attacker hides this sheet and shows a decoy one.

And this leads us to the end of this diary/tutorial. I hope you found it interesting and useful, and that it will help someone analyze such heavily obfuscated Excel 4 macro malicious files which, this time with help of Microsoft’s own Excel can be relatively easily dynamically analyzed.

Finally, I have to stress out one more time that you should be ultra careful when performing such an analysis since we will be executing malicious code.
 


Bojan
@bojanz
INFIGO IS

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →