Hey SDDL SDDL: Breaking Down Windows Security One ACE at a Time

Windows permission misconfigurations remain a common attack vector in enterprise environments. Attackers consistently leverage these misconfigurations for privilege escalation, with Security Descriptor Definition Language (SDDL) emerging as a blind spot. From LockBit's manipulation of event log permissions to RomCom's exploitation of Task Scheduler vulnerabilities (CVE-2024-49039), SDDL misconfigurations have become a prime target for sophisticated attacks.

SDDL controls who can access and modify resources within Windows environments. Since its introduction in Windows 2000, it has managed access to registry keys, files, folders, and Active Directory objects—serving as both a defense mechanism and potential attack surface.

In this blog, we'll explore SDDL's structure and functionality, provide tools for decoding SDDL strings, and demonstrate effective interpretation techniques. We'll examine both defensive advantages and potential adversarial exploitation paths, equipping you with a comprehensive understanding of SDDL's role in Windows security. From basic Access Control Entry (ACE) interpretation to advanced Discretionary Access Control List (DACL) configurations, this guide will help defenders identify and address permission-based vulnerabilities in their environments.

What is SDDL?

If you've ever used the Windows operating system, chances are you've configured permissions on a file or folder through the familiar Properties dialog. Accessed via the Security tab, in its basic form, this interface allows you to manage access and actions on a securable object (e.g., file, registry, etc.).

Figure 1: Advanced security settings

Figure 2: Permission entry settings

The Security tab does a great job at simplifying the access control system. We can get a sneak peak at how this abstraction looks by using the PowerShell Cmdlet “Get-ACL.”

Figure 3: Get-Acl cmdlet Sddl property results

Windows uses Security Descriptors to manage ownership, permissions, and audit settings for objects. To simplify handling these, it uses SDDL.

SDDL is a Microsoft-defined syntax used to represent security descriptors as text strings. These descriptors contain information about the ownership, permissions, and audit settings of securable objects like files, services, and registry keys. By utilizing SDDL, administrators can define and modify access controls in a human-readable format, facilitating easier management and auditing of security settings.

Here are two examples of SDDLs. Note that we'll dive more into decoding these in a moment, but we wanted to show how these look before we get even deeper.

Example 1 - A Simple File Permission:

This is about as basic as it gets - a single permission entry defining who owns the file and what a single group can do with it.

Example 2 - A Full Service Configuration:

This is what you might see in the real world - a complex set of permissions controlling a Windows service with different levels of access for different users and groups.

Don't worry if these look like gibberish right now; that's exactly why we're going to break them down piece by piece in the next section. What's important to notice is how the complexity grows while maintaining the same basic structure.

SDDL Structure

At its core, an SDDL string consists of four main building blocks:

Each of these elements serves a specific purpose in defining the security settings for an object. Let's break them down:

[owner-string]

• Purpose: The owner-string specifies the security principal that owns the object.
• Format: O:<SID>/<String representation of an SID>
• Examples:
  • O:S-1-5-21-1004336348-1177238915-682003330-512
  • O:BA

In the first example, the Security Identifier (SID) represents the owner of the object, whereas in the second example, the string representation of the Built-in Administrator group is used.

[group-string]

• Purpose: The group-string specifies the primary group associated with the object, and it uses a similar structure to the owner string
• Format: G:<SID>

[dacl-string] /

The Discretionary Access Control List (dacl-string) defines the permissions for users and groups to access the object. It specifies who is allowed or denied access, as well as the level of access granted or restricted.

• Format: D:(acl-flag)(ace-string)*

[sacl-string]

In contrast, the System Access Control List (sacl-string) specifies audit rules for the object. It governs which actions or access attempts are logged for monitoring and auditing purposes, providing a mechanism to track and review activities for compliance and security analysis.

• Format: S:(acl-flag)(ace-string)*

Each of these is composed of an optional “ac-flag” and one or more ACE strings, which define individual rules.

What is an Access Control Entry (ACE)?

An ACE is a fundamental component of an Access Control List (ACL) within a security descriptor. Each ACE specifies the permissions granted or denied to a user or group for a particular object.

Structure of an ACE in SDDL

ACEs are represented as strings enclosed in parentheses, with fields separated by semicolons.

The general format of an ACE string is as follows:

• Type: Specifies the purpose of the ACE, such as whether it allows, denies, or audits access. Common values include: A (allow) and D (deny)
• Flags: Determine how the ACE is applied and inherited. Common values include: OI (Object Inherit) and IO (Inherit Only)
• Rights: Indicates the access rights controlled by the ACE. It can either be represented as a hex value or with a set of predefined strings.
• Object GUID: A string used to identify and scope an ACE to a specific object. Example: Referencing the GUID of the "user" object in Active Directory "bf967aba-0de6-11d0-a285-00aa003049e2"
• Inherit Object GUID: A string used to specify the type of objects that can inherit this ACE
• SID: represents the Security Identifier (SID) of the user or group to whom the ACE applies.

Keep in mind that most of the fields above are optional, apart from the type, rights, and SID.

Additional fields can exist for different types of ACEs, namely:

• Conditional ACEs: Introduce a condition expression field that allows SDDL authors to offer more granular controls by limiting or allowing access based on an evaluated condition.
• Resource Attribute ACEs: Introduce an “attribute-data” field with its own structure.

Both of these special aces are outside the scope of this blog but are covered by both Microsoft documentation and the mind map later in this blog provided by the Splunk Threat Research team.

Now that we have a better understanding of ACEs, let's break down a some of the ACEs from our earlier examples:

This breaks down into:

• Type: A (Allow)
• Flags: ;; (none. in this case)
• Access Rights: RPWPCCDCLCSWRCWDWOGA
• Object GUID: ;; (none. in this case)
• Inherited Object GUID: ;; (none. in this case)
• Account SID: BA (Built-in Administrators)

Here we're explicitly denying (D) the Write DAC (WD) permission to the Built-in Guests (BG) group.

In short, think of ACEs as building blocks: you stack them together to create your complete security policy. Each one answers a specific question: "What can this SID (user/group) do (or not do) with this resource?" When Windows checks if an entity can perform an action on a securable object, it evaluates these ACEs in order until it finds a matching one that either allows or denies the requested access.

Putting Everything Together

Now that we have a deeper understanding of how SDDL works, we can see how it applies to various Windows securable objects.

1. Services
   • Controls who can start, stop, or modify Windows services
   • Critical for preventing service-based privilege escalation
   
   

D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)




2. Active Directory Objects
   • Defines permissions for users, computers, and group
   • Controls who can modify Active Directory attributes and properties
   
   

D:(A;;RPWPCCDCLCSWRCWDWOGA;;;DA)




3. Files and Folders
   • Determines read, write, and execute permissions
   • Crucial for data protection and access control
   
   

D:(A;;FA;;;BA)(A;;FA;;;SY)(A;;0x1200a9;;;BU)




4. Registry Keys
   • Controls who can modify Windows registry settings
   • Essential for system configuration security
   
   

D:(A;;KA;;;BA)(A;;KR;;;BU)

Microsoft provides comprehensive documentation that catalogs all possible values for each component:

• Access Rights (like FA for Full Access, WD for Write DAC)
• Trustee SIDs (like BA for Built-in Administrators, SY for System)
• ACE Types (like A for Access Allowed, D for Access Denied)
• ACE Flags (like CI for Container Inherit, OI for Object Inherit)

In addition, the Splunk Threat Research Team created the following mind map for reference, which details the entire structure of an SDDL string, along with all the possible values and detailed explanations for each one. We highly encourage practitioners who want to learn about this topic or simply want a refresher to check it out.

Figure 4: SDDL Demystified Mind Map
https://github.com/MHaggis/SDDLMaker/tree/main/MindMap

Using StreamLit to Simplify SDDLs Decoding

Understanding and working with SDDL strings can be challenging, even for experienced administrators. With thousands of possible permission combinations and complex syntax rules, manually decoding SDDL strings is both time-consuming and error-prone. To address this challenge, the Splunk Threat Research Team developed an interactive SDDL parsing and analysis tool.

This Streamlit application serves multiple purposes:

• For Security Teams: Quickly analyze SDDL configurations across your environments to identify potential misconfigurations or overly permissive settings
• For Threat Hunters: Decode suspicious SDDL modifications observed during incident investigations
• For System Administrators: Generate valid SDDL strings with a user-friendly interface, eliminating syntax errors
• For Security Researchers: Study and compare SDDL patterns across different Windows objects and malware samples

The application features an intuitive interface for both parsing existing SDDL strings and building new ones, complete with security impact analysis and best practice recommendations. You can access the tool on GitHub.

Note: This tool is community-supported and not officially maintained by Splunk.

How Do Adversaries Use SDDL?

Adversaries are no strangers to SDDL and tampering with permissions; they often leverage SDDL to bypass or blind security controls, or to simply extend access or ownership over a securable object. Let’s review some examples and how you can help identify these situations using out-the Splunk Threat Research Team’s of-the-box detections.

LockBit's Use of Registry Permissions for Event Log Tampering

A few years ago, we saw LockBit tampering with different event log channel permissions to restrict access to a limited set of users on the infected machine. By altering these registry permissions, LockBit targeted specific Windows Event Channels that record a range of system, security, and application activities—making it harder for defenders to detect its actions. Below are some of the affected channels and the SDDL permissions applied by LockBit in the sample analyzed by the Splunk Threat Research Team:

Figure 5: LockBit Sample from VirusTotal, Splunk 2024

1. AMSI/Debug Channel
   • Registry Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\AMSI/Debug
   • SDDL: O:BAG:SYD:(A;;0x1;;;SY)(A;;0x5;;;BA)(A;;0x1;;;LA)
   • Explanation: This SDDL specifies that Local System (SY) has "generic read" access (0x1), the Built-in Administrator group (BA) has "generic read" and "write" access (0x5), and Local User Account (LA) has "generic read" access. This configuration effectively limits which users can view AMSI-related logs. AMSI logs include details about scripts and executables scanned by antivirus software, and tampering with these permissions means defenders without administrative privileges cannot easily access this log data. This impacts defenders by hiding alerts or warnings generated by AMSI that could point directly to malicious activity, therefore delaying detection and response.
2. AirSpaceChannel
   • Registry Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\AirSpaceChannel\ChannelAccess
   • SDDL: O:BAG:SYD:(A;;0x1;;;SY)(A;;0x5;;;BA)(A;;0x1;;;LA)
   • Explanation: Similar to the AMSI/Debug Channel, Local System has "read" access, Built-in Administrators have both "read" and "write" access, and Local Users only have "read" access. This channel is used for telemetry and diagnostic data.
3. Analytic Channel
   • Registry Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Analytic\ChannelAccess
   • SDDL: O:BAG:SYD:(A;;0x1;;;SY)(A;;0x5;;;BA)(A;;0x1;;;LA)
   • Explanation: The Analytic Channel is intended for real-time logging of system activities, which helps in identifying irregularities. With Local System and Built-in Administrators having read and write capabilities while Local Users are limited to read-only access, this restriction makes it difficult for non-administrative accounts to investigate real-time system changes.

This technique was applied to all the channels available on a system.

Windows New Custom Security Descriptor Set On EventLog Channel

To detect this type of event log tampering through SDDL modifications, the Splunk Threat Research Team has developed detections and atomic tests specifically targeting changes to Windows Event Channel permissions. The Windows New Custom Security Descriptor Set On EventLog Channel detection will alert when an adversary attempts to modify channel access descriptions, helping defenders identify potential event log tampering early in an attack:

Figure 6: Windows New Custom Security Descriptor Set On EventLog Channel Detection

Modify Event Log Channel Access Permissions via Registry - PowerShell

This test simulates an adversary modifying access permissions for a Windows Event Log Channel by altering the "ChannelAccess" registry value. Specifically, it changes the SDDL string. These modifications can restrict or grant access to specific users or groups, potentially aiding in defense evasion by controlling who can view or modify an event log channel.

Figure 7: Modify Event Log Channel Access Permissions via Registry - PowerShell Atomic Test

Modify Event Log Channel Access Permissions via Registry 2 - PowerShell

This test simulates a similar tactic, where an adversary modifies access permissions for a Windows Event Log Channel by altering the "ChannelAccess" registry value. However, instead of directly changing the “WINEVT” key, this approach targets policy registry values, such as “HKLM\SOFTWARE\Policies\Microsoft\Windows\EventLog”.

Figure 8: Modify Event Log Channel Access Permissions via Registry 2 - PowerShell Atomic Test

Modify Event Log Access Permissions via Registry - PowerShell

This test simulates an adversary modifying access permissions for a Windows Event Log channel by setting the “CustomSD” registry value. Like the previous method, this involves changing the SDDL string to control who can view or modify an event log channel. These modifications can be used for defense evasion by restricting or granting access to specific users or groups.

Figure 9: Modify Event Log Access Permissions via Registry - PowerShell Atomic Test

Insights from Glupteba

In the case of the Glupteba malware family, as highlighted by Sophos, the adversary used SDDL to set advanced permissions on the installed "WinmonProcessMonitor" driver. By leveraging sc.exe to set permissions, they aimed to create restrictive ACLs, which ensured that no unauthorized user—especially administrators—could stop or pause the service. Specifically, the line (D;;WPDT;;;BA) in the SDDL string denies (D) permissions to stop (WP) or pause (DT) the service for members of the Built-in Administrators group (BA). This effectively means that even if an administrator gains access to the infected machine, it becomes significantly more challenging to stop these malicious services.

Figure 10: Glupteba, Page 16, Sophos, 2020

Figure 11: SDDL Decoding, Splunk 2024

Windows New Deny Permission Set On Service SD Via Sc.EXE

Understanding how Glupteba leverages SDDL for service persistence, the Splunk Threat Research Team created a detection to identify suspicious service permission modifications. This detection focuses on identifying when new security descriptors are set on services via SDDL, which could indicate an attempt to restrict service management capabilities:

Figure 12: Windows New Deny Permission Set On Service SD Via Sc.EXE Detection

White Dev 89 and the Revival of Legacy Tools

A particularly interesting case study emerged when PWC reported on a threat actor dubbed "White Dev 89," who demonstrated how older Windows utilities can be repurposed for malicious activity. The threat actor leveraged `subinacl.exe`, a legacy Windows Resource Kit tool from the Windows 2003 era, to manipulate security descriptors across their target environment.

SubInACL is particularly powerful because it provides granular control over security descriptors, allowing modification of:

• Ownership settings
• Primary group assignments
• SACLs and their entries (called AACEs in SubInACL)
• DACLs and their entries (called PACEs in SubInACL)

What makes SubInACL particularly interesting for both defenders and attackers is its versatility. The tool can manipulate permissions across multiple object types:

• Files and directories (including recursive operations)
• Registry keys
• Services
• Printer shares
• Active Directory objects

While PWC's report doesn't detail exactly show how White Dev 89 wielded this tool, its capabilities align perfectly with common adversary objectives such as:

• Persistence through service permission modifications
• Privilege escalation via registry key permission changes
• Defense evasion by altering audit policies
• Lateral movement preparation by modifying share permissions

Let's use this single SubInACL command as an example:

The above will grant the user designated by “NewDomain\User” the “full control” access to the service “\\ServerName\ServiceName”. Check out the following documentation, for additional details on how to use SubInAcl.

Windows SubInAcl Execution

To combat the abuse of legacy tools like SubInAcl, the Splunk Threat Research Team developed a dedicated detection to identify their execution. This detection helps identify potentially malicious permission modifications across multiple Windows object types. It looks for any execution of the “SubInAcl” utility. As this is a legacy utility, it should not be present on any modern system, hence any execution is considered suspicious.

Figure 13: Windows SubInAcl Execution Detection

SubInAcl Execution

This test simulates an adversary executing the Windows Resource kit utility SubInAcl. Upon execution, a process creation log should be generated, indicating successful execution.

Figure 14: SubInAcl Execution Atomic Test

RomCom

The RomCom exploits in 2024 demonstrate why continuous monitoring of SDDL permissions remains important. Their exploitation of CVE-2024-49039 through Task Scheduler's overly permissive SDDL (D:P(A;;GA;;;S-1-15-2-1)(A;;GA;;;WD)) showcases how adversaries continue to find new ways to abuse Windows permissions. While this particular vulnerability has been patched, it’s important to monitor SDDL changes across your environment. Microsoft's patch implementation of a more restrictive SDDL (D:(A;;GRGWGX;;;SY)(A;;GRGWGX;;;LS)(A;;GR;;;NS)(A;;GR;;;IU)S:(ML;;NWNXNR;;;ME)) demonstrates proper security boundaries by limiting system and service accounts to specific permissions.

As new and evolving SDDL-based threats continue to emerge, the Splunk Threat Research Team will continue to develop new security content to help practitioners defend against these threats. For instance, we already monitor for suspicious service permission changes using “sc.exe sdset” as shown here:

Figure 15: Windows New Deny Permission Set On Service SD Via Sc.EXE Detection

However, we also recognize that adversaries may target different Windows objects through their SDDL permissions. This encourages us to continuously expand our detection coverage as new abuse techniques emerge.

Looking Ahead: Securing Your Environment

As we've seen throughout this blog, SDDL modifications play an important role in both defensive security and adversarial tactics. To help defenders detect SDDL-based threats, the Splunk Threat Research Team has developed a comprehensive analytic story focused on defense evasion and unauthorized access via SDDL tampering. This collection encompasses detections for various SDDL modification techniques we've discussed throughout this blog - from event log channel permissions to service security descriptors.

The story includes detection analytics for:

• Windows Event Log channel permission modifications
• Service security descriptor changes via sc.exe
• Permission alterations using legacy tools like SubInAcl
• File and folder permission changes through icacls
• Registry value modifications affecting security descriptors

These detections, combined with the knowledge of SDDL structure and adversary tradecraft covered in this blog, provide defenders with the tools needed to identify and investigate suspicious permission changes in their environment.

While our detections provide a strong foundation for identifying malicious SDDL changes, effective defense requires a layered approach:

1. Correlate SDDL Changes: Link SDDL modifications with other suspicious activities. For example, combine service permission changes with process creation events or registry modifications to build a complete picture of potential threats.
2. Baseline Your Environment: Document your standard SDDL configurations for critical services, registry keys, and event log channels. This makes it easier to spot potentially malicious deviations.
3. Regular Auditing: Use the SDDL parsing tool we've provided to regularly audit permission changes in your environment, particularly for sensitive objects like services and event logs.
4. Detection Strategy: Implement the detections provided in this analytic story and correlate them with existing security controls. For instance, combine SDDL modification alerts with authentication events or process monitoring to identify potential privilege escalation attempts.

The tools and knowledge shared in this blog will help you better understand and detect SDDL-based attacks.

Learn More

This blog helps security analysts, blue teamers, and Splunk customers identify SDDL modifications or changes by enabling the community to discover related tactics, techniques, and procedures used by threat actors and adversaries. You can implement the detections in this blog using the Enterprise Security Content Updates app or the Splunk Security Essentials app. To view the Splunk Threat Research Team's complete security content repository, visit research.splunk.com.

Feedback

Any feedback or requests? Feel free to put in an issue on Github and we’ll follow up. Alternatively, join us on the Slack channel #security-research. Follow these instructions If you need an invitation to our Splunk user groups on Slack.

Contributors

We would like to thank Michael Haag and Nasreddine Bencherchali for authoring this post and the entire Splunk Threat Research Team for their contributions: Jose Hernandez, Teoderick Contreras, Lou Stella, Bhavin Patel, Rod Soto, Eric McGinnis, and Patrick Bareiss.