In a recent article:

Investigating an Office 365 account compromise

I detailed how, if you go into the Azure AD sign in logs for an individual user you’ll probably see a huge amount of failed logins because automated hacking tools are banging away trying to brute force access into these accounts.

Once you see the sheer volume of attempts, constantly trying to gain access, you’ll hopefully appreciate how important Multi Factor Authentication (MFA) is because it means that even if the password is guessed then to login there is a need for another factor, like a security PIN.

So you think your safe with just MFA eh? Well, perhaps not as safe as you may think, because there is a good chance that basic authentication is still enabled on the tenant. What is basic authentication? Simply a login and password. Why is it still on? Because enabling MFA for users doesn’t disable it, it remains in place as a fall back.

With basic authentication still in place, this allows bad actors to keep banging away on your tenant trying to brute force a password. If you haven’t got MFA enabled for users, it is probably only a matter of time before a user’s password gets brute forced. Even if you have MFA, it is better to not even provide bad actors the ability to get one step closer to actually logging in now is it?

If you are serious about security for your Office 365 tenant then you need to enable MFA AND also disable basic authentication. Is this going to break stuff? If you are using application prior to Office 2013, for example, then yes, but you shouldn’t really be using those anyway.

To understand how to disable basic authentication and the ramifications of doing that, have a look at the following article:

Disable Basic authentication in Exchange Online

Most security conscious people should be using modern applications that mean that switching off basic authentication shouldn’t cause an issue at all.

After you have disabled basic authentication, go back into your logs and see how all the attacks I’ve mentioned previous effectively cease. It ain’t magic, you’ve just hardened your tenant by reducing the risk surface area. For bonus credits on securing your tenant take a look at:

Azure AD and ADFS best practices: Defending against spray attacks

I also have the following script in my GitHub repo:

https://github.com/directorcia/Office365/blob/master/o365-modern-auth.ps1

that will enable modern authentication in your tenant when run. However, beware of enabling this as it can cause issues, especially older (pre-Office 2013) applications.

So remember, yes enable MFA across your Office 365 organisation but ALSO disable basic authentication as well!

Office 365 has a good deal of security available out of the box, however much of it needs to be fully configured from the defaults. Add to this the additional security options Microsoft 365 Business brings to the table on top of what Office 365 provides as standard. Services like Office 365 Advanced Threat Protection (ATP), Data Loss Prevention (DLP), Legal Hold and so on are included with Microsoft 365 Business and most also still need to be configured appropriately.

Configuring security options is nothing new. IT Professionals have been doing it for years. That won’t change just because services are now in the cloud.

Even after you have configured all of these services appropriately, there are more security options you can add on from Microsoft. I think that probably the best add on security service you can bolt on to your Microsoft/Office 365 environment is Office 365 Cloud App Security.

You can simply add the Office 365 Cloud App Security to any existing tenant and then assign it to your users. As you can see from the above (in $AUD), it is pretty cheap for what I’ll show it can do for you.

Now before I get too far down the path of explaining Office 365 Cloud App Security I need to let you know there is a more advanced version of this service called Microsoft Cloud App Security that I’ll cover in more detail in an upcoming article. Here, I’m going to focus on Office 365 Cloud App Security. If you want to know the differences between the two services take a look at:

What are the differences between Microsoft Cloud App Security and Office 365 Cloud App Security

Once you purchase a subscription to Office 365 Cloud App Security and assign the licenses, you will see an extra option appear the Alerts section of the Security and Compliance center, as shown above. Selecting the new Manage advanced alerts menu item will display the Managed advanced alerts screen on the right. Like most security option in Microsoft 365, you’ll need to go in there and enable it the first time you visit.

Once it has been enabled select the Go to Office 365 Cloud App Security button.

You’ll now be taken to the Office 365 Cloud App Security console and a list of policies as you can see above. These are the default policies that are created for you and it is possible to create your own policies which I’ll cover soon.

Take a moment to have look through the list of default policies and you’ll find the cover some very common scenarios.

In this case, I’ve click on the Mass downloaded by a single user policy to view the details.

The real heart of the policy is the Create Filter for the policy section a little down the page as shown above. This is where you create the rules to determine when an alert should be activated.

A little bit further down the screen you’ll find the section to manage the alerts. Here you’ll see the option to send an email, text message and the new preview option to trigger a Microsoft Flow. This new Microsoft Flow feature will allow you to automate just about any action if the alert is triggered.

The Governance section at the bottom of the page shows you the default actions that you can take when an alert is triggered, including the ability to suspend the user and force them to sign in again.

The above shows you a custom policy that I have created that will alert me when an Office 365 administrator logs on outside my corporate network.

Once you have customised the default policies and add any custom ones all you need to do is wait until an alert is triggered.

When you receive an alert via email it will look like the above with links to take you straight to the policy match.

You can now view any alerts in the console as shown above.

When you select an alert you can dig deeper into the details as shown above as well as Dismiss or Resolve it by recoding how it was (these are in the top right corner of the screen).

Not only can you configure and view very detailed alerts but you can also view the Office 365 Activity Log as shown above. This is very, very handy and much easier than having to use the interface in the Security and Compliance center or an exported CSV file.

If you click on an item you again get a huge amount of information as shown above.

The buttons in the top right of the item allow you to search on similar:

– Activity types (i.e. here Log on)

– Activity from the same user

– Activity from same IP

– Activity from same country and region

– Activity in the same time frame

The above shows you the failed logon activities, each of which you can drill into for more information.

So the second things the Office 365 Cloud App Security can provided is a detailed way to browse and investigate the Office 365 Activity log.

Another thing Office 365 Cloud App Security can do is ingest the logs from on premises firewalls and UTM devices and display them in a dashboard as shown above. Here you can see exactly what cloud apps are being used in your environment. The idea is that it helps you identify shadow IT and prevent the leakage of corporate data from non authorised applications.

That’s a lot of power for a very small price in my books and makes Office 365 Cloud App Security a worthwhile investment for your environment. If you want even more power then you can look at Microsoft Cloud App Security which I’ll detail in an upcoming article.

If you are serious about monitoring your Microsoft/Office 365 environment quickly and easily, then nothing beats Cloud App Security. For most, Office 365 Cloud App Security will do what is required but remember that for only about $1 more, Microsoft Cloud App Security has even more power.

You can of course sign up for a 30 day trial of either product in your tenant today and try it for yourself. I’m pretty confident when you see everything that it can do you’ll happy add to the tenant going forward.

So when you get Microsoft/Office 365, I suggest Cloud App Security (either Office 365 or Microsoft) as something that you should add for sure if you are serious about security (and who isn’t these days??).

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

Data Loss Prevention (DLP) is typically an outbound scanning technology in Office 365 that monitors and prevents sensitive information from leaving the organisation.

Previous, DLP was only part of Exchange Online. It is still possible to configure policies only in Exchange Online as you can see above, in the Exchange Online Admin console.

To do this in PowerShell you’d use the command:

new-dlppolicy

The new of way doing DLP in Office 365 is via the Security and Compliance Center as you see above. The benefits of using this new method is that it is possible to use policies to not only protect Exchange Online but SharePoint and OneDrive for Business from data leakage.

Office 365 DLP has a number of pre-canned policy templates you can use as shown above. It is always best practices to at least start with these since they cover the basics.

You’ll note above that I’m looking to configure a policy based on Australian Financial Data. This in effects scans material looking for SWIFT code, Australia Tax File Number, Australia Bank Account Number and Credit Card as you see in the lower right.

Proceeding with the GUI wizard then asks for the areas in Office 365 to protect. As you can see from the above, these locations include Exchange email, SharePoint sites and OneDrive accounts. You can modify the inclusion and exclusions to all these different areas if you wish.

You then determine what content you are looking for in the policy settings, as well as when to detect.

You can customise these rules if you wish, as shown above.

Finally, you can determine how this policy will operate and whether it is active.

Why is all this important for using PowerShell? The simple answer is, that with many options, knowing what everything does in the web interface is going to help when it comes to implementing via PowerShell.

So, to start the PowerShell configuration process you are going to need to connect to the Office 365 Security and Compliance center using PowerShell. You’ll find scripts to do that at my GitHub repo here:

https://github.com/directorcia/Office365

We don’t want to use the older, Exchange Online only cmdlets like:

new-dlppolicy

we’ll be using the newer Security and Compliance cmdlets like

new-dlpcompliancepolicy

The first thing I need to is create a new DLP policy called ‘Australian Privacy Act’ and do that with the commands:

$params = @{
‘Name’ = ‘Australian Privacy Act’;
‘ExchangeLocation’ =’All’;
‘OneDriveLocation’ = ‘All’;
‘SharePointLocation’ = ‘All’;
‘Mode’ = ‘Enable’
}
new-dlpcompliancepolicy @params

Now, this basically establishes the policy and the location that it applies to in Office 365. There are not any rules yet to check the content.

To do this. you need to create a variable that holds the sensitive data types you want to check. Yo can do that with the following:

$senstiveinfo = @(@{Name =”Australia Driver’s License Number”; minCount = “1”},@{Name =”Australia Passport Number”;minCount=”1″})

You’ll find information about the specific sensitive data types for you region here:

https://docs.microsoft.com/en-us/exchange/policy-and-compliance/data-loss-prevention/sensitive-information-types?view=exchserver-2019

With all that in place, the rule can be added to the existing policy using the following:

$Rulevalue = @{
‘Name’ = ‘Low volume of content detected Australia Privacy Act’;
‘Comment’ = “Helps detect the presence of information commonly considered to be subject to the privacy act in Australia, like driver’s license and passport number.”;
‘Policy’ = ‘Australian Privacy Act’;
‘ContentContainsSensitiveInformation’=$senstiveinfo;
‘BlockAccess’ = $true;
‘AccessScope’=’NotInOrganization’;
‘BlockAccessScope’=’All’;
‘Disabled’=$false;
‘GenerateAlert’=’SiteAdmin’;
‘GenerateIncidentReport’=’SiteAdmin’;
‘IncidentReportContent’=’All’;
‘NotifyAllowOverride’=’FalsePositive,WithJustification’;
‘NotifyUser’=’Owner’,’SiteAdmin’,’LastModifer’
}

New-dlpcompliancerule @rulevalue

You should recognise many of these settings from what is in the web interface. Don’t forget that DLP takes a while to crawl through all the different content areas you have selected and be applied.

If all of that executes successfully, then you should see a new DLP policy in the web interface as shown above.

If you have an Office 365 or Microsoft 365 licenses that includes DLP, you should use the pre-existing templates that Microsoft provides you for you region and create a new policy for each.

You can, of course, customise these easily by changing the PowerShell parameters or creating your own rules to suit. The great thing is, once you have worked all of this out you now a configuration you can apply to every tenant quickly and easily.

That is the power of automation thanks to PowerShell!