When considering the methods of attack an organization should defend itself, what comes to mind? Certainly, you should defend yourself against the most devastating forms of attack. That missing patch that leads to full domain compromise? Take care of that immediately. That password policy that means everyone uses “1234”? Should probably look at that too.
What about the most ubiquitous forms of attack though? These are probably just as important to address when defending yourself against potential attackers. Why though? Because most attackers see these methods as tried and true and are likely a go to when attempting to gain any sort of foothold in a network, because they’re applicable to just about any target network. So, let’s take a look at one of these common forms of attack and figure out how to defend ourselves against it.
One of the most important parts of compromising a domain is compromising a single account to gain access. To do this, an attacker typically needs to enumerate valid accounts to determine what the possible targets are.
One of the most common forms of enumeration involves the exploitation of Office 365. To perform this exploitation, an attacker will first need to determine if the implementation of O365 is managed or federated.
In the case of a managed domain, authentication goes through O365. However, in the case of a federated domain, authentication goes through local Active Directory set up by the organization and is always done through the on-premises Active Directory infrastructure. This means that if the on-prem servers go down – users that are not connected internally to Active Directory could lose access to things like email and the Office 365 suite temporarily until connection is restored.
What does this mean for testers though? In the case of a managed domain, testers are able to use O365 to determine the validity of the accounts in their enumerated list, forming a master list of accounts that can be targeted for attacks such as password spraying.
To avoid allowing attackers to determine the validity of accounts on your network, it’s as simple as setting the domain to federated. But what other factors are there to consider when looking at a managed domain as compared to a federated one?
For starters, an attacker may be able to exploit a managed domain, but managed domains are also far easier for an organization to set up and manage since all functions are carried out through Microsoft online.
Federated is a bit more complicated to set up, leading to many organizations selecting managed domains as their preferred implementation. There are also other factors to consider. For example, an organization had likely been using different services prior, and oftentimes it is far simpler to migrate to a federated domain as compared to a managed one, again motivating many organizations to select a federated domain.
Like everything, there’s always pros and cons to both managed and federated domains. However, from a security posture standpoint, a federated domain provides a substantial roadblock to threat actors.
Whether it’s been on external penetration tests or even red team engagements, running into federated domains has prevented me from enumerating valid emails for the client’s organization. If I were able to successfully enumerate a list of emails through a managed domain, it would have saved me as the attacker a lot of time and made the entire password spray/credential gathering process much smoother and much faster.
Sure, there are other ways of enumeration (and also blind password spraying without any validation) but it’s definitely something that has thrown a wrench in my plans as an attacker and could potentially be the difference maker between getting compromised and staying safe.
Ultimately, it’s important for organizations to choose what suits them best. However, it’s also important to weigh the benefits and risks of each option before deciding which choice to make.
A special thanks to AJ Hammond for assistance in writing this article.
