Passkeys in the Microsoft Authenticator app using an iPhone
Setting up a passkey via a physical Yubikey 5 (usb-c)
Note: This post is targeted at users who want to set up passkeys in the Microsoft Authenticator app or register a physical key. Your administrators must have enabled the capability to use passkeys before you can complete the steps below. To use passkeys via the Authenticator app, you need Android 14 or later, or iOS 17 or later (at the time of writing this post). Additionally, make sure that your Microsoft Authenticator app is updated to the latest version.
Configure Passkeys in the Microsoft Authenticator App on an iPhone
Access https://mysignins.microsoft.com and login
Click security info from the left pane
Click + Add sign-in method
4. Click the option, Passkey in Microsoft Authenticator
5. You may be prompted to go through MFA before you are able to add a new sign-in method. Please continue with this. When done, continue to step 6.
6. Read the pre-reqs and click next
7. Don’t click Next just yet. You will need to follow the instructions mentioned on your screen first.
Open the Microsoft Authenticator app on your phone. Tap on the account/email address you will be setting this passkey for. Keep the app open while you proceed with the setup.
Click Create a passkey. If this option does not appear, ensure that you have met the pre-reqs I mentioned at the beginning of this post.
8. You will be prompted to sign-in. Click the Sign-in button and login
9. If it is the first time you’re setting up a passkey via the Microsoft Authenticator app, you’ll be prompted to enable a couple of settings on your phone before you are allowed to continue.
10. We’re done with the configuration on the phone. Continue to the step 11 below.
11. Return to your laptop/desktop and click next to complete the process.
That’s it. If you’re interested in configuring a physical key, such as a YubiKey, the next section goes through the process.
Configure a passkey via a physical Yubikey 5 (usb-c)
Access https://mysignins.microsoft.com and login
Click security info from the left pane
Click + Add sign-in method
3. Click the option Security key
4. You may be prompted to go through MFA before you are able to add a new sign-in method. Please continue with this. When done, continue to step 5.
5. Select the type of security key. I select USB device
6. Have your physical key ready, after clicking next, you’ll be prompted to plug it in.
7. Click next and then select Security key (If this option does not appear, click the option other ways to sign-in and then click Security key). Click next.
8. Read and click OK
9. Read and click ok
10. You will be prompted to insert you physical key
11. You will be prompted to create a new PIN
12. Your physical YubiKey will flash and you will be prompted to place you finger on it
13. Passkey saved, click ok
14. Finally, you will be prompted to give your Physical key a name so you can easily identify it.
15. Done
I hope you found this post useful. Catch you at the one
In this blog post, I demonstrate how to use an Adversary in The Middle (AiTM) phishing attack to capture a user’s session token utilising a tool called Evilginx. There are several methods to protect against such attacks and I will be concentrating on phishing resistant MFA.
IMPORTANTDISCLAIMER: The user accounts involved are demo user’s. The information provided in this blog post is intended for educational and demonstration purposes only. Evilginx is a powerful tool that can be used to steal session tokens, which can lead to unauthorised access to user accounts. This tool should only be used for legitimate penetration testing on systems where you have explicit permission to do so. Unauthorised use of Evilginx or any similar tool is illegal and unethical, and can result in severe legal consequences. Always ensure you have proper authorisation before conducting any security testing.
What is Evilginx? Evilginx is an advanced phishing framework that provides a way to bypass multi-factor authentication (MFA) protections by capturing session tokens. It operates as an Adversary-in-The-Middle (AiTM) proxy, intercepting communication between a victim and a legitimate service to steal authentication credentials and session tokens. Unlike traditional phishing attacks that trick user’s into divulging their passwords, Evilginx focuses on obtaining credentials and session tokens, enabling attackers to login without entering user credentials. This makes it a powerful tool for penetration testers and security researchers who need to assess the resilience of their systems against such sophisticated attacks, however, it can also be used by bad actors.
Here’s how it works in few steps:
Attackers create fake login pages that look almost identical to legitimate ones, such as login pages for Microsoft, Google, Facebook and more.
When user’s enter their credentials, Evilginx captures them and forwards them to the real site, making it seem like a normal login process.
It can also intercept multi-factor authentication (MFA) codes, allowing attackers to gain unauthorised access.
This makes Evilginx particularly dangerous because of its capabilities to bypass security measures like MFA.
To protect yourself, always verify the URL of the login page, use phishing resistant MFA, and be cautious of unexpected login requests.
Let’s dig deeper and understand the process via the diagram below
How does Adversary-in-The-Middle (AiTM) take place using Evilginx
Click the image below to enlarge
Now, let’s see the process in action
Note: I’ve already installed and configured the Evilginx application.
Let’s explore how Evilginx can capture a user’s session token and gain access to data.
I launch Evilginx on my server
2. I type:
lures create microsoft365 lures get-url 0
Click image to enlarge
3. I copy the fake url as shown in the image above. A malicious actor typically requires the user to click on this URL, often distributed through a phishing email.
For demonstration purposes, we’ll assume that the a real user has clicked the malicious link received through a phishing email.
I launch a browser and manually enter the URL of the fake login page.
Enlarge the image below.
Question: Can you spot anything suspicious in the image below?
In case you didn’t spot the suspicious detail, take a closer look at the website address, the letter ‘o’ in ‘micros’ has been replaced with a zero.
Bad actors often use cloned login pages that can appear convincing and legitimate. This highlights the importance of continuously educating ourselves and others about the risks of phishing attacks.
⚠️ WARNING: Please do not attempt to access the fake URL shown above on your own device.
4. Now, let’s assume the user proceeds to log in. For this demo, I’ll be using a test account:
This account is protected with multi-factor authentication (MFA) using the Microsoft Authenticator app. However, it’s important to note that I am not using phishing-resistant MFA.
I proceed to log in via the fake login page. Meanwhile, the Evilginx application is actively listening and capturing authentication logs in the background.
5. I click Next and am prompted to enter my password to authenticate with Microsoft Entra ID.
6. I enter my username and password, then click Sign in. I complete the MFA challenge via my Authenticator app when prompted. As mentioned earlier, this account does not currently use phishing-resistant MFA.
After logging in, I am briefly signed in before being automatically logged out. However, by this point, the Evilginx tool has already captured the necessary authentication information.
7. Let’s take a look at what Evilginx has captured.
8. At this point, I have successfully captured the user’s credentials, including the username and password, through the fake login page.
Evilginx has now captured the user’s session, including the MFA acceptance, a critical point in demonstrating how traditional MFA can be bypassed in such attacks. Let’s dig a little deeper.
9. I run the sessions command and can see that the username, password, and session token have all been successfully captured.
10. I type sessions 13 and press Enter to inspect the captured session in more detail.
11. The session token is now visible, this includes the full session data that Evilginx has intercepted, allowing an attacker to potentially hijack the authenticated session without needing the user’s credentials or MFA prompt again.
12. Next, I prepare to replay the stolen session token. I highlight and copy the token from the Evilginx output.
13. I’ve downloaded Firefox and installed a cookie editor extension to assist with injecting the session token.
14. I launch Firefox and navigate to https://office.com.
15. I click the Sign in button on office.com and am redirected to the official Microsoft login page.
16. I clear all existing cookies using the cookie editor extension.
17. Inside the cookie editor, I click the Import option and paste the stolen session cookie. I then click Import again.
I return to the fake login page. I type my username and click Next, but instead of entering a password, I select the option: Use your face, fingerprint, PIN, or security key instead, as shown in the image below.
2. I’m prompted to use a security key, but this prompt is for the fake domain (login.micr0soft.com). My passkey is registered to the legitimate domain (login.microsoft.com), so authentication fails. As a result, Evilginx is unable to capture the session token.
No sessions saved by the Evilginx app
I hope this post was useful. Thanks for reading and see you at the next one.
In this 2 post blog series, I’ll explore emergency “break glass” account best practices, the importance of phishing resistant MFA (Multi Factor Authentication), how phishing-resistant MFA can protect against credential and session token theft via a phishing attack by a bad actor, and finally I will go through a step by step demo on configuring a physical FIDO2 (Fast Identity Online) supported passkey, specifically a YubiKey. I purchased a YubiKey for 30 euros from Yubico. Please note that Yubico offers various types of YubiKeys including different types of USB connectors and physical keys which meet different compliance standards, so it’s essential to research your options before making a purchase. Additionally, since FIDO2 is an open standard, several other vendors offer physical keys, giving you multiple options to choose from.
IMPORTANTNOTE Part 2 will provide a detailed, step by step demo on configuring a YubiKey. I recommend reading this post (Part 1) first to understand best practices and how FIDO2 works to secure your account. However, if you wish to skip to Part 2, click the following link: Part 2 – Configure a YubiKey For An Emergency Access Account In Entra ID | Cloud Build
Image of a Security Key NFC (Near Field Communication) by Yubico. This is the key I purchased.
Explanation of NFC: Near Field Communication (NFC) is a wireless technology that enables devices to communicate with each other when they are in close proximity, typically within a few centimetres. Think about when you touch your card or Apple Pay on your phone against a card reader to make a payment. If supported, you can utilise the NFC capabilities allowing you to touch they key on a NFC reader built in to your phone or a internal/external NFC reader built in to your laptop.
As mention above, part 2 covers the step by step demo, so before diving into the steps for configuring my YubiKey as a secure phishing resistant MFA method, I’d like to go through some important points, starting off with best practices you should consider when setting up an emergency access account.
Emergency Access “Break Glass” Account Best Practices
Emergency accounts also known as break glass accounts are crucial accounts that provide access to critical systems during an emergency. Microsoft recommends that organisations have two cloud only emergency access accounts permanently assigned the Global Administrator role. These accounts are highly privileged and should not be assigned to specific individuals. They are limited to emergency scenarios only and where normal accounts can’t be used or all other administrators are accidentally locked out. Here are a few points to note when creating your emergency break glass accounts:
Assign Both Emergency Accounts Permanent Global Administrator:
Having two break glass accounts ensures that if one account becomes inaccessible, you have a fallback account.
Use Non-Obvious Names:
Avoid obvious names like emergency@.onmicrosoft.com or breakglass@.onmicrosoft.com. Instead, use random human names to make the accounts obscure, making it more challenging for attackers to target them during attacks like password spraying.
Create Cloud Identities:
Create your break glass accounts using the *.onmicrosoft.com domain inside Entra ID. Avoid syncing accounts from on-premises to prevent access issues if on-premises systems fail.
Configure Complex Passwords:
Use strong passwords, ideally with a minimum of 16 characters as recommended by Microsoft at the time of writing this post. Although it is possible to create passwords up to 256 characters long, a minimum of 32 characters is common. Feel free to increase the length of the password as per your requirements. However, be aware that no matter how strong the password, bad actors can still steal user credentials via a phishing attack, therefore still a potential risk and the reason why it is recommended to use phishing resistant MFA, such as FIDO2 supported devices. More on this later.
Secure Password Storage:
If you’re using passwords, follow Microsoft’s recommendation to separate the password into two or three parts, write each part on separate pieces of paper, and store them in secure, fireproof safes in different locations. Ensure only authorised individuals have access.
Use Phishing Resistant MFA:
For multi-factor authentication (MFA), use a phishing resistant method like a FIDO2 Security Key. Again, ensure you store these physical keys in a safe location and only allow authorised individuals access.
Audit and Monitor Access:
Configure monitoring to notify you if the emergency break glass accounts are used, allowing for swift action.
Diversify MFA Methods:
Avoid using the same MFA method as your admins. For instance, if admins use passkeys via their phones or certificate based authentication (CBA), use a physical pass key for the emergency accounts to avoid issues affecting mobile devices such as a wider mobile network outage.
Avoid Assigning to Individuals:
Do not attach break glass accounts to an individual, such as an engineer’s mobile phone, to prevent issues if the person is unavailable. Just imagine if that individual is on holiday, it’s not good practice from both a convenience and security point of view.
Exclude from Conditional Access Policies:
Ensure at least one emergency access/break glass account is excluded from all Conditional Access policies.
Regular Validation and Documentation:
Validate your emergency accounts every 90 days or sooner if needed. Document a step by step process to allow authorised IT staff access to the accounts in emergencies. Training and clear documentation are crucial. The last thing you want is to discover an issue during a real emergency which could have been prevented through testing and validation.
Now that we have covered best practices for emergency break glass accounts, you may have read or heard that Microsoft announced mandatory multi factor authentication (MFA) will be enforced for Azure sign ins. This will gradually be rolled out to other portals, such as admin.microsoft.com, and more. So, what does this mean? Well, any user account logging into the admin portals will be required to enable MFA before they can log in.
Previously, it was possible to log into the Azure portal using an account without MFA enabled, but this will no longer be possible going forward. Why? Because one of the most effective security measures available to organisations is multifactor authentication (MFA). Research by Microsoft shows that MFA can block more than 99.2% of account compromise attacks. Since emergency accounts are commonly used to log into admin portals, these accounts are not exempt from this new rule. Attackers could exploit emergency break glass accounts to access your environment with Global Administrator privileges and cause significant damage. Previously, a large number of organisations would create emergency break glass accounts without enabling MFA, which was normal. However, this recent announcement from Microsoft means that organisations will no longer be allowed to login to admin portals using any account including emergency break glass accounts with a password alone. MFA must be enabled with phishing resistant MFA being highly recommended, however, other MFA methods are allowed. In my opinion, it makes sense to secure these highly privileged accounts.
Great, we’re nearly there. What’s next? I would like to provide a quick overview of passkeys and how passkeys can protect you against a bad actor stealing user credentials and session token via a phishing attack using tools such as Evilginx. Let’s learn more.
What are passkeys? Passwords can be compromised through various methods, including phishing attacks, regardless of their complexity. FIDO2 supported passkeys enable phishing-resistant, passwordless authentication. They replace weak credentials with strong, hardware backed public/private key credentials, reducing the chances of user credentials and session token being stolen.
A common attack method involves a bad actor attempting to steal user credentials by tricking them into clicking a malicious link. Adversary in the Middle (AiTM) attack tools, such as Evilginx, can intercept communication between the user and login providers like Microsoft, Facebook, or Google, capturing the necessary information to access the user’s data. Evilginx is capable of capturing session cookies, which validate a user’s session after MFA is completed. Put simply, Evilginx can bypass non-phishing resistant MFA, making it ineffective and allowing unauthorised access to the user’s data.
When configuring a FIDO2 supported method, such as a physical YubiKey, the process involves the generation of two keys:
A private key, which remains on the physical YubiKey and never leaves the device. This is similar to how other phishing resistant methods function, such as Windows Hello For Business. This private key never leaves the physical device, so in the case of a YubiKey, the private key is stored securely on the YubiKey. With Windows Hello for Business, the private key remains on the device, such as the laptop, stored in a secure TPM (Trusted Platform Module).
A public key is provided to the relying party. In my case, the relying party is Microsoft, because I’ll be using my FIDO2 supported physical passkey to log in to admin portals such as the Azure portal.
Because passkeys are phishing resistant, they are highly recommended. Apart from physical FIDO2 security keys, there are other phishing resistant MFA methods available, including Certificate Based Authentication (CBA), passkeys via the Microsoft Authenticator app and one I mentioned earlier, Windows Hello for Business.
Why are passkeys secure? When configuring a passkey, there are a number of security features that prevent a hacker from misusing your credentials. One of the key security features is proximity, which means the user must have proximity between the authenticator and the laptop. In this case, the authenticator could be a physical FIDO2 security key or a passkey on the Authenticator app. This prevents users from being tricked by a bad actor, for example, if the bad actor attempts to steal a user’s session token via a phishing attack, it would be of no use, because the hacker is most likely sitting someplace far away from the laptop, and therefore the proximity check fails and access is denied.
Another important security feature is that the FIDO2 supported device is tied to a specific website address or relying party. This means that if a bad actor tries to fool the user by directing them to a fake URL via a phishing attack, the authentication attempt would fail when the user attempts to use their phishing resistant device, such as a YubiKey. This is because the private key stored on the device will only respond to the specific website it was originally registered with. So, even if a hacker tries to mimic the real website by creating a good looking clone pointing the user to login.micr0soft.com (disguising the o for a zero), the FIDO2 supported key won’t complete the authentication process because it was originally registered against login.microsoft.com and not the fake login.micr0soft.com.
Still confused? I demonstrate the YubiKey registration process in the diagram below.
Click the image below to enlarge.
How does a hacker steal user credentials and session token?
One of the methods I am focusing on in this post is where bad actors steal user credentials via a phishing attack, by fooling the users to click a link which directs the user to fake login page. The user assumes that they are accessing a genuine login page and upon the entering a username, password and even going through non-phishing resistant MFA, the bad actor captures the users session token and then replays it on their own device. Yes, there are tools such as Evilginx which can bypass MFA. This allows the hacker direct access to the user’s data such as email, one drive data and so on, without having to authenticate again.
In the video below, Merill Fernando (Principal Product Manager @ Microsoft Entra) demonstrates how Evilginx works and provides a couple of controls which can prevent such an attack when an Adversary in the Middle (AiTM) attack tool such as Evilginx is used.
DISCLAIMER: Evilginx has the potential for malicious use. It’s crucial for defenders to account for such attacks and devise strategies to safeguard their users from these types of phishing threats. Evilginx should only be employed in lawful penetration testing engagements with explicit written consent from the targeted entities or for educational objectives.
Note While phishing-resistant MFA provides strong protection against phishing attacks and greatly reduces the risk of credential theft, it does not completely prevent token theft, for example, if a bad actor uses malware on a user’s device. This is why it’s essential to adopt a defense in depth strategy, which includes multiple layers of security measures, including endpoint protection on your devices.
In the below video Alex Weinert (VP Identity Security at Microsoft) provides several solutions to help protect against token theft.
Passkeys Available via Phone Using the Authenticator App In the next post, I demonstrate how to set up a physical FIDO2 support passkey from Yubico. However, I wanted to mention that passkeys are also available without needing to purchase a physical key. Modern smartphones come equipped with built in FIDO2 authentication capabilities, providing you with phishing resistant protection and allowing you to use biometric features like fingerprint or face recognition as passkeys. With the Microsoft Authenticator app, you can register and use these passkeys on your iPhone or Android phone to securely log into your accounts. This provides a convenient and cost effective way to enhance your online security without having to purchase physical security keys.
I know what you’re thinking! “If passkeys are available for free using phones via the Authenticator App, why should I purchase a physical key?”
Great question! While passkeys on smartphones offer a great level of convenience and security, there are several reasons why an organisation might still opt for physical security keys. Here are a few benefits:
Device Flexibility: Physical passkeys can be used with any device, including shared workstations, without relying on employees’ personal mobile phones. If you don’t allow the use of personal mobile phones in your organisation, you could purchase physical passkeys.
Enhanced Protection: Physical keys can offer an extra layer of protection against malware and other attacks that might target vulnerabilities in mobile devices.
Compliance Requirements: In some industries, compliance requirements may mandate the use of physical keys. Therefore, while smartphone based passkeys are excellent for many users, physical keys still play a crucial role depending on your organisational requirements.
Emergency Break Glass Accounts: A physical FIDO2 key would be a better option than a mobile phone for an emergency break glass account. It ensures that access is not dependent on the availability or functionality of a specific mobile device. YubiKeys don’t contain moving parts and are designed to be simple and robust, with a solid construction that contributes to their reliability. They don’t require batteries or an external power source, as they draw power directly from the USB or NFC connection when in use, making them ideal for offline storage and offsite locations.
In Part 1, I covered emergency account best practices and the benefits of FIDO2 supported passkeys. If you haven’t read the post, I highly recommend doing so to get a understanding of the foundational concepts and best practices that will enhance your overall security. It’s worth the read! You can check out part 1 by clicking the following link Part 1 – What is a FIDO2 key and How to Set One Up for Emergency Access in Entra ID | Cloud Build
In this blog post, I will guide you through the step by step process of configuring a YubiKey purchased from Yubico. As explained in part 1, the open standard technology used under the hood is FIDO2, which is also used by other vendors. It’s not only Yubico that provides these FIDO2 based security keys.
Now that you have had an overview of passkeys and how bad actors steal user credentials and session token, let’s continue to part 2, enabling my YubiKey (FIDO2) which I purchased from Yubico.
Access entra.microsoft.com
Click protection and authentication methods from the left pane
3. Click Passkey (FIDO2) which is set to disabled by default
4. Click the toggle to enable, click select groups and then browse and locate your security group in which your emergency break glass account is a member of. In my case, I have created a DemoGroup which includes the emergency break glass account.
5. Next, click Configure
6. There are several default configuration options. Let’s go through these one at a time.
Allow self-service setup The default option is set to yes, which means users can self register a passkey by logging into the my sign-ins portal accessible via https://mysignins.microsoft.com/security-info. If set to No, users can’t register a passkey.
Note: Currently in preview, administrators can use Microsoft Graph and custom clients to provision FIDO2 security keys on behalf of users. At the time of writing, there is no option to provision FIDO2 keys on behalf of users via the Azure or Entra portal, therefore, users have to enable this capability themselves via the my sign-ins portal I shared above. Public preview: Microsoft Entra ID FIDO2 provisioning APIs
Enforce attestation The next option is Enforce attestation.
When this option is set to Yes, Microsoft relies on the FIDO Alliance Metadata Service (MDS) to determine security key compatibility with Windows, Microsoft Edge browser, and online Microsoft accounts. The FIDO Alliance Metadata Service (MDS) is a centralised repository of the Metadata Statement that is used by the relying parties to validate authenticator attestation and prove the genuineness of the device model. Vendors such as Yubico report data to the FIDO MDS. Vendors are responsible to publish all root attestation certificates to the FIDO Alliance MDS; otherwise, attestation verification can fail. In simple terms, attestation involves performing a check against a central verification database to ensure the FIDO2 key being used is listed and verified in a central database.
Administrators can enforce which hardware security key providers are allowed in their environment. For example, an organisation may only allow particular models of YubiKey deny all other providers. YubiKeys are identified by a AAGUID which can be accessed at the following url, YubiKey Hardware FIDO2 AAGUIDs – Yubico
I purchased a security key NFC with firmware version 5.7. Accessing the link above, I’ll be able to locate the unique AAGUID for this model of device. If I enter the AAGuid into the configuration within EntraID, only this model of security key will be allowed in my organisation. I could add additional AAGUIDs if needed.
If you wish to use passkeys in Microsoft Authenticator, clicking the check box labelled Microsoft Authenticator automatically adds the two AAGUIDS for Apple and Android to the list, allowing you to use passkeys in the free Microsoft Authenticator app. If you wish to learn more, click the following Microsoft Learn link, How to enable passkeys in Microsoft Authenticator for Microsoft Entra ID
The images below show how an AAGUID is added and include the check box to enable passkeys in Microsoft Authenticator. I won’t be covering passkeys in the Microsoft Authenticator app but you can learn more at the link I posted above.
Ok, we’re done. The option to use PassKeys (FIDO2) is enabled.
The user experience
In the next steps, I will login using my emergency break glass account and enable the option for physical PassKeys.
5. I am required to configure MFA before I can enable a security key. I click next.
6. Click Next again
7. I already have the Microsoft Authenticator App installed on my phone. I click next
8. I open the Authenticator app on my phone and scan the QR code provided
9. A two digit code appears on screen and a prompt on my Microsoft Authenticator App requesting I enter the two digit code. After entering the code, I receive a notification approved message.
12. I click add sign-in method and select Security Key again. This time I receive two options. I click USB device.
13. Click Next. If I had selected NFC in the step above, I would receive the message below. By selecting USB, the message would be similar but there would be no mention of “tap your security key on the reader”.
14. I am redirected to Windows Security. I select Security key and click Next
15. I click ok
16. Click ok. Notice the key will be locked down to login.microsoft.com. If a bad actor attempts a phishing attack and redirects the user to a fake url, the YubiKey will not allow access and authentication would fail.
17. I am prompted to insert my YubiKey into my laptop. Plug the physical key into the USB port depending on which USB device you purchased.
18. Once the YubiKey is detected, I am asked to create a new pin. This pin will be stored inside my YubiKey.
19. After creating a PIN, I am prompted to place my finger on the YubiKey and I receive a notification that the Passkey has been saved.
20. Name the Key, for example YubiKey 5 NFC, and click next.
21. We’re all set. Click done
22. The new YubiKey is now visible as one of my sign-in methods.
23. I remove the YubiKey from the USB port in my laptop.
To test the YubiKey. I’ll access portal.microsoft.com
Type my username
Instead of entering a password, I click the option, Use your face, fingerprint, PIN, or security key instead
24. Select Security key and click next
25. I enter the pin I created earlier, and click OK
26. The YubiKey flashes and I am prompted to place my finger on the YubiKey. I’m in.
That’s it.
Enforcing users to use phishing resistant MFA If you wish to enforce the use of phishing resistance MFA for certain or all users, you can use authentication strengths via conditional access policies in Entra ID.
A few points to note
Conditional Access requires Entra ID P1 licenses. It is not a free feature.
Attestation enforcement governs whether a passkey (FIDO2) is allowed only during registration. Users who register a passkey (FIDO2) without attestation aren’t blocked from sign-in if you were to enable the option enforce attestation later.
Enforce key restrictions should be set to Yes only if your organisation wants to allow or disallow certain security key models or passkey providers, which are identified by their AAGUID. You can work with your security key vendor to determine the AAGUID of the passkey or check the vendors website. If the passkey is already registered, you can find the AAGUID by viewing the authentication methods for the user in Entra ID by clicking authentication methods from the left pane. The AAGUID is also visible from the my sign-ins portal.
If your organisation doesn’t currently enforce key restrictions and already has active passkey usage, you could collect the AAGUIDs of the keys being used today. Add them to the allow list and enable enforce restrictions. This task can be completed with an automated script that analyses logs, such as registration details and sign-in logs.
Currently in preview, administrators can use Microsoft Graph and custom clients to provision FIDO2 security keys on behalf of users. At the time of writing, it was not possible to automatically provision the rollout of FIDO2 security keys to users from the portal.
I hope you found this two part blog series useful. Thank you for tuning in and catch you at the next post.
In this post I explore how to integrate Defender for Endpoint with Defender for Cloud Apps natively without having to go through much effort.
Why would you want to do this? Once traffic information is collected by Defender for Cloud Apps, you can analyse what Cloud Apps your users are accessing, including details such as website address, IP, user and device name.
Defender for Cloud Apps takes advantage of capabilities to block endpoint device access to Cloud Apps. Cloud Apps can include any application or website accessed over the Internet, for example, Office 365 and websites such as social media sites. For example, you may want to identify commonly used risky cloud storage and collaboration websites your users may be using and unsanction (block access). Defender for Cloud Apps helps you manage over 31,000 apps by assessing risk factors provided by Microsoft to ensure compliance. If a Cloud App does not meet security and compliance requirements, you can unsanction the app. This is basically shadow IT and mitigation, allowing you to block the use of unauthorised Cloud Apps in your organisation with a click of a button.
Pre-requisites
Microsoft Defender for Cloud Apps license
Microsoft Defender for Endpoint with Plan 2 OR Microsoft Defender for Business with a premium or standalone license.
Windows 10 version 1709 (OS Build 16299.1085 with KB4493441), Windows 10 version 1803 (OS Build 17134.704 with KB4493464), Windows 10 version 1809 (OS Build 17763.379 with KB4489899) or later Windows 10 and Windows 11 versions.
There are number of configuration options we must enable before the data we require from our user devices is visible within Defender for Cloud Apps.
Access the Microsoft Defender XDR portal at security.microsoft.com
From the left pane, click settings.
3. Click Endpoints
4. Click Advanced features
5. Scroll down to Microsoft Defender for Cloud Apps and enable this option.
6. From the left pane, click Settings again
7. Click Cloud Apps
8. Under Cloud Discovery, click Microsoft Defender for Endpoint
9. Enable enforce access. Once you discover and unsanction unauthorised Cloud Apps, users will not be able to access them and will receive a warning. You can also set up additional alerting options as required, such as redirecting the users to a custom web page of your choice when a website/cloud app is blocked.
10. Click Settings > Endpoints > Advanced features, and then select Custom network indicators. This allows you to leverage Microsoft Defender Antivirus network protection capabilities to block access to URLs using Defender for Cloud Apps.
11. Click Yes to confirm.
It can take up to 2 hours before information is passed from the endpoints to Defender for Cloud Apps
12. Access Defender for Cloud Apps (security.microsoft.com) and click Cloud Discovery from the left pane as shown in the image below.
13. Once the data is visible in Defender for Cloud Apps, a new report similar to the one below should be visible. The report shown in the image below is named Win10 Endpoint Users.
14. In the Win10 Endpoint Users report, some statistics start to become visible. Click Discovered apps.
15. We can see a list of Cloud Apps being accessed by users. There is not much going on as I only have one Windows 10 machine and one user that I used for this demo.
Each Cloud App/website is assessed against a catalog of built in Cloud Apps. The Microsoft Defender for Cloud Apps catalog page provides a list of over 31,000 discoverable Cloud Apps. Defender for Cloud Apps discovery analyses your traffic logs from your Windows 10 and 11 devices to give you ongoing visibility into Cloud use, shadow IT, and risks posed to your organisation. Defender for Cloud Apps rates each website/cloud app risk based on regulatory certification, industry standards, and best practices.
16. We can dig deeper and check the users and IP addresses tab.
17. All Cloud Apps accessed by my demo users are ok from a risk score point of view, but let’s assume that I wanted to prevent my users from, accessing Dropbox or other websites. I could unsanction, block access to the Cloud App.
Note: unsanctioning a Cloud App blocks access for the whole organisation. However, you can create custom App tags which can be based on include and exclude. You can then select to exclude or include certain devices. For example, block access to social media sites for all devices apart from marketing user devices.
18. Once I click unsanction, a list of drop box url’s are added to a blocked list known as Indicators. These can be viewed by clicking settings from the left menu > Endpoints and then scroll down to Indicators as shown in the image below.
19. You’ll find that as part of unsanctioning Dropbox, a number of urls are added automatically by Defender for Cloud Apps, such as dropbox.com, dropbox.jp, dropboxbusiness.com and more. You could also manually add website addresses you wish to block from user devices.
Note: it can take a few hours, sometimes up to 24 hours before the changes are synced to Defender for Endpoint.
20. We can also unsanction Cloud Apps from the catalog of over 30,000 built in apps. From the left pane click Cloud App catalog.
21. I filter to display all Cloud Apps with a risk score of zero. Change the filter as per your requirements using the risk score option shown in the image below.
A total of 321 apps (at the time of writing) with a risk score of 1 appear from the catalog.
22. Let’s click the first one in the list, torrentz.cl
Clicking the app, provides me with some useful information including app security and compliance details. This could be really useful as I may only want my users accessing apps which meet ISO 27001 and ISO 27018 compliance.
I could also check if my users are using this app and if yes, I could decide to unsanction (block) or even monitor access. If a Cloud App is tagged as monitored, a message will appear notifying the users that this cloud app/website is being monitoring.
23. After the indicators have synced to Defender for Endpoint (This could take a few hours, sometimes up to 24 hours), I launch Edge browser and access dropbox.com, I receive a blocked message. An alert is also logged in the Defender portal to inform administrators that a user attempted to access an unsanctioned (blocked) website/cloud app.
Message: This website is blocked by your organization. Contact your administrator for more information.
and that’s it. I hope you found the post useful.
See you at the next post
Subscribe
Subscribe to new tech posts.
We will never send you spam email or forward your details to third parties.
