Bridging Clouds and Domains, Expanding Risks

Good morning everybody. Um what uh will happen if your on premises active diretoryries breach and this breach is escalating to your cloud environment or even worse if your cloud environment uh breach escalates into uh back into your active directory. In the next 45 minutes, 40 45 minutes, I'm going to discuss how attackers can exploit um hybrid identity or control control plane uh trust path um to gain access to uh environments and to move materally between those environments. Before we get started, I would like to uh thank our sponsor. Uh without them, we would not be here today. So, a big thank you to all of them. A few words about myself. As you mentioned, I'm

Goswa. I'm a cloud security consultant at Resilix. I'm mainly working with cloud security offensive and defensive. Uh mainly working on security engineering, implementing security features at customers, but also doing some incident response and uh offensive security engagements in uh Azure and hybrid environments. But my main focus lies in Microsoft 365 as security stack. Um and that's what I on what I will focus today. Uh you can find me on LinkedIn and also I don't have my own blog. uh but you can also find I'm posting regularly on the radics blog as my colleagues are also doing. So what are the topics for today? Uh first we'll have an introduction uh just to set the basics. Then we'll see uh three

scenarios how to attack and attack detect and defend. We'll see how to go from how attackers can go from on premises to cloud environment then from cloud environment to on premises and then we'll close a loop by uh having a scenario that goes from on premises to cloud and then back to on premises. Then we have a conclusion and hopefully time for uh Q&A. That's it. >> All right. Uh maybe a bit of background why this talk why am I here today? Um as I mentioned I perform um security offensive engagements in cloud and hybrid environments but I'm also implementing Asia and hybrid security controls in uh customers environment. So sometimes I'm trying to break what uh

I'm implementing at customers. Um one issue or one problem that I identify uh mainly during my offensive security experience is that um some h I hybrid identity and control plane trust pass have not always um covered or have underestimated by blue teams and also red teams. So my goal today is to demonstrate how real world hybrids uh p private scenarios can be abused by attackers and how you can defend that. I will have demos and I will for each scenario I will provide some uh practical defensive guidance for the blue teams to uh detect those abuses and then to protect against them uh to make sure that everyone is uh understands the basics uh I just did uh

entra ID first Asia 101 slide um what is entra ID entra ID is formally Azure ID it's a cloud-based identity provider it can be seen as on premises active directory while the concept principle is the same. Uh the underlying concepts and technologies, protocols are completely different. Uh but it stores those users, groups, service principles, etc. Uh during the presentation, I will mention tenant. A tenant is in fact a dedicated instance of enter often represents an organization. Entra ID is mainly used for authentication. Then we have Azure. Uh Azure is the Microsoft uh cloud resource platform. That's where you can uh deploy applications. uh where you spin up virtual machines and so on um and those

resources uh are mainly deployed are deployed in subscription which is a container that will hold uh those Asia resources. It's also an access billing and governance boundary. So one subscription is isolated uh by default from other subscriptions. Uh I mentioned that Android's useful authentication Azure has its own access control model which is the Azure airbag model. uh so the uh Azure um role-based access control model that is used for authorization. So and Friday ID will will issue uh the access token and then the Asure airback host will be used to validate whether uh users have access uh to specific resources. A few security principles in entry uh you have users can be human users but it can also be um um service

accounts that have been provisioned as user accounts. Uh then you have service principles which have mainly application identities. You have uh an application that runs in the background and does needs to access some um some connected resources in Android ID. Then that's uh typically what you use. And then we have manage identities. Manage identities uh is important for the first scenario. It's a special type of uh service principle uh that is assigned to Azure resources. And then um you don't have to manage credentials of those manage identities because uh Microsoft fully manage them. So you don't have to rotate secrets or certificates. All right. Maybe just to get um an overview uh Wu has experience working

experience with Asia and id in the audience. All right. Okay. uh for the first scenario uh which is maybe the most um basic scenario then we'll go uh to scenario three two and three which will be more advanced uh but we'll see how we can go from on premises environment to a cloud environment by abusing a mish identity on an hybrid VM before we get started with the scenario detail uh just a few concepts uh first we have the age of instance metadata service it's a service that runs locally on any cloud v machine and This service is actually exposed on a nonutable IP which is 16925469254 and it gives information on the current virtual machine. So you can get

information about the network and about the resource in Azure. This instance metadata service also uh can be used to get access tokens from the manage identity which is assigned to that uh virtual machine and this uh those access tokens that you get can then be used to access other Azure services. At the bottom of the slide, you see an animation. So you have an application that runs on an Asia virtual machine and if that application wants to access resources, uh it can go to the instance metadata service which will then talk to entry id get back an access token and that access token can be used to access those uh resources in Microsoft Asure. How does our uh scenario first scenario

looks like? Uh we have the internal network of an organization and this internal network has been uh connected to Azure and AWS uh virtual networks uh via side to side VPN connections uh which is uh quite uh frequent in organizational environments. In Microsoft Azure, you can have an Azure virtual machine that is assigned to a manage identity and then can access other resources. That's also pretty common uh setup. And in uh AWS uh you have similar setup instead it's an EC2 instance role uh that is assigned to the EC2 instance and that role can be assumed to get access to databases in Amazon FDS or storage objects uh within uh Amazon S3. If you are an attacker and or a red

teamer and wants to access those uh resources and are in a in a internet network of that um enterprise environment, you can potentially try to connect to those uh virtual machines and assume the identity of that virtual machine uh and then access to um to cloud resources. Why I'm talking about this uh scenario today? uh because uh when doing um offensive security engagements, we often have initial foothold in an organization network, internal network and sometimes we do have some um objectives that are cloud-based. Um so when we access some server, we always check if that instance metadata service can be from Azure, GCP or AWS is running and maybe we can abuse that um to gain access to cloud

resources and further expand our access in the cloud. So I have a first demo uh to show you how it looks like in practice. So we are on an Asia virtual machine which is an internal network on uh that IP. If I want to see if that um um more information about that virtual machine, I can go to the instance metadata service and uh get more information about the resource running. So here I see that I'm running in the Azure public cloud. I see the uh VM name, the offer name. I also see the admin username and also that password authentication is disabled. Um we see the SSH authorized key. Uh also that is something that will be interesting is

that you see the resource ID of that um victory machine running in Asia. So those res well that information can be used then for enumeration later on also you see the network interfaces for instance if you have multiple you will see them all here we only see the private IP address. All right, because uh it's an Asia virtual machine, I can try to request an access token to access the management.asure.com which is a Asure REST API. So via that Asure REST API, I can take actions, admin administrative actions on uh in Azure. So here I see that I have a token um uh when I I call that uh um IMDS endpoint and then I can

use that token to list subscription that I have access to. So here we see that uh I have access to one sub subscription which is a GM lab pay as you go subscription. Okay. So I know that I have access to that subscription or can I uh check further what I have access to. Then I can check for the resources I have access to and there will see that an Azure key volt is access well that organ identity has access to an Azure key volt because we know that we have access to a key volt we can list the whole assignments that we have in that subscription so that we know what we can do inside that Azure key volt.

Here we see uh the the results of the the role assignments. So we see two role assignments. one for uh the admin user. Uh so it's a user human user that is used to manage um secret certificates and keys within that key volt. Um and then we have the second um whole assignment which is for our manage identity. We see principal type service principle and the principal ID is our manage identity and that role is the key volt secrets officer. This means that we can manage secrets in Azure key volt. All right. So now that I know that I can go to the vault I can request an access token for the vault.asure.net um resource which is the data plane of

Azure key volt so that I can do um data plane operation like secret get secret list uh in that key volt. So we retrieve the access token uh also setting some variables for small scripts to list all the secrets that I have access to. Um so we see that I'm using the vault endpoint and then the slash secrets to list all the secrets within that uh Azure key volt and we'll see that one secret is being returned which is a uh BTG account password. So it's a break glass account password which is ID privilege account in uh entry ID used for recovery purposes and then I can go to that endpoint using the key token

that I got before to get the password of that um the password of that account or the content of that secret. We see that the content is this is a BTG account password. All right. So why were we able to list uh those resources uh or that resource and the whole assignment? In fact, um it depends on the role that the manage identity has been assigned to. In this case, uh it was assigned to the keyhole secret officer role which has the as you can see at the bottom of the slide which has a get whole assignment permission and that permission allows you to list resources and uh the related assignments whole assignments on uh that resource.

However, if we take another one like the storage blob data contributor, we see at the bottom of the slides that the get role assignment is not listed. So, we could have access actually this manage identity was uh assigned uh the storage blob data contributor to a storage account but we did not see it nor the um role assignments um when quering the API. So this is something you can also take in into account if you're a red team want to access some cloud resources from cloud virtual machines always make sure that uh you do not stop with what you can see there might be services or automation that then reach out to that service to that storage account and that

you can also abuse or retrieve sensitive information. All right so that's was the uh more attack part. Now let's go to the uh detect how can you detect such abuse? Uh it's usually not done in uh most environments because it's uh it can be difficult. You need to have detections for every use cases. Uh but it's an approach to at least um get detection rules for the most sensitive resources in an environment. So first is uh look for uncommon key volt operations of any other operations. Here we see that um secret list has been performed. While if uh an automation knows which uh secret to access, it does not probably need to do secret list but only secret get. So

that secret list can be uh seen as uh suspicious and then trigger some uh alerting. Then um for um you can also check for um different IP addresses for unexpected IP addresses. If you see if your automation is running from a um private IP um and contacting your uh your storage account privately using a private endpoint so onetoone connectivity uh you should not see uh public IP addresses or different IP addresses accessing that key volt and also here we see that the list container operation has been done again if you have an automation running it probably does not need to list resources because it knows what to access. Finally, how can you protect uh block

public access to Azure pass resources? So what are pass resources? It can be storage accounts, can be key volts, SQL servers uh and favor connectivity over private endpoints. So onetoone communication connectivity uh we do not see that uh often in customers environment enterprise environments because of private endpoint will include cost but then uh you can still use firewall rules to prevent to allow list which IP addresses public IP addresses you want uh to allow to access your resources and this will already allow to decrease the attack surface of your uh resources. Then we have uh follow the list principle. I will mention it a few times during the presentation. Uh but if we would have assigned the uh as airback

role at the secret level instead at the key volt level all of this would not have been possible. We would not have seen uh that age of key volt and the role assignment. And finally, we have Entra ID protection uh which is a a premium features in a premium feature in Entra ID uh which allows to detect suspicious usage patterns for workload identities including managed identities. All right. So that's uh the first scenario. Now um for the second scenario we uh so we saw how we can go from uh potentially on premises to cloud. No can or can we go to cloud uh from a cloud environment to on premises and this will be uh by abusing Asia arc. You may ask

what is Azure Arc? Uh Azure Arc is a multi cloud and on premises uh management platform which will extend which extends uh the Azure control plane by projecting nonasure or on premises resources into uh Azure resource manager and you will see those resources in Azure as if they were running in Azure. It can be used for SQL servers uh Kubernetes clusters and also uh servers Windows and Linux. In our case, we'll focus on those. Um when you aren enable a server uh it's called an Azure arc enabled server uh there will be uh the Azure connected machine agent running on that server and then this uh agent will do first the communication to um to back

to uh Azure and then it will also allow um it also define what is allowed to run from the Azure control plane on that server but we'll come uh to that a bit uh later. We also see Azure arc being more and more used at customers because uh it's a requirement for uh some services like defender for server which is Microsoft defender for endpoint on uh Linux and Windows servers and also for centralized logging if you want to collect uh security locks from uh uh on premises servers for instance uh you can um one option is to install Asia arc and the Azure monitoring agent to then collect the logs in the Microsoft team solution which is Microsoft sentinel. So

this is uh more and more used uh from uh because of those uh requirements. Um also good to know is that um those uh Azure arc enabled servers also have their instance metadata service um running and every Azure arc enabled server is by default assigned to manage identity. By default, it does not have a lot of permission, but it can be used to grant permission so that an SQL server can access uh or sorry, a server can access an SQL server in the cloud. Uh you can also get tokens for that. Uh the instance metadata service is running on the local O port 40342. The process is similar except that you just need to prove that you can access a

secret file and then um pass the content of that secret file when you request an access token. And once you have the access token then you can access uh Azure resources if the Azure airback allows it. It's also interesting. Azark is also interesting because it provides very powerful control plane capabilities. Uh for instance you can run commands or execute arbitrary scripts via the custom script extension as system or root on Linux. So LT authority system on Windows or root on Linux. And uh for instance, if you take the example of uh the custom script extension, it can be abused uh for command and control. Let's say uh during a team engagement, a compromised uh server of a customer, you can

potentially onboard that server to Azure Arc into your uh Azure control subscription and then uh send scripts via that Azure Arc agent to that on premises server. Uh I'm not sure if I would do it, but it's uh then you abuse a trusted um service on those uh machines or at least on Windows servers. Uh to be able to run those commands or uh execute scripts, you need to be admin to have owner permission or contributed permission on those uh Azure Arc objects. All right. So what does the second scenario looks like? again with the internal network of an organization and in uh their environment they have on premises servers and because they want to centralally manage those servers in

Azure do patch management collect security logs they decided to onboard it to Azure Arc and because of that then they also decided to uh use a managed identity to access other Azure resources via the managed identity as we've seen in scenario one if someone uh has malicious intent uh uh an Azure admin with malicious intent or someone could compromise an administrator in that subscription, they could potentially connect to to that server and execute uh commands as anti- authority system on uh your on premises server. How does it look like in practice? Um hope it's big enough. Um so first uh we are on DC1 uh gummlab.local. Uh so that's my main data domain controller in

my AD environment and we see that Azure Arc is running on that um on that machine on that DC. So if we check the object in Azure we see that uh we can get some information about it. Uh you see the domain FQDN you see the machine name uh you also see uh hardware information uh the network interfaces and so on. because I'm owner or at least I do have administrative permission on that uh object. I can go to the uh Azure API Azure REST API and uh run commands on that server. So the name of the command that you see here host name for instance is can be anything but then the script is what is actually going to run

on that server. So in this case I'm going to run host name and a second command which will be my just to prove that uh we have anti- authority system on that uh machine for demo purposes. All right so that's the second um command and after a while you will get the results from those commands. Uh you see the script has uh execution completely completed. uh you see output DC1 uh for the O name command and then for one by you will see that uh you are indeed uh running as anti- authority system. Now a bit more interesting um the custom script extension um as I mentioned it allows to run uh arbitrary scripts on

the systems and this can potentially lead to a domain compromise. Let's say I'm running as arc. I use the default configuration of Asia arc on the domain controllers. This could allow me to add users and add change group memberships from the Asia control plane. So we are still on that same server. I'm just going to show you that I do have a few users in that uh domain uh with the Azure admin and then uh mostly the built-in uh users in active directory. If I go back to uh the Asia control plane and the extension page uh we see MD.winds Windows which is the MD extension for Microsoft Defender for endpoint and we have the Azure

monitoring agent which will be used to collect the logs. But what if I want to execute script? I can create the custom script extension for Windows. Here I will select the script that I want to run. So the cse.ps1 PS1 script and once the script has executed which takes a bit of time we will see that the bides user has been added uh to AD domain to of active directory and that this user has been uh granted a domain admin privileges. How does it look like? Uh what are the artifacts on the server? Um if you go to see packages plugins you will see folders for every extensions that are running on those servers. Uh for the run

command uh we see that the host name and my commands are visible locally on the server. So we see what has been executed. And then for the custom script extension you also see uh like for the um run command you will see that uh we can also retrieve the content of the CSC script which is uh that one we see that new ad user besides we see the password that has been added and also that uh it has been added to the domain admin group. All right. Uh how can we detect those abuse uh those edge of arc abuse? Um so when I was uh looking into that um first I was okay it's nice to abuse but how

can we detect that first I had a look at the Azure activity logs uh which were not really useful because they lack of because of the lack of context. So the run command for instance you see that uh two commands have been executed but you don't see what has been executed you only see that something has happened. If there would be someone with malicious intent in your environment, uh they could make it look like it's a legitimate Microsoft service executing those commands. Same for the custom script extension, we see that uh the custom script extension has been created, but you don't see what has been executed or what was the output of the script. Um

however if you go to uh the um Azure object go to the uh activity logs and then for every log entry you will get uh the change history and in that change history you get uh more in more valuable insights on what has been done. So on the left uh you see the run command post name and at the bottom left you see that you see the script that has been actually executed on those servers and on the right you see um a bit less information. You see that the custom slip extension has been deployed that we already know. But you can also get the output of the uh script that has been uh that has been done. So the get ad group

member and we see that besides the besides user is indeed member of the domain admin group. That's why I mentioned that it can be interesting for command control because then you can execute scripts and get the output of those scripts in that um in that page in that uh dashboard. How can you protect against those? Uh first uh the first uh step I all the first recommendation I have to customers is to always prevent command and script executions. Use an extension allow list to make sure that you only allow what you want to run on your server. If you only want to connect logs then only allow that specific extension or if you cannot use um uh an allo list you can

use the Azure agent monitor mode which will allow Microsoft defender for server lock collection and so on. I do have a note though on Microsoft defender for endpoint part. If you install Microsoft Defender for endpoint um and that the server is on boarded to your MD tenant then you will also get the possibility to do a live response session on those servers and that can be used also for script or command executions from uh than the defend of portal but then from a cloud control plane. So that's also something to uh be careful of. So the key mainway main main key takeaway is to disable all unnecessary capabilities. As a asure policy, Windows admin center,

the custom script extension and the run commands can all change the configuration of your servers from the Asia control plane which can increase which increases the attack surface of your on premises servers. Then use the list privilege principle for the onboarding uh service principle. not something that I tackle uh no because it's because of time but if you are in enterprise environments we see that uh a lot of customers are using group policy objects to deploy and to onboard servers uh to Azure Arc and those credentials of the service onboarding service principle uh can be easily extracted from on premises. So make sure that you limit the permissions to the minimum required which is Azure

connected machine onboarding role. uh if you give admin access the connected machine admin role to the service principle then it can be used to execute commands and scripts uh again um on those servers and as we've seen during uh the first uh scenario monitor for manage identity misuse. All right so this brings us to our last scenario from active directory to cloud and then back to a different active directory domain by abusing dedicated administration. I think it's pretty uh interesting example or uh demo because that's uh what uh we've encountered during a red team at a customer. Uh we compromised their AD environments. Uh we were able then to move to the to their cloud environment and from that we also

saw that uh their environment was connected to customers environment and from that connection we could also use Azure hack as we seen in scenario to to gain access to their uh on premises server. So it can be seen as a a kind of a supply chain compromise by abusing uh identity first path. All right, a bit of concepts first. Um so in this uh demo I will discuss about entry id connect uh which is an agent that you can install on your uh on premises active directory to synchronize identities from on premises to active directory and this will sync users devices groups and group membership potentially if you enable that. Uh and while it can be useful for uh centrally

managing your identities it can also have some security implications. What if your privilege identities uh are sync from active directory to enter ID? Um this could potentially lead also uh to a full cloud compromise. If your um AD is compromised, if you have global admins that are synchronized uh from uh your on premises active directory, then attackers could leverage that connection, that trust to gain full access to your uh entra ID tenant. And then we have Azure Lighthouse. Um Azure Lighthouse is a feature that enables cross tenant Azure management u by allowing delegated access to subscription from service providers or multi-tenant enterprises environment. And this um as we see at the bottom of the slides we have the service provider

tenant with Asia Lighthouse. That service provider tenant will define a lighthouse template which defines a permission and a role assignment. And then on the right we have the customers tenant and those customers tenant will deploy the template to delegate access to their own resources to that service provider tenant. It's commonly used in a manage for by um managed security service provider or also sock team to gain access to Microsoft sentin workspaces from customers. Once uh they've deployed uh that Azure lighthouse I mean the customers have deployed that Azure lighthouse template they can get uh the service provider uh will get delicate access to those uh Azure resources and from that service provider tenant they will they will have

a centralized view on all those resources they do not need to use guest accounts they only uh they can access that as if the resources were deployed in their own tenant. Um so as I mentioned a template is defined on the managing tenant uh side and then the template is deployed in a managed tenant by a non- guest account in a managing in the managed tenant uh by an account that has owner rights. During testing uh Stephan and I discovered a vulnerability that could allow any user me even guest users uh to do the on boarding of that um lighthouse template. So a guest user can delegate access from one subscription of dev customers potentially to the um to their

service provider tenants. So we decided to report this vulnerability to Microsoft which decided to fix the documentation. So uh it's not a non- guest users it can be any account uh as um if they have the correct permissions. Uh but I think this is quite interesting because if you have owners in your subscriptions and that they have owner permission for some reasons then uh they could um use that access to um delegate some of your resources to their tenant without you knowing and I'm going to come back on that in the next few slides. So how does our third scenario looks like? Um we have my security service provider which is my ad domain. So the

gummlab.local AD environment and that active directory is connected to my gummlab. Microsoft.com and thren and of which the um there is one sync ad group uh that has privilege access admin access to lighthouse delegation from uh my customers. Then we have uh the resilics environment the resilics lab environment um which is the customer tenant. uh with the AD local uh with the ADSRV1 uh domain controllers which is an on- premises server of course and then this server is also on boarding to Asia arc for management purposes to collect the logs and for the deployment of defender for instance and as I mentioned yeah the the Asia admins will get access contributor access to the uh subscriptions in the resilics lab

on Microsoft tenant but what if uh someone compromised the MSSP AD environment then they can add themsel to the sign ed group and then uh they will get uh they can get admin access to the customers subscriptions as environment but also as objects if they use the default configuration. Uh this is uh last demo for today. Uh it's actually how it went or the the scenario went uh when we uh were working on the engagement. Uh it's a bit simplified for demo purposes and the context is changed of course. Um but this is uh exactly how it went. So we are on a standard workstation of a user named user to make it easy. Uh that's my

in my gumm lab uh local ad domain. I'm on standard user workstation which has been uh hybrid Azure AD joined and SSO is not enabled in that case but we can imagine that SSO single sign on would would be enabled in hybrid environment to allow um users to you to use the um on premises identity to connect then to cloud resources without wave and to enter the credentials again. Eventually we were doing some reconnaissance and we discovered that there were a few groups that were hinting that um they could give access to Azure. So that was interesting. We decided to check okay what do we have access in Azure at the moment. Um and then we did not see any uh resources any

subscription. We also were only in the gumml lab.microsoft.com tenant. So nothing sufficient. Eventually we found a vulnerability um by enumerating the ADCS active directory certificate service templates and we found an AC1 vulnerability which is uh one of the most common active directory misconfiguration nowadays and this misconfiguration allows any user in that uh in that AD domain to request a certificate for any user. So in this case we requested a token um a certificate for the built-in domain admin because why not. So here we have the certificate of that domain admin and using another tool we'll ask a TGT so a ticket gaining an access token uh to uh for that built-in admin and inject it in our session so

that we can manipulate group memberships. So in this case yeah we added our user user into the Azure admins group and to just to validate that we have access uh that we have been successfully added uh we can do the get ad group member and we see that there is two users the user admin and the user after refreshing our access in Azure we see that we have now access to a new subscription which is a bides customer demo the as you go subscription uh that subscription is in fact the subscription of the resilics lab tenant and you can see that by the tenant management group ID which is the tenant ID of that resilics lab on

Microsoft tenant and then you also see that we have a server it's maybe going a bit fast but there is an on-prem server that is a enabled and because I am admin contributor access to that subscription I can also execute commands on that uh server I will run two commands uh first to get domain uh to get the domain of that machine just prove I that I have access and then the host name command Um also for demo purposes to show that uh we have access to that server. All right. After some time we'll see that the domain is in it ad.local. So the ad environment of our customer and then we see that uh the domain is adrv1.

All right. Then how does it look like uh in the background? I thought it would be interesting for you to also see uh what is configured in the background. Uh first we have the Azure admin. So we in the managing tenant we have the Azure admin group in Entra which is a group that has been synced from the on premises active directory and we see our two user of which are user named user that we have been added uh adding uh via uh AC1 abuse. Then we see indeed that we have a customer which is uh Resilix lab tenant and then we see that that our bides customer uh demo pass you go subscription has been delegated to the

Azure admin uh group and we see that the contributor and user access admin permission has been uh delegated. On the other side we have the delegate tenant the manage tenant. So the resilics lab on Microsoft tenant we see the subscription that is part of that tenant. And if we go to uh the role assignments in that subscription, we only see one one for the uh owner of the subscription that is uh that has been assigned when creating the the subscription. You do not see Azure Lighthouse permissions that have permission that have been delegated via Azure Lighthouse. You only see that in the dashboard of Azure Lighthouse. There you see that there's indeed a delegation for the subscription

to Asia admins uh with the contributor and user access admin and you do not see what is Asia admins. It could be a group could be a um a user uh and you don't know how it's managed on that uh end. So that's why I mentioned that it's quite interesting um because you can add permission in a stealth way because um not a lot of um companies are constantly looking or even monitoring uh Azure lighthouse deployments. So that's can be quite stealthy because permissions are not shown in uh Azure portal um access control page of a subscription. Okay. Um we can uh how can we detect that? uh we can detect the ADCS abuse in

this case AC1 on the left you see that uh the certificate has been requested by the user user for the built-in domain admin account so that should trigger detection and then you also see that uh following that event the domain admin has authenticated using certificate based authentication so if that's not something you use for your uh built-in domain admin it should be not be used but uh if that's something that is not used um um that should also trigger detection. I also at Microsoft Defender for identity uh running on that uh uh AD environment. Microsoft Defender for identity is an on premises um security solution that will monitor activities that happens on premises and uh I had two alerts two

incidents generated one for certificate enumeration and then one for the certificate based authentication attended for the uh domain admin. However, group membership changes is not something that is uh monitored or often monitored by organization. Uh I've we've actually never been caught um changing group memberships. Um a funny example uh was that an organization they are actually they were monitoring they had alerts for group membership sensitive group members group membership changes. Uh but those alerts were sent to the mailbox of an admin that was only checked once a month. So uh by the time we were done uh they only called us. Um so yeah once you get domain admin changing those sensitive groups that are sync them to

active to entry ID is something that is not uh usually monitored and that can well it's maybe more difficult to uh monitor. How can you defend or can you protect? Our first step is to avoid synchronizing privilege identities or groups from on premises AD that would grant elevated Azure or Entra permission. Uh make sure that those are cloud only uh for users for admin users in Entra. They should be uh clouded only dedicated account and named account not shared account. And then groups should be uh groups that grant uh privilege holes should be also managed in antra only and not synced from AD because otherwise uh this trust relationship can be abused. Then also it's not really the scope of that

presentation but make sure to audit and add your ADCS configuration as I mentioned it's one of the most common AD vulnerability nowadays. So if you have that running in your environment uh make sure to run an audit for that. Uh follow the list principle. It's the third time I'm uh telling that to you now. Um but make sure that you uh follow it uh everywhere uh you can in Azure and everywhere else um because it's um it can prevent most of um abuses or exploits in uh Azure or cloud environment. And then finally as I mentioned monitor for Azure Lighthouse deployments. If you do not use Azure Lighthouse seeing those activities in the Azure activity log should be highly

suspicious. uh and especially if you have a service provider or uh owners in your environment that have elevated access. All right. Uh so for the conclusion um and uh nothing was really new. It was not a zero day. It was also not a misconfiguration in isolation. It's more a chain chaining uh misconfiguration and abusing legitimate services that are actually used in customers environment. So it's made to um highlight that while those services can be used and I I've heard some people saying that do not use Azure Arc it will just uh expand or increase your attack surface on on premises servers. I do not completely agree because it can be used for legitimate reasons. Uh but then make

sure that you are done the configuration of the agent. do not run it in uh the default mode which is a full mode which allows all the capabilities because uh control plane access can translate into uh system or root level access executions on those uh hybrid machines. So yeah to link back to the title of the presentation make sure that you audit also those identity breaches um I think all abuses related to uh entry ID connect are well known ADFS abuse are all well known but those are usually from what I've seen uh less uh monitored or less um tackled by organization what are the main categories uh of this uh presentation uh that's all the

recommendations I've been mentioning during the presentation. So add on the Aure R configuration list principle again rest access when you can then use dedicated cloud only users for admin access or admin task and then um use enter ID groups for uh granting privilege access in a cloud environment or any applications