Two jobs after escalation
You have elevated access on a single host. That access is fragile: the user logs off, a reboot kills your shell, a patch closes the hole you came in through, and you are locked out of an environment you spent days getting into. So the first job after escalation is persistence — planting a way back in that survives reboots and password changes, so you do not have to re-exploit from scratch every time.
The second job is lateral movement: that first box is almost never the goal. The goal is the domain controller, the database, the file server — targets that sit deeper in the network. Lateral movement is how you go from one compromised host to many, and pivoting is how you reach networks you cannot even touch from where you started.
Persistence mechanisms
Persistence means installing something that re-runs your access on a schedule, at boot, or at login — so a reboot or a logout does not end the engagement. Every operating system gives legitimate software dozens of ways to start automatically, and an attacker simply borrows those same hooks. The table below covers the mechanisms you will see most often.
| OS | Mechanism | Note |
|---|---|---|
| Windows | Registry Run keys | Values under HKLM/HKCU ...\Run launch a program at login. A long-standing favorite because it is trivial to set and survives reboots. |
| Windows | Scheduled tasks | schtasks can run your payload at boot, at login, on an interval, or on an event — blends into a sea of legitimate tasks. |
| Windows | New / modified services | A service set to start automatically runs as SYSTEM at boot. Creating one, or hijacking an existing one, buys both persistence and high privilege. |
| Windows | Startup folder | Anything dropped in the user or all-users Startup folder executes at login. Low-tech and noisy, but effective. |
| Windows | WMI event subscriptions | A permanent WMI subscription fires your payload when a chosen system event occurs. Fileless and stealthy — a known APT technique. |
| Linux | Cron jobs | A line in crontab re-launches your callback on a schedule. The classic Unix persistence hook. |
| Linux | systemd services / timers | A custom .service unit (optionally paired with a .timer) starts at boot and can auto-restart — the modern equivalent of a Windows service. |
| Linux | Shell startup files | Appending to ~/.bashrc (or profile scripts) runs your command every time that user opens a shell. |
| Linux | SSH authorized_keys | Dropping your public key into ~/.ssh/authorized_keys gives passwordless SSH back in — clean, quiet, and survives password resets. |
Credentials are the real key
Here is the single most important idea in this lesson: lateral movement runs on stolen credentials, not on fresh exploits. Once you are inside, you rarely need another vulnerability to reach the next machine. You need a username and password — or, just as good, a password hash — that the next machine will accept. Real intrusions move sideways by logging in, not by breaking in again.
That is why a single weak box can topple an entire domain. Compromise one machine, harvest the credentials cached on it, and those credentials very often work somewhere else:
- Credential reuse — the same local administrator password is set on dozens of machines, or a user reuses one password everywhere. Crack or capture it once and it unlocks the rest. This is the engine of most domain compromises.
- Pass-the-hash — on Windows you often do not even need the plaintext password. The NTLM hash itself is enough to authenticate to other systems, so a dumped hash is the key — no cracking required.
- Harvesting — where the keys come from: hashes dumped from the SAM database, credentials scraped from LSASS memory, cached domain credentials, and plaintext secrets sitting in config files, scripts, and saved sessions.
Internalize this and lateral movement stops looking like magic. It is a loop: land on a host, harvest its credentials, use them to reach the next host, harvest again. Each hop hands you fresh material for the hop after it.
Lateral movement techniques
With harvested credentials in hand, moving to another host means using the network's own legitimate remote-administration channels — the exact tools admins use every day, which is precisely why this traffic blends in. Each technique below is just a different way of saying "log in somewhere else using access you already have."
- PsExec — remotely creates and runs a service on the target over SMB to get a command shell. Drive it with credentials or a hash you already harvested.
- WMI — Windows Management Instrumentation can spawn processes on a remote machine using existing credentials, with no new file written to disk on the way in.
- WinRM — Windows Remote Management (PowerShell remoting) gives you a remote shell over an administrative protocol that is often already enabled in a domain.
- RDP — Remote Desktop. With valid credentials it is the most literal form of lateral movement: an interactive desktop session on the next box.
- SSH — the Linux equivalent of all of the above. A reused password or a harvested private key gets you a shell on the next host directly.
Notice that none of these is an exploit. They are sanctioned remote-access tools, abused with stolen access — which is exactly what makes lateral movement so hard to spot and so important to study.
Pivoting: reaching what you can't touch
Often the machine you really want is on a network segment you cannot reach from your attacking box — an internal subnet with no route from the outside. But the host you just compromised can reach it. Pivoting turns that compromised host into a relay, routing your traffic through it so your tools can reach systems that are otherwise invisible to you. These are the three workhorse approaches.
| Approach | Mechanism | Use case |
|---|---|---|
| Meterpreter routing | route + portfwd | route tells the framework to send traffic for an internal subnet through the session; portfwd forwards a single remote port back to your local machine to hit one specific internal service. |
| SOCKS proxy | socks_proxy + proxychains | Stand up a SOCKS proxy through the session, then run external tools (scanners, browsers) through proxychains so your whole toolset reaches the internal network transparently. |
| SSH local forward | ssh -L | Bind a local port to a single remote service through the pivot — e.g. reach an internal web app or database that is only listening on the far side. |
| SSH remote forward | ssh -R | Open a port on a host you control that tunnels back inward — useful for getting a callback out of a network that blocks outbound connections. |
| SSH dynamic / SOCKS | ssh -D | Turn an SSH session into a SOCKS proxy, tunneling an entire toolset through the pivot host instead of forwarding one port at a time. |
The mental model is the same across all three: your traffic enters the compromised host, exits onto a network you could never reach directly, and the answers come back the same way. Master pivoting and a single foothold becomes a doorway into everything that host can see.
The defensive flip
Everything above is also a checklist for the defender. Because lateral movement and persistence rely on legitimate tools and reused credentials, the countermeasures are mostly about limiting blast radius and watching for the artifacts — the very ones we just produced.
- Network segmentation — break the network into zones so a single compromised host cannot reach the whole estate. Segmentation is what stops one weak box from becoming a domain-wide breach.
- Credential hygiene and unique local admin passwords — kill credential reuse. A tool like LAPS sets a different, rotating local administrator password on every machine, so a hash harvested from one box opens nothing else.
- Disable legacy authentication — retire weak, hash-passable protocols where you can, so a captured hash is far less useful for moving sideways.
- Monitor for the artifacts — alert on new services and scheduled tasks, suspicious Run-key and ~/.bashrc changes, unexpected authorized_keys entries, LSASS access, and a single account authenticating to many hosts in a short window. Each is a footprint of a technique on this page.
By now you have kept your access and spread it across the network. The next question is the one that actually matters to the client: so what? What is on these machines, what can you reach, and what does it prove about the real-world impact of the breach? That is looting — turning access into evidence of impact — and it is where this phase goes next.