Archivo para la categoría ‘Security’

Multi-Factor Auth inside Office365

viernes, 21 de febrero de 2014 Sin comentarios



Hi, todays article is about Multi-Factor Auth for Office365.

First of all, lets explain what is it, what are the benefits and then proceed to explain how to enable, configure and manage it via GUI and PowerShell…


Multi-Factor Auth is a multiple validation system that allows us to fortify the security when accessing out system, but not just that, it also allows us to know when someone is trying to access our data and be able to notify as fraud the undesired access. All this with the smple use of an SMS code, telephone call, mobile phone call or via APP.

So, does that means that I will have to input a code each time a access my mailbox?, not exactly, unless you select the send message or call options, our installed APP will be the one in charge to notify us of the access petition and be able to answer if we authorize or decline it.

And what happens with each program on which a make use of my account, will I have to authorize them each time they try to access my data? no, we have the option to configure a unique «APP Password» for every program with a unique activation.

Does that means I can create as many APP Passwords I want? No, we have a 40 APP Passwords limit.

What programs can I use with my APP Password? We can make use of known programs like Microsoft Outlook, Microsoft Lync, Office 2013 suite, and some others like Lync mobile client, Windows 8 and 8.1 Mail APP or the Office365 Activation assitant.

What is the name of the APP that I can use to authenticate the access? The APP is called «Multi-Factor Auth» and it’s available for IOS, Android and Windows Phone of course, just search for it on the store.

Is this feature available for all of the Office365 plans? No, just for MidSize, Enterprise (E1, E3 and E4) and Standalone (Exchange Online and Sharepoint Online) plans, so no Small Business plans are supported.


To enjoy this feature we just have to enter our Office365 portal as an admin and enable it for the users we want:

  • Enter our Office365 portal ( as an admin and click on «Users and Groups» and then on «Set up» dentro de «Set Multi-factor Authentication requirements»:


  •  On «View» select the view to be applied of the users we want to be shown, in my case I selected «Sign in allowed users«:


  • Select the users we want to enable and click on «Enable» and «Enable multi-factor auth» on the popup window:

0auth3 0auth4

Once the admin part is done, we can now proceed to do the user part. This is what the user is supposed to do once he enters the first time to the portal. It’s very important that the user logs in onto the portal before doing anything else with his account.


  • This will take us to the aditional security verification page, select the option we want and continue, on this case we will select «Notify me through app» and then click on  «Configure«:


  • Follow the steps and click on «Done«:


  • Once this is done, t will ask us if we make use of programs like Microsoft Outlook or Lync to create APP Passwords, in this case we will assume the user makes use of Microsoft Outlook, so we’ll create one clicking on «Create«:


  • Assign a name for the program, copy and paste the generated code inside the credentials request of our Microsoft Outlook. This password will not be shown again so it’s important to copy and paste it directly :


  • If we have the need to create more APP Passwords or modify the contacting method, we just have to enter our portal, click on the little hog on the upper right side and then on  «Office365 Settings», select the option «additional security verification» and click on «Update my pnone numbers used….», this will give us access to the settings and APP Passwords configuration area:


auth10 auth11

Auth9 Auth8.19


In order to work with Multi-Factor Auth, we must follow the next steps:

Connect-MsolService $MultiFactorAuth= New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationRequirement $MultiFactorAuth.RelyingParty = «*» $MultiFactorAuth = @($MultiFactorAuth)

Once the object has been created, you can start running the different options:

  • To enable just one specific user:

Set-MsolUser -UserPrincipalName -StrongAuthenticationRequirements $MultiFactorAuth

  • Enable on all users:

Get-MsolUser -All | Set-MsolUser -StrongAuthenticationRequirements $MultiFactorAuth

  • List all users with the enabled feature:

Get-MsolUser | Where-Object {$_.StrongAuthenticationRequirements -like «*»}  | select DisplayName,UserPrincipalName,StrongAuthenticationMethods,StrongAuthenticationRequirements

  • Disable the feature on a specific user:

$MultiFADisable = @() Set-MsolUser -UserPrincipalName -StrongAuthenticationRequirements $MultiFADisable


Just one thing, If we enable this feature on an admin account, keep in mind it wont be able to manage the subscription via PowerShell because its not supported, to do so, Microsoft recommends to create another account without any license applied and strong password to be used for powershell.


Once we try to log in via the portal, it will show us a notification on the app where it asks us to verify or cancel:

wp_ss_20140217_0001 wp_ss_20140217_0002 wp_ss_20140217_0003



Hijacking Office365 sessions with “Dead” Cookies

lunes, 2 de septiembre de 2013 Sin comentarios



I’ve been investigating for some time the security that Microsoft Office365 platform is offering and what are the weak points that may be when working with our data on the cloud, analyzing the communications being carried out with the use of sniffers, different browsers and operating systems (including Windows 8.1) as a workstation role. So today I’ve found out an article about this that really got my attention written by Ms. Smith, attractive enough to put it to test right away.

Session Hijacking: The theory

Normally whenever we access a web service with some user and password, one or more cookies are stored in our PC, allowing the access to that web service without introducing the credentials again by saving them into it, so the system understands there’s no need to identify yourself again because you’ve already done so.

So what happens if someone gets his hands on those cookies? Well it’s simple, if the status of those cookies are alive, then he could make use of the users session inside that web service without needing not even a single password. A few popular examples of these are FireSheep in Tuenti, or Facebook Apps binary cookies. Besides the problem is when these cookies get the status of «dead» without being totally dead, leaving the session open even after the user is logged off the web service, as we saw in the famous LinkedIn cookies case. Well Microsoft’s Office365 is not an exception and can be hijacked with a stolen cookie even after the user has logged off.

Microsoft Office365 session hijacking: PoC

Following Ms. Smith article, I decided to use a Windows 7 workstation and install Google Chrome browser with the «Edit my cookie» plugin. Once installed I logged in to my Microsoft Office365 portal using Chrome:


Once I was inside, I clicked on the upper right cookie button and selected «Export Cookies«:


Then opened a notepad and pasted the info I’ve exported with the cookie info that holds the Microsoft Office365 session:


I saved it as a txt file on my desktop and logged off my Office365 session, until now that session should be killed already so even If a wanted to, I couldn’t access to my info again.

So I got another workstation running (this time with Windows 8.1) and pasted to the desktop the txt file:


I also installed on this machine the Google Chrome Browser and the «Edit my cookie» plugin, and browse to the Microsoft Office365 login page. Once I’ve got there, I clicked on the upper right cookie button and selected «Import cookies» and saved changes:


Once the process was done, y entered again the same Microsoft Office365 login page by retyping the URL on the address bar without closing the browser, and there it is! I got it to all my info, without entering a single letter of my password.



How to mitigate the cookie stealing inside Microsoft Office365:

Getting a Microsoft Office365 session cookie needs another combined attack, like accessing local files locally, cheating a user for getting into a Man in the Middle scheme or finding a client-side vulnerability that enables you to access the cookie. It’s not that easy but it’s possible though because of the behavior of the cookie as it should be killed totally when logging off to mitigate this problem. On Raul Siles article about Session Management Cheat-Sheet we can find some security measures that should be applied to session cookies.

Microsoft has confirmed they’re working on it to fortify security of sessions, but meanwhile make sure you’re cookies are not held by other hands, so I recommend to always clear your browser cache and make use of the Internet Explorers In-Private functionality (Ctrl+Shift+P) as this allows the no use of session cookies to be stored on the local PC.