Identity Threat Detection & Response (ITDR)
Real-time detection of active attacks against your identity infrastructure, enriched with graph context so you can immediately understand the blast radius of a compromised account.
Requires role: Operator or higher
Related: Risk Posture Dashboard, Detection Alerts, Telemetry Pipeline, Select Fire, Asset Criticality, Multi-Agent Intelligence, Identity Bridge
Overview
Traditional SIEM tools detect attack patterns by correlating log events — for example, 10 failed logons in 5 minutes triggers a brute force alert. What they cannot tell you is what the attacker gains if that brute force succeeds. Is the targeted account a standard user with access to a handful of file shares, or a service account with replication rights on every domain controller?
The ITDR Detection Engine in FidelID™ closes this gap. Every alert is automatically enriched with context drawn from the identity graph:
- Identity type — Is the targeted account a User, ServiceAccount, Computer, or ServicePrincipal?
- Criticality tier — Is it a Tier 0 asset (Domain Admin, Enterprise Admin, Domain Controller)?
- Blast radius — How many nodes can an attacker reach from this identity within three hops through the access graph?
This means an alert about a Kerberoasting attack against svc-sql tells you not just that the attack happened, but that svc-sql is a Tier 0 ServiceAccount with a blast radius of 47 nodes including three Domain Controllers. That is the context needed to determine whether to page the on-call team immediately or schedule an investigation for the next business day.
The engine runs inline with the telemetry ingestion pipeline. As events arrive from your Identity Bridge agents, they are normalized and evaluated against all detection rules before being written to the graph. Alerts that cross a rule's threshold are persisted and are immediately visible on the Detection Alerts page and queryable through the Graphne conversational agent.
All alerts are tagged with MITRE ATT&CK technique IDs, making them straightforward to correlate with threat intelligence feeds and feed into external SIEM or SOAR workflows.
NOTE
The ITDR engine includes 6 detection rules and a full Detection Alerts page for viewing, filtering, triaging, and managing alerts. See the Detection Alerts guide for the investigation UI.
Prerequisites
Before ITDR alerts will fire, the following must be in place:
- Role: Operator or Admin to view the Detection Alerts page and query alerts through the Graphne agent
- Identity Bridge deployed: At least one bridge agent must be running and connected to the platform
- Event forwarding enabled: The bridge must be configured to forward Windows Security Events to the telemetry ingest pipeline (this is the default configuration)
- Events flowing: Confirm that telemetry events are being received by checking bridge sync metrics — the "Events Ingested" counter should be increasing
- Identity graph populated: At least one full sync must have completed so that identity nodes exist in the graph for blast radius enrichment
TIP
If you have the bridge running but are unsure whether telemetry is flowing, open the Graphne agent and ask: "How many telemetry events have been ingested in the last hour?"
How the Detection Engine Works
The engine evaluates every batch of incoming events against all registered detection rules. Rules use sliding time windows to correlate events: failed logons are grouped within a 5-minute window, TGS requests within a 1-minute window, and so on. When a rule's threshold is crossed within its window, an alert is generated.
The evaluation happens in three stages:
- Rule evaluation — Events are filtered and grouped in memory against each rule's logic (no database queries required at this stage)
- Graph enrichment — When an alert fires, the engine queries the identity graph to populate the subject's node type, criticality tier, and blast radius
- Alert persistence — The enriched alert is written with a 1-year retention period
After an alert fires, the rule's event window is cleared to prevent the same batch of events from generating duplicate alerts.
Once alerts are persisted, they appear on the Detection Alerts page where you can filter by severity, rule, domain, and status, triage individual alerts, and track investigation progress. You can also query alerts through the Graphne conversational agent for ad-hoc investigation.
Detection Rules
The engine ships with six detection rules covering the most common Active Directory attack techniques. Each rule fires independently — a single batch of events can trigger multiple rules.
Brute Force (T1110.001)
Severity: HIGH
Detects repeated failed logon attempts against a single account, indicating a password-guessing attack.
| Setting | Value |
|---|---|
| Time window | 5 minutes |
| Threshold | More than 10 failed logons for the same account |
| Windows events | 4625 (failed logon), 4771 (Kerberos pre-auth failure), 4776 (NTLM credential validation failure) |
The alert includes the number of failed attempts, the source host or hosts, and the targeted account. Graph enrichment then adds the account's type and blast radius so you can immediately assess whether a generic user account or a privileged service account is under attack.
Example alert title: Brute force detected: john.doe
Example description: 47 failed logon attempts for john.doe from 2 source(s) within 5m0s
Password Spray (T1110.003)
Severity: HIGH
Detects a source host attempting authentication against many different accounts with few attempts per account — the hallmark of a password spray, which tries one common password against every account to stay below per-account lockout thresholds.
| Setting | Value |
|---|---|
| Time window | 10 minutes |
| Threshold | More than 5 distinct accounts targeted from a single source host |
| Windows events | 4625 (failed logon) |
Unlike brute force, the alert is keyed on the source host rather than the victim account. The description lists how many distinct accounts were targeted and the total event count from that source.
Example alert title: Password spray detected from ATTACKER-PC
Example description: Failed logons to 8 distinct accounts from ATTACKER-PC (11 events)
TIP
Password spray and brute force can occur simultaneously. A spray followed by a focused brute force against the most promising account is a common progression. Review both alert types together when investigating credential-based attacks.
Kerberoasting (T1558.003)
Severity: CRITICAL
Detects an attacker requesting Kerberos service tickets (TGS) using weak RC4 encryption. RC4-encrypted service tickets can be taken offline and cracked to recover the plaintext password of the service account. This technique does not require elevated privileges to execute, making it a common step in privilege escalation.
| Setting | Value |
|---|---|
| Time window | 1 minute |
| Threshold | More than 3 TGS requests with RC4 encryption (ticket type 0x17) from the same user |
| Windows events | 4769 (Kerberos service ticket requested) |
The alert lists the names of the targeted services (the service accounts whose tickets were requested). Checking the blast radius of those service accounts helps you understand the worst-case impact of a successful crack.
Example alert title: Kerberoasting detected: jsmith
Example description: jsmith requested 5 TGS tickets with RC4 encryption targeting 3 service(s)
NOTE
Modern environments should enforce AES encryption for Kerberos service tickets. RC4 TGS requests from non-legacy clients are a strong indicator of active Kerberoasting. If your environment has legitimate legacy systems that require RC4, coordinate with your infrastructure team to isolate or upgrade those systems.
DCSync (T1003.006)
Severity: CRITICAL
Detects a non-Domain Controller account exercising Active Directory replication rights to pull password hashes for all accounts in the domain. DCSync is a credential dumping technique that allows an attacker who has compromised an account with replication permissions to extract every credential in the domain without touching a Domain Controller directly.
| Setting | Value |
|---|---|
| Time window | Immediate (single-event trigger) |
| Threshold | Any single event |
| Windows events | 4662 (object operation performed) with DS-Replication-Get-Changes and DS-Replication-Get-Changes-All property GUIDs |
This rule fires on the first event. There is no threshold — any DCSync attempt from a non-DC account is always malicious and warrants immediate investigation.
The Windows normalizer identifies the replication GUIDs in event 4662 and marks the action as dcsync_attempt. The detection rule fires on any such labeled event.
Example alert title: DCSync attempt by CORP\jsmith
Example description: Account CORP\jsmith used directory replication rights (DS-Replication-Get-Changes + Get-Changes-All) on DC01 — this is a credential theft technique
WARNING
A DCSync alert is a near-certain indicator of compromise. Treat it as a confirmed incident, not a suspected one. Isolate the account immediately, rotate all domain credentials, and initiate your incident response process.
Tier 0 Group Change (T1098)
Severity: CRITICAL
Detects any modification to a Tier 0 privileged group — Domain Admins, Enterprise Admins, Schema Admins, Administrators, and other groups identified by well-known relative identifiers (RIDs). Adding an account to one of these groups is a common privilege escalation step that grants an attacker domain-wide administrative rights.
| Setting | Value |
|---|---|
| Time window | Immediate (single-event trigger) |
| Threshold | Any single event |
| Windows events | 4728 (global group member added), 4732 (local group member added), 4756 (universal group member added) |
The Windows normalizer elevates the severity of group change events to critical when the target group's SID matches a known Tier 0 RID. The detection rule fires only on events already elevated to critical severity, so it will not alert on changes to standard security groups.
The alert includes three key attributes:
- member: The account that was added to the group
- group: The Tier 0 group that was modified
- modifier: The account that performed the change
Example alert title: Tier 0 group modification: Domain Admins
Example description: CORP\helpdesk-admin added CORP\jsmith to privileged group Domain Admins
Audit Tampering (T1562.002)
Severity: CRITICAL
Detects changes to the Windows audit policy. Attackers frequently disable or modify audit logging before performing malicious actions to prevent their activity from appearing in event logs. Any audit policy change warrants immediate investigation, as there is rarely a legitimate operational reason to modify audit policy outside of a documented change window.
| Setting | Value |
|---|---|
| Time window | Immediate (single-event trigger) |
| Threshold | Any single event |
| Windows events | 4719 (system audit policy was changed) |
Example alert title: Audit policy changed by CORP\svc-deploy
Example description: Audit policy modification on SERVER-01 by CORP\svc-deploy — may indicate evidence tampering
Graph-Enriched Alert Context
Every alert where the subject identity can be found in the graph is automatically enriched with the following context. This enrichment runs after the rule fires and before the alert is written to the database.
| Field | Description |
|---|---|
| Subject Node Type | The identity subtype from the graph: User, ServiceAccount, Computer, ServicePrincipal, Group, etc. |
| Subject Tier | The criticality tier assigned by the Asset Criticality Engine. Tier 0 = highest privilege (Domain Admins, DCs). Absent if the identity has not been classified. |
| Blast Radius | The count of distinct nodes reachable from the subject identity within three outbound hops through the access graph, excluding structural container and policy links. This represents how many resources an attacker controlling this identity could potentially access. |
The graph context tells you not just that an attack happened, but how much damage is at stake. For example, a Kerberoasting alert against a Tier 0 ServiceAccount with a blast radius of 47 nodes — including Domain Controllers — warrants immediate escalation, while the same attack against an isolated service account with a blast radius of 3 can be investigated on a standard timeline.
NOTE
If the subject identity cannot be found in the graph (for example, the account has not yet synced), the alert is still created without graph enrichment. The graph context fields will be absent or have zero values. This does not prevent the alert from being actionable — the raw event data is still complete.
Alert Severity Levels
| Severity | Color | Rules | Response Guidance |
|---|---|---|---|
| CRITICAL | Red | Kerberoasting, DCSync, Tier 0 Group Change, Audit Tampering | Treat as active incident. Investigate immediately and consider isolating the subject account. |
| HIGH | Orange | Brute Force, Password Spray | Investigate within the hour. Determine if the attack succeeded (check for successful logons from same source). |
| MEDIUM | Yellow | (Future rules) | Investigate within the business day. |
| LOW | Gray | (Future rules) | Review in your next scheduled security review. |
| INFO | Blue | (Future rules) | Informational only — no action required. |
Alert Lifecycle
Alerts move through four states. Status transitions can be made from the Detection Alerts page or through the Graphne agent.
open --> acknowledged --> resolved
--> false_positive
open --> resolved
open --> false_positive| Status | Meaning |
|---|---|
| open | New alert, not yet reviewed |
| acknowledged | Under active investigation |
| resolved | Confirmed threat, remediated |
| false_positive | Confirmed benign — rule triggered incorrectly |
Alerts are retained for one year from creation and then automatically purged. There is no need to manually delete old alerts.
Viewing and Managing Alerts
The primary interface for alert triage is the Detection Alerts page, accessible from Analysis > Detection Alerts in the sidebar. It provides filtering by severity, rule name, domain, and status, along with inline status management for triaging alerts.
For ad-hoc investigation, you can also query alerts through the Graphne conversational agent. Open the agent from the sidebar and ask questions in plain language. The agent queries alerts and returns results with formatted context.
Example Queries
Show recent alerts:
"Show me recent security alerts"
"Are there any open CRITICAL alerts?"
Filter by rule or severity:
"Show me all Kerberoasting alerts from the last 24 hours"
"List open brute force alerts in domain CORP"
Investigate a specific identity:
"Are there any alerts for svc-sql?"
"What ITDR alerts exist for accounts in the Domain Admins group?"
Understand blast radius:
"What is the blast radius for the account in the most recent DCSync alert?"
Triage and prioritize:
"Which open alerts involve Tier 0 accounts?"
"Show me all alerts from the last hour sorted by severity"
The agent will return alert summaries including the rule name, title, severity, subject identity, and graph context. For detailed investigation, ask follow-up questions to explore the identity graph around the subject account.
MITRE ATT&CK Coverage
All detection rules include MITRE ATT&CK technique IDs. These map to the official MITRE ATT&CK framework at https://attack.mitre.org/techniques/{id}/.
Current Coverage (6 Rules)
| Rule | MITRE ID | Technique Name | Tactic |
|---|---|---|---|
| Brute Force | T1110.001 | Brute Force: Password Guessing | Credential Access |
| Password Spray | T1110.003 | Brute Force: Password Spraying | Credential Access |
| Kerberoasting | T1558.003 | Steal or Forge Kerberos Tickets: Kerberoasting | Credential Access |
| DCSync | T1003.006 | OS Credential Dumping: DCSync | Credential Access |
| Tier 0 Group Change | T1098 | Account Manipulation | Persistence |
| Audit Tampering | T1562.002 | Impair Defenses: Disable Windows Event Logging | Defense Evasion |
Planned Coverage (Additional Rules)
| Rule | MITRE ID | Technique Name |
|---|---|---|
| AS-REP Roasting | T1558.004 | Steal or Forge Kerberos Tickets: AS-REP Roasting |
| Golden Ticket | T1558.001 | Steal or Forge Kerberos Tickets: Golden Ticket |
| Pass the Hash | T1550.002 | Use Alternate Authentication Material: Pass the Hash |
| Lateral Movement Chain | T1021 | Remote Services |
| Account Manipulation | T1098.001 | Account Manipulation: Additional Cloud Credentials |
| SID History Injection | T1134.005 | Access Token Manipulation: SID-History Injection |
| Trust Manipulation | T1484.002 | Domain Policy Modification: Trust Modification |
The mitreAttack field in every alert contains the technique ID string. You can use this to cross-reference alerts with threat intelligence platforms, add to SIEM correlation rules, or automate SOAR playbook selection.
Integrating with External Tools
Because every alert contains a MITRE ATT&CK technique ID, a subject identity, a domain, and a timestamp, they can be forwarded to external tools through the Detection Alerts page or scheduled export workflows.
For SIEM integration: Export alerts using a scheduled query and forward the JSON records to your SIEM's ingest endpoint. The mitreAttack, severity, subjectId, and domain fields map cleanly to most SIEM schemas.
For SOAR workflows: The Graphne agent can be queried to retrieve alert data and trigger downstream automation. Ask the agent to retrieve alerts matching specific criteria and parse the structured response.
For threat intelligence correlation: The mitreAttack field maps directly to ATT&CK Navigator layer format for visualizing your current detection coverage.
Troubleshooting
No alerts are appearing even though attacks are occurring
Possible causes:
- Events not flowing: The bridge may not be forwarding telemetry events. Check the bridge sync metrics — the "Events Ingested" count should be increasing during active logon activity.
- Bridge version: Telemetry forwarding requires a bridge version that supports the telemetry pipeline. Older bridge versions may not forward event data.
- Event IDs not audited: The Windows audit policy on your domain controllers must be configured to log the relevant event IDs. Check that the following audit categories are enabled:
- Audit Logon / Logoff (for 4624, 4625, 4771, 4776)
- Audit Kerberos Service Ticket Operations (for 4769)
- Audit Directory Service Access (for 4662)
- Audit Security Group Management (for 4728, 4732, 4756)
- Audit Audit Policy Change (for 4719)
Resolution: Navigate to Bridges in the sidebar, open the bridge detail view, and check the Sync Metrics panel. If "Events Ingested" is 0 or static, contact your administrator to verify the bridge event forwarding configuration.
Alerts fire but graph context (blast radius, tier) is missing
Possible causes:
- Identity not yet synced: The subject account exists in Active Directory but the bridge has not yet synced it into the graph. The engine will create the alert without enrichment when the subject cannot be matched.
- Name format mismatch: Telemetry events report account names as
DOMAIN\usernameor[email protected], while the graph stores the sAMAccountName. The enrichment query uses fuzzy matching; very short usernames may not match correctly.
Resolution: Trigger a manual sync from Bridges > [bridge name] > Trigger Sync to ensure the graph is current. If the issue persists, ask the Graphne agent to look up the identity directly: "Find the identity node for svc-sql" to confirm it exists in the graph.
I see many brute force alerts for service accounts at regular intervals
Possible cause: Some monitoring tools, scheduled tasks, or applications are configured with stale credentials and generate periodic authentication failures. This is a legitimate operational issue rather than an active attack, but the accounts involved should be investigated to update their credentials.
Resolution: Review the source hosts listed in the alerts. If they correspond to known monitoring servers or automation platforms, update the credentials in those systems and acknowledge the alerts as operational findings.
DCSync alert fired for a known Domain Controller
Possible cause: The Windows normalizer identifies DCSync via replication property GUIDs in event 4662. If the event was generated by a Domain Controller performing legitimate replication, the normalizer should not label it as dcsync_attempt. However, if a DC account is being used interactively from a workstation (not from the DC itself), the rule may fire.
Resolution: Examine the sourceHost and targetHost fields in the alert. If the source host is a known Domain Controller, this may be a false positive. Mark the alert as false_positive from the Detection Alerts page or via the Graphne agent: "Mark alert [alert ID] as false positive."
Too many alerts for a busy environment
Context: High-volume environments with frequent authentication failures (such as those with many expired service account passwords) may generate a large number of brute force or password spray alerts.
Resolution: Use the Detection Alerts page to filter by severity and focus on CRITICAL alerts first. You can also use the Graphne agent: "Show me only CRITICAL alerts from the last 24 hours." Prioritize CRITICAL alerts (Kerberoasting, DCSync, Tier 0 group changes, audit tampering) for immediate action. HIGH-severity brute force and spray alerts can be reviewed in batches.
Related Documentation
- Detection Alerts — Full alert management UI for viewing, filtering, triaging, and resolving detection alerts
- Identity Bridge — Configure the bridge agent that forwards telemetry events to the detection engine
- Risk Posture Dashboard — Organization-wide risk score that complements ITDR with posture-based detection
- Asset Criticality — How identity criticality tiers are assigned, which determines the blast radius context in alerts
- Multi-Agent Intelligence — The Graphne agent used to query detection alerts and investigate findings