Detecting Windows Security Descriptors Exploitation

Windows environments are complex ecosystems comprising numerous objects such as files, processes, registry keys, and more. Security Descriptors, integral to managing access control, are often leveraged stealthily by attackers for privilege escalation. Understanding these descriptors is crucial for both offensive maneuvers and defensive strategies. This article, curated by the DARC team, explores the nuanced world of Windows Security Descriptors, highlighting their critical role, stealthy exploitation by adversaries, and effective detection methods.

Understanding Windows Security Descriptors

A security descriptor in Windows is a data structure that contains the security information associated with a securable object. These descriptors can be applied to various objects such as files, directories, processes, threads, access tokens, registry keys, and more. The key components of a security descriptor include:

• Object Owner (SID): Identifies the owner of the object.
• Discretionary Access Control List (DACL): Specifies the permissions for who can access the object.
• System Access Control List (SACL): Specifies the audit settings for access to the object.
• Set of Control Bits: Define characteristics of the descriptor itself.

DACL and SACL in Detail

• DACL (Discretionary Access Control List): Contains Access Control Entries (ACEs) that define the access rights for users and groups. Object owners have the ability to modify an object's DACL, influencing who has what type of access.
• SACL (System Access Control List): Used for auditing access to the object. It can log events such as successful or failed access attempts, providing crucial information for monitoring and threat detection.

To check DACL and SACL via command line:

# Define the path to the file you want to check
$file = "C:\path\to\your\file.txt"

# Get the security descriptor (ACL) of the file
$acl = Get-Acl -Path $file

# Display the Discretionary Access Control List (DACL)
Write-Host "Discretionary Access Control List (DACL):"
$acl.Access | Format-Table -Property IdentityReference, AccessControlType, FileSystemRights

# Display the System Access Control List (SACL)
Write-Host "`nSystem Access Control List (SACL):"
$acl.Synchronization | Format-Table -Property IdentityReference, AccessControlType, FileSystemRights

[DACL Information for the System File rundll32.exe in the System32 Folder]

Note: SACL entries might be blank if object auditing is not enabled.

Securable Objects in Windows

A securable object is any object that can have a security descriptor attached to it. Examples include:

• Files and directories
• Named pipes
• Processes and threads
• Access tokens
• Windows desktops
• Registry keys
• Services
• Printers
• Network shares

Common Abuses of ACLs

Generic Permissions

• GenericAll (GA): Full control over an object.
• GenericWrite(GW): Write permissions on an object.

Control Permissions

• WriteDACL: Modify the DACL of an object.
• WriteOwner: Change the owner of an object.

Object-specific Permission Modifications

• Files: Modify or delete sensitive files.
• Processes: Inject malicious code into running processes.
• Registry Keys: Alter registry settings for persistence or privilege escalation.
• Services: Change service configurations to run malicious executables.

How Adversaries Do It

Enumerating Access Control Lists (ACLs) is essential for both attackers and defenders to understand existing permissions and identify potential weaknesses.

Manual Enumeration Focus Areas:

• Critical files and directories
• Sensitive registry keys
• Important processes
• System services

Automated Tools That Help:

• PowerSploit’s PowerView: Use Get-DomainObjectAcl and Add-DomainObjectAcl to inspect and modify domain object ACLs.
• PowerShell Cmdlets: Use Get-Acl and Set-Acl to manually inspect and modify an object's DACL.
• Impacket’s dacledit.py Script: A Python tool for inspecting and editing DACLs.

Methodology

If an object's (called objectA) DACL features an Access Control Enteries (ACE) stating that another object (called objectB) has a specific right (e.g. GenericAll) over it (i.e. over objectA), attackers need to be in control of objectB to take control of objectA. The following abuses can only be carried out when running commands as the user mentioned in the ACE (objectB) (see impersonation techniques).

Impact

• By altering DACL entries, an attacker can grant themselves elevated permissions. This can be done without any exploits or CVEs, making it a stealthy method of escalation.
• Tampering with SACLs allows attackers to suppress logging, making their activities harder to detect.
  
  

Logging Location: Event ID 4670 - Object Rights Manipulation

Event ID 4670 in Windows Security Auditing logs captures modifications to security settings on securable objects like files, directories, registry keys, or services. These events are crucial for auditing changes to access control settings, providing insights into who made the change and what exactly was modified.

DQL Query:

stream=win-audit where eid="4670" |  duration 1d | groupby objecttype, objectserver, object, processname, @OldSd , @NewSd

Output:

Fields of interest:

• NewSd: Shows the new security descriptor (SDDL format) applied after the change.
• OldSd: Displays the old security descriptor (SDDL format) before the modification.

Let's break down the provided SDDL strings for both OldSD and NewSD:

OldSD

SDDL String value:
D:(A;;GA;;;SY)(A;;GA;;;NS)

1. D: indicates a DACL (Discretionary Access Control List).
2. (A;;GA;;;SY): Allows SY (System) full control (GA).
3. (A;;GA;;;NS): Allows NS (Network Service) full control (GA).

NewSD

SDDL String value:

D:(A;;GA;;;SY)(A;;RC;;;OW)(A;;GA;;;S-1-5-86-615999462-62705297-2911207457-59056572-3668589837)

1. D: indicates a DACL (Discretionary Access Control List).
2. (A;;GA;;;SY): Allows SY (System) full control (GA).
3. (A;;RC;;;OW): Allows OW (Owner Rights) read control (RC)
4. (A;;GA;;;S-1-5-86-615999462-62705297-2911207457-59056572-3668589837): Allows specific permissions to the trustee S-1-5-86-615999462-62705297-2911207457-59056572-3668589837 (a specific security identifier, likely a service account or user)

Modification Reason: The change likely adjusted access permissions on an object, possibly restricting or expanding access to specific users or services. This modification may reflect an update to security policies or a response to security auditing findings to better control access rights and permissions on critical objects.

Understanding such changes through Event ID 4670 logs helps administrators maintain oversight of access control configurations, ensuring security policies are enforced effectively across the Windows environment.

Detection Strategy

Baselining oldSD and newSD for every processname and system is the best approach - however these can be very system resource intensive. The easiest to implement strategy that we will use is the modification of SD by a processname that is not spawned from a windows native path.

Let's see how we do this in DNIF HYPERCLOUD:

Approach 1

Machine Learning based Outlier Detection For Object Permissions Modifications

Approach 2

Validate if the object modifications are performed from a process spawned from a non-native windows paths and raise a signal/alert in case of a match

Pro Tips for Blue Teams

• Noise Management: Expect high volumes of 4670 events. Implement tuning and whitelisting to filter out noise and focus on relevant activities.
• Comprehensive Auditing: Consider global audit policies for extensive monitoring, but be aware of the increased event volume.

Conclusion

References:

1.  Security Descriptors in Windows
2. Security Descriptors | HackTricks