Metasploit Post-Exploitation: Meterpreter, Privilege Escalation and Pivoting

The session is the beginning, not the end

Landing an exploit is the part beginners celebrate and experienced testers treat as step one. A shell on one machine, as a low-privilege user, with no way back in if the connection drops, proves very little on its own. The value of an engagement is in what the session lets you demonstrate next: that you could become administrator, read the credentials that unlock the rest of the network, and reach systems that were never exposed to you directly. That is post-exploitation, and Meterpreter is the tool built for it.

This guide assumes you already have a Meterpreter session — if you do not, the companion guide covers getting one. Everything here runs at the meterpreter > prompt.

Why Meterpreter, and not a plain shell

An exploit can hand you an ordinary command shell, and sometimes that is all you get. Meterpreter is worth choosing when you can because of how it runs: it lives in the memory of the process it landed in and never writes itself to disk, it speaks to you over an encrypted channel, and it exposes one consistent set of commands whether the target is Windows or Linux. A plain shell makes you fight the target's own tooling — different commands on every OS, everything written to disk, everything in the clear. Meterpreter gives you a stable platform to work from.

Orient before you act

The first minute in a new session is for finding out where you are, not for firing commands:

meterpreter > sysinfo        # OS, architecture, hostname, domain
meterpreter > getuid         # who you are running as
meterpreter > getpid        # which process you are living inside
meterpreter > ipconfig       # the target's networks — note ones you can't reach yet

getuid decides your whole next move. If it already reports NT AUTHORITY\SYSTEM or root, you skip privilege escalation entirely. If it reports an ordinary user, that is the first problem to solve. And ipconfig is where pivoting begins: a second network interface on the compromised host, on a subnet you could not touch from outside, is the map of where you go next.

Getting from user to administrator

meterpreter > getsystem

getsystem tries a handful of known local privilege-escalation techniques and, on an unpatched or misconfigured host, may take you straight to SYSTEM. When it works, it is the fastest path. When it fails — and on a patched, modern system it usually does — the honest next step is enumeration, not repetition. Background the session and run a local exploit suggester:

meterpreter > background
msf6 > use post/multi/recon/local_exploit_suggester
msf6 > set SESSION 1
msf6 > run

That checks the session against local exploits the target may be vulnerable to and hands you a shortlist to try. Escalation on a well-maintained system is a research problem — which missing patch, which weak service permission, which misconfiguration — not a single magic command, and treating getsystem as if it always works is how beginners get stuck.

Harvesting credentials — carefully

Once you are SYSTEM, credentials are the prize, because they turn one compromised host into access across the network:

meterpreter > hashdump                 # local SAM password hashes
meterpreter > load kiwi                 # the in-memory Mimikatz extension
meterpreter > creds_all                 # cached credentials from memory

Two cautions that matter on a real engagement. hashdump and kiwi read the most sensitive data on the machine, and on a monitored network they are exactly what an EDR is watching for — loading kiwi may be the loudest thing you do all day. And what you recover is client data under your custody: it belongs in the report and in an encrypted store, not left in your loot directory or pasted into a chat. Handle it like the liability it is.

Reaching what you could not see: pivoting

This is the technique that turns a single foothold into a network compromise, and the reason ipconfig was the first thing you ran. If the host you own sits on a second subnet — say it can reach 10.0.0.0/24, which you never could from outside — you can route traffic through it:

meterpreter > run autoroute -s 10.0.0.0/24
meterpreter > background
msf6 > use auxiliary/scanner/portscan/tcp
msf6 > set RHOSTS 10.0.0.0/24
msf6 > run

autoroute tells the framework to send traffic for that subnet through your session, so Metasploit's own scanners and exploits now reach machines that were never exposed to you. Add a socks_proxy module on top and your other tools — a browser, sqlmap, anything that honours a SOCKS proxy — can reach the internal network too. This is the step where an assessment stops being about one server and starts being about the client's actual exposure.

Files, screenshots, and gathering evidence

meterpreter > download C:\Users\Administrator\Desktop\notes.txt
meterpreter > upload ./tool.exe C:\Windows\Temp\report.exe
meterpreter > screenshot
meterpreter > pwd

A pentest report is only as persuasive as its evidence. A screenshot of the target's desktop, the contents of a sensitive file, the output of getuid showing SYSTEM — these are what turn "the host was vulnerable" into "here is what an attacker would have taken". Collect proof as you go, and note the timestamps.

Persistence, and why to be reluctant with it

Metasploit can install a mechanism that re-opens your session after a reboot. On a real client engagement you should be reluctant to use it, and never without explicit permission in the rules of engagement, because it means leaving a backdoor on a system you do not own. If it is in scope, it is also a cleanup obligation: whatever you install, you are responsible for removing, and an unremoved persistence mechanism is a finding against you. The safer habit is to document that persistence was achievable — you had the access to install it — rather than actually planting one.

Clean up after yourself

Post-exploitation leaves traces, and a professional removes them:

• Delete files you uploaded (rm inside Meterpreter, or the target's own commands).
• Remove any persistence mechanism you were authorised to install.
• Record every change you made — accounts, files, services — so the client can verify the environment is back to where it started.

Leaving a lab dirty is a bad habit; leaving a client's production system dirty is a professional failure.

The rule that sits above all of it

Every command here is illegal against a system you have not been authorised in writing to test, and the sensitive ones — credential dumping, persistence, pivoting to new hosts — are exactly the actions a rules-of-engagement document scopes explicitly. "I had a shell so I kept going" is not authorisation. Stay inside the written scope, and practise the whole chain against Metasploitable or a HackTheBox target until the workflow is muscle memory before you run it anywhere real.

Running this without the local setup

Post-exploitation is where a self-managed Metasploit install earns its keep, and running it yourself is a fine way to work. If you would rather not maintain the framework and its extensions, CyberSec Pro runs Metasploit's modules from a browser — module and options on a form, the command shown before it runs, output streamed back — with each job in its own container and any credentials you supply held in memory for that job alone and never written to disk. The discipline is unchanged: orient first, escalate by enumeration rather than repetition, treat harvested credentials as client property, and clean up everything you touched.