Investigating an Office 365 account compromise

I’m starting to get lots of questions about how to determine when exactly an Office 365 account was compromised. Typically, the two most common compromises are phishing and weak passwords. This article is going to focus on one of the ways weak passwords are exploited.

The first thing to appreciate here is that, generally, Office 365 won’t maintain logs needed for detailed investigation beyond 7 days and secondly most logging in Office 365 is disabled by default. There are a number of different audits in the product that you should enable, the major one is Activity auditing which I have detailed how to enable here:

Enable activity auditing in Office 365

The place I suggest you start any investigation is with my free PowerShell Office 365 user login auditing script which I have detailed here:

Auditing Office 365 logins via PowerShell

If you are a CIAOPS Patron subscriber I have an enhanced version of this same script that also outputs the results to a CSV file.

image

The above shows you the screen output of this script. You’ll see successful logins in green and unsuccessful ones in red.

The indication that an account has been compromised will either be:

1. Successful login from a suspicious IP address (indicating phishing and the fact that the bad actors already have the user’s password)

or

2. A number of failed logins to an account followed immediately by a successful login (indicating that the account password has been guessed via brute force).

In this article I’m going to focus on hunting down item 2, as item 1 is tougher, and means combing through IP addresses.

So, what we now need to do is take a look at the CSV file the script generated and see if we can find the login pattern we are looking for.

image

I’m using Excel as my primary investigation tool here as it provides more flexibility than other tools for me.

Firstly, I’m going to insert a table to make querying data easier.

Next, I’m going to filter out my know corporate IP addresses so I am only left with those I don’t recognise. In this case, I’m also going to only focus on a single user. Finally, I’m going to sort the times from newest to oldest.

image

Now what I’m going to do is hone in on an unfamiliar IP – in this case 110.82.6.244. When I filter the file further I find over 85 entries for that IP as shown above. The interesting things is that these entries happen sequentially on the same day and start at 1:16AM and end at 1:35AM. This confirms that my account has probably been the subject of some sort of automated ‘password spray’ attack. This basically means the bad actors have used an automated process to repeatedly try to login to my account using different passwords.

What passwords are they using? There are huge tables out there with all sorts of passwords people like to use. Where did these tables come from? Typically from systems that have been compromised and had all their login credentials stolen. These stolen credentials are now being re-purposed sand used to attack other accounts. Have a look at Troy Hunt’s site:

Have I been Pwned?

if you haven’t already to get an idea of the sheer volume of credentials there are in the wild.

image

You’ll note that in this list I don’t have any filter on the Operation column. Why? Because, I’m look for the pattern of repeated logins failures and THEN a successful login indicating that the account password has been guessed.

Luckily, for this attack IP address I don’t see that pattern. So basically, they tried 85 different attempts over a 20 minutes or so and don’t appear to have gained access. Phew.

image

When I do a lookup on the location of this IP address, I find it is in China.

image

I can do some more investigation by digging into the user account details in the Azure Active Directory service inside the Azure portal as shown above.

Basically I’ve gone into the Azure portal, selected the Azure Active Directory service then select Users and then the specific user I want to to investigate.

From the items that appear on the left for that specific user I select Sign-ins and then customise the search so that:

Application = Office 365 Exchange

Status = Failure

You then need to select the Apply button to update the query. Once I have done this I now get a list of login failures as you can see above.

image

If I select an entry in question (i.e. one from the previous results in the CSV file generated by my script) I see the above details.

The details show it is from the same IP address (110.82.6.244) and that client app in question was SMTP, i.e. the login was attempting to do an email account login.

It is also interesting to note that Microsoft blocked the attack by locking the account because it tried to login in too many times. Thus, Microsoft is detecting this common sort of attack and mitigating it based in the IP address and the repeated attempts from a single IP address. Thanks Microsoft.

image

You can click through the remaining links at the top of the page to get other information.

Unsurprisingly, there is no device info as you can see above.

This screen also gives you the option to download this log information to a CSV directly from the Azure portal for further analysis if you want. Down side is, that it is simply the single user you see here, not across all the users in the tenant.

image

Now that tenant wide option is available if you return to the top level options for Azure Active Directory, but you’ll need to have a subscription for Azure AD Premium P1 or better.

What I have therefore shown you so far will work with any Office 365 tenant and that is probably a good place to call and end to this particular article. I’ll be doing more around additional investigation options available in both standard and premium offerings soon, but for now I’ll leave you with an article from Microsoft that everyone managing an Office 365 environment should read:

Azure AD and ADFS best practices: defending against password spray attacks

and watch out for more from me around detecting and blunting attacks on Office 365.

YOUR call to action after reading all this should be to go and check your tenant for attacks like this and ensure you are doing everything you can to prevent their possible success.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s