This is Cerebrus, the 3 headed fiery monster of a Dog, that guards the gates to Hades ‘the underworld’ , as says the Greek Mythology.
Kerberos — the authentication protocol developed by MIT, derives its name from Cerebrus;
- and is based on the concept of 3 entities playing their part in the authentication workflow to secure an identity, much alike the role played by 3 cute looking heads in the above figure (Now that’s some impressive analogy !!)
Microsoft took this open-source protocol, and added quite a few extensions/enhancements to bake it as the primary authentication protocol in Windows.
These extensions are termed MS-KILE , and are specified in RFC4120.
This was implemented then as a primary authentication mechanism used to manage access resources in a Windows Active Directory environment.
A few references talking more about MS-KILE implementation are included at the bottom in credits section (1).
Allright, so before we go any further, A brief disclosure to state the objective and expected takeaways from this writeup.
We all know there is plenty of really good content available online explaining Kerberos authentication process in all its verbosity and possible detail, as well as detailed walkthroughs available of Kerberos based AD attacks.
Now, as a blue teamer in a SOC type setting,
- you often do not have admin level access on the assets in the enterprise to be able to dump out lsass.exe process (or other processes) or run klist remotely and investigate the tickets,
- nor is access readily available to Domain Controllers or tools like adsiedit/adexplorer to check the object attributes on the fly.
But what you do have access to is a SIEM (Splunk/Exabeam, etc) which ingests the security/System/EDR, etc (subject to configuration) logs from these assets,
and hence is a very good tool to co-relate the events from multiple assets and piece together Kerberos authentication workflow in sequence from these multiple assets.
So, I will attempt to present this more from a Blue Team standpoint
- And touch upon the basics of Kerberos workflow,
- Followed by representing that through events captured in a SIEM.
Primarily, Microsoft Active directory provides functionality of managing access for/to the resources that are members of its authentication realm (called domain)
And these resources are entities represented as objects within an Active directory domain — like user objects, computer objects, printer objects, file share objects, etc.
This logical structure then forms the basis of 2 step process that occurs when accessing any object in the domain
- First part of it is Authentication , which is essentially — Are you who you claim to be ?
— This is where Kerberos as the primary authentication protocol (since windows 2000) slots in. Others are NTLM, CHAP, etc - Following a successful Authentication is Authorization — do you have the required privilege to access the resource you are asking for ?
— This piece is handled by the accessed resource or the machine hosting it, and is based on Access Control Lists (ACL’s), group memberships, etc.
Kerberos, as the Primary Auth protocol, lies at the heart of Active directory.
Revisiting the analogy of 3 cute heads at the start of the article, the 3 actors that play their part in Kerberos protocol are
Kerberos authentication workflow
- This workflow and the protocol is one of the really well documented pieces of technology, and you all might already have a very good idea of how it works.
- So I’ll try not to go over the theoretical bits, but would walk this authentication process through a practical scenario,
and include references for further reads wherever required.
The Kerberos protocol centers around tickets which are issued by the trusted 3rd party — the Domain Controller , which actually can be any domain controller (comprising of AS & TGS).
- What these tickets are,
- What data they contain, how are they encrypted,
- and how does one ticket lead to another
is what this workflow is, and all nearly all AD attacks are based upon.
I’ve below listed the environment that will be used to demonstrate the stages in Kerberos authentication workflow
Through this activity
- Client Rootuser1 enters username password at logon to Client workstation Win10Client01.ForestRoot.net
- This authenticates RootUser1 into Domain ForestRoot.net , by the Domain Controller (Win2019DC1 Or Win2016DC1)
- It next attempts to access File Share “//Win2019Member01/TestShare” which resides on a Member Server Win2019Member1.ForestRoot.net
- This triggers required workflow to authenticate RootUser1 to Win2019Member1
- Post which, RootUser01 does authenticate successfully to Win2010Member1, authorizes as well successfully and is able to access the share
Here’s a diagrammatic representation for this workflow, With annotations/remarks added to reflect this scenario.
Referred off: http://www.labofapenetrationtester.com/2017/08/week-of-evading-microsoft-ata-day4.html
How often do these requests occur, the next diagram below
Based on my understanding of how Kerberos works, I’ve tabulated the workflow as below.
Some terms from the figure above
What is krbtgt? : https://adsecurity.org/?p=483
What is SPN ? : https://adsecurity.org/?page_id=183
And now the jewel : Log Telemetry
Here are the Events generated for this workflow, and the key fields within those events
Let’s take a look at 2 Sample Events
4768 (For TGT Generation)
4769 (For TGS Generation)
This is 4768
https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768
Here is the Event 4768 logged when TGT was issued to Client RootUser1, when authenticated to Domain ForestRoot.net
And the actual TGT ticket , as cached by the Client Win10Client01.
- we can relate the ticket to data attributes in fields within the log.
klist tgt output
https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768 (TGT Fields)
b) And here is the Event 4769, logged when TGS/Service Ticket was issued to RootUser1 for authenticating to Win2019Member1@Forestroot.net
- Note the ‘Service Name’ field : this is the Account bound to the Target SPN (krbtgt for TGT, and Win2019Member01$ for TGS in this case)
And below is 4769 (TGS)
https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4769
And the TGS/Service tickets, as cached on the Client workstation Win10Client01.
- 1st in the list is the TGS for Win2019Member1.ForestRoot.net, required to authenticate to this AP (App Server)
and access the share //Win2019Member1/TestShare
- 2nd and 3rd tickets are for authenticated LDAP connections (which is also a service) to the 2 KDC’s Win2019DC1.ForestRoot.net & Win2016DC1.ForestRoot.net
A quick Snippet :
Q: Where does this Kerberos Policy for ticket expiry and renewal duration come from ?
A: It comes from Default Domain Policy — Computer Configuration — Policies — Windows Settings — Security Settings — Kerberos Policy
Finally, how does it all stitch together in a SIEM
- Sorted in chronological order, most recent events at the bottom
- and the activity related to event/group of events is tagged as well
Legend
Hope this was helpful understanding the Kerberos workflow.
Thanks for reading through. Please do post any feedback/suggestions you might have.
Next, I would try to use the same approach and capture a few AD attacks (Kerberoasting, AS-REP Roasting, Delegation, Golden/Silver Tickets) within SIEM.
Until then, Cheers :)
Credits :
(1)[MS-KILE]: Kerberos Protocol Extensions
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/2a32282e-dd48-4ad9-a542-609804b02cc9
[MS-KILE] Glossary
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/e720dd17-0703-4ce4-ab66-7ccf2d72c579
(2) Wanting to go deeper into Kerberos
This article here gives a very good graphical representation of the authentication process.
https://posts.specterops.io/kerberosity-killed-the-domain-an-offensive-kerberos-overview-eb04b1402c61
For those who would fancy a threadbare explanation, I would want to recommend this whitepaper. If it interests you — this is the best I’ve read so far.
https://support.sas.com/resources/papers/proceedings17/SAS0623-2017.pdf
