REPRODUCIBLE EXERCISE · SYNTHETIC TEST DATA

Failed SSH logins. Then a success.

A transparent demonstration of how I reason through an alert. This uses an authored test fixture, not a captured client incident or proof of a real compromise.

Question

Does the successful root login after repeated failures warrant escalation?

Evidence

Host: lab-ubuntu-01. Rule 5763, level 10; the fixture tags password guessing (T1110.001).
14:03:17 and 14:03:18: failed root login from 185.220.101.34.
14:03:19: accepted root login from the same source in the fixture’s previous_output field.

The sample’s previous_output includes an event after the top-level alert timestamp. This is a synthetic correlation example, not a verified ordering guarantee for real Wazuh alerts.

Assessment

The engine scores this 75/100 and suggests true-positive, high severity. My next step would be to verify whether the successful login was authorised, inspect session activity and correlate surrounding events. The score is heuristic; it is not a probability or proof of compromise.

Alternative explanation

An authorised administrator could mistype a password and then log in successfully. A scheduled test could also explain the pattern. Confirm source ownership, change approvals, authentication method and commands executed before concluding that access was malicious.

Handover

Record the account, source, host, event timestamps, observed success and unresolved authorisation question. Escalate suspected unauthorised access through the response runbook, preserve logs, and request approved containment if warranted.

No IP reputation lookup or endpoint verification was performed for this demonstration.

Reproduce

Download the exact sample JSON below.
Open the triage tool and select “SSH brute force then success (Linux)”.
Keep enrichment off and select Analyse alert.
Review the score, reasons and generated ticket; challenge the conclusion using the alternative explanation above.

Download source JSON ↓Download generated ticket ↓Run this example ↗

Actual triage tool output for the synthetic SSH sample, showing indicators and reasoning — Actual tool output from the synthetic sample. Enrichment was off; this is not a captured client incident.

Raw alert

{
  "timestamp": "2026-09-12T14:03:18.412+0000",
  "rule": {
    "level": 10,
    "description": "sshd: brute force trying to get access to the system. Authentication failed.",
    "id": "5763",
    "mitre": {
      "id": [
        "T1110.001"
      ],
      "tactic": [
        "Credential Access"
      ],
      "technique": [
        "Password Guessing"
      ]
    },
    "frequency": 8,
    "groups": [
      "syslog",
      "sshd",
      "authentication_failures"
    ]
  },
  "agent": {
    "id": "003",
    "name": "lab-ubuntu-01",
    "ip": "10.0.20.15"
  },
  "manager": {
    "name": "wazuh-manager"
  },
  "decoder": {
    "name": "sshd"
  },
  "data": {
    "srcip": "185.220.101.34",
    "srcport": "51422",
    "srcuser": "root"
  },
  "full_log": "Sep 12 14:03:18 lab-ubuntu-01 sshd[21044]: Failed password for root from 185.220.101.34 port 51422 ssh2",
  "previous_output": "Sep 12 14:03:17 lab-ubuntu-01 sshd[21044]: Failed password for root from 185.220.101.34 port 51422 ssh2\nSep 12 14:03:19 lab-ubuntu-01 sshd[21051]: Accepted password for root from 185.220.101.34 port 51430 ssh2",
  "location": "/var/log/auth.log"
}