Designing a SIEM path from Windows events to a CoPilot case

Monitoring my Windows endpoints is where Active Directory, the firewall and the SIEM meet. A single failed logon on a file server is just a line in a log. It becomes something I can work with once it has been collected, decoded, matched to a rule, raised as an alert and put in front of me as a case with its evidence attached.

SOCFortress CoPilot is the centre of this design: the one queue where alerts from Wazuh and Graylog become cases. The path follows the SOCFortress reference stack. My 8 November inventory lists no running Wazuh or CoPilot guest (a container named wazuh was stopped on 1 November), so the alerts below are worked examples; the commands are the real ones for each step. The SOC service catalog shows every service in the stack and what each one does.

Collection: getting events into Wazuh

On Windows, the Wazuh agent reads the event channels it is configured for, such as Security and System, and ships them to the Wazuh manager. PowerShell logging needs its own channel added. The firewall cannot run an agent, so Sophos sends its log over syslog to the manager instead. Both inputs are documented setups; the check I care about is that each source actually arrives.

Get-Service -Name WazuhSvc | Select-Object Status, StartType

Status  StartType
------  ---------
Running Automatic

Analysis: from event to alert

The manager decodes each event into fields (event ID, account, logon type, source workstation) and runs them through rules. A single 4625 is low severity; several from the same source in a short window match a rule for repeated failures and raise the level. The indexer stores the alerts, and the dashboard shows them. Those are four roles, and when something is missing it helps to know which one to blame.

Cases: from alert to CoPilot

CoPilot reads alerts from the Wazuh indexer through its connector and puts them in an alert queue. From there I group related alerts into a case, attach the evidence, and record what I decided. The case is the part that outlives the dashboard: it says what happened, what I looked at, and why I closed or escalated it.

The SOC-0142 case walks through that last step with a simulated cluster of failed logons, and the lab console has the alert queue it comes from.

One burst of failures, traced into two alerts

This is the comparison I wanted the design to make easy: the endpoint’s view and the SIEM’s view of the same thing. It uses the first exercise from the AD entry: 12 wrong passwords for one lab account, in two bursts.

The endpoint holds 12 events and the SIEM shows two alerts, and both are right. Three things only make sense side by side:

• The alert count is not the attempt count. Each alert means “the threshold was crossed”, not “six things happened”. A burst of 30 failures would still be a handful of alerts.
• The sub status lives on the endpoint. All 12 are 0xC000006A: a real account and a wrong password. That points at a person or a saved credential, not someone guessing usernames.
• The gap is the lead. Alert 1 fires at 08:15:04, and the next failure comes at 08:20:00. A retry on a fixed timer, such as a mapped drive with an old password, produces a gap like that every time; a person retyping does not.

For the same path driven from the attacking side, see the Kali Red and Blue walkthroughs: a bounded failed-logon test traced from event 4625 through Wazuh into a CoPilot case.

What I learned

Designing the hand-offs taught me to ask every alert two questions: which events made it, and which events it left out. The SIEM is good at telling me that a pattern happened. The endpoint is where I find out why.

Takeaway: when an alert fires, open the raw events behind it before deciding anything. Count them, read the sub status, and look at the spacing between them.

Further reading: Wazuh architecture · CoPilot project · CoPilot docs · Sophos syslog server setup