A social engineering attack is one of the most impressive pentesting options. But before starting attacks, you need to clearly learn the process of their execution at all stages. If you don’t, you could get into trouble with the law, or worse, you could harm the mental health of the target you’re attacking. This is where sets of standard procedures come into play, which we will refer to as frameworks. In this section, you will learn about the process of interacting with your client to determine (adhere to) the scope of the task. We will also look at two important processes for doing OSINT and social engineering – the social engineering framework and the OSINT OODA cycle. (Observe-Orient-Decide-Act, observation-orientation-decision-act) – and discuss the operating systems you can use for this agreement with the client.
The first step in preparing for an attack is to coordinate with the customer, whether it’s the direct customer, your manager, or another team in your company. Even after you’ve completed the initial task familiarization process, don’t hesitate to ask questions about the job. Your reputation, livelihood, and even criminal record could be at stake, so make sure you’re clear on what you can and can’t do and why.
During the task familiarization phase, you should talk closely with the client to determine exactly what your test intrusion will look like and how it will occur. This stage includes finding out who your contact person will be, and considering deadlines (for example, the number of hours allocated to the task; the time of day, week or month the test will be given, and periods when you cannot take the test ). Legal aspects should also be discussed, making sure that the contract contains language that will protect you from legal problems. This is why it is wise to hire a lawyer. You need contract clauses that insure you against accidental damage and other contingencies. Finally, discuss the scale of your attack, such as the number of calls or emails.
You and your client should document the results of the scoping phase of the Terms of Reference (TOR) – the part of the contract that clearly states what you are and are not authorized to do within the scope of the assignment. Make sure that the appropriate rules for conducting offensive actions are written in the TK. It must detail any prohibited or recommended excuses, email addresses, source or destination IP addresses, and other restrictions or requirements applicable to the work.
Also, make sure that you are listed by name in the contract and TOR. It is best to name all testers involved in the contract, if possible, as well as the company you work for.
When determining the scope of the task, make sure that your participation in social engineering meets certain requirements. Among other things, make sure you have the proper permission and legal protection to perform social engineering and that the person signing the contract is authorized to give you permission to do so. If you are an internal employee testing your own company,
Obtain written permission from management. If you are handling test orders from other organizations, consider taking out special Errors and Omissions (E&O) insurance to protect yourself legally. E&O insurance, also called professional liability insurance (PLI), is designed to protect you from having to pay the full cost of a negligence lawsuit in civil court (if you lose that court).
The familiarization phase sets the tone for the entire interaction. An incorrect assessment of the work can cause trouble for both parties. This can make interactions unduly difficult, forcing you to spend more time on phone calls at inappropriate times or to get work done improperly. Incorrect assessment of the task can also damage your professional reputation if the company you work for considers you a non-specialist. The worksheet in Appendix 1 will help you ask the right questions to make sure you have all the information you need.
Definition of goals
After signing the contract and creating the technical task, once again discuss with the client the goals of future testing. Will the test result be used as a rationale for implementing new business security tools, products, and technologies? Will it be used to assess human capital needs? Maybe the test is needed just to check compliance with the company’s internal rules? Or will the customer use it to evaluate the performance of the security team (for example, as part of a performance review or to make a promotion decision)? The answers to these questions shouldn’t affect how well you do your job, but they should help you understand what to expect and how to structure your communications.
Definition of methods
The methods you use are critical to your participation. Will you use a misspelled domain name that is very similar to the client’s domain name (an especially effective strategy if the correct spelling is subject to a typo), or will you buy an available domain with the same name and a different top-level domain (eg nostarch.us instead of the legitimate nostarch.com)? Will you pretend to be a supplier, customer or partner? Using malicious document downloads or just collecting credentials? Will you use vishing and phishing together? Does the client want you to use an automated solution, or should you prioritize manual labor, as we discuss in Chapter 7?
Knowing the technology your customer is using and where to focus your efforts will be an important factor in the success of the attack. First of all, check if it is possible to gather information from open sources about the technologies used by your customer, and then try to use this information. This approach has the added benefit of providing the customer with a method of detecting and possibly attributing any other attacks, as well as verifying that the customer has properly implemented and used their technology. Your customer will surely be satisfied if he receives more information than he ordered.
When developing pretexts for interaction, try to find events in the environment of your victim that could be used against him. You may apply to work for an organization that provides cloud storage or email services to the victim company and request additional information regarding the “security incident.” To collect additional OSINT data, you can look at pages and groups in local social networks.
If you have enough time, buy a few copies of local newspapers. If you’re close enough, walk around town and look for flyers or posters announcing upcoming events. Is there a common interest or goal among the goals? Maybe one of your employees likes hiking, running, obstacle courses, or going to outdoor rock festivals? Does the organization have a bowling or softball team? If so, what leagues are they in and where do they play? Who are they playing against?
The considerations mentioned here will transform your phishing attack from random to targeted, greatly increasing its chances of success. Taking the time to get to know the victim and their environment will make your job much easier, but be sure to share the information and advice you receive in your report, as well as in any training you may be asked to provide following the testing.
Based on the collected information, develop your scenarios and reasons. Show the client three to five best options, and let him choose which one is better to use. If possible, confirm the timing of your attack, but not the exact time. This keeps your customers on edge and gives you an element of surprise.
While no client should inform employees of the scenarios you choose, I have found that this happens quite often. For example, in one of my contracts, the client limited the possible excuses and scenarios, and then prescribed the exact times when I could send phishing emails and make phishing calls. At the same time, an important nuance was made: if during the call I was asked to call back later for any reason, I could do so without additional agreement.
Fortunately, I was able to use this point to my advantage. During the call, I created a lot of very loud background noise and simulated a disconnection. Between the noise and the “hanging up” I managed to get about two-thirds of the callers to ask me to call them back.
Use of specialized operating systems for social engineering
Social engineers and OSINT builders differ in that they use the right tools in their work. Kali, a popular Linux distribution designed for penetration testing, created and maintained by Offensive Security, comes with tools such as the Social-Engineer Toolkit (SET), theHarvester, Ghost Phisher, Maltego, and Recon-ng. We will discuss these tools in more detail in the following sections. Kali OS and the tools it ships with are most effective when used as part of a penetration or interaction test that involves general social engineering without extreme OSINT collection, although advanced OSINT collection can also be accomplished with Kali.
In addition, the Canadian non-profit organization Trace Labs has created and actively maintains a fork of Kali Linux (with the blessing and assistance of Offensive Security) that is intended to assist in OSINT investigations, particularly Search Party competitions using OSINT to locate missing persons. Trace Labs’ pre-configured virtual machine (VM) has a variety of OSINT investigative tools targeting both businesses and humans. It is available for free download at https://www.tracelabs.org/trace-labs-osint-vm/.
Using a less common operating system and configuration also has its advantages. In particular, it allows you to customize the environment according to your preferences and comfort level. If I’m doing research on a victim that can detect me, I don’t want to use my home or work network, even over a VPN that might be compromised. Instead, in addition to the Kali Offensive Security and Trace Labs versions, I use an Ubuntu system running on a cloud-based Virtual Private Server (VPS) instance where I have installed a custom suite of tools including SpiderFoot, Recon-ng, Metasploit, Metagoofil, theHarvester, and some lesser known scripts and utilities that I modified. The VPS has its own independent IP address and I can launch new instances of it with new IP addresses to avoid detection. (I’ve created and archived an Ubuntu system image, so I can make new copies as often as I need to.) I can also increase the security of my VPS by securing it – removing unnecessary services or programs, closing unused ports, and applying secure configuration to the system – and using one or more VPNs. We’ll look at setting up the infrastructure for phishing in Chapter 7.
Some tools also work on Windows. Some of these are web-based tools (like Netcraft, Hacker Target, and OSINT Framework) that you basically access from a web browser. Doing this from a Mac or PC may be more convenient than Linux. However, keep in mind that you are more likely to be caught by the company if you use your personal or even work system to perform these transactions. As long as such actions are properly authorized, the worst case scenarios are (a) blocking and (b) adding your IP address to a threat repository (a crowdsourced list of malicious entities or characteristics such as an email address, IP address, file hash, or domain), which means that your potential customers or victims may be warned that the IP address you are using is considered “malicious”. Using a VPS for an attack allows you to use the installation only once and then destroy it.
Successive phases of attack
All ethical hackers usually follow a certain sequence of attack phases, ensuring that all necessary information is collected and used. This sequence typically consists of the following steps: reconnaissance, scanning and listing, gaining access, maintaining access, removing traces, and reporting. You can read more about these stages at сторінці https:// www.cybrary.it/blog/2015/05/summarizing-the-five-phases-of-penetration-testing/.
When it comes to social engineering, it makes sense to define a slightly different attack process. In fig. Figure 3.1 schematically depicts a penetration testing process adapted for social engineering.
The downside to this approach is that you can leave behind a “dirty” IP address that has been compromised by your actions. If this IP is blacklisted by security services, then the next user who receives this address may have serious problems. But the author preferred to remain silent about it. – Note. transl.
Review
This is the scoping stage of a social engineering task where you ask your customer questions to make sure you have all the information they need.
Exploratory
In the research phase, you are trying to identify the key employees of the company; sellers, partners, suppliers, used technologies; used domains and subdomains; email addresses and the standard syntax of company email addresses (for example, first and last name separated by a period). Once the mission contract is signed, you can start scouting within the time frame specified in the contract. As long as the contract is adhered to and the intelligence is conducted within your time frame (for example, not spending 12 hours collecting OSINT on one target in a 4-hour attack), no amount of OSINT will be superfluous. However, you may find that some organizations maintain proper operational security (OpSec) by not using social media or even taking proactive measures to deliberately post misleading or false information on their accounts to avoid such threats. We call this process active disinformation.
In Chapters 4, 5, and 6, I’ll tell you about some of the OSINT data collection tools. Keep in mind that although it is important to gather enough information about the target company
and its employees, you are responsible for protecting the data while it is in your possession. You should only keep what you need, no longer than you need, and only for the periods of time prescribed by law.
Design and approval
It takes some time to ensure that the OSINT information you collect is relevant and then use it in a way that helps the employees of the victim organization grow and learn. After all, even if you’re trying to access a system or information, ideally you’ll get caught, and you’ll want customers to learn from what you’re doing.
The design and approval phase involves coming up with possible reasons for contact that your customer should review and approve. Share with them the details of the excuse, the phone numbers you’ll be calling from, the email addresses you’ll be sending emails from, and the time frame you plan to start and finish the test. Also explain your purpose. For example, it can be counting the number of clicks on links in an email. Or you might try to obtain sensitive information from company employees or deploy malware or remote shell droppers (software that allows you to remotely connect and install malware).
Realizations
During the implementation phase, you install and configure the correct software. It includes infrastructure such as email accounts, web servers, macro-enabled Microsoft Office documents, malware, USB drives, and other decoys. You can also access the organization’s waste bins and collect documents to take them off site for further analysis. You will use pretexts approved by your client-side contact and put them into practice by conducting phishing, vishing and other attacks as specified in the TOS.
Detection
During the detection phase, defenders will try to detect your actions and then take steps to reduce their effectiveness or impact. Depending on the scope of the attack, defenders may or may not know that the attack is authorized.
If it’s part of the red team’s job, they likely won’t know ahead of time. Although this phase seems less exciting than the attack itself, it is the most important part of the process. Remember, your ultimate goal is to teach your organization how to detect and mitigate social engineering attacks.
Measurement
In the measurement phase, you collect information such as the number of people who fell victim to your tricks, how long it took to detect the attack, when victims reported it, how many such reports there were, and many other metrics. Once you have collected and analyzed this information, you need to compile it into a report for the client. We will talk about measurement methods in chapter 9.
Making a report
In the reporting phase, you take the collected metrics and combine them with the technical workload, a summary of the idea and plan of attack, a summary of how the interaction went, and any findings from OSINT collection or mission execution. A template similar to the one in Appendix 2 can be used to write the report. Send this report to the client for review. If you choose to keep a copy of the report, you must secure the document as the information it contains could potentially be used to attack the client.
In addition to this social engineering process, you may find it helpful to refer to the observe-orientation-decision-action (NORD) cycle to gather the OSINT data I use. The cycle shown in Figure 3.2 asks you to observe your findings and build a hypothesis (orientation phase), then look for additional information to try to confirm what you already have.
Once you have enough data, you can decide what to do with it. Should you be phishing or vishing, or do you need more information to be successful? Do you have enough information to conduct a commissioned penetration test or red team fight with the appropriate degree of stealth? Then, depending on the results of these decisions, you move on to action.
Actions may include executing an attack or writing a report (if OSINT is all the client wants), or they may initiate additional iterations of the NORD cycle. There is no right or wrong answer; This depends on your goals and the time limits outlined in your customer agreement.
However, you can apply this loop to any attack, whether it’s hacking a web server or gaining network administrator privileges.
In September 2019, a pair of pentesters working for Coalfire were arrested for trying to break into the Dallas County Courthouse in Adela, Iowa. While specific details about this incident are not available at this time, we do know that they were acting as part of a penetration test mandated by the Iowa Judicial Administration (SCA). In a statement to Ars Technica, the SCA acknowledges that it authorized Coalfire to review the security of the court’s electronic records.
According to their statement, the SCA neither requested nor expected the testers to attempt to physically enter the courthouse. The testers and Coalfire say the penetration test was intended to determine the vulnerability of the recordings and assess the response of law enforcement. Although this approach is not devoid of common sense, the fact that the testers spent several hours in jail and had to post bail shows a lack of understanding during the familiarization phase of the task.
Pentesters could have acted differently based on the information provided. I recommend communicating with your client’s security staff more often. If you have any questions, feel free to ask them. In addition, testers must ensure that they have a notarized copy of the official permit with them when they physically enter the building.
How can you mitigate or prevent negative consequences:
Ask more questions to clarify the scope of your authority;
Maintain a working dialogue with your contact person via e-mail. Verbal communication helps to achieve the goal faster, but is not suitable for legal protection;
The customer’s management should clearly state not only what is permitted, but also what is prohibited in the contract and permit documents. This should be part of the contract preparation process.
We used materials from the book “Social Engineering and Ethical Hacking in Practice”, which was written by Joe Gray.
765 
605 
690 
629 
661 
625 
655 
724 
656 