Skip to content

Latest commit

 

History

History
87 lines (63 loc) · 5.11 KB

S01E06.md

File metadata and controls

87 lines (63 loc) · 5.11 KB

🐾 S01E06 - Registry tracks

The registry modification was done in PowerShell through the Invoke-WmiMethod:

Invoke-WmiMethod -Class StdRegProv -Name SetStringValue -ArgumentList (2147483649,"SOFTWARE","Yes","CanBeDeleted")

So it will create a registry string value CanDeDeleted set to Yes under HKEY_CURRENT_USER\SOFTWARE. Here is mapping table for the hive numbers used in the method:

Hive Hexadecimal value Decimal value
HKEY_CLASSES_ROOT 0x80000000 2147483648
HKEY_CURRENT_USER 0x80000001 2147483649
HKEY_LOCAL_MACHINE 0x80000002 2147483650
HKEY_USERS 0x80000003 2147483651
HKEY_PERFORMANCE_DATA 0x80000004 2147483652
HKEY_CURRENT_CONFIG 0x80000005 2147483653
HKEY_DYN_DATA 0x80000006 2147483654

What do we see from this in the local system?

❓ What is there by default?

Again, nothing. But like other operating system, the right combination of Advanced Audit Policy and SCAL will generate traces in the Security event log.

The Registry audit subcategory needs to be enabled:

auditpol /get /subcategory:"Registry"
System audit policy
Category/Subcategory                      Setting
Object Access
  Registry                                Success and Failure

And SACL needs to be set on the registry object. Then a modification will generate the event 4657:

4657

Note that since the registry modification was done through the StdRegProv WMI provider, the process name noted for this event is WmiPrvSE.exe.

That's pretty much all we have out of the box and since we can't practically enabled SACL for modification everywhere, we have to be selective or be ready to handle a flooding of 4657.

🙏 Sysmon to the rescue!

Sysmon and a good configuration file (such as the one suggested by SwiftOnSecurity) will help us with bringing a good balance between noise and threat detection. It would not have helped us for our macro because it is writing in a harmless place, but if the macro did try to write somewhere fishy, then Sysmon would have generate an event 13.

Just for the sake, if we had configured Sysmon to track modification under the HKEY_CURRENT_USER\SOFTWARE, this is what we would have seen in the Microsoft-Windows-Sysmon/Operational event log:

13

🙈 What if we don't have anything in the log?

Registry keys have metadata which are not visible with the regular tools (such as regedit.exe). Each key is storing a timestamp of last write time. It is at the key level, not at the value level. So if there are multiple values in a key, the timestamp will not tell us which value was last change. But we would know that something has changed.

To see those timestamps, you can select a key in regedit and chose to export it in a text format. Regedit export Then the timestamp will show up at the key level: exported

So if we have traces of processes that are known to be able to modify the registry such as:

  • reg.exe
  • regedit.exe
  • powershell.exe
  • powershell_ise.exe
  • cscript.exe
  • ...

We can try to infer if they modify the registry at their time of execution (from the process creation event 4688 to process termination event 4689) by looking at the last write time of all registry keys (not 100% reliable as they could have been rewritten since, but better than nothing). To help with that endeavour, we can use the command line tool from Eric Zimmerman's toolset RECmd. Example of a partial command:

RECmd.exe --StartDate "10/29/2021 15:35:01" --StoptDate “10/29/2021 15:40:00" ...

Note that there is also a graphical version of this tool available Registry Explorer. Which can show those timestamps along with other interesting things such as deleted keys and disassociated keys. It also has a set of bookmarks to quickly go to the known registry paths useful for troubleshooting and/or investigation.

👁‍🗨 What do we see in MDE?

The is a table available in Advanced Hunting in the Microsoft 365 Defender portal: DeviceRegistryEvents. This is populated by Microsoft Defender for Endpoint.

MDE

It does not contain all registry modifications. It only has the one known to be potentially used by TTPs. In our macro case, since we were not doing anything fishy, MDE didn't care to log the action in this table. Remember that if you run a query against the DeviceRegistryEvents and get not results, it doesn't mean that what you are looking for didn't happen. It could mean that we don't collect the data. However, if you get a match, you have a true positive.

📝 Summary

Event ID Event Log Enabled by default Builtin feature Notes
4657 Security No Yes Requires SACL and can be very verbose
13 Microsoft-Windows-Sysmon/Operational No No Can be very verbose depending on the Sysmon configuration