Social engineering can be difficult to deal with. People inherently want to give out information, especially to Human Resources or the executives. Ira Winkler and Brian Dealy have written an excellent paper, available here. In this article, I want to unpack some of the security implications, and reiterate the “lessons learned” for my readers.
So, what happens in the paper is that a team of attackers gain a whole lot of information, starting with very little. They use publicly available information just from google searches, to eventually get a copy of the company directory and a whole lot of Employee Identification Numbers, and from there they got user IDs and passwords. Then, they called Information Systems and got phone numbers for the modems, and would be able to dial in to access the compromised user accounts. It’s important to understand these weak points in your systems – it may seem like a great idea, or even just a convenient idea, to post information like that where you intend employees only to even search for it, but people are always on the prowl.
The attackers in this story were hired on by the company in question, specifically to test their organization against malicious actors. Whereas a real attack would include physical visits to the company, this team was restricted to four days worth of man-hours, and they could only try to retrieve information through phone contacts. So, right away this isn’t going to include attack vectors like rooting through your trash for improperly disposed of documents (shred them!) or email phishing, or anything like that. This is a case study about what can be accomplished simply by calling people and lying about who you are.
Step 1: Search for Publicly-Available Information
The first step was the google search. Google indexes pretty much everything by default. IT for this company had dropped the ball in any of several ways: they may have misconfigured the “robots.txt” file, which tells Google what to ignore. Pages that are listed there are not accessible without a direct link. Second, they may have left databases configured with default options in place. A username/password combination like “admin/password” is pretty awful, and it’s awful on purpose. The idea is that IT staff will change that default authentication, but that’s not always the case. Don’t get me wrong. It’s completely OK to post internal materials on your servers – just make sure that they’re only accessible through your business’s intranet, not the internet at large. Another option is to password-protect important documents and PDFs.
With just a regular web browser the attackers were able to find names of potential targets, and then they used a phone book to get the phone number of the office closest to them. From there, they called for a copy of the annual report and the toll-free number. With this information, the attackers were able to piece together positions of executives and used that information to contact a secretary and get harmless background information on an executive. They got the secretary’s number by calling the mail room and claiming to be a new employee, and the mail room sent them a company directory. The mail room also told them that you need two numbers to perform a transaction within the company: an Employee Number and a Cost Center Number. Having two separate numbers is a lot better than just one, but we’ll see that these numbers are not treated as the keys to the company that they are.
With a direct line to an executive, they were able to acquire the Employee Number and Cost Center Number of an executive by asking the secretary on two separate occasions by telling the secretary they were from Public Relations and Auditing, respectively. Then, using the main telephone number, they got to the department responsible for sending out directories, and using the executive’s numbers they got them to send a directory to the attackers.
Step 2: Navigating the Corporate Structure
Once the directory arrived, they went to work calling dozens of employees to acquire Employee Numbers, by pretending to be Human Resources accidentally contacting the wrong employee. The numbers were collected under the guise of correcting confusion. The attackers decided that finding new employees was the best way to find a way into the systems; essentially, the assumption was that new employees would be less familiar with security protocols. At this stage, a fortuitous thing happened. It turned out that the person responsible for New Hires had recently moved phones, and the message the attackers received told them a specific name for the person, which let them ask for the information from that specific person; when someone already knows your name, it makes their requests seem more legitimate.
Step 3: The Fix is In
The person called them back, to no real surprise, and provided a list of the current week’s new hires, and departments for most of them. The attackers knew not to contact new Information Systems employees. They called other people, instead, posing as an Information Systems employee and told them they were undergoing a security audit. They received information from these employees such as employee numbers, computer IDs, what software was being run, and what systems were being used. Of course, they got usernames and passwords. The reason software and hardware information is valuable is because of the nature of computer security. Most flaws are related to version numbers, for instance, a Dell acquired within certain dates might have a bug in the particular software that Dell installs that allows a hacker to gain access to the machine. It seems innocuous, until you pair it with a database of known security flaws. Once they had all of that information, they used a program called a Demon Dialer to dial all the phone numbers associated with the company and figured out which ones were modems, and with that they circumvented the company’s sophisticated firewall.
Many of the weaknesses the attackers exploited in this case are common to many other companies. Let’s walk through the exact issues, so you can put them in a checklist and talk to your security staff about them.
Do Not Rely Upon Common Internal Identifiers
The “security” of an employee identifier was not really security. It’s not really validation. It’s trivially easy to acquire them and leverage them to attack your company. They are incredibly useful for business intelligence. They are the solution for tracking all kinds of metrics. But don’t use them for protecting anything. Assume that they are compromised and just make them unimportant except for tracking various processes. What you should do is have a separate identifier for support activities. This will mean that attackers have to retrieve both pieces of information to do the same thing, and that’s easier to detect considering no department should need both of those pieces of information. It doesn’t make your organization any less efficient, but it does make it more secure.
Implement a Call Back Procedure
One of the problems with this case is that employees gave out information to people on the phone, based on what they said. You would be better served by having caller identification, or by having your employees hang up and call the proper number, as listed in the company directory. That way, an impersonator won’t get the call back, and you’d know that someone tried to attack you. This is another small thing that causes a little inconvenience to your organization, but which makes it very inconvenient to try to hack you.
Implement a Security Awareness Program
Make sure that all your employees know not to give out passwords. Technicians do not need passwords; they will have all the access they need from their end. Have a basic educational program as part of your orientation. New employees shouldn’t start until you can trust them that they won’t compromise your organization on accident. Computer professionals often assume that what is basic to them is basic to everyone else. People who are in the know about computer security are a minority, most people will not already know best practices for security.
Identify Direct Computer Support Analysts
You should have one computer support tech for about every 60 users. This person may not directly handle all support requests, but this person is assigned to certain users so that those users know not to talk to anyone else claiming to be from technical support. This prevents the largest attack vector in the case study, and makes it much harder to impersonate computer support, especially in tandem with a caller ID or call back procedure.
Create a Security Alert System
This is something that organizations are getting better at. The attackers in this case noted that no one had any way of telling their coworkers that they suspected a security threat. There was no policy or procedure in place to catch the attackers. There should be something in place at your organization to tell employees what to do if they suspect they are being targeted.
Social Engineering to Test Security Policy
You should occasionally hire licensed, experienced professionals to test your security. That’s what the organizations in this story had done; the attackers were trained within the US Intelligence Community and hired specifically to perform this attack. Sometimes a penetration test (as these events are called) do not include a social engineering portion. Make sure it does. Make sure that your security audits include information on whether your training is successful in turning out educated, security-aware employees.
If you need assistance with securing your computer networks, drop us a line. We’ll be glad to help.