Left the Door Open on Purpose: Building a Live Honeypot and Watching the World Try to Walk Through…

Deploying Microsoft Sentinel, exposing a VM to the internet, and observing real-world RDP brute force attacks from across the globe, and what it taught me about SIEM, log ingestion, and how fast the internet finds an open door.

DISCLAIMER: This lab was built entirely within a personal Azure subscription using a deliberately exposed virtual machine for educational purposes. The honeypot VM was isolated, monitored, and decommissioned after the lab was complete. The PowerShell script used for geolocation enrichment was sourced from Josh Madakor's tutorial, which I'd recommend to anyone looking to get hands-on with Microsoft Sentinel for the first time. This write-up is published for educational purposes, intended for security students, blue teamers, and SOC analysts who want to understand what real attack telemetry looks like before they have to triage it in production.

Overview

Most cybersecurity labs simulate attacks. You spin up a vulnerable machine, run a tool against it yourself, and observe the output. Clean, controlled, predictable.

This one is different.

This lab uses a deliberately exposed Windows 10 virtual machine, a honeypot, connected to Microsoft Sentinel, Microsoft's cloud-native SIEM, to observe real, unsolicited attack traffic from across the internet. No simulated attackers. No scripted scenarios. Just a VM with an open attack surface sitting on a public IP, and the internet doing what it always does when it finds one.

Within hours of dropping the firewall, the attempts started rolling in. RDP brute force attacks from across Europe, automated scanners probing for credentials, all of it logged, enriched with geolocation data via a custom PowerShell script, and visualized on a live world map inside Microsoft Sentinel.

For anyone doing SOC work, (or trying to get there) this lab is about as close to a production threat landscape as you can build on a personal Azure account.

Background: What Is a Honeypot?

A honeypot is a system that is intentionally made vulnerable and exposed to attract attackers. It has no legitimate users, no real business function, and no data worth protecting. Its entire purpose is to be a target, and to log everything that happens when threat actors or automated tools find it and start probing it.

Honeypots have been used in enterprise security for decades as a way to study attacker behavior, generate threat intelligence, and detect lateral movement inside networks. In this lab, the honeypot is a Windows 10 VM running on Azure with a public IP address and no inbound firewall rules. Essentially a sign that says "open for business" to every scanner and brute force tool on the internet.

The value of a honeypot isn't what's inside it. It's what the traffic to it tells you about who's looking.

Background: What Is RDP Brute Force?

Remote Desktop Protocol (RDP) is a Microsoft protocol that allows users to connect to and control a Windows machine remotely over a network. It runs on port 3389 by default and is widely used in enterprise environments for remote administration.

RDP brute force is exactly what it sounds like; an attacker (or more commonly, an automated tool) systematically attempting username and password combinations against an exposed RDP port until one works. It's one of the most common initial access techniques in the threat landscape, particularly against internet-facing Windows systems with weak or default credentials.

Every failed RDP login attempt generates a Windows Security Event with ID 4625: Failed Logon. That event contains the source IP address, the username attempted, the logon type, and a timestamp. Aggregated at scale, those events tell a clear story about who is trying to get in and from where.

In a SOC context, a sudden spike in 4625 events from a single source IP is a classic brute force indicator. Knowing that at the event level, having seen it generated in real time, changes how you read those alerts in production.

Background: What Is Microsoft Sentinel?

Microsoft Sentinel is a cloud-native Security Information and Event Management (SIEM) and Security Orchestration, Automation, and Response (SOAR) platform built on Azure. It ingests log data from connected sources, applies analytics rules to detect threats, and provides investigation and response tooling, all without requiring on-premises infrastructure.

At its core, Sentinel sits on top of a Log Analytics Workspace, which is the data layer where raw logs land and are made queryable via KQL (Kusto Query Language). From there, Sentinel adds the detection and visualization layer: workbooks, analytics rules, incidents, and playbooks.

Sentinel is one of the most widely deployed enterprise SIEMs in the market, particularly in Microsoft-heavy environments. Comfort with how Sentinel ingests data, how workbooks are structured, and how alerts surface is directly applicable to the kind of SOC work that matters right now.

Lab Environment

Cloud Platform: Microsoft Azure SIEM: Microsoft Sentinel Log Ingestion: Log Analytics Workspace Enrichment: Geolocation.io API Scripting: PowerShell Machine: Windows 10 VM (deliberately exposed honeypot)

Section 1: Creating a Free Azure Account

Why this matters: Microsoft Sentinel is Azure-native, which means getting comfortable in the Azure portal is a prerequisite for working with it effectively. Azure's resource model, subscriptions, resource groups, regions, and how services connect to each other, is the foundation everything else in this lab builds on. For any analyst working in a Microsoft-heavy SOC environment, this is the home base.

Azure offers a free account with $200 in credits for the first 30 days, which is more than enough to run this lab end to end without spending anything out of pocket. Standing up an Azure account also opens the door to the broader Microsoft security ecosystem. Defender for Cloud, Entra ID, Microsoft 365 Defender, all of which tie back into Sentinel as log sources in a real deployment.

[Screenshot — Azure account creation and portal landing page]

Section 2: Creating the Honeypot VM

Why this matters: A honeypot VM is the bait. It needs to look like a real, reachable Windows machine on the internet, which in Azure means a VM with a public IP address and an open attack surface. The goal here isn't to protect the VM. It's to make it as visible and accessible as possible so that the attacks come naturally, without any effort on my part to attract them.

In enterprise environments, misconfigured or forgotten internet-facing assets do exactly this unintentionally. Shadow IT, decommissioned servers left running, dev environments spun up and never secured — they all look like this VM from the outside. Understanding what that exposure looks like from the attacker's perspective is part of what makes this lab valuable.

The VM was deployed as a Windows 10 machine in Azure with a standard public IP. Nothing special about the configuration, the exposure comes in the next step.

[Screenshot — VM creation in Azure portal]

Section 3: Creating an Inbound Rule to Allow All Traffic

Why this matters: By default, Azure VMs have a Network Security Group (NSG) attached that restricts inbound traffic. This is the step where that protection gets stripped away intentionally. Creating an inbound rule that allows all traffic from any source on any port.

In a production environment, a rule like this would be a critical misconfiguration. It's the network equivalent of leaving every door and window open. But for a honeypot, it's the point, removing the NSG restrictions is what makes the VM visible to the automated scanners and brute force tools that are constantly sweeping public IP ranges looking for exactly this kind of exposure.

This step also illustrates something that comes up in real SOC investigations: overly permissive NSG rules are a genuine finding. Knowing what "allow all inbound" looks like in Azure, and how quickly it translates to attack traffic, makes that misconfiguration feel concrete rather than theoretical.

[Screenshot — NSG inbound rule allowing all traffic]

Section 4: Deploying the Virtual Machine

Why this matters: Once the VM is live with a public IP and an open attack surface, it joins the internet. And the internet is not a quiet place.

Automated scanners operated by threat actors, security researchers, and botnet infrastructure are continuously sweeping public IP ranges, probing for open ports, exposed services, and default credentials. Port 3389, the default RDP port, is one of the most targeted. The moment this VM's public IP became reachable, it was effectively in a queue to be found.

There is no grace period. There is no warming up. The question was never whether this VM would be hit. It was how fast.

[Screenshot — VM deployment confirmation in Azure]

Section 5: Deploying Log Analytics Workspace

Why this matters: Log Analytics Workspace is the data engine that Microsoft Sentinel runs on. Before Sentinel can do anything, query logs, fire alerts, render visualizations, it needs a place to store and index the raw data flowing in from connected sources. That place is the Log Analytics Workspace.

Understanding the relationship between the Workspace and Sentinel is foundational for anyone working with Microsoft's security stack. In a production environment, the Workspace is where you'd tune data retention, configure cost controls, and connect log sources. It's also where gaps show up! If a log source isn't connected to the Workspace, Sentinel can't see it, and a blind spot exists.

Deploying the Workspace first, before Sentinel reinforces the architecture: data ingestion layer first, detection layer on top.

[Screenshot — Log Analytics Workspace deployment]

Section 6: Capturing Logs in Microsoft Defender

Why this matters: Microsoft Defender for Cloud (formerly Azure Security Center) is the bridge between the VM and the Log Analytics pipeline. Enabling log collection here tells Defender to start forwarding the VM's security events, including Windows Security Event ID 4625, the failed logon event that is the primary signal in this entire lab, into the Workspace where Sentinel can query them.

In production SOC environments, this connector configuration is where coverage gaps often hide. An endpoint that isn't forwarding logs to the SIEM is effectively invisible to the detection layer. It can be compromised, scanned, or brute forced with no alert ever firing, because the signal never made it upstream. Building this connection manually in a lab setting makes that dependency concrete.

[Screenshot — Microsoft Defender for Cloud log capture configuration]

Section 7: Enabling VM Log Gathering in Security Center

Why this matters: This step specifically enables the collection of Windows Security Events from the honeypot VM at the level needed to capture 4625, Failed Logon events. It's a separate configuration from simply having Defender connected. You have to explicitly tell the pipeline what class of events to collect.

Event ID 4625 is the heartbeat of this entire lab. Every single RDP brute force attempt that hits the honeypot generates one. Each event contains the source IP, the username attempted, the failure reason, and the logon type. Aggregated across thousands of attempts, those events become a picture of who is targeting the VM and from where. Understanding that a single event ID is behind the detection, and that it has to be explicitly enabled to flow is the kind of detail that matters when you're troubleshooting a detection that isn't firing in production.

[Screenshot — Security Center VM log gathering enabled]

Section 8: Connecting Log Analytics to the VM

Why this matters: This is the step that closes the loop between the honeypot and the SIEM. The Log Analytics agent gets installed on the VM and begins forwarding Windows Event logs, including the 4625 events being generated by every failed RDP attempt into the Workspace in near real time.

In enterprise environments, this agent-based connection is what separates visible assets from blind spots. A VM without the Log Analytics agent isn't in the Workspace. It doesn't appear in Sentinel queries. It doesn't generate alerts. From the SIEM's perspective, it doesn't exist. An attacker operating on that endpoint is working in the dark, which is exactly why asset coverage validation is part of any mature SOC's operational baseline.

[Screenshot — Log Analytics agent connected to VM]

Section 9: Setting Up Microsoft Sentinel

Why this matters: With the Log Analytics Workspace deployed and the VM forwarding logs, Sentinel can now be connected to the Workspace and the detection layer comes online. This is the moment the lab transitions from a logging exercise to an actual SIEM deployment.

Sentinel is one of the dominant cloud SIEM platforms in the enterprise market. Its native integration with Microsoft's security ecosystem, Defender for Endpoint, Defender for Cloud, Entra ID, Microsoft 365 makes it the natural home for detection and investigation in Microsoft-heavy environments. The SMB and mid-market space, which is Huntress's primary customer base, runs heavily on Microsoft products. Knowing how Sentinel is structured, how it ingests data, and how workbooks and analytics rules work is directly applicable to the kind of environments those customers are running.

[Screenshot — Microsoft Sentinel workspace connected and configured]

Section 10: Logging Into the VM via Remote Desktop

Why this matters: RDP-ing into the honeypot serves two purposes. First, it confirms the VM is reachable and functioning. Second, it gives direct access to the Event Viewer, the source of truth for what's happening on the endpoint before any of it has been enriched or visualized upstream.

There's also something worth sitting with here: connecting to this VM over RDP is exactly what the attackers outside are trying to do. The same protocol, the same port, the same authentication flow. The only difference is that I have valid credentials and they don't…yet. Understanding the attack surface from the user side makes the threat model feel a lot more real than reading about it.

[Screenshot — RDP connection to honeypot VM]

Section 11: Observing Event Viewer Logs on the VM

Why this matters: Before any enrichment, any SIEM query, any visualization, the raw Windows Security Event logs are sitting right here in Event Viewer. This is the ground truth. Event ID 4625, Failed Logon, one entry per brute force attempt. Source IP, username attempted, logon type, timestamp.

Reading these directly, before they hit the pipeline, built an understanding of what the data looks like at its source. That context matters more than most people realize. When a detection isn't firing in Sentinel the way you'd expect, the answer is often in the gap between what the endpoint is generating and what's actually making it to the Workspace. Having seen the raw event at the source means you know what you're looking for when something goes wrong upstream.

In a production environment, a SOC analyst triaging a brute force alert might never look at Event Viewer directly. But knowing it's there, knowing what a 4625 looks like before it's been processed by a pipeline, is foundational context that makes everything downstream make more sense.

[Screenshot — Event Viewer logs]

Section 12: Turning Off Windows Firewall on the VM

Why this matters: The Azure NSG controls traffic at the network perimeter. The Windows host firewall controls it at the OS level. With both active, the VM is protected at two layers. Disabling the host firewall removes the second layer, maximizing the attack surface and ensuring that RDP traffic reaching the VM's public IP can actually connect to the service.

This step also illustrates a misconfiguration that appears constantly in real environments. Host firewalls get disabled by IT for compatibility reasons, by users who don't understand the risk, and by malware as part of an attack chain to reduce detection surface. A disabled host firewall is itself a signal, in endpoint telemetry, it typically generates an event that a properly configured SIEM would alert on. Recognizing that a missing firewall state is a detection opportunity is a useful pattern to carry into SOC work.

[Screenshot — Windows Defender Firewall disabled on honeypot VM]

Section 13: Getting a Geolocation.io API Key

Why this matters: A raw IP address in a log is useful. An IP address with a country, region, city, latitude, and longitude attached to it is actionable. The difference between those two things is enrichment, taking raw telemetry and layering on additional context that makes triage faster and more informed.

Geolocation.io is a third-party API that takes an IP address as input and returns geographic data about its origin. In this lab it's being called manually from a PowerShell script, but the concept maps directly to how threat intelligence enrichment works in a production SIEM. Sentinel, Splunk, and most enterprise SIEMs have connectors that automatically enrich IP addresses in alerts with geolocation, reputation scores, and threat intel feed data. Building this enrichment manually, from the API key registration through to the enriched output made the concept concrete in a way that relying on a built-in connector never would have.

[Screenshot — Geolocation.io API key registration]

Section 14: Running the PowerShell Script to Enrich Logs with Geo Data

Why this matters: This is the step where raw telemetry becomes intelligence. The PowerShell script continuously pulls Event ID 4625 entries from the Windows Event Viewer, extracts the source IP address from each failed logon event, queries the Geolocation.io API with that IP, and writes an enriched log entry, containing the original event data plus country, state, latitude, longitude, and a friendly label to a custom log file on disk.

Watching it run in real time was the moment this lab stopped feeling like a tutorial and started feeling like actual threat data. European IP addresses populating in the output. Usernames being attempted: Administrator, admin, user, root, the predictable defaults that brute force tools cycle through. City names appearing next to source IPs. The abstract concept of "RDP brute force attacks from the internet" became something specific and visible.

This script is doing manually what a threat intel enrichment pipeline does automatically in a mature SIEM deployment. Understanding the mechanics of that enrichment, where the data comes from, how it gets attached to the raw log, what happens when an IP doesn't resolve, is foundational context for working with enriched alerts in production.

[Screenshot — PowerShell script running with geolocation output visible]

Section 15: Creating a Custom Log in Log Analytics Workspace

Why this matters: Microsoft Sentinel has native connectors for dozens of log sources, Azure services, Microsoft 365, Defender products, third-party security tools. But the enriched log file being generated by the PowerShell script isn't one of them. It's a custom file sitting on disk on the honeypot VM. Getting it into the Workspace requires a custom log configuration.

Custom logs are how SOC teams pull in telemetry from non-standard sources. Legacy systems without native connectors, custom application logs, third-party tools that output to flat files. Building one here, pointing the Workspace at the enriched geolocation output, made the ingestion pipeline tangible. It also made the potential for ingestion failures tangible, if the file path changes, if the agent loses connectivity, if the log format shifts, the data stops flowing. Those are real failure modes that show up in production environments, and having built the pipeline from scratch makes troubleshooting them significantly more intuitive.

[Screenshot — Custom log creation in Log Analytics Workspace]

Section 16: Extracting Custom Fields

Why this matters: Ingesting the custom log gets the raw data into the Workspace. But raw log data is a string, a single line of text with values packed inside it. To make that data queryable, filterable, and usable for visualization, the individual values need to be extracted into their own named fields. Latitude needs to be a field. Longitude needs to be a field. Country needs to be a field. Without field extraction, the data is in the Workspace but Sentinel can't do anything useful with it.

Field extraction is one of the most common sources of broken detections in production environments. A detection rule that references a field that didn't parse correctly will fail silently, no errors, no alerts, just nothing. Having built field extraction manually, knowing what a correctly extracted field looks like and what it looks like when it fails, is the kind of hands-on context that makes troubleshooting those issues in production significantly faster.

[Screenshot — Custom field extraction configuration in Log Analytics]

Section 17: Setting Up the Map Workbook in Sentinel

Why this matters: A Sentinel workbook is a customizable dashboard, a visualization layer built on top of KQL queries against the Log Analytics Workspace. The map workbook takes the latitude and longitude fields extracted in the previous step and plots each attack event as a point on a world map, sized and colored by volume.

Building this from scratch, writing the query, selecting the visualization type, configuring the map parameters is the applied version of what a SOC analyst does when building detection dashboards. It's also where the data pipeline either proves itself or exposes its gaps. If the field extraction didn't work, the map won't populate. If the custom log isn't flowing, there's nothing to query. The workbook is the end-to-end validation that everything upstream is functioning correctly.

In production Sentinel deployments, workbooks are how SOC teams build operational visibility, geographic threat distribution, alert volume trends, coverage gaps across log sources. Knowing how to build and interpret them is a practical skill.

[Screenshot — Sentinel workbook map configuration]

Section 18: Watching the Attacks Roll In

Why this matters: This is the section that makes the whole lab worth building.

Within hours of the honeypot going live, firewall down, RDP exposed, public IP sitting on the internet, the map started populating. Attack traffic from across Europe. Dozens of source IPs. Hundreds of failed logon attempts. All of it enriched with geolocation data, plotted by country and volume on a live world map in Microsoft Sentinel.

What surprised me most wasn't the sophistication. It was the speed, and the sheer fact that it happened at all. I wasn't expecting to see results this quickly. I wasn't expecting to see them from this far away. There was something genuinely striking about watching a map of Europe light up because a virtual machine I spun up in Azure had been sitting on the internet for a few hours with its firewall off.

That reaction, the surprise at how fast the internet finds an exposed asset is actually the most important takeaway from this lab. In a production environment, a misconfigured VM doesn't sit exposed for hours without being found. It sits exposed for minutes. The attackers aren't waiting. The scanners aren't sleeping. The moment an asset becomes reachable, it's already being probed.

That's the threat landscape SOC analysts are working against every shift.

[Screenshot — Microsoft Sentinel world map showing live attack data by country and volume]

What I'd Look For as a SOC Analyst

Running this lab from the defender's side, watching the pipeline from raw Event Viewer log to enriched geolocation data to Sentinel visualization, made a few things click that are directly applicable to triage work.

Event ID 4625 is the signal. Volume and velocity are the story. A single 4625 event is noise. It happens on every Windows machine with every mistyped password. Hundreds of 4625 events from the same source IP, targeting the same username, over a short time window, that's a brute force attempt. The detection logic isn't complicated. What's important is understanding the underlying event well enough to know when the threshold should fire and when it's just a user locking themselves out.

The username matters as much as the source IP. Brute force tools cycle through predictable username lists, Administrator, admin, user, guest, the machine's hostname. Attempts against those usernames from an external IP are high-confidence signals. Attempts against a specific, valid employee username from an external IP are higher confidence still — they suggest the attacker has done OSINT on the target organization and knows who works there. The username field in a 4625 event is often the detail that changes the severity of a brute force finding.

Geolocation is context, not a verdict. An attack originating from a country your organization doesn't operate in is a data point, not a conclusion. It raises the priority of investigation and shapes the narrative, but geolocation alone doesn't determine maliciousness. VPNs, Tor exit nodes, and compromised infrastructure mean the apparent origin of an attack is often not its real origin. Use it to prioritize, not to conclude.

Log coverage gaps are blind spots, not edge cases. The entire detection chain in this lab, 4625 events flowing into Log Analytics, enriched via PowerShell, visualized in Sentinel, breaks the moment any single connector fails. No agent, no logs. No logs, no alerts. No alerts, no detection. In a production SOC, validating that expected log sources are actually flowing is as important as tuning the detections themselves. A SIEM that isn't receiving logs from a segment of the environment isn't protecting that segment.

Speed matters more than most people realize. The honeypot started receiving attempts within hours. In a real environment, an exposed RDP port on a public IP is found in minutes, sometimes seconds. That's not hyperbole; it's the baseline reality of internet-facing infrastructure. Attack surface management, prompt patching of internet-facing services, and alerts on new public-facing assets aren't nice-to-haves. They're foundational.

Closing Thoughts: Why This Lab Hits Differently

Most SIEM labs are staged. You feed synthetic log data into a pipeline, watch it process, and call it done. There's value in that, but there's a ceiling on what it teaches you.

This lab has no ceiling like that. The attacks in it were real. The IP addresses were real. The brute force attempts were real tools or real people scanning the internet and finding an open door. Watching that happen, seeing it accumulate in Event Viewer, seeing it light up on a Sentinel map in near real time, is the closest thing to a live SOC feed you can build on a personal Azure account.

It also changed how I think about the threat landscape in a way that reading never fully did. Knowing intellectually that RDP brute force is common is one thing. Watching it happen to your own machine, from countries you've never been to, within hours of flipping a firewall rule, that's something else. The attackers aren't waiting for an invitation. They're already looking. The only question is whether you're watching back.

For anyone preparing for SOC work, this lab is worth the time. Build it, watch it run, and sit with what the map is actually showing you. It will change how you read brute force alerts for good.

Tyler Reynolds is a SOC Analyst and cybersecurity practitioner focused on blue team operations, alert triage, and detection. Find more of his work on GitHub and connect on LinkedIn.