Forum Discussion

Marcel_Graewer's avatar
Marcel_Graewer
Brass Contributor
Apr 04, 2026

Great write-up, JoaoFranca​ !

I'd like to add a complementary approach to the PowerShell + Power BI workflow: if your Domain Controllers already ship Security Event Logs to a Log Analytics workspace, you can query Event IDs 4768/4769 directly via KQL. Depending on your Sentinel connector (legacy vs. AMA with the updated schema), the TicketEncryptionType field may need to be parsed from EventData first:

SecurityEvent
| where EventID in (4768, 4769)
| parse EventData with * 'TicketEncryptionType">' TicketEncryptionType "<" *
| where TicketEncryptionType == "0x17"
| parse EventData with * 'ServiceName">' ServiceName "<" *
| parse EventData with * 'TargetUserName">' TargetUserName "<" *
| parse EventData with * 'IpAddress">' ClientIP "<" *
| summarize Count = count() by TargetUserName, ServiceName, ClientIP, bin(TimeGenerated, 1h)
| order by Count desc

If you're using the Windows Security Events via AMA connector with the latest DCR schema updates, TicketEncryptionType may already be available as a top-level field, which simplifies the query.

This gives you a continuously updated view of RC4 dependencies without scheduling script runs or manually exporting CSVs. Building a Sentinel Workbook on top of this provides similar dashboard functionality to the Power BI example, but with near-real-time data and the ability to create alerting rules.

And one addition regarding the new Kdcsvc events (201-209): these land in the System log, not Security. Most Sentinel deployments only collect the Security channel from DCs by default. Make sure your Data Collection Rules (DCR) via AMA also include the System channel - or add a custom XPath query targeting System!*[System[Provider[@Name='Kdcsvc']]] to capture these events. This is easy to miss and will leave a significant blind spot during the audit phase.

For tracking controlled rollback accounts: I'd recommend creating a Sentinel Watchlist for every account temporarily set to msDS-SupportedEncryptionTypes = 0x1C (28). That way you maintain visibility on what still needs final remediation before the July 2026 enforcement, and you can cross-reference it with your KQL queries to see if those accounts are still generating RC4 tickets.