Get answers out of a log file
Install a local AI assistant, point it at real security logs, and pull findings out of them in plain English — the core classroom-ready skill.
You've just come on shift covering web01. An overnight alert flagged unusual SSH activity, but the detail was thin — 'possible brute force', unconfirmed. Nobody has established whether anything actually happened. You have the raw logs and a local AI assistant. Before the morning stand-up you need to answer two things: is this a real incident, and if so, exactly what did the attacker do?
1 Guided walkthrough
First time in AnythingLLM? Do the one-time setup at the top of this page (install, pick a model, learn where the upload and prompt controls are). It takes about five minutes and every lab below assumes it.
Download and unzip the log pack (button at the bottom of this card). You get auth.log, access.log, a SOC alert queue, a host audit, and a support-ticket log.
Create a new workspace — call it "Log analysis" — and upload auth.log and access.log into it. Wait until AnythingLLM shows both files finished embedding.
You should see: Both files appear in the workspace with a green/ready state. If a file is still processing, give it a moment.
Start by having it teach you the format — useful if you have never read an auth log.
Paste this into the assistantExplain what the file auth.log records. What does one line represent, and what do "Failed password" and "Accepted password" mean?You should see: A plain-English description of SSH authentication events — failures, successes, usernames, and source IPs.
Now hunt. Ask it to quantify the failures by source.
Paste this into the assistantIn auth.log, list each source IP address with how many times it FAILED to log in and how many times it SUCCEEDED. Which IP looks like a brute-force attempt, and why?You should see: It flags 203.0.113.47 — many failures in a row, then a success.
This is the pivot that makes the case. Give it the analyst's context.
Paste this into the assistantThe user "deploy" normally logs in from 198.51.100.14. Did "deploy" ever log in SUCCESSFULLY from a different IP address? If so, which IP and at what time?You should see: It identifies the 08:52 successful login for "deploy" from 203.0.113.47 — the brute-force IP, not the normal one.
Cross-reference the second file to see the same attacker on the web side.
Paste this into the assistantNow consider access.log as well. Did the IP 203.0.113.47 also attack the website? List exactly what it tried and whether anything succeeded.You should see: SQL injection against /products, path traversal reading /etc/passwd and db.php, then a login and a bulk export of the customers and orders tables.
2 Work the incident yourself
No prompts given this time — you write them. Forming the right question is the skill. Work these on your own; compare with a neighbour if you can.
- Build a complete timeline of the incident — every significant event from the first suspicious attempt to the attacker's last action, with timestamps. Use the assistant to help, but YOU decide what belongs on the timeline.
- Establish the full scope: which account was compromised, what did the attacker do once inside (persistence, evidence tampering), and what data left the building?
- Tie the two logs together: connect the SSH compromise in auth.log to the web attacks in access.log. Same actor? State your evidence, not just your hunch.
- Write a three-sentence executive summary a non-technical manager could read and act on. No jargon, no IP addresses without context.
- Answer the hard one: what single alert or control, had it existed, would have caught this soonest? Defend your choice.
What to notice
- The assistant can read a log format a first-year student cannot yet parse — used as a tutor, that is a real teaching aid.
- The successful login came from the same IP that had been failing for ten minutes. That single correlation is the whole case.
- The assistant is only as good as your question. "Anything unusual?" is vague; "which IP succeeded after failing?" gets the answer.
- Everything ran locally on a laptop. This is a lab a student can repeat at home with no account and no cost.
Think about it
- Where did the assistant genuinely speed you up, and where did you have to correct or double-check it?
- It answered every question confidently and never said "I'm not sure". In a real SOC, what is the cost of a confident wrong answer?
- Would you let this assistant triage alerts unsupervised overnight? Where exactly is your line?
Take it further — for fast finishers
- Re-ask your key questions in a fresh chat. If the answers drift, what does that say about using an AI as your system of record?
- Ask the assistant to draft a detection rule (plain-English or Sigma-style) that would catch this pattern next time — then poke holes in it: how would an attacker evade it?