Dee’sCYBER CORNER
Project showcase

Security operations / Lab walkthrough

Recreate my
Azure honeypot lab.

A lab walkthrough showing failed login activity, KQL analysis, and incident generation in Microsoft Sentinel.

Microsoft AzureMicrosoft SentinelKQLLog Analytics

★ The lab that got me the most interview questions

Hiring managers kept asking me to walk them through this one. Being able to explain every step, from the VM to the KQL to the incident, made a real difference in my interviews.

Why I built this lab

I wanted to see real attack activity, not just read about it. A honeypot let me watch failed sign-ins arrive, investigate them with KQL, and turn what I found into a detection that creates incidents, the core of what a SOC analyst does every day.

Make it your own. This is how I did it, not the only way. Feel free to adjust the lab to your liking: change the names, tools, or scope, or take it further. What matters is that you understand what you built and why.

The environment

I built and tested a cloud environment using a Windows virtual machine in Microsoft Azure, Windows Security Logs, Log Analytics, and Microsoft Sentinel. The monitoring focus is failed authentication activity, including Windows Event ID 4625.

Monitoring architecture

  1. Azure Windows VMGenerate and observe security events.
  2. Windows Security LogsCollect authentication activity and failed logon events.
  3. Log Analytics + SentinelCentralize logs for security monitoring.
  4. KQL detectionIdentify failed authentication patterns.
  5. Analytics rule + incidentTurn detection logic into security visibility.

Follow the walkthrough

This walkthrough follows my Azure honeypot setup, event collection, investigation, and detection process.

1. Create the Azure VM

My honeypot setup used a Windows 10 VM in Azure. Create a separate lab VM and review the network security group rules for the RDP connection. Keep this learning environment separate from production systems.

2. Connect Windows Security events

Connect the VM to the Log Analytics workspace through Azure Monitor Agent and a data collection rule. Collect Windows Security events and use Microsoft Sentinel with the workspace. Confirm that events reach the SecurityEvent table before continuing.

3. Generate failed login activity

In the lab, I used repeated RDP login attempts with invalid credentials to generate Windows Security Event ID 4625. This records failed authentication activity for analysis.

My initial check used three failed sign in attempts to the employee account. These attempts verify that failed authentication events are being collected.

4. Query the events in Sentinel

I queried the SecurityEvent table for Event ID 4625 and sorted the results with the newest events first. 

SecurityEvent
| where EventID == 4625
| sort by TimeGenerated desc
Microsoft Sentinel Logs displaying a KQL query filtering SecurityEvent for Event ID 4625 and sorting by TimeGenerated
The query used to inspect failed authentication events. Click the screenshot to view it at full size.

Review the failed login results

The results show repeated Event ID 4625 records, including timestamps, account names, and the computer associated with the events. These records establish the failed login activity visible in the lab.

Microsoft Sentinel query results showing multiple Windows Security Event ID 4625 failed login records
Failed login events returned by the query. The screenshot shows records dated May 22, 2025.

5. Create the detection rule

I used the following KQL in a scheduled analytics rule. It groups failed logins by account in five minute windows and returns groups with more than five attempts. 

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

Three attempts alone do not meet this rule’s threshold. To validate the rule, generate more than five failed attempts for the same account within one five minute window in the lab.

Validate the incidents

The incident view shows two medium severity incidents from the brute force logon detection rule. This confirms that the lab progressed from collecting failed login events to generating incidents for review.

Microsoft Sentinel Incidents showing two open medium severity brute force logon detection incidents
Two medium severity incidents visible in Sentinel after the detection rule triggered.

6. Add the geolocation view

My honeypot project also used a watchlist named geoip to enrich source IPs and a workbook named map.json to show approximate locations. Match the source IPs to the watchlist data and use the enriched results in the workbook. IP geolocation gives an approximate network location, not a verified person’s location.

7. Review, troubleshoot, and clean up

If events are missing, check the agent, data collection rule, workspace, and query time range. If no incident appears, review the account grouping, five minute time window, rule threshold, and scheduled rule configuration.

When finished, remove the temporary RDP access and stop or delete the lab VM and resources you no longer need. Review the workspace retention and any resources that can continue to incur charges.

What the evidence shows

This lab demonstrates the path from failed authentication logs to KQL analysis and incident generation. The rule shown groups events by account, so it does not by itself identify a source IP or establish where an attempt originated.

This is my process. You can adapt it for your own learning environment.

Back to my project