Skip to main content

Wolfcore Cyber Security

Port 88 (Kerberos): what it is, how it is attacked and how to secure it

Written by Ruben Selby, Founder and Lead Security Consultant, Wolfcore. Last reviewed 11 November 2026.

Part of the Wolfcore Resources library: Ports, protocols and services.

In one sentence: Port 88 is where a Windows domain controller hands out the digital passes that let staff sign in to file shares, databases and servers, so it should be reachable from your own network and not from the internet.

What runs on this port

Port 88 carries Kerberos, the sign-in protocol used by Active Directory. A domain controller runs the Key Distribution Center (KDC), which issues tickets. Microsoft’s firewall checklist for Kerberos lists port 88 over both TCP and UDP. The standard (RFC 4120) says, in Microsoft’s words, that a KDC must accept TCP requests and should listen for them on port 88. Large tickets, which grow with group membership, can overflow a UDP packet, so TCP matters.

Related ports on the same checklist include 464 for Kerberos password changes, 389 and 636 for LDAP, 445 for SMB and 135 for RPC. The protocol itself, step by step, is explained in kerberos-authentication. This page is about the port: who can reach it and what that means.

Why attackers look for it

An answer on port 88 tells an attacker they have found a domain controller, the machine that holds every account in a Windows network. Inside a network, an attacker who already has one ordinary account can ask the KDC for tickets. From the internet, a reachable domain controller should not exist at all.

How it gets attacked

Who it affects and how badly

  • Sole trader to 10 staff: most have no domain controller, so port 88 is not in play. Microsoft 365-only firms use cloud sign-in instead.
  • 10 to 50 staff (accountancy, legal, construction offices with an on-premises server): one old service account password can be cracked and become the key to the server. Downtime and a rebuild are the realistic worst case.
  • 50 to 250 and 250 plus, including schools, councils, manufacturers and care providers: a stolen domain admin ends in network-wide ransomware or data theft. Regulated firms add reporting duties and client losses.

Worked example for a small business (illustration only)

An invented example, not a real client. A 30-person accountancy runs an on-premises server with a service account for its practice software. The account was created years ago with a short password that never expires. A staff laptop is infected after a phishing click. The attacker requests a service ticket for that account, cracks it offline and signs in to the server as the service account, which is also a local administrator. The cost is a week of rebuilding, locked client files and an ICO notification. The fix is a long random password (or a managed service account), AES encryption and alerting on ticket requests.

How to check whether yours is exposed

  1. Check your internet firewall: port 88 (TCP and UDP) must not be forwarded to any server.
  2. List your domain controllers and confirm which networks can reach 88 on them.
  3. In Event Viewer on a domain controller, look at Security events 4768 and 4769 and check the encryption type. Microsoft documents how RC4 shows up in these events.
  4. Check the System log for the KDC audit events 201 to 209 that Microsoft added in January 2026.

What we check on a test

  • Whether port 88 or any other domain controller service answers from the internet.
  • Whether a standard user account can request service tickets and what encryption comes back.
  • Which service accounts exist, how old their passwords are and how much privilege they hold.
  • Whether RC4 is still allowed and whether KDC audit events show legacy dependencies.
  • Whether domain controllers are patched and whether admin accounts are separate from daily accounts.

The UK angle

The NCSC’s lateral movement guidance says that after an initial foothold attackers try to compromise more hosts and escalate privileges, with a domain controller as a typical target. It recommends separate admin accounts, least privilege, patching, host firewalls that block inbound connections by default, and network monitoring that treats domain controllers as high value assets. These map onto Cyber Essentials themes of firewalls, secure configuration, update management and user access control.

How to secure it

  1. Never expose port 88 or any domain controller port to the internet.
  2. Set service account passwords long and random, or use group managed service accounts. MITRE suggests 25 or more characters.
  3. Enable AES and phase out RC4 with the group policy “Network security: Configure encryption types allowed for Kerberos”.
  4. Make sure every domain controller has the 2026 updates for CVE-2026-20833 and that enforcement is on, after checking the KDC audit events for devices that still need RC4.
  5. Patch domain controllers first each month.
  6. Give service accounts the least privilege they need, never Domain Admin.
  7. Log and alert on bursts of ticket requests and RC4 tickets.
  8. Segment the network so only the machines that need a domain controller can reach 88.

Frequently asked questions

Does port 88 need to be open? Inside your network, yes, wherever Windows computers sign in to a domain. To the internet, no.

Is port 88 TCP or UDP? Both. Microsoft’s checklist lists 88 for TCP and UDP, and large tickets use TCP.

What attack is linked to port 88? Kerberoasting, where service tickets are cracked offline to recover a service account password.

Related terms

kerberos-authentication, ntlm-authentication, how-privilege-escalation-works, port-636-ldaps, port-445-smb, port-135-msrpc

How Wolfcore helps

A Wolfcore penetration test finds this the way an attacker would, by hand, not with a scanner. Start with the free web vulnerability scan.