While partnering with the DevOps group on eliminating XML External Entity (XXE) bugs, I also built a detection playbook to catch real-world exploitation. Internal services often run with elevated permissions, so even a low-volume XXE probe can give an attacker high-impact secrets. Below is the stack we assembled to watch for abuse without drowning the SOC in false positives.
Telemetry sources. We forward the reverse proxy logs, application structured logs, Falco alerts, and AWS CloudTrail events into our SIEM. XXE attempts typically include three telltale signs: <!DOCTYPE declarations, outbound calls to the metadata service (169.254.169.254), and errors linked to unexpected entity expansion. Capturing all three lets us correlate attempts to a specific service or user.
Detection logic. The first rule flags any XML payload that contains both SYSTEM and file:// or http://. A second rule watches the network layer for internal workloads requesting metadata endpoints or sensitive files over NFS shortly after XML uploads. We also enriched events with service owner metadata so the on-call engineer immediately knows who to page.
Response workflow. When a rule fires, an Automation Runbook creates a case, quarantines the offending pod by adding a network policy, and instructs responders to rotate credentials exposed during testing. We follow up with a lightweight post-incident review that feeds straight into secure coding office hours.
If you have XML anywhere in your stack, treat XXE as both an engineering and detection problem. Eliminate the bug where you can, but keep your sensors sharp—attackers still lean on this technique because it easily bypasses legacy allowlists.