How InTrust can drastically reduce RDP attack attempts frequency

It is well known for anyone who tried to run a VM in the cloud that RDP port if left opened will be attacked with massive waves of brute-force attempts from IPs all around the world.

I run a detection lab in Azure and at some point, it just started to be more annoying to me than I thought and instead of closing access to RDP, I decided to try another approach.

With Quest InTrust it is possible to execute response actions when an alert is triggered. Out of the box, InTrust has an alert about failed logon from the same workstations. The thing is – a lot of these attempts are going without source workstation name being identified and how do you block one if you know the name – they are not in the same domain with my machine anyway.

So, first, we need a rule that triggers on the same IP rather than the workstation name. So I’ve copied the workstation rule

You will need to add source IP into the alert fields(the highlighted text on the image above) so that we can trigger the response action using the Source IP(which is Insertion String 20 in the 4625 event ID). Also to make the rule work for the IP, on the example above I've changed the workstations name(Insertion String 14) in the rule code (highlighted with red rectangles) to the source IP(Insertion String 20).

Make sure also to add a Source IP field for the alert, and I also decided to fix the text of the alert as well

Next, we need to add a script that will bock IP address in the Windows Firewall, here is an example that I used, I just copied the user logoff script, deleted contents, and parameters and then just added this code instead

param(

         [Parameter(Mandatory = $true)]

         [ValidateNotNullOrEmpty()]   

         [string]

         $SourceAddress

)

$SourceAddress = $SourceAddress.Trim()

$ErrorActionPreference = 'Stop'

$ruleName = 'Quest-InTrust-Block-Failed-Logons'

$ruleDisplayName = 'Quest InTrust: Blocks IP addresses from failed logons'

function Get-BlockedIps {

    (Get-NetFirewallRule -Name $ruleName -ErrorAction SilentlyContinue | get-netfirewalladdressfilter).RemoteAddress

}

$blockedIps = Get-BlockedIps

$allIps = [array]$SourceAddress + [array]$blockedIps | Select-Object -Unique | Sort-Object

if (Get-NetFirewallRule -Name $ruleName -ErrorAction SilentlyContinue) {

    Set-NetFirewallRule -Name $ruleName -RemoteAddress $allIps

} else {

    New-NetFirewallRule -Name $ruleName -DisplayName $ruleDisplayName -Direction Inbound -Action Block -RemoteAddress $allIps

}

We also need to add a parameter for the source IP (and if you are a perfectionist, unlike me, you would also change the script and parameter descriptions )

Now we need to add this script as a response action to the rule, enable the rule, and make sure the appropriate site is selected in the real-time monitoring policy. Response action script should be running on the agent, and make sure to specify the correct parameter

So, let’s try this in the wild wild west of the outside Internet 

This is a nice chart we’ve created together with Microsoft using Kusto Query Language in Azure Log Analytics on the volume of authentication errors we see in my detection lab in Azure, you can see that the overall number of failed logins dropped by 80%

And you kind of see them going up day by day, probably when newer crawlers and scanners discovered my opened RDP ports 

 I have 66 IP addresses after a week of running this test.

Here is a summary of top 10 usernames that have been attempted by these brute-force scanners

You can see more examples of using InTrust response actions on our product page www.quest.com/intrust in the videos in the resource section