Social Engineering

Case Study: Physical Social Engineering

Physical social engineering tests involve our expert team attempting to gain access to offices and buildings with a view to testing the security of the building’s infrastructure and employees. We generally perform them with some of our more mature clients from a cybersecurity perspective. Effective engagements rely on a minimal number of staff within the company (ideally only one or two) knowing that the test is taking place to ensure a “real” response from employees, security, and processes.

 

This engagement was particularly interesting as the client asked us to not only gain access to two different sites but to see if it was possible to remain on site unchallenged and to see what additional information we could gather by talking to employees – we’re always up for a challenge, so challenge accepted!

 

Reconnaissance

 

Reconnaissance, or Open Source Intelligence (OSINT), is an important part of any social engineering engagement, but even more so for physical tests. Answers to onsite questions need to be immediate and there’s no opportunity to look at notes or scripts to ensure that the pretext goes as planned. We used Google Maps (Street View is amazing for virtually ‘walking’ around the outside of buildings before arriving on site), Wiggle, and LinkedIn to build up a good idea of the layout of each building, possible methods of entry and the ‘pretext’, i.e., why we should be let in.

 

Pretext

 

Pretexting is developing a character/reason/motive for you to be engaged with employees at the business being tested. This is one of the most important stages in a social-engineering campaign as a believable pretext can make the difference between gaining access/information and not. In this case, we discovered that our client was having significant building work undertaken at one of their sites, so posing as contractors and consultants would be an effective way to gain access to the sites and potentially move around unimpeded. We often find that people don’t question someone wearing Hi-Viz and a hard hat.

 

Initial Access

 

With two different sites in scope, we decided it would be best to hit both on the same day with the reasoning that, if we can gain access to one, it will lend further credibility to our trying to access the second “We’ve just been down at X and are looking to complete Y task here”.

With that in mind, we decided to try and gain access to a satellite site first as we considered it the ‘easier’ of the two targets. We pulled up into the car park, and dressed in our Hi-Viz, a member of staff smoking outside the main entrance asked us if we needed to go inside. With an easy win like that in the bag, we quickly tried to put as much distance between ourselves and the front entrance – however, we then found out that every door inside the building was on key card access with the only exception being a conference room that was currently unoccupied.

 

Once inside the room, we found several ethernet ports that we could plug laptops into, start looking for traffic on the network and see what we could find via scans. However, our run of good luck quickly came to an end when two members of staff came in and wanted to use the room – rumbled, or so we thought! Our Hi-Viz and pretext put them at ease, they allowed us to continue our “tests”, and within five minutes had even given us the corporate Wi-Fi password. Except for the few employees we had already met, there was very little happening at this site either in person or on the network.

 

The Main Event

 

With the Wi-Fi password and some credibility (and confidence) from our initial success, we decided to go for the Head Office – the main target. As we pulled up on site, we saw other people in Hi-Viz and hard hats exactly as we’d hoped from our initial research. However, our self-congratulations quickly stopped when we faced our first major challenge of the day – no one was answering the reception intercom and the other people in Hi-Viz were not inclined to let us in. “We’ll get in trouble if we let anyone in”. That’s a good mark for security, but not so good for us trying to find holes in it.

 

We waited outside for approximately fifteen minutes until an employee arrived outside the building. We gave them a quick explanation we’d been at the other site running some tests and were looking to finish the job here. This worked and we were let in and followed the employee up to the correct floor. They turned and asked us if we needed to “Speak to IT”, but we said no and that we would be fine to complete our work “without any extra support” (phrasing is everything in social engineering – we wouldn’t want to be a burden on the IT department now, would we?). Not having a proper sign-in process made our task much easier as it relied on employees to be assertive in stopping us rather than the helpful and kind people they were (social engineering plays on social norms and unfortunately the kindness/naivety of others).

We asked whether it was hot-desking so as not to end up sitting in someone from the security team’s chair! It was, which helped us a lot, as it meant we could find a quiet corner of the office and plug in laptops. At this point again we had free reign of the building and this time the whole floor was open plan. Whilst we ran some man-in-the-middle attacks on both Wi-Fi and ethernet in the hope of retrieving user hashes for cracking, we took a quick tour of the office to look out for any useful information under the guise of inspecting parts of the office as per our pretext. Hot-desking meant this was fairly fruitless, but did give us a bit more authority and meant we were not disturbed for the rest of the test.

 

On returning to the desk, a number of user hashes had been logged by our laptops – we were able to crack one whilst on site and this happened to be a member of the security team. Additionally, an Active Directory misconfiguration discovered when running BloodHound showed that one of the Domain Admin accounts was Kerberoastable from the user we had just cracked their hash – and now had their password. After some more hash cracking using one of our favourite tools Hashcat and we now had Domain Administrator credentials, and effectively, the keys to the kingdom. We ran some commands and jumped onto the Domain Controller to show impact for our client and then promptly left – after spending nearly 4 hours in two separate sites across a large city without detection.

 

We rang our client later to give them a brief overview of findings from the day before writing and sending the full report.

Our recommendations for your security from this test and other physical social engineering engagements are listed here:

 

Problem

Solution

Explanation

Unauthorised visitors gaining access

Ensure the sign-in process is followed for visitors

Staff can stop unauthorised visitors before they can get further into the building. Holding the door for someone is helpful, but also a risk if that door is meant to be key card only.

Physical social engineering

Provide staff training on risks

Targeted social engineering can be much more damaging than traditional phishing vectors and puts personal safety at risk in addition to IT/information security.

Employee and visitor badge security

Ensure social media does not reveal badge details

Social media posts can show what employee badges and/or visitor badges look like, making it easier for attackers to create fake badges and gain access to restricted areas.

Tailgating

Account for all entrances

Employees can be followed into the building from designated smoking areas, bypassing the front desk and security. All entrances must be accounted for and monitored.

Ethernet and Wi-Fi access point security

Be mindful of access to internal infrastructure

Unauthorised individuals can plug into the ethernet or Wi-Fi network and perform man-in-the-middle attacks, leading to a complete domain takeover. Consider implementing MAC filtering for ethernet connections.

 

 



Contact us..

Related Articles