Threat Hunting #21 - Hiding in plain sights with real or rogue computer accounts - Part 2/2

In Part 1 of hiding in plain sights with a rogue computer account, we've discussed the problem of filtering false positives based on the presence or not of the "$" sign in the source or destination account name of a specific event.  In this part we will demonstrate how an attacker can use this "technique" and what are the resulting artifacts that an analyst can refer to:

Method 1: using psexec to move laterally 

After obtaining valid domain privileged credentials (we name here EXAMPLE\admin01), the attacker will create a fake computer account (named EXAMPLE\SERVER01) using Net.exe.

This move, will generate an event 4720 User Account Created (instead of 4741 for Computer Account Created):

Next the attacker will use psexec.exe to start a privileged interactive shell from PC01 to the Primary Domain Controller (10.0.2.15):

This action, will generate some artifacts related to PsExec excution we've already discussed in a previous post. In this case we are more interested by possible artifacts related to the use of the fake/rogue computer account (SERVER01$).

On PC01 (client) you can see below, no file system user profile is loaded (which is expected, no local authentication):

Same for the server side (10.0.2.15|DC), no file system or registry user profile is loaded (expected as well, because we are running in the context of a system service PsExec created spoolsrv):

For more information about the different windows user profiles please refer to this article.

Method 2:  Using Net.exe use to move laterally with the fake computer account

Same as for method 1, no user profile is loaded (registry, file system and user profile service application logs). BUT because our authentication went through ntlm, we can see below some event logs that can help us spot the abnormal authentication activity (if monitored):

But, for 4624, not always the source workstation names is populated, only when the authentication package is NTLM, for kerberos it will usually be equal to "-".


Method 3: Logon with explicit credentials using RunAs utility

Same as for method 2,  the authentication will go via NTLM which will generate same artifacts:

Takeaways:

1. No user profile is loaded (file system, registry) for the above remote access methods.
2. If NTLM is used as the authentication package, the source workstation name will be populated, in 4624, otherwise if it's Kerberos only the source IP will be logged.
3. Net users or Net users /domain will return only accounts without the $ sign in their names (not necessarily a real computer account).
4. Implement the use cases we've shared in Part 1/2 of this post. 

References:

https://docs.microsoft.com/en-us/windows-server/storage/folder-redirection/troubleshoot-user-profiles-events