diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 911b4b8bc..4e7b0adb5 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -241,6 +241,7 @@ - [Windows C Payloads](windows-hardening/windows-local-privilege-escalation/windows-c-payloads.md) - [Active Directory Methodology](windows-hardening/active-directory-methodology/README.md) - [Abusing Active Directory ACLs/ACEs](windows-hardening/active-directory-methodology/acl-persistence-abuse/README.md) + - [BadSuccessor](windows-hardening/active-directory-methodology/acl-persistence-abuse/BadSuccessor.md) - [Shadow Credentials](windows-hardening/active-directory-methodology/acl-persistence-abuse/shadow-credentials.md) - [AD Certificates](windows-hardening/active-directory-methodology/ad-certificates/README.md) - [AD CS Account Persistence](windows-hardening/active-directory-methodology/ad-certificates/account-persistence.md) diff --git a/src/windows-hardening/active-directory-methodology/README.md b/src/windows-hardening/active-directory-methodology/README.md index ff3ce2414..9567c394e 100644 --- a/src/windows-hardening/active-directory-methodology/README.md +++ b/src/windows-hardening/active-directory-methodology/README.md @@ -166,7 +166,7 @@ Regarding [**ASREPRoast**](asreproast.md) you can now find every possible vulner - You could use the [**CMD to perform a basic recon**](../basic-cmd-for-pentesters.md#domain-info) - You can also use [**powershell for recon**](../basic-powershell-for-pentesters/index.html) which will be stealthier -- You ca also [**use powerview**](../basic-powershell-for-pentesters/powerview.md) to extract more detailed information +- You can also [**use powerview**](../basic-powershell-for-pentesters/powerview.md) to extract more detailed information - Another amazing tool for recon in an active directory is [**BloodHound**](bloodhound.md). It is **not very stealthy** (depending on the collection methods you use), but **if you don't care** about that, you should totally give it a try. Find where users can RDP, find path to other groups, etc. - **Other automated AD enumeration tools are:** [**AD Explorer**](bloodhound.md#ad-explorer)**,** [**ADRecon**](bloodhound.md#adrecon)**,** [**Group3r**](bloodhound.md#group3r)**,** [**PingCastle**](bloodhound.md#pingcastle)**.** - [**DNS records of the AD**](ad-dns-records.md) as they might contain interesting information. @@ -322,7 +322,7 @@ Having **WRITE** privilege on an Active Directory object of a remote computer en resource-based-constrained-delegation.md {{#endref}} -### ACLs Abuse +### Permissions/ACLs Abuse The compromised user could have some **interesting privileges over some domain objects** that could let you **move** laterally/**escalate** privileges. diff --git a/src/windows-hardening/active-directory-methodology/acl-persistence-abuse/BadSuccessor.md b/src/windows-hardening/active-directory-methodology/acl-persistence-abuse/BadSuccessor.md new file mode 100644 index 000000000..87bc156e5 --- /dev/null +++ b/src/windows-hardening/active-directory-methodology/acl-persistence-abuse/BadSuccessor.md @@ -0,0 +1,69 @@ +# Abusing Active Directory ACLs/ACEs + +{{#include ../../../banners/hacktricks-training.md}} + +## Overview + +Delegated Managed Service Accounts (**dMSAs**) are a brand‑new AD principal type introduced with **Windows Server 2025**. They are designed to replace legacy service accounts by allowing a one‑click “migration” that automatically copies the old account’s Service Principal Names (SPNs), group memberships, delegation settings, and even cryptographic keys into the new dMSA, giving applications a seamless cut‑over and eliminating Kerberoasting risk. + +Akamai researchers found that a single attribute — **`msDS‑ManagedAccountPrecededByLink`** — tells the KDC which legacy account a dMSA “succeeds”. If an attacker can write that attribute (and toggle **`msDS‑DelegatedMSAState` → 2**), the KDC will happily build a PAC that **inherits every SID of the chosen victim**, effectively allowing the dMSA to impersonate any user, including Domain Admins. + +## What exactly is a dMSA? + +* Built on top of **gMSA** technology but stored as the new AD class **`msDS‑DelegatedManagedServiceAccount`**. +* Supports an **opt‑in migration**: calling `Start‑ADServiceAccountMigration` links the dMSA to the legacy account, grants the legacy account write access to `msDS‑GroupMSAMembership`, and flips `msDS‑DelegatedMSAState` = 1. +* After `Complete‑ADServiceAccountMigration`, the superseded account is disabled and the dMSA becomes fully functional; any host that previously used the legacy account is automatically authorised to pull the dMSA’s password. +* During authentication, the KDC embeds a **KERB‑SUPERSEDED‑BY‑USER** hint so Windows 11/24H2 clients transparently retry with the dMSA. + + +## Requirements to attack +1. **At least one Windows Server 2025 DC** so that the dMSA LDAP class and KDC logic exist. +2. **Any object‑creation or attribute‑write rights on an OU** (any OU) – e.g. `Create msDS‑DelegatedManagedServiceAccount` or simply **Create All Child Objects**. Akamai found 91 % of real‑world tenants grant such “benign” OU permissions to non‑admins. +3. Ability to run tooling (PowerShell/Rubeus) from any domain‑joined host to request Kerberos tickets. +*No control over the victim user is required; the attack never touches the target account directly.* + +## Step‑by‑step: BadSuccessor*privilege escalation + +1. **Locate or create a dMSA you control** + ```bash + New‑ADServiceAccount Attacker_dMSA ` + ‑DNSHostName ad.lab ` + ‑Path "OU=temp,DC=lab,DC=local" + ``` + +Because you created the object inside an OU you can write to, you automatically own all its attributes . + +2. **Simulate a “completed migration” in two LDAP writes**: + - Set `msDS‑ManagedAccountPrecededByLink = DN` of any victim (e.g. `CN=Administrator,CN=Users,DC=lab,DC=local`). + - Set `msDS‑DelegatedMSAState = 2` (migration‑completed). + +Tools like **Set‑ADComputer, ldapmodify**, or even **ADSI Edit** work; no domain‑admin rights are needed. + +3. **Request a TGT for the dMSA** — Rubeus supports the `/dmsa` flag: + + ```bash + Rubeus.exe asktgs /targetuser:attacker_dmsa$ /service:krbtgt/aka.test /dmsa /opsec /nowrap /ptt /ticket: + ``` + +The returned PAC now contains the SID 500 (Administrator) plus Domain Admins/Enterprise Admins groups. + +## Gather all the users passwords + +During legitimate migrations the KDC must let the new dMSA decrypt **tickets issued to the old account before cut‑over**. To avoid breaking live sessions it places both current‑keys and previous‑keys inside a new ASN.1 blob called **`KERB‑DMSA‑KEY‑PACKAGE`**. + +Because our fake migration claims the dMSA succeeds the victim, the KDC dutifully copies the victim’s RC4‑HMAC key into the **previous‑keys** list – even if the dMSA never had a “previous” password. That RC4 key is unsalted, so it is effectively the victim’s NT hash, giving the attacker **offline cracking or “pass‑the‑hash”** capability. + +Therefore, mass‑linking thousands of users lets an attacker dump hashes “at scale,” turning **BadSuccessor into both a privilege‑escalation and credential‑compromise primitive**. + +## Tools + +- [https://github.com/akamai/BadSuccessor](https://github.com/akamai/BadSuccessor) +- [https://github.com/logangoins/SharpSuccessor](https://github.com/logangoins/SharpSuccessor) +- [https://github.com/LuemmelSec/Pentest-Tools-Collection/blob/main/tools/ActiveDirectory/BadSuccessor.ps1](https://github.com/LuemmelSec/Pentest-Tools-Collection/blob/main/tools/ActiveDirectory/BadSuccessor.ps1) + +## References + +- [https://www.akamai.com/blog/security-research/abusing-dmsa-for-privilege-escalation-in-active-directory](https://www.akamai.com/blog/security-research/abusing-dmsa-for-privilege-escalation-in-active-directory) + + +{{#include ../../../banners/hacktricks-training.md}} \ No newline at end of file diff --git a/src/windows-hardening/active-directory-methodology/acl-persistence-abuse/README.md b/src/windows-hardening/active-directory-methodology/acl-persistence-abuse/README.md index 2648d7696..7e2d99b6e 100644 --- a/src/windows-hardening/active-directory-methodology/acl-persistence-abuse/README.md +++ b/src/windows-hardening/active-directory-methodology/acl-persistence-abuse/README.md @@ -4,6 +4,12 @@ **This page is mostly a summary of the techniques from** [**https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/abusing-active-directory-acls-aces**](https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/abusing-active-directory-acls-aces) **and** [**https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/privileged-accounts-and-token-privileges**](https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/privileged-accounts-and-token-privileges)**. For more details, check the original articles.** +## BadSuccesor + +{{#ref}} +BadSuccesor.md +{{#endref}} + ## **GenericAll Rights on User** This privilege grants an attacker full control over a target user account. Once `GenericAll` rights are confirmed using the `Get-ObjectAcl` command, an attacker can: