{“lastseen”:”2026-05-19T00:58:42″,”description”:”In this article\\n\\n 1. Attack chain overview\\n 1. Cloud compromise: Microsoft Entra ID and Microsoft 365\\n 2. Initial access and persistence through targeted social engineering and SSPR abuse\\n 3. Directory discovery and persistence\\n 4. Microsoft 365 discovery and exfiltration\\n 5. Cloud compromise: Microsoft Azure\\n 6. Azure App Service and Key Vault compromise\\n 7. Azure Storage and SQL data exfiltration\\n 8. Azure Virtual Machines compromise\\n 9. ScreenConnect installation and defense evasion\\n 10. Post-compromise activity using ScreenConnect\\n 2. Mitigation and protection guidance\\n 1. Ensure adequate security coverage across attack surfaces\\n 2. Security hardening and best practices\\n 3. General hygiene recommendations\\n 4. Indicators of compromise (IOCs)\\n 5. Microsoft Defender XDR detections\\n 3. Learn more\\n\\n\\n\\nMicrosoft Threat Intelligence recently uncovered a methodical, sophisticated, and multi-layered attack, where a threat actor we track as Storm-2949 launched a relentless campaign with a singular focus: to exfiltrate as much sensitive data from a target organization\u2019s high-value assets as possible. The attack exfiltrated data from Microsoft 365 applications, file-hosting services, and Azure-hosted production environments, where the organization\u2019s production application ecosystem resides.\\n\\nWhat began as a targeted identity compromise rapidly evolved into a full-spectrum assault on the organization\u2019s cloud infrastructure. The attack spanned various Azure resources, with emphasis on software-as-a-service (SaaS), platform-as-a-service (PaaS), and infrastructure-as-a-service (IaaS) layers. \\n\\nStorm-2949 didn\u2019t rely on traditional malware and other on-premises tactics, techniques, and procedures (TTPs). Instead, they leveraged legitimate cloud and Azure management features to gain control-plane and data-plane access, which they then used to execute code remotely on VMs, and access sensitive cloud resources such as Key Vaults and storage accounts, among others. These activities allowed them to move laterally across cloud and endpoint environments while blending into expected administrative behavior.\\n\\nAs organizations continue to adopt cloud infrastructure at scale, threat actors are increasingly targeting identity and control plane access rather than individual devices. When cloud identities are compromised, legitimate administrative features can be used to achieve outcomes similar to traditional lateral movement, often with fewer indicators of compromise. Behavior-based detections across endpoints, cloud environments, and identities\u2014such as those provided by Microsoft Defender\u2014can help teams identify and correlate these activities.\\n\\nIn this blog, we unpack the full attack chain from initial access to cloud and endpoint takeover. We then offer actionable insights into how organizations can detect, contain, and prevent similar identity-driven threats in their environments.\\n\\n## Attack chain overview\\n\\nThe campaign that Storm-2949 deployed can be divided into two phases: targeted identity compromise and cloud infrastructure compromise. We discuss each of these phases in detail in the succeeding sections.\\n\\nFigure 1. Storm-2949 attack diagram.\\n\\n### Cloud compromise: Microsoft Entra ID and Microsoft 365\\n\\nIn this phase, the threat actor targeted specific users through social engineering to obtain their Microsoft Entra ID credentials. Using these credentials, the threat actor then proceeded to exfiltrate data from Microsoft 365 applications.\\n\\n### Initial access and persistence through targeted social engineering and SSPR abuse\\n\\nWe assess with high confidence that Storm-2949 leveraged a social engineering technique consistent with known abuses of Microsoft\u2019s Self-Service Password Reset (SSPR) process. In such attacks, a threat actor initiates the SSPR process on behalf of a targeted user and subsequently employs social engineering tactics to persuade the user to complete multifactor authentication (MFA) prompts that appear to be legitimate.\\n\\nFor example, the threat actor might impersonate an internal information technology (IT) support representative and contact the user claiming that their account requires urgent verification, instructing them to approve MFA prompts as part of a routine password reset procedure. \\n\\nOnce the user approves these prompts, the threat actor is able to reset the user’s password and remove existing authentication methods, such as phone numbers, email addresses, and Microsoft Authenticator registrations, effectively eliminating MFA as a control and enabling unrestricted account access. Immediately after gaining access to the compromised account, the threat actor is then prompted to re-enable MFA and register a new authentication method. At this stage, the threat actor enrolls Microsoft Authenticator on their own device, granting themselves persistent access and preventing the legitimate user from signing in.\\n\\nStorm-2949 used a similar process repeatedly across multiple users within the targeted organization. The selection of victims, which included IT personnel and senior leadership, indicated deliberate targeting. Based on the roles of the compromised users and the investigation findings, we assess that the threat actor likely used an organized and convincing phishing scheme to lure users into completing the fraudulent MFA prompts and thereby compromise their identities.\\n\\n### Directory discovery and persistence\\n\\nFollowing the initial identity takeover, the threat actor conducted directory discovery using Microsoft Graph API. Using a custom Python script, they issued automated API requests to enumerate users and applications within the tenant. Through these queries, the threat actor searched Microsoft Entra ID for user accounts based on name patterns and role attributes, likely to identify privileged identities and additional high\u2011value targets.\\n\\nFigure 2 illustrates the types of Graph API queries observed:\\n\\nFigure 1. Discovery using cURL.\\n\\nDuring this attack phase, the threat actor also attempted to establish persistence by adding credentials to a compromised service principal to enable continued access independent of the compromised user accounts. This attempt failed due to insufficient permissions. Undeterred, the threat actor continued enumerating service principals and known application identifiers, indicating an effort to map application\u2011level access paths and expand long\u2011term footholds within the environment. \\nUsing the same social engineering techniques and SSPR abuse described earlier, the threat actor expanded their foothold by compromising three additional cloud user accounts.\\n\\n### Microsoft 365 discovery and exfiltration\\n\\nStorm-2949 leveraged their access to the compromised user accounts to explore and exfiltrate files from the victim organizations\u2019 cloud file storage services. Shortly after obtaining initial access within the organization, they targeted Microsoft 365 applications, including OneDrive and SharePoint, identifying and accessing the organization\u2019s sensitive files, focusing on IT documents concerning virtual private network (VPN) configurations and remote access procedures. We assess that this behavior reflects an attempt to identify opportunities for lateral movement from a compromised cloud identity into the endpoint network.\\n\\nThe threat actor then launched a large-scale data exfiltration from these storage services. In one instance, Storm-2949 used the OneDrive web interface to download thousands of files in a single action to their own infrastructure. This pattern of data theft was repeated across all compromised user accounts, likely because different identities had access to different folders and shared directories.\\n\\n### Cloud compromise: Microsoft Azure\\n\\nArmed with access to multiple compromised identities \u2013 which were assigned with privileged custom Azure role-based access control (RBAC) roles on several Azure subscriptions \u2013 and a growing understanding of the environment, the threat actor shifted focus toward the victim\u2019s Azure environment. With a clear agenda centered on data exfiltration, Storm-2949 demonstrated a relentless drive to uncover and extract the most sensitive assets within the victim\u2019s Azure environment, specifically from production-based Azure subscriptions. \\n\\nTheir campaign targeted not only core applications but also the broader ecosystem of interconnected resources such as Azure App Services web applications, Azure Key Vaults, Azure Storage accounts, and SQL databases. These resources collectively power the organization\u2019s cloud-hosted services. This phase marked a transition from identity-centric abuse and SaaS data theft to targeting a range of Azure services, with an emphasis on both PaaS and IaaS workloads.\\n\\n### Azure App Service and Key Vault compromise\\n\\nOne of Storm-2949\u2019s main targets was a production Azure App Service web application that contained sensitive data. Following several failed attempts to access this application, likely due to gateway and network restrictions, Storm-2949 shifted focus to other web apps that appeared to be part of the same ecosystem. These auxiliary apps, such as those handling authentication or internal APIs, were individually deployed Azure App Service instances with their own resource identities.\\n\\nStorm-2949 successfully compromised several of these secondary web apps by taking advantage of the user\u2019s privileged Azure RBAC permissions and invoking the Azure management-plane operation, microsoft.Web\/sites\/publishxml\/action, which retrieves the application\u2019s publishing profile. This profile often contains basic authentication credentials for deployment endpoints such as FTP, Web Deploy, and the Kudu management console. Kudu is a built-in administrative interface for Azure App Services that allows authenticated users to browse the file system, inspect environment variables, and execute commands within the app\u2019s context.\\n\\nDespite successfully compromising several of these auxiliary web apps, Storm-2949 was unable to gain access to the primary production application they were ultimately targeting. It is assesed, that the secondary services, while part of the same broader ecosystem, didn\u2019t contain the level of sensitive data or privileged access the threat actor was seeking. While these footholds provided visibility into application configurations and infrastructure, they didn\u2019t deliver the high-value assets that aligned with the threat actor’s data exfiltration objectives. As a result, the threat actor was forced to pursue alternative paths in their effort to reach the production web app.\\n\\nStorm-2949 recalibrated their approach and shifted their focus toward backend resources that were part of the sensitive web app ecosystem and could provide stronger leverage. The threat actor pivoted to the organization\u2019s Azure Key Vault estate \u2013 an environment more likely to centralize sensitive secrets and offer indirect access to production systems. Part of the compromised user\u2019s Azure RBAC permissions was the privileged Owner role over a specific Key Vault that seemed to contain credentials that would enable the compromise of the production application.\\n\\nOver the span of four minutes, the threat actor successfully manipulated Key Vault access configurations and accessed dozens of secrets within the said Key Vault. These secrets included database connection strings, identity credentials, and more, dramatically expanding the attack\u2019s blast radius.\\n\\nAmong these secrets, we believe the threat actor found credentials that enabled them to access the application they coveted the most, which was the main production web app. After they successfully authenticated into the web app, the threat actor changed its password to retain control. They then began exfiltrating sensitive data from it.\\n\\n### Azure Storage and SQL data exfiltration\\n\\nIn parallel, Storm-2949 expanded access across additional cloud resources inside the ecosystem that contained the web app, including Azure Storage accounts and an Azure SQL server.\\n\\nTo enable access to the server, the threat actor abused their existing Azure RBAC permissions to manipulate the SQL server firewall rules by using the microsoft.sql\/servers\/firewallrules\/write operation. They then connected to the SQL server using the credentials they obtained (along with the web app credentials) from the compromised Key Vault.\\n\\nThe threat actor proceeded with data exfiltration and continued to delete the modified SQL firewall rules, which is an activity consistent with defense evasion. \\nSimilar to the SQL server compromise, to set up and prepare for massive data exfiltration from Azure Storage, the threat actor also manipulated storage account network access configurations using the microsoft.storage\/storageaccounts\/write operation. This manipulation enabled public access to the storage accounts from a closed set of threat actor-owned IP addresses. In addition, the threat actor abused the Azure management-plane operation microsoft.Storage\/storageAccounts\/listkeys\/action to access multiple storage account Shared Access Signature (SAS) tokens and account keys, enabling the use of static, non-interactive authentication to retrieve data.\\n\\nUsing these keys, the threat actor downloaded large volumes of data from several Azure Storage accounts using a custom Python script that leveraged the Azure SDK for Storage. The script allowed them to programmatically enumerate and download blobs directly to their own endpoint device. This storage\u2011based exfiltration continued over multiple days since the initial access, with the threat actor alternating between secret- and OAuth\u2011based authentication as access conditions and controls evolved.\\n\\n### Azure Virtual Machines compromise\\n\\nApart from the web app and data-store resource compromise, the abuse of Azure Virtual Machine (VM) extensions and administrative features \u2013 specifically Run Command and the VMAccess extension \u2013 were also prominent elements of this attack. These activities appear to have been primarily intended to expand operational access within the victim environment by leveraging compromised VMs as intermediary footholds. Observed actions across these systems focused on credential harvesting and environment discovery, as well as attempts to access resources that weren\u2019t directly reachable through previously compromised identities. These efforts included domain reconnaissance and the collection of authentication material that could facilitate movement between cloud and on\u2011premises environments, as well as enable access to additional high\u2011value assets.\\n\\nShortly after the initial access, the threat actor operated in parallel, trying to compromise the organization\u2019s virtual machines. Using the compromised users assigned with privileged Azure RBAC permissions, the threat actor deployed the VMAccess extension to create a new local administrator account on a targeted VM. VMAccess is an Azure VM extension intended to help administrators restore access to a VM when credentials get lost or misconfigured by allowing password resets or the addition of privileged local users through the Azure management plane. In this case, the threat actor abused the extension to gain backdoor access to an administrator user on the VM.\\n\\nUsing the Run Command feature, the threat actor deployed a script attempting to abuse the VM\u2019s managed identity by requesting an access token from the Azure Instance Metadata Service (IMDS) and using it to authenticate to \u2013 and retrieve secrets from \u2013 the production web app-related Key Vault. However, the threat actor wasn\u2019t able to retrieve the secrets because the managed identity lacked the required permissions. Yet, this attempt shows the threat actor using guest-level execution as a bridge to additional Azure resource access through workload identity.\\n\\nFigure 2. Token theft and Key Vault access script.\\n\\n### ScreenConnect installation and defense evasion\\n\\nStorm-2949 further abused the Run Command by running a PowerShell script intended to deploy persistent remote access while reducing host-based security visibility on multiple VMs.\\n\\nThe script attempted to weaken Microsoft Defender Antivirus by disabling several protections, including real-time protection and behavior monitoring, and by interfering with its associated service. These changes lowered the likelihood that subsequent activity would be blocked or generate actionable alerts on the device.\\n\\nThe script then installed the ScreenConnect remote monitoring and management (RMM) tool obtained from threat actor-controlled infrastructure. The installation process included several steps intended to masquerade the tool\u2019s presence, such as making the network request appear consistent with trusted software updates and placing files in locations intended to resemble legitimate system content.\\n\\nTo further obscure the tool\u2019s presence, the script attempted to rename or configure the installed service to resemble legitimate Windows components, providing a simple form of local masquerading.\\n\\nFinally, the script attempted cleanup actions to remove local forensic artifacts that could be attributed to the threat actor. These included clearing Windows event logs, removing execution artifacts, and deleting command history and temporary files. Such steps are commonly observed in post-compromise activity and are generally intended to complicate investigation rather than provide durable evasion.\\n\\n### Post-compromise activity using ScreenConnect\\n\\nThe threat actor used the deployed ScreenConnect to launch commands across multiple compromised devices, performing basic discovery. This included collecting host level details (for example, operating system and configuration information) and enumerating domain context such as user accounts and group memberships.\\n\\nAcross a subset of those hosts, the threat actor focused on credential harvesting techniques. They discovered and exfiltrated .pfx certificate files – artifacts that might contain private keys and could be valuable for follow-on access if imported or reused elsewhere. In parallel, they searched for remote file shares for likely credential exposure by scanning files for password related strings. Not every collection effort occurred on every host; rather, it was distributed across systems based on what data and access each host provided.\\n\\nThese actions show ScreenConnect being used as a practical execution channel to run discovery, collect credentials, and attempt to operationalize access across different devices.\\n\\nWhile the threat actor ultimately established execution on several endpoints, these systems didn\u2019t appear to yield high value data aligned with their objectives. The endpoint activity primarily served as a secondary capability for discovery and credential harvesting, rather than a core exfiltration channel.\\n\\nThroughout this incident, Microsoft Defender generated multiple alerts that helped analysts piece together activity across endpoints and cloud. Defender correlated these signals into unified incidents, surfacing high-fidelity alerts and a coherent view of threat actor activity. This kind of cross-domain correlation \u2013 collecting and normalizing telemetry and linking related alerts \u2013 illustrates the value of an integrated detection and response approach for improving signal-to-noise clarity and end-to-end visibility.\\n\\n## Mitigation and protection guidance\\n\\nThe visibility provided by correlated alerts across identities, cloud, and endpoints can help organizations investigate and understand attacks end-to-end. Building on this visibility, organizations can reduce risk and limit the impact of similar attacks by deploying appropriately scoped detection and response capabilities (including Microsoft Defender where applicable) and by applying targeted hardening practices.\\n\\n### Ensure adequate security coverage across attack surfaces\\n\\nTo effectively detect and respond to attacks that span identity, cloud, and endpoint environments, organizations should ensure they have monitoring, detection, and response capabilities deployed and properly configured across those surfaces. The following examples describe how Microsoft Defender capabilities can be used to help with this; equivalent controls might be available in other security solutions.\\n\\nUse Microsoft Defender for Endpoint for:\\n\\n * Tamper protection enabled to prevent threat actors from stopping security services such as Defender for Endpoint, which can help prevent hybrid cloud environment attacks.\\n * Endpoint detection and response (EDR) in block mode so that Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus doesn\u2019t detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts detected post-breach.\\n * Investigation and remediation in full automated mode to allow Defender for Endpoint to take immediate action on alerts to help remediate alerts, significantly reducing alert volume.\\n\\n\\n\\nUse Microsoft Defender for Cloud to protect your cloud resources and assets from malicious activity, both in posture management (Microsoft Defender Cloud Security Posture Management), and threat detection capabilities. Enable workload protection capabilities across cloud resources, including:\\n\\n * Microsoft Defender for Resource Manager\\n * Microsoft Defender for App Service\\n * Microsoft Defender for Key Vault\\n * Microsoft Defender for Storage\\n * Microsoft Defender for Databases\\n * Microsoft Defender for Servers\\n\\n\\n\\nIn addition, leverage the Microsoft Defender XDR to hunt for threats across cloud environments and resource with advanced hunting. Security teams can proactively investigate threat actor activity by querying telemetry across multiple domains using tables such as CloudAuditEvents, CloudStorageAggregatedEvents, and others, enabling deep visibility into control-plane and data-plane operations, authentication events, and cross-service attack patterns.\\n\\nUse Microsoft Defender for Cloud Apps and enable connectors to monitor SaaS activity.\\n\\n### Security hardening and best practices\\n\\nIn addition to deploying the appropriate Defender capabilities, organizations should apply the following security controls and practices to mitigate similar attack paths:\\n\\n#### **Identity protection**\\n\\n * Secure accounts with credential hygiene. Practice the principle of least privilege and audit privileged account activity in your Microsoft Entra ID and Azure environments to slow or stop threat actors.\\n * Enable Conditional Access policies. Conditional Access policies are evaluated and enforced every time the user attempts to sign in. Organizations can protect themselves from attacks that leverage stolen credentials by enabling policies such as device compliance or trusted IP address requirements.\\n * Ensure MFA is required for all users. Adding more authentication methods, such as the Microsoft Authenticator app or a phone number, increases the level of protection if one factor is compromised.\\n * Ensure phishing-resistant MFA strength is required for Administrators and privileged user accounts.\\n * Ensure all existing privileged users have an already registered MFA method to protect against malicious MFA registrations\\n * Implement Conditional Access authentication strength to require phishing-resistant authentication for employees and external users for critical apps.\\n * Refer to Azure Identity Management and access control security best practices for further steps and recommendations to manage, design, and secure cloud environment.\\n * Turn on Microsoft Entra ID protection to monitor identity-based risks and create risk-based Conditional Access policies to remediate risky sign-ins.\\n\\n\\n\\n#### **Cloud resource protection**\\n\\n * Use the Azure Monitor activity log to investigate and monitor Azure management events.\\n * Configure and harden resources firewall rules and access controls to allow access only from trusted IP ranges and virtual networks to prevent unauthorized access.\\n * Use Azure policies to continuously enforce the hardened configurations.\\n * Practice and apply Azure Storage security best practices:\\n * Use Azure policies for Azure Storage to prevent network and security misconfigurations and maximize the protection of business data stored in your storage accounts.\\n * Implement Azure Blob Storage security recommendations for enhanced data protection.\\n * Use the options available for data protection in Azure Storage.\\n * Enable immutable storage for Azure Blob Storage to protect from accidental or malicious modification or deletion of blobs or storage accounts.\\n * Enable Azure Monitor for Azure Blob Storage to collect, aggregate, and log data to enable recreation of activity trails for investigation purposes when a security incident occurs or network is compromised.\\n * Use private endpoints for Azure Storage account access to disable public network access for increased security.\\n * Avoid using anonymous read access for blob data.\\n * Enable Azure blob backup to protect from accidental or malicious deletions of blobs or storage accounts.\\n * Apply the principle of least privilege when authorizing access to blob data in Azure Storage using Microsoft Entra and RBAC and configure fine-grained Azure Blob Storage access for sensitive data access through Azure attribute-based access control (ABAC).\\n * Practice and apply Azure Key Vault security best practices:\\n * Enable purge protection in Azure Key Vaults to prevent immediate, irreversible deletion of vaults and secrets. Use the default retention interval of 90 days.\\n * Enable logs in Azure Key Vault and retain them for up to a year to enable recreation of activity trails for investigation purposes when a security incident occurs or network is compromised.\\n * Restrict public network access to Azure Key Vault by enabling private endpoints and disabling public access to reduce exposure to unauthorized access attempts.\\n * Regularly audit Azure RBAC role assignments and Key Vault access policies, depending on the Key Vault permission model, to ensure least privilege and detect over-permissioned identities. Microsoft explicitly recommends Azure RBAC over Key Vault access policies. \\n * Configure SQL server firewall rules to restrict access to known IP addresses and monitor for unauthorized changes to firewall configurations.\\n * Enforce authentication through Microsoft Entra ID for SQL instances to reduce reliance on static credentials and improve access control\\n * Practice and apply Azure App Service security best practices:\\n * Disable legacy authentication methods and enforce managed identity usage for Azure App Services to prevent credential theft through publishing profiles.\\n * Monitor and restrict access to Azure App Service publishing credentials by limiting RBAC permissions and auditing usage of the publish profile API.\\n * Enable diagnostic logging in App Service logs to detect suspicious deployment or configuration changes.\\n * Enable Microsoft Azure Backup for virtual machines to protect the data on your Microsoft Azure virtual machines, and to create recovery points that are stored in geo-redundant recovery vaults.\\n * Audit and restrict the use of Azure VM features and extensions such as Run Command and VMAccess by limiting RBAC permissions and monitoring for suspicious invocation patterns.\\n * Use Azure Policy to restrict or audit the deployment of Azure VM extensions across your subscriptions.\\n\\n\\n\\n### General hygiene recommendations\\n\\n * Investigate Microsoft Security Exposure Management attack paths. Security teams can use attack path analysis to trace cross-domain threats that pivot to cloud workloads, escalate privileges, and expand their reach.\\n * Use Azure Policy to enforce organizational standards and prevent the deployment of risky configurations, such as public access to sensitive resources.\\n * Implement consistent cloud security recommendations hygiene.\\n\\n\\n\\n### Indicators of compromise (IOCs)\\n\\nIOCs reflect observations at the time of analysis and may not be exhaustive or persistent.\\n\\n**Indicator**| **Type**| **Description** \\n—|—|— \\n176.123.4[.]44| IP address| Attacker egressed from this address \\n91.208.197[.]87| IP address| Attacker egressed from this address \\n185.241.208[.]243| IP address| ScreenConnect instance used by Attacker \\n \\n### Microsoft Defender XDR detections\\n\\nMicrosoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.\\n\\nCustomers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.\\n\\nNote that the following detections only covers the threat activities we\u2019ve observed at the time of analysis.\\n\\n**Tactic******| **Observed activity******| **Microsoft Defender coverage****** \\n—|—|— \\nInitial access| \u2013 Sign-in activity from attacker infrastructure to compromised identities \\n \\n\u2013 Sign-in and authentication activity to Azure resources | **Microsoft Defender XDR** \\n- Authentication with compromised credentials \\n- Compromised user account in a recognized attack pattern \\n- Malicious sign in from a risky IP address \\n- Malicious sign in from an IP address associated with recognized attacker infrastructure \\n- Malicious sign in from recognized attacker infrastructure \\n- Malicious sign-in from an unusual user agent \\n- Malicious sign-in from known threat actor IP address \\n- Successful authentication from a malicious IP \\n- Successful authentication from a suspicious IP \\n- Successful authentication using compromised credentials \\n- User compromised through session cookie hijack \\n- User signed in from a known malicious IP Address \\n- Impossible Travel \\n \\n**Microsoft Defender for Identity** \\n- Possibly compromised user account signed in \\n- Possibly compromised service principal account signed in \\n \\n**Microsoft Defender for Cloud** \\n**_Defender for Resource Manager_** \\nSuspicious invocation of a high-risk \u2018Initial Access\u2019 operation detected (Preview) \\n \\n**_Defender for Databases_** \\nLogin from an unusual location \\n \\n** _Defender for Storage_** \\n- Access from an unusual location to a storage account Access from an unusual location to a storage blob container \\n- Access from an unusual location to a sensitive blob container \\n- Access from a known suspicious IP address to a sensitive blob container \\n- Access from a suspicious IP address \\n- Unusual unauthenticated public access to a sensitive blob container \\nExecution| \u2013 Various types of execution-related suspicious activity by an attacker were observed| **Microsoft Defender XDR** \\n- Possibly compromised user ran a malicious script using an Azure VM extension \\n- Potential hybrid ransomware or hands-on-keyboard attack originating from Azure VM extensions \\n- Hybrid ransomware or hands-on-keyboard attack originating from Azure VM extensions \\n- Azure VM extension activity followed by ransomware or hands-on-keyboard attack \\n \\n**Microsoft Defender for Cloud** \\n**_Defender for Resource Manager_** \\n- Suspicious invocation of a high-risk ‘Execution’ operation detected (Preview) \\n- Azure Resource Manager operation from suspicious IP address \\n- Suspicious Run Command invocation detected (Preview) \\n \\n**_Defender for Servers P2_** \\n- Run Command with a suspicious script was detected on your virtual machine \\n- Suspicious Run Command usage was detected on your virtual machine (Preview) \\n- Suspicious unauthorized Run Command usage was detected on your virtual machine (Preview) \\n \\n**Microsoft Defender for Endpoint** \\n- Compromised account conducting hands-on-keyboard attack \\n- Potential human-operated malicious activity \\n- Suspicious process execution \\n- Suspicious command execution via ScreenConnect \\n- Suspicious activity through Azure VM extension process \\nPersistence| \u2013 Attacker device registered as MFA method \\n \\n\u2013 ScreenConnect installed on Azure VMs| **Microsoft Defender for Identity** \\n- Suspicious addition of default third\u2011party MFA method to user account \\n- Suspicious Entra device join or registration \\n \\n**Microsoft Defender for Cloud Apps** \\n- Suspicious addition of device with strong MFA \\n- Suspicious addition of strong authentication device \\n- Malicious device with strong MFA was registered \\n \\n**Microsoft Defender for Endpoint** \\nUncommon remote access software \\nDefense evasion| \u2013 Attempts to tamper with Microsoft Defender Antivirus \\n \\n\u2013 Manipulation of Azure Storage account, Key Vault, and SQL database configurations| **Microsoft Defender for Endpoint** \\n- Attempt to turn off Microsoft Defender Antivirus protection \\n- Attempt to clear event log \\n- Event log was cleared \\n \\n**Microsoft Defender for Cloud** \\n**_Defender for Resource Manager_** \\nSuspicious invocation of a high-risk \u2018Defense Evasion\u2019 operation detected (Preview) \\n \\n**_Defender for Key Vault_** \\nSuspicious policy change and secret query in a key vault \\nCredential access| \u2013 Secret extraction from Azure Key Vault \\n \\n\u2013 Attempted theft of workload identity tokens using Azure VM Run Command \\n \\n\u2013 Credential harvesting from endpoints through ScreenConnect \\n \\n\u2013 Publishing Azure App Service web app profile for credential access \\n \\n\u2013 Listing Azure storage account access keys for access | **Microsoft Defender Antivirus** \\n- Trojan:Win32\/SuspAdSyncAccess \\n- Backdoor:Win32\/AdSyncDump \\n- Behavior:Win32\/DumpADConnectCreds \\n- Trojan:Win32\/SuspAdSyncAccess \\n- Behavior:Win32\/SuspAdsyncBin \\n \\n**Microsoft Defender for Endpoint** \\n- Indication of local security authority secrets theft \\n- Password stealing from files \\n \\n**Microsoft Defender for Cloud** \\n**_Defender for Resource Manager_** \\nSuspicious invocation of a high-risk \u2018Credential Access\u2019 operation detected (Preview) \\n \\n**_Defender for Servers P2_** \\nRun Command with a suspicious script was detected on your virtual machine \\n \\n** _Defender for Key Vault_** \\n- Suspicious policy change and secret query in a key vault \\n- High volume of operations in a key vault \\n- Unusual application accessed a key vault \\n- Unusual operation pattern in a key vault \\n- Unusual user accessed a key vault \\n- Access from a suspicious IP address to a key vault \\nDiscovery| \\n\u2013 Domain and system discovery commands run on virtual machines| **Microsoft Defender for Endpoint** \\nSuspicious sequence of exploration activities \\n \\n**Microsoft Defender for Cloud Apps** \\nSuspicious file access \\nLateral movement| \u2013 Traversal between cloud resources and applications| **Microsoft Defender for Identity** \\nSuspicious sign-in to a web app following MFA phone number tampering activity \\n \\n**Microsoft Defender for Cloud Apps** \\nCompromised user accessed a SaaS application \\n \\n**Microsoft Defender for Cloud** \\n**_Defender for Resource Manager_** \\nSuspicious invocation of a high-risk \u2018Data Collection\u2019 operation detected (Preview) ** ** \\nExfiltration| \u2013 Data exfiltration from Azure Storage accounts and other resources \\n \\n\u2013 Data exfiltration from file storage services| **Microsoft Defender XDR** \\nSuspicious behavior: Mass download \\n \\n**Microsoft Defender for Cloud Apps** \\n- Suspicious massive data read \\n- Suspicious mass download from risky or unusual session \\n- Suspicious mass download from risky or unusual session \\n- Suspicious mass download from risky or unusual session \\n- Possible exfiltration of data archive \\n- Possible data exfiltration from a suspicious IP address \\n- Suspicious quantity of downloaded archive files \\n \\n**Microsoft Defender for Cloud** \\n**_Defender for Resource Manager_** \\nSuspicious invocation of a high-risk \u2018Data Collection\u2019 operation detected (Preview) \\n \\n**_Defender for Storage_** \\n- The access level of a potentially sensitive storage blob container was changed to allow unauthenticated public access \\n- Publicly accessible storage containers successfully discovered \\n- Publicly accessible storage containers unsuccessfully scanned \\n- Unusual amount of data extracted from a storage account \\n- Unusual data access activity \\n- Unusual amount of data extracted from a sensitive blob container \\n- Unusual number of blobs extracted from a sensitive blob container \\n- Potential data exfiltration detected \\n- Access from a suspicious IP address \\n \\n_This research is provided by Microsoft Defender Security Research with contributions from Adi Segal, Karam Abu Hanna, Alon Marom, and members of Microsoft Threat Intelligence._\\n\\n## Learn more\\n\\nFor the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.\\n\\nTo get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.\\n\\nTo hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.\\n\\nReview our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization. \\n\\nHow Microsoft discovers and mitigates evolving attacks against AI guardrails \\n\\nLearn more about securing Copilot Studio agents with Microsoft Defender \\n\\nEvaluate your AI readiness with our latest Zero Trust for AI workshop.\\n\\nLearn more about Protect your agents in real-time during runtime (Preview)\\n\\nExplore how to build and customize agents with Copilot Studio Agent Builder \\n\\nMicrosoft 365 Copilot AI security documentation \\n\\nThe post How Storm-2949 turned a compromised identity into a cloud-wide breach appeared first on Microsoft Security Blog.”,”published”:”2026-05-18T22:42:50″,”modified”:”2026-05-18T22:42:50″,”type”:”mssecure”,”title”:”How Storm-2949 turned a compromised identity into a cloud-wide breach”,”source”:””,”references”:””,”id”:”MSSECURE:5AD7A84325AFB86E0C1059E1736E3D0E”,”bulletinFamily”:”blog”,”cwe”:null,”cvelist”:[],”sourceData”:””,”sourceHref”:””,”cvss”:{“score”:0,”severity”:”NONE”,”vector”:”NONE”,”version”:”NONE”},”cvss2″:{},”cvss3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””,”cvssV3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””}},”href”:”https:\/\/www.microsoft.com\/en-us\/security\/blog\/2026\/05\/18\/storm-2949-turned-compromised-identity-into-cloud-wide-breach\/”,”category_name”:”News”,”post_link”:””,”product”:””,”version”:””,”vendor”:””,”ai_description”:””,”ai_severity”:””,”ai_vendor”:””,”ai_product”:””,”ai_version”:””,”ai_score”:0}<\/p>\n","protected":false},"excerpt":{"rendered":"
{“lastseen”:”2026-05-19T00:58:42″,”description”:”In this article\\n\\n 1. Attack chain overview\\n 1. Cloud compromise: Microsoft Entra ID and Microsoft 365\\n 2. Initial access and persistence through targeted social engineering…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[6,8,12,110,13,33,7,11,5],"class_list":["post-55404","post","type-post","status-publish","format-standard","hentry","category-category_news","tag-cve","tag-cvss","tag-exploit","tag-mssecure","tag-news","tag-none","tag-security","tag-tapic","tag-vulnerability"],"yoast_head":"\n