1. Brief
Recently we experienced a malware attack on a windows PC. As an impact, the victim’s personal credentials were stolen, and personal information was leaked. The hacker used the victim’s credentials to abuse their social media account.
2. Architecture
A. Malware (Client side) Client side (malware)
The malware is quite heavily protected and runs in a stealthy way to avoid being noticed. It has 5 layers of protection from outside in.
- Themida shell protection
- Manual obfuscate on VB.NET, payload in direct binary form as a parameter injection
- KoiVM virtualization, binary partly virtualized, it runs in memory to reassemble
- The remaining part uses confuseEX code obfuscation, it runs in memory to reassemble
- Payload on XOR cypher encryption
B. Networking (Hacker)
Once the malware is triggered in the target OS, it will release itself to the memory, create the VM and release the payload in the memory. It reassembles the payload in order to execute.
The payload will write to normal system instances to manipulate them to make TCP connections.
The infected instance controlled by the payload will first try to connect to a telegram account and load its profile page. On the profile page, it will get the backend IP address to which it will connect. This will give the hacker more flexibility when they are changing or moving in the backend, and they don’t have to deploy the malware on the victim’s computer again.
The infected instance will make a request to the hacker’s backend to download more dll to support the local operations. Normally those dll are not malicious. They are sqlite related dll so that the malware can run a database in memory to collect data and wrap it up for sending back to the hacker.
After getting all the necessary dependencies, the infected instance begins to scan the victim’s -folders on the computer and tries to harvest sensitive data. It looks like a normal system instance trying to collect user-sensitive data.
The data is formulated in the memory and the database file can be temporarily stored in the victim’s hard drive before it is sent back to the hacker’s backend.
The package will be encoded, packed up, and sent back to the backend server according to the harvest instructions from the hacker’s backend, while the infected instance manipulated by the payload attempt make the connection to the backend.
Later the infected payload will download a persistence instance to a folder that set-ups a special permission that the victim cannot access. The instance will run on a trigger of a windows task scheduler every minute.
3. Victim experience
A. Infiltrating
i. Paid software for free
When downloading cracked paid software for free, the malware might be also included. It might be located in a misleading position that the victim might click, and as a consequence download the malware. The victim might run it by accident.
ii. New order in the email
The email attachment is in an encrypted zip file. The password is already told in the email which tempts the victim to open it.
The reason for a password-protected zip file is that the zip file would be re-encoded by the password cipher so that the anti-virus won’t catch the fingerprint of the virus/malware.
B. Harvesting
The entire harvesting process is happening without the victim’s attention, and nothing will show up on the screen of the victim’s computer. While the malware is running, the dropped files by the malware would be deleted as well after the harvest. Therefore, almost no evidence is left behind. The persistence instance is running from a hidden system folder that the user doesn’t have access to.
C. Gaining Control
The persistence instance can potentially maintain the connection between the victim’s computer and the hacker’s backend so the hacker can have access at any time in the future.
4. Malware behavior
A. Mitre ATT&CK tactics and techniques
- Uses schtasks.exe or at.exe to add and modify task schedules
- DLL side loading technique detected
- Injects a PE file into foreign processes
- Writes to foreign memory regions
- Spawns processes
- Binary may include packed or crypted data
- Creates files inside the user directory
- Contains long sleeps (more than 3 min)
- Creates guard pages, often used to prevent reverse engineering and debugging
- Tries to harvest and steal browser information (history, passwords, etc.)
- Monitors Window changes (e.g. starting applications), analyzes the sample with the simulation cookbook
- Queries a list of all running processes
- Queries the cryptographic machine GUID
- Reads software policies
- Queries the volume information (name, serial number, etc.) of a device
- Queries information about the installed CPU (vendor, model number, etc.
- Reads ini files
- Enumerates the file system
- Tries to detect sandboxes and other dynamic analysis tools
- Tries to detect virtualization through RDTSC time measurements
- May try to detect the virtual machine to hinder analysis (VM artifact strings found in memory)
- Finds strings related to Crypto-Wallets (likely being stolen)
- Tries to steal Crypto Currency Wallets
- Tries to harvest and steal browser information (history, passwords, etc.)
- C2 URLs / IPs found in malware configuration
- Downloads files / exe / compressed data from the webserver
B. Control and Feedback on traffic
The feedback traffic is packed up as a base64 encoded package. Decoding it will reveal a zip file and decompress it so that the structure can be seen.
We noticed that the following has been uploaded:
- user’s machine information
- browser saved passwords
- autofill information (meaning the user’s history input in the browser)
- local chrome extension data, (including password management tool and crypto wallet)
- cookies (ongoing sessions and saved sessions)
- browsing history of all browsers
- download history
- user files (specific harvesting instructions from the backend, in this case, it contains all the txt, and doc files on the desktop and document folder)
5. Reverse engineering
A. Stage 1: Themina protection
We decompressed the file from the encrypted (password known) zip file to get the exe file. It pretended to be a brave browser installation file. The size was 427MB.
We tried to run it with any debugging software on. However, we got a warning, and the malware did not run.
We unpacked the themida protection and got to the next stage exe file.
The unpacked file was only 373KB in size compared to the initially found 427MB.
B. Stage 2: vb.net binary code execution
We opened the state2 file. The PE is a VB.NET header and it contained a huge amount of raw data.
The entrance was at “4ar()”. It loaded the “byte[]Hus7and” byte into the memory and tried to run the raw bytes as an instance. Therefore, we have reason to believe that the byte array is a payload which is the next stage of reverse engineering.
We rebuilt the assembly to source code and extracted the binary by changing its logic.
Some functions need attention here, for example, the Tr2ck() is used to obfuscate the logic.
By rewriting the array bytes to an external source, we got the binary for the next stage.
C. Stage 3: koiVM virtualization
We got the binary from the last stage while it tried to execute from the memory in a file format on the hard drive.
There is a few more metadata information also available in this stage for this exe.
In this stage, the binary is made in the .NET framework as well.
It is protected by the KoiVM, which is an extension of the confuserEX obfuscator.
We tried to devirtualize it with community KoiVM tools, but it failed. It seems that it is a modded version KoiVM. Therefore, we needed to devirtualize it manually.
The payload was located in _T.resource in a file named “BIDEN_HARRIS_PERFECT…”
After extracting that data block, we noticed it is not an exe binary.
We think it will be the resource for the next stage.
D. Stage 4: confuseEX code obfuscation
For the rest of the code, we removed the suspected payload located in the resource of the binary and run it in a sandbox. However, it was not running as intended, meaning the traffic and malicious activities are not functioning. It indicated that this binary should be run together with the virtualized binary and that it should be assembled together in the memory.
We disassembled the rest of the code and analyzed the logic.
E. Stage 5: Payload encryption
In the last part, we focused on the extracted potential payload we found in the last stage. It is protected by XOR encryption. We could brute force the cipher, but after taking a closer look at the Hex code, we could already figure out the cipher. In the next step we got the cipher and decrypted the data block into a binary.
Next, we got the raw binary of the malware. After running it on the PC, it was working exactly the same as the protected malware.
The next step is to reverse engineer the raw binary. Apparently, it is assembled by C++.
6. Impacts
A. Harvesting instructions
When the malware starts, it is sending a request to the server and asking what to harvest.
It is posting the victim’s computer machineID, as well as the configureID (- most probably the virus mutant ID). After that it will get a reply of a list of instructions.
It is asking the malware to find a lot of crypto wallet profiles and also all the txt files under the user desktop etc. There is a token to identify the client reply and match with the backend server database.
As a reply, the victim’s computer would replay accordingly to this harvest instruction.
B. System info
In the system info reply, it includes
OS Information:
- Locale:
- Time zone:
- OS version
- Architecture:
- CPU:
- RAM:
- Display size:
- Display Devices:
List of Installed applications and versions
C. Browser sensitive information
Here it collects as much as possible browser sensitive information on all the possible browsers in the victim’s OS. This includes all the autofill history, cookies, and passwords.
D. Sensitive files
After placing a file named “password.txt” on the desktop, it was sent to the backend in the TCP package. In fact, as the harvest instruction indicates, the malware collected all the txt on the desktop.
E. Screenshot and application-specific sensitive data.
A screenshot option is available for uploading as well. Furthermore, applications like steam and discord contain valuable user login information. Therefore, stealing the login data could make it possible to steal the user’s login session. Even if the user has a 2fa, stealing the session makes it possible to bypass this.
7. More info about the malware
Stage2 binary details https://www.virustotal.com/gui/file/159818a2a5130996e88491bfd928a95f2cd3fbe59f9d5564c982e8efa12a9162/
Stage5 binary details https://www.virustotal.com/gui/file/196c6c11d9d04997640c802f46bfaa070864dae6d45fc46c2e363660b972c90a
When this article is being composed. The hacker is moving the backend server to another place and recoded the protection of the malware. However, the principle didn’t change much. The suspected remote backend address are following.
- 77.73.134.24:80 (payload download)
- 77.73.134.30:80 (harvest data receiving server)
- 89.208.104.172:80 (payload download)
- mutant backend ip address (by 2022-Dec-20)
- 88.119.161.195:80 (harvest data receiving server)