Service Creation via Local Kerberos Authentication

  1[metadata]
  2creation_date = "2022/04/27"
  3integration = ["system", "windows"]
  4maturity = "production"
  5updated_date = "2025/03/20"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies a suspicious local successful logon event where the Logon Package is Kerberos, the remote address is set to
 11localhost, followed by a sevice creation from the same LogonId. This may indicate an attempt to leverage a Kerberos
 12relay attack variant that can be used to elevate privilege locally from a domain joined user to local System privileges.
 13"""
 14from = "now-9m"
 15index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
 16language = "eql"
 17license = "Elastic License v2"
 18name = "Service Creation via Local Kerberos Authentication"
 19note = """## Triage and analysis
 20
 21> **Disclaimer**:
 22> 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.
 23
 24### Investigating Service Creation via Local Kerberos Authentication
 25
 26Kerberos is a network authentication protocol designed to provide strong authentication for client/server applications. In Windows environments, it is often used for secure identity verification. Adversaries may exploit Kerberos by relaying authentication tickets locally to escalate privileges, potentially creating services with elevated rights. The detection rule identifies suspicious local logons using Kerberos, followed by service creation, indicating possible misuse. By monitoring specific logon events and service installations, it helps detect unauthorized privilege escalation attempts.
 27
 28### Possible investigation steps
 29
 30- Review the event logs for the specific LogonId identified in the alert to gather details about the logon session, including the user account involved and the time of the logon event.
 31- Examine the source IP address and port from the logon event to confirm it matches the localhost (127.0.0.1 or ::1) and determine if this aligns with expected behavior for the user or system.
 32- Investigate the service creation event (event ID 4697) associated with the same LogonId to identify the service name, executable path, and any related command-line arguments to assess if it is legitimate or potentially malicious.
 33- Check for any recent changes or anomalies in the system or user account, such as modifications to user privileges, group memberships, or recent software installations, that could indicate unauthorized activity.
 34- Correlate the findings with other security alerts or logs from the same timeframe to identify any patterns or additional indicators of compromise that may suggest a broader attack or compromise.
 35
 36### False positive analysis
 37
 38- Routine administrative tasks may trigger the rule if administrators frequently log in locally using Kerberos and create services as part of their duties. To manage this, create exceptions for known administrative accounts or specific service creation activities that are part of regular maintenance.
 39- Automated scripts or software updates that use Kerberos authentication and subsequently install or update services can also generate false positives. Identify these scripts or update processes and exclude their associated logon IDs from the rule.
 40- Security software or monitoring tools that perform regular checks and use Kerberos for authentication might inadvertently trigger the rule. Review the behavior of these tools and whitelist their activities if they are verified as non-threatening.
 41- In environments where localhost is used for testing or development purposes, developers might log in using Kerberos and create services. Consider excluding specific development machines or user accounts from the rule to prevent unnecessary alerts.
 42
 43### Response and remediation
 44
 45- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation.
 46- Terminate any suspicious services created during the incident to halt potential malicious activities.
 47- Conduct a thorough review of the affected system's event logs, focusing on the specific LogonId and service creation events to identify the scope of the compromise.
 48- Reset the credentials of the compromised user account and any other accounts that may have been accessed using the relayed Kerberos tickets.
 49- Apply patches and updates to the affected system and any other systems in the network to address known vulnerabilities that could be exploited in similar attacks.
 50- Implement network segmentation to limit the ability of attackers to move laterally within the network, reducing the risk of privilege escalation.
 51- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation efforts are undertaken."""
 52references = [
 53    "https://github.com/Dec0ne/KrbRelayUp",
 54    "https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html",
 55    "https://github.com/cube0x0/KrbRelay",
 56    "https://gist.github.com/tyranid/c24cfd1bd141d14d4925043ee7e03c82",
 57]
 58risk_score = 73
 59rule_id = "e4e31051-ee01-4307-a6ee-b21b186958f4"
 60severity = "high"
 61tags = [
 62    "Domain: Endpoint",
 63    "OS: Windows",
 64    "Use Case: Threat Detection",
 65    "Tactic: Privilege Escalation",
 66    "Tactic: Credential Access",
 67    "Use Case: Active Directory Monitoring",
 68    "Data Source: Active Directory",
 69    "Data Source: Windows Security Event Logs",
 70    "Resources: Investigation Guide",
 71]
 72type = "eql"
 73
 74query = '''
 75sequence by winlog.computer_name with maxspan=5m
 76 [authentication where
 77
 78  /* event 4624 need to be logged */
 79  event.action == "logged-in" and event.outcome == "success" and
 80
 81  /* authenticate locally using relayed kerberos Ticket */
 82  winlog.event_data.AuthenticationPackageName :"Kerberos" and winlog.logon.type == "Network" and
 83  cidrmatch(source.ip, "127.0.0.0/8", "::1") and source.port > 0] by winlog.event_data.TargetLogonId
 84
 85  [any where
 86   /* event 4697 need to be logged */
 87   event.action : "service-installed"] by winlog.event_data.SubjectLogonId
 88'''
 89
 90
 91[[rule.threat]]
 92framework = "MITRE ATT&CK"
 93[[rule.threat.technique]]
 94id = "T1543"
 95name = "Create or Modify System Process"
 96reference = "https://attack.mitre.org/techniques/T1543/"
 97[[rule.threat.technique.subtechnique]]
 98id = "T1543.003"
 99name = "Windows Service"
100reference = "https://attack.mitre.org/techniques/T1543/003/"
101
102
103
104[rule.threat.tactic]
105id = "TA0004"
106name = "Privilege Escalation"
107reference = "https://attack.mitre.org/tactics/TA0004/"
108[[rule.threat]]
109framework = "MITRE ATT&CK"
110[[rule.threat.technique]]
111id = "T1558"
112name = "Steal or Forge Kerberos Tickets"
113reference = "https://attack.mitre.org/techniques/T1558/"
114
115
116[rule.threat.tactic]
117id = "TA0006"
118name = "Credential Access"
119reference = "https://attack.mitre.org/tactics/TA0006/"