
Using PowerShell to Identify Federated Domains
The Economy of Mechanism – Office365 SAML assertions vulnerability popped up on my radar this week and it’s been getting a lot of attention. The short version is that you could abuse the SAML authentication mechanisms for Office365 to access any federated domain. It’s a really serious and interesting issue that you should totally read about, if you haven’t already. I have a feeling that this will bring more attention to domain federation attacks and hopefully some new research into the area.
Since I’m currently working on some ADFS research (and had this written), I figured now was a good time to release a simple PowerShell tool to enumerate ADFS endpoints using Microsoft’s own APIs. The SAML assertions blog post mentions using this same method to identify federated domains through Microsoft. I’ve wrapped it in PowerShell to make it a little more accessible. This tool should be handy for external pen testers that want to enumerate potential authentication points for federated domain accounts.
Office365 Authentication
If you are trying to authenticate to the Office365 website, Microsoft will do a lookup to see if your email account has authentication managed by Microsoft, or if it is tied to a specific federation server. This can be seen if you proxy your traffic while authenticating to the Office365 portal.
Here’s an example request from the client with an email address to check.
GET /common/userrealm/?user=karl@example.com&api-version=2.1&checkForMicrosoftAccount=true HTTP/1.1 Host: login.microsoftonline.com Accept: application/json Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate X-Requested-With: XMLHttpRequest Connection: close
You will get one of two JSON responses back from Microsoft:
- A response for a federated domain server endpoint:
{ "MicrosoftAccount":1, "IsDomainVerified":0, "NameSpaceType":"Federated", "federation_protocol":"WSTrust", "Login":"karl@example.com", "AuthURL":"https://adfs.example.com/adfs/ls/?username=karl%40example.com&wa=wsignin1.0&wtrealm=urn%3afederation%3aMicrosoftOnline&wctx=", "DomainName":"example.com", "FederationBrandName":"ExampleCompany" }
- A response for a domain managed by Microsoft:
{ MicrosoftAccount=1; NameSpaceType=Managed; Login=support@OtherExample.com; DomainName=OtherExample.com; FederationBrandName=Other Example; TenantBrandingInfo=; cloudinstancename=login.microsoftonline.com }
The PowerShell tool
To make this easier to parse, I wrote a PowerShell wrapper that makes the request out to Microsoft, parses the JSON response, and returns the information from Microsoft into a datatable. You can also use the -cmd flag to return a command that you can run to try and authenticate to either federated domain servers or to the Microsoft servers.
Here’s a link to the code – https://github.com/NetSPI/PowerShell/blob/master/Get-FederationEndpoint.ps1
Here’s an example for each scenario:
Federated Endpoint:
PS C:> Get-FederationEndpoint -domain example.com -cmd | ft -AutoSize Make sure you use the correct Username and Domain parameters when you try to authenticate! Authentication Command: Invoke-ADFSSecurityTokenRequest -ClientCredentialType UserName -ADFSBaseUri https://example.com/ -AppliesTo https://example.com/adfs/services/trust/13/usernamemixed -UserName 'test' -Password 'Summer2016' -Domain 'example.com' -OutputType Token -SAMLVersion 2 -IgnoreCertificateErrors Domain Type BrandName AuthURL ------ ---- --------- ------- example.com Federated Example Company LLC https://example.com/app/[Truncated]
If you’re trying to authenticate with this command, it’s important to note that this does require you to guess/know the domain username of the target (hence the warning). Frequently, we’ll see that the email address account name (ex. kfosaaen) does not line up with the domain account name (ex. a123456).
Microsoft Managed:
PS C:> Get-FederationEndpoint -domain example.com -cmd | ft -AutoSize Domain is managed by Microsoft, try guessing creds this way: $msolcred = get-credential connect-msolservice -credential $msolcred Domain Type BrandName AuthURL ------ ---- --------- ------- example.com Managed example NA
If you get back the “managed” response from Microsoft, you can just use the Microsoft AzureAD tools to login (or attempt logins).
Since this returns a datatable, it’s easy to pipe in a list of emails to lookup federation information on.
*Screenshot Note – This was renamed from Get-ADFSEndpoint to Get-FederationEndpoint (10/06/16)
Prerequisites
Both of the authentication methods that the script returns are taken from Microsoft, and since I don’t own that code, I can’t redistribute it. But here’s some links to get the authentication tools from them.
The code for Invoke-ADFSSecurityTokenRequest comes from this Microsoft post:
The Microsoft managed authentication side (connect-msolservice) comes from the Azure AD PowerShell module. See Here:
Finally, here’s a nice run down from Microsoft on how you can connect to any of the Microsoft online services with PowerShell:
Future Work
Taking this further, you could wrap both of these authentication functions to automate brute force password guessing attacks against accounts. Additionally, you could just use this script to enumerate the federation information for the Alexa top 1 million sites. Personally, I won’t be doing that, as I don’t want to send a million requests out to Microsoft.
I actually have some other stuff in the works that is directly related to this, but it’s not quite ready to post yet. So keep an eye on the blog for more interesting ADFS attacks.
Explore More Blog Posts

Shift Left Security: Integrating Pentesting Early in Development
Discover how to integrate penetration testing into a shift left security strategy, enhancing application security early in the development lifecycle.

Validating Azure Cloud Security with Breach and Attack Simulation as a Service
NetSPI’s Breach and Attack Simulation as a Service offers focused simulation tests for Azure users to validate your cloud security capabilities.

Getting Shells at Terminal Velocity with Wopper
This article introduces Wopper - a new NetSPI tool that creates self-deleting PHP files and automates code execution on WordPress using administrator credentials.