> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Huntress ITDR Alerts

> Work Huntress ITDR identity reports: unwanted access, rogue apps, mail-rule anomalies. Verify with the user and drive the remediation-approval flow closed.

<Info>
  **Category:** Vendor Runbooks · [View source ↗](https://github.com/Thread-Magic/super-magic-skills/blob/main/skills/vendor-runbooks/huntress-itdr-alerts/SKILL.md)
</Info>

**Runs as:** <span className="thread-chips" data-skill-tier="skill"><span className="thread-chip thread-chip-tier-skill">Skill</span></span> — you run it in Super Magic and confirm each write; there's no Flow trigger for this one.

**Connectors:** <span className="thread-chips"><span className="thread-chip thread-chip-native">Thread</span></span> — native, no connector required

**Role:** [Security & Compliance Owner](/start-here/roles/security-compliance-owner), [Technician](/start-here/roles/technician)

**Outcome:** Risk & Compliance, Faster Resolution & Response

**When to use:** A Huntress incident report or signal email lands mentioning unwanted access, a suspicious login, a rogue/malicious inbox or OAuth application, or a mail-rule anomaly; a tech asks "what do I do with this Huntress identity alert?"; or a Huntress remediation is pending approval and someone wants a second opinion.

**Run it:** on the alert ticket.

## Prompt

```
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.
```


## Related topics

- [Huntress EDR Incident](/skill-library/vendor-runbooks/huntress-edr-incident.md)
- [Alert Runbooks](/skill-library/alert-runbooks/overview.md)
- [Backup Failure Triage](/skill-library/devices-and-infrastructure/backup-failure-triage.md)