Failure is a fact of life and it’s doubly true when it comes to security. On-site social engineering is a unique beast and it carries its own issues when it comes to failure. While it’s easy enough to modify your payload to bypass a WAF or just hang-up the phone when the phish isn’t biting, you don’t have the luxury of just disappearing when confronted in person (even if you’re wearing camouflage). You are forced to literally come face to face with an obstacle and try your darndest to figure your way out of it.
You’re probably going to be caught eventually. We even make it a specific goal during every engagement. Unfortunately, night vision goggles do not give you the foresight to see when it will happen, so you’ll need to come prepared with a get-out-of-jail letter.
Building a Letter
The concept of a get-out-of-jail letter itself is simple: it’s a document from the client proving that you are allowed to be sneaky. Essentially, it is your permission slip to be on-site. It should contain all of the necessary information to verify who you are working with and what you are doing. Document any specific addresses or buildings that you will attempt to access, as well as detailed contact information for your client point of contact.
I recommend that you include at least two different contacts and/or multiple methods to reach your primary contact. Ideally, there should be one other person on-site who is aware of your activities. Keep in mind that it is completely up to the client who they notify and how much information they share regarding the project – just make sure that someone can vouch for you. You don’t want to be stuck in an awkward situation where a security guard is unable to reach the only person who knows just exactly what is going on.
It’s a fairly generic document that has worked well for both legitimate and decoy letters.
Trust, But Verify
Yes that heading is a cliché, but there’s a reason it gets repeated ad nauseam. It is important to confirm the accuracy of any document – including one that says a complete stranger should have all-encompassing privileges to break into a building. There is nothing stopping an attacker from simply fabricating the entire scenario. That’s why I’ve started to carry a second letter – to see if someone will validate its contents or just take it at face value.
Preparing a decoy letter is no different than creating a legitimate one – just swap the contact information with something a teammate can access. Google Voice is a free, popular option. Simply choose the number you wish to use and configure it to forward to a co-worker’s phone. The main caveat with Google Voice is that you can only own one number at a time. This restricts you to a certain geographic region since unfamiliar area codes are still one of the first things that catch someone’s attention.
Another useful service is Flowroute. Flowroute allows you to purchase several individual numbers across multiple area codes. You can then configure inbound calls to forward to the numbers of your choice. This flexibility allows you to setup both a desk phone and mobile number for your decoy contact. If you want to establish an extra ounce of credibility, record the target company’s public-facing phone greeting, mix it with a standard voice message prompt, and set that as the “desk phone” voicemail. Then when you get caught and present the decoy letter, just have the person call the desk phone first.
Mandatory War Story
You can’t just write an article about “on-site social engineering” without an accompanying anecdotal series of events. I was able to utilize this “decoy letter” with great success while on an engagement last year. To set the stage, this customer was split across two separate buildings. The primary building was several floors tall with keyfob entry into each floor after exiting the elevator. This building occupied the majority of the business employees. The secondary building was just across the parking lot and held IT staff. I had already obtained access to one of the restricted floors in the first building and had been on-site for a little over an hour under the guise of an IT intern that was tasked with “upgrading monitor firmware”. At this point I was trying to establish persistent remote access by compromising a workstation and creating a reverse shell back to our external testing machines. Par for the course for these types of engagements. My USB Rubber Ducky was already configured with a PowerShell payload and all I needed to do was plug it into an unlocked workstation, wait a few seconds, and just walk away.
I eventually caught someone’s attention and they wanted to escort me over to my manager’s office to confirm if this was legitimate work. Luckily, the client contact I was working with sits in the second building. Walking out the office, across the parking lot, and towards this other building gave me plenty of time to (unsuccessfully) talk my way out of the situation. As we approached the doorway, I finally came clean with the employee and handed them my fake letter. They read it over, made a comment along the lines of “hah, that’s good”, and we continued onward into the office. That wasn’t really the reaction I was expecting at all and I practically begged – “Just call the number on the paper, that’s a direct line for this specific situation. He’ll answer it I promise!” This was my first time getting caught so quickly so I was pretty disappointed in myself.
We made our way through the building towards the contact’s office. I had accepted my fate. Getting caught isn’t the end of the world and is absolutely accounted for when preparing for the engagement. We’ll normally take a few minutes to go over the details of what happened, what lead up to the catch, and then document it in the final report. From there, we’ll ask to be released back into the wild to continue the test. To my surprise, the contact had stepped out of their office at just the right time. Without anyone to talk to, I was escorted back to the main building and my captor agreed to call the number listed in the letter. This number belonged to a second tester located back at our headquarters. It was up to Karl to get me out of this mess.
Karl answered the phone. (I’m fairly certain this call ended up interrupting him during a meeting – sorry about that.) I was only able to overhear half of the conversation – “I found Patrick in the office and he says he’s working with you? … Okay … okay. So should I just let him go or … okay.” And sure enough, I was free to go.
Gotta Catch Em’ All
A core part of our onsite testing methodology involves getting caught. Typically there are protocols in place that an employee is meant to follow. Our goals are to:
Determine whether or not those protocols are sufficient.
Ensure that employees are actually following them.
During the initial entry and setup we’ll try our best to fly under the radar – but as we stay onsite longer and longer, we start to “turn up the volume” so to speak. It’s obviously an issue that someone is able to tailgate into an office and sneak around for a few hours, but what can the client really do with this information? This risk is (or should be) accounted for in their physical controls. The employees are the last line of defense and it’s important to identify just where they will draw the line.
Another benefit here is the lasting impression it leaves on the staff. It is not our intention to wreak havoc and turn the company into a mass of paranoia, but it brings a few of the issues that we test for into the spotlight. It really highlights that just about anyone could become a target. A complete stranger entering the building and asking to borrow your laptop, once a mere thought that was passively ingested through mandatory annual training videos, has now turned into a legitimate concern that they will actively attempt to identify and prevent.
PTaaS is NetSPI’s delivery model for penetration testing. It enables customers to simplify the scoping of new engagements, view their testing results in real time, orchestrate faster remediation, perform always-on continuous testing, and more - all through the Resolve™ vulnerability management and orchestration platform.
We help organizations defend against adversaries by being the best at simulating real-world, sophisticated adversaries with the products, services, and training we provide. We know how attackers think and operate, allowing us to help our customers better defend against the threats they face daily.
At NetSPI, we believe that there is simply no replacement for human-led manual deep dive testing. Our Resolve platform delivers automation to ensure our people spend time looking for the critical vulnerabilities that tools miss. We provide automated and manual testing of all aspects of an organization’s entire attack surface, including external and internal network, application, cloud, and physical security.
Our proven methodology ensures that the client experience and our findings aren’t only as good as the latest tester assigned to your project. That consistency gives our customers assurance that if vulnerabilities exist, we will find them.