Origins

Scenario

You are provided with a minimal PCAP file. Your goal is to find evidence of brute force and data exfiltration.

Executive Summary

A single external host brute-forced the FTP service on a backup server, then logged in with the credentials it found. Once inside, it downloaded files with RETR, each over its own passive-mode data connection. Because FTP is clear text, the capture alone held the file contents. One was a maintenance notice that carried the password for a separate backup SSH server, which turns one compromised service into a second one. The other was an inventory of cloud storage buckets with an internal mailbox address, useful material for follow-on social engineering.

Artifacts

• Packet capture: the single PCAP → tshark for filtering and stream extraction, Wireshark to eyeball it

Timestamp note: Wireshark’s frame.time kept displaying the capture in the +1000 local offset even with UTC time formatting selected. Convert by hand before submitting a YYYY-MM-DD hh:mm:ss answer.

Reconnaissance

Start with a TCP conversation summary restricted to FTP. One external host is behind all the traffic to port 21 on the internal server 172.31.45.144, with a long run of short connections that point to guessing rather than a person typing.

tshark -r ftp.pcap -q -z conv,tcp

Look the Q1 address up in ipinfo.io. It resolves to AWS space in ap-south-1, and the city field gives the answer. Geolocation of cloud ranges is coarse, so treat the city as context and not as attribution.

The server announces itself in its 220 greeting at the start of every control connection, so the banner is the cheapest place to read the software and version.

tshark -r ftp.pcap -Y 'ftp.response.code == 220' -T fields -e ftp.response.arg

Credential Access

The brute force begins at the first USER command from the Q1 address. Pull it with its timestamp. Wireshark shows it as 14:12:54 with a +1000 offset, so subtract ten hours to get UTC.

tshark -r ftp.pcap -Y 'ftp.request.command == "USER"' -T fields -e frame.time -e ip.src -e ftp.request.arg

Gotcha: The displayed time stays in local time even with UTC formatting selected. Reporting 14:12:54 gives the right second on the wrong day-part.

Initial Access

Failed guesses end in 530. Filter for the single 230 Login successful reply, then read back to the USER and PASS commands on that same stream. The successful exchange sits in frames 399 to 409.

tshark -r ftp.pcap -Y 'ftp.response.code == 230 || ftp.request.command == "USER" || ftp.request.command == "PASS"' -T fields -e frame.number -e ftp.request.command -e ftp.request.arg -e ftp.response.code

Exfiltration

After the Q5 login, list the FTP commands on the control channel. The downloads are the retrieve command, seen in frames 462 and 492. The control channel only names the files. The content travels on separate data connections.

tshark -r ftp.pcap -Y 'ftp.request.command' -T fields -e frame.number -e ftp.request.command -e ftp.request.arg

Collection

Passive mode puts every transfer on its own port, announced in the 227 PASV reply. Read those replies to map ports to transfers, then dump the small data streams. The stream on port 9759 is a PDF, Maintenance-Notice.pdf. Carve it from the stream and run pdftotext; the notice contains the SSH backup server password.

tshark -r ftp.pcap -Y 'ftp.response.code == 227' -T fields -e frame.number -e ftp.response.arg

tshark -r ftp.pcap -q -z follow,tcp,raw,<stream-index>

pdftotext Maintenance-Notice.pdf -

Gotcha: The format hint is 15 characters. The asterisks around the password in the document are part of it, not PDF markup, and leaving them off is a wrong answer.

The second useful transfer is on port 23530: a plain text file, s3_buckets.txt. Follow that data stream and read it; the 2023 archive bucket is listed there.

tshark -r ftp.pcap -q -z follow,tcp,ascii,<stream-index>

The same s3_buckets.txt from Q8 also holds an internal mailbox address. The PCAP does not contain the phishing email itself, so the link between that address and the phishing is the question’s premise, not something the capture shows.

Tip: No new artifact needed. Re-read the Q8 stream in full before hunting elsewhere.

Attack Summary

IOCs

MITRE ATT&CK

Defender Takeaways

Don’t expose plain FTP to the internet. Credentials and file contents crossed the wire in clear text, so a capture alone gave up the password and every file. Use SFTP or FTPS with key or certificate authentication.

Alert on repeated FTP login failures. A burst of failed USER/PASS pairs from one source ahead of a 230 is an easy detection. Lock out or rate limit the source after a handful of failures.

Don’t store credentials in documents on file servers. A maintenance notice carrying the SSH password turned one FTP compromise into a second server. Keep secrets in a vault and rotate anything that sat in a readable file.

Don’t keep cloud asset inventories next to the data. The bucket list and an internal mailbox address gave the attacker targets and a believable sender identity for follow-on social engineering.

Normalise timestamps before reporting. Packet tools can display capture time in the analyst’s local offset, which here shifted the attack start by ten hours.

Conclusion

A guessable FTP password gave the attacker the backup server, and its files gave them a second server’s credentials and a map of the cloud storage. Everything crossed the network in clear text, so the capture holds the whole story.