4624, 4625, 4688, 4720, 4732, 4776, 7045 and 4104 are the Windows event IDs I check first in every SOC investigation. What each one tells you, which fields matter, and how they show up in my lab.
When an alert lands in a SOC queue, the first question is always the same: what actually happened on that machine? On Windows endpoints the answer almost always starts in the Security event log. These are the eight event IDs I check first, what each one tells me, and how they show up in my home lab. I keep this list taped to the side of my monitor, and every investigation I have run in the lab has started with at least two of them.
An account successfully logged on. On its own it means little. The value is in the fields. Logon Type 3 is a network logon, Type 10 is Remote Desktop, Type 7 is a workstation unlock. Pair the source IP and the account name with what you expected to see. A 4624 for an admin account from an IP that has never touched that server, at an hour when nobody works, is a finding. In my lab, the moment a brute force run finally guesses right, this is the event that proves it. Sequence matters: a wall of failures followed by one success is a different story than a success on its own.
An account failed to log on. This is the raw material of brute force and password spray detection, and it is the event behind my LAB-001 SSH investigation on the Linux side of the same pattern. Read the sub status codes, they tell you why it failed:
That distinction changes the priority of the alert. Failures against accounts that do not exist is reconnaissance noise until the volume gets serious. Failures against your real admin account is an incident in progress.
A new process has been created. This is the single most useful event for understanding what ran on a machine. It only earns its keep if you turn on command line logging through group policy, Audit Process Creation plus the setting to include the command line. Without the command line you know powershell.exe ran. With it you know powershell.exe ran with an encoded command and a download cradle. In my lab, 4688 with command line is what turns a vague alert into a timeline: parent process, child process, exact arguments, in order.
A user account was created. On a workstation, this should be rare and almost always tied to IT work. On a compromised machine, it is persistence: the attacker making their own way back in that does not depend on the password they stole. When I see 4720 I immediately ask who created it, which account was used, and what happened in the ten minutes after. The answer to that last part is usually the next event on this list.
A member was added to a local group. The one that matters is Administrators, and in the log you will see the group identified by its SID ending in 544. 4720 followed by 4732 is the classic one two punch: new account, instant admin. Either event alone deserves a look. Together, outside a change window, they are about as close to a confirmed incident as a pair of log lines gets. Both fired cleanly in my lab the first time I simulated it, which told me my Wazuh rules for account tampering were in good shape.
The computer attempted to validate the logon credentials for an account. On a domain controller this is NTLM authentication being checked. I watch it during password spray simulations because NTLM attempts against the DC show up here even when the target machine's own logs are thin. A run of 4776 failures across many different account names from one workstation is a spray, whatever the threshold rules on the endpoint say. It is also a good reminder that the DC often sees the attack before the victim does.
This one lives in the System log, not Security, and new analysts miss it for weeks. A service was installed on the system. Legitimate software does this. So does PsExec, so do remote access tools, so does a lot of malware setting up persistence. The event gives you the service name, the file path, and the start type. A service pointing at a binary in a temp or users folder, set to start automatically, is never a good sign. I check 7045 on any machine where I have already seen suspicious 4688 activity, because the service is often how the attacker plans to survive a reboot.
Windows PowerShell script block logging recorded a block of code. If 4688 tells you PowerShell ran, 4104 shows you what it actually did, including code that was obfuscated on the command line and only becomes readable when it executes. Attackers know this log exists, which is why some frameworks try to downgrade or bypass it, and the attempt itself leaves traces in other event IDs. In the lab, 4104 is where I go to confirm intent. A suspicious process is a maybe. The decoded script content is a yes or a no.
Order of operations in a real investigation: start with 4625 and 4624 to establish who authenticated and whether they should have. Move to 4688 and 4104 to see what ran. Then 4720, 4732 and 7045 to answer the persistence question, did they leave themselves a way back in? 4776 fills the gap when the authentication happened against the DC instead of the endpoint. Eight IDs will not cover everything Windows logs, but they cover the first hour of almost any investigation I have practised, including the 50 plus simulations in my attack simulation results.
Next: building the same first check list for Linux, starting with auth.log patterns and the journald equivalents.
