Kerberos Port 88: Why Hackers Love This One Port (Explained Simply)

If you work in cybersecurity, you'll hear about "port 88" a lot when people talk about attacking Windows networks (Active Directory). This article explains why, using plain language and simple examples — no jargon overload.

First, What Is Kerberos?

Think of Kerberos like the ticket system at a concert venue.

1. You show your ID at the front gate (this is your password).
2. The gate staff gives you a wristband (this is called a TGT — Ticket Granting Ticket).
3. Later, when you want to enter a specific room (like the VIP lounge), you show your wristband to the room's guard, and they give you a room ticket (this is called a TGS — a Service Ticket).
4. The room guard doesn't check your ID again — they just trust the ticket, because it was signed by the venue.

Port 88 is the "front gate" — it's the network door where all of this ticket-issuing happens on a Windows domain.

This system is smart because you only show your ID once, and then tickets handle everything else. But like any ticket system, if someone can grab a ticket and take it somewhere private to study it, that becomes a problem.

Why Do Attacks Happen Here?

Reason 1: Anyone can ask for a room ticket, even for a room they don't plan to enter.

At this "venue," any guest can walk up and say "give me a ticket for the VIP lounge" — the gate doesn't ask "why do you want it?" It just hands over a ticket that's sealed with the VIP lounge's own key (a password-based key).

The attacker doesn't even need to go to the VIP lounge. They just take that sealed ticket home and try thousands of guesses to figure out what key sealed it. If the VIP lounge used a weak, simple key (a weak password), the attacker cracks it — often within hours.

This is called Kerberoasting.

Simple example:

impacket-GetUserSPNs domain.local/username:password -dc-ip 192.168.1.10 -request

impacket-GetUserSPNs domain.local/username:password -dc-ip 192.168.1.10 -request

This is like saying: "Hey gate, give me tickets for every VIP room in the building." The attacker then takes all those tickets home to try to crack them.

Reason 2: Some guests don't even need to show ID.

Normally, you must show ID before getting your wristband. But some accounts are set up (often by mistake) to skip the ID check. For those accounts, anyone can request a wristband without proving who they are — and that wristband can also be taken home and cracked.

This is called AS-REP Roasting.

Simple example:

impacket-GetNPUsers domain.local/ -usersfile users.txt -no-pass -dc-ip 192.168.1.10

impacket-GetNPUsers domain.local/ -usersfile users.txt -no-pass -dc-ip 192.168.1.10

This is like saying: "Give me a wristband for this list of guests — I won't show any ID." If the gate allows it (because ID-checking was turned off for that guest), the attacker gets a wristband to crack at home.

Why This Actually Works

• The cracking happens offline, away from the "venue." There's no alarm, no lockout, no one watching. The attacker can guess passwords all night on their own laptop.
• Service accounts (used by apps, not humans) often have old, weak, or never-changed passwords — because IT teams are scared to change them in case it breaks something.
• The request itself looks completely normal. Asking for a ticket is a totally normal thing to do on the network, so it doesn't look suspicious by itself.

What Happens After the Attacker Cracks a Password?

Once they crack one weak service account password, they can log in as that account and look for more ways to move deeper into the network. Some follow-up steps:

See who else is on the guest list:

impacket-GetADUsers domain.local/username:password -dc-ip 192.168.1.10

impacket-GetADUsers domain.local/username:password -dc-ip 192.168.1.10

Simple meaning: "Show me everyone's name and how old their password is."

Look for VIP guests who can borrow other people's wristbands:

impacket-findDelegation domain.local/username:password -dc-ip 192.168.1.10

impacket-findDelegation domain.local/username:password -dc-ip 192.168.1.10

Simple meaning: "Find any staff member who's allowed to act on behalf of other guests." (This is a special, risky permission called delegation.)

Steal the master ticket-printer's key:

impacket-secretsdump domain.local/username:password@192.168.1.20

impacket-secretsdump domain.local/username:password@192.168.1.20

Simple meaning: "Dump the passwords stored on this machine." If the attacker gets the domain's master key (called the krbtgt key), it's game over — they can make their own wristbands for anyone.

Print a fake "all-access" wristband:

impacket-ticketer -nthash <krbtgt_hash> -domain-sid <sid> -domain domain.local administrator

impacket-ticketer -nthash <krbtgt_hash> -domain-sid <sid> -domain domain.local administrator

Simple meaning: "Using the stolen master key, make me a wristband that says I'm the Administrator." This fake wristband is called a Golden Ticket, and it works even if the real Administrator changes their password.

Key Takeaways

• Port 88 is where Windows hands out "tickets" for network access.
• Anyone can ask for a ticket — the system trusts the ticket's seal, not the person asking.
• If the seal (the password) is weak, the attacker cracks it later, offline, with no alarms.
• One weak service account password can snowball into full control of the entire network.
• These aren't "hacking the software" — they're abusing normal features that were left unguarded.

How to Protect Against It

Problem Simple Fix Weak service account passwords Use long, random, auto-changing passwords (called gMSAs) Accounts that skip ID checks Turn that setting back on unless there's a real reason not to No one watching for suspicious ticket requests Set up alerts for one account asking for lots of tickets at once Too many staff with "borrow wristband" powers Regularly review and remove delegation permissions that aren't needed Attackers going unnoticed for months Set up decoy accounts ("honeypots") — if anyone touches them, it's an instant red flag

The Simple Takeaway

Kerberos isn't broken — it's just a ticket system, and ticket systems only work if every ticket's "seal" (the password) is strong. Most of these attacks exist because somewhere, some service account has a weak or forgotten password. Fix that one thing everywhere in your network, and you remove most of the attack surface.

This article is for security professionals testing systems they're authorized to test, or defenders securing their own networks.