Kerberoasting without SPN

Service principal name (SPN)  yes Active Directory (AD) Records in the database , Show which services are registered to which accounts ：

have SPN Account example for

If an account has one SPN Or more SPN, You can Kerberos To one of them SPN Request service ticket , And because part of the service ticket will be encrypted with a key derived from the account password , You will be able to crack this password to force it offline . This is it. Kerberoasting How it works .

There is a way to do this without knowing the target service SPN In case of execution Kerberoasting attack . I will show you how it is done , How it works , And when it will work .

Kerberos Basic knowledge of

Kerberos It's based on ASN.1 Open source binary protocol .Kerberos The core of is the key distribution center (KDC) service , It USES 88/tcp and 88/udp port ​​. stay Active Directory Environment , They are installed on each domain controller .

Let's run Impacket Medium GetUserSPNs.py Tools to demonstrate Kerberoasting How it works ：

Execute in a lab environment Kerberoasting attack

First , The tool is connected to LDAP, And find a with SPN And is not a user of a computer account .AD Each machine account in has a stack of SPN, But their service tickets cannot be brutally cracked , Because the machine account has 240 Byte long passwords .

then , The tool is connected to KDC, And use its for each discovered account SPN One to get a service ticket . In our example , Only one account was found , And the tool selects “MSSQLSvc/sp-sql:1433”SPN To request a ticket .

It is not important that the selected service is functioning properly ;AD There is... In the database SPN Enough to attack .

This is it GetUserSPNs.py Started traffic dump , So now we can go through all the described phases in detail ：

Kerberoasting Attack traffic dump

How customers get TGT

Each client must report to KDC Authenticate and obtain a ticket granting ticket (TGT), This will allow them to continue to request any number of service tickets .

This mechanism is used to reduce the number of times that authentication is required , No, TGT There is no way to bypass it to request a service ticket .

Not authenticated AS-REQ / Preauth request

AS-REQ Packets are used to request TGT.

stay AS-REQ in , The client is in sname Field “krbtgt/DomainFQDN”SPN, And in cname Field TGT Principal name of the account ：

Not authenticated AS-REQ Contents of the packet (#7)

first AS-REQ Packets are sent without authentication data , To maintain backward compatibility . Only in the target account Active Directory Set up in DONT_REQ_PREAUTH When marking , It will succeed .

AS-REQ The response of should contain a structure , This structure uses a key derived from the password of the customer account for encryption and signing , So if AS-REQ Work without any authentication , Anyone can brutally crack other people's passwords offline .

This is called ASREPRoasting attack , stay Impacket It can be made up of GetNPUsers.py Script execution ：

Use from Impacket Of GetNPUsers.py perform ASREPRoasting attack

ASREPRoasting One application of is Targeted Kerberoasting. It depends on being intentional for you in AD Account settings controlled in DONT_REQ_PREAUTH sign , And get it $krb5asrep$  Hash value .

Because of the “ Administrators ” Account not set DONT_REQ_PREAUTH sign , therefore KDC A... Was sent to the client KRB-ERR Data packets , It includes KRB_PREAUTH_REQURED error . This packet is called Preauth request .

KRB-ERR Contents of the packet (#8)

If “ Administrators ” Account does not exist , We will receive KDC_ERR_C_PRINCIPAL_UNKNOWN error . This is Kerberos The user enumerates the functions used in the attack .

Certified AS-REQ

Let's examine the next AS-REQ Data packets ：

Certified AS-REQ Contents of the packet (#9)

next AS-REQ Basically the same as the first request , But it contains data that can authorize clients . This data is a special structure that contains the current timestamp , This structure is encrypted and signed with a key derived from the account password .

The key derived from the account password is called Kerberos secret key , How they are calculated depends on the encryption algorithm used ：

• AES-128 and AES-256： The key is based on the password PBKDF2 Hashed
• RC4： The key is from the password NT Hash calculated （ Always with Pass-The-Hash Use with attacks ）
• DES： The key is calculated directly from the password

Use the client principal name in the request ,KDC Try to AD Find the client's account in the database , Extract its pre calculated Kerberos secret key , And verify the identity of the client .

AS-REP

stay KDC After verifying the identity of the client , It will send one AS-REP Data packets , It contains clients from which to build TGT Data of memory object ：

AS-REP Contents of the packet (#10)

TGT In itself krbtgt Of the account kerberos Key encryption and signature , It is therefore intended only to KDC End decompression . It contains the session key 、 Metadata and privileged attribute certificate of the client (PAC).PAC Include the name of the client 、 Security identifier (SID) And groups .

In order for the client to use TGT, It needs to construct a TGT Memory objects , This object will contain TGT In itself 、 Its session key and all metadata . The client is encrypted from its key AS-REP Partially extract the session key .

How customers get service tickets

Client construction TGT After the memory object , It can be used TGS-REQ Packets request any number of service tickets . When these requests are accepted ,KDC Will use TGS-REP The packet responds .

TGS request

TGS-REQ The name of the service principal that contains the ticket request 、TGT And use TGT A structure that encrypts the session key and contains the current timestamp ：

TGS-REQ Contents of the packet (#11)

When KDC received TGS-REQ when , It decrypts TGT, Extract session key , And check the identity of the client .

TGS-REP

TGS-REP Packets are used to transfer service tickets to KDC client .

stay KDC After verifying the identity of the client , The following steps will be carried out ：

1. KDC Check according to the decrypted timestamp TGT Whether it is still valid ;
2. If TGT More than... After sending 15 minute ,KDC Recalculate the decrypted PAC, And check whether the client is Active Directory Is not disabled in ;
3. KDC Find the account to which the sent service principal name resolves ;
4. KDC Withdraw the... Of the discovery account kerberos secret key ;
5. KDC Building service tickets , from PAC And service ticket session key ; The service ticket uses the... Of the service account kerberos Key to encrypt and sign ;
6. KDC Create a structure using the service ticket session key , And use TGT The session key encrypts and signs it .

Both the service ticket and the structure with the service ticket session key are contained in TGS-REP In the packet ：

TGS-REP Contents of the packet (#12)

The encrypted part of the service ticket is in Kerberoasting The part of the attack that has been brutally cracked .

Explore the format of the principal name

Let's check what we collected before AS-REQ The principal name in the packet ：

Kerberos Example of principal name in traffic

The client principal name is in cname Field , The service principal name is in sname Field . All principal names have an integer called the principal name type .

The principal name usually consists of “/” Characters are divided into a series of strings . for example , Subject name Of krbtgt / CONTOSO .COM stay Kerberos The communication consists of two strings ：KRBTGT and CONTOSO.COM.

according to RFC 4120, cname and sname Fields have different uses , But the structure of these fields is the same ：

KDC-REQ-BODY    ::= SEQUENCE {
 kdc-options  [0] KDCOptions,
 cname        [1] PrincipalName OPTIONAL
 realm        [2] Realm
 sname        [3] PrincipalName OPTIONAL,
 ...
}

PrincipalName   ::= SEQUENCE {
 name-type    [0] Int32,
 name-string  [1] SEQUENCE OF KerberosString
}

KerberosString  ::= GeneralString (IA5String)

cname and sname The same structure of the fields caught my attention , I've decided to Kerberos Testing their different uses in the protocol .

Kerberos The secret of

Find out Windows KDC Services are handled through the same set of functions cname and sname Field , And it doesn't matter which format the principal name chooses at any given time .

All principal names resolved to the same account are the same

If you are in Kerberos There is a... In the packet SPN value , You can replace it with this SPN Of the account SAM Account name (SAN) value , And there will be no interruption ：

with SAN Of TGT-REQ Packet example

This allows you to do so without knowing anything about the target account SPN In case of execution Kerberoasting attack . however , Will continue to require at least one target account to exist SPN.

Reward ： To relive S4U and AnySPN attack

I checked Impacket Source code , I found two interesting places , They are closely related to the technologies found , But with Kerberoasting irrelevant .

Use SAM Account name S4U2Self and S4U2Proxy request

Let's try to use getST.py Formal Impacket To abuse resource-based constraint delegation ：

Use Impacket Examples of abuse of resource-based constraint delegation

Here we have “user01” account , This account has “http/test”SPN And authorized access “SRV02$” Any of the accounts SPN Authority .

According to the specification （S4USelf KRB_TGT_REQ,S4U2Proxy KRB_TGS_REQ）,user01 Your service should be in S4U2Self and S4U2Proxy It is used in the request SPN. however , You can see Impacket In this type of request SAN：

Impacket Of S4U2Self Requested traffic dump

These requests do not conform to the specification , But it will succeed , because Windows KDC Insensitive to the given principal name format .

AnySPN attack

Impacket We have realized a kind of system called AnySPN Something to attack . This attack attempts to modify the SPN, When it comes to target services SPN Different time ：

Use Impacket perform AnySPN attack

Alberto Solino Wrote an excellent article Kerberos entrust 、SPN And more   Explain how it works .

This is the main part of this article ：

Alberto Solino A fragment of the article

In short ,Benjamin Delpy、Ben Campbell and Alberto Solino Notice the host A On Service A The service ticket of may be applicable to the host A Service on B.

actually , If we decrypt the encrypted part of any service ticket , We will see that it does not contain any SPN：

Decrypt the encrypted part of the service ticket with the password of the service account

Print the information contained in the service ticket encryption section

The encrypted part of the service ticket only contains the session key of the ticket 、 Metadata and authentication of users PAC. Service ticket SPN Included in the unencrypted and unsigned parts of the protocol , The client may not consider it at all .

The service ticket is valid for all services running under its service account

therefore , If you want to know if there is SPN To which... The service ticket will be issued when the service ticket is requested SPN, Now you know that the service ticket does not contain anything .

Reward ： Use primary name type

cname and sname The structure of the field contains a called Principal Name Type The integer of .RFC 4120 The specification defines 9 Possible values ：

RFC 4120 Excerpt from ：6.2. Principal's name

I did some research , And create a table , It contains the actual Principal Name Types Value and its value in Windows The meaning of ：

Name type	value	significance
NT- Unknown	0	representative SPN and SAN Format
NT- The headmaster	1	be equal to NT-UNKNOWN
NT-SRV-INST	2	be equal to NT-UNKNOWN
NT-SRV-HST	3	be equal to NT-UNKNOWN
NT-SRV-XHST	4	Express SPN Format
NT-UID	5	I won't support it
NT-X500- The headmaster	6	representative DN Format
NT-SMTP- name	7	be equal to NT-UNKNOWN
NT- Enterprises	10	representative UPN、SAN And a variety of DomainName+SAN Format
NT-MS- The headmaster	-128	representative SAN And a variety of DomainName+SAN Format
NT-MS-PRINCIPAL-AND-ID	-129	be equal to NT-MS-PRINCIPAL
NT-ENT-PRINCIPAL-AND-ID	-130	Equate to NT-X500-PRINCIPAL
	*	be equal to NT-UNKNOWN

I find NT-ENTERPRISE Types are more common than NT-UNKNOWN Types are more valuable . It supports the following stack of name formats ：

• User principal name
• sAMA Account name
• [email protected]
• [email protected]
• Domain NetBIOSName\sAMAccountName
• Domain FQDN\sAMAccountName

Please note that , If you use SRV01  String as sAMAccountName, also SRV01  Account does not exist , and SRV01$  Account exists , Then this name will be regarded as SRV01$  Principal name of the account .

Other interesting principal name types are NT-X500-PRINCIPAL. It supports RFC 1779 The structure of the DN . Here is how to write the same in this structure Active Directory Three examples of objects ：

CN=SQL ADMIN,OU=LAB Users,DC=CONTOSO,DC=COM
CN="SQL ADMIN";OU="LAB Users";DC="CONTOSO";DC="COM"
OID.2.5.4.3=SQL ADMIN,OU=LAB Users,DC=CONTOSO,DC=COM

Unfortunately , Cross forest trust does not support NT-X500-PRINCIPAL type .

The technology Kerberoasting Application in

I have NT-ENTERPRISE and NT-MS-PRINCIPAL The usage of type is added to Impacket Of GetUserSPNs.py. Let's see when these changes are Kerberoasting Three common situations necessary for success .

cannot access LDAP Of Kerberoasting

You may find yourself in a situation ： You can visit KDC service , You get a list of accounts （ for example , adopt RID Loop attack ）, But you don't SPN.

Because you no longer need SPN, You can use the new -userfile Option to request service tickets only from the user list ：

Use the new GetUserSPNs.py Execute by user list Kerberoasting

The -userfile Option utilization NT The enterprise type looks up from the specified file accountd.

Incorrect use SPN Of Kerberoasting account

KDC Ticket refund is prohibited SPN There are two types of ：

• Wrong grammar SPN
• Repetitive SPN, That is, when the same SPN When values are assigned to multiple accounts

If KDC One of the findings is this , It will be returned KDC_ERR_S_PRINCIPAL_UNKNOWN error , It's like passing on SPN There is no such thing as ：

Use incorrect SPN Make... To the account Kerberoasting

new GetUserSPNs.py Change the account list from LDAP Package to NT-MS-PRINCIPAL type , And don't use SPN, So you can even misunderstand SPN Get hash value in ：

Use the new GetUserSPNs.py Yes SPN Incorrect account Kerberoasting

For internal use “DomainFQDN\sAMAccountName” Format , In the output “\” Change the character to “/”, To conform to Impacket Format the user name and prevent it from escaping in other tools .

adopt Forest Trusts Use NetBIOS name SPN Make... To the account Kerberoasting

When you request from another domain SPN My service ticket , And this SPN have NetBIOS Hostname in name format , Your KDC The target service will not be found ：

Trust through Lin to have NetBIOS name SPN Account for Kerberoast Handle

Use the new GetUserSPNs.py file , You will never get such services KDC_ERR_S_PRINCIPAL_UNKNOWN：

Use the new GetUserSPNs.py Trust through the forest has NetBIOS name SPN Account for Kerberoasting