Today I’d like to share a quick analysis initiated during a threat hunting process. The first observable was found during hunting process over OSINT sources, the entire infrastructure was still up and running during the analyses as well as malicious payload were downloadable.
My first observable was a zipped text file compressing a simple update.js script. The script was created to avoid automatic analisis tools since the dimension (>9MB) really makes hard to beautify or remove unwanted/funny or added trash code every which happens to be everywhere.
|type||Drop and Execute|
The following images show how it looked like at first sight. As many of you are aware, analyzing scripts is just a matter of time or, if you have enough memory on your machine (or time to spend over that task) a computational matter during virtualization. If you are old style (I do like it a lot ) it is a matter of “keywords” , in other words adding some
console.println or whatsoever you like to make debugging quick and easy. Few strings in this update.js reminded me to the use of obfuscator.io tool, but I did not investigate further on this direction, it was quite easy as well to reach the point.
Finally its execution was reached. I obtained this status by using some classic and romantic hand working balance to dynamic execution with the always great JSDetox. Finally the real behavior came out. It looks like to be a drop and execute artifact. It takes a file called Dll.ppam from an IP address (please take a look to IoC section to see details on found IoC), it decodes it from
base64, and it invoked the method
VAI (really interested Italian word to say “GO”, nice coincidence !?) in the
Fiber.Home class. It then passes to such a function an interesting address:
https://firebasestorage. googleapis. com with some parameters as the following image shows (please reverse the byte order on the right string).
Lets take a closer look to what Dll.ppam is. First it’s a .NET Portable Executable, so we might have an easy path ahead.
|type||Drop, evasion and Memory Invoke|
The .NET is not packed and the code reading is quite “straight forward”. An interesting technique that I’d like to highlight (and to track) is in the way the malware developer used to step forward the malware control flow, which reminds me a known threat actor. Many different techniques could be used at this point if you want to make something happening after specific conditions or if you simply want to give an execution order. The most easy and (maybe) quick way to follow could be the adoption of
nested functions or, if you are a more sophisticated malware developer, you might decide to use
exception handlers or, again, you might decide to switch from function to function in different libraries, or for the shake of example, a simple single flow as a simple unique function. But this malware developer decided to use a quite characteristic way developing an interesting combination of
case. In other words it starts by assigning
num variable which it makes
case 0 to switch. In each
case it updates the
num variable to control the
switch(num) selector making the flow running in the desired way. The following image shows the
VAI function, in where you might appreciate the control flow and additional IoC (such as IP address, dropped url and artifact name, etc..).
The VAI routing starts by downloading a file called
Rump.xls from a remote server. It places the file content into a variable and it reverse its bytes order, later it replaces special characters to the letter
A. The resulting decoded file (bytes Inverted, Special Character replaced and base64 decoded) is another PE file written in .NET technology and encoded in base64.
Finally once the Rump.xls file is decoded in memory,
Dll.ppam runs it by calling the method
Adre inside the
Fsociety.Tools library, passing as argument
The following table sums up the original and dropped file by Dll.ppam named Rump.xls, while the next table shows details about the .NET PE file resulting from the decoding process.
|type||post exploitation tool, C2 communication|
|name||Rump.xls.inverted.charsReplaced.decoded (given name)|
|type||post exploitation tool, C2 communication decoded|
Rump.xls looks like to be an implementation of Fsociety tools, a complete post exploitation framework. This library is able to get system information
GetSystemTimeAsFileTime and to get the used software policies:
"regsvr32.exe" (Path: "HKLM\SOFTWARE\POLICIES\MICROSOFT\WINDOWS\SAFER\CODEIDENTIFIERS"; Key: "TRANSPARENTENABLED"). It also contains the ability to get persistence by
and it might get remote access by using the
"regsvr32.exe" touched file "%WINDIR%\AppPatch\sysmain.sdb"
The image above shows an interested detail about the called function
Ande, where you might appreciate a similar coding style if compared to the Dll.ppam even if the control flow, this time, is managed by simple nested if. The infinitive loop and the variable names are matching the previous code. However those similarities are way too weak to say anything about the authorship (IMHO), but still indicators to keep tracking.
According to Microsoft Threat intelligence the drop server (
22.214.171.124) has been seen with two certificates (please refer to IoC sections for sha1). The first certificate (SN:
136234453590953102797263558291395548452) has been issued on 2022-11-14 with common name
servidor (server as in Spanish). On 2022-11-14 the attacker changed the webserver certificate by adding the certificate having as SN:
13098529066745705731 issued on 2009-11-11 and having with common name
localhost. This Certificate has been recorded in almost 50k related IPs over the past 13 years. The following image shows what I meant.
One of the 50k IPs in where the same certificate was found, was the same that TeamCymru was able to track, thanks to previously posted IoC from Yoroi Threat Intelligence, back to Hagga Threat Actor. According to Microsoft researchers:
Team Cymru researchers describe how they were able to pivot in threat telemetry, using IOCs from Yoroi Security’s blog as seeds, to identify several other C2s. From the starting point of an IP address (126.96.36.199) associated with an Agent Tesla command and control server, it was possible to pivot and identify a backend server hosting a MySQL database operated by the threat actor Hagga. From this point a further pivot led Team Cymru researchers to the identification of additional C2s hosting the Mana Tools C2 panel along with a common certificate that can be used to increase confidence in attributing future infrastructure to this threat actor.
In this blogpost I shared a personal analysis on an interesting artifact found during threat hunting research. Since the very beginning of the analysis I had some feelings about the designed patterns used on .NET libraries and the modus-oprandi looked familiar to me. What surprised me a lot was to see indicators of FSociety framework embedded on this malware stack, but finally a matching certificate used in the infrastructure pointed my attention on TeamCymru analysis on Hagga Threat Actor (HERE). If a matching certificate and code style (not discussed here, but you might try by yourself to check HERE) are enough to you, I would bet on HAGGA threat actor with a new used post exploitation framework FSociety.tools.
Dropper: p://4 .204 .233 .44/Dll/Dll .ppam
Dropper: p://4 .204 .233 .44/Rump/Rump .xls
Command And Control: 188.8.131.52 port: 8895
970f993ad1a289620b5f5033ff5e0b5c4491bb2b (drop webserver Certificate 1)
b0238c547a905bfa119c4e8baccaeacf36491ff6 (drop webserver Certificate 2)