Vish helpdesk → Okta MFA reset → admin → ransomware (MGM-class)

§ Context

Assumed environment: target uses Okta as IdP with helpdesk able to reset MFA over phone with weak identity proofing. Several admin users have profiles visible on LinkedIn.

§ Steps

1. 01
   Push attacker payload via mgmt platformInitial Access

   T1078— Valid Accounts
2. 02
   Authenticate, register attacker factorPersistence

   T1098— Account Manipulation
3. 03
   LinkedIn OSINT on IT adminsReconnaissance

   W-RECON-GITHUB-DORK— GitHub / GitLab Dorking
4. 04
   Push policy / Conditional Access changesPrivilege Escalation

   C-AZ-RBAC-OWNER— Azure RBAC Owner Assignment
5. 05
   Vish helpdesk for MFA factor resetInitial Access

   SE-VISHING— Vishing (Voice Phishing)
6. 06
   Mass-encrypt ESXi + endpointsImpact

   HV-ESXI-RANSOM— ESXi Mass-Encrypt Ransomware
7. 07
   Helpdesk resets factorCredential Access

   APT-OKTA-SE— Identity-Provider Helpdesk SE (Scattered Spider)

§ References

• T1078Valid Accounts
• T1098Account Manipulation

§ Frequently asked

What is the "Vish helpdesk → Okta MFA reset → admin → ransomware (MGM-class)" attack path?

Identify an Okta admin via LinkedIn. Vish the helpdesk pretending to be that admin, get MFA reset. Sign in, plant attacker MFA factor, then push policy changes that disable MFA for chosen apps before mass-deploying ransomware. It chains 7 steps drawn from real-world offensive-security techniques.

What starting position does this attack require?

The first step is Push attacker payload via mgmt platform (T1078) — a initial access primitive. Assumed environment: target uses Okta as IdP with helpdesk able to reset MFA over phone with weak identity proofing.

What is the final impact of this kill-chain?

The final step lands on Helpdesk resets factor (APT-OKTA-SE), which falls under Credential Access. From here, an operator typically pivots into post-exploitation or maintains persistence.

How can defenders detect or prevent this attack?

Detection and prevention vary per step. Refer to each linked MITRE ATT&CK entry under "References" — every technique on that page lists defensive controls, detection telemetry, and known threat-actor usage.

§ Related dossiers

• Shared techniques4

  Vishing → helpdesk MFA reset → account takeover

  Pose as a panicked employee locked out before a meeting. Helpdesk resets MFA based on partial PII (employee ID + date of birth from LinkedIn). Attacker registers their own factor.

• Shared techniques2

  Mass SMS phish → Okta-style portal → SaaS sprawl (0ktapus)

  Wide SMS phishing campaign targeting employees of ~130 organisations with a single phishlet that captures Okta credentials + push approval. Mass automated logins to Twilio, MailChimp, DoorDash et al.

• Shared techniques2

  Dev workstation → cloud backup keys → encrypted vault store (LastPass 2022)

  Attacker compromised a single LastPass DevOps engineer's home machine via outdated Plex Media Server, harvested AWS keys for the encrypted-vault backup bucket, exfiltrated production vault data.

• Shared techniques2

  Build-system implant → signed supply-chain backdoor (SolarWinds-class)

  Compromise the target vendor's build server. A small implant rewrites a single source file at compile time — every official signed release downstream now ships the backdoor.

• Shared techniques2

  Insider admin panel coercion → mass account takeover (Twitter 2020)

  Identify employees with access to an internal admin panel. SE / coerce one to use the panel to change target accounts' email + 2FA, then take them over.

• Shared techniques2

  Slack token in CI log → DM history → vendor mailbox compromise

  A CI run echoed a Slack xoxb-/xoxp- token. Use it to read DMs, harvest password-reset links and vendor invitations, pivot into the corporate mailbox.