As someone who supports a lot of Windows environments - yes, it's incredible the rate at which this occurs. I'd strongly point people at the RD Gateway MFA plugin as a requisite for publishing RDS these days:
> I'd strongly point people at the RD Gateway MFA plugin
Is this working well? I've tried setting this up a few weeks ago and found it to be somewhat brittle. The MFA requests would sometimes be delayed long enough that the GW would timeout. I've tested this on Windows 2022.
I've a whole range of clients running it without an issue.
I will say however, the only MFA it supports is push (ie, TOTP doesn't work), and if you're not familiar with that, be aware many Android installations snooze that app and the push doesn't work unless you specifically have the app open at the time you logon.
We’ve been using it for years and it’s always been irritating in the way you describe. It seems if you miss the first push notification, you’ll receive a flurry more, many of which don’t really seem to do anything even if you do approve them. It’s possible that I have the timeouts set incorrectly, but I’ve followed Microsoft’s guidelines. Unfortunately we don’t have a better solution, so we suffer with it.
We use Rublon for adding MFA to Remote Desktop and other VPNs too and it works very well. It’s not an over engineered monstrosity like Microsoft solutions.
I think that's down to the problem you're trying to solve. Much like SSH brute force, if you know the only account is yours and it has an appropriately reasonable password and you can trust yourself not to get phished (say, you have a system managing the logon) then that's probably fine.
The second there are other people with dumb passwords, or many other risk factors at play, I'd really suggest you need something doing MFA which unfortunately, MS doesn't offer out of the box on RDP.
You never know which 0-day gets discovered tomorrow, so even strong password might not be enough. I always change default ports on both SSH and RDP. It helps falling out of scope of unsofisticatrd scanners, keeps logs a bit cleaner plus doesn't waste CPU on useless auth attempts. Keeping ports behind VPN or port knocking is even better, but not always feasible
There’s a pretty cheap program that will do auto blocking, it’s easily googleable. Also changing the default port will cut down the numbers. I’ve had one hacked over RD gateway so that alone isn’t the answer. On our cloud windows servers we use a remote management agent to access, this obvs has its own trust issues but overall works well.
The difference between type 3 and type 10 is probably the difference between providing the username and password when connecting to RDP or after already connecting. In the latter case it's “interactive”: you enter the password via the GUI of the server you connected to.
Yep, I have a single Windows Server machine with an RDP port(non default) exposed to the world and it gets tens of thousands of failed logins every day. It has been for the past few years. I have no idea who is wasting their time on this or why, but as far as I can tell it's costing me nothing, so other than setting up an alert for a successful login I decided to simply ignore it.
It's basically a fail2ban for windows. Its goals are also mainly what we love about fail2ban:
pre-configured
no-initial-ducking-around-with-scripts-or-config-files
install-and-forget
You can download it here ( v2.1.5 - April 2022 ) .
Also, we love issues!
If anyone needs something or has questions about something, please feel free to open an issue. We are especially happy to get issues about log-entry samples we don't react on, or ideas of how we can support more protocols.
A bit more detailed description of what EvlWatcher does.
Scenario: there are those bad people out there, hammering your service (RDP and whatnot) with brute force attempts.
You can see them and their IPs clearly in the Windows Event-Log.
You have searched the web and yea, there are plenty of tools, scripts, and all that, to read the event-log and automatically ban the attackers IP.
You however, are lazy. You need something like fail2ban, with a preconfigured set of rules to just RUN right away and it works.
But then, it still needs enough flexibility for you to completely configure it, should you wish to do so.
EvlWatcher does that. It scans the Windows-Event-Log, and reacts.
It works by installing a service that scans the event log for unsuccessful login attempts. When one of its rules are violated (e.g. trying to log in without correct credentials, more than 5 times in 2 minutes), it will place that poor bastard into a generic firewall rule, and thereby ban the attacker for 2 hours.
Also, when someone is repeatedly trying, there is a permanent ban list for that, where people defaultly land on when they've had three strikes.
You can, of course, adjust the rules to your liking. They are basically a consisting of an event source, and a Regex to extract an IP, its pretty simple.
My old ts_block[0] project does something similar to yours, albeit for RDP only and with much less sophisticated customization.
I opted to go with a WMI Event Sink rather than polling the Event Log. I've never done a benchmark to see which architecture would use less CPU, but I can say the WMI event sink causes nearly instantaneous reaction.
As an aside: I'd love to hear if somebody tries ts_block on Windows Server 2022. It works fine on 2012 R2 thru 2019 but I've never tried it on 2022.
Not my project. I was also going to post yours but decided not to due to questions in issues about support for newer versions of windows. Something about IP address missing from event?
I've long-neglected ts_block and probably should update the documentation, if nothing else.
Windows Server 2012 R2 removed the IP address from the Event Log entry for failed RDP logons (to be fair, it's really that the just didn't include it in failed RDP logons when the TLS security layer is used-- reverting to the old RDP security layer in Windows Server 2012 R2 restores the IP address). Without doing something dodgy like trying to correlate closed TCP connections to Event Log entries there's no simple way to ascribe IP addresses to failed RDP logons on that version of Windows.
In Windows Server 2016 and 2019 Microsoft put the IP address back into the Event Log entry, restoring ts_block's functionality.
Thanks for this dude! I have a forked copy with a few different things and it works great. We catch so many IPs and I get a good feeling about slowing down these guys. I do still have to try on 2022 but I don’t see why it wouldn’t work.
https://github.com/greatquux/ts_block
If I ever bother to work on ts_block again I'm definitely going to implement all the features you added. (I'm aware you've already written the code but, for me, half the fun is writing the code. >smile<)
I avoided running servers since people are jerks but if I did that would be on my checklist of things to set up if I intended one to stick around long term.
People seem to reinvent concepts from long ago for reasons I do not understand.
It cuts down on the feasibility of generic internet scan + brute force attacks like described in this article. It's not an answer to specialized/focused attacks though cleaner logging may help you notice those.
It's best to do both as security isn't something delivered by a single solution. After all it's not like protocols such as RDP and SSH have been found to be infallible over the years, they've had side-channels, vulnerabilities detectable by scanning, and other weaknesses regardless whether your password was theoretically impossible to brute force when you made it.
You never reach the point "I'm secure" you simply reach the point "adding more security measures costs more than the risk it removes".
Again say there were vulnerabilities due to sidechannels, vulnerabilities related to repetitive scanning with certain options, or weaknesses in the algorithms that allow for collisions much sooner than expected. If you're interesting enough to specifically be targeted by a distributed attack then hopefully you have additional layers while if you're just getting attacked for having an IP exposed on the internet IPS/IDS like fail2ban can be a pretty good first defense. In both cases it's great to feed your SIEM.
I deliberately do not run Fail2Ban so that attackers waste their resources on my server. Before I turned off logging due to GDPR, I got 40M failed login attempts per month.
> Before I turned off logging due to GDPR, I got 40M failed login attempts per month.
Logging failed login attempts would definitely fall under legitimate interest so you can reenable them. It's not like the attackers would complain anyway.
Logging without consent would be legal due to legitimate interest, but I would also have to comply with "Chapter 3 Rights of the data subject" https://gdpr-info.eu/chapter-3/ In particular, I do not like article 13 paragraph 1 section (a) because I prefer to stay anonymous. I still receive daily spam from the time I published my contact details on a website 10 years ago. It has also become illegal to embed contact details in an image or hide it behind a captcha due to accessibility. I would risk a 5000 € fine if I did it anyway.
They do not appear to be ramping up on any of my VPS nodes. I see the same averages to my tarpit ports on all my nodes.
# VPS They all look similar to this
iptables -L INPUT -n -v | grep TAR | sort -r | awk '{print $1"\t" $3"\t" $11}'
2680 TARPIT dpt:23
2657 TARPIT dpt:6379
170K TARPIT dpt:445
1186 TARPIT dpt:80
882 TARPIT dpt:22
757 TARPIT dpt:443
591 TARPIT dpt:5900
311 TARPIT dpt:21
296 TARPIT dpt:3389
119 TARPIT dpt:873
Some poorly coded bots appear to get stuck on 445 indefinitely. On the other hand I do see a vast increase on my home network to 5900 VNC. It is usually about double the hits to 3389 RDP
[Edit]
Here is a second home connection that has a higher uptime. Running tcpdump it looks like the latest VNC bots do not recognize and avoid tarpits.
Windows do not log the passwords they tried, so we can't know which ones were used
Would be interesting to create a server daemon that listens on TCP port 3389 and implements the login portion of the RDP protocol to 1) Be able to gather information about the passwords used and 2) Experiment with ways to lock up or stall the scanners.
Well I never ever expose RDP to the internet directly. Allow only office IP or setup some VPN/jumphost via ssh whatever.
I trust SSH much more than RDP to not have RCE/auth bypass bugs. SSH is also much easier to setup key auth or 2FA than in RDP if one like they mentioned in post are more used to setting up Linux boxes.
After reading this blog post - I would not send any logs to their servers.
Exactly! I at first thought this was a rogue or disgruntled employee who wrote a blog post on the way out. But it appears to be a legit article sanctioned by their company.
They literally opened a server without firewall rules for anyone to connect to their RDP port, and wrote a blog article to brag about it. They also have a Windows agent but they brag about not using Windows in the past 20 years…
You absolutely should blame Flyserver. They allow bots to run, and they don't do anything about it. There are too many network operators like this.
Imagine if any networks where constant and ongoing illegal activity happens, and the network operators do nothing, eventually result in those networks being taken away. Things would change drastically.
37 comments
[ 0.76 ms ] story [ 88.2 ms ] threadhttps://docs.microsoft.com/en-us/azure/active-directory/auth...
It's also supported to publish behind the Azure App Proxy, avoiding the need for any port forwards at all:
https://docs.microsoft.com/en-us/azure/active-directory/app-...
Is this working well? I've tried setting this up a few weeks ago and found it to be somewhat brittle. The MFA requests would sometimes be delayed long enough that the GW would timeout. I've tested this on Windows 2022.
I will say however, the only MFA it supports is push (ie, TOTP doesn't work), and if you're not familiar with that, be aware many Android installations snooze that app and the push doesn't work unless you specifically have the app open at the time you logon.
The second there are other people with dumb passwords, or many other risk factors at play, I'd really suggest you need something doing MFA which unfortunately, MS doesn't offer out of the box on RDP.
Given the frequency with which these incidents happen, I am more inclined to think they are a bulletproof hoster of some kind ...
At a certain point it becomes difficult to attribute things to “incompetence” rather than malicious intent
README…
It's basically a fail2ban for windows. Its goals are also mainly what we love about fail2ban:
pre-configured no-initial-ducking-around-with-scripts-or-config-files install-and-forget You can download it here ( v2.1.5 - April 2022 ) .
Also, we love issues!
If anyone needs something or has questions about something, please feel free to open an issue. We are especially happy to get issues about log-entry samples we don't react on, or ideas of how we can support more protocols.
A bit more detailed description of what EvlWatcher does.
Scenario: there are those bad people out there, hammering your service (RDP and whatnot) with brute force attempts.
You can see them and their IPs clearly in the Windows Event-Log.
You have searched the web and yea, there are plenty of tools, scripts, and all that, to read the event-log and automatically ban the attackers IP.
You however, are lazy. You need something like fail2ban, with a preconfigured set of rules to just RUN right away and it works.
But then, it still needs enough flexibility for you to completely configure it, should you wish to do so. EvlWatcher does that. It scans the Windows-Event-Log, and reacts.
It works by installing a service that scans the event log for unsuccessful login attempts. When one of its rules are violated (e.g. trying to log in without correct credentials, more than 5 times in 2 minutes), it will place that poor bastard into a generic firewall rule, and thereby ban the attacker for 2 hours.
Also, when someone is repeatedly trying, there is a permanent ban list for that, where people defaultly land on when they've had three strikes.
You can, of course, adjust the rules to your liking. They are basically a consisting of an event source, and a Regex to extract an IP, its pretty simple.
I opted to go with a WMI Event Sink rather than polling the Event Log. I've never done a benchmark to see which architecture would use less CPU, but I can say the WMI event sink causes nearly instantaneous reaction.
As an aside: I'd love to hear if somebody tries ts_block on Windows Server 2022. It works fine on 2012 R2 thru 2019 but I've never tried it on 2022.
[0] https://github.com/EvanAnderson/ts_block
Windows Server 2012 R2 removed the IP address from the Event Log entry for failed RDP logons (to be fair, it's really that the just didn't include it in failed RDP logons when the TLS security layer is used-- reverting to the old RDP security layer in Windows Server 2012 R2 restores the IP address). Without doing something dodgy like trying to correlate closed TCP connections to Event Log entries there's no simple way to ascribe IP addresses to failed RDP logons on that version of Windows.
In Windows Server 2016 and 2019 Microsoft put the IP address back into the Event Log entry, restoring ts_block's functionality.
If I ever bother to work on ts_block again I'm definitely going to implement all the features you added. (I'm aware you've already written the code but, for me, half the fun is writing the code. >smile<)
https://www.fail2ban.org/wiki/index.php/Main_Page
I avoided running servers since people are jerks but if I did that would be on my checklist of things to set up if I intended one to stick around long term.
People seem to reinvent concepts from long ago for reasons I do not understand.
You never reach the point "I'm secure" you simply reach the point "adding more security measures costs more than the risk it removes".
Logging failed login attempts would definitely fall under legitimate interest so you can reenable them. It's not like the attackers would complain anyway.
I'd love to see one of their Data Subject Access Requests.
Dear Victim,
Can you wipe my failed login attempts from your servers.
Yours,
The Hacker!
Would be interesting to create a server daemon that listens on TCP port 3389 and implements the login portion of the RDP protocol to 1) Be able to gather information about the passwords used and 2) Experiment with ways to lock up or stall the scanners.
https://research.nccgroup.com/2021/10/21/cracking-rdp-nla-su...
https://github.com/nccgroup/nlahoney
I trust SSH much more than RDP to not have RCE/auth bypass bugs. SSH is also much easier to setup key auth or 2FA than in RDP if one like they mentioned in post are more used to setting up Linux boxes.
After reading this blog post - I would not send any logs to their servers.
They literally opened a server without firewall rules for anyone to connect to their RDP port, and wrote a blog article to brag about it. They also have a Windows agent but they brag about not using Windows in the past 20 years…
Imagine if any networks where constant and ongoing illegal activity happens, and the network operators do nothing, eventually result in those networks being taken away. Things would change drastically.