the path from ordinary domain user to domain admin

one weak password, one bad night for your domain

there's a reel going around showing "ordinary user to domain admin" like it's a magic trick. it's not magic, it's just active directory doing exactly what it was configured to do. the tool in the video is bloodhound, and the technique is kerberoasting. if you run windows domains, you need to understand this chain not to run it, but to break it before someone else does.

what bloodhound actually maps

bloodhound isn't malware. it's a graph tool that ingests normal active directory data, group memberships, session info, acl permissions, and draws the shortest path from "any authenticated user" to "domain admin." it exists because most orgs have no idea how tangled their permissions actually are. a helpdesk account nested three groups deep might have local admin on a box where a domain admin is logged in. bloodhound just draws that line for anyone who asks.

as a defender, you should be the one running it against your own environment first. if an attacker's free mapping tool finds a five-hop path to full compromise, you want to find it before they do.

# defensive use: run bloodhound's data collector (sharphound) yourself
# against your own domain, in a test or authorized admin context,
# then review the graph for short paths to Domain Admins / Enterprise Admins

why kerberoasting works

kerberos lets any authenticated user request a service ticket for any service account that has a registered service principal name (spn). that ticket is encrypted with a hash derived from the service account's password. the user doesn't need special rights to ask for the ticket, they just need to be logged in. once they have it, they take it offline and try to crack the password with no lockout, no alerts, no rate limiting from the domain controller's perspective.

the whole attack lives or dies on one thing: how strong is that service account's password. a 25-character random string is basically uncrackable in any realistic timeframe. a service account password set in 2014 that's some variation of the app name plus a year is cracked in minutes.

find your own roastable accounts

you can audit this from the defender's seat with tools you already have access to. the goal is to find every account with an spn and check password age, password strength policy, and privilege level.

# powershell, run with an account authorized to query AD
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName, PasswordLastSet |
  Select-Object Name, PasswordLastSet, ServicePrincipalName

anything with an spn, a stale password, and membership in a privileged group is your priority list. those are the accounts an attacker would target first, so target them first yourself.

breaking the chain, not just one link

the video's own caption gets it right: strong service account passwords plus tiering break this. here's what that actually looks like in practice.

service account passwords: use long, random, machine-generated passwords for every service account, minimum 25+ characters. better yet, migrate to group managed service accounts (gmsa), which rotate automatically and never have a human-memorable password to crack in the first place.

tiering: domain admins should never log into regular workstations or servers that lower-tier users also use. that "hop to a privileged host" step in the attack only works because someone violated tier separation. enforce it with dedicated admin workstations and restricted logon rights.

kerberos encryption: disable rc4 support where you can and require aes for ticket encryption. rc4-encrypted tickets are dramatically faster to crack offline.

monitoring: a spike in ticket-granting-service requests for service accounts, especially many spns requested by one user in a short window, is a strong kerberoasting signal. get that alert built in your siem now, not after an incident.

the takeaway

this attack chain isn't clever, it's patient. it relies on defenders never auditing their own permission graph and never rotating service account passwords. run bloodhound against your own domain. find your roastable accounts before someone else does. enforce tiering so one compromised laptop doesn't become a domain-wide event. the path from user to domain admin only exists if you leave it lying around.