Part 1 meticulously detailed the initial compromise phase of LUMMAC.V2, from its deceptive "ClickFix" delivery to the various execution techniques employed. Building on that foundation, Part 2 now shifts focus to the post-infection activities, specifically delving into the sophisticated network communication LUMMAC.V2 utilizes to interact with its C2 infrastructure and exfiltrate sensitive data from compromised systems.

Network Communication

Once the LUMMAC.V2 payload is delivered and executed on the victim's machine, the malware immediately initiates a series of DNS queries to resolve the domain names of its hard-coded Command and Control (C2) servers. As depicted in the figure below, this process involves persistent querying until a successful resolution is achieved.

Figure 13: DNS requests and TLS handshake by the malware

The malware establishes a TLS v1.2 connection with the resolved IP address. As shown in Figure 14, the Server: Cloudflare header in the HTTP response, along with the CF-RAY header, definitively identifies the use of Cloudflare. This indicates that the C2 infrastructure is fronted by a reverse proxy service utilizing Cloudflare, which not only masks the true IP addresses of the C2 servers but also provides DDoS protection. This strategy makes the C2 infrastructure more resilient, harder to take down, and significantly more difficult to trace.

Data Staging and Exfiltration

After establishing a connection with its command-and-control server, the LUMMAC.V2 malware sends an HTTP POST request containing the string act=life in the request body. This request serves as a heartbeat signal to check the availability of its current proxy server as illustrated below.

Figure 14: Initial check-in by the malware

Upon receiving a successful 200 OK response, LUMMAC.V2 proceeds to request its configuration data from the command-and-control server. It does this by sending another HTTP POST request, this time with act=receive_message in the body. This request also includes identifying information such as the malware's version (Ver), the customer's unique Lumma ID (Lid), and a configuration Version (j), all of which are detailed in Figure 15.

Figure 15: obfuscated Configuration data from the C2

The malware receives its configuration data in an obfuscated form as a response to the HTTP request, employing both Base64 encoding and XOR encryption to conceal its true content. This layered obfuscation technique aims to evade detection and hinder analysis of the malware's instructions. However, this obfuscated configuration data was successfully decoded using CyberChef as shown in figure 16.

Figure 16: Deobfuscation of the configuration data

After receiving instructions from its command and control server, LUMMAC.V2 proceeds to stage data from the victim’s machine. This includes sensitive information like cryptocurrency wallets, browser extensions, browser files, important files from the user's profile, and data from specific applications. A detailed list of the files targeted by this malware can be found at the end of this blog post (refer to Tables 1, 2, and 3).

To send this staged data back to the Command and Control server, the malware uses an HTTP POST request. As illustrated in Figure 17, this request includes a few key pieces of information:

• HWID: This stands for Hardware ID, a unique identifier for the victim's machine.
• PID: The PID, Packet ID, specifies the data type in a network packet, enabling the server to correctly interpret incoming information, such as standard (1), Chrome (2), or Firefox (3) data..
• LID: This stands for LUMMA ID, a unique ID associated with the specific LUMMAC.V2 malware.
• act=send_message: This tells the server that the malware is sending stolen data.

Figure 17: Exfiltration by the malware 

LUMMAC.V2 is designed to steal sensitive data, such as passwords and cryptocurrency wallets, and send it to the attackers. As shown in the figure 18, the malware confirms successful exfiltration after receiving an OK response from its command server. Mandiant has observed that LUMMAC.V2 can also request further instructions or malicious payloads from the command server using an HTTP POST request with the get_message parameter. This allows the attackers to maintain control of the infected system and potentially deploy additional tools for further compromise.

Figure 18: Complete mission 

Extracted configuration data

This configuration is from the LUMMAC.V2 sample https://www.virustotal.com/gui/file/9b5261901aab3f45a0381d39b0f535853fdcae74c7f25121efda70bb89b062e2/detection. 

Table 1: General Settings

Table 2: Targeted Browser Extensions

Part 2 has thoroughly detailed the network communication, data staging, and exfiltration mechanisms employed by LUMMAC.V2, along with proactive threat hunting and detection strategies within Google SecOps. We've seen how the malware establishes resilient command-and-control through Cloudflare, communicates via HTTP POST requests for heartbeats and configuration retrieval, and then exfiltrates a wide array of sensitive data, from cryptocurrency wallets to browser information and application-specific files, often using obfuscation.

Now, as we transition into Part 3, we will delve deeper into the specific file paths and configurations targeted by the malware for data collection. This section will build upon our understanding of LUMMAC.V2's operational tactics by providing the specific techniques it uses to maintain a foothold on compromised systems, equipping us with even more precise knowledge for defense and remediation.