The Attacker Only Has to Decide Once
For most of security history, the person deceiving you and the person deciding what happens next were the same human, working in real time. That’s changing. Once you notice it, it shows up everywhere.
Look at four recent stories: phishing that abuses a real Microsoft sign-in flow, a North Korean group planting malware through fake job interviews, the same group turning up on a package registry that had never been abused this way, and a crew that let three chained AI agents run a card-theft campaign against more than a hundred companies. They cover different topics but share one shift, at increasing levels of automation.
Chapter one: getting a human to do the trusted step
Device code phishing barely fakes anything. Instead of a lookalike login page, the attacker starts a real Microsoft device sign-in flow, the same one a smart TV uses to authenticate. It generates a genuine code and a genuine verification page. The attacker just needs a pretext (a fake Teams invite, a “secure chat”) to get the victim to type that code in.
The victim logs into the real site, completes their own MFA, and hands the resulting token to someone else. There’s no fake domain to spot, because there isn’t one. The trust was never in the interface. It was in the person clicking, and the attacker only had to supply a believable reason to click.
The same shape appears in North Korea’s Graphalgo campaign: a convincing LinkedIn profile, a job offer from a Web3 company that doesn’t exist, a “coding challenge” repo. The target isn’t lured to a fake site. They run real code on a real machine as part of what looks like a normal hiring process. The repo itself looks clean, because the malicious part arrives through a dependency.
This September, that dependency trick moved to the HashiCorp Terraform Registry, the first time the public registry has been used to distribute malware. One of the providers was published as kreuzwenker/docker, one letter away from the legitimate and widely used kreuzwerker/docker. So there is some faking here after all, just one layer upstream. The attacker doesn’t fake the login page. They fake a name in a list developers already trust, and let the interview supply the reason to install it.
In all of these cases the attacker’s job was persuasion. Get a human to take one legitimate action in the wrong context, and the system does the rest. What happened next, with the stolen token or the compromised laptop, was still a human decision, made in the moment.
Chapter two: deciding once, in advance
The fourth story is where that pattern breaks.
In September, researchers at Gambit got into a staging server run by an attacker who had been active since at least July. By then the operation had compromised at least 119 websites, including a Fortune 500 hospitality company and a major U.S. airline. It had pulled more than 600,000 card records straight from the databases of two companies and planted skimmers on the checkout pages of five more.
Card theft itself isn’t new. What was new was how the operation ran.
Three chained AI tools did the work. Strix handled scanning. Cairn was an autonomous exploitation engine that chased goals like “get a shell.” Hermes orchestrated everything, reportedly running on Claude Opus 4.6. Hermes carried a persona file named “SOUL - Red Team Operator” and 121 skills, 78 of them offensive. It chose the injection method (a tampered JavaScript file, a script tag in a tag manager block, a poisoned CDN cache), decided when to escalate, and decided when to move on.
The human mostly handed over short goals between runs. Between September 10 and 15, the setup launched 105 attack waves and succeeded to some degree on at least 27 targets. Scanning alone added up to 633 hours against 138 hosts in nine days.
The detail worth remembering is a single line in one of the skill files, which told the agent to “wipe the source fields in batches” once the card data was downloaded. It’s tempting to read that as an agent deciding to cover its tracks. It wasn’t. A human decided that, once, when writing the file. The agent then carried it out against every Magento database it reached, and the wipes caused real outages at several retailers. The human never had to reconsider, and nobody did.
That’s the actual shift. The attacker didn’t stop making decisions. They stopped making them in real time. The judgment moved out of the operator’s head and into goals, personas, and skill files that run unattended, at a scale no single operator could match.
Same trust problem, the decision just moved
The pattern isn’t “attackers use fancier tools.” That’s true every year and not very interesting. What’s interesting is that the point where trust gets exploited has moved twice, in the same direction. First it moved from the interface to the person: get a human to take one real step for you. Then it moved from the person to a written instruction: decide once, and let an agent take every step after that.
Defenders are heading the same way, with AI-assisted triage, autonomous response, and agents acting in the SOC without a human checking every alert. Gambit shows what that looks like without the guardrails a real security team would insist on. A reasonable-sounding line, written once and never revisited, turned into data loss at victims the author never looked at. That’s familiar if you’ve ever watched an agent take an instruction a little too literally. It applies to your own runbooks just as much as to theirs.
What this changes for you
If you run Microsoft 365: MFA won’t stop device code phishing, because the victim completes MFA themselves. Block the device code flow with Conditional Access for everyone who doesn’t need it, and move toward phishing-resistant sign-in and token protection. Treat any unsolicited request to enter a sign-in code as an attack.
If you hire or write code: “Run this repo for the interview” is a red flag, even when the repo itself looks clean. Check dependency and provider names character by character, and pin trusted Terraform providers so a lookalike can’t slip in.
If you run a webshop: Watch for unexpected script tags, changes to tag manager blocks, and cron jobs you didn’t create. Also assume the attacker may delete data on the way out. Test that you can restore your customer and order databases, not just that the backups exist.
If you’re a customer: You can’t prevent your card being stolen from someone else’s database. Turn on transaction alerts, use virtual or single-use cards for smaller webshops, and check your statements.
If you’re handling an incident: Update your mental model of “the attacker.” If a compromise looks fast, cheap, and a little too tidy (card fields emptied in batches after a quiet period, a skimmer a cron job keeps putting back), you may not be facing a human working a playbook live. You may be facing an agent executing one. And “cheap” is real: the operator’s own cost review averaged about $25 per target, from roughly $3 at the low end to $79 at the high end. At that price, “unsophisticated” no longer means “small-scale.”
Sources
Malicious AI agents steal 600K credit cards, infect 100+ sites with skimmers, BleepingComputer: https://www.bleepingcomputer.com/news/security/malicious-ai-agents-steal-600k-credit-cards-infect-100-plus-sites-with-skimmers/
Autonomous AI agents attack online retailers, Gambit Security: https://gambit.security/blog-posts/autonomous-ai-agents-online-retailers-25-a-company
Attackers Use Malicious Terraform Providers to Deliver Go Malware via HashiCorp Registry, The Hacker News: https://thehackernews.com/2026/09/attackers-use-malicious-terraform.html
Graphalgo Terraform providers and Go modules, Aikido: https://www.aikido.dev/blog/graphalgo-terraform-go-modules
Lazarus campaign plants malicious packages (Graphalgo, original reporting), The Hacker News: https://thehackernews.com/2026/02/lazarus-campaign-plants-malicious.html
How device code phishing gives scammers access to your account, Malwarebytes: https://www.malwarebytes.com/blog/how-to/2026/09/how-device-code-phishing-gives-scammers-access-to-your-account