Network Forensics Investigation

Investigation summary

Investigation scope

Individual fourth-year forensic examination of three supplied packet captures from a fictional case, following the analysis and reporting stages of OSCAR.

My analysis

I preserved and hashed the evidence, separated incompatible interface captures, indexed traffic with Zeek, reconstructed files and application data, decoded embedded material, and documented the evidence chain.

Technical focus

• PCAP preprocessing
• Zeek correlation
• DOCX and XML analysis
• Base64 decoding
• File reconstruction
• Steganography and timeline reporting

Demonstrated result

I recovered and reported three distinct evidence sets while retaining their transformation history and uncertainty, including missing units and unresolved identity attribution.

Case overview

This was my fourth-year Advanced Digital Forensics investigation into three supplied packet captures from a fictional international trafficking case. I completed the work individually and followed the analysis and reporting stages of the OSCAR methodology. The practical objective was to recover relevant network evidence, preserve a repeatable path from the original captures to each conclusion, and report only what the evidence supported.

The captures were not ready for immediate processing. Each contained packets from two interfaces with different snapshot lengths, which caused Zeek to reject the files. I preserved the supplied PCAPs, calculated SHA-256 hashes, created working copies, separated the interfaces in Wireshark, and verified the derived captures before processing them independently. This became part of the evidential record rather than an undocumented repair step.

Zeek provided the main indexing layer. Its connection and file identifiers linked extracted objects back to the source and destination addresses, protocol, original filename, detected type, and network session. Wireshark remained the packet-level reference when the abstraction in a log file was not enough. Linux utilities, CyberChef, SilentEye, Firefox, and a Windows examination VM were then used only where the recovered evidence required them.

The three captures presented different analytical problems.

• Capture one was a relevance problem. A useful DOCX file sat among a large number of ordinary SMB and FTP transfers. After tracing the Zeek file identifier, I unpacked the document, inspected word/document.xml, found Base64 content inside the WordprocessingML, and decoded a list of eleven medicines with numerical amounts. The traffic did not establish the unit of measurement, so I did not invent one.
• Capture two was a relationship problem. Several ZIP archives contained image fragments that did not render individually. Their filenames formed a quotation supplied in the brief. Ordering and concatenating the fragments produced a valid JPEG, and evidence elsewhere in the capture identified SilentEye as the relevant steganography tool. Using that application on a Windows VM recovered another Base64 string, which decoded to a short message.
• Capture three was a presentation problem. The original chat service no longer existed, and the browser had polled for small pieces of the conversation over many HTTP responses. I correlated http.log and files.log, recovered the related response bodies, consolidated the HTML, and rendered it locally. The conversation described a meeting on 2 November at 22:00 and included coordinates that mapped to Death Valley. It also created uncertainty over who controlled one account, which I reported as uncertainty rather than identity attribution.

The main result was not simply three decoded artefacts. It was a documented chain showing how each result moved from source PCAP, to interface export, to Zeek record, to extracted object, to analyst-created output. The project developed practical experience in evidence preservation, PCAP preprocessing, network metadata correlation, file-format analysis, application-layer reconstruction, steganography, and reporting conclusions at the level the evidence could withstand.

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.

The scenario concerned communications between parties of interest, but the assignment was still a network-forensics exercise rather than an intelligence attribution exercise. I could report the data transferred, the endpoints involved, the sequence of recovered messages, and the transformations used to make the evidence readable. I could not prove the physical identity of a person from an account name or assign meaning that was not present in the captured data.

The scope included:

• validating and preserving the three supplied PCAPs;
• resolving the mixed-interface capture problem;
• producing Zeek logs and extracted objects from derived working copies;
• tracing files through connection and file identifiers;
• reconstructing content carried through SMB, FTP, and HTTP;
• decoding Base64 only after identifying it in the evidence;
• analysing an application-level fragmented image and steganographic carrier;
• rebuilding a readable chat history without access to the original server;
• reporting evidential limits alongside the findings.

The captures were intentionally constructed university evidence. The account names, addresses, documents, and messages belonged to the exercise and are presented here only to explain the analysis.

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. I 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.

Evidence preservation and transformation

Hashing the source was only the first control. The investigation also needed a clear distinction between the original evidence and every artefact produced during analysis.

I treated the files in four groups:

Evidence class	Examples	Handling
Source evidence	The three supplied PCAPs	Preserved read-only and verified through SHA-256
Derived network evidence	Per-interface exports	Created from working copies and linked back to the source capture and interface
Tool output	Zeek logs and extracted objects	Retained under the capture and interface that produced them
Analyst-created artefacts	Unpacked DOCX, reconstructed JPEG, combined HTML, decoded text	Documented as transformations rather than original evidence

That distinction mattered most in captures two and three. suspect.jpg did not exist as one transferred object. I created it by ordering and concatenating several recovered fragments. The combined chat file also did not exist on the wire as one page. It was an analyst-created presentation of separate response bodies. Both were useful evidence products, but neither replaced the objects or packets from which they were derived.

For each transformation I retained the reason for the step, the input artefact, the output artefact, and the identifier or filename needed to repeat it. A third party should be able to reproduce the result from the source evidence rather than rely on a screenshot of my final output.

I preserved all three source PCAPs, both per-interface exports for each capture, the corresponding Zeek logs, extracted objects, the unpacked WordprocessingML and the reconstructed suspect.jpg. Recalculating the source-PCAP hashes reproduced the SHA-256 values above, and the Capture 1 output links the recovered DOCX to Zeek file identifier Fo5O021bZuxL4ykzE1. Those artefacts make the transformation path repeatable from the original inputs to the reported results.

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 tools also served different levels of the investigation. Wireshark showed packets and capture structure. Zeek provided searchable metadata at scale. Archive and XML tools exposed the internal structure of recovered files. CyberChef made the decoding step visible and repeatable. SilentEye was introduced only after the evidence identified it. Firefox restored the presentation that had originally been supplied by the missing chat application.

I did not treat one tool as authoritative for every stage. Zeek could identify and extract an object, but the object still needed to be validated against its MIME type and examined manually. CyberChef could decode a string, but the result still needed to make sense in context. Firefox could render the reconstructed chat, but the individual HTTP responses remained the evidential source.

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.

The error was important because it affected the interpretation of the capture container, not just tool convenience. A packet’s snapshot length determines how much of the original frame was retained. Zeek expected the records in the processed file to share a consistent interface context. Splitting by frame.interface_id created working files with one interface and one snapshot-length definition.

I verified each output before continuing:

source capture
  -> inspect interface metadata
  -> filter frame.interface_id
  -> export displayed packets
  -> inspect derived capture
  -> confirm one interface
  -> calculate or retain derived-file hash
  -> run Zeek

This did not repair missing packet bytes or change the source capture. It changed the container used for analysis so that each interface could be processed consistently. The original remained available if a later question required comparison with the unsplit evidence.

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. I 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.

This was the working evidence model for the rest of the investigation. A filename alone was not enough. I wanted to know which host sent the object, which host received it, which protocol carried it, which connection it belonged to, and which transformation produced the readable result.

The model also prevented context loss when several files had similar names. Zeek’s extracted filename could be an internal identifier rather than the original network filename. The FUID and connection UID provided a stable way to join the object back to files.log, conn.log, http.log, or the packets themselves.

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.

The selection was based on the evidence chain, not only the recognisable filename. files.log showed the source and destination pair, the SMB origin, the detected Office Open XML type, and the FUID used in the extraction directory. That meant the unpacked files could still be attributed to one observed transfer.

DOCX was useful because it is not an opaque proprietary blob. It is a ZIP package containing XML, relationships, styles, media, and metadata. The human-visible body is normally stored in word/document.xml. Examining that file avoided depending on Microsoft Word and exposed text that could be hidden from ordinary document viewing.

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 I recorded the names and values without inventing one.

I treated the Base64 shape as an investigative lead rather than proof. Long strings with a restricted character set can indicate encoding, but the decoded result still has to be validated. In this case, the output produced structured and readable records that matched the scenario and could be repeated from the same XML text.

The finding was therefore:

SMB transfer observed
  -> Zeek FUID identifies track6.docx
  -> DOCX package unpacked
  -> word/document.xml examined
  -> Base64 text recovered
  -> eleven medicine records decoded

The traffic supported the existence and transfer of that data. It did not establish who authored it, whether the amounts were accurate, or which measurement unit was intended.

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.

The main difficulty in capture one was time and relevance. Zeek extracted many files correctly, but extraction did not decide which one mattered. A production investigation would need a repeatable triage process using file type, size, entropy, strings, protocol, endpoint, time window, and scenario-specific indicators. Automated flags could narrow the work, but a human still has to understand why an artefact is relevant and whether the surrounding traffic supports that conclusion.

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 were complete application-level transfers. The image itself had been split before transmission, so there was no missing IP reassembly step for Wireshark or Zeek to perform. Each fragment arrived as its own file object. The relationship only became visible after comparing the archive contents and the word-based filenames.

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 brief provided a useful ordering clue, but I did not rely on the clue alone. The resulting file also had to satisfy technical checks:

• the fragments had to concatenate without introducing text delimiters or altered bytes;
• the output had to have a coherent JPEG structure;
• file-type inspection had to recognise it as an image;
• an image viewer had to render it;
• the recovered carrier had to be accepted by the steganography application identified elsewhere in the evidence.

Each successful check reduced the chance that the ordering had produced a coincidental or corrupted result.

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 platform change was part of the documented method. SilentEye could not be installed successfully in the Ubuntu examination environment, while the recovered Windows build ran inside a separate Windows VM. Moving the artefact into that VM created another derived examination step, so the source image and its hash still needed to be retained.

This capture contained four separate concealment or representation layers:

network transfers
  -> ZIP archives
  -> application-level image fragments
  -> reconstructed JPEG carrier
  -> steganographic payload
  -> Base64 text
  -> decoded message

Calling all of these steps “encryption” would have been inaccurate. The files were split, hidden, and encoded, but the exercise did not establish cryptographic confidentiality.

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 repeated polling was central to the reconstruction. The application did not return one complete transcript. It returned small updates over time, and the browser assembled the experience for the user. Without the server, I had to reproduce enough of that relationship from the captured responses.

The correlation route was:

http.log request and connection UID
  -> files.log response-body FUID
  -> extracted HTML or text object
  -> order by request and capture time
  -> consolidate the related response bodies
  -> render locally

Concatenating every extracted HTTP file without correlation would have mixed unrelated content and application resources. The UIDs and repeated endpoint pattern defined the relevant set.

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.

The messages also contained an attribution problem. One account claimed awareness that scrutiny was focused on the person associated with the account, then said investigators would not know who was actually behind the shipment. That language was relevant to the scenario, but it was not proof of who used the account.

I separated the claims:

Claim	Evidence strength
The browser received the recovered text	Supported by the captured HTTP responses
The accounts used the names shown in the chat	Supported by the recovered application content
A meeting was discussed for the stated date, time, and coordinates	Supported by the message sequence
The coordinates map to Death Valley	Supported by independent geographic lookup
A particular real person controlled either account	Not established by the capture

That separation is essential in forensic reporting. Network evidence can attribute traffic to an endpoint and application identity while leaving the human operator unresolved.

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.

Cross-capture findings

The captures required different kinds of reasoning even though they were processed through the same initial workflow.

Capture	Main difficulty	Core method	Result	Evidential limit
One	Relevant content among benign transfers	FUID and connection correlation, DOCX/XML analysis, Base64 decoding	Eleven named medicines with numerical amounts	Unit and authorship not established
Two	One carrier split across separate transfers and concealed again	Archive review, inferred ordering, binary concatenation, SilentEye, Base64 decoding	Reconstructed boat image and hidden message	Creator and intent not independently established
Three	Conversation distributed across repeated HTTP responses	HTTP/file UID correlation, response recovery, HTML consolidation, browser rendering	Meeting date, time, coordinates, and identity ambiguity	Account names did not establish human identity

The same evidence model held across all three:

identify the relevant traffic
  -> retain the network identifiers
  -> recover the transferred object or response
  -> validate the file or representation
  -> transform only when necessary
  -> keep the result linked to its source
  -> state the conclusion and its limit together

The captures also showed that “network forensics” does not stop when a packet is decoded. The useful evidence was stored in Office XML, archive contents, image fragments, a steganographic carrier, encoded text, and application responses. Packet and flow analysis identified the material; file and application analysis made it understandable.

Reporting the evidence

I tied each conclusion to the source capture, interface, protocol, Zeek identifier, recovered artefact, and transformation used. I 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 each finding I would expect an evidence record to contain:

• source capture name and SHA-256;
• interface identifier and derived-PCAP filename;
• capture time or relevant packet range;
• source and destination addresses and ports;
• Zeek connection UID and file FUID where present;
• protocol and original network filename;
• extracted-object hash;
• transformation performed and tool used;
• output hash;
• observation, interpretation, and stated limitation.

That level of information is required to reproduce the result or defend it under review.

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.

Critical evaluation

The common technical workflow was successful, but each capture exposed a different weakness in a manual investigation.

Capture one: triage cost

Zeek made extraction straightforward. The difficult part was deciding which of the extracted files deserved deeper analysis. The brief directed attention towards transfer protocols, but there were still many unrelated objects. Manually opening every file does not scale and can also expose the examination environment to risky content.

A stronger process would create an evidence index automatically, then prioritise files using type, size, entropy, strings, origin, destination, timing, archive membership, and known indicators. The analyst would still make the decision, but the repetitive inventory work would be consistent and recorded.

Capture two: relationship and anti-forensics

No individual transfer contained the answer. The relevant evidence came from the relationship between several archives and their filenames. The scenario clue made the intended ordering discoverable, but a real investigation may not provide that hint.

I would improve this stage by grouping extracted objects by connection, time window, archive structure, filename pattern, and byte signatures. File-carving or similarity checks could identify fragments that appear to belong to one binary object. The reconstruction should then be validated by file structure rather than accepted because an image viewer happens to display something.

The steganography step also depended on finding a reference to SilentEye. That was preferable to trying many tools blindly, but the investigation should record how the tool was identified and which settings were used. Otherwise, the result is hard to reproduce.

Capture three: missing application context

The chat service was unavailable, so the capture held responses without the original database or server-side application state. Consolidating the HTML restored readability, but it did not reproduce everything the service may have known.

The derived chat page could also change sequence if the source objects were not ordered correctly. A stronger reconstruction would use packet timestamps, HTTP request order, connection UIDs, and the message timestamps inside the responses. It would produce both a human-readable transcript and a machine-readable timeline that retained the source FUID for every message.

Tool reliability

I initially described several tools as forensically sound because they were open source. Open source helps review, but it is not enough by itself. The process is defensible because the source evidence is preserved, tools and versions are documented, transformations are repeatable, outputs are hashed, and conclusions can be checked against packets.

I would also validate important results with a second method where practical. A Base64 decode can be repeated with a local command-line decoder. A JPEG reconstruction can be checked with file-format tools. A message timestamp can be compared with packet time. Independent confirmation reduces dependence on one application’s interpretation.

Automation opportunities

The investigation was manageable by hand, but the same process would become slow across large packet collections. The clearest improvement would be an evidence-indexing pipeline that runs after each per-interface capture is created.

It could:

• hash every source, derived capture, extracted object, and analyst output;
• record parent-child relationships between artefacts;
• join Zeek FUIDs to connection UIDs and protocol logs;
• retain source and destination addresses, timestamps, MIME type, and original filename;
• run safe file-type and string identification;
• identify archives and index their contents without executing them;
• flag Base64-shaped strings for review;
• group objects by connection, host pair, time window, filename pattern, or archive;
• build a transformation manifest as each result is created;
• generate an initial timeline for analyst validation.

A useful record might look like:

artefact_id: derived-0042
parent: SMB-Fo5O021bZuxL4ykzE1.docx
operation: unzip
output: word/document.xml
tool: unzip
source_capture: Capture 1.pcap
interface: 0
connection_uid: ...
file_uid: Fo5O021bZuxL4ykzE1
sha256: ...

The pipeline should not automatically decide that encoded or high-entropy content is malicious. It should make the evidence easier to navigate and preserve the steps the analyst performs.

Application to incident response and threat hunting

Although this was a fictional forensic case, the working method transfers directly into SOC and incident-response investigations.

Zeek identifiers provide a useful bridge between broad telemetry and packet evidence. A SOC alert may begin with a host pair, protocol, domain, or unusual file transfer. Zeek can narrow the related sessions and objects, while packet review confirms details that the log representation may omit. The same identifiers can then be carried into a case record alongside endpoint telemetry.

The three capture problems also map to common operational investigations:

• relevance: identify the small number of meaningful transfers among ordinary business traffic;
• relationship: recognise that several individually harmless objects combine into one outcome;
• presentation: reconstruct an application or user sequence from logs and partial responses after the original service is unavailable.

A threat-hunting workflow should therefore avoid treating each file or connection independently. Host, user, network session, file object, timestamp, and application action need to be correlated before the activity can be explained.

Project boundaries and limitations

Constructed evidence

The captures were designed for a university scenario. The concealment methods and clues were intended to be solvable within the assignment. They should not be presented as representative of the scale or ambiguity of a live international investigation.

Analysis and reporting phases

The work concentrated on the OSCAR analysis and reporting stages. I did not acquire the traffic, operate the original monitoring infrastructure, or manage a physical evidence seizure.

Missing original services

The chat server and wider infrastructure were unavailable. Capture three could only be reconstructed from observed network responses, not from the application’s database or server logs.

Incomplete attribution

The evidence linked traffic to IP addresses, sessions, filenames, and application account names. It did not prove the physical identity of the user behind an account.

Scenario-provided clues

The quotation in capture two materially assisted the ordering of the fragments. Without it, further structural and similarity analysis would have been required.

Manual triage

The investigation relied heavily on manual review of extracted files. That was practical for the supplied data but would not scale reliably without indexing and automation.

Tool and platform dependence

SilentEye required a Windows VM after the Ubuntu attempt failed. The examination therefore crossed platforms and depended on a historical application build. Tool versions and output hashes would need to be retained in a formal case.

Evidential claims

The decoded medicine data did not define units. The reconstructed image did not prove authorship. The chat content did not establish human identity or prove that the discussed meeting occurred. These limits are part of the findings.

Public presentation

The selected figures show the method and results without reproducing every case artefact or appendix.

What I developed through the project

The project developed practical experience in:

• preserving source evidence and calculating SHA-256 hashes;
• distinguishing source, derived, tool-generated, and analyst-created artefacts;
• reading PCAP metadata and interface configuration;
• resolving a mixed snapshot-length problem without altering the source;
• using Wireshark filters and exporting selected packets;
• processing captures with Zeek and interpreting its protocol logs;
• correlating connection UIDs and file FUIDs;
• tracing extracted files back to endpoints and sessions;
• unpacking DOCX files and reviewing WordprocessingML;
• identifying and decoding Base64 data;
• analysing application-level file fragmentation;
• reconstructing binary data from multiple transfers;
• using file structure to validate a recovered carrier;
• applying an identified steganography tool in an isolated VM;
• reconstructing a conversation from repeated HTTP responses;
• separating account identity, network identity, and human attribution;
• documenting transformation chains and evidential limits;
• identifying automation opportunities for production-scale analysis.

The main lesson was that extracting data is not the same as explaining it. Zeek could produce objects and logs, but the investigative work came from understanding how those objects related to one another and what could be supported from the traffic.

Capture one required relevance. Capture two required reconstruction across separate files. Capture three required rebuilding the presentation supplied by a missing application. All three required the same discipline: preserve the source, retain the identifiers, document every transformation, and stop the conclusion where the evidence stops.