Password theft is a very serious problem that Microsoft seems to have focused on for quite some time now. A key point for this is the implementation of accreditation systems in two or more steps, limiting the potential scope of a stolen or insecure password, of course, but also analyzing the means used by cybercriminals to get hold of them, to try to find a solution.
Today we read, in Bleeping Computer, that the Local Security Authority Subsystem Service, LSASS for its acronym in English, has been exploited by cybercriminals precisely for that purpose, to compromise credentials that are subsequently used in multiple schemes of attacks within network infrastructures, in order to spread laterally to other systems on the same network.
The process is effective when a system is used with more than one account, and it consists of obtaining administration credentials on it and, subsequently, carrying out a memory dump process of LSASS, which is executed locally in Windows. And it is that the content of said memory dump, among other things, contains NTLM hashes of the credentials of those users who have used said system.
Microsoft had already taken action in the past against this threat. For example, Windows Defender blocks applications that carry out this task, such as Minikatz. The problem is that, despite this, cybercriminals can still design specific tools or resort to unidentified ones and carry out memory dumps to obtain said hashes, which will facilitate the subsequent attack on other accounts and systems that may be compromised..
Thus, Microsoft has taken a more forceful decision, which is to severely limit access to the LSASS process, and for this purpose has created a new rule, called “Block theft of credentials from the local security authority subsystem of Windows”. Their values, by default, will be Configured and the default mode will be set to Block.
This move is part of a more aggressive policy by Microsoft against threats. In it, some measures are being taken that limit access to functions widely used by some users, but that in their current state do not provide the level of security necessary to keep them operational. These measures are intended to reduce the attack surface and, most likely, in the short and medium term we will continue to see movements in this direction.
Convenience or security? This is the question that arises in this context and with this step by Microsoft, and it is that some of these changes may have a negative impact, as we have planned before, on the work of some people. The problem is that, due to their nature, there are many elements that are potentially insecure, and despite an in-depth analysis of them, no solutions seem to appear that allow them to be kept in the same conditions as up to now, but with an acceptable level of security.
So in cases like this, I think Microsoft acts as responsibly as possible, providing a level of security that is consistent with what users expect. And, in hindsight, whenever possible, you can hope to improve on that, like bringing back features once they’ve been shielded. But today, safety must come first.