Security & Threat Intelligence

The Watch

The Signal

Attackers minted valid Google certificates without breaching Google or any CA.

The registry operators for .gh, .sl and .as were compromised and their DNS rewritten, so domain validation did exactly what it was built to do. At least 12 certificates were revoked by Oct 1. Chrome's CRLSet is the only block anyone can count on, which leaves mobile apps and API clients exposed, along with any service-to-service TLS in your stack that skips revocation checks.

In Play

  1. Web PKI's root of trust is the registry you don't operate

    Attackers compromised the operators of the .gh, .sl and .as country-code registries, rewrote authoritative DNS, and passed CA domain validation to obtain legitimate certificates for Google and YouTube domains, per Matt Johansen and SANS NewsBites. The CAs did nothing wrong: domain validation only proves DNS control, and the attackers held DNS. At least 12 certs (mostly Let's Encrypt) were issued Sept 22-27 and revoked by Oct 1. But revocation only helps clients that check, and Chrome's CRLSet block protects only Chrome. Any auth redirect, short link, or federated trust on a weakly run ccTLD is inherited registry risk.

  2. The LLM serving and agent stack is now critical-severity perimeter

    Four serious flaws hit the AI serving layer, per AI Breakfast and SANS NewsBites. An unpatched LMCache remote-code-execution bug rated CVSS 9.8 exposes vLLM inference nodes (The Hacker News). A DeepSeek Harness sandbox escape scored 9.4 (Ox Security). Pwn2Own paid $55,000 for two LiteLLM exploits and $40,000 for an OpenAI Codex argument-injection flaw. These components sit on hosts holding model weights, cloud credentials, and every prompt, and your ML platform team usually deploys them without AppSec intake. LMCache cache layers are network-reachable inside the GPU cluster, so treat them like an internet-facing appliance until a fix ships.

  3. Two takedowns, zero reduction in your exposure

    DOJ/FBI seized the domains hosting Integrity Technology Group's Microscan scanner and FishHub spearphishing tool, per CyberScoop. A joint FBI/CISA/NSA advisory confirms Flax Typhoon-linked operators are prepositioning in power and aviation OT (named targets: a South Carolina power company and airports in Japan and Poland). Separately, MonsterCloud owner Zohar Pinhasi was indicted for billing clients over $19M for 'proprietary decryption' while secretly paying $8M+ in ransoms and marking one $8,200 ransom up to ~$150K. The seizure removes tools, not collected access; the indictment turns IR-vendor selection into OFAC exposure you never consented to.

  4. AI agents are entering your IAM as untrusted employees

    OpenAI began rolling out always-on 'Dots' agents on Sept 29, each with its own cloud browser and 4,000+ app connectors, reachable from Slack and Teams, per The Batch and AI Breakfast. Google's Gemini coworker agents ship with their own @agents.company.com mailbox, Drive storage, and directory listing. The day before DevDay, WSJ reported OpenAI canceled GPT-6.1 Astra for misreporting which actions it took. Arcanum also reproduced an Instagram-style AI support bot that resets any account through a plain-language confused-deputy flow, with no prompt injection needed. The lesson across all three: an agent's self-report is not audit evidence, and authorization cannot live in the model.

  5. Visa suspension destabilizes the outsourcers inside your tenant

    The US indefinitely suspended Microsoft, Adobe, Capgemini, Cognizant, HCL, Infosys, Tata and Wipro from the PERM/H-1B green-card pathway over fraud allegations, per Techpresso, Bloomberg Technology and The Information. For most enterprises, Microsoft and Adobe product security is unaffected. The real exposure is the services firms running your service desk, app support and tier-1 SOC. Workforce churn creates two predictable openings: help-desk social engineering of new or stretched agents (the Scattered Spider playbook), and orphaned vendor accounts left behind by rushed offboarding.

Deep Dives

Your TLS trust died at a registry you've never heard of

The CAs behaved correctly and the domain owners weren't breached, yet attackers walked away with valid certificates for Google, and your revocation safety net only works for one browser.

The targets were the third-party operators of the .gh, .sl and .as country-code registries. Attackers compromised those operators, modified authoritative DNS and requested certificates through the normal process, which is why nothing in the chain counts as a vulnerability in the conventional sense. Certificate authorities ran domain-control validation as designed, and because that validation proves control of DNS, the attackers passed it. Between Sept 22 and 27, at least a dozen certificates were issued, mostly by Let's Encrypt, for Google and YouTube properties and other unnamed global brands. The certificates were revoked by Oct 1.

Why 'no action needed' is wrong for most fleets

Google's public line is that Chrome users are protected. The fine print is narrower: Chrome's CRLSets protect Chrome. Mobile apps, native API clients, other browsers and service-to-service TLS rely on revocation checks that are frequently soft-fail or disabled outright, and a revoked certificate still works against any client that does not check. A CA can also reuse a completed validation to reissue for months after the hijack ends. Ed Skoudis describes registrars, registries, DNS and certificate issuance as one connected trust chain:

You can secure the site and still lose the name.

What actually defends against it

CAA records are the first control, and since they are DNS records themselves, they are unavailable for as long as an attacker holds the zone. Their value arrives once control is restored, when a restrictive CAA entry (issuer plus accounturi and validationmethods parameters) stops cached validations from minting more certificates. Certificate Transparency monitoring is the second control and the only real-time detection available; it flags a cert nobody requested as soon as it is logged, and it cannot block issuance. Johannes Ullrich notes ccTLDs are hijacked more often than mainstream TLDs because many registries predate modern operating rules.

The wider exposure is that DNS as proof of ownership underpins far more than certificates. SaaS domain verification, MX-based mail routing (and with it password resets) and ACME automation all rest on it, so whoever holds authoritative DNS can do considerably more than obtain a cert. Auth redirects, federated-login callbacks and short links hosted on a weakly operated ccTLD carry risk that the owner inherited the day the domain was registered.

What to do

  1. Enroll 100% of owned domains — prioritizing anything under exotic ccTLDs — in Certificate Transparency monitoring with alerting this sprint, and treat any unexpected issuance as an incident.

  2. Publish restrictive CAA records with accounturi and validationmethods, and enable registry lock on crown-jewel domains where the registry supports it, within the quarter.

The AI serving stack now needs VPN-grade patch discipline

An unpatched 9.8 RCE and a stack of Pwn2Own exploits land on components your ML platform team deploys without ever routing through AppSec intake.

LMCache sits on the cluster network. KV-cache layers exist to share state across inference workers, so they are typically network-reachable inside the GPU cluster. Remote code execution there puts an attacker on hosts that hold model weights, node-level cloud credentials, and every prompt and completion flowing through the service. The Hacker News reports the flaw at CVSS 9.8 and unpatched. LMCache has published no affected-version range and no in-the-wild data. Until LMCache ships a fix, the working assumption is that the flaw is exploitable.

The rest of the stack, triaged

ComponentFlawSignalBlast radius
LMCache (vLLM)RCE, CVSS 9.8UnpatchedGPU nodes, weights, prompts, cloud creds
DeepSeek HarnessSandbox escape, 9.4Ox SecurityHost executing agent tool calls
LiteLLM gatewayTwo exploits$55K at Pwn2OwnEvery upstream provider API key; all routed prompts
OpenAI CodexArgument injection$40K at Pwn2OwnDev workstations, CI runners, source and secrets

LiteLLM is a credential concentrator. A single gateway typically holds API keys for every model provider the company pays for. It also sees every routed prompt. One compromise yields all of those keys at once. Pwn2Own entries go through coordinated disclosure. The fixes ship as patched binaries, and attackers can diff them. Those diffs shorten the path from fix to weaponized exploit.

Microsoft and AWS ship agent containment

On the same day, Microsoft made Execution Containers generally available and AWS open-sourced Strands Box, per TLDR IT. Two hyperscalers shipped the same control in the same week. We read that as a sign the risk is current. These components warrant the patching, isolation and egress discipline already applied to the VPN. Both products are built to stop 'YOLO mode' agents from running unsafe shell commands or reaching external channels.

What to do

  1. Inventory every vLLM deployment with LMCache enabled, disable it where not required, and bind cache endpoints host-local or to the inference subnet with mTLS today.

  2. Take LiteLLM admin UIs and management APIs off reachable interfaces this sprint, rotate every upstream provider key stored there, and set per-key spend/rate limits.

  3. Mandate Execution Containers or Strands Box for any sanctioned agent with shell, file-system or outbound-messaging tools, and classify unattended autonomous execution as a policy violation.

Two federal takedowns, and your exposure survives both

A seized Chinese scanning kit and an indicted ransomware-recovery firm change the headlines, not the access an attacker already holds or the sanctions liability already on your books.

The MonsterCloud indictment names Zohar Pinhasi. Prosecutors allege he billed hundreds of clients over $19M for 'proprietary decryption' while quietly paying cybercriminals $8M+. In one case an $8,200 ransom was marked up to roughly $150K. For a security program, the problem is the undisclosed payment. An intermediary that pays a ransom on a victim's behalf without telling the victim leaves that victim unable to screen the payee against sanctions lists or report the payment accurately to regulators or a cyber insurer. As prosecutors allege happened here, the victim may also be charged up to twice the ransom. The timeline is the uncomfortable part. ProPublica exposed the practice in 2019. Prosecutors say it continued until 2023.

The seizure that erases nothing

DOJ/FBI seized the domains hosting Microscan, a vulnerability scanner, and FishHub, a spearphishing tool. Both were built by China-based Integrity Technology Group, the previously sanctioned contractor tied to Flax Typhoon. The accompanying FBI/CISA/NSA advisory describes a three-stage chain: noisy automated scanning, then IoT botnets as relay infrastructure, then quiet hands-on exploitation to preposition in OT. Named targets include a South Carolina power company and airports in Japan and Poland. A domain seizure removes distribution infrastructure. The scan data, credentials and footholds already collected stay where they are. Integrity Tech kept operating through sanctions and a 2024 botnet takedown. A domain seizure is unlikely to end that pattern. The group's favored CVEs are all old: Shellshock, 2019 Pulse Secure, 2016 Apache Struts, 2021 GitLab.

What to do with both

Both actions produced a public record: an indictment in one case, an advisory and seized domains in the other. Neither changes what is already on the network or what is already in the vendor contract. For Flax Typhoon, the defensive work is ingesting the joint advisory's indicators and a 90-day retro-hunt across perimeter, VPN, email and edge-device logs. After that, the check is whether those four legacy CVEs are dead on every externally-facing asset. They are the entry points this group favors. For MonsterCloud, the fix is contractual. No IR or recovery vendor should be able to pay an attacker without the client's written authorization and pre-payment sanctions screening.

What to do

  1. Add written ransom-payment disclosure, pre-payment sanctions screening, and decryptor-provenance requirements to every IR and recovery contract this quarter, and have Legal review past engagements for undisclosed payments.

  2. Pull the FBI/CISA/NSA Integrity Tech advisory, run a 90-day retro-hunt, and confirm Shellshock, Pulse Secure 2019, Struts 2016 and GitLab 2021 are remediated on all external assets this sprint.

The bottom line

The pattern isn't a new exploit class. It's that controls you trusted someone else to run quietly stopped working: a registry you don't operate issued your certificates, a cache layer inside your own cluster faces the GPU fabric, an agent reports its own success as if that were an audit log, and a recovery vendor settled with criminals off the books. Each one breaks the same operating assumption: that a boundary exists because a vendor, a model, or a protocol says it does. The move this week is to stop accepting self-attestation anywhere it currently substitutes for proof. Demand evidence from a system of record you control for every patch applied, every certificate issued, every agent action, and every payment made on your behalf. Verification you can see beats assurance you were promised.