Shimcache/amcache analysis timestamps

[nathaz09]

Hey team,

I've been playing with the shimcache/amcache analysis subcommand and the CSV output timestamps are not lining up as expected. Below is the command I'm using to execute Technique 2 (T2) – Shimcache Amcache Near Timestamp Pair Detection.

chainsaw analyse shimcache ./SYSTEM --amcache ./Amcache.hve --regexfile ../chainsaw/mappings/shimcache_patterns.txt --tspair --output output_new.csv

 ██████╗██╗  ██╗ █████╗ ██╗███╗   ██╗███████╗ █████╗ ██╗    ██╗
██╔════╝██║  ██║██╔══██╗██║████╗  ██║██╔════╝██╔══██╗██║    ██║
██║     ███████║███████║██║██╔██╗ ██║███████╗███████║██║ █╗ ██║
██║     ██╔══██║██╔══██║██║██║╚██╗██║╚════██║██╔══██║██║███╗██║
╚██████╗██║  ██║██║  ██║██║██║ ╚████║███████║██║  ██║╚███╔███╔╝
 ╚═════╝╚═╝  ╚═╝╚═╝  ╚═╝╚═╝╚═╝  ╚═══╝╚══════╝╚═╝  ╚═╝ ╚══╝╚══╝
    By WithSecure Countercept (@FranticTyping, @AlexKornitzer)

[+] Regex file with 15 pattern(s) loaded from "/Users/Documents/Chainsaw/chainsaw/mappings/shimcache_patterns.txt"
[+] Windows 10 Creators shimcache hive file loaded from "/Users/Documents/Chainsaw/ShimcacheTest/SYSTEM"
[+] Amcache hive file loaded from "/Users/Documents/Chainsaw/ShimcacheTest/Amcache.hve"
[+] 223 pattern matching entries found from shimcache
[+] 1 near shimcache & amcache timestamp pairs found (with 0 overlapping the pattern matched entries)
[+] 13 timestamp range matches found from amcache
[+] Saved output to "/Users/Documents/Chainsaw/ShimcacheTest/output_new.csv"

When I view the CSV the timestamps are not ordered in a linear format as demonstrated in the wiki. You can see in my output the times are out of order. I understand that each analysis technique has accuracy caveats and edge cases, however this ordering still seems drastically incorrect. I tested with Technique 3 (T3) – Shimcache Amcache Timestamp Range Matching and had the same results.

My CSV:

Wiki CSV:

I'm hoping anyone could provide an explanation for this or some guidance on execution.

Thanks!

[56616c6f72]

Hi there!

We came up with this method when we were contacted to deal with an incident where the breach had been going on for awhile with minimal evidence available. We had to get creative with the evidence we had to answer important questions such as when did the breach start. While we knew it was not perfect and had some caveats, it delivered consistent results with a bit of human reasoning. However, it was a super manual task, so we decided to automate.

As most incident responders experience at some point, the operating systems have a lot of edge cases and all tools get caught out. These are often hard to determine by investigators during the incidents if not documented. As responders who suffered this in the past, we looked to document any behaviour that might cause inaccuracies and catch responders off guard.

We documented all the caveats and edge cases we could think of and emulate on the blog post and the wiki. This is covered in the T3 Caveats section, sadly the "Out of Order Timestamps" issue is something we observed.

As shared on the blog:

There is a possibility that some of the timestamps inferred with this technique might produce out of order timestamps on the timeline. This is due to the fact that the Amcache key update timestamp might have occurred at a slightly different time than the Shimcache insertion. This is mostly a problem with Shimcache entries that were inserted in a burst during a short time frame.

@Markus98 was the legend who completed this research and built the tool for us. He might have more insight into it!

[Markus98]

My guess would be that the timestamp 19:54 in your screenshot was picked up by T1. The list of regexes was compiled by us and worked in testing, but it is possible that it contains entries that do not work in 100% of the cases. In these cases the Shimcache timestamp does not match the Shimcache insertion time. This could also be the source for the weird timestamps above the 19:54 entry in the screenshot.

The tool assumes that the timestamps acquired with T1 are 100% true with no checks or anything. This is why if there are any bad entries in the list of path regexes, it can produce weird results like this.

Your screenshot does not show the full path, so I cannot say for sure which regex pattern caused this issue. Maybe you can reveal the path / executable so that the issue could potentially be investigated further? Anyways, to work around this issue, you could make a copy of the shimcache_patterns.txt file and remove the regex line(s) that matches the path of the Shimcache entry that has the weird timestamp and pass that in as a parameter to the tool. You should get a cleaner timeline like this, but most likely with less timestamps.

Hopefully this helps or clears things up!

Thanks for the shout out @56616c6f72! 😄