{"id":1264,"date":"2026-11-01T07:05:52","date_gmt":"2026-11-01T07:05:52","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/?p=1264"},"modified":"2026-11-01T07:08:59","modified_gmt":"2026-11-01T07:08:59","slug":"microsoft-sentinel-advance-one-complete-end-to-end-hands-on-lab-part-4","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/microsoft-sentinel-advance-one-complete-end-to-end-hands-on-lab-part-4\/","title":{"rendered":"Microsoft Sentinel Advance: One Complete End-to-End Hands-On Lab – Part – 4"},"content":{"rendered":"\n

Module 3: Advanced | Day 4 only<\/strong> | Detection Engineering, Threat Hunting and SOAR<\/h2>\n\n\n\n
\n

Curriculum version:<\/strong> 1 November 2026
Course:<\/strong> Five-day progressive Microsoft Sentinel technical training
This manual:<\/strong> Day 4 only \u2014 syllabus competencies A01\u2013A14<\/strong>
Prerequisite:<\/strong> Demonstrated successful completion of Days 1\u20133
Primary SIEM experience:<\/strong> Microsoft Defender portal<\/a>
Format:<\/strong> Day-wise, guided technical lab manual; no hourly schedule<\/strong>
Authorized use:<\/strong> Isolated, instructor-approved environment with invented identities and data
Source basis:<\/strong> The uploaded Module 3 \u2014 Advanced<\/em> agenda, supplemented by Microsoft Learn verification (references at end)<\/p>\n<\/blockquote>\n\n\n\n

\n\n\n\n

READ FIRST \u2014 accuracy, scope, grading and safe execution<\/h1>\n\n\n\n

This is a workbook, not a proof that anything ran.<\/strong> The UI paths and product behaviors were checked against official Microsoft Learn guidance available on 1 November 2026; local KQL fixtures were checked for coherent data relationships and intended assertions. There is no authenticated test against your Azure tenant<\/strong>. Portal releases, Defender feature entitlements, region availability, enabled tables, workflow connectors, access roles and approval-provider licensing can change results. Every lab separates (a) reproducible offline\/synthetic<\/em> evidence, (b) live tenant<\/em> evidence and (c) feature-dependent alternatives. A learner may not report a cloud integration as PASS<\/strong> without directly observing its required state and logs.<\/p>\n\n\n\n

Never<\/strong> use actual compromised accounts, endpoint isolation, real firewall blocks, account disablement, unapproved tickets or privileged remediation as training actions. Use synthetic incident titles beginning D4-LAB-<\/code>, fictitious users in aster.example<\/code>, and TEST-NET example IPs (198.51.100.0\/24<\/code>, 203.0.113.0\/24<\/code>). These addresses are placeholders only<\/strong>; do not send traffic to them. Prefer manual playbook execution against a labeled incident before enabling an automatic rule. Do not expose Logic Apps connection credentials in screenshots.<\/p>\n\n\n\n

Important 2026 distinctions:<\/strong><\/p>\n\n\n\n

    \n
  1. The\u00a0Defender portal<\/strong>\u00a0is the primary UI; Microsoft says Sentinel’s Azure portal experience ends after\u00a031 March 2027<\/strong>\u00a0[R01]. You will still administer Azure resources in the Azure portal.<\/li>\n\n\n\n
  2. ASIM<\/strong>\u00a0is a query-time normalization model. A parser returning normalized fields does\u00a0not<\/strong>\u00a0imply all source vendors are covered or the events are trustworthy [R02\u2013R03].<\/li>\n\n\n\n
  3. Sentinel NRT rules<\/strong>\u00a0run once per minute and have rule-specific restrictions. Microsoft also recommends\u00a0unified custom detections<\/strong>\u00a0for eligible integrated Defender experiences;\u00a0do not equate<\/strong>\u00a0the two systems or promise equivalent licenses [R04\u2013R05].<\/li>\n\n\n\n
  4. Hunting bookmarks can be viewed but not newly created in the Defender portal<\/strong>; advanced hunting does not support the old bookmark action. Preserve a hunt with saved query text and an evidence ledger instead [R06].<\/li>\n\n\n\n
  5. Playbook trigger options now include newer case-based experiences and legacy incident options<\/strong>. The actual trigger and automation-rule compatibility depend on the tenant. Match the trigger shown in\u00a0your<\/strong>\u00a0portal, rather than mixing an incident-triggered rule with a case-triggered workflow [R07\u2013R09].<\/li>\n\n\n\n
  6. Logic Apps costs extra<\/strong>; granting Sentinel permission to run a playbook is separate from granting an engineer permission to edit it [R08].<\/li>\n<\/ol>\n\n\n\n

    Learning outcome and 5W1H contract<\/h2>\n\n\n\n
    Lens<\/th>Day 4 operational answer<\/th><\/tr><\/thead>
    What?<\/strong><\/td>ASIM, source\/parser contracts, quality-engineered detections, NRT vs scheduled, hypothesis hunts, ATT&CK, Logic Apps\/SOAR<\/td><\/tr>
    Why?<\/strong><\/td>Make heterogeneous signals comparable, reduce false attribution, test detection reliability and safely orchestrate repetitive investigation<\/td><\/tr>
    Who?<\/strong><\/td>Detection author, data steward, SOC analyst\/hunter, workflow operator, incident commander, business\/system approver<\/td><\/tr>
    When?<\/strong><\/td>Normalize when source schemas diverge; hunt when a falsifiable question exists; automate only after authorization and negative-path testing<\/td><\/tr>
    Where?<\/strong><\/td>Sentinel-enabled workspace, Defender advanced hunting\/Sentinel configuration, Azure Logic Apps resource group and approved ticket sandbox<\/td><\/tr>
    How?<\/strong><\/td>Validate parsers \u2192 detect a time-ordered sequence \u2192 test good and bad cases \u2192 hunt and record uncertainty \u2192 deploy guarded workflow \u2192 review run history<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Aster Retail \u2014 the continuing case<\/h3>\n\n\n\n

    Aster Retail (entirely fictional) has a privileged identity admin@aster.example<\/code>. A simulated sign-in, unusual firewall observation and a subsequent role grant suggest possible misuse. On Day 3 students already completed second-source ingestion, KQL joining, watchlist enrichment, a tuned rule, incident metadata and a workbook<\/strong>. On Day 4<\/strong>, the new work is normalized detections, test design, structured hunting, and approval-gated SOAR<\/strong>. Do not<\/strong> repeat Day 3’s onboarding or watchlist exercises.<\/p>\n\n\n\n

    YesNo \/ timeoutVendor-specific activityASIM parser contractMulti-stage detection KQLPositive \/ negative regression testsHypothesis-led hunt + ATT&CKLab incident \/ caseSentinel automation ruleLogic Apps playbookLab scope + approval?Non-disruptive update + auditStop; record rejection<\/pre>\n\n\n\n
    Lab tracks and definition of PASS<\/h2>\n\n\n\n
    Track<\/th>Available environment<\/th>What can be demonstrated<\/th>Allowed result<\/th><\/tr><\/thead>
    A \u2014 full lab<\/strong><\/td>Sentinel workspace, permitted test incident\/case, supported parser sources, Logic Apps and approval connector<\/td>Full ASIM \u2192 detection \u2192 hunt \u2192 playbook \u2192 run-history chain<\/td>Operational PASS if each evidence gate passes<\/td><\/tr>
    B \u2014 shared instructor lab<\/strong><\/td>Instructor operates restricted Azure resources, learners perform KQL, design and observe controlled runs<\/td>Same sequence with signed attribution of instructor-controlled steps<\/td>Competency PASS with operator attribution<\/td><\/tr>
    C \u2014 synthetic-only<\/strong><\/td>KQL editor or offline worksheets; no connector\/licensing<\/td>Fixture queries, reasoning, workflow design and fault analysis<\/td>Conceptual PASS only; not live deployment<\/strong><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Day 4 completion gate:<\/strong> An ASIM source contract; query optimization justification; a multi-stage query and positive\/negative test matrix; a falsifiable hunt and ATT&CK mapping; an approval-gated workflow; proof of approve\/reject or equivalent safe negative-path tests; permission review; and one troubleshooting report. See final rubric. An offline mock-up is valuable but not a substitute for a real Logic Apps run.<\/p>\n\n\n\n
    Required instructor preflight (before Day 4)<\/h2>\n\n\n\n