DigitStealer Infostealer Targets macOS, Revealing Critical Infrastructure Vulnerabilities

DigitStealer is an increasingly active macOS‑targeting infostealer whose predictable command‑and‑control (C2) setup exposes structural weaknesses in its operators’ infrastructure decisions.

While technically sophisticated on the endpoint, its reuse of the same providers, protocols, and registration patterns has made much of its backend unusually easy to fingerprint and track.

The malware is typically delivered via spoofed disk images masquerading as legitimate applications, such as the DynamicLake productivity app, and via fake websites and installer flows to trick users into executing it.

Jamf and Moonlock both note that DigitStealer heavily abuses macOS automation and native tools, executing most of its logic in memory and relying on staged payloads rather than a single monolithic binary.

DigitStealer was first detailed by Jamf Threat Labs in November 2025 as a multi‑stage macOS infostealer focused on harvesting browser data, keychain contents, files, and at least 18 different cryptocurrency wallets.

The stealer also performs environment checks to avoid sandboxes, skipping virtual machines and older Intel hardware in favor of Apple Silicon M2 and newer systems, which are more likely to belong to high‑value, financially attractive victims.

Once installed, DigitStealer runs through several payload stages that each implement a distinct capability.

These include deceptive password prompts to steal macOS credentials, targeted collection of browser and wallet data, and staging and compression of stolen information for exfiltration to the C2 endpoints.

The final stage establishes persistence via a Launch Agent and turns the stealer into a backdoor, regularly polling its C2 for AppleScript or JavaScript tasks that allow operators to return to compromised machines at will.

C2 Protocol and Crypto Challenge

On the wire, DigitStealer talks to a small set of fixed API paths that clearly map to its internal workflow: endpoints such as /api/credentials, /api/grabber, /api/poll, and /api/log are used to send stolen credentials, upload files, exfiltrate logs, and maintain the long‑lived backdoor session.

Researchers have observed infected hosts sending the hardware UUID of the system, hashed with MD5, to the C2 roughly every 10 seconds as part of this polling behavior.

Before the C2 will accept commands, it presents the malware with a cryptographic “challenge” and a “complexity” parameter; only when the client produces a value that, when hashed with the challenge string, matches a required pattern does the server issue a session token and tasking.

This puzzle adds an anti‑analysis layer on top of traditional checks, making it harder to trivialize C2 emulation or to replay traffic without implementing the challenge‑response logic correctly.

Captured HTTP(S) responses from live servers show JSON structures exposing the challenge and complexity fields that defenders can reliably hunt for when scanning suspicious domains.

This consistent API structure, coupled with the polling interval and UUID‑based client identifier, effectively creates a behavioral fingerprint that security teams can encode in detections and custom analytics rules.

Where DigitStealer becomes most interesting is its infrastructure: a handful of procurement choices made it unusually simple to map out related servers and domains.

Community posts on X have highlighted multiple C2 domains including look‑alike or generic names such as diamondpickaxeforge[.]com, booksmagazinetx[.]com, and goldenticketsshop[.]com all of which share similar registration and hosting traits.

Threat hunters using platforms like Hunt.io and WHOIS services have shown that many of these domains resolve to IP addresses on the same Swedish hosting provider and ASN, are fronted by nginx over HTTPS on port 443, and a narrow set of OpenSSH versions on the same boxes.

TLS certificates tend to be issued by Let’s Encrypt, and WHOIS records frequently point to a small cluster of registrars, with nameservers routed through privacy‑friendly providers that have appeared in other malware and ransomware campaigns.

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.

Because the operators repeatedly choose .com domains, a single hosting network, and a tight combination of web and SSH service versions, analysts were able to translate these attributes into SQL‑like queries to enumerate additional, previously unreported infrastructure.

A Likely Small, Closed Operation

Follow‑up checks using simple scripts that hit the known DigitStealer API paths and look for the distinctive JSON challenge fields further validated which servers were actively running the malware backend.

This level of uniformity is atypical for large malware‑as‑a‑service (MaaS) ecosystems, where multiple customers tend to bring their own hosting, providers, and operational preferences, resulting in a far more heterogeneous footprint.

Taken together, DigitStealer’s infrastructure patterns strongly suggest that it is controlled by a single operator or a tightly knit group rather than a broad affiliate‑driven service.

The centralized ASN, recurring domain patterns, constrained registrar and nameserver choices, and nearly identical stack of nginx and OpenSSH versions all point to a shared workflow owned end‑to‑end by one team.

While it is possible the codebase is reused or shared, the lack of infrastructure diversity argues against a widely rented MaaS offering where each customer deploys independent C2 resources.

For defenders, DigitStealer underlines a key lesson: even highly evasive, multi‑stage macOS malware can be exposed when its operators trade convenience for uniformity in their backend, leaving a trail that threat intelligence teams can systematically follow.

Indicators of Compromise

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.