Detect Identity-Based Supply Chain Attacks in Cloud

What’s the definition of an identity-based supply chain attack? An identity-based supply chain attack is a cyberattack that targets a trusted third-party vendor who provides critical supply chain services or software. In recent years, there has been a significant increase in security vulnerabilities related to cloud identities within the context of supply chain attacks.

Suppose an adversary can get access to a service provider environment by compromising the user entity. In that case, doors are open to all client environments where the service provider is providing services. There are plenty of security measures that could be taken into use on both the service provider and Client side. Unfortunately, I’ve seen too many environments where best practices are not followed and there is plenty of room for improvements in many environment’s security posture.

These identity-based supply chain attacks can cause significant damage to an organization’s data, systems, and reputation. In this blog, I will demonstrate how Microsoft’s Defender for Cloud’s new enhanced capability and Azure Activity Log raw data can be used to detect supply chain attacks and what measures should be implemented in the environment to prevent attacks from happening in the future. The focus of this blog is on the Azure LightHouse access scenario.

Background

Before jumping into the more technical side of things let’s familiarize ourselves with the basics. According to Microsoft documentation, partners can have different permission types depending on used partnership model. Some of these permission types grant quite wide permissions to the customer environments.

Side note: Delegated administrator permissions (DAP), which are used on the CSP model, are on the sunset path and GDAP is the way to go.

Permission type	Description
Delegate Access Permissions (DAP)	Partners that manage products and services for your organization or school. In Azure Active Directory (AD), the partner is a Global Administrator for your tenant. This role lets them manage services like creating user accounts, assigning and managing licenses, and password resets.
Granular Delegated Access Permissions (GDAP)	Partners who manage products and services for your organization or school, but who have limited access to what they can do in the Microsoft 365 admin center. Granular delegated administrator privileges (GDAP) let partners complete tasks in the admin center without having global admin permission. By giving GDAP to partners, you ensure they have the least-permissive roles and limit the risk to your organization.
Reseller	Partners who sell and manage Microsoft products and services to your organization or school.
Reseller & delegated administrator	Partners who sell and manage Microsoft products and services to your organization or school.
Partner	You give your partner a user account in your tenant, and they work with other Microsoft services on your behalf.
Advisor	Partners can reset passwords and handle support incidents for you.
Microsoft Products & Services Agreement (MPSA) partner	If you’ve worked with multiple partners through the MPSA program, you can allow them to see purchases made by each other.
Line-of-business (LOB) partner	Partners can develop, submit, and manage LOB apps specific to your organization or school.

Azure Management for Partners

As we can see from the table above, there are plenty of different ways to grant permissions for a service provider to customer environments. Besides that, some of the models also grant permissions to the Azure environment or give a possibility to do so.

Azure LightHouse

Azure Lighthouse is a service that enables managed service providers (MSPs/MSSPs) to deliver managed services to their customers at scale. With Azure Lighthouse, service providers can access and manage multiple customer subscriptions from a single portal, using delegated access and identity management (RBAC passthrough). This reduces the complexity and overhead of managing multiple tenants and improves the efficiency and security of service delivery. In general, MSSPs use mainly Azure Lighthouse for managing multiple Azure environments. This approach is great from a productivity point of view but can have significant security challenges depending on how the service provider environment is configured and hardened.

If you compare for example GDAP and Azure LightHouse, the latter adds more granularity for managing the permissions and doesn’t require a similar partnership to GDAP (The latter requires a ‘reseller’ partnership).

What is an Identity-Based Supply Chain Attack?

Now we have gone through general info related to different partner models and it’s time to turn focus on the actual attack. Service providers such as MSP/MSSPs are attractive targets for adversaries because if they can compromise one admin account from the service provider side, they potentially have access to multiple environments on their hands. As of today, a large number of organizations are serviced and maintained by external service providers, such as MSPs/MSSPs. The delegated permissions levels depend on the services they provide to their Clients or at least should depend. The least privileged model should be used always.

Attack Scenario

Imagine a scenario where MSP/MSSP environment identities are not adequately protected and an adversary compromises the service provider admin account. After compromising the service provider account (initial access) the next phase is a kind of reconnaissance where an adversary identifies what permissions and where they are able to attack.

This attack also belongs to ‘Defense Evasion’ (in MITRE ATT&CK framework) which consists of techniques an adversary may use to evade detection or avoid other defenses. Sometimes these actions are the same as (or variations of) techniques in other categories that have the added benefit of subverting a particular defense or mitigation.

Detection

Detections are close to my heart because I have been working on the blue team side where I’m helping my customers to build and strengthen their defenses. I have written earlier about the similar scenarios (MSP/MSSP) we are talking about here, how you can secure and audit MSSP access, and how to detect changes in Azure Lighthouse delegations. Even though blogs are a few years old there are some principles that could be followed:

Even though it has been possible to detect MSP/MSSP activities, the detection mechanism requires often custom use cases and rules. A great addition to the detection part is the ‘Microsoft Defender for Cloud’ enhanced capabilities for the threat protection layer (Defender plans). This enhanced detection capability correlates events collected through Azure Resource Manager (ARM) and can identify possible suspicious activities coming from the MSP/MSSP side. We are talking about operations through delegated access. These activities are differentiated from member users’ activities.

Defender for Cloud enhanced plan – Defender for Resource Manager

For the enhanced detection capability in MDC, you need to enable the ‘Resource Manager’ plan from MDC.

Defender for Resource Manager

Azure Resource Manager (ARM) is the deployment and management service for Azure. It provides a management layer that enables the creation, update, and deletion of resources in the Azure subscription. By leveraging the MDC enhanced plan called ‘Defender for Resource Manager’ you will get protection for resource management operations in the environment, whether they’re performed through the Azure portal, Azure REST APIs, Azure CLI, or other Azure programmatic clients as seen in the figure below.

Side note: the MDC alert reference for Resource Manager is found here.

Defender for Resource Manager detects the following attack scenarios:

Suspicious resource management operations, such as operations from malicious IP addresses, disabling antimalware, and suspicious scripts running in VM extensions
Use of exploitation toolkits like Microburst or PowerZure
Lateral movement from the Azure management layer to the Azure resources data plane

Detection in the MDC

In the MDC, alerts with a delegated access indication are triggered due to the activity of third-party service providers. A similar alert can be seen in the figure below.

Finding service provider activities with KQL

MDC isn’t enough in the MSP/MSSP scenario and that’s why we need to rely on Azure Activity logs that automatically receive events from Azure Resource Manager (management plane). The following example query shows activities made by a user from another tenant towards your tenant. The user (MSP/MSSP) sign-in activities are not shown in the Customer tenant but activities made through Azure RM can be seen in the Customer tenant.

AzureActivity
| where TimeGenerated >= ago(1d)
//| where TimeGenerated between (datetime_add("minute", -15, datetime("2023-09-14T11:44:43.000Z")) .. (datetime_add("minute", 15, datetime("2023-09-14T11:44:43.000Z"))))
//| where Caller == 'demo1@M365x412384.onmicrosoft.com'
| where ActivityStatusValue == "Success" or ActivityStatusValue contains "Start"
| where OperationNameValue contains "WRITE"
| extend ['RBACRole'] = tostring(parse_json(tostring(parse_json(Authorization).evidence)).role)
| extend ['RoleAssignmentScope'] = tostring(parse_json(tostring(parse_json(Authorization).evidence)).roleAssignmentScope)
| extend ['Scope'] = tostring(parse_json(Authorization).scope)
| extend ['Claims_authnmethodsreferences'] = tostring(parse_json(Claims).["http://schemas.microsoft.com/claims/authnmethodsreferences"])
| extend ['Claims_upn'] = tostring(parse_json(Claims).["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"])
| extend ['Claims_tenantid'] = tostring(parse_json(Claims).["http://schemas.microsoft.com/identity/claims/tenantid"])
| where ['Claims_tenantid'] != '<insert your own aka customer tenant ID here>'
| project TimeGenerated, Caller, CallerIpAddress, ['RBACRole'], ['Claims_authnmethodsreferences'], ['Claims_tenantid'], ['Scope']

The results show activities from another tenant and we can also see has strong authentication methods are used or not (included in claims) – pwd,mfa.

Side note: If you are keen to find out sign-in activities by Cloud Service Provider (CSP) who access to the tenant through Partner Center, you can find sign-in activities from Entra ID sign-in logs by using filter ‘Cross-tenant access type: Service Provider’. There are other access types also available for monitoring B2B or Microsoft Support access.

Mitigation

Follow the security best practices as a service provider and customer side. Detailed documentation about the recommended activities is found in Microsoft Partner Center documentation.

Security best practices for partners

Security best practices for customers

Besides the security recommendations list there are a few Azure Policy settings that we recommend implementing in the customer environment:

Audit delegation scopes of a managing tenant
Allow managing tenant IDs to onboard through Azure Lighthouse

With these policies administrators on the customer side can audit the delegation scopes and limit the allowed delegations against their own tenants.

M365 Defender Threat Analytics Recommendations

In this chapter, I will go through Microsoft 365 Defender Threat Analytics report recommendations which I’ve found extremely useful.

Cloud Identity Abuse

M365D Threat Analytics has a report for ‘Cloud Identity Abuse’, that provides general prevention guidance for identity abuse attack scenarios. All of the recommended actions are valid in an identity-based supply chain attack because an attack always starts by gaining credentials.

According to the M365 Defender Threat Analytics report, Microsoft researchers still observe continued activity from Midnight Blizzard. Cloud service providers (CSP), managed service providers (MSP), and other IT services organizations that rely on delegated administrative privileges (DAP), as well as the downstream, are encouraged to prioritize the associated alerts stated in the detection details section. Microsoft customers are also encouraged to review this report and the mitigation list that follows as a guide to identify and investigate Midnight Blizzard patterns in logs and network activity.

Detections (Threat Analytics report)

Microsoft 365 Defender

Alerts with the following titles in the security solutions can indicate threat activity on the network:

Suspicious Addition of an Exchange-related App Role (alerts when the addition of an Exchange-related application role was observed; this is a correlation rule that only triggers if Microsoft Defender for Cloud Apps is also deployed)

Microsoft Sentinel

Azure VM Run Command operations executing a unique PowerShell script (alerts when an Azure Run command is used to execute a unique PowerShell script on a virtual machine)
Azure VM Run Command operation executed during suspicious login window (alerts when an Azure Run command execution event is associated with a user and IP Address that has recently been associated by an Azure Sentinel UEBA user entity behavior alert)
Azure Portal Sign-in from another Azure Tenant (alerts for sign-in attempts to the Azure Portal where the user who is signing in is from another Azure tenant, and the IP address the login attempt is from is an Azure IP)

Defender for Cloud

Suspicious Run Command invocation detected (alerts on a suspicious Run Command invocation in a subscription)
Delegated access (alerts with a delegated access indication are triggered due to the activity of third-party service providers. learn more about service providers’ activity indications

Defender for Cloud Apps

Unusual addition of credentials to an OAuth app (identifies the suspicious addition of privileged credentials to an OAuth app, based on baseline behavior of activities learned by the product)
- Moved into the Behaviors data layer in MDA
Unusual ISP for an OAuth app (alerts when OAuth apps perform activities from an unusual ISP, which could indicate an attempted breach using a non-genuine OAuth provider)
- Enabled in MDA

Sam's Corner

Site about cloud security

Detect Identity-Based Supply Chain Attacks in Cloud