Episode Details

This story was originally published on HackerNoon at: https://hackernoon.com/when-powershell-said-failed-tcpdump-said-why.
A failed PowerShell download, a missing packet, and the tcpdump commands that proved where the connection really died — host firewall, not the attacker.
Check more stories related to cybersecurity at: https://hackernoon.com/c/cybersecurity. You can also check exclusive content about #cybersecurity, #tcpdump, #network-forensics, #threat-hunting, #incident-response, #packet-analysis, #infosec, #blue-team, and more.

This story was written by: @RoshanRajbanshi_frqj97tc. Learn more about this writer by checking @RoshanRajbanshi_frqj97tc's about page, and for more stories, please visit hackernoon.com.

A malicious PowerShell script on a compromised app server tried to download a second-stage payload and failed — but the error message couldn't say whether the attacker's server refused it, a firewall blocked it, or it never left the host. Four tcpdump commands settled it: the request never reached the network at all. This piece walks through the core tcpdump syntax (reading captures, payload inspection, host/port filtering, TCP flag matching) using a clean sample file, then applies it to a real incident-response case to show why packet-level visibility catches things host logs structurally can't.