Writeup on how we built runtime enforcement into our k8s agent with eBPF instead of shipping Falco alongside it. Covers the syscall tracepoint design, in-kernel filtering with BPF maps, why we picked SIGKILL over BPF LSM, and a staging postmortem where enforcement wasn't namespace-scoped and we took out our own Harbor, Cilium, and RabbitMQ.

Been doing some detection work around Kerberoast traffic this week and wanted to share a gap that's easy to miss in environments that haven't fully deprecated RC4.

The standard detection is Event ID 4769 filtered on encryption type 0x17. Most SIEMs have this as a canned rule. The problem is in environments with mixed OS versions or legacy applications that dynamically negotiate encryption, 0x17 requests are normal background noise. If you're not filtering beyond encryption type you're either drowning in false positives or you've tuned it so aggressively you're missing real attacks.

What you should look for:

4769 where:

• Encryption type is 0x17
• Requesting account is a user principal, not a machine account
• Service name is not krbtgt and not a known computer principal
• The requesting account has had no prior 4769 events against that specific SPN

That last condition is the one most people skip. Legitimate service ticket requests follow patterns. A user account requesting a ticket for a service it's never touched before at 2am is a different signal than the same request during business hours from a known admin workstation.

But the actual gaps noone is talking about -> gMSA accounts are immune to offline cracking because the password is 120 characters of random data rotated every 30 days. But the migration is never complete. Every environment has at least a handful of service accounts that can't be migrated.. anything that needs a plaintext password in a config file, some Exchange components, legacy apps with no gMSA support.

Those accounts are permanent Kerberoast targets. (!) The question isn't whether they're there. It's whether you know exactly which ones they are and whether you're watching them specifically.

On the offensive side of this:

RC4 downgrade via AS-REQ pre-auth is well documented. Less discussed is that in environments where AES is enforced at the GPO level but legacy applications are still negotiating through Netlogon, you can still coerce RC4 service ticket issuance by manipulating the etype list in the TGS-REQ. LmCompatibilityLevel = 5 controls client behavior. It has no authority over what a misconfigured application server requests through MS-NRPC. Silverfort published a POC on this last year (i wrote about this a couple weeks ago) they forced NTLMv1 through a DC configured to block it using the ParameterControl flag in NETLOGON_LOGON_IDENTITY_INFO. Microsoft acknowledged it, didn't patch it, announced OS-level removal in Server 2025 and Win11 24H2 instead. (typcial)

If your environment isn't on those versions, that vector is still open and there's no compensating control beyond full NTLM audit logging and application-level remediation.

btw:

auditpol /set /subcategory:"Kerberos Service Ticket Operations" /success:enable gets you the 4769 visibility.