Security descriptor, owner, DACL, SACL, and ACE: Reading a permission record

1. Core mechanism

This lesson teaches you how to read a security descriptor field by field: owner/primary group SIDs, DACL, SACL and control bits, and the type/flags/rights/trustee components of an ACE. Groups will be collected for tokens at 05.01, authentication/authorization separation will be at 05.02; The allow/deny order and the impact of inheritance on the access decision are covered in 05.04. The focus here is on reading a permission record correctly — distinguishing which field says what — and seeing the distinction between meta-control and data-access. Binary marshalling detail is left to MS-DTYP; SDDL string representation and field meaning are examined here.

Interfaces and specifications

• Security descriptor: structure that carries the security information of a securable object; It consists of owner SID, primary group SID, DACL, SACL and control bits.
• Owner SID: owner of the object; It is denoted by O: in SDDL. Primary group SID: Represented as G: in SDDL (moved for POSIX compatibility, plays a secondary role in Windows access).
• DACL (D:): ACE list that determines which rights are allowed/denyed to which trustees; produces the access decision.
• SACL (S:): ACE list that determines which access attempts produce audit records; It does not grant access, it produces audit.
• ACE fields: type (e.g. A=access-allowed, D=access-denied, AU=system-audit), flags (inheritance etc.), rights (access mask), object/inherit GUID and trustee SID.
• Meta-control rights: READ_CONTROL (read descriptor, except SACL), WRITE_DAC (change DACL), WRITE_OWNER (change owner); these govern the permission structure of the object.
• Control bits: P (protected), AI (auto-inherited), AR (auto-inherit-required) flags on DACL/SACL in SDDL; Specifies the inheritance behavior of the descriptor.

A security descriptor consists of five parts

The security information of a securable object is collected in a single security descriptor. This structure can carry five types of information: the object's owner and primary group SIDs, a DACL that determines access, a SACL that determines audit production, and a set of control bits that qualify the meaning of the descriptor. In SDDL string representation, these parts are written with the prefixes O:, G:, D: and S: respectively.

The Owner field is important because ownership relates to the right to manage the permission structure of the object. The primary group field is secondary in most Windows access scenarios (moved for POSIX compatibility). The real work comes down to DACL and SACL: one answers the question 'who can access what', the other 'which access attempt leaves a trace'.

Reading an ACE by field

An ACL is a list of ACEs (access control entries); Each ACE specifies a trustee and the rights allowed/deny/audited for that trustee. In SDDL, an ACE is written with six basic fields in parentheses: ace_type (A allow, D deny, AU system-audit), ace_flags (inheritance and audit flags), rights (access mask abbreviations or hex), object_guid, inherit_object_guid, and trustee (SID or abbreviation).

The rights field carries the access mask: generic such as GR/GW/GX, standard such as RC/WD/WO/SD, file-specific abbreviations such as FR/FW/FA or raw hex in the form 0x.... The Trustee field tells who the ACE is applied to; connects to the SID, not the name (03.03). Reading a permission record means solving these fields one by one and answering the question 'who, which right, allow, deny or audit?'

DACL access determines SACL audit

DACL and SACL use the same ACE syntax, but their functions are completely separate. DACL determines whether access is granted when a process accesses an object; the system reviews ACEs in the DACL based on the rights requested. SACL grants no access; It only determines which access attempts (successful, unsuccessful, or both) will produce records in the security event log.

This distinction is often confused in practice. Adding a SACL audit ACE does not give anyone access; Adding a DACL allow ACE produces no audit. The two lists are independent: an object may have wide access but no audit, or conversely, access may be narrow but every attempt is recorded. Knowing which track you are in when reading a track record — D: or S: mi — determines the meaning.

The right to control is stronger than the right to data

Among the standard access rights, two govern the descriptor itself: WRITE_DAC is the right to change the DACL in the object's security descriptor; WRITE_OWNER is the right to change the owner. READ_CONTROL is the right to read the descriptor (except SACL). These are not 'data' rights, but 'control' rights: they govern not what gets accessed, but who determines who can access what.

So seeing an ACE containing WRITE_DAC or WRITE_OWNER when reading a permission record requires more attention than a regular Read/Write ACE. A trustee with a WRITE_DAC can rewrite the DACL and grant himself any data rights he desires; A trustee carrying WRITE_OWNER can replace the owner. In the descriptor we will follow, these two rights will appear in both a DACL ACE and a SACL audit ACE — one carries the risk, the other tracks that risk.

State and data flow

1. The O: field of the descriptor is read: owner Domain Admins (DA) alias; Ownership associated with the authority to manage the permission structure of the object.
2. G: field is read: primary group Domain Users (DU); Secondary role in Windows access.
3. ACEs in the D: field are resolved one by one: File All (FA) allow for Built-in Administrators; Read-execute class hex mask (0x1200a9) allow for Domain Users (RID 513); READ_CONTROL + WRITE_DAC (RCWD) allow for a delegate principal (RID 2814).
4. The RCWD ACE is marked as meta-control: The RID 2814 principal can rewrite the DACL, i.e. grant itself any data rights.
5. Audit ACE in S: field reads: Success audit (AU;SA;WDWO) on WRITE_DAC/WRITE_OWNER attempts for Everyone (WD) — a SACL entry that tracks descriptor change attempts.
6. Result: in the same descriptor there is both a DACL ACE that carries the meta-control and a SACL ACE that audits the use of that meta-control; access (D) and tracking (S) are read separately.

2. Exploitation

Broken trust assumption

Broken assumption: Only data rights such as Read/Write are important in a permission record; WRITE_DAC or WRITE_OWNER is 'administration detail only'. In effect, these meta-control rights open you up to full control over the object, regardless of existing data ACEs, as it gives you the ability to rewrite the DACL or modify the owner.

Technical prerequisites

• A principal has the WRITE_DAC (change DACL) or WRITE_OWNER (change owner) right on the target object.
• This meta-control right is not noticed or is mistaken for 'low risk delegation'; Permission review only looks at data rights.
• No SACL or event logging tracking descriptor changes, thus keeping the DACL/owner change silent.
• Delegation is granted on a large scale (e.g. to a large number of objects), expanding the effect of meta-control.

Exploitation mechanism

WRITE_DAC grants the right to modify an object's DACL; WRITE_OWNER permits changing its owner. In Windows, an owner can receive implicit WRITE_DAC by default and can therefore edit the DACL; OWNER RIGHTS ACEs can define those implicit owner rights, and BlockOwnerImplicitRights conditions apply in some AD computer-object scenarios. So WRITE_OWNER is not a data right and does not by itself guarantee DACL modification on every object; inspect the target object's type and descriptor. Keep two questions separate during review: 'what data can this principal access now?' and 'under what conditions could this principal gain control of the permission structure?' Scope includes which principals have WRITE_DAC/WRITE_OWNER on which objects together with the target's owner-rights rules; controls include least-privilege for meta-control rights, reviewing unnecessary ownership, and auditing DACL/owner changes with suitable SACL and audit coverage.

Which is the most dangerous area in permit registration?

When reviewing permissions, attention often goes to data rights such as FullControl/Modify. WRITE_DAC directly allows rewriting the DACL; WRITE_OWNER can change the owner, and a Windows owner can receive implicit WRITE_DAC by default. Because OWNER RIGHTS ACEs and some AD computer-object conditions can limit this path, evaluate each target together with its descriptor and object type.

Separate two questions: 'what data can this principal access now?' and 'under what conditions can this principal change the permission structure?' With WRITE_DAC, the DACL-management path is present; with WRITE_OWNER, check the target object's implicit owner rights as well. Flagging meta-control ACEs separately from data rights makes both the potential control path and its boundaries visible.

3. Defense & Detection

Telemetry scope

• Changing the permissions (DACL or owner) of an object is recorded as 4670 (Permissions on an object were changed); The event carries the security descriptor before and after the change in the OldSd and NewSd fields as SDDL, so the difference can be read.
• 4670 is not generated when the SACL itself changes. For file-system or registry object SACL changes, examine 4907; it is not generated for Active Directory objects.
• Producing a 4670 requires appropriate audit ACEs in the object's SACL: 'Change Permissions' and/or 'Take Ownership' in the file object, 'Write DAC' and/or 'Write Owner' entries in the registry key that audit attempts. If SACL does not include these, the event is not generated at all.
• Therefore, monitoring a descriptor change depends on two conditions: the correct SACL scope (the S: field contains audit ACEs that will trigger the change) and the relevant audit subcategory (Audit File System/Registry) being active.

Events and relevant fields

• 4670: OldSd and NewSd SDDL strings are compared to determine which ACE has been added/removed or the owner has changed; ObjectName and HandleId show which object changed, SubjectUserSid shows the principal who made the change.
• The addition of a WRITE_DAC/WRITE_OWNER (WD/WO) ACE in the NewSd of the 4670 is direct evidence of the expansion of meta-control, and the difference with the OldSd makes this apparent.
• 4907 shows the OldSd/NewSd difference for a SACL change on supported file-system/registry objects. Do not generalize this Event ID to AD object auditing; inspect the DC’s Directory Service audit path and actual descriptor state separately.
• Since 4670 production is tied to SACL, the absence of the event does not mean 'no change'; If the SACL does not contain the correct audit ACEs, the change can occur silently.
• In AD DS, 4662 is generated on the DC with Audit Directory Service Access and an object SACL matching the operation. ObjectName, AccessMask and Properties describe the operation context; the record alone is not a before/after descriptor difference.

Watch the change through the right channel

Start with the object type and changed component. In this lesson’s file example, compare 4670 OldSd/NewSd for a DACL/owner change and use 4907 for a SACL change. 4907 is not generated for AD objects. Copying a file audit scheme directly to an OU or user object creates the wrong evidence expectation.

Producing 4670 requires the relevant audit subcategory and a matching audit ACE on the object. The SACL is a production prerequisite here, not the changed component. For AD DS, inspect the DC’s Directory Service Access/4662 path, object SACL and current descriptor together; an operation record is not a complete descriptor difference.

Detection logic · XPath

*[System[EventID=4670] and EventData[Data[@Name='ObjectType']='File']]

Query assumptions

• The expression selects 4670 permission-change events for File objects in a single Windows Event Log document; The OldSd/NewSd difference should also be compared (outside of XPath).
• Named-field selection only works if EventData/Data/@Name values ​​are flattened with ObjectType/OldSd/NewSd names; The backend mapping must be verified.
• The 4670 generation depends on the Change Permissions/Take Ownership audit ACEs and the Audit File System subcategory in the object's SACL; Without these, the event would never occur.
• The query was not run on a real host or SIEM in this session; there is no threshold, no dataset, and no time window; SACL changes should be monitored separately with 4907.

False positives

• Legitimate administrative operations (permission fixes, migration, application installations) routinely produce 4670; A single incident does not indicate malicious intent.
• Bulk ACL fix tools can produce large numbers of 4670s; these should be separated as benign baseline.
• Looking at the event count alone without examining the OldSd/NewSd difference is misleading; The real signal is in the added meta-control (WD/WO) ACEs.
• The absence of event is not security; If the SACL does not contain the appropriate audit ACEs or the subcategory is closed, changes are not saved.

Hardening

• Limit WRITE_DAC and WRITE_OWNER rights and unnecessary ownership to least-privilege; Inventory and reduce which principals carry this meta-control on which objects.
• Configure the SACL of high value objects to capture descriptor changes (Change Permissions/Take Ownership audit ACEs) and enable the Audit File System/Registry subcategories.
• Track events 4670 (DACL/owner change) and 4907 (SACL change) separately; In particular, prioritize adding WD/WO ACE to NewSd and narrowing the audit scope.
• Measure audit volume and business impact in a pilot context before implementing controls; Verify that SACL expansion keeps log volume manageable and maintain a rollback plan.

Read the examples

O:DAG:DUD:(A;;FA;;;BA)(A;;0x1200a9;;;S-1-5-21-1002233445-2244556677-3366778899-513)(A;;RCWD;;;S-1-5-21-1002233445-2244556677-3366778899-2814)S:(AU;SA;WDWO;;;WD)

Two reality checks

Assumption: Adding an ACE to a SACL in a permission record gives relevant users access to that resource.

In fact: An audit ACE does not grant access; with suitable audit policy it enables recording of specified access attempts. The DACL defines discretionary access rights. Token privileges and other applicable checks can also affect access outcomes: this example examines an ordinary file request without an enabled applicable bypass privilege. Expanding audit coverage and granting permission are separate operations.

Assumption: If a user does not have Read/Write rights to a file, they cannot do anything to that file; Rights like WRITE_DAC are unimportant administrative details.

In fact: WRITE_DAC is the right to change the DACL of the object, and WRITE_OWNER is the right to change the owner (Standard Access Rights). These meta-control rights do not grant data access, but manage the permission structure: a principal with WRITE_DAC can rewrite the DACL and add any rights he wants, even if the existing DACL does not grant him any data rights. Therefore, in a permission record, these rights must be considered with higher risk than ordinary Read/Write.

Sources

• Microsoft · Security Descriptors
  Security descriptor components: owner and primary group SIDs, DACL, SACL, and control bits; SECURITY_DESCRIPTOR structure
• Microsoft · Access Control Lists
  The DACL determines access and the SACL determines audit generation; an ACL is a list of ACEs; each SACL ACE specifies success/failure audit generation
• Microsoft · Access Control Entries
  An ACE specifies a trustee and the allow/deny/audit rights for that trustee; ACE field structure
• Microsoft · Standard Access Rights
  Definitions of READ_CONTROL (read the descriptor, excluding SACL), WRITE_DAC (modify the DACL), WRITE_OWNER (modify the owner), and DELETE
• Microsoft · ACE strings
  SDDL ACE syntax; A/D/AU ACE types, RC/WD/WO/SD/FA rights abbreviations, and trustee SID aliases (DA/BA/DU/WD)
• Microsoft Open Specifications · [MS-DTYP] SECURITY_DESCRIPTOR
  SECURITY_DESCRIPTOR control flags (SE_DACL_PRESENT, SE_DACL_PROTECTED, SE_DACL_AUTO_INHERITED, SE_SELF_RELATIVE) and OwnerSid/GroupSid/Sacl/Dacl fields
• Microsoft · 4670(S) Permissions on an object were changed
  OldSd/NewSd (SDDL) fields; 'does not generate if the SACL was changed'; requirement for Change Permissions/Take Ownership audit ACE in the SACL; Audit File System/Registry
• Microsoft · 4907(S) Auditing settings on object were changed
  File/registry SACL changes; not generated for Active Directory objects.
• Microsoft · Owner of a New Object
  The owner implicitly has WRITE_DAC; WRITE_OWNER access can set a valid user/group SID as owner
• Microsoft · [MS-ADTS] Blocking Implicit Owner Rights
  AD-specific conditions where implicit owner READ_CONTROL/WRITE_DAC rights can be blocked for certain computer objects and OS versions
• Microsoft · Event 4662
  DC; ObjectName/AccessMask/Properties operation context, matching SACL; not full descriptor diff.
• Microsoft · Audit Directory Service Access
  Directory Service Access audit subcategory and SACL-matched operations.
• Microsoft · Managing privileges in a file system
  Caller holds and enables privilege; SeBackupPrivilege/SeRestorePrivilege defined file operations, not a universal DACL-only outcome.