What are the risks of exposing the Windows Kerberos proxy to the Internet ?

Question

What are the risks of exposing the Windows Kerberos proxy to the Internet ?

Serge Caron 45

The basic configuraton: firewall that filters everything out EXCEPT traffic on port 443.

The firewall redirects traffic to Windows Server 2025, port 443.

I am striclty interested in the KDC Proxy and the IIS configuration is reduced to the minimum.

IIS "web.config" is:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <httpProtocol>
            <customHeaders>
                <add name="X-Content-Type-Options" value="nosniff" />
                <add name="Strict-Transport-Security" value="max-age=15552001;includeSubDomains;preload" />
                <add name="X-Frame-Options" value="SAMEORIGIN" />
                <add name="X-XSS-Protection" value="1;mode=block" />
                <add name="Content-Security-Policy" value="upgrade-insecure-requests" />
                <add name="Permissions-Policy" value="geolocation=(self)" />
                <add name="Referrer-Policy" value="same-origin" />
            </customHeaders>
        </httpProtocol>
    </system.webServer>
</configuration>

IIS "iisstart.htm" is:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <meta charset="UTF-8">
    <title>Title</title>
    <style type="text/css">
        .wide-image {
            background: url("Your_Favorite_Image.jpg") no-repeat;
            background-size: cover;
        }
        #clickable-div /*Cover the entire image*/
        {
            position:fixed;
            padding:0;
            margin:0;
            top:0;
            left:0;
            width: 100%;
            height: 100%;
        }
    </style>
</head>
<body class="wide-image">
    <div id="clickable-div" onclick="location.href = 'https://www.google.com/maps';">
    </div>
</body>
</html>

This proxy may or may not be a domain controller.

Amongst other things, I understand that failed connections are downgraded to NTLM and some, if not all, users should be members of the Protected Users group.

Is there a way to assess the risk of exposing this KDC proxy ?

Regards,

Allan Solomon Mejia 2,595 Reputation points

2026-07-23T20:01:07.8866667+00:00

Hi Serge,

Exposing a Kerberos KDC Proxy (KKDCP) to the Internet is a supported deployment model, but like any Internet-facing service, its security depends on proper hardening rather than simply opening TCP 443.

A few considerations:

TLS should be enforced (TLS 1.2/1.3), with a trusted certificate and strong cipher suites.

The server should be fully patched and run only the required IIS/KDC Proxy components. Avoid hosting unnecessary applications on the same server.

If possible, deploy the KDC Proxy on a member server rather than directly on a domain controller to reduce the attack surface.

Restrict access with a firewall, enable logging, and monitor for abnormal authentication patterns.

If you're concerned about NTLM fallback, consider enforcing Kerberos where possible, disabling NTLM where supported, and using features such as Protected Users, Credential Guard, and the latest Kerberos hardening guidance.

The primary risks are similar to any Internet-facing authentication endpoint: denial-of-service attempts, exploitation of unpatched vulnerabilities, credential attacks, and misconfiguration. However, exposing TCP 443 alone does not expose the domain controller directly or the Kerberos service itself—the KDC Proxy simply relays Kerberos messages over HTTPS.

Microsoft also recommends performing regular security assessments using tools such as Microsoft Defender for Identity, Microsoft Defender for Endpoint, and reviewing IIS and Security event logs for anomalous authentication activity.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.
Serge Caron 45 Reputation points

2026-08-04T18:48:35.8166667+00:00
Hello Allan,

Thank you for your answer.

As specified in the question, the firewall filters out everything except port 443. You arre correct: I should have mentionned that only TLS 1.2/1.3 are enabled and that only AES 128 and 256 are supported.

Further, I you replace in web config the line

<add name="Content-Security-Policy" value="upgrade-insecure-requests" />

by

<add name="Content-Security-Policy" value="upgrade-insecure-requests; base-uri 'self'; img-src 'self'; object-src 'self'; script-src 'self';" />

then IIS will not interact with anything that access the server using a valid HTTPS request.

The question relates only to the Microsoft applications (https://.../Rpc and https://.../RpcWithCert) that are provided in the "Default Web Site".

Consider that the KDC Proxy is a member server enforcing Kerberos, which is the configuration that we are using.

It is unclear if the Microsoft applications can be abused from the Internet side of this server.

Regards,
Allan Solomon Mejia 2,595 Reputation points

2026-08-04T19:15:17.1+00:00
Hi @Serge Caron ,

Thank you for the additional details and for clarifying your configuration.

Given that:

Only HTTPS (TCP 443) is exposed,

TLS 1.2/1.3 and AES-128/256 are enforced,

The server is a member server hosting the KDC Proxy (KPSSVC) rather than a domain controller,

your attack surface is significantly reduced compared to exposing traditional Kerberos ports directly.

Regarding your question about the Microsoft-provided endpoints (/rpc and /RpcWithCert) hosted under the Default Web Site, these are designed to act as Kerberos over HTTPS (KKDCP) proxy endpoints. They relay Kerberos messages between the client and a domain controller over HTTPS. They do not authenticate users themselves or expose LDAP, SMB, or the Kerberos service directly on the Internet.

As with any Internet-facing HTTPS endpoint, there is still a residual risk of:

Denial-of-service attempts.

Exploitation of future vulnerabilities in IIS, HTTP.sys, or the KDC Proxy service if systems are not kept up to date.

Misconfiguration of IIS or authentication settings.

However, when deployed following Microsoft's guidance (TLS-only, current security updates, least privilege, strong authentication, and continuous monitoring), the KDC Proxy role is intended to be safely exposed to the Internet for remote Kerberos authentication scenarios.

One additional recommendation would be to enable logging and monitoring for the /rpc endpoints and review IIS logs together with Windows Security and KDC Proxy operational logs. This can help identify abnormal authentication patterns or reconnaissance activity. If you're using Microsoft Defender for Identity or Microsoft Defender XDR, those products can also provide additional visibility into suspicious Kerberos-related activity.

Thanks again for sharing your findings regarding the Content-Security-Policy changes. They're useful context for others following the thread.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.
Serge Caron 45 Reputation points

2026-08-04T19:52:48.8366667+00:00
Hello Allan,

Thank you for your answer.

As specified in the question, the firewall filters out everything except port 443. You arre correct: I should have mentionned that only TLS 1.2/1.3 are enabled and that only AES 128 and 256 are supported.

Further, I you replace in web config the line

<add name="Content-Security-Policy" value="upgrade-insecure-requests" />

by

<add name="Content-Security-Policy" value="upgrade-insecure-requests; base-uri 'self'; img-src 'self'; object-src 'self'; script-src 'self';" />

then IIS will not interact with anything that access the server using a valid HTTPS request.

The question relates only to the Microsoft applications (https://.../Rpc and https://.../RpcWithCert) that are provided in the "Default Web Site".

Consider that the KDC Proxy is a member server enforcing Kerberos, which is the configuration that we are using.

It is unclear if the Microsoft applications can be abused from the Internet side of this server.

Regards,

Serge Caron 45

Hello Allan

I understand that Denial Of Service attacks are not a failure of Microsoft Software and that Microsoft provides regular updates to their OS.

The entire IIS configuration is shown in the question and IIS authentication issues are prevented by the absence of interaction with anyone trying to access the website.

With this reduced surface attack in mind, we can verify that the KDC Proxy server does NOT downgrade any logon to NTLM. The script below can be used to scan all DCs for event ID 8004 from a specific server.

For example, ParseNTLMAudit.ps1 -StartTime 2026.02.04 -IncludeOnly YourKDCProxyServer will result in the single line NTLM audit from 02/04/2026 00:00:00 to 08/04/2026 15:25:50 indicating that no NTLM was allowed from this server in the past six months.

I have to presume that successful Kerberos logons are correctly handled by the DCs.

Here is the conundrum: can the /Rpc applications establish a session when Kerberos credentials are invalid ?

For example, in a RDP connection attempt, I understand that the target computer can still refuse the connection. However, this is the scenario to be avoided at all times.

Regards,

##******************************************************************
## Revision date: 2026.01.08
##
##		2026.01.08: Proof of concept / Initial release
##
##
## The original script was generated from some AI and modified to 
## display NTLM events from all DCs in the domain.
##
## Copyright (c) 2026 PC-Évolution enr.
## This code is licensed under the GNU General Public License (GPL).
##
## THIS CODE IS PROVIDED *AS IS* WITHOUT WARRANTY OF
## ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING ANY
## IMPLIED WARRANTIES OF FITNESS FOR A PARTICULAR
## PURPOSE, MERCHANTABILITY, OR NON-INFRINGEMENT.
##
##******************************************************************
#
#

<#
.SYNOPSIS
    Parse Windows Event ID 8004 (NTLM authentication) from Security logs.

.DESCRIPTION
    This script retrieves Event ID 8004 from the Security log, extracts useful
    NTLM authentication details, and outputs them in a structured table.
    It includes error handling and supports filtering by date range.

.NOTES
    Requires: PowerShell 5.1+ and appropriate permissions to read Security logs.
#>

param (
    [datetime]$StartTime = (Get-Date).AddDays(-1), # Default: last 24 hours
    [datetime]$EndTime   = (Get-Date),              # Default: now
    [array] $Exclusions = @(),
    [array] $IncludeOnly = $null
)

# Get the ID and security principal of the current user account
$myWindowsID = [System.Security.Principal.WindowsIdentity]::GetCurrent()
$myWindowsPrincipal = New-Object System.Security.Principal.WindowsPrincipal($myWindowsID)

# Get the security principal for the administrator role
$adminRole = [System.Security.Principal.WindowsBuiltInRole]::Administrator

# Check to see if we are currently running as an administrator
if (!$myWindowsPrincipal.IsInRole($adminRole)) {
	Write-Host -ForegroundColor Red "Administrative privileges are required to run this script."
	Write-Host
	exit 911
}

# Restrict this script to servers (member server or domain controller)
if ($(Get-WmiObject -Class Win32_OperatingSystem) -eq 1) {
	Write-Host -ForegroundColor Red "Run this script on any server of the domain."
	Write-Host
	exit 911
}


### Make sure AD cmdlets are available
try { Import-Module ActiveDirectory -ErrorAction Stop }
catch { Install-WindowsFeature RSAT-AD-PowerShell }

# Output date range

Write-Host
Write-Host "NTLM audit from $StartTime to $EndTime"
Write-Host

# MS-NRPC NETLOGON_SECURE_CHANNEL_TYPE definition
$SChannelTypes = @("Null","MsvAp","Workstation","TrustedDnsDomain","TrustedDomain","UasServer","Server","CdcServer")

# Get all DCs in this Domain
$DCs = Get-ADDomainController -Filter * | Select-Object -ExpandProperty HostName

# Parse the logs
$parsed = @()
foreach ($DC in $DCs) {

	try {
		# Retrieve Event ID 8004 from Security log
		$events = Get-WinEvent -ComputerName $DC -FilterHashtable @{
			LogName   = 'Microsoft-Windows-NTLM/Operational'
			Id        = 8004
			StartTime = $StartTime
			EndTime   = $EndTime
		} -ErrorAction Stop

		if (-not $events) {
			Write-Host "No Event ID 8004 entries found in the specified time range." -ForegroundColor Yellow
		} else {
			# Parse and display relevant fields
			$parsed += foreach ($event in $events) {
				$xml = [xml]$event.ToXml()

				# Extract fields from EventData
				$data = @{}
				foreach ($d in $xml.Event.EventData.Data) {
					$data[$d.Name] = $d.'#text'
				}

				if ( (($null -eq $IncludeOnly) -or ($IncludeOnly -match $data['SChannelName'].ToLower())) `
					-and (-not ($Exclusions -match $data['UserName'].ToLower())) ) {
					[PSCustomObject]@{
						TimeCreated     = $event.TimeCreated
						Controller	    = $DC.Split('.')[0]
						TargetUser      = $data['UserName']
						TargetDomain    = $data['DomainName']
						WorkstationName = $data['WorkstationName']
						SChannelName	= $data['SChannelName']
						SChannelType	= $SChannelTypes[$data['SChannelType']]
					}
				}
			}
		}

	} catch {
		Write-Host -ForegroundColor Red "Error retrieving Event ID 8004 from $DC :"
		Write-Host -ForegroundColor Red "->  $($_.Exception.Message)"
	}

}

# Output as a table
$parsed | Sort-Object TimeCreated -Descending | Format-Table -AutoSize

Write-Host

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Serge Caron 45 Reputation points

2026-08-05T14:05:22.1766667+00:00

Hello Allan,

The question is about known KDC Proxy vulnerabilities.

In the case of Remote Desktop Gateway, as documented here, "if you have an RD Gateway deployed, did you know that unless a KDC proxy is also deployed on the same host and port, you have a guaranteed NTLM downgrade for the RD Gateway connection from mstsc".

It is possible to configure this RD Gateway to authenticate clients using only the Kerberos Proxy.

What is not trivial is to find out what are the other functionalities available through the /Rpc modules available in IIS.

This question is not answered.

Regards,
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

2 answers

Your answer

Allan Solomon Mejia 2,595 Reputation points

2026-07-23T20:01:07.8866667+00:00

Hi Serge,

Exposing a Kerberos KDC Proxy (KKDCP) to the Internet is a supported deployment model, but like any Internet-facing service, its security depends on proper hardening rather than simply opening TCP 443.

A few considerations:

TLS should be enforced (TLS 1.2/1.3), with a trusted certificate and strong cipher suites.

The server should be fully patched and run only the required IIS/KDC Proxy components. Avoid hosting unnecessary applications on the same server.

If possible, deploy the KDC Proxy on a member server rather than directly on a domain controller to reduce the attack surface.

Restrict access with a firewall, enable logging, and monitor for abnormal authentication patterns.

If you're concerned about NTLM fallback, consider enforcing Kerberos where possible, disabling NTLM where supported, and using features such as Protected Users, Credential Guard, and the latest Kerberos hardening guidance.

The primary risks are similar to any Internet-facing authentication endpoint: denial-of-service attempts, exploitation of unpatched vulnerabilities, credential attacks, and misconfiguration. However, exposing TCP 443 alone does not expose the domain controller directly or the Kerberos service itself—the KDC Proxy simply relays Kerberos messages over HTTPS.

Microsoft also recommends performing regular security assessments using tools such as Microsoft Defender for Identity, Microsoft Defender for Endpoint, and reviewing IIS and Security event logs for anomalous authentication activity.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.
Serge Caron 45 Reputation points

2026-08-04T18:48:35.8166667+00:00

Hello Allan,

Thank you for your answer.

As specified in the question, the firewall filters out everything except port 443. You arre correct: I should have mentionned that only TLS 1.2/1.3 are enabled and that only AES 128 and 256 are supported.

Further, I you replace in web config the line

<add name="Content-Security-Policy" value="upgrade-insecure-requests" />

by

<add name="Content-Security-Policy" value="upgrade-insecure-requests; base-uri 'self'; img-src 'self'; object-src 'self'; script-src 'self';" />

then IIS will not interact with anything that access the server using a valid HTTPS request.

The question relates only to the Microsoft applications (https://.../Rpc and https://.../RpcWithCert) that are provided in the "Default Web Site".

Consider that the KDC Proxy is a member server enforcing Kerberos, which is the configuration that we are using.

It is unclear if the Microsoft applications can be abused from the Internet side of this server.

Regards,
Serge Caron 45 Reputation points

2026-08-04T19:52:48.8366667+00:00

Hello Allan,

Thank you for your answer.

As specified in the question, the firewall filters out everything except port 443. You arre correct: I should have mentionned that only TLS 1.2/1.3 are enabled and that only AES 128 and 256 are supported.

Further, I you replace in web config the line

<add name="Content-Security-Policy" value="upgrade-insecure-requests" />

by

<add name="Content-Security-Policy" value="upgrade-insecure-requests; base-uri 'self'; img-src 'self'; object-src 'self'; script-src 'self';" />

then IIS will not interact with anything that access the server using a valid HTTPS request.

The question relates only to the Microsoft applications (https://.../Rpc and https://.../RpcWithCert) that are provided in the "Default Web Site".

Consider that the KDC Proxy is a member server enforcing Kerberos, which is the configuration that we are using.

It is unclear if the Microsoft applications can be abused from the Internet side of this server.

Regards,
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Serge Caron 45 Reputation points

2026-08-05T14:05:22.1766667+00:00

Hello Allan,

The question is about known KDC Proxy vulnerabilities.

In the case of Remote Desktop Gateway, as documented here, "if you have an RD Gateway deployed, did you know that unless a KDC proxy is also deployed on the same host and port, you have a guaranteed NTLM downgrade for the RD Gateway connection from mstsc".

It is possible to configure this RD Gateway to authenticate clients using only the Kerberos Proxy.

What is not trivial is to find out what are the other functionalities available through the /Rpc modules available in IIS.

This question is not answered.

Regards,
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Answer 1

Allan Solomon Mejia 2,595

Hello @Serge Caron

Thank you for the clarification and for sharing the Microsoft security advisories.

You're correct that the concern is specifically about the Kerberos KDC Proxy Service (KPSSVC) and the recent RCE vulnerabilities (CVE-2024-43639 and CVE-2025-33071), not the general authentication configuration of RD Gateway.

If your question is whether other IIS RPC modules or Windows components depend on the KDC Proxy service, Microsoft does not currently publish documentation that enumerates all components or features that make use of KPSSVC. The documented use case is Kerberos proxying for scenarios such as Remote Desktop Gateway and clients that require Kerberos authentication without direct line-of-sight to a domain controller.

If you're considering disabling the KDC Proxy service as a mitigation, I'd recommend first validating whether any clients in your environment are using it by:

Reviewing IIS logs for requests to the KDC Proxy endpoint.

Monitoring the KDC Proxy (KPSSVC) operational logs in Event Viewer, if enabled.

Testing RD Gateway connectivity after temporarily disabling the service in a non-production environment.

As of today, I'm not aware of Microsoft publishing a definitive list of all Windows features that rely on KPSSVC beyond the documented scenarios. If Microsoft has additional implementation details, a moderator may be able to engage the Windows Server product group for clarification.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.

Serge Caron 45 Reputation points

2026-08-07T20:56:59.6033333+00:00

Hello Allan,

In our environments, the member servers running the Kerberos Proxy offer no other services: they must run the KPSSVC service.

I hope you are in a position to engage a moderator and/or the Windows Server product group to get a definitive answer to this question.

Regards,
Allan Solomon Mejia 2,595 Reputation points

2026-08-07T21:34:19.46+00:00
Thank you for the additional information, @Serge Caron .

That's helpful context. If your Kerberos Proxy servers are dedicated to KPSSVC and do not host other IIS applications or RPC-based services, that significantly narrows the scope of potential impact.

Based on the Microsoft documentation currently available, there is still no published guidance that comprehensively lists all Windows features or components that rely on the Kerberos KDC Proxy Service (KPSSVC) beyond the documented scenarios (such as Kerberos proxying for Remote Desktop Gateway and other remote Kerberos authentication scenarios).

Since your question is specifically about the broader impact and any undocumented dependencies of KPSSVC, I agree that this would benefit from clarification by the Windows Server product group. A Microsoft moderator may be able to engage the engineering team to confirm:

Whether KPSSVC exposes any additional functionality beyond the documented Kerberos proxy scenarios.

Whether disabling the service has any unsupported or undocumented side effects.

Whether Microsoft has specific mitigation guidance for environments affected by CVE-2024-43639 and CVE-2025-33071 beyond applying the security updates.

In the meantime, Microsoft's recommended mitigation remains to apply the latest security updates for the affected Windows Server versions rather than relying solely on service configuration changes.

I hope a Microsoft moderator reviewing this thread can help determine whether this should be escalated to the Windows Server engineering team for further guidance.

Please don't forget to "Accept the Answer" if this information helped you. This will help us and others in the community as well.

Answer 2

Microsoft has published two Remote Code Execution (RCE) advisories affecting the Kerberos Proxy service:

CVE-2024-43639 Windows KDC Proxy Remote Code Execution Vulnerability, published 2024.11.12
CVE-2025-33071 Use after free in Windows KDC Proxy Service (KPSSVC) allows an unauthorized attacker to execute code over a network, published 2025.06.10

The enumeration of affected products (from Windows Server 2012 to 2025) was updated on 2026.06.17.

These RCE are exploitable directly from the Internet and do not require authentication to gain access to the hosting server.

The following will display the exact build of a server :

$os = Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion"
Write-Host "$($os.ProductName) $($os.DisplayVersion) (Build $($os.CurrentBuildNumber).$($os.UBR))"

Also, as pointed out in the comments, the Kerberos Proxy service has undocumented side effects.