OAlerts — The Microsoft Office Event Log

In this short post, I wanted to take a few and examine a fun little artifact: OAlerts.evtx. Is this a "new" artifact? No, not necessarily. However, I think there can be a wealth of information within this artifact if it relates to what you're trying to find. As forensic investigators continue to find out more about user interaction while on a certain box, this event log may or may not assist you in recreating those timelines.

While an entire book could be written to go over the forensic value of each event log (hmm…), I recently had some success within OAlerts.evtx. Seeing as I couldn't find much else in the form of write-ups (simple Google search), I figured I'd share my experience with others.

What is OAlerts.evtx?

Aptly named, OAlerts.evtx captures alerts generated by Microsoft Office during user interaction. Now, one may think, "I don't ever get "alerts" in Microsoft Office". Not true. See, per my analysis with this event log, that little "Would you like to save your changes" box that pops at the end, when I close out a document prior to saving one last time, is considered an alert. Check it out:

I obviously generated this event for the purpose of this post, but the document that I had open is clear as day. Furthermore, we have an Event ID (300), that we can use to reference other events.

This event also told us the application that through the alert, there’s obviously an associated timestamp, as well as some other strings. Let’s examine those:

Breaking down the Events

Let’s examine the above event in a bit more detail.

  • Event ID 300 From what I can tell, each event I’ve been able to generate (force) is Event ID 300. I believe this might be a general “Office Alert” ID, but I’ll continue researching
  • P1: 200054 Currently, I think this value relates to the particular event and application that occured. For example, Excel may throw a “Want to Save” alert, but will not have the same P1 value as Word. The beginning digit (and possibly first 2–3 characters; still investigating) gives us an idea of which application threw the alert. Here’s a high-level of P1 value breakdowns:
  • 1x series — Microsoft Excel
  • 2x series — Microsoft Word
  • 3x series — Microsoft Outlook
  • 4x series — Microsoft PowerPoint
  • 5x series — Microsoft Access
  • 11x series — Microsoft Publisher
  • I’ve put up a GitHub file to track my progress on identifying unique OAlert P1 values as I go along. Feel free to have a look, and if you can expand, please contribute!
  • P2: 15.0.4420.1017 This clearly refers to the Office version number. Office 2013 is Office 15, technically.

Why do I care?

As a forensic investigator, the last thing I need is another minute artifact to pull information from. In some cases, this may be the, well, case. However, if you are looking to identify user activity during a period of time, items found in this event log may be able to identify what files a user interacted with. Will other artifacts sometimes also tell us this? Yes, of course they will. But I don’t mind a bit of certainty sometimes — I can also use events to prove interaction.

The second reason is that this event log, at least in my research, captures much more than simple “forgot-to-save” pop up boxes. Let’s look at the following errors:

While I’ve blocked out the email here, this event provides us an example of an account that is not associated with an Office product. Note that I had to enter my product key (not login via MS online), however this alert provided me with an email address that I may not have had via other means.

Let’s look at another event:

Hrm..now it’s possible we have an event of someone opening a file that they shouldn’t be? Note that our P1 value begins with 3, indicating Outlook.

Ok, one more:

Well this is a great alert. If we can determine what file a user was interacting with, and then see an alert that a sheet in Excel is being deleted, some more questions can be asked. This may also prompt an investigator, if they haven’t already, to examine the disk for earlier versions of a file to determine what exactly was deleted.

Conclusion

Is the practice of examining event logs anything new? No — event logs have been a great source of data for a long time to help understand what is going on with a system. I merely wanted to share my experiences, and hope that one day this research may help someone identify user activity, or help fill in a missing gap.

Happy forensicating!!


Originally published at www.505forensics.com on March 20, 2015.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.