Source-First, SIEM-Agnostic Active Directory Detection

You already know what a SIEM is for. What you may have absorbed without noticing is the assumption that detection happens in the SIEM, so no SIEM means no detection. This sub takes that assumption apart, because the most exposed domains are often the ones without one.

That scenario is not an edge case, it is the median. The organizations most exposed on Active Directory are frequently the least instrumented.

A detection course built entirely on Sentinel queries quietly abandons exactly the people who need it most. So this course starts somewhere else, and it is worth being explicit that this is a deliberate departure from how the rest of the platform teaches.

Most of our courses assume Microsoft Sentinel and Defender, because they are about cloud-era estates that have them. This one does not, because the audience defending on-premises Active Directory often does not, and the evidence does not require them.

That is not a knock on the cloud-era courses or on Sentinel. It is a recognition that Active Directory is a different problem with a different audience. The domain controller has been writing the same security events for twenty years, long before any cloud SIEM existed, and those events still hold the proof. A course about defending AD should meet defenders where the evidence actually is, which is the controllers, not a particular console.

The Windows Security log is the universal layer

Here is the fact the vendor got wrong. The events that catch AD attacks, the 4769 with RC4, the 5136 on a delegation attribute, the 4662 carrying replication GUIDs, are written to the Windows Security log on the controllers.

That log exists on every domain, produced by Windows itself, with no extra product required. It is the universal layer, and there are three places to read it, in rising order of how much infrastructure they need.

You can read it locally on a controller with Get-WinEvent, a built-in PowerShell command. Nothing to buy, nothing to install. That is the floor, and it is enough to run a detection by hand or on a schedule.

That floor is more capable than it sounds. A scheduled PowerShell query against the controllers, writing its hits to a file or an email, is a real detection that has caught real intrusions in small shops. It is not elegant and it does not scale, but it works, and working beats elegant when the alternative is nothing.

You can forward it with Windows Event Forwarding to a collector, so events from all your controllers land in one place you can query without logging on to each one. Still no licensed product.

Or you can feed it into whatever SIEM you have and query it at scale with alerting and correlation. The same evidence flows through all three. The detection logic does not change. Only the convenience of reading it does.

Convenience is not nothing, though. On a busy controller the local log rolls over fast, so the events you need may already be gone by the time you investigate. Forwarding is partly about querying many controllers at once and partly about keeping the evidence long enough to find it. You can start at the floor today and add reach later without changing a single detection.

Sigma is the canonical form

If the same logic runs everywhere, you want to write it once in a form that belongs to no single vendor, then translate it. That form is Sigma.

A Sigma rule describes a detection in vendor-neutral YAML: which log source, which fields, which values. It is the rule you carry between jobs and between tools, the thing you hand to someone running Splunk when you run Sentinel and have it mean the same thing.

A Sigma rule is short and readable. It names the log source, a selection of fields with the values that flag the attack, and a condition that ties them together, plus notes on likely false positives and a severity. There is no magic in it, which is the point: anyone can read it and see exactly what it claims about the world.

Turning a Sigma rule into a running query is done by a converter or by hand. The course does the translation for you and shows the result, so you see the portable rule and the concrete query side by side and learn to move between them yourself.

So the course treats Sigma as canonical. For every detection, the Sigma rule is the source of truth, and the forms you run, the Get-WinEvent query, the KQL, the SPL, are renderings of it.

The discipline this builds is portability. You stop thinking in one query language and start thinking in the detection, which you can then express wherever you happen to be working. That is the difference between knowing a tool and knowing the craft.

MDI is an enhancement, not a requirement

Microsoft Defender for Identity is genuinely useful. It watches the controllers, raises named alerts for many of these attacks, and adds signal the raw log does not have, most importantly around reconnaissance.

Three concrete gains show up where you have it. Its sensors see the LDAP and enumeration patterns native auditing misses, so recon becomes visible. It raises named, triaged alerts, a Suspected DCSync, a Suspected Kerberoasting, which is a faster entry point than reading raw events. And it correlates identity activity across accounts and devices more richly than a single Security event does.

Where you have it, this course shows you what it adds, because ignoring a tool you are paying for would be foolish. But it is an enhancement, and no core detection depends on it.

Every detection rests first on the Windows log, and the MDI form is shown as the extra signal you get on top, never the only path. This matters for two reasons.

The obvious one is the opening scenario: the teams most exposed often do not have MDI, and a detection they cannot run is no detection at all.

The subtler one is resilience. Tools get misconfigured, licenses lapse, sensors fall behind. A program anchored to the universal log keeps working when the enhancement layer does not, and treats the enhancement as a bonus rather than a single point of failure.

The one place this honesty costs you

Source-first thinking also means being straight about where the universal log is weak, and there is one place it is. Reconnaissance, the LDAP and directory enumeration an attacker runs to map the domain, is not meaningfully logged by native Windows auditing.

You cannot write a Sigma rule for an event that does not exist. So the recon module does not pretend to detect it with the Security log. It teaches posture instead.

You run the same enumeration tools against your own domain to see what an attacker would see, reduce what the directory gives away, and tier your accounts so the map is less useful when someone draws it. Where Defender for Identity is present it adds real recon detection, shown as the enhancement it is.

In practice that means running BloodHound or SharpHound and PingCastle against your own domain, reading the attack paths they surface, and closing the worst ones: removing a delegation nobody uses, tightening an over-broad group, separating tier-zero accounts from everyday admin. You are doing the attacker's recon first and acting on it, which is a different and more honest activity than waiting for an alert that the native log cannot raise.

But the honest baseline is that recon is the gap, and a course that taught you a fake detection there would be teaching you to trust an alert that will never fire. Being clear about the gap is part of being trustworthy about everything else.

What SIEM-agnostic does not mean

Source-first is not anti-SIEM. If you have Sentinel or Splunk, use it, and the course gives you the KQL and SPL to do so. A SIEM is the right home for a standing detection program: it collects centrally, retains for months, alerts on a schedule, and correlates across sources in ways a single controller cannot.

What source-first refuses is the assumption that the SIEM is where detection begins. The detection begins with the event and the field that distinguishes the attack. The SIEM is one excellent place to run that logic at scale, not a precondition for having it. Hold those two ideas together and you get the best of both: portable detections that also run well in whatever platform you own.

Source-first is a discipline, not a limitation

It would be easy to read all this as making the best of a constraint, as if source-first were the budget option. It is the opposite. Anchoring to the universal log is the more rigorous choice, because it forces you to understand the evidence rather than the dashboard.

When your detection is a Sigma rule over named Windows fields, you can explain exactly why it fires and exactly what would make it miss. When your detection is a saved search in one vendor's console, that understanding is easy to skip, and you inherit the vendor's assumptions without examining them.

There is a career argument here too. Tools change, employers change, and the vendor you know today is not the one you will use in five years. The analyst who understands the evidence carries that understanding intact across every move, while the analyst who only knows a console starts over each time the console changes.

The source-first analyst is the one who can walk into any environment, find the controllers, and start detecting with what is already there. That portability is worth more over a career than fluency in any single product, and it is the capability this course is really building.

It is also why the order of this course matters. You learn the event and the field first, the canonical rule second, and the specific query last, so that the durable knowledge sits underneath the disposable syntax. Get that order right and every later module compounds, because you are adding detections to a foundation that does not move when the tooling does.

The next sub makes the four-surface idea concrete by taking one detection, Kerberoasting, and showing the same logic as a Sigma rule and then as the Get-WinEvent, KQL, and SPL forms you would actually run, so the pattern is familiar before you meet it in every module that follows.