Introduction
Win32/InfoStealer.Dexter is part of a family of malware to steal information such as credit card numbers, passwords, or various techniques. This sample held anti-analysis techniques and basic steal techniques to hide its true abilities. This could also be categorized as a trojan.
Static Analysis
Upon copying the piece of malware onto the workstation, it was inspected with PE Explorer and PEID to determine if it was packed. While PEID showed that there was no commercial packer used on this executable, the difference between the virtual Size and raw size difference found in PE explorer told a different story.
Opening the .rsrc section, the following was found: A PE program. This program will be set aside for later, but for now, it should be noted that this was indeed the keylogger portion of the executable.
What should be noted here is that even upon saving the binary inside the rsrc section and opening it in IDA pro, I could not see any functions, leading me to believe that it was compressed or encrypted to stop analysis.
IDA PRO Analysis
Analysis using IDA pro was effective, and there were little to no anti-disassembly techniques used. The following data was found when using the strings utility:
- Software\\Microsoft\\Windows\\CurrentVersion\\run
- UpdateMutex:
- 151.248.115.107
- Gateway.php
Binary Analysis
The executable takes in a command-line argument of UpdateMutex: and upon doing so, it was determined that a new Mutex of UpdateMutex:< current Process ID > is being created. This mutex is later destroyed, but this shows that this mutex is being created dynamically.
The main mutex being created is called WindowsServiceStabilityMutex which can be used as a host based indicator.
Heavy Usage of GetProcAddress
The function GetProcAddress was called many times to resolve API in a way that would not have shown up in the IAT table. The functions which were being resolved were RtlCompressBuffer, RtlDecompressBuffer, and RtlGetCompressWorkSpaceSize. Upon further research, I discovered that this is a standard malware method for packing parts of the malware. It is a much older method but the method of storing a packed form of data in a section and then unpacking it during execution still exists.
In this case, this data was stored in the resource section and written to a buffer. This buffer was then written into a file called SecureDll.dll. This data was the same binary discovered earlier but decompressed and able to be analyzed this time. SecureDll.dll name itself shows that it is trying to hide as a legit windows dll. The dll itself was stored in the same directory of the executed program but hidden. It was simple enough to unhide it.
Upon further analysis, I discovered that this dll was a keylogger. The hackers relied on the unpacking and packing of their original malware package and its hiding rather than obfuscation techniques. Their dll file was essentially untouched and very easy to read. Further analysis showed that it was capturing keyboard hooks.
Dynamic Analysis
Dynamic analysis was done in two portions. Connected and disconnected from the network. For the connected portion, I used a host-only network and utilized inetsim to simulate a network that the program could connect to. The network information was then captured using Wireshark.
Un-Networked:
By double-clicking the executable, it deletes itself. Therefore the program must be then run via the command line. As mentioned before, the command line argument UpdateMutex: can be used, but this kept the program in a constant loop. The belief here is that this had something to do with the older version of the software or OS I was using that the program didn’t account for. I then opted to use win33.exe on the command line, which yielded the results I wanted.
This program was discovered to be copying itself to the location C:\Documents and Settings%Username%\Application Data\Java Security Plugin\ javaplugin.exe.
This program path is then added to the registry as the system startup autorun.
Running the program also started up an iExplorer.exe process. Using procmon, I could zero in on what this process is doing. For the most part, it was idle. It wasn’t until typing started in IExplorer, that I saw that it was writing to a file called strokes.log. The keylogger in SecureDLL.dll was only being used when writing in IExplorer. This means that something was possibly injected into the program.
Upon analyzing the strokes.log, there was a lot of junk that was actually encrypted. This form of encryption was a straightforward algorithm of just re-arranging the letters.
Connected
Whatever connection was being used is no more, so the connection was faulty. Only requests were made to the IP 151.248.115.107, but clearly, no responses were made back. Looking through the internet with whois-type websites, I found that the IP was not online.
Because the malware was requesting the IP, it confirmed that the malware was indeed talking to the IP.
To get around this I used INetSim and a Host-Only Network. Using the 151.248.115 network family I was able to route all traffic from the virtual machine to my computer and analyze all the network traffic.
Upon connection, the first thing this piece of malware did was send a POST request of the following:
This is being sent every 6 minutes.
Waiting for IDLE, I never captured any network information that indicated that the captured key data was being sent over the network, but it is always a possibility that periodically, out of the cope of time I have analyzed this malware that it will.
💬 Comment: