Defending the Identity Nexus

[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--