Port 88 – Kerberos (Key Distribution Center)

Port 88 is the default port for Kerberos, the ticket-based authentication protocol that a Key Distribution Center (KDC) uses to prove who a user or service is without ever sending a password over the network. When a client signs into an Active Directory domain or a UNIX/MIT realm, it talks to the KDC on port 88 to get a Ticket-Granting Ticket (TGT), then trades that TGT for service tickets as it reaches each resource. Because every domain controller runs a KDC, an open port 88 is one of the most reliable ways to fingerprint a Windows domain controller on a network — and the front door to a whole family of credential attacks.

Why It’s Open

Kerberos is the default authentication mechanism in Active Directory, so every domain controller exposes port 88 — you can’t turn it off and still have a working domain. Outside Windows you’ll find it on MIT krb5 and Heimdal KDCs, FreeIPA servers, and anything that leans on a realm for single sign-on: NFSv4, Hadoop clusters, and LDAP-backed identity stacks. Appliances and Linux boxes that are joined to AD talk to 88 too. Where port 88 is open, the rest of the domain controller’s services are one scan away — check for LDAP on port 389, LDAPS on port 636, SMB on port 445, the Kerberos password service on port 464, and RPC on port 135.

Common Risks

• Kerberoasting. Any authenticated domain user can request a service ticket for an account that has a Service Principal Name (SPN). Part of that ticket is encrypted with the service account’s password hash, so the attacker cracks it offline — no lockout, no logs on the target service.
• AS-REP roasting. Accounts flagged “Do not require Kerberos pre-authentication” hand out an AS-REP encrypted with the user’s own key to anyone who asks. With just a username list and no credentials, an attacker collects those responses and cracks them offline.
• Username enumeration. The KDC answers differently for a valid principal (PREAUTH_REQUIRED) versus an unknown one (PRINCIPAL_UNKNOWN), so port 88 is a pre-auth oracle for validating usernames before any password is tried.
• Golden Ticket. With the krbtgt account’s hash, an attacker forges arbitrary TGTs for any user — including ones that don’t exist — giving domain-wide persistence that survives user password resets.
• Silver Ticket. With a single service account’s hash, an attacker forges service tickets for that one service, bypassing the KDC entirely and leaving almost no trace.
• Pass-the-Ticket. TGTs and service tickets can be lifted from a compromised host’s memory and replayed elsewhere, reusing a live session without ever knowing the password.
• Weak encryption. DES and RC4 (etype 23) tickets crack far faster than AES, so any realm that still accepts them makes every roasting attack cheaper.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Detect the service and grab the realm

nmap -sV -p 88 <target>

nmap labels the service kerberos-sec; seeing it open alongside 389 and 445 is a strong tell that the host is a domain controller.

Enumerate users with the Kerberos NSE script

nmap -p 88 --script krb5-enum-users --script-args krb5-enum-users.realm='DOMAIN.LOCAL',userdb=users.txt <target>

User enumeration and password spraying with Kerbrute

kerbrute userenum -d domain.local --dc <target> users.txt

kerbrute passwordspray -d domain.local --dc <target> domain_users.txt 'Spring2025!'

AS-REP roasting with Impacket

GetNPUsers.py domain.local/ -no-pass -usersfile users.txt -dc-ip <target> -format hashcat

Kerberoasting with Impacket (valid creds required)

GetUserSPNs.py domain.local/user:password -dc-ip <target> -request -outputfile kerberoast.hashes

Kerberoasting from Windows with Rubeus

Rubeus.exe kerberoast /outfile:kerberoast.hashes

Metasploit user enumeration

msfconsole -q
use auxiliary/gather/kerberos_enumusers
set RHOSTS <target>
set DOMAIN DOMAIN.LOCAL
set USER_FILE users.txt
run

Log every valid username, roastable account, and cracked hash you confirm so it lands in the final pentest report instead of a scratch file.

What to Look For

Known CVEs and Exploits

• CVE-2014-6324 — MS14-068, the Kerberos Checksum bug (CVSS 9.0). A forged PAC signature lets any authenticated domain user obtain domain administrator privileges from the KDC. Weaponized in the wild in 2014 and still a lab classic via PyKEK, Impacket’s goldenPac.py, and Metasploit’s ms14_068_kerberos_checksum.
• CVE-2021-42278 + CVE-2021-42287 — “noPac” / sAMAccountName spoofing (CVSS 8.8). Chained together, a low-privileged user renames a machine account to impersonate a domain controller and requests a TGT as domain admin. Public exploits: noPac.py and sam-the-admin.py.
• CVE-2022-33679 — Windows Kerberos elevation of privilege (CVSS 8.1). An unauthenticated attacker forces an RC4-MD4 session key on an AS-REP and brute-forces it to run code as the targeted user. Proof of concept published by Google Project Zero.
• CVE-2020-17049 — the “Bronze Bit” attack (CVSS 7.2). A security-feature bypass in Kerberos Constrained Delegation lets an attacker who controls a delegating service forge a forwardable ticket and impersonate users to a target service. Built into Impacket’s getST.py with -force-forwardable; also affects Samba.
• CVE-2024-37371 — MIT Kerberos 5 before 1.21.3 (CVSS 9.1). Malformed GSS message tokens with invalid length fields trigger invalid memory reads in the KDC — the UNIX-side reminder that port 88 is not only a Windows concern.

Mitigation

• Enforce AES and disable RC4/DES. Set accounts to AES-only encryption types so roasted tickets are far harder to crack, and retire legacy etypes across the realm.
• Require Kerberos pre-authentication on every account and audit for the “Do not require pre-auth” flag, which is what makes AS-REP roasting possible.
• Use long, managed passwords for service accounts. Group Managed Service Accounts (gMSA) rotate 120-character random passwords automatically, which defeats Kerberoasting in practice.
• Rotate the krbtgt password twice. Doing this periodically (and after any DC compromise) invalidates forged Golden Tickets; two rotations clear both the current and previous key.
• Patch domain controllers. Stay current — MS14-068, Bronze Bit (Nov 2020), noPac (Nov 2021), and CVE-2022-33679 (Oct 2022) are all KDC bugs that turn a foothold into domain admin.
• Monitor Kerberos event logs. Watch event IDs 4768, 4769, and 4771 for bursts of RC4 ticket requests, SPN sweeps, and pre-auth failures that signal roasting or spraying.
• Firewall port 88 to trusted networks. A domain controller should never be reachable from the internet; restrict 88 (and the rest of the DC cluster) to internal management ranges.

Real-World Example

In November 2014 Microsoft shipped an out-of-band patch for MS14-068 (CVE-2014-6324) after the bug was already being exploited in targeted intrusions. The flaw was almost absurdly powerful: the KDC failed to properly validate the signature on the Privilege Attribute Certificate (PAC) — the part of a Kerberos ticket that lists a user’s group memberships. With nothing more than one ordinary domain account and its password, an attacker could forge a PAC claiming membership in Domain Admins, present it to the KDC on port 88, and receive a service ticket that Windows honored as full domain administrator. Tools like PyKEK reduced the whole chain to a single command. It’s the cleanest illustration of why port 88 matters so much: the KDC is the machine that decides who everyone is, so a validation slip there isn’t one more vulnerability — it’s the keys to the entire domain.

FAQ

What port does Kerberos use?

Kerberos uses port 88 (TCP and UDP) for the KDC — the authentication service (AS) and ticket-granting service (TGS) exchanges. Two companion services sit nearby: port 464 for password changes (kpasswd) and port 749 for KDC administration (kadmin). The core ticketing that clients hit constantly is all on 88.

Is port 88 TCP or UDP?

Both. Kerberos historically preferred UDP 88 and falls back to TCP 88 when a ticket is too large for a UDP datagram — which is common in Active Directory, where the PAC pushes tickets past the UDP limit. Modern Windows increasingly uses TCP 88 by default, so firewall rules and scans should always cover both protocols.

What is port 88 used for?

Port 88 carries Kerberos authentication: a client requests a Ticket-Granting Ticket from the KDC, then exchanges it for service tickets to log into file shares, databases, web apps, and other domain resources — all without resending the password. It’s present on every Active Directory domain controller and on MIT/Heimdal KDCs in UNIX realms.

Can port 88 be exploited?

The port itself isn’t a vulnerability, but the KDC behind it exposes a lot of attack surface: Kerberoasting, AS-REP roasting, and username enumeration all work against a normally configured port 88, and unpatched domain controllers add privilege-escalation bugs like noPac and MS14-068 that lead straight to domain admin. Treat any reachable port 88 as a high-value target to enumerate and lock down.

How do I secure or close port 88?

You can’t close it on a domain controller — Active Directory needs Kerberos to function — so the goal is to reduce what an attacker can do with it: enforce AES encryption, require pre-authentication, give service accounts long gMSA passwords, rotate krbtgt, patch the DC, and firewall port 88 to trusted subnets. On non-DC hosts that don’t need to be a KDC, stop the Kerberos service and confirm the port is closed with a rescan.

TL;DR

• Service: Kerberos KDC (ticket-based authentication protocol)
• Default port: 88 TCP/UDP (companions: 464 kpasswd, 749 kadmin)
• Biggest risk: Kerberoasting, AS-REP roasting, and DC privilege-escalation bugs (noPac, MS14-068, Bronze Bit)
• Mitigation: enforce AES, require pre-auth, long gMSA passwords, rotate krbtgt, patch DCs, firewall port 88