aklaha

Thresholds alone are always either noisy or useless. What helps more is what happens next.

Failures followed by a success from the same source is the alert worth waking somebody for. Failures on their own are background radiation on anything internet facing.

If you want a number, 30 in a minute from one source catches automation without catching humans. Tune per service though, SSH on a public address and an internal app should not share a threshold.

Azure AD sign-ins first and it is not close. That is where account compromise shows up.

Exchange admin activity second, especially mailbox rule creation. Somebody who gets into a mailbox creates a rule to hide their tracks and it is a small, high signal event.

SharePoint and OneDrive file activity are enormous and only worth it if exfiltration is specifically your concern. Teams is noise unless you are regulated and have to keep it.

The interesting part is not that a model found it, it is that the cost of looking dropped by four orders of magnitude. That changes who is looking, not just how fast.

Filter the machine accounts, keep the rest.

Type 3 with an account name ending in $ is a computer account doing normal domain business. That is your volume and it is almost never interesting.

Type 3 from a user account is worth keeping. Lateral movement looks exactly like that.

So the filter is on the account name, not on the logon type.

Also worth separating the three things that all get called "the time": when it happened, when it arrived, and what the UI is showing you. Most confusion I have seen is somebody comparing the first on one source with the second on another.

4624, 4625, 4634 for logon activity
4720 / 4726 / 4738 account lifecycle
4728 / 4732 / 4756 group membership
4740 lockouts
4672 special privileges, your admin logon signal
1102 log cleared, this one should page somebody
4688 process creation if you can afford it, and turn on command line auditing or it is half useless

4688 is the expensive one and the most useful. Servers first, see what it costs, then decide about workstations.

syslog-ng if you are doing real parsing at the edge, the config language is much nicer for it. rsyslog if you are just shipping.

journald forwarding works but you are taking structured data, flattening it to a text line, and re-parsing it at the other end. Feels wrong every time I set it up.

Mostly setup time, and that I would have been the only person who understood it. Sysmon config is ugly but everyone on my team can already read it.

No dedicated SOC is the important part. That rules out anything whose value only appears if somebody watches it full time. You want something that emails you when it matters and shuts up otherwise.

By install count it is definitely OSSEC and Wazuh, it is just that nobody writes press releases about those. Open source wins on utilisation by a mile, it does not show up on the Gartner slide.