ESET Live Grid Blank Application Name / Details

[rememberSiberia 0]

9 minutes ago, itman said:

There's also another possibility why you're not seeing any path info for lsalso.exe in your Process Explorer output. Note the following:

https://techcommunity.microsoft.com/t5/windows-it-pro-blog/comprehensive-protection-for-your-credentials-with-credential/ba-p/765314

That is Credential Guard is activated on your device. Read the entire article for various ways to verify if Credential Guard is installed and operational. If not, the following paragraph might be the reason.

I do know in recent years Microsoft has implemented protection mechanisms on Win 10 that initially were only reserved for Enterprise versions. One might be to provide credential protection. This would be most applicable when the device conforms to other Microsoft security requirements such as it has a UEFI, TPM module installed, and Secure Boot option enabled.

Wow amazing thanks for sharing this. I think that's exactly my situation. Further down it also describes the Core Isolation functionality, which I have turned on. Perhaps that's ultimately the reason why LsaIso's details are blank. Do you have Core Isolation turned on?

Also, since I have Core Isolation turned on and LsaIso details are blank (as explained this is evidence of VM being turned on, at least one of the two methods to check), then do I need to turn on Virtualisation Based Security in the Group Policy editor?

Edited July 1, 2021 by rememberSiberia

[itman 1,659]

4 minutes ago, rememberSiberia said:

Do you have Core Isolation turned on?

Yes. But that wouldn't be a factor.

However, Memory Isolation option may be. I have this also enabled. However as the MS article notes, all that is active on my device is the Key Guard feature.

[itman 1,659]

6 minutes ago, rememberSiberia said:

then do I need to turn on Virtualisation Based Security in the Group Policy editor?

Use Windows System Information option to determine if VBS is enabled. On my device, it is only implemented at the base level; i.e. minimal protection.

[rememberSiberia 0]

4 minutes ago, itman said:

Yes. But that wouldn't be a factor.

However, Memory Isolation option may be. I have this also enabled. However as the MS article notes, all that is active on my device is the Key Guard feature.

I think this is the explanation (I might be wrong):

"So even if you had Credential Guard running and had LSA configured as a protected process, an attacker could manipulate process execution from within the kernel.

That’s not strictly true anymore with the introduction of Hypervisor-protected code integrity (HVCI), which is specifically designed to protect the kernel against tampering. HVCI works by adding a degree of separation and moving control of the system’s memory to a secure runtime environment created by the hypervisor."

It seems that HVCI supersedes Credential Guard, which is why I see "Hypervisor enforced Code Integrity" in MSINFO32 instead of "Credential Guard" (as detailed in the guide via the link that you provided - huge thanks again).

Edited July 1, 2021 by rememberSiberia

[rememberSiberia 0]

Sorry what I said above is wrong. You can have both HVCI and Credential Guard enabled, as shown here in the middle of the page (screenshot from someone's MSINFO32):

https://docs.microsoft.com/en-gb/windows/security/identity-protection/credential-guard/credential-guard-manage#enable-windows-defender-credential-guard

[itman 1,659]

One final comment and I am done.

In regards to setting lsass.exe as a Protected Process - Light protected via registry or Group policy option, view it as "Band-Aid" protection against credential stealing because:

1. It's relatively trivial for an advanced attacker to bypass PPL protection.

2. PPL won't protect against the various credential dumping methods; e.g. ProcDump, that exist.

Edited July 1, 2021 by itman

[itman 1,659]

Looks like I was wrong about Win 10 Enterprise being a requirement for Credential Guard protection.

According to this recent Microsoft TechNet article: https://techcommunity.microsoft.com/t5/iis-support-blog/windows-10-device-guard-and-credential-guard-demystified/ba-p/376419 , all that is required is to enable Hyper-V Memory Integrity protection in any Windows version. This is confirmed via following Win System Information screen shot:

I have no idea why both Process Explorer and Win Task Manager show lsalso.exe running rather than lsaiso.exe. One explanation is that lsaiso.exe is running in a virtual container and neither PE or TM have access to it. They both instead just shown the non-virtualized instance, lsalso.exe, instead. At least PE shows via lsalso.exe image display that the path is to lsaiso.exe.

-EDIT- Or what very well may be the case is both PE and Win TM are showing lsaiso.exe with a capital "i"; lsalso.exe, instead. Ditto for Win explorer.exe display of it when viewing the System32 directory.

Also from this article: https://docs.microsoft.com/en-gb/windows/security/identity-protection/credential-guard/credential-guard-manage#enable-windows-defender-credential-guard

Quote

You can use Windows PowerShell to determine whether credential guard is running on a client computer. On the computer in question, open an elevated PowerShell window and run the following command:

PowerShell -

(Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning

This command generates the following output:

• 0: Windows Defender Credential Guard is disabled (not running)

• 1: Windows Defender Credential Guard is enabled (running)

  Note

  Checking the task list or Task Manager to see if LSAISO.exe is running is not a recommended method for determining whether Windows Defender Credential Guard is running.

 

I received an output value of "2." I assume that indicates Windows Defender Credential Guard is being used in a limited mode that only protects lsass.exe.

Also of note is what I underlined above.

Edited July 2, 2021 by itman