An 18-module, hands-on engineering project covering the full SOC lifecycle — infrastructure, telemetry engineering, detection development, threat hunting, attack simulation, RBAC, and automated response — built and documented end-to-end using Microsoft Sentinel and Defender XDR.
Telemetry flows from Windows and Linux endpoints through Data Collection Rules into a centralized Log Analytics Workspace, where Microsoft Sentinel drives detection, hunting, visualization, and automated response.
Every detection in this project is engineered, not just enabled — validated against live telemetry, tuned through investigation, and improved continuously.
Click any module to expand real configuration values, KQL detection logic, step-by-step execution, and analyst notes pulled directly from the project's documentation. Modules with a blue accent bar (08, 09, 10, 11) include a full deep-dive breakdown. Filter by phase below.
Establish a secure, well-structured Azure environment with proper identity management before any monitoring is possible.
| Resource Group | Pavan-ResourceGroup-Sentinel |
| Region | Central India |
| Subscription | Azure Free Trial |
| Tenant | Default Directory (Microsoft Entra ID) |
Analyst noteReviewed Microsoft Entra ID tenant configuration and RBAC principles before provisioning anything, and deliberately avoided owner-level permissions in favor of least privilege.
Deploy Microsoft Sentinel on top of a Log Analytics Workspace to establish centralized SIEM capability.
| Workspace | Pavan-LogWorkspace-Sentinel |
| Region | Central India |
| Linked Resource Group | Pavan-ResourceGroup-Sentinel |
Analyst noteExplicitly documented a key SOC concept at this stage: with Sentinel enabled but no connectors configured, zero logs are ingested and zero alerts/incidents can be generated — detection capability is entirely dependent on the connectors built next.
Integrate identity, endpoint, and threat-intelligence data sources to establish cross-domain visibility.
| Microsoft Entra ID | SigninLogs, AuditLogs — authentication & identity anomalies |
| Microsoft Defender XDR | Endpoint alerts & incidents — malware, suspicious processes |
| Threat Intelligence | Malicious IPs, domains & indicators for correlation |
Analyst noteEach connector maps to a distinct attack surface (identity / endpoint / external threat), reflecting how real SOCs layer visibility rather than relying on a single log source.
Confirm ingested data is actually queryable before building any detections on top of it.
SigninLogs
| take 10ThreatIntelIndicators
| where Confidence >= 80
| project ObservableValue, Type, Confidence, IsActive, IsDeleted, Tags
| sort by Confidence descAnalyst noteValidated 3 connectors end-to-end (SigninLogs, AuditLogs, ThreatIntelIndicators) using TimeGenerated freshness checks — establishing the discipline of validating telemetry before trusting it, used throughout the rest of the project.
Deploy cross-platform endpoints to generate real telemetry and later host attack simulations.
| Windows VM | Windows Server 2022 Datacenter (Azure Edition), Standard B2als_v2 — 2 vCPU / 4GB RAM |
| Linux VM | Ubuntu 24.04 LTS, Standard B2als_v2 — 2 vCPU / 4GB RAM |
| Agent | Azure Monitor Agent (AMA) — replaces legacy MMA |
| Data Collection | Separate DCRs per OS: Windows Security Events / Linux Syslog |
Analyst noteEvaluated Azure Arc for onboarding a personal device as a third endpoint, then deliberately rejected it — reasoning that ingesting logs from a personal machine risked exposing real user activity, and a controlled Azure VM better preserved isolation and repeatability. A documented judgment call, not just a lab step.
Validate the full pipeline from endpoint to queryable data before relying on it for detections.
Heartbeat
| summarize LastHeartbeat=max(TimeGenerated) by Computerunion SecurityEvent, Syslog
| summarize LatestLog=max(TimeGenerated) by TypeAnalyst noteEstablished the telemetry flow model used across the whole project: Endpoint → AMA → DCR → Log Analytics Workspace → Sentinel → KQL — and validated Windows Security Events, Linux Syslog, and Heartbeat independently before moving to detection engineering.
Onboard a non-native log source using the modern Azure Monitor ingestion pipeline — engineering beyond default connectors.
| Auth | Microsoft Entra ID App Registration → OAuth 2.0 Client Credentials |
| IAM Role | Monitoring Metrics Publisher on the DCR |
| Pipeline | Postman → Bearer Token → DCE → DCR → Custom Table |
| Custom Table Schema | TimeGenerated, User, Activity, ip_address, destination_ip, Profile |
| API Result | HTTP 204 No Content — ingestion accepted |
CustomDataIngestionTable_CL
| where TimeGenerated > ago(7d)
| project TimeGenerated, User, Activity, ip_address, destination_ip, ProfileCustomDataIngestionTable_CL
| where Activity contains "Failed Login"
| project TimeGenerated, User, ip_addressAnalyst noteThis module is the clearest signal of engineering depth in the repo: building a full DCE/DCR/App-Registration/OAuth pipeline manually mirrors how real-world SOCs onboard proprietary or legacy log sources that don't have an out-of-the-box Sentinel connector.
Build a KQL-based scheduled detection with full MITRE mapping, entity enrichment, and a validated end-to-end alert-to-incident pipeline.
| Rule Name | More than 5 failed login attempts under a minute | Windows |
| Severity | High |
| MITRE Tactic / Technique | Credential Access — T1110 Brute Force |
| Schedule | Runs every 5 min · looks back 5 min · starts automatically |
| Entity Mapping | Account → Account · Host → WorkstationName · Process → ProcessName |
SecurityEvent
| where EventID == 4625
| project TimeGenerated, Account, EventID, TargetDomainName, ProcessName, WorkstationName
| summarize count() by Account, WorkstationName, ProcessName, EventID, bin(TimeGenerated, 1m)
| where count_ >= 3Analyst noteValidated the complete pipeline live end-to-end rather than trusting the configuration screen: generated genuine EventID 4625 failures on the Windows VM and confirmed the rule fired and an incident materialized in Sentinel — closing the loop from raw telemetry to actionable alert.
Detect Windows log-clearing (anti-forensics) activity in near real-time — which required correctly diagnosing a Sentinel table-mapping gap first.
| The Problem | The existing "Windows Security Events via AMA" connector ingests to SecurityEvent — but Event ID 104 (log cleared) lives in the separate Event table |
| The Fix | Created a dedicated DCR — dcr-windowseventlog — collecting System, Application & Security event log channels into the Event table |
| Rule Name | Log cleared on critical asset | Windows Server |
| Severity | High |
| MITRE Tactic / Technique | Defense Evasion — T1070 Indicator Removal on Host |
| Entity Mapping | Hostname → Computer · LogType (custom) → RenderedDescription |
Event
| where EventID == 104
| sort by TimeGenerated descEvent
| where Computer contains "Pavan-VM-Window"
| where EventID == 104
| project TimeGenerated, Computer, RenderedDescription, EventID, EventLevelAnalyst noteThis module is a genuine debugging story, not just a configuration walkthrough: the analyst correctly recognized that a default connector's silent table-mapping gap meant a real detection blind spot, then engineered around it — exactly the kind of root-cause thinking a hiring panel wants to hear described.
Run a complete SOC-style triage — investigation, advanced hunting, and formal resolution — on the brute-force incident generated in Module 08.
| Affected Device | Pavan-VM-Window |
| Affected User | Pavan-VM-Window\Pavan |
| Hunting Tables Used | AlertInfo · AlertEvidence · SecurityEvent · SecurityAlert · SecurityIncident |
| Final Classification | Benign Positive — Security Testing / Lab Activity, Incident Closed |
AlertInfo
| where TimeGenerated >= ago(5d)
| where Title contains "failed login"
| project Timestamp, Title, Severity, ServiceSource, DetectionSourceAlertInfo
| where TimeGenerated >= ago(5d)
| join kind=inner AlertEvidence on AlertId
| where DeviceName contains "Pavan-VM-Window"
| project Timestamp, Title, Severity, DeviceName, AccountNameSecurityEvent
| where Account == @"Pavan-VM-Window\Pavan"
| where EventID in (4624, 4625)
| project TimeGenerated, EventID, Account, Computer, IpAddress, LogonTypeNameSecurityEvent
| where Account == @"Pavan-VM-Window\Pavan"
| where EventID in (4624, 4625)
| summarize Events=count() by EventIDSecurityAlert
| where CompromisedEntity contains "Pavan"
| project TimeGenerated, AlertName, AlertSeverity, StatusAnalyst noteAdvanced hunting across five different tables found no evidence of compromise, persistence, or lateral movement — and the write-up documents that negative finding explicitly with the queries that produced it, rather than leaving it assumed. That's exactly what a defensible incident closure looks like to an auditor or a hiring panel.
Build 5 SOC-facing dashboards for operational visibility, each combining a specific KQL query with a deliberately-chosen visualization type.
| 01 · Failed Login Monitoring | SecurityEvent → Time Chart (failed-login timeline) + Bar Chart (top targeted accounts) + Grid (latest failed events) |
| 02 · Incident Management | SecurityIncident → Pie (severity split) + Time Chart (incident volume) + Grid (ownership/status) + Bar + Pie |
| 03 · Security Events | SecurityEvent / Event → Event ID distribution & log-clearing visibility |
| 04 · Alert Monitoring | SecurityAlert → analytics rule activity & affected entities |
| 05 · VM Activity | SecurityEvent → host-level authentication behavior |
SecurityEvent
| where EventID == 4625
| summarize FailedAttempts=count() by bin(TimeGenerated, 5m)SecurityEvent
| where EventID == 4625
| summarize FailedAttempts=count() by Account
| top 10 by FailedAttempts descAnalyst noteEach workbook deliberately pairs a specific chart type to the question it answers — a time chart for trend/spikes, a bar chart for ranking top offenders, a grid for raw event detail — mirroring how a SOC lead would want operational visibility structured rather than dumped into one raw table.
Reduce manual analyst effort through incident lifecycle automation.
| Auto-Assign Incidents | Brute-force related incidents auto-assigned to the SOC analyst on creation |
| High-Severity Tagging | High-severity incidents auto-tagged for prioritized triage |
| Auto-Close Low Severity | Expected/benign RDP activity auto-classified and closed |
Analyst noteDistinguishes between incidents that need a human (auto-assign, auto-tag) and incidents that don't (auto-close) — the core judgment call behind any real SOC automation strategy.
Extend automation into full SOAR territory with orchestrated response actions.
| Email Notification Playbook | O365 Outlook connector — sends analyst email on new incident, using dynamic incident content |
| Incident Enrichment Playbook | Auto-adds investigation comments/context to incidents |
| Identity | Managed Identity + RBAC — no hardcoded credentials |
Analyst notePlaybooks are triggered by Automation Rules, not manually — meaning response actions fire automatically the moment a matching incident is created.
Build IOC-driven and behavior-driven detections using custom Sentinel Watchlists.
| Suspicious IP Watchlist | Configured a full GUI (XFCE + XRDP) on the headless Linux attacker VM to simulate a realistic attacker workstation, then correlated its public IP against SecurityEvent auth logs |
| Suspicious PowerShell Watchlist | Custom CSV of suspicious command patterns correlated against PowerShell Operational logs |
Analyst noteBuilding a GUI on the attacker VM specifically to generate more realistic attacker telemetry (rather than just running commands headlessly) shows attention to simulation fidelity.
Extend detection from host telemetry into full network visibility across IDS, firewalls, and threat hunting.
| Suricata IDS/IPS | Deployed on Linux, custom rule authoring (ICMP/RDP/exfil detection), fast.log & eve.json alert analysis, forwarded to Sentinel |
| Linux Telemetry | UFW firewall logging + blocked-traffic analysis |
| Windows Telemetry | Windows Firewall logging + Filtering Platform event analysis |
| Network Threat Hunting | Port scanning, unauthorized connections, suspicious external IPs, and lateral movement (SSH/RDP) hunted across both OSes |
Analyst noteThe lateral movement hunting module traces a full attacker session: failed SSH attempts → successful login → privilege escalation & recon → account creation → staging directory creation — validated with 7 chained KQL queries.
Implement least-privilege access control end-to-end across Azure and Sentinel.
| RBAC Fundamentals | Built-in roles, scopes & authorization flow (Security Principal + Role Definition + Scope) |
| Sentinel Roles | Reader / Responder / Contributor validated with real permission-denied tests |
| Custom RBAC Roles | Purpose-built least-privilege role — validated with a successful VM operation AND a deliberate permission-denied test |
| Service Principals | App Registration → CLI login as SP → RBAC validation |
| Managed Identities | System-assigned identity — az login --identity, zero stored secrets |
| Permission Delegation | Scope inheritance & effective-permissions analysis |
Analyst noteEvery RBAC module includes a negative test (a permission-denied case), not just a successful one — proving the access boundary actually holds rather than just assuming the configuration is correct.
Learn portable, cross-SIEM detection engineering from first principles through a full credential-dumping detection chain.
| 01 — Fundamentals | Sigma rule anatomy, SigmaHQ repository structure, rule review checklist |
| 02 — Build & Convert | sigma-cli installation, custom rule authoring & modification, Sigma → KQL conversion |
| 03 — Deploy & Validate | Official SigmaHQ rule converted to KQL, tuned, deployed as a Scheduled Analytics Rule, validated end-to-end to alert + incident |
| 04 — LSASS Targeting | Sysmon Event ID 10 (Process Access) → Sigma "LSASS Process Targeting" → T1003.001, including a documented noise/tuning observation |
| 05 — LSASS Credential Dumping (End-to-End) | Mimikatz executed in an isolated lab → Sigma "Mimikatz Command-Line Detection" (High) + "LSASS Process Targeting" (Medium) fire as two independent, layered detections covering different stages of the same attack |
Analyst noteModule 05 is the capstone of the whole repo: it proves layered detection coverage — showing that a single attack (credential dumping) can and should be caught by more than one independent rule, at more than one stage.
Five realistic, MITRE-mapped attack chains — each executed end-to-end in an isolated lab (attacker + victim VMs), mapped to the Cyber Kill Chain, and validated against live Sentinel detections.
A suspicious PowerShell payload was staged on the Linux attacker VM, transferred to the Windows victim over SCP, then remotely executed via SSH — emulating an attacker who already has remote access staging a payload without malware, persistence, or destructive behavior.
Detection signalCorrelated against a custom suspicious_powershell_watchlist using has_any() pattern matching on PowerShell Operational logs — a behavior-based detection rather than a static signature.
Simulated a compromised host beaconing outbound to attacker-controlled infrastructure using a Netcat listener as a stand-in C2 server. Sysmon was deployed for process + network telemetry, and a custom Threat Intelligence watchlist represented known-bad C2 infrastructure for correlation.
Detection signalSysmon Event ID 3 (network connection) ingested via AMA and correlated against a custom C2-IP watchlist to flag the outbound callback in near real time.
A social-engineering pretext led the victim to execute a Stage-1 PowerShell payload, which abused certutil.exe — a trusted, signed Windows binary — to retrieve and execute a Stage-2 payload hosted on a Python HTTP server, evading naive signature-based detection.
Detection signalSysmon process-creation telemetry flagged certutil.exe making outbound HTTP connections to download a non-certificate payload — a classic LOLBins detection pattern (trusted binary, abnormal behavior).
Recreated the modern 'ClickFix' social-engineering technique end-to-end: a fake Microsoft Teams voicemail notification redirects to a fake Cloudflare human-verification page, which instructs the victim to paste and run a command via the Windows Run dialog — detected through RunMRU registry-key forensics rather than process telemetry alone.
Detection signalCustom analytics rule built specifically around Sysmon Event ID 13 (Registry Value Set) targeting the RunMRU key — proving user-driven execution occurred, which process telemetry alone can miss if the payload is short-lived.
The capstone simulation: chains the ClickFix pretext into a full delivery pipeline — PowerShell downloads and executes a payload from a Linux staging server, performs host discovery, drops local artifacts, and generates outbound beacon traffic — validated end-to-end against Sentinel incidents across every stage from T0 to T10.
Detection signalDeliberately validated that detections fire at multiple independent stages of the same kill chain (delivery, execution, discovery, C2) rather than relying on a single choke point — the same layered-detection philosophy used in the Sigma/LSASS capstone (Module 18).
17 techniques across 7 tactics — actually implemented and detected across the attack simulation and Sigma detection engineering modules, not a theoretical mapping.
A 35-table reference (including the "Top 15 for SC-200") compiled while building this project — search to filter by table, source, or purpose.
| Table | Source | Data Stored |
|---|---|---|
| SigninLogs | Entra ID | Interactive user sign-ins, MFA, authentication results, IP addresses, locations |
| AADNonInteractiveUserSignInLogs | Entra ID | Token refreshes, service sign-ins, background authentications |
| AuditLogs | Entra ID | User, group, application, role, and policy changes |
| IdentityInfo | UEBA / Entra ID | User attributes, department, manager, job title |
| BehaviorAnalytics | UEBA | User/entity risk observations, anomalies, investigations |
| SecurityAlert | Sentinel / Defender | Security alerts generated by analytics rules and security products |
| SecurityIncident | Sentinel | Incidents created from alerts |
| ThreatIntelligenceIndicator | Threat Intel Feeds | Malicious IPs, domains, URLs, and file hashes |
| Heartbeat | Azure Monitor Agent | Agent health and machine reporting status |
| CommonSecurityLog | Firewalls / IDS/IPS | Firewall events, allow/deny actions, network traffic |
| Syslog | Linux Systems | Linux logs, SSH, sudo, daemon events |
| Event | Windows Event Logs | Windows Security, System, and Application logs |
| SecurityEvent | Windows Security Log | Logons, account changes, process activity, privilege use |
| WindowsEvent | Azure Monitor Agent | Modern Windows event collection |
| DeviceEvents | Defender for Endpoint | Process, registry, file, and service activity |
| DeviceProcessEvents | Defender for Endpoint | Process creation and execution details |
| DeviceNetworkEvents | Defender for Endpoint | Network connections from endpoints |
| DeviceFileEvents | Defender for Endpoint | File creation, deletion, and modification |
| DeviceRegistryEvents | Defender for Endpoint | Registry modifications |
| DeviceLogonEvents | Defender for Endpoint | Endpoint logon activities |
| DeviceInfo | Defender for Endpoint | Device inventory and metadata |
| EmailEvents | Defender for Office 365 | Email delivery and processing events |
| EmailAttachmentInfo | Defender for Office 365 | Email attachment details |
| EmailUrlInfo | Defender for Office 365 | URLs found in emails |
| CloudAppEvents | Defender for Cloud Apps | SaaS activity, file sharing, downloads |
| IdentityLogonEvents | Defender for Identity | Authentication events from on-premises Active Directory |
| IdentityQueryEvents | Defender for Identity | LDAP queries and reconnaissance activity |
| IdentityDirectoryEvents | Defender for Identity | Active Directory object modifications |
| AzureActivity | Azure Subscription | Azure control-plane operations |
| AzureDiagnostics | Azure Resources | Resource-specific diagnostic logs |
| OfficeActivity | Microsoft 365 | SharePoint, OneDrive, Teams, and Exchange activities |
| AWSCloudTrail | AWS | AWS API activity logs |
| AWSGuardDuty | AWS GuardDuty | AWS threat detection findings |
| GCPAuditLogs | Google Cloud Platform | GCP audit events |
| DnsEvents | Defender for Endpoint / DNS | DNS queries and responses |