Reverse Engineering report on Firefox trojan

Executive Summary

This Trojan represents a sophisticated multi-stage attack primarily targeting the Windows environment. Initially masquerading as a Firefox module, it alters system processes like cmd.exe and MsBuild.exe for its activities. The Trojan injects a keylogger into MsBuild.exe, capturing keystrokes and saving them to a file in the %temp% folder for exfiltration. It also ensures persistence by adding malicious link file paths to the startup folder. Key to its operation is its ability to evade detection through its use of legitimate process spaces and dynamic injection techniques. The extracted shellcode, along with its unique hash, indicates a well-planned execution strategy aimed at data theft and long-term access to the compromised system.

Host Indicators

mozglue.dll

Encrypted payload used by mozglue to perform further activities (sarape.txt)

Shellcode which was injected into cmd.exe

Path

Network Indicators

The malicious is very hard to detect because of the use following things:

1. Indirect SYSCALLs
2. Dynamic shellcodes
3. Multi-staging
4. Anti-analysis techniques
5. Trojan in legitimate binaries

Malware Composition

We found a harmful program pretending to be part of Firefox’s files. It was hiding in a file called mozglue.dll. We’ve sent its unique code, known as a hash, “75BEF67BB34E8856088FC708F916D1DB39DA3682D28DBF0C491208F9E0E1B96E,” to the SOC team for a closer look. When we compared this suspicious file to the normal one from the same Firefox version, we noticed that some of the functions inside had been altered.

Binary Diffing

The function’s flow chart shows lots of changes in the code, including new sections that have been put in. The parts that were taken out are marked in red, and the parts that were added are shown in grey.

When you run the file named “1 DOCUMENTO JURIDICO.exe,” it doesn’t start Firefox application because, it loads up all the needed DLLs first, including a tampered “mozglue.dll.” This altered mozglue.dll then runs harmful actions and closes. Here’s what it does:

It searches for a file called “sarape.txt” in the same folder, which contains encrypted payload. The hash for “sarape.txt” is “B76FA44855B0BDB110C5B1C22B1594AB7FF6AE1872A45BEE6C336A2919D513EC”. It copies everything from the folder into a special folder located at %AppData%/Roaming/OMHost. It opens the command prompt process from the SysWow64 folder, which is the 32-bit version, and inserts the payload into it using a special command called NtWriteVirtualMemory. The payload from “sarape.txt” is then decrypted and saved as a new temporary file in the %temp% folder. This file has a different name each time and is always 639-KB size.

Injection

The program uses a Windows function called GlobalAlloc to set aside some memory that any part of the program, or even other programs on the same computer, can use. This function is old and not commonly used today because there are newer ways to do the same thing, but some programs still use it because it’s compatible with older systems. This allocated memory is then used in the command prompt process, cmd.exe.

The program is using a command called CreateFileW, which is made to make a new file or open an existing one. In this case, it’s being used to either make or get into a file with the name f69csf28 that’s stored in a special temporary file at the location C:\Users\username\AppData\Local\Temp.

The malware tricks the system by first setting aside some space in the cmd.exe process where it can write its code. After writing the code there, it switches the space’s setting to “executable” using a command called NtProtectVirtualMemory. This lets it run the code it just added. By doing this within cmd.exe, which is a process the computer trusts, the malware can hide its actions and avoid being caught by security tools that are only looking for trouble in new or known bad processes.

In this situation, the malware sets aside memory in the cmd.exe process, as described earlier. Then, it uses a command called NtWriteVirtualMemory to put the harmful code into this newly created space. It prepares certain settings, known as registers (like RCX, RDX, R8), with specific details: a way to identify the cmd.exe process, the starting point of the memory it set aside, where to find the harmful code to be copied, and how much code to copy over.

After messing with the memory, the malware uses a command called NtQueryInformationThread. This shows it’s using a clever plan. Not only does it get another process ready for the harmful code to be put in, but it also checks to make sure the process is set up right to run the code.

This command, ZwSetInformationThread, is a basic system function that can change different settings and conditions of a thread in a program. When the Trojan uses it, it adds a thread in the cmd.exe process for its own purposes.

The last step in this Trojan’s process is using the NtResumeThread API, which is meant to start a thread running again. In this case, it’s used in the cmd.exe process after the Trojan has put its harmful code into the process’s memory. This might also happen after changing what the thread is supposed to do, so it runs the new code.

Cmd.exe — second stage

The harmful code that the Trojan added to cmd.exe is then used for more steps, like setting up and injecting more code. Next, it puts another part of its payload into MsBuild.exe to keep doing malicious activities. Before finishing, cmd.exe makes sure the Trojan stays on the computer by putting the path to the infected Firefox along with its malicious dll file in the startup folder. This makes the Trojan start up every time the computer starts.

Msbuild.exe — third sage

The code that was injected into MsBuild.exe turns out to be a keylogger. This keylogger records every keystroke and saves this information in a text file in the %temp% directory. Then, it sends this data to a command and control (C2) server {Dinamic-Tigo-191–92–96–62.tigo.com.co:5757}. Additionally, we’ve managed to extract this injected keylogging code. Its unique identifier or hash, is “96bf7154057a2d8747d17e265f11e35677059c505ea67939352a00973995bf12.”

The operations listed include creating, writing to, querying, and closing a file located at C:\Users\shaddy\AppData\Local\Temp\Log.tmp, which suggests that this file is being used to store data collected by the Trojan, likely key logs as mentioned.

Finally, when the socket connection is made, it exfiltrates the logs file over to the c2 server as shown in the screenshots below.