Some of the most interesting hacking at DEF CON 34 didn’t involve malware, a zero-day or someone tearing apart a piece of hardware.
It involved a telephone.
At the Social Engineering challenge, participants targeted large companies with something much simpler than an exploit: conversation.
Before anyone picked up the phone, they did their homework.
Company websites. LinkedIn. Job postings. Employee profiles. Public announcements. Technology references. Anything publicly available that could tell them more about the company and the people working there.
Then they started calling.
Customer service. Recruiting. Physical security. Anyone publicly reachable who might be willing to help someone with a reasonable-sounding question.
They weren’t asking for passwords.
They weren’t asking for credit card numbers.
They weren’t calling and announcing that they wanted sensitive corporate information.
The questions sounded a lot more ordinary.
Does your company use AI?
What application do employees use to communicate internally?
What happens if an employee’s computer is lost or stolen?
Who do they contact?
How does that issue get escalated?
Do employees receive cybersecurity training annually or twice a year?
Individually, many of those questions don’t sound particularly dangerous.
That’s exactly what made the challenge so interesting.
The call starts before anyone picks up
Social engineering doesn’t necessarily start with the phone call.
It can start with information the company and its employees have already put online.
Spend some time on LinkedIn and you can learn quite a bit.
Employees list their positions, responsibilities and sometimes the technologies they work with. Recruiters post jobs describing the tools candidates will use. Companies announce partnerships and projects. Executives discuss new initiatives. Vendors publish customer stories.
None of that is necessarily a security problem.
People need LinkedIn to build careers. Companies need job postings to hire people. Marketing teams need to talk about what the business is doing.
But start putting those pieces together and a picture begins to form.
You might learn who works there.
What departments exist.
What technologies they’re hiring for.
Which vendors they work with.
What projects they’re discussing.
Even some of the language employees use when talking about the company.
Now the caller isn’t starting from zero.
They know enough to make the conversation sound familiar.
And familiar is useful.
The story makes the question
The setup could change from call to call.
One caller might pose as an auditor working through a few routine questions. Another could play the new employee who just needed some help understanding how things worked. Someone else might claim to work for a business partner trying to check off a few compliance requirements.
Nothing about those scenarios immediately screams attack.
In fact, they sound like conversations employees have every day.
And that was the point.
The best pretext wasn’t necessarily the most complicated one. It was the one that gave the person on the other end a perfectly reasonable excuse to be helpful.
Ask someone out of nowhere what communication platform their company uses and they might wonder why you want to know.
Ask the same question as a new employee trying to get set up and suddenly it makes sense.
Ask about security procedures as a random caller and you might get shut down.
Ask as an auditor or partner working through compliance and those same questions can sound like part of the job.
The question didn’t change. The reason for asking did.
That’s what makes good social engineering difficult to recognize.
The caller doesn’t necessarily need to convince someone to knowingly break company policy.
They need to create a situation where answering the question feels like following it.
People really want to help
This was probably the biggest thing that stood out while watching the challenge.
People are helpful.
That’s normally something companies want.
Customer service employees are hired to solve problems.
Recruiters are supposed to answer questions.
Physical security personnel provide assistance.
IT teams want to fix things.
Employees generally don’t want to tell someone, “I don’t know. Figure it out yourself.”
So when someone calls with a believable problem, people naturally try to help.
And sometimes they help more than they need to.
Ask one question and you get the answer.
Then an explanation.
Then some additional context.
Maybe the name of another department the caller should try.
Maybe a little more information because the person wants to make sure the caller understands.
One answer can turn into several without the caller ever having to push particularly hard.
That’s where the exercise became more interesting than the typical security-awareness example.
The employee wasn’t necessarily being careless.
They may have been very good at their job.
The vulnerability isn’t always stupidity. Sometimes it’s good customer service.
That’s a difficult problem for executives.
You don’t want customer service refusing to help customers.
You don’t want recruiters afraid to talk to candidates.
You don’t want physical security treating every confused visitor like a criminal.
You don’t want employees scared to answer ordinary questions.
The answer isn’t teaching people to stop helping.
It’s teaching them to recognize when helping becomes oversharing.
“We Don’t Give Out Sensitive Information”
Then came one of the most interesting contradictions of the entire challenge.
Employees could be asked about cybersecurity training.
Do you receive it annually?
Twice a year?
Many knew the answer.
Some went further and explained the training.
They might talk about what employees were taught and make it clear they understood that they weren’t supposed to provide sensitive company information.
Then the conversation continued.
What communication platform do you use?
Does the company use AI?
What happens if a laptop gets stolen?
Who do you contact?
How does the issue get escalated?
What process do employees follow?
And people would answer.
That’s worth paying attention to.
These weren’t necessarily employees who had never received security training.
They had received the training.
They remembered it.
Some understood it well enough to explain it to the person calling them.
The problem was recognizing that the conversation they were having was exactly the kind of situation that training was supposed to prepare them for.
Knowing the rule and recognizing when the rule applies are two very different things.
Tell someone not to disclose sensitive information and most people understand that a password is sensitive.
A Social Security number?
Obviously.
Customer financial information?
Obviously.
But what about the company’s communication platform?
What platform do I put my hours in?
What days are we paid?
What operating system are you on? Windows or Mac?
Which web browser are you using?
What anti-virus are we using?
Are we using a VPN service?
Each answer can feel harmless.
And individually, it might be.
But the caller isn’t necessarily looking for one big secret.
They’re collecting pieces.
Nobody Had to Give Away the Password
Imagine someone tells a caller which communication platform the company uses.
That’s not a breach.
Another employee explains what happens when a laptop gets lost.
Still not a breach.
Someone identifies which department handles the problem.
Another person explains how an urgent issue gets escalated.
Someone else confirms a technology the company uses.
Nobody handed over credentials.
Nobody installed malware.
Nobody opened a suspicious attachment.
But now the person making those calls knows considerably more about the company than they did before.
And that can make the next conversation better.
Instead of:
“Hi, I’m having a problem with my laptop.”
the caller can now sound more like:
“Hi, I’m trying to follow up on my laptop issue. I was told this goes through [department], but I’m not sure how the escalation works.”
Now the caller knows some of the company’s language.
They know part of the process.
They know which department to mention.
They may know what applications employees use.
They may know enough about the organization to make the next person considerably less suspicious.
That’s why seemingly harmless information matters.
One answer might mean nothing. Put enough answers together and you’ve built a map.
And once you have the map, figuring out where to go next becomes much easier.
Even the silly questions have a job
Not every question has to be important.
Some can be completely harmless.
Some can even be silly.
That’s part of what makes the conversation feel normal.
Real conversations wander.
People make small talk.
They ask follow-up questions.
They laugh.
They talk about things that have nothing to do with the original reason for the call.
If every question sounds like it came directly from a security questionnaire, eventually someone is going to wonder why they’re answering it.
Mix in ordinary conversation and things feel different.
The employee relaxes.
The caller becomes another person who needs some help instead of someone running through a checklist.
Then another useful question gets mixed in.
It’s simple.
And it’s hard to recreate with a five-minute annual training video.
Real social engineering doesn’t always sound suspicious.
Sometimes it just sounds like a normal conversation.
Training Completed Doesn’t Mean Lesson Learned
This is where the conversation needs to move from employees to executives.
Security-awareness programs love numbers.
Training completion rates.
Phishing simulation results.
How many people clicked.
How many reported the email.
How many employees are overdue for training.
Those numbers are useful.
They’re also easy to put on a dashboard.
There’s another question that’s considerably harder to measure:
What happens when someone actually calls?
An employee can complete every required security course.
They can pass every quiz.
They can recognize an obvious phishing email.
They can explain why they aren’t supposed to disclose sensitive information.
Then an “auditor” calls.
Or a “new employee.”
Or someone from a “business partner” trying to satisfy a compliance requirement.
Suddenly, it doesn’t look anything like the example from the annual training course.
That’s where awareness actually gets tested.
The answer isn’t necessarily another hour of mandatory training.
It’s better training.
Give employees situations that feel like real conversations.
Teach them that reconnaissance doesn’t always involve someone asking for a password.
Show them how ordinary information becomes more useful when combined with other information.
Teach them how to verify who they’re talking to.
And most importantly, give them permission to stop a conversation when something doesn’t feel right.
That last part matters.
Employees shouldn’t feel like they’re going to get in trouble for refusing to answer a question until they’ve verified who they’re speaking with.
This isn’t just an IT problem
There’s another reason executives should pay attention to what happened during the challenge.
The calls didn’t have to go to cybersecurity.
They could go to any employee.
Any one who would pick up the phone.
That’s important because companies sometimes treat social engineering as an IT security problem.
It isn’t.
Each department can know something unique enough to provide additional unknown information.
The attacker doesn’t care which department provided the information.
They care whether the information helps.
That means security awareness can’t stop with the people who have administrator accounts or work inside the SOC.
Anyone who answers a phone, responds to an email or understands how the company operates can become part of the conversation.
The attack can start long before anything gets hacked
That’s what stood out to me most from watching the Social Engineering challenge at DEF CON 34.
A cyberattack doesn’t always start when malware executes.
It doesn’t necessarily start when someone types a password into a fake login page.
Sometimes it starts much earlier.
A LinkedIn profile.
A job posting.
A company website.
A name.
A phone call.
A reasonable story.
Then a question.
Then another.
Nothing has been “hacked” yet.
Nobody may even realize anything happened.
But someone on the outside now understands the company a little better than they did five minutes ago.
And that matters.
The people answering those calls weren’t necessarily trying to ignore security policy.
Many were trying to do exactly what their company hired them to do.
Help someone.
Solve a problem.
Answer a question.
Point somebody in the right direction.
That’s why saying “people are the weakest link” doesn’t tell the whole story.
People are people.
They want to help.
They respond to situations that sound familiar.
They trust requests that seem reasonable.
A good social engineer understands that.
They don’t always need to convince someone to break the rules.
Sometimes they just need to convince them that answering the question is part of their job.
For CEOs and security leaders, that’s the lesson worth bringing back from DEF CON.
Don’t just ask whether employees completed their cybersecurity training.
Ask whether they understand what information matters.
Ask whether they know how to verify the person on the other end of the phone.
Ask whether they feel comfortable saying, “I need to verify this before I can answer.”
And ask whether your organization is teaching employees to recognize the conversation that looks completely normal until all the pieces are put together.
Because your employees don’t have to hand an attacker the keys.
Sometimes they only have to explain where the doors are.
