Impacket GetUserSPNs & Kerberoasting Explained
Summary
TLDRThis 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
🔒 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.
🖥️ 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.
🔑 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.
📚 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.
Mindmap
Keywords
💡Kerberos
💡Service Principal Names (SPNs)
💡Hashcat
💡Active Directory
💡Domain Controller
💡Kerberos Silver Ticket
💡Pre-authentication
💡TGS (Ticket-Granting Service)
💡Encryption Type 23
💡Managed Service Accounts
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
関連動画をさらに表示
#34 Spring Security | Bcrypt Password Encoder
Windows Server Homelab: Implementing Service Accounts| Single Purpose Computers (Ep 6)
Troubleshooting the most common Active Directory account issues | Real World IT Tickets
Chapter #8 - Cloud IAM Basics | identity & access management on google cloud platform (gcp)
Cyber4All App Demo, Part 1
Windows Latest CMD Hacks & Tricks
5.0 / 5 (0 votes)