ArcanaIncident-response documentationBrowse the feedTemplates
Back to feed
Playbook
PB-011

Suspicious Execution

1. Purpose & Scope

  • Purpose:

    This playbook defines the response workflow for suspicious process, command-line, script, binary, or interpreter execution. It helps responders validate whether activity is authorised, malicious, or part of a broader incident such as malware, privilege escalation, lateral movement, account takeover, cloud compromise, or data exfiltration.

  • Scope:

    Applies to suspicious execution on endpoints, servers, cloud workloads, containers, virtual machines, administrative hosts, and user workstations. Includes LOLBin abuse, encoded or obfuscated commands, script execution, suspicious parent-child processes, unknown binaries, EDR behavioural detections, and unauthorised administrative tooling.

2. Incident Identification & Criteria

Incident Type: Suspicious Execution

Trigger Conditions:

Initiate this playbook when any of the following occur:

  • Suspicious process execution or EDR behavioural alert
  • Encoded, obfuscated, or high-risk command-line activity
  • PowerShell, bash, Python, JavaScript, VBScript, HTA, or batch execution from unusual context
  • LOLBin abuse such as suspicious PowerShell, rundll32, regsvr32, mshta, wmic, certutil, bitsadmin, schtasks, cscript, or wscript activity
  • Office, browser, email client, archive utility, or PDF reader spawning a shell, interpreter, or downloader
  • Unknown, unsigned, or newly dropped binary execution
  • Execution from temporary directories, user profile paths, network shares, removable media, or cloud sync folders
  • Process behaviour indicating persistence, credential theft, lateral movement, discovery, staging, or exfiltration

Severity Levels:

SeverityDescription
Sev 3Suspicious execution requiring validation; no confirmed malicious outcome
Sev 2Confirmed unauthorised or malicious execution on a single non-critical endpoint with limited impact
Sev 1Execution linked to credential theft, persistence, privilege escalation, lateral movement, data staging, or a critical asset
Sev 0Widespread malicious execution, active propagation, ransomware behaviour, or enterprise-wide compromise

3. Roles & Responsibilities

  • Incident Commander: Coordinates response, sets severity, approves containment, and manages escalation.
  • Incident Responder / Forensic Analyst: Validates execution activity, analyses command lines and process trees, scopes affected assets, and preserves evidence.
  • Communications Lead: Coordinates internal updates and affected-user communications.
  • Other Roles:
    • Endpoint / Platform Team: Supports host isolation, log collection, rebuild, and endpoint control validation.
    • Identity & Access Team: Supports account containment if execution indicates credential or token theft.
    • Network Team: Supports outbound blocking or segmentation when C2, download, exfiltration, or lateral movement is identified.
    • Cloud Security / Platform Team: Supports cloud workload evidence collection and isolation when suspicious execution occurs in cloud-hosted infrastructure.
    • Application / Service Owners: Validate business purpose and support recovery where execution occurred in production systems.

4. Initial Actions

  • Immediate Steps:

    • Triage the alert, affected host, user context, process, parent process, command line, file hash, and detection source.
    • Determine whether the process is still running, whether child processes exist, and whether network activity is active.

    Decision Point:

    • If execution is approved and expected โ†’ document rationale and close.
    • If malicious, unauthorised, or unresolved โ†’ continue investigation and contain if active risk exists.

    Warning: Do not assume execution is benign because the binary is signed, the command completed successfully, the user appears to have initiated it, or antivirus did not alert.

5. Investigation & Analysis

6. Containment, Eradication & Recovery

7. Communication & Escalation

8. Post-Incident Activities

  • Lessons Learned:

    • Conduct a Post-Incident Review (PIR)
    • Document what worked, what didn't, and what needs improvement
  • Documentation Updates:

    • Update this playbook, linked runbooks, detection content, allowlists, administrative tooling guidance, and endpoint hardening guidance where required.

9. References & Linked Resources

10. Appendices

Contributor

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

Contributed to the Arcana Incident Response Documentation Framework.