A few weeks ago Dave Cowen did four nights in a row of Windows 10 testing and I finally got to watching through it all.
Some of it was Dave throwing around some ideas and testing them out, and some was showing some things that he’d previously found. All of it was good to see in action, despite the VM issues. The thing I most liked was Dave trying things out and getting suggestions from the crowd as to where to look for artefacts – a groups knowledge can help cover more bases. It also helps motivate people and avoid the whole burn-out thing.
Overall I can definitely see this as lowering the testing barrier to entry; just need someone to document it afterwards! So that’s what this is. I’ve probably missed some stuff, but easier to find in text form than in video/audio!
Dave downloaded this Win10 developer VM for testing purposes and set up his USN monitoring tool (which looks super useful for this kind of stuff) along with Eric’s Time Monitor to show time granularity.
This videos focus was on FAT32 and ExFat file systems and what interactions may update their access timestamps. Last Access date updating has been disabled since Win Vista for NTFS volumes so the tests here were to see if this applied to other file systems. Overall it didnt look like many interactions modified the Access Date on the files outside of the file being modified.
The testing also showed that changing the timezone, but not changing the clock, will change the times reflected on the files because FAT has no timezone precision.
Matt joined Dave for night two where they talked about the MFT/Logfile/USNJournal interactions. This was a little less testing, and a bit more showing stuff they’d seen before. It also exemplified the need for a live MFT monitoring tool (similar to the USN monitoring tool) because otherwise Dave needed to export and reparse using their Triforce tools after each test.
During the testing Dave showed that there are incrementing sequence numbers for some of the key NTFS files, which may be a bug, may be a feature, but is “normal”. Everything else should start with a sequence number of 1. The File name attribute name space for the first entries of the NTFS filesystem is 3, which indicates POSIX and was a US Government requirement at the time. Although this may have been disputed during the broadcast, not entirely sure. Either way, you can have up to 4 different file names, and I think 0 was unicode.
The testing here showed what happened with extracting files from ZIPs using different utilities.
- Windows-inbuilt – The ZoneID was carried over from the ZIP to the extracted file.
- 7zip – ZoneID was not carried over
- WinZip – Standard Information Attribute modified timestamps had 000 resolution; which one might confuse for timestomping. The reason being that ZIP files don’t have the timestamp resolution.
They also had some issues with the VM.
On the Third Night of Test-mas, Dave looked into the creation of LNK files and jumplist entries.
- Create a file in command prompt – no LNK file
- Open a file in the GUI – LNK, and jumplist entry created
- Create file in the GUI – LNK, and jumplist entry created
Creating a file with the same name results in the LNK file being deleted and recreated with the new contents; but because of file system tunneling the created time will stay the same. Apparently this has something to do with Microsoft Office. As a result, Dave recommends to carve for LNK files. Jumplists other hand have much larger capacities, so you’re more likely to find file access indication in there. I do have a post that I need to finish on jumplists on Win10, but I’d recommend carving for LNK entries in jumplists as well.
Dave then walked through some folders to show that interacting with files in certain folders (ie Inetcache) don’t result in LNK files being created. Something to do with them being temp directories, so I imagine creating a LNK file every time a temporary file is created would reduce the usefulness of LNK files. Apparently accessing files through Outlook also won’t result in LNK entries being created, with nothing being populated outside of the USNJrnl.
Lastly, Dave took at the Recentdocs key to show that creating a file with .tacos would show up in the registry, but not a .exe/.bat/.dll etc; even if those files just have the file extension and are opened in tools like notepad. No LNK files were created for opening ‘executable’ files either, even though they were opened with other tools. There should be other entries such as MRUs. I’m not sure if opening an ‘executable’ extensioned file would show up in the other places one would expect for executables (userassist, appcompatcache, prefetch). Something to look at next time.
Fourth night in a row! This time Dave took a look at timezone changes and whether Win10 logs them. The timezone key is great, but you can only see what it’s currently set to. Maybe you can find something in a VSC although I haven’t tested this. You’ve also only got the last write time to indicate when it was updated. And sometimes the value presented doesn’t make sense (ie Pyongyang has a really long value for the offset)
Every time the timezone was changed an event was logged in the System log with ID 1. This indicated that the clock had been changed. It would say that the timezone has been changed but it would identify what it was changed from or to. There is a setting in Win10 for setting based on location, but a) Dave couldn’t get that to update based on his current location and b) could just set a location and the timezone would update; so may be difficult to rely on for accuracy.
There was also some brief testing of Cortana, which showed that the voice search stored 8 previous entries and they were overwritten when a new search was conducted, which means if Cortana is being used then carving for wav files may be of value.
Alright, so that’s more or less it that I picked up from the videos. I’m sure I missed stuff, if anyone wants to add to the post just comment below!