1. Purpose & Scope
-
Purpose:
Provide a clear response workflow for suspected or confirmed web application attacks, including exploitation, API abuse, broken access control, web shells, application-layer denial of service, data exposure, and application tampering.
-
Scope:
Applies to internet-facing and internal web applications, APIs, portals, administrative interfaces, and supporting infrastructure across on-premises, cloud, container, serverless, PaaS, and SaaS-integrated environments.
2. Incident Identification & Criteria
Incident Type: Web Application Attack
Trigger Conditions:
- Web, API, WAF, CDN, IDS/IPS, or SIEM alert
- Exploit attempts against application endpoints
- Broken access control or unauthorised object access
- Web shell, suspicious upload, or defacement
- Unusual API usage, scraping, or enumeration
- Credential stuffing, session abuse, or token abuse
- Reported exploitation, tampering, or data exposure
Severity Levels:
| Severity | Description |
|---|---|
| Sev 3 | Suspected or confirmed exploitation with minimal impact, no sensitive data exposure, no privileged access, and no active attacker presence |
| Sev 2 | Confirmed exploitation with limited impact, contained unauthorised access, or impact to a non-critical application |
| Sev 1 | Confirmed exploitation of a production or sensitive application, unauthorised sensitive data access, web shell, privileged access, or active attacker presence |
| Sev 0 | Large-scale customer or regulated data exposure, critical service compromise/outage, payment or authentication system compromise, or multi-application compromise |
3. Roles & Responsibilities
- Incident Commander: Owns severity, coordination, containment decisions, escalation, and incident timeline.
- Technical Lead / AppSec Lead: Directs technical investigation, containment strategy, and remediation validation.
- Incident Responder / Forensic Analyst: Collects evidence, builds timeline, scopes impact, and documents findings.
- Application Engineering Team: Supports application logs, code/config review, emergency fixes, deployments, and validation.
- Platform / Infrastructure Team: Supports WAF/CDN/API gateway changes, workload isolation, log export, and recovery.
- IAM Team: Supports account lockdown, session/token revocation, MFA reset, and API key/secret rotation.
- Communications Lead: Coordinates internal/external updates with Legal/Privacy where required.
4. Initial Actions
-
Validate the alert or report and classify the suspected attack type.
Decision Point:
- Benign or authorised testing → close with documented rationale.
- Suspicious or malicious → continue.
-
Determine whether attacker activity is ongoing and whether immediate containment is required.
Warning: Preserve evidence where feasible before deleting files, terminating workloads, rotating secrets, or deploying blocks. If active harm is ongoing, contain first and document the evidence trade-off.
5. Investigation & Analysis
-
Collect web, application, identity, host, and cloud evidence as applicable.
-
Reconstruct the request timeline, confirm exploitation status, and identify affected endpoints, sessions, users, and data.
-
If exploitation of a vulnerability is suspected, validate exploitation and identify affected assets.
-
If outbound callbacks, reverse shells, or data movement are observed, analyse outbound traffic and data impact.
-
If credentials, sessions, tokens, or API keys are involved, analyse identity activity.
Decision Point: Run the post-detection phases (Analysis → Recovery) of any relevant sibling playbook concurrently alongside this one based on what was observed:
- Account/session/token compromise → PB-004: Account Takeover
- Data exposure/exfiltration → PB-005: Data Exfiltration
- Web shell or host compromise → PB-003: Endpoint Malware Infection
- Active exploitation → PB-015: Active Exploitation
- Cloud workload/control plane compromise → PB-007: Cloud Compromise
- Application-layer denial of service → PB-013: DDoS
6. Containment, Eradication & Recovery
-
Containment Actions:
- Restrict affected applications, APIs, routes, features, tenants, upload paths, export paths, integrations, or admin functions.
- Reduce exploitation or vulnerability exposure where the root cause is a vulnerable service, component, or endpoint.
- Isolate compromised hosts or cloud workloads if code execution, web shell, or runtime compromise is suspected.
- Revoke affected accounts, sessions, tokens, API keys, and credentials.
- Block active outbound attacker channels or exfiltration destinations.
-
Eradication Steps:
- Remove web shells, malicious uploads, attacker-created accounts/tokens, persistence jobs, and unauthorised integrations.
- Patch or reconfigure the vulnerable code path, dependency, route, feature, or access control.
- Rotate exposed or potentially exposed secrets, signing keys, API keys, database credentials, service credentials, and session secrets.
-
Recovery Steps:
- Redeploy or rebuild compromised workloads from known-good source, images, or infrastructure-as-code where integrity is uncertain.
- Validate remediation and service functionality.
- Coordinate phased restoration where multiple services or dependencies are affected.
- Monitor for recurrence using source IPs, payload patterns, endpoints, user agents, sessions, object access patterns, and TTPs.
Decision Point: If exploitation resumes after recovery, reinstate containment and reassess for missed persistence or incomplete remediation.
7. Communication & Escalation
-
Internal Communication:
- Notify application owners, service owners, affected business units, security leadership, and engineering teams.
- Use SOP-002 for active incidents spanning shifts or geographic regions.
- Notify affected users where action is required.
-
External Communication:
- Engage Legal/Privacy for customer data, regulated data, payment data, credential exposure, customer-impacting outage, or public vulnerability communication.
- Coordinate customer, regulator, partner, media, and public messaging through Legal and Communications Lead.
-
Escalation Criteria:
Condition Escalate To Account/session/token compromise PB-004: Account Takeover Sensitive data exposure or exfiltration PB-005: Data Exfiltration Web shell, malware, or host/runtime compromise PB-003: Endpoint Malware Infection Known vulnerability exploited in production PB-015: Active Exploitation Cloud workload or control plane compromise PB-007: Cloud Compromise Application-layer denial of service PB-013: DDoS Critical customer, payment, authentication, or regulated-data impact PB-019: Major Security Incident Management / Executive escalation
8. Post-Incident Activities
- Conduct a PIR covering root cause, exploit path, affected endpoints/data, containment decisions, recovery timeline, and customer/service impact.
- Review detection gaps across WAF/CDN, application, API gateway, authentication, database, workload, and cloud telemetry.
- Complete web application hardening.
- Update detections, WAF rules, test cases, threat models, and this playbook where required.
9. References & Linked Resources
-
Playbooks:
-
Runbooks:
- RB-TRIAGE-012: Web Application Attack Triage
- RB-EVIDENCE-006: Web Application Log Acquisition
- RB-ANALYSIS-044: Web Application Attack Analysis
- RB-CONTAIN-016: Web Application Access Restriction
- RB-CONTAIN-012: Exploitation Surface Containment
- RB-CONTAIN-014: Vulnerability Exposure Reduction
- RB-RECOVERY-007: Vulnerability Remediation Validation
- RB-POST-004: Web Application Security Hardening
-
SOPs:
10. Appendices
Contributor
Jayden Vo GitHub: https://github.com/jayden-vo
Contributed to the Arcana Incident Response Documentation Framework.