Host-Based Analysis · Topic 4 of 5
Interpreting Host, SIEM and Command Line Logs
Read Windows event logs, Linux authentication logs, SIEM and SOAR records and command line output to identify what happened on a host and spot attacks.
- 5 min
- Ask who, what, when, where and result of every log entry.
- Event ID 4625 is a failed logon, and 4624 is a successful logon.
- Event ID 1102 shows that the audit log was cleared.
What it is
Logs are timestamped records of events, and interpreting them means turning lines of text into a clear account of what happened.
Logs come from the operating system, from applications, from a SIEM that gathers them, from a SOAR platform that acts on them, and from commands that an analyst runs.
A good reader asks the same questions of every log. Who did it, what did they do, when, from where and did it succeed?
How it works
Learn the usual fields, then read the entries for the pattern that stands out.
The common questions
- Who: the account or process name
- What: the action or event type
- When: the timestamp, and its time zone
- Where: the host and the source address
- Result: success or failure
Windows event logs
Windows keeps logs such as Security, System and Application. Events are identified by an event ID, and 7045 is written to the System log while the others below are Security log events.
| Event ID | Meaning |
|---|---|
| 4624 | An account logged on successfully |
| 4625 | A logon failed |
| 4672 | Special privileges were assigned to a new logon |
| 4688 | A new process was created (needs process creation auditing enabled) |
| 4720 | A user account was created |
| 1102 | The audit log was cleared |
| 7045 | A service was installed on the system |
Many 4625 events for one account, followed by a 4624, suggest a password guessing attack that succeeded. A 4720 followed by use of the new account, or a 1102 after other activity, points to an intruder covering their tracks.
Linux logs
Linux authentication events are written to /var/log/auth.log on Debian based systems and /var/log/secure on Red Hat based ones. The system journal can be read with journalctl.
Oct 2 02:14:07 srv1 sshd[2210]: Failed password for root from 203.0.113.5 port 52814 ssh2
Oct 2 02:14:11 srv1 sshd[2212]: Failed password for root from 203.0.113.5 port 52816 ssh2
Oct 2 02:14:15 srv1 sshd[2214]: Accepted password for root from 203.0.113.5 port 52818 ssh2These lines show repeated failures for root from one address, then a success a few seconds later. That is the pattern of a brute force attack that worked. The source address and the account give you the next things to investigate.
Syslog severity
Many devices send syslog messages with a severity from 0 to 7. Lower numbers are more serious.
| Number | Name |
|---|---|
| 0 | Emergency |
| 1 | Alert |
| 2 | Critical |
| 3 | Error |
| 4 | Warning |
| 5 | Notice |
| 6 | Informational |
| 7 | Debug |
Application logs
Application logs record what the program saw. A web server log line holds the client address, time, request, response code and size.
A burst of 404 or 403 responses suggests scanning. A request with odd characters suggests an injection attempt.
SIEM and SOAR records
A SIEM normalises logs from many sources into a common format and correlates them. Its alert usually lists the rule that fired, the events behind it, the affected asset and a severity. Read the underlying events, since a rule can fire for harmless activity.
A SOAR platform records what its playbook did. Its case log shows the enrichment steps, such as a reputation check on an address, and the actions taken, such as isolating a host. It is the record of the response, so you read it to see what was done and what is left.
Command line output
Analysts also run commands on a host to confirm what the logs suggest. A process list, a connection list or a listing of startup entries can all back up a log entry. Compare what you see with what is expected for that host.
What to remember for the exam
Seven facts cover most questions on this topic.
- Ask who, what, when, where and result of every log entry.
- Event ID 4625 is a failed logon, and 4624 is a successful logon.
- Event ID 1102 shows that the audit log was cleared.
- Linux authentication logs are in
/var/log/auth.logor/var/log/secure. - Many failures followed by a success suggests a brute force attack that worked.
- Syslog severity 0 is the most serious and 7 is debug.
- A SIEM correlates events, and a SOAR platform records the automated response.
Read the time order. A string of failures then a success from the same address tells a clear story.
Common mistakes
These four errors appear often.
Trusting a SIEM alert without reading the events. The underlying entries show whether it is real.
Ignoring time zones. Logs from different systems may use different zones, so align them before comparing.
Confusing syslog numbers. A lower number means a more serious message.
Missing the log clearing event. A cleared log is itself a sign of an intruder.
Event IDs can differ between Windows versions and settings, so check them against the product documentation when you are unsure.
Check yourself
Work through these three questions.
What does a run of failed SSH logins followed by an accepted login from the same address suggest?
It suggests a brute force attack that succeeded.
What does Windows event ID 1102 tell you?
It shows that the audit log was cleared, which can be a sign that an intruder is covering tracks.
Which syslog severity number is the most serious?
Severity 0, which is Emergency.
Topic 4 of 5 in Host-Based Analysis
Test yourself on Host-Based Analysis
The full Cisco CCNA 200-201 CBROPS question bank has 754 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Cisco. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.