Social engineering is an effective tool in any penetration testers utility belt, it almost always provides a way into an organization...that first essential foothold. For those providing social engineering testing services though, providing and proving value can be a little tricky. Social engineering as a testing tactic can usually be broken down in two ways:
- Opportunistic (point-in-time) social engineering
- Role-based social engineering
Opportunistic attacks are what's most frequently discussed throughout our industry; identifying a potentially vulnerable individual at a target company, performing reconnaissance, crafting an attack scenario, and launching the attack. Whether it's a phishing email, phone call, or by some other means, we then declare victory when that individual falls for our trickery. This approach, while useful in the context of testing, moving one step closer to our goal, doesn't really give us the opportunity to identify systemic flaws. That is, those variables that are actually allowing people to fall victim to these attacks. It really only tells us that people are often gullible and vulnerable...but we knew that already, so what are we really gaining?
Alternatively, role-based social engineering is an approach that evaluates the role that a person supports within a business, such as resetting a password. Ultimately, what we're hoping to identify with this approach is weak or missing controls that leave the human supporting the process susceptible to social engineering techniques. People in such processes are left to make critical decisions at the right time between potentially conflicting goals like security and supporting the business in another way, such as helping a customer fix their problem. Why is it that people are put in these kinds of positions in the first place? With better process design, people supporting critical business processes can be protected from themselves, removing the susceptibility of decision making at critical breakpoints. Let me illustrate with an example.
A web service allows users to reset their passwords if they forgot it or happened to get locked out by some other means. Users can reset their passwords using the web interface or by calling the help desk and answering a few security questions if they choose. If the user chooses to go through the web application then the process may resemble something like this:
Now, if a legitimate user also lost access to their email address, or for whatever other reason wanted to reset their password through the help desk then this example flow may resemble the following process:
In the help desk flow there are a few decision points that may facilitate the customer service representative (CSR) being social engineered by a malicious caller. The first thing to note in our example scenario above is that a CSR can read security question answers from their screen, so if an attacker were to provide answers that were "close enough" to the real answer, then a CSR may accept it as correct. This "close enough" approach likely also means that the CSR can simply accept an answer as the truth if they are either deceived or potentially malicious themselves. If a CSR were forced to type the answer to the security answer to proceed then this type of attack would not be possible. Additionally, an attacker can iterate through multiple security questions in an attempt to reset a target's password. Through casual conversation, this could occur without an increment on the number of incorrect guesses tied to a target account as it might in the web-based workflow.
This is a very basic example of social engineering a role within an organization versus a specific person and how weak controls in the process may allow any individual supporting that role to be a victim to social engineering attacks. Instead of picking on people, let's instead pick on poorly designed processes. Let's direct our resources towards fixing the core problem that enables our people to be susceptible to such attacks.