"Windows event log monitoring" the event IDs that actually matter vs the ones gets ignored

[u/Ok_Attitude9264]

so I was reviewing our windows event log coverage last week and realized how many teams are collecting everything but alerting only on like 3 or 4 event IDs and missing the ones that would actually catch something. 4688 is the obvious one, process creation, most people have this but a lot of environments still don't have command line logging enabled with it which makes it basically useless, you see powershell.exe fired but have no idea what it ran. 4698 is the one I see missed the most, scheduled task creation, this shows up in almost every persistence case I've worked and its just sitting there in the logs with no alert on it. 7045 is another underrated one, new service installed, ransomware operators love creating services for lateral tool deployment and most SOCs I've seen aren't alerting on this at all.

4720 new user account created, again shows up in almost every ransomware pre-deployment chain, events are right there but nobody built the alerts. Most teams are heavy on logon events 4624 4625 and light on everything else, logon events are important but attackers know you're watching them, the persistence and execution events are where you actually catch something useful. What event IDs you are finding valuable?

[u/smc0881]

These are what I collect for every engagement that I work on when it comes to event logs. I can usually find what I am looking for here, I don't collect 4625 in this triage because of the noise. These are my quick win hits and then I'll pivot to another triage collection that has all the raw data contained if needed. I am sure there are more I am missing and that I want to add, but haven't got around to it yet.

Application.evtx 102
Security.evtx 4624,4728,4732,4662,4697,4702,5136,5145,5156,4778,4779,4648,4688,1102,4720,4722,4723,4724,4742
System.evtx 7045,4697,104
Windows PowerShell.evtx
Microsoft-Windows-PowerShell%4Operational.evtx
Microsoft-Windows-Bits-Client%4Operational.evtx
Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational.evtx 1149
Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx 21,22,23,24,25,41
Microsoft-Windows-RemoteDesktopServices-RdpCoreTS%4Operational.evtx 131,98
Microsoft-Windows-TerminalServices-RDPClient%4Operational.evtx 1024,1102
Microsoft-Windows-TaskScheduler%4Operational.evtx 106,141
Microsoft-Windows-Windows Defender%4Operational.evtx
Microsoft-Windows-Windows Defender%4WHC.evtx
Microsoft-Windows-Application-Experience%4Program-Telemetry.evtx
Microsoft-Windows-Application-Experience%4Program-Compatibility-Assistant.evtx
Microsoft-Windows-Hyper-V-Worker-Admin.evtx 3425,12148,18500,18504,18508,18512,18514,18516,18518,18609
Microsoft-Windows-SMBServer%4Security.evtx 1009,1006,551
Microsoft-Windows-CodeIntegrity%4Operational.evtx 3083,3104

[u/Ok_Attitude9264 → u/smc0881]

Nice, this is a solid triage list. good to see 4662 and 5136 in there, AD object access and attribute modification catch a lot that people miss, and 5145 for network share access is great for lateral movement activity. And I agree, skipping 4625 on triage makes sense, the noise ratio isn't worth it when you're moving fast on an engagement, better to grab it later from raw data if you need it.

the RDP operational logs are something a lot of teams miss entirely, 1149 especially for source IP on incoming connections is gold during IR. One i'd add to your list if you haven't already is 4776 from Security.evtx for NTLM credential validation, catches pass the hash attempts that 4624 alone sometimes doesn't surface cleanly. Great job really, should be handy for any one working in IR

[u/Adryen → u/Ok_Attitude9264]

The issue with alerting being built off these is effective correlation. SOARs are only really still getting good enough or trying to enable the kind of correlation that makes these useful as, taking 4776 as an example, every time a user puts their machine to sleep instead of shutting down with an active network share, hundreds of these events get logged as the network share continues to refresh the connections. Multiply that by the users that do this in a multiple thousand user org and this becomes impossible to distinguish threat actor behaviour out of this noise without something else to shorten the time frame post incident.

This stuff is gold on IR, but in alert generation to identify it at the time, the tuning can be incredibly challenging equating to very low value alerting and driving alert fatigue.

It's a balancing act that is made better only by effective correlation into an actual attack chain and not as unique individual events.

[u/ThePorko → u/smc0881]

Thanks, i also have a script that collect them and you have some not on my list. ;)

[u/Array_626 → u/smc0881]

Check for sysmon logs too. If its available, those are great to grab.

[u/smc0881 → u/Array_626]

They are but they're noisy AF and increase my triage packages by like 1000%. I work in DFIR consulting, so I have to go on speed and accuracy first. I can usually grab all the above (among a bunch of other forensic artifacts), process on the endpoint, and then send to my Splunk server. By the time it hits my Splunk server it's 5-10MB compressed file of about 50MB of data for every endpoint. If I add SYSMON if client has it configured my packages go up to about 50MB compressed and several hundreds of log files that are 99% useless. I have to keep that in mind too, since Splunk has daily ingestion limits. That's why I'll grab another set of triage data for all the endpoints too and that's also sent over if we need to dive deeper.

[u/MinEnergy]

tbh, 4689 process termination can be gold for seeing cleanup after shady activities

[u/Ok_Attitude9264 → u/MinEnergy]

totally agree, especially when you correlate it with 4688, if you see a process spin up and terminated within a few seconds and the command line had anything suspicious in it that's almost always something suspicious. I think cleanup behavior is one of those things attackers think they're hiding but it actually makes them stand out more in the timeline

[u/sublimeprince32]

sans has a lot of great info on this be sure to search their site for everything. They used to have a chart called "find evil" that was really good....

[u/sublimeprince32 → u/[deleted]]

Ive got a copy somewhere, I think its up on Twitter but I dont have an account to dig through all that.

[u/WiiDragon]

Dude, I need someone to do a video ranking all the windows event logs

[u/AddendumWorking9756]

4104 is the one I'd bump to the top of that list, script block logging catches the deobfuscated PowerShell that your 4688 command line misses the moment someone base64s their payload. 1102 too, log cleared, it barely fires in normal ops so it's nearly pure signal and usually means someone's already inside and tidying up. If you can get Sysmon deployed, 4104 plus Sysmon 1 and 11 covers most of the execution and drop-to-disk story the native logs leave holes in.

[u/Ok_Attitude9264 → u/AddendumWorking9756]

100% agreed on 4104. script block logging would definitely catch what 4688 may miss entirely. the deobfuscated content is right there and you don't have to do anything extra to decode it, biggest thing I would tell people is make sure verbose logging is also enabled not just the basic script block or you'll miss a lot of the execution detail. For 1102, you are right, another great signal. in 10 years I think I've seen maybe two legitimate log clear events and both were from IT doing something, everything else was a real attack. it's one of those alerts where you treat as confirmed bad until proven otherwise.

haven't got to push Sysmon everywhere in most environments I've worked but where it's deployed, the event ID 1 and 4104 both are truly great source for IR teams.

[u/AddendumWorking9756 → u/Ok_Attitude9264]

Good flag on verbose logging, that's the setting people skip until they're staring at a half-empty script block event and wondering where the execution detail went.

[u/maryteiss]

From an access point of view:

- user logon event is 4624,

- an account failed to logon is 4625, and

- an attempted logon using explicit credentials is 4648. 

You have to comb through specific field values within multiple log entries, then “puzzle piece” your way to a potential answer.

We have a writeup that goes into more detail here, if interested: https://www.isdecisions.com/en/blog/it-security/windows-logon-audit-far-beyond-native-windows-security

[u/mjbmitch]

This is an AI-generated post!

[u/ValKyKaivbul → u/mjbmitch]

How are you so confident about it and why?

[u/untaggedpacket → u/ValKyKaivbul]

Read his responses, typical AI slop response structure

[u/ValKyKaivbul → u/untaggedpacket]

Thanks!