CEO impersonation with Microsoft Booking

Recently I observed an interesting behavior after setting up a Microsoft Booking page. After creating the booking page, I suddenly got an e-mail to an automatically created mail alias with the same name as the booking page. This made me curious and I wanted to understand the behavior behind this, and if this could be abused by attackers to impersonate users in Exchange online. In this blog post, I want to share my findings and some tips on how to detect and prevent this kind of abuse in your environment.

Microsoft Booking

Microsoft describes the Bookings capabilities as part of Microsoft 365:

“A simpler way to organize schedules and manage appointments.”

Booking pages can be either of type ‘personal’ or ‘shared’:

• Personal booking pages provide a handy option for users to create their own booking page, which is automatically linked to their calendar and allows others to book appointments with them. This is a great feature for users who want to share their availability and allow others to easily schedule meetings.

• The shared booking pages allow teams to provide a booking experience for services hosted by a team and come with a special mailbox and calendar.

When creating a shared booking page, we already get a glimpse of the underlying behavior, as we have to provide a name for the booking page, which also determines the mail alias and reply-to address for the automatically created mailbox for the booking page:

So because of this e-mail generation behavior, let’s have a closer look at the ‘shared’ booking page type and how this can be abused by attackers to impersonate users in the organization.

Reverse Engineering the E-mail generation

To understand the behavior of the e-mail generation for the booking page, I created multiple booking pages with different names and observed the generated e-mails. Below is a table with the different booking page names I used and the corresponding generated e-mails:

This reveals the following aspects about the e-mail generation for the booking page:

• Dots are removed for all above cases, including subsequent dots and escaped dots
• Underscores are not removed
• If an SMTP address already exists, a number is added at the end of the mail alias and reply-to address (e.g. [email protected])
• Cyrillic characters are stripped from the e-mail address and alias

So depending on an organization’s naming for e-mails, it can be easier or harder to impersonate users.

Impersonation Opportunities

‘Ideal’ impersonation cases from an e-mail address format are:

• [email protected] (first letter of the first name and full last name)
• [email protected] (full first name and last name with underscore)
• [email protected] (full first name and last name)

And from a recipient name perspective, we can leverage ’traditional’ character substitutions to create similar-looking recipient addresses, such as:

Exchange Online Mailbox Behavior

When using the ExchangeOnlineManagement PowerShell module to look for the created mailboxes for the booking pages, we can also see that the RecipientTypeDetails property is set to SchedulingMailbox and that the creator of the booking page is added as the ForwardingSmtpAddress property of the mailbox:

Detect Creation of Shared Booking Pages with Defender for Cloud Apps

You can use the following KQL query to detect the creation of shared booking pages in your environment based on Defender for Cloud Apps:

CloudAppEvents
| where ActionType == @"New-SchedulingMailbox"
| mv-apply Item = ActivityObjects on (
    summarize 
    BookingPageName = take_anyif(Item.Value, Item.Name == "Name"),
    BookingPageDisplayName = take_anyif(Item.Value, Item.Name == "DisplayName"),
    ReplyToAddress = tolower(tostring(take_anyif(Item.Value, Item.Name == "ReplyToAddress"))),
    WindowsLiveID = tolower(tostring(take_anyif(Item.Value, Item.Name == "WindowsLiveID"))),
    MailAlias = tolower(tostring(take_anyif(Item.Value, Item.Name == "Alias")))
)

Impersonation Attack Scenario

Impersonating a user in the organization becomes very easy, as an attacker can simply send e-mails from the generated booking page mailbox, which will have the same display name and a similar e-mail address as the user they want to impersonate.

Here an example of a ’legitimate’ e-mail sent from the booking page mailbox and a ’lure’ e-mail sent by an attacker impersonating a user in the organization:

Did you spot the OAuth abuse with the prompt=noneparameter? 🙃

Detection Opportunities

If you have Defender for Office in place as well, you can even search for e-mails that originated from recently created booking pages by joining the EmailEvents table.

// Find E-Mails Sent by Shared Booking Pages
let SharedBookingPages = CloudAppEvents
    | where ActionType == @"New-SchedulingMailbox"
    | mv-apply Item = ActivityObjects on (
        summarize 
            BookingPageName = take_anyif(Item.Value, Item.Name == "Name"),
            BookingPageDisplayName = take_anyif(Item.Value, Item.Name == "DisplayName"),
            ReplyToAddress = tolower(tostring(take_anyif(Item.Value, Item.Name == "ReplyToAddress"))),
            WindowsLiveID = tolower(tostring(take_anyif(Item.Value, Item.Name == "WindowsLiveID"))),
            MailAlias = tolower(tostring(take_anyif(Item.Value, Item.Name == "Alias")))
        );
EmailEvents
| join kind=inner SharedBookingPages on $left.SenderFromAddress == $right.WindowsLiveID
| project-rename  EmailEventTimeGenerated  = TimeGenerated1
| project EmailEventTimeGenerated, SenderFromAddress, RecipientEmailAddress, Subject, EmailDirection, DeliveryAction

Preventing Abuse of Shared Booking Pages

Microsoft provides the option to disable the creation of shared booking pages in the Microsoft 365 admin center (the “Allow your organization to use Bookings” setting). By disabling this feature, you can prevent attackers from creating shared booking pages and impersonating users in your organization.

Alternatively, you can also use the Exchange Online PowerShell module to disable or check the creation of shared booking pages with the following command:

Set-OrganizationConfig -BookingsEnabled $false

This does not affect personal booking pages, which can still be created by users. Furthermore, there’s also the option to only allow specific groups to create shared booking pages, which can be a good option for organizations that want to allow certain teams to use this feature. Additional information is available in the Microsoft documentation: https://learn.microsoft.com/en-us/microsoft-365/bookings/turn-bookings-on-or-off

Conclusion

I assume that, similar to myself, a lot of organizations are not aware of the impersonation risk that comes with the shared booking page feature, and that this can easily be abused by attackers to impersonate users in the organization. Therefore, I recommend organizations to review their use of Microsoft Booking and consider disabling the creation of shared booking pages if they are not needed. Otherwise, organizations should monitor for the creation of shared booking pages and any e-mails sent from these pages to detect any potential abuse.

P.S.: While working on this post I found out that cyberis already published a blog post about this topic, which you can find here: https://www.cyberis.com/article/microsoft-bookings-facilitating-impersonation.