honeypot fired, do this before you isolate anything

your honeypot just fired. the alert is real, someone's poking around inside a system you control. your first instinct is probably to yank the network cable or slam the firewall shut. don't. that's the fastest way to turn a valuable forensic moment into a mystery you'll never solve. here's the order of operations that actually gets you answers before you shut the door.

why isolating first is the wrong move

the second you isolate the box, the attacker knows something's wrong. they'll drop tools, cut connections, or trigger a cleanup script if they're smart. you also lose the live picture of what's happening right now: active connections, open sockets, in progress transfers. isolation is still coming, it's just not step one. detection without understanding what you're looking at is just a loud alarm going off in an empty room.

step one: see what's connected right now

before you touch anything else, check live network connections tied to running processes.

ss -tnp

this shows you tcp connections with the process id and program name attached. you're looking for connections you don't recognize, especially outbound ones to ips you've never seen, or a shell process (bash, sh, nc, python) holding open a socket it has no business holding. the -t filters to tcp, -n skips dns resolution so it's fast and doesn't tip anyone off with weird lookups, and -p shows you the process behind each connection. this single command tells you if the attacker is still actively connected or if they already left.

step two: check who logged in and from where

last -a

this pulls recent login history and appends the source hostname or ip at the end of each line, which is the part most people miss because they run last without the flag and squint at a truncated table. you're hunting for logins at weird hours, from ips that don't match your normal admin locations, or accounts that shouldn't be logging in interactively at all (service accounts, for example). this is your timeline. it tells you when the door opened.

step three: watch, don't touch

if ss -tnp showed an active connection, now's the time to observe traffic quietly instead of blocking it.

tcpdump -i eth0 host [attacker_ip] -w capture.pcap

swap eth0 for your actual interface and drop in the ip you found. this captures the traffic to a file you can analyze later without interrupting anything. the goal here isn't to become a real time surveillance operator, it's to grab evidence of what's being sent or pulled before you cut the connection. blocking now means guessing later.

step four: figure out what kind of visitor this is

not every honeypot hit is a targeted human attacker. a lot of it is automated scanners bouncing around the internet, hitting every open port they find. look at the behavior: is it one quick connection and gone, or is it a sustained session with commands being typed, files being pulled, or attempts to jump to other hosts on your network? that difference decides whether you're dealing with background internet noise or someone actively moving laterally through your environment. this decision point is why you gathered the evidence in the first two steps instead of panicking immediately.

then, and only then, isolate

once you understand what's connected, when it got in, and whether it's scanning noise or active lateral movement, now you cut the network access, rotate every credential that touched that box, and start hunting for the actual entry point (unpatched service, leaked key, weak password, whatever it was). isolating too early just means you'll be doing this same hunt later with way less evidence to work with.

the takeaway

a honeypot firing is a gift, it's a controlled environment telling you exactly where to look. the mistake most people make is treating the alert like the finish line instead of the starting gun. run ss -tnp, check last -a, capture the traffic, classify the threat, then isolate and rotate. protect your own systems by practicing this order on a test box before you ever need it for real, because the middle of an actual intrusion is a terrible time to be googling command flags.