What if I told you, you don't need an administrator to create a shared mailbox? What's even better, when creating a shared mailbox for yourself and colleagues, you'll get a whole booking page (courtesy of Microsoft Bookings) added to it!

Introduction

This is a story from when I've got unsolicited e-mail and plunged down a rabbit hole why I've gotten the e-mail in the first place.

Last year, I've wanted to test out Bookings. Bookings is a neat tool for companies to book time with employees for all kinds of appointments. It's a direct competitor of Calendly and the like. It's often overlooked, as Office 365 and Microsoft 365 has so many apps included in their licenses. The app is included in practically all Office 365 and Microsoft 365 licenses (even F and Business licenses!).

I tried this out months ago with a page called "Test". Last week, my colleagues were testing out a new e-mail based process and used a bogus e-mail address, like test@example.com. The bogus part did not seem to check out, because I've received the e-mail.

Doing a deep dive into Exchange Online via Powershell, I've found out that a Booking page will be created as a 'SchedulingMailbox' in the backend.

Bit of foreshadowing

And that's perfectly fine - it's based on a calendar that you can use to interface with calendars of employees and book appointments when they are (made) available. What Microsoft does not tell you, is that e-mails that are sent to that mailbox are forwarded to the creator of the Booking page.

To make it even better, you'll get FullAccess rights to the mailbox too! More foreshadowing

This was a 'aha' moment for me, because this opens up a few attack vectors for a malicious actor with a existing foothold in an organisation (Valid Accounts: Cloud Accounts (T1078.004)) to move laterally or escalate to privileged accounts through 'Internal Spearphishing' (T1534) or (theoretically) e-mail alias takeover¹. Using an internal domain (with internal security policies²) will give phishing campaigns more authority and an increased chance of success. This could also give

---

Proof of concept

After trying out different names, it seems that you can use an underscore (_) as a separator. I've settled on "Windows_Upgrade_Team". After changing the From-address in Outlook on my compromised user, I'm ready to phish some users!

Sorry, dark mode readers

Microsoft Administrators are probably not happy to see that any user effectively can create a shared mailbox with forwarding to their e-mail address. Using E-mail hiding rules (T1564.008), this should be hard to detect for the compromised user (if they are even logging in). Unfortunately, blocking bookings from outside of your organisation does not help:

Just to drive the point home - here is the mailbox opened in Outlook Web, with many (if not, all) functionality working like a normal (shared) mailbox.

Mitigations

As the Bookings app grants access to an unlicensed, but FullAccess mailbox, you would want to limit access to Bookings via a mailbox policy (see this Learn article), or by only turning on the service via licensing for a subset of users. If a user is not able to create a Booking page, it should not be able to create this kind of mailbox.

It's also recommended to audit mailboxes of the type SchedulingMailbox regularly, to make sure there is no abuse going on, like you do with Groups (right...?).

Responsible disclosure

I have contacted Microsoft about this through the Microsoft Security Response Center (MSRC), to disclose the vulnerability. Although a user can receive mail from a self-created address by a Microsoft 365 Group, it's not possible to send mail from that address without an administrator granting permissions to them.

This was done on the 4th of february. A case was made, but on the 13th of february, this vulnerability was not severe enough to warrant a fix and was dismissed. On the 18th of february, I contacted MSRC again to double check my findings (including a different, more clear explanation). I have not received any response after that.

On a personal note...

Although this is not a big issue, I am a bit disappointed in Microsoft for the handling of this vulnerability. Looking this close onto Bookings, the permissions seems to be configured way too broadly³. The 'Secure Future Initiative' seemed like a great plan from PR leadership to bring the security tooling that they are selling internally, but the initiatve does not seem to have tricked down yet.

---

1. This is similar to a domain takeover, where a forgotten e-mail address previously attached to a mailbox of an employee that left, is now up for grabs again. This address can be found though 'Reconnaissance' (TA0043) via internal or external documentation of the organisation. Very far fetched, I know, but a man can dream. ↩

2. During assessments and consultancy work, I regularly see policies for Exchange Online Protection and Microsoft Defender for Office 365 less restrictive for internal e-mails than external. ↩

3. For instance, I am not seeing directly why a user needs FullAccess to the mailbox. Just speculating, but the Booking page could be used as a data store for the Booking page (and it's contents). The e-mail forward seems totally unnecessary, as the 'reply-to' has been set up in the e-mail. ↩