🛡️ Azure Sentinel SIEM Lab

Building a cloud-native Security Operations Center (SOC) environment using Microsoft Sentinel to simulate real-world threat detection and incident response workflows.

---

📋 Project Overview

This lab demonstrates the setup and configuration of a fully functional SIEM environment in Azure. The goal is to simulate enterprise-level security monitoring, including log ingestion from multiple sources, custom KQL detection rules, automated incident creation, SOAR playbooks with email alerting, and a live SOC dashboard.

🎯 Objectives

• ✅ Deploy a Microsoft Sentinel workspace connected to a Windows VM log source
• ✅ Configure Azure Monitor Agent (AMA) via Data Collection Rules
• ✅ Write custom KQL detection rules for brute force attack patterns
• ✅ Create Analytics Rules that automatically generate Incidents
• ✅ Simulate a brute force attack and detect it in real-time
• ✅ Build incident response playbook using Azure Logic Apps (SOAR)
• ✅ Configure automated email alerting via Outlook when incidents are detected
• ✅ Add additional KQL detection rules (privilege escalation, new user creation)
• ✅ Create custom SOC dashboard (Workbook)

🛠️ Technologies Used

Technology	Purpose
Microsoft Sentinel	SIEM / SOAR platform
Azure Log Analytics	Log ingestion & querying
KQL (Kusto Query Language)	Custom detection rules
Azure Monitor Agent (AMA)	Log collection from VM
Azure Logic Apps	Automated incident response (SOAR)
Outlook / Office 365	Email alert delivery
Windows Server 2022	Log source (attack simulation)
Microsoft Defender Portal	Incident management

🏗️ Lab Architecture

Windows Server 2022 VM
        │
        ▼
Azure Monitor Agent (AMA)
        │
        ▼
Log Analytics Workspace (sentinel-lab-workspace)
        │
        ▼
Microsoft Sentinel
        │
   ┌────┴────────────────────┐
   ▼                         ▼
KQL Analytics Rules     Automation Rule
        │                    │
        ▼                    ▼
    INCIDENTS          Logic App Playbook
                             │
                             ▼
                    📧 Email Notification
                    (Outlook - High Importance)

📁 Repository Structure

azure-sentinel-siem-lab/
├── README.md
├── docs/
│   └── screenshots/          # Step-by-step documentation screenshots
├── kql-queries/
│   └── detection-rules.md    # All KQL detection rules
└── playbooks/
    └── incident-response.md  # SOAR playbook documentation

---

🚀 Lab Walkthrough

Phase 1 — Azure Infrastructure Setup

Step 1: Log Analytics Workspace Deployment

Deployed sentinel-lab-workspace as the central data store where all logs are ingested and queried. Resource Group sentinel-lab-rg created in West Europe.

---

Step 2: Microsoft Sentinel Enabled

Enabled Microsoft Sentinel on top of the Log Analytics Workspace. Overview shows clean state — 0 incidents, 0 data connectors, ready to configure.

---

Step 3: Data Connectors — Empty State

Confirmed the Data Connectors page starts with 0 connected sources before configuration.

---

Phase 2 — Data Collection

Step 4: Windows Security Events Connector

Located the Windows Security Events solution in the Content Hub. Includes 2 data connectors, 20 analytics rule templates, 2 workbooks, and 50 hunting queries.

---

Step 5: Windows Server VM Deployment

Deployed sentinel-windows-vm — Windows Server 2022 Datacenter, Standard B2ts v2, West Europe, with RDP enabled and auto-shutdown at 11:00 PM.

All lab resources visible in the All Resources view: workspace, VM, network interfaces, storage.

---

Step 6: Data Collection Rule (DCR)

Created windows-security-events-dcr to automatically install Azure Monitor Agent on the VM and stream All Security Events to the workspace.

---

Phase 3 — Threat Detection

Step 7: RDP Connection & Log Verification

Connected to the VM via RDP. Server Manager Local Server confirms connection to sentinel-window (IP 51.124.185.72).

Windows Event Viewer Security log showing EventID 4688 (Process Creation) — confirms security auditing is active.

EventID 4625 (Audit Failure) and EventID 4724 visible alongside CMD prompt showing failed net user labadmin wrongpassword123 attempts.

EventID 4625 detail — runas /user:fakeuser cmd generating failed logon events.

---

Step 8: KQL — Logs Flowing into Sentinel

Confirmed SecurityEvent table populated — 39 results (1,000 results shown) from sentinel-window in the last 24 hours.

Verification KQL:

SecurityEvent
| where EventID == 4625
| project TimeGenerated, Account, Computer, EventID, Activity
| order by TimeGenerated desc

4 EventID 4625 results confirmed from sentinel-window\fakeuser.

---

Step 9: Analytics Rule — Brute Force Detection

Defender Analytics starts empty — 0 active rules.

New Scheduled rule created using the Analytics rule wizard:

Rule: Brute Force - Multiple Failed Logons configured with name, description, High severity, MITRE ATT&CK T1110.

KQL query and scheduling configured — runs every 5 minutes, looks back 5 minutes, threshold > 0:

SecurityEvent
| where EventID == 4625
| summarize FailedAttempts = count() by Account, Computer, bin(TimeGenerated, 5m)
| where FailedAttempts >= 5

Review confirms all settings — Brute Force, High, T1110, 5min frequency, Alert grouping Enabled.

Rule saved — 1 Active rule confirmed. Toast: "Analytics rule 'Brute Force - Multiple Failed Logons' saved successfully."

---

Phase 4 — Incident Response

Step 10: Brute Force Attack Simulation

Simulated brute force with repeated runas /user:fakeuser cmd failing — "The user name or password is incorrect" in a continuous loop.

for /L %i in (1,1,20) do runas /user:fakeuser cmd

Sentinel confirmed 55 EventID 4625 events from sentinel-window\fakeuser.

---

Step 11: Incident Auto-Generated

Microsoft Sentinel automatically created a High severity Incident — "Brute Force - Multiple Failed Logons".

Incident details: Account sentinel-window\fakeuser, 24 FailedAttempts, Credential Access category.

---

Phase 5 — Automation (SOAR)

Step 12: Logic App Deployment

Deployed sentinel-brute-force-playbook Logic App in sentinel-lab-rg, West Europe.

Logic App Overview — 0 triggers, 0 actions, Stateful workflow, Enabled.

---

Step 13: Logic App Designer — Trigger & Actions

Empty designer — "Add a trigger" ready for configuration.

Microsoft Sentinel incident trigger added — connected to live.com#[email protected] via OAuth.

Create connection panel — OAuth authentication, Default Directory tenant.

Gmail (SOC-ALERT) connection attempted first — [email protected] connected.

Note: Gmail connector is blocked by Microsoft policy when combined with Sentinel (GmailConnectorPolicyViolation). Switched to Outlook.com.

Gmail email body configured with dynamic Sentinel fields (Incident Title, Severity, Status, Created Time UTC).

Final configuration switched to Outlook Send an email (V2) — [email protected], dynamic fields, connected to Outlook.com.

---

Step 14: Playbook Saved

Logic App saved successfully. Notification: "Successfully saved workflow 'sentinel-brute-force-playbook'". Final flow: [Microsoft Sentinel incident] → [Send an email (V2)].

---

Step 15: Sentinel Permissions & Automation Rule

Automation page — 0 rules, 1 enabled playbook.

Granted Sentinel permissions to run playbooks by selecting sentinel-lab-rg.

Created Automation Rule "Brute Force - Run Playbook":

• Trigger: When incident is created
• Condition: Analytic rule name Contains "Brute Force - Multiple Failed Logons"
• Action: Run playbook → sentinel-brute-force-playbook
• Expiration: Indefinite, Order: 1

Automation Rule active — 1 rule, 1 enabled rule, 1 enabled playbook confirmed.

---

Step 16: End-to-End Validation

Second brute force simulation to test the full automation chain:

for /L %i in (1,1,20) do runas /user:fakeuser cmd

Logic App Run history — 2 successful runs (9:28 PM and 9:23 PM, both Succeeded).

Automated email received in Outlook inbox — High importance, all dynamic fields populated:

• Subject: 🚨 Sentinel Alert: Brute Force Incident Detected
• Incident Title: Brute Force - Multiple Failed Logons
• Severity: High
• Status: New
• Time: 2026-03-30T18:26:14.8833333Z
• Message: "Please investigate immediately in Microsoft Sentinel."

Full SOAR chain validated: Attack → Sentinel detection → Incident created → Automation Rule triggered → Logic App executed → Email delivered ✅

---

Phase 6 — Additional KQL Detection Rules

Step 17: Three Additional Analytics Rules

---

Rule 1 — Successful Login After Multiple Failures

Detects a successful logon (EventID 4624) from an account that previously generated 3+ failed logons (EventID 4625) within 1 hour. High-fidelity indicator of a completed brute force attack.

let FailedLogins = SecurityEvent
| where EventID == 4625
| where TimeGenerated > ago(1h)
| summarize FailedCount = count() by Account, IpAddress = IpAddress
| where FailedCount >= 3;
SecurityEvent
| where EventID == 4624
| where TimeGenerated > ago(1h)
| join kind=inner FailedLogins on Account
| project TimeGenerated, Account, IpAddress, FailedCount, Computer
| order by TimeGenerated desc

• Severity: High | MITRE: Credential Access / T1110
• Frequency: Every 5 min | Lookup: Last 1 hour

Analytics dashboard showing 2 active rules — Rule 1 selected with full details panel visible.

---

Rule 2 — New User Account Created

Detects creation of a new local user account (EventID 4720). Common persistence technique after initial compromise.

SecurityEvent
| where EventID == 4720
| project TimeGenerated, Account, Computer, EventID
| order by TimeGenerated desc

• Severity: Medium | MITRE: Persistence / T1136 - Create Account
• Frequency: Every 5 min | Lookup: Last 1 hour

Analytics dashboard showing 3 active rules — Rule 2 saved with toast notification "Analytics rule 'New User Account Created' saved successfully."

---

Rule 3 — User Added to Admin Group

Detects when a user is added to the local Administrators group (EventID 4732). Privilege escalation indicator.

SecurityEvent
| where EventID == 4732
| project TimeGenerated, Account, Computer, EventID
| order by TimeGenerated desc

• Severity: High | MITRE: Privilege Escalation / T1078 - Valid Accounts
• Frequency: Every 5 min | Lookup: Last 1 hour

Note: Rule 3 screenshot was not captured separately — it is visible as the 3rd active rule in the Analytics list (screenshot 49 shows 3 active rules).

---

Step 18: Attack Simulation — All Rules

Stage 1 — Brute force (net use against localhost, triggering Brute Force rule):

for /L %i in (1,1,10) do net use \\localhost\IPC$ /user:testuser wrongpassword 2>nul

Stages 2 & 3 — New user + privilege escalation:

net user hacker P@ssword123! /add
net localgroup Administrators hacker /add

Full attack chain visible — brute force loop (labadmin + LabAdmin@2025!), followed by net user hacker /add and net localgroup Administrators hacker /add.

---

Step 19: Incident Investigation

Brute Force alert details — query results show 8 items: administrator (60 failed attempts), user (15), scans (6), confirming mass authentication attempts detected.

All three incident types generated — User Added to Admin Group (High, Privilege escalation), New User Account Created (Medium, Persistence), Brute Force - Multiple Failed Logons (High, Credential access).

Also confirmed: Brute Force incidents list showing multiple detections over 1 week (Incident IDs 1 and 2).

Note on Rule 1: The net use simulation did not produce matching EventID 4625 + 4624 pairs for the same account under NTLM. The rule logic is valid and would fire correctly in a real network brute-force scenario.

---

Phase 7 — SOC Dashboard

Step 20: Custom Workbook — SOC Dashboard

Built "SOC Dashboard - Azure Sentinel Lab" with 4 live visualization panels via Sentinel Workbooks JSON editor:

Panel	Type	What it shows
Incidents by Severity	Donut chart	High (19) vs Medium (6) — Total 25
Incidents Over Time	Time chart	Attack spike timeline Mar 29–30
Top 10 Failed Login Accounts	Bar chart	sentinel-window\administrator — 605 attempts
Recent Incidents	Table	Latest incidents: "User Added to Admin Group", High, New

---

✅ Progress Checklist

Phase 1 — Infrastructure Setup

• Azure subscription & resource group (sentinel-lab-rg)
• Log Analytics Workspace (sentinel-lab-workspace)
• Microsoft Sentinel enablement

Phase 2 — Data Collection

• Windows Security Events connector (Content Hub)
• Windows Server 2022 VM (sentinel-windows-vm)
• Azure Monitor Agent via Data Collection Rule
• All Security Events ingestion confirmed

Phase 3 — Threat Detection

• KQL query for EventID 4625 (Failed Logon)
• Analytics Rule — Brute Force (5+ attempts / 5 min)
• MITRE ATT&CK mapping (T1110)

Phase 4 — Incident Response

• Brute force simulation (20+ failed logins)
• Real-time incident generation & investigation

Phase 5 — Automation (SOAR)

• Azure Logic App deployed (sentinel-brute-force-playbook)
• Microsoft Sentinel incident trigger (OAuth)
• Outlook email action with dynamic incident fields
• Sentinel permissions granted (sentinel-lab-rg)
• Automation Rule: "Brute Force - Run Playbook"
• End-to-end validated: attack → incident → email ✅

Phase 6 — Additional Detection Rules

• Successful Login After Multiple Failures (T1110)
• New User Account Created (T1136)
• User Added to Admin Group (T1078)
• All rules tested with live VM simulation

Phase 7 — SOC Dashboard

• Incidents by Severity (donut chart)
• Incidents Over Time (time chart)
• Top 10 Failed Login Accounts (bar chart)
• Recent Incidents (table)
• Saved as "SOC Dashboard - Azure Sentinel Lab"

---

🔑 Key KQL Queries

Failed Logon Detection

SecurityEvent
| where EventID == 4625
| project TimeGenerated, Account, Computer, EventID, Activity
| order by TimeGenerated desc

Brute Force Detection (5+ attempts in 5 minutes)

SecurityEvent
| where EventID == 4625
| summarize FailedAttempts = count() by Account, Computer, bin(TimeGenerated, 5m)
| where FailedAttempts >= 5

Successful Login After Multiple Failures

let FailedLogins = SecurityEvent
| where EventID == 4625
| where TimeGenerated > ago(1h)
| summarize FailedCount = count() by Account, IpAddress = IpAddress
| where FailedCount >= 3;
SecurityEvent
| where EventID == 4624
| where TimeGenerated > ago(1h)
| join kind=inner FailedLogins on Account
| project TimeGenerated, Account, IpAddress, FailedCount, Computer
| order by TimeGenerated desc

New User Account Created

SecurityEvent
| where EventID == 4720
| project TimeGenerated, Account, Computer, EventID
| order by TimeGenerated desc

User Added to Admin Group

SecurityEvent
| where EventID == 4732
| project TimeGenerated, Account, Computer, EventID
| order by TimeGenerated desc

---

🗺️ MITRE ATT&CK Coverage

Tactic	Technique	Detection Rule
Credential Access	T1110 - Brute Force	Brute Force - Multiple Failed Logons
Credential Access	T1110 - Brute Force	Successful Login After Multiple Failures
Persistence	T1136 - Create Account	New User Account Created
Privilege Escalation	T1078 - Valid Accounts	User Added to Admin Group

---

📌 What I Learned

• How to deploy and configure Microsoft Sentinel from scratch in Azure
• How Azure Monitor Agent (AMA) collects and forwards Windows Security Events
• How to write KQL queries for real-time security event analysis
• How Analytics Rules automate threat detection and incident creation
• How to build SOAR playbooks with Azure Logic Apps for automated response
• How to integrate Sentinel with Outlook to deliver email alerts with dynamic incident data
• How to simulate real attack scenarios (brute force, persistence, privilege escalation) and verify detection
• How to build live SOC dashboards using Sentinel Workbooks
• The complete SOC workflow: log ingestion → KQL detection → incident → SOAR → email alert

---

Part of my cybersecurity portfolio — evank95.github.io/My-CV-Page