Network Forensics Investigation

Investigation scope

This Advanced Digital Forensics assignment gave me three packet captures from a fictional investigation and asked me to recover and report the relevant network evidence. I completed the investigation individually and followed the analysis and reporting stages of the OSCAR methodology.

I preserved the supplied captures and calculated SHA-256 hashes before analysis. Working copies could then be transformed or split without losing the ability to verify the source evidence. The report recorded the filename and digest for each capture so another examiner could confirm they were using the same inputs.

Source evidence	SHA-256
Capture 1.pcap	e782a7086cc2b349fb32cf9a2acdf6645c225339752cd981ee0cc063e9c848cb
Capture 2.pcap	034042d655c57403ee44f59587d9b6c832b4cc89a660fe47fb4e69d3ae14e79f
Capture 3.pcap	dda90e8e47d0e85ed3e2ca0ce7bbc9712d36286e36b73525df22d464b1dc4ead

The preserved captures remained in a read-only backup. Every interface export, Zeek output, extracted object, unpacked document, reconstructed image, and combined HTML file was derived from a working copy. That separation allowed me to manipulate the evidence needed for analysis without presenting the derived files as untouched originals.

The volume was manageable compared with production network telemetry, but the same core problem was present: most traffic was routine, the original services were no longer available, and the relevant material was spread across different protocols and files.

Tooling and working method

Wireshark provided packet-level inspection, protocol filters, stream following, and timing. Zeek converted the captures into structured connection, DNS, HTTP, file, and authentication logs, which made broad activity easier to search before returning to specific packets.

I used an Ubuntu Desktop virtual machine in VMware Workstation 17 as the main examination environment. Command-line tools such as cut, tree, strings, archive utilities, and file-type inspection supported the reconstruction work. A Windows VM was introduced when the SilentEye build found in the evidence could not be installed successfully on Ubuntu.

CyberChef handled Base64 decoding, and SilentEye was used only after an extracted artefact indicated that the same steganography application had been involved in the scenario. Matching the tool to the evidence reduced the risk of trying arbitrary steganography settings until something readable appeared.

The main tool roles were distinct:

Tool	Use in the examination
Wireshark	Capture metadata, interface filtering, packets, streams, protocols, and timestamps
Zeek	Structured protocol logs, connection UIDs, file UIDs, MIME detection, and object extraction
Linux utilities	Archive inspection, XML review, file ordering, concatenation, and string extraction
CyberChef	Reproducible Base64 decoding
SilentEye	Extraction from the reconstructed carrier after the application was identified
Firefox	Rendering consolidated chat responses when the original web service was unavailable

Open-source tooling alone does not make an examination forensically sound. The evidential controls came from preserving the source, hashing it, documenting versions and transformations, retaining identifiers that connected outputs to packets, and making the path to each conclusion repeatable.

The captures contained traffic from two interfaces with different snapshot lengths. Zeek rejected the mixed capture because the packet records did not share one consistent capture length. In Wireshark I filtered on frame.interface_id, exported each interface into a separate working PCAP, and checked the capture information before processing the files independently.

This was an analysis workaround, not a change to the preserved evidence. The source captures and their SHA-256 values remained unchanged, while each exported file had a clear relationship to one interface in the original.

I repeated the same process for all three captures:

1. confirm the source hash
2. inspect capture metadata and interface identifiers
3. filter one frame.interface_id at a time
4. export only the displayed packets to a derived PCAP
5. confirm that the output contained one interface and a consistent snapshot length
6. process that working file with Zeek
7. preserve the resulting logs and extracted objects under the capture and interface context

Splitting by interface changes the container in which packets are analysed, but not the packet bytes exported for that interface. The report therefore recorded the split as a transformation rather than treating the exports as additional source evidence.

Zeek produced protocol-specific logs and extracted transferred objects. I used files.log to connect:

• the file unique identifier
• the connection UID
• source and destination addresses
• transfer protocol
• detected MIME type
• original filename
• extracted filename

Those identifiers provided the route back from an extracted object to the connection and packets that carried it.

The UIDs were especially useful because extracted filenames do not necessarily preserve the names seen on the wire. A Zeek file ID identifies the observed file object; the connection UID links it to the network session; source, destination, protocol, MIME type, and original filename then give the object its investigative context.

Capture one: narrowing file transfers

The first capture contained FTP, SMB, DNS, HTTP, and NTLM activity. Zeek extracted protocol metadata and transferred files, but the difficult part was separating relevant evidence from benign transfers.

The investigation brief pointed towards file-sharing protocols, so I prioritised FTP and SMB artefacts while retaining the wider traffic context. zeek-cut reduced files.log to the fields needed to compare the transfers. The records showed SMB communications between the scenario hosts 192.168.1.6 and 192.168.1.20, with several objects moving between them.

One object was track6.docx, identified by the Zeek file ID Fo5O021bZuxL4ykzE1. That identifier located the corresponding object in the extraction directory and linked it back to its source and destination, connection UID, SMB origin, detected MIME type, and original filename.

A DOCX file is a ZIP package containing XML, relationships, media, and formatting data. I unpacked the recovered document and inspected word/document.xml, where the text normally appears inside WordprocessingML <w:t> elements.

One text element contained Base64 rather than ordinary document content. Decoding it in CyberChef produced a list of eleven named medicines with associated amounts. The capture did not establish a unit of measurement, so the report recorded the names and values without inventing one.

Omeprazole, Metformin, and Hydrochlorothiazide were among the named medicines. Those examples were supported directly by the decoded text. The scenario described the material as part of a trafficking investigation, but the network evidence itself established only that the document contained those names and numerical amounts.

That sequence demonstrated the difference between extraction and analysis. Zeek could produce the files quickly; deciding which file answered the investigative question still required context, manual review, and a trace back to the traffic that carried it.

It also showed why every transferred object needed at least initial triage. Most of the extracted files were unrelated to the question. Restricting the first pass to FTP and SMB followed the brief, but it did not justify deleting or ignoring the DNS, HTTP, and NTLM logs. They remained part of the capture context and could have contradicted or extended the file-transfer interpretation.

Capture two: fragmentation and steganography

The second capture contained FTP, DNS, and HTTP activity, including several ZIP archives transferred as separate Zeek file objects. Extracting the archives produced image fragments that appeared corrupt when opened individually. Their filenames were words from a quotation supplied as a clue in the fictional brief.

Five Zeek file IDs were associated with the relevant transfers:

FMygeR3ueo0AjCQFFi
FBtaRZ28BILTAUggpk
F4wlRB2yYe3OA4HYrc
FoTfOE1ooiFGJTkSZ3
Fs56tI1MRK5enkQbNe

The archives held files whose individual names formed words from the Obi-Wan Kenobi quotation supplied in the brief: “I’ll never understand how you can simplify these battles into some kind of game.” I used that sentence to establish an ordering, concatenated the binary fragments in that order, and produced a valid JPEG named suspect.jpg. The reconstructed image depicted a boat.

The content had not been fragmented at the IP layer. The carrier file had been divided into pieces and each piece transferred as a separate application-level object, so normal stream reassembly would not recreate the image. The relationship had to be inferred from filenames, archive grouping, the scenario clue, and the fact that the ordered output formed a valid image.

References in the SMB material identified SilentEye. Using the same application on the reconstructed image revealed concealed Base64 data, which could then be decoded. The evidence chain therefore crossed several representations: packet traffic, extracted files, reassembled image, steganographic content, and decoded message.

The SilentEye version available in the evidence was used on the Windows examination VM after the Ubuntu installation attempt failed. It extracted a Base64 string from the JPEG. Decoding that string produced “May the force be with you.”

The matching Star Wars theme supported the selected ordering, but it was not the only validation. The concatenated output had to be recognised as a coherent JPEG, render as an image, be accepted by the identified steganography tool, and yield decodable content. Each successful stage constrained the preceding interpretation.

This capture required relationships between files to be considered rather than analysing each object independently. File IDs, filenames, archive contents, transfer order, the brief, and the reconstructed output all contributed to the result.

The exercise also separated three often-confused ideas:

• packet fragmentation is reconstructed by the network stack or analysis tool
• application-level file splitting creates several complete transfers that must be related externally
• steganography leaves the carrier readable while concealing another data layer inside it

Encoding was then a fourth layer. Base64 altered representation but did not provide confidentiality. Each layer required a different analytical step and a separate record of the resulting artefact.

Capture three: recovering a conversation

The final capture contained a much larger volume of HTTP activity from a web chat service. Zeek’s http.log showed repeated requests between the same client and server, with the browser polling a chat-log endpoint every few seconds.

The original application was not available, and each response held only part of the conversation. Following one request therefore did not recreate the exchange.

I used the HTTP and file UIDs to isolate the related response bodies, consolidated the relevant HTML, and opened the result in Firefox. Reconstructing the presentation layer exposed the sequence of messages rather than a directory of disconnected text files.

The extraction followed the relationship in both directions. http.log identified the repeated chat requests and connection UIDs. Cross-referencing those records with files.log located the response-body file IDs. Consolidating their HTML and rendering it restored enough of the application’s presentation to read the exchange in sequence.

Within the fictional case, the conversation between accounts named “Narco Polo” and “El Chapo” discussed a meeting on 2 November at 22:00 and included coordinates pointing to Death Valley, California. The language also raised doubt about whether the “El Chapo” account was being operated by the person initially suspected.

I recorded both the meeting information and the identity ambiguity. The capture supported the content received by the browser and the network endpoints involved; it did not prove the physical identity of the person using either account. Account name, network address, and human identity had to remain separate claims.

This was a practical example of network forensics meeting file and application analysis. The packets held the content, but the evidence became understandable only after enough of the web application’s polling and presentation behaviour had been reconstructed.

Without the original server, I could not request historical messages through the application’s normal interface or inspect its database. The recovered HTTP responses were therefore the available evidence. Combining them improved readability, but the combined file was a derived analyst artefact and not a replacement for the individual responses or source packets.

Reporting the evidence

The report tied each conclusion to the source capture, interface, protocol, Zeek identifier, recovered artefact, and transformation used. It also separated observations from interpretation. A decoded string or extracted image was recorded as evidence; its significance was explained against the supplied scenario rather than treated as self-evident.

For each transformed item, the chain was documented in order:

source PCAP -> interface export -> Zeek log record -> extracted file
            -> unpacking or reconstruction -> decoded result

That record allowed another examiner to repeat the same steps from the preserved capture rather than trusting only the final screenshot.

For the three main findings, the transformation chains were:

Capture 1 -> SMB file record -> Fo5O021bZuxL4ykzE1
          -> track6.docx -> word/document.xml -> Base64 decode

Capture 2 -> five FTP file records -> ZIP extraction
          -> ordered fragments -> suspect.jpg
          -> SilentEye extraction -> Base64 decode

Capture 3 -> HTTP connection UIDs -> response file UIDs
          -> recovered HTML bodies -> consolidated HTML -> browser rendering

I kept conclusions at the level supported by those chains. The decoded medicine list did not establish units. The reconstructed carrier did not independently identify its creator. The chat account names did not prove human identity. Those limits belong in the finding itself rather than in a detached disclaimer.

The investigation highlighted several analyst habits I now associate with SOC and incident-response work:

• preserve the source and hash it before transformation
• use structured network logs to narrow a large capture
• return to packets when log abstraction removes needed detail
• keep timestamps and protocol context attached to extracted files
• expect encoding, fragmentation, and steganography to create several analysis stages
• document enough of the process for another examiner to reproduce the conclusion

It also exposed clear automation opportunities. A small evidence-indexing tool could:

• hash every source and derived file
• associate each Zeek file ID with its connection UID and protocol
• retain original and extracted names
• run safe type and string identification
• flag long Base64-shaped text for review without automatically trusting it
• group objects by connection, host pair, time window, or archive
• write a transformation manifest as each result is created

I did not build that automation as part of this submission; the completed work was the forensic examination and report. Manual analysis was manageable for these teaching captures, but the same approach would become slow and inconsistent against production-scale packet collections.

The three captures were intentionally constructed university scenarios, but they exercised different forms of concealment and reconstruction: data hidden inside a document package, a file divided across several transfers and then used as a steganographic carrier, and a conversation spread across repeated web responses.

They also showed three different causes of analytical difficulty. Capture one was a relevance problem: the evidence sat among benign files. Capture two was a relationship problem: no single transfer contained the answer. Capture three was a presentation problem: the data existed, but the absent application had previously supplied its sequence and readable form. Treating all three as simply “search the PCAP” would have missed the work required after packet extraction.