VU23225 Investigate Windows security features

Most people meet Windows as a desktop: a Start menu, some windows, a browser. A defender has to meet it as a machine; a layered system of processes, services, drivers, a configuration database and a running record of nearly everything that happens. The reason is simple. You cannot tell that an attack is under way unless you know what "normal" looks like, and you cannot investigate one after the fact unless the operating system wrote down what happened. This unit is the bridge between "I use Windows" and "I can read Windows".

It has two halves that meet in the middle. The first half is the operating system itself: how it is put together, where it keeps its settings, how programs run, and where it records events. The second half is what a security team does with that record: a Security Operations Centre watching a Security Information and Event Management platform, pulling logs off hundreds or thousands of machines, correlating them, and hunting for the quiet signs of an intruder. In the middle sits the attacker, because you only understand why a log matters once you have seen the technique it catches.

Did you know that in most real intrusions the attacker's own tools are barely used? A common pattern is "living off the land", where the intruder uses the utilities already built into Windows (PowerShell, the task scheduler, WMI, signed system binaries) precisely because those tools are trusted and blend into normal activity. That is the whole argument for this unit in one sentence: if the attacker is using Windows against you, you had better know Windows better than they do.

Windows runs code in two privilege worlds. User mode is where applications live; each process gets its own private virtual address space and cannot reach into another process or into the operating system directly. Kernel mode is where the core of the operating system and device drivers run, with full access to hardware and memory. The boundary between the two is crossed through controlled system calls. This split is a security boundary: a bug in a user-mode application should not be able to bring down the machine, and code that wants the deepest access has to get into the kernel, which is exactly why kernel-level malware and malicious drivers are treated so seriously.

A handful of terms recur throughout the unit, so it helps to fix them early:

Process: a running instance of a program, with its own memory space, one or more threads of execution, a security token that says who it is running as, and a set of handles to files and other resources.

Thread: the unit of execution inside a process; a process always has at least one.

Service: a background process managed by the Service Control Manager, usually started at boot without a user logged on. Many Windows security and networking functions are services.

Dynamic-link library (DLL): a file of shared code that processes load at run time. Because programs load DLLs by name and path, tricking a program into loading a malicious DLL ("DLL hijacking" or "side-loading") is a common attack technique.

Handle: a reference a process holds to a resource such as a file, registry key or another process. The list of handles a process holds is often revealing during an investigation.

The boot chain matters because it is the first thing an attacker wants to subvert and the first thing a defender wants to trust. On a modern Windows 11 machine the firmware runs in UEFI mode, Secure Boot checks that each stage of the early boot is signed by a trusted key before it runs, the Trusted Platform Module (TPM) records measurements of what loaded, and only then does the Windows kernel start. If malware could insert itself before the operating system loads (a "bootkit"), no amount of in-Windows defence would see it, which is why the hardware root of trust described later in these notes is not an optional extra.

flowchart LR
  UEFI["UEFI firmware"] --> SB["Secure Boot: verify signatures"]
  SB --> TPM["TPM measures each stage"]
  TPM --> Kernel["Windows kernel loads"]
  Kernel --> Services["Services and user session start"]
  Services --> Apps["User-mode applications"]

Windows stores files on NTFS, a journaling file system that records changes so it can recover after a crash. For a defender NTFS carries several features worth knowing. Every file and folder has a security descriptor holding an access control list, so permissions are attached to the object rather than remembered separately. NTFS keeps timestamps for creation, modification and last access, and attackers sometimes alter these ("timestomping") to make a malicious file blend in with system files, which is why investigators compare timestamps across sources rather than trusting one.

Alternate data streams are an NTFS feature with a security history. A file can carry hidden additional streams of data beyond its main content; the main content is the stream you see, but data tucked into a named stream does not show in a normal directory listing. Windows itself uses one benign stream, "Zone.Identifier", to mark files downloaded from the internet, and that mark is what SmartScreen and Office read to decide a file is from an untrusted zone. Attackers have historically hidden payloads in alternate data streams, so the technique cuts both ways.

The executable format matters because so much of Windows security is about deciding whether a given executable should be trusted. Windows programs use the Portable Executable (PE) format, the structure shared by .exe, .dll and .sys files. A PE file has headers that describe how it should be loaded, a list of the DLLs and functions it imports, and sections for code and data. Two things a defender takes from this: the import table hints at what a program can do (a program importing network and cryptography functions but claiming to be a text editor is worth a second look), and a PE file can be signed with a digital certificate so the operating system can check it came from a known publisher and has not been altered. Code signing and the certificate trust behind it are the backbone of features such as Smart App Control and driver blocklisting later in these notes.

The registry is a hierarchical database that holds most of the configuration for the operating system, its services and its applications, and much of the per-user environment. For a defender it is both a rich source of evidence and a favourite hiding place, so it earns its own section.

The registry is organised into root keys, called hives. The two you will meet constantly are HKEY_LOCAL_MACHINE (HKLM), which holds machine-wide settings that apply to everyone, and HKEY_CURRENT_USER (HKCU), which holds settings for the user who is signed in. Underneath these sit keys (like folders) and values (the actual settings, each with a name, a type and data). The hives are backed by files on disk under C:\Windows\System32\config and in each user's profile, which is why registry contents can be examined during forensics even on a machine that is switched off.

Why does an attacker care about the registry? Persistence. When malware wants to survive a reboot, it needs Windows to launch it automatically, and the registry is full of places that do exactly that. The best known are the "Run" and "RunOnce" keys:

• HKCU\Software\Microsoft\Windows\CurrentVersion\Run and the HKLM equivalent launch a program every time the user (or any user) signs in.
• Services are defined under HKLM\SYSTEM\CurrentControlSet\Services, so a malicious service is a registry change as much as a file on disk.
• Many other keys can trigger code, from shell extensions to image file execution options.

Because there are dozens of these locations, defenders rarely check them by hand. The Sysinternals tool Autoruns enumerates the full set of auto-start locations at once and lets you filter out the signed Microsoft entries, so what remains is the short list worth examining. When you meet threat hunting later, "unusual auto-start entry" is one of the most productive things to hunt for.

If the registry is where persistence hides, execution is where an attack becomes visible. Three mechanisms start code on Windows, and all three are watched closely by defenders.

Ordinary process creation is the first. Every time a program runs, a process is created with a parent (the process that launched it). Parent and child relationships are one of the strongest signals in detection, because normal software launches predictable children and malware often does not. Microsoft Word spawning winword.exe is unremarkable; Word spawning PowerShell, which then spawns cmd.exe, which reaches out to the network, is the shape of a phishing document detonating. Windows can be configured to log every process creation as event ID 4688, optionally including the full command line, and that single log source underpins a large share of endpoint detection.

Services are the second. A service runs in the background under a service account, often with high privilege, and starts without anyone logged on. That makes services attractive for persistence and for running with SYSTEM rights. The installation of a new service is logged (event ID 7045 in the System log), and a new, oddly named service is a classic indicator of compromise.

Scheduled tasks are the third. The Task Scheduler runs programs at set times or on triggers such as logon or an idle period. It is entirely legitimate and heavily used by Windows itself, which is what makes a malicious scheduled task effective camouflage. Task creation and changes are recorded in a dedicated log, and hunting for tasks that run scripts from unusual locations is routine.

Update, current as at August 2026. Command-line process auditing (the part of event 4688 that records the full command line) is off by default and has to be enabled through Group Policy or a device management policy. Turning it on is one of the highest-value logging changes an organisation can make, because so much modern attacker activity is script and command driven; the Australian Signals Directorate's hardening guidance for Microsoft Windows recommends enabling command-line process creation logging for this reason.

Windows keeps a running record of what happens in the Windows Event Log, and reading it is the core practical skill of this unit. The classic view is Event Viewer, but the same records can be queried with PowerShell (Get-WinEvent) and, more importantly, shipped off the machine to a SIEM.

Logs are organised into channels. The three original ones are Application, System and Security, and they are still where much of the value sits. The Application log holds messages from applications; the System log holds messages from the operating system and drivers, including that new-service event; and the Security log holds audit records; logons, privilege use, account changes and object access, when auditing is switched on. Beyond these, Windows has hundreds of "Applications and Services" logs that individual components write to, which is where you find, for example, PowerShell script-block logging and the Windows Defender operational log.

Each event has an ID that identifies the kind of event, a source, a level (information, warning, error) and a body. Learning a handful of security-relevant IDs pays off quickly:

• 4624 is a successful logon, and its logon type tells you how: type 2 is interactive at the keyboard, type 3 is over the network, type 10 is Remote Desktop.
• 4625 is a failed logon; a burst of these against one account is a password-guessing attempt, and the same failure spread thinly across many accounts is password spraying.
• 4672 records that an account signed in with administrator-equivalent privileges.
• 4688 is process creation, as above.
• 4720 is the creation of a user account, and 4732 is a member being added to a security-enabled group; both are worth watching on servers.
• 1102 records that the Security log was cleared, which a careful attacker does to cover their tracks and which should itself raise an alarm.

Did you know that clearing the logs is, ironically, one of the noisiest things an intruder can do? A cleared Security log generates event 1102, and if logs are being forwarded off the machine in real time the record is already gone from the attacker's reach. That is the single strongest argument for getting logs off the endpoint quickly, which is the collection problem the second half of this unit solves.

A limitation to hold onto: logs only exist if the relevant auditing is turned on, and they only help if they are kept long enough and somewhere the attacker cannot reach. Default Windows auditing captures some of this but not all; enabling logon auditing, process-creation auditing with command lines, and PowerShell script-block logging is part of turning a fresh Windows install into something a defender can actually watch.

Windows Management Instrumentation (WMI) is Windows' built-in framework for querying and managing the system. Through WMI you can ask a machine almost anything about itself (its hardware, running processes, installed software, services, event logs) and you can act on it (start a process, change a setting) locally or across the network. It is the plumbing behind a great deal of enterprise administration and monitoring.

For a defender WMI is a double-edged tool. On the useful side, it is an excellent way to collect state from many machines and to build detections; a SIEM or management platform often reads WMI under the hood. On the dangerous side, WMI is a favourite of "living off the land" attackers. It can run code, it can subscribe to events so that an action fires automatically when a condition is met (a technique used for stealthy persistence, since nothing is written to the usual auto-start locations), and it can be driven remotely for lateral movement. Because WMI is a trusted part of Windows, this activity blends in unless you are logging for it specifically, which is one more reason the deeper instrumentation in the next section matters.

Update, current as at August 2026. The old command-line tool wmic.exe is deprecated and is being removed from Windows as an optional feature; WMI itself remains fully supported. Current practice is to use the PowerShell CIM cmdlets, such as Get-CimInstance, in place of the retired wmic command. Since attackers also used wmic.exe, its removal quietly closes one living-off-the-land path, though the underlying WMI capabilities they abused are still present and still need to be watched.

The default Windows logs are good, but they miss a great deal that a defender wants: they do not, by default, record every network connection a process makes, every file it drops, or the hash of every program that runs. System Monitor, universally called Sysmon, fills that gap. Sysmon is a tool from the Sysinternals suite that installs as a service and driver and writes rich, high-signal events into a dedicated log, guided by a configuration file that says what to record and what to ignore.

The events Sysmon adds are exactly the ones detection engineers reach for:

• Process creation with the command line, the parent process, and the SHA-256 hash of the executable (event ID 1).
• Network connections made by a process, tied back to the process that made them (event ID 3).
• Image loads, so you can catch a DLL being loaded from an unusual place (event ID 7).
• File creation, including the download mark on files (event ID 11).
• DNS queries made by a process (event ID 22), which is one of the best ways to catch malware calling home.
• Process tampering and remote-thread creation, the sort of memory manipulation that code injection uses (events for process access, remote threads and process tampering).

A well-tuned Sysmon configuration, paired with a SIEM, turns a Windows fleet from nearly opaque into highly observable. The catch has always been deployment: Sysmon was a separate download that had to be installed and kept updated on every machine.

Update, current as at August 2026. Native Sysmon has moved from announcement to rollout. Microsoft first said in November 2025 that Sysmon functionality would come natively to Windows, delivered through Windows Update rather than as a separate Sysinternals download; by early 2026 it was appearing in Windows 11 preview (Insider) builds, targeted at Windows 11 and Windows Server 2026 (Microsoft Windows IT Pro blog, "Native Sysmon functionality coming to Windows", 18 November 2025; BleepingComputer, "Microsoft rolls out native Windows 11 Sysmon security monitoring", 4 February 2026). In the native model Sysmon is turned on as a Windows optional feature (through Settings, or Dism /Online /Enable-Feature /FeatureName:Sysmon) and then configured with the familiar command, for example sysmon -i for basic monitoring or sysmon -i <config file> for a full configuration, with events and filtering matching the standalone tool; any existing standalone Sysmon has to be uninstalled first. As at August 2026 it is still disabled by default and rolling out through the release channels, so it is not yet on every machine; but the direction is clear, and the deployment and patching burden that kept many organisations from running Sysmon at all is going away. Confirm the current availability on Microsoft Learn before relying on it in a design.

The unit asks you to examine the system administration tools, and the thread running through all of them is privilege. Windows separates standard users from administrators, and the gap between the two is the single most important security boundary on the machine. A standard user can run applications and change their own settings; an administrator can change the system, install drivers, read other users' data and, in effect, do anything. Restricting who holds administrator rights, and limiting when those rights are actually used, does more to contain an attack than almost any other single control.

User Account Control (UAC) is the mechanism most people meet. Even when you are an administrator, your programs run with a standard-user token until something needs elevation, at which point the consent prompt appears and, if you agree, a second, fully privileged token is used. UAC is not a hard security boundary on its own, but it keeps routine work at low privilege and makes elevation a deliberate act.

The administrator's toolkit is worth knowing by name, because attackers use the same tools:

• PowerShell is the modern automation and administration shell; it can manage almost every part of Windows and reach across the network. Its power is why script-block logging and constrained language mode exist, and why "encoded PowerShell command launched by Office" is a detection staple.
• The Microsoft Management Console hosts the graphical snap-ins for services, event logs, users and group policy.
• The Sysinternals suite (Process Explorer, Process Monitor, Autoruns, Sysmon and others) is the investigator's field kit for seeing what is really running.
• Windows Admin Center and, in managed fleets, Microsoft Intune provide the same control at scale from a central console.

Update, current as at August 2026. Windows 11 version 24H2 introduced Administrator protection, a feature that lets an administrator run with a standard token by default and elevate to a temporary, isolated administrator identity only for the specific task that needs it, using Windows Hello to approve. It is a stronger version of the idea behind UAC and narrows the window in which full administrator rights are active. Alongside it, the Windows Local Administrator Password Solution (LAPS) is now built into Windows; it automatically sets a unique, rotating password for the local administrator account on each machine and escrows it centrally, which stops the old attack of one shared local-admin password unlocking every machine in the building.

You cannot recognise an attack you have never seen the shape of, so this section walks a typical intrusion and names the Windows features that see each step. The stages line up with the MITRE ATT&CK knowledge base, the widely used catalogue of real-world attacker tactics and techniques that defenders use as a shared language (attack.mitre.org).

Initial access usually arrives as a person, not a firewall breach. A phishing email carries a document or a link; the user opens it; a macro or a script runs. The signal here is the process tree: an Office application giving birth to a script interpreter.

Execution follows. The script rarely does the damage itself; it downloads or unpacks the next stage. Living off the land is the norm, so the running programs are trusted Windows tools behaving untrustworthily. Process-creation logging with command lines, and Sysmon's hashes and network events, are what expose this.

Persistence is set next, so the foothold survives a reboot. This is the registry Run key, the new service, the scheduled task or the WMI event subscription from earlier sections. Autoruns and the matching event IDs are the counter.

Privilege escalation and credential theft come when the attacker wants more than the first user's rights. The classic move is to read credentials out of the memory of the LSASS process, the part of Windows that holds secrets for signed-in users; the tool Mimikatz made this famous. Access to LSASS memory is exactly what Credential Guard, described next, is built to deny.

Lateral movement spreads the intrusion to other machines, using stolen credentials over network logons, remote WMI or remote PowerShell. Network-type logon events (4624 type 3) across many machines from one account, at odd hours, are the trail.

Actions on the objective are the point of it all: stealing data, or, in a ransomware case, deleting the backups and encrypting the files. By this stage, if nothing earlier was caught, the logs are the record you investigate afterwards, which is why getting them off the machine in real time matters so much.

flowchart TD
  IA["Initial access: phishing document"] --> EX["Execution: script and living-off-the-land tools"]
  EX --> PE["Persistence: Run key, service, scheduled task, WMI"]
  PE --> CT["Credential theft: read LSASS memory"]
  CT --> LM["Lateral movement: stolen credentials, remote WMI or PowerShell"]
  LM --> AO["Actions on objective: data theft or ransomware"]

The reason to learn the chain is that defence is cheapest early. Stopping the phishing document from spawning PowerShell is easier than chasing an attacker who already has domain credentials, and every feature in the next section is really an attempt to break one of these links.

Windows ships with a layered set of security features, and the unit's "implement mitigation strategies" outcome is largely about knowing what each layer does and turning it on. They are grouped here by the attack stage they interrupt rather than numbered, because in practice you deploy several at once.

Stopping bad code from running. Microsoft Defender Antivirus is the built-in, always-on protection against malware, backed by cloud-delivered detection. Attack surface reduction (ASR) rules are targeted controls that block common attack behaviours, such as Office applications creating child processes or scripts running downloaded executables; they cut directly across the phishing chain above. Microsoft Defender SmartScreen checks downloaded files and websites against reputation data and warns on the untrusted. Smart App Control, on clean installs of Windows 11, goes further and blocks apps that are not signed or not known-good, using the same code-signing trust discussed earlier. For organisations that need strict control, App Control for Business (formerly Windows Defender Application Control) enforces an allow-list of exactly which applications and drivers may run.

Protecting credentials. Credential Guard uses virtualisation-based security (VBS) to isolate the secrets that LSASS holds inside a protected container the ordinary operating system cannot read, so the Mimikatz-style memory read fails even on an administrator-controlled machine. Local Security Authority protection hardens the LSASS process against tampering. Remote Credential Guard protects credentials during Remote Desktop sessions.

Protecting data at rest. BitLocker encrypts the whole drive so that a lost or stolen laptop does not surrender its data, binding the encryption key to the TPM so the disk cannot simply be moved to another machine. BitLocker To Go extends this to removable drives.

Trusting the machine itself. The TPM is a hardware chip that stores keys and boot measurements; Secure Boot and Trusted Boot use it to ensure only signed, unmodified code runs during start-up; and on newer devices the Microsoft Pluton security processor builds the root of trust into the main chip. Windows 11's hardware requirements, TPM 2.0 in particular, exist to make these protections the baseline rather than the exception.

Replacing the password. Windows Hello lets a user sign in with a PIN tied to the device or with biometrics (face or fingerprint), where the secret never leaves the machine and cannot be phished or replayed the way a password can. Windows Hello for Business extends this to the organisation with keys backed by the TPM.

The point is not to memorise a catalogue but to see the pattern: each feature denies the attacker one of the steps in the previous section. A machine with ASR rules on, Credential Guard enabled, BitLocker encrypting the disk, Smart App Control blocking unknown binaries and Windows Hello replacing the password is a much harder target, and none of these is an add-on purchase; they are features of Windows waiting to be switched on.

The second half of the unit shifts from one machine to the whole organisation, and the place that watches the whole organisation is the Security Operations Centre. A SOC is the team, process and tooling responsible for monitoring, detecting, investigating and responding to security events, usually around the clock. It is as much an operating model as a room.

SOCs come in a few shapes, and the unit asks you to know the types along two lines. The first is who runs it. An in-house SOC is staffed and run by the organisation itself, giving the most control and the deepest knowledge of the environment, at the highest cost. A managed SOC, delivered by a managed security service provider or as "SOC as a service", outsources the monitoring to a specialist, which suits organisations without the scale to staff their own; the trade-off is that an outside team knows your environment less intimately. A co-managed SOC splits the work, with an in-house team handling business hours and context and a provider covering nights and weekends or surge events. Larger and government bodies sometimes run a fusion centre that brings security operations together with fraud, threat intelligence and other functions.

The second line is where the SOC's tooling lives, and the unit names three models here. A physical SOC keeps all its devices and infrastructure on the organisation's own premises. A virtual (or cloud) SOC runs its tooling in the cloud with a distributed team and no dedicated room. A hybrid SOC combines the two, keeping some capability on-premises and some in the cloud. The two framings overlap in practice, and current practice leans heavily towards virtual and hybrid, precisely because the SIEM itself has moved to the cloud, as the Sentinel section below describes.

Inside the SOC the work is often described in tiers, though good teams treat these as functions rather than a rigid ladder. Frontline analysts triage the incoming alerts and handle the routine ones. More experienced analysts investigate the alerts that survive triage, piecing together what happened across multiple machines and logs. Threat hunters and incident responders go looking for what the alerts missed and lead the response when something real is found. Supporting all of them are the detection engineers who write and tune the rules, because a SOC drowning in false alarms is a SOC that misses the real one. That failure has a name worth remembering: alert fatigue, the state where so many low-value alerts arrive that analysts stop trusting them, and it is a genuine risk the tooling in the next sections is meant to reduce.

A Security Information and Event Management platform, a SIEM, is the system a SOC watches. Its job is to collect logs and events from across the environment (Windows machines, servers, firewalls, cloud services, identity systems), bring them into one place in a common form, and let analysts search, correlate and alert on them. Without a SIEM, the logs from the first half of this unit sit stranded on thousands of machines where no one can see them together; with one, a logon failure on a laptop, a new service on a server and an odd DNS query can be recognised as one connected story.

Two capabilities are the heart of it. Correlation is the ability to join events from different sources by shared fields such as a user name, an IP address or a time window, so that a pattern invisible in any single log becomes a single alert. Detection rules, often called analytics or use cases, are the saved queries that fire when a known-bad pattern appears; "one account failing to log on to twenty machines in five minutes, then succeeding" is a rule that no single machine could ever raise on its own.

The SIEMs you meet by name include Splunk, the open-source Elastic Stack (often called ELK, for Elasticsearch, Logstash and Kibana), Wazuh (open-source, and the platform this unit's own labs install), IBM QRadar, and the cloud-native Microsoft Sentinel discussed below. Each has its own query language, but they express the same idea: filter the events, then aggregate them to surface a pattern. A Splunk search such as sourcetype=WinEventLog:Security EventCode=4625 | stats count by Account_Name counts failed logons per account; the equivalent in Sentinel's Kusto Query Language is SecurityEvent | where EventID == 4625 | summarize count() by Account. Learning to read and write one of these queries is the transferable skill; the syntax differs between products, the reasoning does not.

A SIEM's value is limited by two things: what you feed it and how well the rules are tuned. Feed it too little and the story has gaps; feed it everything with no tuning and analysts drown in noise and cost. Deciding which log sources matter, mapping them to the attacks you care about (MITRE ATT&CK is the usual map), and continuously tuning the rules is ongoing work, not a one-time install. This is why "methods to collect data from multiple end points into a SIEM" is called out in the unit as its own outcome; getting the data in, cleanly and at the right volume, is half the battle.

There are two broad ways to move Windows events off the endpoint and into a SIEM, and the unit's data-collection outcome is really about understanding the choice.

The native Windows method is Windows Event Forwarding (WEF). Windows can forward selected events over the network to a central Windows Event Collector using the built-in WinRM service, configured through Group Policy, with no third-party software on the endpoint. Machines are "source" computers, one or more "collector" computers subscribe to the events they want, and the collector then feeds the SIEM. WEF scales well and costs nothing extra, which is why the Australian Signals Directorate has long documented a recommended set of events to forward.

The agent method installs a small collection agent on each machine that reads the local logs (and often Sysmon) and streams them directly to the SIEM. Modern platforms use this: Microsoft's Azure Monitor Agent feeds Microsoft Sentinel, and endpoint detection and response agents such as Microsoft Defender for Endpoint both protect the machine and send rich telemetry to the cloud. Agents can collect more than plain event forwarding and can act on the machine, but they are software to deploy and maintain.

flowchart LR
  subgraph Endpoints
    W1["Windows endpoint<br/>logs + Sysmon"]
    W2["Windows server<br/>logs + Sysmon"]
    FW["Firewall / network"]
  end
  W1 --> COL["Collector: WEF or agent"]
  W2 --> COL
  FW --> COL
  COL --> SIEM["SIEM: normalise, correlate, alert"]
  SIEM --> SOC["SOC analysts and hunters"]

In practice organisations use both: event forwarding for broad, cheap coverage of Windows security events, and agents where they need endpoint detection and response or richer data. Either way the design questions are the same; which sources, which events, how much volume, how long to retain, and whether the collection survives an attacker who has admin rights on the endpoint.

The training package predates the biggest change in this area, so this is squarely a beyond-TAFE section. The SIEM has moved to the cloud. Microsoft Sentinel is a cloud-native SIEM: instead of running collector servers in your own data centre, you send logs to a service that scales elastically, and you write detections and hunts in Kusto Query Language (KQL), a readable query language built for large volumes of log data. Data connectors pull in Windows events, Microsoft 365 and Entra ID sign-ins, firewall logs and hundreds of other sources, and built-in analytics rules mapped to MITRE ATT&CK provide a starting detection set.

The more recent shift is the merging of SIEM and endpoint detection into one console. Microsoft has been moving the Sentinel experience into the Microsoft Defender portal, so that cloud SIEM (Sentinel) and extended detection and response (Defender XDR, which spans endpoints, identity, email and cloud apps) are used together in a single "unified security operations" surface rather than two separate portals. Update, current as at August 2026: the unified experience in the Defender portal is now the default, and Microsoft is retiring the standalone Sentinel experience in the Azure portal. The cut-over date has been revised more than once (the timeline was updated again in January 2026), and the retirement is scheduled through 2026, so confirm the current date on Microsoft Learn rather than trusting a fixed figure. The practical effect for a SOC analyst is one place to see an alert, pull in the related raw logs, and follow the incident across every layer. Microsoft has also begun describing Sentinel as a platform for the "agentic era", meaning it is being built to support AI agents that assist and, in places, act (Microsoft Security blog, 30 September 2025).

For a student the lesson is not to memorise a product roadmap, which will keep moving, but to understand the direction: the SIEM you learn about as a boxed product in the syllabus is now a cloud service, increasingly fused with endpoint detection, and increasingly driven by queries and AI rather than by clicking through a console. If you can read a Windows event and write a simple KQL query that finds it across a fleet, you have the transferable skill.

A SIEM with detection rules catches the known. Threat hunting looks for the unknown: the intruder who slipped past the rules and is sitting quietly in the environment. The unit lists threat hunting as required knowledge, and the mindset is worth stating plainly. Hunting is proactive and hypothesis-driven; instead of waiting for an alert, the hunter starts from an idea about how an attacker might behave and goes looking in the data for evidence of it.

A hunt usually starts with a hypothesis grounded in attacker behaviour, often taken from MITRE ATT&CK; for example, "an attacker in our environment would use a scheduled task to persist, so let me find scheduled tasks created in the last week that run scripts from user-writable folders". The hunter then queries the collected data (KQL over Sentinel, or the SIEM's own search) to test it, examines what comes back, and either finds something worth escalating or refines the hypothesis and hunts again. Anything the hunt discovers that should have been caught automatically becomes a new detection rule, so hunting steadily improves the SIEM.

A useful idea to carry from this is the "pyramid of pain", which ranks the indicators you can hunt on by how much they cost the attacker to change. Hashes and IP addresses are trivial for an attacker to swap, so detections built on them are brittle; tools and, at the top, the attacker's tactics, techniques and procedures are expensive to change, so detections built on behaviour last far longer. This is why modern hunting and detection lean on behaviour (the process tree, the sequence of actions) rather than on lists of known-bad files, and why the deep telemetry from Sysmon and command-line logging matters so much: it is behavioural data.

Another beyond-TAFE addition, because it is changing SOC work as these notes are written. Microsoft Security Copilot is an AI assistant for security teams that plugs into the Defender portal, Sentinel, Intune and Entra. In its assistive form it summarises an incident in plain language, explains a suspicious script, drafts a KQL query from a question asked in English, and speeds up the report-writing that consumes analyst time. Microsoft has extended it with "agents", semi-autonomous helpers that take on repetitive tasks such as triaging phishing reports or sorting alerts, escalating only what needs a human (Microsoft Security blog, "Microsoft unveils Microsoft Security Copilot agents", 24 March 2025; and the 18 November 2025 announcement bringing Security Copilot agents to Microsoft 365 E5).

The honest framing for a student is that this helps most with the volume problem, the alert fatigue described earlier, and least with judgement. It can draft the query, but you need to know a good query from a bad one; it can summarise the incident, but you are accountable for the response. Treated as a capable assistant that a knowledgeable analyst supervises, it is a real productivity gain; treated as a replacement for understanding Windows, it is a way to be confidently wrong at speed. The Windows knowledge in the first half of this unit is what lets you use the AI well rather than be led by it.

The unit's final outcome is to implement mitigation strategies, and in an Australian context the natural framework is the Australian Signals Directorate's Essential Eight, a prioritised set of mitigation strategies published on cyber.gov.au and maintained by the Australian Cyber Security Centre. Most of the eight map directly onto Windows features covered above, which is a tidy way to tie the unit together:

• Application control maps to App Control for Business and Smart App Control.
• Patching applications and patching operating systems map to Windows Update and update management.
• Configuring Microsoft Office macro settings and user application hardening map to ASR rules and Office policy.
• Restricting administrative privileges maps to standard-user accounts, UAC, Administrator protection and LAPS.
• Multi-factor authentication maps to Windows Hello for Business and Entra ID.
• Regular backups map to a tested backup regime, the control that most often decides whether a ransomware incident is a bad week or a closed business.

The Essential Eight also defines maturity levels, from partial implementation up to a well-resourced adversary-resistant state, so an organisation can measure where it stands rather than treating security as simply on or off. For this unit the value is the mental model: mitigation is layered, prioritised and measurable, and nearly every layer is a Windows feature you can now name and enable.

Two of the unit's outcomes (exploit Windows vulnerabilities well enough to understand them, and implement mitigations) are best learned by doing, and both need a lab that is isolated from anything real. The safe pattern is virtual machines on an isolated virtual network. A hypervisor such as VirtualBox (free) or VMware Workstation runs guest machines that you can snapshot before an experiment and roll back after, so a deliberately infected machine is discarded in seconds. Keep the lab network isolated from your home or work network, and never carry live malware onto a machine that matters.

A realistic Windows security lab has a Windows 11 machine to defend and instrument (with Sysmon and auditing turned on), optionally a Windows Server acting as a domain controller so you can see logons and lateral movement across machines, and a place for the logs to land. For the SIEM half, Microsoft offers time-limited free trials of Sentinel, and there are free, self-hostable SIEMs to practise on, notably Splunk Free, the Elastic Stack (ELK) and Wazuh, the last being the one this unit's own labs install. Purpose-built training platforms are the low-friction way in: TryHackMe (tryhackme.com) and Hack The Box (hackthebox.com) have guided Windows security, Sysmon, SIEM and threat-hunting rooms that provide the vulnerable machines for you, so you can practise reading the logs of an attack without building the attack yourself. Microsoft Learn (learn.microsoft.com) carries the authoritative, current documentation for every Windows feature named in these notes and is the right place to confirm a detail before relying on it.

These notes were built for personal professional development from current, authoritative sources rather than transcribed from the training package. The unit scope block draws on the Victoria University published unit page for VU23225 (vu.edu.au), read 22 August 2026, which carries a page-modified date of 29 August 2024, cross-checked against the reproduced unit overview and learning outcomes on cybersecureworld.net. The Windows feature material is grounded in Microsoft Learn (learn.microsoft.com), including the Windows 11 security book feature index (last updated 18 November 2025) and its pages on the event log, the registry, Windows Management Instrumentation, Sysmon, BitLocker, Credential Guard and virtualisation-based security, Windows Hello, Smart App Control and App Control for Business, Attack surface reduction rules, Administrator protection and the Windows Local Administrator Password Solution. Current-practice updates are dated to their sources: native Sysmon in Windows from the Microsoft Windows IT Pro blog "Native Sysmon functionality coming to Windows" (18 November 2025) and BleepingComputer's rollout report "Microsoft rolls out native Windows 11 Sysmon security monitoring" (4 February 2026); the Microsoft Sentinel move into the Defender portal and the retirement of the Azure-portal Sentinel experience through 2026 from the Microsoft Sentinel blog transition-timeline update of 30 January 2026 and Microsoft Learn's unified security operations documentation, read August 2026; Microsoft Security Copilot agents from the Microsoft Security blog of 24 March 2025 and 18 November 2025; Windows 11 version 25H2 released 30 September 2025, Windows 10 end of support on 14 October 2025, and Windows 11 version 26H2 reaching the Release Preview channel on 27 August 2026 with general availability expected later in 2026, from Microsoft Support, the Windows Insider blog and the technology press. The mitigation framework is the Australian Signals Directorate's Essential Eight on cyber.gov.au, and the attacker-behaviour model is the MITRE ATT&CK knowledge base (attack.mitre.org). Lab and practice references point to the projects' own sites: virtualbox.org, vmware.com, tryhackme.com and hackthebox.com.