From Security Operations
Use this skill when a security incident has been confirmed or is highly suspected and immediate first-response containment steps are needed. Covers standard containment sequences for the most common MSP incident classes — compromised account, malware/ransomware detection, business email compromise, and exposed credential — including what to do first, the correct order of operations, and which connected tool family (RMM, EDR, CIPP/Entra, PSA) handles each step.
How this skill is triggered — by the user, by Claude, or both
Slash command
/secops-pack:containment-playbooksWhen to use
When an incident is confirmed or strongly suspected and immediate first-response action is needed. Use when: contain this incident, isolate device, compromised account, malware detected, ransomware, exposed credential, what do I do first, containment steps, incident response, first response playbook, lock down this account.
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
The first thirty minutes after an incident is confirmed determine whether it
The first thirty minutes after an incident is confirmed determine whether it stays a single-endpoint or single-mailbox event or becomes a portfolio-wide one. This skill is the first-response sequence for the incident classes an MSP sees most often. It is deliberately ordered — containment before eradication, eradication before recovery, recovery before notification — because doing these out of order (for example, resetting a compromised password before revoking active sessions) leaves an attacker's live session valid even after the "fix."
This skill does not replace a full incident response plan or a client's own IR contract terms. It is the playbook for the first response actions a technician or agent takes the moment an incident class is identified, before a deeper investigation or a formal incident report is built (see Incident Timeline Builder for that phase).
Call conduit__search_tools before assuming which tool handles which step
below. A client with Datto RMM but no CIPP connection can still isolate a
device but cannot revoke M365 sessions through this pack — that step must be
flagged as unavailable and handed to whatever manual/console process the
MSP uses instead. Never silently skip a containment step; if the connector
for it isn't present, say so explicitly and name the fallback (manual
console action, PSA ticket note, or escalation).
| Order | Action | Tool family |
|---|---|---|
| 1 | Revoke all active sessions/refresh tokens for the account | CIPP / Entra (session revocation) |
| 2 | Disable the account (do not delete — preserves forensic state) | CIPP / Entra |
| 3 | Review and remove any inbox rules, forwarding rules, or delegate access created during the compromise window | CIPP / M365 mailbox rules |
| 4 | Reset the account password to a fresh, non-reused value | CIPP / Entra |
| 5 | Force MFA re-enrollment, invalidating any attacker-registered MFA method | CIPP / Entra |
| 6 | Check for lateral movement — other accounts with new sign-ins from the same source IP/ASN in the compromise window | CIPP audit logs / SIEM |
| 7 | Re-enable the account only after 1–5 are confirmed complete | CIPP / Entra |
| 8 | Document the timeline and notify the affected user and any downstream recipients of attacker-sent mail | PSA / documentation |
Order matters: reset the password (step 4) only after revoking sessions (step 1) — a password reset alone does not invalidate an already-issued session token.
| Order | Action | Tool family |
|---|---|---|
| 1 | Isolate the affected device from the network (network isolation, not shutdown — shutdown destroys volatile forensic evidence) | EDR (SentinelOne/Huntress) or RMM |
| 2 | Confirm isolation succeeded — device shows isolated/quarantined in the console | EDR |
| 3 | Check for the same file hash / indicator on other endpoints in the same tenant | EDR |
| 4 | If ransomware behavior is confirmed: check backup job status and last-known-good restore point immediately — do not wait for full eradication to check this | RMM / backup platform |
| 5 | Identify patient zero and initial access vector (phishing, exposed RDP, exploited service) where evidence allows | EDR / RMM / documentation |
| 6 | Run the EDR's remediation/rollback action if available; otherwise scope for reimage | EDR |
| 7 | Re-image or reissue credentials for any accounts that were active on the device during the infection window | RMM + CIPP/Entra |
| 8 | Hold the device off the network until a clean scan and patch baseline are confirmed | EDR / RMM |
Never skip step 4 for ransomware-classified events, even if eradication looks straightforward — backup viability is the single fact that most changes the client conversation, and it degrades the longer it's unchecked (some ransomware families delay backup-target encryption).
See BEC Response for the full detection and response sequence. In summary, the containment order is: revoke sessions → audit and remove forwarding/inbox rules → reset password → force MFA re-enrollment → identify and notify any recipients of attacker-sent financial-fraud email before the client's own outreach does.
| Order | Action | Tool family |
|---|---|---|
| 1 | Determine scope — is this a single account's password, or a shared/service account credential that touches multiple systems? | Documentation (IT Glue/Hudu) / PSA |
| 2 | Revoke active sessions for the affected account(s) | CIPP / Entra, or the relevant vendor console for non-M365 credentials |
| 3 | Rotate the credential everywhere it is used — check documentation for every system referencing it before declaring rotation complete | Documentation / CIPP / relevant vendor |
| 4 | If the credential had elevated or admin scope, review recent activity for signs of misuse before rotation (rotation can end an active session but won't retroactively reveal what already happened) | Audit logs (CIPP / EDR / SIEM) |
| 5 | Force MFA re-enrollment if the credential belongs to an MFA-protected account | CIPP / Entra |
| 6 | Update the credential's record in documentation and note the rotation date/reason | Documentation platform |
A credential found in a public breach dump or paste site should be treated as exposed even with no confirmed misuse — rotate on discovery, don't wait for evidence of use.
npx claudepluginhub wyre-technology/msp-claude-plugins --plugin secops-packGuides immediate response to security incidents including containment, evidence preservation, and escalation procedures. Covers NIST SP 800-61 lifecycle.
Develop containment strategies to isolate compromised systems, prevent lateral movement, and stop ongoing attacks.
Builds SOC incident response playbook for ransomware covering detection with SIEM queries, containment, eradication, and recovery phases aligned to NIST SP 800-61 and MITRE ATT&CK. For standardizing SOC procedures.