7 WAYS TO MONITOR YOUR OFFICE 365 LOGS USING SIEM
Office 365 is growing in popularity every single day. As companies move away from dedicated on premise hardware and software to more cloud based, powerful solutions, one thing is commonly forgotten – security monitoring. Yes Office 365 has built in security features, however, it is extremely important that you still monitor behaviour on these systems.
The rules I am about to discuss mainly applies to Office 365 logs, however some may also be useful in other cases. Before I get into this, keep sure you have read all of my previous SIEM use cases posts, which can be found on my homepage – https://blueteamblog.com/.
SUCCESSFUL OR FAILED LOGINS OUTSIDE BUSINESS HOURS
I’m going to start off here with a use case which can and should be applied to various log sources using SIEM. This rule may not work for every company, however for a lot of businesses they only work set hours every week. In this example, I am going to use a company working 9 AM till 5 PM as an example.
Looking for logons outside this time could indicate malicious behaviour. It is worth looking for both successful and failed, as failures can still indicate malicious attempts.
- Log Source = Office 365
- Event is PasswordLogonInitialAuthUsingPassword or UserLoggedIn or UserLoginFailed
- Login is outside business hours. (How you set this up will depend on the SIEM) For example, in IBM QRadar you can create building blocks which define times. In Azure Sentinel, you can use KQL to say “| where TimeGenerated between (datetime(“time”)..datetime(“time”))
- You may need to exclude things like admins, out of hours support staff and colleagues in other countries from this rule, or modify it appropriately.
RARE OFFICE 365 OPERATIONS
There are some operations within Office 365 that are very rarely used apart from by attackers. Due to this, we can look for these operations happening and investigate further.
- Log Source = Office 365
- Username is not ‘NT AUTHORITY\\SYSTEM (Microsoft.Exchange.ServiceHost)’,’devilfish-applicationaccount (Both of these accounts are back-end service accounts which perform these operations legitimately)
- Operation is any of Add-MailboxPermission, Add-MailboxFolderPermission, Set-Mailbox, New-ManagementRoleAssignment
- You may need to exclude any further service accounts in your Office 365 environment.
ACTIVITY OUTSIDE GEOGRAPHIC LOCATION
All modern SIEM’s have built in Geo IP database’s which we can utilise for this rule. Most companies only operate in certain countries, so any activity outside this should be looked into.
- Log Source = Office 365
- Geo location is outside operating countries. (How you implement this depends on the SIEM, however with most you can simply say Location is not USA, UK etc.
- You may need to exclude certain behaviour such as Auth connections happening in India or the USA. This is just the 2FA going to the O365 hosting. (If you require further explanation on this point, contact me)
EMAIL FORWARDING OUTSIDE COMPANY
It is against most companies security policies for users to forward emails outside of the business. It is also a common attack method threat actors use to exfiltrate data. To detect this with a simple rule :
- Log Source = Office 365
- Operation is Set-Mailbox
- Parameter contains ForwardingSmtpAddress
- You may need to exclude any partner companies employees are allowed to forward to, or any other exceptions like this.
We can also create a variation of this rule which can be classed as a higher priority – multiple user’s emails being set to forward to the same destination in a short period of time.
- Log Source = Office 365
- Operation is Set-Mailbox
- Parameter contains ForwardingSmtpAddress
- Forwarding Destination is 2 or more within a 7 day period.
EXCHANGE AUDIT LOG DISABLED
This use case is looking at O365, however auditing being disabled on any log source should be set to alert. Threat actors may disable auditing to evade detection.
- Log Source = Office 365
- Operation is Set-AdminAuditLogConfig
- AdminAuditLogEnabledValue = False
- User Type is Admin / DC Admin (Only administrators can disable auditing)
MALICIOUS POLICY MODIFICATIONS
Threat actors may also disable or remove policies to evade detection, therefore it must be monitored.
- Log Source = Office 365
- Operation matches expression (i)^remove or (i)^disable
- Operation contains AntiPhish, SafeAttachment, SafeLinks, DLp, Audit
Thanks for reading. Do you have any Office 365 use cases’ I missed, or do you need help implementing any I discussed? Contact me at https://twitter.com/blueteamblog or https://blueteamblog.com/contact-me. I would also love to hear what you thought of the post.
Thanks for a great list of indicators. Just a common on the location based metrics; many users use non-company VPN services such as NordVPN or Express VPN when working from home or from public locations. If such use is allowed, this will often cause false positives generated based on location triggers. It is a good idea to either ban the use of so called privacy VPN’s, or to filter out the IP addresses belonging to those VPN providers when creating alerts based on location.