ad-opsec-telemetry

AD OPSEC and Telemetry

Every technique leaves a trace. The goal here is not evasion. It is knowing the noise profile of each action so you can document it for the client before the engagement, pick the quieter of two functionally equivalent techniques, and correlate what you did with what their SOC saw. For a defender, read the same tables backwards: they are the events to monitor and alert on.

Two rules of engagement throughout:

• Document the noise. Tell the client what each high-signal action generated, with the event ID and the source IP, so they can find it in their logs.
• Coordinate the loud ones. DCSync, mass spraying, coercion at scale, and LSASS dumps need explicit client sign-off or an end-of-engagement window when detection no longer matters.

Microsoft Defender for Identity (MDI) is the sensor that matters most in AD; it reads DC traffic directly and ships tuned detections for most of what follows.

---

Kerberoasting: Event 4769, RC4 (0x17)

Requesting service tickets for accounts with SPNs, to crack offline.

• Event 4769 (Kerberos service ticket requested) fires for each SPN targeted. The tell is Ticket Encryption Type = 0x17 (RC4-HMAC). Attackers request RC4 because the resulting hash cracks fastest, but a service that normally uses AES suddenly requested with RC4 is the classic signature.
• MDI: "Suspected Kerberoasting attack" is on by default and triggers on the volume and RC4 pattern.
• Requesting all SPNs at once amplifies the signal. Targeting one high-value account is far quieter than roasting the whole domain.

GetUserSPNs.py corp.local/user:pass -dc-ip <dc_ip> -request -outputfile roast.txt

• MITRE: T1558.003 (Steal or Forge Kerberos Tickets: Kerberoasting).
• Defender watch: 4769 with 0x17 for accounts that otherwise use AES; a single principal requesting many distinct SPN tickets in a short window.
• Remediation: strong (25+ char) service-account passwords or gMSA; AES-only on service accounts; monitor 4769 by encryption type.