PCAP Analysis

Scenario

Analyze the network traffic.

Executive Summary

The capture holds two things worth separating. A plaintext chat on a non-standard TCP port ties the host that initiated it to a second internal peer, which is the sender and receiver pair the first question is after. Separately, the same sender posted a file to a PHP page on a web server on another subnet as a multipart form POST over unencrypted HTTP. The form, the server banner and the storage location were all readable in the stream, and the server’s reply confirmed where the file landed. The TCP conversation table gave the transfer time.

Artifacts

• Packet capture: Pcap_Analysis.pcapng → tshark for conversation stats and display filters, then follow the TCP stream to read the upload in full

Format note: Q1 wants SenderIPv4,ReceiverIPv4 with sender first. Q6 wants a value in *.**** form, so a duration in seconds to four decimal places.

Exfiltration

The IP conversation table shows several internal pairs, and the HTTP upload is the loudest, but the wording is about the communication between two parties rather than the upload. Port 250 stands out: it carries small packets with readable text. Decoding the TCP payloads on that port gives a chat between the user named P13 and one named Cu713. The host that opens the chat and speaks as P13 is the sender, and the other end is the receiver.

This answer was reasoned from that chat rather than read from a field that labels sender and receiver. The evidence pointing to it is the chat itself: the names in the messages map the speakers to their IPs.

tshark -r Pcap_Analysis.pcapng -Y 'tcp.port==250 && tcp.len>1' -T fields -e ip.src -e tcp.payload | xxd -r -p

Gotcha: The upload pair (192.168.235.137 to 192.168.1.7) is the natural reading but is not what the question wants. Order also matters: P13 is the sender, so the initiating host goes first.

From Q1, P13 is 192.168.235.137. Filter for HTTP requests from that host. There is a single POST /panel.php with a multipart body, and its destination is the web server.

tshark -r Pcap_Analysis.pcapng -Y http.request -T fields -e ip.src -e ip.dst -e http.request.method -e http.request.uri

Follow the TCP stream carrying the POST (stream 22). The multipart body has a Content-Disposition header with filename=, which gives the name the client sent the file under.

tshark -r Pcap_Analysis.pcapng -q -z follow,tcp,ascii,22

Tip: The value is the literal form filename, not the PHP page or the request URI. Read the Content-Disposition line in the body.

The server’s response in the same stream carries a Server: header with the full stack: the web server, its OpenSSL build and the PHP version, on a Windows build. The software name is the first token.

tshark -r Pcap_Analysis.pcapng -Y http.response -T fields -e http.server

The response body to the POST says where the file was stored: a short message giving a relative path. The directory is the first component of that path.

tshark -r Pcap_Analysis.pcapng -q -z follow,tcp,ascii,22

Use the TCP conversation table and find the connection from the uploader’s ephemeral port (40740) to port 80 on the server from Q2. Its Duration column is the transfer time. The *.**** format means four decimal places, so take the value as printed.

tshark -r Pcap_Analysis.pcapng -q -z conv,tcp

Tip: Pick the single conversation for the upload stream, not the whole-capture span at the bottom of the table.

Attack Summary

Phase	Action
Discovery	Plaintext chat on TCP/250 between 192.168.235.137 (P13) and 192.168.235.131 (Cu713)
Exfiltration	192.168.235.137 POSTs a multipart form to /panel.php on 192.168.1.7 over cleartext HTTP
Exfiltration	Apache accepts the upload and stores it under the uploads directory

IOCs

Type	Value
IP (sender, P13)	192.168.235.137
IP (chat peer, Cu713)	192.168.235.131
IP (web server)	192.168.1.7
Port (plaintext chat)	250/tcp
URL path	/panel.php
Upload path	uploads/file

MITRE ATT&CK

Technique	ID	Description
Exfiltration Over Alternative Protocol: Exfiltration Over Unencrypted Non-C2 Protocol	T1048.003	File sent to a web server as a cleartext HTTP multipart POST. Best-fit mapping, since the capture alone does not show intent

Defender Takeaways

Cleartext HTTP uploads expose the whole transaction. The filename, the server banner and the storage path were all readable in one stream. Require TLS for internal upload endpoints so anyone on the path cannot inspect or alter the transfer.

Unknown services on odd ports deserve a look. A readable chat ran on TCP/250 with nothing to identify it, and it was the key to who the parties were. Baseline which ports internal hosts talk on and alert on plaintext sessions on ports outside that list.

The Server header hands out the stack. The response disclosed the web server, OpenSSL and PHP versions, which is free reconnaissance. Trim it (ServerTokens Prod on Apache) so banners don’t map directly to known CVEs.

An upload form that echoes the storage path invites follow-up. The response told the client exactly which directory the file went to. Combined with a predictable uploads folder, that makes an uploaded script easy to find and request, so validate file types and keep upload directories non-executable.

Conclusion

A short HTTP POST carried the file, and the capture gave away the server, its software and where the file landed, while a plaintext chat on an odd port named the people involved. The lesson is visibility: cleartext traffic leaves the whole story readable to anyone watching the wire.