Severe Office 365 Token Disclosure Vulnerability - Research and Analysis

I’ve dubbed the attack I’m about to describe as an “Ice Dagger”, i.e. the perfect weapon. The vulnerability we’ve found and the security incident that used it have all the makings of a great crime mystery. Only through months of diligent research were we and the Microsoft Security Response Team able to piece together the elements of what might otherwise have been a perfect crime, totally invisible to existing perimeter and endpoint protection defenses.

Our story starts in April 2013. One of our customer nodes analyzed an HTTP request that triggered a “high risk” heuristics alert. While we talk about our heuristics engine at length on our web site, most of our documentation is about user behavior heuristics,  so before disclosing the vulnerability, I wanted to explain other types of heuristics we have in place. These are similar to the logic behind our behavioral standard deviation algorithm, but focused on applications doing unusual things.

In this case,  we saw Word 2013 requesting a document from a TOR hidden service under the TOR gateway. While we monitor and flag all requests performed against known TOR gateways, this specific request was performed by Word itself, rather than the user. These factors combined marked this event as a “high risk alert” and escalated it to our Adallom Labs research team for further review.

Upon reviewing the metadata of the request, we noticed that its response had a WWW-Authenticate header with RootDomain=””, even though the request obviously wasn’t for a domain. At this point we started assessing the situation and treating it as a potential data theft.

We started by tracing the request: what computer executed it, what employee was using it at that moment and what was he doing. With the help of our customer we eventually got to an email which was sent to that employee, luring him into opening a Word document stored on a TOR hidden service. The mail was written specifically for that employee in what seemed like a very targeted attack. Due to our client’s industry sector and high profile we are unable to give any specific details regarding this attack beyond its mechanics.

Suffice it to say, the referenced TOR hidden service was no longer available when we tried to replay the request in-order to analyze it further. The only lead we had is the request metadata that our platform logs for flagged requests.

This was the starting point for our research. Our goals were:

  1. Discover and assess possible loss of our customer’s data
  2. Research new attack patterns and unknown vulnerabilities
  3. Improve our detection and prevention heuristics and improve the security of our clients

Our approach to security research is a holistic – drilling down layer by layer, sometimes going as far as ignoring clues we already have just to make sure we’re not predetermined about which way to go next.

Let’s dive in.


Imagine you’re an employee.

That’s probably not too hard.
You’re working days, working nights. Doing your thing. Using your mail. Surfing the web. Watching some Breaking Bad episodes.

In your line of work, like most white-collar people, you work with documents. It’s not a question of “if”, it’s a question of “when”.
Whether it’s a memo, price quote, some product manual, someone’s CV, technical documentation or patents.

Your company is an Office 365 Enterprise customer, and that makes you one as well. It comes with lots of perks and goods but the highlight is access to four very useful Office 365 products:

  1. Exchange Online (hosted email service)
  2. SharePoint Online (document management and collaboration)
  3. SkyDrive Pro (file storage service)
  4. Office 2013 Desktop desktop applications (Microsoft Word and friends)

You probably think you know what Office 2013 Desktop is.

Don’t be so sure. It’s a whole new animal. Office 2013 Desktop was designed from the ground up to integrate with cloud services and specifically designed to integrate well with Microsoft’s cloud platform – Office 365. It is fully integrated with SharePoint Online and SkyDrive and if you want to use any of these services you have to be signed in. It’s a requirement:

  1. If you downloaded your Office 2013 Desktop installation from your Office 365 account page, the applications will be automatically signed in upon installation with your Office 365 credentials (presumably for licensing purposes).
  2. To view or edit documents in SharePoint Online or SkyDrive documents with your Office desktop application it has to be signed in with your Office 365 credentials.

And there’s also reminders to sign in built-in to the product:

  1. In case you’re not signed in, this is what the corner of the window looks like:
    Office 2013 begging you to sign in
    Office 2013 Desktop reminding you to sign in
  2. And if you’re saving or opening a file:
    Office 2013 Save As dialog
    Office 2013 Desktop Save As dialog


Eventually if you’re using SharePoint Online or SkyDrive, you have to sign-in. This is what it looks like:

Office 2013 signed in
Office 2013 Desktop signed in


So you’re signed in. Great!

But what does it mean to be signed in? How does SharePoint Online or SkyDrive know that our Word is signed in? Let’s follow the common usage flow and discover. For the sake of discussion let’s assume we have a SharePoint Online site at .

  1. You have this SharePoint document that you want to edit in your Word application. You go to your SharePoint site and you click on the “Edit” button in SharePoint Online, just like this:
    SharePoint Online document edit button
    SharePoint Online document edit button
  2. The user is asked if he wants to allow the website (SharePoint Online) to launch Word through a special protocol handler called “ms-word”:
    Security dialog for launching Word documents from SharePoint Online
    IE’s security dialog for launching Word documents from the web. This dialog varies between browsers but it is generally similar.

    Pressing the Allow button will launch Word. But first, let’s start up Fiddler so we can figure out what goes on from this point.

  3. The first request we see is Word making HTTP OPTIONS request to the folder of the document we’re going to edit:
    Connection: Keep-Alive
    User-Agent: Microsoft Office Word 2013 (15.0.4505) Windows NT 6.1

    And the response is (note that I’ve filtered uninteresting headers):

    HTTP/1.1 401 Unauthorized
    X-MSDAVEXT_Error: 917656; Access denied. Before opening files in this location, you must first browse to the web site and select the option to login automatically.
    WWW-Authenticate: IDCRL Type="BPOSIDCRL", EndPoint="/_vti_bin/idcrl.svc/", RootDomain="", Policy="MBI"
    Content-Length: 0
  4. So, basically, SharePoint is asking Word to authenticate and even sends it a hint (the WWW-Authenticate header) as to how to authenticate. This triggers Word to begin an authentication process with its Office 365 credentials.
  5. The first step in this process is a request by Word to (IDentity Client Runtime Library service), as pointed by the WWW-Authenticate header, with an authentication token that represents your Office 365 credentials:
    GET HTTP/1.1
    Connection: Keep-Alive
    Authorization: BPOSIDCRL t=EwBw...b6IB&p=
    User-Agent: Microsoft Office Core Storage Infrastructure/2.0

    Word gets a cookie named SPOIDCRL it can use when accessing SharePoint Online. 

    HTTP/1.1 200 OK
    Set-Cookie: SPOIDCRL=77u/P...vU1A+; path=/; secure; HttpOnly
    Content-Length: 0

    By the way, the cookie we got is a simple Base64 containing the following:

    <?xml version="1.0" encoding="utf-8"?>
  6. Now, Word, satisfied that it authenticated successfully, goes on to retrieve the document and they live happily ever after.

..but wait, there’s more!

Help! Cue the header police!

A very interesting header that definitely stood out during this authentication process is the WWW-Authenticate header that Word received in the first response (step 3). It looks as if this is the trigger to Word’s authentication mechanism. Let’s go over it:

 WWW-Authenticate: IDCRL Type="BPOSIDCRL", EndPoint="/_vti_bin/idcrl.svc/", RootDomain="", Policy="MBI"

Since interesting headers are good for the soul I started fiddling with the fields in this header. Playing with the EndPoint header has led me nowhere so I moved on to the RootDomain header. When RootDomain was set to any domain other than “”, Word would not send its service token and would give up on the authentication.

But what happened if I got Word to open a so-called “SharePoint Online document” from a malicious site? Is it possible to fool Word into thinking that my malicious website is SharePoint Online and thus getting the user’s Office 365 token?

Chasing pavements

To test this theory I wrote a really simple web server that plays back the same responses that SharePoint Online gives to Word during the authentication process, leaving the WWW-Authenticate header as is – with RootDomain=””. I set it up under a domain name which had no relation whatsoever to, started the web server and fired up Word using the same “ms-word” protocol handler – in order to imitate the same way that SharePoint Online launches Word, just in case there were any flags I couldn’t understand in the URL (ofe|u anybody?):


I was pretty pessimistic while doing this.. I did it just to be able to say to myself that I left no stone unturned. I really had no idea what I was about to uncover.

And then it worked.

Word regarded my web server as the quintessential, and sent its Office 365 token towards my malicious web server, solely based on the this frivolous WWW-Authenticate header that said I was

My web server, programmed to work just like the original SharePoint site, gave Word a cookie for accessing SharePoint and then gave Word the document it wanted. And it was flawless. Invisible. (Gruesome.)

Now, my malicious web server, in possession of your private Office 365 authentication token, can simply go to your organization’s SharePoint Online site, download all of it, modify it or do whatever it wants, and you will never know about it. In fact, you won’t even know you got hit! It’s the perfect crime.

What does this mean?

This means that if I can get you to click on a link to a Word document (for example a link in a mail or a webpage) I can remotely compromise your organization’s SharePoint site without anyone knowing or any alerts being raised.

What would a malicious flow look like?

Who knows? So many possibilities. But let’s walk through a probable scenario:

  1. You get a mail asking you to review a document or visit a webpage. Some ideas: Maybe a document with coupons? Someone’s CV? A price quote? A contract? Obviously at least one employee out of hundreds will read the document.
  2. You click on the link. The web page asks you to open the document in Word, just like SharePoint Online asks you (shown in step 2 above). Because this dialog is so common when using SharePoint Online, it’s really hard to believe anyone will refuse the request..
  3. Word is now requesting the document from the malicious webpage. The malicious webpage asks Word for its Office 365 token and Word willingly gives it. The malicious webpage gives Word a legitimate-looking document in return.
  4. The attacker now has your Office 365 token. You have a document which you will shrug off as meaningless and go on with your day.

Are you sure this works?

Yes. But don’t take our word for it, here’s a video of our PoC:

Frequently Asked Questions

Okay, so you could get into SharePoint Online. What about SkyDrive Pro?

You may be surprised to learn that SkyDrive Pro is actually a SharePoint Online site, so it equally as vulnerable as SharePoint Online itself. It also uses a desktop synchronization utility, but that’s irrelevant to the vulnerability. You can read more about SkyDrive Pro here.

What about applications other than Word?

PowerPoint, Excel and OneNote are also vulnerable to this attack.

What about other versions of Office?

As far as we can tell, only Office 2013 Desktop is susceptible to this attack due to its integration with Office 365.

Could this token be used to log into other Office 365 services such as Outlook Web Access, Office 365 Management Portal?

Great question. I tried to explore this possibility but had no luck. I think the answer lies in the parameters that Word calls LogonIdentityEx() with.. my gut feeling says no.

What’s the lifetime of an Office 365 token?

We haven’t been able to pinpoint the exact lifetime but it is at the very least a few weeks.

Responsible disclosure

On the 29th of May 2013 we contacted the MSRC (Microsoft Security Response Center) and provided them with a copy of our full research. 

The patch for this vulnerability is slated for December 2013’s Patch Tuesday and the vulnerability was assigned CVE-2013-5054 (and discussed in Microsoft Security Bulletin MS13-104).

During this period we worked in cooperation with Microsoft in-order to reproduce the bug and evaluate methods for closing this vulnerability.


Sadly there’s no workaround for solving this vulnerability that doesn’t impair work with SharePoint Online. Please apply the Microsoft patch as soon as possible.

Lessons learned

Things that should have been done better and could have mitigated this vulnerability:

  1. The RootDomain parameter in WWW-Authenticate should be verified against the SSL certificate of the current connection and against the requested host.
  2. In any cases where Word gives out a token to a web site it has to be signed and limited to that specific web site.



A Perfect Crime

The vulnerability we researched here and the security incident that used it is a bona fide Perfect Crime; a crime where the victim doesn’t know that he’s been hit; a crime where there’s no proof of any foul play anywhere; a crime where protecting yourself against it without being familiar with its modus operandi is next to impossible.

There was no malware payload to reverse-engineer. No file hash we can trace through time. No IP address to locate and investigate. No servers to confiscate. The attacker simply gets away with your Office 365 token. For good. This is important in the context of understanding the limitations of your existing endpoint and perimeter defenses in the context of SaaS applications and cloud services. Our goal at Adallom is to help extend your operational purview and protection to SaaS applications themselves rather than rely on endpoint agents or network appliances.

I hope you found this description useful. It should be noted that the Adallom Labs team is currently under responsible disclosure with a different enterprise SaaS vendor on another vulnerability as well as some targeted malware we’ve found in the wild. We expect to be able to write about those in the February timeframe.

32 thoughts on “Severe Office 365 Token Disclosure Vulnerability – Research and Analysis

  1. One minor edit: In step 5 of the “So you’re signed in. Great!” section, you reference the cookie name as SPIDCRL, but your snippet of the headers show it as SPOIDCRL. A small mistake that I’m sure will confuse no one who understands what you’re talking about, but I thought I’d point it out.

  2. Have you considered how an Office 365 service configuration using ADFS changes the exposure? Thanks for a well written findings summary.

  3. Hi Noam,

    Good day. As I understand that there’s a patch already in place to address this issue, is there still a need to install Federation Server Farm Using SQL Server ( token replay detection ) by which should address token replay?
    Your comments is greatly appreciated, thank you.


Leave a Reply

Your email address will not be published. Required fields are marked *

Ready To See Adallom In Action?

We can help you prevent modern attacks, comply with government and industry regulations, as well as monitor, and verify the endless human interactions with SaaS applications.

Request Demo