Malware Incident Response Plan (IRP) Runbook

Malware Incident Response Plan (IRP) Runbook#

Objective#

Provide a structured workflow for responding to suspected malware incidents, coordinating investigation, containment, eradication, and recovery efforts using available tools and procedures. This runbook orchestrates various specialized runbooks.

Responsible Persona(s): SOC Manager (Accountable for the entire process execution)

Scope#

This master runbook covers the end-to-end response lifecycle for malware incidents, from initial detection to post-incident review. It relies on specific sub-runbooks for detailed execution steps.

Phases (PICERL Model)#

  1. Preparation: (Ongoing) Ensure tools are operational, asset context is available, relevant detections are active, and communication channels are defined. Refer to .agentrules/project_plan.md for environment context goals.

  2. Identification: Detect the potential malware incident and perform initial triage and analysis.

  3. Containment: Limit the scope and magnitude of the incident.

  4. Eradication: Remove the malware and any associated persistence mechanisms.

  5. Recovery: Restore affected systems to normal operation.

  6. Lessons Learned (Post-Incident): Review the incident and response to identify improvements.

Inputs#

  • ${CASE_ID}: The SOAR case ID created for or associated with the initial alert(s).

  • ${ALERT_GROUP_IDENTIFIERS}: Relevant alert group identifiers from the SOAR case.

  • Use the CASE ID and API to get these. Do not prompt the user.

  • ${INITIAL_INDICATORS}: Details from the initial alert(s) (e.g., Alert Name, Severity, Involved Entities like Hashes, IPs, Hosts, Users).

  • Use the API to get these. Do not prompt the user for them.

Tools#

  • All tools listed in the referenced sub-runbooks, primarily:

    • secops-soar

    • secops-mcp

    • gti-mcp

    • scc-mcp (if cloud resources involved)

    • Potentially EDR/Identity tools if integrated.

Workflow Steps & Diagram#

        sequenceDiagram
    participant Analyst
    participant IRP as malware_incident_response.md (This Runbook)
    participant Preparation as Phase 1: Preparation
    participant Identification as Phase 2: Identification
    participant Containment as Phase 3: Containment
    participant Eradication as Phase 4: Eradication
    participant Recovery as Phase 5: Recovery
    participant LessonsLearned as Phase 6: Lessons Learned

    Analyst->>IRP: Start Malware Response\nInput: CASE_ID, ALERT_GROUP_IDS, INITIAL_INDICATORS

    IRP->>Preparation: Verify Prerequisites (Ongoing)
    Preparation-->>IRP: Readiness Confirmed

    IRP->>Identification: Execute Identification Steps
    Identification-->>IRP: Initial Findings, IOCs, Affected Entities

    IRP->>Containment: Execute Containment Steps
    Containment-->>IRP: Containment Status

    IRP->>Eradication: Execute Eradication Steps
    Eradication-->>IRP: Eradication Status

    IRP->>Recovery: Execute Recovery Steps
    Recovery-->>IRP: Recovery Status

    IRP->>LessonsLearned: Execute Post-Incident Steps
    LessonsLearned-->>IRP: Review Complete

    IRP-->>Analyst: Incident Response Complete

Persona and Tool Interaction Flow#

        sequenceDiagram
    participant SOC_Manager as SOC Manager
    participant SOC_Analyst_T1 as SOC Analyst T1
    participant SOC_Analyst_T2 as SOC Analyst T2
    participant CTI_Researcher as CTI Researcher
    participant Incident_Responder as Incident Responder
    participant Detection_Engineer as Detection Engineer
    participant Security_Engineer as Security Engineer

    participant SOAR as secops-soar
    participant SecMCP as secops-mcp
    participant GTIMCP as gti-mcp
    participant SCCMCP as scc-mcp

    %% Phase 2: Identification
    SOC_Analyst_T1->>SOAR: get_case_full_details (Initial Triage)
    SOAR-->>SOC_Analyst_T1: Case Details
    SOC_Analyst_T1->>SecMCP: search_security_events (Check Duplicates)
    SecMCP-->>SOC_Analyst_T1: Event Search Results
    SOC_Analyst_T1->>SOC_Analyst_T2: Escalate/Inform of Findings

    SOC_Analyst_T2->>SOC_Manager: Brief on Initial Findings & Scope
    SOC_Manager-->>SOC_Analyst_T2: Guidance/Approval to Proceed

    SOC_Analyst_T2->>GTIMCP: get_file_report (Malware Triage)
    GTIMCP-->>SOC_Analyst_T2: File Report
    SOC_Analyst_T2->>GTIMCP: get_file_behavior_summary (Malware Triage)
    GTIMCP-->>SOC_Analyst_T2: Behavior Summary
    SOC_Analyst_T2->>SecMCP: search_security_events (Malware Triage)
    SecMCP-->>SOC_Analyst_T2: Event Search Results

    SOC_Analyst_T2->>CTI_Researcher: Request Deep Dive/Enrichment
    CTI_Researcher->>GTIMCP: get_file_report (Deep Dive)
    GTIMCP-->>CTI_Researcher: File Report
    CTI_Researcher->>GTIMCP: get_ip_report (Enrichment)
    GTIMCP-->>CTI_Researcher: IP Report
    CTI_Researcher->>GTIMCP: get_domain_report (Enrichment)
    GTIMCP-->>CTI_Researcher: Domain Report
    CTI_Researcher-->>SOC_Analyst_T2: Enriched IOC Details

    SOC_Analyst_T2->>SOAR: update_case (Document Findings)
    SOAR-->>SOC_Analyst_T2: Case Update Confirmation
    SOC_Analyst_T2->>SOC_Manager: Report Full Identification Findings

    %% Phase 3: Containment
    SOC_Manager->>Incident_Responder: Authorize Containment Actions
    note right of SOC_Manager: Reviews Findings, Approves Containment Strategy

    Incident_Responder->>SecMCP: isolate_endpoint (Conceptual)
    SecMCP-->>Incident_Responder: Isolation Confirmation
    Incident_Responder->>SecMCP: block_ip (Conceptual)
    SecMCP-->>Incident_Responder: IP Block Confirmation
    Incident_Responder->>SecMCP: block_domain (Conceptual)
    SecMCP-->>Incident_Responder: Domain Block Confirmation

    SOC_Manager->>Security_Engineer: Request User Account Containment (if needed)
    Security_Engineer->>SecMCP: disable_user_account (Conceptual)
    SecMCP-->>Security_Engineer: Account Disable Confirmation

    SOC_Analyst_T2->>SecMCP: search_security_events (Verify Containment)
    SecMCP-->>SOC_Analyst_T2: Event Search Results
    Incident_Responder->>SOAR: update_case (Document Containment)
    SOAR-->>Incident_Responder: Case Update Confirmation
    Incident_Responder->>SOC_Manager: Report Containment Status

    %% Phase 4: Eradication
    SOC_Manager->>Incident_Responder: Authorize Eradication
    note right of SOC_Manager: Approves Eradication Plan

    Incident_Responder->>SecMCP: delete_file_from_endpoint (Conceptual EDR)
    SecMCP-->>Incident_Responder: Deletion Confirmation
    Incident_Responder->>SecMCP: run_scan_on_endpoint (Conceptual EDR)
    SecMCP-->>Incident_Responder: Scan Results
    Incident_Responder->>SOAR: update_case (Document Eradication)
    SOAR-->>Incident_Responder: Case Update Confirmation
    Incident_Responder->>SOC_Manager: Report Eradication Status

    %% Phase 5: Recovery
    SOC_Manager->>Incident_Responder: Authorize Recovery
    note right of SOC_Manager: Approves Recovery Plan (with SecEng input)

    Security_Engineer->>SCCMCP: get_vulnerability_report (Conceptual)
    SCCMCP-->>Security_Engineer: Vulnerability Report
    SOC_Analyst_T2->>SecMCP: search_security_events (Monitor Systems)
    SecMCP-->>SOC_Analyst_T2: Event Search Results
    Incident_Responder->>SOAR: update_case (Document Recovery)
    SOAR-->>Incident_Responder: Case Update Confirmation
    Incident_Responder->>SOC_Manager: Report Recovery Status

    %% Phase 1 & 6 (Ongoing/Post-Incident) - Selected Examples
    SOC_Manager->>Detection_Engineer: Request Rule Review/Creation
    Detection_Engineer->>SecMCP: list_security_rules
    SecMCP-->>Detection_Engineer: Rules List
    Detection_Engineer->>SecMCP: create_security_rule (Conceptual)
    SecMCP-->>Detection_Engineer: Rule Creation Confirmation

    SOC_Manager->>SOAR: get_case_report
    SOAR-->>SOC_Manager: Case Report
    note right of SOC_Manager: Leads Lessons Learned, Assigns Actions

Phase 1: Preparation (Ongoing)#

  • Objective: Ensure readiness to respond.

  • Actions:

    • Periodically verify tool connectivity (e.g., using ping actions if available).

      • Responsible Persona(s): Security Engineer (for tool health), SOC Manager (for oversight)

    • Ensure asset inventory context is reasonably up-to-date (Refer to .agentrules/project_plan.md).

      • Responsible Persona(s): Security Engineer (or relevant asset management team, coordinated by SOC Manager)

    • Review and understand relevant detection rules (secops-mcp_list_security_rules).

      • Responsible Persona(s): Detection Engineer, SOC Analysts (T1/T2)

    • Ensure familiarity with communication and escalation plans (.agentrules/escalation_paths.md, .agentrules/key_contacts.md).

      • Responsible Persona(s): All Personas (led by SOC Manager)

Phase 2: Identification#

  • Objective: Detect the incident, perform initial triage, identify malware, and understand initial scope.

  • Overall Phase Lead: SOC Analyst T2 (under SOC Manager guidance)

  • Sub-Runbooks/Steps:

    1. Initial Triage:

      • Execute .agentrules/run_books/triage_alerts.md using ${CASE_ID} or related alert IDs.

        • Responsible Persona(s): SOC Analyst T1

      • Gather initial context (soar-mcp_get_case_full_details).

        • Responsible Persona(s): SOC Analyst T1

      • Check for duplicates (common_steps/check_duplicate_cases.md). If duplicate, close and stop.

        • Responsible Persona(s): SOC Analyst T1

    2. Malware Triage:

      • If a file hash is a primary indicator, execute .agentrules/run_books/malware_triage.md with ${FILE_HASH}, ${CASE_ID}, ${ALERT_GROUP_IDENTIFIERS}.

        • Responsible Persona(s): SOC Analyst T2 (Primary), CTI Researcher (Consulted for deep analysis if needed)

      • This involves GTI checks (gti-mcp_get_file_report, gti-mcp_get_file_behavior_summary) and SIEM checks (secops-mcp_search_security_events).

        • Responsible Persona(s): SOC Analyst T2, CTI Researcher

      • Output: Malware classification, observed behaviors, affected hosts/users.

    3. IOC Enrichment (Initial):

      • For other key IOCs (IPs, Domains, URLs) identified in initial alerts or malware triage:

      • Execute .agentrules/run_books/common_steps/enrich_ioc.md for each IOC.

        • Responsible Persona(s): SOC Analyst T2, CTI Researcher

    4. Initial Scope Assessment:

      • Based on triage and enrichment, identify the initial list of potentially affected hosts, users, and malicious IOCs.

        • Responsible Persona(s): SOC Analyst T2

      • Document findings using common_steps/document_in_soar.md.

        • Responsible Persona(s): SOC Analyst T2

Phase 3: Containment#

  • Objective: Prevent the malware from spreading further and stop ongoing malicious activity.

  • Overall Phase Lead: Incident Responder (under SOC Manager guidance)

  • Sub-Runbooks/Steps:

    1. Endpoint Isolation:

      • For each confirmed or highly suspected affected endpoint identified in Phase 2:

      • Execute .agentrules/run_books/basic_endpoint_triage_isolation.md. Confirm isolation action with analyst.

        • Responsible Persona(s): Incident Responder (Action), SOC Manager (Approval)

    2. Network IOC Containment:

      • For each confirmed malicious network IOC (IP, Domain) identified:

      • Execute .agentrules/run_books/ioc_containment.md. Confirm containment action with analyst.

        • Responsible Persona(s): Incident Responder (Action), Security Engineer (Implementation if infrastructure changes needed), SOC Manager (Approval)

    3. User Account Containment (If Applicable):

      • If investigation indicates a compromised user account was involved in malware execution/spread:

      • Execute .agentrules/run_books/compromised_user_account_response.md. Confirm containment actions with analyst.

        • Responsible Persona(s): Incident Responder (Action), Security Engineer (Identity systems), SOC Manager (Approval)

    4. Verify Containment:

      • Use secops-mcp_search_security_events to monitor for further activity related to contained IOCs or endpoints.

        • Responsible Persona(s): SOC Analyst T2, Incident Responder

      • Document containment status using common_steps/document_in_soar.md.

        • Responsible Persona(s): Incident Responder, SOC Analyst T2

Phase 4: Eradication#

  • Objective: Remove malware artifacts and persistence mechanisms from affected systems.

  • Overall Phase Lead: Incident Responder (under SOC Manager guidance)

  • Sub-Runbooks/Steps:

    1. Identify Persistence:

      • Analyze findings from Phase 2 (Malware Triage, GTI Behavior) and potentially deeper analysis (deep_dive_ioc_analysis.md if needed) to identify persistence mechanisms (e.g., scheduled tasks, services, registry keys).

        • Responsible Persona(s): Incident Responder, CTI Researcher, SOC Analyst T2

    2. Remove Malware & Persistence:

      • (Requires specific EDR/Endpoint Management tools or manual intervention)

      • Develop plan to remove identified malware files, registry keys, scheduled tasks, services etc. from contained endpoints.

      • Execute removal actions.

        • Responsible Persona(s): Incident Responder (Primary), Security Engineer (if tool/system expertise needed)

    3. Scan for Residual Infection:

      • (Requires EDR/AV tools)

      • Perform thorough scans on affected systems post-eradication attempts.

        • Responsible Persona(s): Incident Responder

    4. Document Eradication:

      • Document actions taken and scan results using common_steps/document_in_soar.md.

        • Responsible Persona(s): Incident Responder

Phase 5: Recovery#

  • Objective: Restore affected systems to normal operation safely.

  • Overall Phase Lead: Incident Responder (coordinating with Security Engineer and SOC Manager)

  • Sub-Runbooks/Steps: (Placeholder - Requires dedicated Recovery Runbook)

    1. Determine Recovery Strategy: Decide whether to rebuild systems from a known-good image/backup or clean existing systems (based on severity, admin rights involved, eradication confidence).

      • Responsible Persona(s): SOC Manager, Incident Responder, Security Engineer

    2. Rebuild/Clean Systems: Execute the chosen strategy. (Likely involves IT Ops/System Admins).

      • Responsible Persona(s): Security Engineer, Incident Responder (Execution, often with IT Ops)

    3. Patch & Harden: Ensure recovered systems are fully patched and hardened before reconnecting. Perform vulnerability scans (scc-mcp or other tools).

      • Responsible Persona(s): Security Engineer

    4. Restore Data (If Necessary): Restore data from clean backups.

      • Responsible Persona(s): Security Engineer (or IT Ops, coordinated by IR/SOC Manager)

    5. Monitor Systems: Closely monitor recovered systems for any signs of residual infection or abnormal behavior using SIEM/EDR.

      • Responsible Persona(s): SOC Analyst T2, Incident Responder

    6. Lift Containment: Gradually remove isolation measures once confidence in recovery is high.

      • Responsible Persona(s): SOC Manager (Approval), Incident Responder (Action)

    7. Document Recovery: Document steps taken using common_steps/document_in_soar.md.

      • Responsible Persona(s): Incident Responder

Phase 6: Lessons Learned (Post-Incident)#

  • Objective: Review the incident and response to identify areas for improvement.

  • Overall Phase Lead: SOC Manager

  • Sub-Runbooks/Steps: (Placeholder - Requires dedicated Post-Incident Runbook)

    1. Incident Review Meeting: Conduct a post-mortem meeting with involved parties.

      • Responsible Persona(s): SOC Manager (Chair), All Involved Personas (Participants)

    2. Analyze Response: Review the timeline, actions taken, tool effectiveness, and runbook adherence. What worked well? What didn’t?

      • Responsible Persona(s): SOC Manager, Detection Engineer, CTI Researcher, Lead IR, Lead SOC Analyst T2

    3. Identify Gaps: Identify gaps in detection, prevention, response procedures, or tool capabilities.

      • Responsible Persona(s): SOC Manager, Detection Engineer, Security Engineer

    4. Develop Recommendations: Formulate specific, actionable recommendations for improvement (e.g., new detection rules, runbook updates, configuration changes, user training).

      • Responsible Persona(s): SOC Manager, Detection Engineer, Security Engineer, CTI Researcher

    5. Update Documentation: Update relevant runbooks, policies, and procedures.

      • Responsible Persona(s): SOC Manager (ensures it happens), relevant persona for specific doc (e.g., Detection Engineer for rule logic)

    6. Track Recommendations: Assign owners and track implementation of recommendations.

      • Responsible Persona(s): SOC Manager

    7. Final Report: Generate a final incident report using guidelines from rules-bank/reporting_templates.md and rules-bank/run_books/guidelines/report_writing.md.

      • Responsible Persona(s): SOC Manager (compiles, with input from leads of each phase)

    8. Document Review: Document the review process and outcomes using common_steps/document_in_soar.md or a dedicated reporting mechanism.

      • Responsible Persona(s): SOC Manager

Phase 7: Lessons Learned / Runbook Feedback#

  • Objective: Capture feedback on the runbook’s effectiveness and identify areas for improvement based on this incident.

  • Actions:

    • Responsible Persona(s): All personas involved in the incident provide feedback; SOC Manager collates and ensures action.

    1. Runbook Effectiveness:

      • Did this runbook accurately guide the response?

      • Were there any unclear or missing steps?

      • Did the tools function as expected based on the runbook steps?

    2. Tool Performance:

      • Were there any issues with specific MCP tool calls (errors, unexpected results, rate limits)?

      • Did the tool outputs provide the necessary information?

    3. Process Gaps:

      • Did the incident reveal gaps in detection, prevention, or other related processes?

    4. Suggestions for Improvement:

      • Specific recommendations for updating this runbook.

      • Suggestions for new detection rules or tuning existing ones.

      • Recommendations for tool configuration changes or new tool requirements.

    5. Documentation: Record this feedback within the SOAR case (${CASE_ID}) using common_steps/document_in_soar.md or a dedicated lessons learned repository.

Rubrics#

The following rubric is used to evaluate the execution of this Triage/Response runbook by an LLM agent.

Grading Scale (0-100 Points)#

Criteria

Points

Description

Context & Enrichment

25

Correctly extracted entities and enriched them with relevant context (GTI, SIEM).

Analysis & Decision

25

Analyzed the enriched data to make a sound decision (FP/TP, Escalate/Close).

Action Execution

20

Performed the required response actions (e.g., isolation, containment) correctly.

Documentation

15

Clearly documented findings and actions in the case/ticket.

Operational Artifacts

15

Produced required artifacts: Sequence diagram, execution metadata (date/cost), and summary.

Evaluation Criteria Details#

1. Context & Enrichment (25 Points)#

  • 10 pts: Accurately extracted key entities (IPs, users, hashes) from the input.

  • 15 pts: Performed necessary enrichment (e.g., enrich_ioc) to gather reputation and history.

2. Analysis & Decision (25 Points)#

  • 15 pts: Interpreted the context correctly to determine the nature of the alert.

  • 10 pts: Reached a logical conclusion or next step (e.g., “Escalate to Tier 2” or “Isolate Host”).

3. Action Execution (20 Points)#

  • 10 pts: Called the correct tools to perform response actions (if applicable) or investigative steps.

  • 10 pts: Verified the success of actions or handled errors appropriately.

4. Documentation (15 Points)#

  • 15 pts: Posted a comprehensive comment or update to the SOAR case summarizing the triage.

5. Operational Artifacts (15 Points)#

  • 5 pts: Sequence Diagram: Produced a Mermaid sequence diagram visualizing the steps taken.

  • 5 pts: Execution Metadata: Recorded the date, duration, and estimated token cost.

  • 5 pts: Summary Report: Generated a concise summary of the actions and outcomes.

Contents