{
	"id": "d889ad1e-5a93-4e53-90be-42124b51d746",
	"created_at": "2026-04-06T00:11:38.996941Z",
	"updated_at": "2026-04-10T03:21:49.546549Z",
	"deleted_at": null,
	"sha1_hash": "2efdd0cf0ce9984e299cfa3077edd32294b8fd22",
	"title": "Red Teaming Microsoft: Part 1 - Active Directory Leaks via Azure - Black Hills Information Security, Inc.",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1609983,
	"plain_text": "Red Teaming Microsoft: Part 1 - Active Directory Leaks via Azure\r\n- Black Hills Information Security, Inc.\r\nBy BHIS\r\nPublished: 2018-08-31 · Archived: 2026-04-02 10:40:57 UTC\r\nMike Felch //\r\nWith so many Microsoft technologies, services, integrations, applications, and configurations it can create a great\r\ndeal of difficulty just to manage everything. Now imagine trying to secure an environment that goes well beyond\r\nthe perimeter. While moving everything to a cloud provider can provide amazing returns in scalability,\r\nfunctionality, and even savings, it can also create major blind-spots. Over the past year, I have been looking into\r\nways to target organizations that utilize Microsoft as their cloud provider. I hope to release a number of different\r\ntechniques that have been extremely beneficial in uncovering these blind-spots, much like the research Beau\r\nBullock (@dafthack) and I did when we focused our scope on Google.\r\nI won’t begin to mislead you, I am no Microsoft expert. In fact, the more I read about the products and services\r\nthe more I felt lost. While over the past year I’ve been able to maneuver through and bend these technologies in\r\norder to target the organizations better from a red team perspective, I struggled to try to understand many different\r\nconcepts. What is the default configuration for this? Is this provided by default? Is this syncing with everything? If\r\nI make changes here, do they propagate back? Why not? The list goes on and on. When I’ve shared some of these\r\ntechniques privately it was inevitable that a question would immediately follow. While I feel bringing a problem\r\nwithout a solution is irresponsible, there may be times like now where solutions aren’t black and white. My advice\r\nis to know your environment, know your technologies, and if you aren’t sure then reach out to your service\r\nprovider so you can be sure.\r\nhttps://www.blackhillsinfosec.com/red-teaming-microsoft-part-1-active-directory-leaks-via-azure/\r\nPage 1 of 12\n\nThe Microsoft Landscape\r\nSo you’ve been running Microsoft Active Directory and Exchange on-prem for years but want to quickly deploy\r\nMicrosoft Office to your employees while also providing them with access to a webmail portal, Sharepoint, and\r\nSSO for some internal applications. Somewhere along the way, you decided to migrate to Office 365 and\r\neverything works well! All your users can authenticate with their network credentials and their email works great!\r\nWould you consider yourself an on-prem organization still or are you in the infamous cloud now? Maybe you took\r\na hybrid approach and did both. Microsoft provides an amazing amount of integrations that they support but how\r\ndo you know if you are managing everything correctly?\r\nA Hypothetical Complex Situation\r\nFor managing users on-prem there’s the traditional Microsoft AD. For managing users in cloud services, you\r\ncould leverage Azure AD. For mail, there’s Exchange on-prem but you could always move email to Exchange\r\nonline. If you want the full suite of Microsoft Office there’s Office 365 but I think that routes through Exchange\r\nonline in a Microsoft multi-tenant environment anyhow, so you could technically be using both but paying for\r\none. Since you paid for Office 365 Business, you were also provided a number of services like Skype and\r\nOneDrive despite using GDrive or Box for corporate file sharing. You enroll in a multi-factor solution with SMS\r\ntokens being the default delivery mechanism but for some reason, your users can still authenticate with Outlook\r\nwithout needing MFA… weird.. (Major thanks to Microsoft EWS) Overall, everything just works and for that we\r\nhave to thank Azure AD Connect.. or is it Azure AD Synchronization Services.. or are we still running old school\r\nDirSync with Forefront Identity Manager? Whatever it is, it’s working and that’s all that matters!\r\nhttps://www.blackhillsinfosec.com/red-teaming-microsoft-part-1-active-directory-leaks-via-azure/\r\nPage 2 of 12\n\nSo.. What’s the Big Deal?\r\nA number of problems are created in the situation just illustrated and there is very little a blue team can do to\r\ndefend or respond to a number of different attacks ranging from dumping active directory remotely to bypassing\r\nand even hijacking multi-factor authentication for users.\r\nUnderstanding who is who within an organizational department is typically done in the reconnaissance phase of an\r\nengagement through third-party services like LinkedIn or other OSINT techniques. If you are on the internal\r\nnetwork then revisiting this step is crucial because you need to understand deeper details of the organization like\r\nwhat groups are configured and who are the members of those groups. This is vital in being able to successfully\r\npivot to relevant machines and targeting users based on their access so that escalation can be accomplished. But\r\nwhat if you aren’t on the internal network but still need to determine who to target? Even better, what if the target\r\ngems of the organization are hosted in the cloud and you never actually have to hit the internal network?\r\nWith Microsoft, if you are using any cloud services (Office 365, Exchange Online, etc) with Active Directory (on-prem or in Azure) then an attacker is one credential away from being able to leak your entire Active Directory\r\nstructure thanks to Azure AD.\r\nhttps://www.blackhillsinfosec.com/red-teaming-microsoft-part-1-active-directory-leaks-via-azure/\r\nPage 3 of 12\n\nStep 1) Authenticate to your webmail portal (i.e. https://webmail.domain.com/)\r\nStep 2) Change your browser URL to: https://azure.microsoft.com/\r\nStep 3) Pick the account from the active sessions\r\nStep 4) Select Azure Active Directory and enjoy!\r\nhttps://www.blackhillsinfosec.com/red-teaming-microsoft-part-1-active-directory-leaks-via-azure/\r\nPage 4 of 12\n\nThis creates a number of bad situations. For instance, if we were able to export all the users and groups we would\r\nhave a very nice list of employees and the groups they are a part of. We can also learn what group we need to land\r\nin for VPN, domain administration, database access, cloud servers, or financial data. What’s also nice about Azure\r\nAD is that it holds the device information for each user so we can see if they are using a Mac, Windows machine,\r\nor iPhone along with the version information (i.e. Windows 10.0.16299.0). As if all this wasn’t great already, we\r\ncan also learn about all the business applications with their endpoints, service principal names, other domain\r\nnames, and even the virtual resources (i.e. virtual machines, networks, databases) that a user might have access to.\r\nBut Wait, There’s More!\r\nAn added benefit to authenticating to the Azure portal as a regular user is that you can create a backdoor… err… I\r\nmean a “Guest” account. How super convenient!\r\nStep 1) Click “Azure Active Directory”\r\nStep 2) Click “Users” under the Manage section\r\nStep 3) Click “New Guest User” and invite yourself\r\nhttps://www.blackhillsinfosec.com/red-teaming-microsoft-part-1-active-directory-leaks-via-azure/\r\nPage 5 of 12\n\nDepending on their configuration, it may or may not sync back to the internal network. In fact, while creating\r\nguest accounts is on by default — I’ve only verified one customer where Azure AD Connect was a bi-directional\r\nsync allowing guest accounts to authenticate, enroll a multi-factor device and VPN internally. This is an important\r\nconfiguration component for you to understand since it can create a bad day.\r\nAzure for Red Teams\r\nAccessing the Azure portal through the web browser is great and has many awesome advantages but I have yet to\r\nfind a way to export the information directly. I started to write a tool that would authenticate and do it in an\r\nautomated fashion but it felt cumbersome and I knew with all of these awesome technologies tied together that\r\nMicrosoft has solved this problem for me. There were a number of solutions I came across, some of them are:\r\nhttps://www.blackhillsinfosec.com/red-teaming-microsoft-part-1-active-directory-leaks-via-azure/\r\nPage 6 of 12\n\nAzure CLI (AZ CLI)\r\nBeing a Linux user, I naturally gravitated towards AZ CLI. Partially because I pipe as much data into one-liners as\r\npossible and partially because I over-engineer tools in .NET. Using AZ CLI is a quick and easy way to\r\nauthenticate against the OAUTH for Azure while also quickly exporting the raw data. In this post, we will focus\r\non this solution.\r\nAzure Powershell\r\nWith a rise in awesome Powershell tools like Powershell Empire and MailSniper, I’m amazed that Azure\r\nPowershell hasn’t made its way into one of these tools. There are a massive number of Active Directory Cmdlets\r\nto interact with. To get started, simply install Azure RM Powershell then run: Connect-AzureRmAccount\r\nAzure .NET\r\nI am one of those weird nerds who grew up on Linux but wrote C# for a significant portion of my career. Because\r\nof this, having an Azure .NET library to interact with Active Directory is encouraging. I didn’t dig too much into\r\nthese libraries but from a high-level, it seems they are some sort of wrapper for the Active Directory Graph API.\r\nLet’s Dig In!\r\nAs I previously mentioned, we will focus on interacting with Azure using AZ CLI. In order to get started, we have\r\nto first establish an active session with Azure. On red teams where the engagement involves an organization using\r\nMicrosoft or Google services, I rarely try to go straight to a shell on the internal network. I will normally use a\r\ntool I wrote called CredSniper to phish credentials and multi-factor tokens than just authenticate as that user in\r\npursuit of sensitive emails, files, access, information, and VPN.\r\nWill that presupposition, we will assume valid credentials were already obtained somehow.\r\nInstall AZ CLI\r\nYou will need to add the Microsoft source to apt (assuming Linux), install the Microsoft signing key, and then\r\ninstall Azure CLI:\r\nAZ_REPO=$(lsb_release -cs) echo \"deb [arch=amd64] https://packages.microsoft.com/repos/azure-cli/ $AZ\r\ncurl -L https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add -\r\nsudo apt-get install apt-transport-https\r\nsudo apt-get update \u0026\u0026 sudo apt-get install azure-cli\r\nAuthentication via Web Session\r\nAfter everything is installed correctly, you will need to create a session to Azure using the credentials you already\r\nobtained. The easiest way to do that is by authenticating using ADFS or OWA in a normal browser then:\r\nhttps://www.blackhillsinfosec.com/red-teaming-microsoft-part-1-active-directory-leaks-via-azure/\r\nPage 7 of 12\n\naz login\r\nThis will generate the OAUTH tokens locally, open a browser tab to the authentication page and let you select an\r\naccount based on the ones you are already authenticated with. Once you select the account, the local OAUTH\r\ntokens will be validated by the server and you won’t have to do that again unless they expire or get destroyed. You\r\ncan also pass the –use-device-code flag which will generate a token you provide\r\nto https://microsoft.com/devicelogin.\r\nDumping Users\r\nNow on to my favorite part! There have been numerous techniques for extracting the GAL previously researched,\r\nsuch as using the FindPeople and GetPeopleFilter web service methods in OWA. These techniques have been an\r\nexcellent resource for red teamers but they definitely have their limitations on what data is available, how long it\r\ntakes to enumerate users, how loud it is due to the number of web requests required, and how it occasionally\r\nbreaks. With AZ CLI, it’s super easy to extract all the directory information for each user. In the examples below, I\r\napply a JMESPath filter to extract the data I care about. I can also export as a table, JSON, or in TSV format!\r\nAll Users\r\naz ad user list --output=table --query='[].{Created:createdDateTime,UPN:userPrincipalName,Name:displa\r\nhttps://www.blackhillsinfosec.com/red-teaming-microsoft-part-1-active-directory-leaks-via-azure/\r\nPage 8 of 12\n\nSpecific User\r\nIf you know the UPN of the target account, you can retrieve specific accounts by passing in the —upn flag. This is\r\nconvenient if you are wanting to dig into the Active Directory information for a particular account. In the example\r\nbelow, you will notice I supplied the JSON format instead of the table output.\r\naz ad user list --output=json --query='[].{Created:createdDateTime,UPN:userPrincipalName,Name:display\r\nDumping Groups\r\nMy next favorite function is the ability to dump groups. Understanding how groups are used within an\r\norganization can provide specific insight into the areas of the business, the users, and who the admins are. AZ CLI\r\nprovides a few useful commands that can assist here.\r\nAll Groups\r\nThe first thing I usually do is just export all the groups. Then I can grep around for certain keywords: Admin,\r\nVPN, Finance, Amazon, Azure, Oracle, VDI, Developer, etc. While there is other group metadata available, I tend\r\nto just grab the name and description.\r\naz ad group list --output=json --query='[].{Group:displayName,Description:description}'\r\nhttps://www.blackhillsinfosec.com/red-teaming-microsoft-part-1-active-directory-leaks-via-azure/\r\nPage 9 of 12\n\nSpecific Group Members\r\nOnce you have reviewed the groups and cherry-picked the interesting ones, next it’s useful to dump the group\r\nmembers. This will give you an excellent list of targets that are a part of the interesting groups — prime targets for\r\nspear phishing! Against popular opinion, I have personally found that the technical ability and title do not lower\r\nthe likelihood an intended target is more likely to avoid handing over their credentials (and even MFA token). In\r\nother words, everyone is susceptible so I usually target back-end engineers and devops teams because they tend to\r\nhave the most access plus I can usually remain external to the network yet still access private GitHub/GitLab code\r\nrepositories for creds, Jenkins build servers for shells, OneDrive/GDrive file shares for sensitive data, Slack teams\r\nfor sensitive files and a range of other third-party services. Once again, why go internal if you don’t have to.\r\naz ad group member list --output=json --query='[].{Created:createdDateTime,UPN:userPrincipalName,Name\r\nDumping Applications \u0026 Service Principals\r\nAnother nice feature Microsoft provides is the ability to register applications that use SSO/ADFS or integrate with\r\nother technologies. A lot of companies utilize this for internal applications. The reason this is nice for red teamers\r\nis that the metadata associated with the applications can provide deeper insight into attack surfaces that may have\r\nnot been discovered during reconnaissance, like URLs.\r\nAll Applications\r\naz ad app list --output=table --query='[].{Name:displayName,URL:homepage}'\r\nSpecific Application\r\nIn the below screenshot, you see we obtained the URL for the Splunk instance by examining the metadata\r\nassociated with the registered application in Azure.\r\naz ad app list --output=json --identifier-uri='\u003curi\u003e'\r\nhttps://www.blackhillsinfosec.com/red-teaming-microsoft-part-1-active-directory-leaks-via-azure/\r\nPage 10 of 12\n\nAll Service Principals\r\naz ad sp list --output=table --query='[].{Name:displayName,Enabled:accountEnabled,URL:homepage,Publis\r\nSpecific Service Principal\r\naz ad sp list --output=table --display-name='\u003cdisplay name\u003e'\r\nAdvanced Filtering with JMESPath\r\nYou might have noticed in the above examples that I try to limit the amount of data that is returned. This is mainly\r\nbecause I try to snag what I need instead of everything. The way AZ CLI handles this is by using the –query flag\r\nwith a JMESPath query. This is a standard query language for interacting with JSON. I did notice a few bugs with\r\nAZ CLI when combining the query flag with the ‘show’ built-in functions. The other thing to note is that the\r\ndefault response format is JSON which means if you plan on using a query filter you need to specify the correct\r\ncase-sensitive naming conventions. There was a bit of inconsistency between the names for the different formats.\r\nIf you used the table format, it might capitalize when JSON had lowercase.\r\nDisable Access to Azure Portal\r\nI spent a bit of time trying to make sense of what to disable, how to prevent access, how to limit, what to monitor,\r\nand even reached out to people on Twitter (thanks Josh Rickard!). I appreciate all the people who reached out to\r\nhelp make sense of this madness. I suppose I should learn the Microsoft ecosystem more, in hopes of offering\r\nbetter suggestions. Until then, I offer you a way to disable the Azure Portal access to users. I haven’t tested this\r\nand can’t be sure if this includes AZ CLI, Azure RM Powershell, and the Microsoft Graph API but it’s definitely a\r\nstart.\r\nStep 1) Log in to Azure using a Global Administrator account https://portal.azure.com\r\nhttps://www.blackhillsinfosec.com/red-teaming-microsoft-part-1-active-directory-leaks-via-azure/\r\nPage 11 of 12\n\nStep 2) On the left panel, choose ‘Azure Active Directory’\r\nStep 3) Select ‘Users Settings’\r\nStep 4) Select ‘Restrict access to Azure AD administration portal’\r\nAn alternative is to look into Conditional Access Policies: https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/overview\r\nComing Soon!\r\nThere are a number of different tools out there for testing AWS environments and even new tools that have come\r\nout recently for capturing cloud credentials like SharpCloud. Cloud environments seem to be a commonly\r\noverlooked attack surface.\r\nI will be releasing a (currently private) red team framework for interacting with cloud environments,\r\ncalled CloudBurst. It’s a plugginable framework that gives users the ability to interact with different cloud\r\nproviders to capture, compromise, and exfil data.\r\nReady to learn more?\r\nLevel up your skills with affordable classes from Antisyphon!\r\nPay-Forward-What-You-Can Training\r\nAvailable live/virtual and on-demand\r\nSource: https://www.blackhillsinfosec.com/red-teaming-microsoft-part-1-active-directory-leaks-via-azure/\r\nhttps://www.blackhillsinfosec.com/red-teaming-microsoft-part-1-active-directory-leaks-via-azure/\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.blackhillsinfosec.com/red-teaming-microsoft-part-1-active-directory-leaks-via-azure/"
	],
	"report_names": [
		"red-teaming-microsoft-part-1-active-directory-leaks-via-azure"
	],
	"threat_actors": [],
	"ts_created_at": 1775434298,
	"ts_updated_at": 1775791309,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/2efdd0cf0ce9984e299cfa3077edd32294b8fd22.pdf",
		"text": "https://archive.orkl.eu/2efdd0cf0ce9984e299cfa3077edd32294b8fd22.txt",
		"img": "https://archive.orkl.eu/2efdd0cf0ce9984e299cfa3077edd32294b8fd22.jpg"
	}
}