Fake Maccy Stealer : A macOS credential-stealing backdoor abusing script editor

Executive summary

• Lure — user searches for/downloads Maccy (a real, popular macOS clipboard manager) and lands on the look-alike maccyapp[.]com instead of the real site.
• Execution trick — instead of the usual "paste this into Terminal" ClickFix approach, the victim is guided to open Script Editor and hit Run—which slips past Tahoe 26.4's Terminal paste protections because Script Editor is a trusted Apple app.
• Payload lands — a Rust binary (renamed per host, so no static signature) drops and immediately establishes persistence—not via LaunchAgent/LaunchDaemon like most malware, but by installing a fake, ad-hoc-signed Finder.app as a Login Item.
• Callback — it derives its C2 address from a machine-bound fingerprint (not hardcoded) and opens an encrypted, bidirectional channel to avengerflow[.]com—so it's not just exfiltrating once, it's sitting there as a live implant.
• Blind spot — almost nothing catches it early (1/70 engines at submission) because every stage was built to dodge the specific things static AV and common EDR rules watch for.
• Consequence — because it's a live backdoor, not a smash-and-grab stealer, the response can't just be "delete the file"—anything the user session touched needs rotation/invalidation.

Overview of the attack

It starts with a search. Someone looks up Maccy, a popular open-source clipboard manager for Mac, and clicks a result sitting one line away from the real one. The site looks right, the download looks like an installer, and mounting it opens what appears to be a setup script asking for a single click to run. Within moments a disguised program is on disk wearing the Finder icon, it launches at every login, and it begins pulling saved passwords, browser logins, and whatever is on the clipboard out to a server that isn't Apple's. Nothing on screen looks out of place.

The bait is familiar: a look-alike domain impersonating a trusted developer tool. What makes MacOSapp1 worth documenting is the execution surface. Most macOS credential-theft campaigns this year have leaned on a Terminal copy-and-paste step, and Apple hardened exactly that surface in macOS Tahoe 26.4 with Terminal paste protections. MacOSapp1 sidesteps the hardening rather than defeating it: it delivers its dropper as a JavaScript-for-Automation (JXA) script that opens in macOS Script Editor, a first-party Apple application the paste protections don't cover. The user is asked to click Run. That single approved gesture is the whole attack.

The lure is also not incidental. Clipboard managers are used disproportionately by developers, IT administrators, and security staff—the people who routinely copy API tokens, SSH keys, recovery phrases, temporary passwords, and 2FA codes. A clipboard on that kind of host is a structured cache of fresh secrets, and this campaign is built to compromise the exact tool those targets use to handle them.

Attack dissection

The look-alike lure

Maccy is a widely used, open-source clipboard manager distributed from maccy.app and GitHub (p0deje/Maccy), built and signed by developer Alexey Rodionov (Team ID MN3X4648SC). The attacker registered maccyapp[.]com as a near-identical domain and optimized it to surface in search results next to the genuine project. The fake site advertises "Maccy 2.7.3," a version with no corresponding tag in the real repository, and serves the payload as maccy.dmg.

That format is the first free signal. The legitimate project has never shipped a DMG; every real release is published as Maccy.app.zip. Genuine Maccy builds are signed with an Apple Developer ID, notarized, and stapled, and they clear Gatekeeper without warning. The malicious disk image (45bd0e32…4c48c9) is ad-hoc signed with no Team Identifier and is rejected outright by spctl --assess.

The Script Editor JXA dropper

When the fake maccy.dmg is mounted, a compiled JXA .scpt file opens automatically in Script Editor. The visible portion of the script is a short, plausible configuration block that references the real Maccy App Store URL as a false trust signal, alongside an instruction to press ⌘ + R or click Run. The actual payload is a heavily obfuscated JXA routine pushed below the visible editor window with whitespace padding, so a casual look at the script shows nothing alarming.

macOS still shows an "unidentified developer" prompt when the script runs. That prompt is the same one users have been trained to dismiss for years, and the entire lure is engineered to get exactly that dismissal. There is no vulnerability here to patch—the weakness is a trusted execution surface plus a habituated click.

The dropper's source text is deliberately unreadable. It layers three obfuscation techniques so that no C2 URL or file path appears in the clear: string reversal (constants stored backwards and reassembled at runtime), XOR charcode arithmetic (characters derived from operations on integer literals), and URI-encoded Function() constructors (for example, Function("return decodeURIComponent(\'%69%6d%70%6f%72%74\')")() resolves to 'import').

Through the Objective-C bridge it imports Cocoa, IOKit, and CoreFoundation, which feed the anti-analysis checks that run before anything is downloaded.

CIS geo-fencing and a machine-bound C2 URL

Before it fetches a payload, the dropper runs four independent checks and aborts silently on machines associated with Russia and ten other CIS-aligned countries

• Timezone: NSTimeZone.localTimeZone.name against a set of CIS identifiers including Europe/Moscow, Asia/Almaty, and Europe/Minsk.
• Country/locale: CFLocaleCopyPreferredLanguages against the regex RU|BY|KZ|AM|AZ|KG|MD|TJ|UZ|TM|GE.
• Keyboard input source: TISCreateInputSourceList enumeration against CIS keyboard-language identifiers.
• Architecture: sysctlbyname("hw.optional.arm64"), reporting ARM64 vs x86_64 so the server can serve the correct binary. This is the check that confirms Apple Silicon is the primary target.

The design consequence matters more than the checks themselves. The C2 URL is stored in the JXA script as an RC4-encrypted blob whose key is derived from the four checks’ outputs, concatenated into a 32-byte system fingerprint. The URL therefore decrypts to a different value on every machine, and a researcher who pulls the encrypted blob out of the script cannot recover the URL without running the checks on a qualifying host. Static extraction of the C2 URL from the dropper alone is not possible—an offline or geo-mismatched sandbox never resolves it. (Note the deliberate cryptographic split: RC4 in the dropper, ChaCha20-Poly1305 in the Rust stage.)

The Finder masquerade and Login Item persistence

Once the checks pass, the dropper downloads the Rust binary over NSURLSession and builds a bundle designed to disappear into the system:

~/Library/Application Support/com.apple.finder.monitor/     (mimics Apple's reverse-DNS naming convention)
└── Finder.app/
    ├── Contents/
    │   ├── Info.plist      (LSUIElement=true · LSBackgroundOnly=true)
    │   ├── MacOS/
    │   │   └── F8C06C86    (944,464-byte Rust ARM64 infostealer;
    │   │                    8-hex-char name believed to rotate per host)
    │   └── Resources/
    │       └── AppIcon.icns (copied from the genuine Finder in /System/Library/CoreServices/)
    ├── .config             (34 bytes — plaintext C2 URL)
    ├── .lock               (0 bytes — single-instance mutex)
    └── .Maccy              (0 bytes — clipboard-monitoring marker)

Three choices here are engineered for detection avoidance. The directory name com.apple.finder.monitor imitates Apple’s own reverse-DNS convention for background services. The bundle is named Finder.app and uses a copy of the real Finder icon, so it appears as a second Finder process in Activity Monitor, visually identical to the first. The executable is named with eight hex characters believed to rotate per installation, which defeats hash-and-filename IOC sharing.

Info.plist sets LSUIElement=true (no Dock icon) and LSBackgroundOnly=true (no UI), so the process runs invisibly. The dropper then self-signs the binary with codesign -fs - --deep, ad-hoc signing that Gatekeeper would reject on assessment, but the binary was already authorized when the user approved the Script Editor script, so Gatekeeper does not re-evaluate at this point.

Persistence is registered two ways at once: the legacy LSSharedFileList (LSSharedFileListInsertItemURL on kLSSharedFileListSessionLoginItems) and the modern SMAppService from ServiceManagement.framework. The result shows up in System Settings → General → Login Items as “Finder” with the genuine Apple icon, and the Background Task Manager (BTM) database records it as 2.com.apple.finder.monitor. This is the operationally significant choice: LaunchAgent and LaunchDaemon paths are heavily monitored, whereas Login Item persistence via these APIs draws far less attention and the BTM database is rarely inventoried by default.

Credential theft and exfiltration

The Rust binary runs silently with I/O redirected to /dev/null, entirely within the user session, with no attempt at privilege escalation. Within that context its reach is wide:

• Keychain: SecItemCopyMatching with kSecClassGenericPassword extracts generic password entries from the login keychain—Wi-Fi passwords, app passwords, and credentials stored by password managers and browsers that use the Keychain as a backend.
• Browsers: Direct SQLite reads via libsqlite3.dylib against Chrome’s Login Data and Cookies, Firefox’s logins.json and key4.db, and Safari Keychain items. Session cookies are taken with their flags intact, which enables session hijacking without defeating a second factor.
• Clipboard: NSPasteboard.generalPasteboard captures whatever is copied while the process runs—the passwords, tokens, seed phrases, and recovery codes a clipboard-manager user handles by definition.
• PAM interception: The binary links libpam.2.dylib, the Pluggable Authentication Module library, which can intercept sudo prompts and system authentication dialogs after installation.

Collected data is encrypted with ChaCha20-Poly1305 (IETF, RFC 8439); the expand 32-byte k sigma constant in the binary strings confirms the Rust chacha20poly1305 crate. Each blob is structured [version 0x02][12-byte nonce][ciphertext][16-byte Poly1305 tag], and the beacon body is MacOSapp1{"data":"<encrypted blob>"}. That format, and a C2 contact at 2026-06-26 07:38:02 UTC to https://avengerflow[.]com/api/sync, were recovered from the malware’s own SQLite cache database. The channel is bidirectional: a captured response carrying an encrypted blob confirms the server sends commands back, which is the line between an infostealer and a backdoor.

The chain, step by step

User searches "Maccy" → clicks SEO-positioned look-alike maccyapp[.]com (not the real maccy.app)
   |
   v
maccy.dmg mounted → compiled JXA .scpt opens in Script Editor
   (first-party Apple app; user clicks Run—no Terminal, no paste)
   |
   v
Four CIS geo-fence checks
   (timezone · locale · keyboard · arch; aborts on Russia/CIS)
   |
   v
RC4-decrypt C2 URL from 32-byte machine fingerprint
   (unique per host; not statically extractable)
   |
   v
Rust ARM64 binary downloaded → fake Finder.app built under
   ~/Library/Application Support/com.apple.finder.monitor/
   ad-hoc self-signed; LSUIElement/LSBackgroundOnly hide it
   |
   v
Login Item persistence via LSSharedFileList + SMAppService
   (shows as "Finder"; avoids LaunchAgents/LaunchDaemons)
   |
   +------------------------------+
   v                              v
Second "Finder" process        Credential + clipboard theft
in Activity Monitor            Keychain · browser SQLite ·
(real Finder only ever         NSPasteboard · PAM interception
 runs from CoreServices)          |
                                  v
                               ChaCha20-Poly1305 blob →
                               HTTPS POST to avengerflow[.]com/api/sync
                               (bidirectional—treat host as live implant)

How it looks in telemetry

None of the following depends on a hash or signature specific to this campaign, deliberately, since the Rust binary was 1/70 at first submission and its on-disk name rotates per host:

• A second Finder from a non-system path. The real Finder always runs from /System/Library/CoreServices/Finder.app. No legitimate software runs a process named Finder from anywhere else. This is the single most reliable check and it is testable with one rule.
• A Login Item named "Finder" outside CoreServices. Enumerate Login Items and audit the BTM database (sfltool dumpbtm, and backgrounditems.btm under ~/Library/Application Support/com.apple.backgroundtaskmanagementagent/). This closes the gap the campaign opens by avoiding LaunchAgents/LaunchDaemons.
• An ad-hoc-signed Finder.app. Monitor for a bundle named Finder.app with Signature=adhoc and TeamIdentifier=not set. The malware cannot impersonate Apple’s signing chain.
• Script Editor as an execution surface. Alert when Script Editor.app spawns children that reach the network, write into ~/Library, invoke codesign, or register a Login Item. Treat it the way you already treat osascript and bash.
• Non-browser processes reading browser credential databases, and Keychain queries (SecItemCopyMatching / kSecClassGenericPassword) from a process outside /Applications or /System.
• Outbound HTTPS POST attributed to bundle ID com.apple.finder.monitor. The real Finder makes no such requests.

A rough process-lineage starting point, adjusted to your platform’s syntax:

parent_process == "Script Editor"
AND child_process performs (network_connect
                            OR file_write to "~/Library/Application Support/"
                            OR codesign
                            OR LSSharedFileListInsertItemURL)

Indicators of compromise

Durable indicators reflect design choices the operator would have to rebuild the toolkit to change; they are the ones worth building detections around. Volatile indicators—hashes, domains, IPs—rotate whenever the operator decides to, and should not be the primary detection.

Durable — file system and structural

Durable — process and identity

Volatile — network

Volatile — hashes

Conclusion

Fake maccy malware is clean in signature-based scanning at the moment it matters, so hunt the durable indicators rather than a hash, and treat any hit as an active-compromise investigation rather than a cleanup. The C2 is bidirectional; the question is what the operator did after check-in, not whether the installer is still on disk. Isolate the host before rotating anything.

Practical, low-effort controls:

• Verify Maccy against official sources only. Legitimate Maccy ships exclusively from maccy.app, GitHub (github.com/p0deje/Maccy/releases), the Mac App Store (publisher Alexey Rodionov, Team ID MN3X4648SC), and Homebrew (brew install --cask maccy), always as Maccy.app.zip, never a DMG. Confirm with codesign -dvvv Maccy.app — a genuine build shows Authority=Developer ID Application: Alexey Rodionov (MN3X4648SC) and a stapled notarization ticket.
• Block delivery and C2 at DNS and proxy.maccyapp[.]com is a permanent, zero-risk block. avengerflow[.]com should be blocked for the duration of the campaign; because it is Cloudflare-fronted, IP blocking alone won’t hold.
• Audit Login Items fleet-wide.sfltool dumpbtm across managed endpoints, flagging any bundle ID containing com.apple.finder whose path doesn’t resolve to CoreServices. This is the most reliable single fleet check for this campaign.
• Monitor Script Editor as a high-risk execution surface, and consider MDM restrictions on it for roles that don’t need it.
• Reduce standing credential exposure. On any confirmed infection, treat all Keychain entries, browser-saved passwords, and clipboard contents from the infection window as compromised and rotate immediately.