Domain Privilege Escalation
Checklist : https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Active%20Directory%20Attack.md
Common Attack Methods
Common Misconfigurations
MS14-068
Due to insufficient validation of Group memberships, a domain user's ticket can be re-written to Domain admin.
Kekeo
MITM Attacks
LLMNR/NBT-NS/WPAD Poisoning
NTLM Relaying
Requires SMB-Signing to be OFF
Requires victim to be LA on relayed target.
Identify network systems that do not require SMB message validation
Configure Impacket’s NTLMrelayx to target those systems
Disable SMB and HTTP request/response poisoning in Responder and launch
Wait for creds
Inveigh relaying works only for HTTP Proxy
Integrated DNS Zones
mitm6
Utilizes IPv6 and DNS to relay credentials to a target. By default, IPv6 is enabled and actually preferred over IPv4, meaning if a machine has an IPv6 DNS server, it will use that over the IPv4. Also by default, Windows machines look for an IPv6 DNS server via DHCPv6 requests, which if we spoof with a fake IPv6 DNS server, we can effectively control how a device will query DNS.
LDAP Relay
Used to relay LDAP credentials to DC.
Leverages the default configuration of not required signed LDAP binds.
Identify Domain Admin's workstation.
Establish MITM between workstation and gateway.
Inject a hidden link in the web traffic pointing to an HTTP listener that requests NTLM authentication.
Redirect the captured credentials to DC.
MS-15-011 [GPO
There's a link in the Group Policy object to SYSVOL containing settings for the GPO so that the files can be copied and then applied.
If we become MITM between DC SYSVOL share and a client, we can have that client run our version of that Group Policy.
References:
Passwordless RDP Session Hijack
Requires SYSTEM privileges.
RDP
Successful attack can result in decrypted RDP session containing keystrokes and subsequently privileged credentials.
Cain
Seth: Useful to bypass RDP with TLS or RDP configurations enhanced with CredSSP.
NLA prevents this attack.
Modern defenses can easily detect this attack.
ARP Poisoning
PrivExchange
Pre-requisites:
User credentials with access to mailbox
Exchange server with excessive permissions on DC(default)
Access Control Abuse
References:
Abuse SeBackup privilege
This privilege causes the system to grant all read access control to any file (only read).
GenericAll on Group
Abuse User-Force-Change-Password
Exchange Windows permissions (EWP) security group membership
Add DCSync rights to current user and own the entire domain
Privilege escalation can be accomplished by adding a compromised user from the "Organizational Management" security group to the "Exchange Trusted Subsystem" group that is nested within the "Exchange Windows Permissions" group.
At this point modifycing ACLs of AD objects is possible, and assigning permissions "Replicating Directory Changes" can lead to DCSync rights on the domain.
RBAC Role
AD Recycle Bin Group Membership
The Active Directory Recycle Bin is used to recover deleted Active Directory objects such as Users, Groups, OUs etc. The objects keep all their properties intact while in the AD Recycle Bin, which allows them to be restored at any point.
Kerberoast
Service Account Kerberoast
Offline cracking of service account passwords.
We target User Accounts used as Service Accounts as Machine Account hashes are nearly impossible to crack.
If SPN is not null, DC assumes it is a service account.
The Kerberos session ticket (TGS) has a server portion which is encrypted with the password hash of service account. This makes it possible to request a ticket and do offline password attack.
Service accounts are many times ignored (passwords are rarely changed) and have privileged access.
Password hashes of service accounts could be used to create Silver tickets.
Leaves a 4769 log entry on DC. But this is very common, hence very silent attack.
Tip: Target tickets for accounts older than 2015 and newer than 2005.
Avoids honey accounts.
Easier to crack RC4 encryption.
High likelihood of weak passwords.
Workflow
A attacker authenticates to a domain and gets a ticket-granting-ticket (TGT) from the domain controller that’s used for later ticket requests.
The attacker uses their TGT to issue a service ticket request (TGS-REQ) for a particular servicePrincipalName (SPN) of the form sname/host, e.g. MSSqlSvc/SQL.domain.com. This SPN should be unique in the domain, and is registered in the servicePrincipalName field of a user or computer account. During this request process, the attacker can specify what Kerberos encryption types they support (RC4_HMAC, AES256_CTS_HMAC_SHA1_96, etc).
If the attacker’s TGT is valid, the DC extracts information from the TGT, stuffs it into a service ticket. Then the domain controller looks up which account has the requested SPN registered in its servicePrincipalName field. The service ticket is encrypted with the hash of the account with the requested SPN, using the highest level encryption key that both the attacker and the service account support. The ticket is sent back to the attacker in a service ticket reply (TGS-REP).
The attacker extracts the encrypted service ticket from the TGS-REP. Since the service ticket was encrypted with the hash of the account linked to the requested SPN, the attacker can crack this encrypted blob offline to recover the account’s plaintext password.
Find User Accounts
Request a TGS
Crack Service Account Hash
https://github.com/nidem/kerberoast
AS-REP Roast
Kerberos Pre-authentication : Disabled
If a user's UserAccountControl settings have "Do not require Kerberos preauthentication" enabled i.e. Kerberos preauth is disabled, it is possible to grab user's crackable AS-REP and brute-force it offline.
With sufficient rights (GenericWrite or GenericAll), Kerberos preauth can be forced disabled as well.
Rare in corporate environments.
Workflow
[AS-REQ] Timestamp is encrypted with the NTLM hash of the user and sent to KDC. This is when Pre-Auth is enabled. KDC knows that the request came from the specific user. If disabled, this step can be spoofed.
[AS-REP] KDC creates a TGT which is encrypted. It contains an additional information which is signed with the user's NTLM hash.
Attacker grabs the AS-REP and cracks the user's NTLM hash offline.
Reference: https://www.harmj0y.net/blog/activedirectory/roasting-as-reps/
Enumerating accounts with Kerberos Preauth disabled
Force-Disable Kerberos Pre-auth with GenericWrite or GenericAll ACL
Cracking the hashes
Set SPN
If we have enough permissions -> GenericAll/GenericWrite we can set a SPN on a target account, request a TGS, then grab its blob and bruteforce it.
Make sure the set SPN is unique in the domain.
We can then request a TGS from this user and crack the hash offline.
Enumerate Permissions
Set an SPN for the use
Request TGS -> Export TGS to disk and brute-force offline. Steps are mentioned in the Service Account Kerberoast technique above.
Kerberos Delegation
References
GuidepointSecurity : Link
https://stealthbits.com/blog/what-is-kerberos-delegation-an-overview-of-kerberos-delegation
Kerberos Workflow
User logs on with username & password.
1a. Password converted to NTLM hash, a timestamp is encrypted with the hash and sent to the KDC as an authenticator in the authentication ticket (TGT) request (AS-REQ). 1b. The Domain Controller (KDC) checks user information (logon restrictions, group membership, etc) & creates Ticket-Granting Ticket (TGT).
2. The TGT is encrypted, signed, & delivered to the user (AS-REP).Only the Kerberos service (KRBTGT) in the domain can open and read TGT data
3. The User presents the TGT to the DC when requesting a Ticket Granting Service (TGS) ticket (TGS-REQ). The DC opens the TGT & validates PAC checksum – If the DC can open the ticket & the checksum check out, TGT = valid. The data in the TGT is effectively copied to create the TGS ticket
4. The TGS is encrypted using the target service accounts’ NTLM password hash and sent to the user (TGS-REP).
5. The user connects to the server hosting the service on the appropriate port & presents the TGS (AP-REQ). The service opens the TGS ticket using its NTLM password hash.
Unconstrained Delegation
Workflow
A user provides credentials to the Domain Controller.
The DC returns a TGT.
The user requests a TGS for the web service on Web Server.
The DC takes a copy of the TGT, puts it into the the TGS, delivers it back to the user.
The user sends the TGS to the web server.
The web server service account uses the user's TGT within the TGS, to request a TGS for the database server from the DC. The TGT is placed in memory for future use.
The web server service account connects to the database server as the user.
Unconstrained Delegation allows the first hop server, for example web server, to request access to any service on any computer in the domain, provided the service account for web service must be trusted for delegation to be able to make requests as a user.
DC places user's TGT inside TGS (Step 4 in the previous diagram). This TGT is signed and encrypted with the hash of the Web Service account.
The Web Service is able to decrypt the TGS and extracts the user's TGT from the TGS. This TGT is presented to the DC when requesting for a TGS for the Database server as the impersonated user.
When presented to the server with unconstrained delegation, the TGT is extracted from TGS and stored in LSASS. This way the server can reuse the user's TGT to access any other resource as the user.
'Service For User To Self' (S4U2Self). This extension allows a service to request a token for another user, by supplying their user principal name, but without supplying a password. When the user account has the T24AD flag, these tokens can be requested with the 'forwardable' attribute which allows the service to authenticate with these tokens to other services.
This could be used to escalate privileges if:
You are able to compromise a server that has unconstrained delegation set.
You are able to trick a domain user that doesn’t have ‘Account is sensitive and cannot be delegated’ enabled to connect to any service on the machine. This includes clicking on \\SERVER\Share.
Wait for a Domain Admin to connect to that machine.
Steal token from LSASS Process[Requires local admin privileges]
Inject the stolen token into memory to run privileges commands.
Identify Users/Computers having Unconstrained Delegation
An account that has the
TRUSTED_FOR_DELEGATION
UserAccountControl flag set.Tip: Ignore DCs, they are always shown as having unconstrained delegation.
We must have compromised the computer with Unconstrained Delegation enabled for this attack.
Check/Wait for Domain Admin to log in
Check if any DA token is available in LSASS process and save to disk.
We must trick or wait for a domain admin to connect a service onto the compromised computer.
Leverage printer bug to coerce the DC to authenticate to the compromised host. The incoming TGS(which contains the DC's TGT) is encrypted with the service A/c hash of the compromised host. As we control it, this TGS is decrypted and the DC's TGT is stored in LSASS.
For detailed exploit walkthrough: Refer
Constrained Delegation
Reference:
@harmj0y – S4U2Pwnage and the “s4u” section of From Kekeo to Rubeus
Microsoft documentation on the Kerberos Service for User (S4U) extension
Theory
Constrained Delegation allows the first hop server (web server in our example) to request access only to specified services on specified computers.
If the user is not using Kerberos authentication to authenticate to the first hop server, Windows offers Protocol Transition to transition the request to Kerberos.
Essentially, if a computer/user object has a userAccountControl value containing TRUSTED_TO_AUTH_FOR_DELEGATION then anyone who compromises that account can impersonate any user to the SPNs set in msds-allowedtodelegateto.
Service For User To Proxy (S4U2Proxy): This setting is controlled by the msDS-AllowedToDelegateTo attribute on the user account. It contains a list of Service Principal Names that point to which Kerberos services the user can forward these tokens.
During the first KRB_TGS_REQ to the KDC, the forwardable flag it set, which requests that the TGS returned be marked as forwardable and thus able to be used with the S4U2proxy extension. In unconstrained delegation, a TGT is used to identify the user, but in this case the S4U extension uses the PA-FOR-USER structure as a new type in the “padata”/pre-authentication data field.
Note that the S4U2self process can be executed for any user, and that target user’s password is not required. Also, the S4U2self process is only allowed if the requesting user has the TRUSTED_TO_AUTH_FOR_DELEGATION field set in their userAccountControl.
Important:
We can substitute the service allowed for impersonation with any other service we choose (using the
/altservice:
parameter) when we use the S4U process to request a TGS ticket. This is possible because the service name itself is not in a protected part of the KRB-CRED file.Any service running on the machine account. There is no validation for the SPN specified. eg: LDAP, WMI etc. as the impersonated user.
In the below example, we have the SPN configured to the time service. But since the machine account also runs LDAP, we can impersonate the DA's privileges to access LDAP and run DC Sync Attacks! [No SNAME Validation]
Scenario 1 – You have command execution as the account in question, but you don’t know the password for the account. [For more refer here]
Scenario 2 – You know the NTLM hash for the account in question (or, you at least know the cleartext password and can derive the NTLM hash).
Workflow
The user authenticates to the web service using a non-Kerberos compatible authentication mechanism.
The web service requests a ticket from the Key Distribution Center (KDC) for the 'user' account without supplying a password, as the svc_web account.
The KDC checks the svc_web userAccountControl value for the TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION flag, and that the target user is not blocked for delegation. If OK it returns a forwardable ticket for the 'user' account (S4U2Self).
The service then passes this ticket back to the KDC and requests a service ticket for the cifs/domain.com service
The KDC checks the msDS-AllowedToDelegateTo field on the svc_web account. If the service is listed it will return a service ticket for the file share (S4U2Proxy)
The web service can now authenticate to the file share as the 'user' account using the supplied ticket
Tips
HOST SPN: allows to schedule tasks.
MSSQLSvc SPN: allows DBA rights.
CIFS SPN: allows complete remote file access.
HTTP SPN: allows for the takeover of the remote webservice
LDAP : allows for DCSync
HTTP/SQL service accounts, even if they aren’t elevated admin on the target, can also possibly be abused with Rotten Potato to elevate rights to SYSTEM.
Identify users and computers with constrained delegation enabled
Computer/user object has a userAccountControl value containing
TRUSTED_TO_AUTH_FOR_DELEGATION
Either plaintext password or NTLM hash is required
#1 Using NTLM Hash
Request a TGT for Compromised Service A/c
kekeo can be used to read/write to LSASS without having administrator privileges.
Request a TGS
Inject the ticket
#2 Using Clear-text credentials
Request a TGT
DC Sync Attack
DNS Admins
It is possible for the members of the DNSAdmins group to load arbitrary DLL with the privileges of dns.exe (SYSTEM).
In case the DC also serves as DNS, this will provide us escalation to DA.
DNS service usually runs on DC, hence a quick domain privilege escalation technique!
Creates an Event ID 770 on server [dll loaded from location.dll]
References:
https://adsecurity.org/?p=4064
Pre-requisites
Compromised user belonging to DNSAdmins Group
Privileges to restart the DNS service[By default members of DNSAdmins cannot. This is the exploitable security misconfiguration]
Knowledge of location/share the target Domain Controller’s computer account can access.
RSAT to be accessible
Run on DC and restart it:
Install-WindowsFeature -IncludeAllSubFeature RSAT
Enumerate the members of the DNSAdmins group
Generate the malicious .DLL
Mimikatz
mimilib.dll: Mimilib contains a function which can be loaded as a plugin into serverlevelplugindll in the registry.
By default, the mimilib.dll logs all DNS queries to C:\Windows\System32\kiwidns.log
We can modify mimilib.dll to add our own payload[Reverse shell, Modify ACL etc.]
Tip: If a reverse shell is used, this will result in all DNS queries failing on the server as it will be too busy attending to the interactive shell. Recommended to use other asynchronous payloads.
Once dll is created, host it[via smb], or copy it to a directory which DC has read access to.
Exploiting Group Policy Preferences [GPP]
Whenever a Group Policy Preference is created inside SYSVOL, an associated XML file is also created containing data relevant to the configuration to be deployed. If a password is included, it is encrypted with AES-256 bit encryption. MS released the encryption key.
PKI Abuse - AD CS
Reference
Escalating to Enterprise Admin/Forest Root D.A
Child to Forest Root
Domains in the same forest have an implicit-two way trust with other domains.
There is a trust key between parent-child domains.
Two ways of escalating privileges between two domains of same forest:
Krbtgt hash
Trust tickets
Trust Tickets
Workflow
Client presents time-stamp encrypted with the NTLM hash of the user to the DC-1.
KDC responds with the TGT.
Client resends TGT requesting for TGS for a service.
DC-1 checks it's Global Catalog and finds the service is not in it's domain but a parent domain. Hence, DC-1 responds with an Inter-realm TGT[Referral Ticket]. This ticket is signed and encrypted with a Trust Key.
Client sends the Inter-realm TGT to DC-2. Only validation performed by the DC-2, is whether it can decrypt the Inter-realm TGT. DC-2 shares the Trust Key and can decrypt it. It assumes what's inside the TGT is valid.
DC-2 presents the TGS
Client sends TGS to the service and the service decides whether it can be accessed by the user.
Obtain Trust Key
Execute this on a Domain Controller.
Forge Inter-realm TGT
We're forging a TGT as an Administrator of a Child-Domain from Child-Domain, who is part of E.A group to the Forest Root DC.
Does not require domain admin privileges. (Only trust key)
When using Golden Ticket, you have 20 minutes before a validation takes place from the DC to verify if the associated account exists or not.
/sids: SID of the enterprise admins group of the parent domain. Only validation by DC-2 is checking whether the TGT can be decrypted(which it can since it shares the trust key). Hence we write SID history to make the request coming from us appear as it's coming from the Enterprise Admins group of the parent domain which gives us elevated privileges.
Request for a TGS for a service target domain
Tickets for services:
WMI : HOST and RPCSS
PowerShell Remoting/WinRM : HOST and HTTP
Scheduled Tasks: HOST
Use the TGS to access the targeted service
Inject ticket into LSA using kirbikator.
KRB-TGT
In comparison to Trust Tickets, in this case only TGT is created. This TGT is sent when requesting for TGS.
/sids is forcefully setting the SID History for the Enterprise Admin group for dollarcorp.moneycorp.local that is the Forest Enterprise Admin Group.
On any machine of the current domain
Tips: Avoid Suspicious Logs
Tamper the SID history to make the logs look like the Domain Admin and Enterprise Admin were communicating with each other.
Cross-Forest
Trust Flow Across Forest
In this case you can sign with the trusted key a TGT impersonating the Administrator user of the current domain. In this case you won't always get Domain Admins privileges in the external domain, but only the privileges the Administrator user of your current domain was given in the external domain.
Read this! : dirkjanm.io
Workflow is similar to Cross-Domain requests.
Except for: SID Filtering. We cannot become Enterprise admin as in Cross-Domain Priv esc.
Gained privileges will be same as the ones provided for the requesting DC.
For example:
If our DC is part of Builtin Administrators Group in target Forest, we will get Administrators Group permissions.
If our DC can access a file-share, we can do the same on target Forest.
SID Filtering
TGT contains PAC which contains group memberships of a user.
When TGTs - >TGSs are requested from Forest A to Forest B:
Only existing SIDs from Forest A are allowed.
Non existing SIDs/ForestSpecific SID that exists in forest B within TGT are filtered out.
It still allows us to pretend to be any user in Forest A, so if users from Forest A have been given any special privileges in Forest B
Trust Flow Abuse
Obtain Trust Key
Forge an Inter-forest TGT
Request for TGS
Tickets for other services like HOST,RPCSS,HTTP can be created.
Last updated