Thread by @bettersafetynet

Blue team folks... we have to talk.

It's awesome that you're logging. That's the first step. Now here's the cool stuff to look for that the vendor didn't tell you about.
1

Pay careful attention to logs that stop coming in. If it's worth logging, it's worth monitoring when the logs stop flowing. (how long a gap you'll accept is up to you, but I rarely allow for over an hour)
2

Watch out for log sources where the time changes too much. (except for daylight savings changes)

Time drift is one of the most critical things to account for in log analysis. That's a given... but...
3

Did you know that sometimes attackers will change the date on a host 91 days (or more) in the past? That puts the logs directly into the archive. Thus, no alarms! It's a 'cheap' way for attackers to dodge a defensive control they don't yet have a bypass for.
4

Be on the lookout for "negative detects"

Story time! NDA is up on this so I can share
I once worked a case where a machine had 4624 type 3 (network login) to the file shares... but no 4624 type 2 (interactive login). Attacker somehow filtered the login events (badly I may add)
5

each morning, we saw this pattern for a few days... and realized something was off. Turns out it was a dank attack from a legit state backed group. No indicators were triggered. But there was this odd pattern. Find these oddities!
6

Most importantly though... attackers have a playbook... flip it against them! Know what commands they likely run, when was the last time a user of yours ran "whoami"? Hell, when was the last time a user knowingly ran cmd or powershell?
7

Default alerts and whatever are STARTING points. You can and should do so much more than what they offer.

Bottom line: It's a journey to do real defense... but your goal isn't to just get logging. It's to make it elegant. You can do it. LMK if you have questions. Lets go!
fin