Kerberos Attack Surface

There are different ways of attacking active directory and the attack surface/vectors change all the time. I do like to use built-in tools and my own Linux box to interact with the windows infrastructure environment for few good reasons:

  • Not every environment use NTLM authentication
  • Hacker/Security tools fails to work in Kerberos only environment
  • Stealth – Kerberos less monitored protocol
  • Kerberos is less understood protocol
  • Majority of SIEM services fails to identify
  • Kerberos is difficult to monitor and identify anomalies
  • My ridiculous ego,unconscious aspect of the personality is happier with kerberos
  • Gained initial foothold e.g phishing, web app exploit, client side attack etc.
  • Gained physical access and connected to target network Wired/WiFi.
  • You have no credentials to begin but you are connected to target network.
Reconnaissance Phase:

Domain Name Server (DNS) to look up for particular Active Directory Resource using  dig linux command line utility

dig  -t SRV ( LDAP  AD server discovery)

dig -t  SRV   ( Global Catalog  LDAP recon for entire active directory forest)

dig -t  ( Identify Key distribution center KDC)

dig -t  SRV  ( Kerberos Password changer server)

Example dig command to identify kerberos (KDC Servers)


Figure 1 dig Linux utility to identify  KDC (Kerberos Key Distribution Center)


Similarly we can conduct reconnaissance using NSLOOKUP utility


Figure 2 identifying KDC using nslookup command line utility

LDAP –  We can identify domain controller  and request few details with no authentication:

  •  Functionality level  e.g.  Is the target server 2003,2008/2012 domain controller
  • Identify KDC Kerberos Distribution Center
  • Limited objectclass information e.g. Domain metadata

unauthenticated ldap query


Figure 3  ldapsearch to list juicy useful metadata

Domain functionality level is 4 indicating the target server is Windows 2008 R2

functionality-levelFigure 4 unauthenticated ldap query to identify target server functionality level.


Figure 5  -Ref Microsoft MSDN

You can also use Netbios to identify  hosts in a network  (NBT) still in use for legacy system. I leave this to the reader for unsupervised reading investigate how an attacker abuse NBT (nbtscan & responder)

Imagine that we obtained an unprivileged AD user with no remote desktop/no special privilege with most basic active directory rights e.g. simple basic active directory authentication.

NTLM SessionErro (NTLM Not Supported)


Figure 6 standard penetration tools fails to work with valid credentials

CME  Fails to with correct credentials. (Sky is falling – Target infrastructure is Kerberos only)


Figure 7 CME and other pen test tools fails due to NTLM authentication is disabled

Under the hood at the packet level we see the see NTLMSSP_Auth Plinux user request failed due to the NTLM is not supported.


Figure 8 Attempt to establish NTLM session fails no session created.

Quick look at the Active Security Policy shows the  NTLM Authentication in this domain set to deny all ( Do not apply this to your production environment it will break legacy system communicating with the active directory server )


Figure 9  Deny all to NTLM authentication. Very difficult to implement/apply deny all, due to the legacy products and still list of major network devices doesn’t support Kerberos authentication.

Sky is falling none of our standard security tools no longer work? So maybe the target system is SECURE?  Not so easy…  Kerberos (Hound of Hades)  Multi-Headed dog that guards the gates of the windows environment ( Dead from leaving )

Ok lets utilize MIT Kerberos V5 to operate in secure kerberos environment:

  • Configure /etc/krb5.conf and specify  default_realm to your AD
  • Set the relams at the bottom of configuration file to Active directory FQDN


Figure 10 we setup/configure kerberos KRB5 client and set the relam to our target domain controller to communicate target windows environment via Kerberos authentication.

We must make changes  to /etc/resolv.conf and point our attacking Linux machine to active directory domain name server (DNS) in our case the active directory runs  as DNS  and the IP is


Figure 11 pointed our attacking Linux machine to the active directory

KRB5 configuration is complete we can now authenticate to Active Directory account.


Figure 12 kinit ambientuser user with valid password to create TGT Ticket Granting Ticket. The ticket issued by KRBTGT kerberos master key. Klist shows valid Principal.

smbclient with kerberos to authenticate the target victim server

8Figure 13 kerberos authentication used to connect the target server

rpcclient with  -k flag initiated to connect the target victim server


Figure 14 authenticated to the target server with TGT ticket

Shell? gaining shell via kerberos using wmiexec


Figure 15 limited shell with kerberos authentication on target victim machine

psexec with kerberos authentication against target server


Figure 16 psexec to authenticate target victim server

Golden ticket:
  • Domain Sid
  • Target Domain
  • Impersonated user


Figure 17 forged kerberos ticket user notadministraor to authenticate as domain admin target domain controller server.

Set export KRB5CCNAME variable to the forged kerberos notadministrator.cacche ticket


Figure 18 set KRB5CCNAME to our impersonated notadministrator.ccache

  • Least privilege principle
  • Remove the use of NTLM authentication as much as possible and rely on Kerberos
  • Enable kerberos auditing
  • Monitor Kerberos authentication TGT & TGS tickets