August 2020 – SecurityLiterate.com

Chantay’s Resume: Investigating a CV-Themed ZLoader Malware Campaign

By d4rksystem | August 19, 2020

One beautiful and sunny evening, I happened to be poking around VirusTotal – because that’s what I do with sunny evenings – and I happened to come across an interesting CV-themed document. It was an Excel document entitled “Chantay’s Resume.xlsm”. This caught my eye mostly because resume’s should almost never be in Excel format. Unless you are applying for an accountant role, perhaps – I’m not sure what those people do.

I decided to poke around at this file a bit:

Upon opening this document in Excel, I received a helpful message from the job applicant. Good thing Chantay provided instructions for his resume file, otherwise I wouldn’t be able to see his prior work experience and educational credentials somewhere embedded in this CV.

I pressed the Enable Macros button at the top, as Chantay nicely instructed, and I received this popup error message:

It looks as if Chantay’s resume attempts to download a DLL file from the Internet and then executes it . However, my malware analysis virtual machine is not connected to the Internet, so this process failed. Capturing this download request in a web proxy, such as Fiddler, proved this to be correct:

A connection attempt was made to “hxxp://205.185.125[.]104/7kWZLZ”. This URL is likely hosting Chantay’s malicious DLL.

I also captured this activity in ProcMon (ProcessMonitor). Let’s inspect this activity:

It seems that Excel is attempting to download this DLL from 205.185.125.104, write the file (WriteFile) to a directory in my C: drive, and then load the file using rundll32.exe (ProcessCreate). This is a fairly common method of downloading and executing a payload from the Internet.

How is Excel doing all this, you may ask? I have no idea. There appears to be no VBA macro code in this document, nor p-code, or any other sneaky ways of obfuscating code in Office documents. But let’s dig a bit deeper.

The objects within this Excel document, like many Office documents, can be extracted simply by using a Zip utility such as 7zip. I used 7zip to extract all the embedded objects and one item specifically stood out:

“sheet1.xml” is 481kb, which is a substantial size given that this Excel document appears to only have one page of text and not much else. Inspecting this file a bit more revealed some code, which is likely hidden in the Excel spreadsheet itself:

What we know now is that there is hidden code in this document somewhere, we are just not sure where. Olevba, my go-to tool for Microsoft Office document analysis, displays the following:

So we know that this is an OpenXML formatted document and it contains no typical VBA macros. Let’s open Excel back up and see if we can find the hidden code.

If we navigate to the “Formulas” menu in Excel, there is an option for “Name Manager”. The Name Manager holds information relating to MS Excel formulas. I suspect this document is utilizing formulas for code execution, since this is what we observed when inspecting the XML files above. Name Manger will allow us to see the values of these formulas.

The Name Manager definitely contains some interesting strings worth investigating:

We can see a file path to a DLL, several Windows API functions (CreateDirectoryA, Download File, …), and a URL. Finally, there is an Auto_Open function. This function will execute when Excel is opened on the victim machine and after macros are enabled. We can jump to this location in the Excel workbook by double-clicking this Auto_Open entry in the list.

These functions are obfuscated – Excel needs to “calculate” these values before they can be seen in cleartext. When this Excel document is opened by a victim, the formulas will be calculated and the malicious code will execute.

Luckily for us, the built-in Excel debugger can be utilized to inspect this code. We can do this by right-clicking an interesting cell, selecting “Run”, and then “Step Into”, which will allow us to step into the formula and inspect its output:

dll-file-download-excel-xlm-code-debugging

After stepping though some of the code, we can see interesting strings such as a file being downloaded and saved to the C: drive as a DLL file.

To save time, and because I’m such as nice guy, I de-obfuscated the code for you, using the methods I outlined earlier. This Excel document:

Loads kernel32.dll and invokes CreateDirectoryA to create a new directory under the C: drive in format C:<random>\<random>.
Loads URLMON.dll and invokes DownloadToFileA to download the payload DLL file from hxxp://205.185.125[.]104/kWZLZ.
Starts rundll32.exe to execute the downloaded DLL.

Let’s grab this DLL from the web server and look into it a bit further.

Bullocks. We are presented with a “default campaign not found” message, and the payloads appear to be no longer hosted here. Unfortunately, we won’t be able to grab this payload in this manner.

I turned instead to my friend VirusTotal. A brief search on VirusTotal shows that there are (or were, at one point) several DLL files hosted on this IP address:

In addition, there appears to be many other “resume” files that point to this same IP, including “Ying Rume.xlsm”, “Rose Carron CV.doc”, “Federico CV.xls”, among others:

Circling back to the DLL files, let’s inspect a few of these. Many of these DLL’S have interesting properties. Let’s choose one that looks interesting:

This DLL is called “Google ipdate”, a very legitimate-sounding DLL file, likely straight from Google.

Let’s take a look at the static properties of this DLL file:

A few interesting things about this sample are that it is coded in Borland Delphi, which is a bit strange for a DLL file. Also, as we already saw previously, we have the classic “Google Inc.” and “Google ipdate” meta data.

The original DLL being dropped and executed by the resume Excel document was executed with the parameter of “DllRegisterServer”. I know this because I saw this in the ProcMon output. So, to execute this DLL file in, say, x64dbg, we can run it with the command:

rundll32.exe <dll_file.dll>,DllRegisterServer

After about 1 minute of execution time, msiexec.exe is spawned.

If we attach to the new MSI process in x64dbg and dump its process memory, we can better understand what malware family this sample resides in. Strings are a good place to start with this. We are able to see here some interesting URL strings in memory:

Leveraging Fiddler (or any other web proxy), I was able to confirm that this malware sample is attempting to contact the URLs I saw in memory.

These are likely C2 addresses. After a bit of research on the format of these URLs, there appears to be one malware family that is notorious for using a URI of “post.php”. Dum dum dum… Zloader.

ZLoader is a form of Downloader malware that establishes a connection with one or multiple C2’s, and then attempts to drop additional modules, implants, and other malware. So, it seems that at least one of the DLL’s being delivered in this campaign is ZLoader. Below, we can see part of this infrastructure, mapped out in VirusTotal:

complete-zloader-maldoc-investigation-virustotal

Summary

Well, there you have it. To summarize, Chantay’s nice resume utilizes hidden XLM macros in order to download and execute a DLL payload. The DLL payload, in my case, was a ZLoader variant. Very tricky, Chantay. Hope you at least got that job you were applying for.

Key takeaways: Be careful with resume files sent directly to you, and even more careful if they are in a non-standard format. Resume’s should almost always be in .doc, .docx, .rtf, or possible .pdf… But almost never in .xls/.xlsx fromat 🙂

As always, thanks for reading! If you enjoyed this post, follow me on Twitter (@d4rksystem).

Malware Samples Used

Resume document

b87f733efc95172621e267293ea60c41758ddcd9e005028df22af7e0a199cca8

DLL File

d36366666b407fe5527b96696377ee7ba9b609c8ef4561fa76af218ddd764dec

Analysis of A Lokibot InfoStealer

By d4rksystem | August 8, 2020

Lokibot is a family of “infostealers” designed to steal sensitive data such as credentials, cryptocurrency wallets, and other juicy things. Once a victim system is infected, this data is typically sent to a Command & Control server via HTTP POST.

I decided to dig deeper into this infostealer out of curiosity, as well as its prevalence in the cybercrime communities.

Here is the sha256 hash of the sample I used during this analysis:

49B9A126A7E543B1279C0863795D21CABD5EAA7D4A4E8B6DC1DF717BEDE1559A

A quick static file analysis of the sample does not reveal much. Below, we can see some of the properties and headers of the file, such as that it is an executable. We can also see that the sample is likely written and compiled in Delphi. The import table is also lacking, leading me to believe that the sample is packed and will later unpack itself in memory.

Let’s run the sample in our sandbox and see how it behaves.

Behavioral Analysis

When starting the Lokibot executable in a virtual machine, the sample basically copies itself to the users “AppData\Roaming” directory as “ever.exe”. It then executes the “ever.exe” executable, unpacks itself into a new instance of “ever.exe“, and kills the original “ever.exe” process.

Below, we can see the unpacked sample running as “ever.exe”.

Capturing traffic in Wireshark, we can see some interesting behavior:

The sample seems to make an HTTP POST to the domain “smallthingstress.sytes.net”. Inside the POST data is my Windows hostname, username, and a string at the end. At the beginning, there is a reference to “ckav.ru”. This is actually referencing a domain, “fuckav.ru”, which we will see again later in this sample’s code.

Unfortunately, I was unable to do more analysis of the complete C&C traffic flow because the domain appears to be offline now. Good thing for the victims, bad thing for us malware analysts 🙁

Unpacking Lokibot

The goal of this analysis is to understand the detailed functionalities of the malware. One of the ways in which to do this is to let the sample unpack itself in memory, and then extract it from memory as an executable and finally rebuilding the PE headers and IAT (Import Address Table). This way, we will be able to open up the sample in IDA or another disassembler and view its functionalities to start analyzing it.

For unpacking, I decided to use a tool called “hollows_hunter“. I wrote in detail about hollows_hunter here if you are interested.

In summary, hollows_hunter is a tool that scans all processes in your virtual Windows environment and attempts to locate malicious activity such as hooking, code injection, shellcode, etc. Once the malicious activity is recognized, hollows_hunter automatically dumps the associated executables, and attempts to rebuild the PE file and IAT. It worked really well in past samples I have ran it on, and it is a good idea to run this tool before attempting manual unpacking to save some time.

I ran the Lokibot sample and started hollows_hunter, which can be seen in the above screenshot. Luckily, hollows_hunter was able to dump the malicious process. To my surprise, it also rebuilt the PE and (some of) the IAT successfully, allowing me to inspect interesting imports and strings.

Static Analysis of Unpacked Lokibot

After dumping the unpacked executable, we can now see several interesting strings and functionalities:

For example, there are strings that reference SQL statements, the URL we saw earlier (“smallthingstress.sytes.net”), the “fuckav.ru” domain reference, and some strings referencing various browsers.

Based on the above findings, we can be mostly sure that this sample is designed to enumerate and extract system information such as browser and SQL data. Let’s import the sample into IDA for a deeper analysis.

To start revering this sample, I chose a few of the interesting strings and imports in the strings list. Some of the items that caught my attention were the browser-related strings, and the connection-related imports (socket, connect, send, etc.)

Below, we can see a list of the functionalities of this sample. This Lokibot sample is attempting to read data from the following applications:

*Lokibot – interesting functionalities.*

Lokibot queries the filesystem and registry in order to enumerate system information, credentials, cookies, and other juicy data. Below, we can see some of the function code that is responsible for stealing Safari browser and keychain data:

And here we can see the code responsible for enumerating SSH-related Putty data:

Finally, after gathering the juicy data, Lokibot sends this data to a remote web server (in my case: “smallthingstress.sytes.net”), which is what we saw in the Wireshark data earlier. We can see that in the below code, where the C2 URL and socket information is referenced:

That concludes this brief analysis of Lokibot. There are a lot of areas of code that I did not go deeply into during the static analyses, so I’m sure that this sample has additional functionalities that I overlooked. However, in malware analysis, its easy to get stuck in a rabbit hole of code. Sometimes it is best to simply understand the main functionalities of the code in order to quickly build detentions for them and respond to them in the future, rather than get lost in kilobytes worth of code that may or may not prove to be interesting.

As always, thanks for reading! If you enjoyed this post, follow me on Twitter (@d4rksystem).

Random Code Generation in PowerShell-Based Malware “sLoad”

By d4rksystem | August 7, 2020

Every once in a while, malware will surprise me with a new technique, or a new method of implementing an older technique. It’s kind of like malware analysis Christmas. Unpacking a gift (the malware) and getting a new toy. Nevermind.

Anyway, I was looking into a new “sLoad” sample the other day. “sLoad” is a Powershell-based Trojan downloader that implements a number of interesting techniques, but one special technique that I wanted to highlight with this post. I will not be covering the entire sLoad infection chain in detail here. If you want more information on sLoad, Microsoft put together a great analysis:

https://www.microsoft.com/security/blog/2020/01/21/sload-launches-version-2-0-starslord/

Buried in this sLoad PowerShell script, there is a call to a function “Get-Command -type Cmdlet”, as well as a call to “Get-Random -count 18”. “Get-Command” is typically called by system admins or developers who wish to get a list of various PowerShell functions that can be used for a certain task. In this case, the sLoad code is essentially generating a random subset (18, to be exact) of PowerShell cmdlets, and storing the resultant list in a variable ($r, in this case).

We can see the $r variable populated with these 18 random PowerShell cmdlets:

To prove to you (and to me) that I’m not crazy, I ran this code again for your viewing pleasure and received the following new list of 18 random cmdlets:

Further on in the code, this list of random cmdlets is then separated with try/catch statements, and other code:

Finally, this end result is written to another PowerShell file and dropped to disk. The resulting script looks like the following:

sLoad final dropped script with random cmdlets.

We can see our random cmdlets that don’t actually serve a purpose here, and they will fail to run. Their main purpose is to obfuscate the code a bit, confusing the analyst, and burying the actual malicious functions in a small sea of garbage. In addition, these extra cmdlets likely confuse some endpoint defenses as well (such as EDR and AV).

The interesting thing is that I have not seen any additional information on the Internet for this technique, including in the Microsoft blog post.

As previously mentioned, I won’t go into detail on the malicous functiioanlity, but to quickly summarize, this script is loading a previously-dropped encrypted file (system.ini), which is then decrypted. I may write a follow up post on this decryption functionality as this is interesting as well.

Anyway, I simply wanted to highlight the random code-generation capabilities of this interesting sLoad variant. Please contact me (@d4rksystem) if you see something incorrect in this post or have additional comments!

As always, thanks for reading! If you enjoyed this post, follow me on Twitter (@d4rksystem).