In this entry, we continue with some known attacks on Active Directory environments using Kerberos, mainly lateral movement and persistence.
One of the oldest and most known ways of lateral movement is Pass the hash, where we use a user’s NTLM hash to gain access to resources or computers where the user has some level of privilege.
As seen in a previous post, Pass the hash becomes quite critical, since it is not necessary for the attacker to know the user’s password in order to impersonate it, where the impact increases exponentially when using local administrator accounts, since, without the correct monitoring tools, it will be difficult to detect this type of attack.
When an attacker gains access to a local administrator account, he could exploit PTH if the following conditions are met:
- There are other hosts with a shared password between local administrators and a compromised credential.
- Windows hosts allow remote authentication using local accounts.
- Local administrator accounts are enabled.
However, there are advanced monitoring tools that could detect possible PTH attacks, both at the domain and local level. (Since PTH authentication is done using local administrators, access logs are not recorded in a domain controller, they stay on the computer, so a Blue Team would have to analyze the local logs of internal computers, or implement a SIEM to obtain all this information that is not being stored in the domain controllers).
There are numerous articles on how to detect PTH or indications that can be observed in the access logs of the respective computers that suggest that this attack is being carried out.
For this reason, we present in this post a slightly stealthier technique than PTH, called Pass the ticket.
The Kerberos authentication flow is a bit complicated to explain in a nutshell (I don’t fully understand it yet enough to write confidently about it), but for this scenario, we’ll keep things simple.
When a user authenticates through Kerberos, as a result, he gets a Ticket, either a service ticket or a “ticket granting ticket (TGT)”, this ticket could be considered as an identity document, which can be used in the internal domain to access certain resources without the need to authenticate with username and password.
If an attacker gains control of one of these tickets, he can use it to impersonate the affected user and access internal domain resources as if he were the owner of the ticket.
Scenario 1 – Pass the ticket
In order to configure the vulnerable environment, the only thing we need to do is login into a host with multiple users, in my case, on the host “TECNOLOGIA01”.
Exploitation
We can use the “impacket suite” to perform the attack, leveraging an existing script that automates the credential harvesting process.
As it was mentioned in previous posts, the domain authentication information is stored in memory, specifically within the “LSASS” process, so if we dump the process, we can obtain this information.
For this task, we can use multiple methods, to mention a few:
- From the GUI, we can create a dump using the task administrator.
- Using “Procdump” from Sysinternals. (procdump64.exe -accentual -ma lsass.exe -o lsass.dmp)
- Using “crackmapexec” modules. (LSASSY or procdump)
- Using a native DLL: C:\Windows\System32\rundll32.exe C:\windows\System32\comsvcs.dll, MiniDump PID-LSASS C:\temp\lsass.dmp full
- Other tools (Processdump from Cisco Jabber, SQLDumper from MSSQL, mimikatz, etc.)
The script I mentioned before is called autoProc.py.
Link: https://gist.github.com/knavesec/0bf192d600ee15f214560ad6280df556
It’s recommended to edit the script, to set the correct path where the tool will look for the procdump binary.
This script will authenticate to the host through “wmiexec”, it’ll upload the “procdump” binary, execute it, downloads and deletes the output from the victim host and processes it using “pypykatz”.
Since we have administrative access on the “TECNOLOGIA01” host, we can execute “autoProc” to obtain the lsass dump from the host.
In this case, Windows defender is preventing the dump, so we’ll proceed to disable it remotely, as we did so on previous posts.
PS C:\Windows\System32> Set-MPPreference -disableRealTimeMonitoring $true
Once the antivirus is disabled, we successfully obtain the required information.
This time, by specifying the “-k” flag on “pypykatz”, we’ll be able to extract the existing Kerberos tickets.
Listing the extracted tickets.
We can observe that there are many service tickets, as well as TGT tickets for two users, Service_BD and Administrator, which we can use to impersonate these users.
Since we extracted these tickets straight from a dump file, we need to convert the kerberos tickets from .kirbi to .ccache, we can do that by using the tool “kirby2ccache”, then we set up an environment variable named “KRB5CCNAME” pointing towards our new .ccache ticket and we execute “klist”, confirming the ticket is being recognized.
We try to spawn a semi-interactive shell through “wmiexec” on the domain controller using the extracted ticket.
By using the parameter “-k”, the tool will use the active kerberos ticket instead of a password, we should also use the parameter “-no-pass” to prevent any errors in the kerberos authentication procedure.
The ticket works and we get a valid session on the domain controller, giving us full control over it without the need to obtain the password or NTLM hash of the domain admin.
PERSISTENCE – GOLDEN TICKET
Since we have a valid domain admin kerberos ticket, we’ll use it to create a golden ticket and ensure persistence, which will give us access as a domain admin for a default time of 10 years, assuming the ticket wasn’t detected.
To forge these tickets, we need the following bits of information.
- NTLM hash of the KRBTGT user
- Domain SID
- FQDN
Using impacket-secretsdump, we can obtain the KRBTGT user NTLM hash.
The “-just-dc-user” parameter will allow us to extract a single user hash from the NTDS.dit database.
KRBTGT: 7f9b6cfb……bf1
To extract the domain SID, we can also use impacket suite, in this case, “lookupsid”.
To obtain this information, we can use any valid user within the domain, even low privileged ones.
Domain SID: S-1-5-21…..13415
For the FQDN, we can spawn a remote session on the Domain Controller and query the operating system through WMIC.
FQDN: jsec.local
Now we can forge our golden ticket using impacket suite, “ticketer”.
impacket-ticketer -nthash HASH-KRBTGT -domain-sid SID -domain FQDN USER
We’ll create a ticket for the domain user ‘DC01$’ and save it as “DC01$.ccache“.
We export the ticket with “export KRB5CCNAME=’./DC01$.ccache'” and dump the NTDS.dit database once again.
We get all of the domain users NTLM hashes, confirming the validity of our ticket.
It’s important to note that we don’t even need to impersonate a valid domain user, we can create the ticket for a non-existing user and we’ll still have Domain Admin privileges, because of the way the ticket is forged.
We generated a new ticket for the user “goldenticket“, which doesn’t exist in the current domain, but the access is still granted.
These are some of the known Kerberos attacks, mainly for lateral movement and persistence.
In future posts, we’ll explore slightly more complicated scenarios (Constrained delegation, Domain Admin to Enterprise Admin, etc.).