How a few lines of JavaScript led to silent data theft
This edition of Attack of the Week walks through a realistic, recurring client-side breach pattern seen across e-commerce, SaaS dashboards, and payment flows.
No zero-day.
No backend exploit.
No authentication bypass.
Just trusted JavaScript doing untrusted things.
Executive Summary
- Attack type: Client-side script injection / supply-chain compromise
- Target: Browser-executed payment and authentication flows
- Impact: Token theft, card data exposure, silent fraud
- Detection gap: Backend and identity controls saw nothing
This is not theoretical. This pattern repeats every year.
Phase 1: Initial Foothold (No Breach Required)
The attacker gains execution through one of the following:
- Compromised third-party script
- Tag manager abuse
- Vendor CDN modification
- Malicious update to a trusted library
The injected code is small — often fewer than 20 lines — and heavily obfuscated.
No alerts fire.
Phase 2: Execution in Trusted Context
The malicious script executes:
- Inside the browser
- On a trusted domain
- With full access to DOM and JS runtime
- During legitimate user sessions
Critical detail:
The script inherits the trust of your application.
CSP allows it.
SRI doesn’t detect it (script is “legitimate”).
Backend tools are blind.
Phase 3: Data Observation (Not Exfiltration Yet)
Instead of stealing data immediately, the script:
- Hooks
addEventListeneron sensitive fields - Observes form input timing
- Watches token refresh flows
- Learns page structure and user behavior
This reconnaissance phase can last days or weeks.
Still no fraud.
Phase 4: Silent Exfiltration
Once confidence is high, data is exfiltrated via:
- Beacon requests
- Image loads
- Legitimate analytics endpoints
- Low-frequency outbound calls
Traffic blends in:
- Valid TLS
- Normal destinations
- No unusual volume
Backend monitoring still sees nothing.
Phase 5: Downstream Abuse
Stolen data is used to:
- Replay authenticated actions
- Perform account takeover
- Execute fraudulent transactions
- Monetize at scale
Fraud teams notice anomalies.
Security teams investigate after the fact.
Why Traditional Security Missed This
| Control | Why It Failed |
|---|---|
| WAF | Requests were valid |
| MFA | Authentication already completed |
| SIEM | No abnormal backend logs |
| CSP | Trusted script allowed |
| SAST/DAST | Runtime-only behavior |
The attack never violated backend trust assumptions.
Where Early Detection Was Possible
This breach could have been detected during:
- Script change at runtime
- Unexpected DOM hooks
- New execution behavior
- Outbound request pattern drift
These signals existed before fraud, but no one was watching.
How BreachFin Would Have Detected This
BreachFin focuses on pre-impact signals, including:
- Client-side script execution changes
- DOM manipulation anomalies
- Runtime behavior drift
- Unauthorized client-side access paths
Detection would have occurred during Phase 2 or 3, not Phase 5.
That difference matters.
Why This Pattern Keeps Repeating
Because organizations still believe:
- “Trusted scripts are safe”
- “Valid traffic is benign”
- “Passing compliance equals protection”
- “Authentication is the hard part”
Attackers exploit these beliefs relentlessly.
Lessons Learned
- Client-side execution is part of your attack surface
- Trust must be continuously validated, not assumed
- Runtime behavior matters more than configuration
- Detection must happen before business impact
Final Takeaway
This attack did not break in.
It was invited — and never questioned.
If your security program cannot see:
- What executes in the browser
- How it changes over time
- Whether behavior matches intent
Then this attack pattern is not hypothetical —
it is inevitable.
Attack of the Week exists to show what really fails in production —
and why browser-side visibility is no longer optional.
