How Attackers Use Public Data to Social Engineer Credentials (And How to Stop Them)
A help desk tech at a major company nearly fell for it.
Someone called in asking for a password reset. The caller provided a name, employee ID, and home address. He sounded legitimate. He had insider information. So the tech reset the Active Directory password without properly authenticating the user.
Then things got weird. When asked where to send the temporary password, the caller said he didn’t have access to email or Teams. But when the tech looked up the “VP” on Teams, the person’s status showed “In a meeting.” The real VP was alive and online, actively presenting to coworkers.
The attacker was caught. But this story reveals something that keeps IT leaders up at night: attackers are no longer just cold-calling. They are using real data about real people to sound like insiders.
How Attackers Get Your People’s Information
This is not guesswork. This is intelligence.
LinkedIn hacks, data breaches, public records, and employee directories all leak the same information: names, titles, company names, email patterns, phone numbers, and sometimes home addresses.
A 2024 LinkedIn breach exposed employee IDs and home addresses for hundreds of thousands of workers. An attacker who knows your company structure can cross-reference that data and call your help desk claiming to be a VP with a real home address and employee ID. It sounds impossible to fake. But it is not.
Other common data sources attackers use:
- Previous breaches: If your company was in a breach three years ago, attackers still have that data.
- Public records: Property records, court filings, and business registrations are searchable.
- Job postings and company websites: Organizational structure, team names, reporting lines.
- Social media: Employees post what company they work for, their role, their manager’s name.
- Dark web paste sites: Raw database dumps from old breaches circulate for years.
The attacker in the story above used a LinkedIn breach from years past. He had real employee ID and home address. That credibility is what almost worked.
Why This Attack Type Is So Dangerous Right Now
Social engineering has always been a threat. But the combination of three things makes it lethal right now:
1. Real data is cheap and plentiful
Attackers can buy bulk employee lists with verified information for pennies. They do not need to guess. They know.
2. Help desk staff are under pressure
Take a call. Verify quickly. Move on. The help desk is not a security team. They are support. Under time pressure, verification shortcuts happen.
3. MFA fatigue is real
Even if MFA is in place, attackers count on users (or admins) approving push notifications without thinking. Users have seen so many MFA prompts that they become automatic.
The perfect attack uses real data to lower suspicion, calls someone under time pressure, and then uses that account to send a phishing email or lateral-move into the network.
How to Spot the Con
The help desk tech in the story caught this attack because he noticed one inconsistency: the caller said he did not have Teams access, but Teams showed him online.
That is the kind of attention that stops attacks.
Here are the red flags:
Red Flag 1: The caller provides unsolicited verification data
“I am John Smith, employee ID 45678, I live at 123 Main Street.”
Real employees do not usually offer this without being asked. An attacker is trying to establish credibility fast. If he volunteers specific data, verify it independently before resetting anything.
Red Flag 2: Urgency + unusual request combination
“I need this fixed right now because I am in a meeting with the CEO.”
Real situations have real constraints. But attackers use urgency to bypass careful thinking. If someone is truly in a critical meeting, they can wait 5 minutes for you to verify through a known channel.
Red Flag 3: The caller resists standard authentication procedures
“I cannot use email or Teams right now. Can you just text me the password?”
Standard SOP exists for a reason. If someone cannot follow it, you do not reset their access. Period.
Red Flag 4: The request is for an unfamiliar person
You do not know this employee. You have never helped them before. That does not mean the request is malicious, but it means you need to verify more carefully, not less.
Red Flag 5: Status check inconsistencies
The attacker said he had no Teams access. The real employee was online and in a meeting. One sentence revealed the con.
How to Stop It
1. Never reset credentials over the phone without proper verification
If someone calls asking for a password reset, the answer is always the same: “I will send a verification code to your registered email and phone number. Please check both.”
Then actually send it. If they cannot access those channels, they cannot access their account.
2. Use number matching for MFA push notifications
Do not just ask users to approve a push. Show them a number on their device and a number in the app. They must match. This defeats MFA fatigue attacks.
3. Verify through independent channels
If a VP calls for an urgent password reset, hang up and call them back at the number in your directory. Do not use a number the caller provided.
4. Train help desk staff to trust their instincts
If something feels off, it probably is. A strange request, a sense of urgency, an inconsistency: these are reasons to escalate, not to rush.
5. Implement conditional access policies
Require MFA from unfamiliar locations. Require additional verification for privilege account changes. Do not make help desk staff the only gatekeeper.
6. Audit password reset logs monthly
Who reset whose password? When? From where? Unusual patterns reveal ongoing attacks.
The Bigger Picture
The attacker in the original story lost because one person paid attention. He did not gloss over the inconsistency. He checked. He escalated.
That is not heroic. That is SOP working as intended.
But it is rare enough that it made Reddit. Most organizations do not catch these attacks in real time. They catch them after a breach, after lateral movement, after data exfiltration.
The cost of missing one social engineering attack is not a reset password. It is potentially millions in remediation, downtime, and reputation damage.
Your help desk is not your security weakness. They are your first line of defense. Give them the tools, the training, and the permission to slow down and verify.
Because attackers are counting on speed. They are counting on pressure. They are counting on the assumption that real data equals real identity.
Do not let them assume wrong.
Action Items
- Review your password reset SOP with your help desk team
- Implement number matching for MFA push notifications
- Set up conditional access policies for privilege account changes
- Conduct a social engineering simulation (safe, controlled, with consent)
- Audit password reset and privilege logs for the last 90 days
- Brief your leadership team on this attack vector (they need to know why verification takes 5 minutes)