Service Creation via Local Kerberos Authentication
Identifies a suspicious local successful logon event where the Logon Package is Kerberos, the remote address is set to localhost, followed by a sevice creation from the same LogonId. This may indicate an attempt to leverage a Kerberos relay attack variant that can be used to elevate privilege locally from a domain joined user to local System privileges.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2022/04/27"
3integration = ["system", "windows"]
4maturity = "production"
5updated_date = "2025/01/15"
6min_stack_version = "8.14.0"
7min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
8
9[rule]
10author = ["Elastic"]
11description = """
12Identifies a suspicious local successful logon event where the Logon Package is Kerberos, the remote address is set to
13localhost, followed by a sevice creation from the same LogonId. This may indicate an attempt to leverage a Kerberos
14relay attack variant that can be used to elevate privilege locally from a domain joined user to local System privileges.
15"""
16from = "now-9m"
17index = ["winlogbeat-*", "logs-system.*", "logs-windows.*"]
18language = "eql"
19license = "Elastic License v2"
20name = "Service Creation via Local Kerberos Authentication"
21references = [
22 "https://github.com/Dec0ne/KrbRelayUp",
23 "https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html",
24 "https://github.com/cube0x0/KrbRelay",
25 "https://gist.github.com/tyranid/c24cfd1bd141d14d4925043ee7e03c82",
26]
27risk_score = 73
28rule_id = "e4e31051-ee01-4307-a6ee-b21b186958f4"
29severity = "high"
30tags = [
31 "Domain: Endpoint",
32 "OS: Windows",
33 "Use Case: Threat Detection",
34 "Tactic: Privilege Escalation",
35 "Tactic: Credential Access",
36 "Use Case: Active Directory Monitoring",
37 "Data Source: Active Directory",
38 "Data Source: System",
39 "Resources: Investigation Guide",
40]
41type = "eql"
42
43query = '''
44sequence by winlog.computer_name with maxspan=5m
45 [authentication where
46
47 /* event 4624 need to be logged */
48 event.action == "logged-in" and event.outcome == "success" and
49
50 /* authenticate locally using relayed kerberos Ticket */
51 winlog.event_data.AuthenticationPackageName :"Kerberos" and winlog.logon.type == "Network" and
52 cidrmatch(source.ip, "127.0.0.0/8", "::1") and source.port > 0] by winlog.event_data.TargetLogonId
53
54 [any where
55 /* event 4697 need to be logged */
56 event.action : "service-installed"] by winlog.event_data.SubjectLogonId
57'''
58note = """## Triage and analysis
59
60> **Disclaimer**:
61> 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.
62
63### Investigating Service Creation via Local Kerberos Authentication
64
65Kerberos 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.
66
67### Possible investigation steps
68
69- 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.
70- 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.
71- 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.
72- 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.
73- 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.
74
75### False positive analysis
76
77- 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.
78- 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.
79- 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.
80- 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.
81
82### Response and remediation
83
84- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation.
85- Terminate any suspicious services created during the incident to halt potential malicious activities.
86- 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.
87- Reset the credentials of the compromised user account and any other accounts that may have been accessed using the relayed Kerberos tickets.
88- 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.
89- Implement network segmentation to limit the ability of attackers to move laterally within the network, reducing the risk of privilege escalation.
90- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation efforts are undertaken."""
91
92
93[[rule.threat]]
94framework = "MITRE ATT&CK"
95[[rule.threat.technique]]
96id = "T1543"
97name = "Create or Modify System Process"
98reference = "https://attack.mitre.org/techniques/T1543/"
99[[rule.threat.technique.subtechnique]]
100id = "T1543.003"
101name = "Windows Service"
102reference = "https://attack.mitre.org/techniques/T1543/003/"
103
104
105
106[rule.threat.tactic]
107id = "TA0004"
108name = "Privilege Escalation"
109reference = "https://attack.mitre.org/tactics/TA0004/"
110[[rule.threat]]
111framework = "MITRE ATT&CK"
112[[rule.threat.technique]]
113id = "T1558"
114name = "Steal or Forge Kerberos Tickets"
115reference = "https://attack.mitre.org/techniques/T1558/"
116
117
118[rule.threat.tactic]
119id = "TA0006"
120name = "Credential Access"
121reference = "https://attack.mitre.org/tactics/TA0006/"
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 Service Creation via Local Kerberos Authentication
Kerberos 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.
Possible investigation steps
- 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.
- 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.
- 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.
- 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.
- 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.
False positive analysis
- 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.
- 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.
- 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.
- 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.
Response and remediation
- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation.
- Terminate any suspicious services created during the incident to halt potential malicious activities.
- 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.
- Reset the credentials of the compromised user account and any other accounts that may have been accessed using the relayed Kerberos tickets.
- 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.
- Implement network segmentation to limit the ability of attackers to move laterally within the network, reducing the risk of privilege escalation.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation efforts are undertaken.
References
Related rules
- Active Directory Forced Authentication from Linux Host - SMB Named Pipes
- Potential Privileged Escalation via SamAccountName Spoofing
- Potential Relay Attack against a Domain Controller
- Remote Computer Account DnsHostName Update
- Group Policy Abuse for Privilege Addition