Recipe for RDWeb (Remote Desktop/RDS Web Interface) logs.

[ruklaw]

The remote desktop web interface doesn't work with IPBan stock as the events generated in the security log don't have the IP addresses for where the failed logins have come from.

These can instead be pulled from the IIS logs - I've done a bit of Regex and come up with a recipe that works with both the newer HTML5 and the older web interface (only tested on my server which is Windows Server 2016....)

The only caveat is that it can't report which usernames failed to login - these can be cross referenced and looked up in event viewer but IPBan can't pull that data across automatically. Usernames are reported for successful logins.

RDS.txt

Thanks for your work on IPBan!

[jjxtra]

Thank you for sharing, I will add this to the recipes code section

[balboa41]

Script-Block-RDWeb-Brute-Force-Attempts.txt

Hi guys! So I am also getting tons of 4625 events on my servers, seems like they are trying to do brute force attacks to the RDWeb servers. So far, I found a way to block the attacks, and created this script, which I attached.

Hopefully this can be integrated in the next version of IPBAN. Thank you for your hard work and excellent product!

Note: updating the script with new versions when it get optimized or revised.

[martinbenze]

The RDS recipe helped but as of 19/03/24, lots of our RDWEB servers are getting hit with a HTTP User Agent of "node-fetch/1.0" or blank. I believe they are using this (https://github.com/node-fetch/node-fetch/)
Its also on the National Vulnerability Database: https://nvd.nist.gov/vuln/detail/CVE-2024-22025

Examples of node-fetch from IIS logs below:
2024-03-15 00:04:49 x.x.x.x POST /RDWeb/Pages/en-US/login.aspx - 443 - 36.133.118.254 node-fetch/1.0+(+https://github.com/bitinn/node-fetch) - 200 0 0 763

Examples of null/blank user agent from IIS logs below:
Guest 11:40 AM, Mar 22 2024
2024-03-21 02:47:46 x.x.x.x POST /RDWeb/Pages/en-US/login.aspx - 443 - 41.185.8.146 - - 200 0 0 391

We already had the RDWEB recipe above but this didn't stop the hack.

To get around this we have installed IIS URL Rewrite onto the servers. We created an inbound rule with the following settings and this has stopped the attack for now:

Name: Block Bad UserAgent
Requested URL: Matches the Pattern
Using: Regular Expressions
Pattern: .*

Conditions
Logical Grouping: Match Any

Condition1
Condition Input: {HTTP_USER_AGENT}
Check if input string: Matches the Pattern
Pattern: node-fetch

Condition2
Condition Input: {HTTP_USER_AGENT}
Check if input string: Matches the Pattern
Pattern: ^$

Action
Action Type: Abort Request

[jjxtra]

@martinbenze That shouldn't have been necessary. The regex should find those log entries. I've created a regex101 to prove it.

https://regex101.com/r/yPqiDX/1

[martinbenze]

The regex does catch and ban the IP but within a 3min period the attacker did 3016 attempts from 07:26:22 to 07:29:44 before the IPBAN software blacklisted the IP address. They then change their IP address and go again.

The URL Rewrite has completely stopped anyone using node-fetch, blank and null http_user_agent. So both the regex additional log check in IPBAN and the IIS rewrite work well together.

Can the cycletime and minimumtimebetweenfailedloginattempts config variables be lowered to catch this?

[jjxtra]

You can set min time between failed logins to 0.

[martinbenze]

I have removed the URL rewrite rules and set minimumtimebetweenfailedloginattempts to 0 as a test and it has helped. I wasn't sure what the range was and if it could go lower then the default of 1second. Now instead of 3000 attempts within 3mins there are 35 entries in the IISLogs before IPBAN bans them. I guess tweaking the cycletime lower than 15 seconds may improve on this further but that seems fine.

I have reapplied the IIS URL Rewrites too just to get the attempts to 0 as long as the http_user_agent is null or contains node-fetch.