Alright . Hello everybody . Good
morning , good afternoon and good
evening welcome to a vendor con 2020 .
I like to thank the panel for choosing
my our RFP and you know , giving me the
opportunity to present this topic to
you guys . I'm gonna be talking to you
about Kerberos and you know we're gonna
talk through some different attack
vectors and really why I think this
protocol is so important for us to
understand if you are in the Windows
active directory kind of security space .
So a little bit about me . My name is
Alberto Rodriguez . I go by a rod in
the different social media channels .
I'm a father husband son . I am a part
of the army reserves as a cyber
operations officer and my civilian
employer . I am a sock lead in an
offensive lead doing a little bit of
threat hunting and hacking for my full
time job . And I also teach . So I'm an
adjunct professor at different
universities . I love to teach and
they're on the right , you know , huge
heat fan and I like to code and those
are just two of my family favorite
languages there . So again , thank you
for choosing my talk . I think there
was some competition there some really
great topics at this conference and
let's get to it . So on the agenda for
today we're going to be discussing
authentication as it relates to
Microsoft . We're gonna try and I do
say try , I will try my best to explain
Kerberos . Uh you know from start to
finish , we're going to discuss some
key terms and then we're gonna get into
some of the tactics that relate to this
protocol . A S rep roasting curb
roasting over past the hash on
constrained delegation abuse golden
tickets , silver tickets and then we'll
finish things off . Alright so to
start off Microsoft authentication is
pretty complex and there's a lot of
different protocols . Some are used ,
some are not used depending on the
configuration in your environment . But
one that is very popular is Kerberos
and we're gonna talk about it a little
bit later but I just wanna caveat that
even though it's pretty popular in an
actor director environment and within
Windows authentication , it also exists
within Linux operating system . So it's
not just a Windows Microsoft thing
to continue . We have N . T . L . M .
Which is pretty popular I think we all ,
you know we're all kind of familiar
with N . T L . M N T L . M . Being a
proprietary authentication protocol
from from Microsoft that uses a
challenge and response method and
then we start getting into some of the
cloud authentication and obviously you
know this talk is solely going to focus
on curb rose but there's some really
interesting implications as it relates
to an on premise active directory
security consideration . Once we do
an on premise to cloud synchronization
of data . Uh So as you're a D . And on
premise do play nicely and it's
interesting how they play . I highly
recommend you check out some of those
some of that security research . um
Adam Chester to name to name a few .
And the Specter ops team there as well .
So definitely check that out . But for
this talk we're gonna focus on Kerberos .
Alright so Kirby Rose one on one . Um
you know really it's an authentication
protocol between a server and client .
And there are three different
components that are very important to
understand and I'm gonna , you know ,
reiterate them almost every slide I'm
gonna use these terms . So it's
important for us to kind of understand
that the first piece and again this is
Windows or Linux agnostic . It doesn't
matter . The authentication protocol
itself needs a key distribution center
which is A K D C . And for us in
Microsoft A . D land that happens to be
the domain controller . The second
piece we're going to need is the client
and the client is you know the customer
basically that entity that workstation ,
that user that is requesting access to
a third component of curb Rose a
service . And that service could be
sequel . You know , it could be https ,
it could be C I F S etcetera . So those
three components are very very
important . The K D C . The clients and
the service and Kerberos . The
authentication itself uses shared
secrets for that authentication and for
Windows specifically that happens to be
the nT Lm hash
so we're about to deep dive into it . I
did post the Microsoft docks there at
the bottom highly recommend for you
guys to check out what Microsoft has to
say . But let's get to it . Let's get
to it . Alright , so the first step of
Kerberos is the actual
password itself for that user . So
we're going to create the scenario
where we have a workstation with the
user name of Olaf . There's a domain
controller which again it's the K D . C .
And then we have server one which
happens to be where the service is
being hosted . So Olaf is going to
have their password on their
Elsa's which is the Windows process
that basically contains lots of secrets
within the operating system . So that
password is hashed and stored within
Elsa's . The second step of
Kerberos is Olaf is going to
request a T G . T , which is a ticket
granting ticket from the K D . C .
Which is a domain controller using the
highest domain supported encryption .
Uh And this is simply for backwards
compatibility compatibility reasons .
So in this instance we're just going to
pretend that that T G . T
request is used with a S 2
56 H Mac . And this is known
as the authentication service request .
A s request . All right .
Step 2.5 . Just like quick caveat .
Um you know , the K . D . C . Is going
to receive that user name and it's
going to verify and the domain
controller's database . Whether that ,
you know hash actually matches the
specific users . Hash that was provided .
So if this is true then step three
would be the authentication is valid .
You know , the user checks out no
issues . The domain controller is able
to confirm this and then this domain
controller is going to return a ticket
granting ticket that is encrypted and
signed by the K . R . B . T . G . T .
Hash which happens to be like the
master account so to speak and Kerberos
speak . And that T . G . T . Is
known as the authentication service ,
response A . S . Rep . And it's going
to go into Elsa's . So now in Elsa's we
have two things that we're tracking .
Uh One is , you know all the passwords
encrypted and the different algorithms .
And then two is the T . G . T . For
that specific user . And again that T .
G . T . Is the output
of the user requesting the domain
controller for it . So within that T .
G . T . There's a privileged account
certificate and that's just called the
pack . So within the T . G . T .
There's a pack and it just has relevant
information about the user to include
like the user name , the domain said
etcetera . There's a couple other
different things there . So again to
this point we haven't actually interact
with with the service yet . It's just
the user , you know , authenticating to
the D . C . Saying hey I'm good to go .
I got creds . Okay awesome . Here's
your T . G . T . Great I am ready for
business step forward . So as a user
I'm going to try to access the C . I .
F . S . Service on server one . Uh you
know like the file share type of
service to access some file system
information . And what I'm going to do
is what's called a TGS request
and I'm going to present my T . G . T
back to the domain controller which is
really interesting because they're the
ones who gave it to me . But
nonetheless I'm going to present the T .
G . T . To the domain controller and
this is going to request from the D .
C . The service principal name of that
service that I'm requesting . So again ,
if I'm Olaf and I'm saying , hey I want
server one dot dot com dollar sign .
Give me the C . I . F . S . Service of ,
you know , this means I have like root
privileges or administrator , you know ,
high privilege . You guys don't
understand what I mean . It means I
have some pretty good credentials .
Pretty good access on that server . And
that S . P . N . Value is what I'm
requesting to the domain controller by
presenting my Tgt , which again I can
only obtain if I'm authenticated to the
domain . That's gonna be important
later on . Step five , the TGS
responds . So what's interesting is
that domain controller , it's going to
look up my account , it's going to look
up the service principal name and it's
going to return a service ticket for
server one . Now that service ticket is
sometimes referred to as the ticket
granting service . Um I think per
regulations or really Microsoft docs ,
its service ticket but again industry
kind of uses them interchangeably . So
for the purpose of this talk I'm just
going to call it the TGS . So we have
the T . G . T . T . G . S . And again
I'll go through these a little bit
later on to recap . So that domain
controller presents me Olaf
A T G . S . What's really
interesting and I put my most favorite
emoji there at the bottom . Um What's
really interesting about the TGS is
that it contains the
hash of the account we looked up . So
because we looked up server one C I . F .
S . I get the hash encrypted
within that service ticket . So similar
to the T . G . T . So not to recap
what's going on in L . C . S . We got
the passwords , we got the T . G . T .
And now we have the service ticket that
again contains you know user name . The
service I requested the server that I
requested and then the encrypted N . T .
L . M . Has cache of that service . So
that's where things get really
interesting because if I can get an
encrypted . Nt Lm hash then maybe
there's a way for me to crack that and
obviously there won't be a talk , there
wouldn't be a talk if there wasn't . So
we'll learn through that a little bit
later on . The final step is I present
that Tgs that service ticket to that
server again that TGS was provided to
me by R K D . C . The domain controller .
And that is known as the A . P
request And
Server one is simply going to decrypt
the service ticket . It's going to use
its own hash to actually decrypt the
service ticket which it should , you
know , if we go back a step to encrypt
it with its own hash . Yes , I know my
own hash . So that's how it's going to
decrypt dot t G s and then it's gonna
determine whether I have access to it
or not . So again to to kind of recap
here um you know , I know I'm going a
little bit back and forth but I really
just want to highlight a couple of
points here . We had passwords in
Elsa's , we had the TGT on Alsace . Now
we have the service ticket for that
server that we requested in Alsace .
And I'm going to request with my TGS ,
I'm going to present it to the final
destination which is server one on
service C I F S . Alright , so to kind
of recap here there there's a really
great blog post by picks is also known
as hacking do dot com
and uh he had some black post in french
but you can always get him in english
really , really good research . I
really like this diagram that he put .
So again we have K . D . C . Client and
service , you know hey I want to use a
service K . D . C . Is going to
validate and provided Tgt . Uh T . G .
T . Is going to ultimately come down to
A T . G . S . And then I'm going to
tell the service in this case it was
server one with C . I . F . S . I'm
gonna say hey I really want access to
uh you know your resources and then
that service is gonna say hey you're
you're good to go , I approve your this
message and then it's gonna tell you to
do your thing . Um So I really like
this diagram . I highly recommend you
guys check that one out . I just want
to recap some key turns since I'm
basically gonna throw them around the
rest of the talk . Uh So I just want
everyone to kind of be on the same page
here . So we have K . R . B . T . G .
T . The curb Tgt however you want to
call it . And this is the service
signing key for Kerberos . Alright ,
this is the key . The key . The NT LM
hash for this specific user is used
every time A . T . G . T . Is signed .
So the second term is the T . G .
T . Which is the ticket granting ticket .
That's that first piece that we get
once we authenticate in and then we
receive a TGS which is
again it's it's really called the
service ticket but people refer it as a
ticket granting service . I don't know ,
you guys can make that determination
for the purpose of this talk ? We're
gonna stick with TGS . You have the key
distribution center which is the K . D .
C A K A L . Domain controller . We have
the pack which we talked about the
privileged account certificate which is
inside the T . G . T . We have an A s
request authentication service
request to the domain controller , a S
response which gives you the T . G . T .
T . G . S request which contains the
the users T . G . T . And then after
all of that , we get the TGS response
which has a service ticket . It has the
hash , that's what we want , that's the
money maker right there . Alright ,
awesome , awesome . First tactics we're
going to talk about is a S rep roasting
uh really kind of a tongue twister for
me , but it's a really interesting
tactic , it's not so popular so that's
why I kind of put it towards the front
here . Um but really is
a mis configuration with an active
directory . I've never seen a valid use
for this . Um Again it's it's really
silly , it's not enabled by default but
nonetheless , I've seen it out in the
wild if you will . Uh and it's
basically an active directory property
that is enabled on a specific
account and it leads to
uh you know , ultimately me having that
account credential . So how does that
happen ? The first thing and really the
hardest part to get with this specific
tactic is getting the user name and
knowing that it has um
not request pre off set to enable .
Right ? So first you need a user name ,
you can get user names various
different ways , you know whether its
ascent , you know , L . Dap um linkedin ,
facebook et cetera . So once you have a
user name you're going to
recover the Kerberos a . S
response , which is going to be
encrypted by this users , you know , R .
C . Four H . Mac password . And then
you're just gonna crack , take that
hash and you're going to crack it
offline . It's pretty simple hash cat
has a mode for this . Uh So again , to
to kind of recap if you're in the
Bloodhound space which is an actor
director map a tool , there is already
a pre built query for you . This is
what that property looks like . They're
on the right . So if the user has do
not require Kerberos pre authentication
configured enabled . That means I can
perform this tactic and I do have a
demo at the end of this one . So not to
worry , I'll show it to you here . Life
The second tactic which is arguably one
of the most popular is Kerberos thing .
So Kerberos thing is when
an authenticated user , right ? So as
an authenticated user , we saw the
whole Kerberos exchange , you know , I
get a T G T . I have my encrypted
passwords on else as I have a T G T nl
sas . And then I request a TGS and
remember when I get that TGS back , I
get a service ticket
with part of that service ticket . Is
that service ? N . T . L . M .
Encrypted passwords . So again
it's it's pretty nice now just imagine
you as a user and I kind of put it
there at the bottom for each spN value
in the domain . I'm going to request
the TGS and then I'm going to take that
offline and I'm going to crack it . So
that is what Kerberos in does is when I
request the TgS not to use the actual
service or really to , you know ,
present that Tgs to the service and
allow it to , you know , give it the
opportunity to those resources or not .
It's really me requesting TgS is for
the sole purpose of cracking them off
line . A quick fun fact here
if you're using I . P . Address on
a Windows host , it will actually use N .
T . L . M versus Kerberos . Uh some
Opsec considerations with Kerberos
sting . If you request every single S .
P . N . In the domain , you're probably
gonna get caught . If you're a defender ,
you should understand what is a high
threshold for your organization , you
know , within a specified period of
time to determine whether you were
Kirby roasted or not . Uh for this it's
Windows event log 47 69 don't have that
on the slides but it's 46 6 47 69 .
And you can use that to determine
whether one specific user just
requested , let's say 200 you know , T .
G . S . S . Um in a three minute span
as an example , right , another kind
of offset consideration . You know ,
you should always use net bios and FP
DNS when performing these this tactic
on a Windows environment . Um Again
because if use I . P . Addresses , it's
going to stick out within logging and
then the last piece is decryption
downgrade so You can't actually
stop RC four service tickets . Um but
as an attacker you want to request our
C . Four if you're in a rush to crack
those tickets . Um You know , you have
a decision as an attacker whether to
request our C . Four service tickets or
a S tickets . A . S will blend in a
little bit nicer but it'll be longer
for you to crack those hashes . Alright ,
so just some opposite considerations
there . So here I have a
demo of a S . Rep roasting and Kerberos
and let me just make sure we're gonna
get some good quality video here .
All right , let's just make sure this
is actually gonna work . I just hit
play .
We are recording this . So I didn't
want to wait for that video to come up .
So I just pulled it up live . Uh So
here's just a quick demo . So again
we're gonna use Bloodhound to determine
which user is set to not require pre
authentication and then we're going to
validate that it's set to true . Now we
can use a tool like get ESPN users from
impac it to ultimately receive a T
G . T on behalf of that user . Uh So
there , you know , we pointed to the
domain controller , we don't provide
any password whatsoever and now we get
a T G T for that specific user
account simply because it has a pre off
enabled and then there's a mod on hash
cat for us to crack that hash
and now we have the credentials for
that specific account . So awesome . We
got our first set of credentials in
active directory , you know , we didn't
need a password to get it initially .
So now we're going to do Kerberos thing
which is again we're going to request a
TGS of a valid spN value within the
domain and for the sake of realism
we're actually going after a S P N
slash service account That has domain
admin credentials which I see all the
time . So again impact . It has a great
tool called get users spn . We're going
to specify a domain , we're gonna
specify the user , we just got Avenger
con 2020 and we're
going to request and we're gonna
point it to that specific Domain
controller . I'll give it the password
and awesome enough there is sbc
whatever and there is
the TgS for that
specific sPM value . So again
hashtag for the win we're going to run
mode 13,100 . And
we'll give it a password list and sure
enough we get the password of an
awesome service account . Again a
pretty realistic spectrum that I see
very frequently service account used as
a domain admin with a poor set of
credentials . Gotta be careful with
that . Uh No this recording
things . Great honestly had this been
live in interesting times . Nonetheless ,
next tactic of the day over past the
hash um don't know how it's spelled . I
saw it a couple of different ways you
know we won't get into it but it's a
pretty cool tactic um as a reminder ,
Kerberos is using the N . T . Lm hashes
as the keys for this entire exchange .
So if you have an N T .
LM hash of somebody else
technically hint you
could create a T G T as if you
were that user . Here's the other fun
fact . Even if NT LM authentication is
disabled everywhere , it doesn't matter
you can still create these T G T . S .
These ticket granting ticket on behalf
of a different user when you have their
hash or their credentials . Right ? So
again on our own kind of attacker
workstation we can in essence
um you know , requests in Tgt
on somebody else's behalf because if
you remember the first part of Kerberos
is me authenticating my passwords gets
into Elsa's awesome and then I request
the Tgt from the Domain controller by
sending the highest , you know ,
encryption method used that the D . C .
Will support . Again we skip all of
that at this point we have or not we
skip it . But instead of me sending
mine to request a Tgt , I'm simply
going to send somebody else's to
request that somebody else's Tgt . Uh
It's a pretty stealthy method basically
to request something on somebody else's
behalf . And I do have a demo for
that that will go over later bid on the
next topic . And the next tactic here
is abusing Kerberos delegation
and there's you know there's resource
base and constraint based . I'm sorry ,
constraint and resource based
constrained delegation but we won't
cover those two were simply going to
cover the most damaging . Um and really
want that . I look for all the time
which is unconstrained delegation and
there is the moneymaker property right
there trust this computer or user
for delegation to any service . So what
does this really do if you can see by
the awesome awesome screenshot there
again , picks is um
basically it's this functionality where
a user authenticates to a specific
server , let's say a web server and
they're going and that server is now
allowed to act on
behalf of that originating user . So
again user authenticates to an
unconstrained delegated server because
of that configuration . This magic
bullet right here . The web server can
now access other resources on behalf of
that user . So how do we
abuse this a couple of different ways
and a lot of great research has been
done but you know , by default your
domain controllers will have
unconstrained delegation that is by
default no issues there . Everyone else
should be highly audited . So
how do we abuse this ? You know , this
tactic . Um Ultimately all we really
need is access to a
server or an account with unconstrained
delegation , you know , compromise that
specific server or that specific .
Excuse me , that specific account . The
second thing we're going to have to
receive is as we're sitting on that
compromise , unconstrained delegated
server account as we're sitting on that
server . We're going to need some creds
to come in and play what I mean by that
is either an administrator account can
authenticate or a
domain controller . Computer account
can authenticate or you know , somebody
with some cred has to authenticate to
this server . So again , once they
authenticate we can act on behalf of
that user , that is very dangerous
because replace user right over here
with domain admin and we just
happened to be sitting here . Right .
So again , once
a domain admin authenticates to that
unconstrained delegated server that we
that we've compromised um that
TGS with that T G T is delivered to
the server and actually put into LCS .
Well , since we're sitting on it and
we've already compromised it . We can
extract that Tgt for that domain admin
and we can load that ticket and we can
use it to as an example dc sink the
domain . Alright . So ultimately if you
compromise a server that's marked with
a trade delegation , you can compromise
and reuse that TGT of any user that
connects to that server . There are
some caveats , there is a setting
called a counter sensitive and cannot
be delegated wink , wink , defenders
and there's also a protector users
group . Alright . Within Bloodhound you
can query it . Um and I didn't talk
about it too much here but I'm gonna
demo it , that's why I didn't talk
about it . Um But in essence instead of
waiting for a domain admin to
authenticate , there was a
vulnerability that was discovered a
couple a couple of months now , maybe a
year ago now called the printer bug by
lee lee and will from spectra apps
and it basically forces a server like a
domain controller to authenticate to us .
And I'm actually going to show that
here in a second . So really for
unconstrained delegation um what are we
abusing were abusing the fact that this
unconstrained delegated server can
present somebody else's T . G . T to
get a response . Alright . So because
we can act on behalf of those users
that land on that machine . If you land
on this machine having some credentials ,
I can abuse that to my advantage and I
can basically act on your behalf and
we're going to show you a quick demo of
this as I bring up let's
just take a look here . They're
with me just a second , awesome .
So here is over past the hash so again
I'm on workstation one um I don't have
any T G T s loaded and
I'm going to try to um
access the domain controller on the C .
I . F . S . Obviously I don't have the
right credentials for that . Um you
know , as you can tell that's me trying
to access the domain controller . I
don't have the right privileges to do
that . So what can we do ? Well
we Kerberos data , domain admin service
account . So what we can do is we can
request for a T G . T . As that user
because we have that N . T . Lm hash .
So there it is . And as soon as
we loaded into memory it's an L .
Sass and now I can try
to gather that share . Again it's gonna
request the TGS with that T G . T . Of
the service account and we're going to
get access to the server . Awesome ,
awesome stuff pretty difficult to
detect . And the next one here
which will be on constrained delegation
as I bring it up for the audience .
Alright , there we go . So again
there's my host name , I have to find
unconstrained delegated workstation so
workstation one and obviously by
default domain controller one have on
constrained delegation uh enabled .
We're going to attempt to dump the
K R B T G T account when I do
that , I get an error . Clearly I don't
have the right privileges to do such
thing . The next thing I'm going to do
is from my unconstrained delegated
server I'm going to monitor No , no
pause this real quickly . I'm going to
monitor here for event logs
46 64 which is what ruby is does is a
great tool , highly recommend you check
it out and every five seconds I'm going
to check to see if somebody
authenticates uh to my server . My
unconstrained delegated server And the
target that I'm actually filtering for
is DC- 01 computer object . Why am I
doing this again ? The printer
bug is a finding that leverage is
basically like printer notifications .
You make an RPc call to that server .
In this case I'm making it to the
domain controller here . Once you send
that Rpc call that domain controller ,
you know , it triggers the printer
notification which forces
authentication . That is co hearst
cohort . That's a that's a tough one .
English is my second language there .
So you coerced the server to
authenticate to the destination of
choice . And in this case , Domain
controller is going to send that
authentication to workstation one . We
are successful . We get a T G
T . For that . Domain controller
object . Now what can we do ? Well we
can use ruby asse again . Now that we
have that T G T . Because this is an
unconstrained delegated server . We're
going to use that T G T . Uh to
basically load it into memory ? And
bear with me here . There we go . We
load it into memory . We import it
awesome . And now when we try to
get the K R . B . T . G . T . Account
which will talk about in the next
couple of slides again , this is the
account and the nt LM hash that signs
everything in curb rose . So there's
the Nt LM hash very powerful account .
Very dangerous to have lingering around
and for sake of those that want to see
administrator boom . There it is
again , unconstrained delegation .
Pretty dangerous . Pretty crazy stuff
stuff . But we've covered a s rep
roasting curb roasting over past the
hash unconstrained delegation . Now
we're going to get into golden tickets
and silver tickets . So golden tickets ,
you just saw how we extracted
the K . R . B . T . G . T . Nt Lm
hash . Now within the
T . G . T . Remember there's that pack .
And within that pack we had some user
info , domain info etcetera . Um But
there was also this K . R . B . T . G .
T . Hash that was encrypted .
So a golden ticket , you know it's tim
median which is the creator of Kerberos
and as he put it it's really nothing
more than a special T . G . T . I think
that's a great quote because that's
what it comes down to . It's a special
T G . T . Why is it special where you
know ? Well it's special because it's
the Tgt that can do it all within a
domain , right ? Um and we won't get
too much into like , you know , domain
hopping and , you know , compromising a
domain and then compromising like a
forest , you know , there's there's a
lot involved , but ultimately , you
know , this K R B T G T N T Lm hash is
pretty difficult to get , you know ,
you're , you're ultimately a domain
administrator for you to get it . Um it
should be heavily monitored and what
you need to create a golden ticket is
just the M T LM hash for the K R B T G
T account , the account
name that you want to choose domain
name and then the city of that domain
name . So , again , one something I
I really wanted to kind of mention
regarding golden tickets is like ,
should you create them on a pen test or
red team engagement yes or no uh
personally I say no . And
uh the reason being is , if you
have a golden ticket , You know , some
of these tools that I highly recommend
you you do research on , they give
this , you know , these tickets a
lifetime of like 10 years , you know ,
many cats as an example . Um and it's
just , it's too powerful of a ticket
to really create . Um , I mean , and
the other piece is the only real way to
mitigate , you know , this threat
within your organization . If somebody
has a golden ticket or you believe
adversaries were in there and they were
domain admin , which means they could
have just created some golden tickets
for the themselves etcetera . Is to do
you know uh to reset curb rose twice .
Um by changing that care be uh T . G .
T . Account twice which again , I've
never done it . So you know , don't
quote me . But from what I've read and
from what I've heard , there are some
production considerations . Something
between the lines of like you can crash
A . D . And I don't know , it could get
messy . So again , that is the reason
why I don't recommend them . There's
really personally that I I don't think
there's there's a true need for it . Um
Now there are some considerations ,
like I mentioned the previous slide
with sid filtering which is a
configuration . Um And again it
basically with these golden tickets ,
you can actually compromise the child
domain and then jumped to like a forest
domain compromise . And it gets pretty
complex . I didn't want to go too much
into that . Too much into detail with
those due to the time constraints . So
I'm just going to brush them over and I
am going to show you that golden ticket
demo here again , golden ticket simply
just a super awesome Tgt to have uh
way , I don't know if it's more awesome
than having a T . G . T . With the user
name of Olaf . But nonetheless it's
pretty awesome to have silver ticket
is pretty interesting nickname I guess .
Um But you guys remember those Tgs
responses . Well basically it's you
forging service tickets
and this forgery of TgS . It's what's
called a server silver ticket . Um
What's interesting about a silver
silver ticket is remember that
authentication flow between Olaf and
the domain controller and Olaf again
and the domain controller . And then
ultimately that domain controller would
say like hey here's your T . Gs . Go
have fun . Well that doesn't need to
happen because we're forging those TGS
ourselves and you ask , you know what
do we need ? Well we need the
actual credentials for that service
account or that computer object running
that service . So in our example if we
have as an example the N . T . Lm .
Hash of the server , one computer
object . We can create a server a
silver ticket for that specific account .
So uh there are some you
know Considerations when you create
these silver tickets with computer
passwords . Um and that's really the
fact that every 30 days they rotate
randomly so you can't stop this but
obviously you're probably gonna you
know flag yourself for it . Um but it's
just it's interesting from that
perspective so for silver tickets and
this is from the Microsoft docks um you
have to specify what service you want
to basically gain access to . So here
are all the services um You can
research them as you will uh here are
here's a reference of those S . P . N .
S . That are pretty popular from a
offensive and defensive perspective
like W . M . I . A . Winner M you know ,
C . I . F . S . For like file shares ,
et cetera . Um And here's those S . P .
N . S . That are tied to it . So here's
just a quick reference from a mini cat
command reference perspective , huge
help from 80 security site there by
sean Metcalf . Some really great
research on this specific tactic and
let's just get to it . So I'm actually
not going to demo silver ticket for the
sake of time but I will demo
the awesome golden ticket tactic
here . So again um
workstation one . I'm gonna try to
access the d . c . no dice .
And one of the
things I'll need as I mentioned is the
domain sid best way to get that is who
am I slash user beware of command ,
like argument detections . And again ,
one of the cool things I mentioned
within the slide deck . If we go back
here uh there we go .
You're gonna need a domain name .
Alright , so what's cool about that is
you can actually pick any user . It
doesn't matter what you pick . Um like
this user doesn't exist but you can
still create the golden ticket .
Obviously this isn't the best in terms
of upset considerations But it's it's
kind of a nice to know . Um and this is
because you basically have like 20
minutes to play around before the
tickets are verified with the users .
So there's a domain said there
is the N . T . Lm hash of K R . B T G .
T . And uh we're going
to pass the ticket immediately with
this command
any moment now . There we go . Alright ,
so I run it and I successfully created
this T G . T . And I loaded it into
memory . So now when I try to access
the domain controller , I have a
valid T G . T . In order to do that .
Obviously the K R B T G . T account ,
like I mentioned , it is very dangerous .
Um you know , as far as , you know ,
this specific ticket , I mean you
really want to be careful . Like I
mentioned and I don't know if I can
zoom in , I cannot but take a look at
the lifetime of this ticket . So it was
created this state and
it's gonna expire
2030 . Oh yeah ,
so Yeah , renewal is the
eighth , it was created this day . I
mean 10 years , come on Amy Katz
um some great research , you know , a
great tool , very dangerous . You know ,
Benjamin Delpy 11 of the greatest in
this space . But again , it's very
dangerous to have this ticket floating
around . So again , that's why I always
recommend to kind of steer away from
them , especially in a production or
you know , real pen test or real red
team engagement Just wanted , you know ,
from a defensive consideration . I did
want to showcase the 46 , generated for
this event . Um again , this account
doesn't exist , but it was written to
my log . So if you're a defender , you
definitely want to make sure that um ,
you validate , you know , the account
names and how they tied to these
Kerberos requests . Um
again , you can build a golden ticket
with the user that doesn't exist . They
are a high risk item . Uh , definitely
be careful with them . Many cats is 10
years by default . There's another tool
called ticket . Er I'm not sure how
long that one takes . Um and yeah ,
golden tickets , awesome stuff ,
awesome stuff . Everyone to kind of
recap everything . So
Kerberos is everywhere , curb bo's
abuse is very popular as a great return
on investment from an attacker
perspective . You know , we talked
about a s rep roasting curb roasting
over past the hash on constrained
delegation , golden ticket , silver
ticket . Um , and really on the top
right here , you know , it's a recent
forensics report of , you know , the
ransomware pandemic , really really
kicking in . Um , and you know , just
think about if an attacker has domain
access to your environment . I mean ,
golden tickets are thing , persistence
is a thing . Um you know , Kerberos
thing could get , you know , plenty of
credentials and it's a very dangerous
tactic . You know , I want to thank you
for listening to my talk . Um I want to
thank the Avenger con 2020 personnel
for for this great conference and
allowing me the opportunity to speak ,
definitely want to give credit and
recognition to those amazing security
researchers that have done a lot of
this leg work . I highly recommend you
follow them . You'll get great value
added to uh , to your arsenal just by
reading some of their content there .
You guys can follow me on linkedin .
I'm in slacks . I'm in discords and
thank you guys so much for listening to
this talk .