Get in touch with us
Mailing List - Sign in and check “Add to Mailing List”
Website - csg.utdallas.edu
Slack - #csg on ecsutd.slack.com
Email - email@example.com
Lab Hangouts - ECSS 4.619 - Every Thursday at 4 PM
State Farm CTF
Domain Hacking & Pivoting
1. Domain Concept Refresher
a. What is a domain?
b. Single sign on
3. Attacking Authentication: Pass The
a. Solid plan A
b. Solid plan B thru ...
c. Harden, harden, harden
5. Future Technologies
a. Windows ATP
b. Credential Guard
What is a domain?
● A bunch of computers connected together in a hierarchical structure
○ Domain Controller (DC) - Tells people the rules and handles authentication
○ Organizational Units (OUs) - Logically group things together
○ Group Policy Objects (GPOs) - Apply policies to things on the domain
○ Other stuff
■ Users that need access to network resources
■ Servers / workstations / everything else that makes up those network
What is a domain?
What is a domain?
● Analogy: an army
○ Network is the military base.
○ Domain is all the stuff on the base.
■ Troops, supplies, vehicles, etc.
○ DC is the top dog giving orders.
○ OUs to define different branches.
○ GPOs are the rules / orders to give everyone
Why do we care?
● Why do I want my company to have a domain?
○ For a similar reason to why you want your military to have
an organized army and not just a bunch of dudes with rifles
○ Organization is good
○ Not all users are created equal
● So why do I, as an attacker, want to get on someone’s domain?
○ Go back to that analogy.
■ You become trusted.
■ You wanna be the top dog.
● Important concept with big implications on domain security!
● Make a user give credentials any time they access any network resource?
○ They don’t like that.
○ Also it’s slow; hinders productivity
● Solution: single sign-on! Only sign on once, and you can use any of the things
that you’re authorized to use without signing on again, yay!
○ User logs on with credentials. Credentials get hashed.
○ Hash gets stored somewhere in memory on their computer.
○ Authenticate with the hash of the credentials rather than the credentials themselves, so
you don’t have to store cleartext credentials or send them over the wire.
○ The result? Hashes get left around… usually.
● User enters credentials. They get hashed.
● Give hash to DC. DC authenticates user.
● User logs on. Hash gets stored on their computer.
● When they try to use network resources, they give that hash to the DC,
DC makes sure they’re allowed to use that resource, grants access if so.
● Another analogy
○ There’s a toybox of network resources
○ DC is the toybox’s bouncer.
○ User gives DC their hash, they make sure user is on the list, then
lets him play with that toy
● A bit more complicated than NTLM.
● All about the tickets.
○ Wanna talk to someone? Well, you need a valid Kerberos ticket.
● Where do I get these tickets?
● Kerberos server
○ Has two parts: Authentication Server (AS) and Ticket Granting Server
○ Two types of tickets
■ Ticket Granting Ticket (TGT) - Ticket that lets you get Service
■ Service Ticket (ST) - Ticket that lets you use particular services
● User uses credentials at AS to get TGT
● User takes TGT to TGS to get TSs
● TSs let you use services
● Tickets are stored on user’s computer, but they expire after a
Source: Oracle Help Center
Why Kerberos is better than NTLM
● Supports stronger encryption
● Less load on DC (infrequently
authenticate with TGT)
● Actively developed
● Critical data (tickets) are (generally)
valid for a few days
● Supports both user-to-server
authentication and server-to-user
● Is open source
● Uses weaker encryption algorithms
● More load on DC (authenticate with
DC every time)
● No more development - MS is moving
● Critical data (NTLM hashes) are valid
until user changes password
● Only user-to-server authentication
● Is filthy proprietary software
● Logging into a computer on the domain stores your NTLM hash
on that computer (most of the time*)
● If that computer gets compromised, HackerMan can grab any
stored hashes, which can be used to authenticate against other
parts of the domain as previously-logged-in users
*”Network” login sessions usually don’t leave a hash (RDP being a notable exception).
Every other type of session does. There are nine session types.
● If HackerMan happens to find a domain admin hash -> GG
● If not, use the best credentials you can, authenticate against
other machines on the domain, compromise and grab even more
○ Gradually escalate privileges, pivoting around the domain
on to different machines as different users
It’s also worth mentioning that older versions of NTLM use very weak encryption that is
trivial to crack
Kerberos Saves The Day?
● Gee, NTLM sure sounds bad. It’s a good thing modern Windows OSes
use Kerberos by default! That means I’m safe from Pass The Hash, right?
● In the majority of networks, NTLM functions alongside Kerberos, for the
sake of backward compatibility with a bunch of stuff.
● You can specifically disable all NTLM. This takes some kerjiggering, and
can restrict some functionality, depending on what services you need on
● But if I do that, then am I safe?
Kerberos Saves The Day?
● Still, no.
● Tickets get stored locally, just like an NTLM hash.
● Kerberos is NOT meant to protect against Pass the Hash
● Only slight protection from PtH: tickets are not valid for as long
as NTLM hashes are
● But still, lift someone’s TGT and you can request any services
they have access to.
● “Pass the Ticket” attack. Basically a rebranded Pass the Hash.
● Open source tools already exist to do this.
Solid Plan A
● Remember all the other security talks we’ve given this semester
to keep attackers off your network
○ Keep patches up to date
○ Double check your configurations
○ Incorporate employees into your security team to defend
against social engineering attacks
● But that isn’t enough.
Solid Plans B And Beyond
● Defenders should assume an attacker should get on their network
● Strict focus on boundary defenses has failed corporations repeatedly
● Harden your domain
○ Don’t leave admin hashes laying around
■ Make them manage computers via network logins, when possible
○ Fine tune privileges
■ Be granular when deciding who should be able to do what
■ Does the IT intern really need omega superadmin privileges?
○ Isolate critical components
■ Does omega superadmin really need an email address?