How to investigate potential infected client workstation

Question

In this case a central endpoint security or SIEM solution alerts on Indicators of Compromise on one client workstation in a Windows domain.

Should there be an IT staff who has admin accounts (domain accounts) on these workstations?

1. Admin logs with domain account in per RDP with NTLM-Authentication (interactive logon type): Dangerous because the credentials are stored in LSASS Memory and are dumpable as ntlm hash from a dump with tools like famous mimikatz, WCE, ...(?)

2. Admin logs with a domain account using SMB, WMI, WinRM (network logon) (also NTLM-auth, no Kerberos): Is this safe? Microsoft documentation says that there a no credential cached with a network login. An access token is created but with these, if you use token impersonation techniques, you cannot authenticate remotely to another host on network. But the potential attacker on workstation can replay the netntlmv2 hash? So doing a relay attack with tools like inveight, responder, ...

3. If Admins are part of "Protected User Group", there are only enabled to authenticate with kerberos isn't it? So it would be safe to use RDP AND/OR smb, wmi, etc?

What is the best practice here?

Every time use the LAPS Account for investigation?

Answer 1

First, why are you suggesting NTLM everywhere? That alone is unsafe. Stick to Kerberos in a domain environment.

Option 1 is unsafe. Regardless of what NLA does for NTLM or Kerberos, it will fire the credential in plaintext to the remote machine and the compromised host will have the raw creds.

Option 2 is better as it doesn't leave any credentials on the machine. It does limit what you can do on the machine, so the utility of this option is "ehhh".

Option 3 does not protect you in RDP scenarios. You still fire the raw credential to the remote machine and the compromised host can do whatever they want with it.

What you should do is use Restricted Admin or Remote Credential Guard. For either of these you need to enable this registry value on the target machines:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa
DisableRestrictedAdmin DWORD = 0

Restricted Admin authenticates you to the remote machine but doesn't fire the raw credentials over. Once you've authenticated it switches to using the target machine account for outbound authentication. The side effect is any outbound access to network shares and is as the machine itself and not as the user. To connect to the remote machine you call the RDP app from the command line:

mstsc /restrictedAdmin

Remote Credential Guard is similar, but it allows you to act as yourself by instead proxying any ticket requests that normally require the credential back to the client itself. This means any outbound requests will operate as your user instead of the machine.

mstsc /remoteGuard