Hello Reader,
Tonight we continue to go down further into the application compatibility cache and its associated artifacts. Thanks to tonight's BFFs (Best forensic friends) Phill Moore, Jessica Hyde and Mike Cary for participating in the testing! Here is what we learned:
Tonight we continue to go down further into the application compatibility cache and its associated artifacts. Thanks to tonight's BFFs (Best forensic friends) Phill Moore, Jessica Hyde and Mike Cary for participating in the testing! Here is what we learned:
- Approximately 6 hours or so after the tests were done on 11/16/18 in the prior video (https://www.hecfblog.com/2018/11/daily-blog-540-forensic-lunch-test.html) the entries we expected to show up in the Amcache were written to the registry
- In addition to the programs we executed being delayed in their writes, we also had more programs we extracted in the GUI but did not execute show up in Amcache
- The timestamp of the key here did not reflect when the program executed but rather when it was added to the Amcache hive! We are setting up more testing to determine what the triggers are for Amcache updating
- Extracting an executable from a zip file in the command line did not result in a Shimcache or Amcache entry being made, as suggested by Mike Cary on twitter.
- Executing an executable from the command line did get an entry in the shimcache on shutdown and reboot
- We had an inconsistent result in the amcache on execution where once it appeared after shutdown and another time it didn't
- We have enabled process creation event logging and the VM will run overnight to see when and what hopefully is updating the Amcache
You can watch the video here:
Also Read: Daily Blog #542
Post a Comment