Threat Hunting with Windows Event Logs: A Guide to Detecting Malicious Account Activity

Attackers love to exploit user accounts. Whether they’re creating rogue admin accounts, hijacking legitimate credentials for lateral movement, or abusing built-in accounts to stay hidden, malicious account activity is a hallmark of modern cyberattacks. If you’re not actively hunting for these behaviors, you could have an intruder lurking in your network undetected.

Fortunately, you have a powerful, built-in tool at your disposal: Windows Event Logs. By enabling and monitoring the right events, you can uncover the subtle clues of an attack in progress. Let’s dive into how you can use advanced account auditing to hunt down malicious user activity.

Why Auditing User Accounts Is a Game-Changer 

Actively monitoring account activity is a critical defense strategy. Frameworks like MITRE ATT&CK® highlight numerous techniques that revolve around compromising and creating accounts. Attackers use valid accounts—from standard users to domain admins—to blend in with normal traffic, making them notoriously difficult to spot.

By turning on advanced auditing, you gain the visibility needed to detect these techniques. This guide focuses on Windows accounts, which includes activity on your domain controllers, local machines, and even some Azure-connected services. Whether an attacker is using a local guest account or a domain service account, these hunting techniques are your key to finding them.

Log Location is Everything: Where to Look for Clues

To effectively hunt for threats, you must pull logs from the right sources. The location of an event tells a story.

• Domain Controllers (DCs): This is ground zero for hunting domain-level credential abuse. Your DCs log all authentication attempts for domain accounts. Keep a close eye on critical assets like admin, service, and application accounts by monitoring your DC event logs. Correlating these events across your domain can reveal widespread attacks.

• Servers (Non-DC): Don’t stop at the DC. Other Windows servers, like those running IIS or SQL, also have valuable local accounts. Attackers often exploit these local accounts (e.g., local admin, guest) as a blind spot, knowing that many security teams focus exclusively on domain logs.

• Workstations: User endpoints are a primary target. An attacker might compromise a local account on a workstation to establish a foothold before attempting to escalate privileges or move laterally. Monitoring these local logon events is crucial for catching an initial breach.

How to Enable Advanced Account Auditing in Windows

Most of the critical security events we’ll discuss are not enabled by default. You have to turn them on. You can do this at the local level or, for better consistency in a corporate environment, through a Group Policy Object (GPO).

To enable auditing on a local machine:

1. Open the Local Security Policy editor (search for secpol.msc).

2. Navigate to Security Settings -> Advanced Audit Policy Configuration -> System Audit Policies.

3. Here, you’ll find several categories, including Account Logon, Account Management, and Logon/Logoff.

4. Open the relevant category (e.g., Account Management) and configure the specific subcategories you want to audit. Be sure to check the boxes for both Success and Failure to capture all relevant activity.

Microsoft provides detailed recommendations on which policies to enable for domain controllers, servers, and workstations. It’s wise to consult their documentation to build a robust auditing baseline.

Key Event IDs for Hunting Malicious Account Activity

Once auditing is enabled, your systems will start generating a wealth of security data. While there are many valuable event IDs, let’s focus on four powerful ones for hunting account abuse.

Event ID $4720$: A User Account Was Created

This event is your first alert that a new user account has been created on a local machine or a domain controller. While account creation is a normal IT function, it’s also a classic move by attackers to create a persistent backdoor.

Key Data to Watch:

• Account Name: The name of the new account.

• Primary Group ID: The group the new account belongs to.

• Fields that should be empty on creation, like Password Last Set or Home Directory.

Threat Hunting Tips:

• Hunt for unusual Group IDs: By default, new user accounts are assigned the Domain Users group, which has a Group ID of $513$. If you see an Event ID $4720$ where the Primary Group ID is not $513$, investigate immediately. This could indicate the creation of a privileged account (like an admin).

• Look for pre-filled attributes: A brand-new account shouldn’t have a value for Password Last Set. If you see this or other fields populated upon creation, it could be a sign of suspicious activity.

Event ID $4798$: User Group Membership Was Enumerated

Before an attacker escalates privileges, they first need to figure out which accounts have power. This event is generated when a tool is used to enumerate the members of a local group, a common reconnaissance step performed by tools like BloodHound.

Key Data to Watch:

• User: The account being queried.

• Process Name and Process Information: The executable that performed the enumeration.

Threat Hunting Tips:

• Watch for suspicious processes: Look for enumeration activity originating from non-standard processes. While net.exe or PowerShell can be legitimate, enumeration from a process running from a strange directory (C:\Users\Public\) or with a suspicious name (recon.exe) warrants investigation.

• Monitor for spikes in activity: A single enumeration might be normal. A sudden storm of $4798$ events across many machines or users could signal an automated reconnaissance tool at work.

Event ID $4740$: A User Account Was Locked Out

Account lockouts are often caused by users forgetting their password. However, they are also a tell-tale sign of a brute-force attack, where an attacker is rapidly guessing passwords for an account (like Administrator or admin).

Key Data to Watch:

• Account Name: The account that was locked out.

• Caller Computer Name: The name of the computer where the failed logon attempts originated. Note: this is a computer name, not an IP address.

Threat Hunting Tips:

• Hunt for non-system account lockouts: The only account that should be locking other accounts is the built-in SYSTEM account. If the Security ID in this event isn’t for SYSTEM, it’s a major red flag.

• Correlate with critical accounts: Pay close attention to lockouts for high-value accounts (admins, service accounts, executives).

• Check the source: Is the Caller Computer Name an unfamiliar machine or one that has no business authenticating with that user’s credentials? If you see junk computer names or names outside your domain, start digging.

Event ID $4738$: A User Account Was Changed

This event is generated whenever an attribute of a user account is modified. This is an incredibly rich log for threat hunting because it can reveal an attacker subtly altering an account’s security settings to their advantage. The event log shows which fields were changed and their new values.

Key Data to Watch:

• The specific fields that were changed (e.g., User Account Control, Password Not Required, Smartcard required). Unchanged fields will show a -.

Threat Hunting Tips:

• Look for security downgrades: Hunt for changes to critical security flags. Did an attacker disable the “Password Not Required” flag? Or change a User Account Control setting to allow for delegation? These are classic attacker techniques.

• Monitor changes to high-value accounts: Just like with other events, any unexpected change to a critical account should be scrutinized. Why was a service account’s password policy suddenly changed?

• Context is key: Understanding what’s normal for your environment is crucial. A change to a user’s home directory might be routine, but a change that allows the account to bypass smart card authentication is a five-alarm fire.