Storm-3350 used a legitimate password reset to take over a cloud account and register its own authenticator. The operator signed in within minutes of the reset and completed the account’s existing phone-based check. It then added a sign-in method it controlled. That registration gave the attacker a way to return without relying on the employee’s phone again.
The campaign has affected organizations in Brazil since October 2026, primarily in finance, payments, banking, and digital assets. Activity also reached healthcare, transportation, and logistics. After taking over accounts, the operator mapped cloud services and collected files at scale. Some of its searches targeted credentials that could open access to other systems.
Password Recovery Opened the Account
Voice phishing or impersonation can start the intrusion. In a confirmed case, the operator changed the password through the legitimate self-service password reset flow. It then used the account’s existing SMS or voice method to satisfy multifactor authentication, or MFA, during sign-in.
Recovery and sign-in are separate steps. During recovery, the identity service checks whether the account can use self-service reset. It also checks whether the user can verify their identity through the methods the organization requires. Depending on the policy, recovery can require one or two methods. The campaign evidence leaves the exact recovery checks for the affected account unspecified.
Completing the later MFA challenge indicates that the operator could receive or intercept the phone verification. For example, social engineering involving an employee’s personal phone is one possible explanation. How the operator obtained the verification remains unknown.
An Added Authenticator Gave the Attacker a Way Back
After signing in, the operator registered an instance of Microsoft Authenticator it controlled. Enrollment changed the account’s security information. Future challenges could therefore go to the attacker’s authenticator, even if the employee still had the original phone and number.
Resetting the password gave the operator a password it knew. The additional method gave it a second factor it controlled. Together, those changes made the initial phone interaction dispensable for later sign-ins. The lasting change was in the account’s authentication settings, separate from the lifetime of any particular session.
Cloud Tokens Turned Sign-In Into Bulk Collection
Once inside, Storm-3350 used both browser sessions and automation. Its activity included Python and Node-style clients, OAuth-authenticated curl requests, and enumeration through the Azure command-line interface. Across the campaign, the operator identified accounts, applications, sites, drives, and mailboxes.
A browser lets an operator browse a site as the user. An access token, meanwhile, lets a client call the service’s API within the token’s permissions. For example, POST /search/query in Microsoft Graph can return matching SharePoint and OneDrive items. A separate request for a file’s content can return a temporary download URL. With delegated access, both the app’s granted permissions and the user’s access to the resource constrain those calls.
That separation makes collection easy to automate. A script can build a list of matching items, then retrieve the ones the operator wants. Observed activity included high-volume SharePoint and OneDrive file access. The exact requests and overall volume of data taken remain unspecified.
SharePoint Searches Looked for Keys
Among its searches, Storm-3350 looked for the string AKIA in SharePoint. That prefix identifies a long-term AWS access key ID. The identifier alone cannot sign requests. However, a file that also contains the matching secret could give an operator a route into whatever AWS resources that credential can reach.
The operator also accessed .key, .pem, and .ppk files. Those extensions can indicate key material, but a filename alone establishes neither its contents nor whether any credential still works. These actions show an interest in reusable credentials alongside ordinary business documents. They leave open whether a usable AWS key turned up or whether the operator used one.
Azure Requests Targeted Storage and Deployment Credentials
Storm-3350 also requested Azure storage-account keys and application publishing profiles. A storage listKeys request goes to Azure’s management interface. If the caller has the required permission, the operation can return keys for the specified account. Where the account accepts Shared Key authorization, a valid key can sign later requests to the storage service itself.
Publishing profiles, meanwhile, can contain credentials scoped to an application’s deployment endpoint. If that endpoint accepts those credentials, they can authorize deployment independently of the original user’s interactive sign-in. The two requests therefore point toward different resources. One seeks a way to reach stored data. The other seeks a way to publish application content.
Available evidence establishes the requests. Whether they returned usable credentials or led to storage access or app changes remains unknown.
The Account Change Ties the Sequence Together
A password reset can occur during ordinary work. So can an authentication-method registration or a burst of file access. In this campaign, recovery came first, followed by a sign-in, a new method, and then token acquisition and cloud activity. The account ties those events together even when the requests come from different clients.
We previously examined a device-code phishing campaign that registered an unauthorized device. For Storm-3350, the recorded change concerns the account’s own authentication methods. The new entry marks the point where access stopped depending on the original phone.
Conclusion: A New MFA Method Extended the Takeover
Storm-3350 turned account recovery into control over future sign-ins. Within minutes of resetting the password, the operator signed in and completed the account’s existing phone challenge. It then registered an authenticator it controlled. That last step changed the account’s security information and gave the operator a way to answer later challenges.
After taking over accounts, the operator collected cloud files and requested Azure storage keys and publishing profiles. Whether those requests yielded usable credentials or led to further access remains unknown.
Why This Threat Matters
- Successful MFA can accompany a takeover. A success event shows that someone answered the challenge. Look for a new authentication method alongside that event to determine what changed.
- An enrollment can outlast a session. Revoking the user’s Entra sign-in sessions invalidates refresh tokens. Removing the attacker’s authenticator requires a separate change to the account.
- Ordinary cloud APIs support bulk collection. The operator could discover and retrieve accessible files through legitimate interfaces at a volume that warranted investigation.
- A file library can hold credentials for other services. Searching SharePoint for key material can expose access beyond the original account if the files hold usable secrets.
- Cloud roles can authorize sensitive management requests. For example, an identity with permission to list storage keys can retrieve a credential that signs data requests where Shared Key is enabled.
Where Defensive Control Must Operate
Xcitium ITDR monitors Microsoft 365 and Entra ID for abnormal sign-ins and supports analyst-led investigation. For example, analysts can compare the sign-in with password recovery and method enrollment records. They can then trace the same identity into cloud audit logs to determine which resources it reached.
Where impersonation starts the attack, Xcitium Cyber Awareness Education helps staff recognize unsolicited requests for verification codes and report them. Employees can verify a caller’s instructions through an established support channel before acting on an unexpected reset request.
Protect registration itself through Entra Conditional Access. With combined registration enabled, require an appropriate authentication strength for the security information registration action. Test the policy against legitimate enrollment and recovery flows before enforcement.
Verify Access Before Reopening the Account
Block new sign-ins during response. Remove the unauthorized method and revoke the user’s sessions. Check application sessions separately where the service manages its own access. Then review file downloads and Azure management activity around the enrollment time. If the logs show that a service returned a key or publishing credential, identify dependent workloads before rotating it. Restore sign-in after confirming that the employee controls the enrolled methods and checking for continued activity in the affected services.
