Exploring The Possibilities of Azure Fabric Abuses

Exploring The Possibilities of Azure Fabric Abuses

Speakers: Viktor Gazdag, Principal Security Consultant, NCC Group

Conference: Cloud Village

YouTube: https://www.youtube.com/watch?v=bo5Vz6iOSXw

Overview

In this insightful talk at Cloud Village, Viktor Gazdag, a Principal Security Consultant at NCC Group, delved into the often-overlooked security implications of Microsoft Azure Fabric. Azure Fabric is presented by Microsoft as a comprehensive Software-as-a-Service (SaaS) analytics platform, unifying a wide array of big data services such as data engineering, data factory, and data warehousing within a single, integrated portal. This centralization, while offering significant operational efficiencies and a OneLake storage solution, also consolidates a vast amount of sensitive data and powerful processing capabilities, making it an attractive target for adversaries.

Gazdag's presentation meticulously dissects the potential for abuse within this powerful platform, focusing on critical tenant-level security configurations and demonstrating how an attacker could leverage built-in functionalities for malicious purposes. The talk highlights two primary areas of concern: the creation of persistent backdoors and various methods of data exfiltration. By showcasing practical proof-of-concept demonstrations, Gazdag underscores the importance of understanding the intricate security landscape of Azure Fabric, providing invaluable guidance for organizations to fortify their defenses against sophisticated cloud-native threats.

The significance of this research lies in its proactive approach to identifying and illustrating attack vectors within a relatively new, yet rapidly adopted, cornerstone of Azure's data ecosystem. As organizations increasingly migrate their critical data and analytics workloads to platforms like Fabric, a thorough understanding of its security architecture and potential vulnerabilities becomes paramount. Gazdag's work serves as a crucial wake-up call, emphasizing that the convenience and power of unified platforms must be balanced with robust security practices to prevent unauthorized access, data breaches, and persistent compromise.

Background

▶ Watch: Azure Fabric overview and purpose (0:00)

Azure Fabric represents Microsoft's ambitious vision for a unified analytics platform, designed to simplify and streamline data management and processing for enterprises. It integrates services like Data Engineering, Data Factory, Data Warehouse, Real-Time Analytics, and Power BI under a single umbrella, all leveraging OneLake as a foundational storage layer and orchestrated by underlying capacity resources. This convergence aims to eliminate data silos and complex integrations, allowing users to move seamlessly between different data workloads from a unified portal. Additionally, Fabric supports shortcuts and Mirror DB to incorporate external data, further expanding its reach and utility.

Given its role as the central nervous system for an organization's data analytics, the security posture of Azure Fabric is inherently critical. A compromise within this platform could grant attackers access to vast quantities of sensitive information, enable the manipulation of data pipelines, or establish persistent footholds within an organization's cloud environment. The challenge lies in the sheer breadth of services and configurations available within Fabric, many of which can be inadvertently misconfigured or maliciously exploited if not properly understood and secured.

Gazdag structured his exploration into three main areas: an introduction to Fabric, a deep dive into crucial tenant-level security settings, and an analysis of two distinct abuse scenarios: establishing backdoors and performing data exfiltration. The talk builds upon the premise that while Microsoft provides extensive security controls, the complexity and interconnectedness of Fabric's features can create blind spots or opportunities for attackers who understand how these components can be chained together for nefarious ends. Prior work in cloud security has often focused on IaaS or PaaS layers, but Fabric, as a comprehensive SaaS offering, presents a new frontier where the lines between application-level features and underlying infrastructure security can blur, creating unique attack surfaces that warrant specific attention.

Key Findings

▶ Watch: Warning about user data functions security risks (4:30)

Viktor Gazdag's presentation unveiled several critical findings regarding the security landscape of Azure Fabric, demonstrating how its powerful, integrated features can be weaponized if not properly secured. The primary discoveries revolve around two core themes: the potential for persistent backdoor establishment and the ease of data exfiltration using native Fabric capabilities.

Firstly, Gazdag highlighted that while Azure Fabric offers hundreds of tenant-level security settings, a select few are particularly critical and often overlooked. These settings, related to external data sharing, guest user access, service principal API permissions, and the creation of user-defined functions with custom Python packages, can significantly broaden an organization's attack surface if left in their default, permissive states. Misconfigurations here can allow unauthorized external access or even enable the introduction of arbitrary code.

Secondly, the talk demonstrated a sophisticated method for establishing a backdoor within an Azure subscription directly from Fabric. By chaining together Fabric's Activator (event monitoring and triggering), Notebooks (code execution environment), and the Azure Python SDK, an attacker can automate the creation of Azure resources such as virtual machines, network security groups, and managed identities with elevated privileges. This allows for delayed code execution and persistent access to the underlying Azure subscription, all triggered by seemingly innocuous Fabric events.

Finally, Gazdag detailed multiple built-in options for data exfiltration that are inherent to Fabric's design. These include leveraging Data Pipelines to copy data to attacker-controlled storage, using Notebooks with internet access to upload data, creating Shortcuts to link to external data sources or attacker-owned storage accounts, exploiting SQL Endpoints for read-only access to lakehouse data, and utilizing Mirror DB to replicate database transaction logs. These methods underscore that Fabric's primary function—data movement and analysis—can be easily subverted for malicious data egress if access controls are not meticulously enforced.

Technical Deep Dive

▶ Watch: Exploring backdoor and data exfiltration abuses (6:00)

Azure Fabric's architecture, while designed for seamless data integration, presents a complex security landscape. Gazdag meticulously detailed both preventative tenant-level controls and the specific mechanisms an attacker could exploit.

Tenant-Level Security Settings

Gazdag emphasized that while Fabric boasts "hundreds of settings," three groups are paramount for initial defense:

1. Export and Sharing: This group controls the breadth of data sharing.

• External Data Sharing: Allows sharing Fabric items outside the organization. Disabling this is crucial to prevent broad data leakage.
• Guest Users Can Access Microsoft Fabric: If Entra ID (formerly Azure AD) guest users are invited, they can access Fabric unless this is explicitly disabled. This is a common vector for insider threats or compromised external accounts.
• Restrict Content with Protected Labels: This setting prevents labeled sensitive data (e.g., "secret," "internal only") from being shared via links with everyone, including guest users, mitigating unauthorized access to classified information.

1. Service Principal Access: Fabric allows service principals and managed identities to interact with its APIs.

• Settings exist to allow service principals to access read-only admin APIs or public APIs. Permitting this enables programmatic management of permissions or shared items, which, if compromised, could automate malicious configuration changes or data access.

1. User Data Functions:

• Users can create custom functions, including Python functions, and integrate custom Python packages. These can be called from data pipelines, notebooks, or applications. This capability introduces a significant risk, as it allows for the introduction of arbitrary, potentially malicious code or backdoors into the data processing environment. Careful control over who can create and use these functions is essential.

Beyond these, Gazdag briefly mentioned the utility of Conditional Access Policies for Fabric services and network isolation options like Private Links and Block Public Internet Access. He cautioned that enabling the latter two without proper virtual network and Bastion host configurations would render Fabric inaccessible, highlighting the need for careful planning.

Backdoor Mechanisms

Gazdag explored several Fabric features that could be abused to establish backdoors:

1. Activator: This is Fabric's event monitoring and triggering service. It can subscribe to various events (job, OneLake, workspace, Azure Blob Storage) like creation, update, or deletion events (e.g., created succeeded, created failed). Upon detecting a specific event, Activator can trigger actions such as sending emails, running Power Automate scripts, or executing Notebooks. A notable characteristic is the potential for significant delays (30 minutes up to 2 hours) between an event occurring and Activator processing it, making detection challenging.

1. Notebooks: Fabric notebooks provide an environment for data transformation and reporting, supporting Python, Java, and other languages. Crucially, users can upload and utilize their own custom Python packages, not just those from public repositories. Notebooks can run in the context of the creating user or, if enabled at the tenant level, a service principal or managed identity. This capability is central to injecting and executing arbitrary code.

1. Power Automate: Microsoft's low-code/no-code solution can be integrated with Fabric. It offers Entra ID steps, allowing the creation of service principals, user additions, and other identity management actions. This provides a powerful vector for privilege escalation and user management manipulation.

1. Scheduled Spark Job: These jobs, often using Python, also allow for custom environments where V-format Python packages can be uploaded and executed periodically, offering a persistent execution vector.

Backdoor Proof of Concept (PoC) Architecture

Gazdag's PoC demonstrated a sophisticated backdoor flow:

• An Activator is configured to monitor for specific events within a Fabric workspace (e.g., a notebook being created or deleted).
• Upon detection, the Activator triggers a malicious Notebook (e.g., notebook1).
• This Notebook contains Python code leveraging the Azure Python SDK (specifically azure-identity for credentials and azure-mgmt-compute for resource management).
• The Python code programmatically creates an Azure Virtual Machine (VM), a Network Security Group (NSG) configured to allow SSH access to the VM, and a Managed Identity.
• The Managed Identity is then assigned the Contributor role on a specified Azure Resource Group (e.g., fabric2).
• Once the VM is provisioned, the attacker can SSH into it, obtain an access token using the assigned Managed Identity, and then use this token to access and enumerate resources within the compromised Resource Group, effectively establishing a persistent backdoor with significant control over Azure resources. The use of ClientSecretCredential for a service principal was highlighted for authentication with the SDK.

Demo / Proof of Concept

▶ Watch: Multi-component backdoor proof-of-concept explanation (8:00)

The core of Viktor Gazdag's talk was a compelling demonstration of how these mechanisms could be chained together to create a persistent backdoor. The demo began with a visual tour of the Azure Fabric interface, highlighting its resemblance to Power BI, and then shifted to the Azure portal, where only the Fabric capacity was visible, emphasizing the "black box" nature of Fabric's internal components from a traditional Azure management perspective. A pre-configured service principal was shown, intended for use by the Python SDK.

The demonstration focused on configuring the Activator to monitor for specific events. Gazdag navigated to the Activator settings, selecting "Fabric events" and then "Workspace item events." The Activator was subscribed to all such events within a particular workspace. A rule was then defined to trigger an action when a notebook was created or deleted. The action was set to run an existing malicious notebook, notebook1, which was hidden deep within the workspace structure, making it less conspicuous.

The content of notebook1 was then revealed. This Python notebook was pre-loaded with the Azure Python SDK, specifically azure-identity and azure-mgmt-compute. The code was responsible for:

1. Establishing credentials using ClientSecretCredential for a service principal.
2. Creating a new Azure Virtual Machine (VM).
3. Configuring a Network Security Group (NSG) to permit SSH access to the newly created VM.
4. Creating a Managed Identity and assigning it the Contributor role on a designated Azure Resource Group (e.g., fabric2).

To trigger the Activator, Gazdag performed a seemingly innocuous action: creating and then immediately deleting a new notebook, notebook3, within the monitored workspace. Due to the inherent delays in Activator event processing (noted to be 30 minutes to 2 hours), the video was edited to fast-forward to the outcome.

Upon the Activator processing the event, notebook1 was executed. The Activator's history logs confirmed that notebook3 was successfully created and deleted, and subsequently, notebook1 was executed successfully. The output of notebook1 was then inspected, revealing the public IP address and username for the newly provisioned backdoor VM.

Verification in the Azure portal confirmed the creation of the VM, the corresponding NSG, and the Managed Identity with the expected name. Crucially, the Managed Identity was indeed assigned the Contributor role on the fabric2 resource group, validating the privilege escalation.

The final step of the demo involved Gazdag SSHing into the newly created backdoor VM. From within the VM, he used curl to retrieve an access token for the Managed Identity. This token was then used to list resources within the fabric2 resource group, unequivocally demonstrating that the attacker now had programmatic access and control over the target Azure environment, all initiated by an event within Azure Fabric. This illustrated a powerful, delayed, and persistent backdoor mechanism leveraging Fabric's native capabilities.

Defensive Implications

▶ Watch: Activator event monitoring details and delays (9:00)

The detailed abuses presented by Viktor Gazdag underscore the critical need for robust security postures within Azure Fabric. Defenders must adopt a multi-layered approach, focusing on configuration hardening, vigilant monitoring, and adherence to the principle of least privilege.

1. Harden Tenant-Level Settings: This is the first and most crucial line of defense. Organizations must meticulously review and restrict:

• External Data Sharing: Disable or severely limit the ability to share Fabric items outside the organization.
• Guest User Access: Restrict guest users from accessing Microsoft Fabric unless absolutely necessary, and if allowed, apply strict permissions.
• Service Principal API Access: Limit service principals from accessing admin or public APIs to only those absolutely essential for their function, and ensure these service principals are managed with extreme care.
• User Data Functions: Implement strict controls over who can create and use custom Python functions and packages, as these are direct vectors for arbitrary code execution. Consider disabling this capability if not critical for business operations.
• Protected Labels: Ensure sensitive data is correctly labeled and that the "Restrict content with protected labels from being shared" setting is enforced.

1. Implement Network Controls: While challenging, carefully configuring Private Links and Block Public Internet Access can significantly reduce the attack surface by isolating Fabric access to trusted networks. This requires prior planning to ensure access via virtual networks, VPNs, or Bastion hosts remains functional.

1. Comprehensive Monitoring and Alerting:

• Activator Events: Monitor Activator configurations and execution logs for unusual activity, especially for rules that trigger notebooks or Power Automate flows based on broad event types.
• Notebook Execution: Track notebook creation, modification, and execution history. Look for notebooks running with elevated privileges or those that interact with the Azure Python SDK to create resources.
• Custom Package Uploads: Monitor for the upload of custom Python or V-format packages, as these can contain malicious code.
• Azure Resource Creation: Implement Azure Activity Log alerts for the creation of suspicious resources (VMs, NSGs, Managed Identities, Role Assignments) from Fabric-related identities or contexts. Look for patterns like NSGs allowing SSH from anywhere.
• Data Exfiltration Indicators: Monitor data pipeline changes, new shortcut creations (especially to external or unknown storage accounts), and unusual SQL endpoint sharing or Mirror DB activity.

1. Enforce Least Privilege: Ensure that all Fabric users, service principals, and managed identities operate with the absolute minimum permissions required to perform their tasks. Avoid assigning broad roles like "Contributor" to Fabric-related identities unless strictly necessary and time-bound. Regularly audit and revoke unnecessary permissions.

1. Educate Users: Train data engineers, analysts, and developers on the security implications of Fabric features, particularly regarding code execution, custom packages, and data sharing practices.

1. Refer to Microsoft Guidance: As Gazdag noted, Microsoft provides a whitepaper on securing Fabric. Defenders should consult such official documentation for best practices and recommended security configurations.

By proactively addressing these areas, organizations can significantly mitigate the risks associated with Azure Fabric abuses and protect their critical data assets.

Key Takeaways

• Azure Fabric, while powerful and unified, presents a significant attack surface due to its deep integration and extensive capabilities.
• Critical tenant-level settings related to data sharing, guest user access, and service principal permissions are often overlooked but are vital for initial defense.
• Built-in Fabric features like Activator and Notebooks can be chained with the Azure Python SDK to create sophisticated and persistent backdoors within an Azure subscription.
• The ability to upload custom Python packages introduces a direct vector for arbitrary code execution and should be tightly controlled.
• Fabric's core data movement and analysis functionalities (Data Pipelines, Shortcuts, SQL Endpoints, Mirror DB) can be easily repurposed for data exfiltration if not properly secured.
• Comprehensive monitoring of Fabric events, notebook executions, and underlying Azure resource creation is essential for detecting abuse, especially given potential delays in event processing.
• Implementing least privilege for all Fabric identities and rigorously hardening configurations are paramount to mitigating these risks.

About the Speaker(s)

Viktor Gazdag is a Principal Security Consultant at NCC Group, specializing in cloud and CI/CD security. He holds numerous certifications across Azure and other cloud providers. A seasoned presenter, Viktor has previously spoken at Cloud Village, making this his third appearance at the conference, where he consistently shares his expertise on cutting-edge cloud security challenges.