Hacks Weekly #51 Investigating Risky Events Azure AD

This time we’re going to talk about Azure AD Identity Protection and investigating risky events related to identities. We’re going to detect, analyze and decide what is happening with our users.

First of all, let’s look at the Azure Portal. Let’s launch Portal.azure.com and go to Azure AD Identity Protection where we can see a few statistics related to protecting user identities.

If we go into the User risk policy, then we can configure that by going into the Users -> All users. Here you’ve got the users that we would like to include in that particular policy. We can choose someone from the list.

For example, we can choose a CQUREdemo account. We could also specify the exclusions in the Exclude. As an example for us, that could be a Break Glass account or just simply an account that we’re going to specify there. For us, it’s going to be the CQ SOC2 account and let’s specify the User Risk. We’ve got risk levels that are applied, which are needed for the policy to be enforced, so let’s choose it as low and above.

Now we can get into Controls and go to the require password change. We see two options; “block access” or either “allow access” with the require password change checkbox in terms of enforcing that type of policy. At the bottom of the window, we’ve got the enforce policy switch. Let’s turn it ON. It is actually a pretty easy setup, we just need to save the settings and wait for it to be applied to get a saved user risk policy.

In the Sign-in risk policy, we again go into Users to specify either Individual Users or All Users and we can also specify some Exclusions. We can put the policy to the group of all users but exclude a particular account, let’s use our CQSOC2 account as the break the glass account.

In the Sign-in risk we define the controls to be enforced for All Users. Let’s once again specify it as Low and above. Let’s do the same thing with Controls, where we’ve got the possibility to also configure the type of the control. Choose the Allow Access with the Require multifactor authentication checkbox. Make sure to toggle on the Enforce Policy and Save. While waiting we can see there is also a recommendation regarding conditional access so we can check it out as well.

Within the Conditional Access, among the Policies, you can see that we’ve got an already configured policy. Nonetheless, we’re going to create a new policy and that particular policy will be for a certain group of users.

For this example, we choose All Users while making sure we do not lock ourselves out. In Conditions -> Sign-in Risk we can see it is not configured. In the Cloud Apps or Actions we can configure the corresponding cloud app. Click Select and we can search amongst the cloud apps to which that particular policy is going to be used for.

To demonstrate this part because we are focusing more on the Azure AD Identity Protection, but of course, the policy amongst the Conditional Access is important here too. Let’s go to the Risky users and review the potential here. Here we have the user CQSOC2 and that’s the user that’s at risk and we can learn why. We can see here recent risky sign-ins, and that is something that is going to come out amongst the logs.

If we’ve got certain sign-ins that potentially are coming from the locations that were not defined before, like in terms of conditional access or for example, they are coming from the Tor network, then that is something that we will be able to spot within the log. We can see a recent Azure Portal log-in with the exact date, location, and risk status so we can see why in this case it says At Risk by navigating to User’s Sign-Ins.

If you want to dig into more details, you can see the sign-in events and review all of them. One of these has an Interrupted status and it caught our attention. Of course, we also have some Failures and Successes, so investigating this log set will allow us to see what’s going on with this particular user. Here we’re able to learn that this particular user was logging on from Poland. We can see when so also leveraging the Conditional Access part and it’s not very logical that the user logged on from different locations in a similar time.

The user potentially can be using a VPN and that could be defined here. But that is just to show that this kind of probes for sign-in, so spraying off the accounts from the outside of the certain company could be easily detected. If we go into Risky sign-ins as well, we can see and identify the sign-ins. Those are not related to users but just a probe of sign-in. This is also the place where we’re going to be able to learn that we are experiencing quite a lot of activities, for example from the outside.

Let’s see it in the Tor browser. We’re going through Germany, Poland and so on and this is how we are browsing microsoftonline.com. We will try to sign-in from the Tor Network. That’s the policy that we have configured and we are signing on a CQUREdemo account to test it. After entering the password, the sign-in was actually blocked. First of all, that’s because we are coming from Tor Network and we have configured that type of policy.

When we click More Details we can see a little bit of troubleshooting details. This we can investigate further in the Azure AD Portal. This is proof that the policy is actually applied. So we can only sign. After refreshing the Portal, we can very quickly see the log regarding that activity. We can see the corresponding account CQUREdemo and this is coming from the Netherlands.

We can also verify the details of that probe for sign-in and see the Failure reason. In that case, it is the cannot configure multifactor authentication methods due to suspicious activity and we can see Risk Info and the Detection Type. We can get into the Anonymous IP address which is a log type that defines us that we actually came from the Tor network, which proves the point. In this panel, we can choose confirm sign-in compromised and that would start another process for the user after confirming it. That user will need to, for example, change the password or whatever else we’re going to assign to this kind of activity.

In this episode we presented the Azure AD Identity Protection and how important role it plays in determining whether the users are coming from trusted locations or not and how comfortable and easy it is to discover that some of the sign-ins might be actually suspicious and that there are probes for accounts in our organization to be compromised.

Please let us know if you have any questions and we absolutely hope to see you in further episodes of the CQURE Hacks Weekly.

💡 If you would like to further your knowledge in secure Azure AD make sure to check Implementing Secure Azure Active Directory