Sunday, December 9, 2018

Daily Blog #562: Sunday Funday 12/9/18

Hello Reader,
        We've had a lot of different kinds of challenges to attract different people within the community to participate. This week I'm changing the challenge up again to open up who can participate this week in a test of your google and basic code reading skills.

The Prize:
$100 Amazon Giftcard

The Rules:

  1. You must post your answer before Friday 12/14/18 7PM CST (GMT -5)
  2. The most complete answer wins
  3. You are allowed to edit your answer after posting
  4. If two answers are too similar for one to win, the one with the earlier posting time wins
  5. Be specific and be thoughtful
  6. Anonymous entries are allowed, please email them to dcowen@g-cpartners.com. Please state in your email if you would like to be anonymous or not if you win.
  7. In order for an anonymous winner to receive a prize they must give their name to me, but i will not release it in a blog post


The Challenge:
Find all the projects out there that are making use of DFVFS (https://github.com/log2timeline/dfvfs) with a description of what the code does with it. Let's see if we can find all the possible exemplar code bases out there to help others adopt this framework!

Saturday, December 8, 2018

Daily Blog #561: Solution Saturday 12/8/18

Hello Reader,
       Another challenge where a new victor has emerged! One of the great things about these weekly challenges is that let's people within the larger community a chance to show what they got. This week Zach Stanford has made his mark with his winning submission.

The Challenge:


Document the order that the following shims are executed/data written in Windows 10:
  • Prefetch
  • Shimcache
  • Amcache
  • Userassist
  • SRUM
List the time stamps associated with the entry creation and whatever else you can determine about the order they are called

The Winning Answer:
https://medium.com/@z89127866x/battle-of-the-shims-60fdae38264e

Come back tomorrow for the next week's challenge!

Daily Blog #560: Forensic Lunch 12/7/18

Hello Reader,
        This week we had a Forensic Lunch with Eric Zimmerman! We talked about

You can watch the video here:

Thursday, December 6, 2018

Daily Blog #559: Forensic Lunch Test Kitchen 12/6/18

Hello Reader,
  Tonight we tested the new NTFSDisableLastAccessUpdate registry key in Windows 10 1803. Here's what we learned:

  • We learned that reading double negatives can be hard, it turns out my system did have last access dates on (value of 2) as Maxim Suhanov stated as my system drive was <= 128gb in size
  • We learned that drives larger than 128gb in size (my host system) have last access dates off (value of 3)
  • We learned that changing the value from 2 to 3 will be reversed on reboot as system managed really does mean system managed. 
  • We learned that changing the value from 2 to 1 will remain 1 on reboot meaning user managed will not be overruled by the system on reboot.
  • We learned that we will have to double check every system now because as of Windows 10 1803 we may have updated last access dates again!
You can watch the video here:

Wednesday, December 5, 2018

Daily Blog #558: Forensic Lunch Test Kitchen 12/5/18

Hello Reader,
     Tonight we were testing the Syscache.hve that Maxim Suhanov found in his testing of the Amcache and Recentcache.bcf files, you can read his write up here: https://dfir.ru/2018/12/02/the-cit-database-and-the-syscache-hive/

From our testing tonight here is what we learned:

  • The syscache hive has three indexes
    • The ObjectID key (no relation to $objid) which is inserted into the hive sequentially as new executables are run (we haven't tested executables being prechecked before running)
    • The FileID key which is indexed off of the sequence and entry number of the file being executed
    • The Objectlru which appears to connect the two
  • The ObjectID keys contain the SHA1 hash of the contents of the executable being checked
  • The ObjectID keys contain the MFT reference number of the executable being checked
  • The ObjectID key does not contain the name of the executable, but you can find it by looking up the MFT reference number
  • The Syscache hive appears to be updated quite quickly and is not using the transaction logs to do so 
  • The syscache hive is a Windows 7 feature (haven't tested windows vista) and does not exist in the same location at least in Windows 10
  • The key write time appears to be the time of first check for the current hash, we will change the hash of a known executable to test this behavior tomorrow night
You can watch the video here:

Tuesday, December 4, 2018

Daily Blog #557: Changes in the NtfsDisableLastAccessUpdate key

Update 12/6/18: It turns out that my test system had a system volume smaller than 128gb in size meaning the last access dates were enabled (setting 2). According to @errno_faiil (Maxim Suhanov) if my system driver was larger than 128gb then the last access dates would be disabled (setting 3).

Want to know more? Watch this video: https://www.youtube.com/watch?v=yHG6MEH99Z0

Hello Reader,
        It looks like as of at least Windows 10 1803 a new change has come to an old registry key. The NtfsDisableLastAccessUpdate key found in 'SYSTEM\CurrentControlSet\Control\FileSystem' no longer is just a true/false 1/0 value. It now has four possible values stating how the access dates in NTFS were enabled or disabled.

Looking at my laptop's registry I can see the following value is currently set:

which leads to the question of... what does 80000002 mean? Luckily fsutil will translate the current value for us:


So the 8 appears to be some kind of upper bit masking while the 2 is the value set letting us know that NTFS Access updates are currently disabled by system policy.

Checking the set behavior command in fsutil shows us all the possible documented options:

As you can see we've moved from two possible states (on/off, true/false, 0/1) to four. The system is now tracking if the user or the system has enabled or disable last access dates in NTFS.

Why? I have no idea currently but it certainly does add more context to the decision. So all of you who have tools that interpret this value will need to update your tools!



Daily Blog #556: NCCDC Red Team Call for Volunteers

Hello Reader,
         It's coming around to CCDC competition time for much the of the United States, some schools are already in invitationals. This is the yearly call for volunteers for the NCCDC red team. If you have the following to bring to the table:


  • Custom malware
  • Custom command and control 
  • An active Github repository 
  • The ability to lay low and persist with an active defender
If so, email your cv to volunteer@nccdc.org Spots are limited each year for volunteers and we hope to hear from you.