^{Image by JoRockleyArt from Pixabay}

How do you protect your identities in a cloud world, where, – as Microsoft states- the identity is the new control plane? The countermeasures of modern identity thefts are well known:

• Use Password-Hash-Sync and not ADFS, you get additional features like ‘Leaked Credentials‘ and the full protection power of Azure AD like smart lockout & password protection.
• Use Windows Hello and Password-less authentication to eliminate one of the weakest links in your security strategy. If somebody films you typing in your password, he might be able to access your cloud data, if they are poorly protected. This is not possible if he films you using Hello, even if you work with PIN instead of biometrics, the attacker would need your device in addition to the PIN.
• Hammer into the heads of all IT people in your company that Azure AD is now the primary identity provider. With that you have the same controls like Conditional Access over all your different workloads (Third-Party SaaS-Apps, On-prem Web Apps, WiFi-Auth, etc.)
• Don’t let users consent to apps – in general – or fine tune it through ‘permission classifications‘, to prevent consent phishing.
• Don’t require user passwords to be too complex and don’t expire them! (In short: ‘Summer01!’ … ‘Summer12!’ is not better than ‘breadbutterhoneywalnuts‘)
• Use MFA through Conditional Access. Free your users from getting prompted for MFA when they come from a compliant device. Use the Authenticator App.
• Require MFA + Microsoft Cloud App Security session control, if the users are not coming from a trusted (compliant) device to restrict data access (e.g. read only).
• Use Identity Protection Policies to mitigate potential credential theft (We will discuss below why this does not solve all your problems, as you might expect).
• Enable Self-Service Password Reset, which you need for the Identity Protection policies and which brings you a lot of joy and happiness anyway.
• Block legacy authentication via Conditional Access and on the service level, e.g. Exchange Online, so that you not find yourself in a situation where you protect the front door with the fanciest technologies while you leave the backdoor wide open.
• After all these steps, Conditional Access is your most important control. Make sure you include user risk-based policies and device risk-based policy into your considerations.
• Don’t forget on-prem. Even if you are totally cloud-minded (which is good), I am sure, if your company has a certain size, your identity will still originate on-premises in your local AD. There are known cloud-attacks out there, that start on-premises. Put Azure ATP in place to monitor your on-prem authentication.
• Don’t use standing admin permissions. Instead let admins request and justify additional permissions via PIM. By the way, there is a handy tool that might help you, if you work in multiple PIM contexts: PimMeNow!
• To make it more convenient for your admins (Security has to be the best friend of the users and the admins, otherwise both of them will try to find bypasses of your controls), you can give them read-only roles per default. Often, most of the tasks can be done by viewing. Then, when they need to write – they would need to pim their selves.
• Take care of permission & guest lifecycle via identity governance. Marco has more on that.
• Continuously educate your users. There are voices out there saying, forget the users, concentrate on technology. I don’t think so. Just imagine your users as some sort of a TPM that holds one or more secrets, be it a password, a fingerprint or whatever. Harden that TPM as good as you can.

This list costs you quite a bit of an effort to implement (and maybe some additional licenses) and I guess, you will be disappointed, if I tell you now, its still not enough!

Even if you implemented the above list in the best manner, there are still gaps for attackers (I mean, in general this is no surprise). Let’s take for example the Identity Protection policies. With that you create rules that require a user to get prompted for MFA when a ‘unfamiliar sign-in’ at a certain severity was recorded.

There are two problems with that:

1. “… gets prompted at a certain severity” – you don’t want to set the triggering severity too low, to not annoy your users and more importantly: not to deaden them. So, do you ignore the lower severity alerts that are not covered by your policy?
   
2. Is everything good, after the user confirmed the MFA prompt? (No)

In both cases, you don’t have enough evidence to know what’s going on. To gain more evidence, you need to correlate data. I have seen situations, where users clicked on a credential phishing link, typed in their password and then got a call by “Microsoft” (in case you didn’t recognize the quotes, this was the attacker) telling them to confirm a MFA prompt that would shortly come to their mobile devices, which -sure enough- they did. BAM!

Correlating Data

You need to put together multiple pieces of evidence to make it more probable that your assumptions are correct. The good news is, there are tools that help you with that.

The attack, I described above is very common. So how do you hunt for it? One possibility (and there are many) is to use the MDATP alert “Suspicious URL clicked” (which is triggered by Office ATP). So, if you remember the scenario, the user clicks on a URL and types in the password. The attacker will then use the credentials and make the user confirm the MFA prompt somehow. With that the attacker can login from his location.

If you check our list above, you will recognize that the attacker only has read-access now, due to the MCAS session control and the fact that the attacker is not coming form a trusted device. However, read-access is not too bad.

But the attacker leaves traces. He is probably coming from a new and unfamiliar location, when he signs into AAD. With that we have two pieces of evidence:

Unfamiliar Sign-in & Suspicious URL clicked.

You can combine these in a Azure Sentinel query:

SecurityAlert
| where AlertName has "Unfamiliar sign-in properties"
| where TimeGenerated > ago(1d)
| extend $account1 = tostring(parse_json(Entities)[0].["Name"])
| join (
SecurityAlert
| where AlertName has "Suspicious URL clicked"
| where TimeGenerated > ago(30d)
| extend $account2 = iif(isnotempty(tostring(parse_json(Entities)[4].["Name"])), tostring(parse_json(Entities)[4].["Name"]), tostring(parse_json(Entities)[1].["Name"]))
| project TimeGenerated, DisplayName, $account2
) on $left.$account1 == $right.$account2

In this query, we are joining the two events, so whenever a “Unfamiliar Sign-in” alert is triggered by identity protection, the query will look after “Suspicious URL clicked” events for that user during the last 30 days. If both is true for a certain user, you should look into it.

Fusion

With fusion Azure Sentinel has some more built-in capabilities for such correlations like:

• Sign-in event from an unfamiliar location leading to mass file download
• Sign-in event from an unfamiliar location leading to Exchange Online mailbox exfiltration

and more.

There are also other cool ideas in the Internet that take travel plans of your users into consideration to put more value into events like ‘impossible travel’. Check out this great video: https://www.youtube.com/watch?v=BcxiY32famg&feature=youtu.be

Local Credential Stealing

Another chance for correlation of important events comes into play, when you get familiar with the latest blog post of Dirk-Jan Mollema. Together with Benjamin Delpy, he found out about stealing Primary Refresh Tokens on Windows 10 machines by the help of Mimikatz (Which was developed by Benjamin). Read more details here. One of the counter measures here is to turn on the ASR rule to block credential stealing from LSASS. Which in turn brings many false/positives. But we can -again- combine those ASR (Audit) Alerts with unfamiliar sign-ins, since the attacker would have different sign-in properties, when he had stolen the PRT. Together with a friend, I will write about this in more detail in one of my next blog posts.

Wrap-Up

We already covered two important elements of a successful and modern identity strategy:

1. Do (most of) the possible – see the big identity to-do list above
2. Fill the gaps with monitoring / hunting / correlations

The third part is about improvement. Try to stay up-to-date with the latest developments. E.g. you need to know, if there are possibilities to circumvent certain countermeasures, like the one Stephan describes here.

Correlation is getting more and more important. We will see Sentinel and Microsoft Threat Protection with new power here in the near future, since they are integrating more and more data sources. With that, it depends on our defender creativity to build the right queries to separate the wheat from the chaff and track down real identity threats.