Lost a shell six hours into an engagement because I started recon before migrating

Five-day engagement, and the phishing payload finally landed on day one after three days of nothing. Got a shell, and the first thing I wanted to do was start looking around, check privileges, list users, get a feel for the network. Six hours later it was gone. The user closed the document that had launched the macro, and the process the shell was living in closed with it. Two days into a five-day window, no foothold, and no way back in short of hoping someone opens another phishing email.

The actual mistake wasn't the payload, it was assuming that first shell was stable. A shell riding on the back of a macro, a script, or a dropped executable only lives as long as its parent process does, and the parent is almost always something a completely ordinary user action can end: closing a document, an AV signature catching up to the file, someone just logging off for lunch. None of that is rare. None of it should be able to end an engagement.

What should've happened in the first sixty seconds, before any of the recon I was excited to do, is two things. Migrate the session into a process that has nothing to do with how I got in, something the user has no reason to ever close, explorer.exe or a long-running background service. That alone separates the shell's lifespan from the fragile thing that delivered it. Then set up persistence, a scheduled task, a service, or a registry run key, so that even a reboot during the engagement doesn't wipe the access out. Telling myself "I'll set persistence up after I look around" is exactly how you end up writing an incident report about your own access instead of a findings report about theirs.

The thing that actually prevents this going forward isn't discipline, it's automation. A Metasploit resource script that runs migrate, then persistence, then the first handful of loot commands, means every new shell from every payload runs through the same safe sequence without me having to remember any of it under time pressure with the client's clock running.

Codelivly's Metasploit Post Exploitation Handbook is built around exactly this, treating migration and persistence as the first move instead of something you get to eventually, plus the .rc automation scripts to make the whole sequence repeatable: https://resources.codelivly.com/product/metasploit-mastery-the-ultimate-command-automation-handbook/. Their exploitation fundamentals learning path is free if you want to practice the reverse shell and payload basics underneath all this: https://codelivly.com/learning-paths/exploitation-fundamentals