Huntress ITDR Alerts

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.