OAlerts.evtx — The Hidden Microsoft Office Evidence Log

Most people have never heard of it. But when someone opened a suspicious file, deleted emails to cover their tracks, or tried to access an encrypted document they weren't supposed to — Office quietly wrote it all down.

---------------------------------------------------------------------------------------------------------

Wait, What Even Is OAlerts?

Okay let me start with a question. You know when you're about to close a Word document and it hasn't been saved, and that little popup appears saying "Do you want to save changes to Document1?" — that annoying box that's interrupted everyone's day a thousand times? Right. Turns out every single time that box appears, Windows writes a note about it. Name of the file. Timestamp. What the message said. Everything.

That's OAlerts.evtx in a nutshell. Every time Microsoft Office shows the user a dialog box — any application, any alert — the contents of that dialog get logged in a custom Windows Event Log file called OAlerts.evtx. It's been there since Office 2010 and most investigators completely miss it.

📁 Location:  C:\Windows\System32\winevt\Logs\OAlerts.evtx

You can open it directly in Windows Event Viewer — just search "event viewer" in the Start menu, navigate to Applications and Services Logs, and find OAlerts. Every single event in this log has the same Event ID: 300. That's it. Just one ID. The application name and the message content sit inside the event description, which is the part worth reading.

---------------------------------------------------------------------------------------------------------

Why Does This Matter Forensically?

Here's the thing — most forensic artifacts tell you what files exist.

• Shellbags show you folders that were browsed.

• LNK files show you files that were opened.

• Jump Lists show recently accessed documents.

  
  

These are all useful. But These artifacts do not reliably show content changes. That gap is a real problem when you're trying to prove someone tampered with data.

OAlerts fills that gap in a really specific way.

Because the "unsaved changes" dialog only appears when there are unsaved changes, seeing that event in the log is evidence that the file was opened and modified. The name of the file is recorded verbatim in the log entry. That's far more than most artifacts give you.

One more thing worth calling out:

it doesn't matter where the file lives. Local drive, USB stick, network share — if Office shows a dialog about it, OAlerts records it. That means you can catch file activity on removable media that other artifacts might miss entirely.

---------------------------------------------------------------------------------------------------------

The Scenarios You'll Actually Encounter

Let's go through the real situations where OAlerts becomes useful. These aren't edge cases — I've ordered them by how often they come up in investigations.

---------------------------------------------------------------------------------------------------------

Real Examples — Let's Look at Actual Events

This is where it gets interesting. Let me show you three events you might encounter — the kind that show up in real investigations. Notice how the log records the dialog message word for word. Whatever Windows showed the user on screen is exactly what ends up in the log.

Example 1 — Someone opened something they shouldn't have

This one is a classic. Someone on the system had a document called "handles.xlsx" open in Word. They closed it without saving. Word showed the standard "save changes?" dialog — and OAlerts faithfully recorded the entire thing, including the filename.

Now we know this document existed on this machine, was opened in Word, was modified (because unsaved changes existed), and the user interacted with it at this exact timestamp.

Example 2 — Someone emptied their email trash

Outlook is one of the most forensically opaque applications in the Office suite — there aren't many artifacts that track what a user actually did inside it.

OAlerts is one of the few exceptions. When a user right-clicks their Deleted Items folder and chooses "Empty Folder", Outlook asks for confirmation first.

That confirmation dialog — and the fact it was triggered — goes straight into OAlerts.

Worth noting:

OAlerts doesn't record which user account triggered the event. The log entry itself doesn't have user identity. But you can cross-reference it with Windows Security Event Log logon events (4624/4648) around the same timestamp to work out who was active on the machine at that moment.

Example 3 — Wrong password on an encrypted document

This one is particularly interesting for insider threat investigations. When someone tries to open a password-protected Office document and enters the wrong password,

Word shows an error dialog. And yes — OAlerts records that too.

You'll see the filename and a note that the password was incorrect. This could mean the document was encrypted and the person trying to open it wasn't supposed to have access.

---------------------------------------------------------------------------------------------------------

At a Glance — Common Events You'll See

Here's a quick reference of the most common scenarios you'll encounter in this log, what they look like in the event description, and what each one tells you forensically.

--------------------------------------------------------------------------------------------------------

Connecting OAlerts to the Bigger Picture

OAlerts doesn't tell you the whole story on its own — but it connects really well with other artifacts. Here's how I think about combining it with other evidence sources.

Think of it this way:

OAlerts tells you what happened (a specific file was modified, emails were deleted, a bad password was entered). The Security Event Log tells you who did it (which account was logged in). LNK files and Jump Lists tell you where the file lived (the full path on disk). Together they build a timeline that's hard to dispute.

---------------------------------------------------------------------------------------------------------

How to Collect It During an Investigation

Collecting OAlerts.evtx is the same as collecting any other Windows event log.

The file lives at C:\Windows\System32\winevt\Logs\OAlerts.evtx. 

On a live system you can copy it with administrative rights. On a forensic image you just navigate to that path within the image and extract it.

For parsing, my Favorite options.

Eric Zimmerman's EvtxECmd.exe will parse it cleanly into CSV and you can open it in Timeline Explorer — which means OAlerts events slot right into the same workflow as your other SRUM and event log data.

Log Parser and PowerShell's Get-WinEvent both work too.

---------------------------------------------------------------------------------------------------------

Quick Reference

--------------------------------------------Dean----------------------------------------------------