Presenters: Owen O’Connor, Vice President of Digital Evidence; Robert Bond, Product Marketing Manager for the Forensic Division at Guidance Software
Robert Bond: Welcome, everyone, and thank you for attending Guidance Software’s webinar, Conducting Office 365 Investigations, featuring Owen O’Connor. Before we get started with Owen, my name is Robert Bond. I’ll be your host and moderator for this session. If you have any questions during this session itself, please submit them electronically through the Q&A dialog box on the bottom right portion of your WebEx screen. We’re going to answer your questions in the Q&A at the very end of the presentation. As always, if you don’t have a chance to submit a question during the presentation itself, or you’re watching an archived version of the webinar, you can submit your questions directly to me, at firstname.lastname@example.org.
Just to give you a little background on Owen O’Connor – Owen is an experienced information security leader, he has 17 years of experience. He founded Cernam, which is a cloud-focused digital evidence firm which develops tools for evidence identification, collection, and analysis. Owen presented a lot of this information at CEIC last year. I’m going to invite him to present this year at CEIC as well. He’s going to mention a tool or a set of slides that describe a tool inside of this presentation, and we can send those slides along to you. Just send a note to me at email@example.com. We’ll make sure that tool gets to you.
Now, this particular webinar is not a self-serving EnCase webinar at all. As a matter of fact, you won’t see the EnCase interface inside of this webinar. This is really about Office 365, and how that stores information, and how you, as a digital forensic investigator, can get that information. If you want to know more about how EnCase supports 365, a quick summary is this:
If you’re an eDiscovery customer today, we have connectors for Office 365, and so you can get into cloud repositories, and get that information for any kind of eDiscovery matter. If you’re an EnCase forensic user, and you’re doing a dead box investigation, a lot of what Owen is going to talk about really pertains to you and your investigation, so Office 365 or OneDrive, more specifically, creates backup copies on the hard drive of whatever is stored in the cloud, and then inside those Office 365 or OneDrive folders, you’ll be able to find artifacts. And again, Owen is going to get into that.
So just real quickly – and I go through this in every webinar presentation – we have Guidance-certified training classes. Our training classes – we have 24 different training classes. The two that you see on the screen right now, EnCase CFI and CFII, they’re really our cornerstone training classes, especially if you want to earn your NC certification. We have 4500 people that have done that. The annual passport training that you see at the bottom, that is our unlimited access training. So training can take place in any one of three mediums – in the classroom, on demand, or vClass, which is a simulcast training, where you at home can look into a classroom virtually, and in real time, and then take all the exams or do all the practicals in real time as well.
So here’s a list of our resources – and we go through this each time, in each webinar as well, but today I’m going to do something a little bit different. We have a brand new website at Guidance Software, so I just want to make sure you understand where to find all these different resources. If you go to the top nav, and you want to find our startup training, just go Training, click over, and you’re going to end up at our EnCase forensic training. Now, if you want our Enterprise or CyberSecurity training, those are listed in the Related Information section down below. But for those of you that haven’t taken our on-demand training, it really is excellent. The forensic is a 10-part, as you can see, four-hour training. You can go through a table of contents and just get a feel for what is presented in each one of these sections.
We won’t go through that now, but you can certainly get an idea of what that looks like. So I encourage you, especially if you’re a new v7 user, to go and try out that training. One other thing I wanted to show you real quick is our App Central site. We now have 146 free apps. They’re listed down the pages, and you can search for the apps that I’m going to mention in just a second.
So, for example, if you want to find Simon Key’s very popular ShellBag EnScript, you can certainly just search on “shellbags”. It’ll come up; click on it, download it, and it’s yours for free.
We also have a Digital Forensics Today blog. I think 150 or so different entries into that blog. You’re welcome to search on features or industry events or whatever happens to be in that blog. And then, just real quickly, here’s our most downloaded EnScripts over the past 60 days. ShellBags, as I just mentioned, is number one. BSS Examiner, which has been around for about three and a half years, is a steady number two. SEEB USB Mounted Devices Report, which gives you a list, from the registry, of all the different USB devices that have been plugged into that system, is number three. Thanks, Bryan Jones. And if you want to learn any more about these top three EnScripts, there’s a blog post about them and what they do inside of Digital Forensics Today.
So with that, let’s get you over to Owen. Owen, please, take it away.
Owen O’Connor: Thank you, Robert. And thank you, everyone, for joining us today. What we’re going to cover today – we’re discussing Office 365 investigations and security incidents, how we handle them. So before we get into that, we’ll introduce what Office 365 is, why any of us should care about it, why it’s relevant to us. We’ll look a little bit at the Office 365 security model. We’ll look at some scenarios around incidents and investigations involved in the platform, and, corresponding to that, some of the approaches, tools, methods that can be useful in responding. Lastly, then, we’ll wrap up looking at some tips and pointers on how to prevent security incidents and how to adapt your current processes to Office 365.
A disclaimer before we begin: I’m not a Microsoft employee, I don’t work with them, I don’t represent them in any way, nor have I ever done. This really is a talk based on my experience as a practitioner working with the platform, developing solutions around it, running investigations involving it. This is based on either my direct experience or on public reference material, not on anything that is confidential to Microsoft.
With that out of the way, let’s look at the basics of Office 365.
What this platform is effectively – it’s a cloud service which provides three basic things. At a fundamental level, it provides collaboration, document storage, and real-time communication. If you’re familiar with the Microsoft products, Microsoft server or on-premises products, these categories map to three products: Exchange, SharePoint, and Lync, or as it’s now called, Skype for Business.
So individually, these offerings are not hugely exceptional, they’re not unique in the market by any means, they have competition. But what Microsoft is doing with Office 365 is providing all three of these as an integrated service, really as a platform where each of the parts fits together reasonably well. They’re also pricing that quite competitively in a way that seems to be doing pretty well in the market, which is why it’s relevant to all of us.
If you’re familiar at all with Office 365, you might have come across some services like OneDrive for Business, and you might be wondering how they were late to Exchange or to SharePoint or to Lync, which we’ve said are the three core components. What I’ve tried to do in this figure is to show, starting from those core components, from those Ring 0 components, if you like, to show how some other components relate to them, how some other features and parts of the service that you might come across interrelate.
At Ring 1, you’ve got a series of support components which, in some cases, they’re optional, things like Intune – certain customers use it, certain ones don’t – others like Exchange Online Protection or Azure Active Directory, a much larger set of customers use, or maybe all customers use. So these are support infrastructure, if you like. They’re equivalent to the antivirus or anti-spam products that you would run on your own network.
At Ring 2, in the green box there, you’ve got some overlay services, what I’ve called overlays. These are components or features of the product which have been built on one of the core components, one or more of the core components. You have things like OneDrive for Business, which is a file storage, sharing, and synchronization tool. That’s built on top of SharePoint. When you store a document in OneDrive, you’re really storing it in a particular document library in SharePoint, in your My Site.
Similarly, the video portal is built on top of Office 365 – built on top of SharePoint, rather. Videos that you store on the portal are saved into SharePoint. Office Groups then is a relatively new component which was built on top of Exchange and SharePoint. So you can see that these are not wholly new core components. These are services or offerings that are built out of the core elements.
And lastly, then, at Ring 3, you have some cloud-only services which don’t have an equivalent on-premises or server product that you can install on your own network – things like Yammer, which is another collaboration service. It’s cloud-only – if you want to use it, you can license it, you can adopt it through Office 365, but it’s only available in the cloud.
With all of this going on, you can see that this is a relatively complex platform. This isn’t equivalent to a fairly simple, single-purpose cloud service like Dropbox. There’s quite a lot going on here, there’s a lot of different features, different organizations may use it different ways. What you’ll see here in the screen, in this slide, is a set of icons or a menu which users see when they log into the Office 365 web interface. If you’re in SharePoint, if you’re in Outlook web app, this is the menu that you’ll see showing you the different parts of the service that you have access to. You can see, for instance, you can jump from email, say, into your calendar or into OneDrive or into PowerPoint Online, an online version of PowerPoint.
So even though there’s a lot going on here, the fundamental storage locations, there’s really just two in most environments, in what Microsoft calls tenants. So for most customers, there really are just two places that we need to worry about in terms of evidence storage. The first is Exchange, the second is SharePoint. In this talk, we’re going to be concentrating quite a bit on Exchange – it’s the more forensically rich storage location. It also stores not just the kind of data you would see in a normal, on-premises Exchange server, it also stores data and items relating to Office 365 itself. So for example, this menu that you’re seeing, with the different icons, the elements of that menu are stored in Exchange, in a hidden part of the mailbox that we’ll come on to talk about.
Before we can look at security incidents, before we can look at investigations in the platform, we need to understand a little bit about how security works in Office 365. The fundamental thing here is that when you move to Office 365, you are not simply outsourcing security to Microsoft, you are not handing over responsibility for information protection to another organization. You’re still responsible for securing Exchange, for securing SharePoint, for an awful lot of management tasks. So there are organizations who have moved to Office 365, and immediately cut their Exchange team or even reduced headcount maybe in their SharePoint team. I think in 2015 it’s quite clear that that isn’t a sound approach, that isn’t the automatic consequence of moving to Office 365. You still have responsibilities for managing Exchange.
So your team, for instance, manage identities in the platform, you create the users, you create the groups, you manage things like mailboxes, SharePoint sites, access lists. Effectively, in terms of Exchange, if you’re familiar with how Exchange is run, the customer is responsible for virtually everything in the Exchange control panel and everything logically above that. Microsoft looks after the things that are below the Exchange control panel, like the actual Exchange installation, the operating system, the storage, the networking. It takes care of that, but the customer is responsible for virtually everything in the Exchange control panel.
In addition to not understanding their responsibilities or this shared security model, the other key difficulty that I’ve seen is customers not paying attention to the security policies and the settings. In many respects, the way that Office 365 is configured out of the box, if you like, when you create a new environment, the settings emphasize ease of use or ease of deployment over security and control. So customers really need to manage the platform quite carefully, tune the policies, tune the settings to match their requirements. And unfortunately, that key step seems to be one that many organizations skip or don’t give enough attention to. As an example of the sort of issues that this can cause, there’s a whole host of settings around mobile devices that need to be managed, but the default policy allows any user to enroll any device, including personal devices. So there’s effectively no controls, all of the dials are turned to zero, in terms of mobile device security, by default.
A couple of examples here of customer-managed or customer-owned security controls. Customers are responsible for identifying and choosing the identity repository that they’re going to use – so for instance, whether they’re going to use user accounts that are stored in an on-premises Active Directory environment, or whether they’re going to use the Azure cloud Active Directory offering, or maybe they’re going to federate through a third-party service. They may not be using Active Directory at all, they could be federating back to some type of [indecipherable] identity service.
They’re then also responsible for configuring and determining how authentication works. There are options, for instance, to turn on two-factor authentication via text message, there are options to enable what’s called claims-based authentication, which allows, for instance, restricting logons by IP address range. These are options that customers have open to them, but Microsoft doesn’t own these controls. They’re customer-owned controls. Customers turn on and off various features, customers manage a whole host of settings and policies relating to mobile devices, to audit trails, things like the access protocols by default in the platform. Every mailbox access protocol that you can image is enabled by default. So a new Exchange environment in Office 365, your users can use POP3, they can use IMAP, they can configure mobile devices via ActiveSync, they can Outlook web app from any IP address. So these are settings that customers need to tune to their particular requirements.
Customers also own several critical security processes in the context of Office 365. So customer personnel, for instance, are responsible for managing privileged access, deciding who has admin access, deciding what level of access or what individual rights that they have in the platform. Customers provision users, de-provision and provision mobile devices, they also handle things like “special circumstances” leavers – if you have a person leaving the organization where you need to do more than the normal process, you may need to wipe devices, you may need to take some additional steps. Customers are responsible for those processes.
Also, things like changes to the platform – customers need staff assigned to review changes to the platform, review new features that are coming out, and decide whether or not they should be enabled or disabled, whether they introduce new security considerations, or whether particular settings need to be configured.
To sum up then, in terms of security: we have to assume that Exchange and SharePoint are very attractive targets. They store huge amounts of corporate data in a reasonably searchable, reasonably discoverable fashion. So they’re a very attractive target for either insiders or external attackers. There’s also a factor that moving to Office 365 may make certain data more accessible. For instance, email might previously only have been available on the corporate network, but by moving to Office 365, an organization might decide that a VPN connection is no longer needed.
The bottom line then, I suppose, is that if, as with on-premises infrastructure, customers don’t pay sufficient attention to security, it’s perfectly possible for an Office 365 environment to be compromised internally or externally. In certain scenarios, a cloud compromise like this could also be more difficult to remediate than the equivalent on-premises. We can’t, for instance, in the cloud context, simply restore servers from backups and roll back to a known point in time prior to an issue. It may be that something like an external compromise of an administrator account in Office 365 may be far more difficult to remediate to get the platform back to a trusted state.
With that in mind, let’s move on to look at some of the scenarios where we might need to investigate Exchange Online particularly. As we have said, Exchange and SharePoint are commonly targeted – so what are the types of issues that we see? Many of you are probably seeing Exchange and SharePoint very commonly in your internal investigations into, say, malicious insiders, malicious IT staff, any issues around employee data theft. Very often, the core of these issues is either Exchange mailbox data or documents stored in, say, SharePoint document libraries.
We also see SharePoint and Exchange quite heavily in internal data spillage issues or over-sharing issues, if you like, where access lists maybe aren’t appropriately setup, and staff who shouldn’t have access to certain data find that they do. That data then spreads within the organization and causes particular difficulties.
Other security incidents outside of investigations, breaches and incidents also frequently involve Exchange. You’ll see issues around privacy breaches, around external leaks of information, even things like harassment issues or spoofed internal emails. A lot of these relate to Exchange, just because it’s such a major communication system in most companies.
When we’re looking at on-premises Exchange, we’re looking at a traditional Exchange server sitting in your data center. We really have numerous sources of evidence. We have a variety of paths in front of us at the start of an investigation, we can look at quite a range of audit trails, we can look at things like the Windows event logs, we can look at the flat log files that come out of Exchange from components like OWA. If we want to know who has access to a particular mailbox via Outlook web app in the last week, we can go to those log files, do a quick query, and pull out that data. We’ve also got quite a bit of internal Exchange login data, and we’ve got logs from supporting components, like maybe a remote access system, or antivirus systems which might be logging traffic in and out.
In terms of interrogating the platform itself and getting useful data out, there are quite a few what are called [PowerShell commandlets] or interfaces into the platform which will give us a live view of interesting data. We can pull mailbox data out in to a PST for analysis, we can look at things like active client sessions. If we’re interested in who has logged on today to a particular mailbox, we can pull that directly from the platform via PowerShell from Exchange.
Outside of these [commandlets], outside of these logs, we can also do quite a bit with the servers themselves, because they’re in our environment. We control everything in front of them, everything behind them. We can instrument the servers themselves, we can monitor traffic to and from them, we can even mount and access the raw Exchange database files or go to backups if we need to.
By comparison, when we look at Exchange Online, we look at Exchange in Office 365, the service is based on Exchange 2013, so you might expect that many of the same techniques and resources apply. Unfortunately, they don’t. This is a shared cloud service. Your data isn’t sitting on a server exclusive to you, it’s sitting on a server shared with other organizations. So you can’t, for instance, get access to the Exchange database files, you can’t get access to the Windows operating system. You’re never going to be able to [indecipherable] into the Exchange server hosting your Exchange Online mailboxes, you’re never going to be able to get a disk image of that server, because it’s not just your data – in most cases, this is multi-tenant, shared cloud infrastructure.
So here’s a quick comparison of what we have. We do not have Windows event logs, we do not have log files from things like ActiveSync or OWA, we lose many of the supporting components, just because they’re no longer relevant. You may no longer have a requirement to VPN in to access email, for instance. So you lose that visibility.
Quite a few of our key most useful PowerShell [commandlets] are also deliberately disabled or deliberately restricted in the online version of the platform in the cloud service. So we can’t do a mailbox export request in the same way to [outport] it to PST. We can’t access things like logon statistics, we can’t get some of the same detail about mobile device usage that we could on premises.
You might think that this looks like a pretty bad situation when it comes to investigations in Office 365. We don’t have the logs we’d like, we don’t have the level of access we’re used to, some of the default settings are unhelpful for investigations. But it’s not all bad news. The great thing about Office 365, from a forensic point of view, is that it’s accessed using recent versions of Outlook. It’s accessed using either Outlook 2010 or 2013 in most cases, earlier versions are not supported. It’s also accessed using the latest versions of things like OWA. So the advantage for us of these newer versions, these newer clients is that they create a lot more forensic valuable data than earlier versions. They create some fantastic artifacts that we can use to make good some of these deficiencies or some of these disadvantages, and really help us when it comes to investigations.
Now that we understand Office 365 a little bit better, let’s look at how we can approach it in terms of investigations. As I said earlier, the core of this talk really is around Exchange mailbox analysis. This is about how we can make the very most of what’s inside Exchange to facilitate our investigations, and how we can best extract that content. Before we can drill into that, we need to get a better view of how data is stored in Exchange, and just exactly what makes up an Exchange mailbox.
In my experience from working in this area, training in this area, I think there’s a great many forensic professionals, even very, very experienced colleagues, who don’t have a good view of what’s inside an Exchange mailbox. They have a view essentially of the left-hand-side of this figure here in this slide. They see the user items in the blue box, they understand that there are folders called ‘Inbox’ and ‘Sent Items’, that inside of those there’s a series of emails, and that’s essentially the limit of their understanding.
In order for us to get [indecipherable] the topic of Exchange forensics, we need to dig further. We need to look at the right-hand-side of this figure in the green box, we need to look at these non-user items which Outlook doesn’t show us but which really are at the heart of Exchange forensics, and therefore at the heart of Office 365 investigations.
In this slide, you can see two views of the same mailbox. On the left-hand-side, we have the Outlook view, and you’ll see all of the folders that you’re familiar with – things like the Inbox, the Drafts folder, the Calendar folder, deleted items. On the right-hand-side, you can see a slightly differently formatted view, but if you look down towards the bottom, under ‘Top of Information Store’, you’ll start to see the same folders that you’re used to in Outlook. So you’ll see the ‘Calendar’ folder, you’ll see the ‘Contacts’ folder. What the right-hand-view represents is really the truth of the mailbox structure, the truth of the content that’s inside a mailbox.
This is from a tool that we’ll go on to in a moment, called MFCMAPI, but broadly, it’s showing us four types of content that are not shown to us by Outlook. It’s showing us hidden folders within the user area – so if you look at Contacts, for instance, on the left-hand-side we see just one sub-folder called ‘Lync Contacts’. On the right-hand-side we see four subfolders – so three of these are being hidden from view in Outlook, a little bit like a hidden folder on the Windows file system. We’ve also got system folders, which is essentially everything above that Top of Information Store line. Top of Information Store represents the beginning of the user space in the mailbox, where Outlook stores most of its user-facing data. The rest of the mailbox, the stuff above that – these are system folders.
And one of the most important there, you’ll see Recoverable Items. If you’re familiar with older versions of Exchange, this is what used to be called the dumpster. It’s where data goes after it’s been… if you go to delete an item in Outlook, it will first be moved to the recoverable items area before being completely removed from the mailbox. It allows users to undelete items, a bit like the Recycle Bin in Windows, for a period of time before they’re fully deleted.
If your view of an Exchange mailbox comes from viewing it in Outlook, you’re also missing several other pieces of data – you’re missing a critical amount of metadata. If you look at the properties of an item in Outlook, you’ll see, for instance, three timestamps, you’ll see the size of an item, you’ll see the importance flag and the sensitivity flag. These represent about 10% of the available metadata for a typical email. So you’re missing 90% of that metadata, including things like additional timestamps. You might have a case where time data is critical – by missing out on some of this data, you could be missing critical evidence.
Secondly, for this slide, Outlook is hiding an entire category or class of items which are stored in Exchange mailboxes. These are called folder-associated items or FAIs. You’ll see we’re talking quite a bit in the rest of this deck about FAIs. So this really is a critical point. A folder-associated item is similar to an email, but it’s a hidden system or application item. It stores things like application settings, it stores user activity data. It doesn’t typically store emails or calendar items, but it’s a very large and important part of an Exchange mailbox, and very central to forensics.
Really, if we’re using Outlook to examine mailboxes for forensic purposes, it’s almost like doing disk forensics via Windows Explorer. It’s not going to give us the true view of what’s going on or what data exists. We need different tools [to let us] look a bit deeper.
The primary tool that I’ve found very useful for Exchange forensics is a free tool called MFCMAPI. It’s not intended as a forensic tool, it’s an Exchange troubleshooting and analysis tool written by a member of Microsoft’s Exchange team, named Stephen Griffin. But it’s a very, very powerful, under-the-hood Exchange exploration tool. It lets us look at the internal structure, it lets us access these hidden areas, system folders, it lets us view folder-associated items.
There’s also a companion tool called MrMAPI, which goes alongside MFCMAPI. MFCMAPI is your GUI, slightly easier-to-use, finding-your-way-around exploration type tool. MrMAPI, on the other hand, is a command line tool which you can use to do automated exports of mailboxes or of particular items from a mailbox.
So for today’s session, we’re not going to look in detail at these two tools. If you are interested in how to use them, we covered it in quite a bit more detail at CEIC 2015. If you’d like a copy of those slides, contact myself or Robert after the session.
Now that we understand the Exchange online structure, now that we understand the true structure of a mailbox, what can we find inside? Broadly, we’ve got five categories of data. We can find caches of user data – so these are user emails, user calendar items, contacts, whatever – which are outside of the user’s control, which the user may not be able to delete. So these are very useful shadow copies of user data, in a sense, a bit like a Windows temporary files area.
You’ll also find application data – so data generated by applications. It might be similar to data stored in the Windows registry, it might be lists of most recently used areas or files or references, it might be temporary data generated by a particular application, it could be usage data, which is the third category here. So you’ve got usage information, like effectively logs – data that’s being stored in the mailbox by applications, maybe like Lync or Outlook web app, which represent user activity, effectively pseudo logs, almost.
Fourthly, we’ve got data from other Enterprise systems – so because Exchange is so central in many organizations, there are third-party applications that like to integrate with Exchange and store data into it. So you’ll see data associated with things like BlackBerry Enterprise server, if you still have that in your environment. You’ll see data from voicemail systems that store messages into Exchange, usage data, application data from these platforms may exist in your Exchange mailboxes.
And lastly, we really have a treasure trove of metadata. We have huge amounts of metadata, up to perhaps a couple of hundred items of metadata per item, we have rich folder-level metadata, we have rich metadata about even down to individual attachments on emails. If you look in Outlook at an attachment, it will tell you the file type, the file name, and maybe the file size. If you look under the hood with something like MFCMAPI, you’ll find quite a bit more data about that attachment, some of which can be very, very useful for investigations.
This is the little top ten that we provided at CEIC 2015 of some of the most interesting, some of the most useful finds that we’ve come across, that my team had come across [indecipherable] around forensic artifacts inside Exchange mailboxes. These are all found in Exchange online, certain of them may also be found in Exchange on-premises, so if you’re dealing with recent versions of Outlook and recent versions of Exchange, you may also have some of this data on your regular on-premises servers.
So just to highlight a couple of these, at number two there, you have what I’m calling these IPM.Activity folder-associated items. So these are examples of those hidden system items, these are stored in a folder under “Recoverable items”, and they’re effectively stored there temporarily, so they don’t remain there for a hugely long period. They’re being stored there before being deleted from the mailbox. But if you can collect them and access them, they give you a map of mailbox activity. They will effectively tell you a user accessing this mailbox opened this series of emails in this ten-minute period, they spent 45 seconds reading this email, three minutes reading this email, two seconds reading that email. It’s a very, very granular, rich set of data on mailbox access.
So obviously, if you were working with something like an unauthorized mailbox access issue, you knew that a particular mailbox had been compromised and had been accessed in a given time period, you could look at this IPM.Activity data to say at a very, very granular level what data was accessed, what might this person have been looking for.
You’ve got a series of items there at number three around ActiveSync. There’s an entire system folder, an entire structure in the system area under the ExchangeSyncData folder which relates to ActiveSync. ActiveSync is Microsoft’s rich mobile device sync protocol – so it synchronizes not just emails, but calendar items, and tasks, and contacts, and what not. It also handles basic device management for mobile devices. So if you look in a particular mailbox, you look at this ExchangeSyncData folder, you can find the device IDs of every ActiveSync device that’s associated with that mailbox. If you’re interested in whether this person is using a personal mobile device to connect to their work email, provided they’re doing it over ActiveSync, you can find that data in this ExchangeSync data structure.
At number four there, PeopleModel data. Again, this is a folder-associated item, but this time it’s under the inbox. It’s got a type or a class of IPM.Confirguration.Inference.PeopleModel, and what this is effectively is a map of who each person interacts with most closely. So Office 365 is tracking who the individuals in the company that you work with most closely are, and even individuals externally, or email addresses externally. So if you see an employee who is regularly emailing data to their personal address, that personal address will show up as a very close contact in this proximity data. It’s a very, very useful artifact that, if you were looking at five people in a particular team, and you weren’t sure who else was relevant, you could pull this PeopleModel artifact, do some very simple analysis, and say, “Based on Office 365’s view of the organization we need to add these other three people to our scope.”
So we have some very, very useful, interesting data. We can see things like even down to search terms. If you have someone who is accessing their mailbox via Outlook web app or you have an unauthorized access via Outlook web app, you can see the history of search queries that have been run in that mailbox by looking at a particular folder-associated item at the root of the mailbox.
So there’s really a wealth of data here. At CEIC 2015 we showed some examples of this, and we have some examples in the slides if you’d like to take a look at any of them more closely.
How do we find these? How do we come across these interesting forensic artifacts? It’s effectively impossible at this point to document all of the forensic artifacts. They vary by organization, they vary by user. If one person is using Outlook web app in a particular way, another user in the same team, in the same company might not use Outlook web app at all, so those artifacts won’t be present. Some users don’t know that they can access their work mailbox via OWA, for instance.
They’re also just so rich – there’s so much data here it would be like trying to do an exhaustive documentation of every artifact found in the Windows registry or ever artifact found in any OS10 [indecipherable] file. There’s just too much in here, it’s too rich of a platform.
But fortunately, with something like MFCMAPI, with a tool that lets us look deeper into the mailbox structure, we can almost stumble across interesting artifacts. We can look at areas like the root of the mailbox or the root of the user area, what’s called the top of information store. If we look at folder-associated items there, if we look at the items that are being modified or updated on a regular basis – say, if you were to look at the items which change on working days and don’t change on non-working days, that would be a good initial indication that those are artifacts which relate to user activity. You could then drill in and find that something like the IPM, that activity, folder-associated items are tracking how emails are read.
In a specific operational scenario, if you have a problem where, let’s say a user is repudiating a particular email, they say that their mailbox was accessed without authorization and they’re claiming that a particular email which was sent from their mailbox was sent by an unauthorized person, that they didn’t send the email, they’re denying any knowledge of it. You can take a more focused approach to the artifacts in their mailbox. You would start by taking probably a copy of all of the data in their mailbox, and you would do a fairly typical timelining exercise looking at creation and modification timestamps.
So let’s say that the email was sent at 10 am on Monday, you would look at any of the items, either user items or system items, which were created or modified around that time. That might indicate, for instance, that Outlook web app was being used at that time, and you could then look more closely at OWA to drill into where was it being accessed from, what logons occurred, is the pattern of usage in that period consistent with the user accessing it or does it maybe indicate that someone else accessed their mailbox.
If you’re doing keyword searches, there’s quite a bit of interesting data in the mailbox in some of these hidden areas. You’ll find, for instance, Windows SIDs. So the sort of SIDs that you’re familiar with from EnCase, if you take one of those, say, for the Active Directory user, and you search across the mailbox, you’ll find items that have been modified by that particular user. You’ll also find things like usernames, email addresses, IP addresses, as you’d expect.
So where do we go from here? I suppose summing up in terms of preventing security incidents – my experience is that many Office 365 customers have not really considered security. They have adopted the platform, they did some security due diligence initially to make sure that this was the right platform for them. But effectively, what that told them was that this platform can be made secure, not that it is secure out of the box.
So I think the first thing that an organization needs to do to improve security and prevent incidents is to review all of the default settings for the key components that they’re using. If you’re not using Skype for Business, you may be able to just disable that and not worry about the settings and policies. But if you’re using Exchange, if you’re using SharePoint, you really need to go through all of the defaults, all of the settings, all of the policies, all of the templates, and make sure that you’ve considered all the items that have security relevance.
As you’re doing that, there’s a particular attention need to be paid to mailbox access protocols and how mailboxes are accessed. So the policies around Outlook web app for instance, the policies around Active Sync and other things that control mobile device usage – this is an area where I’ve specifically seen breaches occur, where, let’s say a malicious person is able to add a mobile device to a victim’s mailbox, and by doing that they get effectively all of that user’s email pushed to them in a very convenient way, and in a way that’s quite difficult to detect in many cases.
Thirdly, I would say document the changes which need to be made as you’re creating mailboxes or SharePoint sites. There’s a set of polices and settings that are key for security – things like mailbox access auditing, which cannot be defined in advance, they can’t simply be set by policy, they have to be manually configured for each new mailbox. So it’s very important to document for your helpdesk [team’s sake] exactly how these mailboxes need to be created and then to look back periodically or look at the logs even, to say when a user is created, do the expected changes occur immediately afterwards.
And lastly here, your key security processes – things like user de-provisioning, the things that you understand very well for your on-premises systems, you need to document your assumptions, your expectations, and test and validate them for Office 365. You may find, for instance, that user de-provisioning works slightly differently, that simply disabling a user’s Active Directory account isn’t enough to meet your requirements, that you need to go through some additional steps or you need to be aware of some caveats around that.
Adapting then, to Office 365, if you’re in a situation where your organization has moved to Office 365 or your customers have moved to Office 365, your current forensic processes for dealing with Exchange may not map well to Office 365. Even though Exchange in Office 365 is very heavily based on Exchange 2013, it’s not quite the same.
So it’s very important to ensure that the audit trails are enabled, and that they’re appropriately configured. If you turn on mailbox access auditing, for instance, you’ve also got to specify which types of access you want. You could have mailbox access auditing turned on, but only be auditing item deletion, for instance, which doesn’t tell you when someone has actually logged on to a mailbox; or you might have it turned on but you’re only keeping the logs for a week instead of 90 days or however long you want.
Secondly, I think the native ediscovery features in the platform – we haven’t had time to walk through them today, but Office 365 has a host of compliance or ediscovery type features, some of which can be useful for investigations. The legal hold feature, for instance, is a useful evidence preservation feature. It has some limitations, it has some caveats you need to be aware of – for instance, it’s not really suitable for covert use, but it may be something that, in certain investigations or certain security incidents, it’s useful to turn on legal hold or to use some of the search features.
Thirdly, the ability to preserve evidence is clearly key, the ability to get evidence out of the platform. So looking at tools like MFCMAPI, looking at MrMAPI, looking at some of the third-party tools on the market to understand when the time comes to do an Exchange investigation, how do we get not just the user data, but how do we get the full breadth of the mailbox out.
And lastly, I would say review the processes for access to employee data. If your current practice, for instance, involves assigning an investigator access to a mailbox, and then logging on directly, you may want to look at that in the context of Office 365, and see whether that action overwrites too much interesting data, whether the cost of that in terms of modifying evidence in the mailbox is too high, or whether you want to change to a different process.
Summing up then, before we take some questions, of what we’re talking about in Office 365 is a very, very powerful, very flexible platform. It’s capable of being run in a very secure manner, but many of the key security settings are controlled by customers, and the default values when you create a new environment may not be ideal for investigations or even for preventing security incidents.
Secondly, Exchange really is at the heart of Office 365 when it comes to evidence. Even if the challenge that you’re working on is not related to Exchange, even if it purely relates to Skype for Business, for instance, or OneDrive for Business, there is likely to still be interesting evidence in Exchange, which is potentially easier to get at, potentially richer in forensic value. So consider Exchange regardless of what your case is.
Thirdly, “Outlook lies” is the bottom line, I suppose – don’t be misled by Outlook. The true content of a mailbox is very, very different. There’s huge forensic value once you start to look under the hood, but don’t be misled by what Outlook tells you is in a mailbox or what Outlook tells you about, say, metadata.
And lastly, this really is a very, very interesting area in terms of forensics. There is huge scope for further research, for further work, for tools, for EnScripts. This is an area that I think will be taking off hugely in the next couple of years. So learning more about Exchange will pay off. It really deserves in-depth examination and deserves a closer look. Finally then, just a couple of references which you might like to screenshot or take a look at in the slides afterwards, a couple of resources that might shed further light on Office 365, on MFCMAPI, or on how we can research artifacts inside Exchange mailboxes.
With that, I’ll hand back to Robert for questions. Thank you very much.
Robert: Great. Thank you, all. So as all of you know that attend these webinars, we’re going to try and do about a 14-minute Q&A session with Owen. We always try and stop at the top of the hour. We know people have things to do. So we want to get as much information in, in as short a time as possible. If you do have questions, please plug them in on the bottom right portion of your WebEx screen. And for all those folks that want both the CEIC 2015 presentation as well as this presentation, please send an email to me at firstname.lastname@example.org. Again, that’s email@example.com.
And real quick, Owen, before we get started, there were a couple of questions about EnCase 7 from [Bob Stillerman] and some other folks, about parsing PST from Office 2013, I believe it was. It will in fact parse a PST or an [OT] file. If you have any questions about that or need technical support, please call our technical support line at 1866-973-6577.
Owen, are you ready for the first question?
Robert: Fantastic. The first one is: where would you start investigating OneDrive for Business or SharePoint in Office 365?
Owen: Okay. So, as we’ve talked about at the very beginning, OneDrive for Business really is built on top of SharePoint. So you can think of OneDrive for Business as effectively being another corner, another area within SharePoint. So that’s why the two [still sit] together. As it stands, Office 365 logging doesn’t give us a huge amount of data on access to data in SharePoint. That is changing, or due to change, with some new features that Microsoft has announced around audit trails. But typically, if you’re trying to work out, say, all of the documents that a particular user accessed on their last day, or everyone who accessed a particular document, that data can be difficult to obtain.
Currently, one of the very promising ways of doing it – there is some data inside the Exchange mailbox relating to a feature called Office Graph in Office 365. Office Graph is a new feature which essentially tracks activity within Office 365. It looks at what emails you’re reading most quickly, what documents you spend most time reading, and it builds up a picture of your interests and your connections in the company. By doing that, it’s effectively tracking data on who’s reading what documents in SharePoint and in OneDrive. So that data relating to Office Graph that’s inside, in the Exchange inbox, in this series of folder-associated items, that’s where I’d start looking. It’s not a well researched area or a well written up area right now, but it’s definitely fruitful.
Robert: Okay, great. And folks, if you do need to drop off, please fill out our survey. That’s exactly the reason we get people like Owen, is because you ask for him.
Owen, this next question is: why is it necessary to look inside the Office 365 mailbox for evidence? Why can’t folks just rely on the logs or the PC contents?
Owen: I suppose this is about taking a cloud-specific approach, about approaching this problem from the perspective of the cloud rather than from the PC side or from the logs. Just as I mentioned there with SharePoint or OneDrive for Business, Office 365 is a very, very strong platform, very robust, very flexible, can be made very secure, can be operated in a very secure manner. But logging historically has not been its strong suite. So really, this approach of looking deeply into the mailbox and doing Exchange forensics is really about making the most of what we have, making the best of what data is available, rather than just saying, “Well, there’s no data available in the logs, so the bad guy gets away.”
Robert: Hmm. Okay. So how does Office 365 compare with other cloud apps? We got a variety of questions around this, but when you look at Dropbox or Google apps or some other cloud software like that, is there more forensic value inside of Office 365, and if so, why?
Owen: I think there is. I guess the flexibility that… the functionality in Office 365 and particularly in Exchange Online, if you compare it to a single purpose or a more limited cloud service, like, say, a Dropbox or another cloud type storage solution, Exchange is doing a lot more, there’s a lot more going on, and particularly, it has a much wider range of clients.
So you’ve got the different versions of Outlook on Windows, on Mac, you’ve got Outlook web, you’ve got a bunch of different mobile devices, you have a whole range of third-party clients connecting into Exchange and into Office 365. Those are using Exchange to store data, they’re storing, really, the kinds of data that we used to see in the Windows registry or on the PC file system. That kind of data is migrating into Exchange mailboxes, because it’s a convenient central storing place for data that used to go in the registry. So certainly we’re seeing more data inside Office 365, more forensic value inside the platform than on quite a few of the others.
Robert: So just extending that question a little bit, would you rather deal with an [on-prem] Exchange server or Exchange online, in an investigation?
Owen: Sure. I guess a lot of my background is on-premises Exchange. I enjoy log analysis as much as the next guy. But given all that I’ve learned about Office 365 and what I’ve been discovering recently inside, particularly, Exchange mailboxes, I’d much rather be dealing with Exchange online than a server.
Even if I can get an image of the server, even if I have every log that I could want, some of these forensic artifacts, things like that PeopleModel artifact that effectively maps the pattern of interactions in the organization, that’s a huge timesaver, it’s a huge boon for investigations. Some of these IPM.Activity artifacts, those are effectively better than any log. They’re more granular, they record a much greater level of detail. There is a bit more work needed to pull them out and to analyze them and to make sense of them, but at the end of the day you get a much better picture.
Robert: Okay, great. So when you’re starting an investigation, how would you detect the use of Office 365? What kinds of local artifacts would you look for on a target system?
Owen: Sure. If I have an image of the PC in front of me, for someone who’s using, say, Outlook connoting to Exchange in Office 365, I’ll be looking firstly at their MAPI profiles, so the configuration information for Outlook that tells Outlook where its servers are. We can pull that out of the Windows registry, it’s a pretty well documented set of registry keys around MAPI. If you pull that data out, you’ll see references to Exchange Online servers, they stand out pretty clearly.
You’ll also see on the Windows file system, under the user profile, you’ll see a series of autodiscover xml files. So if you search for the word “autodiscover” in the filename and “xml” as the extension, you’ll see a number of files that Outlook creates. Those are interesting because they point to Exchange Online servers again, so you can tell the difference between someone using a local, in-the-data-center server versus one on the cloud, but they also list out every mailbox that the user has access to. So if you’re looking at the PC of, say, someone in the IT department who maybe has given themselves access to mailboxes they shouldn’t, you’ll potentially find a listing of those mailboxes in those autodiscover xml files, which can be useful.
Robert: Okay, great. And then, when you’re looking at Office 365, are you likely to see that application outside of a corporate investigation?
Owen: I think we’re starting to. Certainly the more common scenario right now is that you’re either working within a corporation or you’re investigating something going on, or maybe in a criminal context you’re looking at an organization. You will though see it for individual use. So my email address here that’s on screen at the moment, firstname.lastname@example.org, that is hosted on Office 365, even though it’s a personal domain name, personal email account. Office 365, this is sort of the new Microsoft, where you don’t need to phone up and speak to an account manager and have a long conversation and sign a five-figure or six-figure check. You can roll up to the website, put in a credit card, and for $5 a month get yourself a single mailbox, Office 365, set up.
Robert: That’s a good point. And for anybody that wants to contact Owen directly, you can reach Owen at email@example.com or you can link up with him at LinkedIn at www.linkedin.com/in/owenoconnor. We have a little time for two more questions I think. When you look at the future of cloud-based forensics – and everybody talks about this obviously, we had so many different sessions at CEIC last year – what is your perspective in terms of what the challenges are going to be, what Office 365 is going to be in terms of forensic challenges, what Dropbox may be or [Box]? Can you kind of speak to that?
Owen: So where we expect things to go in the future you mean?
Robert: Exactly, yeah.
Owen: I think we will see more and more data accumulating on the PCs, but we won’t be able to build the full picture of what’s gone on just by looking at PC data. So even if we have, say, every mobile device we could want, every PC we could want, there is still a need to go to the source, which in this case is the cloud service. I think in terms of how we access data, the trend is pretty clearly towards better use of more sophisticated APIs, so the sort of application programming interfaces or development interfaces that provide us… like Microsoft or Google or Dropbox, the systems that they build for third-party application developers, those are how we’re going to get data in future, both in terms of metadata and audit trails, but also evidence collection.
Robert: Fantastic. So we’re just tying up right now. Is there any other comments you’d like to make before we conclude this presentation?
Owen: Just to thank everybody, really, for coming. Obviously, in the time available… this is a very big topic, so we’ve been limited in what we could cover. We haven’t, for instance, touched on Office 365 Dedicated or Office 365 Government. Those are really quite distinct environments, with some differences. But there’s a lot more we could cover here. So as I think you mentioned early on, Robert, we have the new CEIC Enfuse 2016 coming up next year. If anyone has any suggestions for additional material they’d like to cover, that’d be very welcome, if it’s more around Office 365, deeper detail around Exchange forensics, or maybe some other Enterprise cloud platform that you’re dealing with. And if you send through a suggestion to Robert of myself, we’ll be happy to factor it in for maybe [a talk at MIT] next year.
Robert: Yeah, and folks, we know we didn’t get to all the questions. It’s two minutes before the hour. We really always try and commit to getting you off the line before the hour. So with that, we’d like to conclude right here, and you can send any additional questions to firstname.lastname@example.org or to me, and I’ll try and get one of our folks here to solve it or Owen to solve it. You can send those questions to email@example.com.
Owen, thanks so much. Excellent presentation. Saw it at CEIC, thought it was fantastic. Looking forward to next year, and certainly loved the presentation today. Thank you, everybody, for joining us. We had a great crowd today. And if you have any questions about anything related to guidance software, please send those questions to me as well, again. Have a great day. Thanks very much.
End of Transcript