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:

1. 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"
   }

2. 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:

• https://blogs.msdn.microsoft.com/besidethepoint/2012/10/17/request-adfs-security-token-with-powershell/

The Microsoft managed authentication side (connect-msolservice) comes from the Azure AD PowerShell module. See Here:

• https://msdn.microsoft.com/en-us/library/jj151815.aspx

Finally, here’s a nice run down from Microsoft on how you can connect to any of the Microsoft online services with PowerShell:

• https://technet.microsoft.com/en-us/library/dn568015.aspx

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.