AgentTesla-Style Malware Traffic Analysis & Suricata Detection Engineering

Investigation Overview

Network traffic analysis is one of the most valuable techniques available to security analysts when investigating suspicious activity inside an environment.

Even when endpoint telemetry is unavailable, encrypted files have been deleted, or malware is no longer present on the compromised machine, network captures may still reveal communication patterns, remote infrastructure, protocols, authentication attempts, and potential data exfiltration.

This investigation analyzes a malicious network capture associated with an AgentTesla-style infection scenario. The objective is not simply to identify suspicious packets. Instead, the investigation follows the complete analytical process expected from a SOC or network forensics analyst.

Investigation Goals

Investigation Scope

Before analyzing network evidence, the scope of the investigation must be clearly defined. This prevents analysts from jumping directly into individual packets without understanding what questions the investigation is expected to answer.

For this case, the primary evidence source is a packet capture containing traffic generated during a suspected malware infection. The investigation therefore focuses on network-observable behavior.

Analysis Environment & Toolset

Malware-related packet captures should be analyzed inside a controlled laboratory environment. The investigation was structured around an isolated analyst workstation where the evidence could be inspected without interacting with production systems.

Core Analysis Tools

Analysis Philosophy

A packet capture should not be treated as a collection of isolated packets. It should be treated as a timeline of communication that can be reconstructed into attacker behavior.

With the investigation environment prepared and the analytical scope defined, the next stage is to establish the integrity of the evidence before performing deeper traffic analysis.

Evidence Acquisition & Integrity Verification

Before beginning the investigation, the packet capture was treated as the primary network evidence.

The sample analyzed in this investigation was:

2026-02-03-GuLoader-for-AgentTesla-style-infection-with-FTP-data-exfil.pcap

The original password-protected archive was first transferred into the dedicated project evidence directory before extraction and analysis.

Figure 1 — Evidence acquisition and project directory preparation.

After extraction, the PCAP was verified and basic capture metadata was reviewed to confirm that the evidence was readable and suitable for analysis.

Figure 2 — PCAP metadata and evidence verification.

SHA-256 Integrity Verification

A SHA-256 hash was calculated before performing the investigation. This created a reproducible integrity reference for the evidence used throughout the analysis.

sha256sum *.pcap | tee ../notes/pcap-sha256.txt

Figure 3 — SHA-256 integrity reference generated for the analyzed PCAP.

Establishing the Network Baseline

After verifying the integrity of the evidence, the next objective was to understand the packet capture at a high level before investigating individual connections.

Initial triage focused on three areas:

Protocol Hierarchy

TShark was used to inspect the protocol distribution within the packet capture.

tshark -r *.pcap -q -z io,phs

The capture contained 353 packets and was primarily composed of TCP traffic.

Figure 4 — Initial protocol hierarchy generated with TShark.

Identifying the Primary Host of Interest

IPv4 endpoints were enumerated to determine which internal and external systems were participating in the observed network activity.

tshark -r *.pcap -q -z endpoints,ip

The primary internal endpoint identified in the capture was:

Several external IP addresses were also observed:

The host 10.2.3.101 participated in the majority of the observed communications and was therefore selected as the primary system of interest.

TCP Conversation Analysis

TCP conversations were reviewed to determine which outbound connections from the internal host required deeper analysis.

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

Resolving the External Infrastructure

DNS traffic was analyzed to identify which domains were resolved by the internal system and determine whether those resolutions correlated with subsequent network connections.

tshark -r *.pcap \
-Y "dns.flags.response == 0" \
-T fields -e dns.qry.name \
| sort -u

Four domains were observed:

Figure 5 — DNS queries extracted from the packet capture.

The domain ftp.corvineagles.com was particularly important because the capture already contained an outbound FTP connection.

DNS Response Correlation

tshark -r *.pcap \
-Y 'dns.flags.response == 1' \
-T fields \
-e frame.time \
-e dns.qry.name \
-e dns.a

Figure 6 — DNS response analysis and IP correlation.

DNS response analysis confirmed:

Figure 7 — Correlation between DNS resolution and subsequent FTP infrastructure.

FTP Control Channel Investigation

With the DNS relationship established, the next stage was to inspect the FTP control session between the internal host and the external server.

FTP commands were extracted from the packet capture to reconstruct the control-channel activity.

tshark -r *.pcap \
-Y "ftp.request.command" \
-T fields \
-e frame.number \
-e ip.src \
-e ip.dst \
-e ftp.request.command \
-e ftp.request.arg

Figure 8 — FTP control-channel commands observed in the PCAP.

The control channel contained authentication activity followed by commands associated with passive-mode file transfer.

STOR Operations

Two outbound STOR operations were identified. The command is used by an FTP client to upload data to the remote server.

Reconstructing the FTP Data Transfers

An FTP STOR command demonstrates the intention to upload a file, but the control-channel command alone does not prove that meaningful data was successfully transferred.

The investigation therefore moved to the corresponding FTP-DATA sessions.

Figure 9 — Passive FTP data-transfer sessions correlated with the STOR operations.

Passive-Mode FTP Correlation

Additional high-numbered TCP connections between 10.2.3.101 and 162.241.123.75 were correlated with the passive FTP sessions initiated by the control channel.

Packet-Level Validation

The corresponding TCP streams were reconstructed to determine whether the transferred data contained meaningful information.

Figure 10 — Packet-level reconstruction of the FTP data-transfer activity.

Reconstruction demonstrated that the transfers contained meaningful host and user information rather than arbitrary test data.

Investigation Chain So Far

Suricata Detection & Alert Triage

After manually identifying suspicious FTP-based data transfers, the same packet capture was analyzed with Suricata.

The objective was not simply to determine whether Suricata generated an alert. The goal was to compare IDS telemetry with the independently reconstructed packet evidence and determine whether the resulting detections represented validated true positives.

Configuration Validation

Before processing the PCAP, the Suricata configuration and loaded rules were validated.

sudo suricata -T -c /etc/suricata/suricata.yaml

The configuration test completed successfully, confirming that Suricata was ready to process the network evidence.

Figure 11 — Suricata configuration and rule validation.

Offline PCAP Processing

sudo suricata \
-r pcap/2026-02-03-GuLoader-for-AgentTesla-style-infection-with-FTP-data-exfil.pcap \
-c /etc/suricata/suricata.yaml \
-l output/

Suricata generated multiple output artifacts, including:

Figure 12 — Offline PCAP processing and generated Suricata output.

Initial Alert Review

cat output/fast.log

Several malware-related detections were generated during the analysis.

Figure 13 — Malware-related alerts identified during initial Suricata triage.

Structured Alert Triage with EVE JSON

Rather than relying only on the human-readable fast.log, the structured EVE JSON telemetry was inspected using jq.

jq 'select(.event_type=="alert")' output/eve.json

This allowed alerts to be reviewed together with fields such as:

Figure 14 — Structured Suricata alert analysis using EVE JSON.

Existing Signature Analysis

After identifying the AgentTesla FTP alert, the next objective was to determine exactly why Suricata generated the detection.

Instead of treating the signature as a black box, the corresponding Emerging Threats rule was located and compared directly with the packet content.

One of the most important content conditions in the rule was:

content:"STOR|20|PW_";

In Suricata content syntax, |20| represents the hexadecimal value for an ASCII space.

The signature was therefore looking for traffic resembling:

Figure 15 — Emerging Threats AgentTesla FTP signature inspection.

Rule-to-Packet Validation

tshark -r pcap/*.pcap \
-Y 'ftp.request.command == "STOR"' \
-T fields \
-e frame.number \
-e ip.src \
-e ip.dst \
-e ftp.request.command \
-e ftp.request.arg

Figure 16 — Direct validation of the AgentTesla signature against FTP packet content.

An IDS alert is the beginning of an investigation, not the end of one.

The detection was therefore assessed as a validated true positive. The signature name was not accepted as proof by itself; the exact network content responsible for the match was identified in the PCAP.

Building a Custom Suricata Detection

After validating the existing Emerging Threats signature, independent detection logic was developed from the observed network behavior.

Generic FTP Upload Rule

alert ftp $HOME_NET any -> $EXTERNAL_NET any (msg:"LOCAL SOC Suspicious FTP File Upload"; flow:established,to_server; ftp.command; content:"STOR"; sid:1000001; rev:1;)

Rule Validation

sudo suricata -T \
-c /etc/suricata/suricata.yaml \
-S rules/local.rules

sudo suricata \
-r pcap/2026-02-03-GuLoader-for-AgentTesla-style-infection-with-FTP-data-exfil.pcap \
-c /etc/suricata/suricata.yaml \
-S rules/local.rules \
-l output/custom-rule-test

Figure 17 — Initial custom behavioral detection for outbound FTP uploads.

The generic rule triggered twice, corresponding to both previously identified FTP uploads.

Detection Tuning

To improve specificity, a second rule was developed using the filename structure observed during the credential-related upload:

alert ftp $HOME_NET any -> $EXTERNAL_NET any (msg:"LOCAL SOC Possible Credential Exfiltration via FTP - PW HTML Pattern"; flow:established,to_server; ftp.command; content:"STOR"; ftp.command_data; content:"PW_"; startswith; content:".html"; sid:1000002; rev:2;)

Figure 18 — Tuned Suricata rule based on the observed PW_ HTML filename pattern.

Rule Debugging & Validation

The initial tuned rule did not immediately generate the expected alert. Instead of modifying the rule based on assumptions, Suricata application-layer telemetry was inspected to understand how the FTP command and command data were exposed to the rule engine.

Figure 19 — Application-layer inspection and tuned-rule validation.

IOC Extraction & Classification

Network indicators were extracted after the suspicious behavior had been reconstructed. Indicators were classified according to their role in the investigation rather than treating every observed address as malicious.

Figure 20 — Extraction of network indicators from the investigation.

Figure 21 — IOC and transferred-artifact validation.

Reconstructing the Observable Attack Sequence

Individual network artifacts become significantly more useful when they are placed into chronological context.

The packet capture was therefore used to reconstruct the observable sequence of events surrounding the exfiltration.

Figure 22 — Timeline reconstruction from packet timestamps and protocol events.

Figure 23 — Chronological correlation of FTP control and data-transfer activity.

Mapping the Observed Behavior

MITRE ATT&CK was used to describe behaviors supported by the available network evidence and reconstructed transferred content.

Validating the Independent Investigation

Ground-truth documentation was intentionally reviewed only after the network investigation had produced an independent assessment.

This prevented the expected answer from influencing the initial interpretation of the packet evidence.

Independently Identified Activity

Figure 24 — Final comparison between independent findings and the supplied ground truth.

Final SOC Analyst Verdict

The investigation produced multiple mutually supporting sources of evidence demonstrating malicious outbound data transfer from the internal endpoint.

Evidence Supporting the Verdict

Recommended Response Actions

Based on the network evidence, the affected endpoint should be treated as compromised and escalated through the incident-response process.

From Packet Capture to Defensible Detection

This investigation demonstrated how a relatively small packet capture can be transformed into a complete network-forensics case when the analysis focuses on correlation rather than isolated indicators.

Starting from raw PCAP evidence, the investigation identified the affected endpoint, reconstructed DNS and FTP activity, validated outbound data transfers, correlated Suricata alerts with packet content, and translated the observed behavior into custom IDS detection logic.

Effective SOC analysis is not about collecting the largest number of alerts. It is about turning telemetry into evidence, evidence into understanding, and understanding into detection.