Identity Threat Detection and Response (ITDR) Guide

Stolen and abused credentials are among the most common ways attackers get in, 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, Microsoft Entra ID, 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, Microsoft Entra ID, Okta, cloud IAM (AWS, GCP, Azure), VPN, PAM, RADIUS, and application authentication logs. Identity providers that support the Shared Signals Framework can also push RISC account events, such as credential compromise or sessions revoked, instead of waiting for a log pull.
• 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 Protection, Microsoft Defender for Identity, Semperis) or a set of detection rules and playbooks built on your existing SIEM (Splunk, Sentinel, Google Security Operations).

Step-by-Step Implementation

Step 1: Instrument Identity Data Sources

The quality of your detection depends on the quality of your data. Enable complete 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, typically 2-4 weeks as a practitioner estimate, 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. A typical practitioner target, not a measured benchmark, is under 5 minutes for critical detections.
6. Mean time to respond (MTTR): Measure how long it takes from alert to containment. As a practitioner estimate, automated playbooks should achieve under 2 minutes.

Common Pitfalls and Troubleshooting

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.