---
title: "How to Read Cybersecurity Logs for AP Cybersecurity"
description: "Learn to read auth, network, application, and nginx access logs for AP Cybersecurity, spot indicators of compromise, and cite log evidence on the FRQ."
canonical: "https://fiveable.me/ap-cybersecurity/device-security-analysis/cybersecurity-log-analysis-guide/study-guide/IWpYZi6GBGMUAEftFlk8"
type: "study-guide"
subject: "AP Cybersecurity"
unit: "Device Security Analysis"
lastUpdated: "2026-06-18"
---

# How to Read Cybersecurity Logs for AP Cybersecurity

## Summary

Learn to read auth, network, application, and nginx access logs for AP Cybersecurity, spot indicators of compromise, and cite log evidence on the FRQ.

## Guide

Reading logs is one of the most testable skills in [AP Cybersecurity](/ap-cybersecurity "fv-autolink"). This guide helps you analyze log evidence the way the exam expects: find the meaningful fields, spot [indicators of compromise](/ap-cybersecurity/unit-3/detecting-network-attacks/study-guide/5kYH3dgJpqFp57SUnjEX "fv-autolink") (IoCs), and turn raw lines into evidence-based explanations.

## Where Log Analysis Shows Up

Log reading lives in the detection skills, especially 3.D and 4.4.D, where you classify attacks by analyzing digital evidence. You also use it in 5.6.E when you analyze logs for [application attacks](/ap-cybersecurity/unit-5/application-and-data-vulnerabilities-and-attacks/study-guide/T25I7qaDw4w4XT1rkAYr "fv-autolink").

It is heavily tested in two places. On the multiple-choice section, you may get scenario items built on server access logs, [authentication logs](/ap-cybersecurity/unit-4/detecting-attacks-on-devices/study-guide/JpiXN2cti74uJERazuw3 "fv-autolink"), and ARP reply logs. On the free-response [Device Security Analysis](/ap-cybersecurity/device-security-analysis "fv-autolink"), you get multiple sources from one device, which can include system application logs (`/var/log/app/network_app.log`), authentication logs (`/var/log/auth.log`), and nginx access logs (`/var/log/nginx/access_log`).

The FRQ asks you to cite evidence from the sources and explain your reasoning. That means quoting a log line or field and connecting it to an attack, not just naming the attack.

## Log Types You Should Recognize

Different logs answer different questions. Knowing which log holds which evidence helps you decide where to look.

| Log type | What it records | What attacks it reveals |
|:--|:--|:--|
| Authentication logs (`/var/log/auth.log`) | Login attempts, success/failure, user, source IP | Brute force, password spraying, credential stuffing |
| Website login logs | App-level login attempts and outcomes | Account takeover, repeated failed logins |
| Network logs | Connections, protocols, traffic volume | Scanning, DoS floods, on-path activity |
| Application logs (`/var/log/app/network_app.log`) | Application events and errors | Injection attempts, abnormal requests |
| Access logs / nginx access logs (`/var/log/nginx/access_log`) | HTTP requests, URLs, status codes, client IP | SQL injection, path traversal, enumeration |

## The Fields That Carry the Evidence

Most logs are just rows of fields. Train yourself to scan for these eight, because they are where IoCs hide.

- **Timestamp:** When did it happen? Tight clustering of events in seconds is a flag.
- **User:** Which account? Watch for `root`, `admin`, or accounts that should not be [logging](/ap-cybersecurity/key-terms/logging "fv-autolink") in.
- **Source IP:** Where did it come from? A single external IP hitting many accounts is suspicious.
- **Destination:** What was targeted? A sensitive server or restricted path matters.
- **Status code:** Did it succeed or fail? In nginx logs, `200` is success, `401`/`403` are denied, `404` may signal probing, `500` may signal injection breaking the app.
- **Command:** In auth or application logs, which action ran? [Privilege escalation](/ap-cybersecurity/unit-2/cyber-foundations/study-guide/0oS8jJyX7iolYntwz5Eh "fv-autolink") commands stand out.
- **Event type:** Is this a `Failed password`, `Accepted password`, or error event?
- **Repeated pattern:** This is the big one. Many failures from one IP, then one success, is the classic brute-force-into-compromise [signature](/ap-cybersecurity/unit-4/protecting-devices/study-guide/n86HF5aR65a2DLQwNHDn "fv-autolink").

## A Practical Reading Workflow

Use the same routine every time so you do not miss evidence under time pressure.

1. Identify the log type and what it can prove.
2. Scan timestamps for bursts or unusual hours.
3. Group lines by source IP and by user.
4. Count failures versus successes per IP and per account.
5. Look for the failure-then-success transition.
6. Check status codes and requested paths for probing.
7. Write the IoC plus the matching attack name and your reasoning.

## Worked Mini-Example

Here is a trimmed [authentication log](/ap-cybersecurity/key-terms/authentication-log "fv-autolink"). Read it before you read the analysis below.

```
Feb 12 03:14:02 host sshd: Failed password for admin from 203.0.113.7 port 51002
Feb 12 03:14:03 host sshd: Failed password for admin from 203.0.113.7 port 51010
Feb 12 03:14:04 host sshd: Failed password for admin from 203.0.113.7 port 51019
Feb 12 03:14:05 host sshd: Failed password for admin from 203.0.113.7 port 51027
Feb 12 03:14:06 host sshd: Accepted password for admin from 203.0.113.7 port 51035
```

The fields tell a story. The same source IP `203.0.113.7` makes many `Failed password` attempts against `admin` within a few seconds, then one `Accepted password`.

That repeated-failure-then-success pattern is an IoC of a successful brute-force attack. A strong FRQ answer would cite the IP, the rapid failed attempts, and the final acceptance, then conclude the `admin` account was likely compromised.

Now compare with an nginx access log:

```
198.51.100.4 - - [12/Feb] "GET /products?id=5 HTTP/1.1" 200

198.51.100.4 - - [12/Feb] "GET /products?id=5' OR '1'='1 HTTP/1.1" 500

198.51.100.4 - - [12/Feb] "GET /products?id=5 UNION SELECT * HTTP/1.1" 500

```

The requested paths contain SQL fragments like `OR '1'='1` and `UNION SELECT`, and the server returns `500` errors. That points to a [SQL injection](/ap-cybersecurity/key-terms/sql-injection "fv-autolink") attempt, with the `500` codes suggesting the unexpected input reached the database and caused errors.

## Turning Logs Into FRQ Answers

The rubric rewards evidence plus reasoning, so do not just label the attack. Quote the specific field or line, name the attack, and explain why that evidence supports your conclusion.

A reliable answer template is: "In source X, [quoted evidence] shows [pattern], which indicates [attack type] because [reasoning]." Match the task verb too. If the prompt says Identify, point to the evidence; if it says Explain, give the reasoning that connects evidence to outcome.

When asked about [mitigations](/ap-cybersecurity/unit-1/leveraging-ai-in-cyber-defense/study-guide/uvMQfHoviL6tgFrEstZ8 "fv-autolink"), tie them back to the log evidence. Repeated failed logins justify an account-lockout policy; injection patterns in access logs justify [input validation](/ap-cybersecurity/key-terms/input-validation "fv-autolink") and sanitization.

## Common Mistakes to Avoid

These are the traps that cost the most points.

- **Naming an attack with no evidence.** Always cite the line or field. A correct label without proof is incomplete on the FRQ.
- **Ignoring the success line.** Many students stop at the failures. The single `Accepted` or `200` after failures is what proves compromise.
- **Misreading status codes.** Treat `200` as success and `401`/`403` as denied. Do not assume every logged request worked.
- **Skipping the source IP grouping.** Scattered events look random until you group by IP and see one attacker.
- **Confusing log types.** Do not look for HTTP status codes in `auth.log` or for SSH logins in an nginx access log.
- **Overlooking timestamps.** Bursts in seconds or logins at odd hours are evidence on their own.

## Quick Checklist

Before you finalize a log answer, confirm you have done all of this.

- Stated the log type and what it proves
- Quoted at least one specific field or line
- Grouped by source IP and user
- Identified the repeated pattern or the failure-then-success transition
- Named the matching attack
- Explained the reasoning, not just the label

Practice on the sample sources you will see, especially `/var/log/auth.log` and `/var/log/nginx/access_log`, and the FRQ log questions will feel routine.

## FAQs

### Which log files appear on the AP Cybersecurity exam?

Scenario questions can use server access logs, authentication logs, and ARP reply logs. The Device Security Analysis FRQ can supply system application logs (/var/log/app/network_app.log), authentication logs (/var/log/auth.log), and nginx access logs (/var/log/nginx/access_log).

### How do you spot a brute-force attack in an authentication log?

Group lines by source IP and user, then look for many Failed password events in a short window followed by an Accepted password. That repeated-failure-then-success pattern is an indicator of compromise pointing to a successful brute-force attack.

### What log fields should I focus on when analyzing evidence?

Focus on timestamp, user, source IP, destination, status code, command, event type, and repeated patterns. These fields hold most indicators of compromise, and grouping events by IP and account makes attacks visible.

### How do I cite log evidence correctly on the free-response question?

Quote the specific line or field, name the attack, and explain why that evidence supports your conclusion. Match the task verb: Identify points to evidence, while Explain requires reasoning that connects evidence to the outcome.

## Structured Data

```json
{"@context":"https://schema.org","@type":"FAQPage","inLanguage":"en","mainEntity":[{"@type":"Question","@id":"https://fiveable.me/ap-cybersecurity/device-security-analysis/cybersecurity-log-analysis-guide/study-guide/IWpYZi6GBGMUAEftFlk8#which-log-files-appear-on-the-ap-cybersecurity-exam","name":"Which log files appear on the AP Cybersecurity exam?","acceptedAnswer":{"@type":"Answer","text":"Scenario questions can use server access logs, authentication logs, and ARP reply logs. The Device Security Analysis FRQ can supply system application logs (/var/log/app/network_app.log), authentication logs (/var/log/auth.log), and nginx access logs (/var/log/nginx/access_log)."}},{"@type":"Question","@id":"https://fiveable.me/ap-cybersecurity/device-security-analysis/cybersecurity-log-analysis-guide/study-guide/IWpYZi6GBGMUAEftFlk8#how-do-you-spot-a-brute-force-attack-in-an-authentication-log","name":"How do you spot a brute-force attack in an authentication log?","acceptedAnswer":{"@type":"Answer","text":"Group lines by source IP and user, then look for many Failed password events in a short window followed by an Accepted password. That repeated-failure-then-success pattern is an indicator of compromise pointing to a successful brute-force attack."}},{"@type":"Question","@id":"https://fiveable.me/ap-cybersecurity/device-security-analysis/cybersecurity-log-analysis-guide/study-guide/IWpYZi6GBGMUAEftFlk8#what-log-fields-should-i-focus-on-when-analyzing-evidence","name":"What log fields should I focus on when analyzing evidence?","acceptedAnswer":{"@type":"Answer","text":"Focus on timestamp, user, source IP, destination, status code, command, event type, and repeated patterns. These fields hold most indicators of compromise, and grouping events by IP and account makes attacks visible."}},{"@type":"Question","@id":"https://fiveable.me/ap-cybersecurity/device-security-analysis/cybersecurity-log-analysis-guide/study-guide/IWpYZi6GBGMUAEftFlk8#how-do-i-cite-log-evidence-correctly-on-the-free-response-question","name":"How do I cite log evidence correctly on the free-response question?","acceptedAnswer":{"@type":"Answer","text":"Quote the specific line or field, name the attack, and explain why that evidence supports your conclusion. Match the task verb: Identify points to evidence, while Explain requires reasoning that connects evidence to the outcome."}}]}
```