Eleven Days of Silence in the SIEM

Do not disable it. Disabling removes the only current coverage for password spraying and brute force, and the queue problem is not caused by the rule existing - it is caused by the rule not knowing what normal looks like.

Tune in this order:

1. Baseline the known-good. Service accounts and the backup job have stable source/destination patterns. Encode that: exclude by account and source pair, not by account alone - a service account suddenly authenticating from a workstation is exactly what you want to see.
2. Raise the threshold for interactive accounts to a level that still catches spraying (many accounts, few attempts each) while ignoring user typos.
3. Keep every raw event. Suppress the alert, never the logging. Suppressed volume should be visible on a dashboard so the tuning does not become invisible.
4. Add a companion rule that fires on successful logon after a burst of failures from a new source - brushing aside the failures and then succeeding is the interesting event.
5. Review in 30 days. Rule suppression is a hypothesis; measure whether the noise actually dropped and whether anything real was missed.

The judgement: 'too many alerts' is a detection engineering problem, and the fix is precision, not silence.

Why the failed-logon rule was irrelevant: the attacker never failed to authenticate. They had valid credentials from phishing, so every logon was a success. A rule built on failure counts is structurally blind to valid-account abuse - this is why 'log in with stolen credentials' is one of the most common initial access techniques and one of the least detected.

Missing detections, stage by stage:

• Initial access: successful VPN/SSO logon from a country or ASN never seen for that user; impossible travel; first-seen device for the account. Identity logs, not endpoint logs.
• Execution: PowerShell with encoded commands, download cradles, or execution from a user-writable path - requires script block logging and EDR telemetry, which likely were not forwarded.
• Lateral movement: a workstation account authenticating to a file server it has never touched, or NTLM/SMB connections at unusual volume.
• Data staging: abnormal file access volume on the file server.

The concept to name: detection coverage by technique, not alert count. The SIEM was rich in one technique (guessing credentials) and empty in four others. The right response to an 11-day dwell time is a coverage map against a framework like MITRE ATT&CK, then building the missing rules - the noisy rule is a symptom of misallocated effort, not the cause of the breach.

Assess quickly, then act. Encoded PowerShell from an office productivity laptop, at night, is not consistent with normal business activity. Low alert severity is the rule's label, not a verdict on the host.

Do:

1. Contain the host with EDR network isolation. It is reversible, keeps the machine running, and stops lateral movement - the exact risk you are worried about. If your playbook requires approval, contact the on-call IR lead in parallel rather than waiting.
2. Preserve evidence: leave memory and disk intact, capture the process tree, command line, parent process, and the account context before doing anything else.
3. Pivot: check authentication logs for that user across VPN, SSO, and file shares; check for the same PowerShell pattern on other endpoints.
4. Document times, decisions, and evidence locations as you go, because the 02:00 memory will not survive to the morning.

Trade-offs: the finance manager cannot work until you release the host, and if this turns out to be an approved software deployment you have interrupted a business process. Both are recoverable. A ransomware detonation on a finance laptop is not.

Do not: power off or reboot (destroys volatile evidence), delete files or run cleanup tools, or message the user asking 'did you run this?' before containment - tipping off a compromised account is a real risk.