Creating Targeted Scenarios
Gavin Watson, Senior Security Engineer, RandomStorm Limited
Once the objectives have been agreed with the client, the next stage is to design scenarios to meet those objectives. This chapter provides a series of models that testers can use to create effective scenarios that not only meet objectives but also identify multiple vulnerabilities rather than concentrating on a single security flaw. The ultimate purpose of these models is to ensure that assessments provide value to the client and lead to improvements in their security.
Keywords
Social engineering scenarios; target identification; target profiling; physical reconnaissance; pretext design mapping; cover stories; exit strategies
Information in this chapter
Introduction
Chapter 6 discussed the benefits and challenges associated with the threat modeling stage of the social engineering assessment. This critical stage identifies the most significant security threats, ensuring value for the client by focusing the assessment on the right areas.
In order to test each of the identified threats, the security consultants will design and execute social engineering scenarios. These scenarios consist of multiple components that will be covered in the first section of this chapter. Each component is purposefully selected so that each scenario is tailored to identify specific vulnerabilities and meet clear objectives.
A fundamental component of any scenario is a target, sometimes referred to as a mark. In terms of social engineering, this is almost always a human being. A target identification model used by the authors to document their decision-making process will be discussed. Additionally, this model can also be used by beginners to aid in the design of scenarios. This provides a clear and easy process to follow.
Once a clear objective and target have been identified, the next stage would be to design a pretext (or plausible situation) to meet that objective, and to identify specific vulnerabilities. The “pretext design mapping” approach can be used to aid and document the thought process behind the design of the scenarios.
Scenarios are not always designed to succeed as failed scenarios can often identify unique security issues. Designing scenarios to fail will be covered, along with planning for unexpected events and having an exit strategy prepared.
The components of a scenario
By this point in the assessment the security firm should have a good idea of the significant threats their client faces. Therefore it is now time to design scenarios that assess the business’s susceptibility to those threats, identify multiple vulnerabilities and ultimately improve the client’s overall security.
Each scenario has multiple components and each must be clearly defined to aid both the testing company and the client themselves (if only in terms of documentation). To explain each component in context, we will use one of the common short game attack scenarios presented in Chapter 4.
• Threat
The client is concerned that their call center, consisting mainly of undertrained students, is susceptible to basic social engineering attacks. If an attacker gained access to a highly privileged employee’s email account it could result in serious, possibly unrecoverable, damage to the business reputation. As there are literally hundreds of call center employees, the security risk could be very significant indeed.
• Objective
The objective should be clear from the start and be directly associated with one of the client’s threats. In this case, the objective is very simple:
Gain access to the email account of a highly privileged user.
There are of course smaller objectives to complete first, such as reconnaissance and target identification, but this is the main overall objective for the scenario.
• Target
The next section of this chapter will discuss a formal approach to target identification. However, for the purpose of this example we will assume this has already been performed.
The following employees have been identified as suitable targets for the scenario.
• A. Smith, B. Smith, C. Smith
There may be multiple groups of targets, each associated with a specific scenario, so it is important to clearly define them at this point.
• Attack Vector
In this example our attack is going to be conducted over the telephone, as per the client’s specifications. It is important to define this here as the same scenario could theoretically be performed via email.
• Pretext (plausible situation and character)
The pretext chosen should be one among many that could achieve the same objective. The following sections of this chapter will cover formal approaches to generating pretexts. However, for the purposes of this example the pretext of the short game attack scenario will be used, as previously described. Therefore, the character and plausible situation would be as follows:
The chief executive (character) is in a meeting with important clients and would like the password reset as his current email account password no longer works.
• Primary techniques
The primary technique used in this example is impersonation, as the target will need to believe the caller to be the chief executive. Strictly speaking, pretexting is also a primary technique used in this scenario, but as a pretext will form the basis for the vast majority of social engineering scenarios it is usually not necessary to define it.
• Secondary/supporting techniques
The secondary techniques can be used to identify additional vulnerabilities and/or increase the chances of success (should increased success be beneficial). In this example the tester may use “pressure and solution” to attempt to manipulate the target more effectively. The “pressure” could be that the chief executive is in a meeting and they’re not happy about the situation, the “solution” would be to quickly reset the password. If this supporting technique was to be used then the pretext would be as follows:
The chief executive is in a meeting with very important clients and is annoyed that his password isn’t working. They would like it reset promptly or else there may be consequences for the help desk employee to deal with.
• Vulnerability identification
The vulnerabilities identified map directly to the primary and supporting techniques used in the scenario. For example:
primary technique−basic impersonation=vulnerabilities in the caller identification procedures
secondary technique−pressure and solution=weaknesses in the awareness and training program
• Business exposure
The business exposure is the potential damage caused should the threat agent be successful in exploiting a vulnerability, i.e. the damage caused should a social engineer successfully gain access to the employee’s email account and publish the contents online. It is important to clearly define the exposure and present it as the worst-case scenario. A successful attack and a defined exposure can at the very least provide a great deal of leverage when securing budget for improvements to security.
• Rules of engagement
This component is often discussed with the client before any scenarios are designed. The initial briefing will define clear rules of engagement, such as no lock picking, no damage to company property, no disruption to business activities and strictly no access to certain areas. However, rules at this stage mean that multiple scenarios can be designed with varying rules to identify different issues. For example, a client may decide that they would not like any lock-picking activities as it could damage the locks, which are expensive to replace. However, one or two scenarios could involve lock picking providing they are confined to certain areas of the building. The testers could then perform scenarios with and without lock picking and present the results to the client, which could be very surprising and valuable. Therefore, defining rules of engagement as a component of individual scenarios is important.
• Resources
Certain scenarios can be performed with a single engineer, others require more than one. In some cases multiple engineers can supplement scenarios in supporting roles, increasing the chances of success. Therefore, the resources available to perform the specific scenario are an important component to include. For example, there may be a single scenario with two variants, one with a single engineer and one with two engineers. The difference in the results between the two scenarios could be significant.
• Environmental factors
These are factors outside of an organisation’s control that could impact the scenario in one way or another. For example, if it was raining then the social engineer would look pretty odd lurking outside. If it is foggy then security cameras will be affected. If it is hot weather windows and doors may be left open. Therefore, it is important to include these details as part of the scenario as they may need to be repeated when environmental factors are not a complication.
Target identification
Social engineers will often perform target identification in their head, possibly even switching between targets as they play out their complex scenarios. As professional security consultants, this kind of freestyle scenario execution is not always a viable option. This is not to say that consultants shouldn’t take advantage of opportunities should they present themselves during an assessment, it is just important to maintain a clear structure. Presenting convoluted and sporadic results to clients is rarely beneficial in the attempts to improve security. It is important to try and keep scenarios clear and consistent so they identify the issues they were designed to. Additionally, documentation of the process is crucial to help the client understand the issues identified and also as a reference should additional testing take place at a later date. Finally, for a company branching out into social engineering assessments, this formal approach can help to keep the whole process clear and manageable.
Formal target identification is a structured process of elimination resulting in just a few targets that are deemed as the most suitable (for the objective). Figure 7.1 shows a basic generic target identification triangle that could be used for many different situations. When attacking a business, every single employee is a potential target as well as everyone directly and indirectly connected with that business. Therefore, the starting point in this process is to build the foundations of the triangle with those targets. The amount of targets will reduce, as they are “promoted” to a higher layer based on certain criteria. The individual layers of criteria in Figure 7.1 are quite general so that they can be applied to different objectives.
To explain this process fully, we will choose a simple objective:
Open-source reconnaissance
The example provided shows how the foundations of our triangle have been populated, with all the employees of company xyz being Targets A through H. A real company would of course likely have many more employees but eight is enough to demonstrate this process.
In order for a target to be promoted to the next layer up, they have to pass a series of fundamental criteria. At the first layer, the criteria are based on open-source intelligence or initial reconnaissance. As the first step of an attack is researching the target or targets then this makes perfect sense. It is possible to eliminate a large number of potential targets based solely on information you have gathered remotely and based on the overall objective of the attack.
• Seniority in company
Choosing a target with higher privileges than the rest can often be advantageous. However, if the objective requires targeting vulnerable new starters then the opposite is true.
• Good digital footprint
If there is limited information on a target then there’s not much to base any decisions on. In response, a decision could be made to design attacks that gain this information, but there would need to be a good reason for doing so as that could take time that you may not necessarily have. However, if the target is the CEO and the research has revealed very little information about them, then attacks designed to obtain this information could be justified.
• Within target department
Although any employee could theoretically provide a valid pass, it is usually the reception that provides them, therefore it makes sense to promote targets in the right department.
In the example, Targets A and H did not meet any of the criteria and so they were eliminated. This results in Targets B through G being promoted to the next layer of the triangle. However, when eliminating targets, it need not be black and white. The targets that are promoted could just have met more of the criteria than the rest, or the eliminated targets could have not met “some” of the criteria. Ultimately it is up to the consultant to decide on how to promote and eliminate the targets.
In this example, three criteria have been used to make the decisions. In a real world assessment there will be many more depending on the complexity of the objective, the business and amount of employees in scope.
Target profiling
The next layer of the triangle is focused on target profiling. Previous criteria included having a good digital footprint; there should be enough information on each target to make decisions. At this point, decisions are being made based upon the individual characteristics of the target. Obviously these characteristics do not guarantee success; the idea is simply to increase the chances of success based on generalizations. For example, a phishing email attack would probably have more success targeting the elderly than it would the younger generation. The key term here is “probably.”
• Age
As mentioned above, certain attacks would be more successful depending on the age of the target. However, although the tendency is to pick on the elderly, as they are less likely to be computer literate, be very careful that precious time is not wasted. If the objective was to manipulate a target into revealing information, then it may be a better decision to choose a younger new starter rather than a hardened ex-military target in their 60s. It is important to think carefully about the objective and how the criteria should affect any decision to promote or eliminate the target.
• Gender
These criteria are not here because the authors believe one gender to be more susceptible than the other to social engineering. It is here because the scenario or objective could be gender specific. For example, the client may suspect that their male dominated call center personnel are not following the proper procedures when a young girl calls them to have their password reset. Therefore, to keep to the client specifications it would be good idea to eliminate female targets. Of course it could be suggested that an alternative scenario using a male voice and targeting a female employee could reveal interesting results.
• Interests
If the research has revealed a target to have a lot of interests then this information could be used against them.
In the example objective, age and gender are relatively irrelevant, therefore Targets B and G were eliminated based on them having less useable interests than the others.
Physical reconnaissance
The third layer of the triangle moves away from remote reconnaissance and focuses on the targets and how they relate to the objective.
• Patterns of behavior
These criteria could mean very different things depending on the objective. For example, if the aim is to call a target individual when they are at the office, then it would be a good idea to learn what hours they work. Similarly if the aim is to engage a target with information elicitation then it would be a good idea to learn where they go for lunch or when they step outside for a cigarette. Furthermore, these criteria could be far more fundamental such as a target not actually being available during the whole testing window.
• Physical covert engagement
In a similar way to patterns of behavior, targets can be promoted or eliminated based on whether or not they can actually be engaged with. Physical covert engagement can mean taking photographs or recording the target for the purposes of information gathering. Therefore, if good photographs and recordings of certain targets can be obtained there is an increased reason to promote them over others. This level of engagement is not usually necessary for the majority of social engineering assessments, it is included here simply to demonstrate the process thoroughly. A real world attack may well involve this layer of target identification, especially if it is spread over months.
• Associates engagement
Through convert engagement it should become clear who is associated with the target. Their close friends and work colleagues could become additional avenues through which to attack the primary target. For example, a close colleague could be used as part of a social proof supportive technique. Likewise, if it becomes apparent that two colleagues work closely together, then it would be a good idea to avoid attacking one by impersonating the other (such as over the telephone), as they will likely recognise an impostor.
In the example, Targets C and F will not be available during the testing window. This information could be leveraged as they could be impersonated if they are away. However, they are not suitable targets for the given scenario.
Target engagement
The final layer reveals the best possible targets for an attack based on all the information gathered. There are no longer any decisions to be made regarding elimination or promotion within the triangle. Working up to the top of the triangle has identified Targets D and E, who are both receptionists, as the most beneficial targets. Remember that a real world scenario would have many initial targets, so there may be far more than just two at the top of the triangle.
• Prioritize targets
There will be differences between the final targets in terms of overall suitability. For example, one may have met slightly more criteria than the other, therefore, it is a good idea to prioritize the targets and concentrate on the most promising ones first.
• Scenario creation
Now that the target or targets have been identified, it is time to design a suitable social engineering scenario. The objective and target can be used as a basis for “pretext design mapping”, which is a process explained in the next section.
• Overt engagement
This is the final stage of the interaction with the target: the actual execution of the social engineering scenario.
Remember that it is very possible to arrive at this stage and then realize that a final target is in fact unsuitable after all. Or after executing the scenarios you are then in a position to attack further targets. In these cases, the focus is on the next layer down in the triangle, revisiting the targets previously eliminated. By following this process, the right people are targeted in the right sequence, using the allotted time as effectively as possible.
Pretext design mapping
The target identification process described in the previous section revealed two suitable targets: Targets D and E. The process can now continue to the pretext design mapping stage using Target D and the objective of obtaining a valid access pass.
Figure 7.2 shows an example pretext design map for our objective. The map begins with the objective and the chosen target. At this initial stage, it is very possible to have more than one target and continue the tree for each, but the example will be kept as simple as possible.
The tree branches off at the “Who” stage answering the question of who is associated with the target and objective. In our example, the question is “Who would a receptionist give a valid access card to?”. This creates two obvious branches being “Contractors” and “Employees” as a receptionist would certainly give out passes to these groups. These are just two possibilities for the sake of the example as there will be more groups that could be listed here, such as visitors.
The next branch answers the question of “why” or “how”, such as “Why would a receptionist give out a valid pass to a contractor or employee?”. For example, an employee may have forgotten to bring in their pass and so requires a temporary one for today. Or the pass may be given out to a contractor that performs routine maintenance. This can be seen as the first branch in our tree. There are numerous reasons why passes would be given out and as many as can be thought of should be listed here. This forms the basis for the pretext and helps mind map all the various possibilities. By splitting these into distinct groups it is easier to generate possibilities rather than trying to pick something random out of thin air.
Once possibilities have been added to the “how/why” section, then the process of beginning to create pretexts starts. The idea is to continue on from the “how/why” section and incorporate the reconnaissance information to flesh out the details. For example, the first pretext on the tree is based on impersonating an employee that has forgotten their pass. The reconnaissance may have revealed that a certain employee will not be in the office during the testing window and that they have just started, making it less likely that the receptionist staff will know them well. Similarly, regarding the possibility of a contractor performing routine maintenance, the reconnaissance may have revealed details of a third party that visits every week.
The second pretext down is based on impersonating an employee from another branch and trying to obtain a temporary pass. The reconnaissance may have revealed details of another branch and the necessary imagery to create a fake ID badge. Therefore, this pretext is certainly a possibility. Obviously, the more research that is conducted, the easier it will be to create pretexts.
Having established a pretext, the next stage is to clarify what techniques will be used. This is a critical stage to ensure value for the customer by being thorough and effective. The tree branches off to list alternative techniques that could be used during the same pretext. For example, the first pretext involving a forgotten pass could be attempted two ways. The consultant could simply impersonate an employee and ask for a badge, or they could first send a fake authorization email to reception before arriving. Again, these are just two of many different techniques that could be listed here. Both of these approaches come with an element of risk, which are listed next to the technique. In the diagram, just impersonating is classed as a high risk whereas impersonating with an email authorization is classed as a medium risk. The reason for this is that an email provides credibility (even if it isn’t in line with the standard procedures) and so should be slightly less risky. There are no scales for the assignment of risk, it is purely qualitative and ultimately the decision of the consultant.
The techniques and attack vectors used in a pretext will result in the identification of different vulnerabilities if the objective is successfully achieved. In our example, just impersonating will identify issues with reception specific awareness training and pass replacement procedures. However, if the other approach is taken, using an email authorization letter, it also identifies issues with email specific awareness training. At first it would appear that the second approach would be more beneficial, but it isn’t always as simple as that. If the second approach is taken, more vulnerabilities are indeed identified, but taking the first approach will mean the vulnerabilities are more significant (because the consultant didn’t need any additional credibility to obtain a pass, they just asked for it).
According to the tree, another possibility is that a receptionist would give an access pass to a contractor if an employee was to arrange one. A possible technique would be impersonation via telephone or email. Remember that these are only two of many possibilities. Here, the two different attack vectors result in the identification of different vulnerabilities. The telephone attack vector would identify issues with telephone caller validation procedures, whereas the email attack vector would identify issues with email specific awareness and training material. In addition, as these are both remote attack vectors the risk is relatively low.
When the risk levels and identified vulnerabilities are presented in this way, we can begin to make some good decisions about what pretexts to use in the assessment. For example, it would be beneficial to use lower risk pretexts at the beginning of an assessment and higher risk pretexts towards the end. Similarly, as we can see which vulnerabilities are identified with each pretext, we can select the pretexts that would identify a good cross-section of different vulnerabilities. If time weren’t an issue then of course as many pretexts as possible could be attempted. However, in most social engineering assessments they’ll likely be a very limited amount of time.
Planning for the unknown
There are professional social engineers with a true “gift of the gab” that can talk their way into and out of any situation a test may thrown at them. However, it is not particularly helpful to point this fact out when attempting to provide advice for companies wanting to branch out into social engineering. If they have natural talent for it then they’ll certainly find it easier, but that doesn’t mean that they can’t perform a solid social engineering assessment if they’re not significantly extroverted. The fact is that practice makes perfect; if someone keeps at it they’ll eventually perform techniques naturally and with minimal effort. Following the advice in the book, keeping the assessment structured and effective will be far more beneficial to the client than trying to be confident, outspoken, silver-tongued devil.
For consultants that are not very confident in target engagements, the idea of planning for the unknown can be very appealing. However, the idea of having all the answers ready and prepared is of course farcical, as they can’t possibly plan for every possible outcome to a scenario. If a security guard suddenly approaches claiming to be doing a random employee pass check, was this planned for? Probably not, but at least the client will get a green tick in the report. If it is so very difficult to plan for the unknown then is there any point considering the various possible outcomes? The answer is of course: it depends. If a spear phishing email attack is being planned, then possible outcomes present themselves through email replies, therefore there will probably be plenty of time to decide on an appropriate response. If it is executing a scenario designed to trick a specific receptionist, then potentially anything could happen, and there may be very little time to think of an appropriate response. For example, just as the consultant walks into the reception, the receptionists could unexpectedly change, rendering the specific target profile inspired attack useless. A highly experienced consultant could potentially shift to an alternative approach immediately. However, a new social engineer could panic and may end up not knowing what to do and risk being exposed. Unfortunately, they can’t really stand there considering what the best way to proceed would be, at the very least this may raise suspicions. Considering some possible events in advance can help to avoid situations like this. There are a few approaches to this explained in the following sections.
Scenario specific outcomes
Once the targets have been identified and scenarios designed, it can be helpful to extend the pretext design mapping tree to include probable outcomes. These outcomes can then be considered and appropriate responses planned. Each scenario should have obvious possible outcomes that need to be included. For example, let’s consider one of the most cliched scenarios in social engineering: the delivery driver. The idea is to gain access to the building by posing as a delivery person. This scenario is fairly absurd, which becomes apparent when you consider the likely outcomes.
• The receptionist asks for the package to be dropped in reception
How many businesses realistically let a delivery person onto the premises to give the package directly to the recipient? Some perhaps, but if that is the case the business is no way near the point of needing a social engineering assessment, they need to start with security basics first. This outcome is by far the most likely and therefore the attack will be cut short, with the consultant being forced to leave the building, having accomplished very little.
• You’re not our usual delivery person?
Even if a convincing fake uniform and credentials have been created, chances are the employees will notice that it is not the usual delivery person. When they sign the sheet, has that been replicated perfectly? If the delivery person normally uses an electronic device to record signatures, is this something that the consultant possesses? What about the van, does that look right? If they suspect something is not right they may push to prove the identity, which could be challenging, especially if there has been little time to prepare. As this outcome is likely, they’d best have a very convincing cover story and exit strategy if they are going to attempt it.
• The real delivery person has just been or arrives at the same time
A rather embarrassing but very possible outcome is that the real delivery person has unexpectedly been or arrives just as the consultant does. This could happen despite thorough reconnaissance; they may have been early or late for reasons that couldn’t possibly have been planned for. If this does happen, suspicions will be raised very quickly and a very tricky situation indeed will ensue.
• The receptionist lets the consultant through
This is indeed a “possibility” but when considering the various other outcomes this really is the least likely.
A very common mistake is to base all of the planning on the presumption that the scenario will succeed: being fully prepared for entering the building, heading to the target department, achieving the objective and leaving without incident. However, if consideration for other basic initial outcomes has been neglected, then the whole attack can be jeopardized.
The above example of a delivery driver shows that considering basic outcomes can result in a decision to not attempt the attack. However, in the majority of cases, considering outcomes is more about increasing the chances of success and reducing the chances of failures causing significant issues.
Cover stories
Strictly speaking, a cover story should have been established once a pretext is designed. In many ways, developing a cover story is little more than fleshing out the pretext to fill in the finer details that may be brought into question. There should be a very clear idea of exactly why the consultant is there and why they are calling or sending the email. However, a cover story isn’t just necessary in case they get questioned by suspicious employees, it is also there to ensure that common and innocuous questions don’t end up raising suspicion.
• Harmless questions
Suppose the scenario involves the impersonation of an electrical engineer, coming to site to perform PAT testing on an employee’s laptop. It seems simple enough, but what if an employee innocently asked where the consultant trained to do PAT testing? It doesn’t matter how much the consultant “believes” they are that character, they won’t be able to pick answers out of thin air, and they shouldn’t have to rely on being able to talk their way out of it. If they don’t have a quick answer to such a harmless and innocuous question they could be in trouble. Chapter 3 covered the basics of impersonation and the kind of questions they should be asking regarding the character. However, it is also important to consider the kinds of questions people may ask just in casual conversation. Build up a background to the character and expand on the purpose for being there.
• Challenging questions
If a situation arises where the consultant is challenged, then there are some predictable questions that could be asked. It is essential that the consultant can at least answer the following:
There are also other areas that need to be considered that aren’t so obvious but could still make things difficult.
• Local awareness: If you are impersonating an employee and ask where a certain department is, you could quickly raise suspicion.
• Employee car parks: As above, if impersonating an employee then don’t park in the visitors car park.
• Car registration number: You may need to write this in the sign-in book. If you provide a fake one then ensure you know it verbatim.
• Mobile phone number: Using your own phone or a temporary one? If it’s temporary for the assessment make sure you know the number. If you are asked for the number and don’t know it off hand it could look suspicious.
Exit strategies
Exit strategies are another possible extension to the pretext design map. No matter how carefully and thoroughly an attack is prepared for, there are certain outcomes that are difficult to recover from. It is outcomes such as these that require an exit strategy, providing damage control. Exit strategies are not necessarily approaches to rescuing a situation, they are approaches to ending it without raising further suspicion or ruining the entire attack.
It is fairly common for very confident and prepared trainee social engineers, engaging with a target via telephone, to crumble and hang up abruptly when something happened that they didn’t expect. This “bailing out” of the situation by hanging up on the target will only confirm their suspicions. If a consultant can talk their way out of it then great, if not, then they can attempt some of the following:
• Diversion
Claim to have suddenly remembered something else to be talked about and direct the conversion onto that whilst thinking of how to answer the previous question: “Oh! Before I forget, could I just ask you about…”.
• Interruption
Claim to have just been interrupted by a colleague and ask to call the target back or to put them on hold for a minute. This will give you time to think of how best to respond, but don’t leave it too long.
• Play the fool
Depending on what has been asked, it may be a suitable option to pretend to have forgotten something or act to not have been told it. Ask the target to hold on for a moment while you look up the information.
• Question the question
Answering a question with a question is a way to stall while thinking of how to answer. For example, if asked for an employee number, buy time by asking why it is needed, where it is usually written or for details about the authorization process in general.
• Ignoring the question
It may seem like a risky approach but ignoring the question and continuing on can sometimes result in the target giving up and moving on, if only to be polite.
When face to face with the target, the above approaches aren’t ideal with the exception of diversion. When in a tricky situation, a consultant could attempt some of the following.
• Suddenly remembered something
Just remembered having left an important document or piece of equipment in the car and need to go fetch it before forgetting about it again.
• Phone call
Not everyone has an audible ring tone set on their phone, some people just rely on the vibration. Therefore, this can be used to pretend to be receiving a call and go through a fake conversion that enables an excuse to leave suddenly, or to use the conversation time to rethink the approach.
Designing to fail
Each scenario that is created is initially designed to succeed and highlight certain vulnerabilities. However, a “failed” scenario can potentially highlight additional security issues. For example, instead of using supporting techniques to avoid being challenged, a consultant may actually try and look suspicious to assess how employees challenge new faces (which identifies issues with awareness and training programs). One particular assessment performed by the authors demonstrates this quite clearly. The client had insisted, despite the best efforts to dissuade them, that access to the server room should be the main objective. The reconnaissance was conducted, appropriate scenarios to identify vulnerabilities were designed and the engineers arrived to execute those scenarios. What wasn’t known was that the client had informed all the employees that an assessment was going to be performed and on which day. Once the consultant had gained access to the building, suspicious employees immediately surrounded them. They challenged the consultant asking them who they were and why they were there. The consultant, although somewhat taken aback by the ambush, held their composure and explained they were visiting from another branch and showed their “fake” employee badge (luckily this was in line with the current scenario they were executing). On seeing the employee badge the interrogators immediately dropped their accusations explaining “Oh thank god for that! Apparently, there’s going to be a “mystery shopper” type guy at some point today, so we’re all on our guard! The IT department is that way.”. The consultant took full advantage of the situation by chatting at length with the employees about this “mystery shopper.” In this example the consultant did not originally intend to be challenged in this way, but being challenged identified a very serious issue with the awareness and training program, or lack thereof.
Another similar example involved a failed challenge by a security guard. Two consultants were involved in a standard assessment. One of the scenarios had resulted in them obtaining a valid pass, but only one. Toward the end of the assessment, the consultants decided to try and use the pass to get both of them into the building at the same time. They were successful in gaining access but a security guard, via the security cameras, observed the “piggybacking” with the pass. The guard quickly intercepted the two consultants and asked to see their employee badges. One consultant showed the valid badge and other claimed to have forgotten his badge, hence using his colleague’s. The security guard escorted the employee without a badge back to the security room for further questions, then allowed the other consultant with the valid badge to continue on. Had this been a real attack, although one individual was caught, the other would have been free to continue their task.
Including scenarios that are bound to fail are important, but they shouldn’t always be approached in such a black and white fashion. Sometimes, the best approach is to design a collection of scenarios, all with the same objective, but with varying degrees of sophistication. To explain this more clearly, consider an email phishing attack scenario. By designing the perfect email phishing attack right down to the finest detail, so that the recipient couldn’t possibly spot it as a fake, you would be very likely to succeed. However, what does this prove? Possibly presenting the client with a worst-case scenario “Look what an attacker could potentially do!”. The problem is that the client will seriously struggle to defend against an attack like that, so what has the assessment really achieved? Instead, suppose that the testing company inserts a few minor errors, such as spelling mistakes, a slightly different domain name or inconsistencies in the email signature. Now, there is the potential for staff to spot these and contact the IT help desk to report it. What does this then tell the client? Quite a lot. It tells them that their employees are looking for these issues and reporting them appropriately. If they don’t receive any calls, then they know where their awareness and training programs need improvement. If the attack was reduced to the basics, involving very simple phishing attacks, then a lack of calls from the employee would indicate some serious security issues! These varying degrees of attack can all be launched simultaneously, as the testing company knows whom they are sending them to and the client knows who rang up to report the issue. In addition, if the phishing email is harvesting credentials, then the testing company can see who fell for the attack.
Summary
Ensuring value for the client is of paramount importance, especially when time is limited. The formal approach to both target identification and pretext design has been discussed. These methods ensure that the scenarios target the most relevant areas and identify as many vulnerabilities as possible.
Scenarios don’t always go to plan, having the outcomes considered, cover stories prepared and knowing your exit strategies can go a long way to improving the chances of success.
The next chapter will look at how to collect and leverage open-source intelligence during an assessment.