It's 3am on a SOC floor, forty-some alerts deep in the queue, and one more comes in: a scheduled task creation on a workstation, kicked off by PowerShell with an encoded command block. On its own that's not unusual, this environment's patch management agent does the exact same thing most nights, same rough shape, PowerShell spinning up a scheduled task to run a deferred update script. The analyst has closed dozens of alerts that look like this one over the past few weeks. This one gets the same treatment: matches the known pattern, closed as expected admin activity, next alert in queue.
The problem is that "matches the known pattern" and "is the known-benign thing" aren't the same check, and the gap between them is exactly where this kind of miss lives. The legitimate patch task always launches from the same parent process, the patch agent's own service binary, and always points at a script sitting in the same fixed directory. The alert that got closed shared the general shape, PowerShell, encoded command, scheduled task, but its parent process wasn't the patch agent, and the script path wasn't in the usual directory. Neither of those two fields is something you'd notice from a glance at the alert summary. You'd only catch it by pulling the actual process lineage and comparing the specific field that makes the benign case benign, not the general silhouette that makes it look benign.
This is the shape alert fatigue actually takes on a busy floor, and it's worth naming precisely because it's easy to imagine the opposite: an analyst who's lazy, or not paying attention, or skipping steps out of carelessness. That's rarely what's happening. What's happening is a triage process that, under real volume, optimizes for "have I seen something like this before" instead of "does this specific instance verify against the thing that actually proves the pattern is benign." Pattern-matching on shape is fast and it's right most of the time, which is exactly what makes it dangerous the one time it isn't: it never feels different from all the times it was correct.
The fix isn't "look closer at everything," because that's not a real instruction under alert volume, it's a way to guarantee burnout without actually raising catch rate. The fix is knowing, for each alert type your environment generates in volume, what the one or two fields are that actually distinguish the benign version from an impersonation of it, and checking those specific fields as a standing habit rather than re-deriving them from memory at 3am under load. For a scheduled-task-via-PowerShell alert, that's parent process and script path. For a different alert type it's a different pair of fields entirely, but there's always a specific, checkable difference between "looks like the routine thing" and "is the routine thing," and finding it ahead of time, during calm hours, is what makes triage decisions defensible instead of a guess dressed up as pattern recognition.
That's the actual skill a SOC analyst is building across L1 to L3, not "watch more alerts" but "know which specific field kills the false-positive read for each alert type your environment throws, and check it every time regardless of how confident the shape looks." Codelivly's SOC Analyst Book Bundle works through that discipline across all three levels, from L1 triage logic through to the detection engineering that should be encoding these distinguishing fields into the rule itself so the next analyst isn't relying on memory at 3am either.
If you want to practice this exact judgment call before it costs you anything, the free Wazuh Alert Triage lab on codelivly.com puts you in front of real alert noise and asks you to make the same call.
Top comments (0)