Social engineering attacks hit organizations constantly. In 2018, not only did an average of 83% of organizations see a phishing attempt, there was an increase in credential theft related to phishing attacks of more than 70%. So it’s no surprise that many organizations are trying to figure out how susceptible they are to this kind of attack and figure out some approaches for how to fix it. Well that’s where a Social Engineering Assessment comes in. And as with any form of active penetration testing or adversary simulation, there are some risks and things that can go wrong during a social engineering engagement. Let’s look at a few scenarios:
During a social engineering assessment, the attack team is trying to take advantage of the human element of an organization, its employees. In the process, those employees that do fall victim may experience “buyer’s remorse” (e.g. “Oh I shouldn’t have done that…”) and embarrassment about being the weak link. That’s all part of the process though, and the users that are compromised during the assessment generally show a much bigger improvement in their behavior. The whole point of a social engineering engagement is to find these weaknesses throughout the organization and then fix the root cause or improve the surrounding controls, like awareness training.
To help address the risk here and prevent any public shaming from happening, we always anonymize screenshots that are included in the report. Not only do we want to avoid disclosing sensitive information in those screenshots, we don’t want to personally call someone out because that’s not the point of the assessment. We’re using sophisticated attacks, so it’s not entirely fair to put the blame on a particular individual. It’s more important to identify areas of weakness and bolster training for the organization as a whole (for example), because this week it may have been Bob but next week it could just as easily be Alice.
Sometimes after a social engineering assessment, management doesn’t know how to respond. That’s not entirely surprising, as this type of assessment can make a fairly secure organization seem weak and unprepared. You could have the information security budget of a king with all the blinky boxes you thought you needed, but Bob clicking on that link in a phishing email and opening that macro-enabled Word document just bypassed all that. Unfortunately, one of the responses we’ve seen in these scenarios is to ask for a list of who fell for the social engineering attempts and then proceed to issue reprimands, or sometimes worse, actually fire these employees.
This should never be the answer when reviewing the results of a social engineering assessment, as it is ultimately managements responsibility to prepare their employees and utilize compensating controls to help protect from these types of threats. The organization’s that get mad about something like this are probably the same organizations that aren’t putting as much effort into preventing these types of attacks as they could and should. So while we can’t prevent this from happening, we don’t provide a list of specific employees that were compromised unless it is explicitly requested. And further, none of our recommendations are ever to reprimand individuals or fire them, but rather to increase security awareness, improve training quality, and consider technical controls that may help improve detection.
The third and final problem I want to discuss when it comes to things that can go wrong during a social engineering engagement, is the potential for out-of-scope compromises. Now this may not make sense yet, but try and follow me. When we’re sending out phishing emails with malicious Word documents attached, we have no control over what host those end up on. Obviously we’re targeting corporate users and corporate email accounts, but a lot of organizations allow email access from other devices (Office 365). And many employees that get a potential job offer from a fake recruiter are going to forward that email to a personal email address anyway. So when that backdoor is detonated and we get a remote shell from a system, it may be a personal computer or another organization’s asset.
Now we want to avoid this scenario if at all possible. Even though we’re the good guys and not a real threat actor, we don’t want to exploit out-of-scope systems in any capacity. So there are a couple of things we do during an assessment to help prevent this. When we get a remote connection from a potentially exploited user, the first thing we do before interacting with the session is check the callback IP address. If possible, we’ll tie this to open-source intelligence or information we’ve received from the customer about IP ranges they own and NAT outbound traffic to. The second thing we’ll do to help confirm the legitimacy of a target is to check the network address, host name, and current user. Since these are the first commands we run when we start remotely interacting with a system, it allows the attack team to confirm the correct system was exploited and it belongs to our target company before going any further.
Is that all?
These may not seem to bad, as far as bad things go. And you’re not wrong, there is very little risk of downtime, business disruption, or any negative consequence from a network level. One of the other things to consider is time/resource loss from people that get phished, just in the sense that it takes time to interact with the attack team and if they catch on and decide to report it, that’s time out of their work day. Additionally, depending on if your IT team is in on the assessment, it could result in time wasted on their end responding to an incident or trying to perform forensic analysis when it’s just a test scenario.
So while there are some things that could go wrong during a social engineering assessment, there are a lot of things we do to ease those repercussions on our side and some things you can do to help prepare yourself, as well. If you want more information on what all is involved with this type of assessment, check out our Social Engineering Methodology for a more step-by-step walk-through of the process.