Now after we have the domain information, we move on to the next phase of penetration testing – directly to the attack. Let’s consider 4 potential vectors:

• Roasting
• Attack via ACL
• Kerberos delegation
• Abusing GPO Permissions

Roasting

This type of attack targets the Kerberos protocol. There are 2 types of Roasting attack:

• Kerberoast
• Asreproast

Kerberoast

The attack was first demonstrated by user timmedin at DerbyCon in 2014. If the attack is successful, we will be able to sort out the password of the service account in offline mode, without fear of blocking the user. Quite often, service accounts have excessive rights and a static password, which may allow us to obtain domain administrator rights.

To understand the essence of the attack, let’s consider how the Kerberos works.

1. The password is converted to an NTLM hash, the timestamp is encrypted with a hash and sent to KDC as an authenticator in the TGT ticket request (AS-REQ). The domain controller (KDC) checks the user information and creates a TGT ticket.
2. The TGT ticket is encrypted, signed and sent to the user (AS-REP). Only the Kerberos service (KRBTGT) can open and read data from a TGT ticket.
3. A user submits a TGT ticket to a domain controller when requesting a TGS ticket (TGS-REQ). The domain controller opens a TGT ticket and checks the PAC checksum.
4. The TGS ticket is encrypted with the NTLM hash of the service account password and sent to the user (TGS-REP).
5. The user provides a TGS ticket to the computer on which the service is running (AP-REQ). The service opens a TGS ticket using its NTLM hash.
6. Access to the service is provided (AS-REP).

Having received a TGS-ticket (TGS-REP), we can find the password for the service account offline. For example, using hashcat.

According to RFC396, are reserved 20 types of encryption for the Kerberos protocol. The types of encryption that are used now, in order of priority:

1. AES256_CTS_HMAC_SHA1
2. AES128_CTS_HMAC_SHA1
3. RC4_HMAC_MD5

In recent versions of Windows, AES encryption is used by default. But for compatibility with the systems below Windows Vista and Windows 2008 server, is required support for the RC4 algorithm. During carrying out an attack, is always first made an attempt to obtain a TGS ticket with RC4_HMAC_MD5 encryption, which allows you to quickly sort through passwords, and then through the rest of data. Harmj0y conducted an interesting study and found out that if you specify only Kerberos AES128 and AES256 encryption support in the user properties, the Kerberos ticket will still be issued with RC4_HMAC_MD5 encryption.

Disabling RC4_HMAC_MD5 is necessary at the domain level.

Kerberoasting attack has 2 approaches.

1. The old method. TGS tickets are requested via setspn.exe or the .NET System.IdentityModel.Tokens.KerberosRequestorSecurityToken of the Powershell class, retrieved from memory using mimikatz, then converted to the desired format (John, Hashcat) and sorted.
2. The new method. machosec noticed that the KerberosRequestorSecurityToken class has a GetRequest method, which extracts the encrypted part with a password from a TGS ticket.

Tools for conducting an attack:

1) Search for SPN records

• ps1
• Find-PSServiceAccounts.ps1
• Get-NetUSER -SPN
• (Get-ADUser -Filter {ServicePrincipalName -ne “$ null”} -Properties ServicePrincipalName) .ServicePrincipalName

2) Request a TGS ticket

• exe (native Windows utility)
• Ticket request through powershell

Add-Type -AssemblyNAme System.IdentityModel

New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList “<ServicePrincipalName>”

• Request-SPNTicket

You can view the current cached tickets using the klist command.

3) Export of tickets:

• Invoke-Mimikatz -Command ‘“ Kerberos :: list / export ”’
• Mimikatz -Command ‘“ Kerberos :: list / export ”’
• Invioke-kerberoast
• py

An example of automated execution of all 3 points:

• RiskiskSPN

Find-PotentiallyCrackableAccounts -Sensitive -Stealth -GetSPNs | Get-TGSCipher -Format "Hashcat" | Out-File kerberoasting.txt

• Powersploit

Invoke-Kerberoast -Domain jet.lab -OutputFormat Hashcat | fl

• py

GetUserSPNs.py -request jet.lab\user:Password

Asreproast

The vulnerability is here in disabled Kerberos pre-authentication. In this case, we can send AS-REQ requests to a user who has disabled Kerberos pre-authentication and get the encrypted part with a password.

The vulnerability is rare, since disabling preauthentication is not the default setting.

Searching for Users with Disabled Kerberos Authentication:

• Powerview

Get-DomainUser -PreauthNotRequired -Properties samaccountname -Verbose

• Active Directory Module

get-aduser -filter * -properties DoesNotRequirePreAuth | where {$ _. DoesNotRequirePreAuth -eq "True" -and $ _. Enabled -eq "True"} | select Name

Getting the encrypted part:

• ASREPRoast

Invoke-ASREPROast | fl

Attack via ACL

An ACL in a domain context is a set of rules that define the access rights of objects in AD. An ACL can be configured for a single object (for example, a user account), or for an organizational unit, for example, OU. When you configure the ACL on the OU, all objects within the OU will inherit the ACL. ACLs contain access control entries (ACEs) that determine how the SID interacts with the Active Directory object.

For example, we have three groups: A, B, C, where group C is a member of group B and group B is a member of group A. When the guest user is added to group C, guest will not only be a member of group C, but also an indirect member of groups B and A. By adding access to a domain object to group A, the guest user will also have access to this object. In a situation where the user is a direct member of only one group, and this group is an indirect member of the other 50 groups, it is easy to lose the connection of inherited permissions.

You can retrieve the ACLs associated with the object by running the following command:

Get-ObjectACL -Samaccountname Guest -ResolveGUIDs

You can use the tool to exploit errors in ACL configuration.

Invoke-ACLPwn. The Powershell script collects information about all ACLs in the domain using the BloodHound collector, SharpHound, and builds a chain to obtain writeDACL permission. After the chain is built, the script operates each step of the chain. The order of the script:

1. The user is added to the necessary groups.
2. Two ACEs (Replicating Directory Changes and Replicating Directory Changes ALL) are added to the ACLs of the domain object.
3. If you have rights to DCSync using the Mimikatz utility, is requested the password hash of the user krbtgt (default setting).
4. After the operation is completed, the script deletes all added groups and ACE entries in the ACL.

The script is aimed only at using writeDACL permissions. The following access rights may also be of interest to an attacker:

• Rights to change the user password when the current password is not known. Operation with PowerSploit – Set-DomainUserPassword.
• Rights to add groups, computers, and users to groups. Operation with PowerSploit – Add-DomainGroupMember.
• GenericWrite Rights to change the attributes of an object. For example, change the value of the scriptPath parameter. The next time the user logs on to the system, the specified file starts. Operation with PowerSploit – Set-DomainObject.
• WriteOwner. Rights to change the owner of the object. Operation with PowerSploit – Set-DomainObjectOwner.
• Rights to add users to groups, change user passwords, etc. Operation with PowerSploit – Set-DomainUserPassword or Add-DomainGroupMember.

Exploitation:

• Invoke-aclpwn

Starting from a machine that is in a domain:

./Invoke-ACL.ps1 -SharpHoundLocation. \ Sharphound.exe -mimiKatzLocation. \ Mimikatz.exe

Starting from a machine that is not in a domain:

/Invoke-ACL.ps1 -SharpHoundLocation. \ Sharphound.exe -mimiKatzLocation. \ Mimikatz.exe -Username 'domain \ user' -Domain ‘fqdn_of_target_domain’ -Password ‘Pass’

• aclpwn.py  – similar tool written in Python.