Module 2: Intermediate | Day 3 only | Complete instructor-and-learner manual

Edition: 1 November 2026
Course: Microsoft Sentinel Technical Training — 5-day progressive curriculum
This document: Day 3 only; prerequisite: successful completion of Foundations (Days 1–2)
Primary user interface: Microsoft Defender portal (https://security.microsoft.com)
Format: Day-wise, hands-on, step-by-step; no hourly timetable
Scope: I01–I14, the 14 new Intermediate competencies from the supplied agenda
Lab safety: Authorized, isolated Azure environment and fictional data only

READ FIRST — verification, boundaries, and a credible PASS result

What has been checked: The procedures and navigation paths in this manual were researched against Microsoft Learn pages available on 1 November 2026. Source-specific links are supplied beside each lab, and the source register is at the end. This document has been structurally and internally checked for syllabus coverage, complete examples, Markdown formatting, and evidence checkpoints.

What cannot honestly be claimed: This manual was not run against your Azure tenant. The instructor must validate permissions, portal labels, region, features, data connector prerequisites, Linux distribution, actual field mappings, analytics rule scheduling, and billed usage in the assigned lab. A command appearing in the document is not evidence that it succeeded in your tenant. Never mark a cloud lab PASS without the observable evidence specified below. Some features change by tenant and license, and some remain in preview.

Do not use production identities, internet-routable test endpoints, actual threat infrastructure, active containment, or unapproved log ingestion. 198.51.100.23 and 203.0.113.10 are documentation-only addresses from TEST-NET ranges; they are labels inside fictitious records, not destinations to contact. Do not expose TCP/UDP 514 to the public internet.

Day 3 complete means: Learner proves a second telemetry path (or an instructor-approved evidence-only substitution), correlates records from two relevant sources, enriches the result, publishes and tunes a controlled scheduled detection, configures low-risk incident-metadata automation, visualizes source quality, diagnoses failures, and produces an auditable final evidence pack. To earn the full operational PASS, the real connectors, rule, incident, and automation must actually produce the expected results. The offline synthetic track can award conceptual credit but not a claim of live deployment.

Source freshness and critical corrections to older tutorials

Portal: Microsoft says its Azure-portal Sentinel experience will no longer be supported after 31 March 2027. Teach the Defender portal first; Azure portal remains useful for Azure VM, network, agent, DCR and resource administration. [R01]
Collection: Use Syslog via AMA and Common Event Format (CEF) via AMA, with an explicit Data Collection Rule (DCR) and association. Avoid the retired legacy Log Analytics agent patterns. Facility and severity choices govern what enters the destination. [R02], [R03]
Threat intelligence: New indicators belong in ThreatIntelIndicators (and STIX objects in ThreatIntelObjects), not the formerly ingested ThreatIntelligenceIndicator table. The legacy TIP/Graph indicator connector was announced for discontinuation in 2026; do not teach it as a new onboarding route. [R10], [R11]
UEBA: Its enabling roles and supported sources must be checked. The current Defender experience has Settings > Microsoft Sentinel > UEBA, with workspace anomaly detection configured separately where required. Activating UEBA creates additional telemetry and possible storage charges. [R12]
Analytics: Scheduled rules must return TimeGenerated from source data. Enabling a rule does not automatically prove an alert or incident exists. Their evaluation can be affected by ingestion delay, lookback, result thresholds, grouping, and Defender integration. [R13], [R14]
Automation: Day 3 uses incident-metadata actions (e.g., tag, owner, status) only; Logic Apps/playbooks, approval gates, and disruptive remediation are Day 4 topics. Available trigger/action combinations differ; alert-creation rules do not support the same metadata actions as incident-creation rules. [R15]
Workbooks: Azure Monitor workbooks are workspace-associated Azure resources. Creation requires workbook-write permissions; Defender has its own viewer and some visualizations may route to Azure. [R16]

5W1H learning contract for Day 3

Lens	Day 3 answer the learner must demonstrate
What	AMA, Syslog, CEF, DCR, KQL correlation, watchlist, threat indicators, UEBA, custom detections, automation rules, workbooks
Why	Broaden coverage, improve evidential confidence, add asset/business context, reduce unnecessary alerts, standardize safe SOC case handling
Who	Platform/collector owner, connector engineer, detection author, watchlist steward, SOC analyst, SOC lead, approval authority
When	Ingest on agreed source need; correlate when separate signals share defensible keys; tune only with observed examples; automate after scoping
Where	Linux forwarding VM, DCR/agent, Log Analytics workspace, Microsoft Sentinel configuration, Defender incident queue, workbook resource group
How	Authorized source → safe Linux test event → AMA+DCR → `Syslog`/`CommonSecurityLog` → KQL + watchlist → detection → incident automation → workbook + evidence

Lab architecture (the arrows matter)

configurationLinux demonstration eventsrsyslog or syslog-ngApproved firewall / CEF demoAzure Monitor AgentData Collection Rule + VM associationLog Analytics workspaceSyslog tableCommonSecurityLog tableTime-bounded KQL correlationSentinel watchlistScheduled analytics ruleDefender incidentMetadata-only automation ruleSource-health workbook

Important distinction: A synthetic query that displays two datatable() tables does not prove AMA, CEF parsing, a DCR, a stored log, or a real alert. It is a teaching fallback only. The normal path below uses real test events created on a controlled lab VM.

1. Instructor preparation (mandatory; complete before learners begin)

1.1 Continuity from Days 1–2

Keep the same fictional tenant storyline, Aster Retail. Students completed Foundations and can already identify the Microsoft Entra tenant, subscription, resource group, Sentinel-enabled Log Analytics workspace, baseline KQL, basic built-in detection, and incident-triage workflow. Do not re-teach those labs. Verify their artifacts and move immediately to the new Intermediate tasks.

Scenario: A privileged account appears in a Linux audit-like application event, followed by a firewall denial from the same test source address. The SOC must correlate and interpret these signals, verify whether the identity is high value, classify a synthetic finding, create a tuned detector, assign the case safely, and visualize pipeline quality.

Scenario limitations: A shared IP plus a time window is not proof of a user’s identity. NAT, proxies, shared hosts, deliberate falsification, timing skew, and field parsing can create false links. The lab deliberately asks students to tighten correlation with an account field where the CEF parser supplies one.

1.2 Choose and record the delivery track

Track	What is available	Can demonstrate	Can claim
A — full Azure lab (recommended)	Approved subscription; existing Sentinel workspace; Linux VM; allowed agent/DCR/write roles	Real Syslog, optional CEF, watchlist, rule, incident, metadata automation, workbook	Full operational PASS if all evidence gates pass
B — instructor-managed shared lab	Learners receive reader access + instructor controls one collector and writes	Full evidence chain, with separately attributable learner submissions	PASS on demonstrated competencies; infrastructure steps recorded as instructor-operated
C — restricted/synthetic	Query editor only, or instructor-supplied screenshots and CSV	`datatable()` KQL, interpretation, simulated detection design, cost/risk decisions	Conceptual PASS only; not live connector/detection/automation PASS

Use A or B for a course advertised as fully hands-on. Track C must be disclosed clearly to students.

1.3 Prerequisites and role ownership

Component/action	Preflight requirement	Who verifies
Microsoft Sentinel	Existing Sentinel-enabled Log Analytics workspace from Day 1; correct tenant and workspace	Instructor
Portal	Learner can access Defender portal and the workspace-specific Sentinel experience	Instructor
Linux VM	Instructor-approved Azure Linux VM using an AMA-supported OS; `rsyslog` or `syslog-ng`; `logger`, shell, `sudo`; accessible over Bastion or approved private SSH	Infrastructure owner
Azure Arc (only for non-Azure servers)	Azure Connected Machine agent, supported configuration, connectivity	Infrastructure owner
AMA installation	Permission to install VM extension; Microsoft guidance identifies VM Contributor / Azure Connected Machine Resource Administrator or equivalent	Azure administrator
DCR creation and association	Monitoring Contributor at appropriate scope (or equivalent operations) and access to selected VM	Azure administrator
Content hub	Permission to install needed Syslog / CEF solutions and access data connectors	Sentinel administrator
Detection authoring	Microsoft Sentinel Contributor or appropriate workspace/resource-group write permissions	Sentinel administrator
Watchlist creation	Sufficient Sentinel workspace write permissions to create/manage watchlists	Sentinel administrator
Incident operations	Permitted Defender/Sentinel incident-management role, owner/team as applicable	SOC lead
Workbook	At least Workbook Contributor on the workspace resource group for writing; Workbook Reader for reading	Azure administrator
UEBA enablement (optional)	Microsoft Entra Security Administrator or equivalent plus required Azure role, no blocking workspace lock; not needed merely to read existing UEBA results	Identity/Sentinel administrator
Threat intelligence onboarding (optional)	Valid licensed/approved feed, correct connector/API, legal authority to use it	TI owner

Do not assign Owner or Tenant Global Administrator broadly just to get a lab working. Have the instructor perform privileged steps where delegated access is unavailable. Role prerequisites are not interchangeable: VM and DCR administration are Azure control-plane activities; incident analysis and rule authoring have separate RBAC boundaries. [R02], [R12], [R13], [R16]

1.4 Safe naming and configuration record

Before beginning, instructor fills this actual environment sheet:

Field	Actual value (fill before class)
Training tenant (non-secret label)	`________________`
Azure subscription (friendly name)	`________________`
Region (Log Analytics + chosen VM)	`________________`
Resource group (existing or new dedicated)	`rg-sentinel-d3-lab-<cohort>`
Workspace name (Day 1)	`________________`
Linux collector VM	`vm-sentinel-d3-<cohort>`
OS + release (`cat /etc/os-release`)	`________________`
Agent extension state	`________________`
Syslog DCR name	`dcr-sentinel-d3-syslog`
CEF DCR name (if used)	`dcr-sentinel-d3-cef`
Watchlist alias	`day3_privileged_accounts`
Rule name	`SENTINEL-D3-LAB-Privileged-Source-Correlation`
Automation name	`SENTINEL-D3-LAB-Tag-And-Assign`
Workbook name	`Sentinel D3 - Source Quality and Correlation`
Temporary owner (valid SOC user)	`________________`
Approved maximum ingestion / cost budget	`________________`
Planned cleanup owner	`________________`
Allowed lab source IPs/networks	`________________`
Source mode	`Syslog direct / Syslog+CEF / approved evidence-only`

Keep an artifact register: DCR names/IDs, extensions, solution installs, generated test marker, created analytics and automation rules, workbook, watchlist, and temporary VM. Without this register, safe cleanup is hard.

1.5 Financial, security, and data-protection gates

Confirm subscription and resource-group budget alerts, VM SKU/hourly charge, Log Analytics ingestion/retention charge, possible Sentinel pricing, and whether connector data is billable. Do not assert this is a free lab.
Use a small, shut-down-capable VM and minimal bounded test events; do not activate all facilities globally to ‘see what happens’.
Require an approved region and data residency posture. Use only fictitious data.
Prefer Bastion/private network access; do not open port 514 publicly. For localhost-injected messages, there is no need for a public network listener.
Log ingestion and DCR updates can affect data volume, noise and charges. Instructor approval required before expanding facilities/levels.
No actual account lockouts, firewall blocking, disabling identities, emailing outsiders, or Logic Apps playbooks in Day 3.
Decide cleanup before beginning: will the trainer delete only Day 3 resources, keep the Day 1–2 workspace, or remove an entire dedicated lab RG? Never delete a shared workspace by accident.

Instructor readiness checklist

[ ] Day 1/2 learner progression already passed or equivalent evidence reviewed.
[ ] Correct Sentinel workspace and selected Linux VM are documented.
[ ] VM OS is compatible with current AMA support; VM connectivity is healthy.
[ ] Agent/DCR/Content hub permissions are assigned or an instructor executor is present.
[ ] At least one route to a real connector exists; alternative track announced if not.
[ ] No production data source or public port 514 is included.
[ ] Lab budget and acceptable telemetry rate are approved.
[ ] A valid incident owner exists for automation lab.
[ ] The instructor can open Log Analytics query editor, Analytics, Automation and Workbooks.
[ ] Optional threat-intelligence and UEBA permissions/charges are separately approved.
[ ] Screenshots may capture only fictitious lab data and non-sensitive resource details.

1.6 How the learner records actual evidence

Use this template at the end of every lab. Do not replace an empty result with a guessed result.

Lab ID:
Operator / learner:
Workspace (friendly name):
UTC start/end:
Delivery track: A / B / C
Executed steps (deviations and screenshots):
Query / command run:
Actual evidence (table, result count, name, timestamp):
Expected vs observed:
Troubleshooting performed:
Instructor witness:
Verdict: PASS / PARTIAL (reason) / BLOCKED (reason) / FAIL
Created artifacts for cleanup:

The instructor owns raw screenshots and grading records. Do not place keys, tokens, secrets or privileged connection strings in evidence. Redact subscription IDs if evidence will leave the organization.

2. Navigation map and required competencies

Lab	Syllabus	Main artifact / observable result	Hands-on track
D3-L01	I01	Source-selection decision record	All
D3-L02	I02	Linux VM + AMA/DCR + Syslog evidence	A/B
D3-L03	I02–I03	CEF collector test or documented alternative; multicloud path matrix	A/B/C
D3-L04	I04	Ingestion quality evidence and data-fidelity report	A/B/C
D3-L05	I05	Reproducible KQL composition workbook / query pack	All
D3-L06	I06	Two-source time-bounded correlation with limitations	A/B/C
D3-L07	I07	Governed CSV watchlist + enriched query	A/B/C
D3-L08	I08	Indicator verification and contextual decision	All; live TI optional
D3-L09	I09	UEBA context or validated no-UEBA fallback	All; live UEBA optional
D3-L10	I10	Scheduled custom rule, alert, and incident	A/B
D3-L11	I11	Replayed positive/negative test cases; measured tuning	A/B/C
D3-L12	I12	Low-risk incident metadata automation; audit evidence	A/B
D3-L13	I13	New source-health/correlation workbook	A/B
D3-L14	I14	Multi-layer fault isolation and remediation journal	All
D3-CAP	I01–I14	Final assessment + 100-point evidence rubric	All; operational PASS only A/B

Dependency chain: L02 Syslog → L03 CEF (optional but recommended) → L04 quality → L05 KQL → L06 correlation → L07 enrichment → L10 detection → L11 tuning → L12 incident automation → L13 workbook → L14 troubleshooting → capstone. L08 and L09 add context if approved; do not block the core lab because a TI provider or licensed source is absent.

DAY 3 — INTERMEDIATE HANDS-ON LABS

D3-L01 — Choose collection patterns for a realistic security estate (I01)

Competency: Choose API, managed connector, agent-based, or syslog-forwarder intake based on source type, operational ownership, data quality, cost and compliance. Not a repeat of the Day 1 starter Microsoft connector.

Prerequisite: The learner can access the appropriate Sentinel workspace and its Data connectors listing.

Exact guided procedure

Sign in to Microsoft Defender portal at https://security.microsoft.com; ensure the intended tenant is active.
Navigate to Microsoft Sentinel > Configuration > Data connectors. Confirm the configured workspace; don’t assume a connector belongs to the workspace you intended. [R01], [R02]
Record the installed and available Syslog via AMA, Common Event Format (CEF) via AMA, and approved third-party connectors (if visible). If a connector is absent, check whether its solution must first be installed from Microsoft Sentinel > Content management > Content hub.
For each candidate source, record its transport, logs generated, destination table, authentication, upstream agent needs, owner, service/VM cost, estimated volume, and who signs off.
Build the table below, changing only the selection to suit your actual environment.

Source	Preferred intake	Destination (confirm in connector)	Limitation / acceptance criterion
Azure subscription control-plane audit	Existing Day 1 Azure Activity	`AzureActivity`	No need to reconnect for Day 3
Linux system/application syslog	Syslog via AMA + DCR	`Syslog`	Supported Linux VM; facilities/severity correctly selected
Firewall emitting CEF	CEF via AMA + Linux forwarder + DCR	`CommonSecurityLog`	Vendor product mapping; separate facility, no duplicate ingest
AWS CloudTrail (if approved)	Supported Microsoft/partner CloudTrail solution/connector	Source-specific, inspect connector	Cloud-side authorization + region/account governance
GCP audit or other SaaS	Supported connector/API or Logs Ingestion API	Connector-specific	Authentication, event coverage, field mapping
Vendor application without connector	Ingestion API/custom integration only after design review	Custom table if designed	Contract, parsing, schema, ownership, costs

Mark which additional data you will really ingest today. The reference lab uses a Linux syslog source and (where possible) a synthetic CEF firewall source.
Compare two alternatives: API/managed integration versus a collector/agent. Write why one is safer/cheaper/more maintainable for the selected source.

PASS D3-L01: Student submits the decision matrix and correctly distinguishes source availability from active ingestion. Not a PASS: Merely finding a connector tile.

Troubleshooting: Missing connector → check Content hub solution and permissions; wrong tenant/workspace → switch explicitly; no connector available → select documented offline pattern and mark operational integration BLOCKED.

Reference: [R02], [R03], [R04].

D3-L02 — Provision/validate Linux collector; configure AMA, DCR, and Syslog (I02)

Competency: Prove that the second telemetry pipeline exists end-to-end. This is the first indispensable live lab.

A. Prepare an isolated Linux VM

Instructor creates or provides an Azure virtual machine with an OS explicitly supported by current Azure Monitor Agent for Linux. Prefer a small Ubuntu LTS/RHEL-class image only after verifying the AMA compatibility list in [R05]; don’t blindly choose ‘latest’ or use an arbitrary distro.
Place VM in the approved training subscription, resource group, region and private network. Use private SSH or Azure Bastion. Do not give the VM a public 514 rule.
Confirm the VM is running, has DNS/HTTPS connectivity to required Azure Monitor endpoints, and has available disk space. Restrict SSH to authorized principals. An Arc-enabled non-Azure alternative is acceptable only when Azure Arc Connected Machine agent is already healthy.
Open an SSH/Bastion terminal and record the host/version:

cat /etc/os-release
uname -a
hostname -f || hostname
id
python3 --version
command -v logger
command -v rsyslogd || command -v syslog-ng

For Ubuntu with rsyslog installed, check services. If not installed, use the distribution’s supported package mechanism after instructor approval; do not run a downloaded opaque shell script without reviewing its current Microsoft-generated contents.

sudo systemctl status rsyslog --no-pager || true
sudo systemctl status syslog-ng --no-pager || true
sudo systemctl status azuremonitoragent --no-pager || true

Record which syslog daemon actually runs. Avoid running rsyslog and syslog-ng concurrently on the same listener unless explicitly designed. If logger is missing, have the administrator install the distro’s util-linux package using an approved method.

Expected evidence: Operating-system identification, syslog daemon active, authorized VM access, VM resource ID and subscription recorded. AMA may not yet be installed at this stage.

B. Make the Syslog connector available

In Defender portal, open Microsoft Sentinel > Content management > Content hub.
Search for the Syslog solution; install/update the supported solution only in the training workspace if the required connector is absent. Confirm installation completed.
Go to Microsoft Sentinel > Configuration > Data connectors, search for Syslog via AMA, open the connector page. If none appears, revisit solution installation/permissions rather than guessing a similarly named legacy connector. [R02]

C. Create and attach the Data Collection Rule

From the Syslog via AMA connector page, choose + Create data collection rule.
Basics: enter dcr-sentinel-d3-syslog (append cohort suffix if name already used); choose approved subscription/resource group.
Resources: choose the actual Linux VM. For Azure VM, the host should be visible. For non-Azure host, confirm Arc connection first. Do not select other machines.
Collect: choose only facility local5 and severity Warning (this also covers more severe messages). If the current wizard presents a different facility list, locate and record local5; do not select all facilities as a workaround.
Review the selected stream/destination and the correct target workspace. Create the DCR.
Refresh the connector page and verify the DCR is listed and linked to the correct VM. Azure’s extension installation may be initiated automatically from this workflow; check Azure portal > VM > Extensions + applications and ensure AzureMonitorLinuxAgent reaches Provisioning succeeded. [R02], [R06]
In Azure portal, open Monitor > Data Collection Rules, select this DCR, and verify its resource association, facility-level selection, and destination. Screenshot the actual association, not only the DCR name.
On Linux, re-check agent service and host resources:

sudo systemctl is-active azuremonitoragent || true
sudo systemctl is-active rsyslog || true
sudo systemctl is-active syslog-ng || true
df -h /

Expected evidence: AMA service is active or extension provisioning is successful as documented; DCR association includes the selected VM; allowed local5/Warning filter and intended destination are visible.

D. Send a bounded, harmless Syslog test message

Define a unique training marker; write it down so your queries can isolate this run:

DAY3_RUN_ID="D3-$(date -u +%Y%m%dT%H%M%SZ)"
echo "$DAY3_RUN_ID"

On the selected VM, send one local application-style event. This is not an actual privileged login, and its fictional source IP will never be contacted:

logger -p local5.warning -t SENTINEL_D3 \
  "SENTINEL_D3_LAB run=${DAY3_RUN_ID} actor=lab.admin@asterretail.example src=198.51.100.23 outcome=success event=privileged_session"

Check the local system journal or syslog, depending on distribution. Some distributions won’t write this local facility to /var/log/syslog; do not infer collection failure solely from an absent file.

sudo journalctl -t SENTINEL_D3 --since "20 minutes ago" --no-pager | tail -n 15

In the correct workspace Logs query experience, run the query below. Replace D3-REPLACE-THIS with the exact printed run ID. Remember that ingested records can arrive asynchronously; Microsoft’s connector troubleshooting guidance allows up to about 20 minutes. [R02], [R06]

Syslog
| where TimeGenerated >= ago(2h)
| where SyslogMessage contains "SENTINEL_D3_LAB"
| where SyslogMessage contains "D3-REPLACE-THIS"
| project TimeGenerated, Computer, Facility, SeverityLevel, ProcessName, SyslogMessage
| order by TimeGenerated desc

If rows are not present, run the broad scoping query to distinguish ingestion from an over-tight filter:

Syslog
| where TimeGenerated >= ago(2h)
| summarize Count=count(), Latest=max(TimeGenerated) by Computer, Facility, SeverityLevel
| order by Latest desc

Use a UTC timestamp in the evidence register and record actual ingestion latency if ingestion_time() is available (see L04). Never change the selected workspace mid-test.

PASS D3-L02: DCR + VM association evidence, healthy agent/daemon, an observed row with the unique marker in the destination Syslog table, and its TimeGenerated. PARTIAL: only host-level logger evidence. BLOCKED: inability to install agent or access workspace.

Diagnostic sequence: no Linux emission → fix logger/syslog daemon; missing agent extension → check Azure VM scope/role; missing DCR association → assign right VM; wrong facility or severity → correct narrow DCR; no workspace rows → inspect endpoint access, AMA logs, workspace and allowed processing delay. Do not ‘fix’ this by collecting everything.

Sources: [R02], [R03], [R05], [R06].

D3-L03 — Collect a synthetic CEF firewall signal and compare multicloud options (I02, I03)

Competency: Explain raw Syslog versus CEF, add a second class of telemetry without facility collision, and select supported third-party/multicloud collection paths. No real firewall is required—only a lab-generated CEF-format message.

A. Plan the forwarding route before changing it

Approved synthetic CEF via loggerLocal UDP 514 listenerrsyslog / syslog-ngAMA local receiving endpointCEF DCR: local4 Warning+CommonSecurityLog

On the Linux collector from L02, verify that rsyslog or syslog-ng is installed and azuremonitoragent is healthy.
In Defender portal open Microsoft Sentinel > Content management > Content hub, locate the Common Event Format (CEF) solution and install it if required. Then open Microsoft Sentinel > Configuration > Data connectors > Common Event Format (CEF) via AMA. [R02]
Create a DCR named dcr-sentinel-d3-cef using the same approved subscription, destination workspace and only the intended lab Linux VM.
In Collect, choose facility local4 with minimum severity Warning. It must not overlap the local5 Syslog DCR from L02. Where the portal provides stream/destination details, confirm CEF target stream Microsoft-CommonSecurityLog (destination table CommonSecurityLog) rather than generic Syslog.
Create the DCR and verify it is associated with the VM. Confirm the AMA extension succeeded. Record whether two DCRs are associated with this single VM, and check they don’t collect the same facility into both streams. [R02], [R03]
If the host is acting as a Syslog/CEF log forwarder, follow the current installation script shown on that exact connector page to configure your chosen syslog daemon and forwarding/listening behavior. Inspect the script in the UI and have the instructor authorize it before execution. Do not paste a stale URL/script from an older tutorial. This can modify rsyslog/syslog-ng files and open a local listener.
Verify the listener from the Linux machine:

sudo systemctl status azuremonitoragent --no-pager
sudo systemctl status rsyslog --no-pager || true
sudo systemctl status syslog-ng --no-pager || true
sudo ss -lunp | grep ':514' || true
sudo ss -ltnp | grep -E '(:28330|:514)' || true

If no UDP 514 listener exists, return to the currently documented connector/daemon configuration. Do not set 0.0.0.0:514 on an internet-accessible host just to make the test pass. Use a private Linux host and local injection.

B. Emit one controlled CEF message

In the same Linux host terminal, execute the following. Its field values are fictitious; the logger sends to localhost only. The syntax follows the structure of Microsoft’s CEF-via-AMA test instructions; actual parsing must still be verified on the workspace. [R02], [R06]

logger -p local4.warning -P 514 -n 127.0.0.1 --rfc3164 -t CEF \
  '0|AsterLab|Firewall|1.0|D3-100|Privileged source was denied|5|src=198.51.100.23 dst=203.0.113.10 suser=lab.admin@asterretail.example act=deny msg=SENTINEL_D3_LAB'

Why -t CEF rather than putting CEF: into an arbitrary shell string? With the Microsoft-documented logger approach, the syslog application tag is used to construct the expected RFC-style payload. Third-party devices may produce a different but valid envelope; inspect the actual raw payload on a test host if parsing fails.

In the workspace Logs editor:

CommonSecurityLog
| where TimeGenerated >= ago(2h)
| where DeviceVendor == "AsterLab" and DeviceProduct == "Firewall"
| project TimeGenerated, Computer, DeviceVendor, DeviceProduct,
          DeviceEventClassID, Activity, DeviceAction,
          SourceIP, DestinationIP, SourceUserName
| order by TimeGenerated desc

Expected: At least one new CommonSecurityLog record with DeviceVendor = AsterLab, DeviceProduct = Firewall, and SourceIP = 198.51.100.23. Verify whether the parser populated SourceUserName from suser and DeviceAction from act; different product schemas and parsers can alter field names/values. A Syslog event without parsed CEF columns is not the same as successful CEF parsing.

If the correct CEF fields have not appeared, wait for the documented processing window then follow L14. Do not keep replaying unbounded messages. Use the diagnostic KQL below to check whether the data appeared as generic Syslog instead:

Syslog
| where TimeGenerated >= ago(2h)
| where SyslogMessage contains "AsterLab" or SyslogMessage contains "D3-100"
| project TimeGenerated, Computer, Facility, ProcessName, SyslogMessage
| order by TimeGenerated desc

An appearance only in Syslog suggests a CEF stream/facility/parser/configuration issue. It may also be normal for the current DCR’s intended design; check exactly what you configured rather than assuming the connector is wrong.

C. Instructor walkthrough: multi-cloud and third-party collection choices

For each hypothetical environment below, find the currently supported integration route in Content hub. Do not connect live tenants to the lab without written authorization.

Estate	Source-side prerequisite to discuss	Typical destination consideration	Mandatory mapping questions
AWS CloudTrail	Account/region coverage; bucket/event delivery; least privilege	CloudTrail connector/solution’s documented table	API vs data event selection; timestamps; cross-account scope
GCP Cloud Audit Logs	GCP project/org permissions and delivery mechanism	GCP connector or approved log pipeline	Principal identity, resource hierarchy, event category
Firewall / NDR	CEF-compatible device or collector; networking	`CommonSecurityLog` if connector uses CEF	Which field contains source IP/action/user? NAT?
Identity SaaS	Supported provider connector, API or streaming integration	Connector-specific logs	Principal naming; failure codes; service-account exclusion
Custom app	Design-reviewed DCR + Logs Ingestion API / partner route	Explicitly named custom table	Schema and transformation; event-time; pagination; retries

PASS D3-L03: Student demonstrates a parsed test CEF record or provides an instructor-authorized alternate-source evidence record with honest reason; plus a completed multicloud selection matrix. Full live correlation assessment still needs two appropriate actual sources. Do not claim that listing AWS or GCP connectors constitutes onboarding them.

Troubleshooting: logger rejected --rfc3164 → inspect logger --help and use an approved supported Linux utility; port 514 not listening → inspect Microsoft script/rsyslog config and listen address; record only in Syslog → check CEF facility (local4), stream and header; record nowhere → packet/daemon/agent/DCR/egress checks. Consult [R02], [R03], [R06].

D3-L04 — Test the ingestion pipeline for fidelity, timeliness, and duplicates (I04)

Competency: Determine whether data is usable for detections; separate “events are present” from “the source is trustworthy.”

A. Confirm basic coverage and freshness

In Logs, select the correct workspace, set an appropriate time window, and execute the queries individually:

Syslog
| where TimeGenerated >= ago(24h)
| summarize Events=count(), LastEvent=max(TimeGenerated), Hosts=dcount(Computer)
    by Facility, SeverityLevel
| order by Events desc

CommonSecurityLog
| where TimeGenerated >= ago(24h)
| summarize Events=count(), LastEvent=max(TimeGenerated),
            MissingSrc=countif(isempty(SourceIP)),
            MissingAction=countif(isempty(DeviceAction))
    by DeviceVendor, DeviceProduct
| order by Events desc

Use a field-level sample to verify that source IP, actor/user and event classification mean what the SOC thinks they mean:

CommonSecurityLog
| where TimeGenerated >= ago(2h)
| where DeviceVendor == "AsterLab"
| project TimeGenerated, DeviceVendor, DeviceProduct,
          SourceIP, SourceUserName, DeviceAction,
          DestinationIP, DeviceEventClassID, Activity
| take 20

Inspect the actual source (SyslogMessage) rather than trusting a parser or apparent IP field blindly. Compare an emitted test string to its resulting row.

B. Measure arrival delay only if available

ingestion_time() can return a valid ingestion timestamp when supported by the table’s ingestion-time policy; null is not proof that no data arrived. Also, event TimeGenerated may reflect device clock behavior rather than actual receipt time.

Syslog
| where TimeGenerated >= ago(2h)
| where SyslogMessage contains "SENTINEL_D3_LAB"
| extend IngestedAt = ingestion_time()
| extend IngestDelaySeconds = datetime_diff('second', IngestedAt, TimeGenerated)
| project TimeGenerated, IngestedAt, IngestDelaySeconds,
          Computer, Facility, SyslogMessage
| order by TimeGenerated desc

If IngestedAt is null or the delay looks negative/implausible, record not measurable in this table/configuration, then compare your instructor’s shell emission UTC timestamp, observed ingestion UTC timestamp, VM time sync and source time fields. Do not publish an SLA conclusion based on one synthetic event.

C. Check duplicates and parsing quality

Syslog
| where TimeGenerated >= ago(2h)
| where SyslogMessage contains "SENTINEL_D3_LAB"
| summarize Count=count(), First=min(TimeGenerated), Last=max(TimeGenerated)
    by Computer, SyslogMessage
| order by Count desc

A Count > 1 can mean intentionally re-sent source events or true duplication. Inspect whether the same message was generated multiple times; determine whether both Syslog and CEF DCRs match the same facility. Do not deduplicate events indiscriminately in detections without preserving distinct source-event IDs.

CommonSecurityLog
| where TimeGenerated >= ago(24h)
| summarize Total=count(),
            EmptySourceIP=countif(isempty(SourceIP)),
            EmptyUser=countif(isempty(SourceUserName)),
            EmptyAction=countif(isempty(DeviceAction))
    by DeviceVendor, DeviceProduct
| extend SourceIPCompletenessPct =
         iif(Total == 0, real(null), 100.0 * (Total - EmptySourceIP) / Total)
| order by Total desc

Prepare a small quality report:

Test	Actual observation	Expected acceptance condition
Freshness	`________`	New test rows visible within documented delay/window
Table target	`________`	Syslog in `Syslog`, CEF in `CommonSecurityLog`
Host/source identity	`________`	Distinguishes lab VM and fictional source
Source address/action	`________`	Fields present and semantically correct, or limitation recorded
Clock/time	`________`	Source time plausible; skew assessed
Duplication	`________`	Repeated rows explained, not assumed
Narrow collection	`________`	Selected DCR facilities/severities are documented

PASS D3-L04: Quantitative query results and a reasoned fidelity verdict. “Two rows exist” without schema/duplicate/timestamp analysis is insufficient.

Sources: [R02], [R03], [R06].

D3-L05 — Intermediate KQL lab: `let`, `join`, `union`, `extend`, `parse`, `mv-expand`, `distinct` (I05)

Competency: Compose advanced queries intentionally and verify that joins do not inflate confidence or row counts. These exercises run without any ingestion because they use in-query datatable() and print samples. They are for KQL learning, not for a deployed analytics rule.

Exercise K01 — Reusable expressions, filtering and calculated fields

Copy one block at a time into the workspace Logs query editor:

let AdminEvents = datatable(Actor:string, SourceIP:string, Action:string)
[
  "lab.admin@asterretail.example", "198.51.100.23", "privileged_login",
  "lab.ops@asterretail.example",   "203.0.113.99",  "read_config",
  "lab.admin@asterretail.example", "198.51.100.23", "change_setting"
];
AdminEvents
| extend IsPrivilegedAction = Action in ("privileged_login", "change_setting")
| where IsPrivilegedAction
| project Actor, SourceIP, Action, IsPrivilegedAction

Expected: Two rows for lab.admin@.... Explain that let improves readability but doesn’t automatically materialize or cache a query.

Exercise K02 — `join kind=inner` (and why row counts multiply)

let Identity = datatable(Actor:string, SourceIP:string)
[
  "lab.admin@asterretail.example", "198.51.100.23",
  "lab.user@asterretail.example",  "203.0.113.99"
];
let Firewall = datatable(SourceIP:string, FirewallAction:string)
[
  "198.51.100.23", "deny",
  "192.0.2.55", "allow"
];
Identity
| join kind=inner (Firewall) on SourceIP
| project Actor, SourceIP, FirewallAction

Expected: Exactly one matching row. Modify Firewall to include the same SourceIP twice and observe duplicate matches; then articulate why IP equality alone is insufficient attribution.

Exercise K03 — Time-bounded correlation

let Logins = datatable(LoginAt:datetime, Actor:string, SourceIP:string)
[
  datetime(2026-11-01T09:00:00Z), "lab.admin@asterretail.example", "198.51.100.23",
  datetime(2026-11-01T11:00:00Z), "lab.user@asterretail.example", "203.0.113.99"
];
let Blocks = datatable(BlockAt:datetime, SourceIP:string)
[
  datetime(2026-11-01T09:05:00Z), "198.51.100.23",
  datetime(2026-11-01T11:45:00Z), "203.0.113.99"
];
Logins
| join kind=inner (Blocks) on SourceIP
| where BlockAt between (LoginAt - 10m .. LoginAt + 10m)
| project LoginAt, Actor, SourceIP, BlockAt

Expected: Only the 09:00/09:05 pair. Note: static test timestamps are fine in in-query teaching examples but unsuitable for alert rules that should evaluate new events.

Exercise K04 — `union` heterogeneous sources safely

let Linux = datatable(Actor:string, Action:string)
[
  "lab.admin@asterretail.example", "login"
]
| extend Source="Linux";
let Cloud = datatable(Actor:string, Action:string)
[
  "lab.admin@asterretail.example", "role_change"
]
| extend Source="Cloud";
union Linux, Cloud
| project Source, Actor, Action
| order by Source asc

Expected: Two rows. union appends results; it does not infer a relationship. It may introduce null columns or type-suffixed columns if schemas don’t align; project harmonizes them.

Exercise K05 — `parse` an agreed application contract

let Raw = datatable(Message:string)
[
  "actor=lab.admin@asterretail.example src=198.51.100.23 action=privileged_login",
  "actor=lab.user@asterretail.example src=203.0.113.99 action=read_config"
];
Raw
| parse Message with "actor=" Actor:string " src=" SourceIP:string " action=" Action:string
| project Actor, SourceIP, Action

Expected: Both actors/IPs/actions extracted. Change one record’s separator or key spelling: extraction can fail. Compare this with extract() using a regex; choose based on source contract rather than trying to recover every malformed record silently.

Exercise K06 — `mv-expand` and `distinct`

print Actors=dynamic([
  "lab.admin@asterretail.example",
  "lab.ops@asterretail.example",
  "lab.admin@asterretail.example"
])
| mv-expand Actor = Actors to typeof(string)
| distinct Actor
| order by Actor asc

Expected: Two unique actors. Explain that mv-expand can increase row volume and query cost.

Exercise K07 — `join kind=leftouter` versus `lookup`

let Findings = datatable(Actor:string, SourceIP:string)
[
  "lab.admin@asterretail.example", "198.51.100.23",
  "lab.user@asterretail.example", "203.0.113.99"
];
let Business = datatable(Actor:string, Owner:string, Criticality:string)
[
  "lab.admin@asterretail.example", "Identity Team", "High"
];
Findings
| lookup kind=leftouter Business on Actor
| project Actor, SourceIP, Owner, Criticality

Expected: Two findings; unmatched user has empty enrichment. An unrecognized actor must not be fabricated as ‘low risk.’

Exercise K08 — Reduce many-to-many joins before operating on a security decision

let Identity = datatable(Actor:string, SourceIP:string)
[
  "adminA", "198.51.100.23",
  "adminA", "198.51.100.23"
];
let Firewall = datatable(SourceIP:string, Decision:string)
[
  "198.51.100.23", "deny",
  "198.51.100.23", "deny"
];
let RawJoin = Identity | join kind=inner (Firewall) on SourceIP;
RawJoin
| summarize JoinedRows=count(), UniqueActors=dcount(Actor) by SourceIP

Expected: Four joined rows from only two records on each side. Explain why metrics need clear event identity (and potentially summarize, deduplication or arg_max) before claiming an attack rate.

PASS D3-L05: Learner runs all eight examples, records expected/actual counts, explains join vs union, demonstrates parsing failure, and identifies the four-row join amplification.

Common errors: Missing ; after let; TimeGenerated silently lost in an alert query; data types mismatch in join keys; many-to-many expansion; union used as correlation; dynamic array not expanded; no normalization of case/whitespace for identity fields.

KQL reference: [R07].

D3-L06 — Correlate Linux and firewall data with a defensible time window (I06)

Competency: Build a two-source KQL correlation against the actual Syslog and CommonSecurityLog tables and critique its assumptions.

A. Prepare evidence and inspect join keys

Verify that L02 produced a Syslog row with SENTINEL_D3_LAB and that L03 produced a parsed CommonSecurityLog row with DeviceVendor=AsterLab.
In the Logs editor, run the query below; use a window that includes your bounded test. Do not reuse old Day 1/2 events that have no shared identity keys.
Examine the parsed LabActor, source IP, and CEF SourceUserName; if parser output is missing, record it before correlating.

let Linux = Syslog
| where TimeGenerated >= ago(2h)
| where SyslogMessage contains "SENTINEL_D3_LAB"
| extend SourceIP = extract(@"src=([0-9.]+)", 1, SyslogMessage)
| extend LabActor = extract(@"actor=([^\s]+)", 1, SyslogMessage)
| where isnotempty(SourceIP) and isnotempty(LabActor)
| project LinuxTime=TimeGenerated, LinuxHost=Computer,
          SourceIP, LabActor, LinuxRaw=SyslogMessage;
let Firewall = CommonSecurityLog
| where TimeGenerated >= ago(2h)
| where DeviceVendor == "AsterLab" and DeviceProduct == "Firewall"
| where isnotempty(SourceIP)
| project FirewallTime=TimeGenerated, SourceIP, SourceUserName,
          DeviceAction, DeviceEventClassID;
Linux
| join kind=inner (Firewall) on SourceIP
| where FirewallTime between (LinuxTime - 10m .. LinuxTime + 10m)
| project LinuxTime, FirewallTime, LinuxHost, LabActor,
          SourceIP, SourceUserName, DeviceAction, DeviceEventClassID
| order by LinuxTime desc

Expected: At least one joined row when the two emitted records share source IP and are within ten minutes. If the messages were sent more than ten minutes apart, send one new bounded pair after instructor approval and record the emission timestamps. There is no guaranteed fixed row count if a cohort has repeated the test; this is why you inspect evidence and add scope.

B. Tighten the correlation

If SourceUserName reliably parsed from suser, add this condition after the time predicate:

| where tolower(LabActor) == tolower(SourceUserName)

If the user field is blank, you cannot claim account-identity correlation—only shared source-IP/time evidence. Explain NAT/shared proxy and time-skew limitations. Consider a unique event correlation ID for real integrations and vendor-specific parsing contracts.

C. Convert the result into a compact detection candidate

Copy and run the following separately. Its TimeGenerated is derived from actual source events and is suitable for a scheduled-rule candidate after lab-specific testing. Not production-ready without source tuning, alert ownership, and peer review.

let Linux = Syslog
| where TimeGenerated >= ago(20m)
| where SyslogMessage contains "SENTINEL_D3_LAB"
| extend SourceIP = extract(@"src=([0-9.]+)", 1, SyslogMessage)
| extend Account = extract(@"actor=([^\s]+)", 1, SyslogMessage)
| where isnotempty(SourceIP) and isnotempty(Account)
| project LinuxTime=TimeGenerated, Account, SourceIP, Computer;
let Firewall = CommonSecurityLog
| where TimeGenerated >= ago(20m)
| where DeviceVendor == "AsterLab" and DeviceProduct == "Firewall"
| project FirewallTime=TimeGenerated, SourceIP,
          SourceUserName, DeviceAction;
Linux
| join kind=inner (Firewall) on SourceIP
| where FirewallTime between (LinuxTime - 10m .. LinuxTime + 10m)
| where isempty(SourceUserName) or tolower(Account) == tolower(SourceUserName)
| summarize TimeGenerated=max(LinuxTime),
            FirewallLastSeen=max(FirewallTime),
            EvidencePairs=count(),
            SampleAction=take_any(DeviceAction),
            Host=take_any(Computer)
          by Account, SourceIP
| project TimeGenerated, Account, SourceIP, Host,
          FirewallLastSeen, EvidencePairs, SampleAction
| order by TimeGenerated desc

Annotation: The isempty(SourceUserName) branch tolerates a missing CEF account but weakens attribution. For production-style high-fidelity rules, remove that branch and require an actually parsed matching account, after validating the parser and deciding what to do with missing identities. Do not treat this query as a confirmed attack detector: the injected records were fictional test logs.

D. Evaluate a minimum three-case test set

Case	Test input	Desired query behavior	Why
Positive P1	Syslog + CEF same source IP, within 10 minutes, actor matches (if provided)	Match	Two different telemetry sources agree
Negative N1	Syslog source IP different from CEF	No match	Join key differs
Negative N2	Same IP but 30+ minutes apart	No match	Time boundary rejected
Edge E1	Same IP, different CEF user	No match if strict actor equality enabled; otherwise explicitly flagged weak	Shared infrastructure ambiguity
Edge E2	Repeated test events	Possibly multiple pairs, then summarized	Join multiplicity

Do not generate thousands of events for testing; if live time-bound cases are hard to replay safely, execute datatable() variants as in L05 and separately label the real-path observation.

PASS D3-L06: The KQL runs with live joined results or the instructor records a clearly marked alternate two-source evidence set. Learner states the join key and time window, demonstrates at least one negative test, and writes limitations. No source data, no PASS on ‘correlation demonstrated.’

Sources: [R07], [R13].

D3-L07 — Governed watchlist creation and business-context enrichment (I07)

Competency: Turn a CSV reference list into contextual enrichment, control its lifecycle, avoid using watchlists as large-scale event storage.

A. Build a tiny approved CSV file

Create a local UTF-8 text file named day3_privileged_accounts.csv with exactly this content. This is embedded in the manual so no separate download is required:

UserPrincipalName,Owner,Criticality,ApprovedUntil,Comment
lab.admin@asterretail.example,Identity Team,High,2026-12-31,Fictional lab privileged account
lab.ops@asterretail.example,Cloud Operations,Medium,2026-12-31,Fictional operations account
lab.breakglass@asterretail.example,Security Lead,Critical,2026-12-31,Fictional emergency account

Open the file in a plain-text editor, confirm header names, no extra comments/blank header lines, and no real employee data.
Confirm the owner/steward, source-of-truth, change approval, review cadence, and removal date. Watchlists are reference data; they are not a master identity directory. [R08]

B. Create the watchlist in the correct Sentinel workspace

In Defender portal go to Microsoft Sentinel > Configuration > Watchlist.
Choose + New (or equivalent Create action shown in the current portal).
Enter Name: Day 3 Privileged Accounts, Alias: day3_privileged_accounts, Description: Synthetic authorized training reference list; save the owner in the class ledger.
On Source, choose Local file, upload day3_privileged_accounts.csv, and indicate that the header is on line 1 (0 rows preceding the header).
Choose SearchKey = UserPrincipalName (the column used to join events to this list).
Review and create. Wait for the watchlist to be queryable; a successful UI notification does not guarantee immediate query visibility. [R09]

C. Verify the list, then enrich a live correlation

_GetWatchlist('day3_privileged_accounts')
| project SearchKey, UserPrincipalName, Owner, Criticality, ApprovedUntil
| order by SearchKey asc

Expected: Three synthetic entries, each with correct SearchKey and owner/criticality. The watchlist may have cached refresh behavior and an internal TimeGenerated timestamp; do not interpret watchlist TimeGenerated as when the account became privileged. [R08]

Then run this live enrichment against Syslog (doesn’t require CEF to be present):

let Privileged = _GetWatchlist('day3_privileged_accounts')
| project JoinKey=tolower(SearchKey), Owner, Criticality, ApprovedUntil;
Syslog
| where TimeGenerated >= ago(2h)
| where SyslogMessage contains "SENTINEL_D3_LAB"
| extend Account=extract(@"actor=([^\s]+)", 1, SyslogMessage)
| where isnotempty(Account)
| extend JoinKey=tolower(Account)
| lookup kind=leftouter Privileged on JoinKey
| project TimeGenerated, Computer, Account, Owner, Criticality,
          ApprovedUntil, SyslogMessage
| order by TimeGenerated desc

Expected: Fictional lab.admin@... event enriches to Owner = Identity Team, Criticality = High. If the watchlist has no match, output may have null enrichment. Null is not the same as approved unprivileged.

D. Add controlled review logic (not an implicit permanent bypass)

Ask the learner: Does ApprovedUntil mean the account is safe? No. It might mean a temporary approval period, not an exception to detect suspicious behavior.
Discuss when an allowlist is legitimate: signed ownership, specific behavior/context, scope, expiry, audit trail; avoid broad ‘ignore all activity from this user’ filters.
For an actual time-bound review example:

_GetWatchlist('day3_privileged_accounts')
| extend ApprovalEnd=todatetime(ApprovedUntil)
| extend ApprovalCurrent=isnotnull(ApprovalEnd) and ApprovalEnd >= now()
| project SearchKey, Owner, Criticality, ApprovalEnd, ApprovalCurrent

This does not change watchlist rows and does not suppress detections; it only derives current approval context.

PASS D3-L07: Watchlist exists, _GetWatchlist() returns the expected records, a real or separately labeled synthetic event is enriched with the correct owner/criticality, and a stewardship/expiry policy is documented.

Troubleshooting: invalid file format; alias case; header misspelling; wrong SearchKey; wrong workspace; tolower() mismatch; newly created list not yet queryable; stale/missing reference owners.

Sources: [R08], [R09].

D3-L08 — Evaluate threat-intelligence indicators safely (I08)

Competency: Recognize indicator lifecycle, expiry, confidence, source reliability and false matches; use TI as context, not a blanket verdict. No real malicious IOC and no external TI subscription are needed for the required exercise.

A. Discover the correct 2026 TI experience

In Defender portal, locate Microsoft Sentinel > Threat management > Threat intelligence (navigation may also surface TI under an investigation-oriented Defender experience, depending on onboarded services). Check the workspace/tenant context.
Record which approved TI connectors and feature licenses are already available. Do not subscribe to a feed, register credentials or import public malicious infrastructure for the training just to make a query return rows.
If an approved feed already exists, check that the workspace contains ThreatIntelIndicators. This is the modern indicator table; the old ThreatIntelligenceIndicator ingestion was retired in 2025. The old Threat Intelligence Platforms (TIP) connector was slated to stop collecting in June 2026; current new integrations should use supported TIP upload API or TAXII methods, approved by the TI owner. [R10], [R11]
If the table is available, query its actual schema. This is read-only:

ThreatIntelIndicators
| where TimeGenerated >= ago(30d)
| summarize arg_max(TimeGenerated, *) by Id
| where IsDeleted == false and Revoked == false and IsActive == true
| project TimeGenerated, Id, ObservableKey, ObservableValue,
          Confidence, ValidFrom, ValidUntil, Pattern, Tags
| take 25

Important: The IsActive property and expiry handling are related but not identical. In an operational TI match, additionally consider the current time against validity fields and the exact ObservableKey/pattern semantics. A numeric Confidence value is not a mathematically calibrated probability of attack.

If the table does not exist, or is empty due to missing entitlements/connectors, record not available in lab and complete B. Do not fabricate a live TI match.

B. Self-contained synthetic TI matching exercise

Run this query independently; it uses fictional records and stays inside the query engine:

let Network = datatable(TimeGenerated:datetime, SourceIP:string, Action:string)
[
  datetime(2026-11-01T09:06:00Z), "198.51.100.23", "deny",
  datetime(2026-11-01T09:08:00Z), "203.0.113.99", "allow"
];
let Indicators = datatable(IndicatorIP:string, Confidence:int,
                           ValidUntil:datetime, Revoked:bool)
[
  "198.51.100.23", 80, datetime(2026-12-31T00:00:00Z), false,
  "203.0.113.99",  90, datetime(2026-01-01T00:00:00Z), true
];
Network
| lookup kind=leftouter Indicators on $left.SourceIP == $right.IndicatorIP
| extend IndicatorUsable = isnotnull(IndicatorIP)
                    and Revoked == false
                    and ValidUntil > datetime(2026-11-01T00:00:00Z)
| project TimeGenerated, SourceIP, Action, Confidence,
          ValidUntil, Revoked, IndicatorUsable

Expected: 198.51.100.23 is a fictional valid indicator in the simulated snapshot, while 203.0.113.99 is not usable because revoked/expired. The test is deliberately anchored to the scenario date so its expected output remains reproducible. In live TI queries use now() and actual indicator source field mappings.

C. Analyst decision worksheet

Question	Required answer
Is an IP match sufficient to label a person malicious?	No; NAT, infrastructure sharing, stale indicators and spoofed logs must be assessed
What makes an indicator actionable?	Provenance, accuracy, observable type, expiry, confidence, relevant behavior and ownership
How do you handle an expired indicator?	Filter from active matching or clearly label historical context; do not silently enforce
What is the difference between TI and a watchlist?	TI is threat-context evidence with indicator lifecycle; watchlist may be business reference data
Where is the audit record?	Feed/operator provenance, imported indicator ID, action taken, UTC timestamps, review decision

PASS D3-L08: Learner demonstrates correct 2026 table/connector awareness, executes synthetic validity checks, states matching limitations, and writes one justified intelligence disposition. Optional live bonus: approved feed/table actually returns data.

Sources: [R10], [R11], [R17].

D3-L09 — Inspect User and Entity Behavior Analytics (UEBA) context (I09)

Competency: Determine when UEBA enrichments can strengthen an investigation, what scores mean, and what must not be inferred from an anomaly.

A. Confirm availability and roles before enabling anything

Ask the instructor whether UEBA is already enabled in the training workspace and whether identity-signal sources are present. Do not turn it on without approval: it creates additional data and can increase storage cost.
If authorized to enable UEBA, confirm the enabling principal has Microsoft Entra Security Administrator or equivalent tenant permissions plus the required Azure RBAC, and that resource locks do not block changes. Merely viewing UEBA data does not require these special enablement roles. [R12]
In Defender portal go to System > Settings > Microsoft Sentinel > UEBA. Under current documented experience, turn on UEBA only with explicit approval, select only intended directory/source options, and choose Connect.
For anomaly detection (if authorized), go to Settings > Microsoft Sentinel > SIEM workspaces, select the correct workspace, open Anomalies, and toggle Detect Anomalies if available and approved.
For supported sources, verify the actual connector dependencies and data readiness. A fictional CEF product from L03 is not automatically a supported UEBA input. Microsoft documents only supported vendor/source schemas. [R12]

B. Inspect available UEBA logs (read-only)

If BehaviorAnalytics is present:

BehaviorAnalytics
| where TimeGenerated >= ago(7d)
| project TimeGenerated, UserPrincipalName, ActivityType,
          SourceIPAddress, EventSource, InvestigationPriority,
          ActivityInsights
| order by InvestigationPriority desc, TimeGenerated desc
| take 25

If the table exists but no rows are returned, that is an observable result—not proof UEBA is broken. Verify enabled sources, permissions, volume and whether any events actually qualify for profiling. If the table is unavailable, use the synthetic scoring discussion in C and record that live UEBA was not tested.

C. Interpret the scores without overclaiming

Microsoft distinguishes BehaviorAnalytics.InvestigationPriority (0–10) from Anomalies.AnomalyScore (0–1). They describe different levels of unusual behavior, and a high score is not a conviction. [R18]

Synthetic interpretation table:

Fictional evidence	Score	Analyst response
Admin launches approved first-time service change	Investigation priority 8/10	Validate change request and relevant roles; unusual does not prove malicious
Multiple independently suspicious events form a new pattern	Anomaly score 0.91/1	Prioritize corroboration, isolate time window and evidence, escalate if justified
Routine nightly automation looks normal	1/10	Still check source fidelity and whether a policy violation occurred

Write one alternative benign explanation for a high score and one serious concern a low score would not rule out.
State where UEBA might add useful context to L06’s correlation (identity profile, peer context, historical behavior).
Note why unsupported or thin telemetry can produce a misleading risk picture.

PASS D3-L09: Documented availability/approval check, live query result if supported, correct comparison of two score types, and a reasoned analyst statement. Do not block progression because UEBA is unavailable if the substitute exercise is completed; mark optional live feature NOT VERIFIED.

Sources: [R12], [R18], [R19].

D3-L10 — Publish and validate a custom scheduled analytics rule (I10)

Competency: Convert the real cross-source query into a working detection, map entities and useful custom details, control its lookback and alert generation, and demonstrate the alert → incident path. This lab must be performed in a dedicated training workspace or by an instructor with approved write privileges.

A. Pre-publish validation and safety checks

Confirm that L06’s compact candidate query runs in the intended Log Analytics workspace, returns rows for recent actual test logs, includes a legitimate TimeGenerated:datetime, and returns the columns Account, SourceIP, Host, EvidencePairs, and SampleAction.
If L03’s CEF source is unavailable, do not insert a synthetic datatable() into a production-like scheduled analytics rule. Either (a) complete the rule-authoring walkthrough as a non-deployed design exercise or (b) ask the instructor to provide a separate, approved real data source and rewrite the query for that source. Mark operational rule PASS only after real evidence exists.
Confirm that the rule uniquely matches lab markers and AsterLab test device data. No broad SecurityEvent/SigninLogs queries or real privileged accounts should be alerted on by this exercise.
Save the exact tested query in the instructor evidence pack. Record the last query result UTC timestamp.

B. Create the scheduled query rule via Defender portal

Open Microsoft Sentinel > Configuration > Analytics.
Select + Create > Scheduled query rule. [R13]
In the general stage, enter:
- Name: SENTINEL-D3-LAB-Privileged-Source-Correlation
- Description: TRAINING ONLY: synthetic Linux plus CEF source-IP/time correlation; test marker required; delete after lab
- Severity: Low or Informational per instructor policy, not High simply because the fictional account is called admin
- Status: Disabled until the query/settings are checked; then enable for the bounded demonstration
- MITRE ATT&CK: only choose tactics/techniques for which the scenario supports an explanatory mapping; absence of mapping is preferable to inaccurate labels
On Set rule logic, paste the validated candidate KQL from D3-L06 section C, adjusted only for actual test field mappings.
Entity mapping (if supported by your rule editor):
- Account entity → identifier FullName → column Account (confirm email-string handling in your tenant)
- IP entity → identifier Address → column SourceIP
- Host entity → HostName or current supported host identifier → column Host, if the current wizard offers a compatible mapping. Record any omitted mapping rather than guessing.
Custom details: map useful scalar outputs such as EvidencePairs and SampleAction, avoiding secrets or raw log payloads. Keep descriptions short.
Query scheduling: use Run query every 5 minutes, Lookup data from the last 20 minutes, which satisfies the current documented condition that lookback ≥ interval. Microsoft describes minimum 5-minute intervals for scheduled queries; the engine can introduce processing offset/ingestion delay. [R14]
Alert threshold: Generate alert when results > 0; select Group all events into a single alert for the lab to prevent a storm.
Use Test with current data if shown, and document the result. Simulation is useful but does not constitute proof of an alert or incident.
Incident settings: leave Create incidents from alerts enabled in a Sentinel-on-Defender environment. For the training rule, prefer default/simple grouping until the instructor authorizes a change; read the available options to avoid accidental incident floods. [R13], [R14]
Review any automated response stage without adding Day 4 playbooks. Create the rule; confirm it appears under active rules with the expected name.

C. Prove the actual alert and incident chain

If the query has recently matching rows, enable the rule and wait for its actual scheduled evaluation. If data ages out of the 20-minute lookback before the first run, have the instructor send one fresh bounded Syslog+CEF pair as in L02/L03 and record the UTC time. Do not increase collection volume impulsively.
In the Defender portal incident queue / relevant Microsoft Sentinel incident experience, search for the training rule or its associated alert. Depending on tenant/portal edition, incidents may be visible under unified Incidents, with case-preview options available separately. Record the actual label used by the tenant.
Open the incident. Confirm the alert was created by SENTINEL-D3-LAB-Privileged-Source-Correlation, the evidence time is recent, and intended mapped entities/custom details are visible.
Record: rule name, run/test UTC timestamps, alert identifier, incident identifier, mapped IP/account, severity, and any missing fields.
If no incident appears: verify first that a real alert exists, then check incident creation settings, query matches during scheduled lookback, actual query execution, portal filters, RBAC and integration mode. A search returning zero results for a UI view is not proof the rule never executed.

Mandatory proof chain:

Actual Linux Syslog row
   + actual parsed CEF row
       ↓
Time-bounded KQL result with TimeGenerated
       ↓
Enabled scheduled analytics rule (name + settings)
       ↓
Created alert (real ID)
       ↓
Created Microsoft Defender / Sentinel incident (real ID)

PASS D3-L10: Instructor has evidence of every link of this chain and can inspect entity mapping. PARTIAL: saved/enabled rule but no alert/incident. BLOCKED: missing role/permissions/second source; leave the rule disabled and record the reason.

Failure tips: Source events too old; no CEF table; empty actor; facility filtered; event timestamp skew; TimeGenerated absent in final projection; query is too costly; rule set Disabled; scheduled window excludes events; rule fails to create incidents; wrong Defender queue view. See L14.

Sources: [R13], [R14], [R20].

D3-L11 — Tune rule fidelity, grouping, ownership and false-positive behavior (I11)

Competency: Show measured improvements without suppressing genuine signal. Change one factor at a time; maintain a before/after test matrix.

A. Establish the baseline

Take a screenshot or record the L10 rule query, evaluation interval, lookback, threshold, event grouping, incident settings, alert count and false-positive observations.
Determine how many distinct lab source events underlie one detection (do not use joined row count as the event count; L05 showed why joins multiply).
Record the current rule name/version in the course log and identify an owner for tuning changes.

B. Introduce an approved benign comparator

The instructor may emit one extra harmless syslog message with a separate fictional maintenance identity. It should not be used to bypass policy; it is there to evaluate relevance and false positives.

logger -p local5.warning -t SENTINEL_D3 \
  'SENTINEL_D3_LAB actor=lab.maintenance@asterretail.example src=192.0.2.44 outcome=success event=authorized_maintenance'

Confirm this message reached Syslog.
Observe that the current two-source correlated rule should not trigger from Syslog alone without matching CEF evidence. If it does, investigate the query rather than writing a broad exception.
In a self-contained synthetic query, create a matching firewall event for maintenance and test whether a scoped documented maintenance exception would be justified. This avoids generating another live alert unnecessarily.

C. Create an explicit decision table

Test ID	Source conditions	Desired handling	Expected lesson
P1	Lab admin and CEF match; no change ticket	Alert / triage	Correlated signal worthy of review
P2	Same signal, novel source, repeated evidence	Review; possibly higher severity after corroboration	Not necessarily one alert per event
N1	Syslog only	No cross-source alert	A source-only event is not this detector’s target
N2	Different IP / outside time window	No alert	Avoid unrelated joins
B1	Approved maintenance identity, valid ticket/time	Possible documented scoped exception	No unconditional identity allowlist
E1	Parser fails to populate actor	No high-fidelity account conclusion	Data-quality dependency

D. Apply a narrow, reversible refinement

Prefer a strict actor match (when CEF parsed SourceUserName is demonstrably present) instead of the weakened L06 branch:

// Use this as a replacement predicate in the correlated query
| where isnotempty(SourceUserName)
| where tolower(Account) == tolower(SourceUserName)

Consider excluding only approved maintenance action types within a real change window. An example of the logical requirement, not a copy-paste production filter:

EXCLUDE ONLY IF:
  account is in governed maintenance reference data
  AND change ID matches an approved ticket
  AND event UTC time is inside authorized start/end
  AND the behavior actually matches that change's permitted scope
  AND detection owners have approved the exception

Re-run both positive and negative tests in the query editor. If the positive case disappears after strict account matching, investigate whether missing CEF parsing—not benign behavior—caused it.
Update the rule in the approved lab only after showing the test evidence. Preserve previous query/version, and document rollback.
In rule configuration review alert threshold, event grouping, incident grouping, and suppression options. These have distinct semantics: suppressing rule evaluations after an alert is not the same as excluding benign records in KQL. Avoid both alert storms and blind intervals. [R14]
Record actual incident dispositions and owner-hand-off convention (for example, New → Active; then evidence-based classification), without using automatic closure for a security-critical situation.

E. Quantify the effect carefully

Report observed values rather than invented industry benchmarks:

Measure	Before	After	Interpretation
Positive test cases detected	`___/___`	`___/___`	Should not lose true test cases
Negative test cases alerted	`___/___`	`___/___`	Should decrease or stay zero
Distinct source events	`___`	`___`	Dedup/identity limitations recorded
Alerts / test window	`___`	`___`	Not a substitute for accuracy
Known false positives	`___`	`___`	Must be documented examples
Mean time to disposition in lab	`___`	`___`	Not a production SOC SLA

PASS D3-L11: One documented, reversible change with before/after positive and negative evidence, clear source quality assumptions and a rollback plan. FAIL: “We filtered the admin account entirely, so noise is gone.”

Sources: [R13], [R14], [R21].

D3-L12 — Create non-playbook incident automation: safe tag + assignment (I12)

Competency: Scope low-risk automation to this one training rule, test that a real incident is tagged/assigned, and avoid loops or unintended cases. This lab deliberately excludes Logic Apps/playbooks, account disabling, endpoint isolation, network blocks and notifications to external users (covered in Day 4 only).

A. Preflight: review the trigger/action combinations

Open Microsoft Sentinel > Configuration > Automation in the Defender portal.
Select Create > Automation rule. [R15]
Choose When incident is created (or the currently available matching creation trigger) so you can use Add tags, Assign owner, and possibly Change status. Do not choose When alert is created if the intent is incident metadata: Microsoft documents Run playbook as its available action on the basic alert trigger, not arbitrary incident fields. [R15]
Decide on the exact analytic rule name condition, preferring Analytic rule name rather than just an incident title, since Defender can normalize or modify titles. If a different condition UI appears, record the actual supported condition and avoid widening the scope.
Select an actual allowed SOC owner. A display name typed without a valid principal may be rejected or cause a rule error.

B. Configure a reversible rule

Use the following desired configuration, adapting field names to the wizard when required:

Property	Intended Day 3 setting
Name	`SENTINEL-D3-LAB-Tag-And-Assign`
Trigger	When incident is created
Condition	Analytic rule name contains `SENTINEL-D3-LAB-Privileged-Source-Correlation`
Action 1	Add tag `TRAINING-D3-INTERMEDIATE`
Action 2	Assign owner a real designated instructor / SOC lab user
Action 3 (optional)	Set status `Active` only if instructor’s workflow allows it
Order / expiration	Explicitly scope/order it; select expiration/disable at cleanup where supported
Actions deliberately omitted	Run playbook, close incident, email outside lab, disable account, block IP

Save the automation rule and verify that it appears enabled only for the intended lab scope.
To test a creation trigger, generate one new bounded matched Syslog/CEF pair after ensuring the rule was created and that the scheduled analytics rule is enabled. Existing incidents do not retroactively fire a newly created creation trigger.
Wait for an actual new incident. Inspect its tag and owner; also inspect the automation execution/audit information where available.
If the same incident is grouped with an earlier one rather than a new incident being created, the creation trigger may not fire. Record the actual grouping behavior and arrange a controlled new-incident scenario if the training workspace allows it.
Test the negative path: an incident from an unrelated rule must not receive the training tag/owner because of this automation rule. Do not generate an unrelated production incident; instructor may use an already existing synthetic lab case or a documented rule-condition inspection.
Write a rollback/disable action and turn off the automation immediately after the test if the cohort does not need it for the capstone.

C. Failure cases and troubleshooting

Symptom	Check first	Do not do
Rule never fired	New incident created after automation? condition matches actual analytics rule name?	Make an unrestricted rule
No owner assigned	Valid permitted principal? connector/workspace RBAC?	Give Global Admin to everyone
Tag applied to wrong incidents	Scope, condition, rule order, case-sensitive assumptions	Ignore collateral tagging
Multiple updates/re-triggering	Using updated trigger? update loop? idempotence and conditions	Use repeated loops as test
Action unavailable	Alert vs incident trigger differences; preview conditions	Assume portal is broken

PASS D3-L12: Real new lab incident has the intended tag and valid owner (and provenance is recorded), plus negative scope reasoning and rollback. A saved automation rule without observed effect is only PARTIAL.

Sources: [R15].

D3-L13 — Build a focused, operational workbook (I13)

Competency: Create—not merely view—a custom operational workbook answering two specific questions: Is the new Linux/CEF source alive? and Is the correlation showing recent evidence?

A. Permissions and design

Verify Workbook Contributor at the destination resource-group scope (or equivalent workbook-write permission). An ordinary Sentinel incident-reader role is not automatically enough. [R16]
Choose the same workspace as L02/L03; confirm it uses a queryable tier for the tables required by the lab. Do not confuse a long-retention data-lake query with an active analytics-rule input.
Plan three workbook elements: heading, trend/volume chart, and source-health table. Optional fourth: real L06 correlation results.

B. Create a workbook in Microsoft Defender portal

Go to Microsoft Sentinel > Threat management > Workbooks and choose Add workbook. Microsoft documents this as the from-scratch creation route. [R16]
Select Edit. Add a Markdown/text section stating SENTINEL D3 — LAB DATA ONLY and the learner’s intended workspace.
Add a query control. Set Data source = Logs, Resource type = Log Analytics, then select the exact lab workspace. Some menu labels are inside an editor dialog rather than top-level navigation; record your actual version.
Paste the trend query below into the query component. Set visualization to an area, bar, or time chart if offered:

Syslog
| where TimeGenerated >= ago(24h)
| where SyslogMessage contains "SENTINEL_D3_LAB"
| summarize EventCount=count() by bin(TimeGenerated, 5m), Computer
| order by TimeGenerated asc

Run it and inspect the output before choosing a chart. If only one safe test event exists, the chart will show only a single bucket; that is valid, not a visual defect. Do not generate excessive log volume to make the graph look pretty.
Add a second query component, configured as a table, with source freshness:

Syslog
| where TimeGenerated >= ago(24h)
| where SyslogMessage contains "SENTINEL_D3_LAB"
| summarize Events=count(), LastSeenUTC=max(TimeGenerated) by Computer, Facility
| order by LastSeenUTC desc

If CEF ingestion succeeded, add a third table:

CommonSecurityLog
| where TimeGenerated >= ago(24h)
| where DeviceVendor == "AsterLab" and DeviceProduct == "Firewall"
| summarize Events=count(), LastSeenUTC=max(TimeGenerated),
            MissingSourceIP=countif(isempty(SourceIP))
     by DeviceProduct, DeviceAction
| order by LastSeenUTC desc

Optional: add a fourth results table using D3-L06’s compact correlation candidate. Ensure its query is not inadvertently scheduled as an alert; workbook queries are read-only visualizations.
Add a descriptive title/labels: Synthetic Linux data volume, Syslog last event, CEF parsing health, Correlated evidence — lab only. Choose a consistent UTC time window.
Select Done editing, then Save. Enter the exact workbook name Sentinel D3 - Source Quality and Correlation, approved subscription/resource group, and workspace association. [R16]
Close and reopen the saved workbook. Verify it appears under the correct workspace and that all controls can query without author privileges on every data source.
Where the Defender portal cannot display a supported visualization, Microsoft notes that Open in Azure may be required for some workbook features. This is an implementation exception, not a recommendation to use Azure portal for the whole course. [R16]

C. Interpretation and validation questions

Record the actual answers:

What UTC time was the last successful Syslog event received? Is it within the tested period?
Does CEF show MissingSourceIP greater than zero? If yes, what is the impact on L06 joins?
Is an empty correlation chart due to data absence, a time filter, a KQL error, or a missing connector?
Which query executes across the widest historical range? Can the workbook be bounded to reduce unnecessary queries?
If this workbook is shared, who needs workbook-reader access and workspace Log Analytics read permissions?

PASS D3-L13: New saved workbook (not a screenshot of a default template), two functional original query components with real lab output, readable labels, reopened view, and correct student interpretation. PARTIAL: workbook saved but one query fails or data source unavailable; record it honestly.

Sources: [R16].

D3-L14 — Diagnose and repair intermediate failures systematically (I14)

Competency: Trace a failure across source → network/daemon → AMA → DCR → workspace → KQL → analytic rule → incident → automation → workbook. Students must fix safe simulated faults without destroying working lab infrastructure.

A. Instructor troubleshooting decision tree

NoYesNoYesNoYesNoYesNoYesNoYesNoYesNoYesWas test emitted on Linux?logger / application / daemonDid it reach local syslog listener?protocol + host firewall + port 514Is AMA running and VM associated to DCR?agent extension + DCR resource associationCorrect facility, severity and destination?DCR streams + workspace + duplicate facilitiesRows in target table after delay?AMA diagnostics + endpoint access + parsingDoes scoped KQL return rows?time filter + schema + join keysDid rule run and create an alert?interval + lookback + TimeGenerated + thresholdIncident and automation executed?incident settings + grouping + RBAC + triggerVerify final workbook and evidence pack

B. Non-destructive Linux checks

Run on the actual collector host (approved diagnostic access required):

# Check services: no restart or configuration changes.
sudo systemctl status azuremonitoragent --no-pager
sudo systemctl status rsyslog --no-pager || true
sudo systemctl status syslog-ng --no-pager || true

# Verify relevant TCP/UDP listeners. Some routes use UNIX sockets locally.
sudo ss -lunp | grep ':514' || true
sudo ss -ltnp | grep -E '(:28330|:514)' || true

# Inspect rsyslog syntax without changing it (rsyslog systems only).
sudo rsyslogd -N1 2>&1 | tail -n 40 || true

# Find recent agent and syslog service messages (redact secrets/identifiers).
sudo journalctl -u azuremonitoragent --since '30 minutes ago' --no-pager | tail -n 60
sudo journalctl -u rsyslog --since '30 minutes ago' --no-pager | tail -n 60 || true

# Verify adequate free disk (full disk can halt logging).
df -h /

Packet inspection only when explicitly permitted and only for a short bounded duration: sudo tcpdump -ni lo udp port 514 -c 10. Do not continuously capture traffic or export payloads outside the lab. Check that test traffic actually goes to loopback or the approved private listener. Microsoft documents port 514 to syslog daemon and a local AMA forwarding port such as 28330 in relevant architectures; the exact configured endpoint must be verified on your VM. [R06]

C. Scenario-based fault tests

T01 — DCR exists but Syslog is empty

Verify the exact VM resource appears under the DCR resource associations.
Confirm AMA extension/service is healthy and that the destination workspace is correct.
Confirm collection local5 Warning+ covers the logger event; re-run one bounded logger message.
Query broad Syslog (without the marker filter), then narrow. Wait for documented processing delay.
Record root cause. Do not broaden every facility as a permanent fix.

T02 — CEF present in Syslog but not CommonSecurityLog

Check test message framing and -t CEF/syslog tag.
Compare local4 against actual received facility; verify the CEF stream Microsoft-CommonSecurityLog and its DCR association.
Verify rsyslog/syslog-ng forwarding configuration produced by the current Microsoft script.
Check the raw message for a valid CEF:0|vendor|product|version|class|name|severity|extensions envelope.
Record whether parser limitations, DCR routing, or an incorrectly generated CEF test was responsible.

T03 — Duplicate alerts / excessive rows

Count raw events in Syslog and CommonSecurityLog independently.
Inspect repeated logger tests and DCR facility overlap.
Compute join multiplicity; compare EvidencePairs to distinct source events.
Check alert-per-event versus one-alert grouping, incident grouping and rule suppression.
Apply a scoped query correction; do not ‘fix’ duplicates by simply closing all resulting incidents.

T04 — Invalid or empty KQL join

Run left and right subqueries independently and count rows in the same UTC window.
Inspect column types (SourceIP, Account, TimeGenerated, SourceUserName).
Normalize only defensible join keys (e.g., case, whitespace); do not invent missing identity.
Inspect whether both devices observed source IP from the same network vantage (NAT/proxy may differ).
Test a synthetic two-row join that must succeed, then return to the real query.

T05 — Custom scheduled rule enabled but no alert

Confirm KQL returns at least one recent real row during the intended lookback.
Ensure its final results include TimeGenerated and query scheduling lookback ≥ interval.
Confirm rule is enabled, correct workspace/table plan, no disabled incident setting, and appropriate alert threshold.
Review evaluation timing and ingestion delay; simulation alone isn’t actual alert proof.
Check whether the alert exists but is merged into an existing incident or hidden by portal filters.

T06 — Incident exists but automation didn’t apply tag

Confirm a new incident was created after automation was enabled.
Check the actual analytic rule name against the automation condition.
Confirm the trigger is incident creation, not alert creation; verify tag/owner actions are supported.
Review automation rule ordering and audit/execution details, plus owner eligibility.
Ensure incident grouping didn’t append an alert to an old incident without a creation event.

T07 — Empty custom workbook

Confirm workspace selection, query time range and connected tables.
Run the workbook KQL in Logs separately; note its actual result.
Confirm workbook reader and Log Analytics permissions; distinguish authorization failure from no results.
Verify the workbook was saved/reopened in the intended resource group.
If a visualization isn’t available in Defender, use the documented Open in Azure option if allowed.

T08 — UEBA/TI table not available

Ask whether the feature has actually been enabled and appropriate sources/feeds installed.
Check role/permissions, source dependencies and elapsed processing time; note that absence may be expected.
Use the synthetic exercise. Record feature as not verified rather than creating an unrelated broad subscription.

D. Complete a root-cause journal

Issue	Initial symptom	Reproduction	Layer causing failure	Evidence	Smallest safe correction	Re-test	Revert if needed
T01
T02
T03
T04
T05
T06
T07
T08

PASS D3-L14: Learner independently traces at least three different failure layers and records evidence for a corrected or conclusively isolated root cause. At least one must involve data collection/quality and one detection/incident stage. Do not intentionally disable shared collectors or revoke permissions to create a classroom exercise.

Sources: [R06], [R13], [R14], [R15], [R16], [R20].

3. End-of-Day 3 capstone — integrated, evidence-based examination

D3-CAP — Aster Retail: correlated privileged-source investigation

Mission: An authorized Linux application test records a fictional privileged session. An approved firewall simulator emits a matching denied-traffic CEF event. You will prove ingestion, correlate it, enrich it, build an explainable detection, tune without losing signal, route the resulting training incident safely and demonstrate monitoring. Use your actual lab evidence and do not substitute fabricated console screenshots.

Learner execution steps

Source design: State why Syslog via AMA and CEF via AMA are selected, their role boundaries, expected tables, and the no-overlap facility design. Include one alternate integration pattern for a non-Microsoft source.
Telemetry: Produce one approved Linux test event plus one CEF event (instructor-controlled if necessary); record source UTC timestamps, VM, DCR IDs, workspace, and observed row IDs/fields.
Quality: Show table-level TimeGenerated, mapped source IP/action, missing-field/duplicate/freshness analysis and any parsing caveats.
Correlation: Demonstrate a joined result that uses an explicit ten-minute window and explain why IP equality is weak without an account match or similar additional evidence.
Context: Use day3_privileged_accounts watchlist to identify the fictional high-value user and the reference-data owner. Discuss optional UEBA/TI context honestly based on availability.
Detection: Show a validated scheduled rule, low-risk lab severity, correct TimeGenerated, entity mapping, current query schedule and alert threshold; demonstrate a real alert and incident if on Track A/B.
Tuning: Test a positive and negative case, preserve query versions, document any narrow exception and rollback.
Case operations: Show a scope-limited creation automation that tags and assigns a new lab incident; produce action evidence and demonstrate safe negative scope.
Dashboard: Open the original source-health workbook and answer whether Syslog and CEF are fresh, complete and correlated.
Troubleshooting: Solve or isolate three injected/documented problems using the diagnostic decision tree.
Closeout: Disable noisy temporary artifacts and record how the instructor will remove or retain approved lab resources.

Objective rubric (100 points)

Competency	Points	Required observable evidence
Collection selection/architecture (I01–I03)	12	Correct patterns, owner, least privilege, facility separation
Working additional source + schema validation (I02–I04)	18	AMA/DCR association, real Syslog plus CEF (or approved second source), correct destination records
Intermediate KQL + correlation (I05–I06)	18	`let`/join, window, parsed fields, source-attribution caveats, negative test
Watchlist + contextual judgment (I07–I09)	12	Queryable watchlist, correct enrichment; TI/UEBA availability and interpretation
Custom scheduled detection (I10)	15	Rule, actual alert and incident, mapping, schedule, threshold, test evidence
Measured detection tuning (I11)	8	Before/after positive and negative outcomes, rollback
Low-risk metadata automation (I12)	7	New incident tagged and assigned with correct scope
New workbook (I13)	5	Reopened saved workbook, working custom queries
Troubleshooting and documentation (I14)	5	Three-layer evidence-based root cause journal
Total	100

Mandatory operational competency gates

A learner obtains Day 3 Intermediate operational PASS only when:

[ ] Score at least 80/100; and
[ ] At least one new source genuinely ingested into the workspace and its schema was validated; and
[ ] Correlation of two actual telemetry sources was demonstrated (not only datatable()); and
[ ] A queryable watchlist enrichment was shown or an explicitly approved equivalent business-context lookup demonstrated; and
[ ] A real custom scheduled detection produced a real alert and incident; and
[ ] At least one reversible false-positive/tuning change passed positive and negative testing; and
[ ] Incident metadata automation acted on a new lab incident with proper scoping; and
[ ] One custom workbook was saved/reopened and three troubleshooting layers were evidenced; and
[ ] No unsafe production activity, uncontrolled ingestion or unapproved privileged changes occurred.

Restricted Track C rule: Learners can obtain a conceptual / design completion recognition if they meet the knowledge items and score threshold, but must complete outstanding live gates before being marked operationally qualified for Advanced. One may arrange a supervised remediation test; never change the grading rule retroactively.

Instructor answer key / expected reasoning

Data connectors differ in event scope, privileges, transport, data schema and operational ownership. A connector installed from Content hub is not proof of a live event stream.
Syslog local5 and CEF local4 are a documented lab design choice, not universal facilities. DCR destination and collector must match the actual emitted record.
One real emitted event may produce a row after processing delay. The precise row count is not fixed because the cohort may repeat tests, agent/parser behavior varies, and grouping changes output.
An IP+time join is weaker than a corroborated multi-attribute link. Joined row counts can multiply; count distinct underlying source events where required.
Watchlists are governed reference data; SearchKey must match the selected CSV column. Missing lookup result is unknown context, not an automatic safe classification.
Indicators need validity, source, confidence, expiry and type; a match does not prove compromise. For 2026 use ThreatIntelIndicators, not the old table.
UEBA investigation priority and anomaly scores differ in range/meaning; anomalies demand corroboration. Synthetic CEF doesn’t magically enable UEBA.
Scheduled analytics must return source-based TimeGenerated and evaluate real records during the lookback. A saved rule or simulation alone isn’t a detected incident.
Event grouping, incident grouping and suppression are distinct controls; false-positive exclusions need controlled tests and explicit rollback.
Case metadata automation needs an incident trigger, not a basic alert trigger, for tag/owner operations; preexisting incidents are not guaranteed to fire creation automations.
Operational workbook data selection and user permissions should be verified independently. No chart result can mean a genuine zero, time mismatch or a permissions/query failure.

4. Classroom troubleshooting and evidence worksheet templates

4.1 One-page incident/detection change record

Course: Microsoft Sentinel Intermediate / Day 3
Scenario: Aster Retail — entirely fictional security observations
Rule name and exported query version:
Rule author + review/approval:
Workspace and data tier:
Data sources, DCRs, collector:
Source test timestamps (UTC):
Linux record observed (ID/marker):
CEF record observed (ID/class/vendor/product):
Join key and time window:
Corroborating identity context (or missing field):
Watchlist alias + owner + review date:
Threat indicator / UEBA status and limitations:
Before/after detection positives and negatives:
Rule schedule, lookback, threshold, grouping:
Alert ID and incident ID:
Automation rule name, trigger/condition/actions:
Action evidence (tag + owner):
Workbook name/URL or resource ID:
False-positive assumptions and open risks:
Revert plan:
Instructor signature/date:

4.2 Lab result ledger

Lab	Date/UTC	Student	Execution track	Actual result	Evidence ref	PASS/PARTIAL/BLOCKED	Instructor
L01
L02
L03
L04
L05
L06
L07
L08
L09
L10
L11
L12
L13
L14
CAP

4.3 Technical troubleshooting matrix

Observable symptom	Likely causes	First safe verification	Success criterion
Linux event absent locally	Wrong daemon, `logger` failed, host access issue	Journal, daemon, `logger` output	Test marker observable on source/daemon
Syslog table empty	AMA not installed, DCR not associated, facility mismatch	VM extension, DCR, broad Syslog query	Lab marker in target workspace
CEF not parsed	Wrong facility/stream/header/forwarder script	Raw message, port 514, `CommonSecurityLog` query	Vendor/product/source columns populated
Duplicate CEF/Syslog	DCR facility overlap, repeated test generation	DCR streams and event counts	Duplicates explained or corrected
Delay unexplained	Clock skew, ingestion pipeline, lag	UTC clocks + ingestion_time when available	Plausible evidence timeline
No KQL join	Mismatched IP/time/user, missing source	Execute sides independently	Correct positive case, negative case rejected
Watchlist no match	Wrong alias, SearchKey, casing, delayed creation	`_GetWatchlist()` + normalized keys	Intended context present
TI no table	No feed, wrong workspace, unsupported tier	Table list/connector inventory	Availability recorded correctly
UEBA empty	Feature/source not enabled, thin data, role	UEBA settings/sources/tables	No false claim of UEBA signal
Analytics no alert	Stale TimeGenerated, threshold, window, disabled rule	Saved query + interval/lookback + rule status	Actual alert ID
Alert but no incident	Incident disabled, grouping, Defender view	Rule incident settings + incident filters	Actual incident ID or documented reason
Automation silent	Old incident, rule condition/owner error	New incident UTC + rule action audit	Intended tag and owner
Workbook empty	Query/time/workspace/permissions mismatch	Run KQL in Logs, reopen workbook	Expected query component result

5. Safe laboratory cleanup and post-course handover

Cleanup order matters. Stop active detections and automations before deleting the data sources or VM. Keep the Day 1/Day 2 Sentinel workspace intact unless its owner explicitly authorized otherwise.

Step 1 — Disable lab analytics and automation

In Microsoft Sentinel > Configuration > Analytics, find exactly SENTINEL-D3-LAB-Privileged-Source-Correlation and disable it. Confirm status; do not disable unrelated rules.
In Microsoft Sentinel > Configuration > Automation, disable exactly SENTINEL-D3-LAB-Tag-And-Assign and confirm no additional lab rule remains.
If the course needs reproducible grading, export safe rule/query configuration through an approved process; remove credentials and resource identifiers before sharing externally.

Step 2 — Close/document training-only incidents

Locate incidents created by the training rule. Preserve the necessary instructor evidence and disposition.
Close according to the approved training classification (e.g., simulated/benign test activity) and record that no real compromise occurred. Follow the actual available incident classification labels in your Defender tenant; don’t invent one.
Verify automated ownership/tagging has stopped on new incidents.

Step 3 — Remove reference data and workbook (if exclusive to this lab)

Delete or retain day3_privileged_accounts only according to the course retention plan. It should not become a production privileged account authority.
Delete or retain Sentinel D3 - Source Quality and Correlation based on whether it belongs to a shared teaching library. Avoid deleting a workbook created by another cohort.
Record the names, dates, owners and decision in the artifact register.

Step 4 — Remove CEF/Syslog DCRs and extensions responsibly

Identify the exact training-created DCRs and their VM associations in Azure Monitor.
Do not delete a shared agent, shared DCR or monitoring association. If the VM is dedicated and no other sources depend on the DCR, remove the training-only associations/rules with owner approval.
Remove the training-only forwarder configuration or shut down the dedicated VM per infrastructure policy. If Microsoft’s forwarder script changed rsyslog files, remove only the generated configuration and validate the remaining daemon; do not casually overwrite system config.
Reconcile the final VM state: stopped/deallocated or deleted if exclusive to the lab. Deallocation may stop VM compute charges but persistent disks/public IP resources can still incur costs; inspect Azure Cost Management.

Step 5 — Verify post-lab safety and spending

[ ] No active Day 3 scheduled analytics rule.
[ ] No active Day 3 metadata automation.
[ ] All training incidents documented and dispositioned per lab policy.
[ ] Watchlist/workbook ownership resolved.
[ ] Temporary Linux test VM, DCRs and forwarding settings handled with owner approval.
[ ] Correct Sentinel workspace remains as planned for Days 4–5.
[ ] No unexpected collection/ingestion costs or real customer data exposure.
[ ] A final cleanup record was signed.

6. Exact syllabus-to-lab coverage audit

This table is the mechanical non-duplication and completeness crosswalk. Day 1/2 content is assumed as a prerequisite, not re-taught.

Intermediate topic	Main lab(s)	Practical objective	Evidence gate
I01 Expand data-source coverage	L01	Connector decision matrix	Chosen route + ownership
I02 Linux/network telemetry, AMA, Syslog/CEF, DCR	L02, L03	Configure approved agent/forwarder/DCR	Real target-table events
I03 Third-party and multicloud intake	L03	Select and compare AWS/GCP/firewall/app patterns	Documented integration matrix
I04 Pipeline validation	L04	Schema, timestamps, latency, duplicates	Fidelity report
I05 Intermediate KQL	L05	`let`, `join`, `union`, `extend`, `parse`, `mv-expand`, `distinct`	Eight correct query exercises
I06 Identity/infrastructure correlation	L06	Time-bounded two-source join	Positive/negative evidence
I07 Watchlist enrichment	L07	CSV → SearchKey → `_GetWatchlist` join	Enriched record + owner
I08 Threat indicators	L08	Validity, confidence, expiry, source	Live read or synthetic TI exercise
I09 UEBA introduction	L09	Enable/consume only if authorized; interpret scores	Live read or authorized substitute
I10 Custom scheduled rule	L10	KQL, mapping, threshold, lookback, incident	Real alert and incident
I11 Detection tuning/incident flow	L11	Scoped exceptions, grouping, precision proxy	Before/after test matrix
I12 Metadata automation (no playbooks)	L12	Created-incident scoped tag/assignment	New tagged/assigned incident
I13 Focused workbook	L13	Saved original source-quality visualization	Reopened functioning workbook
I14 Intermediate failures	L14	Multi-layer troubleshooting	Root-cause journal

Day 4 reserved material: ASIM-based detection engineering, detailed threat hunting/ATT&CK mapping, NRT vs scheduled/custom detection strategy, Logic Apps/playbook construction, managed identity and response approval gates. Day 5 reserved material: enterprise workspace architecture, lake/storage strategy, KQL jobs, content-as-code CI/CD, SOC metrics, health/audit operationalization and full production governance. Do not repeat those modules here.

7. Official Microsoft source register (verified for this edition)

Links below point to Microsoft Learn documentation reviewed for this manual, not to any user tenant. Microsoft can revise documentation and portal screens; before running a future cohort, re-check pages, particularly connector and licensing guidance. These are the sources for the documented procedures, not proof of a successful run in the training subscription.

Ref	Official documentation	Used for
R01	Microsoft Sentinel in the Defender portal	Primary experience, migration, limitations, UI navigation
R02	Ingest Syslog and CEF messages to Microsoft Sentinel with AMA	Connector prerequisites, DCR wizard, Linux tests, CEF examples
R03	Syslog and CEF AMA connector overview	Architecture, facility overlap and duplicate avoidance
R04	Connect data sources to Microsoft Sentinel	Connectors/selection foundations
R05	AMA supported operating systems and environments	Collector host compatibility, Azure Arc applicability
R06	Troubleshoot Syslog and CEF via AMA	Agent/rsyslog/port checks, 20-minute ingestion allowance
R07	Kusto Query Language documentation	Operator meanings and reproducible KQL exercises
R08	Use watchlists to correlate and enrich event data	`_GetWatchlist`, SearchKey, stewardship and limits
R09	Create watchlists in Microsoft Sentinel	CSV upload, alias, wizard, SearchKey
R10	Threat intelligence in Microsoft Sentinel	Modern TI lifecycle, table transitions
R11	Work with STIX objects and indicators	`ThreatIntelIndicators`/`ThreatIntelObjects` and legacy retirement
R12	Enable User and Entity Behavior Analytics	UEBA roles, setup, supported data, optional anomaly toggle
R13	Create a scheduled analytics rule	New scheduled rule wizard, mapping, `TimeGenerated`
R14	Scheduled analytics rule options and behavior	Thresholds, event grouping, interval/lookback, ingestion delay
R15	Create and use Microsoft Sentinel automation rules	Incident trigger/actions, scoping, audit, preview differences
R16	Visualize and monitor by using workbooks	New custom workbook, permissions, save/refresh
R17	ThreatIntelIndicators table schema	Validity/confidence/revocation/observable columns
R18	Advanced threat detection with UEBA	Risk score interpretation and behavior context
R19	BehaviorAnalytics table schema	UEBA field names and scoring output
R20	CommonSecurityLog schema	CEF parsed field names and meanings
R21	Microsoft Sentinel best practices	Collection, detection quality and query efficiency
R22	Threat detection in Microsoft Sentinel	Scheduled vs modern unified custom detections and guidance

2026 design note on rule engines: The syllabus explicitly asks students to author a custom scheduled analytics rule in Day 3 (I10), so that hands-on procedure is retained here. Microsoft’s newer Defender custom detections experience is relevant and may be preferable for some production deployments; a complete comparison belongs to Advanced Day 4, not a replacement of this skill requirement. [R22]

8. Final quality checklist for the training provider

[ ] This is Day 3 alone; Day 1/2 material is referenced as prerequisite, not repeated.
[ ] Every syllabus item I01–I14 has its own practical lab coverage and a PASS standard.
[ ] Instructions clearly distinguish real ingestion, in-query synthetic data and optional integrations.
[ ] Every Azure resource operation identifies the intended tenant/workspace/VM and appropriate permission.
[ ] There is no uncontrolled public syslog listener, external malicious infrastructure, credential leak or disruptive remediation.
[ ] Source and destination schemas are inspected before claiming a valid correlation.
[ ] Source-linked timestamps are retained in scheduled analytics query output.
[ ] TI and UEBA instructions describe current tables/roles and optional branches.
[ ] Rule, incident and metadata automation must have observed success, not only saved configuration.
[ ] Workbook and DCR resources have explicit cleanup owners.
[ ] Capstone grade and critical skills gate are reproducible and auditable.
[ ] Instructor verifies tenant-specific menus, licensed features and cost before classroom delivery.

End of Microsoft Sentinel Day 3 Intermediate Gold Standard Hands-On Lab Guide.

rajeshkumar