Windows AD ServicePrincipalName Added To Domain Account

Description

The following analytic detects the addition of a Service Principal Name (SPN) to a domain account. It leverages Windows Event Code 5136 and monitors changes to the servicePrincipalName attribute. This activity is significant because it may indicate an attempt to perform Kerberoasting, a technique where attackers extract and crack service account passwords offline. If confirmed malicious, this could allow an attacker to obtain cleartext passwords, leading to unauthorized access and potential lateral movement within the domain environment.

Query · spl

`wineventlog_security` EventCode=5136 AttributeLDAPDisplayName=servicePrincipalName OperationType="%%14674" ObjectClass=user | stats values(ObjectDN) as ObjectDN by _time, Computer, SubjectUserName, AttributeValue | rex field=ObjectDN "^CN=(?P<user>[a-zA-Z0-9!#$%&'@^_{}~.-]+)," | rename Computer as dest, SubjectUserName as src_user  | `windows_ad_serviceprincipalname_added_to_domain_account_filter`

Implementation guide

To successfully implement this search, you ned to be ingesting eventcode 5136. The Advanced Security Audit policy setting Audit Directory Services Changes within DS Access needs to be enabled. Additionally, a SACL needs to be created for AD objects in order to ingest attribute modifications.

Known false positives

  • A Service Principal Name should only be added to an account when an application requires it. While infrequent, this detection may trigger on legitimate actions. Filter as needed.

Analyst notes

Known false positives: A Service Principal Name should only be added to an account when an application requires it. While infrequent, this detection may trigger on legitimate actions. Filter as needed.

Raw source Windows AD ServicePrincipalName Added To Domain Account · SPL
Esc
Published by splunk/security_content ↗, licensed under Apache 2.0 ↗. Reproduced here unmodified. 
name: Windows AD ServicePrincipalName Added To Domain Account
id: 8a1259cb-0ea7-409c-8bfe-74bad89259f9
version: 11
creation_date: '2022-11-17'
modification_date: '2026-05-13'
author: Mauricio Velazco, Splunk
status: production
type: TTP
description: The following analytic detects the addition of a Service Principal Name (SPN) to a domain account. It leverages Windows Event Code 5136 and monitors changes to the servicePrincipalName attribute. This activity is significant because it may indicate an attempt to perform Kerberoasting, a technique where attackers extract and crack service account passwords offline. If confirmed malicious, this could allow an attacker to obtain cleartext passwords, leading to unauthorized access and potential lateral movement within the domain environment.
data_source:
    - Windows Event Log Security 5136
search: >-
    `wineventlog_security` EventCode=5136 AttributeLDAPDisplayName=servicePrincipalName
    OperationType="%%14674" ObjectClass=user
    | stats values(ObjectDN) as ObjectDN by _time, Computer, SubjectUserName, AttributeValue
    | rex field=ObjectDN "^CN=(?P<user>[a-zA-Z0-9!#$%&'@^_{}~.-]+),"
    | rename Computer as dest, SubjectUserName as src_user  | `windows_ad_serviceprincipalname_added_to_domain_account_filter`
how_to_implement: To successfully implement this search, you ned to be ingesting eventcode `5136`. The Advanced Security Audit policy setting `Audit Directory Services Changes` within `DS Access` needs to be enabled. Additionally, a SACL needs to be created for AD objects in order to ingest attribute modifications.
known_false_positives: A Service Principal Name should only be added to an account when an application requires it. While infrequent, this detection may trigger on legitimate actions. Filter as needed.
references:
    - https://adsecurity.org/?p=3466
    - https://www.thehacker.recipes/ad/movement/dacl/targeted-kerberoasting
    - https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-5136
    - https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/t1208-kerberoasting
drilldown_searches:
    - name: View the detection results for - "$ObjectDN$"
      search: '%original_detection_search% | search  ObjectDN = "$ObjectDN$"'
      earliest_offset: $info_min_time$
      latest_offset: $info_max_time$
    - name: View risk events for the last 7 days for - "$ObjectDN$"
      search: '| from datamodel Risk.All_Risk | search normalized_risk_object IN ("$ObjectDN$") | stats count min(_time) as firstTime max(_time) as lastTime values(search_name) as "Search Name" values(risk_message) as "Risk Message" values(analyticstories) as "Analytic Stories" values(annotations._all) as "Annotations" values(annotations.mitre_attack.mitre_tactic) as "ATT&CK Tactics" by normalized_risk_object | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`'
      earliest_offset: 7d
      latest_offset: "0"
finding:
    title: A Servince Principal Name for $ObjectDN$ was set by $user$
    entity:
        field: user
        type: user
        score: 50
intermediate_findings:
    entities:
        - field: src_user
          type: user
          score: 50
          message: A Servince Principal Name for $ObjectDN$ was set by $user$
analytic_story:
    - Sneaky Active Directory Persistence Tricks
    - Interlock Ransomware
asset_type: Endpoint
mitre_attack_id:
    - T1098
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint
tests:
    - name: True Positive Test
      attack_data:
        - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/service_principal_name_added/windows-security.log
          source: XmlWinEventLog:Security
          sourcetype: XmlWinEventLog
      test_type: unit

Detection rules belong to the projects that publish them and remain under their own licenses. This site indexes and links to them; it claims no rights in them.