MDR for Microsoft 365 Progress Report #2

Now that we've plowed through the end of year holidays, it's time to give another update on some of our progress on enhancing the MDR for Microsoft 365 product. Again, this does not encompass all of the work that the team has put into the product. These are simply the highlights.

When we identify a malicious inbox rule in Microsoft 365, we queue up a remediation task to disable or delete the rule. In some cases when we tried to delete the rule we would get back an error that the specified inbox rule didn't exist. This was an issue on our end where we weren't correctly identifying the unique rule ID in some cases. This has now been fixed and we're successfully remediating malicious inbox rules.

There are several steps required to configure Microsoft 365 to forward audit logs and any issue with any of the steps will cause the logs to never start or to stop even after they have been sending. We've identified some race conditions in the way we were executing the setup steps that could some times cause a failed setup and we're addressing those. We also beefed up our detection and monitoring so that we can identify when the necessary configuration is no longer working causing us to stop receiving logs. This only affects ~5% of our mapped tenants and that number keeps dropping as we work through the issues.

In the last report, we noted that we had started to include Spur.us VPN data to enrich the events we are receiving from Microsoft, and the results of the last 2 weeks have shown a significant increase in the number of successful detections of anomalous logins. This isn't the only indicator we're using to try and detect account takeovers, but is an indicator with a unique perspective. This serves to detect what a lot of folks generally refer to as impossible travel. Attackers generally use a VPN to disguise the source of their traffic so they are less likely to be shut down. Combining the use of a VPN with unique or uncommon geographic locations and other indicators allows us to better identify anomalies without flooding our SOC with false positives.

One of the more "interesting" things we've found while working with the event data from Microsoft is that in a lot of cases the identity of the user who initiated the action isn't clear unless you're a computer. For example, user login events (success and failure) have a field for the users UPN (unique identifier, usually their email address). This is the more human-friendly identifier for a user. Ideally you would be able to search for events with the users UPN and find all of the events. Unfortunately the reality is that this field is often not filled with a real UPN and instead has the value 'Not Available'. We don't know why this is the case, but it's how Microsoft is logging these events. The problem with this is that if you were to search for events using a users UPN, you wouldn't get all of their events because some aren't correctly associated.

Fortunately there is another field in these events that designates the users GUID (Globally Unique IDentifier) in the UUID format. These are not human-friendly. Based on this we've added some enrichment steps to our event processing that will identify when an event is not correctly associated to a user and will lookup the user based on their GUID so we can correctly identify the UPN, or human-friendly ID. This allows us to better identify all events for a given user using the human-friendly identifier. This is one of those capabilities that is necessary for accuracy, but not default functionality for SIEM solutions that are simply receiving logs from Microsoft 365.