How Attackers Use Public Data to Social Engineer Credentials (And How to Stop Them) | C2XCEL Insights

Attackers are weaponizing LinkedIn, public records, and previous data breaches to sound legitimate during credential attacks. Here is how to spot the con before it costs your company millions.

A help desk technician 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 and possessed insider information. Consequently, the technician reset the Active Directory password without properly authenticating the user.

Then things became suspicious. When asked where to send the temporary password, the caller claimed he did not have access to email or Microsoft Teams. However, when the technician looked up the "VP" on Teams, the individual's status showed "In a meeting." The actual VP was online and actively presenting to colleagues.

The attacker was caught, but this incident reveals a trend that concerns IT leaders: attackers are no longer just cold-calling. They are using legitimate data about real individuals to pose as insiders.

How Attackers Obtain Your Employees' Information

This is not guesswork; it is intelligence gathering.

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 understands your organizational structure can cross-reference that data and call your help desk claiming to be a VP, providing a real home address and employee ID. While it sounds difficult to fake, it is not.

Other common data sources attackers utilize:

• Previous breaches: If your company was involved in a breach years ago, attackers may still possess that data.

• Public records: Property records, court filings, and business registrations are easily searchable.

• Job postings and company websites: These reveal organizational structures, team names, and reporting lines.

• Social media: Employees frequently post their employer, role, and manager’s name.

• Dark web paste sites: Raw database dumps from legacy breaches circulate for years.

The attacker in the story above utilized a LinkedIn breach from years past. He possessed a valid employee ID and home address. That credibility is what almost allowed the attack to succeed.

Why This Attack Vector Is Currently Dangerous

Social engineering has always been a threat, but the combination of three factors makes it particularly lethal today:

1. Real data is inexpensive and plentiful

Attackers can purchase bulk employee lists with verified information for minimal cost. They do not need to guess; they have the facts.

2. Help desk staff are under pressure

Technicians are often encouraged to take calls, verify users quickly, and move on. The help desk is a support function, not a dedicated security team. Under time pressure, verification shortcuts often occur.

3. MFA fatigue is a reality

Even when multi-factor authentication (MFA) is in place, attackers count on users (or admins) approving push notifications reflexively. Users see so many MFA prompts that the approval process becomes automatic.

The ideal attack uses real data to lower suspicion, targets someone under time pressure, and then uses that compromised account to send phishing emails or move laterally into the network.

How to Spot the Deception

The help desk technician in the story stopped this attack because he noticed an inconsistency: the caller claimed he did not have Teams access, yet Teams showed him as being online.

That level of attention is what prevents breaches.

Here are the primary red flags:

Red Flag 1: The caller provides unsolicited verification data

“I am John Smith, employee ID 45678, and I live at 123 Main Street.”

Legitimate employees do not typically offer this information without being prompted. An attacker is attempting to establish credibility quickly. If a caller volunteers specific data, verify it independently before resetting any credentials.

Red Flag 2: Urgency combined with unusual requests

“I need this fixed immediately because I am in a meeting with the CEO.”

While real emergencies occur, attackers use urgency to bypass critical thinking. If someone is truly in a critical meeting, they can wait several minutes for verification through a known channel.

Red Flag 3: Resistance to standard authentication procedures

“I cannot use email or Teams right now. Can you just text me the password?”

Standard Operating Procedures (SOPs) exist for a reason. If a caller cannot follow the established protocol, do not reset their access.

Red Flag 4: Requests for unfamiliar personnel

If you do not recognize the employee or have never assisted them before, it does not necessarily mean the request is malicious, but it does mean you need to verify their identity with greater care.

Red Flag 5: Status check inconsistencies

In the aforementioned scenario, the attacker claimed he had no Teams access while the real employee was online in a meeting. A single inconsistency revealed the con.

How to Prevent These Attacks

1. Never reset credentials over the phone without proper verification

If someone calls for a password reset, the response should be standard: “I will send a verification code to your registered email and phone number. Please check both.”

If they cannot access those registered channels, they should not be granted access to the account.

2. Use number matching for MFA push notifications

Do not simply ask users to approve a push notification. Require them to match a number shown on their workstation with one in the mobile app. This significantly mitigates MFA fatigue attacks.

3. Verify through independent channels

If an executive calls for an urgent password reset, end the call and reach out to them via the phone number listed in your official internal directory. Never use a number provided by the caller.

4. Train help desk staff to trust their instincts

If a request feels suspicious, it likely is. Unusual requests, manufactured urgency, and data inconsistencies are valid reasons to escalate a ticket rather than rushing to completion.

5. Implement conditional access policies

Require MFA for logins from unfamiliar locations and implement additional verification for changes to privileged accounts. The help desk should not be the sole gatekeeper.

6. Audit password reset logs monthly

Review who reset passwords, when, and from which locations. Identifying unusual patterns can reveal ongoing or attempted attacks.

The Bigger Picture

The attacker in the original story failed because one employee paid attention to detail. He did not ignore the inconsistency; he investigated and escalated.

This is the SOP working as intended.

However, it is rare enough to be noteworthy. Most organizations do not identify these attacks in real time; they discover them after a breach, lateral movement, or data exfiltration has already occurred.

The cost of a successful social engineering attack is far greater than a reset password. It involves potentially millions of dollars in remediation, downtime, and reputational damage.

Your help desk is not a security weakness; it is your first line of defense. Provide them with the tools, training, and institutional permission to slow down and verify identities.

Attackers rely on speed, pressure, and the assumption that having real data equates to having a real identity. Professional IT leadership ensures those assumptions are wrong.

Action Items

• Review password reset SOPs with your help desk team.

• Implement number matching for MFA push notifications.

• Establish conditional access policies for privileged account changes.

• Conduct controlled social engineering simulations.

• Audit password reset and privilege logs for the last 90 days.

• Brief your leadership team on this attack vector to ensure they understand why verification protocols are necessary.