What the PCAP Told Me: A January 2025 Cyber Attack Investigation

Disclaimer: This is an independent investigation to enhance my skills in threat hunting and threat intel analysis. I downloaded the capture of the attack from https://www.malware-traffic-analysis.net/2025/01/28/index.html. I tend to refrain myself from looking up the details of the attack on the internet to preserve the integrity of my findings. Although, as part of correct practices in threat intel and threat hunting, I look into the internet to validate my claims AFTER my investigation.

For this investigation, I look into the pcap file containing the capture of the attack that occurred on January 29, 2025, on a compromised endpoint owned by DESKTOP-LQCS5F2, with IP address 10[.]1[.]28[.]147. The attacker used two malicious domains fubuzbvy23nnn[.]top with IP address 64[.]52[.]80[.]229 and fmnljjmachihehge[.]top with IP address 45[.]61[.]163[.]218. These domains contain malicious and highly-obfuscated PowerShell scripts injected into these URIs:

• http[:]//fubuzbvy23nnn[.]top/f78.svg
• http[:]//fmnljjmaeihehge[.]top/f%20mzioj%20m.php?s=57820
• http[:]//fmnljjmaeihehge[.]top/nexdplitf0htr.php?id=DESKTOP-LQCS5F2&key=74255137276&s=578

The malicious scripts were injected into the victim’s endpoint via HTTP GET requests.

The timing between the DNS queries and the GET requests speaks to how quickly the payload executed. It took only 10 milliseconds from the DNS query on fubuzbvy23nnn[.]top to establish a connection and deliver the payload.

However, the same thing cannot be said with the domain fmnljjmachihehge[.]top, since the injections were very specific and done separately.

The DNS query on fmnljjmaeihehge[.]top and its first GET request came roughly a minute after the initial delivery from fubuzbvy23nnn[.]top — not because of a delay in the attack chain, but because the payload delivery from fubuzbvy23nnn[.]top was still in progress between 09:35:26.361278 and .684978.

What I initially read as a gap was actually an overlap: while the multi-packet GET response from fubuzbvy23nnn[.]top was still being transmitted, the first GET request to fmnljjmaeihehge[.]top had already fired at 09:36:02. This either suggests the malware was making simultaneous HTTP requests — the first payload executing fast enough to trigger the second domain before its own delivery finished — or that a second user action, such as clicking another link, initiated contact with fmnljjmaeihehge[.]top independently.

Notice that fubuzbvy23nnn[.]top uses port 80, which is an HTTP protocol for web traffic. This clearly indicates that the traffic source is an insecure web application. Also notice that the sizes of most packets exceed 1000 bytes. This is not a normal occurrence in web traffic. Further, if we look at the screenshot below, the reassembled GET packet lands on a third-party application, which looks normal in plain sight.

However, after conducting reputation check on IP address 166[.]88[.]182[.]65, I found out that it belonged to subscribe[.]bigeznola[.]com. This domain has been flagged by VirusTotal as malicious.

Currently, the IP address associated with bigeznola[.]com is owned by Braxet Group Inc., as per its WHOIS record. According to ThreatFox’s database, Braxet Group Inc. is associated with 6 Indicators of Compromise related to Cobalt Strike and Phemedrome Stealer malwares.

Following the HTTP stream of the GET request to fubuzbvy23nnn[.]top, we can see the user-agent identifies the client as Windows PowerShell running on a Windows NT system. Moreover, the payload size is 21,726 bytes, which explains the GET request multi-packets with exceeding 1000 byte sizes.

Further, while the HTTP header indicates that f78[.]svg is a plain/text file type, it is, in fact, an obfuscated PowerShell script commonly used in cyber attacks for fileless malware delivery or defense evasion. This technique maps to MITRE ATT&CK ID T1059.001 (Command and Scripting Interpreter: PowerShell), T1027 (Obfuscated Files or Information), and T1027.010 (Command Obfuscation).

The script uses heavy mathematical obfuscation to hide its true intentions from traditional antivirus scanners and Network Intrusion Detection Systems (IDS). Instead of typing readable commands, the attacker has converted the characters into math equations and character arrays. When executed, PowerShell processes the math in real-time to rebuild the payload directly in memory without ever writing a suspicious file to the hard drive.

The Start-Sleep: 15 in the first line of the script is a native PowerShell cmdlet that forces the script to pause for 15 seconds, which is often used to evade simple sandbox analysis that times out quickly.

Moving on to the next HTTP GET request:

The first GET request by the victim to fmnljjmaeihehge[.]top is another obfuscated PowerShell script, which contains a long blob of Base64-encoded text. This is high-entropy encoded data, with a Shannon entropy of 7.979 out of 8.0, which essentially indicates maximum randomness.

and a conditional block:

which, if decoded is:

The returned byte array may indicate a next-stage payload that gets loaded into memory and executed without touching disk.

The second GET request by the victim to fmnljjmaeihehge[.]top is very particular and interesting. The URI indicated particular paramaters that include the computer name of the target endpiont: http[:]//fmnljjmaeihehge[.]top/nexdplitf0htr.php?id=DESKTOP-LQCS5F2&key=74255137276&s=578.

While scanning the obfuscated script, my eye caught an interesting command $env:COMPUTERNAME+jeouskzh.

In PowerShell, the $env prefix is used to view, create, or modify system and session environment variables, and allows you to interact with system configurations directly from your command line. So, the concept of a COMPUTERNAME variable on a downloaded payload from a URI that included the name of the victim’s workstation is interesting.

This is the jeouskzh expression found in the payload:

Decoding the hidden expression in jeouskzh revealed a WMI query string — *Select from AntivirusProduct — with the function call resolving to new. This queries the root\SecurityCenter2 WMI namespace to enumerate all installed antivirus products on the machine, returning details such as product name, state, and signature update timestamps. (T1518.001 Security Software Discovery, T1082 System Information Discovery, and T1047 Windows Management Instrumentation**).

In essence, $env:COMPUTERNAME retrieves the machine’s hostname, while jeouskzh queries all registered antivirus products and returns details like product name, state, and signature update timestamps.

This is a very common AV detection / defense evasion technique used in malware loaders and stagers to fingerprint the endpoint before deciding whether to proceed with execution.

Both payload from fmnljjmaeihehge[.]top are large in size.

What followed the GET requests was another DNS query. This time, it was for the attacker’s C2 channel cyz3a2ykhj59kx8[.]top, with IP address 86[.]107[.]101[.]93.

There had been several beaconings before the final TCP connection was established for the payoad injection. Also notice that while the source of the payload was from a domain cyz3a2ykhj59kx8[.]top, it did not use the standard HTTP/HTTPS ports.

Port 25658 is non-standard HTTP/HTTPS post and is frequently associated with command and control (C2) communications by threat actors attempting to blend in with regular traffic.

Between the beaconings was a Domain Enumeration identifying the victim as a Windows NT workstation with hostname DESKTOP-LQCS5F2, and a potential master browser from the WORKGROUP domain.

Unfortunately, the capture was not able to reveal the content of the payload injected into the workstation, but it was huge.

One thing that I also found interesting in the capture was everything appeared normal (aside from the ICMP requests from www[.]architectureandgovernance[.]com which were blocked by the victim’s workstation) until subscribe[.]bigeznola[.]com was queried by the victim and then everything after that escalated too quickly. Digicerts were requested for verification, then followed by the three GET requests to the malicious domains, then the C2 beaconings, and finally the web injection attack.

It is, of course, presumptuous of me to consider this idea since the capture cannot prove it, but it could have been that subscribe[.]bigeznola[.]com was attached as a link in a phishing email and the victim clicked it, providing the attacker initial access to the workstation. The payload transmitted via the GET request to fubuzbvy23nnn[.]top would then have established the foothold.

Threat intel and reputation check findings on the three domains from open-source intelligence platforms:

For fubuzbvy23nnn[.]top:

For fmnljjmaeihehge[.]top:

For cyz3a2ykhj59kx8[.]top:

The January 29, 2025 attack was swift, layered, and deliberate. From the initial access through subscribe[.]bigeznola[.]com, to the obfuscated payload delivery, endpoint fingerprinting, and ultimately the C2 channel and web injection.

Based on the discovery of multiple domains currently associated with the IP addresses used by the threat actor, it would be prudent for security teams to update their firewall rules to block these domains from communicating with user endpoints and to reinforce user training against phishing.