In early 2026, Lumma Stealer activity once again began surfacing in public reporting and community analysis. While much of the discussion focused on payload behavior and infection chains, we were more interested in something else: the infrastructure quietly supporting the second stage of the operation.

Second-stage servers are where persistence, follow-on payload delivery, and command communication happen. They're the operational backbone. And unlike malware samples, infrastructure leaves patterns.

Following a SANS ISC Diary published on January 14th highlighting recent Lumma Stealer activity, our research team pivoted on network-level indicators to uncover a cluster of second-stage servers spanning two autonomous system networks (ASNs).

Rather than analyzing the stealer's capabilities, which have been covered extensively, we focused on hunting the infrastructure itself. That shift quickly surfaced several consistent patterns across the observed second-stage servers:

Key Findings:

• 17-second-stage servers hosted on AS56971 Cloud and AS215607 (dataforest GmbH).

• All servers share identical nginx/1.24.0 (Ubuntu) headers, and use the .cc top-level domain.

• Hunt.io scans show ongoing deployment, with the majority appearing within the last 7-14 days.

• In addition to using the .cc TLD, many of the domains shared a tech-themed naming pattern, even using typosquatted names similar to large cybersecurity companies and software.

• Port 443 was used for communication with the victim endpoint, and navigating to the webpage resulted in a generic "not found" message with no other information.

To understand why these patterns matter, it's important to examine how Lumma structures its staged infrastructure.

Understanding Lumma & Its Staged Infrastructure

Lumma Stealer emerged in 2022 as a malware-as-a-service offering targeting browser data, cryptocurrency wallets, and credential theft. The operation faced disruption in May 2025 when Europol and Microsoft seized multiple domains, but it quickly returned with updated infrastructure and distribution methods.

After initial infection, compromised systems communicate with second-stage servers that deliver additional malware or establish persistence. The SANS ISC diary documented this behavior, noting victims receiving PowerShell scripts from .cc domains that create scheduled tasks and maintain ongoing connections.

That detail provided the starting point for identifying infrastructure patterns rather than individual payloads.

For defenders, blocking second-stage infrastructure provides a vital containment opportunity. If the infected endpoint can't communicate with backup/follow-on servers, this is an important break in the so-called kill chain of the attacker's actions on the compromised device, limiting their next actions.

With that containment opportunity in mind, we shifted from analyzing malware behavior to examining the infrastructure enabling Lumma's second stage.

Infrastructure Analysis

We began our hunt with a simple step: visiting one of the reported Lumma follow-up domains referenced in the aforementioned post, fileless-market[.]cc, and another reported on X/Twitter, s3-microserrvice-updatehub[.]cc. In what is likely a poor attempt to throw off researchers, the webpage returned a basic, custom "not found" over HTTPS.

The .cc TLD, originally the country code for the Cocos Islands, has a history of abuse in malware and phishing campaigns. Due to its low registration costs, ease of registration, and lack of regulation, this is an ideal source of domains for threat actors.

While a custom HTTP response is indeed interesting, we decided to move to the IP address for additional details. The domain resolved to 94.183.183[.]156, hosted on AS56971. A closer look reveals three open ports: SSH (22), HTTP (80), and HTTPS (443). Both web services were found to be running nginx version 1.24.0, which was released in April 2023.

AS56971 CGI Global Limited, a Hong-Kong-based network provider, offers cloud virtual dedicated servers (VDS) with infrastructure across Europe, the United States, and Asia. This provider may be attractive to threat actors as Bitcoin and other forms of digital currency are accepted, allowing some anonymity in acquiring infrastructure.

The TLS certificate, issued by Let's Encrypt, uses the same domain for its common name. The JA4X hash, a373a9f83c6b_7022c563de38_2e3757343cb0 by itself is not useful for hunting, but when combined with our other findings, will be used to find similar infrastructure.

These initial indicators: AS56971 as the hosting provider, nginx 1.24.0 web servers on port 443, a custom "not found" response, and a Let's Encrypt JA4X hash with *.cc domains as the common name will serve as the base for our infrastructure hunt. Alone, these indicators may appear all too common to hunters and defenders, but when combined, they form a unique fingerprint that we'll build in the following section.

The next step was to test whether this JA4X fingerprint was isolated to a single host or indicative of a broader, coordinated deployment.

Building the Advanced Search Query

Let's first start on building a query to get an idea of how many servers our scans have observed with similar configurations as above. For this task, we'll use Hunt's Advanced Search feature (currently in Beta) using SQL queries to search across our internet-wide scan data.

Our goal is to find a manageable number of servers matching the same configuration profile (AS56971, .cc domains, port 443, JA4X hash). Below is the query we came up with:

SELECT *
FROM ip
WHERE asn.number = '56971'
AND same_port( service.port = 443
AND http.headers.server = 'nginx/1.24.0  (Ubuntu)'
AND tls.cert.hash.ja4x = 'a373a9f83c6b_7022c563de38_2e3757343cb0'
AND tls.cert.subject.common_name LIKE '*.cc'
)

                
Copy

Breaking down the SQL fields:

• asn.number = '56971' - Limits results to CGI Global Limited infrastructure

• services.port = 443 - Focuses on HTTPS servers

• http.headers.server = 'nginx/1.2.40 (Ubuntu) - Matches the specific server version

• tls.cert.hash.ja4x = 'a373a9f83c6b_7022c563de38_2e3757343cb0' - Identifies servers using the same certificate fingerprint

• tls.cert.subject.common_name LIKE '*.cc' - Captures the domain naming pattern

The same_port()lookup ensures all criteria apply to the same service on the same port, preventing false positives from servers running multiple services with different configurations.

Running this query resulted in 14 unique servers.

Fourteen matching servers within a single ASN strongly suggested structured deployment, prompting us to examine adjacent networks for similar configurations.

Expanding the Hunt: Infrastructure Diversification

Threat actors operating at scale understand the value of distributing malicious infrastructure across multiple hosting providers to reduce single points of failure. The next step was examining adjacent networks with similar technical profiles.

Extending our search revealed a single IP on AS215607 (dataforest GmbH), a German hosting provider: 94.26.106[.]117. The server exhibited the same configuration discussed in the previous section.

The IP resolved to a single domain, network-defender[.]cc, which we have not seen previously reported in connection with Lumma Stealer activity. Given the identical network setup, and recent domain registration, we believe with moderate-to-high confidence this finding represents Lumma-related infrastructure. The shift to dataforest GmbH likely suggests a continuation in a known TTP for Lumma, constantly evolving infrastructure, or this could be a test run of the network for future campaigns.

Updating the Advanced Search query to include both ASNs is straightforward:

SELECT *
FROM ip
WHERE asn.number IN (56971, 215607)
AND same_port( service.port = 443
AND http.headers.server = 'nginx/1.24.0  (Ubuntu)'
AND tls.cert.hash.ja4x = 'a373a9f83c6b_7022c563de38_2e3757343cb0'
AND tls.cert.subject.common_name LIKE '*.cc'
)

                
Copy

Output example:

Our new query brings our total to 17 servers, 14 on AS56971 Cloud, and 3 on dataforest GmbH. All IP's appeared within the same timeframe, suggesting a coordinated or automated deployment.

More importantly, this pattern demonstrates how infrastructure-level hunting can expose coordinated deployments that would otherwise remain fragmented.

Mitigation Strategies

We recommend the following actions:

• Monitor for connections to AS56971, AS215607 on port 443 with nginx/1.24.0 headers and .cc domains.

• Review DNS logs for .cc TLD domains with recent registration dates and matching a tech-themed naming pattern.

• Block the IOCs provided below and monitor for similar infrastructure patterns as operators continue to expand.

Note: the IP's/domains identified in this research were active as of February 21, 2026. To stay ahead of the threat, defenders should remain vigilant for servers matching similar, but not identical, profiles as the malware's infrastructure continues to evolve.

Indicators of Compromise (IOCs)

Summary

Lumma's second-stage infrastructure isn't random. When you zoom out from the payload and focus on the hosting layer, clear patterns emerge. Shared ASNs, identical nginx versions, reused JA4X fingerprints, consistent certificate traits, and tightly clustered deployment timelines all point to structured, repeatable operations. That's the kind of signal that survives domain churn and malware updates.

Infrastructure hunting shifts the advantage back to defenders. Instead of reacting to single IOCs, you can track deployment behavior, identify parallel servers, and anticipate expansion across adjacent networks. When certificate fingerprints and service configurations line up across multiple providers, you're no longer chasing samples; you're mapping the adversary's backbone.

Want to run this type of hunt yourself? Book a demo, and we'll walk you through it.