Detect application or system exploitation by looking for crash patterns, abnormal process behaviour, memory corruption symptoms, and unexpected child processes after a vulnerable service or application receives input. Monitor for web requests, file uploads, or network traffic that precede instability or command execution. Prioritise exposed services and recently patched assets.
What exploitation attempts usually leave behind
Exploitation rarely looks like a single perfect indicator. It usually leaves a pattern: the target service becomes unstable after receiving crafted input, the process crashes or restarts, and adjacent activity suddenly changes. Security teams should treat those symptoms as correlated evidence, not as isolated noise, especially when they occur on internet-facing or recently patched systems.
The most useful starting point is to connect the symptom to the trigger. If a web request, file upload, API call, or network packet is followed by a crash, a memory fault, a shell launch, or a new child process, that sequence is materially more suspicious than a crash with no preceding input. That is why defenders often pair application telemetry with host process data and network context rather than relying on one log source alone. MITRE ATT&CK Enterprise Matrix remains a strong reference for mapping those post-exploitation behaviours to observable techniques such as process creation, injection, and credential access.
Which telemetry is most likely to catch exploitation in progress
Crash signatures, exception bursts, out-of-bounds access, and memory corruption symptoms are valuable because they often appear at the point where an exploit is trying to bend application logic into arbitrary code execution or denial of service. On the host, look for abnormal process trees, unexpected command interpreters, odd parent-child relationships, privilege changes, and executables launching from unusual paths. On the network, look for bursts of requests that are abnormal for the service, especially when they precede instability or remote command execution.
Monitoring becomes more effective when teams baseline normal behaviour for each exposed service. A reverse proxy, upload portal, and database-backed application all fail differently, so a single “anomaly” rule is usually too blunt. A better approach is to watch for changes in frequency, sequence, and state, such as repeated crashes after the same endpoint is hit, unexpected outbound connections after a request, or a service that begins spawning helper processes it never normally uses. CISA Known Exploited Vulnerabilities Catalog is useful here because it helps teams focus monitoring and hunting on vulnerabilities with confirmed active exploitation.
Application teams should also correlate these alerts with patch state and exposure. Systems that are internet-facing, recently changed, or still awaiting remediation deserve faster triage than internal assets with no exploit path. If a service was just patched and then begins crashing in a way that resembles prior exploitation patterns, that can indicate an attempt to validate exploitability before the attacker escalates further.
How to separate a bad crash from a real exploitation attempt
The key distinction is whether the crash or instability is explainable by normal defects alone, or whether it is paired with signs of malicious control. An exploit attempt often produces a chain: crafted input, abnormal parsing or corruption, service degradation, and then unexpected action such as a child process, file write, or outbound connection. Benign bugs usually stop at the crash. Exploitation attempts often continue into execution or persistence.
That is why confirmation should include both application and host evidence. Review the exact input that preceded the failure, examine the process tree around the event, and check whether the service account, worker process, or container runtime did anything outside its usual profile. When the signal is strong, supplement it with memory dumps, EDR telemetry, and logs from the load balancer or WAF. NIST National Vulnerability Database helps anchor this investigation to the vulnerable product and the known exposure profile, while FIRST EPSS helps teams prioritise which flaws are more likely to be exploited in the wild.
Risk and Threat Considerations
Exploitation attempts are dangerous because the first visible symptom may be the point at which the attacker is already close to code execution, privilege escalation, or service takeover. A crash alone can be noisy, but a crash followed by new process creation, abnormal child processes, or outbound traffic often means the target is being actively shaped by hostile input.
Failure mechanism: The attacker sends input that triggers parsing errors, memory corruption, unsafe deserialisation, or logic abuse, then watches for instability, code execution, or a post-exploit process chain that confirms success.
Impact: The result can range from denial of service to remote code execution, data access, lateral movement, or further compromise of the exposed service and its dependencies.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Exploit chains often end in unexpected process execution after crafted input. |
| Recommendation — Map suspicious post-crash process creation to ATT&CK and hunt for execution techniques. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Security Events | Detecting exploitation depends on continuous monitoring of process and network events. |
| ID.RA-01 — Asset Vulnerabilities Are Identified and Recorded | Prioritisation depends on knowing which exposed assets are vulnerable and in scope. | |
| Recommendation — Monitor exposed services for crash-after-input patterns and abnormal child processes. Prioritise monitoring and response for exposed systems with known or suspected vulnerabilities. | ||
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | System monitoring is needed to detect exploitation indicators across host and application telemetry. |
| Recommendation — Correlate application crashes, process anomalies, and network activity under SI-4. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Logs are required to reconstruct the sequence from input to crash to execution. |
| Recommendation — Collect and review logs that show request, crash, and process-creation sequences. | ||
Practitioner Guidance
What to prioritise: Triage exposed services first, then recently patched assets, then any system that shows a repeatable crash-after-input pattern. Those are the places where exploitation attempts are most likely to be both observable and actionable.
What to verify: Confirm whether the suspected event includes a clear trigger, a process-level symptom, and a downstream action such as child process creation, command execution, or suspicious network egress. If you only have a crash with no follow-on activity, treat it as a weaker signal until more telemetry arrives.
Practitioner takeaway: The best exploitation detection is sequence-based, not signature-based, because the attacker’s input, the crash, and the post-crash behaviour together tell you far more than any one alert alone.