User account exposed to Kerberoasting
Detects when a user account has the servicePrincipalName attribute modified. Attackers can abuse write privileges over a user to configure Service Principle Names (SPNs) so that they can perform Kerberoasting. Administrators can also configure this for legitimate purposes, exposing the account to Kerberoasting.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2022/02/22"
3integration = ["system", "windows"]
4maturity = "production"
5updated_date = "2024/10/28"
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 = """
12Detects when a user account has the servicePrincipalName attribute modified. Attackers can abuse write privileges over a
13user to configure Service Principle Names (SPNs) so that they can perform Kerberoasting. Administrators can also
14configure this for legitimate purposes, exposing the account to Kerberoasting.
15"""
16from = "now-9m"
17index = ["winlogbeat-*", "logs-system.*", "logs-windows.*"]
18language = "kuery"
19license = "Elastic License v2"
20name = "User account exposed to Kerberoasting"
21note = """## Triage and analysis
22
23### Investigating User account exposed to Kerberoasting
24
25Service Principal Names (SPNs) are names by which Kerberos clients uniquely identify service instances for Kerberos target computers.
26
27By default, only computer accounts have SPNs, which creates no significant risk, since machine accounts have a default domain policy that rotates their passwords every 30 days, and the password is composed of 120 random characters, making them invulnerable to Kerberoasting.
28
29A user account with an SPN assigned is considered a service account, and is accessible to the entire domain. If any user in the directory requests a ticket-granting service (TGS), the domain controller will encrypt it with the secret key of the account executing the service. An attacker can potentially perform a Kerberoasting attack with this information, as the human-defined password is likely to be less complex.
30
31For scenarios where SPNs cannot be avoided on user accounts, Microsoft provides the Group Managed Service Accounts (gMSA) feature, which ensures that account passwords are robust and changed regularly and automatically. More information can be found [here](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview).
32
33Attackers can also perform "Targeted Kerberoasting", which consists of adding fake SPNs to user accounts that they have write privileges to, making them potentially vulnerable to Kerberoasting.
34
35#### Possible investigation steps
36
37- Identify the user account that performed the action and whether it should perform this kind of action.
38- Contact the account owner and confirm whether they are aware of this activity.
39- Investigate if the target account is a member of privileged groups (Domain Admins, Enterprise Admins, etc.).
40- Investigate if tickets have been requested for the target account.
41- Investigate other alerts associated with the user/host during the past 48 hours.
42
43### False positive analysis
44
45- The use of user accounts as service accounts is a bad security practice and should not be allowed in the domain. The security team should map and monitor any potential benign true positive (B-TP), especially if the account is privileged. Domain Administrators that define this kind of setting can put the domain at risk as user accounts don't have the same security standards as computer accounts (which have long, complex, random passwords that change frequently), exposing them to credential cracking attacks (Kerberoasting, brute force, etc.).
46
47### Response and remediation
48
49- Initiate the incident response process based on the outcome of the triage.
50- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. Prioritize privileged accounts.
51- Isolate the involved hosts to prevent further post-compromise behavior.
52- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
53- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
54"""
55references = [
56 "https://www.thehacker.recipes/ad/movement/access-controls/targeted-kerberoasting",
57 "https://www.qomplx.com/qomplx-knowledge-kerberoasting-attacks-explained/",
58 "https://www.thehacker.recipes/ad/movement/kerberos/kerberoast",
59 "https://attack.stealthbits.com/cracking-kerberos-tgs-tickets-using-kerberoasting",
60 "https://adsecurity.org/?p=280",
61 "https://github.com/OTRF/Set-AuditRule",
62]
63risk_score = 73
64rule_id = "0b2f3da5-b5ec-47d1-908b-6ebb74814289"
65setup = """## Setup
66
67The 'Audit Directory Service Changes' logging policy must be configured for (Success, Failure).
68Steps to implement the logging policy with Advanced Audit Configuration:
Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policies Configuration > Audit Policies > DS Access > Audit Directory Service Changes (Success,Failure)
1
2The above policy does not cover User objects, so set up an AuditRule using https://github.com/OTRF/Set-AuditRule.
3As this specifies the servicePrincipalName Attribute GUID, it is expected to be low noise.
Set-AuditRule -AdObjectPath 'AD:\CN=Users,DC=Domain,DC=com' -WellKnownSidType WorldSid -Rights WriteProperty -InheritanceFlags Children -AttributeGUID f3a64788-5306-11d1-a9c5-0000f80367c1 -AuditFlags Success
1"""
2severity = "high"
3tags = [
4 "Domain: Endpoint",
5 "OS: Windows",
6 "Use Case: Threat Detection",
7 "Tactic: Credential Access",
8 "Data Source: Active Directory",
9 "Resources: Investigation Guide",
10 "Use Case: Active Directory Monitoring",
11 "Data Source: System",
12]
13timestamp_override = "event.ingested"
14type = "query"
15
16query = '''
17event.action:("Directory Service Changes" or "directory-service-object-modified") and event.code:5136 and
18 winlog.event_data.OperationType:"%%14674" and
19 winlog.event_data.ObjectClass:"user" and
20 winlog.event_data.AttributeLDAPDisplayName:"servicePrincipalName"
21'''
22
23
24[[rule.threat]]
25framework = "MITRE ATT&CK"
26[[rule.threat.technique]]
27id = "T1558"
28name = "Steal or Forge Kerberos Tickets"
29reference = "https://attack.mitre.org/techniques/T1558/"
30[[rule.threat.technique.subtechnique]]
31id = "T1558.003"
32name = "Kerberoasting"
33reference = "https://attack.mitre.org/techniques/T1558/003/"
34
35
36
37[rule.threat.tactic]
38id = "TA0006"
39name = "Credential Access"
40reference = "https://attack.mitre.org/tactics/TA0006/"
Triage and analysis
Investigating User account exposed to Kerberoasting
Service Principal Names (SPNs) are names by which Kerberos clients uniquely identify service instances for Kerberos target computers.
By default, only computer accounts have SPNs, which creates no significant risk, since machine accounts have a default domain policy that rotates their passwords every 30 days, and the password is composed of 120 random characters, making them invulnerable to Kerberoasting.
A user account with an SPN assigned is considered a service account, and is accessible to the entire domain. If any user in the directory requests a ticket-granting service (TGS), the domain controller will encrypt it with the secret key of the account executing the service. An attacker can potentially perform a Kerberoasting attack with this information, as the human-defined password is likely to be less complex.
For scenarios where SPNs cannot be avoided on user accounts, Microsoft provides the Group Managed Service Accounts (gMSA) feature, which ensures that account passwords are robust and changed regularly and automatically. More information can be found here.
Attackers can also perform "Targeted Kerberoasting", which consists of adding fake SPNs to user accounts that they have write privileges to, making them potentially vulnerable to Kerberoasting.
Possible investigation steps
- Identify the user account that performed the action and whether it should perform this kind of action.
- Contact the account owner and confirm whether they are aware of this activity.
- Investigate if the target account is a member of privileged groups (Domain Admins, Enterprise Admins, etc.).
- Investigate if tickets have been requested for the target account.
- Investigate other alerts associated with the user/host during the past 48 hours.
False positive analysis
- The use of user accounts as service accounts is a bad security practice and should not be allowed in the domain. The security team should map and monitor any potential benign true positive (B-TP), especially if the account is privileged. Domain Administrators that define this kind of setting can put the domain at risk as user accounts don't have the same security standards as computer accounts (which have long, complex, random passwords that change frequently), exposing them to credential cracking attacks (Kerberoasting, brute force, etc.).
Response and remediation
- Initiate the incident response process based on the outcome of the triage.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. Prioritize privileged accounts.
- Isolate the involved hosts to prevent further post-compromise behavior.
- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
References
Related rules
- FirstTime Seen Account Performing DCSync
- Kerberos Pre-authentication Disabled for User
- Potential Shadow Credentials added to AD Object
- Sensitive Privilege SeEnableDelegationPrivilege assigned to a User
- Potential Credential Access via DCSync