Computer Object ACL Abuse Active Directory: DACL Review Guide

What Is Computer Object ACL Abuse Active Directory?

Computer object ACL abuse Active Directory reviews ask who can change a machine identity's directory object. GenericAll, WriteDACL and WriteOwner can expose routes to resource-based constrained delegation (RBCD), unauthorized key credentials or a machine-password reset. Finding a dangerous grant establishes an exposure; proving exploitation requires change and authentication evidence.

The computer objects attack-surface introduction already explains the RBCD ACL path alongside delegation, replication rights and privileged group membership. This guide takes that foundation into an operational review: inspect the DACL and owner, distinguish three abuse paths, collect directory-change evidence and repair both the permission path and any unauthorized configuration.

The review concerns rights on a computer object. A machine account holding privileges elsewhere is a different relationship. Record the controlled object's DN and GUID, the trustee receiving the grant, the grant's scope and the expected administrative purpose before deciding what to remove.

How It Works: Review the DACL and Owner

A discretionary access-control list (DACL) contains access-control entries (ACEs). Each entry identifies a trustee and rights; object-specific entries can restrict the property, extended right or inheriting object class. Reading only a displayed permission name misses that scope. Microsoft's AD access-right enumeration defines these fields and the WriteDACL and WriteOwner rights.

GenericAll is not just a raw bit to search for. MS-ADTS access-right mapping maps generic rights into specific rights when a security descriptor is stored. An audit that searches only for 0x10000000 can miss mapped full control. Interpret the resulting rights together with ACE type, property scope and inheritance.

Ownership needs its own check. Microsoft documents blocking of implicit owner rights on computer objects, with operating-system and BlockOwnerImplicitRights conditions. Do not assume that becoming owner always provides an unrestricted DACL-write path. Verify the effective rights on the actual DC configuration. Equally, removing a conspicuous full-control ACE does not establish a clean result if an unexpected owner or another applicable grant remains.

Why Computer Objects Need a Dedicated ACL Review

A delegation inventory answers which machines currently accept delegated identities. An ACL review asks who could change that answer tomorrow. An empty RBCD attribute therefore does not close a finding about a trustee that can write it. The same distinction applies to key credentials: inventory the stored values and the ability to add them.

Start with business context rather than a blanket ban on administration. A deployment service may need particular provisioning rights; that does not establish a need for permanent full control of every server object. Ask the owner to identify the operation, affected objects, approved trustee and expiry or review date. Compare that requirement against the actual ACE.

Direct and inherited permissions need different repairs. If an unwanted grant originates on a parent OU, changing one computer leaves other recipients exposed. Trace the inheritance source and inspect the object-class scope before changing it. Keep the administrative owners of the OU and its workloads involved so the replacement delegation supports the legitimate task.

The Attack Chain: Three Paths from Object Control

1. RBCD configuration

An attacker with effective write access to msDS-AllowedToActOnBehalfOfOtherIdentity can attempt to insert a controlled service identity into the resource's delegation configuration. WriteDACL can be an earlier stage that grants the required write permission. The Microsoft schema reference describes this attribute as the access check for acting on behalf of other identities at services running as the account.

Microsoft's constrained-delegation overview explains resource-side authorization and the S4U2Proxy service-ticket exchange. The consequence is access through eligible services on the target resource, subject to the environment and service authorization. It is not an automatic guarantee of local Administrator or Domain Admin. Review the destination services and the privileges of the impersonated identity to assess impact.

2. Shadow credentials

An unauthorized public key in msDS-KeyCredentialLink can create a separate key-based authentication route when the environment supports the relevant key-trust flow and the attacker holds its private key. MS-PKCA Key Trust requires AD-backed implementations to confirm the same public key in the account's attribute.

Distinguish broad attribute-write access from validated writes. The latter impose additional checks beyond the attribute schema. The computer validated-write specification requires SELF, the relevant validated-write right and specific blob constraints for adding a value, including no existing value. Those conditions do not mean every third party with a validated write can install a key.

Domain-joined device public-key authentication also explains legitimate computer-key provisioning. A populated attribute is a triage input, not a compromise verdict. The shadow credentials guide develops this distinction and explains why password-only cleanup can leave an unauthorized key route in place.

3. Machine-password reset

Full control can include the Reset Password extended right. Microsoft's Reset Password schema entry explicitly lists Computer among the applicable classes. An unauthorized reset can give an attacker control of the account's password-based credential, with impact depending on that account's privileges and available authentication paths.

It can also disrupt the machine's trust relationship. Microsoft's secure-channel troubleshooting guidance describes password mismatches between the device and AD. Treat an unexplained reset as an identity incident and an availability concern. Coordinate recovery with the system owner; a unilateral directory-side password change is not a safe diagnostic experiment.

Enumeration: One Read Command, Then Effective-Rights Review

On an administrative Windows system with dsacls available, open an elevated command prompt or PowerShell session and substitute the verified computer DN in this single read command:

dsacls "CN=APP01,OU=Servers,DC=example,DC=com" /A

Microsoft's dsacls reference documents ACL display and /A for owner and auditing information. Use an account authorized to read the DACL, owner and auditing information; ordinary READ_CONTROL access excludes the SACL. This example was not executed against an AD environment.

Resolve each unexpected trustee to a current identity. Record inherited versus explicit grants, applicable groups, property scope and the owner. Confirm effective permissions using the directory's security tools rather than treating every allow entry as an independent, immediately usable attack. Investigate unresolved identities and explain approved administrative exceptions in the review record.

Prioritize sensitive servers and the OUs that delegate control over them, then expand the review to all computer objects. Save the before-state so a later change can be evaluated against the same object and permission scope.

Detection: Event ID 5136 and KQL

Microsoft's Event ID 5136 reference verifies directory-object modification auditing. Enable successful Audit Directory Service Changes on DCs and appropriate write-auditing SACL entries on the monitored objects or attributes. Microsoft notes that schema settings can suppress auditing for some objects and properties, so validate actual coverage. Retain the actor, object, attribute and operation correlation fields. Value deletion and addition can be parts of one modification; do not count them as separate incidents.

The following KQL is an unexecuted starting query for a workspace receiving DC Security events into WindowsEvent. It assumes named properties inside EventData. Microsoft's WindowsEvent table schema defines that field as dynamic and says parsing failures populate RawEventData instead. Inspect representative records before relying on this mapping.

WindowsEvent
| where TimeGenerated > ago(7d)
| where Channel == "Security" and EventID == 5136
| extend ObjectClass = tostring(EventData.ObjectClass),
         ObjectDN = tostring(EventData.ObjectDN),
         AttributeName = tostring(EventData.AttributeLDAPDisplayName),
         ActorSID = tostring(EventData.SubjectUserSid),
         ActorName = tostring(EventData.SubjectUserName),
         Operation = tostring(EventData.OperationType),
         OperationCorrelation = tostring(EventData.OpCorrelationID)
| where ObjectClass =~ "computer"
| where AttributeName in~ ("msDS-AllowedToActOnBehalfOfOtherIdentity",
                          "msDS-KeyCredentialLink", "nTSecurityDescriptor")
| project TimeGenerated, Computer, ObjectDN, AttributeName,
          ActorSID, ActorName, Operation, OperationCorrelation
| order by TimeGenerated desc

Check separately for 5136 records with empty or differently shaped EventData; otherwise parsing gaps become invisible. Adapt the query if the connector uses SecurityEvent or another table. Validate SACL coverage and security-descriptor change visibility with a controlled administrative change before making coverage claims. The query finds candidate modifications, not proof of abuse.

For the reset path, supplement directory-change review with Event ID 4742 under Audit Computer Account Management. Its Password Last Set field can reflect a manual reset or ordinary machine rotation. Microsoft also documents DACL changes yielding empty changed-attribute fields. An empty field list therefore does not establish that nothing relevant changed.

Triage against approved deployment, enrollment and delegation changes. Preserve the previous configuration where available, identify the initiating account and check the affected machine's subsequent activity. Raise priority when an unapproved actor changes a sensitive server, an owner changes unexpectedly, or a permission change precedes a delegation or key addition. Missing audit data requires a collection investigation; it cannot establish absence of exploitation.

Remediation: Remove the Permission Path and Recover the Identity

Step 1: Preserve evidence and narrow the delegation

Capture the DACL, owner, inheritance source and relevant attribute values before changing them. Remove unauthorized full-control, DACL-write and ownership grants. Replace necessary provisioning access with rights scoped to the documented operation and object class. Repair an inherited grant at its source and review other affected computers.

If a specific trustee is confirmed to require no remaining ACEs on this object, dsacls /R provides a documented removal operation:

dsacls "CN=APP01,OU=Servers,DC=example,DC=com" /R "EXAMPLE\RetiredProvisioning"

/R removes all ACEs for that trustee; it is not a selective full-control cleanup. For a trustee retaining legitimate rights, edit the specific offending ACE instead. Confirm the resulting owner and effective rights afterward. This documentation-based example was not executed.

Step 2: Remove unauthorized delegation and keys

Reconcile RBCD delegates with the resource owner's approved list. Set-ADComputer exposes PrincipalsAllowedToDelegateToAccount; use the verified intended set, preserving legitimate application dependencies. Removing an unauthorized delegate without fixing the writer's permission leaves the configuration open to recreation.

For a confirmed unauthorized key, the same cmdlet supports removing an exact LDAP attribute value:

Set-ADComputer -Identity "APP01" -Remove @{ 'msDS-KeyCredentialLink' = $ConfirmedUnauthorizedValue }

$ConfirmedUnauthorizedValue must contain the exact preserved, reviewed value. This is a documentation-based syntax example, not an executed recovery. Preserve approved device keys, document how each remaining value was validated and test legitimate authentication after cleanup.

Step 3: Restore trust and verify closure

If machine credentials were compromised, coordinate credential recovery with the device owner and investigate downstream access. On a domain member, Microsoft's secure-channel cmdlet provides this verification command:

Test-ComputerSecureChannel -Verbose

Run it locally in PowerShell opened with Run as administrator on the affected domain member. This documentation-based verification command was not executed. Microsoft warns that it produces false positive errors on domain controllers; follow DC-specific procedures there. A working secure channel verifies that relationship, not removal of every attacker-controlled directory value.

Close the finding only after reviewing the resulting permissions and owner, reconciling delegation and keys, checking intended service operation and confirming that monitoring receives the expected changes. Assign an owner and review date to every retained exception.

How EtcSec Detects This

The etc-collector implementation provides two catalogue views of this computer-object permission review:

• COMPUTER_ACL_GENERICALL inspects grant ACEs on computer objects for raw GenericAll or mapped AD full control, excluding built-in administrative trustees. It joins computer DNs when inventory is available and uses a less precise location heuristic when it is absent.
• COMPUTER_ACL_ABUSE reports computers carrying the DangerousACL flag. The audit engine derives that flag from allowed GenericAll, WriteDACL or WriteOwner grants on computer objects, excluding self and expected privileged trustees.

Treat these as one overlapping editorial control: a specific full-control view and an aggregate dangerous-rights view. Their trustee filters differ, so do not promise identical finding sets or sum their counts into a total of independent exposures. Both report configuration exposure; neither establishes that RBCD, a rogue key or a password reset was successfully abused. Use their affected objects to start the DACL review and correlate with change evidence.