A security analyst receives a report that a finance employee’s account downloaded a large customer file at 02:17. The identity system shows a successful login, a firewall reports an outbound connection and an endpoint alert identifies an unfamiliar process. It is tempting to combine those observations into a definitive accusation. That would be a mistake: the clocks may not agree, the network address may be shared, the alert may describe a legitimate scheduled export and none of the three records necessarily proves that the employee personally initiated the download.
Digital forensics is the disciplined process of identifying, collecting, preserving, examining and reporting evidence relevant to a question. It supports incident response but is not identical to containment. An incident commander may need to isolate a compromised workstation before the complete story is known; the examiner must still preserve enough trustworthy evidence to explain what happened, what could not be established and which actions altered the system during response. This example is a hypothetical investigation, not an account of an investigation that was performed.
Define the claim before choosing the evidence sources
For the finance alert, write the claim as a question: “Did an unauthorized person use this account to download the customer file?” Several subquestions follow. Which identity was authenticated? From which device and client address? Which process made the request? Was the file read by the application, and did the connection transfer the alleged amount of data? Was the action approved by a scheduled business job? Each question needs evidence at the correct technical boundary.
An identity provider’s successful sign-in establishes an authentication event under its logging rules, not proof of which person held the keyboard. A firewall allow event proves a policy decision for observed traffic, not the content of an encrypted file or its business authorization. An application download record can identify a requested object but may lack process lineage on the originating endpoint. By listing these limitations before collecting data, analysts reduce the risk of treating the first plausible explanation as the only one.
The incident response lifecycle describes triage, containment, eradication and recovery. The forensics task here is narrower: preserve original observations and establish whether they support an account compromise, a sanctioned export or another event. Keep those purposes distinct so an urgent containment decision is not misreported as a completed forensic finding.
Preserve evidence before routine response work destroys it
Collection order depends on business urgency, legal authority and how quickly each data source disappears. Volatile system state, such as active network connections or memory-resident process data, may change when a workstation is restarted. Cloud sign-in and proxy records may have short retention periods or roll out of a query window. At the same time, continuing a malicious session could expose more customer data. The responder should follow an approved incident procedure, coordinate with authorized legal or investigative personnel when needed, and record why containment or collection was prioritized.
At a minimum, record the case ID, host or tenant identifiers, source-system owner, original time range, collecting analyst, collection method and file location. Export original log records with enough surrounding metadata to interpret them. Avoid taking only screenshots when authenticated exports or suitable forensic acquisition methods are available. Screenshots may assist a timeline but are rarely an adequate replacement for machine-readable event fields or a disk image acquired for a defined purpose.
When practical, store an untouched original in restricted evidence storage and analyze an authorized working copy. Record a cryptographic digest at acquisition and when copies are created, using an approved algorithm and repeatable procedure. A matching hash supports integrity of those bytes between checks; it does not prove that the sensor logged every relevant action, that the collection was lawful or that an analyst interpreted the event correctly. NIST SP 800-86 describes acquisition, integrity verification and documented handling as foundational activities. It is a technical reference, not legal advice or a substitute for an organization’s current investigation policy.
Build a timeline that accounts for clocks and missing records
Suppose the identity provider records a login at 02:14 UTC, the endpoint logs a process at 22:15 local time and the firewall exports a flow at 02:17. Before inferring sequence, record the source’s timezone, daylight-saving assumptions, timestamp precision, synchronization status and ingestion delay. The endpoint may be four hours behind UTC; a SIEM chart might display the time of collection rather than the event’s original timestamp. Preserve both original and normalized representations so another analyst can reproduce the ordering.
A timeline should separate observed facts from interpretations. An endpoint process start at one time and an outbound connection at the next do not prove the process opened that socket unless process/network telemetry or another correlation supports it. A NAT gateway may show one public address for dozens of workstations, and a reverse proxy may replace the apparent client address unless trusted forwarding fields and logs are configured. Track device IDs, session IDs, user identifiers, request IDs and destination names rather than relying on IP address alone.
The SIEM correlation discussion explains how multiple source records can support one hypothesis. Here the important discipline is to preserve disagreements. A login record without a matching endpoint event might indicate missing telemetry, a different device or a query error; it is not a license to invent the missing process. Mark the gap explicitly and identify which surviving source could help resolve it.
Use each data source for the question it can answer
Network flow records commonly summarize source and destination, ports, transport, observed bytes, action and session timing. They may show that the workstation exchanged a large volume of data with a cloud endpoint, but not which customer file was transferred. A packet capture taken at the correct point may expose detailed protocol timing and some payload for unencrypted traffic; HTTPS typically hides application content without authorized endpoint-side or other supported inspection. Capturing on one switch port does not rule out traffic on a different route.
Endpoint telemetry can tie a process to its parent, executable path, publisher, command line, file activity and outbound connection where supported and collected. A signed process is not automatically benign, and a generic executable name is not proof of malware. A file digest helps identify matching bytes but does not independently explain why the process executed or who authorized it. Preserve the original alert’s detection reasoning and distinguish that reasoning from separately verified system evidence.
Application logs may provide the decisive business context: authenticated account, request method, object identifier, authorization result, response status and returned byte count. A 403 for an attempted export means the application rejected that request under its rules; it does not mean the user’s identity was never authenticated. Conversely, a 200 response can be a successful application operation, but the requested object and amount still need to be checked. Correlate request IDs and service logs with endpoint and network signals wherever supported.
Analysts should minimize unnecessary sensitive material when collecting logs or captures. Personal information, credentials and proprietary payloads can appear in endpoint data or poorly protected protocols. Apply access controls, narrow capture filters, retention requirements and appropriate redaction for sharing. The Wireshark documentation describes packet-analysis capabilities; using a tool does not confer permission to monitor users or systems outside an approved investigation.
Keep a chain of custody that another reviewer can follow
For every evidence item, maintain a unique identifier, collector, source, acquisition date and timezone, acquisition tool/version where relevant, integrity digest, storage location, and a history of every transfer or authorized access. If an analyst extracts a filtered subset from a larger log, record the filter and retain the source export. If a workstation disk is imaged, record the imaging method and any exceptions. A supervisor or independent reviewer must be able to identify which artifact supports a reported conclusion without relying on private analyst memory.
Imagine a raw endpoint export with SHA-256 digest recorded at acquisition. A working copy is later converted into a normalized timeline. The timeline’s digest differs because the content and format changed; that does not mean the original has been tampered with. Preserve the raw item and record the transformation, input artifact and analysis script or settings. Do not claim that a matching digest proves evidence completeness or that the account holder was the actor. Integrity, relevance, provenance and attribution are different claims.
Where an incident may have disciplinary or legal consequences, requirements for preservation, disclosure, access and collection authority can be stricter than routine troubleshooting. Escalate to the responsible counsel or authorized investigator rather than treating an informal operations checklist as a chain-of-custody standard for every jurisdiction.
Test alternative explanations before writing the finding
Return to the finance alert. Hypothesis A is an authorized overnight report job. It predicts a change ticket, a signed or approved scheduled task, the expected service identity, a known destination and a dataset matching the business purpose. Hypothesis B is misuse of a real employee credential. It predicts a suspicious sign-in context, an unapproved endpoint or tool, unexpected object access and lack of a matching approved job. Hypothesis C is miscorrelation: the firewall’s connection belongs to another host behind shared NAT, or the endpoint alert and application download are unrelated.
Create a decision table that states what could support or disprove each explanation. A verified job schedule and matching process lineage support A but do not by themselves prove the exported file was appropriate. Successful authentication from an unfamiliar source supports investigation of B but may also reflect legitimate travel or network changes. If a reliable request ID ties the application export to the expected approved job and no contrary evidence remains, explain the confidence and the limits of that conclusion. If key logs were not retained, mark the attribution unresolved rather than fabricating certainty.
Include response actions in the case timeline separately from observations of suspected attacker activity. If the account was suspended at 02:23, later failed logins may be consequences of containment rather than additional hostile attempts. If an analyst reset the workstation, document which volatile evidence was lost. The final report should separate findings, remaining uncertainty, affected data, authorized response, recovery status and recommended follow-up controls.
Write a case report that can be challenged and reproduced
A concise evidence table should contain the claim, supporting artifact ID, source and time, relevant field or observation, alternative interpretation, evidence limitation and reviewer. The incident narrative can then cite those IDs instead of relying on screenshots or dramatic language. An explicit “not established” outcome is preferable to a confident but unsupported attribution. Store the final report under the organization’s approved evidence and confidentiality rules.
The SY0-701 exam objectives include investigation data sources and security operations, but the professional skill is broader than naming a log type. A dependable examiner knows when to preserve volatile state, which record supports each proposition, why clocks or encrypted traffic limit conclusions, and how to document custody without overstating a hash or a tool result. These are proposed exercises and methods—not claims that a live employee, payment system or workstation was investigated.