Ttdfjt

I know that exists tools for get the passwords in plain text from memory in Windows (read memory and decrypt password from LSASS process).

This behavior still exists in The Windows Server 2019 ?

Is there any way of avoiding that a local admin user get the password from a Windows machine using some of this tools, for example Mimikatz?

Thanks.

No to avoid it, as to steal kerberos ticket or NTLM hash keep in mind the user must be a local administrator, and the application must be run as a admin too.

Please see that note from mimikatz;

Run Mimikatz as Administrator: Mimikatz needs to be “Run as Admin” to function completely, even if you are using an Administrator account.

As such it fall into the 10 immutable laws of security; See the one in bold;

Law #1: If a bad guy can persuade you to run his program on your
computer, it's not solely your computer anymore.

Law #2: If a bad guy can alter the operating system on your computer, it's not your computer anymore.

Law #3: If a bad guy has unrestricted physical
access to your computer, it's not your computer anymore.

Law #4: If
you allow a bad guy to run active content in your website, it's not
your website any more.

Law #5: Weak passwords trump strong security.

Law #6: A computer is only as secure as the administrator is trustworthy.

Law #7: Encrypted data is only as secure as its
decryption key.

Law #8: An out-of-date antimalware scanner is only
marginally better than no scanner at all.

Law #9: Absolute anonymity
isn't practically achievable, online or offline.

Law #10: Technology
is not a panacea.

As you fall into the 10 immutable laws of security, Microsoft will never fix that, as a admin can do anything on the computer, even installing a keylogger, who know, as you must understand it's more how you protect your environment against such attack vector that is important.

So at first I would suggest to use restricted group GPO to make sure no one can add itselft to the local admin group.

Secondly I would remove all other boot device than the HDD to secure who can boot on a flash device, to prevent someone that could wipe a local admin account's password.

Thirdly I would protect with a strong password the BIOS.

Lastly, I would use a encryption method for the hard disk, to prevent non-authorized change by a cold boot if someone remove the hard disk from the machine.

There is surelly other tips, but you must abide to a strong security's model if you want to secure your enterprise work space, and enable account auditing if you want to catch a bad actor.

With default settings it's not possible to dump clear text WDigest credentials from the LSA memory anymore, but having local administrator privileges all these new security features can still be disabled, as Microsoft loves to keep backwards compatibility. So, after adding a couple of registry keys Mimikatz – or Kiwi for Windows 10 – starts to function again for all passwords entered after the modifications.

• 
  

  In Windows 8.1 security features were added that stops storing WDigest credentials in clear text, and they were backported to earlier Windows versions in KB2871997, fixing every version since Windows 7. When the feature is enabled, Mimikatz starts showing (null) for the password, but it can be disabled with:

  
  
  

  [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersWDigest]
  "UseLogonCredential"=dword:00000001
  

  
  


• 
  

  In Windows 10, Windows Defender Credential Guard is protecting passwords. After disabling the security feature as described above, the passwords are shown, but they are not in clear text:

  
  
  

  

  
  
  

  However, Windows Defender Credential Guard can be disabled through Group Policy. As this policy effectively just adds two registry keys, it's egually easy to disable e.g. from command prompt.

  
  
  

  [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlDeviceGuard]
  "EnableVirtualizationBasedSecurity"=dword:00000000
  
  [HKEY_LOCAL_MACHINESystemCurrentControlSetControlLSA]
  "LsaCfgFlags"=dword:00000000
  

  
  
  

  Once a user uses his password again, it appears in clear text:

  
  
  

  

  
  

As this could easily be used for stealing Domain Administrator credentials, people should not have local admin privileges on their workstations, and separate accounts without Domain Administrator privileges should be used for local administration.

I would like to propose a solution that does actually work fairly well in practice. The other answers hint that it's impossible to protect perfectly, but you can make it difficult enough that most attackers will give up and move on to easier targets.

First, enable Credential Guard. This will move the secrets out of LSA so attackers can't read the passwords out of process memory.

Second, enable LSA Protected Process mode (RunAsPPL=1). This will prevent attackers from injecting code into LSA or reading memory.

Third, enable HVCI to prevent attackers from disabling the above protections from within the kernel.

Forth, lock this all down with UEFI so even if an attacker does screw with the registry keys, it's incredibly difficult to disable since the config is locked in by UEFI boot settings.