Identity Threat Detection and Response (ITDR) Guide

Identity is the most targeted attack vector. Over 80% of breaches involve compromised credentials, and adversaries increasingly use identity-based techniques — credential theft, privilege escalation, lateral movement, and MFA bypass — to achieve their objectives. Traditional security tools like firewalls and endpoint detection are necessary but insufficient. They were not designed to detect the subtle signals of identity compromise.

Identity Threat Detection and Response (ITDR) fills this gap. ITDR is a security discipline focused on detecting attacks that target the identity infrastructure itself — directory services, authentication protocols, identity providers, and privileged access — and responding to those attacks before they cause damage.

This guide walks you through building an ITDR capability, from architecture through detection engineering to response playbooks.

What You Will Learn

• The ITDR framework and how it fits into your security stack
• Key identity attack techniques and how to detect them
• Building detection rules for credential theft, privilege escalation, and lateral movement
• Designing response playbooks for identity incidents
• Integrating ITDR with your existing SIEM and SOAR

Prerequisites

1. Centralized logging — Identity events from your IdP, Active Directory, cloud IAM, VPN, and critical applications must flow to a central SIEM or data lake.
2. Active Directory auditing — AD is the primary target for identity attacks. Advanced audit policies must be enabled (discussed in Step 2).
3. IdP event logging — Your IdP (Okta, Azure AD, Ping) must export authentication, authorization, and administrative events.
4. Baseline behavior data — At least 30 days of historical identity event data to establish behavioral baselines.
5. Incident response team — People who will triage and respond to identity alerts. This can be your existing SOC team with identity-specific training.

Architecture Overview

ITDR operates as a specialized detection and response layer focused on identity signals:

• Identity Data Sources: Active Directory, Azure AD, Okta, cloud IAM (AWS, GCP, Azure), VPN, PAM, RADIUS, and application authentication logs.
• ITDR Detection Engine: Analyzes identity events in real-time and near-real-time, applying detection rules, behavioral analytics, and machine learning models.
• Alert Correlation: Correlates individual identity signals into attack narratives (e.g., password spray followed by MFA bypass followed by privilege escalation = likely compromise).
• Response Orchestration: Integrates with SOAR platforms to automate containment actions (disable account, revoke sessions, force re-authentication, block IP).
• Identity Posture Management: Continuously assesses the security configuration of identity infrastructure (AD misconfigurations, overprivileged accounts, stale credentials).

Data flow: Identity systems generate events -> Events stream to SIEM/ITDR platform -> Detection rules evaluate events -> Alerts fire for suspicious activity -> SOC analysts investigate -> Response playbooks execute containment and remediation actions.

The ITDR platform can be a dedicated product (CrowdStrike Falcon Identity, Microsoft Defender for Identity, Semperis) or a set of detection rules and playbooks built on your existing SIEM (Splunk, Sentinel, Chronicle).

Step-by-Step Implementation

Step 1: Instrument Identity Data Sources

The quality of your detection depends on the quality of your data. Enable comprehensive logging on every identity system:

Active Directory:

# Enable advanced audit policy via Group Policy
# Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy

# Critical audit categories:
# Account Logon:
#   - Audit Credential Validation: Success and Failure
#   - Audit Kerberos Authentication Service: Success and Failure
#   - Audit Kerberos Service Ticket Operations: Success and Failure

# Account Management:
#   - Audit User Account Management: Success and Failure
#   - Audit Security Group Management: Success and Failure

# Logon/Logoff:
#   - Audit Logon: Success and Failure
#   - Audit Special Logon: Success

# Directory Service Access:
#   - Audit Directory Service Changes: Success

# Verify audit policy is applied
auditpol /get /category:*

Cloud IdP (example: Okta):

{
  "log_streaming": {
    "destination": "siem",
    "event_types": [
      "user.authentication.sso",
      "user.authentication.auth_via_mfa",
      "user.session.start",
      "user.account.lock",
      "user.mfa.factor.update",
      "policy.evaluate_sign_on",
      "application.user_membership.add",
      "group.user_membership.add",
      "system.api_token.create",
      "user.account.privilege.grant"
    ],
    "format": "json",
    "real_time": true
  }
}

Cloud IAM (AWS CloudTrail):

{
  "Trail": {
    "Name": "identity-events",
    "S3BucketName": "security-logs",
    "IsMultiRegionTrail": true,
    "EventSelectors": [
      {
        "ReadWriteType": "All",
        "IncludeManagementEvents": true,
        "DataResources": [
          {
            "Type": "AWS::IAM::Role",
            "Values": ["arn:aws:iam::*"]
          }
        ]
      }
    ]
  }
}

Step 2: Build Core Detection Rules

Start with high-fidelity detection rules for the most common identity attack techniques:

Detection: Password Spray Attack

rule:
  name: "Password Spray Detected"
  description: "Multiple accounts experiencing failed authentication from same source in short window"
  data_source: "idp_authentication_logs"
  logic: |
    SELECT source_ip, COUNT(DISTINCT username) as unique_users, COUNT(*) as total_failures
    FROM auth_events
    WHERE event_type = 'authentication_failure'
      AND timestamp > NOW() - INTERVAL '10 minutes'
    GROUP BY source_ip
    HAVING unique_users > 10 AND total_failures > 25
  severity: high
  mitre_att_ck: "T1110.003"
  response: "password_spray_playbook"

Detection: Impossible Travel

rule:
  name: "Impossible Travel Detected"
  description: "User authenticated from two geographically distant locations within an impossible timeframe"
  data_source: "idp_authentication_logs"
  logic: |
    WITH user_logins AS (
      SELECT username, source_ip, geo_location, timestamp,
        LAG(geo_location) OVER (PARTITION BY username ORDER BY timestamp) as prev_location,
        LAG(timestamp) OVER (PARTITION BY username ORDER BY timestamp) as prev_timestamp
      FROM auth_events
      WHERE event_type = 'authentication_success'
    )
    SELECT * FROM user_logins
    WHERE geo_distance(geo_location, prev_location) > 500  -- km
      AND EXTRACT(EPOCH FROM (timestamp - prev_timestamp)) / 3600 < 2  -- hours
  severity: high
  mitre_att_ck: "T1078"
  response: "impossible_travel_playbook"

Detection: Kerberoasting

rule:
  name: "Kerberoasting Activity Detected"
  description: "Excessive TGS requests for service accounts with RC4 encryption from single source"
  data_source: "windows_security_log"
  logic: |
    Event ID 4769 (Kerberos Service Ticket Requested)
    WHERE TicketEncryptionType = 0x17 (RC4)
      AND ServiceName NOT LIKE '%$'  -- Exclude machine accounts
      AND COUNT(DISTINCT ServiceName) > 5 WITHIN 5 minutes FROM same IpAddress
  severity: critical
  mitre_att_ck: "T1558.003"
  response: "kerberoasting_playbook"

Detection: DCSync Attack

rule:
  name: "DCSync Attack Detected"
  description: "Non-domain-controller machine requesting directory replication"
  data_source: "windows_security_log"
  logic: |
    Event ID 4662 (Directory Service Access)
    WHERE Properties CONTAINS '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2'  -- DS-Replication-Get-Changes
      OR Properties CONTAINS '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2'   -- DS-Replication-Get-Changes-All
      AND SubjectUserName NOT IN (known_domain_controllers)
  severity: critical
  mitre_att_ck: "T1003.006"
  response: "dcsync_playbook"

Detection: MFA Fatigue Attack

rule:
  name: "MFA Fatigue Attack Detected"
  description: "Multiple MFA push notifications sent to same user in short period with repeated denials"
  data_source: "idp_mfa_logs"
  logic: |
    SELECT username, COUNT(*) as push_count,
      SUM(CASE WHEN result = 'denied' THEN 1 ELSE 0 END) as denied_count
    FROM mfa_events
    WHERE factor_type = 'push'
      AND timestamp > NOW() - INTERVAL '10 minutes'
    GROUP BY username
    HAVING push_count > 5 AND denied_count > 3
  severity: high
  mitre_att_ck: "T1621"
  response: "mfa_fatigue_playbook"

Detection: Privilege Escalation via Group Membership

rule:
  name: "Sensitive Group Membership Change"
  description: "User added to privileged group outside of change window"
  data_source: "active_directory_logs"
  logic: |
    Event ID 4728 (Member Added to Security Group)
    WHERE TargetGroupName IN (
      'Domain Admins', 'Enterprise Admins', 'Schema Admins',
      'Account Operators', 'Backup Operators', 'Server Operators'
    )
    AND NOT within_change_window()
    AND SubjectUserName NOT IN (authorized_identity_admins)
  severity: critical
  mitre_att_ck: "T1078.002"
  response: "privilege_escalation_playbook"

Step 3: Implement Behavioral Analytics

Rule-based detection catches known patterns. Behavioral analytics catches unknown patterns:

• Authentication baseline: Build a profile of each user's normal authentication behavior (time of day, source IP ranges, applications accessed, geographic locations). Alert on deviations.
• Access pattern baseline: Track which resources each user normally accesses. Alert when a user accesses a resource they have never accessed before, especially if it is a sensitive resource.
• Velocity anomalies: Detect sudden increases in authentication events, group membership changes, or permission modifications that exceed normal rates.
• Peer group analysis: Compare a user's behavior to their peer group (same department, same role). If one member of the Finance team suddenly starts accessing engineering resources, that is anomalous.

# Simplified behavioral anomaly detection
def detect_anomaly(user_id, event):
    baseline = get_user_baseline(user_id)

    # Check for unusual login time
    if not baseline.is_normal_hour(event.timestamp.hour):
        create_alert("unusual_login_time", user_id, event, severity="medium")

    # Check for new source IP
    if event.source_ip not in baseline.known_ips:
        create_alert("new_source_ip", user_id, event, severity="medium")

    # Check for first-time resource access
    if event.resource not in baseline.accessed_resources:
        if event.resource in sensitive_resources:
            create_alert("new_sensitive_resource_access", user_id, event, severity="high")

    # Check for velocity anomaly
    recent_event_count = count_events(user_id, last_minutes=30)
    if recent_event_count > baseline.avg_30min_events * 3:
        create_alert("velocity_anomaly", user_id, event, severity="high")

Step 4: Build Response Playbooks

Detection without response is just expensive logging. Build automated and semi-automated response playbooks:

Playbook: Password Spray Response

playbook:
  name: "Password Spray Response"
  trigger: "password_spray_detected"
  steps:
    - action: "block_source_ip"
      target: "firewall, waf"
      parameters:
        ip: "{{ alert.source_ip }}"
        duration: "24h"

    - action: "identify_compromised_accounts"
      description: "Find accounts that authenticated successfully from the spray source"
      query: |
        SELECT username FROM auth_events
        WHERE source_ip = '{{ alert.source_ip }}'
          AND event_type = 'authentication_success'
          AND timestamp BETWEEN '{{ alert.start_time }}' AND '{{ alert.end_time }}'

    - action: "force_password_reset"
      target: "compromised_accounts"
      description: "Reset passwords for any account that authenticated from the spray source"

    - action: "revoke_sessions"
      target: "compromised_accounts"

    - action: "notify_soc"
      message: "Password spray from {{ alert.source_ip }}. {{ compromised_count }} accounts potentially compromised. Containment actions executed."

    - action: "create_incident_ticket"
      severity: "high"

Playbook: Compromised Account Response

playbook:
  name: "Compromised Account Response"
  trigger: "account_compromise_confirmed"
  steps:
    - action: "disable_account"
      target: "{{ alert.username }}"
      systems: ["active_directory", "idp", "cloud_iam"]

    - action: "revoke_all_sessions"
      target: "{{ alert.username }}"

    - action: "revoke_all_tokens"
      target: "{{ alert.username }}"
      systems: ["oauth_server", "saml_idp"]

    - action: "reset_mfa"
      target: "{{ alert.username }}"

    - action: "audit_recent_activity"
      target: "{{ alert.username }}"
      window: "72h"
      description: "Gather all actions taken by this account in the last 72 hours for forensic analysis"

    - action: "check_lateral_movement"
      description: "Identify systems the compromised account accessed and check for persistence"

    - action: "notify_user_manager"
      message: "{{ alert.username }}'s account has been disabled due to suspected compromise. Contact the security team for re-enablement."

    - action: "escalate_to_ir_team"
      if: "lateral_movement_detected OR sensitive_data_accessed"

Step 5: Establish Identity Posture Management

ITDR is not only about detecting active attacks. It also involves continuously assessing and improving the security posture of your identity infrastructure:

• AD security assessment: Regularly scan for AD misconfigurations: unconstrained delegation, SPNs on privileged accounts, AdminCount without AdminSDHolder protection, weak Kerberos configurations.
• IdP configuration review: Audit authentication policies, conditional access rules, and administrative access quarterly.
• Stale identity cleanup: Identify and disable accounts that have not authenticated in 90 days.
• Privilege creep review: Quarterly access reviews for privileged group memberships and role assignments.

# Example AD posture checks
# Find accounts with unconstrained delegation (attack target for Kerberos delegation attacks)
Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation |
  Select-Object Name, TrustedForDelegation

# Find SPNs on privileged accounts (Kerberoasting targets)
Get-ADUser -Filter {ServicePrincipalName -ne "$null" -and AdminCount -eq 1} `
  -Properties ServicePrincipalName |
  Select-Object Name, ServicePrincipalName

# Find accounts with passwords older than 1 year
Get-ADUser -Filter {Enabled -eq $true -and PasswordLastSet -lt $((Get-Date).AddDays(-365))} `
  -Properties PasswordLastSet |
  Select-Object Name, PasswordLastSet

Configuration Best Practices

• Tune before you alert. Run detection rules in logging-only mode for 2-4 weeks to establish baselines and eliminate false positives before enabling alerting.
• Prioritize high-fidelity rules. Start with DCSync, Golden Ticket, and Kerberoasting detection — these have high true-positive rates and indicate serious compromise.
• Correlate across sources. A single failed login is noise. A failed login from a new IP followed by a successful login followed by a privilege escalation is a story. Build correlation rules that chain events.
• Automate containment. For high-confidence, high-severity detections (DCSync from a non-DC, Golden Ticket usage), automate containment (disable account, isolate host) without waiting for human approval.
• Maintain detection rule hygiene. Review and update detection rules quarterly. Attackers evolve their techniques, and your detections must evolve with them.

Testing and Validation

1. Purple team exercises: Simulate identity attacks (password spray, Kerberoasting, DCSync) in a controlled environment and verify that detection rules fire correctly.
2. Detection coverage mapping: Map your detection rules to the MITRE ATT&CK framework. Identify gaps in coverage for identity-related techniques.
3. Playbook dry runs: Walk through each response playbook as a tabletop exercise with the SOC team before an actual incident.
4. False positive analysis: After 30 days of operation, review all alerts. Calculate the false positive rate and tune rules to reduce noise.
5. Mean time to detect (MTTD): Measure how long it takes from attack execution to alert firing. Target under 5 minutes for critical detections.
6. Mean time to respond (MTTR): Measure how long it takes from alert to containment. Automated playbooks should achieve under 2 minutes.

Common Pitfalls and Troubleshooting

| Pitfall | Impact | Mitigation | |---------|--------|------------| | Insufficient AD logging | Critical attacks go undetected | Enable advanced audit policies; verify events appear in SIEM | | Alert fatigue from noisy rules | SOC ignores identity alerts | Tune aggressively; suppress known false positives; prioritize high-fidelity rules | | No correlation across identity sources | Attack narrative fragmented | Normalize identity events to a common schema; correlate on username + time window | | Automated response without guardrails | False positive triggers account lockout | Require high confidence threshold for automated actions; build in human approval for borderline cases | | Stale baselines | Behavioral models produce false positives after legitimate changes | Retrain baselines monthly; account for organizational changes (new hires, role changes) |

Security Considerations

1. Protect the ITDR platform. If attackers compromise your detection platform, they can suppress alerts while conducting their attack. Treat the ITDR platform as critical infrastructure with dedicated admin accounts and MFA.
2. Log integrity. Attackers who compromise AD can potentially tamper with security logs. Forward logs to a write-once/append-only store (immutable storage) to preserve forensic evidence.
3. Insider threat detection. ITDR should detect not only external attackers but also malicious insiders who use their legitimate credentials for unauthorized purposes. Behavioral analytics is essential for this use case.
4. Privacy considerations. Behavioral monitoring touches on employee privacy. Work with legal and HR to ensure your ITDR program complies with local privacy laws and internal policies.
5. Detection evasion. Sophisticated attackers will attempt to evade detection by operating slowly (low-and-slow attacks), using legitimate tools (living off the land), or compromising monitoring agents. Layer multiple detection approaches (rules, behavioral analytics, deception) to increase coverage.

Conclusion

ITDR is not optional — it is the natural evolution of security operations in an identity-centric world. As organizations move to zero trust architectures and identity becomes the primary security perimeter, the ability to detect and respond to identity-based attacks becomes as important as endpoint detection and network monitoring.

Start with the fundamentals: instrument your identity data sources, build high-fidelity detection rules for known attack patterns, and create response playbooks that contain threats quickly. Then layer in behavioral analytics for unknown patterns and posture management for preventive controls. Each capability you add reduces your exposure to identity-based attacks.

FAQs

Q: Do I need a dedicated ITDR product or can I build on my existing SIEM? A: You can build effective ITDR on your existing SIEM (Splunk, Sentinel, Chronicle) using custom detection rules. Dedicated ITDR products (CrowdStrike Falcon Identity, Microsoft Defender for Identity) add pre-built detections, AD-specific sensors, and identity-focused analytics that accelerate deployment. The choice depends on your team's capacity and budget.

Q: What are the highest-priority detection rules to deploy first? A: DCSync detection, Kerberoasting detection, password spray detection, privilege escalation (sensitive group changes), and impossible travel. These cover the most common and impactful identity attack techniques.

Q: How do I handle the volume of identity events? A: Identity event volumes can be massive (millions per day in large enterprises). Use event filtering at the source to forward only security-relevant events. Use tiered storage (hot for 30 days, warm for 1 year) to manage costs while retaining forensic data.

Q: Should automated response disable accounts without human approval? A: For high-confidence, high-severity detections (DCSync from a non-DC, Golden Ticket), yes — the risk of not acting immediately exceeds the risk of a false positive. For medium-confidence detections, require human approval within a time-bounded SLA.

Q: How does ITDR relate to XDR? A: ITDR is a specialized capability that can operate standalone or as a component of an XDR (Extended Detection and Response) platform. XDR correlates signals across endpoint, network, email, and identity. ITDR provides the identity-specific depth that generic XDR may lack.