Microsoft Office Macros continue to be the security nightmare that they have been for the past 3 decades. System and security admins everywhere continue to try to protect their users from prevalent macro malware, but they find Microsoft's tooling often less than helpful.

Case in point, the Microsoft page that describes how to disable macros sports this useful warning:

If only life were so easy.... The only two people who will ever be "sure" what a macro is doing are its original developer, and the malware analyst who just reverse engineered it. And I'm actually even doubtful about the developer.  

Considering how shaky and often bypassed the avialable mechanisms are to control macro usage, we would expect to at least see some decent instrumentation that allows us to log, monitor and reproduce "what happened". But... no. There are hardly any useful logs. Which over the years led to a plethora of work-arounds, YARA rules, Powershell scripts, and reverse engineering. 

This week, I had the "joy" of doing a bit of the latter, while investigating an incident. One of the few places where macro execution leaves traces is in the "TrustRecords" entry in the registry:

HKCU:\SOFTWARE\Microsoft\Office\16.0\Word\Security\Trusted Documents\TrustRecords
HKCU:\SOFTWARE\Microsoft\Office\16.0\Excel\Security\Trusted Documents\TrustRecords
HKCU:\SOFTWARE\Microsoft\Office\16.0\PowerPoint\Security\Trusted Documents\TrustRecords

The version number (16.0) might vary depending on your Office installation. Whether, when and how the keys get populated also depends on the "Trust Center" setting as described in the Microsoft link above.

But in general, the registry entries will look something like this:

The rightmost value (00 or 7f) indicates which trust center warning the user clicked away. "00" means "Open for Editing" and "7F" means "Allow Macros to Run". The other hex values encode, amongst other data, the original creation time stamp of the file whose name is shown. This can be extremely helpful when you need to determine the exact time of original download, if the file came from a shady source. In combination with the file name, this can be the "pivot points" that you need in an incident to go hunting in proxy or email logs, to determine how that file got to the user in the first place. 

Volatility has support to extract this information, but if you are forensicating on a live system, you can also wing it with Powershell in a pinch:

$regkeys =  'HKCU:\SOFTWARE\Microsoft\Office\16.0\Word\Security\Trusted Documents\TrustRecords',
            'HKCU:\SOFTWARE\Microsoft\Office\16.0\Excel\Security\Trusted Documents\TrustRecords',
            'HKCU:\SOFTWARE\Microsoft\Office\16.0\PowerPoint\Security\Trusted Documents\TrustRecords'
foreach ($key in $regkeys) {
        try {$item = Get-Item $key -erroraction stop} catch { $item = "" }
        foreach ($line in $item.property) {
            $values = $item.getvalue($line)
            if ($values[-1] -gt 0) {$type="RUN"} else {$type="EDIT"}
            $timestamp = [datetime]::FromFileTimeUtc([System.BitConverter]::ToUint64($values,0))
            Write-Output "$line $timestamp $type"
        }
}

Yep, not exactly the most beautiful code. It ain't my fault that Microsoft insists on using 64bits for a time stamp, nor that converting such a value back into human readable time is so convoluted in Powershell :).

In my case, for the registry screenshot shown above, the Powershell spits out the following

%USERPROFILE%/Downloads/invoice%2058633.xls 03/24/2021 23:52:21 RUN
%USERPROFILE%/Downloads/Invoice%2038421.xls 03/22/2021 23:45:42 EDIT
%USERPROFILE%/Downloads/Invoice%2094377.xls 03/22/2021 21:02:04 EDIT

which tells me that the file I want is "invoice 58633.xls", because for it, Macros were allowed to run. It also gives me a timestamp for when the user made the download - March 24, 23:52 UTC. 

If you have savvy ways of keeping track of or analyzing macro execution in your environment, please let us know, or share in the comments below.