A pentester gets a shell on day one of a five-day engagement, from a phishing payload someone finally clicked after three days of silence. The instinct is to start looking around immediately: check privileges, list users, map the network. Reasonable instinct, wrong order. Six hours later the shell is gone. The user closed the document that launched the macro, and the process it spawned went with it. Two days into a five-day window and the only foothold is gone, and getting another one means waiting for someone else to open another phish, if anyone does.
The mistake wasn't the payload or the target. It was treating the first shell as a stable one. A shell running as the child of a macro, a script, or a dropped executable lives exactly as long as its parent process does, and its parent is usually something a normal user action can kill: closing a document, an AV signature finally matching the dropped file, the user just logging off. None of that is unusual, all of it happens on a normal workday, and none of it should be the thing standing between an assessor and their access.
The fix is two commands run in the first sixty seconds, before recon, before anything interesting. First, migrate: move the Meterpreter session into a process that has nothing to do with how you got in, one the user isn't going to close on their own, explorer.exe or a long-running service process. That decouples the shell's lifespan from the fragile thing that delivered it. Second, persistence: register a scheduled task, a service, or a registry run key that re-establishes a callback on reboot or logon, so a restart during the engagement window doesn't mean starting over. Skipping either step because "I'll do it after I look around" is exactly the gap between an engagement that produces findings and one that produces an incident report about your own access.
The part that actually saves time on a real engagement isn't remembering to run these commands, it's not having to. Writing them once as a Metasploit resource script, migrate, then persistence, then the first loot commands, means a fresh shell from any payload runs the same safe sequence automatically instead of you retyping the same eight commands under time pressure with the client's clock running.
Codelivly's Metasploit Post Exploitation Handbook covers exactly this: migration and persistence as the first move, not an afterthought, plus the .rc automation scripts to make it repeatable instead of manual every time. The exploitation fundamentals learning path on the site is a free place to practice the reverse shell and payload basics this builds on.
