Typosquatting Is No Longer a User Problem. It's a Supply Chain Problem

TL;DR 

• Typosquatting is no longer a user problem. Attackers now embed lookalike domains inside legitimate third-party scripts. No mistyped URL required, no server breach needed.
• AI broke the economics of defense. LLMs generate thousands of convincing domain variants in minutes; full campaign deployment takes under ten. Malicious package uploads jumped 156% last year. Manual vetting is dead.
• Your security stack can't see this. Firewalls, WAFs, EDR, and CSP have no visibility into what approved scripts do once they execute in the browser.
• The Trust Wallet attack proved it. $8.5M stolen in 48 hours through a trojanized Chrome extension. No alert fired, not because something failed, but because nothing was watching.

This isn't a crypto story

On December 24, 2025, Trust Wallet users started losing money. Not because they clicked a phishing link. Not because they reused a weak password. Not because they did anything wrong at all.

A self-replicating npm worm called Shai-Hulud had spent months harvesting developer credentials: GitHub tokens, npm publishing keys, and Chrome Web Store API credentials. Those keys allowed attackers to push a trojanized version of the Trust Wallet Chrome extension through official channels. Chrome's verification passed it.

The malicious extension executed entirely inside users' browsers, silently capturing seed phrases and transmitting them to the attacker's infrastructure at a domain disguised as Trust Wallet's own analytics endpoint. Within 48 hours, 2,500 wallets had been drained. Total loss: $8.5 million. No server was breached. No alert ever fired.

Strip away the seed phrases and what remains is this: a trusted browser-delivered asset was silently modified to intercept sensitive user data before the legitimate application could process it, invisible to server logs, firewalls, WAFs, and EDR. Not because those controls were misconfigured, but because they were never designed to observe what happens inside a browser session, even a poisoned one. 

Swap seed phrases for payment card data. Swap the Chrome extension for a marketing pixel, a support widget, or an A/B testing framework. The attack is identical. A typical e-commerce checkout page runs 40-60 third-party scripts. Each is a trusted connection. The same thing could happen there.

How typosquatting got here: three phases

What makes Phase 3 a genuine evolution isn't just sophistication, it's economics. LLMs can generate thousands of convincing domain variations in minutes. Homograph attacks combine Latin, Cyrillic, and Greek characters to produce domains that appear visually identical in browser address bars while evading string-distance detection. Domain registration, SSL issuance, and full campaign deployment now take under ten minutes. Sonatype's data shows malicious package uploads to open-source repositories jumped 156% year-over-year, so volume alone has made manual vetting structurally impossible.

Three attacks that show the pattern

Typosquatting targets the domain layer, package compromise targets the supply chain, and browser-runtime abuse targets what trusted code does after it executes. 

1. Trust Wallet Chrome Extension (December 2025) 

Shai-Hulud harvested developer credentials over months before pushing a trojanized extension through official Chrome Web Store channels. The malicious extension captured seed phrases and transmitted them to a lookalike analytics domain. 2,500 wallets drained. $8.5M lost. Detection time: zero. No server-side visibility exists for browser-runtime execution.

2. chalk/debug npm attack (September 2025)

A phishing email targeting a single package maintainer gave attackers access to 18 trusted JavaScript libraries, including chalk and debug, with over two billion combined weekly downloads. Within 16 minutes, malicious code was injected across all of them, hooking browser APIs to silently intercept network traffic and wallet interactions. Fast containment limited direct losses to around $500. The exposure window wasn't the story. Two billion downloads was.

3. Solana Web3.js Library Attack (December 2024) 

Attackers compromised a publish-access account for the @solana/web3.js npm library through a phishing campaign, then published malicious versions containing a hidden function that intercepted private keys mid-transaction and exfiltrated them to an attacker-controlled domain registered just days before the attack. Any application that auto-updated within the five-hour window shipped the backdoor directly to its users. Nearly $200,000 drained before discovery. 

How the compromise happens: trust replaces deception

Classic social engineering needed a human in the loop, someone to mistype a URL, click a link, approve a prompt, trust a sender. The attacker's job was to manufacture trust in the moment.

The current generation of attacks skips that step entirely. Trust is no longer manufactured, it's inherited. Your build pipeline already trusts npm. Your vendor already trusts their CDN. Your browser already trusts the vendor. The attacker doesn't need to deceive anyone; they only need to insert themselves anywhere along a chain of trust that's already been granted.

Call it supply chain subversion - the deception isn't aimed at a person; it's aimed at the dependency graph.

The blind spot in your security stack

A marketing vendor integrated into your web properties references a JavaScript CDN registered six weeks ago. Valid SSL. Recognizable domain. Then the script is quietly updated. 

On your payment page, the browser silently loads the modified script. An invisible overlay intercepts keystrokes before they reach your application. Your server logs record a normal session. No alert fires.

CSP is the control most often cited as the defense. But CSP is a guest list, not a behavior monitor. An allowlisted script that reads your payment form fields and exfiltrates the data is still fully permitted, because the origin is trusted. CSP handles the connection. It cannot handle the execution.

Malicious behavior in 2026 is deferred to runtime by design. Shai-Hulud's packages remained dormant during automated scanning, only activating under specific runtime conditions. Static analysis cannot catch payloads loaded dynamically after execution begins.

What detection actually requires

IBM's 2025 Cost of a Data Breach Report found that the average breach takes 241 days to identify. In supply chain attacks where malicious behavior executes silently in browser memory, that window can be significantly longer, unless you're watching the runtime.

Detection requires observing what scripts actually do after they execute: which domains they communicate with, which page elements they access, and how their behavior deviates from established baselines. That's runtime behavioral monitoring, the one layer most enterprise security stacks currently lack.

The characteristics to monitor for:

• Unexpected data exfiltration: Scripts reading form fields and transmitting values to domains outside your approved list
• Dynamic domain resolution: Scripts calling domains registered recently or resolving differently than their baseline
• Behavioral drift: A script that behaved normally last week is now accessing different page elements this week. 

Detecting a suspicious domain in your dependency tree is necessary, but not sufficient. The harder problem is understanding what the script loaded from that domain actually does. AI-generated obfuscation is now specifically engineered to defeat static analysis: the code passes linting, mimics legitimate minified libraries, and produces no signature matches. 

Closing that gap requires behavioral deobfuscation at runtime, executing the script in an instrumented environment and tracing its actual behavior, not attempting to read its source. That means surfacing what a script actually accesses: form fields, cookies, network endpoints -  regardless of how heavily obfuscated the source is. It's the approach Reflectiz built its AI deobfuscator around, and it's detailed in the guide below. 

Your action plan

If you're not sure where to start, prioritize by exposure: payment pages first, authentication pages second, everything else after. Here's a practical sequence: 

This week:

• Audit third-party scripts for recently registered CDN domains in your dependency chain
• Review CSP reports, not just violations, but what your approved origins are actually doing
• Identify which pages handle sensitive data (payment, login, PII forms) and prioritize monitoring there first

This month:

• Deploy runtime behavioral monitoring for payment and authentication pages
• Establish behavioral baselines for all approved third-party scripts
• Implement subresource integrity (SRI) checks where scripts are self-hosted or cacheable

Proactive domain registration, strict CSP, and enforced DMARC are necessary. They cover domain registration, script delivery, and email impersonation. None of them covers what happens after an approved vendor script is silently modified. That's the gap most teams don't see until it's too late.

The controls above tell you what to do. Mapping them to your actual environment, vendor inventory, and compliance obligations is where execution stalls. Reflectiz has published a CISO Expert Guide with the complete framework: domain governance, foundational controls, runtime behavioral monitoring, and a phased implementation roadmap built around that gap.

Download the guide here →

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.