Threat Intelligence Guidance from the Frontlines: Proactive Defense Against ShinyHunters-Branded Data Theft Targeting SaaS January 30, 2026 Mandiant Mandiant Services Stop attacks, reduce risk, and advance your security. Contact Mandiant Introduction Mandiant is tracking a significant expansion and escalation in the operations of threat clusters associated with ShinyHunters-branded extortion. As detailed in our companion report, 'Vishing for Access: Tracking the Expansion of ShinyHunters-Branded SaaS Data Theft' , these campaigns leverage evolved voice phishing (vishing) and victim-branded credential harvesting to successfully compromise single sign-on (SSO) credentials and enroll unauthorized devices into victim multi-factor authentication (MFA) solutions. This activity is not the result of a security vulnerability in vendors' products or infrastructure. Instead, these intrusions rely on the effectiveness of social engineering to bypass identity controls and pivot into cloud-based software-as-a-service (SaaS) environments. This post provides actionable hardening , logging , and detection recommendations to help organizations protect against these threats. Organizations responding to an active incident should focus on rapid containment steps, such as severing access to infrastructure environments, SaaS platforms, and the specific identity stores typically used for lateral movement and persistence. Long-term defense requires a transition toward phishing-resistant MFA , such as FIDO2 security keys or passkeys, which are more resistant to social engineering than push-based or SMS authentication. Containment Organizations responding to an active or suspected intrusion by these threat clusters should prioritize rapid containment to sever the attacker’s access to prevent further data exfiltration. Because these campaigns rely on valid credentials rather than malware, containment must prioritize the revocation of session tokens and the restriction of identity and access management operations. Immediate Containment Actions Revoke active sessions: Identify and disable known compromised accounts and revoke all active session tokens and OAuth authorizations across IdP and SaaS platforms. Restrict password resets: Temporarily disable or heavily restrict public-facing self-service password reset portals to prevent further credential manipulation. Do not allow the use of self-service password reset for administrative accounts. Pause MFA registration: Temporarily disable the ability for users to register, enroll, or join new devices to the identity provider (IdP). Limit remote access: Restrict or temporarily disable remote access ingress points, such as VPNs, or Virtual Desktops Infrastructure (VDI), especially from untrusted or non-compliant devices. Enforce device compliance: Restrict access to IdPs and SaaS applications so that authentication can only originate from organization-managed, compliant devices and known trusted egress locations. Implement 'shields up' procedures: Inform the service desk of heightened risk and shift to manual, high-assurance verification protocols for all account-related requests. In addition, remind technology operations staff not to accept any work direction via SMS messages from colleagues. During periods of heightened threat activity, Mandiant recommends that organizations temporarily route all password and MFA resets through a rigorous manual identity verification protocol, such as the live video verification described in the Hardening section of this post. When appropriate, organizations should also communicate with end-users, HR partners, and other business units to stay on high-alert during the initial containment phase. Always report suspicious activity to internal IT and Security for further investigation. 1. Hardening Defending against threat clusters associated with ShinyHunters-branded extortion begins with tightening manual, high-risk processes that attackers frequently exploit, particularly password resets, device enrollments, and MFA changes. Help Desk Verification Because these campaigns often target human-driven workflows through social engineering, vishing, and phishing, organizations should implement stronger, layered identity verification processes for support interactions, especially for requests involving account changes such as password resets or MFA modifications. Threat actors have also been known to impersonate third-party vendors to voice phish (vish) help desks and persuade staff to approve or install malicious SaaS application registrations. As a temporary measure during heightened risk, organizations should require verification that includes the caller’s identity, a valid ID, and a visual confirmation that the caller and ID match. To implement this, organizations should require help desk personnel to: Require a live video call where the user holds a physical government ID next to their face. The agent must visually verify the match. Confirm the name on the ID matches the employee’s corporate record. Require out-of-band approval from the user's known manager before processing the reset. Reject requests based solely on employee ID, SSN, or manager name. ShinyHunters possess this data from previous breaches and may use it to verify their identity. If the user calls the helpdesk for a password reset, never perform the reset without calling the user back at a known good phone number to prevent spoofing. If a live video call is not possible, require an alternative high-assurance path. It may be required for the user to come in person to verify their identity. Optionally, after a completed interaction, the help desk agent can send an email to the user’s manager indicating that the change is complete with a picture from the video call of the user who requested the change on camera. Special Handling for Third-Party Vendor Requests Mandiant has observed incidents where attackers impersonate support personnel from third-party vendors to gain access. In these situations, the standard verification principals may not be applicable. Under no circumstances should the Help Desk move forward with allowing access. The agent must halt the request and follow this procedure: End the inbound call without providing any access or information Independently contact the company's designated account manager for that vendor using trusted, on-file contact information Require explicit verification from the account manager before proceeding with any request End User Education Organizations should educate end users on best practices especially when being reached out directly without prior notice. Conduct internal Vishing and Phishing exercises to validate end user adoption of security best practices . Educate that passwords should not be shared, regardless of who is asking for it. Encourage users to exercise extreme caution when being requested to reset their own passwords and MFA; especially during off-business hours. If they are unsure of the person or number they are being contacted by, have them cease all communications and contact a known support channel for guidance. Identity & Access Management Organizations should implement a layered series of controls to protect all types of identities. Access to cloud identity providers (IdPs), cloud consoles, SaaS applications, document and code repositories should be restricted since these platforms often become the control plane for privilege escalation, data access, and long-term persistence. This can be achieved by: Limiting access to trusted egress points and physical locations Review and understand what “local accounts” exist within SaaS platforms: Ensure any default username/passwords have been updated according to the organization’s password policy. Limit the use of ‘local accounts’ that are not managed as part of the organization’s primary centralized IdP. Reducing the scope of non-human accounts (access keys, tokens, and non-human accounts) Where applicable, organizations should implement network restrictions across non-human accounts. Activity correlating to long-lived tokens (OAuth / API) associated with authorized / trusted applications should be monitored to detect abnormal activity. Limit access to organization resources from managed and compliant devices only. Across managed devices: Implement device posture checks via the Identity Provider. Block access from devices with prolonged inactivity. Block end users ability to enroll personal devices. Where access from unmanaged devices is required, organizations should: Limit non-managed devices to web only views. Disable ability to download/store corporate/business data locally on unmanaged personal devices. Limit session durations and prompt for re-authentication with MFA. Rapid enhancement to MFA methods, such as: Removal of SMS, phone call, push notification, and/or email as authentication controls. Requiring strong, phishing resistant MFA methods such as: Authenticator apps that require phishing resistant MFA (FIDO2 Passkey Support may be added to existing methods such as Microsoft Authenticator.) FIDO2 security keys for authenticating identities that are assigned privileged roles. Enforce multi-context criteria to enrich the authentication transaction. Examples include not only validating the identity, but also specific device and location attributes as part of the authentication transaction. For organizations that leverage Google Workspace, these concepts can be enforced by using context-aware access policies. For organizations that leverage Microsoft Entra ID, these concepts can be enforced by using a Conditional Access Policy. For organizations that leverage Okta, these concepts can be enforced by using Okta policies and rules. Attackers are consistently targeting non-human identities due to the limited number of detections around them, lack of baseline of normal vs abnormal activity, and common assignment of privileged roles attached to these identities. Organizations should: Identi