Lumma Stealer infection analysis (from pcap)

-

You know that Infostealers play a foundational role in the cybercrime ecosystem because they act as initial access and data collection engines. Instead of going straight for disruption, they quietly harvest credentials, session cookies, browser data, crypto wallets, and system fingerprints from large numbers of machines. This information is then monetized in underground markets, often bundled as “logs” and sold to other actors.

The following diagram is an example of the interaction between Infostealer Actors and Ransomware-as-a-Service operators. 



Analyzing Malware from the network perspective is always revealing. It looks like Lumma Stealer is living a second life with some recent breaches, including the Context.ai one.

Let’s walk through a simple exercise: we will examine a Lumma Stealer infection chain and then analyze a corresponding malware PCAP sample (special thanks to malware-traffic-analysis.net). This will allow us to observe its network communication patterns, yes, with a lot of encrypted data, but with enough evidences to make some interesting assumptions

Lumma Stealer execution PCAP Analysis >

At the first stage we have the DNS answer needed to connect to the host possuhb.com, resolved with the public IP address 174.138.43.121

The kind of domain naming reminds me to Domain Generation Algorithms. Adversaries may make use of Domain Generation Algorithms (DGAs) to dynamically identify a destination domain for command and control traffic rather than relying on a list of static IP addresses or domains. 

https://attack.mitre.org/techniques/T1568/002/


Virus total gives the host a score of 24/95 with different detections from known vendors


Immediately after the host resolves the DNS name, it starts a TLS-encrypted connection with the server. There is not much to see here, just the initial cipher negotiation and a lot of high-entropy encrypted payload. But, thanks god, after some TLS ACKs, we also observe some unencrypted HTTP traffic containing some juicy information.


At this stage the infostealer malware is tracing and fingerprinting the host by collecting relevant information. By decoding it we'll get JSON structured data that gives the attacker a complete device/browser fingerprint view used to uniquely identify and classify the host before further action

the data might also be used to try to understand if there is a human behind the client or if it is related to a sandbox environment, and then trigger some evasion techniques; anyhow, we can't find any evidence of that behavior. Let's move ahead :)

The data sent to the C2 server is a detailed fingerprint of the infected host, combining system, browser, and environmental information into a single profile. It includes the operating system and full user agent, along with hardware characteristics like CPU cores and input capabilities, giving a baseline of the machine. On top of that, it gathers advanced fingerprinting signals such as WebGL renderer details, a canvas-generated image hash, installed fonts, and browser plugins, all of which help uniquely identify the device. Network conditions like latency and connection type are also reported, together with screen resolution and display properties.

One more great indicator is contained in this HTTP GET /api/set_agent



The /api/set_agent pattern is well known in the wild, is explicitly associated with Lumma Stealer C2 infrastructure and has been flagged in multiple threat intel feeds as malicious . More importantly, the exact endpoint /api/set_agent is not unique or random. It shows up repeatedly across different campaigns and domains, which strongly indicates it’s part of a reusable backend/API used by the malware family. This is one more good element for detection logic. 


After that the encrypted party starts again without the ability to look at the payload, but we can make some assumptions just looking at how the session looks like:



What’s happening here is a burst of data from the client to the C2, followed by a rapid series of acknowledgments from the server. You can see the client sending multiple full-sized TCP segments (Len=1460), which is typical of efficient data transfer (near MTU size). Each of those packets increases the sequence number, meaning more data is being pushed out continuously.


On the other side, the server responds with a stream of pure ACK packets (Len=0), where the Ack number steadily increases. That progression  shows that the server is successfully receiving chunks of data and acknowledging them in order.


So nothing fancy on the TCP side, but this evidence is enough for me to establish that the malware is exfiltrating, in a second stage, a good amount of data from the client.


2 Key TakeAways


  • The Network is your last line of defense. Any cybersecurity solution can be evaded, but you can't remove traces from the network; you can just try to hide in the noise. Understanding signals from the noise is our job.
  • Even encrypted packets can reveal meaningful signals. Analyzing malware from a network perspective often requires a solid understanding of the TCP/IP model, but encryption does not equate to invisibility. Even when payloads are protected, the surrounding metadata, such as timing, packet sizes, session patterns, and connection behaviors, can still provide valuable insight into what is happening on the wire.


Popular posts from this blog

Introduction to Memory Forensics

-
Image
" Memory Forensics is a practice useful in areas like incident response, malicious code analysis, network security, threat intelligence gathering. Each function performed by an operating system or application results in a specific modifications to the computer’s memory (RAM), which can often persist a long time after the action, essentially preserving them. Memory Forensics provide unprecedented visibility into the runtime state of the system, such as which processes were running, open connections, and recently executed commands. " I've written this blog post to introduce some fundamental skills in Memory Forensics . Over the past year, I’ve explored various tools and techniques for hunting malware in memory dumps, gaining insights into memory virtualization and the critical relationship between an operating system and its hardware . As part of this article, I’ve included a hands-on tutorial on using the Volatility Framework to analyze Windows processes and detect pot...
Read more

Malware is lightweight

-
Image
As a solutions engineer in the industry, I recently had a discussion with a Security Analyst about the maximum file size that a Dynamic Analysis (sandbox) system should support to effectively deal with malware. Representation of a skinny malware :) I noticed that, sometimes, the expectation is to support even hundreds of megabytes for executables or exploitable-like files. However, if you pause for a moment and consider the key requirements of well-crafted malware, you will realize that: Malware is a Platform : Modern malware is built on penetration frameworks, requiring attackers to use multiple tools at different stages, from the initial compromise to achieving their final goal. Malware must be Stealthy : Attackers need to remain undetected and move quickly while generating as little noise as possible. Detection must be Evaded : Malware must minimize network traffic and implement evasion techniques to bypass detection at various levels. Given these points, you can understand that lar...
Read more