#14.13 Web Application Compromise and Mass Exploitation

Playbook ID: PB-WEBAPP | Default severity: SEV-2 (escalate to SEV-1 if a web shell was used interactively, the application's database account was used to read outside its normal query set, the application's cloud role was used from outside your account, or the application sits on a payment or authentication path) | Owner: Operations Lead (Application)

#When to run this

• A WAF or IDS signature fires on a request matching a published exploit, and other requests from the same source in the same window returned 2xx rather than 403.
• Access logs show successful requests to a URI, parameter or handler that does not exist in your build manifest.
• A file under the web root that is not in the deployment artefact — from file-integrity monitoring, a scheduled diff against the build, or a manual look after an advisory.
• EDR process lineage showing the application process spawning an interpreter: php-fpm → sh, java → bash, w3wp.exe → cmd.exe. This maps to Exploit Public Facing Application [T1190], and CISA lists web shells as a named indicator for that technique (CISA IR Playbook, Table 1).
• The web tier initiating outbound connections it has never made before, or resolving domains it has never resolved.
• GuardDuty UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS naming the web tier's instance role — the classic tail end of a server-side request forgery chain (GuardDuty IAM finding types).
• A vendor advisory, a CISA KEV addition, or a directive covering software you run internet-facing — particularly where the guidance requires a compromise assessment and not only a patch.
• Someone outside tells you: a hosting provider, a researcher, a customer, a payment processor, or law enforcement.

Not for: perimeter appliances — VPN concentrators, firewalls, load-balancer appliances, file-transfer boxes — which are Playbook 14.12, because their forensics and their vendor relationship work differently. Container and cluster compromise is 14.10. Availability loss without intrusion is 14.8. Takeover of a SaaS application you do not host is 14.3. Manipulation of an LLM or agent's behavior rather than its host is 14.11. A compromise that arrived through a dependency you shipped is 14.5, run in parallel. Once you can name records and data subjects, the notification workstream is 14.7. Chapter 10 owns the vulnerability management program this playbook fails over from; Chapter 9 owns the detections that should have caught it.

#What you are dealing with

Two different incidents wear the same clothes here, and you must decide early which one you are in. The first is a targeted attack on your application: someone found a flaw in code you wrote, and they came for you. The second, far more common in 2026, is that you were one of several thousand hosts a scanner walked past. An internet-wide scan is not a burglar casing your house. It is someone walking the whole street trying every door handle, and yours turned. The exploitation was indiscriminate; the triage of victims afterwards is not, and that is the part that hurts.

The numbers moved decisively in this direction. Vulnerability exploitation reached 31% of breaches in the 2026 DBIR, overtaking credential abuse for the first time in that report's nineteen-year history (SecurityWeek), and Mandiant has recorded exploits as the top initial infection vector for six consecutive years, at 32% (M-Trends 2026). VulnCheck's 1H-2026 measurement is the one to keep in your head when someone asks whether you have time: 23.43% of KEV entries showed evidence of exploitation on or before the day the CVE was published, and around 200 CVEs reached exploited status within 31 days (VulnCheck). Meanwhile only 26% of KEV vulnerabilities were fully remediated across 13,000 polled organizations, down from 38%, with median patching time rising to 43 days (Help Net Security). The window is closing and the response is slowing. The UK's NCSC makes the consequence concrete: three vulnerabilities — Ivanti Connect Secure CVE-2025-0282, Fortinet FortiManager CVE-2024-47575, and Microsoft SharePoint CVE-2025-53770 — accounted for 29 of its nationally significant incidents in a single reporting year (NCSC Annual Review 2025).

What the adversary wants is rarely the application. It is what the application is trusted to reach: the database account, the object store, the secrets in the process environment, and — on cloud-hosted web tiers — the instance role. A web application is the one component in your estate that is deliberately reachable by everyone on earth and deliberately holds credentials to your data. That combination is the whole business model.

And here is the mistake teams make, almost universally. They patch, confirm the scanner is clean, and close the ticket. Patching removes the door handle that turned. It does nothing whatsoever about the person already inside, because the web shell they dropped is served by your own application over ordinary HTTPS to an ordinary-looking path, and it does not care that the original flaw is fixed. CISA's own framing is that a vulnerability found to have been exploited is no longer a vulnerability ticket — it escalates immediately into incident response (CISA vulnerability response playbook). Patch. Then hunt. Both. Every time.

#Roles for this incident

Marking used below: `TIP-OFF = the adversary can observe this action. EVIDENCE` = this destroys or degrades evidence and must not run before capture.

#Phase 1 — Detection and Triage

# 1) Files under the web root modified since the last known-good deploy.
#    Substitute your real deployment timestamp, in UTC.
find /var/www -xdev -type f -newermt "2026-09-01 00:00:00" \
  -printf '%TY-%Tm-%TdT%TH:%TM:%TS  %p\n' | sort

# 2) mtime is attacker-controllable with `touch`; ctime is not settable directly.
#    Run this second pass whenever timestomping is plausible - it usually is.
find /var/www -xdev -type f -newerct "2026-09-01 00:00:00" \
  -printf '%CY-%Cm-%CdT%CH:%CM:%CS  %p\n' | sort

# 3) The strongest single check: diff the live tree against the artefact you
#    believe you deployed. Anything "Only in" the live tree is a candidate.
diff -r --brief /mnt/known-good-build /var/www/html

# 4) Package integrity on the host (RPM and dpkg systems respectively).
rpm -Va
dpkg --verify

# Find the first successful exploitation attempt in a combined-format access log.
# In that format: $1 source IP, $4 timestamp, $7 request URI, $9 status, $10 bytes sent.
# Confirm your own log_format before trusting the field positions.
awk '$7 ~ /<vulnerable-path>/ && $9 ~ /^[23]/ { print $4, $1, $7, $9, $10 }' \
  access.log | head -40

#Phase 2 — Containment

Sequence is the content of this phase. Capture volatile state, then break the vector at the edge, then cut the identity, then cut egress, and only then move the host out of service. Reverse the last two and the adversary watches their access die while their C2 channel is still open, which is exactly the window they use to burn what they have.

# Isolation security group swap - `--groups` replaces the instance's groups entirely
# and requires at least one group ID.
aws ec2 modify-instance-attribute --instance-id i-1234567890abcdef0 --groups sg-0isolation

# Force IMDSv2 and restrict the hop limit. `--http-endpoint` must be set when
# `--http-tokens` is set. Verify the MetadataNoToken metric reads zero first.
aws ec2 modify-instance-metadata-options \
    --instance-id i-1234567890abcdef0 \
    --http-tokens required \
    --http-put-response-hop-limit 1 \
    --http-endpoint enabled

// The inline policy the AWS console attaches as `AWSRevokeOlderSessions`.
// It denies sessions assumed before the timestamp plus roughly 30 seconds of
// propagation slack. Attaching it requires PutRolePolicy on the role, and it
// does NOT work for service-linked roles or IAM Identity Center permission sets.
{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition": {
      "DateLessThan": {"aws:TokenIssueTime": "2026-09-05T14:00:00Z"}
    }
  }
}

#Phase 3 — Eradication

Do not start this phase until CISA's three preconditions hold: all means of persistent access are accounted for, adversary activity is sufficiently contained, and all evidence has been collected (CISA IR playbook). It is an iterative gate, not a checkbox — if the hunt turns up a new artefact, you are back in Phase 1.

Accessed, or merely accessible. This is the determination that sets your severity, your notification obligation and your legal exposure, and it is the one teams answer with a feeling instead of evidence. Work it as three separate questions with three separate answers.

What could it reach? Answer this from configuration, and answer it today. It is the grants on the database account, the policies on the cloud role, the buckets and the API keys. It requires no logs and it defines the outer bound — the "accessible" set. Legal will want this number whether or not you can narrow it.

What did it do? Answer this from the application's data-access telemetry: database query or audit logs, object-store data-event logs, and application-level access records. This is where most organizations discover the hole. Cloud object-store data events are frequently opt-in — AWS states that by default, trails and event data stores log management events but not data events (CloudTrail concepts) — and database query logging is off in most production configurations for performance reasons. If it was off, say so in the record, in those words, and stop there. Absence of evidence in a source that was never collecting is not evidence of absence, and a report that blurs the two will not survive a regulator or a plaintiff.

How much left? When data-access logs are missing, the web tier's own access log is the fallback and it is better than nothing. Response byte counts distinguish a command result from a data set: a 2xx returning 300 bytes is a shell answering whoami; a series of 2xx responses returning tens of megabytes to the same client is data leaving the building. Pair that with egress volume from flow logs for the same window and you have a defensible upper bound even without query-level visibility.

# Total bytes returned to a suspect source IP, and the largest responses it received.
# Combined format: $1 source IP, $7 request URI, $9 status, $10 body bytes sent.
awk -v ip="203.0.113.7" '$1==ip { n++; sum += $10 } \
  END { printf "%d requests, %d bytes returned\n", n, sum }' access.log

awk -v ip="203.0.113.7" '$1==ip { print $10, $9, $7 }' access.log | sort -rn | head -25

#Phase 4 — Recovery

#Phase 5 — Post-Incident

#Decision points

#Communications and notification triggers

Exploitation of an application starts no regulatory clock by itself. What starts a clock is confirmed unauthorized access to data, and in this scenario that determination arrives through the database or the object store, not through the web tier. The trigger to escalate is Phase 3's accessed-versus-accessible work: the moment you can say a specific data set was read by an unauthorized principal, brief Legal Liaison and hand off to Playbook 14.7. Do not wait until you can count records — the clock does not.

Three paths here are easy to miss. If the application processes payment card data, contractual notification duties to your acquirer and the card brands typically run on far shorter timelines than statute, and they are triggered by suspected compromise rather than confirmed access. If the application is multi-tenant, your customers' data is in scope and their own regulators may be too. And in a mass-exploitation event, coordinate with the vendor and your sector ISAC before publishing anything: your independent disclosure can burn a coordinated timeline and tell other victims' attackers what defenders have found. Chapter 15 holds the notification decision tree and every regulatory deadline. Do not reconstruct them here and never commit to a deadline from memory.

#Automation notes

Automate freely. All of Phase 1's gathering: on an exploit-signature hit, automatically suspend log rotation, export the log window with hashes, snapshot the instance volumes, open the legal hold, run the web-root diff against the deployment artefact, pull the application's IAM policy and database grants, and post the whole package into the incident channel. Every one of those is reversible, evidence-producing and verifiable after the fact. Automating the snapshot is the highest-value play available here for the same reason it is in Playbook 14.10: it removes the time pressure that makes responders start deleting things.

Automate behind a human gate. WAF vector blocking in enforce mode, and deregistration from the load-balancer target group. Both are reversible and both cost latency or capacity rather than correctness when they fire on a false positive — but both are visible to the adversary and to your customers, so gate them on a named approver and rate-limit them. Require the automation to prove the block by replaying a request and reporting the status code, rather than reporting success on an API acknowledgement.

Never automate. Patching production, credential and session-key rotation, database credential changes, egress blocks that sever established connections, instance termination, and the accessed-versus-accessible determination. The last one deserves particular emphasis: the documented failure modes of agentic triage are overconfident closure backed by weak proof and hallucinated detail in investigation narratives, and a data-access determination is exactly the artefact where a confident-sounding wrong answer becomes a regulatory filing. Use AI to assemble the log timeline and to summarize the grant inventory. Have a human sign the conclusion. Chapter 17 has the gate design in full.

#Pitfalls

Takeaway: scope by build digest and target group, never by the hostname that happened to alert, and rebuild from the pipeline artefact onto fresh infrastructure rather than deleting the shell you found. If you cannot reproduce the host from source, write that down as an architecture finding with a date against it — it is the most valuable thing this incident will hand you.