Background: developer, cybersecurity basics but not a security professional. Working on a M Chip Mac. Posting as a writeup and to sanity-check my analysis and response.

Discovery

Auditing login items in ~/Library/LaunchAgents/. Normally vendor-named (com.google.keystone.agent), but one entry was a bare 32-character hex string pointing to a JS file in an identically-named directory.

xml

ProgramArguments: /usr/bin/osascript -l JavaScript ~/Library/Application Support/<hex>/<hex>.js RunAtLoad: true KeepAlive: true ThrottleInterval: 60 StandardOutPath: /dev/null StandardErrorPath: /dev/null 

RunAtLoad/KeepAlive = starts at login, respawns on crash. Both output paths to /dev/null = zero logging by design.

The payload

Obfuscated (string-array rotation, a0_0x... identifiers, anti-beautify self-check, console hijacking). Working through it:

Fingerprinting: MD5 of the hardware UUID sent as User-Agent — stable per-host ID, survives reinstalls.

Polling: curl to a random-looking C2 domain every 60s via /api/poll.

Proof-of-work gating: server sends a challenge + difficulty; client brute-forces a nonce until SHA256(nonce-challenge) hits N leading zeros before getting a session token. Not security — anti-analysis. Burns sandbox CPU and filters out short-lived research environments.

Execution: response type field branches to osascript -l JavaScript, osascript (AppleScript), or curl | bash — all backgrounded, output discarded, payloads piped via stdin so nothing hits disk.

Ack loop: separate PUT confirming task completion, same PoW handling.

Key point

No credential-harvesting code, no keylogger, no exfil routine — it's a generic execution channel. What it did over 5 months is entirely dependent on what was pushed to it, and unknowable since nothing was logged.

Running as user (no root) but with osascript, reachable surface on a dev box: git tokens in .git/config, passphrase-less SSH keys, .env files, certs on disk, unprotected keychain items (plus AppleScript can render fake password prompts for protected ones), browser cookies/sessions, and screen capture. Secure Enclave–bound passkeys/Touch ID items held — not reachable by a software process, any attempt triggers an unspoofable OS prompt.

Install date (Spotlight kMDItemDateAdded): Feb 13. Found late July — ~5.5 months.

Why detection failed

Commercial AV installed the whole time; ran ClamAV afterward too. Zero detections, both, even knowing the exact path. Signature engines hash/pattern-match against known-bad corpora — useless against a bespoke, obfuscated, one-off sample. Nothing here is structurally illegal either: osascript is first-party Apple, a .js file + LaunchAgent plist are ordinary primitives. Only the naming convention and combination were anomalous — semantic signals a heuristic/behavioral engine could catch, not a signature one.

The actual detection method: ls -la ~/Library/LaunchAgents/.

Forensics: mostly a dead end

LSQuarantineEvent DB empty for that window (suggests the file was written by a running process, not browser-downloaded), Downloads/browser history clean, .zsh_history rotated out (SAVEHIST=1000), npm logs only back to July, unified log retention nowhere near 5 months, Time Machine's oldest backup postdates the incident.

Ruled out: no ClickFix-style paste-into-terminal.

What lines up temporally: a short GitHub Copilot session that evening, working on a payments API integration — chat history long gone. Circumstantial, not proof. But there are documented issues with AI coding agents: indirect prompt injection leading to unapproved shell execution, hidden-unicode instructions in config/rules files, hallucinated package names pre-registered by attackers. A compromised npm postinstall hook is equally plausible. Genuinely don't know.

Response:

Containment: unloaded LaunchAgent, killed process, removed plist + payload dir.

Verification (4 independent passes):

• KnockKnock (structural persistence enumeration, checks code signing) — everything else attributable/notarized
• Reboot + launchctl list | grep -v
  
  Vollständiger Original-Bericht

  Ausführliche Details, Code-Beispiele & Hersteller-Stellungnahme auf reddit.com.

  ↗ Original-Artikel auf reddit.com lesen