General Blog

How self-signed certificates invite man in the middle attacks.

  • Introduction
  • The purpose of digital certificates
  • What is a self-signed certificate?
  • What’s the impact?
  • Where do we go from here?
  • Conclusion

Ever since communication was invented, the need for encryption has been apparent and the solution has been sought after by all. This led many mathematicians down a path to create scalable, efficient solutions that not only encrypt communications, but creates a system that ensures integrity and confirms messages were truly sent by the person that it claims to be. While cryptography is a gigantic conversation piece that definitely deserves its own blog post, it is not our intention to get into the nitty gritty about the math behind cryptography. Instead, I’d rather talk about the fundamental purpose of digital certificates, and why IT admins seem to forget half of their purpose.

The purpose of digital certificates

Digital certificates serve two main purposes:

  • Provide information about the public key so that communication can be encrypted, and only decrypted by those that hold the paired private key. In other words, it ensures others can’t see the data within your session.
  • Certifies the ownership of a public key by the named subject of the certificate. In other words, it confirms that system you are communicating with is the one that you intended to.

But over time, many IT administrators seem to have forgotten about half the reason these digital certificates exist. From my time working at an MSP, to my time working as a Pentester, it is far too common to see self-signed certificates in use on important network infrastructure, including backup systems, remote desktop servers/workstations, switches, access points, camera systems, Hypervisors, and more — with many users trained to ignore certificate warnings because “that’s suppose to happen”.

What is a self-signed certificate?

Self-signed certificates have a useful purpose, which is to allow you to communicate with a device over an encrypted connection. This is obviously very important, but they lack in one critical area.

Digital certificates not only contain information about the public key used to encrypt the connection, but they also contain the digital signature of an entity that has verified the certificate’s contents (called the issuer). When a certificate is “self-signed”, that means there was no third party issuer to confirm the legitimacy of the system’s identity. This would be like a couple of police officers showing up with badges they printed themselves from Staples — It may look legitimate, but the police department (a trusted third party) didn’t actually issue those badges to verify the legitimacy of the “officers” identity.

Because of this, what would stop an attacker from pretending to be the system you meant to connect to? Sure, the communication would be encrypted, but if the attacker provides the public key used for the encryption, then they could also control the private key used to decrypt the communication. This is called a Man in The Middle attack.

What’s the impact?

When most people think of “Man in the Middle” (MitM) attacks, they usually think of connecting to insecure, public Wi-Fi networks. This is a problem.

MitM attacks are not restrained to only wireless networks, they’re prevalent in wired network environments too. The goal of these attacks can range from spying on somebody’s activity, harvesting credentials, or even redirecting the flow of traffic to a different location. All of these can have very real impacts, especially when you consider the high value of infrastructure that we commonly find using self-signed certificates.

For example, let’s talk about a technology that 2020 has us all more familiar with — the Remote Desktop Protocol (RDP). It is very common to see self-signed certificates in use when connecting to a remote computer via RDP. If you’re unsure if your computer is using a self-signed certificate, let me ask you: Does this image seem familiar?

If you answered “Yes” to that question, and if your first instinct when being displayed with this prompt is to click “Yes”, then your computer is likely using a self-signed certificate and you are vulnerable to Man in The Middle Attacks.

Seth is a tool written by Adrian Vollmer of German-based security company SySS that helps automate the process of performing RDP MitM attacks. If you’re interested in seeing just how easy it is to use this tool to perform attacks, feel free to check out my post Performing RDP Man in the Middle (MitM) Attacks Using to Steal Passwords.

Let me ask you another one. Are you an IT administrator that is used to seeing this when browsing to the web interface of your equipment? If the answer is “Yes”, then your equipment is likely using a self-signed certificate and you are vulnerable to Man in The Middle Attacks.

Where do we go from here?

The good news is that there are many articles online on how to replace self-signed certificates with trusted ones, which makes this problem easy to fix from a technical perspective. The bad news is fixing this problem at an organizational level may be a bit more difficult if your users are already used to blindly accepting these certificate warnings.

Once certificates are signed by a trusted authority, users will no longer be presented with these warnings as long as things are working properly. This means that in the event of a real MitM attack, users will need to be aware that these certificates errors should NOT be ignored, as it will be an indication that a real attack is underway. Should they choose to follow their untrained habit of ignoring these warnings, they will still be vulnerable to these attacks.

This is where user awareness training comes in, yet again, as a very critical piece of your security posture. If you need help getting your security awareness training programs dialed in, feel free to reach out to us at Lykosec.

The IT department must not be excluded from this training either, as they are probably the most at-risk of misunderstanding why they’re getting a certificate warning. Devices ship out of the box with self-signed certificates deployed automatically, and IT admins are very used to ignoring them when browsing the web interfaces of these devices. IT needs to not only be made aware of the impact of this problem, but also needs to understand how it works so they can determine properly when a certificate warning is safe and when it isn’t.

IT teams should make every effort to replace self-signed certificates. In an ideal scenario, equipment that ships with self-signed certificates should be prepped in an isolated subnet that no other users connect to. IT should make sure that they are the only devices connected to this subnet before accepting the certificate warning, and include replacing the self-signed certificate with a certificate signed by a trusted authority as a mandatory step before that device is put into production.


While self-signed certificates serve their purpose for encrypting communications, relying on them in production invites Man in the Middle attacks as users are no longer able to verify the legitimacy of the system’s identity. If you can’t confirm who you’re talking to, you don’t really know them, and as our mothers always told us, “you should never talk to strangers”.

Hacking Tutorial

Performing RDP Man in the Middle (MitM) Attacks Using to Steal Passwords

Are you used to getting inundated with invalid certificate prompts when connecting to a remote machine? Way more often than not do I see self-signed certificates in play when establishing RDP connections. This always left me wondering… Surely this opens the door to a Man in the Middle Attack?

Insert Seth! Which is described by its authors as “A tool written in Python and Bash to MitM RDP connections by attempting to downgrade the connection in order to extract clear text credentials.”

Table of Contents:

  • Installing the Tool
  • Setting the Stage
  • Performing the Attack
  • Mitigation Strategies

Installing the Tool

You can download the tool from GitHub by using the following command.

sudo git clone

We have a couple prerequisites to install.

sudo apt install dsniff -y

Setting the Stage

In my demo, we have three virtual machines in play.

  1. Attacker VM running Kali Linux at IP address
  2. Victim VM running Windows 10 at
  3. Server/Destination VM running Windows 10 at

The victim is going to sign into his computer, and then attempt to perform a RDP connection to the Destination VM at using his domain credentials, NBA\dLillard. When he attempts the connection, he is prompted to enter a password.

Because IT admins are usually lazy, all machines are just using their self-signed certificates which generate certificate errors when users connect. Many users in the real world are actually numb to these errors because this is such a common misconfiguration left far too often. Because of this, majority of users will just ignore the certificate error that gets generated during the Man in The Middle attack.

Performing the Attack

The tool is actually very simple to use.


Using the above syntax, our command will look like this.

sudo ./ eth0

When we execute the above command, we just need to wait for the victim to attempt their RDP connection. Once they do, they’ll be treated with their normal credential and certificate error prompts, which should return their cleartext credentials to us.

The above example is showing output from Seth when the destination machine does not require NLA authentication. However, domain joined Windows 10 machines will enforce NLA by default, which means we will not be able to forward the connection request off to the server in order to establish the connection.

However, even with NLA enabled, Seth will spin up a fake server in order to attack the client and receive the cleartext credential. The end user’s connection attempt to the server will fail, but we’re still able to utilize the tool to grab what we need.

Warning When Using Against Local User Accounts

Be careful when using this tool against machine that are not domain joined, or against machines that authenticate over RDP using local user accounts.

I found that when I attempted to perform the attack to non-domain joined machines, the invalid hostname was passed to the destination server. The login was attempted using the local user account to the hostname of the victim, and not the local user account on the hostname of the destination. The attack still “worked” because I was able to extract cleartext credentials, but the end user was unable to authenticate to their destined computer and would know something was wrong.

Mitigation Strategies

Configure clients so they do not establish connections to a RDP host if they cannot verify its identity. This will require Public Key Infrastructure, either by purchasing public certification or rolling out your own infrastructure.

Windows machines can be configured in this way using the following GPO:

Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Connection Client\Configure server authentication for client