Anatomy of a SIEM Alert

From Raw Log to Alert

In Lesson 2.1, you learned about the 8 categories of log sources that feed a SIEM. But raw logs are just data — thousands of lines per minute, impossible for a human to read in real time. The SIEM's job is to transform that flood of data into alerts: structured, prioritized notifications that tell you something security-relevant happened.

Here's the transformation pipeline:

1. Raw log arrives from a source (e.g., sshd writes a line to auth.log)
2. Decoder parses the log format and extracts fields (source IP, username, program)
3. Rule engine evaluates the decoded fields against hundreds of detection rules
4. Match — if a rule's conditions are met, the SIEM generates an alert
5. Alert appears in the dashboard with severity, description, and all extracted fields

In Wazuh, this pipeline runs in real time. The moment a log event matches a rule, you see an alert. Understanding every part of that alert is the skill that separates fast analysts from slow ones.

Speed matters. A typical L1 analyst is expected to triage 50-100 alerts per shift. At 60 seconds per alert, that's about 1-2 hours of pure triage work per 8-hour shift. The rest is investigation, documentation, and escalation. If you can't read an alert in under 60 seconds, you'll fall behind.

The Anatomy of a Wazuh Alert

Every Wazuh alert contains the same core fields, regardless of whether it came from a Windows event, an SSH log, or a firewall drop. Learning these fields once means you can read any alert in any module of this course.

Click to enlarge

Field-by-Field Breakdown

Severity Levels: The 0-15 Scale

Wazuh uses a severity scale from 0 to 15. Unlike some SIEMs that use "Low / Medium / High / Critical" labels, Wazuh's numeric scale gives you finer granularity — and it drives how you prioritize your queue.

Click to enlarge

Level Ranges and What They Mean

How Severity Affects Your Workflow

In a real SOC, your alert queue is sorted by severity. Here's how an L1 analyst works through it:

1. Start with 13-15 — These should be rare (1-2 per week in most environments). If one fires, it's your top priority.
2. Then 10-12 — The bulk of your "real" investigation work. Every high-severity alert gets a decision: True Positive, False Positive, or Escalate to L2.
3. Batch-process 7-9 — Medium alerts often need context: is the file integrity change expected (deployment) or unexpected (compromise)? Check with the asset owner.
4. Scan 4-6 for patterns — A single level-5 alert is noise. Fifty level-5 alerts from the same IP in 10 minutes is a brute force campaign.
5. Ignore 0-3 — Unless you're specifically hunting or troubleshooting.

Understanding Rule Groups

Every Wazuh rule belongs to one or more groups — category labels that help you understand what type of event you're looking at without reading the full description. Groups are your fast-filter mechanism.

Common Rule Groups and What They Indicate

Using Groups for Fast Filtering

In the Wazuh Dashboard, you can filter by rule groups to focus on specific event categories:

• Starting your shift? Filter authentication_failed + level 10+ to see any brute force activity that happened overnight.
• Investigating a host? Filter by agent + syscheck to see all file changes on that system.
• Looking for lateral movement? Filter windows + authentication_success + logon type 3.
• Checking for active attacks? Filter attack to see all rule-matched attack indicators.

MITRE ATT&CK Mapping in Alerts

Many Wazuh rules include MITRE ATT&CK mappings — the rule.mitre field contains the technique ID, tactic, and technique name. This connects every alert directly to the ATT&CK framework you studied in Lesson 1.3 and Lab 1.2.

What the MITRE Fields Tell You

Why This Matters for Investigation

When you see a MITRE mapping on an alert, it immediately answers: "What is the attacker trying to achieve?"

• T1110 — Credential Access — Brute Force → The attacker is trying to guess passwords. Check: how many attempts? Did any succeed? What account was targeted?
• T1543.003 — Persistence — Windows Service → The attacker may have installed a backdoor service. Check: what's the service name? What executable does it run? Is it in a suspicious path?
• T1070.001 — Defense Evasion — Clear Windows Event Logs → The attacker is destroying evidence. This is almost always malicious. Check: who cleared the logs? What was the account?

Not all rules have MITRE mappings — informational events (agent started, log rotation) typically don't. But most security-relevant rules at level 5+ do.

Source Data: Where the Investigation Starts

The data.* fields contain the extracted, structured data from the original log event. These fields vary by log source, but they're where you find the answers to your investigation questions.

Source Data by Log Type

SSH / Linux Auth Events:

Windows Security Events:

File Integrity Monitoring:

Web / Access Logs:

The Raw Log: Your Ground Truth

The full_log field contains the complete, unmodified original log line exactly as it was written by the source. This is your ground truth — the one field that can't be wrong because it's what actually happened, before any parsing or interpretation.

When to Read the Raw Log

• Verifying the alert — Does the raw log actually say what the rule description claims? Occasionally, a decoder might misparse a field and the rule fires on incorrect data.
• Finding details not in source data — The decoder might not extract every field. Command-line arguments, user-agent strings, or specific error messages might only be visible in the raw log.
• Investigating anomalies — If an alert looks unusual, the raw log often contains context that the parsed fields don't capture.

Raw Log Examples by Source

SSH Brute Force (Linux):

Feb 15 06:25:01 linux-web-01 sshd[5150]: Failed password for root from 185.220.101.42 port 45030 ssh2

Windows Failed Logon (4625):

An account failed to log on. Logon Type: 3 Account For Which Logon Failed: Account Name: Administrator Account Domain: CYBERBLUE Failure Reason: Unknown user name or bad password. Source Network Address: 91.234.99.87

SQL Injection Attempt (Web):

203.0.113.50 - - [15/Feb/2026:07:26:33 +0000] "GET /api/users?id=1'+OR+'1'='1 HTTP/1.1" 400 0 "-" "sqlmap/1.7.2"

File Integrity Change:

File '/etc/passwd' checksum changed. Size changed from '2847' to '2903'. Old md5sum: 'd41d8cd98f00b204e9800998ecf8427e'. New md5sum: 'a7f3e5b2c1d98764f0e2b3a4c5d6e7f8'.

Compliance Metadata

Many Wazuh rules include compliance framework mappings — references to specific controls in PCI DSS, GDPR, HIPAA, and NIST 800-53. These appear in the alert as additional fields:

These fields don't change your investigation but they matter for two reasons:

1. Compliance reporting — Your SOC may need to demonstrate to auditors that specific events are detected and investigated. Compliance mappings prove it.
2. Alert prioritization in regulated industries — A healthcare SOC might escalate any alert with HIPAA mappings faster than others, regardless of severity.

The 60-Second Triage Workflow

Now that you understand every field, let's put it together into a repeatable workflow. This is the process you should follow for every alert, and it should take no more than 60 seconds for the initial classification.

Click to enlarge

Step 1: Severity (2 seconds)

Glance at rule.level. This instantly tells you how urgently you need to act:

• 0-6: Low priority — batch-process or skip
• 7-9: Medium — investigate within the hour
• 10-12: High — investigate now
• 13-15: Critical — drop everything

Step 2: Description + MITRE (5 seconds)

Read rule.description and check rule.mitre. Now you know what was detected and what phase of an attack it represents. This frames your entire investigation.

Step 3: Agent / Host (3 seconds)

Check agent.name and agent.ip. Which system is affected? A brute force on a development workstation is less urgent than the same attack on a domain controller.

Step 4: Source Data (15 seconds)

Extract the key fields from data.*:

• Who? Source IP, username
• What? Process name, service name, file path
• How? Logon type, HTTP method, protocol

Step 5: Raw Log (15 seconds)

Scan full_log for anything the parsed fields missed. Look for:

• Command-line arguments
• User-agent strings
• Specific error messages or status codes
• Anything that seems unusual

The Decision (20 seconds)

Based on what you've read, make one of three calls:

• Close as False Positive — Expected behavior, known maintenance, test activity
• Close as True Positive (handled) — Real but low-impact, no further action needed
• Escalate to L2 — Suspicious, needs deeper investigation, potential incident

Putting It All Together: Reading a Real Alert

Let's walk through a complete alert from your Lab 1.1 environment:

Alert: SSH Brute Force Confirmed

60-second triage decision: Level 10 + external IP + targeting root + outside business hours = True Positive. Check if the attacker eventually succeeded (look for a subsequent 4624/5501 from the same IP). If no successful login, close with note. If successful login found, escalate immediately — the system may be compromised.

Common Alert Patterns You'll See Repeatedly

After a few shifts in any SOC, you'll notice the same alert types appearing again and again. Recognizing these patterns speeds up your triage dramatically:

What's Next

You can now read any alert in your SIEM. In Lesson 2.3 — Dashboards & Visualizations, you'll learn how to build views that organize hundreds of alerts into visual patterns — spotting brute force campaigns, tracking alert trends over time, and building the SOC dashboard you'll use every shift.