Rubeus Kerberoast & AS-REP Roast: LDAP Filters and What to Log

Kerberoasting and AS-REP roasting are still bread-and-butter AD abuse. Rubeus makes both loud in a lab and educational on the wire: the LDAP search that finds targets is often more distinctive than the TGS request that finishes the job.

Below is what I capture when running Rubeus in a DetectionLab-style domain — filters, ports, and the Windows events I want beside the PCAP.

Commands (lab)

# Kerberoast — users with SPNs, not krbtgt, not disabled
.Rubeus.exe kerberoast /outfile:hashes.kerberoast

# AS-REP roast — users with DONT_REQ_PREAUTH
.Rubeus.exe asreproast

Rubeus prints the LDAP path and filter. That is your detection brief.

Kerberoast LDAP filter

(&
  (samAccountType=805306368)
  (servicePrincipalName=*)
  (!samAccountName=krbtgt)
  (!(UserAccountControl:1.2.840.113556.1.4.803:=2))
)

Decoded intent:

• samAccountType=805306368 — normal user objects
• servicePrincipalName=* — has an SPN (roastable material)
• exclude krbtgt
• UAC bit filter excludes disabled accounts (ADS_UF_ACCOUNTDISABLE)

On the wire: LDAP search to the DC (389/636) requesting attributes needed to request TGS tickets afterward. Shortly after, you should see Kerberos TGS-REQ traffic for those SPNs (88/tcp).

AS-REP roast LDAP filter

(&
  (samAccountType=805306368)
  (userAccountControl:1.2.840.113556.1.4.803:=4194304)
)

4194304 is DONT_REQ_PREAUTH. Any user still carrying that flag is a finding even before an attacker shows up — your vuln management story writes itself.

PCAP workflow

• Domain workstation: e.g. 172.16.1.185
• DC: e.g. 172.16.1.184
• Wireshark: ip.addr == 172.16.1.185 || ip.addr == 172.16.1.184 then refine to ldap || kerberos

Timeline you want to demonstrate in a writeup or detection test:

1. LDAP search with one of the filters above
2. Kerberos AS-REQ / TGS-REQ burst
3. Optional: hashcat/john offline (stays off the wire — do not expect IDS to see cracking)

Windows events worth correlating

Event	Why
4769	TGS requested — look for RC4 (0x17) ticket encryption where AES should dominate; high volume of TGS for many SPNs from one user is a classic hunt
4768	TGT related; AS-REP path interactions
4624 / 4625	Context for the session performing the LDAP bind
LDAP logging / 4662	If you actually audit directory service access (often incomplete in the wild)

Hunt sketch (conceptual):

# Pseudo-hunt: one user requests many distinct service tickets quickly
4769 grouped by Account_Name + Service_Name
where Ticket_Encryption_Type in (0x17, 0x18)
| uncommon service set from a non-service account

RC4 TGS is not always malicious (legacy SPNs exist), but legacy crypto + LDAP recon filter + non-admin workstation is a story.

Network IDS angle

Unlike some BloodHound full-collect noise, Rubeus target discovery is a sharp LDAP filter. If you BER-match on the wire:

• ASCII servicePrincipalName near samAccountType / 805306368
• or the OID matching UAC bitwise for preauth disable

…you get higher precision than “any LDAP.” Still lab-validate. Encrypted LDAPS will blind pure NIDS unless you have a decrypt point.

For coercion tools (PetitPotam and friends) the story shifts to SMB/EFS RPC on 445 — different post. Do not mash every AD tool into one signature.

Prevention that reduces roast value

• No user accounts with SPNs without a hard password / gMSA
• AES-only where possible; stop RC4 where you can survive it
• Find and clear DONT_REQ_PREAUTH: Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true}
• Tiered admin so a workstation user cannot LDAP-browse everything interesting

Detection test plan (steal this)

1. Snapshot lab DC + workstation
2. Start packet capture on DC span
3. Run kerberoast, stop capture, label PCAP
4. Run asreproast, separate PCAP
5. Confirm 4769/4768 series on DC Security log
6. Write one LDAP rule + one 4769 analytics rule
7. Replay PCAPs after every sensor upgrade

If your detection only fires on the Rubeus PE hash, you will miss Impacket, custom scripts, and the next rename. Detect the directory question and the ticket pattern.