Microsoft Defender Will Soon Block Windows Password Theft (bleepingcomputer.com) 33
Microsoft is enabling a Microsoft Defender 'Attack Surface Reduction' security rule by default to block hackers' attempts to steal Windows credentials from the LSASS process. BleepingComputer reports: When threat actors compromise a network, they attempt to spread laterally to other devices by stealing credentials or using exploits. One of the most common methods to steal Windows credentials is to gain admin privileges on a compromised device and then dump the memory of the Local Security Authority Server Service (LSASS) process running in Windows. This memory dump contains NTLM hashes of Windows credentials of users who had logged into the computer that can be brute-forced for clear-text passwords or used in Pass-the-Hash attacks to login into other devices. While Microsoft Defender block programs like Mimikatz, a LSASS memory dump can still be transferred to a remote computer to dump credentials without fear of being blocked.
To prevent threat actors from abusing LSASS memory dumps, Microsoft has introduced security features that prevent access to the LSASS process. One of these security features is Credential Guard, which isolates the LSASS process in a virtualized container that prevents other processes from accessing it. However, this feature can lead to conflicts with drivers or applications, causing some organizations not to enable it. As a way to mitigate Windows credential theft without causing the conflicts introduced by Credential Guard, Microsoft will soon be enabling a Microsoft Defender Attack Surface Reduction (ASR) rule by default. The rule, ' Block credential stealing from the Windows local security authority subsystem,' prevents processes from opening the LSASS process and dumping its memory, even if it has administrative privileges.
While enabling the ASR rule by default will significantly impact the stealing of Windows credentials, it is not a silver bullet by any means. This is because the full Attack Surface Reduction feature is only supported on Windows Enterprise licenses running Microsoft Defender as the primary antivirus. However, BleepingComputer's tests show that the LSASS ASR rule also works on Windows 10 and Windows 11 Pro clients. Unfortunately, once another antivirus solution is installed, ASR is immediately disabled on the device. Furthermore, security researchers have discovered built-in Microsoft Defender exclusion paths allowing threat actors to run their tools from those filenames/directories to bypass the ASR rules and continue to dump the LSASS process. Mimikatz developer Benjamin Delpy told BleepingComputer that Microsoft probably added these built-in exclusions for another rule, but as exclusions affect ALL rules, it bypasses the LSASS restriction.
To prevent threat actors from abusing LSASS memory dumps, Microsoft has introduced security features that prevent access to the LSASS process. One of these security features is Credential Guard, which isolates the LSASS process in a virtualized container that prevents other processes from accessing it. However, this feature can lead to conflicts with drivers or applications, causing some organizations not to enable it. As a way to mitigate Windows credential theft without causing the conflicts introduced by Credential Guard, Microsoft will soon be enabling a Microsoft Defender Attack Surface Reduction (ASR) rule by default. The rule, ' Block credential stealing from the Windows local security authority subsystem,' prevents processes from opening the LSASS process and dumping its memory, even if it has administrative privileges.
While enabling the ASR rule by default will significantly impact the stealing of Windows credentials, it is not a silver bullet by any means. This is because the full Attack Surface Reduction feature is only supported on Windows Enterprise licenses running Microsoft Defender as the primary antivirus. However, BleepingComputer's tests show that the LSASS ASR rule also works on Windows 10 and Windows 11 Pro clients. Unfortunately, once another antivirus solution is installed, ASR is immediately disabled on the device. Furthermore, security researchers have discovered built-in Microsoft Defender exclusion paths allowing threat actors to run their tools from those filenames/directories to bypass the ASR rules and continue to dump the LSASS process. Mimikatz developer Benjamin Delpy told BleepingComputer that Microsoft probably added these built-in exclusions for another rule, but as exclusions affect ALL rules, it bypasses the LSASS restriction.
So a half-assed fix for a stupid design? (Score:1)
That makes me trust them so much more!
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
Re: So a half-assed fix for a stupid design? (Score:1)
Yup, most would rather say I am wrong on obvious corner-case technicalities.
Re: (Score:2)
Indeed. And the little fact that on Unix the problem got solved and is now solved. On Windows you can still attack machines using the same old well-known flaw and it looks like the Windows designers try everything so they can to keep that flaw active. Just replacing the NTLM hash with something cryptographically secure would not have been that hard. They could even have accepted the old and the new for a while and then disable the old one. As passwords get changed, this would not even have been hard in any
Re: (Score:2)
This could be a UNIX issue, but Windows has far more users, and users who have accounts that can easily run code with elevated privs. On most UNIX variants, elevating to root [xkcd.com] takes some explicit action, either by running su, sudo, or using a program that requests elevation from the desktop environment. Windows, generally, it is a lot easier to get elevation, as UAC tends to just be a "yes/no" thing. The amount of times I've dealt with a compromised Linux machine or Mac that had a user hack root, then dum
Re: (Score:1)
Well, true. The fundamental difference is that Windows does not really have a security architecture and hence is deeply stuck in the single-user not-networked OS mind-set. It would require a fundamental redesign to finally be secure and sandboxing the whole OS may indeed be the best thing that can be done absent that redesign. In a sense, Windows has still not arrived in the Internet age.
On Unix, on the other hand, the problem was fixed basically by using the existing, reliable user-separation and adjusting
Re: (Score:2, Informative)
Re: (Score:1)
It's a similar design used by MOST systems. There is some MS dumbassery in there but it's not inherently bad.
The fix is indeed half-assed but only because there is no actual way to fix it. This "fix" won't do shit if you have admin on the machine. The other way of doing it, running it in a virtual machine is idiotic. It just uses up resources for no good reason. The admin still has full control over the VM and raw access to the hardware! There is no possible way to prevent an admin from dumping the memory o
Please understand problem before complaining (Score:2)
Re: (Score:2)
Four words of what you said (Score:5, Interesting)
You pointed out it's designed to transparently (invisibly) send ~credentials to arbitrary systems on the network. Without bothering the user. "This is the problem space that the LSASS process is designed to work in", you said.
Let's think about that for a moment. Send the user's credentials to anyone who asks, without even making the user aware of the fact you're giving out their credentials.
"This is the problem space", you said. Perhaps "this the problem". Maybe we shouldn't be handing over the user's credentials without the user even being informed that you're doing so. Maybe passwords are supposed to be *secret*. Maybe you aren't *supposed to hand them out to anyone who asks for them.
Understanding that, similar functionality can be achieved by encrypting the (opaque) session token with at least a short PIN, if not via the fingerprint reader or other stronger authentication. The user has to enter the pin or tap their finger in order to send their credentials out over the network. Meaning they choose to do so, intentionally. Even a short PIN makes it possible to detect invalid tokens and therefore makes it possible to stop attacks that brute force the secondary authentication - the fingerprint or pin or whatever.
Re: (Score:2)
Let's think about that for a moment. Send the user's credentials to anyone who asks, without even making the user aware of the fact you're giving out their credentials. [...] Maybe passwords are supposed to be *secret*.
Actually I said to implement single sign on, I did not say to transmit or reveal the user's credentials. They are similar but not the same.
Maybe we shouldn't be handing over the user's cred (Score:2)
Even if the system is configured badly (and it falls back on ntlm) it doesn't send plain text password on the wire.
There are of course multiple ways to trigger attacks using Responder, so there are still areas to improve.
It's the access credential (Score:2)
What's sent over is the credential needed to gain access as the user. That's why pass the hash is the thing.
Whether or not it's the same bits as the user-typed password *doesn't matter* - it functions as the password.
Re: (Score:2)
There isn't an alternative. You want to have network based logins, you have to send credentials over the network. It doesn't matter if the user is prompted for them or not because most users are not competent to decide when they should enter their password, they just blindly do it when told to.
The specific issue this addresses is that credentials can be recovered locally by getting the NTLM hash. Like hashes on Unix systems, they are stored in a protected file, which is why malware often attacks the process
Re: (Score:2)
Maybe we shouldn't be handing over the user's credentials without the user even being informed that you're doing so. Maybe passwords are supposed to be *secret*. Maybe you aren't *supposed to hand them out to anyone who asks for them.
Maybe. But then maybe we also shouldn't live in a world where 50% of my time is spent logging into systems handing over credentials I happily hand over anyway just to do the most basic tasks I need to.
It's 2022. I'm no longer working on just my computer in a bubble. THAT is the problem space. As an aside you just proposed a solution that involves bombarding users with confirmation. I suppose you think UAC successfully stopped all malware right? No of course not. Asking a user to do something invariably invo
Re: (Score:3)
Ok, I'll assume this is a sincere question. Those do still happen on Slashdot.
The first part is that they're going to have to break backward compatibility. It's not as if Microsoft doesn't do this regularly anyway. So let's take that as a given. What are the solutions, if we don't have to make this thing work with any existing software?
Let's start with Kerberos, a system Microsoft did reimplement (imperfectly, although there are Windows binaries for complete Kerberos implementations). This is designed to pr
Re: (Score:2)
Microsoft goes out of its way to maintain backwards compatibility for corporate stuff like network credentials. As an example, Windows 11 supports a bunch of old versions of the SMB protocol and of the NTLM stuff that are known to be flawed due to weak crypto and design errors. They are turned off by default, but still there and supported because some corporate customers can't or won't upgrade their systems.
That's part of the problem for Microsoft. Any improvement they make will takes decades to permeate th
If your code gained admin priviledges (Score:1)
Couldn't you just display a fake "enter password" screen? Most people are just going to assume nothing weird is going on, since it's fairly common on smartphones to be repeatedly nagged to provide your login every time the fingerprint reader/face recognition malfunctions.
Also iTunes. Damn thing loves asking you to login like Slashdot editors love dupes. If you made an malicious app to steal iTunes passwords, all it would need to do is show a fake login prompt. No one would think anything of it.
Re: (Score:2)
I realize the article is about Windows, what I meant by using a smartphone example is that it has trained people to be accustomed to repeatedly verifing your credentials on a device where you're ostensibly already "logged in". From a security perspective, that wasn't such a great idea, since it means if a malicious application asks for your login credentials, you probably will provide them without even realizing that you're making a terrible mistake.
Plain text (Score:2)
Re: (Score:2)
No, these days it uses what appears to be such a weak hashing algorithm that there's a roaring trade in password recovery tools.
Re: (Score:2)
Windows and various Windows applications uses the Credentials Management API for storing credentials these days in an opaque, encrypted format.
As is normal for Windows, attempting to use the Credentials Management API requires bashing your skull against a brick wall repeatedly as you try to understand why it is so badly documented, why it is poorly designed for your use-case, why you have to link half of Windows into your application to use it, why several SDK header #defines are missing, and why all of the
The 90s called: (Score:2)
Feels like a cash grab though.... (Score:2)
I'm not opposed to the improved security.... but the fact this isn't supported across the board for Windows products is telling. You need an "Enterprise" edition of Windows Server for this? That's one costly license vs the type most small or mid-sized businesses use.
But additionally, this only works when Windows Defender is chosen as the primary anti-virus solution. I get that from the standpoint that it's not Microsoft's problem to write this code into competitor's AV solutions. But couldn't they just i
Credential Guard breaks virtualization (Score:1)
One side effect of using Credential Guard (at least at the time I write this) is that it breaks virtualization using VirtualBox (and possibly other non-MS virtualization tools as well). Credential Guard utilizes Microsoft's Hyper-V technology - even if you haven't explicitly enabled Hyper-V, Credential Guard and a few other of the protective measures (Core Isolation for one) enable enough of it that it will prevent other hypervisors from being able to use Intel VT-x or AMD VT-d; Virtualbox will try to degr