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.
Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.
YouTube session cookie.
Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.
Analytics cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.
Preference cookies enable a website to remember information that changes the way the website behaves or looks, like your preferred language or the region that you are in.
Unclassified cookies are cookies that we are in the process of classifying, together with the providers of individual cookies.
Cookies are small text files that can be used by websites to make a user's experience more efficient. The law states that we can store cookies on your device if they are strictly necessary for the operation of this site. For all other types of cookies we need your permission. This site uses different types of cookies. Some cookies are placed by third party services that appear on our pages.
Discover why security operations teams choose NetSPI.