A burst of failed logins at 09:12 does not prove an account was compromised. What happened next matters more: did a login succeed, from which address and device, and did that session do anything unusual? Incident analysis puts isolated alerts in time order and checks them against evidence. It also makes clear what remains unknown, so a plausible explanation does not harden into a supposed fact.
Analysis is different from containment and recovery, though the work overlaps. Blocking an account may be urgent; finding out whether its session reached sensitive data takes longer. If you are learning in a lab or supporting systems you are authorized to work on, define the scope, preserve relevant records, test explanations against more than one source, and document the limits of your findings.
Start with a decision, not a favorite theory
Before opening a log viewer, write down the decision your analysis must support. Should an endpoint remain isolated? Do credentials need rotating? Was a service outage caused by malicious activity or a failed deployment? A clear question keeps the investigation from wandering after an interesting but irrelevant clue.
Open a short case record: alert source, time received, affected assets, known business impact, authorized point of contact, and incident owner. Keep the alert’s original wording separate from your interpretation. “Identity provider reported 43 failed sign-ins followed by one success” is an observation. “An attacker guessed a password” is a hypothesis.
Set an initial boundary around the hosts, accounts, applications, and time window in scope. Expand it when evidence calls for it, and record why. On production systems, follow the organization’s response and escalation procedures. A serious-looking alert does not authorize you to change access controls, run intrusive tests, or inspect personal data on your own.
Triage what needs attention first
Severity and certainty are different. A low-confidence alert on a privileged account may need immediate verification; a confirmed event on an isolated test machine may have little operational impact. Ask:
- Is harmful activity still occurring, and is there a time-sensitive containment decision?
- Which accounts, systems, or data could be affected, and how important are they?
- Which evidence could disappear soon, such as short-retention logs or volatile system state?
- Who can preserve evidence, approve containment, and communicate updates?
If ongoing damage makes waiting impractical, containment can happen before the full story is known. Record the reason and exact time. Disabling an account or disconnecting a host changes what evidence will be available afterward.
Preserve evidence without changing the story
Original logs, alerts, and system records are more useful than screenshots of filtered results alone. Export or copy relevant records with approved tools, keep the originals where possible, and work from copies. For each collection, record who collected it, when, from which system, the time range covered, and any filters used. If your process supports it, record a cryptographic hash so you can check later copies for changes. A hash helps verify file integrity; it does not prove the source system recorded events accurately.
Keep access narrow. Logs may contain account names, IP addresses, message contents, or other sensitive information. Store them in an approved location, restrict permissions, and follow retention and privacy rules. Do not send raw records to a personal account or unapproved public analysis service. If formal forensic or legal handling may be needed, involve the appropriate team before collecting volatile data or altering a device; local procedures determine how custody is documented.
Note gaps as soon as you find them. A missing endpoint log could mean logging was disabled, the retention period expired, or collection failed. It is not proof that nothing happened. Preserve context too: deployment times, planned maintenance, and known monitoring outages are easy to forget later.
Build a timeline that respects clock errors
A timeline anchors the analysis, but clocks on different systems do not always agree. Record each source’s timezone and timestamp format, and whether its clock appears synchronized. Normalize working timestamps to a common reference such as UTC while keeping the original values. If a device clock is five minutes slow, note the uncertainty rather than silently shifting its entries.
Start with a small event table and add rows as evidence comes in:
| Time, UTC | Source | Observed event | Reliability or gap |
|---|---|---|---|
| 09:12 | Identity logs | Repeated failed sign-ins for one account | Centralized clock |
| 09:17 | Identity logs | Successful sign-in recorded | Client identity needs checking |
| 09:19 | Application audit log | Session accessed a report | Report contents not established |
That sequence is not a verdict. The successful sign-in could belong to the account owner; opening a report does not show it was downloaded or disclosed. Check whether the records point to the same session, user, device, and application. A correlation ID or session identifier is usually stronger evidence than close timestamps. An IP address alone might represent several users on a shared network.
Choose sources that answer specific questions
Each record type shows a different part of the event. Identity logs may show authentication attempts and session details. Endpoint records can show process starts, account changes, or security-tool alerts. Application audit logs can identify actions within a service. DNS and network records may show which services a system contacted, but a connection does not establish what data moved. Deployment records and help-desk tickets may explain an ordinary change that resembles an incident.
Do not collect everything just because it is available. Name the question each source can answer and its limits. “Can application logs tie report access to the authenticated session?” is more useful than “Check app logs.” A log that does not record downloads cannot rule one out. If an endpoint was offline, the absence of alerts tells you little.
Separate observations, hypotheses, and conclusions
Make uncertainty visible. An observation is directly recorded or independently verified; a hypothesis explains it; a conclusion has enough support to guide a decision. “The account signed in from a new device” counts as an observation only if the device identifier is reliable and earlier device history is available. A claim that the owner’s device was stolen would need separate confirmation.
For important findings, consider at least one competing explanation. A spike in failed logins could come from an outdated password stored in a service, a misconfigured application, or unauthorized attempts. Compare those possibilities with the attempt rate, source consistency, maintenance records, and the owner’s verified activity. Contact the owner through an established channel, not through details in a suspicious message or event.
A simple evidence matrix helps keep the reasoning honest:
- Claim: The successful login was unauthorized. Support: The account owner reports no activity at that time; the device is not in approved inventory. Limit: Device attribution is incomplete.
- Claim: Sensitive information left the environment. Support: None established. Limit: The available application log records report access but not transfer volume.
Base confidence on the quality of the evidence, not the number of alerts. Several alerts generated by one event are not independent confirmation. Say what would change your assessment, such as an audit record tying a file export to the session.
Determine scope and impact carefully
Scope asks where activity occurred and what else might be affected. Impact asks what changed or was exposed. A successful login may bring an application into scope without proving data loss. Conversely, an outage in one service can matter greatly if it interrupts a critical operation.
Follow recorded relationships outward: account to session, session to application actions, host to processes, and event to affected data or service. Note how strong each connection is. Check nearby accounts or systems only when the evidence and your authorization justify it. In a learning lab, that might mean comparing identity and application audit records for two test accounts. In an organization, broader queries may require the incident lead’s approval.
Describe impact concretely: “One user could not access the service for 20 minutes,” or “A report was opened by a session not yet attributed to its owner.” Do not say data was stolen when the records show only access. If missing logs prevent a firm assessment, say impact cannot be ruled out and identify the missing evidence.
Coordinate analysis with containment and recovery
Analysis should inform action, not hold up urgent protection. If an account appears to be actively misused, the incident lead may revoke sessions or disable access while an analyst preserves available logs. Record who approved the action, when it happened, and what changed. Then compare activity before and after containment. Fewer alerts do not prove it worked if monitoring stopped too.
Recovery needs its own checks. Restoring access, applying a fix, or rebuilding a host does not show that the original cause is gone. Check the specific condition that allowed the event, verify that affected services behave as expected, and watch for recurrence over a defined period. Keep investigation findings separate from routine troubleshooting notes so an assumption made during a hurried fix does not become accepted fact.
Write a report another person can audit
A useful report lets another responder see both the finding and its basis without repeating every log search. Include a concise description, scope and time window, a timeline with source references, confirmed facts, unresolved questions, impact, actions taken, and next steps with owners. Mark estimates and confidence levels plainly. Leave unnecessary personal data out of the main report, and retain restricted evidence according to policy.
Turn detection and analysis gaps into specific improvements. “Improve logging” gives a team little to act on. “Retain application session IDs alongside report-access events for the approved retention period” identifies a missing connection. Afterward, test that new logs are readable, time-synchronized, and available to authorized responders before relying on them.
To practice, create two test-account events in an isolated, authorized lab: several failed sign-ins and one legitimate success. Compare the identity record with an application access log. Leave the success unattributed in your case note until a shared session identifier or other reliable evidence connects the records. That unresolved line is better than a confident story based only on matching timestamps.
