, , , ,

Social Engineering and Microsoft SSPR: The Road to Pwnage is Paved with Good Intentions 

| John Malone

John Malone is a penetration tester for Black Hills Information Security. He regularly performs external, internal, and social engineering-based assessments. His favorite tools are confidence and charisma.

Social Engineering and Microsoft SSPR

Introduction

Most organizations treat Microsoft Self-Service Password Reset (SSPR) and push-based MFA as pure wins: fewer help desk tickets, less lockout drama, and more convenience for everyone. You’d think everyone would win here, right? 

It might seem that way at a high level, but when I worked in physical security, it became clear that with more convenience often came less security. The same concept, it seems, holds true here. 

In this blog, we’ll look at a social engineering technique that combines Microsoft SSPR with social engineering phone calls to gain initial access to Microsoft 365. The best part? The tester will never need to talk to the help desk. 

We’ll cover: 

  • How the ruse works (from a red team perspective) 
  • Why it’s so effective psychologically 
  • How to scope and run it ethically in an engagement 
  • Why this should be part of regular social engineering testing 

Legal / ethical note: Everything here is for authorized testing and defense only. Using these techniques without explicit written permission is illegal and unethical. Don’t be that person. Don’t be a jerk. 

The Technique

Let’s get right to it. At a high level, the attack looks like this: 

  1. The attacker performs reconnaissance and checks to see if the target’s tenant has Microsoft SSPR enabled. This is done by visiting https://aka.ms/sspr and entering a valid username and solving a captcha. 
Microsoft SSPR Access Interface
  1. If successful, options will appear that allow you to specify how you would like to reset the user’s password. This can come in the form of entering a number provided by SSPR (extremely potent, as you can tell call targets that you are “assigning them a security code”), security questions configured by the user, or accepting a push notification or phone call. 
Options for Account Reset
  1. The attacker calls the user, claiming to be from the service desk / security team following up on a security issue. 
  2. The attacker coaches the user into approving the MFA prompts as part of a “verification.” 
  3. After the MFA is approved, the attacker resets the user’s password via SSPR. 
Assigning a New Password
  1. The attacker logs into Microsoft 365 with the new password, then lies to the user and says they did not receive the first push and will need the employee to send another. 
MFA Code for Target
  1. To keep the user quiet, the attacker gives the user “their new password” and instructs them to reset all devices and then change it again later. 
  2. The user feels in control, and so the call goes unreported while the tester now has initial access. 
Initial Access in Microsoft 365

From the user’s perspective, this all feels normal: 

“IT called me, said there was an issue, sent me MFA prompts and a new password. They fixed it.” 

From a red team / attacker perspective, it’s a clean path to initial access that completely bypasses help desk hardening. 

How the Ruse Works in Practice 

Below is a conceptual walkthrough that you can adapt into a RoE-approved playbook. I’ve sorted this into a list of bullet points because I’m pretty sure that’s going to be easier reading than a giant wall of text 😊. 

1. Start with a Rules of Engagement Call 

Before you do anything, ensure you and your client have a rules of engagement call and that you: 

  • Define scope clearly: 
    • Which tenant(s) and user groups are in scope? 
    • Is anyone specifically out of scope? 
  • Describe the ruse explicitly: 
    • You, the tester, will: 
      • Trigger SSPR flows for users. 
      • Cause unsolicited MFA prompts on their devices. 
      • Call them and use a help desk / security pretext. 
      • Reset passwords and log into Microsoft 365 if possible. 
  • Get buy-in on the why: 
    • This ruse: 
      • Bypasses help desk identity-verification policies entirely. 
      • Exploits users’ trust in IT and their familiarity with push-based MFA. 
      • Tests whether training has addressed this specific flavor of social engineering. 

Document everything. The customer should understand exactly what you’re about to simulate and why. 

2. Recon: Is SSPR Even in Play? 

There’s no point running this scenario if: 

  • SSPR isn’t enabled, 
  • Targets don’t have SSPR/MFA registered, or 
  • The reset flow requires factors you can’t realistically influence. 

Your pretext plan doesn’t need exact policy values, but you do need to know: 

  • Is SSPR enabled for the tenant? 
  • Do targeted users appear to have SSPR/MFA set up? 

If the tenant doesn’t use SSPR, this specific chain is off the table, and you pivot to a different vector. If it is in play, you now know there’s a viable path worth testing. 

3. Establish a Plausible Caller Identity 

The phone call makes or breaks this attack. 

  • Number and caller ID: 
    Use a number strategy that the client has approved in the RoE: 
    • It should look like something the user wouldn’t immediately distrust. 
    • It doesn’t need to spoof their exact help desk number, but it must be plausible. 
      • Speaking of spoofing, make sure you get written permission to do this also if you plan on doing it. 
  • Persona: 
    Decide who you are: 
    • “IT Service Desk” 
    • “Security Operations Center” 
    • “Incident Response Team” 
    • Attempt to find any documentation or mention of IT on the company website or in available documents. Sometimes, you’ll find a hint that will help your introduction appear more legitimate.
  • Story: 
    A simple, believable line is enough: 
    • “We’ve seen some unusual sign-in activity and we’re calling users to verify access.” 
    • “We’re doing a quick security check-in due to some suspicious login attempts.” 

4. Make Your Target Comfortable 

When the target picks up: 

  • Introduce yourself and build rapport. 
    • Name, team, purpose of call. 
    • Optional light humor or other social engineering tactics to disarm: 
      • “I’m guessing you’re not working from China today, right?” 
  • Frame the situation as urgent but not catastrophic. 
    • “We’ve had a few suspicious logins from outside the country, and we’re doing a quick validation.” 
    • “This should only take a couple of minutes so we can make sure your account doesn’t get locked.” 
  • Set expectations about the prompts. 
    • “You’re going to see a couple of security prompts on your phone. I’ll let you know when they go through, and I just need you to approve them while we’re on the line.” 

While you’re talking, you initiate the SSPR verification for their account so that the MFA push notifications appear right on cue. 

The psychological levers here are classic: 

  • Authority: You’re “IT” or “Security.” 
  • Urgency: There is an incident, and they don’t want their account locked. 
  • Altruism: They feel like they’re helping fix a problem. 
  • Control: The real cornerstone of this ruse. The ruse is designed to keep the target feeling in control at all times. They are not providing you with confidential information and still have control over their workstation and mobile device. From their perspective, all they are doing is proving they can control their authenticator and account. And then after the password change occurs, they have the new password. No problem, right? That is why I almost never see this ruse get reported. 

5. Coaching MFA Approvals 

Modern users are trained to approve MFA pushes. The twist here is that: 

  • They didn’t initiate the sign-in flow. 
  • You’re telling them that you initiated it for security reasons. 

You walk them through it: 

  • “You should see a prompt from Microsoft now.” 
  • “Go ahead and approve that so we can verify it’s really you.” 
  • “If you see another one right after, approve that one as well — the system can be a bit finicky.” 

Once the first MFA step is complete, SSPR considers the user verified and allows a password reset. After the second, the tester now has initial access. 

6. Resetting the Password and Gaining Access 

With verification done, you set a new password and: 

  • Attempt to log into Microsoft 365 / Entra ID from your test infrastructure. 
  • Observe how Conditional Access reacts: 
    • Do you get straight in from any IP? 
    • Are you blocked/challenged because your device isn’t compliant? 
    • Are there location or risk-based conditions? 

If Conditional Access is permissive, you now have initial access. 

If CA is stricter, the test still yields valuable data: 

  • You’ve proven that a social engineer can successfully reset an account password. 
  • You can then measure how well CA policies limit the blast radius of that compromise. 

7. Reassurance as Insurance 

To reduce the likelihood that your call is reported, help the target feel good about the call and reassure them. 

Once you’ve logged in and confirmed access: 

  • Give the user “their new password.” 
    • “Okay, we’ve successfully secured your account. Your new temporary password is: [redacted].” 
  • Frame follow-up actions as best practice. 
    • “I’d like you to log out of all your devices, wait a bit so everything syncs, and then change this password to something only you know.” 
  • Create a small delay. 
    • Asking them to “wait an hour” or similar before changing the password: 
      • Feels like a technical requirement to them. 
      • Gives the attacker a window to operate. 
      • Reduces the chance they immediately call the real help desk and expose the ruse. 

From the user’s perspective, this was just a mildly annoying but helpful security call. Nothing seems “incident-worthy.” 

Why This Works So Well 

This pattern is effective because it sits at the intersection of help desk and system controls and end-user trust. Many organizations train help desk staff to resist social engineering, but this attack completely bypasses the help desk and goes directly to the user, who may have minimal social engineering awareness training. 

Because this technique is psychologically manipulative and touches live user accounts, it deserves extra care. 

Most importantly, users should always receive positive coaching if they are compromised on a social engineering test. Negative options such as termination rarely work out well for anyone in the long-term, as the replacement might fall into the same trap later. 

The goal here should always be learning and building a stronger security culture. 

How Do We Defend Against This Tactic? 

The easy answer is to simply disable Microsoft SSPR. However, that may not be an option for some. In that case, users should be coached not to accept MFA prompts that they did not initiate and to always call the purported caller back at a number the callee is already familiar with to try and confirm if the call was legitimate or not.

If someone says they are from the help desk, hang up and call back. 

Brief Case Study: Social Engineering Campaign 

A recent penetration test was carried out using the techniques in this blog. The tester made a total of 6 social engineering calls, with every single call resulting in initial access. The tester introduced themselves as a help desk member, made a joke about the user “not testing from China, right?“, and then used the moment of humor to pivot into a need to do a quick security check. SSPR was then used to generate two-digit numbers to be entered into Microsoft Authenticator. The tester gave these numbers to the employees, who entered them into their phone. 

After gaining access, the penetration tester was able to access Microsoft Outlook and obtain personally identifiable information (social security numbers, birth dates, home address) of client customers and to send emails to the tester and point of contact’s email to prove that compromise had occurred. The tester also gained access to SharePoint, which resulted in the retrieval of internal documents containing sensitive information. Lastly, the tester pivoted into Microsoft Teams and used the platform to send messages to their point of contact. 

Why This Should Be Tested Regularly 

This isn’t a one-time stunt for a cool red team report. It’s a vector that deserves ongoing attention because: This scenario simultaneously tests identity confirmation tooling (SSPR, MFA, Conditional Access), how users act under pressure, and the organization’s ability to detect and follow-up on social engineering attacks. 

If you’d be interested in seeing how your organization would stand up to a social engineering campaign, consider giving our friendly consulting team a call! 

Ready to learn more?

Level up your skills with affordable classes from Antisyphon!

Pay-Forward-What-You-Can Training

Available live/virtual and on-demand