Fake Maccy Stealer

Maccy is a widely used open source clipboard manager distributed from maccy.app and GitHub, built and signed by developer Alexey Rodionov (Team Identifier MN3X4648SC). The attacker registered maccyapp[.]com as a near identical domain and optimized it to appear in search results alongside the legitimate project listing. The malicious domain claims to distribute Maccy version 2.7.3, a version number with no corresponding GitHub tag in the legitimate repository.

The payload is served as maccy.dmg. The official Maccy project has never distributed a DMG; all legitimate releases are published as Maccy.app.zip on GitHub. That format mismatch is the first detectable signal. The SHA-256 of the malicious disk image (45bd0e321aa85b63b5dee4e87465e4088546eea5da6efb9c96847023384c48c9) does not match any legitimate Maccy release hash. Legitimate Maccy binaries are signed with an Apple Developer ID, notarized and stapled, and pass Gatekeeper without warnings. The malicious payload is ad-hoc signed with no Team Identifier and is explicitly rejected by spctl --assess.

The lure selection is deliberate. Clipboard managers are disproportionately used by developers, IT administrators, and security professionals who regularly copy and paste sensitive material: API tokens, SSH keys, recovery phrases, temporary passwords, and 2FA codes. A clipboard running on such a host is a structured cache of recently used secrets. The campaign is designed to compromise the tool its targets rely on to handle that data.

When the victim mounts the DMG, a compiled JXA .scpt file opens automatically in macOS Script Editor. The visible portion of the script contains a short, plausible looking configuration block referencing the official Apple App Store URL for Maccy, alongside instructions to press ⌘ + R or click the Run button. The App Store URL is a deliberate trust signal and has no functional role. The real payload is a heavily obfuscated JXA routine hidden below the visible editor window through whitespace padding.

Why Script Editor bypasses macOS protections: Script Editor is a first party Apple application with full system trust. Apple's macOS Tahoe 26.4 Terminal paste protections target the specific attack surface where victims are instructed to paste commands into Terminal. Those controls have no effect on code executed by clicking Run inside Script Editor. macOS does display an "unidentified developer" warning when the script runs, but this is the same prompt users have been conditioned to dismiss for years, and the lure is built around getting them to do exactly that.

The obfuscation in the JXA script uses three layered techniques. String reversal: constants are stored backwards and assembled at runtime. XOR charcode arithmetic: individual characters are derived from arithmetic operations on integer literals. URI-encoded Function() constructors: the instruction Function('return decodeURIComponent(\'%69%6d%70%6f%72%74\')')() evaluates to 'import' at runtime. The result is a dropper that does not contain any readable C2 URL or file path in its source text.

The JXA script imports three macOS frameworks through the Objective-C bridge: Cocoa (UI, NSWorkspace, NSFileManager), IOKit (hardware enumeration), and CoreFoundation (timezone and locale queries). These imports are the basis for the four geo-fence checks that run before any payload is downloaded.

Before downloading or installing anything, the JXA dropper runs four independent checks to abort execution on machines associated with Russia or ten other CIS aligned countries. This pattern is consistent with Russian speaking MaaS operators protecting themselves from creating victims who could file a domestic complaint, a practice documented across multiple macOS infostealer families operating in the same ecosystem.

• Timezone check:NSTimeZone.localTimeZone.name against 12 CIS identifiers including Europe/Moscow, Asia/Almaty, Europe/Minsk, and related zones.
• Country code check:CFLocaleCopyPreferredLanguages against the regex RU|BY|KZ|AM|AZ|KG|MD|TJ|UZ|TM|GE.
• Keyboard input source check:TISCreateInputSourceList enumeration against a list of CIS keyboard language identifiers.
• Architecture check:sysctlbyname("hw.optional.arm64") to report ARM64 vs x86_64 to the C2, allowing the server to serve the correct binary. This is the check that confirms Apple Silicon targeting as the primary objective.

The C2 URL is stored in the JXA script as an RC4-encrypted blob (distinct from the ChaCha20-Poly1305 used in the Rust binary). The RC4 decryption key is derived from the outputs of the four geo-fence checks concatenated into a 32-byte system fingerprint. This design means the C2 URL decrypts to a different value on every machine, and a researcher extracting the encrypted blob from the script source cannot recover the URL without running the checks on a qualifying host. Static IOC extraction of the C2 URL from the dropper script alone is not possible.

Once the geo-fence checks pass, the JXA dropper downloads the Rust binary from the decrypted C2 URL via NSURLSession and builds the following structure on disk:

~/Library/Application Support/com.apple.finder.monitor/
<!-- mimic Apple reverse-DNS naming convention -->
└── Finder.app/
    ├── Contents/
    │   ├── Info.plist          (LSUIElement=true · LSBackgroundOnly=true)
    │   ├── MacOS/
    │   │   └── F8C06C86        (944,464 bytes — Rust ARM64 infostealer)
    │   └── Resources/
    │       └── AppIcon.icns    (copied from /System/Library/CoreServices/Finder.app)
    ├── .config                 (34 bytes — C2 URL plaintext: https://avengerflow.com/api/sync)
    ├── .lock                   (0 bytes — single-instance mutex)
    └── .Maccy                  (0 bytes — clipboard monitoring marker)

Three aspects of this layout are purpose engineered for detection avoidance. The directory name com.apple.finder.monitor imitates the reverse-DNS convention Apple uses for its own background services. The bundle is named Finder.app and uses a copy of the genuine Apple Finder icon lifted from the system path, producing a second process in Activity Monitor that is visually identical to the real Finder. The executable inside is named with eight hex characters derived from the host, which is believed to rotate per installation, defeating binary hash IOC sharing at the filename level.

The Info.plist sets LSUIElement=true (no Dock icon) and LSBackgroundOnly=true (no UI surface), so the process runs entirely invisibly. After writing the bundle, the dropper self-signs the binary using codesign -fs - --deep (ad-hoc signing), producing a Gatekeeper rejection when assessed with spctl --assess, but the binary has already been authorized by the user's approval of the Script Editor script, which means Gatekeeper does not re-evaluate at this point.

Persistence is registered via two APIs simultaneously: the legacy LSSharedFileList (LSSharedFileListInsertItemURL on kLSSharedFileListSessionLoginItems) and the modern SMAppService from ServiceManagement.framework. The resulting Login Item appears in System Settings → General → Login Items as "Finder" with the genuine Apple Finder icon. The Background Task Manager (BTM) database records it as 2.com.apple.finder.monitor with disposition [enabled, allowed, visible, notified].

The choice to use Login Items rather than LaunchAgents or LaunchDaemons is operationally significant. Detection coverage for ~/Library/LaunchAgents/*.plist and /Library/LaunchDaemons/*.plist is well-established in macOS security tooling. Login Item persistence via LSSharedFileList and SMAppService receives substantially less detection attention, and the BTM database entry is not examined by default in most security tool inventories.

The Rust binary runs silently, with all I/O redirected to /dev/null. It operates entirely within the user session context and does not attempt privilege escalation. What it can access within that context is extensive.

Keychain credentials: The binary calls SecItemCopyMatching with kSecClassGenericPassword, kSecAttrService, kSecReturnData, and kSecReturnAttributes. This API chain extracts generic password entries from the login keychain, covering Wi-Fi passwords, application passwords, and credentials stored by password managers and browsers that use the Keychain as a backend.

Browser credentials: Direct SQLite access via libsqlite3.dylib targets Chrome's Login Data and Cookies databases, Firefox's logins.json and key4.db, and Safari Keychain items. Session cookies are captured with their security flags intact, enabling session hijacking without needing to crack a second authentication factor.

Clipboard contents:NSPasteboard.generalPasteboard captures whatever the user has copied while the process is running. This is precisely the data a clipboard manager user expects to see: passwords, tokens, seed phrases, and recovery codes copied during normal work.

PAM interception: The binary links libpam.2.dylib, the Pluggable Authentication Module library. This can intercept system authentication events, potentially capturing passwords entered into sudo prompts or system security dialogs after installation.

Collected data is encrypted with ChaCha20-Poly1305 (IETF variant, RFC 8439). The presence of the string expand 32-byte k in the binary strings confirms the ChaCha20 sigma constant from the Rust chacha20poly1305 crate. Each encrypted blob follows the structure: [version: 1 byte = 0x02] [nonce: 12 bytes] [ciphertext: N bytes] [Poly1305 tag: 16 bytes]. The beacon body format is MacOSapp1{"data":"<encrypted blob>"}, which was confirmed from the malware's own SQLite cache database, which recorded a C2 contact at 2026-06-26 07:38:02 UTC to https://avengerflow.com/api/sync.

The C2 channel is bidirectional. A captured C2 response containing an encrypted blob confirms that the server sends commands back to the implant. A compromised host should be treated as an active implant, not as a one-shot credential leak. All credentials should be considered exposed and rotated, and all active sessions should be invalidated.