Runbook: Frontend Compromise
Security SpecialistOperations & StrategyDevops
This is an example runbook. Review and customize for your protocol before use. Add your specific DNS provider, hosting platform, and deployment procedures.
Quick Reference
| Field | Value |
|---|---|
| Typical Severity | P1 |
| Primary Responder | Frontend SME |
| Last Updated | [Date] |
| Owner | [Name] |
Identification
Symptoms
- Users report unexpected transaction requests
- UI behaves differently than expected
- Wallet drainer behavior detected
- Injected scripts or unexpected external resources appear in page source
- Official domain or subdomain resolves unexpectedly
- Community reports phishing or malicious prompts on the official frontend
Attack Vectors
| Vector | Signs |
|---|---|
| DNS hijack | Domain pointing to wrong IP or nameserver changes |
| CDN compromise | Malicious files served from trusted edge path |
| Dependency attack | Malicious npm/package dependency in built frontend |
| Build pipeline compromise | CI/CD workflow or build output tampered with |
| Hosting compromise | Files modified directly on origin or hosting platform |
Immediate Scope Questions
- Is the compromise limited to the frontend, or does it indicate deeper CI/CD or hosting compromise?
- Are users being asked to sign malicious transactions, approvals, or messages?
- Which domains, subdomains, and static assets are affected?
- How long may the compromised content have been served?
Immediate Actions
Step 1: Stop serving the compromised frontend
Why: The first priority is preventing new user interactions with a malicious interface.
Options:
- Point DNS to a controlled maintenance page
- Disable CDN distribution
- Remove or disable the affected site on hosting
- Block or disable the specific route/app if compromise is scoped and partial control is retained
Step 2: Warn users quickly and clearly
Why: A compromised frontend often becomes a user-signing incident within minutes.
- Post on Twitter/X
- Post in Discord/Telegram
- Update status page or incident page
- Pin the warning in primary community channels
Message template:
Our website may be compromised. Do NOT interact with [domain] or approve any transactions until further notice. If you have not signed new transactions, your funds in the protocol remain unaffected.
Step 3: Preserve evidence before cleanup
Why: The malicious content, served assets, and resolver state may change quickly.
- Save page source and served JavaScript bundles
- Record affected URLs, file hashes, and timestamps
- Capture DNS state, CDN config, and hosting/deploy history
- Preserve CI/CD and deployment logs if relevant
Step 4: Determine the trust boundary failure
Why: You need to know whether to treat this as DNS, hosting, dependency, or pipeline compromise.
- Identify how the malicious content was introduced
- Identify what credentials or systems may also be exposed
- Identify whether backend, admin, or deployment systems should also be treated as untrusted
Investigation
Priority: Identify Attack Vector
The first priority is understanding how the attacker gained access so you can close that vector.
- How did attacker gain access? (DNS, CDN, dependencies, CI/CD, hosting)
Once identified, go to the specific runbook:
- DNS hijack → DNS Hijack
- CDN/hosting compromise → CDN/Hosting Compromise
- Dependency attack → Dependency Attack
- Build pipeline compromise → Build Pipeline Compromise
Impact Questions After Containment
- What exactly was changed or injected?
- What user actions were being induced? (approval, signature, transfer, login, seed phrase theft)
- Which users interacted during the compromise window?
- Did the incident affect only the frontend, or also the underlying protocol or admin systems?
Check These
| Component | How to Check |
|---|---|
| DNS records | dig, registrar, DNS provider console |
| CDN files and config | compare to known-good state |
| Build artifacts | CI/CD logs, artifact store |
| Dependencies | lockfile, registry metadata, package diffs |
| Hosting files | compare deployed content to repo / known-good release |
Mitigation
See the specific runbook for detailed mitigation steps:
Recovery
Before Restoring Service
- Root cause identified well enough to prevent immediate recurrence
- Access path closed
- Fresh deployment produced from verified source and trusted build path
- Relevant credentials rotated
- Critical user flows manually checked before reopening
Restoring Service
- Deploy verified build
- Verify served assets match expected release
- Test critical wallet and transaction flows
- Monitor for unexpected asset changes, approvals, or user reports
- Announce service restored
Affected User Support
If users may have signed malicious transactions or approvals:
- Compile likely affected addresses from chain and telemetry data where possible
- Provide approval revocation guidance
- Provide transaction/contract indicators users should review
- Preserve evidence for later root-cause and impact analysis
- Consider remediation or compensation separately from immediate containment
Escalation
- Decision Makers - immediately
- Infrastructure Vendors - if hosting/CDN involved
- Legal & Communications - for user communication
Prevention Checklist
After resolving, review:
- DNS provider security and registrar controls
- Hosting/CDN access controls
- CI/CD security
- Dependency management discipline
- Frontend integrity controls (where applicable)
- User-facing monitoring for unexpected asset changes