In August 2019, a very secure and sensitive organization commissioned the Comsec Red Team to carry out a Social Engineering (SE) project. The customer requested that we try to access their network through their tech support line. The only information available to the Red Team was the phone number for the organization’s tech support team.

We begin every SE project with OSINT (Open Source Intelligence). So, the team searched for a high-ranking employee at the organization who tech support would likely not be acquainted with. After selecting the appropriate employee, we gathered all the necessary personal information (full name, phone number, email address, photos, position, length of employment, previous workplaces, etc.), as well as potentially relevant employment information (such as the name of his direct manager, who his colleagues are, etc.). The next step was to create the best possible scenario for the project to succeed.

In order to execute the perfect SE attack, attackers must take into consideration the following variables prior to creating the scenario:

• Who are they going to impersonate? And why this person?
• What is their goal?
• What are the victim’s capabilities? (i.e. can they change the user’s password?)
• Can the victim provide the targeted information required by the attackers?
• What kind of scenario will cause the least suspicion?
•  What is the best time to carry out the attack for maximum effectiveness?
• Setting the scene

Then team selected a high-ranking employee who we will call John for the sake of this blog. The staged scenario is that John is on vacation overseas with his family (without his work computer or VPN access). His boss has asked him to organize a meeting with a government security organization and a very important visitor needs to be approved for entry into the facility. In order to access any of the customer’s facilities, all visitors must be approved by the organization’s security department.

John has a young daughter and a teenage son. So the scenario plays out that John’s wife has gone shopping, leaving him to care for the children. John will call tech support and request entry approval for the visitor, whom we will call Mike (also not his real name), for the purpose of meeting with John’s boss. The Red Team will assume the identities of John, Mike and the teenage boy. A YouTube video will be played in the background to simulate the little girl crying.

One of the best ways to get a person to reveal classified information is by getting them to empathize with you, your situation, or to feel sorry for you. Another technique is to make them feel that they are in control and you are disadvantaged in some way. The attacker must be highly self-confident and not hesitate under any circumstances. He must also be able to improvise and seem reliable enough so that tech support representative will want to help him, while keeping him under just the right amount of pressure to cloud his judgment, but not become suspicious.

The team agrees, as part of the scenario, that if the tech support representative asks a question that the team can’t answer, the team will fake an argument between John and his son about who is supposed to be looking after the crying little girl to buy some time and deflect the request. This scenario is meant to create a lot of pressure as well as empathy on the part of the tech support representative.

The attack begins

With the team familiar with the scenario, their roles and the goal, “John” calls tech support and requests approval to grant “Mike” entry into the facility. The response from tech support is that they are unable to grant approval, but that Mike can do it himself by using the online system. They provide the URL and ask John to log in with his credentials.

To add authenticity, make the tech support representative feel empowered and avert any suspicion that he is speaking to an attacker, John asks, “What is a URL and where is it? Is it on the internet?” After explaining what a URL is, the representative tells John to log into the system with his employee ID and password.

The attacker naturally doesn’t have an employee ID or password, so he asks the representative to log in on his behalf. The representative asks “John” for his employee ID, so “John” improvises and provides random numbers while the team creates vocal distractions in the background. The representative says there are too many numbers and that employee ID numbers only have 6 digits.

The attacker immediately flips the situation to his advantage and, with complete confidence, asks the support representative: “Don’t you know how to count?! I only gave you 6 digits!” and repeats the same number minus the two last digits.

At that point, the support representative is convinced that he’s speaking with John but he still needs John’s correct employee ID number. However, despite his willingness to help, he says that he can’t find it in the database. So the attacker asks him to search by name. The support representative searches for John’s name and reveals John’s real employee ID! The attacker tells him that he has never heard of this number and has no idea what he is talking about, and that “Mike” is already outside waiting for permission to enter the building. The support representative asks him to hold while he transfers the call to a more senior person in his department.

Gaining full access to the system

So now we know the system’s URL, John’s employee ID, and his email and phone number (through OSINT) which we have also previously acquired. The only thing left is to find a way to get or reset John’s password to gain access to the internal systems with John’s account.

Reviewing the possibilities, we noticed that in order to change the password, the ‘forgot password’ function sends a temporary access code (OTP) via SMS (text message) which in our case will result in the real John getting the message. To avert this, the team decides to change John’s phone number in the organization’s database so the text message will be sent to the attackers instead of to John.

Tech support works in shifts from 7:00 AM to 9:00 PM. The team waits until there is a shift change so they won’t speak with the same person who might become suspicious. “John” calls again and identifies himself, explaining that he has bought a new mobile phone line and would like to change his number in the database. The tech support representative asks for John’s employee ID (which we got from the previous social engineering phase), his previous phone number (which we gathered from the OSINT phase) and his new phone number.
After supplying all the required information, the representative gladly changes the phone number, and the text message from the “forgot my password” system is sent to the new phone number which belongs to the attacker.

And, just like that, the team succeeds in gaining full access to the organization’s systems.