Passwords: with or without you

A couple of days ago, I had a small conversation with John Nabil Iskander on twitter:

So, here we go. As announced last Ignite conference in 2018, Microsoft customers can live without passwords now. After phone sign-in and Hello of course, we now have security key support, which means you can now sign in to your Windows 10 AAD joined device by the use of those little friends here:

(There are also other hardware suppliers)

Microsoft is currently rolling out the public preview of this feature to all tenants worldwide. When it is enabled in your tenant, you will find a new item under AAD / Authentication Methods in the Azure Portal called “Authentication method policy”:

As you can see above, the methods are empty. You might have to enable the preview feature for some or all of your users:

After a few minutes (yes, please crab a coffee or two), the new authentication methods appeared in my tenant:

In the meanwhile, you could configure an Intune device configuration policy to target those users that you would like to enable to sign in with their security key. Therefore, go to Intune / Device Configuration / Profiles / Create Profile / Custom.

Configure the new profile with the following settings

  1. Name: Security Keys for Windows Sign-In
  2. Description: Enables FIDO Security Keys to be used during Windows Sign In
  3. Platform: Windows 10 and later
  4. Platform type: Custom
  5. Custom OMA-URI Settings:
    1. Name: Turn on FIDO Security Keys for Windows Sign-In
    2. OMA-URI: ./Device/Vendor/MSFT/PassportForWork/SecurityKey/UseSecurityKeyForSignin
    3. Data Type: Integer
    4. Value: 1


Then assign this policy to the audience of your choice.

Then, when the authentication methods have arrived in your tenant, you can click one of those methods to enable and configure them:

Do not change the “key restriction policy” settings. This functionality will be available when the product goes GA. After enabling FIDO2 security key, I also enabled “Authenticator passwordless sign-in”:

After this configuration is done, you can go to, click on “Security Info” and then add “security key” as a new sign-in method (you can use Edge to do that, however, it looks like the Chredge (Edge Beta) is not supported yet):

I chose a USB device then:

Get your key ready:

Now the browser is interacting with the operating system:

I then had to touch the Yubikey and could then finish the installation:

Now, lets see how this looks like:


Security keys are a secure alternative to Hello for Business with PIN login, when you have older devices that do not support biometric authentication. Other than just relying on a device PIN, with security keys, you do not enable your co-worker to just watch you typing in your PIN and enable them then to logon to your machine, while you are drinking coffee. Now, you take your security key with you, which adds an extra portion of security.

I am still waiting for the ability to disable certain authentication methods for specific users from an admin perspective (I would love to disable password sign-in for example) – however, what we got today is a big step into a password-less world.

The New Unified Identity SecOps Experience

The new Unifed Identity SecOps Experience brings together information from Azure ATP, Microsoft Cloud App Security (MCAS) and Azure AD Identity Protection.

In this blog post, we will look into the new UI and evaluate which value it has. However – as always-, I am trying to add a little ‘spice’ and therefore we will build in some mimikatz action. Be excited :-).

Even in a 100% cloud world (if it is a company of a certain size) we will not get rid of the local Active Directory anytime soon. That means we need to synchronize users between the on premises AD and the Azure AD and this makes the on-premise AD a possible attack vector for Azure AD / O365 services.

Imagine an ‘on premises’ attacker wants to take control over the CEOs personal data (in OneDrive). I will walk you now through the complete kill-chain of such an attack and show you meanwhile where the new improvements and the known features of MCAS can help to detect an respond to the attack:

Let’s assume the credentials of a user account called “Jule” have been compromised. An attacker is then utilizing those credentials to logon to Jule’s laptop and later running some tools to get higher privileges.

Azure AD Identity Protection has recognized that the credentials may have been compromised and has created a risky sign-in alert. Since this information is now synced with MCAS, we see an increase in the “investigation priority score” of “Jule”:

What you can see above is the brand new “User Page” in MCAS (actually, it is so brand new that it is still in private preview, so things could change here, keep this in mind).

Our (IT) world is getting more complex every day. In order to handle more and more alerts, prioritization is key. So, depending on the alerts that come up related to a certain identity, Microsoft is calculating an investigation priority score for this identity.

Because Identity Protection has found a risky sign-in for “Jule”, she got assigned an “investigation priority score” of +23.

On the MCAS Dashboard, we have a new section called “Top users by investigation priority”:

This helps us to prioritize our investigation work. We see “Jule” is under the top three users in my test lab. But wait a minute! Why is a user called “admin” even higher rated?

Well, with the stolen credentials, our attacker was able to logon to Jule’s laptop and to install a tool called “mimikatz”. With mimikatz you can do many nasty things, the attacker used it to gain an important password hash. Note: it is not that easy to run mimikatz on an up-to-date Windows machine. E.g. Windows Defender will not let you run it.

However, let’s assume the attacker found a way to run it. The password hash, the attacker is searching for, is in the memory of a Windows component called “Local Security Authority Subsystem Service (lsass)”. To access it, you have to be either local admin or find another way. For our purpose, let’s say Jule was already local admin. With that, the attacker could easily get “Debug” privileges:

He then ran “sekurlsa::logonpasswords” to retrieve the passwords he was looking for from memory.

Anyway, this did not reveal any interesting password hashes yet. Now, lets assume an administrator had to connect via a TeamViewer session to the client in order to support her in whatever case. Let’s further assume, this administrator had to do a “runas” on Jule’s laptop to do his stuff:

Gotcha. That’s exactly what the attacker needed to run “sekurlsa::logonpasswords” again. Now, he found the password hashes from the Admin user, he was looking for:

The attacker could then use mimikatz to take this hash and use it in a “pass-the-hash” (pth) attack. In a nutshell, a pth attack is a attack where the attacker presents the hash of the password to the system it tries to logon instead of the actual password:

When firing a pth attack, mimikatz automatically opens a new command prompt. The attacker then used psexec to gain a remote shell on the local dc (without suppling admin credentials, remember, the attacker is still on Jule’s Laptop in Jule’s user context with no permission on the domain):

That worked, the attacker now has a remote shell on the domain controller! Let’s see which privileges he now has:

As you can see, the pass the hash attack worked like a charm. Mimikatz impersonated the attacker as admin since he was able to read the password hash of the admin user from memory and passed the pw hash over for logon. (So, never ever use Domain Admin credentials to do local machine admin stuff!).

By analyzing the eventlog and monitoring the traffic on the DC, Azure ATP came up with two new alerts during the attacker’s pth-journey:

Those alerts are now also visible in MCAS. In fact, we can see here the complete kill-chain in the alerts section – which is great for investigation:

First the risky sign-in, then the pth-attack on “admin”, then the remote code execution from Jule’s Laptop to the DC.

When you simply click on the alert and then on the “admin-tag” you can see, that these alerts then also pay into the investigation priority score on the admin’s user page in MCAS:

When you click on the machine name tag in the alert, you come to the (also brand new) machine page:

As you can perfectly see here, “jule” and “admin” used their credentials on this machine – also both alerts are associated with the machine. From an investigator’s perspective, we know now exactly what happened.

Anyway, back to our kill-chain: since the attacker now has an admin shell (context of user “admin”), he is trying to make his new power more persistent by adding the user account, he is already controlling (Jule), to the Domain Admins group:

The problem, the attacker is facing now, is, he needs to somehow bridge the gap to the cloud. He has domain admin permission locally, but unfortunately, this admin user has zero permissions in the cloud.

Then he installs the RSAT tools on Jule’s laptop to make things a little more comfortable (by the way, the RSAT tools are an optional windows feature now, which you don’t have to download but only enable in windows optional settings):

By investigating the Active Directory, the attacker finds a promising OU with a promising user:

Since the attacker has compromised Jule’s account and then escalated her user privileges to “Domain Admin” by the pass-the-hash attack, he is now able to change the password of the user “IT Service Admin” and then use it to logon to (remember, we are syncing passwords from on-premises to the cloud):

MFA would be another obstacle here, so better enable all users to use MFA. Anyway, our attacker now is one step further:

Now he uses the admin center to access the CEO’s OneDrive files, yes, in my lab I’am CEO baby 🙂

Et voilà:

The attacker now only has to download all the files and upload them to his dropbox:

Again, our friend MCAS alerts us here and tells us, there is something going on:


Beside the fact we paved the way for our attacker a little (we disabled Antivir and made the attacked user ‘Jule’ a local admin right from the start), we saw a nice real-world kill-chain: The attacker escalated the privileges of an account he had compromised before. Then he gained some persistence and then he took over the control of the CEO’s personal files in OneDrive.

More importantly: we showed how the tools from the new Unified Identity SecOps Experiencealerted us in every phase of the kill chain.

We didn’t show how Windows Defender and Microsoft Defender ATP would have prevented all the nasty things the attacker did, but I showed that already in another post.

Some people say, when it comes to ‘Security’, you need diversity (in regards to the manufacturer). Actually, I believe the real power here comes from the smooth integration of the different tools. As you have seen, it looks like Microsoft is doing a pretty good job in this area.

Go, hack yourself!

While talking about the protection mechanisms in modern cloud environments, one tends to forget the other side.

You must know your enemy in order to fight him successfully. Today we will build a lab to attack a modern Microsoft cloud environment that is protected by the brightest star on Microsoft’s security sky: Microsoft Defender ATP*.

*Windows Defender ATP was recently renamed to Microsoft Defender ATP, since it now also supports some functionality on MacOS (and more is planned)

But first, lets move to the dark side. I am sure you already heard of many of the tools used by attackers today, but have you ever used them to attack your own machines? Let’s see how that works!

Our lab is simple:

  • 1 x Windows 10 1809, AAD joined, Intune managed, Microsoft Defender ATP secured, 100 % Cloud
  • 1 x Kali Linux with Metasploit

In case you don’t know it, Kali Linux is a Linux distribution that comes with many important attacking and penetration testing tools. Metasploit is a framework for the complete kill-chain.

A kill-chain?

A kill-chain describes the process from the first contact of the attacker to the ‘promised land’ (whatever they are gaining to obtain).

1-1Pic01: kill chain

Attack vectors are the first contact the attacker has with your property: He leaves a prepared USB stick on your company parking, he writes an Email with an attachment or with a link to your users, or he attacks you e.g. with a password spray attack.

In former times then, when he accessed ‘Patient 0’, the first computer: he was in. ‘In’ meant your managed environment, behind your firewalls. Now, in modern concepts, there is no ‘in’ or ‘out’ anymore. Clients are built to be always in an open network. This is, what makes one of the next steps harder: lateral movement. Hopping from one computer to the next was easier in former times, since everything inside the perimeter was considered as ‘safe’. (Is this still the case in your environment? Go 100% cloud!)

To move laterally, the attacker would try to gain more permissions (admin etc.) and gather more information about your network and directory (e.g. Global Address List discovery).

Now, let’s start with the fun part of this post. On the left you can see the Metasploit console, on the right, you see our Windows 10 client:

2Pic02: our setup

First, we must choose an exploit we can use on the Windows machine. I have chosen to find the appropriate exploit. I have then decided to take an exploit in a popular video player software, VLC:

3Pic03: choose an exploit

This exploit is a so called ‘use after free’ exploit that tries to use memory that was just freed from the application.

Many exploits are already integrated in the Metasploit database, however, ‘my’ exploit wasn’t. The VLC exploit is quite new. gives you the possibility to download the exploit, so that you can use it in Metasploit. After download, you just tell Metasploit to use it:

Pic04: use the exploit

With ‘show payloads’, you can examine the possible payloads of this exploit. When you read the description of the exploit, you see that the author of the exploit recommends to only use certain payloads with the exploit since others (e.g. the meterpreter payload) crashes the application:

5Pic05: show payloads

With show options you can see what options are necessary to configure the exploit:

6Pic06: show options

In the options above, we see, that the exploit will generate two MKV (video) files. The first has to be opened by the victim (the second has to reside in the same directory). We also see, what settings are already set or still empty. The only setting that is missing here is ‘LHOST’, the IP address of our attacking machine. So let’s set it:

7Pic07: set LHOST

That’s it, we are ready to run the exploit:

8Pic08: run the exploit

As expected, Metasploit has generated the two .mkv files for us:

9Pic09: here we go

Now, when we remind ourselves on the kill-chain diagram at the beginning, we need an attack vector. How do we distribute the .mkv files to the victim? Well, that is pretty easy, we can zip it and send it by Email or – that’s what I did-, we can put it on Dropbox and share it with the user. If you attach it with a ‘social-engineering made up’ text, you can make sure that it is being watched, or better: ‘double-clicked’. (I just had to convince myself).

The .mkv files are on the client now. In the meanwhile, we need to setup a ‘Listener’ on our attacking machine that waits for the victim to double-click on the .mkv file. I have decided to create a reverse shell handler (which is also the default payload option for the exploit):

10Pic10: setup the listener

When you observe the above screenshot, you see that we ‘use’ an exploit again, in this case for the listener “exploit/multi/handler”, we then set the payload and the ‘LHOST’ IP and are then ready to exploit (run) it:

11Pic11: start the listener

The listener is now doing what it should: listening. I now went on the Windows 10 machine and double-clicked the first .mkv file. After a few seconds, I started to receive some data on the listener and finally got a Windows command prompt on my Kali Linux machine!

And what do you do, when you have a command prompt on a unknown Windows machine? Exactly, I did a ‘DIR’:

12Pic12: orientation

Ok, that was a hesitantly first try – I must admit that, let’s get gutsy and start something:

Pic13: finally got some help with mental math (click to enlarge)

Pretty cool, isn’t it? Meanwhile on the good side of the planet, Microsoft Defender ATP started sending me first Alerts:

14Pic14: ooh

In the artifact timeline we can see which application triggered the alert:

15Pic15: artifact timeline

Uh-huh, VLC seams to make some bad stuff on one of the Windows clients in my environment 😊 As we can see in the process tree, ATP has exactly found what our exploit was doing, it started allocating some free memory (like in the exploit description: ‘use after free’):

16Pic16: process tree

Anyway, lets try to get a step further. I am trying now to upgrade the remote shell session to a meterpreter session. With meterpreter we have more possibilities. You can easily run a keylogger, Mimikatz or much more. To upgrade to meterpreter, we have to put the remote session into a background session by pressing ctrl+Z. Then we use the exploit “shell_to_meterpreter”:

17Pic17: trying to start a meterpreter session

With ‘sessions’ we can see the current remote shell session. We set the exploit to session 1 to tell the shell_to_meterpreter exploit to use our remote shell session to upgrade, then we run the exploit:

18Pic18: not working somehow

With that, ATP freaked out:

19Pic19: new alerts in ATP (1)


20Pic20: new alerts in ATP (2)

And we didn’t get any new (meterpreter) session, but still have just the remote shell session:

21Pic21: no new session

What happened? As we can see in the ATP machine timeline, it was ATP’s friend Windows Defender Antivirus that remediated our attempt to attack the machine with the meterpreter payload:

22Pic22: friends will be friends (Windows Defender Antivir did the job)

Which is good or bad, depending on the perspective. Let’s take a look on the complete alert history:

23Pic23: Alerts queue

What scared me a little here is the fact that all these alerts had an assigned severity of “medium”. So, you really must look into your medium alerts!

Windows Defender and Microsoft Defender ATP worked hand in hand in my scenario. However, I had access to the targeted machine and could execute arbitrary code (calc.exe). ATP recognized that – which is good, but wouldn’t it be even better if we could get a hint upfront?

Microsoft Defender ATP Threat and Vulnerability Management

Microsoft is currently rolling out this new feature to tenants worldwide. With TVM, ATP gathers information about the applications on your clients, the installed versions and the configuration. This data is then compared with Microsoft’s Threat Intelligence. That’s why ATP could already tell me before my Windows 10 machine was attacked that it has a vulnerability in an application called “VLC”:

Pic24: we could have known before

ATP even tells me which vulnerabilities are associated with the installed version of VLC:

25Pic25: CVEs associated with the software version

You might have recognized that our CVE is (the second) is listed. When we click on this CVE, we get a description that is quite similar to the description on

26Pic26: CVE details


I have just scratched the surface. After I had access to the target machine and was able to execute calc.exe, I gave up quite early when the meterpreter session couldn’t be established. There are many possibilities to obfuscate the payload to make it harder to be recognized. The fact that ATP noticed that the VLC exploit allocated just freed memory shows the real power of the tool, the power of behavioral analysis.

Threat & Vulnerability Management completes Microsoft Defender ATP. It gives you a vulnerability-based view on the application landscape of your environment and gives you prioritized advices on how to get rid of the vulnerabilities before it gets actively exploited.

However, to be able to judge the importance of tools like Microsoft Defender ATP, you must betake yourself to the red-team’s point of view. If you try to think like an attacker, you will be better able to understand how to protect your environment. So … go, hack yourself!

Office ATP P2

Since the beginning of February 2019, Microsoft is dividing Office ATP features into P1 and P2. Everything that was called “Threat Intelligence” before goes now into Office ATP P2. In this article, I give a brief overview of Office ATP P1 and P2 features and go deep into an exciting P2 feature called “Attack Simulator”.

But let’s start with P1. To be honest, I was underestimating the value of Office ATP for a while. But in the meanwhile (while I was not watching), Microsoft added more and more functionality to mitigate the most common attack vectors:

  • Email
    • Links in Body & Attachments (Fat Client & OWA)
  • Links in Documents
    • Office on Windows, iOS, Android
    • Links in Team Conversations
  • Files in
    • OneDrive
    • SharePoint
    • Teams

So, you say, you have Exchange Online and SharePoint Online and those services are using Anti-Virus anyway, so why would you need Office ATP?

ATP goes a step further: Whenever you read “link” in the above bullet list, Office ATP is replacing this “link” with a link that is pointing to Microsoft servers. That means, when your users click on this link to e.g. download a file, this file goes through all the Office ATP intelligence. So even if the link was Ok during e.g. delivery of the Email but the attackers changed the document on the server-side in the meanwhile (and after the initial scan), Office ATP will recognize that. This is called: Safe Links.

With Safe Attachments on the other hand, Microsoft is even detonating your attachments! They will take the attachment to a virtual environment and watch how it behaves in order to decide if it is malicious.

How this looks like for example in Teams was recently described by ‘Matt Soseman’:

Looking deeper into P1 features

The services improved over time. E.g. with “native link rendering” Microsoft displays the original link in the hover-window instead of the Safe-Link to not confuse users:

Pic01: hover text

You must look into the status bar in order to see the “real” URL:

Pic02: Status bar

Of course, all those techniques are not the holy grail. As always: somebody finds an exploit (e.g. “baseStriker” in Safe Links) and Microsoft closes that gap afterwards.

It is also important to note that not all content on SharePoint goes through Office ATP. Instead ATP is using a smart algorithm that takes guest and sharing activity under consideration. So, whenever there is “external” activity with files, it will act.

Now, lets shift gears and talk about Office ATP P2 features

There are several features available here: with ‘threat tracker’ you get informed about the latest threats and their details. On the ‘threat dashboard’ you get reports about malware, spam and phishing happened in your tenant. With ‘Explorer’ you get a powerful tool to hunt for threats in your environment.

You can integrate Windows Defender ATP here to find out to which machines a certain Email was delivered.

But let’s now come to the feature we will look closer at: Attack Simulator

Next to ‘Safe Links’ and ‘Safe Attachments’, making users aware of not clicking on a link from a suspicious looking Email and not opening that attachment is maybe the most important mitigation. Office ATP P2 helps you with Attack Simulator to increase awareness at your users. You have three ‘attack campaigns’ (more to come):

  • Spear Phishing
  • Brute Force
  • Password Spray

Let’s start a Spear Phishing Attack:

With this Spear Phishing Attack, we try to ‘steal’ credentials from the user by placing a link into an Email that we send and make them to click on the link and provide their credentials.

Pic03: Launch Attack

Provide a name:

Pic04: Give it a name

Select people from your organization (you cannot use this against external users):

Pic05: Specify your targeted users

Provide Display-Name and From Email Address. This is what your targeted users will see in their Email clients. You can choose Login Server URL from a dropdown list. Microsoft will monitor logins to these pages for you and report on it. You can also configure (optionally) a custom landing page. This page will be displayed, after the user logs in. Finally, specify a Subject:

Pic06: Provide Details of the attack

Don’t be afraid: Microsoft does not track the credentials your users provide, nor do they check if they are correct (I never put in the real passwords in my tests and always was passed through to the landing page).

Then we have an Email Body Editor including a HTML source code editor. There are two variables you can use in the HTML body:

  • ${username}
  • ${loginserverurl}

Pic07: compose your poisoned Email

Together with the source code editor we can create a hyperlink in the Email, that does not make the original URL visible at the first glance (as you can see above):

Pic08: HTML view on the mail

That’s it, you get the final question if you really want to proceed. If you say ‘finish’ the attack fires:

Pic09: fire your attack

Now let’s see how this looks on the user’s side (here in OWA):

Pic10: user’s view in their inbox

When the user clicks on the mail she gets prompted by the well known Microsoft login dialogue (notice that chrome already thinks this is a ‘not secure’ site):

Pic11: user gets prompted

Whatever credentials you provide, you get forwarded to the specified landing page:

Pic12: Custom landing page

Back in Attack Simulator you can look on the report of your attack:

Pic13: Report of the attack results

As you can see, we targeted one user with our attack and had one successful attempt (well, I would say it was not successful, because the user clicked on the link, but that’s another story). You can download a CSV of all users and the description of their behavior.

The other available attacks run real password attacks against your user accounts. Either you provide a password list and see if those passwords are used by the users targeted (Brute Force) or you specify just one password and use it against a broader scope of users (Spray Attack). You then get a similar report as we have already shown:

Pic14: Report of BruteForce attack / Spray attack

Conclusion / A word of caution

I really like the attack simulator. With the available attack types, you can challenge your users and that means you make your environment more secure. But you must handle it with care. You should plan your ‘attacks’ very good and inform instances like ‘workers council’ and ‘data protection’ (and the management). Then I would suggest that you start a campaign for more security. Maybe you launch a specific website with tips and videos to improve user’s behaviors. Then during this campaign, you mention somewhere in your user communication, that you might also challenge them – so you warn them a little bit. Then, when they get ‚caught‘ don’t be mad at them. Explain carefully what happen and how they can improve. Your users are your friends 🙂

When it comes to Safe Links and Safe Attachments, you can easily roll this out in a scoped manner. Just increase the number of targeted users by time. So, you get a good impression of the impact it has.

AI, Protect Me!

Azure AD Identity Protection (IP) recently got a refresh (in preview). We will have a look into some of the enhancements. But first, I will give you a brief overview of what is it all about:

In a nutshell, IP handles two kind of things:

  • Risky Sign-Ins
    • Is the authentication request really coming from the authorized user?
    • Can be triggered by:
      • Atypical travel (10 PM: Sign-in from New York, 10:30 PM Sign-in from Frankfurt)
      • Anonymous IP Address (e.g. Tor Browser)
      • Unfamiliar Sign-In properties (Takes past sign-ins into consideration and checks for regular used devices, locations and networks to compare it with the current sign-in)
      • Malware linked IP address (Microsoft researches IP addresses that are associated with malware)
  • Risky Users
    • Either a former Sign-In was risky (see above)
    • Or Credentials have been leaked and Microsoft found them on any dark web marketplace or so.

The calculation of the Sign-In and User Risks is done by the help of machine learning.

Keep in mind that all machine learning technologies need learning periods. E.g. ‘Atypical travel’ needs like 14 days or 10 logins to learn the users sign-in behavior. ‘Unfamiliar sign-in’ whereas needs 30 days, during which it is passive. (see here for more info)

You then can create policies based on Risky Sign-Ins or Risky Users. In case of Risky Sign-Ins, you can challenge users for MFA, in case of Risky Users, you can prompt users for a password change (hopefully through SSPR) or you can block access in both cases.

That’s pretty much the basic functionality of Azure AD Identity Protection, except for one thing, we didn’t talk about yet:


This is where the freshness comes in. Microsoft is investing a lot of effort into a clean overview to make it easy for the security administrator to see at one glance what is going on. In order to see how well reporting is in IP, we need to setup the risk policies and then produce some Risky Sign-Ins first.

Setup of Risk Policies


Pic1: IP Policies

Both, User and Sign-in risk policies consist of

  • User Scope (who will be effected by this policy)
  • Conditions (Low, Medium or High Risk)
  • Controls

Pic2: Policy Controls

Now that the policies for Sign-in Risk and User Risk have been setup and assigned to the users, let’s play around with it:

We sign-in to Office 365 via a TOR Browser to anonymize our IP address:


Pic3: Tor Browser

Shortly after we get a new risk as you can see in the brand-new risky users report:


Pic4: Risky users

As you can see, we tried to login to Office 365 and didn’t succeed. The location is also interesting, you can see, the sign-in happened somewhere from Italy (while I am living in Germany) – this is since TOR is proxying all requests to other nodes in other countries.

In the ‘Basic Info’ tab, you get user info from Azure AD. ‘Risk events not linked to a sign-in’ is also interesting: Microsoft is continuously screening leaked credentials on dark places in the internet. So, if your credentials are sold anywhere out there, a risk is listed under ‘Risk events not linked to a sign-in’.

Until now, we do not know about the actual reason for the risk. Let’s click on the risky sign-in to get to the risky sign-in report:


Pic5: Risky sign-ins

Here we have it: ‘Anonymous IP address’ was (as expected) the reason for the risk.

Now, your investigation as a security administrator starts. You will have to check with this user if she used a TOR browser by intention or if somebody else tried to logon with her credentials. After you found out, you can click on ‘confirm compromised’ or ‘confirm safe’. This will a) put the user on high risk if she was really compromised and b) help machine learning, well …, to learn.

Microsoft calls this “Smart Feedback” and this is also brand new (in preview).

This was an easy case (user connected by Tor Browser), as mentioned, your work starts after the risk was detected. You must investigate what’s really going on. So, what you need are really good and clean reports that you can filter, sort and customize. With this refresh of Identity Protection, the Risk reports have been enhanced a lot to support you in your daily job.

A word of caution: to test the policies easily, I set the condition to “low risk and above” and the scope to my “all users” group. After hitting OK, I immediately received this one here below and couldn’t work with the portal anymore. I then had to re-authenticate and … was prompted to authenticate and then to change my admin password. As you can see, those risk policies are really working


Pic6: I am out!

So, be sure whom you assign those policies and have a Break-Glass Admin Account (thankfully I had) that you always exclude from all policies (also in conditional access).

But that’s not all

This risk report data is also available via Graph API. Let’s have a look how that is working. We will use Graph Explorer to show which information we can get also programmatically:

You might have to give yourself the appropriate permission, if you see this:


You will need:


Make sure you are logged in to graph explorer and use the new beta API, then try for example “identityRiskEvents”:


Pic7: Graph explorer

When I do that, I see the same sign-in risk we saw earlier in the GUI:


Pic8: Graph response

As you can see, you even get some extra information, like the geographical data of the IP location.

Christmas Special: Peace between Security and Usability (by the example of Multifactor Authentication in Azure AD)

One of the biggest problems of our times in IT is to pacify the long-lasting war between security and usability. We all know this picture here below that shows precisely human behavior: people will accept security, when its easy enough. Otherwise they will find their own way around security:


Pic1: The easy way

For me, this leads to the conclusion that a security design of a system is only a good security design (yes, also from security perspective, not only from user perspective!) when it allows people to behave naturally.

Some people in charge of IT security, design secure systems for the sake of security – not thinking about the users. They think it is more important to have a secure design in place and users will somehow handle it. They are not yet aware of the fact that people should be an important part within their designs, since they can circumvent whatever they designed.

Users will always ‘win’. At the end, the often mentioned ‘young talents’ (and I think also the older ones) search other employers, when they are annoyed by too many virtual walls around them.

We somehow must marry security & usability in order to improve both.

One of the best examples of such a marriage is Microsoft’s implementation of multifactor authentication (MFA) in conjunction with conditional access:

When you require MFA for users that join a Windows 10 device to Azure AD:


Pic2: Require MFA for AAD join

Then, when you setup a new device, after you authenticate during OOBE …


Pic3: OOBE prompts for company credentials

… you get prompted for MFA:


Pic4: MFA Prompt

In this scenario, I have disabled Windows Hello for Business (WHfB) to proof something, I will come back on later. Here is where you can enable and disable WHfB:


Pic5: Where you disable WHfB for test purposes

So, after OOBE went through (I did not receive a prompt to setup WHfB during Windows installation as expected), I log in to windows and could open Edge and connect to without an MFA prompt:


Pic6: Login to OWA without MFA prompt

The question is why? Lets take a look in the AAD sign-ins:


Pic7: Azure AD Sign-Ins

As we can see, the ‘MFA Result’ states that “MFA requirement (is) satisfied by claim in the token”.

Now lets log-in from a different computer that is not AAD joined (or use a private browser session):


Pic8: MFA prompt from not AAD joined pc (in german)

Here we get a MFA prompt, since Conditional Access is configured as follows:


Pic9: MFA enforced through conditional access

As you can see, under all circumstances, we force MFA here for Exchange (you have to believe me the latter ).

Before we answer the question, why didn’t I get prompted in the first place, when I logged in from a AAD joined computer, we will take a look at a second scenario:

Registered Device (Workplace Joined, local Workgroup):

After the installation of a ‘stand alone Windows 10’, I had to do MFA to connect to OWA (as expected):


Pic10: connect to OWA from stand-alone machine


Pic11: MFA prompt on stand-alone machine

Then I registered the device in AAD:


Pic12: register device in AAD

Again, I had to use MFA in order to register the device:


Pic13: MFA prompt when registering device in AAD

After successfully registering the device (incl. MFA), I was able to access without any further MFA prompts.

Again, in the sign-ins, you can see that MFA was satisfied through a claim in the token:


Pic14: MFA requirement satisfied from registered device

So, again, why don’t we see MFA prompts from registered and AAD joined devices? The answer can be found on a Microsoft FAQ page:

Q: Why do some of my users do not get MFA prompts on Azure AD joined devices?

A: If user joins or registers a device with Azure AD using multi-factor auth, the device itself will become a trusted second factor for that particular user. Subsequently, whenever the same user signs in to the device and accesses an application, Azure AD considers the device as a second factor and enables that user to seamlessly access their applications without additional MFA prompts. This behavior is not applicable to any other user signing into that device, so all other users accessing that device would still be prompted with an MFA challenge before accessing applications that require MFA.


In addition: Microsoft is considering the device also as a second factor, when enrolling the device (AAD Joined) for Windows Hello for Business (without the MFA requirement during setup!). After WHfB enrollment, you are also not prompted again for MFA furthermore.


Imagine a scenario where a user sits in a train and logs in to Windows in order to read her mail. Let’s ignore WHfB for a moment. She types in her username and her password and does not get prompted for MFA, since she works from a trusted (AAD joined or registered) device. A rude woman behind her watches her when she types in username and password. The rude woman than will be very disappointed at home, when she tries to login to Office 365 with the credentials of her victim and then gets prompted for MFA (especially because she hasn’t seen her victim having to do the same).

The beauty of Microsoft’s implementation of multifactor authentication gets visible, when you get NOT prompted for additional authentication methods. Security can show its strength, when usability does not suffer by it.

Garage: Azure AD Terms of Use for B2B and AIP

As already mentioned, this blog will have detailed (long) posts and also shorter ones that have a “garage-character” that documents features and solutions I evaluate. This is the first post of this ‘garage’ category.

To be honest, I believe this whole “terms of use” thing was triggered by this guy here. Oliver and myself were in a project at a customer that wanted this functionality that users would have to accept some sort of terms of use before proceeding with a service. (of course we were not the only one requesting this feature, but he was the first chatting about this with the Intune product group). You can like this feature or not and you can also doubt it’s value in a modern IT world, but sometimes it makes things easier (especially in bureaucratic Germany) and you don’t want to fight each fight.

Anyway: Microsoft has started to expand this functionality. You can now set to have users to accept terms of use (TOU) on each device and you can even expire this setting so that they have to re-accept it after a certain period of time.

Then it also gets expanded to other services (currently in public preview):

  • Intune Enrollment
  • B2B Users
  • AIP Documents

Let’s take a closer look on these use cases:

In all cases, you would create a conditional access policy that requests from the given users to accept the terms of use of your company. In this policy, we will combine the requirements for B2B users, Intune enrollment and for AIP users. So we need to select “all guest users” for the B2B scenario and then specific users (Hedi) for the AIP and Intune demo (in real world, you would probably select ‘all users’ here):


Next, you select the AIP cloud app and the Intune enrollment cloud app to indicate that those apps should bring up the terms of use when accessed:


Here you go: on the access controls you then have the control “all users terms of use” (which is the name of the terms of use I created). Select it and enable the policy:


If you now share a document with a guest user via email …


… this guest user gets a prompt to accept the terms of use, when opening the document you shared (as you can see it is adopting to your language :-)):


If you send someone a AIP protected document (you don’t have to send it by mail, the ‘terms of use’ is triggerd when you authenticate against AAD, since the conditional access policy fires then) …


… the recipient then also has to accept the terms of conditions, when opening the document:



The more granular it gets the better. So you prompt your users only to accept the terms of use if it is absolutly necessary without annoying them.