Leave it open and they will come

TL;DR – A story of how I left an RDP port wide open (oops!) and MDC and Sentinel came to my rescue when my resource was attacked.

Nope! I didn’t do this on purpose. Normally, I do a lot of testing to generate alerts and incidents in MDC, Sentinel, Defender 365 etc., but this one was not planned, not part of any test to generate alerts. This was a real attack.

Recently, I launched some resources as part of a lab to test Azure Purview, because… well, data governance. One of the resources included in the lab was a SQL Server on Azure VM and, unfortunately, the network configuration left the RDP port open. I was lucky to have previously configured Microsoft Defender for Cloud (MDC) and integrated it with Microsoft Sentinel.

The first thing I noticed

The Sentinel incidents started coming, this is how I first noticed there was something wrong. These were incidents and alerts that I did not expect within this workspace.

Digging in a little deeper on one of the alerts (‘Traffic detected from IP addresses recommended for blocking‘), I can see the entity associated was my Purview lab server and there was inbound traffic from IPs that may be malicious.

I could also see a link to go to Defender for Cloud and get more info, so I did. I could see that 32 different IPs tried to connect to my resource on port 3389.

I can see more details about those IPs as well.

And I could see actions I could take to “Mitigate the threat” and to “Prevent future attacks” as well. I could also trigger an automated response, which would mean running a Logic App, but in this case, the “Enforce rule” action available meant it would not require a Logic App.

When I clicked on “Enforce rule“, it gave me the option to immediately update the network configuration to block port 3389 for that server. This recommendation came from the adaptive network hardening recommendations, so it is based on a machine learning algorithm that “factors in actual traffic, known trusted configuration, threat intelligence, and other indicators of compromise, and then provides recommendations to allow traffic only from specific IP/port tuples“. That means the recommended rule will take into account any legitimate sources.

In my case I didn’t need any of the ports open from the Internet, so I would update it to deny all traffic on that port from the Internet, which is what clicking on “Enforce” did, as shown below.

A SOC analyst having the ability to make it stop right there by just clicking one button can mean their effectiveness is that much more valuable. Also, the fact that the recommendation they are following comes from the evaluation of the legitimate traffic as determined by the machine learning algorithm, means it is likely the way it should have been configured initially for the specific requirements of that resource. And if you wanted to automate this response in the future, you can do that from either Sentinel (playbooks) and/or MDC (workflow automation) using Logic Apps.

The other alert

You probably noticed there were two different types of alerts on Sentinel, the other one was ‘Suspicious authentication activity‘, as shown below.

Digging in deeper on the MDC side (by following the links from Sentinel above), I could see all the details about the various users the attacker tried to use. I could also see the actions recommended by MDC, which include the various recommendations to prevent future attacks. Because MDC is both a Cloud Workload Protection (CWP) solution and a Cloud Security Posture Management (CSPM) solution, so it can alert during an attack, as well as prevent attacks. The same policies can even prevent resources from being configured incorrectly initially, but that’s a subject for another blog.

The original setup

You are probably wondering ‘where are all these alerts and recommendations coming from and why are they showing up in Microsoft Sentinel’? They are coming from Microsoft Defender for Cloud because I enabled the enhanced security services for my resources, as shown below.

This enables these workload protections and various other features, as described in the documentation. And that allows it to alert me when these attacks happen. You can also see the same alerts shown here to the right, under “Most prevalent security alerts“.

And they are showing up in Microsoft Sentinel because I have the Defender for Cloud connector enabled for the subscription where my resource is located and some analytic rules enabled as well.

Multi-cloud and Hybrid

And if you are thinking, but this only works on Azure resources, you will be pleasantly surprised to know that MDC is multi-cloud. So, everything I just shared here can apply to resources on AWS and GCP natively, and on other clouds as well as on-prem resources using Azure Arc.

Just a little further

Since I was able to see these alerts in Sentinel, I was also able to run some playbooks to go to RiskIQ and find out if they knew anything about these IPs that were trying to connect to my resource. If you want to know more about this setup, please reference my previous post, RiskIQ Illuminate Content hub solution within Microsoft Sentinel. And here’s how that information shows up in Sentinel for this specific case.

As you can see above, after running that playbook, the incident was updated to ‘Active‘, the Severity was raised from ‘Low‘ to ‘Medium‘, a tag was added ‘RiskIQ Suspicious‘, and 33 comments were added with more information about the various IPs that were included in the incident. In this case, I had already resolved the issue from MDC, but in other situations a SOC analyst can also make use of this data to correlate to other open incidents.

While this incident was a complete surprise to me, it was a great opportunity to see the power of these Microsoft Security services working together to make a resolution to these types of attacks that much easier for any SOC analyst.