Recently, in performing my daily due diligence to keep up with the latest news and changes in information security, one article in particular caught my attention. Its topic of SSL encryption, and the related research, are particularly fascinating and nascent to me as an offensive security professional. The first article was in Dark Reading, and while its title was a bit “click-bait like” it is still true: more than 40% of attacks abuse SSL encryption. This did not catch my attention because it was any sort of surprise, but more because it is actually true, and I know it is from personal experience.

How Encryption Hides

Consider this: For the past nine years almost every attack I have ever successfully pulled off within any client’s network has taken advantage of the fact that SSL traffic is rarely actually inspected. Even when I want to use SSH and reverse shells I still almost always wrap that inside of SSL traffic to ensure it won’t receive any scrutiny or set off any alarms. Using encryption to mask my activities is as close to “Standard Operating Procedure” (SOP) as it gets in penetration testing and hacking – at least for me it is.

However, I would also like to point out that these techniques have worked despite numerous mitigating controls on client’s networks. One of the first penetration tests I ever got to take part in was for a company that had relatively recently added the ability to decrypt, review, and filter encrypted (SSL/TLS) traffic. This is a relatively simple task if you have control over the end-user systems. All that must be done in order to read and inspect every encrypted packet is to add a new trusted certificate (which you own) to the computer’s cert store. Then becoming a “man-in-the-middle” (MitM) is not difficult, and any encrypted traffic can be inspected before it is allowed to traverse the DMZ on its way to the Internet.

Privacy, Security and Secrets

There are many “schools of thought” on the topic of reading your user’s encrypted traffic. The first thing that comes to my mind (and that of many others) is privacy. This is not regulated privacy, as there are no rules to protect the privacy of the activities that take place on corporate owned systems. The company owns the computers, network, Internet connection, etc., so they can more or less do whatever they want. This definitely includes the end user systems and any traffic they generate on those systems, regardless of whether that traffic is strictly business related or not.

Keep Using Encryption

Now, I need to make sure it’s clear that this is not intended as a criticism of encryption of any kind, as attackers can (and do) use it against you. But, it is also a very powerful tool in your arsenal to ensure the integrity and, arguably more importantly, the confidentiality of your data. Another thing to think about is that just because encrypted traffic over port 443 is an easy way to mask illicit activities now doesn’t mean there aren’t hundreds of other potential channels available.


So, if all organizations began carefully inspecting every single encrypted packet that they could, attackers would still find a way to get their traffic onto, and data off of, that network in some manner that is virtually undetectable. This does not mean that the inspection of encrypted, or SSL/TLS packets won’t help though. You need to discuss and understand the implications of this type of monitoring. It is necessary to have the right resources and that those assets can be dedicated to this task. The primary assets required to pull this off are hardware ($$) and personnel ($$$$). If your organization can afford the resources it takes to monitor the encrypted traffic on your network, then you should begin the process of implementation.

In conclusion, attackers will continue to use SSL/TLS encryption to bypass automated controls just like they will keep using direct to memory malware techniques to inject malware (look for this topic in my next blog post). But, if your organization has a relatively mature information security program, this is a good next step (another layer of security) to consider.