When Your Partner Betrays You - Trusted Relationship Compromise In The Cloud

When Your Partner Betrays You - Trusted Relationship Compromise In The Cloud

Speakers: Sebastian Walla

Conference: fwd:cloudsec North America 2025

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

Overview

Sebastian Walla, a cloud threat intelligence analyst at CrowdStrike, presented two real-world case studies of trusted relationship compromises in Azure, both conducted by the China-nexus threat actor Murky Panda (tracked by Microsoft as Silk Typhoon). The talk demonstrated how a nation-state adversary exploited the inherent trust between organizations and their SaaS providers and cloud solution providers (CSPs) to gain access to downstream customer environments, ultimately reading emails without triggering alerts in the victim tenants. Walla provided detailed hunting queries and detection techniques for identifying this initial access vector, which remains rare in cloud environments but has emerged at least three times since 2024.

Background

▶ Watch: Trusted relationship compromise as an emerging cloud initial access vector (1:30)

Trusted relationship compromise as an initial access vector has been well-documented in on-premise environments but is relatively new to cloud. CrowdStrike's primary observations from 2024 show that most cloud initial access comes from valid cloud accounts or exploitation of public-facing applications. However, trusted relationship compromises represent an emerging third vector that is particularly dangerous because the attacker inherits the legitimate trust and access that organizations have granted to their external partners.

For this talk, a trusted relationship is defined by two conditions: a pre-existing connection between a downstream customer and an external organization (such as a SaaS provider or managed service provider), and the downstream customer having granted that external organization access to their cloud environment. In Azure, this access is typically realized through cross-tenant access or multi-tenant applications.

Murky Panda / Silk Typhoon is a China-nexus threat actor whose primary objective is intelligence collection. They prefer to achieve initial access through zero-day or n-day vulnerability exploitation, and they consistently target email as their primary data source -- a behavior consistent with nation-state intelligence collection against government and policy-making targets.

Key Findings

▶ Watch: Case 2: Cloud Solution Provider compromised via legacy DAP with Global Admin (6:00)

Case Study 1: Compromised Multi-Tenant SaaS Application (Q1 2025). Murky Panda exploited a zero-day vulnerability to compromise a SaaS provider and almost certainly obtained the application registration secret from one of the provider's multi-tenant applications. In Azure's multi-tenant architecture, a SaaS provider's application registration lives in their tenant, while a service principal (enterprise application) representing that registration lives in the customer's tenant. The same application secret authenticates both sides. With the stolen secret, Murky Panda authenticated as the service principal in at least one downstream customer's tenant and read emails. The entire attack -- from SaaS provider compromise to email exfiltration -- left minimal traces in the downstream customer's logs because all preparatory activity occurred in the SaaS provider's tenant.

Case Study 2: Compromised Cloud Solution Provider via Cross-Tenant Access (Q3 2024). Murky Panda compromised a Cloud Solution Provider (CSP) -- a participant in Microsoft's partner program for IT service providers. The compromised CSP was still using the legacy Delegated Admin Permissions (DAP) mechanism, which grants members of the admin agents group full Global Administrator privileges across all downstream customer tenants. The compromised user was a member of this group, giving Murky Panda global admin at every downstream customer. They authenticated to a downstream customer without MFA, created a backdoor user, added it to groups with Application Administrator privileges, then used that role to add secrets to pre-existing service principals. The backdoored service principals all had Mail.Read application permissions; some had Mail.ReadWrite, Application.ReadWrite.All, or RoleManagement.ReadWrite.Directory (a direct path to Global Administrator). Despite having extraordinary access, they used it solely to read emails.

Microsoft has since announced that starting September 2025, MFA will be enforced for CSP access to Partner Center, addressing the MFA bypass observed in this intrusion.

Technical Deep Dive

▶ Watch: Backdooring service principals with Mail.Read and RoleManagement.ReadWrite.Di... (10:00)

The multi-tenant SaaS architecture in Azure works as follows: the SaaS provider creates an application registration in their tenant with a secret. Downstream customers instantiate a service principal in their own tenant that represents this application. When the SaaS provider authenticates using their application secret, they can act as the service principal in the customer tenant and access whatever resources (e.g., M365 data) the service principal has been granted. If an attacker obtains the application registration secret, they can authenticate as the service principal in every downstream tenant where it is instantiated.

The DAP/GDAP mechanism for Cloud Solution Providers is the legacy trust model. DAP provides two groups: helpdesk agents (helpdesk administrator at all downstream tenants) and admin agents (Global Administrator at all downstream tenants). GDAP (Granular Delegated Admin Permissions) improves this by allowing temporary permissions, granular role assignment, and per-customer access scoping. Organizations still using DAP face the risk demonstrated in Case Study 2.

For hunting, Walla identified several detection approaches:

• Service principal sign-ins from unexpected IP ranges: Non-human identities should exhibit regular patterns; deviations indicate compromise
• New service principal credential key IDs: When an attacker adds a secret to a service principal, the credential key ID in sign-in logs changes (though legitimate credential rotation causes the same)
• Workload Identities Premium conditional access policies: Allow restricting service principal sign-ins to specific IP ranges associated with legitimate SaaS providers
• Partially redacted IP addresses in sign-in/audit logs: Cross-tenant access (including CSP activity) causes IP addresses to be partially redacted (numbers replaced with 'X' for IPv4, fully redacted for IPv6), serving as a proxy for identifying CSP activity
• Add User events with redacted IPs: Reliable indicator of CSP-created users, except in environments where MSPs routinely create users
• Python requests user agent on credential additions: Murky Panda used a likely Python script (user agent: "Python requests") to backdoor service principals; hunting for this user agent on credential modification events is effective if the organization doesn't use the same library for legitimate operations

Demo / Proof of Concept

▶ Watch: Hunting techniques: IP ranges, credential key IDs, and redacted addresses (12:00)

No live demo was performed. The talk focused on threat intelligence case studies with detailed slide-based walkthroughs of the attack chains and hunting query logic.

Defensive Implications

▶ Watch: Using partially redacted IPs as proxy for identifying CSP activity in logs (16:00)

Organizations should take several immediate actions:

1. Migrate from DAP to GDAP immediately if using Cloud Solution Providers with legacy delegated admin permissions
2. Apply conditional access policies to service principals using Workload Identities Premium to restrict sign-in IP ranges for multi-tenant SaaS applications
3. Force MFA for CSP access using conditional access policies as described in Fabian Bader's research, rather than waiting for Microsoft's September 2025 enforcement
4. Monitor service principal sign-in logs for unexpected IP address ranges and new credential key IDs
5. Hunt for partially redacted IP addresses in sign-in and audit logs as a proxy for cross-tenant / CSP activity
6. Review service principal permissions -- any service principal with Mail.Read, Mail.ReadWrite, Application.ReadWrite.All, or RoleManagement.ReadWrite.Directory permissions should be treated as high-value targets for monitoring
7. Restrict Application Administrator role assignments to minimize the ability to add secrets to service principals

For understanding Azure privilege escalation paths, Walla referenced Fabian Bader's maintained map of Entra ID privilege escalation paths.

Key Takeaways

• Trusted relationship compromises are an emerging initial access vector in cloud environments, observed at least three times since 2024, primarily conducted by China-nexus threat actor Murky Panda / Silk Typhoon
• Compromising a single SaaS provider or Cloud Solution Provider can grant access to all downstream customer tenants through Azure's multi-tenant trust mechanisms
• Legacy DAP grants Global Administrator to all downstream customers -- organizations must migrate to GDAP immediately
• MFA was not enforced for CSP cross-tenant access; Microsoft will begin enforcement in September 2025
• Most of the attacker's preparatory activity occurs in the external partner's tenant, giving downstream customers minimal visibility into the initial compromise
• Non-human identity monitoring (service principal sign-in patterns, credential key ID changes) is the primary detection surface for downstream customers

About the Speaker(s)

Sebastian Walla is a cloud threat intelligence analyst at CrowdStrike, where he specializes in tracking and analyzing cloud-focused threat actors. His work focuses on identifying emerging attack patterns in cloud environments and developing hunting techniques for cloud-native threats.