A Chinese hacker’s intrusion though a US government Microsoft 365 account is a wake-up call to review your current logging stance.
Sandwiched into the same day that Microsoft announced the rebranding of Azure Active Directory to Microsoft Entra ID, and on the day the company announced it was tracking an Office/HTML zero-day vulnerability for which there was no patch available, the company also dropped a bit of a bombshell: A Chinese attacker had targeted some of its customers in the US government.
Using a stolen customer Microsoft account signing certificate, the hacker spoofed the authentication process to obtain access to government mail accounts. How did Microsoft determine that there was a problem?
It didn’t. The red flag was raised by the government customers who had paid for premium logging capabilities and were able to track who accessed the contents of their mailboxes. The situation highlighted the huge importance of logging and knowing what logging functionality comes standard and what is offered through premium services.
First, a bit of history. Years ago, there was an API that researchers found that would track account activities and would expose who had gained access to a mail item. In a business email compromise, you could determine whether an attacker had obtained access to your network, but you often didn’t know whether they opened or had access to certain information or if it merely looked like they had.
Once this information came to light, researchers built a tool that would expose this information. It was stated at one time that Microsoft was planning to release the so-called “Magic Unicorn” tool that would allow detailed tracking of Office 365 mailbox activity and make it public.
Fast-forward a few years and a few name changes, the API that exposed the ability to know what an attacker did was added to Microsoft 365 in the form or licensing at the E5 or G5 levels. The MailItemsAccessed mailbox auditing is now licensed to those who have premium Microsoft 365.
Fortunately for the rest of us, this logging was in place when the Chinese attacker accessed Exchange Online. The logging that was available in that version of Exchange Online allowed them to know that the attackers had been in the system.
As noted in the CISA documentation, “An FCEB agency observed MailItemsAccessed events with an unexpected ClientAppID and AppID in Microsoft 365 audit logs. The MailItemsAccessed event is generated when licensed users access items in Exchange Online mailboxes using any connectivity protocol from any client. The FCEB agency deemed this activity suspicious because the observed AppID did not normally access mailbox items in their environment. The agency reported the activity to Microsoft and CISA.”
It has come to light that the attackers somehow gained access to a consumer-level Microsoft account signing key that they then used to build an enterprise authentication token. Microsoft has since revoked these keys and put in place an infrastructure to ensure that consumer-level access can’t be used to forge authentication to Enterprise assets. It also appears that they will be reviewing additional processes to ensure this doesn’t happen again in the future.
This has also pushed Microsoft to take the bold step of ensuring every customer has this level of logging available without having to pay for a premium level to gain access. The ability to know whether you truly had a breach is a key element of any service and should not be limited to those who can pay for such levels of information. On July 19, 2023, Microsoft announced that it will be phasing in access to wider cloud security logs for worldwide customers at no additional cost.
Microsoft will begin rolling out these logging enhancements starting in September but there are ways you can get access to these log files now and evaluate their information in the meantime. First, use a trial: if you think you’ve had a breach and do not have this licensing in place, you will still want to be aware that the logging is available so you can then sign up for a trial.
As Microsoft itself advises: “If you’re not an E5 customer at this time, use the 90-day Microsoft Purview solutions trial to explore how additional Purview capabilities can help your organization manage data security and compliance needs. Start now at the Microsoft Purview compliance portal trials hub.” Even if you do have E5 for some of your users, be aware that it’s licensed per mailbox. So, for example, shared mailboxes will need either an E5 or a trial license turned on for even shared mailboxes.
Even without an E5 license, you do get some logging events reported to you, such as the principal accessing the mailbox. SP authentication and mailbox access events should be seen in the event logs, but not in MailItemsAccessed until this is added in September.
In an online post, security solutions architect Nathan McNulty points out that even if you do have an E5 license, it doesn’t mean that auditing has been enabled. While logging is now enabled by default, if you are an older Microsoft 365 customer it may not be. Thus you’ll want to proactively review his recommendations especially if you have a mixed environment where some are licensed for E5 and some are not.
Key premium logging includes the following items:
Mailitemsacessed
SearchQueryInitiated
Send
As noted above, although mailbox audit logging on by default is turned on for all organizations, until September only users with licenses that include Audit (premium or E5/G5 licenses) return mailbox audit log events in audit log searches in the Microsoft Purview compliance portal or via the Office 365 Management Activity API by default.
Use a trial version to begin evaluating the logging process. Be aware that there are limitations: specifically that MailItemsAccessed is throttled so events may not be complete. You may have to make inferences as to what occurred and won’t have logs of every individual item access. There are nuances and understanding that you need to ensure your staff are aware of. Thus, ensure lab time is budgeted to properly understand what this new logging will provide in terms of information and resources.
If there is one good thing that may have occurred as a result of the Chinese intrusion is that it has pushed Microsoft to change its stance on logging and include it in every level of Microsoft 365. My recommendation to you is that for any of your Microsoft products, or even any other cloud vendor product, you want to reach out to these vendors and start demanding certain levels of logging and security in all products.
Use this opportunity to reach out to your vendors and review if they can provide you with guidance should an attack on their resources. In the meantime, I would review resources such as benchmarks from the Center for Internet Security that can assist you in the deployment of cloud resources. Finally, review your current logging stance and ask yourself if you would be able to investigate such attacks.
Susan Bradley has been patching since before the Code Red/Nimda days and remembers exactly where she was when SQL slammer hit (trying to buy something on eBay and wondering why the Internet was so slow). She writes the Patch Watch column for Askwoody.com, is a moderator on the PatchManagement.org listserve, and writes a column of Windows security tips for CSOonline.com. In real life, she’s the IT wrangler at her firm, Tamiyasu, Smith, Horn and Braun, where she manages a fleet of Windows servers, Microsoft 365 deployments, Azure instances, desktops, a few Macs, several iPads, a few Surface devices, several iPhones and tries to keep patches up to date on all of them. In addition, she provides forensic computer investigations for the litigation consulting arm of the firm. She blogs at https://www.askwoody.com/tag/patch-lady-posts/ and is on twitter at @sbsdiva. She lurks on Twitter and Facebook, so if you are on Facebook with her, she really did read what you posted. She has a SANS/GSEC certification in security and prefers Heavy Duty Reynolds wrap for her tinfoil hat.
Leave a Reply