In the third installment of the “Matrix” series, “The Matrix Revolutions,” there’s a character called the Trainman. He’s a program in the Matrix whose main job is to run a train station that serves as a gateway for those seeking travel into the Matrix realm without the usual pathways.
Think of Azure, Microsoft’s cloud computing service, like the Matrix. Just as the Trainman provides an unconventional entry point to the Matrix, Azure also has its own set of programs designed to give users access to Azure, but not in the way most people are accustomed to. Even though you might not use any of these other methods regularly, it’s important to know how to monitor them if any new deployments get configured in your tenant.
Access packages
Azure access packages are part of Entra ID Identity Governance. They allow Global Admins to bundle access to applications, cloud services, SharePoint online sites and Microsoft Entra roles (Coming soon) for internal and external users in a package that can be distributed to users. The user can quickly run the access package and be automatically granted access to resources depending on the package configuration.
An access package can be created in such a way that it adds users to a group that, in return, grants Microsoft Entra ID roles with no approval required. Creating a new access package requires Global Admin permissions. When an access package is created, an event will be logged within Microsoft Entra ID under Monitoring Audit logs.
Entra ID > Monitoring > Audit Logs
The Microsoft Entra ID Audit log can be exported to a SIEM using the “Export Data Settings.” Below is a screenshot of an event that was exported to Splunk; from here, you could create an alert based upon any new operationName of “Create access package” to notify you or your team.
Access packages are created and maintained in Azure Identity Governance. Within Identity Governance you can view configuration parameters, including historical events about who requested access to use the package and who has an active assignment.
Entra ID > Identity Governance > Access packages
Within the Azure console page for access packages you can quickly identify the name, description and usage stats.
Clicking on the name of the access package will drill down into additional details. There you will be able to see what roles and groups are configured for the access package, including individuals who have requested access and if they have active assignments.
Cross-tenant synchronization
Azure cross-tenant synchronization is a feature that allows organizations to synchronize user identities, allowing seamless collaboration for multi-tenant organizations. Cross-tenant synchronization defines a trust relationship between the source and target tenants. Users are pushed from the source tenant to the client tenant, simplifying the complexity of access management and resource sharing and increasing collaboration.
Image courtesy of Microsoft
Cross-tenant synchronization must be configured by a Global Admin. Once in place, it will sync the user accounts from the parent domain into a child domain. Cross-tenant synchronization can be configured in such a way that the imported user accounts look like member users rather than guest users. When cross-tenant synchronization is configured, it will generate an event logged within Microsoft Entra ID under Monitoring Audit logs.
Below is a sample cross-tenant synchronization event from Splunk. An alert can be created for any new operationName of “Add a partner to cross-tenant access setting.”
External user invites will generate an event that will be logged in Entra ID Monitoring Audit logs with an activity of “Invite external user.”
Azure allows you to view or modify an existing cross-tenant synchronization setting. There you will be able to view the name of the source organization and make modifications to the trust settings. You are also able to remove cross-tenant synchronization by selecting the trash can icon.
Entra ID > External Identities > Cross-tenant access settings
Azure Lighthouse
Azure Lighthouse offers a management solution designed to simplify operations, management, and monitoring across Azure environments. It allows service providers to manage resources for multiple customers from a single control plane. When a service provider uses Azure Lighthouse to manage a customer’s resources, the actions performed by the service provider’s users are recorded in the customer’s Azure subscription activity logs. While activities such as creating or deleting a resource or viewing access keys are usually logged, Lighthouse users do not directly appear in the customer’s Microsoft Entra ID as members or guests. Since the users don’t appear in Entra ID as members or guests, no login or audit events are ever generated.
A Lighthouse deployment will require someone with Global Admin privileges to import a JSON file manually or from Azure Marketplace, granting another Azure tenant access to your subscription or resources. The new Azure Lighthouse setup events can be found in Microsoft Entra ID Audit log with an activity of “Add a partner to cross-tenant access setting.”
Below is a sample Azure Lighthouse event from Splunk. An alert can be created looking for any new operationName of MICROSOFT.MANAGEDSERVICES/REGISTRATIONASSIGNMENTS/WRITE combined with a resourceId of */PROVIDERS/MICROSOFT.MANAGEDSERVICES/REGISTRATIONASSIGNMENTS/*.
To view or modify current Azure Lighthouse configurations in your tenant, hop over into the “Service providers” management pane. For each offer, the service provider’s name and the offer associated with it will be displayed. When you click on the service provider name it will give you a description with the details about the service provider, including tenant ID and permissions that are granted. On the “Service provider offers” page you can remove a service provider offer at any time by selecting the corresponding trash can icon.
Service providers > Service provider offers
Granular delegated admin privileges (GDAP)
GDAP is the replacement for delegated access privileges (DAP). GDAP allows partners to access their customers’ environments for support and license management. This can range from a Teams administrator up to Global Admin role. The GDAP process to obtain permission to manage a customer is relatively secure. It requires the partner to be registered with Microsoft Partner Center and to create a request that the customer must approve.
You will find Audit logs within Microsoft Entra ID under Monitoring; all new GDAP creations will be logged here.
The Audit log can be exported to a SIEM using the “Export Data Settings.” Below is a screenshot from Splunk an alert can be created looking for any new operationName of “Add a partner to cross-tenant access setting” combined with identity of “Partner Customer Delegated Administration.”
App registrations and service principals
Imagine you create an application that needs to save or get information from Azure. You need a special pass to securely allow your application to talk to Azure without anyone else pretending to be your application.
You must register your app in Azure for your application to get that special pass. Creating the App Registration will generate a unique client ID and allow you to create a secret. This will be the special pass your application will use to authenticate to Azure. You will also define the permission it needs to talk to a database. The app registration is essentially your application’s declaration to Azure, saying, “Here I am, and this is what I need to do.”
Within the creation of the app registration a service principal is created, which allows the application to sign in and access Azure resources. This service account is granted specific roles allowing it access to Azure resources like the database. With these permissions, the application can save or get information from the database.
Let’s discuss how API permissions can be abused. When registering your app, you select permissions that allow your application to talk to the database. Many other permissions can be granted to your application, including a few Microsoft Graph roles that an adversary could find very interesting if they were ever to gain a foothold.
We’ll start with AppRoleAssignment.ReadWrite.All and assume this was granted during app registration. This Microsoft Graph app role allows the service principal to grant itself any Microsoft Graph app roles and bypass the consent process. Now let’s imagine your app registration client ID and secret somehow found their way into a adversary’s hands. Upon logging into your application with additional AppRoleAssignment.ReadWrite.All permission, they used the service principal to adopt two more Microsoft Graph app roles: Directory.ReadWrite.All and RoleManagement.ReadWrite.Directory. With Directory.ReadWrite.All, they could create a new Entra ID user account. Then, with the RoleManagement.ReadWrite.Directory, they could grant the user account Global Admin role.
All new user creations or Entra ID RBAC changes create events are logged into the Entra ID Audit log. It is relatively easy to detect if a new user is granted a Global Admin role or another highly privileged role. Also, every API permission grant will generate an event displayed in the Entra ID Audit log. We recommend checking out some of Andy Robbins’s posts for SpecterOps on Azure API permission abuse, including “Microsoft Breach — What Happened? What Should Azure Admins Do?”, which offers some great advice on how to detect and steps to protect your Azure environments.
All aboard!
Much like the Matrix’s Trainman, unconventional methods such as access packages, cross-tenant synchronization, granular delegated admin privileges (GDAP), Azure Lighthouse, and the nuanced configurations of app registrations provide unique gateways through which users can be granted access to the environment. While designed to enhance flexibility and operational efficiency, these tools also introduce complexities that necessitate meticulous attention to detail and a profound understanding of their mechanisms—even if they are not part of your everyday operations.
Just as the Trainman controls access to hidden parts of the Matrix, cybersecurity professionals must patrol these unconventional access methods to secure their Azure environments effectively. Securing Azure is a continuous journey, demanding vigilance and a proactive approach to navigating the ever-evolving cyber landscape.