So, you think you’re ready for enforcing AES for Kerberos?

Chris_Cartwright · ‎Mar 08 2024

Note: Something went wrong with some search engines indexing this page. This is a repost from the original June article.

Hello, Chris Cartwright here from the Directory Services support team. We have many customers asking questions about how to track down the usage of RC4 in their environment. Over the years, we’ve had tons of great articles that, when put together, provide a fairly simple solution to this problem. (These can be found in the References section at the end of this article.) However, as Windows Admins, AD Admins, Sysadmins, or whatever title is bestowed upon us, we usually like the solutions wrapped up in one package so we can move on to the next fire or project. I hope to do that here.

This article assumes that the reader is well versed in Kerberos Encryption Types. If not, I highly recommend scrolling down to the References sections and reading Understanding Kerberos Encryption Types.

The Events

First, we want to address how to find RC4 (Because no one should be using anything weaker than that these days right?) in the Event Logs. We need to have a few things configured before we can see the events. Auditing Kerberos on all DCs in the environment needs to be enabled for at least “Success.” We can verify this by running the following two commands on your DCs:

auditpol /get /subcategory:"Kerberos Service Ticket Operations"
auditpol /get /subcategory:"Kerberos Authentication Service"

The most common way of deploying these auditing settings is with a GPO, thus ensuring that all DCs have the same auditing configuration. We can find these under Computer Configuration\Policies\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Audit Policies\Account Logon in the Group Policy Editor.

These audits will produce event IDs 4768 and 4769 in the Security log on the DC with information regarding the service requested, the user that made the request, and the encryption type used.

Here’s an example of a TGT retrieved using RC4 (Less common) in Event ID 4768:

We’re looking for 0x17 in the Ticket Encryption Type field. If you find 4768, we also want to make sure we don’t have a Kerberos-Key-Distribution-Center Event ID 42 in your System log:

Here’s an example of a service ticket requested that used RC4 (More common) in Event ID 4769:

Again, we’re looking for 0x17 under Ticket Encryption Type.

Here’s an example of a ticket being renewed that used RC4 (less common) in Event ID 4770:

Once you find these, you need to take a look at the Client address and Service Name. The most common reasons for RC4 are that the source client is configured for RC4, or the target service is not explicitly configured for AES. Explicitly enabling an account for AES, as shown in the screen capture below, is done via the account tab on the user properties in the Active Directory Users and Computers management console:

Another reason, hopefully less common, would be Domain Controllers are configured against our recommendations to either have AES disabled or default to RC4, whether that’s via DefaultDomainSupportedEncTypes or “Network security: Configure encryption types allowed for Kerberos.”

The Query to Find RC4

In order to filter the Security logs for these events, you can use the following query with the Event Filter XML Filtering:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
*[EventData[Data[@Name='TicketEncryptionType']='0x17']]
</Select>
  </Query>
</QueryList>

Once you have the events being generated all your DCs, you can start searching for RC4.

Event Forwarding

Now, looking at these events one DC at a time isn’t so bad if you only have a few DCs. However, if you start pumping up the DC count, it quickly becomes an administrative headache. If only there was an easy way to collect all of these and look at them all at once…

Well, friends, we heard you! (About 15 years ago, I think.) Windows comes with the ability to forward events matching a particular filter leveraging Windows Event Forwarding (Sends events) and a Subscriber (Configures events to be sent). This allows you to send events to a subscriber so that you don’t have to search every DC. Our configuration here will leverage Group Policy to push the Event Subscriber information to all DCs. Our collection point will be configured with a subscription that is Source Initiated and leverages the XML query above. We will go over an example of such a subscription.

For simplicity’s sake, this will not be configured for HTTPS. However, we would encourage you to use TLS, if possible, in your environment. You will need to pick a target server, the Subscriber, where you want these events to be collected.

On your Subscriber, open Event Viewer, and you should notice a folder that says Subscriptions at the bottom. Click on it and choose Create Subscription. If you’ve never worked with them before, you may get a message asking if you want to configure the Windows Event Collector Service to automatically start. Select Yes.

Give the subscription a name that makes sense to you, configure it to be Source computer initiated, and then add the Domain Controllers groups in your forest as necessary.

Next, Click on Select Events, hit the XML tab, check the “Edit query manually” box, and click Yes on the warning that pops up. Copy and paste the query above into this field. Note: You may need to use notepad or other basic text editor as an intermediary.

If you wish to change the Advanced Settings, you may do so at this point. Otherwise, click OK.

However, by default NETWORK SERVICE, is unable to read the Security log. The preferred and supported method to rectify this is to modify the security descriptor on the Security Log to include (A;;0x1;;;NS). You will need to get the current configuration of the log by running wevtutil gl security, paying close attention to channel access:

Mine was

O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)

So, in my GPO, I put in this string:

O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;NS)

under Computer Configuration\Policies\Administrative Templates\Windows Components\Event Log Service\Security as shown below:

You can confirm that the change applied here:

Custom Event Forwarder Target

You will notice that by default, your target for forwarding is mostly limited to “Forwarded Events.” This may not suit your needs if you are forwarding other things. We can create a Customer Event Forwarder Target using the process below. We need a manifest (.man) file:

<?xml version="1.0"?>
<instrumentationManifest xsi:schemaLocation="http://schemas.microsoft.com/win/2004/08/events eventman.xsd" xmlns="http://schemas.microsoft.com/win/2004/08/events" xmlns:win="http://manifests.microsoft.com/win/2004/08/windows/events" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:trace="http://schemas.microsoft.com/win/2004/08/events/trace">
    <instrumentation>
        <events>
            <provider name="WEC-RC4" guid="{E0F20503-A96E-4964-9F3F-C635FBC572B5}" symbol="RC4" resourceFileName="C:\Windows\system32\RC4KRB-Hunter.dll" messageFileName="C:\Windows\system32\RC4KRB-Hunter.dll">
                <channels>
                <channel name="RC4-Hunter" chid="RC4-Hunter" symbol="RC4_Hunter" type="Operational" enabled="true" message="$(string.WEC-RC4.channel.RC4_Hunter.message)"></channel>
                </channels>
            </provider>
        </events>
    </instrumentation>
    <localization>
        <resources culture="en-US">
            <stringTable>
            <string id="WEC-RC4.channel.RC4_Hunter.message" value="RC4 Hunter"></string>
            </stringTable>
        </resources>
    </localization>
</instrumentationManifest>

Save the text above as RC4KRB-Hunter.man. From here, the instructions diverge. We can either use the Windows Software Development Kit to run a few commands to create the dll we need to pass to Event Viewer or we can use Visual Studio. While the SDK method is a bit more friendly to non-developers, Visual Studio is the preferred method.

Creating the DLL with Windows SDK

First, you’ll need to download the SDK from the Windows SDK site (https://developer.microsoft.com/en-us/windows/downloads/windows-sdk/) or the archive, if you need an older version. In the installer, select the following:

Copy the manifest (.man) file above to a working folder and compile the manifest. Below, I created an “RC4” folder. Here are the commands to create a dll from the manifest:

"C:\Program Files (x86)\Windows Kits\10\bin\10.0.XXXXX.0\x64\mc.exe" c:\RC4\RC4KRB-Hunter.man

"C:\Program Files (x86)\Windows Kits\10\bin\10.0.XXXXX.0\x64\rc.exe" c:\RC4\RC4KRB-Hunter.rc

"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe" /win32res:C:\RC4\RC4KRB-Hunter.res /target:library /out:C:\RC4\RC4KRB-Hunter.dll

You should now have, among other things, RC4KRB-Hunter.man and RC4KRB-Hunter.dll.

Creating the DLL with Visual Studio

First, you need to download Visual Studio Community Edition from https://visualstudio.microsoft.com/vs/community/. Choose the following install options:

Copy the manifest (.man) file above to a working folder and compile the manifest with mc.exe. Below, I created an “RC4” folder.

"C:\Program Files (x86)\Windows Kits\10\bin\10.0.XXXXX.0\x64\mc.exe" C:\RC4\RC4KRB-Hunter.man

This will create, among other things, an h and rc file. We will use these in Visual Studio. When it launches, you can logon or choose to skip.

Set up for first use might take a while (Lunch break)

Create a new project, Windows Desktop Wizard, and give it a name:

Click Create, and choose Dynamic Link Library as Application type. Make sure Empty Project is checked.

Right click on the right side and choose Add Existing Item

Select the .rc and .h files.

You should see the files showing in the project as shown below:

On the top Menu bar, select Project->Properties, and set /NOENTRY under Linker\Advanced.

Then, in the top Menu bar, click Build->Build Solution. In your project folder, there will be a dll file under .\x64\Debug.

Importing the Magic

Copy your man and dll files to your subscriber under C:\Windows\System32, and then run:

wevtutil im C:\Windows\System32\RC4KRB-Hunter.man

Open up Event Viewer, and you should see something like this (but without events):

If you find yourself needing to rollback this change, run:

wevtutil um C:\Windows\System32\RC4KRB-Hunter.man

Make sure you’ve already removed any Subscriptions first.

Once this manifest has been imported, you can target it with your subscription:

Deploying the Subscription Configuration

Now that you have a subscription created, and (optionally) the custom event forwarding target, we need to deploy the configuration to our DCs:

server=http://events.contoso.com:5985/wsman/SubscriptionManager/WEC,Refresh=300

You may change the refresh value to whatever you wish. Link this to you Domain Controllers OU, and either wait a bit, or run gpupdate on a DC. Open Event Viewer, and you should see something like this (if you have RC4 hits in the security log):

Good hunting!