Impacket GetUserSPNs & Kerberoasting Explained

Summary

This video tutorial delves into the Kerberos Silver Ticket attack technique, demonstrating how to exploit user accounts with Service Principal Names (SPNs) in an Active Directory domain. Using the 'get_userSPNs' script and hashcat, the attacker can capture and decrypt encrypted data to obtain user passwords, all without needing admin rights. The script's process is explained, highlighting the importance of SPNs and the potential risks of setting services to run under user accounts. The tutorial also touches on best practices like using Managed Service Accounts to mitigate such vulnerabilities.

Takeaways

• 😀 The video demonstrates a technique called Kerberos Silver Ticket attack, which exploits user accounts with Service Principal Names (SPNs).
• 🔒 The attack requires initial domain credentials but does not need special permissions like admin rights.
• 🖥️ The setup involves two virtual machines: one acting as a domain controller with Active Directory and the other as an attacker machine separate from the domain.
• 🔎 The 'get_userSPNs' script from Impacket is used to identify user accounts with SPNs, which are then targeted for the attack.
• 🔑 The attack relies on the fact that user accounts often have weaker passwords than computer accounts, making them more susceptible to cracking.
• 🔄 The process includes using Kerberos authentication to request a Ticket-Granting Service (TGS) ticket, which is encrypted with the user's password.
• 📈 The TGS ticket, once cracked using hashcat, reveals the user's password, granting the attacker access to the service the account is running.
• 🛠️ The video mentions the use of managed service accounts or group managed service accounts as a more secure alternative to running services under user accounts.
• 🔗 The script performs an LDAP search to find user accounts with SPNs, which is a crucial step in identifying potential targets for the attack.
• 📚 The video script serves as an educational guide, explaining the technical aspects of the Kerberos Silver Ticket attack in detail.
• 🔮 The video promises a follow-up on Kerberos Silver Tickets, indicating a deeper exploration of the attack technique in subsequent content.

Q & A

What is the Kerberos Silver Ticket attack?

The Kerberos Silver Ticket attack is a technique where an attacker uses a user's account password to forge a Ticket-Granting Service (TGS) ticket, which can then be used to gain unauthorized access to services within a domain that authenticate using Kerberos.

What is the purpose of using the 'get user SPNs' script in the attack?

The 'get user SPNs' script is used to identify user accounts that have Service Principal Names (SPNs) assigned to them. These accounts are vulnerable to the attack because they have services that authenticate with Kerberos.

Why is it necessary to have DNS server settings pointing to the domain controller during the attack?

DNS server settings need to point to the domain controller because Kerberos authentication requires the use of fully qualified domain names (FQDNs). Correct DNS settings ensure that the attacker can resolve the domain controller's FQDN and perform the attack correctly.

What is the significance of the user account having a service principle name (SPN)?

A user account with an SPN is significant because it indicates that the account is associated with a service that authenticates with Kerberos. This makes the account a potential target for the Kerberos Silver Ticket attack.

What is the role of hashcat in the Kerberos Silver Ticket attack?

Hashcat is a password cracking tool used in the attack to decrypt the encrypted data obtained from the Kerberos TGS request. Once decrypted, the user's password can be revealed, allowing the attacker to forge tickets.

Why are computer accounts not targeted in the Kerberos Silver Ticket attack?

Computer accounts are not targeted because they have very long and complex passwords that are automatically changed by the system every 30 days. Cracking these passwords is impractical due to their length and complexity.

How does the attacker use the cracked user account password in the context of the attack?

Once the user account password is cracked, the attacker can use it to forge a TGS ticket, pretending to be that user and gaining access to services that the user account has access to within the domain.

What is the difference between using a user account and a managed service account to run a service?

A user account may have a simple password and can be used to run a service with Kerberos authentication. A managed service account, on the other hand, has a long, complex password that is automatically changed, making it more secure and less susceptible to attacks like the Kerberos Silver Ticket attack.

Why might an administrator set a service to run as a user account?

An administrator might set a service to run as a user account to grant specific permissions to access resources across the network. This allows for more granular control compared to running the service as a local system or network service account.

What is the next step or related attack after successfully performing a Kerberos Silver Ticket attack?

After successfully performing a Kerberos Silver Ticket attack, the next step or related attack could be a Pass-the-Hash attack or escalating privileges within the domain using the compromised user account.

Outlines

00:00

🔒 Kerberos Silver Ticket Attack Overview

This paragraph introduces a cybersecurity technique known as the Kerberos Silver Ticket attack. The speaker plans to demonstrate the attack using an 'Impacket' script called 'get_userSPNs' combined with 'hashcat' to extract a user's password. The setup involves two virtual machines: one acting as a domain controller with a basic Active Directory domain, and the other as an attacker machine not part of the domain. The speaker mentions that this attack is similar to previous Kerberos attacks covered in past videos, which targeted accounts without pre-authentication enabled. The process begins with a demonstration and will be followed by an explanation of how the attack works. It is noted that the attack requires some initial domain credentials but does not need special permissions or admin rights.

05:03

🖥️ Setting Up the Attack Environment

The speaker discusses the technical setup for the Kerberos attack, emphasizing the need for fully qualified domain names (FQDNs) over IP addresses for Kerberos authentication. The process involves configuring the attacker machine's DNS server to point to the domain controller and using the 'get_userSPNs' script to identify user accounts with service principal names (SPNs). The script is executed with the domain name, a user account, and its password as parameters. The speaker points out that the attack requires only ordinary domain user credentials and does not necessitate admin-level access.

10:05

🔑 Cracking Kerberos Tickets with Hashcat

In this section, the speaker demonstrates the use of 'hashcat' to crack the encrypted Kerberos ticket data obtained from the 'get_userSPNs' script. The process involves identifying the correct hash type from 'hashcat' examples and using it to decrypt the ticket, which yields the user's password. The speaker successfully recovers the password for a service account, illustrating that the attack can work against any user account in the domain that runs a service authenticating with Kerberos, using only basic domain credentials.

15:06

📚 Understanding Service Principle Names (SPNs) and Kerberos Vulnerability

The speaker explains the concept of service principal names (SPNs) and their role in Kerberos authentication. SPNs are necessary for services that use Kerberos authentication and are composed of a service name, machine name, and optionally a port number. The speaker clarifies why computer accounts are not targeted in such attacks due to their long, complex passwords that change automatically. In contrast, user accounts with SPNs are vulnerable if they have weak passwords. The speaker also discusses why services might be configured to run under a user account and the security implications of doing so, including the use of managed service accounts as a more secure alternative.

🔄 The Process of the Kerberos Silver Ticket Attack

This paragraph delves into the technical details of how the Kerberos Silver Ticket attack operates. The process begins with authenticating a legitimate user account with the domain controller and conducting an LDAP search to find user accounts with SPNs. When a Ticket-Granting Service (TGS) is requested for a service, the response is encrypted with the password of the account running the service. This encrypted data can be cracked to reveal the account's password, which can then be used to forge tickets claiming membership in any group, effectively bypassing the need for further authentication with the domain controller. The speaker also mentions that this attack serves as a precursor to a more advanced 'silver ticket' attack, which will be covered in a subsequent video.

Keywords

💡Kerberos

Kerberos is a network authentication protocol designed to provide strong authentication for client/server applications by using secret-key cryptography. In the video, Kerberos is the core authentication mechanism being exploited to perform a 'Kerberos Silver Ticket' attack, which involves obtaining a user's password by leveraging the user's service principal names (SPNs).

💡Service Principal Names (SPNs)

Service Principal Names are unique identifiers used by Kerberos to associate a service instance with a domain account. In the script, the 'get user SPNs' script searches for user accounts with SPNs, which are crucial for the attack because they indicate that the account is used to run a service that authenticates with Kerberos.

💡Hashcat

Hashcat is a password recovery tool that uses various techniques to crack hashed passwords. In the context of the video, it is used to crack the encrypted Kerberos ticket, which was obtained by exploiting a user account with SPNs, ultimately revealing the user's password.

💡Active Directory

Active Directory is a directory service that Microsoft developed for the Windows domain networks. It is used for authentication and provides a centralized location for managing users, computers, and other resources. The video's scenario involves a basic Active Directory domain setup for demonstrating the attack.

💡Domain Controller

A Domain Controller is a server that handles security and access control for a Windows domain. In the script, the Domain Controller is the target of the Kerberos authentication process, where the attacker manipulates the authentication to gain unauthorized access.

💡Kerberos Silver Ticket

A Kerberos Silver Ticket is a type of ticket that an attacker can forge to gain access to a service within a Windows domain. The video discusses how obtaining a user's password through the described attack can lead to creating a Silver Ticket, which can be used to authenticate as that user to any service within the domain.

💡Pre-authentication

Pre-authentication is a step in the Kerberos authentication process where the client proves its knowledge of the password without sending the password over the network. The video mentions that if pre-authentication is disabled, it could be exploited in a different type of Kerberos attack.

💡TGS (Ticket-Granting Service)

The Ticket-Granting Service is a part of the Kerberos protocol that issues tickets to access services within the domain. In the script, after obtaining a TGT (Ticket-Granting Ticket), the attacker requests a TGS to access a specific service, which is then used to obtain the encrypted data that can be cracked.

💡Encryption Type 23

Encryption Type 23 refers to the specific encryption method used in the Kerberos protocol. In the context of the video, it is the encryption type of the TGS reply that the attacker captures and later cracks using Hashcat to reveal the user's password.

💡Managed Service Accounts

Managed Service Accounts are a type of domain account designed to provide services with a domain account that has automatic password management and the ability to delegate permissions to access resources. The video suggests using Managed Service Accounts as a security measure to mitigate the risk of the described attack.

Highlights

Introduction to Kerberos Silver Ticket attack technique using 'get user SPNs' script and hashcat.

Setup of two virtual machines: one as a domain controller with Active Directory and another as an attacker machine.

Explanation of Kerberos authentication mechanism and its relation to the attack.

Demonstration of the attack using 'get user SPNs' in PowerShell.

Importance of using fully qualified domain names (FQDN) for Kerberos authentication.

Requirement of having initial domain credentials for the attack.

Process of using hashcat to crack the encrypted data obtained from the Kerberos request.

Identification of user accounts with service principal names (SPNs) as potential targets.

Difference between attacking user accounts and computer accounts in the context of Kerberos.

Discussion on why computer accounts are not targeted due to their complex and frequently changed passwords.

Common practice of setting services to run as user accounts in Active Directory.

Explanation of why user accounts with SPNs are vulnerable to Kerberos attacks.

LDAP search demonstration to find user accounts with SPNs.

Wireshark demonstration of the Kerberos handshake process during the attack.

Clarification on how the TGS (Ticket-Granting Service) ticket is encrypted with the service account's password.

The vulnerability arises when the service account's password is compromised, allowing attackers to forge tickets.

Transition to the next video on Kerberos Silver Ticket attacks, extending the capabilities of the initial attack.

Recap of the entire attack process, from obtaining initial credentials to cracking the service account's password.

Transcripts

so today we're going to take a look at a

technique called Kerberos sting not to

do this we're going to use an impact

script called get user SPNs

and we'll combine that with hash katz

and with the two of them we'll be able

to get a user accounts password now as

usual I've got two virtual machines set

up here one that's a domain controller

with this very basic Active Directory

domain and then another which is our

attacker machine which is not a member

of the domain completely separate now if

you've seen some of my previous videos

on Kerberos attacks a lot of this will

be very familiar we're basically doing

the same thing that we did in the attack

where we used in packets get MP users

script to attack accounts that don't

have Cobras pre authentication enabled

is a very similar thing but just with a

different part of the Kerberos

authentication mechanism so you'll

definitely recognize some things if

you've seen those videos if not don't

worry because I will try and explain

things in a decent amount of detail in

this one this is also going to leave

very nicely into another video which

will be coming very soon on Kerberos

silver tickets so I think to start with

we'll just do a very quick demonstration

of the attack and then I'll go through

and explain exactly how it works so if

we run get user SP ends dr py b in

packet script I'm just going to

familiarize myself with the syntax again

I'm pretty sure we literally just need

specify the domain first of all actually

as well we need to set our DNS server to

point to the machine that were going to

be attacking the domain controller to be

fair if all you're doing is this get

user SPN the script and the Kerberos

ting attack you could probably get away

with just doing the Dutch tcpip option

with the implicit script to specify the

DC IP address you probably don't need to

set your DNS server but it's going to

make things easier when we come to do

the Kerberos solve a ticket attack so

I'm just going to do it now and it will

also mean that we don't need to specify

the IP address with this get user SPN

script so we're going to here change

adapter options because the thing is

with Kerberos you need to use fully

qualified domain names you can't use IP

addresses by default anyway there is an

option you can set to enable that but by

default if you're using an IP address to

connect to something now you won't be

using Kerberos authentication or

fallback 2011 and for this attack we

need to use Kerberos authentication so

I'm going to just put in the domain name

and then the user account we're going to

use that is one thing to point out is

that for this attack you need to already

have some credentials they don't have to

be

anything special if we look at this

account that I'm going to use it's not a

member of any special groups so she just

domain users and some random security

group as there's no special permissions

required for this just any user account

in the domain so we're gonna specify the

domain and then the user and the

password and then that should be all we

need actually so let's just try that and

there we go we get some results again

I'm gonna explain exactly where these

results coming from what they all mean

but to start where they just want to do

a demo off the attack I'm just going to

prove that it works for people that just

literally want to see a step-by-step

guide of how to do it so if we do that

again we do - requests we will get TDs

or you can just think of it as a load of

encrypted data that was encrypted with

this accounts password so if we can

crack this then we can get this accounts

password and that is essentially what

the Kerberos ting technique is all about

so we'll take all this and we'll just

put it into hash cat just copy that and

to find out what mode we need to use in

hash cat have just gone to the house cat

examples we'll just search for Kerberos

it's not this one because we're not

doing an AS req attack we're doing a TGS

attack so it will probably be this on

here you can see there we've got the

type of encryption is type 23 if we go

back to our machine you'll see here

we've got type 23 is the encryption type

there so we'll just take this number

here 13100 M

13100 and then we will paste in the

information that we got from the script

or just say you want to use the rock

cued up text file to crack it go through

and in a few seconds there we go it was

correct it so the password was just set

to the same thing that I said leave

their account to obviously they would

normally be different passwords but you

see here the password is just password

with zero so we now know the password

for that SQL service account and we

didn't really have to do anything which

is wrong run scripts pass it into hash

cat and we get the passwords and that

will work for any user account in the

domain that has been set to run a

service that authenticates with Kerberos

and again all we needed with just any

domain credentials we don't need any

kind of admin rights or anything like

that so now that you've seen the attack

in action

let's take a look at how it actually

works and why this works so if we go on

to our domain control here

and we'll look at what actually makes

this account vulnerable essentially it's

the fact that it's a user account and

it's got in its attributes

after the service principle name it's

got some values in here that is

essentially all that makes it vulnerable

to this kind of attack so for an example

if we just create a new user account

test or just a password to test as well

I just got in the habit of always taking

those things okay

finally test isn't good enough password

will just use password with a zero again

then my favorite default okay so now

we've got that account in there because

we haven't set any service principle

names on it when we run this script it

won't find that account okay so we're

not seeing our test account in there but

as soon as we add a service principle

name you don't have to do this from the

attribute editor tab you can do it from

PowerShell and there's also a set SPN

executable that's included the windows

but I'm just used to doing it through

here I'm wondering why I can't see and

that's because I've got that tick so

only shows that we've already got values

in them yes if we go into here and we

add we just put a test slash test just

put anything in there by that and now if

we go back to our attack machine when

that same script again now we could

basically just get the password for this

test account because it's got a service

principle name set so why is that the

case and also why don't we see or why

don't we go after computer accounts

because if we look at a computer account

and we go to the area it's a tab look at

service principle name see that's got

loads of sales principle names so why

aren't we attacking that why doesn't the

script find that essentially because

computer accounts have very long complex

passwords that get automatically set by

the system every 30 days I think is by

default so trying to crack them is a

very very long process potentially

impossible I can't remember off the top

of my head what the password length is

but I've got a feeling it's something

like 150 characters of just random bytes

so we can't just throw with a rock you

password list at it and assume that

we'll get cracked or even doing a brute

force crack would take forever so that's

why we don't graph the computer accounts

user accounts on the other hand

as you've just seen we can set very dumb

passwords for passwords it will probably

be in a common password list and it's

quite common for people to do this to

create a user account to run a service

like if we open up services that Emma

see this is where an admin would set

this so we go to the MS SQL service

called SQL Server you can see here that

I've set that to run using that service

account so this is that account there

that SQL servers account we've set it to

run as that account we've had to put the

password in here and that's a pretty

common thing for admins to do because

say you've got a service that needs to

access some files especially if they're

on another server it's got access

something across the network if you just

leave this running as local system or

network service then when this goes to

connect out to a file server or whatever

to do something with those files say

this was running as network service like

this one here you've got a grant that

account permission to access those files

which now means every other service

that's running as a network service has

permission to access those files and if

they were on a remote file server now

you've got to grant the computer account

for the services running on you've got

to grant that permission to access those

files which means that any service on

this entire computer that can access

things over the network has now got

permission to access those there are

some ways around that I'm not going to

go into that too much I'm just trying to

give you a rough idea of why someone

would actually set a service to run as a

user account and like you can use these

NT service accounts now that's fine for

accessing local files and resources

because now you can grant permissions to

this virtual service account that's

technically the name of them virtual

service accounts if you want to look

into them more yeah they get created for

each service and it'll just be NT

service slash the name of the service so

yeah that's fine for local access but if

you want to access something across the

network then again you're gonna have to

grant permission to the computer account

which means any service on this entire

computer can now access those resources

and that might not always be desirable

so that's a reason for using an actual

user account in the domain because now

you can grant permissions anywhere on

the network to that user account and

then set the service to run as that user

account and now only that service can

access those files and resources the

best solution though is to use a managed

service accounts or a group managed

service account and they are user

accounts in Active Directory that

essentially behave like computer

accounts

get their passwords set to those long

complex passwords and changed

automatically and then you can use them

to run a service so that's kind of the

solution to this but I'll be honest

they're not particularly well I was

gonna say they're not well supported

they out likely do they work perfectly

but actually working with them as a bit

of a pain like you can't just right

click here and create a new my service

account maybe there's some newer tools

since I last looked into them that make

it easier to use now but yeah when they

first came out managed in group managed

service accounts you had to do it all

with PowerShell and it was a little bit

awkward so there we go that was a bit of

a long tangent but I hopefully

understand that it is kind of common for

people to set services to run as a user

account from Active Directory so if that

service in this case SQL Server that

service wants to use Kerberos

authentication or wants to support

Kerberos authentication it has to have a

service principle name that's just part

of the way that Kerberos works I'm not

going to go into that too much right now

but long story short it has to have a

service principle name for it in order

for it to be able to respond to Kerberos

authentication requests and that service

principle name as you can see is made up

from the service name which can be

whatever the service wants it to be and

then the Machine name and optionally a

port number also optionally you don't

have to have the full fully qualified

domain name there you'll see in a lot of

the default ones here it'll just have or

it'll have both sites so I'll have the

service and then just the computer name

and then I'll have the service and the

computer name and the fully qualified

domain name that's because when a client

tries to connect to one of these

services it has a few options of how it

could specify the name you see there's

different variations again so the

service principle names have to support

each of those that a client could

potentially use so going back to our SQL

SVC account so we know that it's got

these SP ends how does the in package

script take advantage of that go back to

our workstation essentially all the

script is doing in this part here where

we just run it the first time without

that request all it's doing is just an

LDAP search just to find any user

accounts that have got a service

principle name we could do this

ourselves just as easily and I'm gonna

do this from the DC just so I don't have

to bother setting up like a reverse

shell and but assume that you were doing

this remotely you can do this with like

LDAP search or if you had a reverse

all going on the remote machine you

could do it this way but yeah it's just

a nailed up so if we do like get a V

user we set an LDAP filter do a service

principle name equals anything this is

going to find any user accounts that

I've got a service principle name all

right would if I actually put the dash

in the right place there we go

so what does that found is found the

krbtgt account which we can ignore

that's a built in Kerberos kind of

master key account which I've covered in

other videos the golden ticket one

specifically but yeah so other than that

it's found our SQL SVC account and it's

found our test account which is exactly

what the impact script found if we

wanted to actually see the results so

just do properties and we'll say

1includes so as principal name so now we

can see we get this after we added to

the results and it shows us the SPN for

each of these accounts so here we're

seeing those same SV ends that we saw in

actual Directory users and computers so

that's essentially all the implicit

script is doing at that point it's just

doing an LDAP search for user accounts

that have any value in the service

principal name so nothing crazy there

nothing special so we flick back to the

workstation what it does when we do dat

request though is if we open up

Wireshark this is where things will get

very familiar for people who have seen

the get MP users video we just do a

capture on the network card and we run

that stop this I'm gonna filter it for

Kerberos now what we can see is that we

get the normal Kerberos kind of

handshake going on to authenticate the

user account and this is authenticating

legitimate user account the a Smith

account and in a previous video where we

were looking at Kerberos pre

authentication and the get NP user

script this part here basically wouldn't

happen because if pre off is disabled we

kind of skip this part and we go

straight to here where we just get back

some encrypted data that's encrypted

with the users password and we can crack

it again that's covered in a previous

video I'm not going to go over that now

so even though preauth is enabled on

this account

we've got legitimate credentials for

this a Smith account so we're fine then

we move on to the tds part now these are

doubled here because we've got one where

we're requesting that test service and

then we've got the one where we're

requesting the SQL service so we're just

gonna ignore test service or focus on

this

well part so now going to explain

everything that Kerberos does but for

this part we're going to focus on just

accept that we log on as a legitimate

user account we get what's called a TGT

and then we can use that TGT to request

a ticket for a service the TGT proves

that we are who we say we are so in this

case we're saying I am a Smith our user

account and I want to access this mssql

service on this computer the Kerberos

service or the domain controller in this

case you would think would do some kind

of like authorization check to see if

this user account is allowed to access

this service but it doesn't it just says

sure here's a TGS which is another kind

of ticket for that service you can use

that to access the service now it's then

up to the service itself to decide if

this user account is allowed which is

fine because the service will look at

this this encrypted data here which

we'll get onto in a second this contains

the the user's username and the groups

are they're a member of so the service

can look at that because it can decrypt

this again I'll explain how why in a

second

it can decrypt that you can see this

user is a member of these groups it's

got this username this security ID are

they allowed in satisfying the access

controls how things is still okay it's

not as if this part here means that we

can now just access every service in the

world the service can still easily deny

us access but to actually do the

Kerberos authentication side of things

we need to pass it this TGS ticket and

that's what it's sending back to us here

this TGS rep is the domain control

sending as a ticket the we can then pass

on to whatever service this is that

we're trying to access so this encrypted

part is the important bit really because

it's encrypted with this e type of 23

and if you remember in the hash code

examples let me show you it we ended up

using this here because it's a TGS rep

and it's a type 23

okay so Kerberos TDS rep e type 23 we go

back to our machine we'll see we've got

the Kerberos TGS rep e type 23 so that's

why we use that hash cap mode to decrypt

this text here so like I've said

multiple times this is encrypted and

it's encrypted using the password of the

service account that is running this

service ok so this is the service front

access and those service principle names

that we were looking at earlier the SP

ends they tie that user account which

was called SQL SVC in our case that SQL

SVC user account is

to this service because it has service

principle name that matches this service

and this machine name okay so that means

that Kerberos and the drain controller

knows that that account is what is

running this service so when it sends

out a TDS for this service again the TDS

is just a ticket that the user gets back

and that they can then pass on to the

service to prove that they are who they

say they are and that they are a member

of these groups and the way we prove

that is the fact that this is encrypted

with the password of the service account

because the user doesn't know the

password of the service account in

theory the only things that know the

password of the service account are the

service because it's running as that

service account and the domain

controller because that's where the

password is stored so that acts as like

a shared secret key for all of this and

that proves the authenticity of this

whole ticket that we're sending so now

when the service receives this request

from us we pass on this ticket this

encrypted ticket to the service it can

decrypt it because it's got its own

password and then it can read the

contents of it if we tried to just fake

our own ticket that said I'm a member of

the domain admins and we send that off

to the service we wouldn't have the

password to encrypt this correctly so

the service would decrypt it using its

password it would just fail the

decryption it wouldn't make any sense so

we would know this wasn't a legitimate

ticket obviously where this all falls

down though is if we do manage to get

the password for this account which is

what we've just done with this attack so

then we can just fake this whole ticket

ourselves we can say I am a member of

domain admins might say it is the

administrator SID we could fake it we

encrypt all of that with the password

that we know for the service account

create this whole ticket send it off to

the service we don't even have to talk

to a domain controller at all we just

talk to the service because we use the

right password to encrypt all this it

can decrypt it thinks it's legitimate

and then it thinks we're a member of

domain admins and that is basically what

Kerberos silver ticket attack is but

we're going to look at that in more

detail and do a demo of that in the next

video but yeah for this one that is

probably about it I feel like I've been

a little bit quick going over all this

stuff and maybe some diagrams would help

when we're talking about you know

passing tickets around but to be fair

there's a lot of examples online if you

just search for like Ross authentication

diagram or something you'll see exactly

how it all kind of flows it's not that

complicated it seems it at first

especially when you're looking at it in

why

but it's really fairly straightforward

and some good videos and good articles

that explain it this is a real quick

recap just to kind of rundown of the

whole process the whole attack starts by

us having some legitimate credentials

use those to authenticate with a domain

controller and do an LDAP search to find

any user accounts that have a service

principle name associated with them

because that means that when we request

a TGS for that service so we request a

TDS for this service here we'll get some

data back that is encrypted with the

password of this account which is what

this data here is we can then crack that

offline with hash cap and get the

password for this account now that's

kind of the end of that attack but it

feeds very nicely into a silver ticket

attack obviously we could now that we've

just got the password for this account

we could just look around as that

account you know maybe that's got access

to something special that we didn't have

access to with these credentials that's

quite likely because it's a service

account you can probably do more than a

regular user account and so that is a

perfectly valid attack on its own but

like I say it feels very nicely into a

silver ticket attack because now we can

forge our own TDs and just claim to be a

member of whatever groups who want so I

think that covers it let me know if you

have any questions I will do my best to

answer them in the comments as always

and yeah I will see you in the next

video