BLOG

Why Conventional Reputation Feeds Miss Software Supply Chain Attacks

We tested supply chain attack indicators across VirusTotal, URLhaus, AbuseIPDB, and urlscan.io - most failed to trigger any alerts.

By cb482791-4ef1-4762-96ad-b0ca4bdd538e · 2026-11-03T20:18:00.000Z

If an attacker drops a compiled backdoor onto an employee laptop, dozens of endpoint agents and antivirus scanners will race to flag the hash. But if that same attacker publishes a malicious npm or PyPI package, the entire threat intelligence apparatus goes blind.

VirusTotal, URL reputation engines, and IP blocklists are built to answer a specific question: “Has the wider security industry already analyzed this artifact and agreed that it’s malicious?”

That question works well for known threats, commodity malware, and phishing campaigns that have already circulated across thousands of corporate inboxes. But in a software supply chain attack, asking that question is dangerous.

Asking external threat feeds if an artifact is malicious is really asking if someone else already got hit, investigated it, and told the world. Software supply chain attacks are measured in minutes and hours. When a malicious package drops, no AV vendor has seen it, no sandbox has ingested it, and no researcher has written a signature for it yet.

Traditional threat feeds also reflect what happens downstream at the perimeter, while supply chain attacks happen upstream at the source. Threat intelligence aggregators index detections from email filters, endpoint agents, and network gateways. A malicious npm or PyPI package never touches any of those things before executing. It goes straight from a package registry CDN to a developer laptop or build pipeline.

To quantify how severe this gap is, we evaluated 624 indicators across two distinct cohorts:

Day-zero ingestion analysis: A 30-day census of 450 network indicators (domains, URLs, and IPs) analyzed at the exact moment of package ingestion between October 2 and November 2, 2026.
Post-disclosure retrospective analysis: An eight-month retrospective of 174 verified indicators across ten major 2026 supply chain attacks from March to October 2026, queried in our November 2026 snapshot months after public disclosure.

Across both datasets, external reputation systems failed to identify active supply chain threats. Even worse, the specialized tools security teams assume will catch what VirusTotal misses (like URLhaus, urlscan.io, and AbuseIPDB) performed with blind-spot rates exceeding 85% to 98%.

What conventional reputation feeds know on day zero

Our first dataset tracked 450 network indicators (229 domains, 166 URLs, and 55 IP addresses) generated by our analysis engine between October 2 and November 2, 2026. Though our platform cataloged thousands of indicators over this period, we isolated this set because they were actively queried against external threat feeds at the exact time of cataloging, giving us a true point-in-time baseline. See our live stats here.

While our enrichment pipeline tracks five threat dimensions (including cryptocurrency wallets on public ledgers), we evaluated this network cohort across the four dimensions relevant to command-and-control and staging infrastructure:

Antivirus and scanner consensus: VirusTotal
Specialized malware and web scanning: URLhaus & urlscan.io
Network reputation and host exposure: AbuseIPDB & Shodan
Domain registration and resolution: RDAP & Google DNS

This window matches the critical operational phase: when a developer or automated CI/CD runner first pulls the poisoned dependency. Because our automated ingestion pipeline specifically extracts and enriches network endpoints from manifests and install lifecycle scripts, this cohort consists of domains, URLs, and IPs rather than package tarball hashes.

At day zero, 62.2% of those indicators had zero detections on VirusTotal across more than 70 engines. Over 70% failed to hit the common enterprise alerting threshold of 3 or more detections.

Indicator Type

Analyzed at Ingestion

0 Detections (Clean)

1 to 2 Engines (Low)

Invisible to SOC Thresholds (≤2)

Payload URLs

166

69.3%

7.8%

77.1%

C2 / Staging Domains

229

59.8%

7.0%

66.8%

C2 / Exfiltration IPs

50.9%

16.4%

67.3%

Total Day-0 Census

450

62.2%

8.4%

70.7%

That 1 to 2 engine bucket is where security operations teams get burned. Most enterprise SOAR playbooks and SIEM correlation rules ignore anything with fewer than 3 detections on VirusTotal to avoid false-positive fatigue from noisy heuristic scanners. In our day-zero census, 8.4% of active, confirmed malicious infrastructure triggered only 1 or 2 engines. Combined with the 62.2% that returned zero detections, more than 7 out of 10 live attack endpoints completely slipped past automated enterprise alerting.

Even on network IP addresses, where reputation feeds traditionally perform best over time, more than half came back with zero detections on day zero and two thirds fell below standard alerting thresholds.

How other intelligence feeds performed at Day Zero

If multi-engine scanners like VirusTotal miss day-zero infrastructure, we wanted to know whether specialized URL, IP, or scanning tools fill the void. We tracked this cohort across our broader enrichment pipeline:

Specialized malware feeds (URLhaus / abuse.ch): >98% unlisted
URLhaus relies on web crawlers, honeypots, and spam traps. Supply chain attackers don’t spam their payload links across public forums or email. Instead, they embed them directly inside .tgz install hooks or obfuscated .py files. Unless a researcher manually submits the URL, it never enters the database.

Network reputation (AbuseIPDB): >90% reported zero abuse incidents
The IPs used by supply chain actors aren’t noisy internet scanners or brute-force bots. Rather, they’re passive listening posts and exfiltration relays set up specifically to receive credentials from infected build pipelines. To crowdsourced IP reputation databases, their abuse confidence score was 0%.

Web scanning and indexing (urlscan.io): Only ~15% had ever been scanned
Most attacker-registered staging endpoints and serverless subdomains had never received a single public crawler hit before package publication, and essentially none carried automated malicious verdicts.

Host fingerprinting (Shodan)
Most dedicated IP addresses either returned a 404 (net-new hosts never indexed by mass port scanners) or showed only commodity cloud edge ports (22, 80, 443) on infrastructure providers like AWS, Hetzner, or DigitalOcean.

Registration age (RDAP / WHOIS)
Over 60% of custom staging domains were Newly Registered Domains (NRDs) created less than 14 days before package publication, or were hosted on automated serverless preview subdomains (Vercel, Render, Netlify). While registration age is a useful heuristic for manual investigation, domain registries don’t assign threat verdicts, which leaves automated SIEM pipelines with nothing to alert on.

How conventional reputation feeds perform months after an attack

The obvious objection to day-zero numbers is lag. Threat intelligence takes time to discover attacks, vendors write signatures, and community feeds update. If you give the industry weeks or months, surely it catches up? Right???

To test whether that catch-up actually happens, our second dataset evaluated 174 verified indicators across ten major supply chain campaigns from March to October 2026. We queried these indicators in our November 2026 snapshot, months after the incidents were investigated, disclosed in public post-mortems, and patched.

External intelligence didn’t catch up.

Across all 174 indicators, 71.3% (124 of 174) remained complete blind spots on VirusTotal, either returning an HTTP 404 or zero detections across up to 92 engines. When applying the standard enterprise threshold (2 or fewer detections), that blind spot rose to 75.3% (131 of 174). For the actual malicious package files and scripts, 87.9% were either never seen by VirusTotal or were scanned and cleared as clean.

Thirteen of the 174 indicators (7.5%) represent legitimate shared services abused by attackers, including webhook.site, rentry.co, and public GitHub release links. If you exclude those shared services to focus strictly on attacker-controlled assets, the blind-spot rate is still 71.4% (115 of 161).

Campaign / Cluster

Target Ecosystem

Total IOCs

Detected (≥3 Engines)

Low Detection (1-2 Engines)

Scanned Clean (0 Detections)

Never Seen (VT 404)

Total Blind Spot Rate

AntV

npm

0 (0.0%)

1 (8.3%)

11 (91.7%)

100.0%

PyPI stealer clusters

PyPI

1 (5.3%)

0 (0.0%)

10 (52.6%)

8 (42.1%)

94.7%

TrapDoor campaign

npm, PyPI, Crates

3 (15.8%)

0 (0.0%)

3 (15.8%)

13 (68.4%)

84.2%

Contagious Interview

npm, GitHub, PyPI

5 (19.2%)

1 (3.8%)

10 (38.5%)

76.9%

PolinRider

npm, Web3

4 (21.1%)

1 (5.3%)

7 (36.8%)

73.7%

Keyv / Cacheable

npm

2 (22.2%)

1 (11.1%)

5 (55.6%)

66.7%

Trivy compromise (TeamPCP)

PyPI, Crates, npm

7 (29.2%)

3 (12.5%)

12 (50.0%)

2 (8.3%)

58.3%

Axios

npm

6 (42.9%)

0 (0.0%)

1 (7.1%)

7 (50.0%)

57.1%

IDE Extensions

VS Code, Open VSX

8 (47.1%)

0 (0.0%)

3 (17.6%)

6 (35.3%)

52.9%

Mini Shai-Hulud Worm

npm, PyPI

7 (46.7%)

1 (6.7%)

6 (40.0%)

46.7%

Total / Overall

Combined

174

43 (24.7%)

7 (4.0%)

49 (28.2%)

75 (43.1%)

71.3%

Note: Total Blind Spot Rate combines indicators returning HTTP 404 (never seen by VirusTotal) with indicators returning zero detections across all scanned engines.

The following chart shows how VirusTotal did at detecting software supply chain indicators, both in the live and historical sets:

The cross-platform test: Testing the other intelligence dimensions

To see whether non-AV threat feeds compensated for VirusTotal’s historical blind spots, we isolated the 54 attacker-controlled network indicators from the historical dataset (excluding the 107 package hashes and 13 shared SaaS endpoints) and tested them directly against URLhaus, urlscan.io, AbuseIPDB, and RDAP registration data.

The results show that external feeds didn’t provide a safety net:

Source

Type of Intelligence

Flagged / Detected

Blind Spot Rate

VirusTotal

Multi-engine AV / URL aggregator

18 of 54

66.7%

urlscan.io

Automated web crawler & DOM scanner

7 of 54

87.0%

AbuseIPDB

Crowdsourced IP abuse reporting

6 of 54

88.9%

URLhaus

Community malware URL feed

1 of 54

98.1%

RDAP / WHOIS

Domain registration age (<30 days old)

11 of 38 domains

28.9% NRD (Neutral)

Crucially, not a single external platform detected an indicator that VirusTotal had missed. Every domain or IP flagged by URLhaus, AbuseIPDB, or urlscan.io was already inside VirusTotal’s detected cohort. The specialized feeds were a strict, degraded subset of VirusTotal’s coverage, not an independent safety net.

URLhaus flagged exactly 1 indicator out of 54 (a 98.1% blind spot). Even months after high-profile write-ups, malicious C2 and exfiltration endpoints hosted on Render, Vercel, and custom domains were never ingested into URLhaus.
urlscan.io had scanned only 12 of the 54 indicators (22.2%), and flagged only 7 with malicious verdicts. The remaining 42 hosts had never been crawled or evaluated by the platform.
AbuseIPDB flagged only 6 of 54 indicators (an 88.9% blind spot). The average abuse confidence score across the entire cohort was below 8%.
RDAP identified 28.9% of registrable domains as Newly Registered Domains, but registration timestamps contain no reputation verdict. An automated firewall or SIEM rule cannot block an outbound connection simply because a domain is 10 days old without crippling development teams pulling from new open-source mirrors and project sites.

Why the conventional threat intelligence model fails

Both datasets point to the same structural flaw. General-purpose indicators, reputation scores, and multi-engine scanners miss supply chain attacks not because they lack data, but because they’re measuring the wrong things.

An infrastructure feed built to track internet-wide scanning campaigns or a virus aggregator built to analyze compiled binaries can’t reliably catch targeted, developer-focused attacks. Three architectural blind spots explain why:

Attacks execute outbound from trusted developer environments
Infrastructure is targeted, low-noise, and ephemeral
Malice lives in interpreted lifecycle scripts, (typically) not compiled binaries

Attacks execute outbound from trusted developer environments

Most enterprise detection stacks are oriented around perimeter defense: blocking inbound probes, filtering untrusted web downloads, or catching phishing links landing in employee inboxes.

Supply chain compromises flip that topology completely. An attacker doesn’t need to punch through your firewall or trick an engineer with a credential-harvesting email. Instead, an automated CI/CD pipeline or a developer running npm install or pip install reaches outbound over standard HTTPS ports to pull dependencies from trusted, public package registries.

When a malicious lifecycle script executes, its C2 beacons and data exfiltration requests blend right into legitimate developer network traffic. In our eight-month retrospective, 13 of the 67 network indicators (19.4%) were legitimate, high-reputation developer platforms, such as Telegram bot APIs, GitHub raw content endpoints, and public webhook listeners. Attackers deliberately route exfiltration through services your developers already (legitimately) use every day.

Because the connection originates from an authenticated workstation or internal build runner and points toward familiar developer infrastructure, perimeter inspection tools assume the session is legitimate and let it pass without a second look.

Infrastructure is targeted, low-noise, and ephemeral

Feeds like AbuseIPDB, URLhaus, and Shodan rely on volume and noise to build a reputation score. An attacker running a botnet, brute-forcing SSH keys, or blasting mass phishing emails generates thousands of alerts across hundreds of victim networks. Within hours, security crawlers index the IP, victim organizations file incident reports, and reputation engines mark the domain as malicious.

Supply chain attackers don’t work like that. They aren’t scanning the internet, hosting public landing pages, or spamming forums. Their staging endpoints and exfiltration servers sit quietly, waiting for a developer to run an install hook. A malicious package might only beacon back a handful of times before an incident responder detects the package and pulls it from the registry.

The data proves how quiet this infrastructure really is:

AbuseIPDB logged zero reports for 100% of the attacker-controlled IPs in our historical cohort. None of them had ever triggered an abuse report from an enterprise SOC.
URLhaus missed over 98% of active network indicators in our October census and 96.3% in our historical retrospective. Because URLs aren’t spammed across email or public forums, web crawlers never encounter them.
urlscan.io had only ever scanned ~15% of our October domains prior to ingestion. When we checked the historical cohort, 64.8% of attacker-controlled domains had never received a single scan in urlscan’s entire history.
Shodan returned 404s or net-new host statuses for the majority of our October IPs, with the remainder showing only standard ports (22, 80, 443) hosted on commodity cloud providers.

Because these endpoints never interact with the public internet at scale, web crawlers never visit them, community abuse databases never receive reports on them, and port scanners only see ordinary hosting infrastructure. To external reputation trackers, that infrastructure isn’t suspicious, it’s completely invisible.

Malice lives in interpreted lifecycle scripts, (typically) not compiled binaries

VirusTotal and endpoint security engines made their names analyzing compiled executables. Give them a Windows PE binary or a Linux ELF file, and their behavioral sandboxes and static heuristics can analyze imports, detect packed sections, and identify known malware signatures with impressive precision.

Supply chain malware rarely drops a compiled executable on day zero. (We are seeing a slight uptick in the use of binaries as part of the payload, but we attribute this to the use of LLMs trained on classic malware.) Instead, it arrives as interpreted text inside package manifests: an obfuscated snippet of JavaScript in a preinstall hook, a base64-encoded string in setup.py, or a tiny bash command piped into curl.

That’s why payload hashes showed the worst detection rates in our entire study:

87.9% of payload hashes in our retrospective dataset triggered zero detections across up to 75 antivirus engines on VirusTotal.
49 out of 107 malicious scripts had never been uploaded to VirusTotal in the first place, returning a 404.
Even when engines did evaluate the files, they scanned clean. Another 45 malicious scripts (42.1% of the cohort) were already indexed by VirusTotal, and all 75 engines rated them completely harmless.
In high-profile attacks like Keyv and Axios, secondary payload scripts like Keyv’s ad111858... (an obfuscated credential-harvesting script) sat on VirusTotal with 0 detections across 63 engines.

To an antivirus engine evaluating individual files in isolation, a 15-line script that checks environment variables and sends an HTTPS POST request doesn’t look like malware. It looks like standard, administrative automation code that thousands of legitimate developer tools run every single day.

The malice doesn’t come from the syntax itself. It’s coming from the context of where and when that code executes inside the package lifecycle. Without that registry context, general-purpose scanning engines can’t tell the difference between a deployment script and a credential-stealing backdoor.

How to triage developer environment alerts

When an alert fires on an open-source package or an unexpected connection during a build step, triage has to be driven by package context and execution behavior:

Inspect the install lifecycle hooks: Check preinstall, postinstall, binding.gyp, tasks.json, and setup.py. Did the package spawn child processes, evaluate base64-encoded strings, or trigger network calls? In package installations, network activity during lifecycle hooks is almost always anomalous.
Audit publisher provenance: Don’t rely on how many weeks a version has been on the registry—malicious packages frequently sit unnoticed for months. Instead, check for release anomalies such as an unvetted maintainer account, a version published directly to the registry with no matching commit or release tag in the upstream Git repository, or an unexpected patch on a long-dormant project.
Trace the network destination: If an install hook made an outbound request, identify where it went. Attackers frequently use raw IP addresses, ephemeral subdomains on serverless hosting, or legitimate webhook listeners and developer APIs to receive exfiltrated data. Treat any outbound connection to an untrusted or non-registry endpoint as an active indicator.
Quantify credential exposure: If malicious code executed, assume exfiltration succeeded. Map what secrets were accessible in that process. Software supply chain attacks often steal CI/CD runner environment variables, cloud provider IAM tokens, package registry publishing keys, .env files on developer laptops, AI service logins, and local SSH or GPG keys. Rotate those credentials immediately rather than waiting to confirm exfiltration.

Verifiable campaign examples you can test right now

You don’t have to take our word for any of this. You can check public indicators for the 10 campaigns we researched on VirusTotal right now.

Keyv and Cacheable compromise

What it was: A self-propagating worm derived from the open-source Mini Shai-Hulud worm. It stole developer credentials and used them to compromise further packages, affecting over 1,300 package versions including keyv, cacheable, flat-cache, and cache-manager.
Why it was selected: To test headline bias—whether scanners detect the full operational payload set or only the specific dropper file named in public incident write-ups.
How external intel performed: Across 9 indicators, VirusTotal had a 66.7% blind spot rate. Two indicators were detected by three or more engines, one had low detection, five returned HTTP 404, and one payload hash was scanned by 63 engines and scored zero detections.
IOC to look up: ad111858f73ef39e955ea4a6cdc83d92b53d5ca0248a94095ff0448c7b147e29 (SHA256 hash). This was the secondary credential-harvesting payload staged during the attack. While the headline dropper script (setup.mjs) reached 24 detections, this secondary payload remains at 0 detections across 63 engines in our snapshot.

Axios account takeover

What it was: Compromised npm maintainer credentials used to publish backdoored releases of axios targeting enterprise developer environments. Exfiltration was routed to an attacker-registered C2 domain with fallback commands pulled from public raw text pastes.
Why it was selected: To evaluate how scanners differentiate between dedicated attacker-owned domains and high-reputation shared services like rentry.co used as command relays.
How external intel performed: Out of 14 indicators, 6 were detected by three or more engines, 1 was scanned clean with 0 detections, and 7 returned 404s, resulting in a 57.1% blind spot rate.
IOC to look up: sfrclak.com (Domain). This was the primary exfiltration host. Following vendor write-ups, VirusTotal flagged it in 23 engines. In contrast, fallback staging endpoints on raw text-sharing services never generated a single detection and returned 404 responses.

Trivy supply chain compromise (TeamPCP)

What it was: A coordinated supply chain attack that reached Aqua Security/Trivy, LiteLLM, Checkmarx, and Telnyx, exposing secrets held by developer workstations and CI environments. The malware used Python AST parsing to extract secrets such as AWS_SECRET_ACCESS_KEY and GITHUB_TOKEN directly from build pipelines.
Why it was selected: To test whether heuristic engines can differentiate between legitimate developer environment inspection and automated secret harvesting in interpreted Python code.
How external intel performed: Across 24 indicators, TeamPCP had a 58.3% blind spot rate. While 7 indicators were detected and 3 had low detection, 12 indicators (including 9 malicious payload hashes and 3 command endpoints) were actively evaluated by VirusTotal and cleared with zero detections.
IOC to look up: csec-supply-chain-attack-1tcq.onrender.com (Domain). This was an active Render-hosted command and exfiltration endpoint used in the campaign. Evaluated across 92 engines on VirusTotal, 0 of 92 flagged it.

TrapDoor campaign

What it was: A cross-registry campaign spanning npm, PyPI, and Crates.io. Attackers published dozens of typosquatted packages masquerading as code quality, compliance, and linting tools, with embedded telemetry pinging a central validation domain.
Why it was selected: To test static domain reputation against infrastructure that deliberately borrows corporate and compliance terminology to blend into legitimate network traffic.
How external intel performed: Out of 19 indicators, VirusTotal missed 84.2%. Only 3 indicators reached three or more detections. Thirteen returned 404s, and three were scanned clean with 0 detections.
IOC to look up: verify.build-standards.org (Domain). This was the primary command and validation domain embedded across 37 backdoored packages. VirusTotal evaluated it across 92 engines, and 0 of 92 flagged it.

AntV maintainer takeover

What it was: Maintainer accounts atool and prop were hijacked, and 324 packages (including the AntV visualization suite) were republished with malicious versions. Injected payloads harvested authentication tokens from local ~/.npmrc files and exfiltrated them out-of-band to automated DNS and HTTP interaction endpoints without spawning interactive shells.
Why it was selected: To test whether security engines have visibility into registry-layer token theft using automated developer environment inspection coupled with disposable interaction endpoints.
How external intel performed: Across 12 indicators, VirusTotal had a 100% blind spot rate. Zero indicators reached detection thresholds. Eleven returned HTTP 404, and one domain returned 0 detections across 92 engines.
IOC to look up: x.oast.fun (Domain). Used as the out-of-band collection endpoint for stolen npm authentication tokens. Queried across 92 engines on VirusTotal, 0 of 92 detected it.

Mini Shai-Hulud self-propagating worm

What it was: A self-replicating npm worm that inspected local git configurations, cloned accessible repositories, injected malicious lifecycle hooks, and published backdoored versions using cached developer credentials.
Why it was selected: To test scanner detection of self-propagating lifecycle scripts that mutate package source files directly on disk.
How external intel performed: Across 15 indicators, 7 were detected, 1 had low detection, 1 was scanned clean with 0 detections, and 6 returned 404s, resulting in a 46.7% blind spot rate.
IOC to look up: git-tanstack.com (Domain). A typosquatted git host used by the worm for command distribution. While this network host was flagged by 18 engines, the package lifecycle scripts that performed the repository mutation and propagation remained undetected.

DPRK Contagious Interview campaigns

What it was: Targeted North Korean operations aimed at cryptocurrency, fintech, and web3 software engineers via social engineering. Victims were directed to clone bespoke coding challenge repositories containing loaders that pulled payloads from serverless hosting platforms.
Why it was selected: To test visibility into bespoke, single-victim staging infrastructure created hours before contact and torn down immediately after execution.
How external intel performed: Out of 26 indicators, VirusTotal missed 76.9%. Five indicators reached three or more detections, one had low detection, 10 returned 404s, and 10 were scanned clean with 0 detections.
IOC to look up: stanionstudios.com (Domain). A lure domain used to stage fake company branding and host malicious project requirements during developer technical interviews. Evaluated across 92 engines on VirusTotal, 0 of 92 flagged it.

PolinRider

What it was: Multi-stage JavaScript payloads embedded in npm packages that retrieved second-stage shellcode and C2 instructions directly from Binance Smart Chain and Ethereum smart contract state lookups via public RPC nodes.
Why it was selected: To test whether antivirus engines and URL filters can track command-and-control channels hosted on decentralized public ledgers.
How external intel performed: Across 19 indicators, 4 were detected, 1 had low detection, 7 were scanned clean with 0 detections, and 7 returned 404s, resulting in a 73.7% blind spot rate.
IOC to look up: 166.88.134.62 (IP Address). A primary RPC relay endpoint used to interact with malicious smart contracts. VirusTotal returned an HTTP 404, having never recorded or evaluated the address.

Targeted PyPI stealer clusters

What it was: Serial typosquatting and dependency confusion packages deploying obfuscated Python scripts. Payloads extracted browser credentials, crypto wallet private keys, and SSH keys, exfiltrating directly via Discord and Telegram bot webhooks.
Why it was selected: To test how URL reputation tools handle malicious payloads exfiltrating data across legitimate enterprise-allowlisted SaaS endpoints.
How external intel performed: Across 19 indicators, PyPI stealers had a 94.7% blind spot rate. Only one indicator reached three or more detections. Eight returned 404s, and 10 indicators (9 Python payload hashes and 1 staging domain) were uploaded, scanned, and cleared with zero detections.
IOC to look up: status.oastify.com (Domain). An exfiltration destination embedded inside multiple malicious Python packages. Checked across 92 engines on VirusTotal, 0 of 92 flagged it.

Malicious IDE extensions

What it was: Extensions published to the VS Code Marketplace and Open VSX impersonating popular code formatters, themes, and developer tools. Malicious code executed via extension activation events or automated tasks.json execution on workspace open.
Why it was selected: To test endpoint and scanner visibility into IDE execution environments that run outside standard terminal package manager lifecycles.
How external intel performed: Across 17 indicators, 8 were detected, 3 were scanned clean with 0 detections, and 6 returned 404s, representing a 52.9% blind spot rate.
IOC to look up: holiday-themes.dev (Domain). An extension C2 host used to stage payloads and receive exfiltrated developer machine telemetry. It was detected by 9 engines, while the underlying extension manifest and workspace task configurations remained completely unflagged.