Detecting Unpatched Web Application Exploitation: Sentinel and GuardDuty Detections

Retrospective: this article looks back at events from September 2017, written in 2026 with the benefit of hindsight.

Exploitation of public-facing web applications is one of the most common ways attackers get in. Detecting exploitation attempts — and especially successful ones — on cloud-hosted applications gives you a chance to respond before data leaves.

Signals worth watching

• Web application firewall alerts for injection, deserialization or remote code execution patterns.
• Web server processes launching shells or unusual child processes.
• New outbound connections from web servers to unfamiliar destinations.
• Unusual data volumes leaving application or database servers.
• Requests targeting known vulnerable paths shortly after a new vulnerability is published.

Where the data lives

• WAF logs: Azure Application Gateway or Front Door WAF, AWS WAF.
• Endpoint telemetry: Defender for Endpoint or Defender for Servers on application hosts.
• Network data: VPC Flow Logs or Azure NSG flow logs.
• GuardDuty findings for EC2 instances communicating with known malicious infrastructure.

A starting query

Web server processes spawning command shells are a strong signal on Windows and Linux hosts:

DeviceProcessEvents
| where InitiatingProcessFileName in~ ("w3wp.exe", "java", "httpd", "nginx", "tomcat9")
| where FileName in~ ("cmd.exe", "powershell.exe", "sh", "bash")
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine

Response

1. Isolate the affected host or remove it from the load balancer.
2. Preserve logs and a snapshot for investigation.
3. Determine what data and credentials the application could reach and rotate those credentials.
4. Patch, then check for persistence such as web shells before returning the host to service.