Penetration tests usually end with a list of vulnerabilities. Far fewer end with a question that matters just as much: what did our SIEM see? Testers use the same tools and techniques as real intruders, often in the same order. Detecting them is a rehearsal for detecting an attacker, and every stage they get through unnoticed is one a criminal would get through too.
Speed matters. Mandiant found that in 2025 the median time between initial access and the hand-off to a second threat group fell to 22 seconds, and exploits remained the most common way in, at 32% of intrusions. [1] You won’t catch that in a weekly report review. You need detections that fire while it happens.
Agree the rules of engagement first
Decide up front whether the SOC knows the test is happening. A blind test measures real detection and response. An announced test lets you tune rules live alongside the testers. Either way, agree how you will tell testers from a real attacker, such as known source addresses, a code word or a contact who can confirm, so a genuine intrusion during the test window isn’t written off as “probably the pentesters”.
External scanning and exploitation
An external test starts with reconnaissance: port and host sweeps, then vulnerability scanners, then attempts to exploit what they find. [2]
- Firewall logs: a burst of denied or reset connections from one source across many ports or hosts. Nmap and masscan are fast and leave a clear pattern.
- Web server, proxy and WAF logs: scanner fingerprints in user agents and request patterns (Nessus, Qualys, OpenVAS, Nikto, sqlmap, nuclei), sudden bursts of 404 errors, and blocked injection or path-traversal attempts.
- Correlation: any two of sweep, scanner fingerprint and exploitation attempt from the same source within two hours is a reliable “someone is actively attacking us” alert, and far quieter than alerting on every scan the internet throws at you.
Active Directory reconnaissance and credential tooling
Once inside, most tests head straight for Active Directory. The tools are well known, and so are their traces in process-creation logs (Sysmon event 1, or Windows 4688 with command-line logging) and PowerShell script-block logs (4104). [3]
- Directory enumeration: SharpHound and other BloodHound collectors, AdFind, and unusually large LDAP queries.
- Password spraying: CrackMapExec or NetExec, kerbrute and similar tools, visible as one source failing logons (4625, or 4771 for Kerberos pre-authentication) across many accounts in a short time. [4]
- Credential dumping: Mimikatz, Rubeus, secretsdump and lsadump in command lines, and unexpected access to the LSASS process.
Kerberoasting and DCSync
Two credential-access techniques deserve their own rules because they are so common in tests and real intrusions alike.
Kerberoasting requests service tickets for accounts with a service principal name, then cracks them offline. [5] On domain controllers, look for event 4769 with ticket encryption type 0x17 (RC4) for services other than krbtgt, especially many in a short time from one account. This needs “Audit Kerberos Service Ticket Operations” switched on. [6]
DCSync abuses directory replication to pull password hashes from a domain controller without touching its disk. [7] Look for event 4662 carrying the directory replication rights GUIDs, from an account or host that is not a domain controller.
Together they tell a story: roasting, then the cracked account signing in to new hosts (4624 logon type 3, or 4648 explicit credentials), then replication. Any two of those for the same account within a day is an incident.
Remote execution with Impacket
Impacket’s psexec, smbexec, wmiexec and dcomexec scripts are staples of internal tests, and they leave consistent traces. [8]
| Stage | Where to look | What it looks like |
|---|---|---|
| Service creation | System event 7045, Security event 4697 | A new service whose path points at %COMSPEC% or ADMIN$, or carries an inline cmd command |
| Tool dropped on an admin share | Security event 5145 (detailed file share) | Executables, batch files or __output files written to ADMIN$ or C$ |
| Remote-execution shell | Sysmon event 1, Security event 4688 | wmiprvse, mmc, dllhost or services starting cmd.exe or powershell.exe |
Command-and-control beacons
Red teams usually run a C2 framework such as Cobalt Strike, Sliver or Metasploit. Watch for it from both ends:
- On the host (Sysmon): default named pipes (events 17 and 18) such as msagent_, postex_ or MSSE-, and process injection (event 8, CreateRemoteThread) into rundll32, dllhost or werfault.
- On the network (proxy, firewall, Zeek): connections to typical team-server ports, and steady, regular beaconing to a rare external destination.
Mature red teams change the defaults, so treat these as the floor, not the ceiling. Beaconing analysis, which looks for regular intervals and small, consistent payloads, still works when names change.
Red-team attack stories, ready to deploy
LogLens includes correlation rules for external scanning and exploitation, Active Directory recon and credential tooling, Impacket remote execution and C2 beacons. It shows which stages your logs can already see, and which source would complete each one.
See LogLens attack stories →Check your logs can see it, before the test
Most “the SIEM saw nothing” results come down to missing telemetry, not missing rules. Before the test, confirm that:
- Process creation with command lines is logged on servers and workstations (Sysmon, or 4688 with command-line auditing).
- PowerShell script-block logging (4104) is on.
- Domain controllers audit Kerberos service tickets (4769), directory service access (4662) and logons.
- Detailed file share auditing (5145) is on for servers, at least for the admin shares.
- Firewall deny logs, proxy logs and WAF logs all reach the SIEM.
After the test: turn the report into detections
Ask the testers for their timeline: every action, with the time, source and target. Line it up against your SIEM’s alerts and logs, and mark each step as alerted, logged but not alerted, or not logged. The “logged but not alerted” steps are your fastest wins: the data is there and only the rule is missing. The “not logged” steps become your next onboarding or audit-policy change. Then test again. A penetration test that improves your detections is worth far more than one that only produces a list of patches.