Cracking Active Directory Domains with Kerberos Attacks
•Als PPTX, PDF herunterladen•
0 gefällt mir•378 views
1. The document discusses various methods for gaining domain administrator privileges on a Windows domain, including exploiting the domain's architecture, abusing Active Directory services like Kerberos, and cracking Kerberos tickets. 2. It provides three attack scenarios: leveraging internal access and the BloodHound tool, performing an NTLM relay attack against WebDAV to setup delegation, and directly cracking Kerberos tickets by requesting tickets for service principal names. 3. The document recommends demonstrating these attacks against a test environment to gain hands-on experience compromising a Windows domain from different starting points.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ă„hnlich wie Cracking Active Directory Domains with Kerberos Attacks
Ă„hnlich wie Cracking Active Directory Domains with Kerberos Attacks (20)
Mehr von UTD Computer Security Group
Mehr von UTD Computer Security Group (20)
KĂĽrzlich hochgeladen
KĂĽrzlich hochgeladen (20)
Cracking Active Directory Domains with Kerberos Attacks
- 1. Cracking the domain Please sign-in via QR Code or https://goo.gl/U46rfU But… gaining knowledge is fun and we always profit from knowledge...
- 2. Announcements â—Ź Square CTF - Oct 10th â—Ź Cambrian Cyber Group - October 21st â—Ź Alkami - October 28th â—Ź Firetalks - October 30th â—Ź TI - November 4th â—Ź Officer Applications!
- 3. What is a network domain? â—Ź A network domain is an administrative grouping of multiple private computer networks or hosts within the same infrastructure. â—Ź A domain controller is a server that automates logins, user groups, and architecture of the domain. â—‹ Typically on microsoft servers. â—‹ Makes it so you don't have to manual setup every host with all the domain data individually.
- 4. What do I want out of this? ● In an ideal pentest you want to control the entire network because that’s what the attackers want. ● The domain controller tells all the other systems how the domain works and how it supposed to look. ○ Controller is managed by the domain admin. ● I.E. I want to be domain admin.
- 5. Okay, so how can I become the big daddy admin? ● You could… ● Phish the admin. ● Break in through web stuff.. ● Kidnap the admin. ● “Persuade” the admin. ● Physically connect to the domain controller. ● Or you could.. ● Abuse the domains architecture to laterally move. ● Abuse active directory. ● Exploit Domain services like Kerberos.
- 6. What’s an active directory? ● The Active Directory Domain Service is a service that authenticates and authorizes all computers and users in a domain, assigning and enforcing security policies (GPO) for all computers. ○ Runs on the Lightweight Directory Access Protocol (LDAP) ● Holds data about what users can access/allowed to do on specified systems. Permissions can be given individually or through AD Groups. ● AD can have many more services like.. ○ Certificate services. ○ Federation services. ○ Rights management.
- 8. 3 attack scenarios 1. Attacking the domain by exploiting it’s architecture. Starting from comfortable shell access of a domain system. 2. Attacking a single machine by exploiting the domains kerberos system. Starting from a more restricted shell access of a domain system. 3. Owning the whole domain by exploiting the domains kerberos system. Starting from no shell access of a domain system.
- 9. Scenario 1: The Bloodhound â—Ź You are inside the network and on a system that is flexible. â—‹ Allows you to download and run things without much fuss. â—‹ Currently a user on the system. â—‹ Currently not much on the immediate system that is exploitable. â—Ź To take advantage of the domain architecture and user permissions you could use a tool called bloodhound. (https://github.com/BloodHoundAD/BloodHound/wiki) â—Ź Collects AD data through powershell to be examined on the attackers machine. â—Ź We can now quickly identify attack vectors on the victim machine.
- 11. What’s this kerberos thing I keep hearing? ● Kerberos is a network authentication protocol that works on tickets that allow for nodes over a network to prove their identity in a secure manner. ● Users are granted ticket granting tickets (TGT) which have a time limit after pre- authentication. A TGT can be used to request access to a service to then gain a ticket granting services (TGS). ● To get a TGS, a service has to be registered under a service principal name (SPN).
- 13. Kerberos delegation â—Ź Sometimes a service may need to access another service on the users behalf. â—Ź There are 3 main delegation features â—‹ Unconstrained Delegation - User gives its TGT to the service and the service uses that ticket to obtain TGS for other services. â—‹ Constrained Delegation - The service uses the users TGS to acquire TGS for other services. â—‹ Protocol Transition - Allows services to request TGS on behalf of users arbitrary users. **It can impersonate users out of thin air!!**
- 14. NTLM Relay Attack ● NetNTLM is a challenge response authentication protocol designed by Microsoft. 1. The client sends a NEGOTIATE message to request authentication and “advertise capabilities”. 2. The server sends a CHALLENGE message that contains a random 8-byte nonce. 3. The client sends an AUTHENTICATE message that contains a response to the challenge. The response is calculated using a cryptographic function with a key derived from the user’s password (the NTLM hash).
- 15. Scenario 2: Wagging the Dog ● Windows and Kerberos have some “features” that could prove useful and things we need for an successful attack. ● Kerberos offers a resource-based constrained delegation which allows a node to configure who is allowed to delegate (impersonate) them. ● This could allow for a possible NTLM relay attack to setup up this delegation on another services behalf if there is no signing on the communication. ● Windows 10 has a webdav server installed by default that doesn’t do message signing. ● When you change your account picture the user SYSTEM opens the image as well to inspect its properties. Taken from: https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html
- 16. Scenario 2: Wagging the Dog Taken from: https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html
- 18. Scenario 3: Roasting Kerberos ● Well I don’t want to impersonate other services I rather just be that service. ● Some more facts you may wanna know about kerberos ○ Need a TGT and a valid SPN to get a TGS. ○ The DC doesn’t track if it is used or if they even have access. ○ The TGS for the SPN is encrypted with the service account associated with the SPN. ○ Kerberos uses RC4_HMAC_MD5 encryption. **It uses the service account’s NTLM password hash to encrypt the ticket** ● So could we just generate NTLM hashes and see which one opens/decrypts the ticket?
- 19. Scenario 3: Roasting Kerberos The Kerberoast Attack â—Ź What if you have an admin who gives a SPN to a domain admin and makes bad passwords? â—Ź Can request a TGS to the domain admin as a normal user. â—Ź Crack the hash to get the domain admins password. â—Ź Profit???? Ticket Hash: 05f50a70b856b624df5e723 15d9c9194 Domain Admin Pass: texsaw{r3c0n_i5_my_m1ddl3 _n4me}
Hinweis der Redaktion
- Certificate is for regulating enterprise wide public key infrastructure. Federation is for single sign on services. Rights management is for restricting documents rights in AD.
- BloodHound is a single page Javascript web application, built on top of Linkurious, compiled with Electron, with a Neo4j database fed by a C# data collector. BloodHound uses graph theory to reveal the hidden and often unintended relationships within an Active Directory environment. Attackers can use BloodHound to easily identify highly complex attack paths that would otherwise be impossible to quickly identify. Defenders can use BloodHound to identify and eliminate those same attack paths. Both blue and red teams can use BloodHound to easily gain a deeper understanding of privilege relationships in an Active Directory environment.
- When users log in, they encrypt a piece of information (a timestamp) with an encryption key derived from their password, to prove to the authentication server that they know the password. This step is called “preauthentication”. In Active Directory environments, the authentication server is a domain controller. Upon successful preauthentication, the authentication server provides the user with a ticket-granting-ticket (TGT), which is valid for a limited time. When a user wishes to authenticate to a certain service, the user presents the TGT to the authentication server. If the TGT is valid, the user receives a ticket-granting service (TGS), also known as a “service ticket”, from the authentication server. The user can then present the TGS to the service they want to access, and the service can authenticate the user and make authorisation decisions based on the data contained in the TGS.
- An attacker in a man-in-the-middle position waits for an incoming NEGOTIATE message from a victim. The attacker relays the NEGOTIATE message to the target server. The target server sends a CHALLENGE message to the attacker. The attacker relays the CHALLENGE message to the victim. The victim generates a valid AUTHENTICATE message and sends it to the attacker. The attacker relays the valid AUTHENTICATE message to the target server. The target server accepts the AUTHENTICATE message and the attacker is authenticated successfully. The NetNTLM protocol does not only provide authentication but can also facilitate a session key exchange for encryption (“sealing”) and signing. The client and the server negotiate whether sealing/signing is required through certain flags in the exchanged messages. The exchanged session key is RC4 encrypted using a key derived from the client’s NTLM hash. The client obviously holds the NTLM hash and can decrypt it. However, a domain member server does not hold the NTLM hash of domain users, but only of local users. When a domain user exchanges a session key with a member server, the member server uses the Netlogon RPC protocol to validate the client’s response to the challenge with a domain controller, and if a session key was exchanged then the key to decrypt it is calculated by the domain controller and provided to the member server. This separation of knowledge ensures that the member server does not obtain the NTLM hash of the client, and the domain controller does not obtain the session key. If the client and server negotiate a session key for signing, an attacker performing a relay attack can successfully authenticate, but will not be able to obtain the session key to sign subsequent messages, unless the attacker can obtain one of the following: The NTLM hash of the victim. Credentials for the computer account of the target server. Compromise a domain controller. However, if the attacker obtains any of the above, they do not need to perform an NTLM relay attack to compromise the target host or impersonate the victim, and this is the reason signing mitigates NTLM relay attacks.
- The attacker compromises credentials or a TGT for an account that has an SPN or creates one (“Service A”). The attacker gains unprivileged access to another computer running Windows 10 or Windows Server 2016/2019 with the WebDAV Redirector feature installed (“Service B”). If required, the attacker uses Service A to add a DNS record using ADIDNS. The attacker changes the account profile picture to a path on a rogue WebDAV NTLM relay server. The attacker relays the computer account NTLM authentication to the LDAP service on the domain controller, and configures resource-based constrained delegation from Service A to Service B. The attacker uses Rubeus to perform a full S4U attack to obtain a TGS to Service B for a user that has local administrator privileges on it. The attacker can pass-the-ticket to compromise Service B.
- This attack involves requesting a Kerberos service ticket(s) (TGS) for the Service Principal Name (SPN) of the target service account. This request uses a valid domain user’s authentication ticket (TGT) to request one or several service tickets for a target service running on a server. The Domain Controller doesn’t track if the user ever actually connects to these resources (or even if the user has access). The Domain Controller looks up the SPN in Active Directory and encrypts the ticket using the service account associated with the SPN in order for the service to validate user access. The encryption type of the requested Kerberos service ticket is RC4_HMAC_MD5 which means the service account’s NTLM password hash is used to encrypt the service ticket. This means that Kerberoast can attempt to open the Kerberos ticket by trying different NTLM hashes and when the ticket is successfully opened, the correct service account password is discovered. Works well because service account passwords are typically short.