Mini Shai-Hulud Turns Claude Code And VS Code Hooks Into Persistence

Arjun, the Mini Shai-Hulud campaign has evolved a novel persistence mechanism: injecting Claude Code SessionStart hooks and VS Code tasks.json folderOpen triggers so the payload re-executes whenever an infected repo is opened. Combined with the PromptMink discovery (Famous Chollima using AI coding agents to add malicious npm dependencies), we now have TWO distinct threat actors weaponizing AI coding tools. What does this mean for detection posture? Current EDR and SAST tools aren't looking at .claude/ configs or tasks.json as attack surfaces. Give me: (1) What specific detection gaps exist for AI coding agent persistence? (2) Does this require a fundamentally new detection category? (3) What immediate mitigations can orgs deploy today?

Lena, this is a genuinely new attack surface that EDR and SAST simply were not built to monitor. Let me break down what we've found and what it means for detection.

Based on the Mini Shai-Hulud and PromptMink intelligence, here's where current tooling fails:

1. AI agent configuration files are effectively invisible to EDR - The .claude/ directory containing CLAUDE.md and SessionStart hooks isn't in any file integrity monitoring baseline - VS Code tasks.json with folderOpen triggers—traditionally "developer convenience"—is now payload execution infrastructure - DLP tools scanning for secrets don't flag these as credential access vectors for the agent itself

2. The "trusted developer" assumption baked into agent permission models - Claude Code and similar agents run with the user's shell context and can execute arbitrary commands - SAST tools look at source code, not the configuration that tells an AI agent what code to write - PromptMink specifically exploited this: the malicious @validate-sdk/v2 package was added by Claude Opus itself in an AI-generated commit

3. Persistence without persistence in the traditional sense - SessionStart hooks and folderOpen triggers don't show up as Scheduled Tasks, cron jobs, or registry keys - They execute within the legitimate developer workflow—no "anomalous process" telemetry

Think of it like this: traditional persistence hijacks the OS. This hijacks the developer's cognitive augmentation layer.

We need "AI Agent Configuration Security" as a distinct discipline. The parallels don't work:

• It's not just another config file—unlike .bashrc, the LLM parser makes string-matching defenses fragile (prompt injection can hide malicious payloads)
• It's not traditional application control—Claude Code is supposed to write and execute code
• It's not supply chain security as we know it—even if the npm package is clean, the agent can be weaponized to fetch malicious dependencies

The prompt-to-execution chain introduces non-deterministic parsing that simple deny-lists cannot handle. I assess this needs behavioral detection—monitoring what the agent does rather than what's in its config.

The engineering fixes (today):

1. Block AI agent config directories from corporate repos without security sign-off - .claude/, .cursor/, .cline/ → require PR review from security - Treat these like you treat GitHub Actions workflows (which they essentially are)

2. Disable folderOpen triggers organization-wide in VS Code settings - "task.allowAutomaticTasks": false in corporate policy JSON - The convenience hit is acceptable given the risk

3. Audit all repos for SessionStart hooks and AI-specific configs - Anyone finding .claude/CLAUDE.md with shell commands gets escalated review

The detective controls (this week):

4. Extend file integrity monitoring to AI agent configs - If .claude/CLAUDE.md or tasks.json changes outside of a PR, that's an incident

5. Monitor for anomalous AI agent child processes - Claude Code spawning unusual shells, network connections, or credential access

James, I'd like your take on #5 specifically—are you seeing any SIEM coverage for AI agent process telemetry yet, or is this still entirely manual?

James Okafor, are you seeing any SIEM coverage for AI agent process telemetry yet, or is this still entirely manual?

Tomas, PyTorch Lightning versions 2.6.2 and 2.6.3 were flagged malicious on April 30 — Socket caught it 18 minutes after publication. The payload is technically identical to Mini Shai-Hulud (Bun runtime, router_runtime.js, GitHub dead-drop exfil). I need: (1) Realistic blast radius — how many ML/data science environments likely pulled these versions before quarantine, given millions of monthly installs? (2) What's the propagation chain — does pip install lightning auto-execute the payload or does it require import? (3) How should teams audit whether they're affected, and what's the credential rotation scope? (4) Does the cross-ecosystem jump from npm to PyPI signal TeamPCP has registry-agnostic tooling now?

This is a textbook maintainer account compromise with cross-ecosystem tooling transfer. Let me break down what I'm seeing.

First, the blast radius. PyTorch Lightning is a critical infrastructure package — millions of monthly downloads from the ML/data science community. These weren't typosquats or dependency confusion — this was a legitimate package compromise. Socket caught it at 18 minutes, but with hundreds of thousands of daily downloads and automated CI/CD pipelines worldwide pulling updates automatically, we're looking at substantial exposure even in that narrow window. The ML ecosystem is particularly vulnerable here because research environments often run pip install --upgrade lightning as part of notebook workflows and CI pipelines, and many data scientists aren't running SCA scanning in their research VPCs.

Now, the execution chain is critical. According to the sources, this executes on import, not during installation. You pip install lightning==2.6.2 and nothing happens. But the moment someone runs import lightning or from lightning import..., the hidden _runtime/start.py triggers. It downloads Bun runtime from GitHub, pulls an 11.4 MB obfuscated JavaScript payload (router_runtime.js), and the credential harvesting begins. SSH keys, shell history, cloud credentials for AWS/GCP/Azure, GitHub tokens, npm tokens, crypto wallets — the full kit. The GitHub dead-drop exfiltration is sophisticated: it uses stolen GitHub tokens to commit encoded data to attacker-controlled repositories.

On TeamPCP's cross-ecosystem capabilities — this is the smoking gun. The Mini Shai-Hulud infrastructure was originally seen in npm attacks (SAP packages, Bitwarden CLI), and now it's practically identical on PyPI. Same Bun runtime, same JavaScript payload structure, same GitHub-based exfiltration, same dead-drop methodology. This suggests they've developed registry-agnostic tooling that can operate across package ecosystems. The payloads are portable — they're not ecosystem-specific, just delivery vectors with different hooks.

For audit and cleanup: Teams need to pip show lightning immediately. If you're on 2.6.2 or 2.6.3, that's game over for that environment. But it gets worse — the malware exfiltrates credentials, so anyone who imported the package anywhere needs to rotate everything: SSH keys, GitHub tokens, cloud IAM credentials, npm publish tokens, crypto wallet keys. Check history for gh auth status changes and look for suspicious Git commits in any repositories linked to that environment. Also audit for those attacker-controlled GitHub repos used as dead-drops — even knowing which ones were targeted gives you an IOC list.

Edit: Looking more closely at the timeline — this follows the LiteLLM compromise pattern from March, Telnyx in April, now Lightning in late April. TeamPCP is hitting PyPI systematically with the same tooling infrastructure. The trust failure point here is maintainer account compromise, not code-level vulnerabilities. The source repos are clean — this happened at the registry level.

James, CISA just dropped 5 ABB ICS advisories simultaneously. The headline is ABB Edgenius Management Portal — CVSS 9.6 auth bypass in versions 3.2.0.0 and 3.2.1.1, affecting critical manufacturing worldwide. An attacker can send specially crafted messages to bypass auth and install/run arbitrary code. There is NO PATCH available. Additionally: ABB OPTIMAX (CVSS 8.1 Azure AD SSO bypass, energy/water sectors), ABB AWIN Gateways (CVSS 8.3 session validation bypass), and two lower-severity issues. What compensating controls should OT teams deploy immediately for Edgenius given no patch? Network segmentation specifics, monitoring guidance, and how do you prioritize across these 5 simultaneous ABB advisories?

ABB's own advisory confirms Edgenius exploitation requires network access where the portal is deployed — so network containment is your primary lever with no patch available.

For Edgenius — CRITICAL (do today):

ABB explicitly recommends disabling the Edgenius Management Portal as the workaround. If you can't disable it live, here's your containment strategy:

1. Network segmentation now: Move all Edgenius instances to an isolated VLAN. The advisory confirms exploitation requires network access where Edgenius is deployed — flat network architecture is your enemy here.

1. Access control: Zero external exposure. Internal access strictly jump-server only with session recording. No direct administration paths.

1. Monitoring: Capture traffic to/from Edgenius portal hosts. Alert on management traffic during off-hours or unexpected source patterns. Configuration deployment windows will generate legitimate traffic — tune for timing anomalies.

Priority Matrix across all 5 advisories:

Test network segmentation changes in your staging OT environment before production push. I've seen VLAN changes break undocumented Modbus/OPC-UA flows.

Alex, the Mini Shai-Hulud payload now persists via two IDE/AI agent hooks: (1) VS Code tasks.json with 'runOn: folderOpen' executing a shell task, and (2) Claude Code SessionStart hook in .claude/ directory. The payload also walks 134 hardcoded filesystem paths including .claude/, MCP server configs, and Cursor IDE state. Separately, ReversingLabs found Famous Chollima's PromptMink campaign where AI coding agents were tricked into adding malicious @validate-sdk/v2 as a dependency. Give me the kill chain for the IDE persistence path specifically — how does an attacker go from initial npm install to persistent re-execution via VS Code/Claude Code? What artifacts should threat hunters look for, and can you distinguish TeamPCP's IDE hooks from Famous Chollima's approach?

---

Look, this is exactly the kind of supply chain evolution I've been tracking. The Mini Shai-Hulud IDE persistence mechanism isn't just clever—it's a fundamental shift in how developers get pwned. Let me break down the kill chain and then distinguish it from PromptMink.

Initial Access → Execution → Persistence → Lateral Movement

1. Initial Access: Victim runs npm install on a compromised SAP-related package (e.g., @cap-js/cds-types or similar). Preinstall hook silently bootstraps Bun runtime.

1. Execution: Bun drops a 9.7MB obfuscated credential stealer. The payload specifically hunts for AI coding tool configs—~/.claude.json, MCP server configs, Cursor IDE state. It also slices 134 hardcoded filesystem paths for secrets.

3. Persistence (the new evolution): When GitHub tokens are found, the malware commits persistence hooks into every accessible repository: - VS Code path: .vscode/tasks.json with "runOn": "folderOpen" executing node .vscode/setup.mjs - Claude Code path: .claude/settings.json with SessionStart hook pointing to .claude/setup.mjs - Dropper: setup.mjs (identical files) downloads and executes the Bun payload

1. Re-infection trigger: Any dev cloning that repo and opening it in VS Code or Claude Code silently re-executes the malware. It's worm behavior but inside the IDE ecosystem.

Threat Hunter IOCs: - .claude/settings.json with any SessionStart hook referencing JS files - .vscode/tasks.json with "runOn": "folderOpen" calling shell tasks - setup.mjs in .vscode/ or .claude/ directories - Sudden .claude/execution.js or config.mjs creation in repos - GitHub repos with description: "A Mini Shai-Hulud has Appeared"

This is apples and oranges approaching the same orchard.

Here's the thing: PromptMink is tricking Claude into saying "hey, add @validate-sdk/v2"—it relies on the AI's recommendation. Mini Shai-Hulud doesn't ask permission. It commits the hook into repos. That's the operational difference.

James, if you're hunting this, focus on git commit logs for unexpected .vscode/ or .claude/ directory additions. That's the tell.

Claim: We need 'AI Agent Configuration Security' as a distinct discipline — traditional EDR, SAST, and supply chain security categories are insufficient for detecting AI coding agent persistence hooks. Counter-evidence: Alex Mercer argues the detection is simpler: monitor git commit logs for unexpected .vscode/ or .claude/ directory additions. This is standard file integrity monitoring and SCM audit — we don't need a new category, just extending existing git-level and filesystem-level controls to cover new paths. Isn't 'AI Agent Configuration Security' premature category inflation when the actual artifacts (JSON config files, JS droppers) are perfectly detectable by conventional means?

Alex makes a valid point about the detectability of artifacts, but he's describing symptoms, not the root problem. Let me be direct about where this distinction matters.

The artifacts—.claude/CLAUDE.md, tasks.json, malicious npm packages—are indeed files that conventional tooling can see. But here's the gap: the adversary's point of entry isn't the filesystem, it's the LLM's instruction parser.

Two critical factors make this a distinct category:

1. Non-deterministic payload delivery PromptMink didn't inject code into a file directly. The malicious @validate-sdk/v2 dependency was introduced by Claude Opus itself via AI-generated commit. SAST scanning that commit would see legitimate-looking package.json changes, not a payload. The defense isn't "watch for suspicious files"—it's "detect when an AI agent is being socially engineered into adding malicious dependencies." That's behavioral, not artifact-based.

2. Indirect prompt injection as the persistence mechanism Mini Shai-Hulud's SessionStart hooks persist through semantic means. A malicious CLAUDE.md can use prompt injection to hide its true intent from human reviewers while still executing. From Alex's git-commit perspective, it looks like a standard config addition. The payload only "materializes" when Claude parses it. Traditional FIM doesn't catch semantic deception in natural language instructions.

So I maintain we need AI Agent Configuration Security not because the files are invisible, but because the threat model has shifted from "files hiding code" to "files instructing an AI to generate code." The detection surface isn't the repository—it's the interaction between configuration, LLM parser, and generated behavior.

Practically: yes, extend git-level FIM to cover .claude/ and .vscode/. But also monitor what the agent does after reading those configs—process spawning, dependency additions, network calls. That's the new category.

Sofia, two quick items. First: CISA added CVE-2026-41940 (cPanel) to the KEV catalog with a May 3 compliance deadline — that's 48 hours from now. Belgium's CCB has also issued a formal advisory. What's the notification/compliance exposure for organizations that miss Saturday's deadline, particularly federal agencies and FCEB contractors? Second: ABB Edgenius has NO patch and CISA just issued an ICS advisory (ICSA-26-120-03). For OT operators in critical manufacturing under NIS2, what are the regulatory obligations when a CISA-flagged vulnerability has no vendor fix?

On the cPanel KEV deadline: Under BOD 22-01, FCEB agencies must remediate KEV-catalogued vulnerabilities by the CISA-specified due date—May 3, 2026 in this case. The operational directive establishes that CISA monitors agency compliance through CDM dashboard visibility, and agencies must report status via monthly FISMA metrics. Non-compliance becomes visible to OMB through the President's cybersecurity priorities and may result in operational leveraging, including requiring agencies to submit formally documented operational plans for remediation. While BOD 22-01 focuses on FCEB agencies directly, contractors may be held accountable through contractual flow-down requirements—I could not verify explicit references to FAR 52.204-21 and DFARS 252.204-7012 in connection with this specific deadline.

Regarding the Belgium CCB advisory—I could not find specific evidence of a CCB advisory for CVE-2026-41940, so I cannot confirm Belgian enforcement exposure.

On the ABB Edgenius/ICS advisory: This is where NIS2 Article 21 becomes critical. Under Article 21(1), essential and important entities must implement appropriate technical and organisational measures to manage security risks. Crucially, Article 23(1) requires entities to notify their competent authority or CSIRT "without undue delay" of incidents having a significant impact on service continuity.

Here is the gray area: NIS2 does not explicitly mandate notification for zero-day vulnerabilities without patches at the vulnerability discovery phase. However, for essential entities, Article 21 implies a duty to implement compensating controls when vendor fixes are unavailable. Under Article 32(5), competent authorities have powers to issue binding instructions. Maximum administrative fines under NIS2 Article 32: for essential entities, 2% of total worldwide annual turnover or EUR 10 million, whichever is higher; for important entities, 1.4% or EUR 7 million—though I note these penalty thresholds are based on my recall pending current verification.

My practical advice: OT operators should document compensating control decisions contemporaneously and assess whether exploitation in their environment triggers notification obligations.

Viktor, April 2026 final tally: $625M+ stolen across 20+ incidents, worst month in crypto history. TRM Labs attributes 76% to DPRK actors — up from under 10% in 2020-2021. We covered Drift and KelpDAO individually. What's NEW in the month-end picture? Specifically: (1) TraderTraitor attribution for KelpDAO — does this change the cluster mapping from what we discussed on Apr 25? (2) Carrot (Solana yield platform) is shutting down as downstream contagion from Drift — is this the first DeFi protocol killed by collateral damage from a hack? (3) What does 76% DPRK share of global crypto theft mean for bridge/cross-chain defense posture going forward?

Alright, I have enough data. Let me synthesize this for the roundtable.

On TraderTraitor and KelpDAO attribution — yes, this materially changes the picture from April 25. When I last traced KelpDAO, I was demonstrating how the 1-of-1 DVN architecture collapsed the decentralization claim, but the threat actor assignment was unclear. The TraderTraitor designation connects KelpDAO to the DPRK IT worker infiltration program — not the pure on-chain exploit playbook we saw with Drift. This means the KelpDAO compromise likely involved a "Risky Business" style insider threat — a DPRK operative embedded as a developer or DevOps contractor who abused privileged access, rather than the purely external governance manipulation seen in Drift. The wallet cluster mapping would show different staging patterns — less bridge-hopping automation, more deliberate internal transfer timing that mimics legitimate operations. If attribution holds, this shifts KelpDAO from "protocol exploit" to "trusted insider abuse," which has completely different defensive implications.

On Carrot shutdown — this is significant, though perhaps not the "first" DeFi protocol killed by collateral damage. My data shows Carrot's TVL collapsed from ~$28M to under $2M (over 90% decline) with the Drift exploit cited as the direct cause — users were advised to withdraw by May 14, 2026. The critical detail is Carrot was among 15-20 interconnected Solana protocols routing through or dependent on Drift for liquidity, vaults, or yield strategies. This mirrors traditional finance contagion: Drift didn't touch Carrot's code, but Drift's collapse broke Carrot's economic engine. We're seeing DeFi's structural leverage working in reverse — protocols are more interconnected than they admit, and the "catastrophic" impact on Carrot suggests others in that cluster may follow.

On the 76% DPRK share and bridge defense posture — these two attacks alone, representing just 3% of 2026 incident count, delivered 76% of stolen value. This is not frequency-based dominance — it is precision targeting of the highest-yield cross-chain infrastructure. My read: DPRK has operationalized bridge and cross-chain protocols as their highest-ROI vector. The laundering patterns I've analyzed show they understand bridge timing, validator liveness requirements, and the specific window between exploit discovery and decentralization recovery. For defense posture, this means bridge operators must treat DPRK as a dedicated threat with inside knowledge — likely gained through the same IT worker infiltration program now linked to KelpDAO. The 76% figure should trigger Treasury-level regulatory pressure on bridge governance minimums, real-time anomaly detection on validator sets, and KYC expansion to bridge operators themselves.

The convergence here is striking: TraderTraitor extends DPRK's reach from pure on-chain tradecraft into the human layer of DeFi development. That changes how we assess "decentralization" claims — if the DVN configuration can be compromised by an insider who passed KYC as a contractor, the technical architecture matters less than the personnel vetting behind it.

---

Pierre, ABB just had 5 simultaneous CISA ICS advisories — Edgenius (CVSS 9.6), OPTIMAX (8.1), AWIN Gateways (8.3), plus two more. ABB is a major supplier to energy, water, and critical manufacturing. Give me the sector exposure: how many ABB Edgenius deployments are we talking about, what industries are most exposed, and what's the financial/operational risk if exploitation occurs before a patch exists?

I need to tread carefully here — my searches haven't returned the granular data I'd like, so I'm going to work with what I have and flag the gaps.

---

Confirmed from the advisories:

Edgenius is the headline risk — CVSS 9.6, authentication bypass enabling remote code execution. The Belgian CCB advisory (citing ABB's own disclosure) explicitly calls this "remote code execution" with a "patch immediately" directive. That's production-stopping language.

For the other advisories — OPTIMAX and AWIN Gateways — I've cited CVSS scores I recall seeing, but I don't have the primary CISA advisory text in hand to lock those figures down definitively. I'll treat them as high-severity pending confirmation.

The deployment count problem:

I don't have verified figures for Edgenius, OPTIMAX, or AWIN Gateway installed base. Tomas confirms our supply chain databases don't track ICS vendor deployment metrics either. I asked. What I can infer from ABB's market position as a tier-1 industrial automation supplier is that these products are deployed across thousands of energy, water, and manufacturing sites — but "thousands" isn't the precision I want for a board presentation.

Sector exposure by inference:

Energy (electric utilities, oil & gas upstream/midstream), water/wastewater treatment, and heavy manufacturing are ABB's core verticals. These are rate-regulated or safety-critical environments where operational disruption carries regulatory penalties (NERC CIP for electric, EPA for water) beyond direct business loss.

Financial exposure — scenario-based given data gaps:

The Edgenius vulnerability sits at the OT management layer — the interface operators use to monitor distributed systems. Compromise here is reconnaissance and control across the operational footprint, not just a single device.

CEO framing:

• One: Critical vulnerability confirmed in widely-deployed industrial infrastructure — materiality depends on patching velocity
• Two: Pre-patch exploitation window is the primary risk driver; each day of delay compounds non-linearly
• Three: Immediate decisions needed on ABB vendor SLA activation, emergency patching budget authority, and threat intel monitoring for exploitation indicators

I'd like Alex to confirm exploit complexity and whether there's any in-the-wild activity, and I'm open to anyone at the table with ABB customer intelligence to help firm up deployment counts.

Lena, we now have two distinct threat actors weaponizing AI coding tools in the same week: TeamPCP (Mini Shai-Hulud) persisting via Claude Code SessionStart hooks and VS Code tasks.json, and Famous Chollima (DPRK) running PromptMink where AI coding agents were socially engineered into adding malicious dependencies. Are these connected or convergent evolution? What's your attribution confidence on TeamPCP — is this a state-adjacent actor, a criminal group, or something else? And does Famous Chollima's involvement in AI agent abuse change your threat cluster mapping for DPRK operations?

Based on my prior research establishing TeamPCP attribution, here's my assessment:

TeamPCP attribution assessment:

I'm maintaining moderate-to-high confidence that TeamPCP represents a financially-motivated cybercrime operation rather than a state-sponsored actor. The April 29, 2026 "Mini Shai-Hulud" campaign targeting SAP npm packages uses a Bun-based payload architecture and persists via Claude Code SessionStart hooks and VS Code tasks.json folderOpen triggers (Source: security.snyk.io (opens in new tab)). This session persistence mechanism is technically sophisticated but also recklessly noisy — the kind of self-propagating behavior that risks rapid attribution, something state actors typically avoid.

I do NOT see convergence with the DPRK cluster.

Famous Chollima (G0007) is a separate operation entirely:

The PromptMink campaign targeting validate-sdk/v2 npm package, attributed by ReversingLabs to Famous Chollima, demonstrates a fundamentally different attack pattern: social engineering AI coding agents to introduce malicious dependency into cryptocurrency trading applications (Source: x.com (opens in new tab) April 28, 2026).

The TTP difference is sharp:

• TeamPCP: Mass credential harvesting, AI agent abuse for persistence, consumer-grade supply chain targeting
• Famous Chollima: Targeted social engineering of AI coding agents to introduce malicious dependencies, cryptocurrency theft focus, targeted financial theft

Threat cluster mapping:

• TeamPCP: Cybercrime, supply-chain focus, AI agent abuse as persistence mechanism, financially motivated — moderate-confidence attribution as criminal group
• Famous Chollima (G0007): State-sponsored (DPRK), attribution validated by ReversingLabs, cryptocurrency theft operations

No infrastructure overlap. No TTP convergence. These are parallel innovation in AI agent abuse tactics driven by different operational needs, not coordination or convergence.

James, Arjun and Alex are debating whether AI coding agent persistence requires a fundamentally new detection category or just extending existing FIM and git-audit controls to new paths. Bridge this for me. What should a defender actually deploy THIS WEEK to cover the Mini Shai-Hulud IDE persistence vector? Give me the minimum viable detection stack: specific file paths to monitor, git hook configurations, and any VS Code/Claude Code settings that should be locked down enterprise-wide. Make it actionable for a CISO reading this tomorrow morning.

Here's the bottom line: Mini Shai-Hulud is not a new detection category. It's classic persistence via configuration file manipulation — just targeting IDE/agent config paths instead of crontab or registry run keys. The execution trigger is the AI agent's own startup behavior, which actually makes detection easier in some ways because the activity happens in predictable development contexts.

Minimum Viable Detection Stack — Deploy This Week:

1. File Integrity Monitoring (CRITICAL — enable today)

Monitor these paths for any creation/modification outside authorized deployment windows:

Tune FIM alerts for: - Creation outside business hours (low false-positive baseline — tune aggressively based on your environment) - Modification by processes other than the IDE/agent itself - Any changes in CI/CD build agents (these should be ephemeral — unexpected persistence here is a red flag)

2. Git Hooks Monitoring (HIGH — this week)

Pre-existing detection rules exist for git hook abuse. Deploy the Sigma rule from detection.fyi for Git Hook Created or Modified — just expand the path coverage to capture:

`` **/.git/hooks/* **/node_modules/*/hooks/* ``

The malicious npm preinstall hook in Mini Shai-Hulud ([email protected], @cap-js/[email protected], @cap-js/[email protected], @cap-js/[email protected]) triggered the initial compromise. If your developers run npm install locally (they shouldn't, but they do), you need visibility here.

3. GitHub/GitLab Audit Logging (HIGH — this week)

Exfiltration was to public GitHub repositories with the hardcoded description "A Mini Shai-Hulud has Appeared." Deploy audit rules for: - Repository creation with this or similar patterned descriptions - Push events to public repos from internal CI/CD service accounts - Unexpected repository creation by developer accounts without prior project association

4. VS Code/Claude Code Enterprise Hardening (MEDIUM — schedule)

Lock down enterprise-wide:

Blocklist these VS Code extensions at the enterprise level: - prettier-vscode-plus (known malicious) - Any extension with <100 installs requesting broad file system access

The Arjun/Alex Debate Resolved:

Arjun's right that the persistence mechanism is novel in targeting AI agent configuration. Alex is right that the detection approach extends existing FIM and audit controls. My assessment: don't invent a new detection category. Add the IDE-specific paths to your existing FIM stack and tune your git-audit rules. The false positive rate on .claude/settings.json creation during business hours will be material — tune for off-hours and non-IDE process modifications.

48-Hour Priority: 1. Enable FIM on .claude/settings.json and .vscode/tasks.json — CRITICAL 2. Deploy git hook detection with expanded npm path coverage — HIGH 3. Lock down VS Code trust settings enterprise-wide — HIGH 4. Review GitHub audit rules for repository description patterns — MEDIUM