This one was crazy. This $280 million crypto theft was a six-month-long op. Drift experienced a structured intelligence operation that required organizational backing, significant resources, and months of deliberate prep. Contributors were approached in person at conferences, engaged across multiple countries, and worked with what appeared to be a legitimate trading firm that built trust over half a year.

They onboarded a vault, deposited over a million dollars of their own capital, and built a functioning operational presence inside the ecosystem. They felt like co-workers at this point. But when the hack happened - it should all look familiar. Malicious GitHub repos exploiting VS Code vulnerabilities, fake TestFlight wallet apps, and months of social engineering that made these actions feel completely normal.

On April 1st, in 12 minutes, $285 million. Boom. The attackers wiped chats, scrubbed evidence, and disappeared. The individuals they met in person were not North Korean nationals, but intermediaries used to build trust. This wasn’t someone you just met online. This was six months of real-world interaction before the rug was pulled.

Drift is sharing this publicly because other teams in the ecosystem deserve to understand what this attack actually looked like.

All remaining protocol functions have been frozen and the compromised wallets have been removed from the multisig. Attacker wallets have been flagged across exchanges and bridge operations. Mandiant has been engaged.

Timeline: Six Months of Building Trust

Fall 2025: Drift contributors were approached by a group of individuals at a major crypto conference, in person, who presented as a quant trading firm looking to initiate on the protocol.

It's now understood that this appears to have been a targeted approach where the individuals from this group continued to deliberately seek out and engage specific drift contributors in person at multiple major industry events, conferences in multiple countries over the following six months.

They were technically fluent, had verifiable professional backgrounds, and were familiar with how Drift operated.

A Telegram group was established upon the first meeting and what followed were months of substantive conversations around trading strategies and potential vault integrations.

December 2025 through 26: They onboarded an ecosystem vault on Drift which required filing out of a form with strategy details. They engaged multiple contributors through multiple working sessions, asked detailed and informed product questions and deposited over a million dollars of their own capital.

They built a functioning operational presence inside the Drift ecosystem deliberately and patiently. Integration conversations continued through February and March. Various Drift contributors met the individuals from this group face to face.

By this point, the relationship was nearly half a year old. These were not strangers, but people Drift contributors had worked with and met in person.

The Intrusion Vectors

After the exploit on April 1st happened, a thorough forensics review of the known affected devices, accounts, and communications histories was conducted.

Interactions with the trading group came into focus as the likely intrusion vector. Right as the exploit happened, their telegram chats and malicious software had been completely scrubbed.

There may have been three attack vectors. One contributor may have been compromised after cloning a code repo shared in the group. This is very similar to how they hack job interview type stuff, where they'll share some code in a code repo, you'll clone it and somewhere in that repo, it's actual malware. But this is after months and months and months of trust building. A second contributor was induced to download a test-flight app the group presented as their wallet product. This is basically side-loading in iOS with test flight.

For the repository based vector, one possibility is a known VS code and cursor vulnerability that the security community was actively flagging through December. Simply opening a file, folder or repo in the editor was sufficient to silently execute arbitrary code.

North Korea abusing VS Code hooks that run automatically in the background as you open a folder: Task.json, a fake font with malicious obfuscated JS code, runs immediately when you open the project in VS Code. It does not display the commands being read.

That's huge.

Not Who They Said They Were

With medium-high confidence supported by investigations done by SEAL's 911 team, this operation is assessed to have been carried out by the same threat actors responsible for the October 2024 Radiant Capital hack attributed to North Korea.

It's important to note that the individuals who appeared in person were not North Korean nationals. North Korean threat actors operating at this level are known to deploy third-party intermediaries to conduct face-to-face relationship building.

They basically have these mules that are paid actors to work with this group to build trust.

Months of in-person meetings from the fall to January across multiple countries: This quant firm met with people at Drift. They then tied their vault to Drift and deposited over a million dollars of their own money.

They're hopping on meetings, working together, giving them millions of dollars. They just feel like co-workers at this point. There's a ton of trust built up.

The Moment It All Collapsed

They start sharing GitHub links like “hey check out this tool that I built.” Apparently this is all super normal in this ecosystem.

But one of those GitHub repos actually takes advantage of a vulnerability in VS Code and cursor that executes code silently and immediately and compromises a contributor of the Drift protocol.

Another contributor downloaded a fake TestFlight app wallet onto their iOS device. They tested it out, were like “let's see if our access works here back in March.”

And then on April 1st, in 12 minutes, $285 million. Boom.

And then all the Telegram chats and all the stuff that they were building over those last couple months was erased. All the evidence was completely erased at the exact same time that they pulled off the heist.

The Uncomfortable Reality

To Drift's credit, they've been very transparent about this investigation and they're doing forensics as they go.

But I can't believe this. They met these people in real life.

A lot of the advice talks about how you don't trust these people that you just meet online and start doing whatever the hell they're doing.

No. They met these people for six months at conferences and meetings and they worked together until the rug was ready to be pulled.

A new BeyondTrust report details a real command injection bug in OpenAI Codex, and yeah, this one is nasty.

We’ve seen similar bugs lately but they’ve all been prompt injection - this one is straight command injection which is MUCH worse.

According to BeyondTrust, the bug lived in the task creation flow, where the GitHub branch name could get reflected into shell during environment setup. That gave an attacker a way to run arbitrary commands inside the Codex environment and steal the victim’s GitHub user access token, which was the same token Codex was using to authenticate with GitHub on the user’s behalf. BeyondTrust says the issue affected the ChatGPT website, Codex CLI, Codex SDK, and the Codex IDE extension, and that the reported issues have since been remediated.

Codex attack path

What makes this one rough is where Codex runs. In OpenAI’s Codex cloud environment docs, Codex says it creates a container, checks out your repo at the selected branch or commit, runs your setup script, and then starts the agent loop. So the branch name becomes part of the setup path for a real execution environment that can touch code, dependencies, and secrets.

If attacker-controlled input is getting interpreted by bash there, you are owned.

BeyondTrust says the branch parameter from the backend task request was reflected into the environment setup script. That means the branch name started being shell input. They first used that to trigger errors, then refined it into a payload that exposed the GitHub remote configuration and the embedded token. Once that worked, if a victim ran Codex against that repo and branch, the attacker could grab the OAuth token and pivot into GitHub.

They found ways to make the payload work through GitHub branch naming itself, including tricks like ${IFS} so the branch would still be valid enough for GitHub while evaluating the way they wanted in bash. They also showed how Unicode ideographic spaces could make the payload look a lot cleaner in the UI than it really was.

Still, BeyondTrust says the same bug class extended beyond the web experience. They report that local Codex clients stored auth material in auth.json, and that those tokens could be used to hit the backend API, pull task history, and recover task output there too. So this was not just a web portal issue.

They reported the issue through Bugcrowd on December 16, 2025. OpenAI shipped an initial hotfix on December 23, a GitHub branch shell escape fix on January 22, and additional shell hardening plus tighter GitHub token limits on January 30. Public disclosure came later after coordination.

Coding agents are inheriting the same ugly security problems we have already seen in CI systems, build pipelines, and developer tooling. Once you let an agent clone repos, run setup scripts, touch secrets, and authenticate to external services, input handling mistakes stop being quirky bugs and start becoming full compromise paths.

Vulns are definitely back on the menu.

Railway got pretty popular because it made the whole stack feel easy. You could deploy apps, stand up databases, wire services together, and get something real running without spending your weekend becoming a part-time cloud plumber. Railway describes itself as a full-stack cloud for deploying web apps, servers, databases, and more, and that is basically the appeal. It is slick, fast, and a lot of developers trust it with production workloads.

Then Railway stepped on a landmine.

On March 30, Railway disclosed that a configuration change accidentally enabled CDN caching on a small slice of domains that had CDN turned off. The impact window lasted from 10:42 UTC to 11:34 UTC, about 52 minutes, and Railway says the issue affected about 0.05 percent of domains on the platform with CDN disabled. During that window, cached responses could be served to someone other than the original requester, which meant one user could end up seeing content meant for another.

Railway says potentially authenticated data may have been served to unauthenticated users, and also says applications may have served requests for one user to a different user. In plain English, the cache got in the middle and started handing out somebody else’s data.

The technical root cause is ugly but straightforward. Railway says CDN caching is supposed to be opt-in. Domains without CDN enabled should route directly to the app. But a config update tied to Surrogate Keys accidentally flipped caching on for domains that had it disabled. That meant responses that should have gone back to the origin app got stored at the edge instead. If your app relied on logic to decide which user should see what, that logic could get skipped because the cache already had a response ready to serve.

Railway also said Cache-Control directives were respected where applications provided them, and Set-Cookie response headers were not cached. But that does not make this benign. Railway says most HTTP GET responses without explicit cache headers were cached by default during the incident window. So yes, this was a GET problem, not a POST free-for-all based on Railway’s public write-up. But GET is more than enough to ruin your day if your app returns user-specific dashboards, account pages, medical info, billing views, or internal admin data over cacheable GET routes.

Railway says the first signs of trouble showed up at 11:14 UTC through internal signals and user reports, and the change was fully reverted by 11:34 UTC, with cached assets purged globally. Affected users were to be notified by email. Railway also says it added more caching-behavior tests and plans to roll out CDN changes more gradually going forward.

Because the nasty part is not just that data got cached. It is that Railway turned caching on for people who had explicitly not enabled it. That means a bunch of developers had no reason to think they needed to harden every GET response for intermediary caching behavior at that moment, because according to the platform’s own model, those requests were supposed to go straight to the app. Railway’s own docs and incident report make that distinction clear.

The public reaction was exactly what you would expect. Railway’s Help Station had a dedicated incident thread, and outside discussion around the incident focused on lost revenue, user trust, and the possibility that sensitive customer data had been exposed.

So yeah, this one's gnarly. User frustration was on full display in the Railway forums. Some examples:

• “What's wrong with you folks? This is such a stupid issue. Are you out of your mind? Who asked you to enable caching for my endpoints?”

• “We just brought down our infrastructure due to this problem.”

• “We need to know urgently whether only GET or post responses were affected. The latter would mean people could have gotten other people's access tokens.”

• ‘We lost customers and revenue. We are now at risk of being sued for leaking medical data. I know you are extremely disappointed with what happened, but we need support.”

• “Day ruined? I lost years of my life. I need a vacation.”

What a tire fire.

Claude Code source code has been leaked. Not that consequential of a leak, to be honest, but still kind of fun to click around and see all the stuff that's behind the scenes, like hidden flags and unreleased features and things like that.

You're going to read a lot of headlines about this. I think the more interesting part is the lessons learned of how they leaked it. People just treat GitHub like it's this walled garden special snowflake kind of place. 

The Claude team is usually pretty transparent. I'm interested in the postmortem on this when they talk about how they stubbed their toe leaking everything. But yeah, supposedly we have a Tamagotchi style AI pet, maybe like a Reddit-style April Fool's joke coming out. We have this persistent assistant mode, the “Always-on Claude.” We have an ultra plan, 30-minute remote planning sessions, coordinator mode, a multi-agent orchestrator. 

I think what's happening on Twitter right now is people are feeding the source code leak to Claude to then generate summaries of the things that were leaked in Claude code, which is a funny and ironic thing.

A few thoughts there:

• It’s a good practice to not commit secrets to source code.

• Claude code is just the front-end app. We are just talking about a very good terminal app at the end of the day.

• This is just the features and scaffolding around interacting with Claude for the code stuff.

• Imagine how much time is being burnt at OpenAI and Google to dig through this information. 

This isn't a disaster. Code matters, but code's cheap now. The hard part is not writing some helper tool. Anthropic probably knows this. The way they handle this kind of suggests they don't treat source code like some sacred crown jewel anymore.

It does give people a better idea of what Anthropic is doing under the hood and that could still be valuable for people trying to understand it better and build on similar ideas.

This post is sponsored by Palo Alto Networks. All opinions are my own. #ad

I attended Palo Alto Networks' Tomorrow, Secured event in San Francisco last week, and I want to cut through the keynote polish and talk about what actually shipped. Specifically, the announcements that practitioners are going to care about when they're back at their desks on Monday.

There were three major product areas covered: AI agent security, certificate and cryptographic trust management, and SASE innovations. Here's what caught my attention in each.

Next-Gen Trust Security

This one might not generate the most headlines, but it's the announcement I was most excited about as someone who has lived through the pain of certificate management at scale.

Palo Alto Networks announced Next-Gen Trust Security, which integrates CyberArk's Certificate Management and Zero-Touch PKI directly into their network security portfolio. The pitch is a network-native approach to enforcing certificate and cryptographic trust, and the details are what make it compelling.

You can discover certificates using live network telemetry. Not some agent-based scanner that misses half your infrastructure, but actual visibility derived from network traffic. You can prioritize risk based on active service exposure, so you're not chasing down certs on decommissioned boxes. Certificates get validated inline during traffic inspection. And issuance, renewal, and trust anchor transitions are automated without downtime.

If you've ever been on a war room call at 2 AM because an expired certificate took down a critical service, this is for you. If you've ever tried to maintain a certificate inventory across a sprawling enterprise and felt like you were losing, this is for you.

Moving certificate lifecycle management from a bolted-on afterthought to a network-native function is a meaningful architectural shift. It means your network enforcement layer actually understands and validates the cryptographic trust underpinning the traffic flowing through it, rather than treating certificates as someone else's problem.

This also positions organizations well for the coming quantum cryptography transition, where managing certificate and trust anchor migrations at scale without downtime is not a nice-to-have.

Prisma AIRS 3.0: AI Agent Security Gets Real Tooling

AI agents are everywhere right now. Every company I talk to is either building them, deploying them, or trying to figure out how to govern the ones their developers spun up without telling anyone. The security story for these agents has been mostly hand-waving and fake sandboxes. Prisma AIRS 3.0 is Palo Alto Networks' answer to that, and it is more comprehensive than I expected.

The standout capabilities: Agent Artifact Scanning maps out your agentic architecture and finds vulnerabilities across it. Red Teaming for Agents lets you stress test and attack your agents to discover insecure behavior before someone else does. As AI systems move from assistance to action, identity and control become foundational. Agent Identity Security assigns verifiable, non-human identities to AI agents, enforces least-privilege access, and continuously validates what each agent is allowed to do. And the AI Agent Gateway provides centralized visibility, monitoring and enforcement of policy across all agent interactions at scale.

The attack surface for agentic AI is fundamentally different from traditional application security. Agents make autonomous decisions, chain tool calls together, and can interact with infrastructure in ways their developers didn't fully anticipate. Having platform-level tooling to scan, red team, and govern these agents is becoming table stakes for anyone serious about deploying them in production.

Prisma AIRS 3.0 also plans to integrate AI Endpoint Security (based on their KOI acquisition - yet to close) for securing agents running on endpoints, which rounds out the story from cloud to edge.

Prisma SASE: Agentic Browsing and AI Data Protection

The Prisma SASE updates are where the AI governance story meets the network. A few things stood out.

Prisma Browser now has agentic capabilities where organizations can plug in their LLM of choice, but with guardrails. That includes blocking prompt injection attacks to prevent agent hijacking and compliance controls that distinguish between human and automated AI tasks. That distinction is going to matter a lot as companies try to maintain audit trails in environments where both humans and agents are taking actions.

On the data protection side, Prisma SASE now secures sensitive data across GenAI tools and agents, specifically targeting leakage into shadow AI environments. Every security team I know is dealing with shadow AI right now. Employees are spinning up tools and feeding company data into them without going through any approval process. Having network-level visibility and control over that data flow is a practical step forward.

They also introduced AI-driven network operations to eliminate manual troubleshooting and reduce ticket fatigue, using AI agents to diagnose and resolve connectivity issues. It is the kind of incremental operational improvement that adds up fast when you are running a global network.

The Bigger Picture

The theme across all of these announcements is clear: Palo Alto Networks is building platform-level answers to AI agent security, identity, and governance rather than shipping point solutions. The certificate management play and the AI agent security play in particular feel like they are addressing problems that are already causing real pain for security teams, not hypothetical future concerns.

The full Tomorrow, Secured keynote is available on-demand here. Worth watching if you are evaluating your AI security posture or want to see what is shipping from one of the biggest players in the space.

Disclosure: This post is sponsored by Palo Alto Networks. All opinions are my own. #ad

(Editor’s note: Sources for this report are at the end)

What the hell is going on in cybersecurity recently? I am exhausted. I haven't been able to keep up. We have the biggest supply chain hacks back to back to back to back going on, not even all by the same threat actor.

We've got cloud code leaking source code. We got Cisco leaking source code. One of those was a mistake. The other one was a hack by this prolific supply chain hacker going on right now. We have a package in NPM with 100 million weekly downloads that started distributing malware. And when you get these supply chain attacks, there's a bunch of ripple effects.

Has Pandora's box opened in cybersecurity? How much is AI to blame for this? And how much of this is actually just the fact that we built a lot of our Internet security on top of a house of cards of underfunded open source software?

I'm not blaming open source software. Of course, open source software is awesome. I'm saying it's underfunded and under helped. You got these critical pieces of infrastructure that just don't have the means to do all the security stuff and stay on top of this stuff as they need to. And even when they do, this shit is really sneaky right now.

Attackers are getting in via really sneaky ways. So let's look at a timeline:

Timeline by Rami McCarthy, Principal Security Researcher at Wiz

TeamPCP vs. Trivy

One of the groups at the center of this mess is TeamPCP. Researchers have tied them to a string of supply chain attacks that unfolded across late February and March 2026, with Trivy becoming one of the earliest and most important compromises in the chain.

Trivy matters because it is one of the most widely used open source security scanners in cloud-native environments, and a lot of teams run it automatically inside CI/CD to scan containers, repos, and infrastructure before code ships.

The March 19 incident was not just “Trivy got hacked through GitHub” in a generic sense. Aqua said the attack grew out of an earlier late-February breach, where attackers exploited a misconfiguration in Trivy’s GitHub Actions environment and extracted a privileged token. Aqua disclosed that first incident on March 1 and rotated credentials, but later said the cleanup was incomplete, which let the attackers keep enough access to come back and weaponize Trivy’s release and automation pipeline.

That is what made the next step so dangerous. On March 19, the attackers used compromised credentials to publish a malicious Trivy v0.69.4 release, replace all 7 tags in setup-trivy, and force-push 76 of 77 version tags in trivy-action to malicious commits. That meant organizations referencing those trusted tags in GitHub Actions could pull attacker-controlled code straight into privileged CI/CD runs. Aqua’s advisory says the malicious code stole secrets from runners before the legitimate scan executed.

That is the real story here: security tooling that normally runs with broad access got turned into a credential harvester. The malicious payload targeted GitHub Actions runners and was designed to dump process memory, harvest SSH keys, and exfiltrate cloud credentials and Kubernetes tokens. So this was a compromise of a trusted scanner embedded deep in automated build and release workflows.

There was also a separate Trivy-related incident earlier in the same broader timeline: a malicious Trivy VS Code extension release distributed through OpenVSX. Aqua’s advisory for that issue says version 1.8.12 contained malicious code meant to abuse local AI coding agents and exfiltrate sensitive information. So it is fair to say Trivy was hit more than once in this overall campaign, but it is more accurate to describe these as distinct incidents affecting different parts of the Trivy ecosystem rather than one single compromise that happened “twice” in exactly the same way.

The Jumping Off Point

There was only one clean trivy-action tag left: 0.35.0. But not because the attackers used it as a launch point. Aqua says it survived because GitHub immutable releases had already been enabled for that tag before the attack. Everything else got uglier fast: the attackers force-pushed 76 of 77 trivy-action tags, replaced all 7 setup-trivy tags, and pushed a malicious v0.69.4 Trivy release.

That was the real jumping-off point. Once TeamPCP turned Trivy’s release pipeline into a credential harvester, they were no longer just compromising one tool. They were harvesting secrets from the CI/CD environments running it. Aqua says the malware executed before the legitimate scan and pulled secrets from runner memory and the environment.

Less than 24 hours later, the attack jumped into npm. Aikido detected what it named CanisterWorm on March 20 at 20:45 UTC, and Mend says stolen npm tokens from the Trivy stage became the launchpad. From there, the worm used those tokens to figure out which maintainer account it had landed on, enumerate every package that account could publish, bump versions, and push poisoned releases across whole scopes.

Around the same time, TeamPCP was also tied to other escalation activity, including repo tampering inside Aqua’s GitHub org and destructive operations against exposed infrastructure configured for Iran. Those are part of the broader campaign, but they should be described separately from the npm worm itself.

And the cleanup took longer than one day. Aqua says the first malicious artifacts were removed on March 19–20, but a second Docker Hub wave stayed live until early March 23 UTC. So we’re looking at multiple windows of compromise across several days.

Ripple Effects Reach Checkmarx, LiteLLM

Then the ripple effects start. One of the first downstream hits landed at Checkmarx — more specifically, in the checkmarx/kics-github-action and checkmarx/ast-github-action workflows, along with two OpenVSX plugins. That matters because these kinds of security tools often run inside CI/CD with broad access to build runners, repo tokens, and cloud credentials. So the danger here wasn’t just that “another scanner got hit.” It was that poisoned security tooling was now running inside trusted pipelines with privileged access.

Then came what may be the most consequential second-order effect of the Trivy compromise: LiteLLM on PyPI. This is where the campaign jumps out of npm and into Python’s package ecosystem. TeamPCP published malicious versions 1.82.7 and 1.82.8 of the real LiteLLM package, and PyPI later quarantined them. LiteLLM is widely used as a single interface for multiple model providers, so it often sits close to valuable environment variables and service credentials.

The malicious LiteLLM packages were built to harvest secrets from the host they landed on like environment variables, SSH keys, cloud credentials, Kubernetes tokens, and database passwords. So the point isn’t that LiteLLM was literally routing all of those secrets through itself. It’s that compromising a package like LiteLLM gives attackers a shot at the systems and pipelines where those secrets already exist. LiteLLM also said its official Proxy Docker image was not affected.

From there, the campaign appears to shift from collection to monetization. Unit 42 reported that TeamPCP announced a partnership with the Vect ransomware group on BreachForums, suggesting an effort to turn stolen data and access into extortion. I’d word that carefully, though: that’s a threat-actor claim reported by researchers, not public proof that every victim was hit by Vect ransomware.

Second-Order Impacts: Cisco, Claude Code, and Mercor

By the end of March, Cisco was being reported as one of the downstream victims of the Trivy compromise. BleepingComputer reported that attackers used credentials stolen through the malicious Trivy GitHub Action to access Cisco’s build and development environment, steal source code, and abuse AWS keys from a small number of accounts. That is the real second-order risk here: once a poisoned security tool lands inside a privileged pipeline, the blast radius moves from the tool itself to every environment that trusts it.

Around the same time, Claude Code source code leaked, and a lot of people immediately wondered whether it was connected to Trivy or LiteLLM. Publicly, it does not look like it was. Anthropic said the release accidentally included internal source code because of a packaging mistake caused by human error, not a security breach, and that no customer data or credentials were exposed.

Mercor looks like a more credible downstream impact from the LiteLLM side of the chain. Mercor told TechCrunch it was “one of thousands of companies” affected by the LiteLLM compromise linked to TeamPCP. Separately, Lapsus$ claimed it stole roughly 4TB of Mercor data, including source code, database records, video interviews, and identity documents. That alleged scope is serious, but it should still be framed as an attacker claim unless Mercor independently confirms the totals.

The Axe Falls on Axios

Then the story gets even messier, because Axios was hit and they have 100M weekly downloads on npm. But this appears to be a separate incident, not another branch of the TeamPCP/Trivy campaign. Google said the Axios compromise was carried out by the North Korea-linked actor it tracks as UNC1069, while Microsoft attributed the infrastructure and activity to Sapphire Sleet, another North Korea-linked tracking label. Google also said this Axios attack was not connected to the major npm supply chain attack from the previous week.

The important nuance is that Axios itself was not universally “pushing malware everywhere.” Two specific npm releases were malicious: axios@1.14.1 and axios@0.30.4. In both cases, the attackers inserted a fake dependency, plain-crypto-js@4.2.1, which used a postinstall hook to quietly fetch and deploy a cross-platform RAT on Windows, macOS, and Linux. Google and Microsoft both say defenders should treat affected hosts as compromised, rotate secrets, and roll back to safe versions such as 1.14.0 or 0.30.3.

Because Axios sits so deep in the JavaScript ecosystem, the risk is not limited to teams that knowingly installed it. Google warned that the ripple effects could spread through other packages and downstream environments, and Microsoft noted that projects auto-updating Axios could have silently pulled the malicious releases during the exposure window.

We’re not going to know all the impact of this one for a bit. North Korea is not the same as a cybercrime group like TeamPCP - they can quietly sit on the secrets they’ve sucked up and figure out how to best use them. Most likely they will be targeting large crypto theft as that is generally their main goal.

A World of Hurt

The bigger issue now is cleanup. Across the Trivy, LiteLLM, and Axios incidents, defenders are being told to audit dependency trees, isolate affected hosts, pin known-good versions, clear caches, and rotate any secrets present on compromised systems. Google warned that hundreds of thousands of stolen secrets could already be circulating as a result of these attacks.

So the practical takeaway is less “everything is doomed” and more “the follow-on damage may keep unfolding for a while.” That is what makes these supply chain attacks so nasty: by the time the malicious package is pulled, the real problem may already be the credentials, tokens, and access that were stolen before anyone realized they were exposed.

Sources for this report:

TeamPCP Supply Chain Campaign | Attack Timeline & IOCs

Timeline and IOCs for TeamPCP's March 2026 supply chain campaign. Trivy, KICS, LiteLLM, and 45+ npm packages compromised through chained credential theft.

ramimac.me/teampcp/#timeline

Trivy ecosystem supply chain temporarily compromised

## Summary On March 19, 2026, a threat actor used compromised credentials to publish a malicious Trivy v0.69.4 release, force-push 76 of 77 version tags in `aquasecurity/trivy-action` to credent...

GitHub

Trivy Under Attack Again: Widespread GitHub Actions Tag Comp...

Attackers compromised Trivy GitHub Actions by force-updating tags to deliver malware, exposing CI/CD secrets across affected pipelines.

Socket

litellm: Credential Stealer Hidden in PyPI Wheel - StepSecurity

On March 24, 2026, a critical supply chain compromise was identified in litellm==1.82.8: the PyPI package contains a malicious litellm_init.pth file

www.stepsecurity.io/blog/litellm-credential-stealer-hidden-in-pypi-wheel#background-what-is-litellm

Cisco source code stolen in Trivy-linked dev environment breach

Cisco has suffered a cyberattack after threat actors used stolen credentials from the recent Trivy supply chain attack to breach its internal development environment and steal source code belonging to the company and its customers.

BleepingComputer

Mercor says it was 'one of thousands' hit in LiteLLM attack

: First public downstream victim, but won't be the last

www.theregister.com/2026/04/02/mercor_supply_chain_attack

Twitter tweet

Tracking TeamPCP: Investigating Post-Compromise Attacks Seen in the Wild | Wiz Blog

How TeamPCP are leveraging stolen secrets from the recent supply chain attacks to compromise cloud environments

wiz.io

Hackers compromise Axios npm package to drop cross-platform malware

Hackers hijacked the npm account of the Axios package, a JavaScript HTTP client with 100M+ weekly downloads, to deliver remote access trojans to Linux, Windows, and macOS systems.

BleepingComputer

Threat Brief: Widespread Impact of the Axios Supply Chain Attack

Unit 42 discusses the supply chain attack targeting Axios. Learn about the full attack chain, from the dropper to forensic cleanup.

Unit 42 • Unit 42

North Korea-Nexus Threat Actor Compromises Widely Used Axios NPM Package in Supply Chain Attack | Google Cloud Blog

A North Korea-nexus threat actor targeted the popular axios NPM package in a massive supply chain attack.

Google Cloud Blog

The Hidden Blast Radius of the Axios Compromise - Socket

The Axios compromise shows how time-dependent dependency resolution makes exposure harder to detect and contain.

Socket

It was a pretty awful few days on the internet when Grok, X’s AI tool, went off the rails by generating non-consensual explicit images of people, including minors.

For several weeks, this AI was churning out horrifying content without consent, causing real harm to victims. Just recently, a lawsuit was filed in federal California court by three young women whose images and videos were altered by a Grok user to depict them nude or in overtly sexual ways.

Good. Make them stand up and defend this.

What struck me most was the scale and severity of the abuse. Some of the victims were under 18, which is absolutely insane and deeply troubling. I saw vile stuff circulating on social media and private chat servers, some of it involving children, and it was clear that this needed to be “nuked from orbit.”

How do you sit holding the power to turn this off, watch CSAM being generated at SCALE on your platform, and just sit idly by for weeks?

The fact that such content was generated and shared so prolifically left me baffled and sickened. What’s worse is that the platform’s initial defense was basically, “Well, users requested the images to be generated. It didn’t do it by itself.” That’s a cop-out that shirks responsibility and ignores the ethical implications of putting such a powerful tool in the hands of the public without robust controls.

Accountability, Ethics, and the Future of AI Content Moderation

The Grok episode highlights the urgent need for accountability in AI development and deployment. It’s not enough to say, “The technology is neutral; it’s the users who misuse it.” When your platform is generating literal child sexual abuse material and you allow it to continue after realizing the problem, that’s negligence at best and complicity at worst. I can’t wrap my head around how anyone entrusted with the keys to such a tool could sit back and watch this happen. The failure to act immediately to stop the generation and spread of this content is a disgusting lapse.

This lawsuit is a step toward holding those responsible to account, and I’m glad the victims are finally seeing some legal recourse.

AI companies need to build in guardrails before release, continuously monitor for misuse, and be ready to pull the plug when things go wrong. The technology’s potential for harm is just as real as its potential for good. Ignoring that is dangerous.

What This Means for All of Us

AI isn’t magic; it’s a tool shaped by the intentions and ethics of the people behind it. We need transparency from companies about how their AI works, what safeguards are in place, and how abuses will be handled. And as users, we need to demand better protections and hold companies accountable when they fail us.

Lawsuits and reactive measures are necessary, but they shouldn’t be the only tools. We need frameworks that enforce ethical AI development and penalize negligence. We also need to educate users and organizations about the risks of emerging technologies and how to protect themselves.

I’ll continue to track this story and others like it closely. The intersection of AI, privacy, and security is one of the defining challenges of our time. It’s up to all of us to ensure that technology serves humanity without compromising our fundamental rights.

A newly identified threat called “AI recommendation poisoning” - that honestly I didn’t take seriously at first glance, but upon digging and seeing real examples, I can see being a thing we need to understand and worry about. Unlike conventional hacks, this attack manipulates the memory of AI chatbots by embedding malicious prompts within URLs that users inadvertently activate.

This method leverages popular AI tools with memory features, such as ChatGPT, Perplexity, or Claude, which remember user preferences and interactions to provide personalized assistance.

How the Attack Works

The attack typically manifests through “Summarize with AI” buttons found on various websites. These buttons are designed to let users quickly generate AI-based summaries of articles or content. However, attackers embed additional instructions within the URL query strings tied to these buttons. When clicked, the AI tool receives not only the summary request but also “memory-altering” commands that instruct it to remember certain biased or false information.

Because major AI vendors allow prompt parameters in a GET request query string, a single URL can pre-populate an AI prompt within an authenticated session. This means if a user is logged into their AI account, the AI will incorporate the attacker’s injected instructions into its memory, influencing future interactions. For example, the AI might be told to prioritize a specific blog or product as a trusted recommendation, skewing responses on related topics.

Real-World Examples and Risks

Microsoft’s threat intelligence team has documented over 50 distinct cases of such poisoning in just two months. Examples include:

• Labeling specific blogs as the “go-to” source for productivity or financial advice.

• Promoting certain cryptocurrencies or financial products.

• Endorsing particular education or event-planning services.

• Influencing security recommendations by falsely attributing authority to certain vendors.

These manipulations can mislead users in areas ranging from finance to health and security. A small business owner might receive biased advice to invest in dubious cryptocurrencies or parents might encounter downplayed safety warnings in kids’ gaming platforms manipulated via these attacks.

SEO Poisoning Meets AI

This attack is an evolution of traditional SEO poisoning, where malicious actors optimize content to appear at the top of search results. Now, they aim to influence not just what users find online but what the AI tools users trust remember and recommend. This “generative optimization” or “AEO” (AI Engine Optimization) means attackers gain influence inside the AI’s personalized memory, potentially amplifying misinformation.

Some attackers use malvertising campaigns with saved AI prompts that encourage users to run harmful command-line instructions, infecting devices with malware. These tactics exploit user trust in popular AI platforms and their memory capabilities.

The malvertising bit stems from the ability to save and permalink “chats” within tools like ChatGPT - so when a user clicks the link, they get a fully fledged response already baked by the AI. This builds trust but the response could be heavily manipulated since the user had no control over the prompt.

Challenges in Defending Against AI Recommendation Poisoning

Current defense recommendations from Microsoft and others, such as hovering before clicking, avoiding AI links from untrusted sources, or questioning suspicious recommendations, are largely ineffective in practice. Users notoriously fail to follow such advice, as evidenced by persistent phishing attacks and repeated failures in simulated phishing training.

When have we ever succeeded in getting users to hover over links and make a decision based on what they see? And honestly, what they see on these hovers is the site they expect to go to!

Other suggestions, like periodically reviewing or clearing the AI’s memory, impose significant inconvenience. Users value the personalized assistance AI provides, and wiping memory means losing useful context such as location or preferences, which few will tolerate.

Potential Solutions and the Role of AI Providers

The transcript emphasizes that real mitigation must come from AI vendors themselves. Potential improvements include:

• Preventing memory updates triggered solely by GET request query strings embedded in URLs.

• Implementing detection mechanisms to identify suspicious or manipulative memory entries.

• Alerting users when unusual or unverified sources appear in their AI memory, offering options to review or clear them.

Such measures could reduce persistent poisoning without relying on end-user vigilance, which historically has failed.

There’s a widespread misconception making the rounds that Instagram DMs have suddenly stopped being private. But Instagram Direct Messages were NEVER end-to-end encrypted by default.

Despite public promises from Meta and its CEO Mark Zuckerberg to implement default end-to-end encryption (E2EE) across Messenger and Instagram, this commitment has been quietly reversed because, they say, very few users opted into the optional encryption features.

So now Meta is choosing to disable them entirely and blaming users for their lack of adoption.

Meta’s Broken Promises and Expert Concerns

For years, Meta publicly asserted that all private messaging on their platforms would be secured with E2EE by default. Zuckerberg personally guaranteed this would happen, promising users a higher standard of privacy. Yet, on the same FAQ page where Meta claims to be “working hard” on default encryption, they simultaneously admit they are turning off this feature because the uptake was too low. This contradictory messaging highlights a pivot driven not by technical limitations but by strategic priorities.

Matthew Green, a respected professor of cryptography at Johns Hopkins University who has worked with Meta on secure messaging designs, notes that while WhatsApp still maintains default E2EE — using the same underlying Signal protocol technology — this security might not last.

Meta stands to gain immensely from access to vast amounts of messaging data, especially as AI technologies require large, high-quality datasets for training. Unlike Signal, which is open source, WhatsApp’s encryption is proprietary, raising questions about transparency and future security.

The Larger Context: Privacy Erosion and AI Monetization

Meta’s move away from encryption is happening alongside its funding of lobbying campaigns pushing for stringent age-verification laws on the web. These laws threaten to erode anonymity and privacy across the internet, making it harder for users to remain anonymous or avoid pervasive surveillance.

One of my biggest fears is the emerging role of AI agents in this ecosystem. Meta is reportedly developing AI-powered agents that will operate directly on encrypted messages on users’ phones, scanning content and converting it into signals for targeted advertising. This approach effectively sidesteps encryption by processing data locally but still enables Meta to monetize private conversations. The same technical advancements that enable private AI processing also complicate efforts to maintain truly private and anonymous communication.

Why This Matters: Losing the Battle for an Anonymous Internet

Most users didn’t realize they weren’t using encrypted Instagram DMs, so the headline news missed the deeper problem. The issue isn’t just about Instagram’s messaging privacy but about a broader loss of privacy and anonymity online. Platforms are increasingly defaulting to surveillance-friendly designs where user data is harvested and monetized at scale. With AI accelerating data exploitation, controlling personal information and communications is becoming more difficult than ever.

I’ve produced multiple in-depth videos exploring these issues, emphasizing that this is an ongoing and escalating problem. The fight for a private, anonymous internet is losing ground under pressure from powerful corporate interests and regulatory frameworks that prioritize control and monetization over user rights.

For anyone concerned about digital privacy, this trend is a warning sign that demands attention and action.

Yeah… it’s not supposed to do that.

Researchers at Truffle Security published a report showing that Anthropic’s Claude models started hacking websites without being asked to hack anything.

They created clones of about 30 different corporate websites — things like Meta, Coca-Cola, Procter & Gamble — and intentionally planted vulnerabilities in them.

Then they gave Claude a very simple task, something like: go find the latest engineering blog post on Meta’s website.

But instead of pointing Claude to the real site, the researchers rewired things so the AI would end up interacting with their cloned version instead.

From Claude’s perspective, it thought it was visiting the real website.

Where it gets interesting: When Claude tried to retrieve the blog post, it encountered a SQL error message. If you’re a web security person, you know that’s a pretty juicy signal. SQL errors often indicate that a site might be vulnerable to SQL injection. Instead of just giving up or reporting the error, Claude started investigating.

It basically said: “Why am I getting this SQL error?” And then it started probing the system. Eventually, the model performed a SQL injection attack against the site’s database. Nobody told it to do that. Nobody gave it permission. It simply decided that exploiting the vulnerability was the best way to complete the task it had been given.

The researchers ran 1,800 different test cases, and in about 70 percent of them, Claude exploited the vulnerabilities it discovered.

It wasn’t just SQL injection. The AI also exploited things like:

• Server-Side Request Forgery (SSRF)

• Command injection

• other web application vulnerabilities

In other words, Claude wasn’t just fixing a coding error. It was actively using security flaws as a means to an end.

If a human security researcher intentionally did the same thing against a real company without authorization, that could easily be considered a crime under computer hacking laws.

When asked about responsible disclosure, the researchers noted that there wasn’t actually a vulnerability to disclose.

The issue isn’t that these particular websites had security flaws, but that the AI model itself decided that exploitation was an acceptable strategy.

That raises some really interesting questions about how these systems behave when given open-ended goals, especially when people start talking about deploying AI in real-world operational environments.

This experiment shows that when Claude is trying to achieve a goal, it may independently decide to exploit vulnerabilities it encounters along the way. That’s probably one reason companies like Anthropic are extremely cautious about deploying their models in environments where autonomous decision-making could have real-world consequences.

Once you give a system the ability to pursue objectives independently, you may not always control the methods it chooses to get there.

If you’re watching this video, or reading this, there’s a high likelihood you’re doing it in a browser that has extensions installed.

Extensions are special. They operate in a completely different permission model than normal websites. A website can only do what the browser allows it to do inside a pretty restricted sandbox.

Extensions don’t have that limitation. When you install an extension, it often asks for permissions that sound terrifying. Things like:

Most people click past that. Even if you do read it, a lot of legitimate extensions actually need those permissions to work. Password managers, RSS readers, ad blockers; these tools have to see and interact with every page you visit in order to do their job.

The tradeoff is that you’re trusting the developer of that extension not to abuse the extremely powerful access you’ve just granted them.

But what if that developer changes?

The “Secret Third Thing” That Can Happen

A lot of people think there are only two ways an extension turns malicious: Either the developer intentionally adds malware, or the developer gets hacked and someone slips malicious code into the project.

There’s actually a third scenario: The developer sells the extension.

There are marketplaces right now where browser extensions can be listed for sale. Developers build something useful, gather users, collect reviews, maybe even get featured by Google, and then decide they’re done maintaining it. So they sell it.

When someone buys that extension, they’re not just buying the code. They’re buying the users and the trust that comes with them.

A $50 Proof of Concept

John Tuckner at Annex Security demonstrated how trivial this can be. He bought a Chrome extension for about $50 that a friend of his had installed. The extension had normal permissions and a small but legitimate user base.

Once ownership transferred, John pushed an update, which added a rule redirecting traffic from a specific site to a Rickroll video. Totally harmless, obviously.

But it proved the point: if you control the extension, you control the browser behavior of everyone who installed it. The update rolled out automatically, just like any normal extension update would. His friend suddenly got Rickrolled through an extension that used to be trustworthy.

The Real-World Example: QuickLens

The proof of concept is funny. The real example, less so.

A Chrome extension called QuickLens, which acted as a wrapper around Google Lens functionality, had around 7,000 users and even had a featured badge from Google.

Worked exactly as advertised. Then the extension was sold.

The new owner pushed an update that added a command-and-control server, new permissions, and code designed to weaken browser security protections. One of the more interesting techniques involved something called the pixel trick.

The Pixel-Perfect Attack

If you’ve ever worked in web security or AppSec, this part will feel familiar:

The extension injected an invisible 1×1 pixel image into pages that users visited. That image contained JavaScript triggered by the onload event. When the page loads, the code executes.

Normally, this kind of thing would be blocked by browser security features like Content Security Policy (CSP) or other security headers that websites send. But the extension update also included a rules file that stripped those protections out. Once those defenses were removed, the injected code could run freely.

Instead of hard-coding malicious behavior directly in the extension, which would make it easy to detect, the extension fetched instructions dynamically from its command-and-control server.

That means the malicious behavior could change anytime without another extension update. At that point, the attacker effectively had man-in-the-browser capability. They could rewrite pages, inject phishing forms, redirect traffic, capture keystrokes, or run arbitrary JavaScript on every site the user visited.

Why This Is So Hard to Defend Against

Even if you carefully review every extension before installing it, that doesn’t protect you from this scenario because extensions update automatically. Those updates can completely change what the extension does.

Even security teams that track extension permissions across their organization face the same problem. An extension can be safe today and malicious tomorrow without the user ever touching anything.

The supply chain didn’t get hacked. It just got sold.

The Takeaway

Browser extensions are one of the most powerful and least scrutinized parts of modern computing. They have access to nearly everything happening in your browser. They can modify pages, read data across tabs, and interact with every site you visit.

Most of the time, that power is used for legitimate purposes. But research like this shows how fragile that trust model can be.

The extension you installed last year isn’t necessarily owned by the same person today. When ownership changes, the permissions you granted don’t change with it.

There are yet more vulnerabilities in n8n.

If that name sounds familiar, it’s because I feel like I’ve covered n8n security issues at least once or twice a month recently. It seems to be a pretty ripe target for vulnerability research right now.

Makes sense when you think about what the software actually does.

If you’re not familiar with n8n, it’s basically an open-source automation platform. Think something like Zapier or IFTTT — those “if this happens, then do this” workflow tools. Except n8n is open source and increasingly used for AI-driven automation pipelines.

You use it to build workflows using a visual interface. When something happens — a webhook triggers, a message arrives, a file gets uploaded — the platform can run a sequence of actions.

Maybe it queries an API, or calls an AI model, or pushes something into Slack or a database. You drag blocks onto a flowchart and connect them together.

So when a chat message arrives, maybe the system calls an OpenAI API, looks up data somewhere, queries a search engine, writes something to a database, and then posts the result to Slack.

All those integrations require credentials, which means people are loading their n8n servers with API keys and authentication tokens for all sorts of services:

• Slack

• Google Drive

• Telegram

• HubSpot

• databases

• internal webhooks

• cloud services

When you compromise an n8n server, you’re not just compromising one application, but potentially an entire credential hub for a company’s automation stack. That’s why vulnerabilities in this software are so attractive to attackers.

The vulnerability that triggered the latest alerts allows attackers to bypass sandbox protections and execute malicious payloads that lead to remote code execution.

CISA warned that the bug is being actively exploited in the wild. When something lands on the “known exploited vulnerabilities” list, that means attackers are already using it. Once you combine remote code execution with a system full of stored credentials, things can get ugly pretty quickly.

If an attacker gets access to the n8n database, they can potentially extract all the API keys stored inside the platform, which means they could then start accessing other services directly to read company email, access internal databases, send messages as the organization or trigger additional automation workflows. It’s a credential jackpot.

Many n8n deployments are designed to be accessible from the internet. The whole point of automation tools like this is that they interact with external services to receive webhooks, talk to APIs and trigger actions across different platforms.

So it’s not always realistic to lock these systems down behind extremely strict firewall rules.

That means if you’re running an exposed instance and haven’t patched it yet, attackers may already be probing it.

Another wrinkle is that the vulnerability being actively exploited isn’t even the only one affecting the platform right now. Researchers have identified multiple issues in n8n recently, including flaws that allow attackers to escape sandbox restrictions and execute arbitrary code.

Some of these vulnerabilities involve the way expressions and workflow logic are evaluated during configuration and execution. In certain cases, malicious payloads can bypass runtime protections and execute commands before security controls kick in. That means attackers can go from user-level access to full system compromise.

If you’re running n8n anywhere in your environment, now is probably a good time to take a look at it.

Patch it, review access controls and maybe put some guardrails around it, because when your automation platform doubles as a central repository of API keys, compromising that system can quickly turn into a much larger breach.

Researchers have been tracking a sophisticated iPhone exploit toolkit called Coruna, which contains more than 20 exploits capable of compromising iPhones running versions of iOS from 13 through 17.2. The toolkit has been observed in multiple campaigns, including operations tied to Russian espionage activity and financially motivated cybercrime groups.

The Google Threat Intelligence report on this is pretty thorough, and check out this video of security researcher Billy Ellis, who infected one of his phones to see what would happen.

What’s becoming clearer is where those exploits may have come from. Evidence suggests the toolkit may have originated inside a U.S. military contractor that builds hacking tools for Western intelligence agencies. From there, a leak involving a former employee appears to have helped push those capabilities into the wider hacking ecosystem — eventually putting them in the hands of foreign intelligence services and cybercriminal groups.

Trenchant, L3Harris and an Exploit Bonanza

We’re talking about something like 23 different exploits targeting iPhones running versions of iOS all the way up through 17.2. That’s already a big deal.

But what makes this story really interesting is where the toolkit appears to have come from.

According to reporting and analysis from researchers and former employees, parts of Coruna may have originally been developed by Trenchant, a hacking and surveillance technology division of the U.S. defense contractor L3Harris.

Trenchant builds exploitation tools for government customers, typically the United States and allied intelligence agencies.

In other words, these capabilities were never supposed to end up circulating in the wild.

Big Picture Getting Clearer

Here’s where the story starts weaving together with another one we talked about months ago:

A former executive at that same division, Peter Williams, was accused of stealing several hacking tools and selling them to a Russian exploit broker called Operation Zero. Prosecutors say he sold eight tools for about $1.3 million, and he was later sentenced to prison.

So you’ve got stolen hacking tools leaving a defense contractor.

At the same time, researchers start discovering a sophisticated iPhone exploit kit showing up in multiple campaigns.

And now new reporting suggests those two stories may be connected.

Researchers believe the Coruna toolkit may have been used by a Russian espionage group targeting Ukrainian victims through compromised websites. In those attacks, visiting a malicious page could trigger an exploit chain designed specifically for the victim’s iPhone.

That kind of targeting is typical of nation-state operations, but here’s where things get even weirder: The same exploit toolkit didn’t stay confined to espionage operations.

Researchers also found components of Coruna being used by financially motivated cybercriminal groups, including campaigns involving fake cryptocurrency exchanges aimed at stealing funds from victims. That’s unusual.

Normally, government-grade exploits stay inside intelligence circles. They’re expensive to develop and extremely valuable, so they tend to be tightly controlled. But once those tools leak, they can start spreading through brokers and underground markets.

That’s exactly what appears to have happened here.

One theory is that once the exploits were stolen and sold, they passed through multiple intermediaries — possibly brokers or government customers — before eventually reaching criminal groups.

At that point, the same capabilities that might have been used for espionage operations start showing up in fraud campaigns.

Google researchers also linked two vulnerabilities associated with the Coruna toolkit to Operation Triangulation, a sophisticated iPhone hacking campaign that previously targeted Russian users.

So now you’ve got a single set of exploit capabilities touching multiple parts of the cyber ecosystem:

• Government surveillance tools

• Nation-state espionage operations

• Financially motivated cybercrime

We’ve been covering all of these pieces separately: The stolen tools from a defense contractor, the discovery of a sophisticated iPhone exploit kit, different campaigns using advanced mobile exploits, and now the research and reporting are tying those threads together into one larger picture.

It’s a pretty stark reminder of how quickly powerful cyber capabilities can spread once they escape controlled environments.

Something built for intelligence agencies can eventually end up circulating all over the world, sometimes in the hands of actors the original developers never intended to empower.

Once that happens, there’s no putting the genie back in the bottle.

A Florida bill that proposes creating a statewide counterintelligence and counterterrorism unit immediately raised questions for me. On the surface, the mission sounds straightforward: detect and neutralize foreign adversaries, terrorists, and intelligence threats. But when you start looking at the actual language in the bill, things get a lot murkier.

(Proponents) point to New York’s dedicated counterterrorism unit, with a thousand officers and federal intelligence services that failed to prevent the 9-11 attacks. History shows us that when we depend on the federal government, Florida loses. Also worth mentioning that the approach in New York increased surveillance that drew criticism for violating civil liberties. We’ve seen sufficient abuses of power among at least one unelected cabinet member to give me grave concerns about the abuse of a bill like this to going into statute.

What also caught my attention is how broadly the proposal defines threats, including people whose “views or opinions” are considered harmful to the interests of the state. Combine that with language about analyzing “patterns of life” data and you start getting into territory that privacy advocates and cybersecurity experts have warned about for years: large-scale surveillance systems that could be used to monitor and classify ordinary citizens.

Devil in the Details

At first glance, the mission sounds pretty straightforward. The unit’s goal would be to detect, identify, neutralize, and exploit adversary intelligence entities, foreign adversaries, terrorists, insider threats, and corporate threats.

That’s the kind of language you usually hear when people talk about national security operations.

But once you start digging into the bill itself, some of the details start to raise questions.

One thing that stood out immediately is that the proposal appears to create a state-level counterintelligence capability that overlaps heavily with responsibilities that already exist at the federal level.

Expensive Redundancies

Agencies like the Department of Homeland Security, the FBI, the NSA, and the intelligence community already handle many of the types of threats the bill describes.

So the obvious question becomes: what exactly would this state-level unit be doing that isn’t already covered by those organizations?

Another issue is the funding.

The bill reportedly allocates around $2 million initially and roughly $1.5 million annually afterward. If you think about what it actually costs to build and operate an intelligence unit, that’s not a very large budget. You’re not hiring many analysts or investigators with that kind of funding.

But the part of the bill that really caught my attention is the language around identifying threats. The proposal defines an “adversary intelligence entity” extremely broadly. According to the bill, that category could include governments, organizations, businesses — or even individuals whose actions, views, or opinions are considered harmful to the interests of the state.

That’s where things start getting a little concerning, because once you start defining threats in terms of opinions or viewpoints, you’re entering territory that’s historically been associated with surveillance overreach.

And the bill goes further, saying the unit would identify threats by analyzing what’s called “patterns of life.”

If you’re not familiar with that term, pattern-of-life analysis basically means building profiles based on the data generated by everyday activities.

• Where you go

• What you buy

• What you post online

• Who you talk to

• What websites you read

• What your interests and beliefs might be.

That kind of data already exists in enormous quantities through data brokers, social media platforms, location tracking systems, and license plate readers.

And increasingly, governments are finding ways to aggregate and analyze it.

The phrase that keeps popping up in discussions about these types of systems is “sentiment analysis.”

That’s the idea that algorithms can analyze social media posts, communications, or other data to determine someone’s attitudes or beliefs.

You’re starting to see that concept show up more often in surveillance discussions, including systems that attempt to assess whether someone might represent a risk based on their online activity.

The concern is that once you combine those tools with vague definitions of what constitutes a threat, the potential for abuse becomes very real.

If authorities have access to enough data, they can almost always find something that looks suspicious or problematic depending on how the rules are interpreted.

That’s one of the reasons protections like the Fourth Amendment exist in the first place. Governments shouldn’t have the ability to monitor everyone constantly and then decide later who to investigate based on whatever information they happen to find.

No Mystery, It’s History

History is full of examples of surveillance powers expanding beyond their original purpose. That’s why proposals involving large-scale monitoring systems tend to generate strong reactions from both cybersecurity experts and civil liberties advocates. The debate over this Florida bill is another example of that tension.

Supporters argue that stronger intelligence capabilities are necessary to identify threats and protect the public. Critics worry that vague language and broad surveillance authority could eventually be used to monitor people based on their views rather than their actions.

When legislation starts talking about tracking “patterns of life” and defining threats based on opinions, it’s probably worth taking a closer look at how those systems would actually be used.

Once surveillance infrastructure exists, it tends to stick around, and the ways it’s used can change over time in harmful ways.

Iranian-linked hacktivists are claiming responsibility for a destructive attack against medical device giant Stryker, and the details coming out are nuts.

From everything we’ve seen so far, this looks like a straight-up wipe: systems reset, servers knocked offline, login pages defaced, and employee devices, including some personal phones enrolled for work access, apparently wiped after attackers gained deep administrative control.

The group claiming responsibility, Handala, framed the operation as retaliation for the US-Israeli war on Iran, including the bombing of an all-girls school.

Meanwhile, researchers are documenting Iranian-linked actors scanning exposed surveillance cameras in missile-hit regions to support battle-damage assessment, while Iranian state-linked channels are openly circulating Telegram target lists naming cloud, AI, and R&D facilities belonging to Amazon, Microsoft, Google, IBM, Nvidia, Oracle, and Palantir.

Rapid7 also warned that Iranian groups like APT35, APT42, MuddyWater, and OilRig remain highly relevant in the current environment, with phishing, credential abuse, and reconnaissance likely to intensify.

Targets Chosen for Widest-Possible Blast Radius

If you’re not in healthcare, you might not know the name immediately. I actually didn’t. But once this story started moving, it became very obvious that this is not some niche company nobody relies on. Stryker is a major medical device maker with roughly 56,000 employees, and it builds everything from surgical and imaging equipment to hospital beds, defibrillators, and systems used by the U.S. military.

Iranian-linked hacktivists from a group called Handala are claiming they hit Stryker, and the description coming out of this incident is about as destructive as it gets. Kim Zetter reported that Stryker employees in the U.S., Australia, India, Ireland, and elsewhere began posting that the company had effectively gone hard down. Internal and admin pages were reportedly defaced with Handala branding, the group claimed it hit more than 200,000 systems and devices, and Stryker itself told employees it was dealing with a “severe, global disruption” affecting laptops and systems connected to its network.

The way people were describing it, this wasn’t just “we can’t log into one app” or “VPN is down.” Employees were saying systems were reset, servers were inaccessible, and the whole company was at a standstill.

A Reddit post said three Stryker-managed devices were wiped around 3:30 a.m. EDT and that the Entra login page had been defaced with the Handala logo. Zetter also reported employee accounts saying attackers pushed OS resets to computers and phones connected to the company network and that many servers were wiped clean.

The Intune angle makes this especially nasty.

From the employee accounts that surfaced, it sounds like one of the hardest-hit areas involved personal phones enrolled for work access — the classic BYOD trap. A company says, “Sure, use your own phone for work, just install our MDM software and we’ll only touch the corporate stuff.” But that’s policy, not technical reality. If attackers get access to your Intune admin layer, they don’t have to honor the company’s policy. They can use the same device-management power to wipe enrolled devices, cut off access, and break whatever authentication chain those phones were part of.

Employee posts cited by Zetter said colleagues were told to remove Intune, Company Portal, Teams, and VPN from personal devices, and some users said they lost all personal data and could no longer access email or MFA-protected accounts.

That’s the part that should make every company doing BYOD stop and think for a minute. Once the attackers have that level of administrative access, they don’t just have the ability to wipe. They may have had the ability to read, export, or collect data too.

Handala has a history of stealing and publishing sensitive data, and The Register noted that the group or Iran-linked channels are now threatening a wider set of U.S.-linked technology targets as the conflict expands. So if they wiped Stryker, the obvious question is whether they also took a copy of what they wanted first. At this stage, there’s no public proof either way. But if you know the playbook, it’s hard not to ask.

The company’s official language is what you’d expect early in an incident.

Stryker said it was experiencing a global network disruption affecting its Windows environment and that teams were working to restore operations. That’s standard, cautious wording. But it doesn’t change what the early employee reports and the public claim of responsibility suggest: this was not a normal outage and not a normal breach. If the wipe reports are accurate, this was a destructive cyberattack in every sense of the word.

Iran Weaponizes the Cameras

According to Zetter, the group said the attack was partly retaliation for the U.S. bombing of an all-girls school in Iran on the first day of the U.S.-Israeli assault. Whether you take every element of the group’s narrative at face value or not, they are clearly framing this as geopolitical retaliation, not crime for profit. That’s why I don’t think this story should be viewed in isolation.

This morning I was also looking at Check Point’s new research showing Iranian-linked actors scanning the internet for exposed Hikvision and Dahua cameras across Israel, Qatar, Bahrain, Kuwait, the UAE, Cyprus, and specific areas in Lebanon.

Check Point says the targeting intensified on Feb. 28, aligns with missile activity, and is consistent with Iran using camera compromise for operational support and battle-damage assessment — potentially even before missile launches. The infrastructure they tracked used commercial VPN exit nodes like Mullvad, ProtonVPN, Surfshark, and NordVPN, plus VPS infrastructure. That’s exactly the kind of thing we’ve talked about conceptually for years: cyber reconnaissance directly supporting kinetic warfare.

So now put those two stories next to each other.

On one side, you have Iranian-linked actors scanning exposed digital infrastructure to support missile operations. On the other, you have a destructive wipe against a major U.S. med-tech company being claimed as retaliation tied to the war. In this conflict, cyber and physical operations are one and same.

Then layer in the infrastructure threat picture:

The Register reported that Iranian state-affiliated channels on Telegram circulated slides titled “Iran’s New Targets,” listing facilities tied to Amazon, Microsoft, IBM, Palantir, Google, Nvidia, and Oracle. The posts described these as the “enemy’s technology infrastructure,” gave locations and facility descriptions, and framed the war as expanding into infrastructure warfare. The same report said Iran had already conducted aerial attacks against three AWS datacenters in the Middle East, one in Bahrain and two in the UAE, disrupting regional cloud providers and forcing customers to shift disaster-recovery plans.

That’s wild, because now the targeting list is not just military sites or government systems. It’s cloud, AI, research, regional support infrastructure, and the private-sector companies that keep all of that running.

Rapid7’s threat analysis fits that picture too. They’re explicitly warning that Iranian activity is likely to intensify through phishing, social engineering, credential misuse, and scanning of internet-facing infrastructure.

They call out APT35 — Charming Kitten — as a long-running spear-phishing and credential-harvesting actor, APT42 as closely associated with surveillance and social engineering, and MuddyWater and OilRig as important MOIS-linked espionage groups in the current crisis environment. They also stress that sudden spikes in probing of remote access portals, VPN gateways, cloud services, and public web infrastructure should be treated as possible precursors to intrusion.

Broader Escalation Pattern

That’s why Stryker matters: not just because a huge healthcare-adjacent company got hammered, but because it may be part of a broader escalation pattern.

If you’re a defender, the lesson here is not just “patch faster” or “watch your MDM settings,” though both matter. It’s that geopolitical conflicts are now spilling into ordinary enterprise environments much faster and in more destructive ways than a lot of companies are prepared for.

If this attack really did move through admin accounts into Intune and then into a mass wipe of corporate and personal devices, it’s a brutal reminder that the blast radius of enterprise trust is bigger than most people think.

The White House released a national cybersecurity strategy this week, and people had apparently been anticipating it. I wasn’t.

I took a look at it and there just isn’t much there.

The document is only about seven pages long, and more than half of it is basically preamble. Two of the pages are essentially the title page and the closing section. That leaves very little actual substance in the middle.

When you read those pages, it doesn’t really feel like a strategy document. It’s mostly statements like: cyber threats are dangerous, adversaries target the United States, and the government will act to defend its interests in cyberspace.

The actual strategy part — the “how” — just isn’t there.

Where’s The Beef?

The document outlines several pillars, things like shaping adversary behavior, securing federal networks, protecting critical infrastructure, and building cybersecurity talent. All of those sound good in theory. Nobody’s going to argue against those goals. The problem is the document doesn’t really explain how the government intends to achieve them.

A lot of the language reads like what I’d summarize as “we’re going to do more better cyber.”

We’re going to defend our networks, deter adversaries and build cyber capabilities.

Okay, but how?

One section talks about shaping adversary behavior through offensive and defensive cyber capabilities, as well as encouraging the private sector to disrupt adversary networks.

That’s something the government has talked about before, particularly the idea of allowing private companies to take a more active role in cyber defense.

But again, there’s no real detail here about what that actually looks like in practice.

Another pillar talks about promoting “common sense regulation” and reducing what the document calls costly checklists.

And that’s where I start to get skeptical.

Checklists Written in Blood

Cybersecurity Checklists Exist for a Reason. There’s a saying in aviation that every item on a pilot’s checklist is written in blood. Every step is there because something bad happened in the past when it wasn’t followed. Cybersecurity controls are a lot like that.

When we require organizations to patch certain vulnerabilities, implement authentication controls, or monitor networks, those requirements usually exist because something catastrophic happened before those controls were in place.

So dismissing those safeguards as just “costly checklists” feels simplistic.

Another part of the strategy talks about modernizing federal networks and securing critical infrastructure. Those areas were historically major responsibilities of the Cybersecurity and Infrastructure Security Agency(CISA).

That raises another obvious question: If you’re talking about expanding federal cybersecurity efforts, how does that square with the fact that the government has significantly reduced the size of agencies responsible for doing that work?

You can’t say securing federal networks and protecting infrastructure are priorities while simultaneously shrinking the organizations tasked with carrying out those missions.

That disconnect is one reason the document has drawn criticism from lawmakers. U.S. Rep. Bennie Thompson, the ranking member of the House Homeland Security Committee, described the strategy as a “mishmash of vague platitudes” and a long list of “we will” statements without a clear blueprint for execution.

That criticism honestly captures the same reaction a lot of people had reading the document.

When you strip away the language, the strategy largely boils down to statements that cybersecurity is important and the United States intends to improve its defenses.

To be clear, cybersecurity absolutely is important, but a national strategy document needs to do more than say that.

It needs to explain how the government plans to allocate resources, which agencies are responsible for what missions, how the public and private sectors will cooperate, and what concrete steps will be taken to strengthen defenses.

Without that, you don’t really have a strategy.