Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


12:30 PM

When Penetration Testers (Almost) Get Caught

Sometimes employees really do learn their physical security lessons

My company, Secure Network Technologies, was recently hired to perform a physical penetration test that required some extensive social engineering – and resulted in a surprise ending.

Over the years, we have penetrated numerous locations, posing as various characters with bogus reasons why we needed to get inside a client's facilities. But despite our experience, we still worry about getting caught. Waiting for a security guard or law enforcement officer to contact the client – and let us off the hook – is a nasty blow to your ego when you are contracted to demonstrate your expertise in social engineering.

To date, we have been able to successfully penetrate our clients' premises about 96 percent of the time. Occasionally, we get challenged by a receptionist or savvy help desk person who won’t help. Recently, however, we ran into a series of events that we didn't expect and had never seen before.

The goal of the job was to obtain internal network access by posing as contractors and gaining physical access to the building. We had successfully penetrated the client's physical security the year before, posing as copier repairmen and jacking into the network (we did actually fix the copier). This second engagement was a test to see if the training and mitigation steps that the client had taken in the interim would hold up against a second attack.

This time, we decided to penetrate the client's offices as heating and ventilation (HVAC) workers. During our planning for the engagement, we made the appropriate arrangements with the customer, had shirts embroidered with the name of a local HVAC company, and created bogus work orders and supporting documents in case anyone questioned our presence.

Once inside the building, we intended to plant a wireless access point on the client's network, then connect to it from a location outside of the facility.

On the day of the engagement, my partners – Bob Clary and Doug Shields – arrived at the customer's office park: a two-story, multi-tenant building. Both men were dressed in the HVAC disguises, wearing tool belts and carrying a ladder. Their conversation was littered with heating and ventilation jargon, like plenums, vents, and returns. Frightening to think neither man is capable of installing a window air conditioner.

They started just outside of the customer’s office space, peering into the crawl space above the ceiling tiles. After a while, they traced the “problem” to the customer’s offices, and asked for entry into the client's space. The security guard complied, swiping our guys in.

Upon entering the customer space, Bob and Doug were immediately questioned by the office manager. After several minutes of questioning, she checked with her boss and they were allowed to continue their work. Bob and Doug followed the “problem” to the back of the office to get some distance from the office manager, who still seemed suspicious. With the coast clear, they planted a wireless access point, gestured as if the HVAC problem was solved, and retreated to the car.

With the access point now in position and emitting a signal, our guys went to sit in the parking lot and scour through the client's internal network. While the guys were exiting the building, however, several police cars pulled into the parking lot and the officers began bounding into the building. Bob and Doug held their breath and kept moving away from the building, passing the officers on their way in.

Back in my Syracuse office, I received an urgent call from our customer. He said that the building had been broken into during the night, and several tenants had their desktop computers and laptops stolen. He asked me to make sure that it was not our people who had done the deed.

I immediately called Bob and Doug to make sure they had not gone rogue and started a mini-crime-spree while under contract. After checking with them, I called the customer back and assured him we weren't the thieves.

The customer then called Doug and Bob directly and requested them to wave off the rest of the effort. Bob and Doug returned to the office -- now a crime scene -- to learn of the break-in that occurred the previous night. Apparently, all of the tenants in the building were victims of the break-in -- except our client.

It was frightening to think of what might have happened if we'd been caught in our pen test just a few hours earlier. With thousands of dollars in missing equipment, irate tenants, and police on the trail, getting caught might have been a real ordeal.

In retrospect, I also think our client had some success to be proud of, even though we were able to get in with our elaborate HVAC apparel and gain limited access to their network before calling off the job. The client's escalated security measures warded off the real burglars, even if it didn't stop us. Who would have thought that our IT security effort would stop a physical crime?

— Steve Stasiukonis is VP and founder of Secure Network Technologies Inc. Special to Dark Reading

Comment  | 
Print  | 
More Insights
Oldest First  |  Newest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/25/2020
Hacking Yourself: Marie Moe and Pacemaker Security
Gary McGraw Ph.D., Co-founder Berryville Institute of Machine Learning,  9/21/2020
Startup Aims to Map and Track All the IT and Security Things
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/22/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, when determining the common dimension size of two tensors, TFLite uses a `DCHECK` which is no-op outside of debug compilation modes. Since the function always returns the dimension of the first tensor, malicious attackers can ...
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, a crafted TFLite model can force a node to have as input a tensor backed by a `nullptr` buffer. This can be achieved by changing a buffer index in the flatbuffer serialization to convert a read-only tensor to a read-write one....
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, if a TFLite saved model uses the same tensor as both input and output of an operator, then, depending on the operator, we can observe a segmentation fault or just memory corruption. We have patched the issue in d58c96946b and ...
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, saved models in the flatbuffer format use a double indexing scheme: a model has a set of subgraphs, each subgraph has a set of operators and each operator has a set of input/output tensors. The flatbuffer format uses indices f...
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 2.2.1 and 2.3.1, models using segment sum can trigger writes outside of bounds of heap allocated buffers by inserting negative elements in the segment ids tensor. Users having access to `segment_ids_data` can alter `output_index` and then write to outside of `outpu...