Identity Threat Detection & Response (ITDR): Kerberoasting, DCSync and Lateral Movement Detection

Overview

SIEM tools find attack patterns by correlating log events. For example, 10 failed logons (event 4625) in 5 minutes raise a brute force alert. They can't tell you what the attacker gains if the attack works. The targeted account might be a standard user with a few file shares, or a service account with replication rights on every domain controller.

The ITDR detection engine in GraphnAI adds that answer. Every alert carries context from the identity graph:

• Identity type: Is the account a User, ServiceAccount, Computer or ServicePrincipal?
• Criticality tier: Is it a Tier 0 asset, such as a Domain Admin, an Enterprise Admin or a domain controller?
• Paths to Tier 0: How many attack paths lead from this identity to Tier 0, up to 5?

So a brute force alert against svc-sql tells you more than that the attack happened. It tells you svc-sql is a ServiceAccount with 2 paths to Tier 0, one of them Validated. With that, you can decide whether to page the on-call team now or investigate on the next business day.

The engine runs inside the telemetry pipeline. Events from your collectors are normalized, stored and applied to the graph, then checked against every rule. An alert appears on the Detection Alerts page as soon as it's stored, and Graphne can query it.

Every alert carries a MITRE ATT&CK ID, so you can correlate it with threat intelligence feeds and route it into SIEM or SOAR workflows.

[!NOTE] The engine runs 11 rules on the events themselves and 3 behavior rules that compare each logon with the identity's baseline. Two older rules are withdrawn. View, filter and triage alerts on the Detection Alerts page. The Detection Alerts item in the sidebar counts the open ones.

---

Prerequisites

Before ITDR alerts fire, you need:

• Role: Operator or Admin, to view the Detection Alerts page and ask Graphne about alerts.
• License: A license that includes ITDR, to see the alerts. While the license is read-only, collection and detection stop.
• A collector deployed: An OpenTelemetry collector forwards Windows security events from your domain controllers. The Identity Bridge doesn't read event logs itself. See Telemetry Pipeline.
• Events flowing: On Admin > Telemetry, the Pipeline tab shows the event counts rising.
• Identity graph populated: At least one full sync, so alerts can find their identity and its paths to Tier 0.

[!TIP] If you aren't an Admin, ask Graphne: "How many telemetry events arrived in the last hour?"

---

How the Detection Engine Works

The engine checks every batch of incoming events against every active rule. A batch is flushed every second, or sooner when 100 events are waiting. Many rules correlate events over a sliding time window: failed logons over 5 minutes, service ticket requests over 1 minute, and so on. When a rule reaches its threshold inside its window, it raises an alert. The other rules fire on a single event.

Each alert goes through three stages:

1. Rule evaluation: Events are grouped in memory against each rule's logic.
2. Graph enrichment: When a rule fires, the engine looks up the subject in the identity graph and records its type and tier. Triage then adds the paths to Tier 0, or the engine does about a minute after it stores the alert.
3. Alert storage: The enriched alert is stored and kept for one year.

A windowed rule raises one alert for each account, source or change it finds. While that finding's evidence is still inside the window, the rule doesn't raise it again. The rest of the window stays, so an alert about one account never discards another account's evidence.

On the Detection Alerts page, you filter alerts by severity, status and rule, triage them, and track the investigation. You can also ask Graphne about them.

---

Detection Rules

The engine has 16 rules: 11 that read events, 3 that compare logons with a baseline, and 2 that are withdrawn. Each rule fires on its own, so one batch of events can raise several alerts. Admins see every rule, with its status, on the Detection rules tab of Admin > Telemetry.

Core Rules

Brute Force (T1110.001)

Severity: HIGH

Detects repeated failed logons to one account: someone guessing its password.

The alert gives the number of failures, the source hosts and the targeted account. Graph enrichment adds the account's type and tier, so you see at once whether an ordinary user or a privileged service account is under attack.

Example alert title: Brute force: 12 failed logons in 5 minutes

Example description: 12 failed logons to CORP\john.doe from 2 sources.

---

Password Spray (T1110.003)

Severity: HIGH

Detects one source host failing to log on to many accounts with a few tries each. A spray tries one common password against every account to stay under per-account lockout thresholds. Many source hosts failing against one account is distributed brute force, which the Brute force rule catches.

Brute force alerts name the targeted account. This rule names the source host instead: its IP address or workstation name. The description gives how many accounts were targeted, and the alert counts the events from that source.

Example alert title: Password spray from 10.0.4.17

Example description: Failed logons to 8 accounts from 10.0.4.17.

[!TIP] Password spray and brute force can happen together. A spray followed by a focused brute force against the most promising account is a common progression. Review both alert types together when you investigate credential attacks.

---

Kerberoasting (T1558.003)

Severity: CRITICAL

Detects an account requesting Kerberos service tickets (TGS) with weak RC4 encryption. An attacker can take RC4 service tickets offline and crack them to recover the service account's password. The technique needs no elevated privileges, so it's a common step in privilege escalation.

The alert's subject is the account that requested the tickets. The alert also lists the services whose tickets it requested. Check those service accounts' tiers to see the worst case if a password is cracked.

Example alert title: Kerberoasting: 5 RC4 service tickets requested

Example description: CORP\jsmith requested 5 RC4-encrypted service tickets for 3 services in 1 minute.

[!NOTE] Modern environments should enforce AES encryption for Kerberos service tickets. RC4 service ticket requests from modern clients strongly suggest Kerberoasting. If legitimate legacy systems still need RC4, work with your infrastructure team to isolate or upgrade them.

---

DCSync (T1003.006)

Severity: CRITICAL

Detects an account using Active Directory replication rights to pull password hashes. With DCSync, an attacker who controls an account with replication rights can extract every credential in the domain without logging on to a domain controller.

The Windows normalizer recognizes the two replication rights in event 4662 and marks the event as a DCSync attempt. The rule alerts once per account and domain controller within the window.

The rule doesn't check whether the account is a domain controller. A domain controller's own computer account can trip it during normal replication, so check the subject before you escalate.

Example alert title: DCSync against DC01.corp.local

Example description: CORP\jsmith requested directory replication on DC01.corp.local using Replicating Directory Changes and Replicating Directory Changes All.

[!WARNING] A DCSync alert from an account that isn't a domain controller is a near-certain sign of compromise. Treat it as a confirmed incident. Isolate the account at once, rotate all domain credentials, and start your incident response process.

---

Tier 0 Group Change (T1098)

Severity: CRITICAL

Detects a member added to a Tier 0 group: Domain Admins, Enterprise Admins, Schema Admins, Administrators and the other groups with well-known privileged relative identifiers (RIDs). Adding an account to one of these groups gives an attacker domain-wide administrative rights.

The Windows normalizer raises a membership addition to critical when the group's SID ends in a Tier 0 RID. The rule fires only on those events, so changes to ordinary security groups don't alert.

The alert records three attributes:

• member: The account that was added to the group
• group: The Tier 0 group that changed
• modifier: The account that made the change

Example alert title: Tier 0 group change: jsmith added to Domain Admins

Example description: CORP\helpdesk-admin added jsmith to Domain Admins.

---

Audit Tampering (T1562.002)

Severity: CRITICAL when any change turns auditing off, LOW when every change only turns it on

Detects a change to the Windows audit policy. Attackers often turn off or change audit logging before they act, so their activity never reaches the event log. Audit policy rarely changes for a legitimate reason outside a documented change window, so investigate every change.

Windows logs one 4719 for each audit subcategory a change touches, so one change can arrive as many events. They fold into one alert per actor and host, with the number of events. The alert names each audit category and each change ("Success auditing removed", "Failure auditing added"), and shows the address the account logged on from when the logon event is stored.

Example alert title: Audit policy changed on SERVER-01

Example description: CORP\svc-deploy changed the audit policy on SERVER-01.

---

Advanced Rules

These rules extend coverage to Kerberos ticket forgery, lateral movement, account manipulation and domain trust changes.

AS-REP Roasting (T1558.004)

Severity: CRITICAL

Detects repeated TGT requests without Kerberos pre-authentication from one source. An attacker enumerates accounts that have pre-authentication turned off, to collect responses they can crack offline.

Like password spray, the alert names the source: its host, or the requesting account when the event has no host.

Example alert title: AS-REP Roasting from 10.0.4.17

---

Golden Ticket (T1558.001)

Severity: CRITICAL

Detects a ticket-granting ticket (TGT) issued with RC4 encryption. A TGT is encrypted with the krbtgt key, so RC4 is unusual on a modern domain and a common sign of a forged ticket.

If some accounts still get RC4 tickets for a legitimate reason, expect alerts for them too.

Example alert title: Golden Ticket: RC4-encrypted TGT

Example description: A ticket-granting ticket encrypted with RC4 was issued for CORP\jsmith.

---

Lateral Movement Chain (T1021)

Severity: HIGH

Detects one account making network logons (type 3) to three or more hosts in turn, which suggests an attacker moving through the network. The rule builds a chain from logons where one logon's target host is the next one's source.

The alert includes the whole chain in its attributes, for example WS-01 → SERVER-A → SERVER-B → DC01. When a logon's host name was removed at ingest because it held a credential, that logon is left out of the chain, and the description says how many were left out.

Example alert title: Lateral movement: 4 hosts

---

Account Manipulation (T1098)

Severity: HIGH

Detects a password reset or an account enable done by another account. Self-service password resets are excluded.

Alerts raised before this rule moved to T1098 still show T1098.001.

Example alert titles: Password reset for CORP\exec-vp, Account enabled: CORP\svc-legacy

---

Trust Manipulation (T1484.002)

Severity: CRITICAL

Detects a domain or forest trust being created, removed or changed. A trust change can give an attacker persistence, or access to resources across domain boundaries.

Example alert title: Trust with partner.example created

---

Withdrawn Rules

Two rules no longer run. Alerts they raised before then still show on the Detection Alerts page. The Detection rules tab lists them as Withdrawn, with the reason in a tooltip.

---

Behavioral Baselines

The engine keeps a baseline for each identity, built from its successful logons (event 4624, "An account was successfully logged on") over the last 30 days. Baselines are rebuilt each time analytics runs: after every full sync, and after every delta sync that changed something. A baseline records:

• Typical logon hours: How the identity's logons spread across the 24 hours of the day, in UTC. An hour counts as typical when it holds more than 1% of them.
• Typical source hosts: The hosts the identity logs on from in at least 10% of its logons.
• Protocol mix: How often it authenticates with Kerberos, NTLM and other protocols.

A baseline needs at least 50 logons in 30 days. Identities with fewer have no baseline, and the behavior rules don't fire for them.

Three behavior rules compare each new logon with the baseline. Each raises at most one alert per identity for each batch of events.

Unusual Logon Hour

Severity: MEDIUM

Fires when an identity logs on at an hour (UTC) that holds 1% or less of its logons over the last 30 days. For example, a user who works 09:00 to 17:00 logs on at 03:00.

Example alert title: Unusual logon hour: 03:00 UTC

Unusual Source Host

Severity: MEDIUM

Fires when an identity logs on from a host outside its typical hosts. For example, a finance analyst who uses WS-FINANCE-01 and WS-FINANCE-02 logs on from SERVER-IT-ADMIN. A logon whose source host name was removed at ingest isn't judged.

Example alert title: Unusual source host: SERVER-IT-ADMIN

Unusual Authentication Protocol

Severity: MEDIUM

Fires when an identity authenticates with a protocol that makes up less than 5% of its baseline. For example, an identity that used Kerberos for every authentication over 30 days authenticates with NTLM.

Example alert title: Unusual authentication protocol: NTLM

---

Alert Notification Badge

The Detection Alerts item in the sidebar carries a badge while alerts are open:

• Count: The number of open alerts. Above 99, it reads "99+".
• Color: The severity of the most severe alert on record, in any status.

Select the item to open the Detection Alerts page. The badge updates as new alerts arrive.

---

Graph-Enriched Alert Context

Every alert whose subject is in the graph carries this context. The engine adds it after the rule fires and before it stores the alert.

The engine matches the subject by account name, alone or with its NetBIOS domain, DNS domain or UPN suffix. On the Detection Alerts page, the flyout draws a blast radius graph of what the subject can reach. Graphne can report the stored values.

The graph context tells you how much is at stake. For example, a brute force alert against a ServiceAccount with 2 paths to Tier 0, one of them Validated, calls for escalation now. The same attack against an account with no paths to Tier 0 can wait for a standard investigation.

[!NOTE] If the subject isn't in the graph (for example, the account hasn't synced yet), the alert is still stored, without a type, tier or paths to Tier 0. The alert is still actionable: the event data is complete.

---

Alert Severity Levels

---

Alert Lifecycle

Alerts move through four statuses. Admins change the status on the Detection Alerts page.

open → acknowledged → resolved
  \
   → false_positive

The page offers the steps shown above.

Alerts are kept for one year from creation, then deleted automatically. You don't need to delete old alerts.

---

Viewing and Managing Alerts

The main place to triage alerts is the Detection Alerts page, under Detection & Response > Detection Alerts in the sidebar. It filters by severity, status and rule, and Admins change an alert's status there.

For quick questions, ask the Graphne conversational agent. Open Graphne from the sidebar and ask in plain language. Graphne reads alerts and returns them with their context. It can't change an alert's status.

Example Queries

Show recent alerts:

"Show recent security alerts."

"Are there any open critical alerts?"

Filter by rule or severity:

"Show all Kerberoasting alerts from the last 24 hours."

"List open brute force alerts in the corp.local domain."

Investigate a specific identity:

"Are there any alerts for svc-sql?"

"Which detection alerts involve members of Domain Admins?"

Understand reach:

"How many paths lead from the account in the most recent DCSync alert to Tier 0?"

Triage and prioritize:

"Which open alerts involve Tier 0 accounts?"

"Show alerts from the last hour, most severe first."

Graphne answers with each alert's rule, title, severity, subject and graph context. Ask follow-up questions to explore the graph around the subject.

---

MITRE ATT&CK Coverage

Every rule carries a MITRE ATT&CK ID. On the Detection Alerts page, the ID links to its page on https://attack.mitre.org.

The withdrawn Pass-the-Hash rule used T1550.002 and the withdrawn SID history injection rule used T1134.005.

The mitreAttack field in every alert holds the ID. Use it to cross-reference threat intelligence platforms, write SIEM correlation rules or pick a SOAR playbook.

---

Integrating with External Tools

Every alert carries a MITRE ATT&CK ID, a subject, a domain and a timestamp, so you can forward it to other tools:

• Export: On the Detection Alerts page, Export saves the filtered alerts as CSV or JSON.
• API: A script can read alerts a page at a time through the platform's API, with an API key that carries the detection:read scope. See API Key Management.
• SIEM: Read alerts on a schedule and forward the JSON records to your SIEM's ingest endpoint. The mitreAttack, severity, subjectId and domain fields map to most SIEM schemas.
• Threat intelligence: The mitreAttack field maps directly to ATT&CK Navigator layers, to picture your detection coverage.

---

Troubleshooting

No alerts appear even though attacks are happening

Possible causes:

• Events not flowing: No collector is sending events, or one stopped. On Admin > Telemetry, the Pipeline tab should show counts rising during logon activity.
• Event IDs not audited: Your domain controllers' audit policy must log the events the rules read. Check that these subcategories are on:
  • Audit Credential Validation (4776)
  • Audit Kerberos Authentication Service (4768, 4771)
  • Audit Kerberos Service Ticket Operations (4769)
  • Audit Logon (4624, 4625)
  • Audit Directory Service Access (4662)
  • Audit Security Group Management (4728, 4732, 4756)
  • Audit User Account Management (4722, 4724)
  • Audit Audit Policy Change (4719)
  • Audit Authentication Policy Change (4706, 4707, 4716)
• Read-only license: While the license is read-only, collection and detection stop.
• No baseline yet: The behavior rules need 50 logons in 30 days for each identity.

Resolution: Check the Pipeline tab on Admin > Telemetry. If the counts are 0 or flat, work through the troubleshooting steps in Telemetry Pipeline. The full audit settings are in Configuring Windows Audit Policy.

---

Alerts fire but graph context (tier, paths to Tier 0) is missing

Possible causes:

• Identity not yet synced: The account exists in Active Directory, but no sync has brought it into the graph yet. The alert is stored without enrichment.
• The alert names a host: Password spray and AS-REP Roasting alerts name the attacking source, so they have no account to enrich.
• The name doesn't match: The engine matches the subject by account name, alone or with its NetBIOS domain, DNS domain or UPN suffix. An account the graph doesn't hold, such as a deleted account or a cloud-only principal, doesn't match.

Resolution: Open Admin > Bridges, open the bridge, and select Full sync to bring the graph up to date. If the context is still missing, ask Graphne: "Find the identity svc-sql." That confirms whether the account is in the graph.

---

Many brute force alerts for service accounts at regular intervals

Possible cause: Monitoring tools, scheduled tasks or applications still hold old credentials and fail to authenticate on a schedule. This is usually an operational problem. Investigate the accounts anyway, and update their credentials.

Resolution: Review the source hosts in the alerts. If they're known monitoring servers or automation platforms, update the credentials there, then acknowledge the alerts.

---

A DCSync alert fired for a domain controller

Possible cause: The rule fires on any account that uses both replication rights, including a domain controller's own computer account during normal replication. Nothing checks whether the account is a domain controller.

Resolution: Check the alert's Subject and its target host. If the subject is a known domain controller's computer account (its name ends in $) and the replication is expected, mark the alert as a false positive on the Detection Alerts page.

---

Too many alerts in a busy environment

Context: Environments with frequent failed logons, for example from many expired service account passwords, can raise a large number of brute force or password spray alerts.

Resolution: On the Detection Alerts page, filter by severity and handle Critical alerts first: Kerberoasting, DCSync, Tier 0 group change, Audit tampering, AS-REP Roasting, Golden Ticket and Trust manipulation. You can also ask Graphne: "Show only critical alerts from the last 24 hours." Review the High brute force and spray alerts in batches.

---

Related Documentation

• Detection Alerts: The page for viewing, filtering, triaging and resolving detection alerts
• Telemetry Pipeline: The collector setup that sends events to the detection engine
• Identity Bridge: The sync that brings identities into the graph, so alerts can be enriched
• Risk Posture Dashboard: The organization-wide risk score, where open alerts count toward identity risk
• Asset Criticality: How criticality tiers are assigned, which sets the subject tier in alerts
• Multi-Agent Intelligence: The Graphne agent you use to query detection alerts and investigate findings