You’ve probably seen it, that familiar yellow warning when you connect to a Remote Desktop session:
“The identity of the remote computer cannot be verified. Do you still want to connect?”
Like many others, you’ve likely clicked “Yes” without a second thought. It’s always been that way, right?
But what if that one click was all it took for an attacker to slip in, intercept your connection, and steal your credentials?
In this blog, we’ll break down a real-world man-in-the-middle attack using self-signed RDP certificates and ARP spoofing, a technique we’ve seen in action during penetration tests. We’ll show you how it works, why it’s effective, and how to stop it before it catches you out.
What is RDP in Cyber Security and Why Is It a Common Target?
Remote Desktop Protocol (RDP) is a Microsoft tool that lets users remotely access a Windows machine seeing and controlling it as if they were physically in front of it.
It’s widely used by IT teams, system admins, support desks, and third-party vendors for everything from troubleshooting to system maintenance. Built into Windows and easy to configure, it’s found on servers and workstations across most internal networks.
But with that convenience comes risk. RDP provides direct access to machines – making it an appealing target for attackers, especially when it’s misconfigured.
One of the most overlooked issues? The use of self-signed certificates.
Internally, many RDP servers use these by default. Users are then greeted with a warning that the server’s identity can’t be verified. Over time, they get used to clicking past it “it’s always been like that.”
This routine response creates an ideal opportunity for attackers to exploit the trust gap. Allowing them to slip in unnoticed when users least expect it.
What Is ARP Spoofing Attack and Why Does It Matter Here?
To understand this attack, you first need to know how devices communicate on a local network and that starts with ARP.
ARP (Address Resolution Protocol) maps IP addresses to MAC addresses so devices know where to send data. When your computer wants to connect to another device – like an RDP server – it asks, “Who has this IP?” The correct device replies with its MAC address, and the connection is made.
ARP spoofing manipulates this process. An attacker sends fake ARP messages claiming that their device is the RDP server. The victim’s machine believes it — and starts sending RDP traffic to the attacker instead.
From the user’s perspective, nothing looks wrong. They connect as normal using the right IP or hostname, unaware that their session is now being intercepted.
This silent redirection is the first stage of the attack. No alerts. No crashes. Just traffic quietly flowing through the attacker’s machine — setting the stage for credential theft.
Breaking Down the Attack: Step-by-Step
This attack isn’t theoretical. It’s a practical technique that relies on common internal misconfigurations and a bit of user complacency. Here’s exactly how it plays out in the wild:
Step 1: The attacker joins the same internal network.
The attacker could be:
- A malicious insider
- Someone who’s already compromised a device on the network
- An external actor who’s pivoted into the environment after an initial breach
Once inside, they’re able to monitor and interact with traffic on the local network.
Step 2: ARP spoofing is used to impersonate the RDP server
The attacker sends out spoofed ARP messages, tricking the victim’s machine into thinking:
“This IP address belongs to the attacker’s MAC address.”
As a result:
- Any traffic meant for the real RDP server is now sent to the attacker
- This includes the initial handshake and certificate exchang
From the user’s perspective, nothing looks suspicious – they’ve typed in the usual hostname or IP, and hit connect.
Step 3: A fake self-signed certificate is served
To complete the illusion, the attacker:
- Generates a new self-signed certificate
- Replicates key details from the real one (such as the Common Name and expiry date)
- Presents it to the user as if it were the expected RDP cert
Why this works:
Most users are used to seeing this warning and have learned to click “Yes” without thinking. The warning doesn’t look any different than it normally would.
Step 4: The user accepts the certificate warning.
This is the pivotal moment.
Because the certificate looks familiar, and the user trusts the environment, they:
- Click “Yes” to accept the certificate
- Proceed with what they believe is a normal RDP session
Step 5: Credentials are intercepted.
Here’s where the real damage happens:
- The attacker receives the user’s authentication attempt
This might include:
- NTLM hashes (which can be cracked offline)
- Or even plaintext credentials in some cases
- The attacker now has valid login details
Step 6: The session is proxied to the real RDP server.
To avoid detection, the attacker:
- Forwards the session to the actual RDP server
- Ensures the user’s session completes as expected
The user logs in successfully. No errors, no failures, no suspicion.
The result?
- The attacker gains access to credentials
- The user is none the wiser
- There’s no visible sign that the session was hijacked
This is a classic man-in-the-middle attack – made possible by a combination of weak certificate practices and silent traffic redirection.
RDP Security Risks: Why This Works – And Why It’s Still Happening
The success of this attack doesn’t come down to advanced malware or obscure vulnerabilities. It works because it exploits two things: human behaviour and internal complacency.
Let’s break it down.
1. Users are conditioned to ignore the warning.
The success of this attack doesn’t come down to advanced malware or obscure vulnerabilities. It works because it exploits two things: human behaviour and internal complacency.
Over time, it becomes habit:
- See the warning
- Click “Yes”
- Get on with your day
That muscle memory is exactly what the attacker relies on.
2. Self-signed certificates are still widely used internally.
In many networks, especially those managed in-house without centralised certificate infrastructure, RDP servers use self-signed certs by default.
Why? Because:
- It’s quicker than setting up a certificate authority
- It “just works”
- And internally, it’s often seen as low risk
Unfortunately, this creates the perfect conditions for an attacker to slip in unnoticed.
3. There’s a false sense of security inside the perimeter.
It’s easy to assume that because an RDP service is only available inside the network, it’s safe from this kind of attack. But once an attacker gains a foothold – through phishing, an exposed device, or misconfigured access – these internal weaknesses become prime targets.
The idea that “it’s on the internal network, so it’s fine” is no longer good enough.
4. The warning message always looks the same.
Here’s what makes the attack so convincing:
- The warning that appears when connecting to a fake RDP server with a spoofed cert is identical to the one shown when connecting to a legitimate one.
- The only difference? The certificate fingerprint — a long string of characters that most users will never check, let alone understand.
So even when something’s not right, there’s nothing visually obvious to raise suspicion.
The bottom line?
This attack doesn’t rely on exploiting a technical vulnerability – it exploits trust. And it thrives in environments where certificate management is lax, and users are trained to click past warnings without thinking twice.
Mitigation: How to Protect Against This Attack
This attack is effective because it takes advantage of common internal setups and user habits — not because it’s sophisticated. Fortunately, there are clear steps you can take to prevent it from working in your environment.
Start by addressing the root of the problem: RDP self-signed certificates. These are untrusted by default and lead users to routinely accept security warnings.
- Replace self-signed certs with certificates issued by your internal Certificate Authority (CA), such as Active Directory Certificate Services.
- This ensures the RDP server’s identity can be verified and removes the need for users to make trust decisions.
Once trusted certificates are in place, enforce their use. You can configure this via Group Policy:
- Block connections to RDP servers that present untrusted or invalid certificates.
- Remove the “Do you want to connect anyway?” prompt entirely.
User behaviour also plays a part. The goal isn’t to teach users about certificate fingerprints – it’s to make the warning itself a signal that something is wrong.
- Educate users not to click “Yes” when they see an RDP certificate warning.
- Encourage them to report the issue instead – it could be the first sign of an attack.
Another small but important change is to ensure users connect using the hostname, not the IP address. Certificates are tied to hostnames – if you use an IP, certificate validation will always fail.
To reduce exposure even further, tighten access to RDP across the network:
- Limit which users and systems can initiate RDP connections.
- Use internal firewalls and network segmentation to restrict lateral movement.
And to stop the spoofing aspect of the attack, monitor your network for suspicious ARP activity. Better still, harden the network infrastructure:
- Enable Dynamic ARP Inspection on managed switches.
- Use network monitoring tools to detect ARP poisoning attempts.
Finally, make internal network penetration testing a regular part of your security programme. These types of misconfigurations often go unnoticed – until someone actively looks for them.
A Familiar Warning, A Real World Threat
This isn’t just a theoretical attack. It’s something we’ve seen first-hand during internal penetration tests – and it often goes unnoticed until it’s demonstrated in action.
The danger lies in how ordinary it all feels. A routine RDP login. A certificate warning that’s always been there. A user doing what they’ve always done. That’s exactly what makes this technique so effective.
It’s a reminder that not every threat announces itself loudly. Sometimes, the most successful attacks blend in with the everyday — hiding in plain sight behind ignored warnings and unchecked assumptions.
If you’re unsure whether your RDP setup could be vulnerable to this kind of attack, we’re here to help. Our Penetration Testing team can walk you through the risks, identify misconfigurations, and help you harden your internal environment – step by step. Call 0121 663 0055 or email enquiries@equilibrium-security.co.uk
Let’s make sure a familiar warning doesn’t become your next breach.
Ready to achieve your security goals? We’re at your service.
expertise to help you shape and deliver your security strategy.
About the author
