Newly Observed RC4 Kerberos Service Ticket Request

  1[metadata]
  2creation_date = "2026/08/04"
  3integration = ["system", "windows"]
  4maturity = "production"
  5updated_date = "2026/08/10"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies a successful RC4-HMAC Kerberos service ticket request for a requester and service pair that has not been
 11observed during the previous 7 days. A newly observed requester-to-service relationship involving an RC4-encrypted
 12ticket may indicate Kerberoasting.
 13"""
 14false_positives = [
 15    """
 16    First-time or infrequent access to legacy services, cross-platform integrations, and inter-domain trust activity may
 17    legitimately establish a new requester-to-service relationship using RC4 encryption.
 18    """,
 19]
 20from = "now-9m"
 21index = ["winlogbeat-*", "logs-system.security*", "logs-windows.forwarded*"]
 22language = "kuery"
 23license = "Elastic License v2"
 24name = "Newly Observed RC4 Kerberos Service Ticket Request"
 25note = """ ## Triage and analysis
 26
 27> **Disclaimer**:
 28> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
 29
 30### Investigating Newly Observed RC4 Kerberos Service Ticket Request
 31
 32This alert flags a successful Windows Kerberos service ticket request that used legacy RC4 encryption for a requester-to-service pairing not seen in the last week. It matters because RC4 tickets are easier for attackers to crack offline, and a new pairing can reveal account targeting rather than normal application behavior. A common pattern is an intruder using a low-privileged domain account to request RC4 tickets for SPN-backed service accounts, then extracting password hashes for Kerberoasting.
 33
 34### Possible investigation steps
 35
 36- Validate whether the requester, source host, and service account relationship aligns with a known application change, scheduled task, or newly deployed system, because legitimate first-seen pairings often coincide with onboarding or configuration work.
 37- Review recent authentication activity for the requester across domain controllers for bursts of service ticket requests to multiple SPNs, especially privileged or human-managed service accounts, which is a strong Kerberoasting pattern.
 38- Pivot on the requesting host and user for adjacent suspicious behavior such as interactive logons from unusual systems, PowerShell or script execution, remote administration activity, credential dumping alerts, or other Active Directory enumeration in the same timeframe.
 39- Examine the targeted service account’s privilege level, password age, SPN exposure, delegation settings, and whether it still permits RC4, then prioritize escalation if the account is highly privileged, old, or tied to critical services.
 40- If the activity is not readily explained, contain the requester and source system as appropriate and rotate the service account credentials while planning to disable RC4 support and enforce stronger Kerberos encryption for affected accounts.
 41
 42### False positive analysis
 43
 44- A newly deployed or reconfigured Windows service, scheduled task, or application host can create a first-seen requester-to-service pairing against a legacy SPN that still uses RC4, so verify recent change activity and confirm the requester, source host, and service account match the expected business function.
 45- An infrequently run maintenance or batch process may legitimately request an RC4 service ticket after more than seven days of inactivity, so confirm the event time aligns with its normal schedule and review adjacent 4769 activity to ensure the account is only accessing its usual limited set of services.
 46
 47### Response and remediation
 48
 49- Isolate the requesting host and any other systems used by the compromised account from the network, block remote administration access, and preserve volatile and disk evidence before rebooting or rebuilding them.
 50- Disable the compromised requester account and the targeted service account, rotate passwords or keys for every exposed SPN-backed service they can access, and force logoff or ticket purge so previously issued Kerberos tickets cannot be reused.
 51- Remove attacker persistence by reviewing and deleting unauthorized scheduled tasks, services, startup items, WMI event subscriptions, remote access tools, Run key entries, and any newly granted local or domain group memberships tied to the affected identities or hosts.
 52- Restore affected endpoints and servers to a known-good state by reimaging compromised systems or rolling back unauthorized changes, then verify business applications start cleanly with the newly rotated service credentials.
 53- Escalate to incident response immediately if the targeted service account is privileged, tied to domain controllers or other Tier 0 systems, or if you also find credential dumping, lateral movement, multiple unusual SPN requests, or forged-ticket activity.
 54- Harden the environment by disabling RC4 where legacy dependencies permit it, enforcing AES-only Kerberos encryption on service accounts, migrating eligible services to gMSAs, reducing excessive service account privileges and SPNs, and adding detections for unusual service ticket bursts and new requester-to-service relationships.
 55"""
 56references = [
 57    "https://learn.microsoft.com/en-us/windows-server/security/kerberos/detect-remediate-rc4-kerberos",
 58]
 59risk_score = 47
 60rule_id = "57bc9e8d-9054-472c-9752-4aa91dc4cd49"
 61setup = """## Setup
 62
 63Audit Kerberos Service Ticket Operations must be enabled to generate the events used by this rule.
 64Setup instructions: https://ela.st/audit-kerberos-service-ticket-operations
 65"""
 66severity = "medium"
 67tags = [
 68    "Domain: Identity",
 69    "OS: Windows",
 70    "Use Case: Threat Detection",
 71    "Tactic: Credential Access",
 72    "Use Case: Active Directory Monitoring",
 73    "Data Source: Active Directory",
 74    "Data Source: Windows Security Event Logs",
 75    "Resources: Investigation Guide",
 76]
 77timestamp_override = "event.ingested"
 78type = "new_terms"
 79
 80query = '''
 81host.os.type:windows and event.category:authentication and event.code:4769 and
 82  winlog.event_data.Status:0x0 and winlog.event_data.TicketEncryptionType:0x17 and
 83  winlog.event_data.TargetUserName:* and
 84  winlog.event_data.ServiceName:(* and not (krbtgt or *$)) and
 85  not (winlog.event_data.TargetUserName:*$@* and source.ip:(127.0.0.0/8 or "::1"))
 86'''
 87
 88
 89[[rule.threat]]
 90framework = "MITRE ATT&CK"
 91
 92[[rule.threat.technique]]
 93id = "T1558"
 94name = "Steal or Forge Kerberos Tickets"
 95reference = "https://attack.mitre.org/techniques/T1558/"
 96[[rule.threat.technique.subtechnique]]
 97id = "T1558.003"
 98name = "Kerberoasting"
 99reference = "https://attack.mitre.org/techniques/T1558/003/"
100
101[rule.threat.tactic]
102id = "TA0006"
103name = "Credential Access"
104reference = "https://attack.mitre.org/tactics/TA0006/"
105
106[rule.new_terms]
107field = "new_terms_fields"
108value = ["winlog.event_data.TargetUserName", "winlog.event_data.ServiceName"]
109[[rule.new_terms.history_window_start]]
110field = "history_window_start"
111value = "now-7d"