Social engineering is quite possibly the least popular means of attacking a network currently employed in penetration testing. It certainly receives the least media attention. These attacks, however, can prove quite costly and should be guarded against. This sort of attack can allow the attacker to bypass the security mechanisms of a network without using any script or hacking tool and without even executing a single piece of code.
Social engineering involves getting employees at target companies to voluntarily surrender their personal or corporate information. This is usually accomplished through nothing more than conversation, often over a telephone and without any direct contact at all. It is essentially a confidence game.
It is a good idea to incorporate such an exploit into your penetration testing since social engineering can circumvent any logical security measures in place. It relies on exploiting employees who either do not place a high value on information security or do not understand that the information they hold (such as the IP address of their firewall or default gateway or even their own password) can be misused to compromise the network if disclosed to malicious individuals.
There are various methods of social engineering. We discuss three in this chapter and give examples we are familiar with that are known to produce positive results. Among these are making apparently harmless telephone calls to employees of the target company, searching through the company's office trash, and casually looking at an employee's workspace to directly obtain or deduce confidential information.
The telephone is the primary tool for social engineering. A talented social hacker can steal more critical information from and cause greater compromise to a target network with a telephone than a team of script kiddies armed with the latest exploit downloaded from the Internet.
Before calling, try to get as much specific information on the target network as possible to help you impersonate an informed caller. Using the discovery tools previously discussed (such as Ws PingPro Pack and Nmap), it is possible to obtain a great deal of information on the target network (such as its IP address ranges, zone transfer, name of mail servers, firewalls, and so on) that may be useful during the telephone conversation. It is not necessary to have any information at all since an obliging target of the attack can be talked into supplying all the information you need. Keep in mind, however, that the less information you have prior to the calls, the more difficult your attempt at social engineering will be. We do recommend that you script out what you are going to say, and the company information you are putting forth, prior to calling.
Among the most common phone techniques are (1) to pose as a member of an organization's technical support division and (2) to play the role of a disgruntled user seeking a password change. A third approach is to call the technical support department of a company and enlist their aid in getting a machine connected to their network. While the nuances of these attacks are performed differently by different hackers, the process is largely similar to what is described below.
The goal of this exercise is to contact a user of the target network and simply keep him or her talking long enough to develop a rapport before asking for his or her password. The general approach is to select a number of employees, say 30, ideally representing varying levels of access to the target network. Employees can be selected at random from a company directory if you have no prior information on the firm.
In this approach, you masquerade as a member of technical support and call unsuspecting employees, claiming to be investigating reports of network congestion in the employees' LAN or subnet and requesting their password in order to conduct tests on the network.
The first step is to call the technical support (or help desk) office and get names of a few people there (or use common names, such as Mike and Chris) and the format of a trouble ticket number. This works best if the technical support functions have been outsourced because company employees will not likely know anyone in technical support.
With this trouble ticket information and a good technical support name, call a target company employee and claim to be investigating reports of network congestion. Hopefully the target is not technically savvy and you can use technical phrases, such as “investigating congestion between the hub and the gateway router for your LAN,” to help convince the target that you are indeed who you say you are. Telling him or her that you are trying to fix the current problem so the target's network connection can be faster may help win the employee over.
Next, engage the employee in running simple “tests” that can be done from the user's desktop. A popular test is to have the target run ping localhost and ask them to see if the TTL field is greater than 64 (it is usually 128 or 256). You then inform the target that a TTL greater than 64 is indeed indicative of network congestion. A ping of the default gateway is also commonly used, which avoids getting caught by employees knowledgeable enough to know the localhost is their own machine. At this time, you can obtain the user's IP address and subnet mask as well as the IP address of the default gateway from the target by asking them to run ipconfig (for a Window's host) or ifconfig –a (for a UNIX machine) and read the results to you. You can justify this by stating you need to see if their IP information corresponds to yours. Running arp –a <gateway> or the netstat command are other good tests.
The idea is to keep the user talking, making it just slightly inconvenient for him or her, before finally asking for the password so that you can continue running these “tests” without taking up any more of the employee's time. At any time, if the employee is getting suspicious, politely end the conversation by stating the last test indicated the problem may not be on their end. Give them the trouble ticket number (make one up following the format received from technical support) and end the conversation. Then you can begin again by calling another employee.
If you happen to reach staff members who have been trained in resisting such attacks or the target happens to be technically proficient, these techniques will be more difficult. However, in a staff of a large enough size, there are sure to be a few individuals who do not hold to such high standards. In the process of finding them, you may encounter several failed attempts. In that case, it is good to space out the telephone calls between days or, preferably, weeks. This is to avoid raising the suspicions of the target firm. When we were engaged to perform a social engineering attack for a company with over 10,000 employees, from a random sample of 30 employees, 17 offered their passwords under such an attack.
The goal of the second common social engineering attack is to get customer service to change a user's password. Specifically, have the password changed to one you know so that you can access that user's account. This can be done by posing as a dissatisfied (or disgruntled) customer and requesting a change of password to either a user-supplied password or a generic default, such as the ever-popular “password.” If you can obtain information on what the organization uses for default passwords, this technique will be even more effective.
Through this approach, you call a customer support center and pose as a user who is having trouble logging into a paid service, such as an online trading account. You then explain to the customer service operator that you have been having problems logging into your account for some time now. You have sent e-mail detailing the problem to the appropriate address (for example, [email protected]) and have received an e-mail reply from someone in customer support saying that by calling in, you could get your password reset and that that should begin to address the problem. (The name of a person in customer service can generally be obtained from the corporate Web page. The head of customer service will suffice since most e-mails from anyone in customer support carry a footer from the department head.) The customer service agent will reply that the account seems to be fine; however, this will not satisfy you.
In this exchange, you will have to convince the customer service representative that you are actually the user in question. However, you will not have to know the user's password, and if asked for it, you can respond by saying that it is insecure to give out your password to anyone. If this is done properly, the customer support representative may not even ask you to prove you are who you say you are. Remember, you are not saying you forgot your password and therefore need a new one (which generally requires you to prove your identity)—you are saying that you are having trouble with the account and have been told by customer service through e-mail that resetting the password may solve the problem. A slightly disgruntled tone also helps legitimize the difficulty you say you're experiencing. The customer support representative may simply reset the password since taking this step allows him or her to show that the situation has been successfully resolved to the customer's satisfaction without having to escalate it to the next level.
If the help desk does not verify callers' identities, the job becomes easier. We find that often companies do not ask for user authentication if the call is coming from a phone number internal to the company. This lends itself to internal testing. During internal testing you can call from a company phone. In addition, using techniques described in Chapter 7, you can hopefully identify user IDs and associate them with actual names. You can then call the help desk toward the end of the day, representing yourself as one of these users. You indicate you have locked out your account after having changed your password and you cannot remember what you changed the password to. If the help desk does not make you verify your identity beyond checking to see that the call came from the desk phone of the person you say you are, you will be successful. Once you have obtained the new password you can log in and move on. This, however, can be easily monitored since the real user will eventually return to the computer and be unable to log in (because you just had the password changed). He or she will call in to have their password reset and this should trigger the help desk that something is amiss. But by then the damage has been done—you have gained access to the system. Along with current user accounts, accounts that have not been used in some time are good targets, especially since no one is routinely checking these accounts. Hopefully you will have some time to use these accounts to try to elevate your privileges before someone realizes your actions.
As a countermeasure, technical support should verify the identity of any caller regardless of what they are asking or where they are calling from. It may, however, be possible to fake the authentication mechanism. The tried-and-true mother's maiden name check is too guessable (and can be discovered over the Internet through various family history Web sites). A company-supplied question and/or answer challenge where the company asks users at sign up to select one of three questions and its corresponding answer, also out of a selected group (for example, “What is my favorite color?” “Red”), is more difficult but still susceptible to brute force attacks over time since there are a finite number of possible combinations. With time and a bit of luck, the correct combination may well be discovered.
Additionally, it is easy for a technical support operator to fail or merely forget to verify identity before issuing a password change. Therefore, establishing a separate queue for issuing password changes and training the customer support representatives who answer these calls to specifically identify unauthorized password change attempts can help reduce the risk of this occurring. This will cause legitimate users some additional delay, however, it can reduce the risk from this type of attack.
This approach involves a few more steps than the previous two. In this case, you call an employee who is working off-site at his or her normal office number. It may take a few calls before finding an employee who is not working at the office. Once you do find one and voicemail answers, hit “0” for the call to be forwarded to the administrative assistant.
When the administrative assistant answers, say that you are calling from an insurance company and the employee's policy is being cancelled unless the employee addresses these issues immediately. Then request a phone number where the employee can be reached (either his or her cell phone or a number at the client location).
At this stage, you can use any cover story that will convey to the receptionist that you must speak to the employee immediately. We have seen hackers call from debt collectors or banks, saying that the employee's assets would be seized immediately unless the employee did something.
In either case, with the employee's number, you next call the employee, posing as a member of the human resources department of the company. Apologetically inform the employee that his or her files and paperwork have been misplaced and you need some information in order to try to track down and correct the issue. Ask the employee for his or her full name, home address, home phone number, office address, office phone number, employee number (if appropriate), and so on. At this stage, no passwords are being requested.
Then, with this information, call the technical support division of the employee's company, pretending to be that employee. State that you're at a client site without your own machine (or say it's not working) and that you need help getting a machine logged into the network. Use the information just gathered to help prove your assumed identity. Then say that you will hand the phone to someone in technical support for the client firm where you are currently working. Now, with the aid of the representative from technical support (at the target company), you can configure a machine that can log into their network.
For this to work, it is not necessary to involve someone posing as a member of the client firm's technical support. This adds some legitimacy, at the cost of some additional complications.
We have discussed several of our favorite telephone hacking approaches, but there are many other good ones. You should definitely try to find or develop those that are comfortable to you. The social engineering attempt may not enable you to obtain immediate access, but it may give you additional information to use in other areas of your test. For instance, you may find user IDs and passwords that you can use for dial-up systems or IP addresses of target systems.
Here's another technique that has worked in the past. When two companies merge, especially those with subscribers or paying customers, you can call customers of either company and pose as an employee of the newly formed company, claiming to be verifying user records. In this process, ask the target for his or her account status (such as account history, number, and so on).
For example, suppose two telecommunications companies merge. You can pose as an employee of the merged company, call a customer of the company (any firm within the regions of those phone companies), and ask for their telephone number range(s). This information can then be used to perform war dialing, which can, among other things, identify desktops with unauthorized modems—one of the most significant security holes throughout America.
During Microsoft's landmark antitrust trial in the final years of the twentieth century, fellow software giant Oracle hired detectives to dig up dirt on Microsoft's activities. One of the techniques the detectives attempted was to purchase Microsoft's trash. Though this may not seem a sanitary activity, it can potentially offer an amazing wealth of information.
Almost every office with a common printer prints out separator sheets with a user's name and the file name of the printed document. A healthy percentage of these sheets wind up in the trash, allowing the brave trash diver to identify at least a partial user list and a list of documents associated with those users. Since people generally give descriptive names to their files, this can also offer many suggestive hints as to what projects the company employees may be working on. Additionally, it may offer the format of the user names. This format along with a company directory could give the hacker a sample user list for the target network.
Further, as employees work on documents, even of a critical nature, they print multiple copies to proofread and make changes. This iterative cycle may yield several printed versions that often do not reach the paper shredder and are instead left in the normal trash. These older versions can still contain a great deal of sensitive information. This is especially true if the final revision was merely for running the spell checker.
Sticky notes often contain a wealth of information. These notes (in yellow and other colors) stand out just as well in trash as they do on a crowded desktop and are a great source of information. On such slips of paper are scribbled names, telephone numbers, and addresses; gift ideas for special occasions; notes from meetings and telephone conversations; and various user passwords. Often valid user names and passwords to printers, remote servers, file shares, guest accounts, and so on are clearly and neatly written on sticky notes and thrown away when either memorized or no longer needed. However, the accounts and access privileges are often still valid.
We strongly recommend using caution when going through the trash. Trash can contain sharp objects, caustic chemicals, rotten food, and other unhealthy and potentially dangerous items. If you are going to perform dumpster diving, wear proper protective equipment; latex surgical gloves underneath thick, heavy-duty work gloves are recommended. However, even these two layers of protection may not be enough to guard against a hypodermic needle. Use caution.
If the organization recycles office paper, you will often find the most useful information there and can avoid the unsanitary conditions of general trash. As for where to dump the trash, please do not dump the contents of the trash receptacle onto your own or a colleague's desktop. Instead, spread a sheet of plastic on a flat surface, dump the trash on the plastic, conduct your examination, and when finished, wrap up the plastic and discard it again. Going through the trash can be done on a user-by-user basis by collecting individual trash receptacles or on a far larger scale by attacking dumpsters and recycle bins that serve entire divisions or even whole companies.
A user's workspace can also provide a cornucopia of information, and sorting through the workspace is usually more sanitary then the user's trash can. Sticky notes are again a prime target. These notes often carry valuable information and are generally stuck to easily visible surfaces. However, documents and user files are also susceptible. Often, even employees who conscientiously shred critical documents during the proofreading stage leave current versions on their desktop or in an unlocked drawer thinking they'll be safe as long as no one knows the documents are there.
Users often leave their computers without engaging their screen saver or cable lock. This allows a hacker to use the employee's computer and the network with all the user's permissions and access rights. Some employees think they are safe because all their applications need passwords; however, the computer's cache file often has all recently used passwords, Web sites visited, cookies, and anything else the hacker needs to exploit the user's network access. This is a major reason why systems should not be allowed to cache such information. Without a cable lock, it may be possible for someone to merely walk off with the computer, especially when all computers and laptops look alike and rarely have discriminating features on the surface.
Evaluating the security posture of your coworker's desktop is a more sensitive matter than the trash. Desktop social engineering should be done during the day while the employees are in the office but away from their desks. You want to catch people while their desk drawers and file cabinets are open and papers are spread out.
There are many approaches to this. Walk around the office space and find out which people do not lock their desks when leaving for lunch or meetings. They are prime targets. See who takes long coffee breaks. Also, find out which employees never lock their desks, leaving their files and possessions always vulnerable to prying eyes and hands. It is worth visiting the selected targets' offices or cubicles before going back to gather information in order to case out the workspace. Identify where they keep their papers and sticky notes. See if you can already spot a posted password. Identify any lockable drawers left unlocked. When reviewing an office space, keep a lookout for any video surveillance camera in use. In such a case, it is not good to sit at the employee's desk or to take any sticky notes or papers. Survey the workspace from a distance, or stand as if you are waiting for the employee to return. Just be ready with a believable cover story in case your presence is questioned.
Once you are familiar with the targets' spaces, go back when they are not around and quickly go through your target list, collecting information. If you feel they may not miss a particular document for a while, borrow it to photocopy and return. Take the copy home and read it at your leisure.
Perhaps more so than in computer penetration, social engineering attempts, especially desktop hacking, raise significant legal, ethical, and privacy issues. To guard yourself, ensure that you have your client's support (the “Get Out of Jail Free Card”) in writing before beginning any such activity.
There are countermeasures that a corporation can implement to guard against social engineering. Since social engineering over the telephone is not a technical exploit, defenses against such attacks will mainly be to prepare staff to recognize and resist them. Security awareness training and constant reminders are key to defending against social engineering attacks. Staff should be trained to never give out confidential personal or account information unless they are absolutely certain they are giving it to members of technical support who have a demonstrable need for the information. Also, standard operating procedures for customer service should include provisions for verifying caller identity before performing critical operations such as resetting accounts. In addition, all employees should be trained to report suspicious inquires to a company's security staff. The security staff may be able to determine through these reports that the company is being targeted for social engineering and send out warnings to all personnel.
Concerning dumpster diving, the firm should have a strict policy of shredding all paper documents regardless of their sensitivity; this will restrict the amount of information you can gather. Security awareness training should stress the importance of shredding sensitive information. While it is possible to reconstruct shredded documents, it is something of a hassle. However, sticky notes are rarely shredded and remain a valuable source of potentially compromising information.
As in the Oracle/Microsoft case, the trash collection work may be outsourced to a trash collection agency. Therefore, the organization will have to look at risk from that outsourcing partner.
Concerning snooping around an employee's workspace, video surveillance cameras can help discourage this activity. However, employees may not want to be monitored while at work. It is important for employees to keep an eye out for and report to physical security any unusual behavior or extra-observant individuals in the office space.