Exploitation Verification

1. Prerequisites

• Suspected exploitation alert, report, or indicator
• Affected vulnerability, weakness, asset, service, endpoint, or workload identified
• Time window for suspected activity defined
• Access to relevant logs and telemetry
• Vulnerability or exploit context available

2. Step-by-Step Instructions

1. Define Verification Target

   • Record the vulnerability, weakness, asset, endpoint, service, workload, alert, indicator, and time window being verified.

2. Identify Expected Exploit Indicators

   • List expected exploit requests, payloads, commands, files, process activity, authentication events, errors, callbacks, or other known indicators.

3. Search for Attempt Evidence

   • Look for inbound requests, alerts, payloads, scans, probes, authentication attempts, or malformed inputs matching expected exploit behaviour.

4. Search for Success Evidence

   • Look for evidence that the exploit changed system state, created access, executed code, wrote files, created sessions, accessed data, changed privileges, or triggered callbacks.

5. Check Affected Asset State

   • Confirm whether the asset was vulnerable at the time of activity.
   • Review version, configuration, exposure, compensating controls, patch state, and reachability.

6. Check Control Outcomes

   • Determine whether WAF, EDR, IDS/IPS, application controls, authentication controls, or network controls blocked, allowed, or partially blocked the activity.

7. Eliminate Benign Explanations

   • Check for authorised testing, vulnerability scans, health checks, misconfigured clients, duplicate alerts, test traffic, or known false positives.

8. Classify Exploitation Status

   • Classify as:
     • No evidence of exploitation
     • Attempted exploitation only
     • Suspected successful exploitation
     • Confirmed successful exploitation
     • Ongoing exploitation
   • Assign a confidence level: low, medium, or high.

9. Record Supporting Evidence

   • Record the logs, alerts, timestamps, requests, payloads, controls, asset state, and reasoning supporting the classification.

10. Record Verification Output

    • Document final exploitation status, confidence level, affected asset, suspected vulnerability or weakness, evidence summary, assumptions, and unresolved questions.

3. Post-Action

• Preserve evidence supporting the verification decision.
• Attach verification status, confidence level, and supporting artifacts to the incident record.
• Document any evidence gaps or telemetry limitations.

Contributor

Vishal Thakur GitHub: https://github.com/malienist

Contributed to the Arcana Incident Response Documentation Framework.