I’ve explained How to build a Custom UEBA with KQL to Hunt for Lateral Movement in Microsoft 365 Defender in my previous post. The solution covers domain accounts. In this post, I’ll cover Lateral Movement involving local accounts.
Usually, there are a few local accounts in an enterprise. These accounts often have high privileges on many systems. Compromising one account opens all the doors if the password of each local account is the same. Password management tools like Microsoft LAPS usually mitigate this risk. However, mistakes can be made. For example, an administrator can request the password of a local account for 2 weeks duration. During this period, the account’s password is not changed… You might guess the rest of the story.
Like service accounts, local accounts are used by specific users/services from specific locations. We can apply the same logic as in the previous post and hunt for local account anomalies. There is a trick, though. While the IdentityLogons table has the FQDN of the device, the DeviceLogonEvents table has only the hostname. We need to normalize the DeviceName to the hostname to make the correlation work. I’m not going to explain everything again; you can read the idea behind this in my previous post.
You can find the query in my Github repo.