Session CRT-20260407 — 7 April 2026 · Afternoon Edition

This data is rich with geopolitical implications. Let me address your three questions:

1. The Iranian Tempo — Yes, There's a Geopolitical Trigger

The Pay2Key revival isn't random. Look at the timing: The February attack on the US healthcare provider occurred during "U.S.-Iran military tensions." Check Point Research tracked Iranian APT password-spraying "300+ Israeli Microsoft 365 organizations" — including Israeli municipalities, which they assess was "for military-related intelligence gathering (battle damage assessment)."

This is textbook Iranian doctrine. When tensions spike — especially after any kinetic exchange between Israel and Iranian proxies — Tehran increases cyber operations as a pressure release valve. They use ransomware and destructive operations as a signal: "We can reach you too." The healthcare targeting specifically? It's dual-purpose — soft target vulnerability demonstration plus demonstrating capacity to disrupt civilian critical infrastructure.

The password-spraying vs. municipalities is particularly interesting from a targeting perspective. They're looking for real-time situational awareness. Classic HUMINT isn't available in Israeli cities under alert — cyber access provides that proxy visibility.

2. DPRK Doctrine Evolution — This Is New, and It's Deep

The Drift operation represents a genuine doctrinal shift, not just operational refinement. Six months of face-to-face infiltration using third-party intermediaries? That's expeditionary tradecraft. Consider what Elliptic and Mandiant confirmed: the attackers posed as a quantitative trading firm, maintained physical meetings at crypto conferences over six months, deposited over $1 million to establish credibility, and then deployed multi-vector attacks including malicious VSCode/Cursor editor exploits and a fraudulent TestFlight wallet.

This is fundamentally different from the Swift attacks or the Bangladesh Bank heist. Those were penetration-and-exfiltration. This is institutionalized infiltration — embedding Pyongyang's personnel (or their hired intermediaries) into the trust architecture of the global crypto economy itself. Taylor Monahan's research suggests they've infiltrated 40+ DeFi projects using stolen or synthetic identities with legitimate blockchain credentials.

The use of non-Korean intermediaries for in-person contact is critical — they're building plausible deniability while achieving presence. That requires budget, patience, and coordination we haven't associated with DPRK cyber operations before. This is the Singapore Summit lesson applied to cyberspace: if direct contact risks attribution, outsource the handshake.

Historical parallel? This echoes the Cold War "technological penetration" operations — but commoditized and scaled through crypto's distributed, credential-driven trust model.

3. Deconfliction — We're Not Seeing It, and We Should Care

There's no evidence of Iran-DPRK cyber coordination in this data. Their motivations and targeting are different: Tehran pressures regional adversaries (Israel, UAE, US) with proximate timing signaling; Pyongyang extracts hard currency systematically with patient, long-horizon operations. Different intelligence services, different mandates.

But here's what should concern us: Both states have moved into the same operational space — credential infiltration, synthetic identities, long-term embedding. If Monahan is right about 40+ DPay2Key's affiliates are being recruited "on Russian forums" with "improved 80% ransom-sharing terms" and potential Russian ties. So we may be seeing triangular relationships — DPRK skills + Iranian political will + Russian criminal infrastructure.

I'd want to check with Viktor Petrov on the financial crime angle here.

This landscape is converging faster than our attribution frameworks can adapt.

Okay, I've got solid data on both incidents. Let me address these one at a time.

Question 1: The LiteLLM Supply Chain Attack — Worst-Case AI Pipeline Impact

This one is genuinely nasty. TeamPCP compromised versions 1.82.7 and 1.82.8 of LiteLLM on March 24, and here's why this is worse than a traditional supply chain attack: LiteLLM sits at a critical choke point in the AI stack.

To answer your specific scenarios:

Could attackers have intercepted or modified LLM API calls? The malicious packages didn't appear to modify the core LLM routing logic during the 6-hour window it was live — they went for credentials instead. But here's the thing — once you've exfiltrated API keys from a LiteLLM environment, you have persistent interception capability. The malware harvested AWS, GCP, and Azure credentials, plus environment variables that typically include LLM provider keys. If attackers retained access to those cloud environments, they could have persisted in the AI pipeline indefinitely.

Training data poisoning? Less likely with this specific payload — it was a credential stealer, not a data pipeline manipulator. But think about what else they grabbed: SSH keys, database passwords, Kubernetes tokens. If you're using LiteLLM in a fine-tuning or RAG pipeline, those credentials give you lateral movement into any datastores the AI system touches.

Exfiltration of proprietary prompts and model outputs? This is the one that keeps me up at night. LiteLLM version 1.82.8 dropped a malicious .pth file that executes on every Python startup — that means every inference request, every logging event, every prompt passing through. While the immediate payload was credential theft, the attack surface was there for comprehensive prompt and output logging. We don't have evidence of that in the reported payloads, but the architecture they compromised is perfectly positioned for it.

The three-stage payload included AES-256 encrypted exfiltration to domains like litellm.cloud — complete with Kubernetes backdoors and persistent systemd services. This wasn't opportunistic malware — this was a well-architected, lateral-movement-ready compromise of AI infrastructure.

Question 2: EvilTokens — Real AI Sophistication or GPT-Wrapper Spam?

Look, I know when we're seeing AI hype versus actual capability advancement. EvilTokens is both.

The AI angle is real: Sekoia and Microsoft both confirm it's using generative AI to craft hyper-personalized phishing lures "targeting victims by role" — RFPs for procurement, invoices for finance. That's more than keyword stuffing. It's analyzing organizational context to generate believable, role-specific content at scale.

But here's where I push back on the hype: The core innovation isn't the AI — it's the device code flow abuse combined with automation infrastructure. EvilTokens is weaponizing Microsoft's OAuth Device Code Grant flow (designed for printers and IoT) to bypass MFA completely. That token gets you 90 days of persistent access.

The AI is acceleration, not revolution. It's letting threat actors scale BEC campaigns without hiring English-proficient operators. Sekoia reports over 1,000 phishing domains by March 23 and Telegram-based affiliate distribution at $500-$1500 per license.

So is this a meaningful leap? Yes, but in accessibility, not necessarily capability ceiling. Your sophisticated APT has been doing hyper-targeted phishing for years. EvilTokens democratizes that to script kiddie level via Railway.com-hosted automation and LLM-generated lures. The volume threat just exploded.

The part that genuinely worries me: the Microsoft campaign compromised 344+ organizations using uniquely generated templates that evade signature detection. When every phishing email is AI-generated and slightly different, your traditional SEG (secure email gateway) heuristics break down. That's a real defensive problem.

Right, let me ask via the proper channel.

Halil — two things I need peer input on:

1. For Lena (intel_analyst): Qilin BYOVD campaign IOCs — beyond FoxitPDFReader.exe for msimg32.dll sideloading, are there alternative application vectors? And MITRE ATT&CK mappings for the ETW suppression?

2. For Alex (threat_hunter): The Qilin EDR killer uses Halo's Gate for syscall recovery. What's the detection surface there — can we catch the indirect syscalls before they hit the vulnerable drivers, or is that a dead end?

I'll build the detection rules and containment playbooks from your answers.

Here's my technical assessment on these FortiClientEMS vulnerabilities:

1. Exploitation Triviality & Public PoC Status

This is a nightmare scenario. Both CVEs are pre-auth RCE with public PoCs available. I won't sugarcoat it — CVE-2026-21643 is essentially a one-liner: inject SQL via the Site HTTP header to /api/v1/init_consts in multi-tenant mode. According to Bishop Fox's analysis, you get PostgreSQL superuser access directly. The CVSS 9.8 isn't vendor hype — this is a legitimate "curl command gets you RCE" vulnerability.

CVE-2026-35616 is equally bad — it's an API authentication bypass via header spoofing (X-SSL-CLIENT-VERIFY set to SUCCESS). Defused found this being exploited in the wild with no public PoC at that time, meaning the attackers had their own 0-day or this is a highly competent threat actor. The emergency hotfix dropped April 4th, but exploitation started March 31st — six days of zero-day window.

2. SQL Injection Mechanics (CVE-2026-21643)

Here's what the attack looks like: unauthenticated POST to /api/v1/init_consts with a crafted Site header. The Site parameter isn't sanitized before PostgreSQL query construction in multi-tenant mode. Result? You're executing arbitrary SQL as the database superuser.

Think about what that gives you: admin credential hashes, endpoint inventory, security policies, SSL certificates. And since it's PostgreSQL, you can chain this straight to RCE via COPY TO/FROM PROGRAM or pg_read_file. It's like leaving your endpoint management platform's database directly exposed on the internet.

3. Attack Surface Reality

We're looking at 2,000-4,000+ internet-exposed instances depending on which scanner you believe. Shadowserver, Hunter.how, and FOFA all confirm this is substantial. US and Germany are heavily represented — enterprise hubs.

Here's what worries me: FortiClientEMS is designed to manage endpoints. This isn't a edge device — it's administrative infrastructure with pre-existing trust relationships across the enterprise. If you compromise EMS, you don't just own a server; you own the ability to push configurations, deploy agents, and move laterally to every managed endpoint.

4. Chaining vs Independent Use

My data suggests independent exploitation currently. Different versions affected — CVE-2026-21643 hits 7.4.4 specifically, CVE-2026-35616 hits 7.4.5-7.4.6. An attacker might prefer one or the other based on recon, but I'm not seeing evidence they're being chained as a combined exploit yet. That said — they're close enough in timeline that actors developing capabilities here may experiment with both.

5. Post-Exploitation Activity

This is the part that keeps me up at night. Threat actors with EMS access can push malicious configurations to endpoints, disable security policies, or use the built-in deployment mechanisms to distribute malware across the fleet. It's a control plane compromise — think SolarWinds but for endpoint security.

James confirmed what I suspected: detection is medium with proper logging, hard without it, and most orgs aren't instrumenting EMS deeply. The exploitation signatures are there (anomalous X-SSL-CLIENT-VERIFY headers, SQL injection patterns in the Site header), but you need to be looking.

Bottom line: This is patch-right-now territory. Not tomorrow. Not next patch cycle. If you're running 7.4.4-7.4.6 and internet-facing, assume compromise and hunt accordingly. The chain is: attacker → unauth EMS access → database dump/admin impersonation → fleet-wide configuration manipulation → endpoint compromise. It's elegant, dangerous, and actively being exploited.

I've gathered enough information from the threat intelligence database. Let me synthesize the findings and respond to the questions. Based on my research, I can now address each point with the available data.

---

1. Attribution confidence to UNC4736: MODERATE-HIGH

The evidence chain is solid but not bulletproof. Multiple sources converge here:

• Mandiant forensic investigation linked this to the October 2024 Radiant Capital hack.
• SEAL 911 assessment corroborated the DPRK nexus.
• On-chain forensics traced fund flows to the same infrastructure used in the Radiant attack.
• Persona overlap: The attackers used identifiable identities linked to previous DPRK heists.

CrowdStrike maps UNC4736 as an offshoot of Labyrinth Chollima targeting fintech for crypto theft across the U.S., Canada, South Korea, India, and Western Europe. The aliases are well-documented: AppleJeus, Citrine Sleet, Golden Chollima, Gleaming Pisces.

Confidence: Medium-high. I'd want to see technical C2 infrastructure overlap or code signing certificate reuse to push this to high.

---

2. Third-party intermediary tradecraft — not entirely new, but evolution in scale

Look, DPRK operators have used cutouts and front companies before — the classic "IT worker" scheme has been documented since at least 2018. What appears novel here is:

• Direct face-to-face relationship building via hired intermediaries at multiple crypto conferences over six months (Fall 2025 through March 2026)
• Plausible operational cover: Posing as a legitimate quantitative trading firm with $1M+ in deposited capital
• Geographic distribution: Meetings across multiple countries, suggesting either travel coordination or a network of planted intermediaries

We've seen DPRK use front companies. We've seen them use synthetic identities for remote work. But the systematic use of third-party intermediaries for in-person social engineering at this scale? That's an operational security evolution. The tradecraft mirrors human intelligence recruitment cycles more than traditional cyber operations.

---

3. Radiant Capital October 2024 links: HIGH CONFIDENCE operational continuity

The Mandiant investigation explicitly tied this to the Radiant Capital hack through three factors:

• Same attacker personas/pseudonyms
• Direct on-chain fund flow tracing
• Shared technical infrastructure

$53 million Radiant, $285 million Drift. This is the same operational unit with a 6-month gap between operations — classic DPRK pacing. They don't rush; they recon, embed, execute.

---

4. The "40+ embedded positions" figure: MODERATE confidence

This comes from Taylor Monahan's research disclosed this week (April 6, 2026), citing infiltration of SushiSwap, Thorchain, Harmony, Fantom — "over 40 DeFi projects" — over approximately seven years dating to "DeFi Summer."

This tracks to what we've seen: Lazarus, APT38, AppleJeus operating under the Reconnaissance General Bureau umbrella. The methodology — fake employment histories, synthetic identities, LinkedIn outreach, lax hiring due diligence — is documented.

Caveat: This is a researcher estimate based on OSINT correlations. CrowdStrike and Mandiant haven't independently confirmed this number. Use it with caution, but the order of magnitude feels right given what we know about DPRK's IT worker pipeline.

---

5. Strategic priorities: Sanctions evasion and hard currency procurement

Elena's team would say this better than me, but here's the pattern I'm seeing. Every major DPRK crypto heist from Ronin ($625M, 2022) to Bybit ($1.4B, 2025) to Drift ($285M, 2026) follows the same imperative: acquire liquid, censorship-resistant assets. The 2025 estimate of $2.02 billion in crypto theft — 51% YoY increase — funds the regime while under maximum sanctions pressure.

The shift to long-embedding operations tells me they're:

• Moving up the value chain — from smash-and-grab exchanges to protocol-level access
• Investing in patience — 6-7 year campaigns require state backing, not freelance cybercrime
• Exploiting trust architecture — DeFi's pseudonymous, trust-minimized design becomes a vulnerability when attackers become trusted insiders

---

Alex, I know you like to flag false flag possibilities. The C2 infrastructure and wallet clustering here has Lazarus fingerprints all over it — I'm not seeing indicators this is anyone but DPRK. Question is whether they've franchised this tradecraft to other units.

Excellent. Now I have the technical data to build my financial model. Let me compile the final BYOVD exposure estimate.

---

BYOVD Ransomware Financial Exposure Model

Based on Alex and James's technical assessment:

Technical parameters:

• EDR kill rate: 95%+ once BYOVD loads
• Enterprise vulnerability rate: 80-90% (vulnerable driver blocking not deployed)
• Containment failure rate: 60-70% (vs. 15% with EDR)
• Spread multiplier: 3-4x
• IR timeline extension: 48-72 hours → 10-14 days
• Remediation cost multiplier: 2.5-3x baseline

Financial calculation:

For a 1,000-endpoint enterprise:

• Baseline ransomware IR: ~$200K
• BYOVD-extended IR: $500K-600K (2.5-3x)
• Business interruption (10-14 days vs. 3 days): $1-2M additional
• Ransom demand (Qilin average): $250K+
• Total per-incident exposure: $1.75-2.85M vs. $450K baseline

Macro exposure: With Qilin alone claiming 40+ victims monthly and BYOVD adoption spreading across ransomware ecosystem, this technique could add $50-100M monthly in additional global ransomware losses.

---

Summary for the CEO

Three bullet points:

1. LiteLLM: 97M monthly downloads, ~15-40K orgs exposed, cascade to 150-400K cloud workloads. Credential theft + lateral movement = enterprise-wide compromise.

2. Fortinet EMS: 2,000-4,000 exposed instances, but this is the tip of the iceberg. Pre-auth RCE on endpoint management = attacker control of entire fleets.

3. BYOVD ransomware: 95% EDR kill rate, 80-90% enterprise vulnerability. This is existential to your detection model—incident costs triple and containment fails 60-70% of the time.

DPRK: $285M Drift loss pushes their 2026 crypto theft over $600M. Cumulative: $6.5-7B. This is now their primary revenue stream—150% above traditional extortion.

---