Exposing the secret Office 365 detailed activity logs and forensics tool | Hacker News Reader

Exposing the secret Office 365 detailed activity logs and forensics tool

lmgsecurity.com

317 pointsfanf237 comments

I looked at the API calls on the CrowdStrike blog post and I have been using parts of these API's for calls in PowerShell for at least the past year for tracking down issues we have had in Office 365. I can understand how frustrating it can be if your competitors seem to have "secret knowledge". However that knowledge may have been gotten by calling up the very helpful people at MS support, laying out the problem and they send you a Powershell script in return.

I couldn't agree more. Why is the API not public? Is it because some sort of top secret corporate conspiracy? Or is it that management just decided to avoid the burden of publishing and maintaining an immature or lesser used API? After reading your comment that whole article seemed a little sensationalist

> just decided to avoid the burden of publishing and maintaining an immature or lesser used API

"Burden" is an understatement. Any API Microsoft documents becomes part of their ongoing commitment to eternal backward-compatibility. (Heck, even some things they never document at all still end up forced into that commitment, like the internal registry hives in Windows 95.)

So Microsoft do everything they can to only document what they're absolutely sure they have in a good, stable, "won't regret later that we didn't fix it some more before setting it in stone" state.

While that may be true for the Win32 APIs, it is certainly not true for their cloud-based products. They’ve had some very poor APIs for Windows Live Mail (predecessor of Office 365 for education) which were also quickly deprecated and replaced.

They could just flag it “volatile”, “unstable” or something. It’s very unlikely that Microsoft did not properly document the api internally and as you see it’s leaking out anyway.

If you'll ever develop a single simple API you'll find out that doesn't work at all. People will use unstable APIs and people will blame YOU and only you when they break.

Exchange WS and Lync/Communicator would disagree with you re: eternal backward-compatibility.

There are a lot of reasons that it might not be public, but a conspiracy is quite low on the list.

My guess is that it's due to one of the following:

* The API isn't considered beta yet. * This was created as somewhat of a side project and hasn't been formalized yet. * Documenting it is on the backlog. * It's meant for internal use in that they may be building in tools in the Security and Compliance center that will be calling it.

This is absolutely not true. I called O365 yesterday (well, they called me at my request) to investigate a potential data breach. All the guy on the phone could do was to read to me out of a technicians manual and then suggest I purchase the Azure Active Directory P2 plan at $9/user/month.

There is a blog post from 2015 about an API for security and compliance motoring. https://www.microsoft.com/en-us/microsoft-365/blog/2015/04/2...

I respect that fact that CrowdStrike and others have spent the time with the api and made life a lot easier for others. As someone who has spent more time than he wanted with the Office 365 API I am a fan of people who make my life easier. That being said I am not buying the drama that these API's have been hidden.

...which is fine if MS hands out the Powershell script to all who ask.

> It was as if Alexander Fleming had discovered penicillin but kept the details hidden in order to make more money. It just seemed wrong.

Because your right to make money is equivalent to other people's right to remain alive.

I don't think there is a right to compel others to unlimited spending to keep you alive. Sure, pencilin is comparatively easy to grow and hopefully you live in a country with universal healthcare that covers it, but if it were some more expensive substance that can't be covered the analogy holds.

Is this API exposing keystroke timing for search queries, which can be used for biometric profiling of authorized users (and attackers)?

I'm not exactly sure why a new tool is needed. Everything necessary is found from the referenced Crowdstrike code at https://github.com/CrowdStrike/Forensics/tree/master/O365-Ou...

> The tide turned on Friday, June 8. Out of the blue, an email popped onto the forensics community mailing list. It contained a single link, to an Anonymous video.

All that video said was "the API you seek is called Activities". Am I missing the joke, or is the name of the API literally the only thing that they needed to get this working?

I've not delved into the code, but typically a lot of APIs when called without any parameters can return an XML page containing the schema of what it can do. So yes, it's totally plausible, that if you already knew how Office 365 APIs worked, all you needed was the name of the unknown API.

Could anyone ever honestly believe this data was not logged by Microsoft??

I'm at a loss for words, really.

I am at a loss for words that you honestly believe some people didn't think or assume it was logged.

This is similar to Azure activity logs - in that they do not provide you log access to "read" actions.. only write/delete ones. However, Azure actually DOES keep those read ops logged. Though I guess, it's not similar in that: Azure still doesn't have an API to fetch them.. not even an undocumented one.

If an API is undocumented, how can you know that it doesn't exist? It might very well exist for internal debugging purposes, just not at the URL you might expect. Or maybe it's at the expected URL but returns 404 to everyone whose access token isn't flagged as an employee in the appropriate department.

As someone who relies very heavily on logs to debug issues in immature and/or fast-moving products, I would be surprised if they didn't log everything. It's sysadmin 101.

In the modern era, you should expect that the privacy policy contains the details of everything that's logged. You need to know that so you can tell your customers what is logged by your subs.

> In the modern era, you should expect that the privacy policy contains the details of everything that's logged.

Perhaps corporations with a history of abusive tactics and legal shenanigans, would prefer to follow a different path?

What a naive / handwavey response. It's clearly not a case of "oh, we never finished up cleaning up the API for use in production" - it's a case of "here's a secret backdoor that we're only going to share with a privileged handful of powerful corporations"

Is this about the whole Office 365 suite including all apps like Word, Excel, etc. running locally or only about Office 365 mailbox accounts? If it is the latter, could the title please reflect this?

So is there a secret tool? Or is this just an undocumented API call that people are only now finding out about?

It's a secret tool that uses undocumented APIs :)

Ahh nice, well the cat is out of the bag now

This makes me wonder how many other APIs rely solely on obscurity to protect major features.

I don't know if this is to protect so much as it's an undocumented and immature API so they never made it public and kept it for internal use only.

Even if that is true not letting forensics specialists know that those logs existed when critical security events took place is very much a problem. But it gets downright shady when only a handful of companies have them while others are told they do not exist.

Basically all of them.

So in the video linked to in the first paragraph: anon says "while the rest of you... still use shitty Perl and have no hair". Lulz indeed.

<sigh>

And now that it is public knowledge...Microsoft has killed access to these logs.

Did not know, wow.

I had to laugh at the line "still use shitty perl" in the video...

All this Facebook-bashing in the recent months and then m$ office is spying on everything you do. This is like a "legit" keylogger, which is activated per default, because it's a product feature. But, you have to trust it also per default, it seems. Damn.

Reply on news.ycombinator.com