If you´re using Azure Active Directory (which of course is a pre-requisite to run Microsoft 365 at all, this blog post is for you! Here I´ll list my “Top 8” when it comes to security related issues you need to keep under close guard!
Worst case scenario is of course that a Threat Actor establishes a foothold in your AAD and is allowed to gain access to sensitive data, or even encrypt data.
Azure AD administrators often overlook crucial steps when it comes to secure their AAD. This could lead to Global Administrator accounts being compromised, due to lack of MFA. The Azure AD Connect could be used to decrypt user passwords in order to further cement the foothold of the Threat Actor.
So, let´s get started on that “Top 8” shall we?
.
1. Overpopulated Global Administrators
Boy, if had a penny for every time a customer tenant has exceeded the recommended amount of Global Administrators in Azure AD, I´d be a “rich” man. Global Administrator permission should be tightly kept under close guard. And not the “go to” permisson for administrators. The permissions of Global Administrator are seldom needed, and you could in about 95% of cases make due with a more Role Based Access Control. The administrative roles in Azure AD number to a total of 71 different roles at the time of writing this post. More about these roles and their scope of use based on administrative tasks can be found here: https://docs.microsoft.com/en-us/azure/active-directory/roles/delegate-by-task
2. Not enforcing MFA on administrative users
Again, just as number 1 this is more common than uncommon in many tenants today. Each and every administrative account must have enforced MFA at all times. If you don´t have the licenses for enabling conditional access, you could rely on the built-in “Security defaults” which enforces MFA on every sign-in attempt made by an administrative role. Don´t use geo-fencing to make MFA exclusions on administrative users, they should always be prompted for this. Make sure to require some form of strong authentication in order to register MFA as well. Temporary Access Pass could be used in this scenario to make sure that strong credentials are used to register MFA. In short, require MFA to register MFA. I recently wrote a post about TAP which you can find here: https://hedbergtech.se/exploring-the-new-feature-temporary-access-pass-in-azure-ad/
I´ve seen this many times, that an account gets hijacked due to a misconfiguration in Azure AD which allows the Threat Actor to guess the password, and when prompted for MFA adding their own cell-phone or authenticator app.
3. Lack of Monitoring
Azure AD comes with a default storing of sign-in logs and audit logs for 30 days when you have Azure AD Premium P1. With Azure AD Free, it´s only 7 days. This will not be enough when the “shit hits the fan” and you need to analyze these logs in order to gain insight into when you were breached and what has happened since. But fear not, this can be avoided using your own Azure Log Analytics service. Simply stream the logs to Azure Log Analytics, and you´ll be able to retain these for as long as you are willing. You could of course stream the logs directly into a SIEM solution as well using Azure Event Hubs, or by using Azure Sentinel.
How to stream these logs to Azure Log Analytics can be found here: https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/howto-integrate-activity-logs-with-log-analytics
How to stream your logs to Azure Sentinel is described here: https://docs.microsoft.com/en-us/azure/sentinel/connect-azure-active-directory
How to integrate your logs to existing SIEM solutions is described here: https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/concept-activity-logs-azure-monitor#event-hub-messages-for-activity-logs
Or at your 3rd party vendor, who might even have an add-on for onboarding the logs from Azure AD.
But logs are not all, you´ll need to have some real-time protection as well. Logs are great, don´t get me wrong, but in case your Global Administrator get´s hijacked and is trying to sign in from a 3rd country, Azure AD Identity Protection is here to help. It calculates the sign-in risk as well as the user risk with each and every user protected by it´s policies to make sure that for instance a sign-in attempt from Russia gets blocked rather than allowed in.
4. Insecure Azure AD Connect Servers
Azure AD Connect is used to synchronize your on-premises Active Directory with Azure AD, this calls for some permissions on the on-premises domain, right? Don´t give the Azure AD Sync account in your AD Domain Admin privileges. There are more sufficient permissions required than giving it the keys to the kingdom. But these servers are prime targets when it comes to malicious actors as they offer a way to move laterally within the on-premises AD as well as a way to move to the cloud with permissions in AAD. These servers should be considered Tier 0 resources (same as your domain controllers, active directory federation services…) and only Domain Admins should have administrative rights on them.
5. Overprivileged Applications
Many applications registered in Azure AD are assigned much stronger privileges than they actually require. It is also not obvious that app owners can impersonate their applications, which sometimes leads to privilege escalation. Registered applications and service principals should be regularly audited, as they can be used by malicious actors as presistent backdoors to the tenant by using Credential Roaming.
6. Production Tenants used for tests
During security engagements such as assessments and audits I see a lot of dev-apps. These are a security risk as they might be forgotten, fall under number 5 in this list, therefore exposing too much PII etc.
Dev/QA should always have a separate standalone tenant.
7. Default settings in Azure AD
There are of course some security settings applied when you first spin up your AAD. However, it is not the tight knitted settings one might want.
For instance, the default setting for every Azure AD is that regular users can grant consent to whatever 3rd party application they´d like:
This should not be the case, as users might grant an application way too much permissions leading to unexpected dataleaks.
The preferred setting here is:
Another thing is Basic Authentication, Microsoft aims to disallow Basic Authentication (POP3, IMAP, MAPI, SMTP) from accessing your Office 365 environment. But that is not the case yet, you NEED to block these protocols as much as possible as they only require username+password for authentication.
Use Conditional Access to block Basic Authentication or Security defualts, which achieves the same result.
8. Insecure ADFS settings
Many organizations just spin up ADFS and let the default settings stand for every relying party. When it comes to authentication via ADFS for Office 365, the endpoints listed in the table below are the minimum set required to achieve this. Every other endpoint for the Office 365 relying party can be disabled:
Endpoint | Purpose |
---|---|
/adfs/ls | Browser based authentication flows and current versions of Microsoft Office use this endpoint for Azure AD and Office 365 authentication |
/adfs/services/trust/2005/usernamemixed | Used for Exchange Online with Office clients older than Office 2013 May 2015 update. Later clients use the passive \adfs\ls endpoint. |
/adfs/services/trust/13/usernamemixed | Used for Exchange Online with Office clients older than Office 2013 May 2015 update. Later clients use the passive \adfs\ls endpoint. |
/adfs/oauth2 | This one is used for any modern apps (on-prem or in cloud) you have configured to authenticate directly to AD FS (i.e. not through AAD) |
/adfs/services/trust/mex | Used for Exchange Online with Office clients older than Office 2013 May 2015 update. Later clients use the passive \adfs\ls endpoint. |
/adfs/ls/federationmetadata/2007-06/federationmetadata.xml | Requirement for any passive flows; and used by Office 365 / Azure AD to check AD FS certificates. |
Disable WS-Trust Windows endpoints on the proxy
WS-Trust uses Windows Integrated Authentication (WIA) and should only be exposed on the intranet in your organization.
These Powershell commands helps you perform this:
Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/2005/windowstransport -Proxy $false Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/13/windowstransport -Proxy $false
Extranet “soft” lockout protection for accounts
Extranet lockout helps you to limit the possibility of password spraying or brute-forcing into Active Directory Domain Services. An ADFS administrator can set a maximum allowed number of failed authentication requests (ExtranetLockoutThreshold) and an observation windows
time period (ExtranetObservationWindow). When this maximum number (ExtranetLockoutThreshold) of authentication requests is reached, ADFS stops trying to authenticate the supplied account credentials against ADFS for the set time period (ExtranetObservationWindow).
Use this Powershell command to enable the feature and set the ADFS Extranet Lockout:
Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 15 -ExtranetObservationWindow ( new-timespan -Minutes 30 )
Some really helpful tips in here. Thanks for sharing.