This blog post details the effort to enable passwordless phone sign-in to Azure Active Directory using the Microsoft Authenticator App. Last week Microsoft announced this capability on September 26^th at the Ignite Conference.

In my environment, I had to first install the Azure AD PowerShell preview module:

Install-Module -Name AzureADPreview -RequiredVersion 2.0.0.114

The first error I got reminded me that I had to run it in an elevated PowerShell window.

The second error I received informed me that there were already existing commands available:

“PackageManagement\Install-Package : The following commands are already available on this system: [Insert a TON of commands] followed by “This module ‘AzureADPreview’ may override the existing commands. If you still want to install this module ‘AzureADPreview’,use -AllowClobber parameter.”

In my case, it errored out because I had previously installed the production Azure AD PowerShell module, so I added the -AllowClobber to the end like this:

Install-Module -Name AzureADPreview -RequiredVersion 2.0.0.114 -AllowClobber

The next thing to do is to connect to Azure AD:

Connect-AzureAD

Then run this command:

New-AzureADPolicy -Type AuthenticatorAppSignInPolicy -Definition ‘{“AuthenticatorAppSignInPolicy”:{“Enabled”:true}}’ -isOrganizationDefault $true -DisplayName AuthenticatorAppSignIn

You can now run a get-AzureADPolicy to see the same information above. This would be a way to check to see if another tenant admin already beat you to the task =)

End User Steps

End-users need to enable sign-in on their Microsoft Authenticator App as described here: https://docs.microsoft.com/en-us/azure/active-directory/user-help/microsoft-authenticator-app-phone-signin-faq

I immediately hit a roadblock where the Authenticator App was ironically blocked by our Conditional Access Policy which requires only approved client apps.

Very strange that Microsoft’s own Authenticator app is not an approved client app.

Another tell-tale sign that something was wrong was I had an exclamation point next to the account inside the Authenticator app.

So I then excluded myself from that policy and continued setup. I had to select an option in the Authenticator app to update phone sign-in.

This worked and then I was able to test the passwordless sign-in successfully. The web page will give you a number, and then you go back into the authenticator app and you select the number from three options.

If you are wondering why 77 is not in the list of three options below, it’s because I didn’t time the screen shot correctly =)

Therefore, I think Microsoft should update the known issues list to include this problem that existing Conditional Access Policies may block the passwordless sign in from working properly.

I also added a UserVoice request to have Microsoft Authenticator added to the list of approved client apps. Kind of funny that this isn’t approved already, but hey, please vote!

https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/35605771-add-microsoft-authenticator-to-approved-client-app

So unfortunately, because our organization relies upon the ‘require approved client app’ to block unsavory apps, we needed to roll back this change.

Rollback Tenant

Get-AzureADPolicy | Remove-AzureADPolicy

Rollback all enrolled Authenticator apps

I discovered that rolling back the tenant was not enough. I also had to remove my O365 account from inside the Authenticator app on my mobile device. I assume when my account was upgraded to Phone sign-in, it must have altered it beyond repair. So I went into the Authenticator App accounts and removed the account, and then re-enrolled it by going to http://aka.ms/MFASetup. Finally, I was able to get back in.

So now that I have tasted how cool passwordless sign-in, I would really like to use it, but will need to wait until it is compatible with the ‘require approved app’ conditional access feature.

References:

https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-authentication-phone-sign-in

Statistics indicate that 20% to 50% of corporate users will give away their username and password when asked to do so by a social engineer (for example through a phishing email).

50% to 70% of corporate users admit to recycling their password across multiple websites. Users will memorize no more than 5 unique passwords, and then they start to increment numbers on the end. Then when these websites are hacked, the passwords can be put into credential stuffing tools like SNIPR to see what websites those passwords can be used on.

Some of the more clever and convincing phishing emails originate from a trusted person such as the CEO, HR Department, IT Department, or even Microsoft. The HR Department example might say “you have received an encrypted message from HR” and if you click on the link to view the message, it steals your O365 password. The attacker then logs into your account, forwards your email to them, and then send emails out to your customers or other colleagues to continue to propagate.

Here are a few tips on how to prepare for when this happens to you.

1. Be prepared to Reset the affected user’s password right away. Note that if you reset the password on-premises, it can take a few minutes before that password change is synced to Office 365 (if you are using Password Hash Sync, it can take 3 to 4 minutes). If you are using ADFS or AAD PTA then there is no delay.
2. Document the steps to revoke an active user’s session in Office 365, forcing them to try to logon with the new password. There are five supported methods, but in my testing I get mixed results on how quickly they take effect. For example, on a mobile device that previously authenticated with an MFA token for ActiveSync, none of the below methods seem to immediately invalidate the MFA token. Fortunately, most account takeovers in O365 are browser-based, so this shouldn’t be a problem to proceed with any of the options below.
   Option 1) Reset the user’s password. This will invalidate the current token.
   Option 2) In Azure AD remote powershell:
   $RefreshTokensValidFrom = Get-DateSet-MsolUser –UserPrincipalName <UPN of the User> –StsRefreshTokensValidFrom $RefreshTokensValidFrom

   Note StsRefreshTokenValidFrom will appear to accept any date, but it will always set to the current date and time.

   Option 3) [Only applies if the user uses OneDrive] From the Office 365 Admin Center under Home > Active Users. Select a user and expand the OneDrive Settings section for that user. Select “Initiate” to perform a one-time sign-out for that user that revokes active sessions across Office 365 services including Exchange Online.
   Option 4) Force logoff during an active user session in Office 365 to use Revoke-SPOUserSession cmdlet from the SharePoint Online PowerShell Module. This method is helpful for automating security incident response flows or when there is a need to revoke multiple users’ sessions.
   Option 5)  Revoke-AzureADUserAllRefreshToken cmdlet is available in the AzureAD V2 PowerShell Module and expires a user’s refresh token by modifying the user’s token validity period”
   Reference: https://blogs.technet.microsoft.com/educloud/2017/06/14/how-to-kill-an-active-user-session-in-office-365/

3. Deploy Multi Factor Authentication on targeted users, privileged users, and users who access sensitive information. Many people do not know that O365 includes free MFA without the need for additional licenses.. it comes built into all O365 plans. Make sure you read the MFA Best Practices blog post here.
4. Check to see if mailbox forwarding was enabled, and if so to who (document the external addresses to verify the validity).
   Here is a great one-liner to run in Exchange Online Powershell:
   get-mailbox -resultsize unlimited |where {$_.ForwardingSmtpAddress -ne $null} | select displayname,forwardingsmtpaddress
5. Check message trace logs in Exchange Online Admin center (http://outlook.com/ecp) to see what items were sent to suspected unauthorized external accounts.
6. Disable forwarding via Transport Rule (This will block inbox rule auto-forwards but not Inbox rule ‘redirects’, OWA, or PowerShell forwarding).
   
   References: https://blogs.technet.microsoft.com/exovoice/2017/12/07/disable-automatic-forwarding-in-office-365-and-exchange-server-to-prevent-information-leakage/
   AND
   https://techcommunity.microsoft.com/t5/exchange-team-blog/the-many-ways-to-block-automatic-email-forwarding-in-exchange/ba-p/607579 
7. Prior to January 1st, 2019, Mailbox Auditing was disabled by default in Exchange Online. Microsoft began enabling it but in early 2019 they paused the audit of a particular action that was formerly known as MessageBind (deprecated 1/23/2019) with the renamed event MailItemsAccessed event, which tells you which emails the owner, delegate or administrator may have accessed. Tony Redmond wrote (here) that the rollout of this action will resume October 2019, per Message Center “MC193448”. At Ignite 2019 conference, it was announced that MailItemsAccessed would be included in ‘Advanced Auditing’ which is an E5 licensed feature. As of February 6th 2020, our tenant still shows no signs of this feature even though we have E5 licenses.
8. Review Azure Reports on a frequent basis. Note that detailed reports are not available with Azure AD Free, and require Azure AD Premium P1.
   1. Risky Sign-Ins
      1. Sign-ins from anonymous IP addresses
      2. Impossible travels to atypical locations
      3. Sign-ins from infected devices
   2. Users flagged for risk
   3. Azure Sign In Logs (Requires P1) at portal.azure.com
   4. Office 365 Audit Logs at protection.office.com or soon to be security.microsoft.com
9. Use Message Trace to see who received emails from the attacker’s email address.
10. Use ATP URL Trace to view who clicked on the hyperlink sent from the attacker.
11. Purge the email with PowerShell for any user who has not yet clicked on the email sent from the attacker.
    There are two ways of doing this, and one is significantly faster than the other.
    Method #1 is the traditional method and uses Search-Mailbox like this:
    Get-Mailbox  -ResultSize unlimited | Search-Mailbox -SearchQuery {Subject:“Urgent Memo from CEO” And received:05/31/2018..06/01/2018} -DeleteContent -Force
    Note: You have to be assigned the Mailbox Import Export management role to use the DeleteContent switch.
    Tip: gather what would be deleted first with this command: Search-Mailbox -Identity [email protected] -TargetMailbox [email protected] -TargetFolder Case1234 -SearchQuery “Subject:Click Here to get a Virus”

    Method #2 is newer and is a LOT faster.
    Search in the compliance center, export the result for evaluation (optional), then proceed with connecting to Exchange Online remote PowerShell and running these two commands (replacing with the search name you used in the compliance center).
    Get-ComplianceSearch -Identity “My Bad Virus”
    New-ComplianceSearchAction -SearchName “My Bad Virus” -Purge -PurgeType SoftDelete

12. Cloud App Security is valuable for many reasons, but it extends the auditing to 180 days whereas the built-in audit logs in the Office 365 Security and Compliance Center only go back 90 days.
    Licensing: CAS is available in two forms, O365 E5 or EMS E5… the former protects mostly O365 and 750 other SaaS apps, whereas the later protects 15,000 SaaS apps and supports automatic log uploads from your on-premises firewalls.
13. Office 365 Threat Intelligence (an E5 feature) can identify who your top targeted users are and alert you when there are active email campaigns going on so that you can alert your users of the threat.
14. Consider Disabling User Consent to 3^rd party applications in Azure Active Directory. This prevents users from granting consent to 3^rd party apps that may be the next wave of ransomware, that encrypts mailboxes. There is a new capability that allows Admins to approve apps that users request. A proof of concept was recently demonstrated on the internet. Review existing oAuth grants.
15. Deploy ATP Anti-Phishing. For more details: https://support.office.com/en-us/article/Set-up-Office-365-ATP-anti-phishing-policies-5a6f2d7f-d998-4f31-b4f5-f7cbf6f38578
16. Disable Legacy Authentication (This will be turned off October 2020, so might as well do it now)
    For more information on this, read the MFA Best Practices blog post here.
17. Disable POP/IMAP for future mailboxes and current mailboxes
    Examples:
    #All Future Mailboxes
    Get-CASMailboxPlan | set-CASMailboxPlan -ImapEnabled $false -PopEnabled $false
    #All Existing Mailboxes:
    get-casmailbox | set-casmailbox -imapenabled $false -PopEnabled $false
18. Disable SMTP Auth at the global level or mailbox level. This prevents users from using this as a brute force vector.
    #Global Level
    Set-TransportConfig -SmtpClientAuthenticationDisabled $true
    #Mailbox Level
    Get-casmailbox -resultsize unlimited | Set-CASMailbox -SmtpClientAuthenticationDisabled $true
19. Disable user’s powershell access in Exchange Online, ex:
    get-user | set-user -RemotePowerShellEnabled $false
    #Don’t lock yourself out – use the where clause to exclude your account.
20. Check Inbox rules and Delegate access in Exchange Online. For example, get-inboxrule -mailbox [email protected]
    Single User:
    Get-InboxRule -Mailbox [email protected] | where {$_.redirectTo -ne $null} |select mailboxownerid,redirectto,description
    Multiple Users:
    get-mailbox -resultsize unlimited |%{Get-InboxRule -Mailbox $_.userprincipalname} | Where-Object {($_.ForwardTo -ne $null) -or ($_.ForwardAsAttachmentTo -ne $null) -or ($_.RedirectsTo -ne $null) |select mailboxownerid,redirectto,description |Export-Csv .\inboxrules.csv -NoTypeInformationNote: For large organizations, this script can sometimes timeout, so you may need to incorporate a counter logic like I created in this other script I published on the TechNet gallery (here).

    ** TBD: Repeat the command above for any rule content where the RSS Subscriptions folder is mentioned. Note: Microsoft’s Cloud App Security has a rule to detect for malicious inbox rules like this.

    Here is the script to check for delegates:
    https://github.com/OfficeDev/O365-InvestigationTooling/blob/master/DumpDelegatesandForwardingRules.ps1

    Microsoft has a new report to show all SMTP and Inbox Forwards https://protection.office.com/reportv2?id=MailFlowForwarding&pivot=Name

Tips:

• Deploying MFA should be the first priority because if a user gives away their credentials, then the attacker cannot access the mailbox to do further damage.
• Many people ask me how to view reports of who has or who has not been enabled for MFA. There are not GUI reports available for this in O365, so I wrote some PowerShell scripts at the bottom of this blog post to help you enumerate those scenarios.
  Hint: It is highly recommended to enable oAuth first (via PowerShell) so that users are not prompted to use ‘MFA App Passwords)
  oAuth is off by default in Exchange Online and Skype for Business Online. It is ON by default in SharePoint and OneDrive. For more info see:
  https://social.technet.microsoft.com/wiki/contents/articles/32711.exchange-online-how-to-enable-your-tenant-for-modern-authentication.aspx

  And
  https://social.technet.microsoft.com/wiki/contents/articles/34339.skype-for-business-online-enable-your-tenant-for-modern-authentication.aspx

• Disabling mailbox forwarding is important because in the most recent incidents, the attacker will forward the mailbox to an outside email address and monitor for a while before initiating emails to customers or other employees.
• Enabling auditing in Exchange Online is important, because by default auditing mailbox activity is disabled. But enabling it is not as easy as you would think – you have to be specific on what actions you want to audit, so I have included examples below.
• Reviewing the Azure reports is important because they will indicate whether a user’s mailbox is being accessed by an unusual or distant IP address. This is often how you will find out that an account has been compromised.

Exchange Online Mailbox Auditing 101

get-mailbox | group-object AuditEnabled

This command will give you a quick and high level picture of how many accounts have Auditing enabled.

get-mailbox -resultsize unlimited | set-mailbox -AuditEnabled $true -AuditLogAgeLimit 180

This command will enable mailbox auditing on all accounts and increase the default audit level from 90 to 180

The following commands will show you the default auditing settings on a single mailbox user “Joe”

get-mailbox joe | select -ExpandProperty auditadmin

get-mailbox joe | select -ExpandProperty auditowner

get-mailbox joe | select -ExpandProperty auditdelegate

Prior to 2/1/2019, The Mailbox Owner auditing only logs a single event by default: MailboxLogin. After 2/1/2019, additional events are logged unless this has been customized.

Therefore, to enable the maximum level of auditing that you can for a mailbox owner, here is the command:

get-mailbox -ResultSize unlimited | set-mailbox -AuditOwner @{Add=”create”,”HardDelete”,”MailboxLogin”,”Move”,”MoveToDeletedItems”,”SoftDelete”,”Update”,”UpdateFolderPermissions”,”UpdateInboxRules”, “UpdateCalendarDelegation”}

Similar commands can be run for AuditDelegate and AuditAdmin.

References:

https://support.office.com/en-us/article/enable-mailbox-auditing-in-office-365-aaca8987-5b62-458b-9882-c28476a66918#ID0EABAAA=Mailbox_auditing_actions

MFA Reporting

The MFA reporting in Office 365 is almost non-existent. You need to go to powershell to audit who has been enforced, enabled or is not yet enabled.

1. Enabled (Means the user has been enabled but they have not yet completed MFA registration)

Get-MsolUser -All | where {$_.StrongAuthenticationRequirements.state -eq ‘Enabled’ } | Select-Object -Property UserPrincipalName,whencreated,islicensed,BlockCredential | export-csv enabled.csv -noTypeInformation

1. Enforced (The user has completed MFA registration, so their account is not protected by MFA)

Get-MsolUser -All | where {$_.StrongAuthenticationRequirements.state -eq ‘Enforced’ } | Select-Object -Property UserPrincipalName,whencreated,islicensed,BlockCredential | export-csv enforced.csv -noTypeInformation

1. Not Yet Enabled (These users have not yet been enabled for MFA)

Get-MsolUser -All | where {$_.StrongAuthenticationMethods.Count -eq 0 -and $_.UserType -ne ‘Guest’} | Select-Object -Property UserPrincipalName | export-csv non-enabled.csv -noTypeInformation

There is a great script that tells you exactly which type of MFA preference that users have set for themselves (ex: SMS vs Authenticator App). You can download that script from here.

Need Help?

Patriot consulting offers many security services for Office 365 including deploying any of the security solutions you read about in this article. We can also do a full audit of your Office 365 environment and make recommendations to harden the security. We also offer incident response services after you get phished. Contact us at [email protected]