Hands-on project: investigate an incident from logs to report
Lesson 2 of 6
2Hands-on project: investigate an incident from logs to report
The big pictureAt 02:07 an alert arrives: "large data export from the app server to an external address". You are the analyst on shift. In the morning your manager will ask one question: what happened, and did customer data leak? All you have are the logs.
What the picture shows: An analyst's route through any incident: confirm the alert is real, gather the evidence into a timeline, name what happened, then contain and document. Each step builds on the one before.
Map of this part
The concepts in order, click any one to jump to it:
Two ways into the same idea
Imagine you are a detective at a museum theft. You have three witnesses who do not know each other: the door camera (the sign-in log), the visitors' book (the web server log) and the outer gate guard (the firewall). Each saw a piece. Your job is to order what they saw by the clock, and the story appears: who came in, from where, what they took, and when they left. Then you write a report the museum director understands without jargon, saying what must be fixed so it does not happen again.
The method: (1) triage: make sure the alert is not a false alarm (is the external address known? is it a scheduled backup?). (2) timeline: normalise the time zone (UTC), gather events from the sources and join them on shared keys (IP, account, host). (3) ATT&CK: name each step as a tactic and technique (such as T1110 Brute Force, T1078 Valid Accounts, T1041 Exfiltration Over C2 Channel). (4) scope: which machines, accounts and data were touched, plus the IOCs to hunt for in the rest of the environment. (5) containment while keeping evidence. (6) the report in line with NIST SP 800-61r3: an executive summary, timeline, impact, actions, and recommendations with an owner and a date. Practise on realistically built incidents on CyberDefenders and in the TryHackMe SOC Level 1 path.
Before You Start
🚨Detection and incident response
You know the SIEM and the response cycle.
🐧Linux and the command line for defenders
You read auth.log and build a pipeline.
🎯How attackers think
You know the ATT&CK tactics.
The Core Idea
1Triage: is the alert real?
An analyst's first minutes are not for deep investigation but for one question: is this real and how bad is it? Check the context: is the external address a known backup provider? Is there a scheduled change tonight? Does this account normally work at this hour? If you find no innocent explanation, classify it as an incident and start the timeline.
| Triage question | Where to find the answer | In our case |
|---|---|---|
| Is the destination known? | The supplier list and threat intelligence | 203.0.113.50 unknown |
| Is there a scheduled change? | The change management system | None |
| Is the behaviour normal for the account? | Historical sign-in log | svc-report never signs in interactively |
| Verdict | Incident, high priority |
2A timeline from three sources
Each source writes in its own format and clock. The decisive step is to normalise time and merge the events into one ordered list, then look for the shared key that joins them: here the attacker's address and the account name. Run the script: it is what SIEM tools do behind the scenes.
Three different time formats became one line. The story: guessing, then a sign-in on a service account, then an export of the customers table, then 48.6 MB leaving for an external address.
from datetime import datetime, timezone
# three sources, three formats (all fictional, documentation IP ranges)
auth = [("2026-11-02T01:52:10Z", "web01", "Failed password for svc-report from 198.51.100.77"),
("2026-11-02T01:52:41Z", "web01", "Failed password for svc-report from 198.51.100.77"),
("2026-11-02T01:53:05Z", "web01", "Accepted password for svc-report from 198.51.100.77")]
web = [("02/Nov/2026:01:58:30 +0000", "198.51.100.77", "GET /admin/export?table=customers 200 48213992")]
firewall = [(1793585220, "10.0.2.15", "203.0.113.50", 443, "ALLOW", "48.6 MB")]
events = []
for ts, host, msg in auth:
events.append((datetime.fromisoformat(ts.replace("Z", "+00:00")), "auth", msg))
for ts, ip, req in web:
events.append((datetime.strptime(ts, "%d/%b/%Y:%H:%M:%S %z"), "web", f"{ip} {req}"))
for epoch, src, dst, port, action, size in firewall:
when = datetime.fromtimestamp(epoch, tz=timezone.utc)
events.append((when, "firewall", f"{src} -> {dst}:{port} {action} {size}"))
for when, source, what in sorted(events):
print(f"{when:%H:%M:%S} UTC {source:<8} {what}")3Name each step in ATT&CK terms
Mapping the steps to ATT&CK is not decoration: it makes your report readable to any team in the world and exposes the gaps in your defence: every technique that worked means a control that was missing or failed.
| Time (UTC) | What happened | Tactic | Technique | The missing control |
|---|---|---|---|---|
| 01:52 | Password attempts on svc-report | Credential Access | T1110 Brute Force | Lockout and alerting |
| 01:53 | Successful sign-in on the service account | Initial Access | T1078 Valid Accounts | MFA, and no interactive sign-in for service accounts |
| 01:58 | Export of the customers table from the admin panel | Collection | T1213 Data from Information Repositories | Admin panel exposed to the internet |
| 02:07 | 48.6 MB to an external address over 443 | Exfiltration | T1041 Exfiltration Over C2 Channel | The volume alert worked but nothing blocked it |
4Containment and the report
Containment here: disable svc-report and rotate its secret, block 198.51.100.77 and 203.0.113.50, and preserve a copy of the logs and the server before changing anything, then hunt for the indicators on the other servers. Then write the report: one page that opens with what the manager needs, then the details for engineers.
Note: no jargon in the summary, every recommendation has an owner and a date, and "customer data should be treated as leaked" is said plainly because the legal decision rests on it.
INCIDENT REPORT IR-2026-031 Severity: HIGH Status: Contained Analyst: <your name> Opened: 2026-11-02 02:07 UTC 1. Summary (for management) A service account with a weak password was guessed from the internet and used to export the customers table (about 48 MB) to an unknown external server. Customer data should be treated as leaked. The account and addresses are blocked. 2. Timeline (UTC) 01:52 password guessing on svc-report from 198.51.100.77 T1110 01:53 successful sign-in on svc-report T1078 01:58 GET /admin/export?table=customers (48 MB) T1213 02:07 48.6 MB sent to 203.0.113.50:443, alert fired T1041 3. Scope and indicators Host web01, account svc-report, table customers. IOCs: 198.51.100.77, 203.0.113.50. No matches found on other hosts so far. 4. Actions taken Account disabled and secret rotated; both IPs blocked; logs and disk image preserved. 5. Recommendations Owner Due No interactive sign-in for service accts IT ops 2026-11-09 Admin panel behind VPN with MFA App team 2026-11-16 Auto-block on large outbound transfers SOC 2026-11-30 Legal and privacy review of the leak Legal/DPO 2026-11-04
Worked example
The task: in another incident the alert is "successful sign-in from an unusual country" on a sales employee's account. Right after it, the log shows a new mailbox rule forwarding every message containing "invoice" to an external address. What do you do, and what do you call the steps?
The answer: triage: is the employee travelling? Ask their manager. If not, it is an incident. ATT&CK: sign-in with a stolen valid account (T1078), then an email forwarding rule (T1114.003) setting up invoice fraud (BEC). Containment: revoke all the account's sessions, reset the password and enforce phishing-resistant MFA, delete the rule after capturing it as evidence, and look for the same rule in other mailboxes. Report: warn finance at once to verify by phone any recent request to change bank details, because that is the real damage likely to follow.
Myth vs Reality
| Myth | Reality |
|---|---|
| Investigating means naming the hacker. | The goal is knowing what happened, its scope, and stopping it; attribution to a named group is rare and needs far more evidence. |
| A good report is long and full of jargon. | A good report opens with a summary a manager gets in a minute, with the details for engineers after it. |
| Rebuild the server at once to end the problem. | Preserve the evidence first, or you will not know how the attacker got in and they will return the same way. |
Where you meet it at work
🚨SOC analyst
Writes triage notes and a timeline for every incident they escalate.
💼Your portfolio
One well-written incident report convinces an interviewer more than ten certificates.
⚖️Compliance
The dated report is what regulators ask for after any leak.
Test your understanding
What is an analyst's first goal when an alert arrives?
Triage first; deep investigation only for real incidents.
Why convert every log to UTC before building the timeline?
A three-hour gap can make the effect appear before the cause.
A successful sign-in on a real account whose password was stolen. Which ATT&CK technique?
Using a valid account to get in is T1078.
What key joins the sign-in log to the web server log in our case?
The same address appears in the sign-in and in the export request.
What must every recommendation in the report have?
Without an owner and a date a recommendation is a wish, not a plan.
Why preserve evidence before deleting the malicious mailbox rule?
The evidence defines the scope and prevents a repeat.
Quick review cards
Check Your Understanding
What do you write in the management summary if you are not yet sure data leaked?
What you know and do not know, plainly: "48 MB left for an unknown address; we are checking the content and treating it as a leak until shown otherwise", with the time of the next update.
Why is a service account signing in interactively a red flag?
Service accounts are used by programs, not people; an interactive sign-in usually means someone stole its secret.
Where can you practise on similar incidents legally?
CyberDefenders and its Blue Team challenges, the TryHackMe SOC Level 1 path, and public Wireshark sample captures. All are environments built for training.
Resources for this lesson
Grouped by type. Start with the official docs for precision, or an article or video for the explanation.
course1
Done with this lesson?
Sign in to save your progress.