Research of a fresh Excel document with Loki malware inside

Utilities and scripts:

file;
msoffcrypto-crack.py
msoffcrypto-tool;
oletools;
scdbg;
Detect It Easy (diec);
inetsim;
fakenet;
PoweShell;
strings.

Fresh analysis of malicious Excel document with Loki malware (sha256: 4973d12a201434d409e66ebbb6568eb38fbb379181e166a1eca399df1f24682b) attachment dated 8/31/2022 Attachments are used in phishing attacks and have a certain income dynamics over the last month (Figure 1) on the site https://bazaar.abuse.ch/.

Figure 1 - the dynamics of the receipt of samples with documents containing LokiBot. — Figure 1 – the dynamics of the receipt of samples with documents containing LokiBot.

Before exploring, let’s make sure the contents of the file have not been encrypted.

Figure 2 - checking the encryption inside the file. — Figure 2 – checking the encryption inside the file.

Since the file is encrypted (Figure 2). We need to find the password and decrypt it.

We will not go far, let’s look for the password in the .xlsx file. After a short search, we get the decrypted file, because the password was inside, after the file was launched, this password was used to decrypt and execute malicious code (Figure 3).

Figure 3 - Finding the password inside and decrypting the file. — Figure 3 – Finding the password inside and decrypting the file.

Now you can start analyzing the file, use the utilities oletools by DidierStevens.

Using Oleid did not show the presence of nested VBA & XLM macros and links inside the document.

Figure 4 - Checking the OleId utility for malicious attachments. — Figure 4 – Checking the OleId utility for malicious attachments.

Without stopping, let’s take a look at the output of oledump.py, it shows the existence of a binary executable in xlsx. Well, let’s export the contents of A2 to a separate file for further analysis (Figure 5).

Figure 5 - oledump.py, executable code export. — Figure 5 – oledump.py, executable code export.

So, let’s run the emulation environment utility to run shellcode: scdbg. Set findsc, ReportMode, CreateDump, etc. (Figure 6).

Figure 6 - configuring scdbg. — Figure 6 – configuring scdbg.

After emulation, in scdbg you can see the functions that are called (Figure 7):

GetProcAddress function to get the address of the ExpandEnvironmentStringsW function to expand the environment variable.
Calling this function for subsequent saving to the correct path of the malicious file.
Obtaining the address of the file download function, then calling it and saving the malicious Cloud2.exe file to %public%regasm_avch.exe.
Execution of the downloaded file.

Figure 7 - Functions called by the malicious code. — Figure 7 – Functions called by the malicious code.

Now that we have the address, let’s upload the file. After downloading, we will analyze the content. First of all, for the presence of a packer / protector and the language in which the code is written. As we can see in Figure 8, the executable is written in C# and protected with a protector.

Figure 8 - information about the executable file DIEC. — Figure 8 – information about the executable file DIEC.

Before analysis, we will remove the protector from the file (Figure 9).

Figure 9 - Removing the protector from the executable file. — Figure 9 – Removing the protector from the executable file.

Now you can start static analysis of the file, using dnSpy (a free utility), IDA Pro, or at worst go through strings to find readable lines. You can also see the functions in the malware sample. The malware interacts with the following resources (follows from the code of the Cloud2.exe.1 executable file):

http://can-sat.netai[.]net/livestream/

Uploading files:

http://tempuri[.]org/_CAN_SATDataSet.xsd
http://tempuri[.]org/_CAN_SATDataSet1.xsd
http://tempuri[.]org/_CAN_SATDataSet2.xsd

Contains the AES encryption algorithm (works with 128, 192 or 256 bit keys). And many other interesting features, you can see the full list yourself.

This completes a small static analysis and begins a dynamic one =)
Dynamic analysis using FakeNet (Figures 10 and 11) and InetSim shows us where the malware goes during launch:

Figure 10 - FakeNet dynamic analysis. — Figure 10 – FakeNet dynamic analysis.

Figure 11 - FakeNet dynamic analysis. — Figure 11 – FakeNet dynamic analysis.

Above and in TCPViewer we see C2 Server 208.67.105[.]162 (location USA, City: Middleton), with which the malware interacts (above in Figure 11, before copying and renaming itself, and in Figure 12, already after copying and renaming with the attributes h – hidden & s – system, to hide).

Figure 12 - TcpView. — Figure 12 – TcpView.

Cloud2.exe copies itself with the attributes h (hidden) & s (system) to the directory C:\Users\\AppData\Roaming\585711\127DE7.exe (with a different name) so that it cannot be visually found, even after turning on the display of hidden files (Figure 13 and 14). By the way, the hash of the file also changes.

Figure 13 - attributes of a directory and a malicious one with a malicious file. — Figure 13 – attributes of a directory and a malicious one with a malicious file.

Figure 14 - Attributes of a malicious file. — Figure 14 – Attributes of a malicious file.

However, we can change the attributes to make the file available to us again (Figure 15).

Figure 15 - file after changing attributes. — Figure 15 – file after changing attributes.

Actually, this little analysis ends. Described some techniques and IoCs (indicators of compromise) during analysis. If you wish, you can go further and perform deeper static and dynamic analyzes.

Another, no less interesting, article on the research of executable code with exploits in PDF files can be found here.