Introduction

I built this project out of curiosity. I wanted to know what would happen if I left a VM with an RDP port open, and I also thought it would be a great time to keep my SOC monitoring skills sharp. I decided to use Azure, as this is a great platform where I could easily set up a Windows VM and attach Sentinel to the VM to monitor logs and create alerts. Unlike my other posts, this is not a step-by-step tutorial, as the setup was fairly complex; it is more of an overview of the process and what I discovered. 

Setting Up The Experiment

To capture real-world data, I chose to deploy a Windows Server VM with a standard name (WIN-SVR01) and simply left the RDP port wide open – terrible, I know! I then connected this machine to a Log Analytics Workspace, linked it with Microsoft Sentinel, and configured the Azure Monitor Agent to collect the Security Event Log that we were focusing on (4624, 4625). This would mean that only the logs around Unsuccessful / Successful Sign-ons would be monitored. I used a very long, secure password so it would be very unlikely that anyone would be able to gain access. I was more checking who would try and how.

Collecting The Data

Once I had set up the process, I created KQL queries to enrich the findings with geolocation data and filtered out my own test logins, giving me a clean dataset of external login attempts. 

Enriching the IP Addresses

In order to gain further insights into the IP addresses, I decided to add a threat intelligence feed. I decided that I wanted to integrate the MISP data feeds directly into Sentinel to create alerts and evaluations from the confidence scores of the feed. 

I did this by running MISP on Docker on an Ubuntu VM, with port 443 exposed so it could serve API requests. I used the default feeds to create the confidence scores, and then used an Azure function app with Python to automatically pull the data from the API every 2 hours. This meant that (after lots of debugging) I gathered some interesting insights into the attackers who tried to connect.

What I found 

After leaving the VM open for 3 days, I had 124 login attempts from 11 different IP addresses. A vast majority of these were from a single IP address within Russia. Most of the IP addresses IPs resolved to hosting companies or unmanaged dedicated-server providers rather than consumer ISPs – a strong hint that many of the connections may be from scanners rather than casual home users. 

I used the MISP threat-intel score to weigh how suspicious each IP is. In plain terms: of the 11 IPs, 3 are medium confidence (MISP score between 40–74) and 8 are low confidence (<40). There were no high-confidence hits (≥75) in this snapshot, so while some sources look more suspicious than others, most did not have extremely strong prior malicious attribution in MISP.

Two specific examples stood out however:

• 185.170.144.3 – This had a score of 60, but the ASN was XHOST INTERNET SOLUTIONS. This is a known bulletproof hoster which has recently been sanctioned by the UK Government, which called XHOST  “a key component of the Russian cybercrime supply chain.” This increases the significance of this attempt and, in a real-world scenario, should trigger some action. 

• 212.102.51.83 – This IP address was interesting as it is a known ProtonVPN node. This shows how some attackers try to hide their identity behind VPNs to make attribution harder. 

Behaviorally, the attacks fall into two patterns: a few IPs repeatedly hammered the RDP service with many attempts, while other IPs tried one or two common usernames and moved on. The most common targeted usernames were still “Test” and “Administrator”, reinforcing that default/obvious accounts are being probed first.

Conclusion 

This experiment highlighted how important it is to not leave an insecure RDP port open. Before the box even showed up on tools like Shodan, it was already being scanned and attacked, from both likely script kiddies to potential high-level Russian cybercrime organisations. It also showed the importance of enrichment and triage to gain further context on attackers. For example, if an IP address has a high score on MISP, this should immediately trigger an alert in Sentinel and/or lead to the IP being blocked immediately. Also, with further checks like VPN checks, TOR exit node checks and ASN checks, we can gain a clearer understanding of the threat so that the Cyber Security department can respond appropriately. 

As always, here is a quick video demo: