Sharing is Caring - The Secret O365 API

The whole field of DFIR thrives and survives on shared research. Professionals who identify novel techniques or develop tools which they share outside their organisation help to drive progress, achieve better understanding and ultimately help the community in the arms race against bad actors.

A recent example which brought this to mind (and prompted this post) is the release of details regarding the Office 365 Activities API as detailed in this post by CrowdStrike.

What will likely follow is a rambling post about information sharing in DFIR so if you are here for technical details you are in the wrong place, check out the CrowdStrike writeup which is detailed and informative.

Business Email Compromise (BEC)

With the introduction of Outlook Web Access and even moreso since the increased adoption of Office 365 (and GSuite) for cloud email within businesses, Business Email Compromise (BEC) has been a growing issue. Over the last 6 years I have been involved in the investigation of many dozens of such incidents. Unsurprisingly, these cases have a tendency to merge into one in the memory but a few have stuck out over the years.

The most significant was the first case I investigated, the customer suffered a compromise of a number of GSuite ('Google Apps for Business' at the time) email accounts, following which executive impersonation was used to defraud them of c1.25million Australian Dollars. The money was wired out by a duped finance employee in a series of transactions as is a common theme in these kinds of compromise. This case was notable due to the certainty with which the customer insisted that it must be an inside job, sure that disgruntled IT staff must be behind it. The client's insistence that we investigate their hunch as a priority, coupled with the limited logging available in Google Apps for Business made for a difficult investigation.

Another especially notable case was in mid 2016 where a a large organisation had suffered a multi account compromise. During the incident the attacker(s) used compromised accounts to phish other internal accounts (another common MO in BEC) eventually resulting in the attacker gaining access to the accounts of senior staff. We were employed to conduct the investigation and the client had already engaged with Microsoft who as it turns out were in a particularly helpful mood that day. There was nothing to set this case apart for the multitude of O365 breaches I had investigated during that time, other than the additional visibility Microsoft were able to share into mailbox account activity.

The client had not enabled any of the available (but off by default) auditing within O365 and AzureAD however as their MS account rep put it, Microsoft may be able to assist but they would need to run queries in their big data system to get some logs. Don't judge too harshly, it was 2016, 'big data' was all the rage. Lo and behold a couple of days later they produced logs per impacted mailbox which contained unprecedented detail on what messages were accessed, searches run as well as login event information. This information is invaluable when investigating cases of BEC and in this case the motivation of the attacker was clear very quickly. Each mailbox was searched for a series of keywords (e.g. bacs, wire transfer, international payment etc) and no other information had been accessed where no hits were returned the account access ceased or the account was used to target other users.

Since then I have encouraged clients to make similar requests to their Microsoft account rep in an effort to get these same logs, especially in cases where all other logging was not enabled. These requests have received inconsistent and commonly unsatisfactory responses especially where the customers were "small fry" tenants with users in the 1000's rather than 10000's. With that said, from time to time customers requests were met with the delivery of logs, and where provided the logs were generally of a consistent format. What I didn't know at the time was that the output we were being provided was associated with the 'Office 365 Activities API' and that it is available to all O365 users irrespective of enabled logging (at least for now) [edited 2018-07-08: The Activities API appears to have been locked down and is no longer available at this time].

The 'Secret API'

During DFIR conferences, at talks and on Twitter, the topic of the 'Secret API' has arisen from time to time. It was evident that access to this information was possible and that a number of individuals and organisation had decided to keep this to themselves in an effort to maintain some sort of competitive advantage. The existence and functionality of the API had been kept quiet by those in the know and I have heard that some SIEM vendors and IR consulting firms have boasted to prospective customers that they had abilities that their competitors did not, as it relates to investigating or integrating with O365 logging.

In this case, and in other similar examples I feel this poses an interesting dilemma to anyone who identifies similar novel analysis methodologies. Personally I feel those who declined to share the information did so at the detriment of other victims. In coming to this conclusion I have considered the following:

DFIR survives on shared research. The reason I started this blog was in recognition of the fact that I have benefited from the research and efforts of others who have investigated artifacts and publicly disclosed their findings. We need to see beyond short term commercial gain in the shared battle against bad actors.
I can't imagine that the 'competitive advantage' these organisations benefited from could be all that significant. Clearly it was being touted enough that it was being used to try to win business but do prospective customers really buy into these claims when so often they are only marketing hype?
It is possible that this information becoming public may cause Microsoft to close down the API prematurely. This is the only defensible justification I can see, I appreciate that widespread disclosure may have (and still may) cause this to prematurely vanish. It isn't lost on me that the CrowdStrike post comes at a time when a number of firms had intimated that they may publish something and indeed a time when the findings have a limited shelf life, as it would appear the API is set to be EOL in 2019.
There is also the risk of a "If other firms aren't sharing, why should I" mentality and I can appreciate this. I've worked in firms where research is seldom published and as such I was part of that problem. In 'listen only' mode some organisations will leech up the work of others while holding tight to their own original research. The answer however is not to close off but rather lead by example and lay rightful praise at the feet of our competitors when they do good research, share findings and further the DFIR/Infosec community as a whole.

To that end I think credit should be given to CrowdStrike for making the decision to share this information with the wider community while other organisations who were evidently 'in the know' did not. They are by no means unique and fantastic work is constantly being published by loads of firms in the field.

I would be interested to hear other peoples take on the topic of sharing research and findings which might otherwise offer a competitive advantage, clearly one size doesn't fit all but are there other considerations which I haven't detailed above?