The user opened the Excel file directly from Outlook. Let's see what traces it left by default and let's see how to enhance that.
As long as the advanced audit policy subcategory Details Tracking/Audit Process Creation is enabled for Success (which seems to be the default setting in Windows), it will generate an event in the Security event log.
In order to get the affective audit policy on a system, the only reliable way it to run the following command:
auditpol.exe /get /category:*
This command requires the SeSecurityPrivilege privilege (therefore, it will have to run elevated to produce results). Note that this command has to run locally. It can't be ran remotely like in the Windows Server 2003 version of the command. To run it remotely, you can use PowerShell session against the target system. For example:
Invoke-Command -Command {auditpol /get /category:*} -ComputerName SECCLT01
Here is one of the event 4688 generated by the user opening Excel from Outlook:
Note that in the screenshot, the line Process Command Line (CommandLine in the XML structure) has the full command used to start the process. Very useful as it also has the file name (which here also confirm that it is running an attachment from Outlook as the path of the file is in the \AppData\Local\Microsoft\Windows\INetCache\Content.Outlook\...). This is NOT the default behavior. The following setting in the local policy (or through group policies) has been enabled on the client to get that information:
Local Computer Policy
↘ Computer Configuration
↘ Administrative Templates
↘ System
➡ Audit Process Creation
Super practical! But could also lead to information disclosure as if a secret is typed in a command line used to launch a process, that secret will be in clear text in the Security event log. Yet, it seems that the pros outweigh the cons as the value of the data in contains is critical for security monitoring. For example, if a VBS script is executed, the event 4688 would only show that cscript.exe was running. With the Audit Process Creation on, we can even see what script was running.
Here is a mapping of what the cryptic value starting with a %% for the TokenElevationType means:
| Value | Description |
|---|---|
%%1936 |
Type 1 is a full token with no privileges removed or groups disabled. A full token is only used if User Account Control is disabled or if the user is the built-in Administrator account or a service account. |
%%1937 |
Type 2 is an elevated token with no privileges removed or groups disabled. An elevated token is used when User Account Control is enabled and the user chooses to start the program using Run as administrator. An elevated token is also used when an application is configured to always require administrative privilege or to always require maximum privilege, and the user is a member of the Administrators group. |
%%1938 |
Type 3 is the normal value when UAC is enabled and a user simply starts a program from the Start Menu. It's a limited token with administrative privileges removed and administrative groups disabled. The limited token is used when User Account Control is enabled, the application does not require administrative privilege, and the user does not choose to start the program using Run as administrator. |
In our case, the event 4688 does has the value %%1938, so we can determine that the user is not running the process as an admin.
- The user started Outlook at some point... We'll skip that one, not super interesting really, Outlook is often running all the time.
- The user opened the attachment from Outlook, so Outlook started Excel.
- Excel started the macro which launched PowerShell.
For the 4688 of Excel, see in the section above. Here is the 4688 of PowerShell
We can see the full command (obfuscated, well in base64) passed in parameter by the macro to PowerShell.
Here is the process tree view in the device timeline in Microsoft Defender for Endpoint:
💡 Note that PowerShell is starting conhost.exe. We won't focus on that at all yet. But that's an interesting artifact as its presence tells us that some command line based application is running. See here for some more details.
Here we are talking about AppLocker in audit mode as some enable it that way to enrich their logging capabilities. It generates events in a separate event logs, the Microsoft-Windows-AppLocker event log, therefore the events will not drown in the middle of millions of non-process related security events, and one can configure their one rules. Not to mention that the data you get at the end could be used to enabled AppLocker in enforce mode later on.
To enable AppLocker, the Application Identity service (AppIDSvc) must be running:
And the minimum required is to have the audit mode on for executables with the default rules enables.
Then when the process is running, we would get the following event 8002:
Which doesn't show much n the General tab, but in the Details tab:
A lot of interesting information not available in the 4688 such as digital signature information or FileHash.
AppLocker uses SHA256 to generate the hash. However, if the file is an signed executable, the hash generated will be using the Authenticode way. Mind the following difference:
Anyhow, PowerShell execution will also be generating an event 8002:
If Sysmon was installed with the default configuration, such as:
sysmon -i
This would have generated an event 1 in the Microsoft-Windows-Sysmon/Operational event log.
So, here is the Excel execution in Sysmon:
As well as PowerShell:
This time, the SHA256 hash of the file is matching what you would have using the cmdlet Get-Filehash.
Although not a focus of this season, here is what we see in Microsoft Defender 365 portal (assuming the victim's device was onboarded in Microsoft Defender for Endpoint). We can see most of what has happened in the device's timeline:
Note that it also decoded the base64 PowerShell command.
💡 Note that things might not be in the exact order. There are an event time and an execution time which display some latency. So two entries of two different categories in the timeline might have different latency of generation and might be displayed in the right order (not by far, but it has to be taken in consideration).
Although not a focus of this season, you can find traces of process execution in the prefetch files of the operating system (if those are available/the feature in enabled). Other artifacts such as ShimCache and AMCache would not help us here as the processes involved here are common processes which frequently run on the local system. However, the prefetch might give us some info:
Processing 'C:\Windows\Prefetch\EXCEL.EXE-9231AABD.pf'
Created on: 2021-08-12 21:06:03
Modified on: 2021-09-09 15:23:41
Last accessed on: 2021-09-09 17:39:06
Executable name: EXCEL.EXE
Hash: 9231AABD
File size (bytes): 389,696
Version: Windows 10
Run count: 8
Last run: 2021-09-09 15:23:31
Other run times: 2021-09-09 15:23:17, 2021-09-02 13:58:13, 2021-09-02 13:58:09, 2021-08-27 15:05:55, 2021-08-27 15:05:45, 2021-08-12 21:05:55, 2021-08-12 21:05:48
Files referenced: 501
…
365: \VOLUME{01d6a756f5e84343-6cf64c9c}\USERS\VERENA\APPDATA\LOCAL\MICROSOFT\WINDOWS\INETCACHE\CONTENT.OUTLOOK\ICTS0NDJ\AHAH-MACRO (002).XLSM
366: \VOLUME{01d6a756f5e84343-6cf64c9c}\USERS\VERENA\APPDATA\LOCAL\MICROSOFT\WINDOWS\INETCACHE\CONTENT.OUTLOOK\ICTS0NDJ\~$AHAH-MACRO (002).XLSM
…
This output was generated with Eric Zimmerman's tool PECmd.
| Event ID | Event Log | Enabled by default | Builtin feature | Notes |
|---|---|---|---|---|
4688 |
Security |
Yes | Yes | Command Line auditing is off by default |
8002 |
Microsoft-Windows-AppLocker/EXE and DLL |
No | Yes | Audit mode |
1 |
Microsoft-Windows-Sysmon/Operational |
Yes | No | Enabled in default installation config |