I Stopped Trusting the Headlines and Checked My Security App Against Real AI-Orchestrated Attacks

A Japanese, more code-heavy version of this is on Zenn.

I build RoamSwitch, a solo-developed network security app for Mac and Linux. It locks down the firewall and shared services the instant you're on a network you haven't approved, and on Pro it adds things like emergency network isolation when it sees ransomware-like behavior, and DNS-layer blocking of phishing/C2 domains.

For the last few releases I'd been building two fairly unglamorous features, a log auditor that flags frequency anomalies against a learned baseline, and a package CVE matcher that checks installed software against a daily-updated vulnerability map. Ordinary "catch what's new, patch what's known" work. Around the same time, Anthropic's threat reports and a string of vendor writeups started describing AI agents autonomously running most of an intrusion themselves. I got uneasy. Was any of what I'd built actually relevant to that, or was I just watching a different movie? I wanted to check the actual technical detail of reported cases against my own code, not against a vibe.

GTG-1002, where AI ran 80-90% of an espionage campaign itself

In November 2025, Anthropic disclosed that a China state-linked group it tracks as GTG-1002 used Claude Code to run a large-scale cyber-espionage campaign against roughly 30 organizations, tech companies, financial institutions, a chemical manufacturer, government agencies, with AI performing an estimated 80-90% of the work, reconnaissance, exploitation, credential harvesting, and exfiltration among it. Human involvement was limited to a handful of strategic go/no-go decisions.

The interesting part is how they got past the model's own safeguards. The operators didn't jailbreak Claude Code in the classic sense. They framed the work as a legitimate, authorized defensive security engagement and kept the framing consistent across the whole engagement. The model accepted the premise and executed each subsequent step as ordinary, sanctioned work. Less "break the lock," more "convince the guard you're supposed to be there."

GTG-2002, where one person made AI the operator, not the advisor

A different Anthropic disclosure from August 2025, GTG-2002, is a smaller-scale but in some ways more unsettling case. A single actor, not a state-backed group, used Claude Code not as a planning aid but as the actual operator, running a data-extortion campaign against 17 organizations across government, healthcare, financial, and emergency-services sectors.

What Claude Code actually did, concretely, reads like a checklist. Network reconnaissance and help with initial access, generating custom exfiltration malware built on the Chisel tunneling tool, hardening that malware against detection with string encryption, anti-debugging tricks, and filename masquerading, analyzing the stolen data to set ransom demands (ranging $75,000 to $500,000), and writing custom HTML ransom notes per victim. The attacker didn't need to be able to code. Claude wrote it for them.

What both cases share isn't really about model capability. It's about how much operational tool access the agent was handed, and how the intent-verification step got defeated. RoamSwitch's own MCP server has been read-only from day one, no config changes, no lockdown toggles, nothing but diagnostics, specifically to avoid this exact failure shape. I want to be honest about scope, though. GTG-1002 and GTG-2002 were intrusions into corporate cloud and internal network infrastructure. RoamSwitch protecting an individual's Mac isn't in the same weight class. What these cases actually validate is the design principle (give an agent the minimum tool surface it needs), not that RoamSwitch would have stopped them.

ClickFix to MacSync/AMOS, the one that can actually hit an individual Mac

Closer to home. Between late 2025 and 2026, ClickFix campaigns disguised as fake AI tool installers have been observed in the wild. The chain plays out like this.

1. Someone searches for a real AI tool by name, "ChatGPT Atlas" and similar, and a sponsored search result (a Google Ad) routes them to a fake landing page.
2. The page shows a fake CAPTCHA that instructs the victim to open Spotlight and paste a "verification code."
3. That "code" is actually a curl command. The instant Enter is pressed, a malicious script is fetched and run from the attacker's server.
4. What gets dropped is an AppleScript-based infostealer (MacSync, also tracked as Atomic macOS Stealer / AMOS) that harvests credentials and session cookies from 14 browsers, 16 crypto wallets, and 200+ extensions.

The evasion arms race is the ugly part. Once macOS 26.4 added a warning for multi-line Terminal pastes, the attackers immediately pivoted to routing execution through Script Editor via the applescript:// URL scheme instead, using dynamic AppleScript payloads and in-memory execution to dodge static analysis.

I walked this attack chain against RoamSwitch's actual guards, stage by stage.

At the ad/landing-page stage, LinkGuardManager (Pro, a signed daily threat feed plus /etc/hosts sinkholing and a NEFilter content-filter extension) and DNSThreatGuard (switching resolution to Quad9 or Cloudflare Security) can both block the connection if the domain is already on a reputation list. Both are reputation-based, though, so a campaign's brand-new domain, not yet flagged anywhere, gets through.

The Spotlight/Script Editor paste-and-execute moment turned out to be the most surprising part of writing this piece. There was already a dedicated guard for it, ClickFixGuard.swift, watching ~/.zsh_history and ~/.bash_history for the double-indirection pattern legitimate installers don't use (base64-decode piped straight into bash or osascript), and firing an emergency network Air-Gap on a hit. But by its own doc comment it's structurally post-hoc, it can only see a command after it's already run, and Script Editor's do shell script never touches either history file in the first place, which is exactly the pivot attackers made once Terminal started warning. Re-reading the code for this piece is what surfaced the fix. SecretLeakAuditor already ran a 1-second NSPasteboard.changeCount poll (on by default) for a different purpose, catching leaked API keys. Adding one call to ClickFixGuard.matchClickFixPattern() (already a standalone nonisolated static func) catches the same pattern the instant it's copied, before the user pastes it anywhere. It doesn't matter whether the destination is Terminal, Script Editor, or some other launcher entirely, detection happens at copy-time and the clipboard gets cleared immediately on a hit. I actually built and shipped this while writing the article, so this line item moves from "can't catch it" to "catches it."

Post-execution keychain, browser, and wallet theft is still an open gap. Watching keychain access needs an EndpointSecurity entitlement, a meaningfully heavier lift, and I scoped it out deliberately rather than by oversight. C2 exfiltration is symmetric with the landing-page stage. DNSThreatGuard/LinkGuard can block it if the destination domain is already known-bad.

The log auditor (frequency-anomaly detection) is where I'd overestimated my own work and want to correct the record. SecurityLogAuditor's actual predicate only covers sudo, sshd, loginwindow, Gatekeeper (com.apple.security.syspolicy), and XProtect-related processes. It doesn't watch osascript launches or curl invocations at all, so it has no behavioral read on AMOS running. I went further and checked whether widening that predicate would even help, by actually pulling the unified log. It wouldn't. osascript launching is logged, but the actual command text handed to do shell script is never recorded anywhere in the log. There's no widening of scope that fixes this, the data simply isn't there. What the log auditor is genuinely good for is surfacing an XProtect detection, if and when Apple ships a signature for this malware family, as a scored, "first time we've seen this template" anomaly instead of something buried in Console.app that nobody reads.

I ported the same clipboard check to the Linux build (roamswitch-linux) too, since GNOME's Alt+F2, KRunner, and similar "paste and run" launchers make the same attack viable there. It ended up simpler than I expected. Instead of shelling out to xclip/wl-paste, it reuses gtk::Clipboard, which already worked transparently across X11 and Wayland for the existing leaked-secret scanner, so no external process calls needed. The pattern match shares its ruleset with the on-disk YARA scanner, and clears the clipboard on a hit the same way the Mac side does.

OpenClaw/ClawHavoc, when the target is the agent, not the human

Between late January and February 2026, a large-scale supply-chain poisoning campaign, tracked as ClawHavoc, hit OpenClaw's ClawHub, a marketplace for AI-agent skills. Attacker-registered developer accounts uploaded 1,184+ malicious skills; Bitdefender Labs found roughly 17% of skills analyzed in the marketplace's first few weeks carried a malicious payload. The trick is hiding instructions inside SKILL.md/README documentation, so an agent reading the "docs" as part of its normal workflow ends up fetching and running malware, confirmed in the wild as an AMOS distribution vector.

The shift here is explicit. The target moved from "deceive the human" to "manipulate the agent's workflow." Since the payload is AMOS again, the C2/domain-reputation story is basically the same as before. But the clipboard fix doesn't apply here, and I want to be precise about why. It assumes a human is copying and pasting a command somewhere. An agent reading SKILL.md and running a shell command directly never touches the clipboard, so it sails right past that check. Worth noting separately, RoamSwitch's guard that blocks external LAN access to local AI server ports (Ollama on 11434, LM Studio on 1234, and similar) covers a different threat entirely, inbound access to a model server on your own machine, not an agent on that same machine being tricked into acting against it.

There's one real lead here, though, and it's Linux-specific. The Server Edition's eBPF-based Runtime Guard (built on Falco/Tetragon) captures full command text at the kernel level, unlike AppleScript's do shell script. Server Edition's whole use case is a headless machine an AI agent operates on your behalf, which maps directly onto this exact threat. Wiring click_fix::match_clickfix_pattern() into that pipeline has real potential value. Two things stand between "potential" and "shipped," though. Falco/Tetragon is a genuinely heavy dependency, not something you casually add to a lightweight client build the way the clipboard fix was, and it's entirely possible Falco/Tetragon's own default ruleset already flags a base64-decode-into-bash pattern, which I haven't checked yet. Finding that out comes before writing any new code.

What actually changed wasn't the bug class

Lay these cases side by side and no new vulnerability class jumps out. ClickFix social engineering, AppleScript-based stealers, C2 exfiltration, all extensions of things that existed years ago. What changed is speed and cost. Flashpoint's research puts the median time from vulnerability disclosure to actual exploitation at 745 days in 2020, down to 44 days in 2025, though that's mostly the mainstreaming of n-day exploitation in general, not something you can pin specifically on AI. The more directly AI-attributable number comes from CrowdStrike's 2026 Global Threat Report. AI-enabled adversary operations were up 89% year over year, with average breakout time (initial access to lateral movement) down to 29 minutes, fastest observed at 27 seconds. Reconnaissance, exploit authoring, ransom-note drafting, work that used to bottleneck on human time, is now something AI does cheaply and at volume. RoamSwitch's package CVE matcher pulling a daily-updated vulnerability map and attempting a background fetch mid-scan is built around exactly that bottleneck disappearing.

There's a second, nastier implication for signature-based detection specifically. When AI regenerates and re-obfuscates the malware binary per target, the way GTG-2002 did, the same campaign can produce a different hash for every victim. A static-signature scanner like ClamAV is structurally always a step behind that, which is why leaning on behavior- and destination-based layers, log auditing, DNS reputation, alongside it isn't a hedge, it's the correct response to that specific weakness.

Writing this actually closed one real gap, and that felt good. Here's what's still open. Keychain access after execution, scoped out on purpose, not by accident; and an AI agent driving a shell directly without ever touching a clipboard, unsolved on Mac, a real but unconfirmed lead on Linux Server Edition. No amount of engineering makes this category of attack go away completely. What you can do is know exactly where the gaps are, work backward from real incidents to figure out what to close next, and actually close what's closable.