macOS Infostealers 2026: YARA Rules for CrashStealer, PamStealer and ClickFix DMGs

Since late 2025, Microsoft and Jamf have independently documented the same shift: infostealers targeting macOS are no longer a marginal phenomenon. Families like CrashStealer or PamStealer, distributed through trojanized DMG installers, using the ClickFix infection chain (the user pastes a command into Terminal themselves after seeing a fake verification alert). The tradecraft keeps evolving, but the blind spot in most SOCs stays the same: detection rules, playbooks and analyst habits are still built almost entirely around Windows. A BYOD Mac fleet, increasingly common in SMBs, slips right through that filter unseen.

This article details a static YARA detection method against these threats, starting from artifacts actually documented by researchers rather than a rule copy-pasted from a random repository.

The starting point: the fact, not the borrowed rule

Before writing a single signature, two very different sources need to be separated. On one side, public incident reports and advisories (Jamf Threat Labs, Microsoft Defender for Endpoint, or independent analyses published under an open license) describe an observed behavior: this Mach-O binary contains that string, this bash script decodes that payload from base64. That technical fact belongs to no one. On the other side, a YARA rule found on a GitHub repo with no explicit license is copyrighted by default, and lifting it as-is into a commercial pack is a licensing problem, not just a quality one.

The right approach is to reconstruct the signature from the documented behavior, then validate it independently against a real sample or a faithful lab reproduction. That is what separates a rule that survives the next campaign from one that breaks the moment the payload changes slightly.

Obfuscated bash scripts embedded in DMGs

The classic entry vector for CrashStealer and close variants is a DMG bundling a shell script, often base64-encoded to dodge shallow scanning and complicate manual review. Once decoded, that script calls osascript to display a convincing system window, then a curl call to command-and-control infrastructure to fetch the final payload.

An effective static rule targets the obfuscation structure itself rather than the exact payload content, which changes with every campaign:

rule MacOS_DMG_Base64_OsaScript_Curl_Chain
{
    meta:
        description = "Shell script embedded in a DMG: base64 decode piped into osascript, followed by a C2 call"
        family = "generic-macos-dropper"
        confidence = "medium"
 
    strings:
        $b64_marker = /echo\s+[A-Za-z0-9+\/=]{80,}\s*\|\s*base64\s+(-D|--decode)/
        $osascript  = "osascript" ascii
        $curl_out   = /curl\s+(-s|--silent)?\s*-o\s+/
        $curl_pipe  = "curl" ascii nocase
 
    condition:
        filesize < 2MB and
        $b64_marker and
        $osascript and
        1 of ($curl_out, $curl_pipe)
}

The key is the combined condition: osascript or curl alone mean nothing (thousands of legitimate installers use both), it is the conjunction of a base64 decode followed by a network call that turns into a signal.

Detecting direct Keychain access outside an Apple process

The core payload of a macOS infostealer is always credential exfiltration from the Keychain. A legitimate tool goes through Apple's frameworks (Security.framework) with the right entitlements. A malicious binary, instead, frequently shells out directly to security find-generic-password, or reads files under ~/Library/Keychains/ bluntly, bypassing the intended API entirely.

rule MacOS_Unsigned_Keychain_Direct_Access
{
    meta:
        description = "Direct Keychain access (CLI or file path) inside a non Apple-signed Mach-O binary"
        family = "generic-macos-stealer"
        confidence = "high"
 
    strings:
        $sec_cmd    = "security find-generic-password" ascii
        $sec_cmd2   = "security find-internet-password" ascii
        $kc_path    = "/Library/Keychains/" ascii
        $kc_path2   = "login.keychain-db" ascii
 
    condition:
        uint32(0) == 0xFEEDFACF and
        2 of ($sec_cmd, $sec_cmd2, $kc_path, $kc_path2)
}

The 2 of threshold (at least two indicators out of four) avoids firing on a single incidental mention in an embedded log or documentation file, while staying sensitive to the typical command-plus-path combination.

Spotting ClickFix prompts

The ClickFix chain has become the dominant social engineering vector on macOS in 2026: a fake page or window prompts the user to "verify they are not a robot" by copying a command, then pasting it into Terminal. The script or binary orchestrating that window through osascript uses native system dialogs (display dialog, display alert) with copy mimicking a security check.

rule MacOS_ClickFix_Fake_Verification_Prompt
{
    meta:
        description = "osascript prompt mimicking a verification window (ClickFix pattern)"
        family = "clickfix-macos"
        confidence = "medium"
 
    strings:
        $dialog1 = "display dialog" ascii
        $dialog2 = "display alert" ascii
        $lure1   = /verif(y|ication)/ nocase ascii
        $lure2   = "not a robot" nocase ascii
        $lure3   = "captcha" nocase ascii
        $clip    = "pbcopy" ascii
 
    condition:
        1 of ($dialog1, $dialog2) and
        1 of ($lure1, $lure2, $lure3) and
        $clip
}

The presence of pbcopy (the macOS clipboard tool) alongside a dialog and a text lure is a triangle rarely seen in legitimate software: it is exactly the mechanism that stages the command the victim is about to paste into Terminal themselves.

Avoiding false positives: whitelist by TeamID, never by name

The classic pitfall of an overly broad Keychain detection rule is blocking real password managers (1Password, Bitwarden, Dashlane) that legitimately touch the Keychain for system integration. The right practice is never to exclude by process name (trivially spoofable) but by the Apple developer signature TeamID, checked upstream of the YARA scan, not inside the rule itself.

# Signature check upstream of the YARA scan
codesign -dv --verbose=4 "$BINARY" 2>&1 | grep -q "TeamIdentifier=2BUA8C4S2C" && echo "1Password verified, excluded from scan"

That filtering step belongs in the orchestration pipeline, never in the YARA rule itself: a rule should never carry trust-identity business logic, only technical artifacts.

The engine gate: Mach-O magic and a performance budget

A poorly scoped YARA rule can slow down a full fleet scan, especially with wide regexes applied against large binaries. The right practice is to gate first on the Mach-O magic number (0xFEEDFACF for a 64-bit binary, 0xFEEDFACE for the legacy 32-bit one) before any string analysis, and to restrict scanning to the locations that actually carry risk: the Downloads folder, files carrying the Gatekeeper quarantine attribute (com.apple.quarantine), rather than a blind scan of the entire disk.

condition:
    uint32(0) == 0xFEEDFACF or uint32(0) == 0xFEEDFACE

This initial gate discards almost every irrelevant file with a single integer comparison before paying the cost of string matching and compound conditions, a performance principle that holds on any scan engine operating at fleet scale.

Complementary behavioral indicators

Static YARA detection covers the artifact at rest, but two behavioral signals reinforce confidence on a live incident: persistence added through a LaunchAgent file under ~/Library/LaunchAgents/ created shortly after a DMG is mounted, and a child process spawning directly from a DMG mount point (/Volumes/) rather than from /Applications. Cross-referenced with a static rule that already matched, these two elements turn a plain alert into a priority case.

Is my BYOD Mac fleet actually covered?

That is the concrete question most security leads face once they realize their tooling was built for Windows: yes, but only if macOS coverage is not an accidental byproduct of a stack designed for a different operating system. Mach-O artifacts, Keychain paths and osascript scripts have no direct equivalent on Windows, a generic Windows-EDR rule will never see them. What is needed is an explicit macOS vertical, tested against real samples, with its own false-positive budget.

In summary

Detecting macOS infostealers demands the same rigor as any other platform: start from documented behavior, not copied code, gate on binary structure before strings, prove the absence of false positives against legitimate tools that touch the Keychain, and complement static detection with behavioral persistence indicators. That is the discipline applied in the ThreatClaw YARA feed: macOS rules validated on the real engine, prioritized by active family, ready to cover a BYOD fleet your Windows tooling never looks at.