Daily Reading for 2026-08-27

AI Infrastructure Security

AI gateways, retrieval platforms, and orchestration engines are quietly becoming the new control plane of the enterprise — and attackers have noticed. Microsoft’s investigation of three compromises (LiteLLM, RAGFlow, Kestra) shows a consistent pattern: whatever the entry path, adversaries converge on the same prize — credentials, persistence, and compute to monetize. These workloads concentrate model-provider keys, database connection strings, tenant config, and container privileges in one runtime, turning a single exposed surface into a multi-asset breach. The lesson for technical readers is structural, not product-specific: AI infrastructure must be defended by its control-plane role, with Tier-0 secret handling, least-privilege database access, deny-by-default egress, and correlation of gateway-originated execution with secret access. Payloads also show signs of AI-assisted development — structured, portable, resilient — hinting that the tooling used to attack AI is itself being built with AI.

Watch for:

• Internet-exposed AI gateway/management surfaces (LiteLLM, RAGFlow, Kestra) accumulating unpatched CVEs and becoming default targets
• Credential concentration in gateway runtimes — /proc/1/environ, virtual-key tables, and DATABASE_URL as single points of failure
• AI-assisted payload craftsmanship (structured imports, fallbacks, masquerading) raising the resilience floor of commodity malware

Wardley signals:

• Components: LiteLLM gateway/proxy; RAGFlow retrieval platform; Kestra workflow orchestrator; LLM provider API keys & virtual keys; container runtimes (Docker socket); cryptominers (XMRig/RandomX); AI-assisted payload generation; Microsoft Defender XDR / Security Copilot.

• Evolution stage: LiteLLM/RAGFlow/Kestra — Custom-to-Product (open-source, rapidly maturing, competing forms, frequent CVE churn, not yet commodity). LLM provider keys — Commodity (utility-style, pay-per-use, expected). Container runtimes — Commodity (standard, essential, invisible). XMRig — Commodity (mature, off-the-shelf monetization tool). AI-assisted payload generation — Genesis-to-Custom (novel practice, observed characteristics but no accepted methodology). Defender XDR/Copilot — Product (feature-differentiated, vendor-branded, growing market).

• Doctrine hits/misses: Know the details (Operation) — the article’s core ask, inventorying exposed AI management surfaces. Manage failure (Operation) — defenders must assume compromise and correlate signals. Remove bias and duplication (Development) — per-team virtual keys vs shared master keys directly addresses duplication of credential exposure. Use appropriate methods — matching detection to control-plane role rather than per-product indicators. Set exceptional standards — treating gateways as Tier-0. Misses implied: Manage inertia — organizations still treat AI workloads as isolated apps, not critical infrastructure.

• Climatic patterns: Everything evolves through supply and demand competition — AI infra components racing from custom to product. Components can co-evolve (practice with activity) — security practice lagging behind the activity it must protect. Success breeds inertia — defenders’ existing app-security mental models resist the new control-plane reality. Competitors actions will change the game — attackers redefining AI infra as a target class.

• Diffusion markers: Multiple distinct open-source AI workloads hit with convergent objectives in one campaign — a copy-cat-class signal that “AI infra as target” is diffusing across the attacker ecosystem. Shared C2/OAST infrastructure reused across workloads. CISA adding the LiteLLM CVEs to the Known Exploited Vulnerabilities catalog marks standardization of the threat. Microsoft packaging Defender detections and Copilot promptbooks for this class signals vendor ecosystem moves to productize defense.

• When AI infrastructure becomes the target: Securing gateways and control points

%% 1. Users: enterprise security teams and defenders of AI workloads
%% 2. Needs: secure AI gateways/control points, detect compromise, protect credentials and compute
%% 3. Capabilities: gateway hardening, secret management, threat detection, runtime isolation
%% 4. Components: AI gateway, RAG platform, orchestration, secret management, threat detection, compute runtime
%% 5. Maturity: gateways/platforms Product; secret mgmt Product; detection Custom; compute Commodity
%% 6. Managed by: security teams via monitoring and least-privilege controls
wardley-beta
anchor securityTeam [0.95, 0.93]
component aiGateway [0.55, 0.65]
component ragPlatform [0.5, 0.6]
component orchestration [0.5, 0.55]
component secretMgmt [0.62, 0.45]
component threatDetection [0.35, 0.5]
component computeRuntime [0.78, 0.35]
aiGateway -> securityTeam
ragPlatform -> securityTeam
orchestration -> securityTeam
secretMgmt -> aiGateway
threatDetection -> aiGateway
computeRuntime -> aiGateway

Tortoiseshell APT

Iran-aligned Tortoiseshell (a.k.a. Mirage Kitten/UNC1549/Nimbus Manticore), an IRGC-affiliated actor active since 2018, is visibly broadening its operational footprint. Group-IB’s enrichment of prior Kaspersky reporting surfaces new tooling — a reverse-SSH tunneling DLL masquerading as wtsapi32.dll and a continued-use TWOSTROKE C++ backdoor with multi-C2 failover, file exfiltration, and in-memory DLL execution — plus a sprawling infrastructure of country-coded subdomains (uae1–14, sau, uk, bel, can, au, jp) across European and Middle Eastern hosts, mostly fronted by Caddy and TLS on port 2222. The throughline is geographic and capability expansion: a state-backed espionage actor industrializing its access toolkit while widening its target surface across defense, aerospace, and government-adjacent sectors.

Watch for:

• New TWOSTROKE variants or sibling backdoors reusing wtsapi32.dll side-loading and encrypted stack strings.
• Country-coded subdomain infrastructure migrating to fresh registrars after takedowns (e.g., tiktok-u[.]sbs suspended, locat[.]sbs persists).
• Reverse-SSH tunneling on port 443 from compromised hosts as a Tortoiseshell-specific TTP worth hunting.

Wardley signals:

• Components: Tortoiseshell APT (organisation); TWOSTROKE backdoor; reverse-SSH tunneling DLL; C2 infrastructure (country-coded subdomains, Caddy/TLS, port 2222); DLL search-order hijacking technique; supply-chain/watering-hole tradecraft; threat-intelligence feeds and EDR/YARA hunting (defensive).

• Evolution stage: TWOSTROKE backdoor — Custom (bespoke, IRGC-specific, repeatedly refined but not a product); reverse-SSH tunneling utility — Custom leaning Product (reuses commodity OpenSSH in a tailored wrapper, mirrors UNC1549 TTPs); country-coded C2 infrastructure — Custom (purpose-built, not yet commoditised); DLL side-loading technique — Product/Commodity (well-documented, widely used); threat-intel feeds/EDR/YARA — Commodity (mature defensive utility).

• Doctrine hits/misses: Defensive side illustrates “Know your users / Focus on user needs” and “Know the details” (deep IOC enrichment, subdomain mapping) and “Listen to your ecosystem” (cross-vendor pivoting off Kaspersky/GTIG reporting). Attacker side illustrates “Manage failure” (multi-C2 failover) and “Use appropriate tools” (commodity OpenSSH/Caddy repurposed). “Remove bias and duplication” is missed by defenders if they treat each alias (Mirage Kitten/UNC1549/Nimbus Manticore) as distinct.

• Climatic patterns: “Components can co-evolve (practice with activity)” — tooling and infrastructure adapt together; “Competitors’ actions will change the game” — takedown/suspension of tiktok-u[.]sbs prompting registrar migration; “Success breeds inertia” — defenders’ reliance on static IOCs risks inertia against shifting infra.

• Diffusion markers: TTP diffusion — reverse-SSH tunneling pattern shared across UNC1549 reporting (Google Cloud) and this Group-IB find, indicating a stable, propagating practice within the actor; infrastructure standardisation — uniform Caddy + TLS + port 2222 across ~25 nodes signals a templated deployment; alias proliferation across vendors (Tortoiseshell/Mirage Kitten/UNC1549/Nimbus Manticore) reflects ecosystem-wide attribution convergence rather than novel diffusion.

• 🚩 Iran-Aligned Tortoiseshell APT Expands Operational Infrastructure Across Europe and Middle East with New TWOSTROKE Backdoor and SSH Tunneling Capabilities.

%% 1. Users: threat-intel analysts and security defenders
%% 2. Needs: detect APT infrastructure, understand tooling, hunt for compromise
%% 3. Capabilities: malware analysis, infrastructure tracking, detection/hunting
%% 4. Components: SSH tunneling tool, TWOSTROKE backdoor, C2 infrastructure, malware analysis, threat intel, hunting
%% 5. Maturity: tooling/backdoor Custom; analysis/intel Product; C2 Custom
%% 6. Managed by: intel teams and CERTs via analysis and hunting rules
wardley-beta
anchor analyst [0.95, 0.93]
component sshTunnel [0.3, 0.6]
component backdoor [0.3, 0.65]
component c2Infra [0.35, 0.55]
component malwareAnalysis [0.55, 0.45]
component threatIntel [0.6, 0.4]
component hunting [0.4, 0.5]
sshTunnel -> analyst
backdoor -> analyst
c2Infra -> analyst
malwareAnalysis -> backdoor
threatIntel -> analyst
hunting -> analyst

QTFY China APT

China-linked threat actor QTFY is described as combining distributed scanning, IoT botnets, and proxy infrastructure to target U.S. critical infrastructure. The throughline is operational scale and reach: rather than a single bespoke intrusion chain, QTFY leans on commodity building blocks — mass scanning of internet-facing assets, repurposed IoT devices as relay nodes, and layered proxies — to assemble a large, disposable attack surface against industrial and infrastructure targets. For a technical reader, the significance is less novelty than logistics: an actor industrializing access by chaining cheap, ubiquitous components into a persistent campaign capability against critical systems.

Watch for:

• Expansion of IoT botnet and proxy rental/resale markets lowering entry costs for state-aligned actors
• Scanning-as-a-service and mass-asset-discovery tools becoming standard campaign plumbing
• U.S. critical-infrastructure sectors (water, energy, transport) reporting more probing tied to QTFY-style infrastructure

Wardley signals:

• Components: QTFY (threat actor/organisation); distributed scanning tools; IoT botnets; proxy/relay infrastructure; U.S. critical infrastructure (target activity).

• Evolution stage: Distributed scanning — Commodity (widely available, low-skill, metric-driven use); IoT botnets — Product/Commodity (rented and reused, accepted criminal utility); proxy infrastructure — Commodity (routine, disposable); QTFY as an org — Custom (bespoke campaign assembly atop commodity parts); critical-infrastructure targeting — Custom (specific targeting, not yet industrialised).

• Doctrine hits/misses: “Manage failure” (defenders must assume breach via commodity chains); “Know the details” / “Know your users” (understanding the actor’s logistics); “Remove bias and duplication” (defenders over-indexing on novel malware while ignoring commodity scanning). Misses on the defender side: “Manage inertia” (critical-infrastructure owners slow to harden IoT-adjacent exposure).

• Climatic patterns: “Everything evolves through supply and demand competition” (attack tooling commoditising); “Components can co-evolve” (IoT botnets co-evolving with proxy/scanning practice); “Success breeds inertia” (defenders’ legacy OT posture).

• Diffusion markers: Reuse of commodity IoT botnet and proxy tooling across state-aligned campaigns signals practice diffusion; scanning-as-a-service and botnet rental indicate standardisation of campaign plumbing; copy-cat adoption of distributed-scan + relay patterns across multiple actors.

• 🚩 China-Linked QTFY Uses Distributed Scanning, IoT Botnets, and Proxy Infrastructure to Target U.S. Critical Infrastructure

%% 1. Users: critical-infrastructure defenders and ICS security teams
%% 2. Needs: detect mass scanning, block botnet/proxy access, protect critical systems
%% 3. Capabilities: attack-surface monitoring, botnet detection, proxy blocking
%% 4. Components: IoT botnet, proxy infrastructure, distributed scanning, attack surface, detection, critical infrastructure
%% 5. Maturity: botnet/scanning Custom; proxy Commodity; detection Custom; critical infra Product
%% 6. Managed by: defenders via monitoring and sector-level coordination
wardley-beta
anchor defender [0.95, 0.93]
component iotBotnet [0.3, 0.6]
component proxyInfra [0.7, 0.45]
component scanning [0.5, 0.55]
component attackSurface [0.35, 0.5]
component detection [0.4, 0.5]
component criticalInfra [0.6, 0.35]
iotBotnet -> defender
proxyInfra -> defender
scanning -> defender
attackSurface -> scanning
detection -> defender
criticalInfra -> defender

NovaCookies Phishing Service

NovaCookies turns Microsoft 365 session theft into a rented product: $320/month buys domains, hosting, redirect hops, a buyer dashboard, and a maintained adversary-in-the-middle relay that captures authenticated sessions after password and MFA submission. The operation scaled sharply from mid-May 2026, reaching hundreds of organizations across regions, with ~90% of observed lures on .vu domains. Delivery chains stack trust — genuine Docusign envelopes, Microsoft/Google OAuth error-redirect hops, compromised legitimate sites — so each hop looks reasonable in isolation and only the final destination is hostile. Anti-analysis is a configurable scoring engine (proof of work, browser checks, context binding), not a fixed gate.

The throughline is industrialisation: what used to be bespoke kit work is now a subscription business with product features, versioned infrastructure, and many customers leaving the same fingerprints. Defenders who block yesterday’s domain catch one disposable part; the service persists. Phishing-resistant auth (passkeys, FIDO2) is the structural counter because origin-bound credentials won’t authenticate to the relay.

Watch for:

• Expansion of the .vu lure shape and brand-mutated hostnames into new domain families as the current set gets burned.
• Reuse of the Microsoft/Google OAuth prompt=none error-redirect trick and registered application IDs by copy-cat kits.
• Buyer-configurable anti-analysis presets spreading as a distinguishable product signature across unrelated-looking campaigns.

Wardley signals:

• Components: NovaCookies AiTM relay service; Microsoft 365 / Entra authentication; Docusign delivery; Microsoft & Google OAuth redirect hops; .vu lure infrastructure; Cloudflare fronting; client-side anti-analysis scoring engine; phishing-resistant auth (passkeys/FIDO2); operator dashboard/subscription panel; IOC feeds.

• Evolution stage:

  • NovaCookies AiTM relay service — Product (rental): subscription pricing, buyer-configurable features, hosted/rotated infrastructure, a maintained product not bespoke kit.
  • Microsoft 365 / Entra authentication — Commodity: ubiquitous, expected, identity backbone.
  • Docusign delivery — Commodity: trusted, standard document service abused as a hop.
  • OAuth error-redirect technique — Product→Commodity: documented by Microsoft, now reused across kits; increasingly accepted form.
  • .vu lure infrastructure — Custom/Product: rotating, campaign-specific, disposable.
  • Anti-analysis scoring engine — Product: configurable, versioned, feature-differentiated capability sold to buyers.
  • Passkeys/FIDO2 — Product (moving to Commodity): growing expectation of use, structural defense being pushed on high-value accounts.
  • Operator dashboard/subscription panel — Product: explicit SaaS-style packaging of criminal capability.
  • IOC feeds — Commodity: versioned, sanitised, treated as essential hygiene.

• Doctrine hits/misses:

  • Listen to your ecosystem (hit, by defenders): companion IOC release and versioned indicators reflect ecosystem-sourced detection.
  • Manage inertia (miss, by targets): reliance on passwords+MFA and domain-block lists is inertia the service exploits.
  • Use appropriate tools (hit, by attacker): layered, configurable anti-analysis chosen pragmatically per deployment.
  • Know your users / Focus on user needs (hit, by attacker): buyer dashboard, redirect options, support — product built around customer needs.
  • Remove bias and duplication (miss, by defenders): treating each campaign as unrelated incidents duplicates effort and misses the shared product.
  • Bias towards data (hit, by defenders): correlating lure shape, hostname mutation, mixed-case tokens, redirect chains into a product fingerprint.

• Climatic patterns:

  • Everything evolves through supply and demand competition — phishing kit industrialising from bespoke to rented product.
  • Components can co-evolve (practice with activity) — anti-analysis practice co-evolving with scanner capability; defender practice co-evolving with kit features.
  • Success breeds inertia — password+MFA model’s past success creates defender inertia the relay exploits.
  • Competitors’ actions will change the game — a documented Microsoft OAuth technique now reused, shifting the delivery landscape.
  • Evolution consists of multiple waves of diffusion with many chasms — infrastructure waves (late 2025 → mid-May 2026 → August) mark diffusion of the service.

• Diffusion markers:

  • Subscription pricing ($320/mo, $200/14 days) with bundled domains/hosting/redirects — explicit productisation and market formation.
  • Reuse of a Microsoft-documented OAuth error-redirect technique across campaigns — practice spreading from disclosure to operational adoption.
  • Many customers leaving identical product fingerprints (mixed-case tokens, .vu shape, relay taxonomy) — copy-cat-style deployment of a shared product.
  • Versioned IOC releases and behaviour-based detection guidance — standardisation of defender response around the product, not just the domain.

• NovaCookies Commercial Adversary-in-the-Middle Phishing Service Captures Authenticated Microsoft 365 Sessions for $320 Monthly Subscription Across Hundreds of Organizations Globally

%% 1. Users: phishing defenders and enterprise security teams
%% 2. Needs: detect AiTM phishing, protect Microsoft 365 sessions, block session theft
%% 3. Capabilities: phishing detection, session protection, phishing-resistant auth
%% 4. Components: AiTM relay, phishing lures, session theft, M365 auth, phishing-resistant auth, detection
%% 5. Maturity: relay/lures Product; session theft Custom; M365 auth Commodity; resistant auth Product
%% 6. Managed by: defenders via detection and structural auth controls
wardley-beta
anchor defender [0.95, 0.93]
component aimRelay [0.5, 0.6]
component lures [0.55, 0.55]
component sessionTheft [0.4, 0.5]
component m365Auth [0.75, 0.4]
component resistantAuth [0.6, 0.45]
component detection [0.4, 0.5]
aimRelay -> defender
lures -> defender
sessionTheft -> aimRelay
m365Auth -> sessionTheft
resistantAuth -> defender
detection -> defender

Qwen3.8-Flash-Next

Qwen3.8-Flash-Next is a multimodal mixture-of-experts model released as open weights, notable less for its headline size (125B parameters) than for its sparse 6B active footprint — a deliberate efficiency play that lets it run on a single DGX Spark once quantized. Simon Willison’s hands-on testing via Unsloth’s quantized variants is itself a signal: the practical frontier for “big” open models now includes consumer-adjacent hardware and community compression tooling, not just cloud clusters. Equally important is Qwen’s framing of this as an “early preview of the architecture used in Qwen4,” turning a shipping model into a public architecture dry-run for the next generation. For technical readers, the throughline is the accelerating compression of the gap between frontier-scale capability and locally runnable artifacts.

Watch for:

• Qwen4 architecture details emerging from this preview (routing, modality fusion, MoE scaling choices)
• Unsloth-style quantization becoming the default on-ramp for running frontier-class open models on single devices
• MoE active-parameter ratios settling into a recognizable “sweet spot” band across vendors

Wardley signals:

• Components: Qwen3.8-Flash-Next (multimodal MoE model); Unsloth quantized model variants; DGX Spark (local inference hardware); Qwen4 architecture (previewed)

• Evolution stage:

  • Qwen3.8-Flash-Next — Product (rental-ish): competing open-weights models with feature differentiation, but still shifting architecture, so late Custom/early Product.
  • Unsloth quantized models — Product: established tooling with competing quant variants users compare and choose between.
  • DGX Spark — Product: a defined, purchasable appliance for local inference.
  • Qwen4 architecture — Genesis/Custom: an early preview, poorly understood, still being discovered.

• Doctrine hits/misses: “Use appropriate tools” (Willison reaches for Unsloth quantization and a DGX Spark rather than cloud); “Bias towards action” (hands-on testing before conclusions); “Know your users” implicit in Qwen shipping a sparse, locally-runnable model. No clear misses.

• Climatic patterns: “Everything evolves through supply and demand competition” (open-weights MoE models racing on efficiency); “Components can co-evolve (practice with activity)” (quantization tooling maturing alongside model releases); “Higher order systems create new sources of value” (local inference of frontier-class models as a new value space).

• Diffusion markers: Unsloth quantized variants as a standardizing on-ramp; Qwen using a released model as a public architecture preview (a press-release/centre-of-gravity style move); single-device runnable frontier models spreading practice from cloud to local hardware.

• Qwen3.8-Flash-Next

%% 1. Users: ML engineers and developers running open models
%% 2. Needs: run frontier open models locally, quantize, get good performance
%% 3. Capabilities: model serving, quantization, local inference
%% 4. Components: Qwen model, MoE architecture, quantization, local hardware, open weights, inference runtime
%% 5. Maturity: model/MoE Product; quantization Product; hardware Product; open weights Commodity
%% 6. Managed by: developers via community tooling and local hardware
wardley-beta
anchor developer [0.95, 0.93]
component qwenModel [0.5, 0.7]
component moeArch [0.35, 0.55]
component quantization [0.68, 0.5]
component localHardware [0.22, 0.45]
component openWeights [0.85, 0.4]
component inferenceRuntime [0.78, 0.55]
qwenModel -> developer
moeArch -> qwenModel
quantization -> qwenModel
localHardware -> qwenModel
openWeights -> qwenModel
inferenceRuntime -> qwenModel