CrashStealer is an information-stealing malware for macOS that carries a valid Apple notarisation, passes Gatekeeper checks without triggering any warning, and is written in native C++ rather than the scripting languages or interpreted runtimes that most macOS stealers use. It is distributed as "Werkbit.app," packaged in a signed disk image accessed through werkbit[.]io, a domain registered in June 2026. The campaign uses meeting PIN-gated download links that limit distribution to specific, targeted recipients, and the social engineering prompts targets to right-click and manually open the application, a specific bypass for macOS's requirement that users explicitly authorise applications from identified developers outside the App Store.
CrashStealer targets browser session data, login keychains, approximately 80 cryptocurrency wallet browser extensions, and six major password managers. Once data is collected, it is packaged into ZIP archives, encrypted using AES-GCM, and transmitted to a command-and-control server at 179.43.166[.]242. Additional backend infrastructure analysis suggests that CrashStealer is one component of a larger multi-platform campaign that extends beyond macOS, with shared infrastructure pointing to activity across multiple operating systems.
Apple's Gatekeeper is the macOS security control that verifies the source and integrity of applications before allowing them to run. For software distributed outside the App Store, Gatekeeper has two requirements: the application must be signed by an identified Apple developer, and it must carry Apple's notarisation, a cryptographic stamp that confirms Apple has scanned the application and found no known malware at the time of submission. Applications that fail either check trigger a warning dialog that most users will not bypass.
CrashStealer meets both requirements. The Werkbit.app disk image and the binary it contains carry valid signatures from Developer ID "Emil Grigorov (WWB7JA7AQV)" and genuine Apple notarisation. These credentials were obtained legitimately through Apple's developer programme, presumably using a real or falsely registered identity, and then used to sign and submit the malware for notarisation. Apple's notarisation scanning did not detect the malicious payload at submission time. The result is an application that appears fully trustworthy from Gatekeeper's perspective and opens without any security warning.
This is the same notarisation abuse technique that has appeared in macOS malware campaigns targeting cryptocurrency users over the past two years. The approach requires more effort than distributing unsigned malware: the attacker needs a valid Apple developer account, must go through Apple's notarisation process, and faces the risk of the certificate being revoked when the malware is discovered. But the payoff is a distribution mechanism that bypasses the primary security control most macOS users rely on to assess whether software is safe to run. For targeted campaigns focused on high-value victims, that trade-off is clearly acceptable.
The majority of macOS stealers that have appeared in the threat landscape over the past several years use scripting languages or runtime environments to implement their payload logic. AppleScript, Python, and Go have all appeared as implementation languages in macOS malware, often because they are easier to write quickly and do not require the compilation and linking steps that native code demands. CrashStealer is different: it is implemented in native C++, compiled directly for the macOS architecture.
The practical consequence for detection is meaningful. Scripting-based malware can often be flagged through static analysis of the script content or through process monitoring that identifies suspicious interpreter invocations. Native C++ binaries are harder to analyse statically without specialised reverse engineering tools, and they do not leave the same process tree signatures that interpreter-based malware produces. CrashStealer supplements the native implementation with specific anti-analysis techniques: control-flow flattening, which restructures the program's control flow graph to make automatic analysis tools less effective, encrypted string handling that prevents static string extraction from identifying the malware's targets and capabilities, and anti-debugging measures that detect when the binary is running under a debugger and alter its behaviour accordingly.
These techniques are characteristic of malware developed for targeted, high-value campaigns rather than commodity stealer operations distributed at scale. The investment in analysis resistance suggests the developers anticipate that their samples will be examined by security researchers and are willing to invest engineering effort to slow that analysis. For detection, the combination of notarisation, native implementation, and analysis resistance means that signature-based detection at the Gatekeeper level is not a reliable defence, and behavioural detection of post-execution actions is the more relevant control.
CrashStealer's collection scope reflects a clear prioritisation of financial and credential assets. Browser data is collected from Chrome, Brave, Edge, Opera, Vivaldi, and Naver Whale, covering the six most-used non-Safari browsers on macOS. Safari is notably absent, likely because Safari's data is stored in locations that are protected by macOS's system integrity protection in a way that differs from Chromium-based browsers, or because the campaign is targeting a user base whose cryptocurrency activity happens primarily in Chromium-based browsers where wallet extensions are more common.
The cryptocurrency wallet extension targeting is the most extensive component of CrashStealer's collection: approximately 80 wallet extensions are in scope, including MetaMask, Phantom, Coinbase Wallet, and Trust Wallet, which together represent a substantial share of browser-based cryptocurrency custody. Browser extension data for crypto wallets typically includes encrypted private keys or seed phrases that, once extracted and decrypted, give the attacker full control of the associated blockchain accounts. The session and authentication data from browser profiles allows the attacker to access web-based exchange accounts and services where the victim's cryptocurrency assets are managed.
Six password managers are also in scope: 1Password, Bitwarden, LastPass, Dashlane, KeePassXC, and at least one additional manager. Password manager data is a high-value secondary target because it frequently contains credentials for banking, investment, and exchange accounts beyond the cryptocurrency wallets that CrashStealer targets directly. A victim whose password manager database is successfully exfiltrated faces exposure not just of their cryptocurrency assets but of any financial account whose credentials the password manager stored.
The system-level collection extends to the macOS login keychain and the contents of the ~/Documents and ~/Downloads directories. The login keychain stores system-level passwords, Wi-Fi credentials, and certificates that are used by macOS and applications for authentication. Its contents can include credentials for corporate VPN connections, shared secrets for enterprise applications, and sensitive authentication material beyond the web passwords that browser-based collection typically reaches. The ~/Documents and ~/Downloads targeting reflects a broader document exfiltration goal: screenshots, financial documents, identity documents, and sensitive communications that victims store in the default macOS download and document locations.
The distribution mechanism for CrashStealer reflects a targeted approach rather than a mass-market campaign. The werkbit[.]io domain serves download links that are gated behind meeting PIN codes, which limits access to recipients who have been specifically sent the PIN. This design suggests the campaign reaches victims through social engineering that happens in a prior channel: a message, an email, or an invitation that provides both the download URL and the required PIN, creating the appearance of a legitimate software download tied to a specific interaction.
The installation prompt instructs recipients to right-click the application and select "Open" rather than double-clicking it directly. This is a social engineering prompt designed specifically to trigger macOS's mechanism for running applications from identified developers that are not in the App Store. When a user double-clicks an application from outside the App Store, macOS performs Gatekeeper verification automatically. When they right-click and select "Open," macOS presents a dialog asking whether they want to open the application from the identified developer, bypassing the more restrictive default behaviour for unrecognised sources. In the case of CrashStealer, which carries valid notarisation, Gatekeeper would not block the application regardless of how it is opened, but the right-click instruction is a standard technique that trains victims to manually override security warnings when they appear for other malware.
After successful execution, CrashStealer installs a LaunchAgent to establish persistence across system restarts. LaunchAgents are macOS's standard mechanism for user-level background services, and their presence is normal for many legitimate applications, which means a malicious LaunchAgent does not stand out on visual inspection of the running system. The malicious agent is configured to re-execute the stealer payload at system startup, ensuring that if the initial collection missed anything (because additional files were added to ~/Downloads or ~/Documents after the first execution), subsequent executions will capture the new material.
Before beginning data collection, CrashStealer performs local password validation, an anti-sandboxing technique that verifies the system is running as a real user account with an accessible login keychain rather than in an automated analysis environment. This reduces the likelihood of triggering alerts in automated malware analysis sandboxes that run without user-level authentication contexts.
Collected data is packaged into ZIP archives and encrypted with AES-GCM before being transmitted to the command-and-control server at 179.43.166[.]242. AES-GCM provides both encryption and authentication: the receiver can verify that the transmitted data has not been tampered with in transit, which is useful for the attacker's operational reliability but also means the exfiltration traffic does not contain plaintext that would be trivially identifiable in network monitoring. The use of standard, well-implemented encryption for exfiltration rather than custom obfuscation schemes is characteristic of professionally developed malware.
The GitHub staging component, where CrashStealer contacts the github.com/mgothiclove repository to retrieve a file named sys.cache, introduces an interesting operational detail. Using GitHub as part of the C2 or staging infrastructure allows the malware to blend exfiltration or configuration retrieval traffic with the large volume of legitimate GitHub traffic that most networks generate. A request to github.com for a file is unlikely to trigger the same network-level scrutiny as a request to an unfamiliar IP address or domain. The specific repository name and file name serve as indicators of compromise for network monitoring: outbound connections to github.com/mgothiclove retrieving sys.cache from a macOS system that matches CrashStealer's other indicators are a reliable signal worth capturing in network detection rules.
The broader multi-platform campaign context, suggested by shared infrastructure analysis, implies that CrashStealer's operators are running parallel operations against non-macOS targets using the same command-and-control infrastructure. For organisations where the threat is primarily macOS-based cryptocurrency users or financial professionals, the macOS-specific indicators are the most immediately relevant. For security operations teams that monitor infrastructure at the network level, the shared C2 IP address and GitHub staging repository are relevant across all platforms, because the same infrastructure will serve malware targeting other operating systems if the campaign is indeed multi-platform as the backend analysis suggests.
The CrashStealer campaign makes a clear argument against treating Apple's notarisation process as a reliable malware prevention control for targeted threats. Notarisation was designed to catch known malware at the point of distribution. It is not designed to catch novel, targeted malware submitted through legitimate developer accounts before the payload is publicly known. Once a malicious application is notarised, Apple's typical response is to revoke the developer certificate when the malware is reported. That revocation prevents future installations on systems that have already applied the revocation update, but it does not address installations that occurred before the revocation, and it does not provide any forensic visibility into systems that were already compromised.
For organisations managing macOS fleets, the relevant controls are behavioural rather than signature-based. Monitoring for LaunchAgent creation by applications that were recently installed from outside managed software channels, monitoring for outbound connections to unfamiliar IP addresses or unexpected GitHub repositories shortly after new application installations, and monitoring for bulk file access operations in the ~/Documents and ~/Downloads directories outside of expected user activity patterns are the detection mechanisms most likely to surface CrashStealer-style attacks. Understanding the danger of leaked credentials extends to the kind of credential and session data that a macOS stealer extracts, because the same underground markets that sell traditional corporate credentials also accept browser session cookies, crypto wallet exports, and password manager databases as high-value items.
Users who believe they may have installed Werkbit.app or any application from werkbit[.]io should treat their macOS login keychain, all browser passwords and session cookies, all cryptocurrency wallet accounts accessible from the affected machine, and all password manager entries as compromised. The appropriate response is to revoke and reissue credentials from a clean, uncompromised system rather than attempting to verify whether the installed application collected data before any remediation action is taken. The presence of the LaunchAgent means the application ran at every system restart, not just at the initial installation point, so the collection window extends from the first installation to the point of removal.
CrashStealer is not the first macOS stealer to abuse Apple's notarisation process, but its native C++ implementation places it in a category that is meaningfully harder to detect than the previous generation of macOS stealers. The first wave of notarisation abuse in macOS stealers appeared around 2022 with threats like AMOS (Atomic macOS Stealer), which used legitimate developer accounts to obtain notarisation for malicious payloads before Apple could revoke them. That generation was primarily implemented in Go or Python, languages that produce binaries with recognisable characteristics for automated analysis tools.
The shift to native C++ in CrashStealer represents a deliberate escalation in the effort to resist automated detection. Analysis of a native C++ binary requires a disassembler and reverse engineering tools. Combined with CrashStealer's control-flow flattening, which transforms the program's control flow graph into a flat dispatcher pattern that defeats standard automated analysis by making it appear that all code is reachable from a single loop, the binary resists the kind of automated classification that security vendors use to generate signatures quickly after initial discovery. The practical consequence is a longer window between first discovery and broad detection coverage across antivirus and endpoint security products.
The macOS threat landscape has seen an accelerating pattern over the past two years: each new stealer family improves on the previous generation's detection resistance, and notarisation abuse has moved from an occasional technique to a standard feature of professionally developed macOS malware. Apple's response has been to improve the notarisation scanning process and accelerate certificate revocation when malware is reported, but the asymmetry favours attackers: they only need to successfully notarise once and distribute before revocation, while Apple must detect and revoke every variant.
The use of meeting-PIN-gated download links is a deliberate targeting mechanism rather than a technical necessity. It limits access to the Werkbit.app download to recipients who have received both the URL and the PIN through a separate communication channel. This creates a filter that excludes security researchers and automated URL scanners, because they would not have the PIN and would not be able to reach the download page. It also creates a social context for the download: the recipient believes they are downloading software tied to a specific interaction, a meeting, a collaboration, or a professional engagement, which increases the likelihood they will install it without the additional scrutiny they might apply to an unsolicited download.
This distribution model is consistent with campaigns targeting high-value individuals: cryptocurrency investors, financial professionals, executives at investment firms, or founders in technology sectors where cryptocurrency transactions are common. These targets are valuable precisely because they have assets worth stealing (crypto holdings, password manager databases covering financial accounts) and they regularly interact with new contacts in professional contexts where receiving a download link is not inherently suspicious. The PIN-gating is a quality filter that ensures the malware reaches its intended targets while reducing the exposure to the scanning activity that would accelerate detection and revocation.
The scope of credentials that need to be rotated following a confirmed or suspected CrashStealer infection is broader than most incident response procedures anticipate. The starting point is obvious: all browser-saved passwords across Chrome, Brave, Edge, Opera, Vivaldi, and Naver Whale, and all authentication sessions for all accounts accessed in those browsers, are compromised. Any website where the infected browser had an active session should be treated as if the attacker has that session.
Beyond browser credentials, the macOS login keychain must be treated as compromised. The login keychain stores not only web passwords but system-level authentication material: Wi-Fi network passwords, application keychain entries, certificates, and private keys that applications have stored there. In a corporate environment, the login keychain may contain credentials for VPN connections, SSH keys for server access, certificates for code signing, and shared secrets for enterprise application integrations. Inventorying and rotating everything the login keychain held requires a systematic enumeration of what was stored there, and that enumeration can only be done reliably before the keychain is cleared, because clearing it removes the inventory.
The approximately 80 cryptocurrency wallet extensions in scope for CrashStealer require specific attention because blockchain transactions are irreversible. Once private key material from a browser-based wallet extension has been exfiltrated, the attacker can drain the associated blockchain addresses at any time. Moving any cryptocurrency holdings to new addresses with freshly generated keys, from a clean, uncompromised device, is the only way to ensure the attacker cannot execute a delayed drain of funds that were in accounts accessible from the compromised machine. The process for responding to credential exposure applies equally to cryptocurrency wallet keys, with the additional urgency that blockchain transactions cannot be reversed after they are confirmed.
When an enterprise network appliance is compromised, the attacker's next step is almost always to monetise the access. Credentials harvested from session logs, certificates extracted from the device, and authentication tokens captured in transit have a well-established route: they end up in stealer logs on criminal forums, dark web marketplaces, or private channels where initial access brokers sell them to the next buyer in the chain.
Defendis monitors these channels continuously. If credentials or data linked to your organisation surface following a perimeter device compromise, Defendis surfaces the exposure with full context: which individual is affected, what data was taken, and how the compromise likely unfolded. That intelligence allows your security team to act on a specific, confirmed risk rather than conducting an expensive, broad investigation with no direction.
Book a demo to see how Defendis approaches dark web monitoring for enterprise security teams.
