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.
Domain Name Server (DNS) to look up for particular Active Directory Resource using dig linux command line utility
dig -t SRV _ldap._tcp.pri-dc-01.cryotoambient.com ( LDAP AD server discovery)
dig -t SRV _gc._tcp.pri-dc-01.cryotoambient.com ( Global Catalog LDAP recon for entire active directory forest)
dig -t _kerberos._tcp.pri-dc-01.cryotoambient.com ( Identify Key distribution center KDC)
dig -t SRV _kpasswd.tcp._tcp.pri-dc-01.cryotoambient.com ( 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
Figure 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 192.168.1.100.
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
Figure 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
- KRBTGT NTLM Hash
- 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