RDP Redirection Attack: How a Simple Configuration File Can Grant Complete System Access!
Here's an interesting and lesser-known RDP attack that works without credentials:
We usually think of RDP attacks as:
Exposed machine on the internet -> Attacker brute-forces creds -> Gets remote access.
But attackers are flipping this model.
They’re not connecting to the victim. They’re tricking the victim into connecting to them!
This is based on a targeted campaign against European govt/military as reported by Google/Microsoft/CERT.
Attack Flow:
Attacker creates a phishing email > Attaches a RDP configuration file (.RDP) > Signs the .RDP file with a LetsEncrypt certificate.
Victim executes the file > Because its signed, no warning is showed > RDP connection gets initiated from the victim's machine to attacker server.
Here's the interesting part: In the .RDP file, attacker defines specific RDP configuration parameters > This allows redirection of all drives, printers, COM ports, smart cards, clipboard, web auth requests (e.g., security key) to the attacker server.
In other words, on attacker's server, all of the victim's drives and other devices are mapped (refer to pic for easy clarity, source: Google Cloud) and accessible to attacker > Attacker exfils data or launches ransomware > Mission accomplished!
A Few Thoughts:
Attackers love the concept of 'why reinvent when you can repurpose?'. We are familiar with the interactive use of RDP (using MSTSC). But this attack leverages a less-common way to use the same: using .RDP config files. Same technology, different method.
Launching this attack is very trivial. Attacker just needs to drop the server name into a .RDP config, tweak a few parameters and hit send. Low effort, high impact.
Enterprises often see incoming RDP as a big risk because its exposed to internet. But this technique flips the threat surface: outgoing RDP can be just as dangerous.
Signed doesn’t always mean safe. LetsEncrypt provides free TLS certificates to anyone who can prove domain ownership. It’s domain validation only, not organizational validation. This is perfect for HTTPS on websites but problematic when: attackers use these certs to sign RDP files to bypass user warnings.
The easiest way to prevent this attack: Do not allow incoming/outgoing RDP traffic to public IP addresses. Default deny. If there is a business need, track them as exceptions granting permission to specific systems only.
More preventive measures: 1) Disable execution of .RDP files from unsigned and unknown publishers. 2) Block .RDP files that are email attachments from external sources. 3) Disable RDP resource redirection via the Registry.