Visualização de leitura

Microsoft Tracks MacSync Stealer by Its Behavior, Not Its Domains

Microsoft tracked over 30 MacSync Stealer domains by focusing on behavioral patterns, revealing a campaign targeting passwords, keys, wallets and other data.

Domain blocking is a losing game when the thing you’re blocking can register a new domain faster than you can add it to a list. That’s the exact problem Microsoft Defender Experts ran into while tracking MacSync Stealer, a macOS-focused information stealer that RST Cloud first flagged for swapping out its command-and-control infrastructure almost immediately after getting publicly outed. Microsoft detailed how its experts stopped chasing individual domains and started tracking the behaviors that stayed constant underneath them.

Instead of tracking individual domains, Microsoft looked at recurring request patterns, HTTP headers and other behaviors. This allowed its researchers to link more than 30 domains to the same campaign and determine that the infrastructure was doing more than just sending commands to infected Macs. It was also being used to collect, stage and exfiltrate stolen data.

“MacSync Stealer is a macOS-focused information stealer that relies on changing infrastructure to deliver payloads, communicate with compromised devices, and exfiltrate data. Earlier reporting by RST Cloud identified the threat through a limited set of domains and documented rapid command-and-control (C2) replacement after public disclosure.” reads the report published by Microsoft.

“Microsoft Defender Experts expanded that view by correlating recurring endpoints and network behaviors across the activity. This behavior-led approach connected more than 30 domains and showed that the infrastructure supported more than C2 communication, extending into active collection, staging, and exfiltration.”

The infection chain starts with a trick rather than an exploit. Victims get social-engineered through a technique known as ClickFix, tricked into pasting or running commands directly in macOS Terminal, and once that shell session fires, curl pulls down attacker-controlled payload content from a path formatted as /curl/[token].

Then, native macOS tools decode and unpack the payload, and an AppleScript-driven layer takes over, blending Unix commands like sh, cp, rm, and killall with osascript calls that make the whole chain look more like ordinary system scripting than malware.

Once active, the stealer focuses on valuable data. The malicious code looks for macOS Keychain data, saved browser passwords and cookies, SSH keys, AWS credentials, Kubernetes configurations and files in common user folders. It also searches for Ledger and Trezor wallet data, showing that the malware targets users with valuable credentials and assets rather than simply collecting random browser history.

What actually confirms exfiltration, rather than just suspicious traffic, is the upload mechanism itself. Collected data gets staged under temporary paths, compressed into an archive, split into chunks, and pushed out through HTTP PUT requests carrying parameters like upload_id, chunk_index, and total_chunks.

“The staged archive was uploaded through rotating infrastructure using curl and HTTP PUT requests. Observed requests included –data-binary, API-key headers, macOS User-Agent string, upload_id values, chunk_index values, and total_chunks parameters.” states Microsoft. “These upload traits confirmed active data exfiltration and provided durable hunting pivots even when domains rotated. “

The researchers pointed out that the exfiltration method stays recognizable even when the destination keeps changing.

RST Cloud’s follow-up work backs up how consistent this infrastructure actually is under the surface. Using the same recurring URI patterns, RST Cloud surfaced eleven additional candidate domains and found a static API-key value shared across four confirmed command-and-control domains, even while the build token attached to each deployment kept rotating. A shared static key sitting inside otherwise rotating infrastructure is exactly the kind of detail that makes automated evasion look less impressive up close.

The attack wraps up with cleanup, deleting temporary archives, staging folders, and lock files after the upload completes. Microsoft notes this reduces what’s left sitting on disk, but it doesn’t erase the behavioral sequence itself.

“After exfiltration, the malware removed temporary archives, staging folders, lock files, and other artifacts. Although this cleanup reduced on-disk evidence, the sequence of archive creation, chunked upload, and deletion can still provide a useful behavioral correlation for defenders.” concludes Microsoft.

For anyone defending Mac fleets, the practical takeaway here isn’t a list of domains to block, since that list will be stale within days. It’s building detection around the recurring shape of the attack itself: shell sessions spawning curl with those specific flag patterns, osascript chaining rapidly into network activity, and archives appearing under /tmp/sync* right before outbound PUT traffic starts. Chase the pattern, not the address, because the address was never going to sit still long enough to matter.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, malware)

macOS Screen Sharing Flaw Exploited to Deploy Monero Miners

Hackers are exploiting a macOS Screen Sharing flaw to gain root access and install Monero miners on Macs with port 5900 exposed online.

The Dutch National Cyber Security Centre confirmed active exploitation of a critical macOS authentication flaw, tracked as CVE-2026-65400 (CVSS score of 9.8), less than two weeks after Apple shipped the fix.

The bug sits in macOS’s built-in Screen Sharing feature, the remote desktop tool baked into every Mac. Apple’s fix improved how the system manages authentication state, closing a gap that let attackers on the network authenticate to Screen Sharing without valid credentials at all.

Apple patched this issue with the release of  macOS Tahoe 26.6.1macOS Sequoia 15.7.9, and macOS Sonoma 14.8.9, crediting researcher Alfredo Pesoli (@__rev) at Bynario Atlas (bynar.io) for the discovery.

“An attacker on the network may be able to authenticate to Screen Sharing without valid credentials” reads the advisory.

That’s a fast, coordinated fix by industry standards. It just wasn’t fast enough to beat whoever started scanning for exposed systems.

NCSC-NL says it received reports of active abuse hitting multiple systems where port 5900, the port Screen Sharing runs on, was reachable directly from the internet.

“The vulnerability concerns an authentication issue in the Screen Sharing functionality where network attackers can gain access without valid credentials. This is made possible by insufficient state management during the authentication process. As a result, unauthorized individuals can perform authentication attempts that would normally not be accepted.” reads the advisory. “The NCSC has received a security advisory indicating that active exploitation of this vulnerability has been observed on multiple systems where port 5900 was accessible from the internet. In all these cases, root access was obtained on the affected system and a Monero crypto miner was placed.”

In every case documented so far, attackers gained root access and dropped a Monero cryptocurrency miner on the compromised machine. Cryptomining is a relatively boring payload compared to what root access on a Mac could actually enable, which makes this look more like opportunistic scanning than a targeted campaign, for now.

This flaw sits in the same source code file as two other Screen Sharing bugs Apple patched a month earlier in macOS 26.6, one of them a genuinely pre-authentication flaw that a researcher going by @osxreverser described needing nothing but a target’s IP address to exploit, no password, no username, nothing.

That researcher claimed to have found around 40,000 exposed Screen Sharing hosts on the internet during a scan, nearly half of them in the US, spanning residential connections, university networks, and at least a few corporate servers.

What ties both bugs together is how mechanically simple they are to trigger. Security firm Calif, which analyzed the flaws, found no memory corruption, no exploitation trickery, no race condition to win, just logic errors that let a couple of correctly ordered packets walk straight past authentication. Calif also said it built a working exploit for both vulnerabilities in about four hours using an AI coding agent, which is the detail that should worry defenders more than the Monero miner itself: the gap between a patch note and a working exploit keeps shrinking, and it’s shrinking because building the exploit barely takes effort anymore.

If you’re running a Mac with Screen Sharing enabled and haven’t updated yet, do it now rather than after finishing this article. And if updating isn’t possible immediately, turn Screen Sharing off entirely under General, Sharing, until you can; leaving port 5900 open to the internet at this point is less a risk than an open invitation.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Monero)

AmnesiaStealer Gives Attackers Live Control of Victims’ macOS Browsers

AmnesiaStealer targets macOS users through fake GitHub pages, stealing passwords, cookies and data while giving attackers live control of the browser.

Jamf Threat Labs researchers disclosed AmnesiaStealer, a new multi-stage Rust-based macOS infostealer that spread through a counterfeit GitHub download page using the ClickFix technique.

The lure looks convincing: correct GitHub dark theme, Octocat logo, “Verified Publisher” badge, and instead of a download button, it asks the visitor to paste a Terminal command. The same fake GitHub template has been observed in Atomic Stealer and MacSync campaigns, which means the lure infrastructure is shared across multiple malware families.

“AmnesiaStealer runs in three stages: The first is a shell script that downloads and launches the payload. The second is a Rust infostealer that harvests the keychain, browsers, Apple Notes and Telegram. The third is a stream_module, fetched on command, that gives the operator hidden, interactive control of the victim’s browser.” reads the report published by Jamf Threat Labs.

The third stage is the part that separates AmnesiaStealer from commodity stealers. Rather than just dumping files, the remote_stream command turns the infected machine into a live browser session the operator can drive in real time, keyboard input, mouse clicks, navigation, tab management, all while the victim’s own browser window stays untouched and shows nothing unusual.

“The stream module clones the victim’s browser profile, launches it headless and gives the operator live, hidden control of the session” states the report.

The Rust payload starts by displaying a native macOS password prompt styled as an Installer dialog.

It validates the password locally against the directory service using dscl, looping with “Incorrect password. Please try again” until the right one is entered.

“The captured password is then reused throughout the chain. It is piped into sudo -S for privileged reads, passed to security unlock-keychain -p, and written to disk in cleartext, both in the staging directory as pwd and in the user’s home directory as ~/.pwd.” continues the report.

With the password in hand the malware unlocks the login keychain, reads Apple Notes via sudo cat, sweeps Desktop, Documents, and Downloads for documents and wallet files, and targets 16 Chromium-family browsers for cookies, credentials, history, and extensions data.

A behavior worth watching on macOS 26 is how AmnesiaStealer handles Chrome’s Safe Storage key. If it cannot retrieve the key normally, the malware deletes it and replaces it with a key it already knows. This lets attackers decrypt newly stolen passwords and cookies, while potentially making previously stored data inaccessible. Since legitimate browsers do not normally delete and recreate Safe Storage entries through the security command, this activity can be a useful detection signal.

The stream module’s cookie theft works through Chrome DevTools Protocol: it calls Network.getAllCookies against the headless browser session, which returns plaintext cookie values because the browser has already decrypted them in memory. This sidesteps at-rest encryption entirely. The module also injects a stealth script through Page.addScriptToEvaluateOnNewDocument to patch browser fingerprinting APIs, keeping the headless session from being flagged as automation by the sites visited. Persistence is installed as a root LaunchDaemon impersonating Apple’s crash reporting service, com.apple.ReportCrash.agent with a random numeric suffix, configured to survive reboots under the console user’s account.

The C2 backend is named Amnesia Panel, sits at the root of the delivery domain, and returns error messages in Russian when login fails. Infrastructure analysis shows the same URL pattern, /d/command?t=token&b=build, across multiple domains resolving to the same address, consistent with a builder that generates per-campaign configurations and embeds them in the payload as an XOR-encrypted blob. The family name, the Russian error messages, and the shared lure templates with other known stealers suggest an established operation rather than a one-off experiment.

“AmnesiaStealer sets out to harvest credentials, browser data and live sessions from macOS users, and it delivers on some of that more than the rest.” concludes the report. “A working collector paired with a working browser-hijack stage, wrapped around a few dated bypasses, makes it worth tracking.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, AmnesiaStealer)

CrashStealer: New macOS Infostealer Uses Signed Apps to Evade Gatekeeper

New macOS infostealer CrashStealer uses a signed app to bypass Gatekeeper, steals credentials and wallets, then AES-encrypts stolen data.

Jamf Threat Labs first spotted CrashStealer in early May 2026 as a suspicious macOS sample uploaded to VirusTotal. By early July, in-the-wild detections confirmed the malware had moved from development into active deployment. The malware is written in native C++, impersonates Apple’s built-in crash-reporting framework, and encrypts everything it collects before sending it out. Most commodity macOS stealers are thin AppleScript wrappers or lightweight Objective-C tools. This one isn’t.

The initial access arrives through a disk image called “Werkbit Setup,” which contains a single application named Werkbit.app. That app is signed with a valid Apple Developer ID, Emil Grigorov (WWB7JA7AQV), and carries a notarization ticket, meaning it clears Gatekeeper on first launch without any warning.

The domain werkbit[.]io, which serves the installer, was registered in late June 2026, and access to the download is gated behind a meeting PIN so the malicious installer isn’t visible to casual visitors.

“We have since identified the stage that precedes the payload: a signed and Apple-notarized dropper, distributed as a disk image named “Werkbit Setup,” that retrieves the CrashStealer payload from attacker infrastructure and launches it.” reads the report published by Jamf. “Because the dropper carries a valid Developer ID and a stapled notarization ticket, it clears Gatekeeper on first launch, in contrast to the ad-hoc-signed payload it installs.”

When the victim opens Werkbit.app, it queries the GitHub API and fetches a file called sys.cache from a repository at mgothiclove/pkeys. That file contains the curl command the dropper runs next, pulling a shell script from endpoint-api-v1[.]com. The script isn’t written to disk in readable form: it arrives as a series of Base64-encoded blobs decoded at runtime before being piped directly to bash.

“The script downloads the payload disk image over cleartext HTTP from hxxp://endpoint-api-v1[.]com/d/f1b24e/download, retrying up to three times, and saves it as CrashReporter.dmg in /tmp.” continues the report. “It mounts the image without browsing or verification (hdiutil attach -nobrowse -noverify -noautoopen -quiet), copies the first .app bundle it finds into a hidden directory at /tmp/.CrashReporter, then detaches the image and deletes the downloaded .dmg. “

The dropper then strips the payload’s existing signature and re-signs it ad-hoc before launching it from that hidden /tmp path. An application bundle launching from a hidden directory under /private/tmp is an unusual and high-confidence indicator on its own.

The downloaded disk image contains CrashReporter.app, which carries the bundle identifier com.apple.crashreporter and an icon designed to look like Apple’s built-in crash-reporting component. The Info.plist contains the C2 address, 179.43.166.242, hardcoded as an App Transport Security exception, visible in cleartext.

“This is likely a byproduct of the authors’ test setup, as it would let an operator reach the C2 regardless of how the server is configured. The reliable takeaway is for defenders: the C2 address sits in the property list in cleartext.” continues the report. “This ATS exception appears in the earlier samples we identified but not in the more recent ones, which omit it.”

Later samples drop this exception, suggesting the operator has since moved to a properly configured TLS endpoint and no longer needs to relax Apple’s network security policy.

The TCC usage-description strings in Info.plist are also worth reading carefully. The malware requests full disk access under the framing “CrashReporter requires Full Disk Access for system administration,” alongside permissions for Desktop, Documents, Downloads, and removable volumes. These strings pre-populate whatever macOS shows the victim in the permission prompt, and the Desktop, Documents, Downloads description matches exactly where the file-search component later walks.

After launch, the malware shows a native macOS password prompt and validates whatever the user enters by calling dscl, a legitimate Apple directory-service utility, with the -authonly option. It loops until a correct password is supplied, then caches the validated credential in ~/.cache/.sys_auth with permissions set to 600. That password is immediately reused to unlock the login keychain via Apple’s own security command-line tool.

Collection is broad. The malware targets Chromium-based browsers including Chrome, Brave, Edge, Opera, Vivaldi, and others, Firefox credential stores, approximately 80 cryptocurrency wallet browser extensions including MetaMask, Phantom, Coinbase, Trust Wallet, Rabby, and Exodus, and 14 password managers including 1Password, Bitwarden, LastPass, Dashlane, and KeePassXC. It also runs a file searcher across ~/Documents and ~/Downloads that skips executables, disk images, large archive formats, and media files to keep the collected set small and relevant. The login keychain copy and the validated account password end up in the same staging area as everything else.

What distinguishes CrashStealer from most macOS stealers is what happens to the data before it leaves the machine.

“The encryption is authenticated and reasonably modern. Each item is encrypted with AES-256-GCM through Apple’s CommonCrypto, following the standard sequence of creating a cryptor (CCCryptorCreateWithMode), setting an initialization vector (CCCryptorGCMSetIV), encrypting (CCCryptorGCMEncrypt), and finalizing the authentication tag (CCCryptorGCMFinal).” states the report.”The 32-byte key is derived with PBKDF2-HMAC-SHA256 over 10,000 iterations (CCKeyDerivationPBKDF), using a passphrase together with a salt.”

The salt is hardcoded in the sample, labeled panel_salt_v1, and a nearby cleartext development string reads “using fallback salt — set CONFIG_CRYPTO_SALT for production,” confirming the operator intended this to be configurable and shipped a development default. The collected files are then zipped into hidden archives with a .zx_ prefix followed by eight random hex characters under ~/.cache/com.apple.crashreporter/. The stealer removes the staging directories after archiving but leaves the .zx_.zip archives behind, making them a reliable artifact for defenders to hunt for.

CrashStealer persists by copying itself to ~/Library/Caches/com.apple.crashreporter/CrashReporter.app, re-signing the copy ad-hoc, and installing a LaunchAgent at ~/Library/LaunchAgents/com.apple.crashreporter.helper.plist. The label is com.apple.crashreporter.helper, continuing the Apple impersonation into the persistence layer. KeepAlive is set with SuccessfulExit as false, meaning launchd restarts the process whenever it exits with an error, keeping it resident across reboots.

Anti-analysis measures include control-flow flattening applied broadly across functions, runtime decryption of sensitive strings from an encrypted blob in the binary’s __const section, and layered anti-debugging.

“A constructor that runs before main, during dynamic-linker initialization, uses sysctl with a KERN_PROC / P_TRACED query, the standard macOS debugger check, and terminates with exit code 45 if one is attached, before any malicious behavior runs.” states Jamf. “Patching out that first check is not enough on its own: a second check later in application initialization exits the same way.”

The delivery domain also hosts a dark-themed operator panel at endpoint-api-v1[.]com/login labeled “Command Panel,” independently spotted by MalwareHunterTeam.

Additional operator interfaces tied to the same campaign have been identified at cohezo[.]io, cohezo[.]com, and cordinex[.]io. Jamf reported the Developer Team ID to Apple after confirming it was used to distribute the malicious dropper.

“CrashStealer’s delivery chain shows real care: rather than a bare, unsigned lure, the operators front the attack with a signed and notarized dropper that clears Gatekeeper before quietly fetching, re-signing and launching the payload.” concludes the report.”What sets it apart from the commodity stealer crowd is less what it collects than how it is built: client-side AES-GCM encryption of the collected files, and an emphasis on analysis resistance through control-flow flattening, encrypted strings and layered anti-debugging.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, malware)

macOS.Gaslight: North Korea-Linked Malware That Tries to Gaslight the Analyst

macOS.Gaslight: DPRK Rust implant for Mac with a prompt injection payload designed to fool AI-based malware analysts.

SentinelLabs researchers spotted a Rust-based macOS implant, dubbed macOS.Gaslight, that surfaced in early June after an Apple XProtect update pointed to a VirusTotal sample uploaded on May 22. The binary was undetected by static engines at the time of writing. They named it macOS.Gaslight, and the name is earned.

“The sample is a macOS implant and infostealer written in Rust. Its most notable feature is an embedded cascade of fabricated system-failure messages, designed to make an LLM-assisted triage agent doubt its own session.” reads the report published by SentinelLabs. “It attacks the agent’s perception, rather than the sandbox it runs in. Accordingly, we dub this family macOS.Gaslight.”

The embedded payload is 3.5 KB of Markdown-fenced hostile data containing 38 fabricated “system” messages, simulating fake token expiry notices, out-of-memory kills, disk exhaustion warnings, and bogus static analysis flags.

These messages were used to trick analysts.

“What makes the sample notable is its attempt to mislead the analyst reading the output. It carries a 3.5 KB Markdown-fenced blob of hostile data containing 38 fabricated “system” messages delimited with {{DATA}} tokens.” continues the report. “The {{DATA}} tokens and the surrounding Markdown fence mimic an LLM triage harness’s own prompt scaffold, blurring the boundary between untrusted sample data and trusted instructions.”

The structure mimics the prompt scaffold an LLM triage harness uses internally, blurring the line between untrusted sample data and trusted instructions. The goal is to get the AI analyst to abort, truncate, or refuse analysis before it reaches anything interesting.

Similar prompt-injection techniques have been seen before, including Windows PoCs documented by Check Point in 2025 and supply-chain payloads like Hades and Shai-Hulud, which used simpler single-block injections rather than this more complex multi-message setup.

Command and control runs over Telegram’s Bot API in a polling loop. All payloads are encrypted with AES-GCM using a fresh nonce per message, and the implant pins its TLS certificate to a custom trust anchor, which means standard proxy inspection doesn’t work. It also reads the host’s proxy settings and routes traffic accordingly, so it still reaches the operator on networks that force outbound connections through a corporate proxy.

“When the URL path segment is the 4-byte literal ‘file’, the constructor substitutes the token that follows with the hardcoded placeholder file/token:redacted, preventing the live bot credential from appearing in any diagnostic output or error string the implant produces at runtime.” states the report.

This self-redaction routine is apparently novel. Most documented Telegram bot malware embeds recoverable tokens; here, even if you capture process logs or crash artifacts, the bot token isn’t in them. It’s only in the runtime config, which isn’t in this sample.

The operator gets an interactive shell with six commands: identify the implant, run shell commands, kill processes by PID, upload files, and halt the implant. The implant also creates a power management assertion to prevent system sleep, keeping the polling loop alive during idle periods.

The malware uses a LaunchAgent with the label com.apple.system.services.activity, impersonating Apple’s own namespace, to achieve persistence. The researchers pointed out that this is a well-documented North Korean macOS tactic.

The data collection side is a gated Python stealer that runs only when the operator enables it via config.

“A separate 2 KB base64-encoded bash installer fetches and stages a self-contained cpython-3.10.18 interpreter from the astral-sh/python-build-standalone project. The installer, a prerequisite for deploying the Python stealer, carries the literal constants PY_VERSION=3.10.18 and BUILD_DATE=20250708 and targets both arm64 and x86_64 macOS.” continues the report. “The widespread use of emojis and strict adherence to comment headers are consistent with LLM-generated output.”

Once the Python environment is staged, the stealer harvests Chrome, Brave, Firefox, and Safari browser data, terminal histories, installed application listings, a running process snapshot, a system profile, and a raw copy of login.keychain-db. Everything goes to the operator via Telegram file upload.

SentinelLABS links the sample to DPRK-aligned activity based on Apple’s own XProtect rule, which tags the binary under MACOS_BONZAI_COBUCH, a family SentinelLABS associates with North Korean threat activity. A sibling sample is also caught by Apple’s AIRPIPE rule, tied to the same cluster. The operator config schema includes Linux and GitHub fields that aren’t exercised in this sample, suggesting this binary is one component of a broader toolset built for multiple platforms.

Analysts building LLM-assisted triage pipelines should treat everything inside a sample as adversarial input, never as instructions.

“macOS.Gaslight is noteworthy for its analyst-targeting prompt injection, an attempt to weaponize the LLM-assisted triage pipelines that increasingly sit in the reverse-engineering loop.” concludes the report. “Anyone building such tooling should treat the contents of the samples they triage as adversarial input, never as instructions, and be prepared to keep hostile content out of the model entirely. As LLM-assisted analysis becomes routine, defenders should expect more samples built to exploit it.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, macOS)

❌