Proactive Defense Against ShinyHunters-Branded Data Theft Targeting SaaS

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: 

• Identify and track all programmatic identities and their usage across the environment, including where they are created, which systems they access, and who owns them.

• Centralize storage in a secrets manager (cloud-native or third-party) and prevent credentials from being embedded in source code, config files, or CI/CD pipelines.

• Restrict authentication IPs for programmatic credentials so they can only be used from trusted third-party or internal IP ranges wherever technically feasible.

• Transition to workload identity federation: Where feasible, replace long-lived static credentials (such as AWS access keys or service account keys) with workload identity federation mechanisms (often based on OIDC). This allows applications to authenticate using short-lived, ephemeral tokens issued by the cloud provider, dramatically reducing the risk of credential theft from code repositories and file systems.

• Enforce strict scoping and resource binding by tying credentials to specific API endpoints, services, or resources. For example, an API key should not simply have “read” access to storage, but be limited to a particular bucket or even a specific prefix, minimizing blast radius if it is compromised.

• Baseline expected behavior for each credential type (typical access paths, destinations, frequency, and volume) and integrate this into monitoring and alerting so anomalies can be quickly detected and investigated.

Additional platform-specific hardening measures include: 

• Okta

• Enable Okta ThreatInsight to automatically block IP addresses identified as malicious.

• Restrict Super Admin access to specific network zones (corporate VPN).

• Microsoft Entra ID

• Implement common Conditional Access Policies to block unauthorized authentication attempts and restrict high-risk sign-ins.

• Configure risk-based policies to trigger password changes or MFA when risk is detected.

• Restrict who is allowed to register applications in Entra ID and require administrator approval for all application registrations.

• Google Workspace

• Use Context-Aware Access levels to restrict Google Drive and Admin Console access based on device attributes and IP address.

• Enforce 2-Step Verification (2SV) for all Google Workspace users.

• Use Advanced Protection to protect high-risk users from targeted phishing, malware, and account hijacking.

Infrastructure and Application Platforms 

Infrastructure and application platforms such as Cloud consoles and SaaS applications are frequent targets for credential harvesting and data exfiltration. Protecting these systems typically requires implementing the previously outlined identity controls, along with platform-specific security guardrails, including:

• Restrict management-plane access so it’s only reachable from the organization’s network and approved VPN ranges.

• Scan for and remediate exposed secrets, including sensitive credentials stored across these platforms.

• Enforce device access controls so access is limited to managed, compliant devices.

• Monitor configuration changes to identify and investigate newly created resources, exposed services, or other unauthorized modifications.

• Implement logging and detections to identify:

• Newly created or modified network security group (NSG) rules, firewall rules, or publicly exposed resources that enable remote access.

• Creation of programmatic keys and credentials (e.g., access keys).

• Disable API/CLI access for non-essential users by restricting programmatic access to those who explicitly require it for management-plane operations.

Platform Specifics

• GCP

• Configure security perimeters with VPC Service Controls (VPC-SC) to prevent data from being copied to unauthorized Google Cloud resources even if they have valid credentials.
  
  Set additional guardrails with organizational policies and deny policies applied at the organization level. This stops developers from introducing misconfigurations that could be exploited by attackers. For example, enforcing organizational policies like “iam.disableServiceAccountKeyCreation” will prevent generating new unmanaged service account keys that can be easily exfiltrated.

• Apply IAM Conditions to sensitive role bindings. Restrict roles so they only activate if the resource name starts with a specific prefix or if the request comes during specific working hours. This limits the blast radius of a compromised credential.

• AWS

  • Apply Service Control Policies (SCPs) at the root level of the AWS Organization that limit the attack surface of AWS services. For example, deny access in unused regions, block creation of IAM access keys, and prevent deletion of backups, snapshots, and critical resources.

  • Define data perimeters through Resource Control Policies (RCPs) that restrict access to sensitive resources (like S3 buckets) to only trusted principals within your organization, preventing external entities from accessing data even with valid keys.

  • Implement alerts on common reconnaissance commands such as GetCallerIdentity API calls originating from non-corporate IP addresses. This is often the first reconnaissance command an attacker runs to verify their stolen keys.

• Azure
  • Enforce Conditional Access Policies (CAPs) that block access to administrative applications unless the device is “Microsoft Entra hybrid joined” and “Compliant.” This prevents attackers from accessing resources using their own tools or devices.
  • Eliminate standing admin access and require Just-In-Time (JIT) through Privileged Identity Management (PIM) for elevation for roles such as Global Administrator, mandating an approval workflow and justification for each activation.
  • Enforce the use of Managed Identities for Azure resources accessing other services. This removes the need for developers to handle or rotate credentials for service principals, eliminating the static key attack vector.
• Source Code Management
  • Enforce Single Sign-On (SSO) with SCIM for automated lifecycle management and mandate FIDO2/WebAuthn to neutralize phishing. Additionally, replace broad access tokens with short-lived, Fine-Grained Personal Access Tokens (PATs) to enforce least privilege.
  • Prevent credential leakage by enabling native “Push Protection” features or implementing blocking CI/CD workflows (such as TruffleHog) that automatically reject commits containing high-entropy strings before they are merged.
  • Mitigate the risk of malicious code injection by requiring cryptographic commit signing (GPG/S/MIME) and mandating a minimum of two approvals for all Pull Requests targeting protected branches.
  • Conduct scheduled historical scans to identify and purge latent secrets that evaded preventative controls, ensuring any compromised credentials are immediately rotated and forensically investigated.
• Salesforce