AgentTesla FTP Exfiltration: A PCAP Walkthrough

The chain behind the capture: GuLoader, AgentTesla, FTP

Three names, three jobs. GuLoader is a downloader — a small, heavily obfuscated first stage whose only purpose is to fetch the real payload from a legitimate cloud host so it sails past reputation filters. AgentTesla is the payload: a long-lived .NET info-stealer that scrapes browser logins, mail clients, and keystrokes. FTP is how this build gets the stolen data out. The source write-up documents the lure that starts it all — a “SHIPPING DOC || INVOICE” email from shipping@paramee[.]com with a RAR attachment, inv. 5234353.rar, that unpacks the GuLoader stage.

The packet capture picks up at the hand-off, and that framing matters: the capture will not show you the email or the RAR. It shows you what the running malware does next. Two of those behaviors survive into the traffic, and both are loud — AgentTesla checks the victim’s public IP, then authenticates to an FTP server and uploads. Let us find them.

What is in the capture

Two hosts, one of them doing all the interesting work: 10.2.3.101, a Hewlett-Packard endpoint (MAC 00:08:02:1c:47:ae) sitting behind a Netgear gateway and resolver at 10.2.3.1. The trace runs 2.2 minutes and sends all of its external bytes to the United States. Short, clean, and — as the analysis makes clear — not benign.

PcapAI’s executive summary names the breach in a sentence: 10.2.3.101 sent login credentials in cleartext to 162.241.123.75, where anyone on the network path could read them — one reusable password exposed. The same incident holds the second finding, the scripted FTP upload that followed.

The executive summary: the cleartext FTP login on top, one reusable password exposed, and both techniques of the incident.

The shape of the attack

Before the individual findings, look at the timeline — it is the first thing that orients an investigation. PcapAI’s event log puts both findings on the 132-second clock, and the ordering is the entire story: the cleartext password (F01, T1040) at T+11.355 s, and the first upload (F02, T1048.003) 0.6 seconds later. Credentials exposed, then immediately used. The indicators above it list what went up: two files named after the victim’s user and machine, an AgentTesla password log and a Thunderbird contact list — names the report shows, never uses to decide.

The report’s indicators and event log: the uploaded files named after the victim, the exposed account, and the login and the upload 0.6 seconds apart.

The traffic volume matches that shape. It is spike-driven: a heavy first ten seconds — about 283 KB, the Google Drive payload pull — then a short secondary surge of roughly 5.8 KB of FTP between T+10s and T+40s, then near silence for the rest of the capture. Two bursts, two purposes. Here is the evidence for each.

Step 1 — the payload pull, and an IP check that gives it away

The first ten seconds are dominated by HTTPS to Google: drive.usercontent.google.com (142.251.186.132) and drive.google.com (142.250.115.138), both in Google’s AS15169, about 276 KB over TLS 1.2. On its own that is indistinguishable from someone syncing a folder — which is exactly why GuLoader stages the AgentTesla payload on Google Drive. A raw IP would draw attention; drive.google.com over TLS does not.

The tell is what sits next to it. There is a single, tiny HTTP request to ip-api.com (208.95.112.1) — just 865 bytes — to the path /line/?fields=hosting. A normal workstation does not ask a third-party API what its own public IP and hosting status are. Info-stealers do, routinely: it fingerprints the victim’s network and lets the malware skip analysis sandboxes and hosting ranges before it commits to exfiltration. Four DNS lookups cover the whole capture — drive.usercontent.google.com, ip-api.com, drive.google.com, and ftp.corwineagles.com — and that fourth name is the one that tells you where this is going.

Step 2 — cleartext FTP credentials on the wire (T1040)

The host opens an FTP control session to 162.241.123.75 — ftp.corwineagles.com, a US shared-hosting box on UNIFIEDLAYER-AS-1 (AS46606) — and sends its login in the clear. FTP carries its USER and PASS commands as plain ASCII, so the account [email protected] and its password are sitting in the packet bytes for anyone on-path to read. PcapAI lifts the credential straight out of the PASS command and flags it as a confirmed, live credential exposure — mapped to T1040 (Network Sniffing), because the very fact that the password is recoverable from the wire is the exposure.

Straight from the report: the FTP login [email protected], masked, accepted by the server — a reusable password exposed on the wire.

This is the worst kind of compromise to find after the fact: the credential is not merely stolen from the host, it is broadcast across the network on its way out. In Wireshark the same evidence is one filter away — ftp.request.command == "PASS" — and anyone passively sniffing the segment, the attacker included, now holds a working login.

Step 3 — data leaving over unencrypted FTP (T1048.003)

With the session authenticated, the malware issues STOR — the FTP upload command — 0.4 seconds after the login, without listing a directory first, and pushes two files from 10.2.3.101 up to the same server. That is the exfiltration, and PcapAI maps it to T1048.003, Exfiltration Over Alternative Protocol: Unencrypted FTP. The volume is tiny — 1.5 kB — so the report does not judge it by size: a STOR within seconds of the login, with no browsing, is a script, not a person. Interactive FTP clients list a directory first.

Nothing about the network gives it away: the FTP control and data connections carry no retransmissions, and the whole upload takes under a second. The hunt for it is the mirror of Step 2: ftp.request.command == "STOR".

The metric that would have fooled you

Here is where a naive glance goes wrong, and where correlation earns its keep. PcapAI’s summary page shows cleartext protocols carrying 1.6% of the captured bytes; TLS carries 97.5%. Taken as a headline, that says healthy network — nearly everything is encrypted. But the entire breach lives in that 1.6%. The 97.5% is the Google Drive payload pull; the 1% of FTP is the credential and the data leaving over it.

A volume-first triage — or a control that only alarms on large outbound transfers — waves this capture straight through. What makes the analysis right is that it does not score on bytes. It pulls the two plaintext findings out of the noise and correlates them: credentials exposed (T1040), then used to exfiltrate (T1048.003). The small flow is the dangerous one, and “mostly encrypted” is exactly the cover an FTP-exfil build like this is counting on.

The verdict

Stacked together: overall risk 80/100, Severe — a High-severity exposure (the cleartext login) and a Medium-severity threat (the scripted upload) on one host. The upload alone would be easy to dismiss at 1.5 kB; what makes it count is the company it keeps. And more useful than any single number is the incident PcapAI builds from the two findings: this is not two unrelated alerts, it is one kill chain — harvested credentials feeding an active upload.

The summary dashboard: risk 80/100, a High exposure and a Medium threat on 10.2.3.101, and the first actions for the exposed account on ftp.corwineagles.com.

The remediation writes itself, and the report spells it out: isolate 10.2.3.101 now; block egress to 162.241.123.75 and shut outbound FTP (TCP/21) at the perimeter; force a reset on [email protected] — and because that password crossed the wire in cleartext, treat it as compromised everywhere it is reused, not just on this host. Then image the endpoint for the GuLoader/AgentTesla dropper.

Indicators of compromise

From this public sample — treat infrastructure as historical, since it rotates quickly. The first group is on the wire in the capture; the second is campaign context from the source write-up.

Catch it in your own captures

You will not see corwineagles.com again — the infrastructure is already burned. The behaviors, though, generalize, and each is a one-line hunt:

• Cleartext FTP authentication. ftp.request.command == "USER" || ftp.request.command == "PASS" surfaces every plaintext login in the capture. On a modern network there should be almost none — each hit is a credential exposed and a host worth a look.
• FTP uploads to the outside. ftp.request.command == "STOR" with an external destination is an internal host pushing files off the network over a protocol no business app should be using for that in 2026.
• Public-IP lookups from an endpoint. Requests to ip-api.com, ipinfo.io, checkip.… and friends are normal for servers, suspicious for a workstation — stealers use them to fingerprint the victim before exfil.
• A small plaintext flow under a big encrypted one. Do not let “% encrypted” lull you. Sort by protocol, not by bytes; the dangerous traffic here was 2% of the capture.

Doing this by hand on every capture is the job. Doing it in under five minutes on every capture is the point of automating it — PcapAI runs these checks and 50+ others, maps each hit to its MITRE ATT&CK technique, recovers exposed credentials, and hands back a PDF you can attach to the ticket.