« Newly Observed Process Exhibiting High CPU Usage Newly Observed ScreenConnect Host Server »
Elastic Docs ›Elastic Security [8.19] ›Detections and alerts ›Prebuilt rule reference

Newly Observed RC4 Kerberos Service Ticket Request

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Newly Observed RC4 Kerberos Service Ticket Request

edit

Identifies a successful RC4-HMAC Kerberos service ticket request for a requester and service pair that has not been observed during the previous 7 days. A newly observed requester-to-service relationship involving an RC4-encrypted ticket may indicate Kerberoasting.

Rule type: new_terms

Rule indices:

  • winlogbeat-*
  • logs-system.security*
  • logs-windows.forwarded*

Severity: medium

Risk score: 47

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Identity
  • OS: Windows
  • Use Case: Threat Detection
  • Tactic: Credential Access
  • Use Case: Active Directory Monitoring
  • Data Source: Active Directory
  • Data Source: Windows Security Event Logs
  • Resources: Investigation Guide

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit
## Triage and analysis

Disclaimer: 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.

Investigating Newly Observed RC4 Kerberos Service Ticket Request

This 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.

Possible investigation steps

  • 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.
  • 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.
  • 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.
  • 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.
  • 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.

False positive analysis

  • 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.
  • 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.

Response and remediation

  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.

Setup

edit

Setup

Audit Kerberos Service Ticket Operations must be enabled to generate the events used by this rule. Setup instructions: https://ela.st/audit-kerberos-service-ticket-operations

Rule query

edit
host.os.type:windows and event.category:authentication and event.code:4769 and
  winlog.event_data.Status:0x0 and winlog.event_data.TicketEncryptionType:0x17 and
  winlog.event_data.TargetUserName:* and
  winlog.event_data.ServiceName:(* and not (krbtgt or *$)) and
  not (winlog.event_data.TargetUserName:*$@* and source.ip:(127.0.0.0/8 or "::1"))

Framework: MITRE ATT&CKTM

« Newly Observed Process Exhibiting High CPU Usage Newly Observed ScreenConnect Host Server »