To Thwart Ransomware, Microsoft's Windows Gets New Defaults Limiting Brute-Force Password Guessing (zdnet.com) 54
ZDNet reports:
Microsoft is rolling out a new security default for Windows 11 that will go a long way to preventing ransomware attacks that begin with password-guessing attacks and compromised credentials. The new account security default on account credentials should help thwart ransomware attacks that are initiated after using compromised credentials or brute-force password attacks to access remote desktop protocol (RDP) endpoints, which are often exposed on the internet.
RDP remains the top method for initial access in ransomware deployments, with groups specializing in compromising RDP endpoints and selling them to others for access.
The new feature is rolling out to Windows 11 in a recent Insider test build, but the feature is also being backported to Windows 10 desktop and server, according to Dave Weston, vice president of OS Security and Enterprise at Microsoft. "Win11 builds now have a DEFAULT account lockout policy to mitigate RDP and other brute force password vectors. This technique is very commonly used in Human Operated Ransomware and other attacks — this control will make brute forcing much harder which is awesome!," Weston tweeted.
Weston emphasized "default" because the policy is already an option in Windows 10 but isn't enabled by default. That's big news and is a parallel to Microsoft's default block on internet macros in Office on Windows devices, which is also a major avenue for malware attacks on Windows systems through email attachments and links.... The defaults will be visible in the Windows Local Computer Policy directory "Account Lockout Policy".
The default "account lockout duration" is 10 minutes; the "account lockout threshold" is set to a maximum of 10 invalid logon attempts; a setting to "allow administrator account lockout" is enabled; and the "reset account lockout counter after" setting is set to 10 minutes.
RDP remains the top method for initial access in ransomware deployments, with groups specializing in compromising RDP endpoints and selling them to others for access.
The new feature is rolling out to Windows 11 in a recent Insider test build, but the feature is also being backported to Windows 10 desktop and server, according to Dave Weston, vice president of OS Security and Enterprise at Microsoft. "Win11 builds now have a DEFAULT account lockout policy to mitigate RDP and other brute force password vectors. This technique is very commonly used in Human Operated Ransomware and other attacks — this control will make brute forcing much harder which is awesome!," Weston tweeted.
Weston emphasized "default" because the policy is already an option in Windows 10 but isn't enabled by default. That's big news and is a parallel to Microsoft's default block on internet macros in Office on Windows devices, which is also a major avenue for malware attacks on Windows systems through email attachments and links.... The defaults will be visible in the Windows Local Computer Policy directory "Account Lockout Policy".
The default "account lockout duration" is 10 minutes; the "account lockout threshold" is set to a maximum of 10 invalid logon attempts; a setting to "allow administrator account lockout" is enabled; and the "reset account lockout counter after" setting is set to 10 minutes.
RDP Naked Access?! (Score:2, Troll)
It seems like there could be some more low-hanging fruit there... I wouldn't even let certificate-based SSH be accessed via a routable IP address!
While I get that sometimes setting up a VPN is too much work... it is hard to understand why MS hasn't made that sufficiently easy to even accommodate remote-work first logins without any third-party tools.
Re:RDP Naked Access?! (Score:4, Insightful)
It's also nice to see Microsoft implements a feature that's been in use on any serious OS for the last 40 years.
And yeah, exposing your RDP service directly to "The Internet" is utterly braindead.
Re: (Score:3)
And yeah, exposing your RDP service directly to "The Internet" is utterly braindead.
It's as if millions of Indian tech support voices suddenly cried out in terror and were suddenly silenced.
Re:RDP Naked Access?! (Score:5, Informative)
It's also nice to see Microsoft implements a feature that's been in use on any serious OS for the last 40 years.
The feature has always been there. They only changed defaults because they realise users are stupid.
Incidentally Linux is chock full of services which don't rate limit or lock out accounts, and anyone who thinks otherwise has clearly not looked into sshd logs on a public facing server.
It's the reason why software like fail2ban exists (which isn't enabled by default in any distro I know of).
Re: (Score:2)
Often the RDP service is only available via VPN, but hackers targeting an institution are getting better at stealing VPN credentials,
Re: (Score:2)
Really? I've been doing this since the early 2000s. Yes, I can see login attempts in the event log.
Re: (Score:2)
It's also nice to see Microsoft implements a feature that's been in use on any serious OS for the last 40 years.
Sure. It's only been the government recommendation since 2017 after all. NIST SP 800-63 rev 3.
Re: (Score:2)
You really don't want Windows to b your VPN host, it's too insecure. A dedicated VPN router is a much better option. Unfortunately, most of those are based on custom software, instead of relying on IPSEC. This is what makes it the hardest to access VPN from Windows. Windows has a built-in IPSEC client, but for most VPN routers, you have to install some proprietary client.
Re: (Score:2)
As long as you aren't relying on the application VPN as your primary firewall I don't see an issue. Using Wireguard as an example, one port forwarded from firewall to the RDP server, application firewall allows only that port from the firewall, and the VPN limited to host communication.
Re: (Score:3)
The issue with port forwarding, is that you are giving an application (like Remote Desktop) the primary responsibility for protecting you network against attacks. Remote Desktop isn't primarily a security-focused application. Yes, it does implement some security protocols, but as this article noted, until now it hasn't even blocked against brute force password cracking. That's a pretty rudimentary security measure, that it didn't have. What other weaknesses does it have, that Microsoft isn't admitting yet?
H
Re: (Score:2)
I get that; you don't port forward RDP, you port forward to Wireguard, which has a loopback/host-only route.
Re: (Score:3)
I wouldn't even let certificate-based SSH be accessed via a routable IP address!
While I get that sometimes setting up a VPN is too much work...
Hmm. Most VPN set-ups I have seen remember your password and are hence basically "certificate-based SSH", probably with reduced security. What specifically to you have in mind here. Because SSH is probably more secure overall than typical VPNs. Or do you just want SSH with certificate and password? That would make sense to me. Although I have recently moved to SSH with password and 2nd factor.
Re: (Score:2)
Client based certificate for authenticating the client, or a secure keypair. Personally I love the simplicity that WireGuard offers, and it is very low overhead/latency. It would be trivial to automate credential updating via emailing of the public key from the client's trusted internal e-mail address.
Re: (Score:2)
> It would be trivial to automate credential updating via emailing of the public key from the client's trusted internal e-mail address.
Trusted email address?
It's trivial for me to set my "from" address as "you@you.com".
Or "biden@whitehouse.gov'. That's not even hacker shit, that's "Learn how to send spam in 15 minutes" shit.
If you ever again find yourself saying "trusted email address", immediately stop that sentence and turn the project over to someone competent in the realm.
If you make any scheme base
Re: (Score:2)
Internal network email can provide source validation. It isn't necessarily perfect, but the strength is that it gives you a very limited level of access with further checks and balances. Think of it as just a logical step or two above "naked on the internet".
Re: (Score:2)
Internal network email is also a very nice tool for an attacker that got in and is now doing lateral movement. More so if people think internal email is somehow secure.
This . morning (Score:2)
THIS MORNING we had 88 scam emails coming "from" internal email addresses delivered to users because someone was thinking the way you're thinking.
Re: (Score:2)
Actually, "trusted email address" is entirely fine. It means "email address that can attack me".
What you never, ever want to say is "trustworthy email address", because these do not exist.
Re: (Score:2)
Well, 2-sided cert authentication or key-pair is good. Pretty much the same as the SSH default with client certs where server cert and cert of the account on the server gets checked as well. You just need to log in once and verify that log-in went to the right target.
Re: (Score:2)
Oh, and ssh with 2FA is great... especially for access to a pull backup machine.
Re: (Score:2)
Oh, and ssh with 2FA is great... especially for access to a pull backup machine.
Indeed, that is why I looked into it. At the moment I plan to do push with chrooted sftp and WORM behavior, but I have not finally decided yet. May do pull after all.
Re: (Score:2)
SSH with password and a security key (like Yubikey) is the more secure option. The key does the crypto on-board, so the secrets never leave it and there is no way to extract them. Requiring a touch prevents malware from using the key if it is left plugged in.
Re: (Score:2)
Don't overdo it. Security is risk management and "more secure" only makes sense if it is free or there is a credible threat that is worse than the additional effort needed. Hence 2FA via Google authenticator (or others) on a regular phone is quite fine in most cases.
If you are concerned about the 2nd Factor secret getting stolen online, you can use an old phone without SIM card to run the authenticator or something like that. Way more secure than that Yubikey, which may have vulnerabilities. If there is no
Re: (Score:2)
wouldn't even let certificate-based SSH be accessed via a routable IP address!
Why not? That's probably about as hard to exploit as a certificate-based VPN. And you can throw fail2ban on it if you're worried about annoying brute-force attacks (which, since you've disabled password auth, right, are really only annoyances.)
Re: (Score:2)
It is still attack surface naked on the internet and difficult to mask. I was always taught to have two independent levels of authentication before you can get to (effectively) root accesss.
Re: (Score:2)
Because you are trusting that your users have secured their private certificates with a passphrase. Problem is lots of them don't and there is absolutely no way to check if they have. It has been a problem in the HPC community for a couple of years now and why back in 2020 we disabled certificate based SSH access. As hackers where jumping from HPC to HPC all over Europe back in April 2020 I was ready to pull the trigger on banning certificate based SSH access and blacklisting all the existing certificates o
Re: (Score:2)
But password-only auth assumes users will pick strong passwords which can't easily be enforced.
MFA is definitely an improvement.
Re: (Score:3)
There is plenty of low hanging fruit. Throwing out the "special characters" requirement would permit people to use longer, memorable, less easily brute forced passwords. There is a famous XKCD cartoon about just this problem.
https://xkcd.com/936/ [xkcd.com]
Re: (Score:2)
Help I can't login!! (Score:3, Funny)
My account is locked out and I keep getting text messages about having to pay a ransom in order to get back into my own system. Please help me!!
Re:Help I can't login!! (Score:5, Funny)
It's not a ransom, it's called a Microsoft subscription.
Re:Help I can't login!! (Score:5, Funny)
MS Ransom/365.
And once again, Microsoft is decades late (Score:2)
As far as I remember, my first Solaris account about 35 years ago already did that as default. After 3 failed log-ins.
Re: (Score:3)
Re: (Score:2)
The entire thing needs a ground-up re-write.
Yes, like so much MS stuff. So the problem is RDS does things differently? Well, then the fact that RDS authenticates differently is a big red flag and points to a broken design. Again, as with so much MS stuff.
Re: (Score:2)
Re: (Score:2)
Anyways, having any method of password-based authentication that does not come with a timeout after failed attempts is simply just completely incompetent and was already so when RDS was designed, because that basic insight into how to do password authentication of any kind is a lot _older_ than MS RDS. Of coruse it is just like MS to have that delay for local, in person login (where it does not matter much), but is missing it on remote login (where it is a catastrophe).
No idea how you can paint yourself int
DOS (Score:5, Informative)
How long before this becomes a vector to purposely lock out admins during an attack?
Re: DOS (Score:2)
If they differentiate between remote and local access it's feasible.
But the sysadmins will need to get the butt out of the chair to make a local server login.
Re: (Score:2)
It was a vector for DOS 30 years ago.
Re: (Score:2)
The default lockout period is 10 minutes, so worst case you just need to block the external attack and then wait a while before you can log in as admin.
Re: (Score:2)
This presumes they don't have a foothold inside your LAN already. Which means you are going to need to isolate it within the LAN. If this is happening to every machine then you are going to need to take down the entire LAN.
A tip for MS system admin (Score:2)
Try turning it off again.
Geo Blocking & disable if failed ~ 50 times (Score:2)
1. Geo-blocking. Attacks against my server come from three primary countries; why can I block those countries (easily)?
(Hand in had with this: Block all VIP (rogue) servers. The list those is growing too)
2. If "someone" tries 60 log in attempts in 50 seconds; there is a good chance "they" are not a person; block them.
Does anyone look at their {server/client} access log files anymore? I see the same brute force attacks against my server multiple tim
Re: (Score:2)
Re: (Score:2)
Why not -- when the first one (hack) attempts; block that IP from accessing my server (ever) again?
That's definitely a good strategy. On my web server I have an automated detection for the most common URL patterns used in attacks, built into htaccess. At the first attempt to fetch an address matching that reference set, the IP gets permanently added to a banned list. Banned IPs get served a 403 Forbidden response. It wasn't too hard to implement, and there are lots of examples of similar systems on the web.
p@55w0rd (Score:2)
Account lockouts are stupid (Score:4, Interesting)
The account lockout feature has always been there, and it's a useless bit of security theatre...
Attackers don't brute force a single account with thousands of passwords, indeed an external attacker usually doesn't know what accounts you have aside from the default "administrator" or "root" on a unix box. Instead they will iterate through usernames instead of passwords, looking for accounts with some of the top 10 most common passwords. The account lockout function will not do anything about this because you're not trying 10 logins to the same account.
Second, if an attacker does know your usernames then he can intentionally lock your accounts repeatedly to cause disruption. That's why the admin account was always exempt from account lockouts, otherwise someone can just hit it repeatedly and prevent you from logging in.
The worst part about is account lockouts is that the users themselves can't do anything about it. Set a strong password? Doesn't matter, now you're not allowed to log in because some bot halfway around the world can't guess your password.
Re: (Score:2)
And yet somehow RDP is a common vector for malware attacks.
It's often not difficult to guess account names, because many companies use standard formats like firstname.lastname. When integrated with email, emails leak usernames too.
The account lockout is for 10 minutes by default. If you see it happen you just need to block the attack at the router, or unplug the affected machine from the network, and wait until the 10 minutes are up before logging in.
Re:Account lockouts are stupid (Score:4, Interesting)
If you need to guess account names, that is a brute force in itself and it won't trigger any lockout. In reality this is exactly what attackers do...
john.smith Password1
jane.smith Password1
etc etc, so the lockouts are never triggered.
By the time you have been through your entire userlist with Password1, and you're ready to start Summer2022 or Password123! chances are the lockout timer has expired.
And this is why brute force attacks are successful despite that a lot of systems already have account lockouts enabled.
If you had the capability to block the source address that might be different, although an attacker is likely to be able to launch attacks from a large number of compromised systems (each just making one or two attempts).
However these days blocking source addresses is also problematic because of things like NAT. Because of deficiencies in IPv4, lots of ISPs and especially mobile operators NAT their entire customer base through a small pool of addresses. If the attacker originates from the same source address as your legitimate users, it's not practical to block them. I've personally witnessed companies block the NAT-pool of the telco which supplies their corporate mobiles, resulting in everyone being unable to access their mobile email all day.
As a security measure... (Score:3)
Security: Off by default (Score:1)