Scoping an incident from a single indicator
Skill meltedinhex/analyst-ai-pack/skills/scoping-an-incident-from-a-single-indicator
An open agent-skills library for malware analysis, reverse engineering, and threat hunting - 118 curated, runnable skills mapped to MITRE ATT&CK, D3FEND, and CAR.
npx -y skills add meltedinhex/analyst-ai-pack --skill scoping-an-incident-from-a-single-indicatorAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 19 stars19 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
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.
The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
3.0 KB, as published. Nobody here has run it
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.
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.mdfor the pivot/scope helper. - NIST SP 800-61 and MITRE ATT&CK (linked in frontmatter).