SECURITY REVIEW
Not yet assessed
Review the original instructions and requested permissions before installing.
No security review is available for this catalog entry yet.
Community / AGENT SKILL
scoping-an-incident-from-a-single-indicator
0
Expands one indicator into the full scope of an incident: pivoting across data sources to find related hosts, accounts, and infrastructure, building a timeline, and bounding what is and is not affected. Activates for requests to scope an incident, pivot from a single IOC, or determine the blast radius of a detection.
Understand the trade-offs.
SKILL QUALITY
Not yet assessed
How clearly the skill guides your agent, how complete its workflow is, and how you can check the outcome.
No quality assessment is available for this catalog entry yet.
The full skill.
Original instructions from the publisher’s SKILL.md
# Scoping an Incident from a Single Indicator ## When to Use - A detection fired on one indicator (a hash, IP, domain, or account) and you must find the full extent of the activity. - You need to bound the incident — which hosts, accounts, and infrastructure are involved — before containment. - You are building an investigative timeline from a single starting point. **Do not use** premature containment on the first indicator alone — acting before scoping can tip off the adversary and leave footholds you have not yet found. ## Prerequisites - Access to relevant data sources (EDR, proxy, DNS, auth logs) and the pivoting/enrichment skills. ## Workflow ### Step 1: Characterize the seed indicator Establish what the indicator is, when it was first/last seen, and on which host/account it appeared. ### Step 2: Pivot to related artifacts Expand outward: the file's other hosts, the IP's other connections, the account's other logons, the domain's other resolvers. Each pivot yields new indicators to pivot again. ```bash python scripts/analyst.py scope events.json --seed <sha256-or-ip> ``` ### Step 3: Build the timeline Order all discovered events chronologically to reconstruct the activity and find the earliest sign (candidate patient zero / initial access). ### Step 4: Bound the scope Define affected vs. unaffected explicitly: list involved hosts/accounts/infrastructure and the evidence for inclusion, and note what was checked and cleared. ### Step 5: Hand off to containment Produce the scoped picture (entities, timeline, indicators) so containment is coordinated and complete rather than piecemeal. ## Validation - Every included entity has explicit evidence tying it to the incident. - The timeline has a defensible earliest event (initial access candidate). - Cleared entities are documented, so scope is bounded, not open-ended. ## Pitfalls - Containing the first host before pivoting, alerting the adversary and missing other footholds. - Pivoting only one hop and missing second-order related entities. - No timeline, so initial access and dwell time stay unknown. ## References - See [`references/api-reference.md`](references/api-reference.md) for the pivot/scope helper. - NIST SP 800-61 and MITRE ATT&CK (linked in frontmatter).