Social Engineering Attacks on IT Helpdesks: A Defence Guide

Your IT helpdesk is the front door to your entire organisation. And right now, sophisticated threat groups are knocking.

Social engineering attacks targeting IT helpdesks have surged over the past two years. Groups like Scattered Spider and SLSH (Scattered Lapsus$ Hunters) have refined their tactics to the point where a single phone call to your service desk can lead to a full network compromise. In February 2026, SLSH was caught actively recruiting people with specific voice profiles to improve their success rate against helpdesk staff, offering up to $1,000 per successful call.

This is not theoretical. The MGM Resorts breach in 2023, which cost the company over $100 million, started with a social engineering call to the IT helpdesk. The attacker impersonated an employee, convinced the helpdesk analyst to reset their MFA, and within hours had access to critical systems.

If your helpdesk verification process relies on "What is your employee ID?" and "What department are you in?", you are already compromised. You just do not know it yet.

---

Why Helpdesks Are the Perfect Target

IT helpdesks exist to help people. That is both their purpose and their vulnerability. Helpdesk analysts are trained to resolve issues quickly, measured on ticket resolution times, and culturally conditioned to be helpful. Attackers exploit every one of these traits.

The Information Asymmetry Problem

A caller who has done basic reconnaissance on LinkedIn, corporate websites, and data breach dumps can sound convincingly like an employee. They know names, job titles, reporting lines, and sometimes even internal project names. The helpdesk analyst, meanwhile, is handling dozens of calls per day and has no reliable way to verify the caller is who they claim to be.

This asymmetry is the core of the problem. The attacker needs to know just enough to sound credible. The analyst needs absolute certainty to refuse help, but the culture punishes them for being difficult.

The MFA Reset Attack Vector

The most common social engineering attack against helpdesks targets multi-factor authentication resets. The attacker calls claiming they have lost access to their MFA device, asks for a temporary bypass or reset, and uses that window to establish persistent access.

This attack works because MFA resets are routine. Helpdesks process them daily. There is no alarm bell that rings when the fifteenth MFA reset request of the day comes in, even though one of those fifteen might be an attacker.

Voice Phishing Is Getting Smarter

Traditional vishing relied on confidence and aggression. Modern vishing is far more sophisticated. Threat groups now use:

• AI-generated voice cloning to mimic specific employees
• Recruited callers with particular voice profiles to match expected demographics
• Detailed scripts refined through repeated testing against real helpdesks
• Callback numbers that appear to come from internal extensions

The SLSH recruitment drive in February 2026 specifically sought female voices, likely because their existing caller pool did not match the demographic profile helpdesk staff expected from certain roles. This level of tactical refinement shows how seriously these groups treat social engineering as a discipline.

---

The Anatomy of a Helpdesk Social Engineering Attack

Understanding how these attacks unfold helps you build defences that address each stage.

Stage 1: Reconnaissance

The attacker gathers information about the target organisation. Sources include LinkedIn profiles, corporate websites, press releases, job postings, social media, and data from previous breaches. They identify a specific employee to impersonate, ideally someone who would plausibly call the helpdesk.

Stage 2: Pretext Development

The attacker builds a believable story. Common pretexts include:

• "I am travelling and my laptop was stolen. I need my password and MFA reset urgently."
• "I just started in the London office and cannot log into my account."
• "My phone broke and I cannot receive MFA codes. I have a board presentation in an hour."

The urgency is deliberate. It pressures the analyst to skip verification steps.

Stage 3: The Call

The attacker calls the helpdesk, delivers their pretext, and provides enough identifying information to satisfy basic verification. They may know the employee's ID number, manager's name, and recent projects. If challenged, they escalate emotionally or invoke authority ("My director needs this done now").

Stage 4: Exploitation

Once the helpdesk resets the credential or MFA, the attacker logs in, enrolls their own MFA device, and begins lateral movement. The entire process from initial call to persistent access can take under thirty minutes.

---

Building Helpdesk Defences That Actually Work

I have implemented helpdesk security improvements across multiple organisations. The following strategies are practical, tested, and effective.

1. Replace Knowledge-Based Verification

Knowledge-based verification ("What is your employee ID?") is broken. Attackers can find or buy this information. Replace it with verification methods that are resistant to social engineering:

• Video call verification for high-risk actions like MFA resets. The analyst confirms the caller's identity visually against their HR photo.
• Manager callback verification where the analyst hangs up and calls the employee's manager to confirm the request.
• Hardware token verification where the employee must present a physical token or smart card that cannot be socially engineered over the phone.
• Push notification verification where a notification is sent to the employee's registered device and they must approve it before the helpdesk proceeds.

The key principle is that verification should rely on something the attacker cannot obtain through research alone.

2. Implement Tiered Request Handling

Not every helpdesk request carries the same risk. Create tiers:

This approach means your helpdesk is not applying the same friction to a printer query as to an MFA reset.

3. Train for Social Engineering Specifically

Generic security awareness training is not enough. Your helpdesk team needs specific social engineering training that covers:

• Red flags to watch for: urgency, authority claims, emotional pressure, reluctance to verify through alternative channels
• Common pretexts: the scripts attackers actually use, updated regularly based on threat intelligence
• Practice scenarios: regular tabletop exercises where analysts role-play both attacker and defender
• Permission to say no: explicit backing from management that analysts will never be punished for following verification procedures, even if it delays a legitimate user

This last point is critical. If your helpdesk analysts fear negative feedback for being "unhelpful", they will prioritise speed over security every time. Leadership must make it clear that proper verification is not optional, and that no one, regardless of seniority, is exempt.

4. Deploy Technical Controls

Technical controls complement procedural defences:

• Caller ID verification integrated with your phone system to flag calls from external numbers claiming to be internal employees
• Automatic cooldown periods for MFA resets, where the new MFA device cannot be enrolled for a set period (e.g. four hours), giving the real employee time to notice
• Anomaly detection on helpdesk ticket patterns, flagging unusual volumes of reset requests or requests for the same user from different channels
• Audit logging of all identity verification steps taken during each request, creating accountability and enabling post-incident review

5. Run Regular Social Engineering Tests

You test your network with penetration tests. You should test your helpdesk with social engineering assessments. Engage a reputable firm to call your helpdesk using realistic pretexts and measure:

• How many calls bypass verification procedures
• How long analysts take to identify suspicious requests
• Whether analysts follow escalation procedures when uncertain
• How well the tiered verification model holds under pressure

Use the results constructively, not punitively. The goal is continuous improvement, not blame.

---

The Identity Verification Framework

For organisations building a formal programme, I recommend structuring your approach around three pillars:

Something They Have

A registered device, hardware token, or smart card that the attacker cannot replicate remotely. This is your strongest verification factor for remote interactions.

Something They Know (But Cannot Research)

Move away from static information like employee IDs. Consider dynamic verification such as details from the employee's most recent IT ticket, or a one-time verification code sent to their registered email.

Something They Are

Video verification, voice biometrics, or in-person confirmation. These are the hardest for attackers to defeat, though AI voice cloning means voice alone is no longer sufficient.

A robust verification framework combines at least two of these pillars for any high-risk request. This aligns directly with an identity-first security strategy where identity verification becomes the primary control plane.

---

Lessons from Real Breaches

MGM Resorts (2023)

A single vishing call to the helpdesk led to an MFA reset, which gave Scattered Spider access to the Okta environment. From there, they compromised the entire network. The total cost exceeded $100 million. The fix? MGM subsequently implemented video verification for all MFA resets.

Caesars Entertainment (2023)

Similar tactics, same threat group. Caesars paid a $15 million ransom. Both attacks demonstrated that even large enterprises with significant security budgets were vulnerable at the helpdesk layer.

Coinbase (2025)

Attackers used SMS phishing combined with voice calls to helpdesk staff. Coinbase's security team detected the attack because an analyst flagged the interaction as suspicious. The difference was training and a culture that rewarded caution.

These cases reinforce a core principle of building a cybersecurity culture: technical controls fail without the human layer, and the human layer fails without leadership support.

---

Quick Wins You Can Implement This Week

If you cannot overhaul your helpdesk verification overnight, start with these:

1. Add a mandatory callback step for MFA resets. The analyst hangs up and calls the employee's registered number before processing the request.
2. Brief your helpdesk team on current threats. Share the SLSH recruitment news and the MGM case study. Real examples are more impactful than abstract warnings.
3. Implement a four-hour cooldown on MFA enrolment after any reset, giving the real employee time to notice and report unauthorised changes.
4. Review your verification questions. If any of them can be answered using LinkedIn or a data breach dump, replace them.
5. Tell your team it is acceptable to say no. Send an email from the CIO or IT Director explicitly stating that following verification procedures is always the right call, even if it inconveniences someone senior.

These steps cost nothing but time, and they close the most exploited gaps immediately.

---

The Bigger Picture

Social engineering attacks on IT helpdesks are not going away. As organisations strengthen their technical defences, attackers will increasingly target the human layer. AI voice cloning, deepfake video, and crowdsourced social engineering will make these attacks harder to detect.

The organisations that defend successfully will be those that treat helpdesk security as a core part of their zero trust architecture, not an afterthought. In a zero trust model, every access request is verified regardless of source. Your helpdesk should operate on the same principle: every caller is untrusted until proven otherwise.

Invest in your people. Give them the training, tools, and institutional backing to challenge suspicious requests. Because the next call to your helpdesk might not be from an employee at all.