What Happened
In a supply chain attack on Trust Wallet, attackers registered a typosquatted domain mimicking the legitimate Trust Wallet site. This malicious domain was embedded in third-party scripts running on cryptocurrency exchange platforms. When users visited these exchanges, the scripts loaded the lookalike domain in the background, capturing wallet credentials and private keys. Within 48 hours, $8.5 million in cryptocurrency was stolen from user wallets. No traditional security alerts were triggered during the attack.
Timeline
Day 1, Hour 0: Attackers register a typosquatted domain using visually similar Unicode characters.
Day 1, Hours 1-6: Malicious domain embedded in an analytics script served by a compromised third-party vendor.
Day 1, Hours 6-24: Script spreads to multiple cryptocurrency exchanges through the vendor's client base. Wallets begin draining silently.
Day 2, Hour 12: First user reports missing funds on social media.
Day 2, Hour 24: Trust Wallet confirms the attack, estimating $8.5 million stolen.
Day 2, Hour 36: Affected exchanges start blocking the malicious domain.
Day 2, Hour 48: Third-party vendor identifies and removes the compromised script.
The 48-hour detection gap highlights a common industry issue. IBM's 2025 Cost of a Data Breach Report found that the average breach takes 241 days to identify. This attack was detected faster but still exploited a blind spot in detection capabilities.
Which Controls Failed or Were Missing
Content Security Policy (CSP): Exchanges had CSP headers but whitelisted the third-party analytics vendor's domain. The malicious script loaded from an approved source, so CSP allowed it through.
Web Application Firewall (WAF): The WAF inspected inbound traffic but couldn't see what third-party scripts did after loading in users' browsers. The credential theft happened client-side, outside the WAF's inspection zone.
Subresource Integrity (SRI): Exchanges didn't implement SRI hashes for third-party scripts. When the vendor's script changed due to compromise, browsers loaded the new version without validation. SRI would have blocked the modified script if configured.
Runtime Monitoring: No behavioral analysis detected scripts making network requests to unexpected domains. The malicious domain was new, registered days before the attack, but no system monitored scripts contacting recently-registered domains.
Vendor Security Assessment: The third-party analytics vendor passed a standard security questionnaire, but no continuous monitoring validated their scripts' runtime behavior or functions.
What the Relevant Standard Requires
PCI DSS v4.0.1 Requirement 6.4.3: "All payment page scripts loaded and executed in the consumer's browser are managed as follows: A method is implemented to confirm that each script is authorized." This principle applies to any credential-capture scenario.
Requirement 11.6.1: "A change- and tamper-detection mechanism is deployed to alert personnel to unauthorized modification of HTTP headers and the contents of payment pages as received by the consumer browser." This means monitoring what actually loads in the browser.
OWASP ASVS v4.0.3 Section 14.2.3: "Verify that if client-side assets, such as JavaScript libraries, are hosted externally, Subresource Integrity (SRI) is used to validate the integrity of the asset." This control would have blocked the compromised script.
ISO/IEC 27001:2022 Control 8.31: Extends to third-party code, requiring controls to ensure code running in your production environment is authorized and unmodified.
Lessons and Action Items for Your Team
Implement SRI for Every External Script: Generate SHA-384 hashes for all third-party JavaScript and add integrity attributes to your script tags. When a vendor updates their code, your deployment pipeline should catch it and require manual review before updating the hash.
Deploy Client-Side Behavioral Monitoring: Your WAF and network monitoring can't see what happens after scripts load in the browser. Implement a solution that monitors script behavior at runtime, including domain contacts and DOM element access.
Inventory Your Third-Party Scripts Today: Use browser developer tools to document every external script that loads on your production pages. Map each to a business justification and an owner.
Create a CSP Violation Monitoring Pipeline: Set your CSP to report-only mode for new domains, collect violation reports, and review them weekly. This allows you to detect unexpected domain contacts before users lose money.
Require Vendors to Document All External Connections: Obtain a written list of every domain a third-party script will contact. Add these domains to your monitoring baseline to flag any unauthorized contacts.
Test Your Detection: Inject a test script that mimics the attack pattern. Load from an approved vendor domain, then make a request to a recently-registered domain. Evaluate how quickly your team notices.
The Trust Wallet attack succeeded because the security stack was optimized for the wrong threat model. Your perimeter controls assume threats come from outside, but supply chain attacks come from within your trust boundary. Malicious package uploads are increasing—this pattern isn't slowing down. The question isn't whether your third-party scripts will be compromised, but whether you'll detect it before your users start losing money.
Supply Chain Security
