Why Attackers Are Bypassing Phishing Emails and Targeting Identity Instead

One of the fastest growing initial access techniques we are seeing right now is Okta vishing: voice-based social engineering designed to compromise the identity provider rather than the inbox.

This shift is redefining initial access, turning what was once an account compromise into an immediate data breach scenario.

Instead of sending phishing emails or deploying malware, attackers simply call the victim or the IT help desk and convince them to weaken or reset multi-factor authentication (MFA).

Once the identity provider is compromised, attackers inherit trusted access across the organization’s SaaS environment through Single Sign-On (SSO). In many cases, this quickly leads to SharePoint and OneDrive data exfiltration, making this far more than just an authentication event.

What is Okta Vishing?

Okta vishing is a form of voice phishing where an attacker impersonates IT support or an employee in order to manipulate MFA settings or account access.

Attackers attempt to convince the victim or help desk to:

• Reset MFA

• Enroll a new authenticator device

• Provide one-time passcodes (OTPs)

• Approve push notifications

• Disclose passwords

• Add attacker-controlled authentication methods

• Reset Okta credentials

• Provide password reset links

• Disclose session cookies

Once access to Okta is obtained, attackers often gain immediate access to downstream applications connected through SSO.

Commonly impacted platforms include:

• Microsoft 365

• SharePoint

• OneDrive

• Salesforce

• Google Workspace

• Slack

• VPN portals

• HR platforms

Because the trust relationship already exists, the attacker does not need to exploit each application individually.

Why Okta Vishing Is Increasing

Attackers have recognized a simple reality: MFA works, until humans are socially engineered.

Instead of attempting to bypass MFA technically, threat actors convince users or help desks to weaken authentication protections on their behalf.

Several factors contribute to the effectiveness of these attacks: 

• Help desks are incentivized to resolve access issues quickly

• Remote work environments normalize authentication troubleshooting

• Employee roles and contact details are easily obtained online

• LinkedIn provides a detailed organizational context

• Company org charts often reveal internal structure

• Attackers can convincingly impersonate executives or new employees

As identity providers become the central control plane for SaaS access, they have become a primary target.

Typical Okta Vishing Attack Flow

Figure 1. Okta vishing attack chain.

Step 1: Reconnaissance

Threat actors gather information about the organization and its employees, including:

• Employee names

• Job titles

• Phone numbers

• Help desk contact details

• Okta tenant naming patterns

• Internal terminology

Common sources include:

• LinkedIn

• Company websites

• ZoomInfo

• Prior breach data breach

• Previously compromised credentials

   

Step 2: Social Engineering Call

Attackers contact the victim or IT help desk, posing as:

• An employee locked out of their account

• An executive traveling who needs urgent access

• A contractor who cannot log in

• An employee who recently changed phones

• A user whose authenticator app stopped working

Common pretexts include:

• “I got a new phone and can’t access Okta.”

• “My authenticator app got wiped.”

• “I’m traveling and got locked out of VPN.”

• “My MFA keeps failing and I have a client meeting in 10 minutes.”

The attacker creates urgency to pressure support staff into bypassing standard verification procedures.

Step 3: MFA Manipulation

The attacker convinces the user or help desk to:

• Reset MFA settings

• Enroll a new authentication device

• Add an attacker-controlled phone number

• Approve push notifications

• Verbally provide OTP codes

• Disable phishing-resistant MFA controls

This step effectively transfers account control to the attacker.

Step 4: SSO Pivot into SaaS Applications

Once authenticated to Okta, attackers inherit trust relationships across connected applications.

Common targets include:

• Microsoft 365

• SharePoint

• OneDrive

• Google Drive

• Salesforce

• Slack

Because SSO authentication is already established, the attacker can immediately begin accessing corporate data.

Step 5: Data Access or Persistence

Post-compromise behaviors frequently include:

• Downloading SharePoint data

• Exporting email

• Creating inbox rules

• Registering OAuth applications

• Generating API tokens

• Adding secondary MFA methods

• Creating email forwarding rules

This often results in large-scale cloud data theft rather than traditional malware deployment.

Why This Leads to SharePoint and OneDrive Data Exfiltration

Compromise of an identity provider often results in immediate access to cloud-hosted corporate data.

Once authenticated, attackers commonly access:

• SharePoint document libraries

• OneDrive storage

• Microsoft Teams files

• Internal wiki platforms

• CRM systems

• Document repositories

As a result, Okta compromise frequently becomes a cloud data theft event rather than a traditional account takeover incident.

DFIR Indicators of Okta Vishing-Related Compromise

Identity Indicators

• MFA reset events without clear justification

• New device enrollment shortly before suspicious activity

• MFA method changes followed by abnormal login behavior

• Login from unfamiliar ASN after MFA reset

• Help desk ticket activity preceding compromise

   

M365 Indicators Following SSO Pivot

• Abnormal SharePoint access volume

• Large OneDrive downloads

• Unfamiliar IP addresses accessing multiple SaaS platforms

• OAuth application consent shortly after login

• Multiple SaaS logins occurring within minutes of MFA reset

How to Defend Against Okta Vishing

Defending against identity-focused social engineering requires controls that go beyond traditional phishing protections. Organizations should:

• Strengthen Verification and Access Controls

• Enforce strict identity verification for MFA resets, password resets, and device enrollment

• Implement step-up verification for high-risk actions such as MFA changes or recovery factor resets

• Train help desk staff on vishing tactics and high-risk scenarios (urgent lockouts, new device requests, travel scenarios)

• Require phishing-resistant MFA (e.g., passkeys, FIDO2 security keys, Windows Hello)

• Apply conditional access policies based on device posture, geolocation, IP reputation, and risk signals

• Restrict self-service recovery options that can be socially engineered

• Limit the number of users with permission to reset MFA or authentication factors

• Require manager approval or ticket validation for sensitive authentication changes
  

• Reduce Identity Attack Surface
• Disable legacy authentication protocols that bypass modern MFA protections
• Restrict OAuth application consent and monitor for newly authorized apps
• Periodically review existing MFA methods and remove unused or high-risk factors (SMS, voice)
• Audit administrative roles and remove standing Global Admin privileges where possible
• Require device registration or compliant device status for access to sensitive SaaS apps
• Expand Detection to the Identity Layer
• Ingest identity provider logs (e.g., Okta) into SIEM or security analytics platforms
• Correlate identity activity with SaaS, cloud, VPN, and endpoint telemetry
• Monitor for key signals such as:
  • MFA reset events
  • New device enrollment
  • Recovery factor changes
  • Authentication policy modifications
  • Logins from new locations, ASN, or unfamiliar geolocation

• Alert on abnormal sequences, such as MFA reset followed by rapid access to multiple SaaS applications

• Monitor for abnormal OAuth token creation or API activity following authentication changes

• Align SOC and MDR to Identity Threats
• Ensure detection and response workflows explicitly include identity-based attack scenarios
• Validate that MDR coverage extends beyond EDR to identity providers and SaaS environments
• Prioritize rapid investigation of authentication changes, not just malware alerts
• Develop playbooks for suspected social engineering incidents involving help desk interaction
• Establish procedures to quickly revoke sessions, reset credentials, and remove unauthorized MFA methods

Identity is the new battleground, and Okta vishing is just one example of how attackers are shifting their focus from exploiting systems to exploiting trust. Read more about my Identity 2026 predictions here.