sigma-rules/rules/windows/credential_access_spn_attribute_modified.toml

[metadata]
creation_date = "2022/02/22"
maturity = "production"
updated_date = "2022/02/22"

[rule]
author = ["Elastic"]
description = """
Detects when a user account has the servicePrincipalName attribute modified. Attackers can abuse write privileges over a
user to configure SPNs so that they can perform Kerberoasting. Administrators can also configure this for legitimate
purposes, exposing the account to Kerberoasting.
"""
from = "now-9m"
index = ["winlogbeat-*", "logs-system.*"]
language = "kuery"
license = "Elastic License v2"
name = "User account exposed to Kerberoasting"
note = """## Triage and analysis.

### Investigating User account exposed to Kerberoasting

Service principal names (SPNs) is the name by which a Kerberos client uniquely identifies an instance of a service for a
given Kerberos target computer. 

By default, only computer accounts have SPNs, and there is no significant risk about this, as machine accounts have a
default domain policy that configures these accounts to rotate their passwords every 30 days, and the password is
compound of 120 random characters, making them not to be vulnerable to Kerberoasting.

So, a user account with an SPN assigned is considered a Service Account, making it available to be accessed by the
entire domain. If any user in the directory requests a 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 more 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 the account password is 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).

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 account that performed the action.
- Check whether this user should be doing this kind of activity.
- 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 related to the user in the last 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 B-TP (Benign True Positive), 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 (Long, complex, random passwords that change frequently) as computer accounts, 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
- Reset the password of the involved accounts. Priority should be given to privileged accounts.
- Quarantine the involved host for forensic investigation, as well as eradication and recovery activities.

## Config

The 'Audit Directory Service Changes' logging policy must be configured for (Success, Failure).
Steps 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)
```

The above policy does not cover User objects, so we need to set up an AuditRule using https://github.com/OTRF/Set-AuditRule.
As 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
```
"""
references = [
    "https://www.thehacker.recipes/ad/movement/access-controls/targeted-kerberoasting",
    "https://www.qomplx.com/qomplx-knowledge-kerberoasting-attacks-explained/",
    "https://www.thehacker.recipes/ad/movement/kerberos/kerberoast",
    "https://attack.stealthbits.com/cracking-kerberos-tgs-tickets-using-kerberoasting",
    "https://adsecurity.org/?p=280",
    "https://github.com/OTRF/Set-AuditRule",
]
risk_score = 73
rule_id = "0b2f3da5-b5ec-47d1-908b-6ebb74814289"
severity = "high"
tags = ["Elastic", "Host", "Windows", "Threat Detection", "Credential Access", "Active Directory"]
timestamp_override = "event.ingested"
type = "query"

query = '''
event.action:"Directory Service Changes" and event.code:5136 and winlog.event_data.ObjectClass:"user" 
and winlog.event_data.AttributeLDAPDisplayName:"servicePrincipalName"
'''


[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1558"
name = "Steal or Forge Kerberos Tickets"
reference = "https://attack.mitre.org/techniques/T1558/"

  [[rule.threat.technique.subtechnique]]
  name = "Kerberoasting"
  id = "T1558.003"
  reference = "https://attack.mitre.org/techniques/T1558/003/"

[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"