Tracking DigitStealer: How Operator Patterns Exposed C2 Infrastructure

Information stealers (infostealers) continue to be the tool of choice fueling an ever growing cybercriminal economy. Harvested credentials are a hot commodity, from account takeover and financial fraud, to underground markets, and hand offs to initial access brokers. As stealer families continue to gain popularity and capabilities targeting major operating systems, it’s critical to understand the infrastructure behind the malicious operations.

DigitStealer, a macOS-targeting infostealer has recently drawn increasing attention from the research and security communities, and as I’ll detail below, the operators’ infrastructure missteps tells a story of its own.

In this post, I’ll cover how a few infrastructure procurement missteps assisted in discovering a cluster of C2 IPs/domains, and why DigitStealer is likely operated by a single individual or small team.

DigitStealer: A Brief Explainer

First reported by Jamf Threat Labs in mid-November 2025, DigitStealer targets 18 different cryptocurrency wallets, browser data, macOS keychain data, and other sensitive information. Unlike similar malware, this stealer has no web panel for sharing access with other operators/affiliates.

Since Jamf’s post, DigitStealer has been observed landing on victim systems by way of spoofing popular applications. Interestingly, the malware specifically targets Apple M2 devices and consists of multiple stages/payloads, each executing a different function. Lastly, the malware operates as a backdoor using a persistent Launch Agent to poll the C2 server every 10 seconds for new AppleScript or JavaScript payloads.

Vendors like Moonlock and Microsoft have also covered DigitStealer in detail, while researchers on X routinely share IOC’s and analysis of the samples. The open sharing of this information is what caught my attention, and kicked off this investigation detailed below.

Starting Point: An X Post

In late January, X user Yogesh Londhe, username @suyog41 shared a post on a recently seen DigitStealer sample posing as DynamicLake, a macOS productivity app. The C2 identified was diamondpickaxeforge[.]com. Additional domains recently identified by X users like @L0Psec, @500mk500, and @malwrhunterteam, and @g0njxa, and @smica83 to name a few, include:

• ebemvsextiho[.]com
• bottleneckid[.]com
• booksmagazinetx[.]com
• goldenticketsshop[.]com
• fixyourallergywithus[.]com

Identifying Infrastructure Commonalities

You may have already noticed a pattern among the above indicators of compromise. Before we dive too deep, let’s quickly look at the C2 communications of DigitStealer.

C2 Network Communication

DigitStealer communicates with four different endpoints correlating to the multi-stage behavior of the malware:

• /api/credentials – send stolen credentials
• /api/grabber – uploads files to C2
• /api/poll – endpoint for persistent backdoor polling
• /api/log – used for exfiltrating data

As discussed in the Jamf post, the final payload is the backdoor component which sends the hardware UUID of the system hashed with MD5 every 10 seconds to the C2. The attacker-controlled server also contains anti-analysis features by way of a cryptographic challenge. Prior to commands being issued, the C2 provides a unique ‘challenge’ string and a ‘complexity’ level. The malware must produce a number that when hashed with the challenge, produces a specific pattern. Only by solving this puzzle can DigitStealer receive a session token and tasks.

HTTP/S requests to the three endpoints above results in the JSON output seen in Figure 2.

Figure 1: Example request to a DigitStealer C2 containing the cryptographic challenge

Infrastructure Tradecraft

You likely noticed that each of the domains mentioned earlier used the same top-level domain (TLD), .com. Reviewing these domains and their resolving IP addresses in Hunt.io reveals yet another pattern that can be used to cluster the servers: every IP is hosted on the ab stract ltd network, located in Sweden.

Figure 2: Example IP Summary information for a DigitStealer C2 in Hunt.io

Figure 3: Domain list for 80.78.25[.]205 containing multiple .com domains.

A third pattern of secure shell (SSH) version numbers used emerged across the group of IPs:

• SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13.14
• SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13.14

Domain Registration & Name Servers

The operator(s) behind DigitStealer not only show a preference toward a specific hosting company, but also a possibly automated workflow of registering domains. The majority of the domains identified during this research were registered through Tucows, with a single outlier belonging to Immaterialism Limited. It should be noted that this domain was on a DigitStealer server, but did not follow the .com pattern and it is not believed to be connected with the malware.

This particular server setup (ab stract ltd ASN, nginx HTTP server, OpenSSH) leads to the thinking that DigitStealer is operated and maintained by a single actor or a small team. The lack of infrastructure diversity does not support a MaaS platform used by multiple, different actors. A counter argument to this hypothesis could be that the code base is shared, but an administrator dictates that C2 infrastructure follow a set pattern.

Figure 4: Domain registration information in DNSAudit.io for a suspected DigitStealer domain

Unsurprisingly, another pattern emerged during a review of WHOIS records. The search revealed that all the domains (even those not using the .com TLD) use Njalla for their nameservers. While a legitimate company, Njalla’s infrastructure has been frequently associated with ransomware and malware campaigns.

If you’ve made it this far, let’s add this to our growing list of commonalities belonging to DigitStealer.

Further analysis of the domains shows:

• Consistent use of Let’s Encrypt TLS issued certificates to protect traffic.
• Many domains use gaming or cryptocurrency/financial related naming (ironswordzombiekiller, diamondpickaxeforge, binance.comtr-katilim, theinvestcofund).
• Domains are registered in batches for specific campaigns (Mid-2025 campaign: June to November, Early 2026 campaign: January and February).

Putting it All Together

To briefly recap, DigitStealer makes use of domains ending in .com, IP’s hosted on a single ASN, and nginx HTTPS servers on port 443, to name just a few. In addition to the web server, we also identified two versions of OpenSSH used across the cluster. This isn’t the full query, but if we’re using SQL it would look something like:

SELECT * FROM IP WHERE asn = 39287 AND port = 443 AND headers.server = nginx AND subject.common_name LIKE '%.com%' AND ssh.version IN ('SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13.14', 'SSH-2.0-OpenSSH_10.2')

To verify our findings, we can create a quick Python script that takes the domains and makes HTTP requests to the above endpoints. The purpose of this check is to look for the JSON response containing the ‘challenge’ and ‘complexity’ fields. With a positive response and WHOIS check looking for Tucows as the registrar and Njalla nameservers, we can be highly confident we are only grabbing DigitStealer infrastructure.

Figure 5: Python results checking against the known DigitStealer endpoints

Some of the domains in the above figure have been publicly reported, and some have not which gives us an even stronger indication we are on the right track. Domains currently not responding could have been taken down by the threat actor, or are yet to be operationalized.

Many malware-as-a-service operations tend to have a scattered footprint as it relates to command and control and payload delivery infrastructure. Different actors have hosting, registration, and nameserver preferences, which admittedly sometimes makes monitoring difficult. The level of uniformity seen points away from a shared service model and more likely toward a closed operation managing the entire chain from domain purchase to collecting credentials.

Conclusion

DigitStealer’s operators have built a functional and effective C2 network, but their consistent infrastructure choices easily allowed for creating a fingerprint that made much of the operation discoverable. By examining shared network attributes starting with a known C2 server, the pseudo query above allowed for identifying domains that have not been reported yet.

When threat actors prioritize efficiency over operational security, it’s important for us as defenders to exploit these mistakes to proactively identify and burn assets before they attack our networks. It should be noted

All domains and associated IPs are provided in the below indicators of compromise table.

Indicators of Compromise