In my previous post, I discussed the first three steps of four showing how a typical trust-based attack can be broken up into the following: 1) theft of the key, 2) use of the key, 3) exfiltration of data, and 4) expansion of its foothold on the network. This post focuses on step 4 while outlining some examples of the actions trust-based attacks perform and how bad actors use keys and certificates to maintain their foothold in the enterprise network.
When reviewing the security architecture for any enterprise network, the majority of the time you will hear security architects talk about defense-in-depth strategies. This equates to the layering of multiple best-of-breed security solutions to stop an attacker from getting in to the network and data leaking out of the network. But what happens when every security solution deployed as part of the enterprise security strategy can be bypassed? This is exactly the case when it comes to trust-based attacks. Security solutions are inherently designed to trust keys and certificates as part of the security stack.
The result is catastrophic. Organizations that invest millions of dollars and hundreds of man-hours in security solutions are constantly being breached because their security controls are undermined as a result of inadequate key and certificate security—they have no visibility into the use of their keys and certificates or ability to respond to an attack. Using these keys and certificates, attackers are able to bypass the organizations’ other security controls unnoticed due to the trusted status granted.
In step 4 of a typical trust-based attack, bad actors will use the stolen keys and certificates to maintain and strengthen their foothold on the network. As part of this process, the malware that was installed in step 3 is used to steal additional credentials, including keys and certificates. Common examples like Mask Operation and Crouching Yeti were successful for up to 7 years, showing just how long APT operators can go undetected.
Once inside the corporate network the name of the game is remain undetected for as long as possible. For cybercriminals, the use of encryption and keys and certificates provides the perfect cover. At the same time, it’s important for cybercriminals to collect additional keys and certificates to be used for future access and malicious campaigns while maintaining privileged access.
A good example of a massive security hole in most organizations is SSH. Forrester research identified almost three-quarters (73%) of organizations hardly ever rotate SSH keys. Public key authentication is one of the more popular authentication deployments of SSH. Unfortunately, it also requires adequate security of the private key. However, more than 50% of organizations don’t even know how many keys and certificates are in use in the network and have no security controls for these keys and certificates.
When authenticating via SSH, privileged identity management (PIM) solutions are bypassed. This is by no means an impediment of PIM solutions: it’s the design of SSH. The majority of security solutions have no visibility into the use of SSH and other keys and certificates on the network. It’s no wonder cybercriminals are taking advantage of them at an ever increasing rate, undermining current security controls.
Keys and certificates are critical for secure communication across the Internet, but when a security method is used for malice, something needs to be done about it. Enterprises need to start by knowing where all of the keys and certificates are on the network, how they are used on the network, who has access to them, and how they are configured. Organizations can get direction from security standards, like SANS 20, that provide very specific guidance on key and certificate security. These standards show promise in their recognition that trust-based attacks need to stopped.