MFA and Conditional Access alone won’t save us from Threat Actors

In the end of a week where we have had 2 very different incidents at high profile organisations across the globe, its interesting to look at these and compare them from the perspective of incident response and the “What we could have done to prevent this from happening” question.

Image Credit – PinClipart

Lets analyze that very question – in the aftermath of the majority of cases, the “What could we have done to prevent this from happening” question invariably leads in to the next question of “What measures can we put in place to prevent this from happening in the future”.

The problem with the 2 questions is that they are reactive and come about only because the incident has happened. And it seems that in both incidents, the required security systems were in place.

Or were they?

A brief analysis of the attacks

  • Holiday Inn

If we take the Holiday Inn attack, the hackers (TeaPea) have said in a statement that:

"Our attack was originally planned to be a ransomware but the company's IT team kept isolating servers before we had a chance to deploy it, so we thought to have some funny [sic]. We did a wiper attack instead," one of the hackers said.

This is interesting because it suggests that the Holiday Inn IT team had a mechanism to isolate the servers in an attempt to contain the attack. The problem was that once the attackers were inside their systems and they realized that the initial scope that their attack was based on wasn’t going to work, their focus changed from Cybercriminals who were trying to make a profit to Terrorism, where they decided to just destroy as much data as they could.

Image Credit – Northern Ireland Cyber Security Centre

Essentially, the problem here is two-fold – firstly, you can have a Data Loss Prevention system in place but its not going to report on or block “Delete” actions until its too late or in some cases not at all.

Second, they managed to access the systems using a weak password. So (am I’m making assumptions here), while the necessary defences and intrusion-detection technologies may have been in place, that single crack in the foundations was all it took.

So the how did they get in? The 2 part of their statement shown below explains it all:

TeaPea say they gained access to IHG's internal IT network by tricking an employee into downloading a malicious piece of software through a booby-trapped email attachment.

The criminals then say they accessed the most sensitive parts of IHG's computer system after finding login details for the company's internal password vault. The password was Qwerty1234.

Ouch ….. so the attack originated as a Social Engineering attack.

  • Uber

We know a lot more about the Uber hack and again this is a case of an attack that originated with Social Engineering. Here’s what we know at this point:

  1. The attack started with a social engineering campaign on Uber employees, which yielded access to a VPN, in turn granting access to Uber’s internal network *
  2. Once on the network, the attacker found some PowerShell scripts, one of which contained hardcoded credentials for a domain admin account for Uber’s Privileged Access Management (PAM) solution.
  3. Using admin access, the attacker was able to log in and take over multiple services and internal tools used at Uber: AWS, GCP, Google Drive, Slack workspace, SentinelOne, HackerOne admin console, Uber’s internal employee dashboards, and a few code repositories.

Again, we’re going to work off the assumption (and we need to make this assumption as Uber had been targeted in both 2014 and 2016) that the necessary defences and intrusion detection was in place.

Once the attackers gained access, the big problem here is the one thats highlighted above – hardcoded domain admin credentials. Once they had those, they could then move across the network doing whatever they pleased. And undetected as well, as its not unusual for a domain admin account to have multiple access across the network. And it looks like Uber haven’t learned from their previous mistakes, because as Mackenzie Jackson of GitGuardian reported:

“There have been three reported breaches involving Uber in 2014, 2016, and now 2022. It appears that all three incidents critically involve hardcoded credentials (secrets) inside code and scripts”

So what can we learn?

What these attacks teach us is that we can put as much technology, intrusion and anomaly detection into our ecosystem as we like, but the human element is always going to be the one that fails us. Because as humans, we are fallible. Its not a stick to beat us with (and like most, I do have a lot of sympathy for those users in Uber, Holiday Inn and all of the other companies who have been victim to attakcs that began with Social Engineering).

Do we need constant training and CyberSecurity programmes in our organisations to ensure that our users are aware of these sorts of attacks? Well, they do now at Uber and Holiday Inn but as I said at the start of the article, this will be a reactive measure for these companies.

The thing is though, most of these programmes are put in as “one-offs” in response to an audit where a checkbox is required to say that such user training has been put in place. And once the box has been checked, they’re forgotten about until the next audit is needed.

We can also say that the priveleged account management processes failed in both companies (weak passwords in one, hardcoded credentials in another).


Multi-Factor Authentication. Conditional Access. Microsoft Defender. Anomaly Detection. EDR and XDR. Information Protection. SOC. SIEM. Priveleged Identity Management. Strong Password Policies.

We can tech the absolute sh*t out of our systems and processes, but don’t forget to train and protect the humans in the chain. Because ultimately when they break, the whole system breaks down.

And the Threat Actors out there know this all too well. They know the systems are there, but they need a human to get them past those walls. MFA and Conditional Access can only save us for so long.

100 Days of Cloud – Day 56: Azure Active Directory and the low level of MFA Adoption

Its Day 56 of my 100 Days of Cloud journey, and today I’m taking a look at Azure Active Directory and MFA Adoption.

We already looked at Azure Active Directory and RBAC roles on Day 4, but today I’m looking at this from a different angle. The reason is because of this article from Catalin Cimpanu telling us that MFA Adoption across all Microsoft Enterprise tenants sits at 22%. And while we may think this is low, this is compared to 11% 2 years ago, and as low as 1% 2 years before that.

This is despite the fact that in August 2019, Microsoft said that customers who enabled MFA for their accounts ended up blocking 99.9% of all attacks. On average, around 0.5% of all accounts get compromised each month

So why the low adoption? The first thought is because of licensing constraints, and I thought about that in relation to both Microsoft 365, Office365 and the various Azure Active Directory offerings.

Lets take a look at Azure AD first – there are 4 different offerings of Azure AD:

  • Free – this version is intended for small businesses and has a limit of 500000 objects. It is primarily intended as an authentication and access control mechanism and supports user provisioning and basic user management functions such as creating, deleting and modifying user accounts. These users can take advantage of self-service password change, and admins can create global lists of banned passwords or require multifactor authentication (MFA). There is no SLA with the Free Edition
  • Office 365 Apps – this is the underlying directory service required to operate the applications on the Office 365 platform, such as Exchange Online for email and SharePoint Online for content management. It has the same features and capabilities as the Free version, but it also adheres to a service-level agreement (SLA) of 99.9% availability. This version comes by default will all Office 365 and Microsoft 365 subscriptions.
  • Premium P1 – this contains the following additional features:
    • Custom banned passwords,
    • Self-service passwords,
    • Group access management,
    • Advanced security and usage reports,
    • Dynamic groups,
    • Azure Information Protection integration,
    • SharePoint limited access,
    • Terms of Use,
    • Microsoft Cloud App Security Integration.
  • Premium P2 – as well as the above, this adds on:
    • vulnerabilities and risky accounts detection,
    • risky events integration,
    • risk-based conditional access policies.

In all of the above offerings MFA is offered as a default, even in the Free tier. So the different levels of licensing in Office365 have no bearing on enabling MFA.

The recommended method for enabling MFA is detailed in this article, where it is recommended that either Azure AD Premium P1 or P2.

So now lets look at the different Office 365 and Microsoft 365 versions – below are the versions where Azure AD Premium P1 and P2 are included:

  • Azure AD Premium P1
    • Office365 E3
    • Microsoft 365 Business Premium
  • Azure AD Premium P2
    • Office 365 E5

If your tenant uses the Free Office 365 versions without Conditional Access, you can use security defaults to protect users. Users are prompted for MFA as needed, but you can’t define your own rules to control the behavior. However, if your licences do not include Azure AD Premium P1 or P2, its recommended you upgrade to one of these tiers to include Conditional Access as part of your MFA deployment.


Hope you enjoyed this post, now go and get enabling MFA on your Azure AD, Office 365 and Microsoft 365 Tenants! Until next time!