Nov 11, 2020
Hackers Aren’t Magicians, They Just Know the Right Questions to Ask
Attackers have a checklist for evaluating a new target, and pro-tip: it doesn’t only have to do with the highest severity vulnerabilities
This is part two of a series on hacker logic — deciding what to exploit. If you’re interested in how a hacker does recon on a company, particularly through social engineering, read part one on reconnaissance.
Even medium-sized companies these days do so much diversified work in the cloud that their attack surface is absolutely massive, making it nearly impossible for them to know where to focus their time or energy. But the good news is that adversaries don’t have time to look at every asset in depth either — the number of assets can often run in the tens of thousands for a large enterprise. Just as there are demands on security teams, adversaries have constraints as well. Their time has a cost, they must operate within limited budgets, and their technical capabilities have an upper bound — they are not magicians.
All of these constraints can work to your advantage as a defender if you can understand them and optimize your defenses to raise the cost to an adversary. This is where flipping your perspective to not only identify what’s exposed, but also what’s most likely to be targeted by an attacker, will dramatically improve the efficiency of your team, reduce overall risk, and ensure you’re always focused on the highest value targets first.
Many assume attackers exploit flaws in software that are rated the highest “severity” on the CVSS scale. But that’s simply not true. Severity is just one of many attributes weighed by an attacker. As a red-teamer hired by many Fortune 500 to hack into their organizations, and as the CTO of Randori, there are six attributes I factor together to determine what to go after (and perhaps weaponize): enumerability, weakness, criticality, applicability, post-exploitation potential, and research potential. The combination of these factors is what I call Target Temptation.
Before an attacker strikes, he’ll weigh each of these factors to determine what to go after first. And I’d argue, if you apply this logic to your own environment, your security strategy will shift, leading you to more efficiencies and lower risk.
Enumerability: How well can I tell what this is?
Probably the most straightforward factor is simply how much a hacker knows about a software from the outside. The more information available, the more confidence they will be there attack will be successful. Enumerability is all about “peeking from the outside.” Imagine doing a stakeout on an office building with big clean windows versus one with small tinted windows. The more of a view you have inside, the more confident you are in your ability to see your task through.
Depending on the service and its deployment, a webserver target could report anything from no server identifier at all, to the server name alone — “Apache” to “Apache 2.4.33,” or even more detailed values. Much of this is configurable and is an easy way organizations can increase the cost or risk to an attacker. If I can understand the exact version of the service and glean insights into its configuration, I can be precise with the exploits I use and attacks I run, maximizing my odds of success while reducing the risk a capability is detected and cover blown.
Weakness: Is the asset known to have a flaw and therefore exploitable?
This is the category people ask about the most, as patching vulnerabilities is the primary focus of many security teams today. While “weakness” considers vulnerability weighting criteria (how severe the vuln is), it also considers what’s required next for the attacker. Don’t assume simply because the CVE or CVSS score is high that it’s of great interest to an attacker — this is a common misconception.
Weakness also takes into account the availability and cost of existing exploits in nonpublic circles. Think Canvas or Zerodium. Often overlooked and depending on a company’s threat profile, it’s likely I’ll use private capabilities (e.g., previously built exploits) in an attack. It happens far more often than many realize.
Criticality: How important is the asset to the business?
Criticality is all about the assumed value of the asset in question. Assets that appear to be a security appliance (VPN, firewall, etc.) are of the highest interest to me — if I can break the security function, I’ve got the keys to the kingdom.
If there is a VPN, firewall, telephony servers, or remote support solutions on your perimeter, an attacker is likely to assume it’s protecting something of value and not just a bridge to nowhere. Compromising it not only provides access to the other side of the firewall, but may also result in an ability to collect or manipulate credentials that can be used to advance throughout an environment.
Ignoring the value of an asset to a business, could lead to a lot of dead ends or stealing ultimately valueless information after an attacker invested significant time and resources into the endeavor. Hackers definitely don’t want that, so worry less about exposed assets which are obviously not protecting something important.
Applicability: If I exploit now, can I reuse it? How useful is this beyond this instance?
Remember: You are not my only target. Attackers of any scope have limited resources — even governments — and they’ll often prioritize their focus and development of capabilities on platforms likely to be useful across multiple endeavors. For years, Apple devices were touted as being unhackable. But the reality was that since Microsoft controlled so much of the market share, creating exploit windows was far more valuable. Now that Apple controls more of the market share, attackers are finding iOS vulnerabilities far more appealing.
From this logic, I’m less likely to invest in vulnerability research for a product used by only a handful of organizations and is of little interest to their mission. However, there might be other reasons to go after the esoteric program on a target perimeter, such as criticality. I’ve had success exploiting home-grown applications, but at least in this category, it would be less of a priority since the investment is likely a one-time sunk cost.
Post-Exploitation Potential: How hospitable will the asset’s environment be to me, if I exploit it?
Post-exploitation potential is how likely I am to be able to do my work on an asset after I break into it. In short, is it a welcoming and hospitable environment in which to travel on through the system? As an adversary, an ideal scenario is to exploit and gain execution in a well-known environment where few defenses exist. I want my malware and pivoting tools to work, and I want nobody to be the wiser when they do.
Endpoints score low in this category. Sure, I’ve got tools that work on Windows, but they are closely monitored, have well-trained users, and are frequently protected by a slew of endpoint security products. VPNs, camera systems, and desktop phones make much more appealing targets. They are unprotected hardware devices which are physically plugged into the network all the time. Many forget a desktop phone is a complete computer with a full range of Linux capabilities, same with VPNs. Manufacturers designed these units to be appliances — they come pre-manufactured, so network administrators don’t install software on them. This makes them juicy, unguarded doorways with only one lock.
Beyond the UI lies a familiar execution environment, more often than not, with a complete userspace and familiar tools pre-installed. This gives these appliances a high post-exploitation potential and contributes to their attractiveness as targets. Other examples of systems that frequently catch security professionals by surprise are phone, VoIP, and print servers.
Research Potential: How long will it take to exploit? (or how hard is it to exploit?)
Research potential assesses how easy it is for me to develop capabilities for a particular asset in your environment. Time is money, and barriers to entry can limit the ability and incentive for adversaries to develop capabilities against particular services, tools, or platforms. While security through obscurity should be avoided, vulnerability research can be a significant deterrent for low-skill or low-resourced adversaries.
An expensive and esoteric platform, such as security appliances, or VOIP systems — anything that comes in a box — may be of high interest to an adversary due to the value of data stored and level of access required, but it calls for special skills and resources and therefore would be scored low on this specific metric. Quite often there are low-hanging fruit vulnerabilities in expensive appliances, but it’s tough to get your hands physically on these costly devices. Whereas a well-documented and open source tool that can easily be obtained and tested would score high on this metric for a broad range of adversaries.
The equation
There’s a bit of an equation that goes into deciding what I’ll go after on your attack surface or in your environment (assuming I’ve made it in). It’s not as simple as asking: “How critical is this CVE?”
I’d argue that while there’s not an exact list of attributes an adversary uses to determine what to exploit, the logic above is pretty universal amongst attackers. You can’t put defensive tooling on all your assets, but you can use the attacker’s perspective to inform what you prioritize to defend on your attack surface. You can also add protective layers around appealing assets that you are unable to instrument directly. Making it harder and more expensive for attackers to get what they came for means extra efforts around the things that matter most, and de-emphasizing some less important assets. It’s knowing the likelihood of what’s going to be attacked first, and determining what efforts can be saved for later. You need to know what to patch, and when to avoid emergency downtime to fix something no one’s likely to attack.
