You are working a Huntress identity (ITDR) report. security-alert-response owns routing,
impossible-travel-runbook owns the sign-in verification ladder; this skill adds how Huntress
packages and remediates. You have no Huntress console access — approving remediation, dismissing a
report, and tenant-admin work like removing OAuth consent are technician steps you direct and
record, never take or invent.
1. Parse the report: severity (roughly Low/High/Critical), identity (UPN), Microsoft 365 tenant,
indicator detail (sign-in IP/location/ISP, application ID and consent scopes for a rogue app,
the rule's conditions and actions for a rule anomaly), timestamps, and the remediation section:
what Huntress recommends or already did. Route on the tenant and UPN fields — reports land on a
shared intake mailbox — and flag for a human rather than reassign on low confidence.
2. Separate contained-already from needs-action: the report says whether Huntress already isolated
the identity (sign-in disabled, sessions revoked) or is waiting on MSP approval. Don't re-plan
containment that happened, or assume containment only recommended.
3. Branch by alert family:
- Unwanted access or suspicious login — run the verification ladder: egress plausibility from
the client's documentation, prior tickets for this user over ~90 days, then the user on a
number on file, never contact details from the ticket or the compromised mailbox.
- Rogue app or malicious OAuth consent — the consent is the vector: who consented, when, what
scopes; mail read/write are the dangerous ones. A user confirming they clicked approve
supports the malicious verdict, not the benign one.
- Rule anomaly — a rule that forwards, deletes, or diverts security-relevant mail is attacker
cleanup until disproven.
4. Drive the approval flow: the decision is the technician's in the portal, so assemble the
evidence, recommend with reasoning, and record who approved what and when. Never approve a
dismissal (report marked expected or benign) without the same evidence bar as closing the
ticket — a dismissed true positive silently disappears. Confirmed compromise branches to
compromised-account-containment for what sits outside Huntress's scope: password reset, MFA
re-registration, app sessions.
5. Note the decision, not just the action: severity, evidence, verification outcome, Huntress's
actions versus the tech's; classify per soc-classification-tree. Huntress "remediated" is not
"case closed" — scope-check mail rules, OAuth grants, and MFA methods before closing.
Client-facing wording stays factual — "investigated and contained," never "hacked"
(defensive-writing-standard).
When in doubt, approve containment — a falsely disabled sign-in is cheap to undo, a missed
takeover is not. Without documentation, egress ranges are unknown.
Magic Library