[AUDIO LOGO] Good afternoon. I'm Sean Metcalf. This talk explores typically deployed technology platforms, including Active Directory VMware vSphere, Azure AD, and Azure. The presentation covers common integration and configuration components, how attackers take advantage of these connections, and how to mitigate these attack techniques. The scenarios covered during this talk includes how an attacker with user rights in one platform can leverage connection points and configured access to escalate privileges in other-- systems, or other areas.
I'm the founder and CTO Trimarc, a professional services company that helps organizations better secure Active Directory, Azure AD, and VMware by performing Security Assessments. I'm a Microsoft Certified Master of Active Directory, a former MVP and I've spoken about identity security at many security conferences around the world, including here at TEC.
This presentation covers quite a bit. I will start by talking about the type and configuration of Directory, and infrastructure services both on-prem and in the cloud, what I refer to as the identity Nexus-- how it can be attacked, and then cover mitigation recommendations for each scenario. Feel free to post questions and comments in the chat, live Q&A to follow this presentation.
A nexus is defined as a connection or series of connections linking two or more things, the internet-connected devices and people. So it's only natural that these connections would occur between systems, especially those managing identities. The challenge is that attackers can leverage these connection points in order to gain access to data, escalate privileges, and persist.
In this section, I cover the systems and connectivity that I typically see at most organizations, though your mileage may vary. These systems should be familiar to most of you, since many companies around the world, and indeed [? Trimarc ?] customers, have these deployed along with many others. The dark blue denotes on-prem systems, lighter blue are for cloud systems, and the purple are those that connect on-prem and cloud.
What I call the Identity Nexus, at least for Microsoft, includes the Directory Services, Active Directory for on-prem, and Azure AD in the cloud. For infrastructure, this includes VMware, since vSphere hosts most servers on-prem, and Azure for infrastructure as a service-- what I typically call is the Cloud Infrastructure-- Cloud Data Center-- these four boxes are the core of what I'm covering in this talk.
We start with some important concepts. And practically all large companies' on-prem servers are hosted on VMware, which includes Active Directory, ADFS, et cetera. And these same companies typically have some Azure footprint, which leverages Azure ID for Directory and Authentication Services, among others, and Azure often hosts domain controllers for on-prem AD environment.
Since we have mentioned the common systems, now we dive into authentication. Users authenticate to AD, which gives them access to VMware and more. If they have ADFS for Federation, then ADFS provides the access token which is proof of identity and their authentication to the cloud environment. This quick conceptual overview works for this presentation, so we'll move on.
I've mentioned that cloud is key as a key part of modern IT infrastructure, so let's talk about cloud authentication. And in this case, we're talking about cloud authentication using ADFS, as at least conceptually. So the user authenticates to AD, then attempts to connect to a cloud resource-- let's say the Azure AD admin portal.
Then they get redirected back to ADFS, which leverages the AD authentication, which is usually the Kerberos ticket, to provide a token to the user, which is provided to Azure AD. Azure AD then provides the user a session token, which is usually just a cookie in the browser. So once the user has a session token or cookie, they can open up the Azure AD portal to administer Azure AD.
Now, what if the attacker was able to either compromise the user's computer, even their web browser? The attacker can now extract the session token, and reuse it on their system. And if the compromised admin account is a global admin, this results in Azure AD being compromised. Microsoft's cloud is effectively built around Azure AD as a core directory and authentication system, so let's talk about Azure AD for a bit.
We're most familiar with Active Directory, so we're going to start with the concepts here. We have accounts, and commonly user accounts we refer to as service accounts, since they're used by applications to perform some sort of action, often privileged. The service accounts get these rights through group membership and/or directly configured permissions.
Azure AD has accounts, though this is where it's a bit different. While you can create accounts and use them as service accounts, more commonly, we have applications and we have service principles, and they're tied together. Permissions for applications in Azure AD typically configured on service principles or the application itself, but the concepts between Active Directory and Azure AD are very similar.
We have groups and we have permissions. What's interesting about Azure AD is that there's application permissions that can be set at the tenant level. When we launched our Azure AD security assessment offering in 2019, it quickly became clear that we should have a primary focus on application permissions at the tenant level because of the important nature of this, and how highly-privileged these applications could be. To ensure that we could provide appropriate guidance and recommendations, we spend time identifying those application permissions that are some of the most sensitive.
So here, I'll list some of the most concerning from the first one, which is effective global admin rights to Azure AD, to role management, which provides the ability to add members to-- and update any of the Azure AD roles, application read/write all, which provides tremendous rights to-- on applications in the environment. And then this really weird app, role assignment read/wright all, gives the application the ability to give itself permissions, including directory rewrite read/write all.
And then the last one, I'll cover it a little bit-- in a little bit. Microsoft highlights the issues around a couple of these applications permissions as well. So if you go to the app permissions reference link at the bottom here, there's a couple of call outs that says Microsoft-- Microsoft says, this is really concerning. Try not to use these.
There's a number of ways that an attacker could compromise Azure AD, so here are the two main ones. Compromise an account, either on-prem or cloud, with rights through membership-- that this account has rights through membership in a privileged Azure AD role, or compromise an account with rights on applications to compromise Azure AD.
Accounts in Azure AD can be susceptible to password spray attacks, if legacy authentication is enabled. The attacker attempts to log on as each user with a single password, then moves on to the next password on the list. When the correct password for a user account is successfully guessed, the attacker has compromised that user.
And the attacker can now leverage the user account to perform reconnaissance of the Azure AD tenant, or worse. The attacker could compromise an account with application permission owner rights to add a credential to the application and impersonate the application and associated permissions. So let's see what that looks like. The attacker compromises this account, and could be done through password spraying, or it could be an on-prem account with rights to Azure AD itself, such as owner rights on the application.
So the attacker is going to leverage this account which has owner rights, which has the ability to add a credential to this application. The attacker then impersonates the application and the associated rights in order to compromise Azure AD, because directory read/write all is effective global admin rights.
Or the attacker could compromise an account that has either application administrator or cloud application administrator rights to do the same thing, to add a credential to the application, impersonate the application, and leverage those associated permissions. So the attacker compromises the account. Since this account is a member of application administrator, the attacker is able to add a credential to the application, and leverage those same sort of rights once they impersonate that application. And again, Azure AD is compromised.
One of the things that Microsoft deployed recently or created is called role assignable groups. This is a new group type to enable groups to be members of Azure AD roles. In order to do this securely, they were configured so only global admins and privileged role admins can create and manage them by default.
But you can configure accounts as owners of a role assignable group so that they can manage their members. There's also an application permission that can be configured at the tenant level called RoleManagement.ReadWrite.Directory. This provides management, and group membership writing, and modification of role assignable groups. So this configuration provides some interesting security implications as organizations start leveraging role assignable groups.
What is the attacker's perspective when it comes to role assignable groups? Well, step one, check for owners and management permissions. Step two, discover which role assignable groups have rights to the Azure AD tenant. And step three, compromise an account they can control the role assignable group. Let's see what that looks like.
This attack path maps out how an attacker could leverage an account with rights, by compromising the account with application permission, owner rights, to add a credential to the application, and impersonate the application and associated permissions. So as we see here, basically the attacker is going to compromise this account, and then leverage the owner rights in order to update the member of the role assignable group.
And then using that member that they have compromised, that they've added to the role assignable group, that member of that role assignable group, through the configuration of that group, is a member of the privileged role administrator, which has the ability to modify membership of global admin. And you end up in a situation here where the Azure AD environment is compromised.
So here, we are looking at leveraging these owner rights, as I mentioned earlier. The attacker is going to compromise the account which has the owner rights on the application, and we're going to walk through here, where they add the credential, much like I talked through before. The attacker then impersonates that application, which has these role management read/write directory permissions in order to add a new account to the assignable group which is a member of global admin. And at this point, Azure AD can be compromised that way.
So obviously, there's some concerns around how role assignable groups may be configured. So I wrote out some logic for checking for potential issues with role assignable groups in Azure AD. The first is to check for a role assignable group, then check to see if there's any members-- if there are any members of an Azure AD role associated with this role assignable, which there probably are, and what level they are configured-- then check to see if any of the role assignable groups have an owner.
And then finally, check to see if there are applications with rights, permissions to manage the role assignable groups. If you end up with a yes to these checks in the if section, you may need to adjust to protect your tenant. Review the questions at the bottom to determine the risk.
So here's some security check logic for applications that are highly privileged in Azure AD. First check for a highly privileged application. So these are the applications that have highly-sensitive application permissions. So I covered that in this earlier slide-- at least some of them. And if there is one then you want to check for, a member of application administrator, and members of cloud application administrator, because these are the ones that are able to manage these applications, including adding credentials to them.
If you have a member for at least one of these, and there is a highly-privileged application, then review the questions at the bottom to determine the risk. And finally, here are some security check logic for applications with an owner that also are configured on highly privileged applications within Azure AD.
So this slide lists a number of common Azure AD security issues that we have identified while performing Azure AD security assessments for customers in the Fortune 50 and beyond. Key points of what to do involves leveraging PIM.
So Azure AD Privilege Identity Management is a fantastic way to restrict access and ensure that people only have the rights when they actually require them. Checking for highly-privileged applications in the environment is very important, and then ensure that there are no regular users that are owners of these applications. In fact, it's a good general rule to make sure that there's no regular users that are owners of any application, since there are roles that can be configured for these specific rights that could be provided through owner rights.
Much like Active Directory, when someone creates an application, they are the owner of that. Scrutinize membership of the application, admin, and cloud application, admin roles. Ensure all admin accounts-- so those members of Azure AD roles-- require MFA. Conditional access is a great way to configure this. And you want to restrict user rights to Azure AD, including limiting app consent-- so which applications users can consent to and how-- as well as restricting external user accounts from being able to invite other guests and being able to recon the Azure AD tenant.
And finally, ensure that legacy authentication is blocked through conditional access, or security defaults is enabled. This will block the common password spray attacks that occur. We've now explored what I call the Identity Nexus, and a number of ways that Azure AD can be attacked to get global admin rights. Let's explore now how the Identity Nexus itself can be attacked.
This is how we typically think of identity. There's a chain made up of individual chain links which comprises a strong chain of identity and authentication-- sounds great. We're in really good shape, and everything's going to be fine. But the reality is that this identity chain is made up of very different chain links that have varying levels of strength and security, and maybe Identity is more of a patchwork of connections that aren't very strong or connect well at all.
This very connectivity challenges assumptions, and often gives attackers the edge. I mentioned earlier that, for many companies, there are two different segments, directory and infrastructure, split into on-premises, cloud, and hybrid components that connect on-prem and cloud.
This conceptual graphic shows how these systems, typically deployed in many organizations, are deployed and configured on infrastructure-- usually VMware, AWS, Azure, et cetera. The first the Identity Nexus attack scenario I cover in this presentation is how enterprise password vaults can be attacked.
In 2018, I talked about attacking typical administration in most companies, which included how to compromise enterprise password vaults, such as CyberArk and SecretServer. The password vault usually stores highly-sensitive credentials, such as domain admin and global admin account credentials.
Attackers love targeting these systems, these enterprise password vaults, since compromising the password vault often provides admin rights to every system on the network, and beyond. In this scenario there's a vault admin group that contains a regular user account that the attacker is able to compromise. From there, they have admin rights on the enterprise password vault which contains admin credentials to Active Directory and Azure AD.
In this scenario, the attacker either compromises the workstation the account with rights is using, or simply the web browser the account uses to authenticate to the enterprise password vault. From there, again, they have admin rights to Active Directory and Azure AD most commonly. Or the attacker identifies a file share on the network with account credentials that provides admin rights to the enterprise password vault.
From there, they, again, have admin rights to Active Directory and Azure AD. So conceptually, we can see how the password vault provides access and admin rights to Azure AD and Active Directory, since very often these credentials for Azure AD, Active Directory, and other systems-- which can include SQL, which include other systems that are being managed, like Workday, some of the most critical and most important systems in the customer environment, in the corporate environment, are typically managed and maintained within the password vault, which makes it very important to protect.
But the challenge here is that the password vaults are not often secured at the level they should be. During assessments, we have identified security issues with most enterprise password vaults. There's a number of ways to compromise these password vaults as an attacker. So compromise the user authentication, compromise a vault admin account, get local admin rights on the vault server, get access to a share that has vault credentials stored on it. This is what happened to Uber, based on published information, as shown in the graphic on the right.
So the key mitigations here include limiting and rights to the password vault by reviewing AD groups that have rights to the vault, limiting who can administer the vault servers including, GPOs that are linked to the OU containing the vault servers. And really, AD admins should only use AD admin systems-- same thing with Azure AD.
You want to make sure that you can restrict and isolate these highly-privileged credentials in order to ensure that you can limit access to them. And when you're using a vault, that's no different. The vault has to be protected at that level as well. And then finally, ensure that vault credentials are not stored anywhere on the network.
So next stop is attacking VMware and Active Directory. So VMware administration is often performed within Active Directory account that's a member of an AD group, such as VMware Admins. So the items in this orange box are in Active Directory itself. In this scenario, the attacker compromises an account which is in the VMware Admins group to compromise vSphere, which hosts virtual domain controllers.
So compromise of vSphere results in compromise of these virtual DCs to compromise Active Directory, which includes multiple AD [INAUDIBLE] on the network if those DCs are hosted on VMware as well. So the interesting thing here is that it's a bit circular. We compromise an AD account to compromise VMware to then jump back and fully compromise Active Directory.
This slide breaks down the scenario I just covered. So VMware admins and AD, which usually includes at least some regular user accounts. And since domain controllers are hosted on this virtual infrastructure, compromise of VMware can result in compromise of Active Directory. The key mitigations here include ensuring that any groups that manage VMware are well-protected in Active Directory, or don't leverage AD accounts to manage VMware at all.
Ensure that there are no regular user accounts that have VMware admin rights, and only admin accounts are used for VMware vSphere administration. Use admin systems for protecting VMware administration. So we've discussed attacking VMware and Active Directory. Now we add an Azure AD as part of the Identity Nexus.
Before talking through this attack scenario, it's necessary to talk about the user administrator Azure AD role. The key points here that the user administrator role can change security group membership, and can reset user passwords, which makes sense. This is a user administrator role. But Microsoft is also thought through privilege escalation to get to global admin, so the direct paths to global admin are not available.
In this scenario, the attacker compromises an account that's a member of the User Administrator role, which I mentioned, has the ability to change a password, or update group membership. And in this scenario we're talking through, basically, with this compromised admin account, the attacker is going to change the password on an account that is a member of the VMware Admins group-- through a process called password write-back, which is being enabled more and more in environments, this changed password on the account within Azure AD, in that blue box up at the top, is going to replicate and synchronize back to on-prem AD environment.
So that user account has this password that's been changed that the attacker knows. And since this account is already a member of the VMware Admins group, the attacker then can compromise VMware. Another interesting note on this is that the attacker could leverage the same admin account in order to leverage that User Administrator role.
But this time, they're going to add a group member into this group, VMware admins, which is synchronized up to Azure AD. And in this environment, group write-back is enabled. So soon after updating the group membership on the VMware group in Azure AD, the attacker-added group member synchronizes to the VMware group in Active Directory on-prem.
Once this happens, the attacker can leverage the AD account that is now a member of on-prem VMware admins group, and use this to compromise VMware. So what's really interesting about this is we have an admin account that is either on-prem or in Azure AD, but with the attacker being able to compromise that account, even if this account has no rights in on-prem AD environment, because they're a member a user administrator in Azure AD, and we have some interesting configurations here. So group write-back is now in public preview, and many customers are looking at leveraging this functionality.
So in this scenario, we leverage potentially an Active Directory account or an Azure AD account with rights in Azure AD to make changes to actually be able to administer VMware. Those changes synchronize back from Azure AD to Active Directory, which gives the attacker full rights to VMware, which as we've seen before it can give us full rights and compromise other systems as well.
This slide covers the key takeaways of this attack scenario. Synchronization of on-prem accounts, and groups of the cloud, and subsequent right back to on-prem is useful, but can be problematic. Write-Back as a useful feature, but now imbues Azure AD admins with on-prem superpowers because of how these integration components are often configured.
Key mitigation for this attack scenario, ensure only it's admin accounts or members of Azure AD roles, preferably leveraging PIM, and MFA is required for these accounts. Another key takeaway is don't synchronize on-prem admin accounts and admin groups to Azure AD. We see very often during our assessments that a lot of organizations synchronize a huge number of groups from their on-prem and AD environment up to Azure AD.
It's effectively, let's just send them all up there. So it's really important to think about the potential issues before enabling these hybrid cloud integration features, especially with newer features, such as group write-back. So this next attack scenario covers attacking Azure and Active Directory through Azure AD.
In 2019, I performed research on the connection points between Azure AD and Azure, and one of the things that I discovered was how easy it was to jump from Azure AD admin rights to Azure root admin rights with minimal logging or the ability to check for this configuration. As shown in the graphic here, a global admin can flip this magic button from no to yes, which adds the account to the user access administrator role in Azure, which provides the ability to add this account to any Azure role that they want-- because the user access administrator role provides the ability to modify and manage those Azure accounts at the root level and beyond.
The Trimarc article linked at the bottom of the slide called from Azure AD to Active Directory via Azure, and an unanticipated attack path provides more detail. But I'm going to cover this as a summary. Here's how this attack scenario works. The attacker compromises an admin account that's a member of global admin.
We've covered a number of ways to get this as an attacker in this presentation. So the attacker is going to flip this magic button from no to yes to gain membership in user access administrator in Azure. Once the attacker has a set, they're able to add themselves in any other account any other Azure role they want. So subscription administrator or owner is an interesting one.
But in this case, the attacker adds themselves to the Virtual Machine Contributor role. This role was described as being able to manage virtual machines, but not able to log on to them, not able to gain access to them, including the storage of those systems. However, this role does provide an interesting ability on virtual systems.
It provides the ability to run a command on the virtual system which is executed as system on that Windows Server. When domain controllers for on-premises Active Directory are hosted in Azure, an attacker with the virtual machine contributing rights can execute a command like Mimikatz run from, say, an Azure AD storage blob.
The attacker command execution on the DC can result in compromising the on-prem Active Directory forest or forest without any access to on-prem environment by the attacker, because those changes that happen in Azure on that virtual DC are going to replicate back to on-prem DCs and ultimately compromise Active Directory on-prem.
So the interesting thing about this is obviously Global Administrator is very powerful. Originally, when Microsoft had published information about this, it was documented as an Azure AD thing, that there was nothing that was related to Azure. Based on the research and the feedback that I gave Microsoft, the documentation has been updated, and there's additional logging around this.
But it's still an important thing to understand, and why it's so very critical to monitor and protect these global administrators, and make sure there's no regular user accounts in there. So this conceptual graphic shows how compromise of Azure AD can lead to the compromise of Azure to then compromise of Active Directory, if you have virtual domain controllers in Azure that are not well-protected within the subscription.
Key takeaways here that an attacker with rights in one system can often lead to gaining additional rights in another. And when sensitive systems like domain controllers, [INAUDIBLE], et cetera are hosted on infrastructure, the Identity Access Management, IAM, and security controls need to be carefully considered. Rights in Azure AD can lead to similar rights in Azure, and depending on what's hosted in Azure, can lead to compromise of a number of systems.
Key mitigations for this scenario include making sure that you protect your global admins. Use PIM for this role as well as the other Azure AD Roles-- requiring MFA for your global admins and the other Azure AD roles. And of course, monitoring the membership of sensitive Azure roles, including user access administrators. So that way, you know when someone gets into that role.
And then also consider separating some sort of systems, such as domain controllers, into another tenant so that way there is no connectivity from Azure AD into this Azure environment. This next attack scenario explores how attackers can compromise ADFS and the related impact. In 2017 at DEF CON, I talked about a potential attack on ADFS that would later be termed the Golden SAML attack.
I discussed how an attacker could compromise an ADFS server, extract the certificates, and then ultimately spoof access to the cloud services to which the ADFS server federates. And as you can see on the slide from DEF CON 2015, I highlight that if you can own the federation server, you own the organizational cloud services. And this is very similar to Golden Tickets, relating to Active Directory in the KRBTGT account.
Since this DEF CON talk, there have been several tools released on how to execute this attack method. Again, once the attacker gains rights to the ADFS server, or even the SQL database the ADFS uses, they are able to leverage this attack method. In the first ADFS attack scenario that I cover here, the attacker compromises a VMware admin account to then compromise VMware.
OK, we've seen that. However, the ADFS server is typically virtual, and virtualized on VMware. And in this instance, the compromise of ADFS results in the compromise of Azure AD by impersonating an Azure AD admin. Effectively, the attacker is going to take that certificate, create their own token, and provide their forged token, that spoofed token, saying that they're a Azure AD admin.
Depending on the configuration, this will work in most organizations. So we provide that token to Azure AD, it's going to say, oh, hello there, global admin. Welcome. So very similar, we have an attacker, compromised an admin account, which is in VMware admins, compromised VMware vSphere to compromise the virtual ADFS server.
But this time, the attacker is leveraging the ADFS certificate in order to federate to Azure and show that, hey, I'm an Azure admin, and I have full rights to Azure. So now that-- through this compromise of VMware and infrastructure in the on-prem environment, they are compromising infrastructure in the cloud environment.
And it's not just Azure. This is any cloud system that ADFS is to. So once the attacker compromises ADFS, they can jump to something like Amazon AWS.
And as I said, really, anything that ADFS federates to. So check your federations, and make sure your ADFS servers are well-protected. They should be treated like domain controllers, as a so-called tier zero system.
So the key takeaways here include the fact that, based on what we see during assessments, VMware security is often lacking. It's likely due to the fact that VMware security is rarely reviewed or even assessed. Think about the last time that you've had a security assessment of VMware. It probably hasn't happened.
Since most organizations host the majority of their systems on VMware, it is a target. Attackers are going after this. Ransomware is targeting VMware, and they're getting more sophisticated in how they do this. Attackers are setting their sights on VMware, since it provides so much incredible access to useful data, the ability to escalate, and then persist in the environment.
It's critical to ensure the security posture of the VMware environment is considered at the same level as Active Directory and other sensitive systems, and this includes VMware administration. This next attack scenario explores how attackers can compromise Azure AD Connect, and the related impact. In this AD Connect attack scenario, the attacker compromises a VMware admin account to then compromise VMware. We've seen this.
In this case, the Azure AD Connect server is typically virtual, and the compromise of this virtual Azure AD Connect server results in the compromise of Azure AD. Because Azure AD Connect has a service count that's associated with on-prem environment, but it also has a service count in Azure AD, which provides full write access to Azure AD. So the Compromise of Azure AD Connect on-prem results in the Compromise of Azure AD in the cloud.
And as we can see here, again, anything that's virtualized on VMware, once the attacker can compromise VMware, everything else can fall down like dominoes. Key takeaways here are similar to what I covered earlier, ensure the security posture of the VMware environment is well-configured. The mitigations are the same as well, protect the VMware vSphere platform and ensure that administration is well-secured.
It's critically important to do so, especially with all of the really important systems and sensitive systems that are hosted on this platform. The next attack scenario explores how attackers can leverage IPMI systems like HP iLO and Dell's iDRAC. So what is IPMI? IPMI is the Intelligent Platform Management Interface, which is effectively a computer system inside the computer that interfaces with these key system components.
The IPMI system typically listens on one or more network interfaces, and many times it's available on the corporate network the server is connected to. So it's effectively a computer in a computer. So they put a computer in the computer so you can computer your computer. IPMI systems, such as HP iLO and Dell iDRAC are vulnerable, as shown by numerous security issues reported over the years to CVEs.
This is compounded by the fact that server firmware is rarely updated unless there's a hardware issue, meaning that vulnerabilities which might normally be fixed through a regular patch cycle are not since IPMI updates are facilitated through firmware updates. I know server admins are hesitant to typically update the server firmware when a server is operating and running just fine.
Almost 10 years ago, CISA posted an article-- so in 2013-- highlighting security issues with IPMI. And as part of this, the article includes a number of risk areas attackers can take advantage of, from the way the passwords are managed by IPMI, or the fact that often one password that's configured is configured across all the IPMI systems-- and the fact that root access on the IPMI system gives complete control over hardware, software, and firmware on that physical server.
And also, IPMI typically results in remote console access to the system, resulting in access to pretty much everything. So this is very dangerous, and it's not like this is complicated in how to compromise IPMI. HP iLO had an interesting vulnerability released in 2017 where the attack involves sending 29 characters, specifically the letter A. So like I said, it's not challenging to compromise or leverage these attack methods against a system.
And all we're doing is basically sending this command to the little web server that IPMI is running on the physical server that's typically on the corporate network. Shouldn't be on the corporate network, but it often is. In 2020, Del iDRAC suffered a serious buffer overflow vulnerability affecting iDRAC 7, 8, and 9.
This is where an unauthenticated remote attacker might be able to execute arbitrary code on the system. This is bad. And tow Dell iDRAC vulnerabilities from 2018 involve privilege escalation, which enables full admin rights to the system. This is super duper bad. So we can check for IPMI on the network, but ultimately compromising a physical server boils down to either gaining physical access or compromising an out-of-band management system like iLO or iDRAC.
iLO hosts a web server on port 2381, iDRAC on 5696 or 5353. We can scan for this, using PowerShell or other scanning tools, to see if the physical server has IPMI exposed on the corporate network looking for these ports. IPMI has had a number of security issues with firmware patches available. As I mentioned earlier, the issue is that pretty much no one updates firmware on physical servers.
And some of the most sensitive systems in an environment run on these physical servers. This graphic conceptually shows how physical server security is effectively based on IPMI security. This includes typical systems, such as VMware ESXi, certificate authority hosts, and domain controllers, which ultimately hosts VMware, vSphere, PKI, and Active Directory, respectfully.
Attacker compromise of IPMI would result in the compromise of physical servers and the hosted systems, including ESXi, CAs, and DCs. Key takeaways here include IPMI systems are often enabled by default, and may be listing on the corporate network instead of an out-of-band network, which is the best practice. If IPMI is available on the corporate network, this makes things easy for the attacker, especially when server firmware hasn't been updated in years, because as I showed you on the previous slide, all the attacker has to do is scan the network looking for these ports that are available.
And once an attacker can compromise IPMI, they can typically compromise the physical server, gaining remote access to memory, storage, and even a remote console. Isolating IPMI to an out-of-band network helps mitigate most of the issues. Updating the server firmware when there are security issues, and preferably before they're identified, is key.
Eclypsium has done a ton of research into firmware issues, and this article is listed here linked at the bottom highlights a number of issues with firmware security. I strongly recommend-- I highly recommend that you go and check this out. And I've explored a number of systems on most customer environments, but what about the so-called admin forest, or red forest, used to manage other AD forests? We've assessed a bunch of admin forests, so let's discuss some of the security challenges.
Microsoft developed the admin forest concept in order to provide secure administration of other AD forests in the environment. The goal is that the admin forest is the most protected on the network. So it's very difficult to attack, at least it should be, since it can manage other production forests on the network. The challenge here is that it's difficult to get this configuration 100% correct and ensure full isolation from other systems.
Here are the key points with an admin forest. It's isolated, very well-protected with strong network controls and authentication security. There's a special one-way trust with managed forests to ensure getting into the admin forest is infeasible-- from a managed forest into the admin forest. Administration of the admin forest is performed with separate special admin accounts different from those managing the various AD forests in the environment.
The admin forest should use current Windows versions, and ensure the environment is patched as quickly as possible. So the attacker may have identified there's a shared system that manages the admin forest, or even a mistake in how admins connect to it. Through this crack in the admin forest security, the attacker gains elevated rights in the admin forest, compromising it, and then compromise-- resulting in compromise of the managed AD forest.
But of course, I mentioned IPMI. So in this scenario, the attacker is able to identify that physical servers are running IPMI, and they're on the corporate network. The servers have not had a recent firmware update, much like many servers, which often hasn't been done in years. So IPMI is often, and probably, vulnerable to multiple attacks.
The attacker here is able to compromise the physical servers, and gain access to the servers and the systems hosted on them. This would result in compromise of the admin forest, and ultimately the managed AD forest. So it's important to ensure that all the design protections are still in place, and the security administration processes are followed appropriately, even years after deployment of the admin forest.
IPMI is a big risk to most admin forests if not isolated and updated appropriately. Ensure that IPMI is appropriately configured, secured, and updated. Only the tier zero system should have access. No system should be shared with other AD forests, especially when talking about the admin forest.
And the trust configuration should be secured appropriately, and not use external trusts. External trusts have some issues with them, so we need to make sure that we're using forest trusts. And finally, ransomware-- the scourge of the world right now.
And this is where it gets really ugly, since once an attacker gains a foothold in one system, they can often jump to another. Ransomware actors are figuring this out, and they're working to automate moving around these connections and across these systems. And with cloud actually makes this quite a bit easier, because there's API-- it's configured in the environment, and these are fairly standard, and published. So it makes programmatic administration and manipulation of these environments fairly straightforward.
In conclusion, we are just starting to see challenges with what I call the Identity Nexus. This is where these interconnections create attacker opportunity. We need to think through how these connections are configured, and if security gaps are introduced along with unanticipated security challenges. It's very important to review these systems as well as the connection points to discover security concerns.
I have summary mitigation slides to follow this one that wraps up pretty much everything I've covered, and some additional recommendations. The slides are available for download and review after this talk. Also, a live QA to follow. Please post your questions in the chat.
That has been my time. Thank you very much for yours.