How To Recon Like An Attacker

With the rise of cloud computing, containerization and serverless computing, maintaining a perfect inventory of your external assets and ensuring they are patched has become an overwhelming challenge. The world simply moves too fast. Instead, many organizations are flipping their perspective and attempting to identify the elements of their attack surface most likely to be targeted by an adversary. Doing so, however, requires organizations to be able to think like an adversary.

This e-book walks through the tactics and approaches developed by the Randori Attack Team from decades of offensive operations that are employed by Randori Recon to identify an organization’s most tempting software targets. After reading this e-book, you should have the knowledge and insight required to conduct recon like an attacker and analyze your own attack surface as if you were an adversary.

The Six Factors Hackers Consider When Targeting An Asset:

1. Enumerability: The Precision of Detection: The more information enumerated about a particular service, the higher the confidence level of an adversary on the success of their attack. Enumerability is all about “peeking from the outside”: depending on the service and its deployment, a webserver target could show anything from “Apache Unknown” to “Apache 2.4.33,” or perhaps no server information could be discerned at all. Much of this is configurable and is an easy way organizations can increase the entry cost to an attacker. If an adversary can understand the exact version of the service and glean insights into its configuration, they can be precise with the exploits they use and attacks they run, maximizing their odds of success while reducing the risk a capability is caught and blown. 
2. Weakness: Known Disclosures and Exploits: When evaluating a target for weakness, ask yourself: Does this target have known vulnerabilities? Are those vulnerabilities severe? Are there known PoCs, exploits or Metasploit modules for vulnerable systems? If the answer is not obviously yes to at least two of those questions, it’s likely a low priority on the weakness scale. The vast majority (>90%) of vulnerabilities are never exploited in the wild. 
3. Criticality - Importance of Function: From the outside, an adversary doesn’t know the importance or use of any particular device with certainty. What may be of obvious value to you as an internal staffer may be entirely disinteresting to an outside observer and vice versa. As an adversary, you have to assume that a device is used for its intended purpose and make judgements off this assumption. From this perspective, services that define a critical security boundary are of the highest interest.
4. Applicability - Level of Adoption: Adversaries have limited resources — even nation states — and need to prioritize their focus and development of capabilities on platforms likely to be useful across multiple engagements. When assessing an asset - ask yourself: How many similar services are exposed on the internet? Is this a commonly used service by others in my industry? How likely is it that targets at other organizations are similarly configured? Sources such as Shodan, Zerodium and install base statistics are great resources to reference when assessing applicability. For example, common services such as the latest versions of Exim SMTPd, Nginx and Apache would rank high due to their broad prevalence. Whereas an EOL version of a regional or industry-specific ERP solution with only a few dozen examples online would rank low. 
5. Post-Exploitation Potential - Usefulness After Compromise: Post-exploitation potential is the usefulness of the device to an adversary after compromise. In short, is it a welcoming and hospitable environment on which to persist. At Randori, this is the category that most often catches folks by surprise and can be the hardest for long-time blue teamers to assess well, as it requires detailed knowledge of the target and a firm grasp on what is or is not useful to an adversary after compromise.
6. Research Potential - Ease of Development: Research potential assesses the ease by which an adversary could develop capabilities for a particular service or platform. Time is expensive and barriers to entry can limit the ability and incentive for adversaries to develop capabilities against particular targets. While security through obscurity should be avoided, when it comes to vulnerability research it can be a real deterrent for low-skill or low-resourced adversaries.