Office 365 at corporate level has the most confidential and sensitive data storage records and thus is targeted as the most critical store for investigation. Its mail contents, user contacts, other data files, artifacts allied to emails, etc. have to be analyzed using reliable Office 365 forensic software. The investigation generally hovers around the records with suspicious details and un-authorized access and information leakage.
Conditions Deterring Investigation
It is important to investigate Office 365 data logs so that estimation can be made as per the logs obtained. “Audit” which can be defined as a record with details who has accessed the account (mailbox) along with timestamp and actions performed on it. These Audit trails are highly useful to maintain security and gather information for investigation. However, when it comes to Office 365, auditing is not enabled for all the mailboxes by default. One has to enable it and only then Audits will be available. This means that if user mailbox is disabled Audits these data sources will not be available;
- Authentication logs
- Client connection details
- Message tracking data
- OWA webserver logs
- Last user log-in details
Thus, if events are not logged details have to be gathered from Microsoft Support. But MS Support can also deliver very limited amount of details. And in such scenarios Office 365 forensic software can be a wise prop to endure the investigation.
If the Audit is enabled, Audits will be available in the Target mailbox. This means if user A tries to access user B’s mailbox, the record of this access is stored in mailbox B in the folder name Audits under “Recoverable Items”. Irony is deletion of mailbox also deletes Audit data. To view this Audit Trails, Web Console or PowerShell can be used. PowerShell is preferable using “search-mailboxauditlog”.
What Indicates Office 365 Was Involved?
At receiver’s end it is difficult to conclude whether the email you are studying was sent using Office 365 or not.
- “MX” records can provide general estimation but it is not always correct. For instance, Microsoft MX can also relate to FrontBridge anti-spam and not to Office 365.
- For more accurate results one can go for SPF records. Query for “TXT” record and view “include: spf.protection.outlook.com”
- “Autodiscover” is a kind of “CNAME” which points to autodiscover.outlook.com is also a better indicator.
- Further, an “NS” record for “ORGNAME.onmicrosoft.com” points to the fact that Office 365 service has been involved.
How to Trace Office 365 Email Data?
In case you are examining a dead system, you can start from searching file names ending “Autodiscover.xml”. To be precise, search it in Outlook’s local appdata folder into Mailbox details, Server details and additional mailboxes to which user is having access. In case investigation has to be made on Office 365 emails, you can perform detailed investigation in headers of Office 365 emails. IP address can be traced from “x-originating-IP” element. You must also be aware of the fact that Office 365 supports SPF well but it does not support DKIM.
This blog highlights some of the basic methods used for such investigations. Email headers, Audit trails are the vast resource for evidences but for detailed and bulk email analysis Office 365 forensic software like are used by professional investigators. It must be noted that to gather information from Audits, it must be enabled. Moreover, there are many other modes available for investigation of Office 365 application like Microsoft’s document-level DRM solution.