An Insider Threat Report by Crowd Research showed that 90% of organisations feel vulnerable to insider attacks. The main enabling risk factors include too many users with excessive access privileges (37%), an increasing number of devices with access to sensitive data (36%) and the increasing complexity of information technology (35%).
When conducting analysis of user activity in O365, cross your fingers and hope that your client has enabled the Unified Auditing Log (UAL) in the tenancy. The UAL is switched off by default and needs to be enabled by the O365 Administrator. The retention period for the logs is dependent on the licensing in the tenancy:
- Office 365 E3 License– Audit records are retained for 90 days. That means you can search the audit log for activities that were performed within the last 90 days.
2. Office 365 E5 License– Audit records are retained for 365 days (one year). That means you can search the audit log for activities that were performed within the last year.
Retaining audit records for one year is also available for users that are assigned an E3/Exchange Online Plan 1 license and have an Office 365 Advanced Compliance add-on license.
When OneDrive is used as the central repository for business data, employees can access (download or view) that data by logging in via the O365 website or using the OneDrive application installed on a computer or smart phone.
In one particular investigation, a large volume of intellectual property was downloaded to a computer using the sync function of the OneDrive application. The UAL contained records showing a ‘FileSyncDownloadedFull’ event. When you use the Audit Log Search in O365 (which sucks), it refers to this activity as ‘Downloaded files to computer’.
The IP address responsible for the sync resolved to the client’s WAN IP, which made sense. What didn’t make any sense was when examining the computer used by the employee, there was no evidence of the downloaded data existing on the computer at or around the time the sync occurred. No USB activity, web browsing, email activity, in fact, no user activity at all.
Digging back through the UAL, I cross checked the MachineID recorded for the ‘FileSyncDownloadedFull’ events against the MachineGUID of the employee’s computer. The ‘MachineGUID’ key is generated uniquely during the installation of Windows. It won’t change unless you do a fresh reinstall of Windows.
The MachineID in the UAL log didn’t match the MachineGUID of the employee’s computer, meaning the computer that the employee used every day was not responsible for the download of data.
As the IP address for the ‘FileSyncDownloadedFull’ records were the client’s WAN IP. It made sense to search across the client’s LAN to see if I could identify the MachineGUID that was used for the sync of data.
To do this I was provided with remote access to a computer using the appropriate administrator account that could authenticate to each of the computers on the network.
To save time, I populated a text file, targetmachines.txt, with a list of the IP addresses for each device on the LAN.
Using a Command Prompt, I ran the following PSExec command to read in the IP addresses from targetmachines.txt, query the registry for the MachineGUID value and store those records in a text file, GUIDresults.txt
psexec @targetmachines.txt reg query HKLM\SOFTWARE\Microsoft\Cryptography /v MachineGUID > GUIDresults.txt
When that process was finished, I did the ol’ Ctrl-f in ‘GUIDresults.txt’ and got a match for the MachineID from the O365 UAL that was responsible for the sync. The employee had logged into a spare computer in the office to download the data which I thought was a creative approach.
The analysis of the spare computer identified various artefacts to demonstrate that the user had logged onto the machine with their account, the data had been downloaded, copied to and accessed on a USB drive that had been plugged in.