Daily Blog #524: Forensic Lunch 10/31/18

Hello Reader,
             This week on the Forensic Lunch we had Hal Pomeranz talking all about XFS file systems and XFS forensics. Tune in and hear about how XFS works and what we can recover:


Daily Blog #523: Forensic Lunch Test Kitchen 10/30/18

Hello Reader,
         Another test kitchen focused on the Recycle.Bin tonight continuing last nights testing. Last night the question we were left with is what triggers the initial creation of the Recycle.Bin directory since its not part of the initial format. Here is what we learned:

  • Creating a file on the drive will trigger a Recycle.Bin
  • Waiting 5 minutes will create a Recycle.Bin even if no file is created
  • Waiting 5 minutes when a drive with a Recycle.Bin created from another system does not create a directory for that user's sid
I'm leaving the drive plugged into the second system to see if overnight the recycle bin creates the sid named directory.

You can watch the video below:

Daily Blog #522: Forensic Lunch Test Kitchen 10/29/18

Hello Reader,
        Tonight on the test kitchen we followed up on a viewer request from Neck aka @AaronSWeiss  on twitter to do some $Recycle.Bin testing on Windows 10 and Windows 7. I validated some facts I've tested before, but not necessarily on Windows 10 as well learned new things.

Here is what we learned:

  • On a fixed disk NTFS drive the $Recycle.Bin will be created as soon as a user copy a files on a drive
  • The $Recycle.Bin will contain the sid of the user interacting with the drive
  • If the NTFS drive is plugged into another system with a $Recycle.Bin already present the next system will create a directory under the $Recycle.Bin directory with that user's SID
  • That the $R files in the recycle bin are really just renamed operations changing the original file name and parent directory on the disk
  • That every fixed disk has its own recycle bin, even though Windows presents a unified view
  • That on FAT formatted fixed disks that $Recycle.Bin's do not contain a SID directory
  • That on FAT formatted fixed disks moved between systems that both systems will share the same $Recycle.Bin directory
Here is the video:

Daily Blog #521: Sunday Funday 10/28/18

Hello Reader,
              In an attempt to engage you and get your inner researcher going I'm again changing things up this week. This week let's get back to basics and see what you can tell me.

The Prize:
$100 Amazon Giftcard

The Rules:

  1. You must post your answer before Friday 11/2/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:
What does performing a copy and paste across two NTFS volumes do to timestamps of the file being copied and the file that is created due to the copy in Windows 7 and Windows 10.

Daily Blog #520: Solution Saturday 10/27/18

Hello Reader,
     No winners this week, let me know what's holding you back from entering!

Daily Blog #519: Forensic Lunch Test Kitchen 10/26/18

RDP Testing with NLA Testing of the OSX RDP v8 by David Cowen - Hacking Exposed Computer Forensics Blog



Hello Reader,
           Well I didn't have time today to do a forensic lunch which means tonight we had another Test Kitchen! I will have to do a forensic lunch early next week to meet the two broadcast a month goal of the forensic lunch, likely Tuesday unless we have a special Halloween edition! I'll line up guests and follow up with. Tonight we continued our RDP testing with NLA testing of the OSX RDP v8 client as suggested by Mike Carey and also testing Beau Bollock's statements regarding the logging or lack there of ip addresses when NLA is present prior to Server 2016.

Here is what we learned:

  • The OSX RDP v8 client is in fact doing NLA, at least the version I tested. Meaning we got a type 3 4624 event in the security log.
  • That the OSX RDP v8 client provides the hostname of the OSX system
  • That the OSX RDP v10 client does not provide the hostname of the OSX system
  • That Windows 10 does log IP and Hostname from failed NLA logins with valid usernames 
  • That Windows 7 does not log IP addresses but only hostnames when handling failed logins with NLA. But we found this was true for invalid as well as valid usernames. 

You can watch the video of our testing here:



Also Read: Daily Blog #518 

Daily Blog #518: Forensic Lunch Test Kitchen 10/25/18

Hello Reader,
               Tonight's test kitchen continued last nights RDP focused testing. Tonight we went through the event logs using the TZWork's tool evtwalk to find all event logs that referenced our host ip addresses we used in the rdp connections along with our hostnames. We also manually turned off NLA to see what it would do to our new Type 3 4624 events and lastly we tested Microsofts RDP client for OSX.

Here is what we learned:

  • We didn't find any new logs on the rdp server side than what we expected
  • We did find that connections we made out via rdp and smb are logged in Windows 10 by default but not Windows 7
  • We found out that turning off NLA by editing the rdp connection file will prevent the type 3 events from occuring during the rdp login
  • We found out that Microsoft RDP client for OSX is also doing NLA by default but isn't passing in the workstation name in the type 3 4624 event

You can watch the video here:

Daily Blog #517: Forensic Lunch Test Kitchen 10/24/18

Hello Reader,
         Another test kitchen with a lot of you tuning in live with a very short notice! Thanks to everyone who made the live broadcast, it really does make the whole thing way more fun for me when all of you get involved. Tonight we continued digging into rdp events looking to understand when and how remote client names got stored when a system rdp's into another computer.

We learned that:

  • When a windows native rdp client connects to a rdp server, even if NLA is not enabled by default, that it will attempt NLA (Network Layer Authentication)
  • That since it attempts NLA before the type 10 4624 event that only contains the ip address of the rdp client you will also get a type 3 4624 event both in the system log. The Type 3 4624 event will contain the rdp client's hostname and ip address. All of these events are in the security log. 
  • That the type 3 and type 10 logins will have their own loginid's to track their session and they will end very closely to each other when the session ends
  • That the linux rdesktop command has the ability to pass a rdp client hostname but it doesn't appear to be accepted
  • That the linux rdesktop command will also start with a type 3 4624 event but it does not appear that it stores the ip address or the hostname of the rdp client
Tomorrow night we will parse through all the logs using either Tzworks evtwalk tool or our eventmonkey tool (depending on what I have time to setup) and look to see if any other log got our ip address or hostname

You can watch the video here:

Daily Blog #516: Forensic Lunch Test Kitchen 10/23/18 - Focus on RDP Brute Forcing Using Ncrack, Hydra, and Patator

Focus on RDP Brute Forcing Using Ncrack, Hydra, and Patator by David Cowen - Hacking Exposed Computer Forensics Blog



Hello Reader,
        We had another test kitchen tonight with a focus on rdp brute forcing windows system from Kali attempting to use ncrack, hydra and patator. We had mixed results but here is what we learned:


  • Windows 10 RDP appears to not be compatible with Ncrack or Hydra. Neither could attempt to login
  • Patator requires FreeRDP to be installed, which is needs way more dependencies that I expected
  • Windows 7 RDP works as expected and Ncrack was able to generate failed logins
  • None of the testing we did got our remote workstation names to appear in the event logs. We tried native rdp from windows 10 vm, native rdp from windows 10 host, and linux based rdesktop along with ncrack
  • The Terminal Services Remote Connection Manager log will record any attempted authentication as a success, even if the account does not exist
More testing tomorrow night to see if we can find out why we aren't getting remote workstation names as expected from the Microsoft Documentation. 

You can watch the video here:


Also Read: Daily Blog #515 

Daily Blog #515: Asking for your input regarding future testing

Hello Reader,
                I'm not doing a test kitchen tonight. However I thought I would take this opportunity to ask you dear reader what you want to see tested. Currently my plan is to:


  • Finish testing ObjectIDs
  • Finish the bitlocker update test
  • Continue testing extended mapi data
  • Test more attacker tools and deep dive what traces they leave 
What other topics are you interested in seeing in the test kitchen? 
Are there artifacts you don't understand or think need more validation?
Are there open questions you have that you don't have the time to answer?

Then dear reader please comment below or send me a tweet or a linkedin message and let me know!

Daily Blog #514: Sunday Funday 10/21/18

Hello Reader,
       Adam Harrison returned this week to reclaim the prize, but every week is a new week and a new challenge. This week we are mixing things up both in the test kitchen were we are focusing on traces left behind by popular pentest tools and the sunday funday challenges to. I focus on a lot of host artifacts because of the work I do, but there is a world of intrusion artifacts out there as well that I want to make sure people are aware of.


The Prize:
$100 Amazon Giftcard

The Rules:

  1. You must post your answer before Friday 10/26/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:
What are the differences between a normal windows type 3 login (network share) and one from tools found in Kali that support either brute forcing logins or accessing shares. Include both the differences in successful attempts as well as failed attempts at access. 

Daily Blog #513: Solution Saturday 10/20/18

Hello Reader,
      While this weeks winning answer did not directly answer the challenge asked it is the most complete and fills in some much needed knowledge. Congratulations to returning Sunday funday champion Adam Harrison for this weeks answer.


The Challenge:
What artifacts of execution exist on a Windows Server 2008+ that do not exist on Windows 7+? In other words name any forensic artifacts that would show a program executed on a windows server os that you wouldn't find on a windows desktop os!

The winning answer:
Adam Harrison

In response to this weeks challenge I undertook to documents as many artifacts as I could think of/search out which evidence program execution, and to determine which Windows operating systems these artifacts are availablefor.

To be up front, I did not identify any which were explicitly available in Windows Server 2008+ but not in the Desktop counterparts. With that said the following artifacts are, in my opinion and experience more commonly available within Windows Server:

  • Event ID 4688 - Requires enabling and in my experience I have seen it more commonly enabled on Servers than Desktops.
  • IDS - Host based IDS running on notable servers

Other artifacts considered and detailed in the table and post below include:
  • Prefetch
  • ShimCache
  • MUICache
  • Amcache
  • RecentFileCache.bcf
  • Microsoft-Windows-TaskScheduler (200/201)
  • LEGACY_* Registry Keys
  • Microsoft-Windows-Application-Experience Program-Inventory
  • Microsoft-Windows-Application-Experience Program-Telemetry
  • BAM
  • SRUM
  • ActivitiesCache.db
  • Security Log (592/4688)
  • System Log (7035)
  • UserAssist
  • RecentApps
  • JumpLists
  • RunMRU
  • AppCompatFlags Registry Keys
  • AV/IDS/EDR

In many instances these are more common to be found/enabled on a Windows Desktop rather than Server, as opposed to the other way around.

The fuller description of all the execution indicators I was able to think of and find, and details as to which OS versions they exist for is laid out in the following blog post:

The key spreadsheet documenting the artifact availability is available here:

It is my intention to keep the spreadsheet updated and and feedback, additions or corrections are gratefully received.

Daily Blog #512: Forensic Lunch Test Kitchen 10/19/18

Hello Reader,
        Another test kitchen on the books! Tonight we took a break from ObjectIDs and took a look at something I've been wanting to test for awhile, smb brute forcing tools. We ran a couple SMB Brute forcing tools:

  • Hydra
  • Medusa
  • Ncrack
  • Nmap's SMB login script
  • Metasploits smb_login module
  • Patator
And then went into the windows event logs to determine what they left behind that would make it obvious this was a third party smb network client trying to brute force in and not a native windows smb client. 

We learned:
  • Windows 10 does not have logon failure auditing on by default
  • Hydra, Medusa, Nmap and Ncrack will provide the IP Address instead of the workstation name in the event logs, which isn't normal
  • Metasploit's smb_login module will set the workstation name to WORKSTATION in the event logs, which isn't normal
  • Patator which is using the impacket smbconnect script passes in a null workstation name, which is again not normal
  • That as of Windows 8 and Sever 2012 there is a new event log source called SMBServer which logs just SMB data, including SMB authentication failures. Very useful when the security log rolls over and is on by default!
You can watch the video here:

Daily Blog #511: Forensic Lunch Test Kitchen 10/18/18

Hello Reader,
             Back to the test kitchen tonight! While tonight's broadcast was a later than normal (showed the kids the few episode of the new Doctor Who season) we did have some good testing done. Tonight we tested my theory of what was recoverable from an external drive formatted NTFS in regards to ObjectIDs. The theory being that we could use the existence of ObjectIDs to show that files were interacted with after being copied, which is important since access dates are no longer updated when a file is opened on a NTFS drive since Windows Vista.

Tonight we learned:

  • ObjectID attributes are set on files accessed from external fixed disks
  • The /$Extend/$ObjID:$O Index root is created when a drive is formatted
  • The $ObjID:$O Index allocations are not populated on the external drive when objects are created within the file system
  • The $logfile will create a record storing the ObjectID that was set, when it was set or changed
  • The $UsnJrnl:$J will contain a timestamped record showing when objectids were set allowing an examiner to timeline when the actions took place
  • With the $logfile records you could determine which Mac address opened the files, when the objectid was set and when the file was deleted
  • With the $usnjrnl records you could determine when the objectid was set and when/if the file was deleted
You can watch the video here:

Daily Blog #510: Office 2016 Backstage Artifacts

Hello Reader,
         New versions of software often bring new artifacts and Office 2016 is no exception. We were working an investigation when we found directory paths that no longer exist on the disk under a directory called:

 '\Users\\AppData\Local\Microsoft\Office\16.0\BackstageInAppNavCache\'

Underneath that directory you will find a series of directories for each of storage locations the user could save files for example:

  • My Computer
  • Onedrive Personal
  • Onedrive business
  • Sharepoint


This will match up to the view you will see when you open a file in Microsoft Office from the 'Backstage' view. Backstage is Microsoft's term for the interface where you can load recently accessed documents before picking a document and after loading Microsoft Office program.  Here is an example form my system:



In the above screenshot I started Microsoft Word, selected open other locations from the bottom and then clicked 'This PC'. It defaulted to my documents directory and then switched over to a newly mounted VHD drive.

On entering the directory from this interface I got a file created in the BackstageInAppNavCache\My Computer directory for the D drive that contained the full path, file name and modification date in Windows filetime format for all of the directories and files on my D drive separated between folders and files.

Here is the folder view:

The last element is the filetime timestamp in decimal format, converting it to hex and putting it into Dcode shows the following:

In addition there is a section for files as seen below:

What was interesting to me on the file section is that the GUI is only showing me the word file, but the cache file shows all files in this directory.

On my system this directory goes back a couple years worth of what was in every directory I've viewed while in this open interface.

One difference I have between my machines though is that one has these as text files, while the other is after the most recent Office update creating them as json files.

Go check yours and let me know what you find!

Daily Blog #509: ObjectIDs and Domains

Hello Reader,
             Well YouTube was down for awhile tonight and at this point I'll need to get to bed before I could finish a test kitchen broadcast (if it would even work tonight!). So instead I decided to follow up on a question by Dr. Joe Sylve who asked in last nights Test Kitchen if Domain's are present in ObjectIDs if the computer was attached to a domain. To test this I went onto one of my domain connected computers and checked the objectID attributes of a file I've opened many times, our blank contract.



As you can see the DomainID is still all 0's meaning that this field is not currently being used, but you never know what the future will hold!

Daily Blog #508: Forensic Lunch Test Kitchen 10/15/18

Hello Reader,
          Tonight Matt Seyer virtually joined me for another test kitchen! We decided to examine the ObjectID index to determine what is really happening when a file is deleted and its ObjectID index entry is deleted. Matt presented his theory, Dr. Sylve contributed what he knew and the rest was solved with testing, tsk utilities, and python scripts.

Here is what we learned:

  • The ObjectID Index is a B-Tree with pages of entries of ObjectIDs
  • The last ObjectID in a page is the one most likely to survive in the slack space if it is deleted
  • ObjectIDs anywhere else in the page have a high chance of being overwritten when the b-tree is balanced unless they got saved from a previous page swap
  • istat won't give you the full path to a file, but you can get there if you are persistent 
  • The $logfile contains every changed page until its overwritten
We also have some new theories to test tomorrow night regarding USN and $Logfile interaction with the ObjectID Index! We should be testing those tomorrow night.

You can watch the video here:

Daily Blog #507: Sunday Funday 10/14/18

Hello Reader,
        The weeks have gone by quickly with nightly testing videos and weekly challenges. The schedule works well for me typically as weekend nights I have less time to do testing as I'm spending more time with my family. Let's see how you'll be spending your week with this weeks challenge.

The Prize:
$100 Amazon Giftcard

The Rules:

  1. You must post your answer before Friday 10/19/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:
What artifacts of execution exist on a Windows Server 2008+ that do not exist on Windows 7+? In other words name any forensic artifacts that would show a program executed on a windows server os that you wouldn't find on a windows desktop os!

Daily Blog #506: Solution Saturday 10/13/18

Hello Reader,
          This week no qualifying submissions, as a reminder this was the challenge:

The Challenge:
The TypedPaths key as we have seen recreates the key each time File Explorer exits. What other artifacts could we use to replace the data that we would have found there?

I'll have to address the answer in a blog post in the future, until then stay tuned for next week's challenge. 

Daily Blog #505: Forensic Lunch Test Kitchen 10/12/18

Hello Reader,
            A shorter test kitchen tonight, mainly because the answer came much quicker than I expected but only in part. Tonight we deleted files from the command line and the GUI to see what effect deleting them would have on the ObjectID Index found at /$Extend/$ObjID:$O. I used the updated $O parser from Matt Seyer found here: https://github.com/forensicmatt/WinObjectIdParser

Here is what we learned:

  • Deleting a file from the command line causes the ObjectID Index to delete the file entry
  • Deleting a file from the GUI causes the ObjectID Index to delete the file entry
  • That the deletion appears to clean and too quick, leading me to suspect that there is more going on here
On Monday I expect to resume this line of questioning with a hex editor (likely 010) and some offset tracking as we look to solve the mystery of the deleted ObjectID records. 

You can watch the video here:

Daily Blog #504: Forensic Lunch Test Kitchen 10/11/18

Hello Reader,
          Tonight we had what I think is a very exciting broadcast of the Forensic Lunch. When discussing on twitter whether or not a ObjectID would be created when a file is accessed over a network share DR Joe Sylve (watch the video to see why i capitalized doctor) hypothesized that it would not, while I pontificated that it would. It turns out ... it does! We then extracted and encoded the local objectid database (/$extend/$objid:$o) and parsed it to find out which systems had which dad.

Here is what we learned:

  • Opening a file from a Windows 10 system on a Windows 7 file share creates an ObjectID that both systems can see
  • The ObjectID contains the volume id and mac address of the file server (the windows 7 system in my testing)
  • The ObjectID database on the Windows 7 system contains the objectid of the file accessed
  • The ObjectID database on the Windows 10 system does not contain the objectid of the file accessed
  • The windows 10 system will create a lnk file for the access
  • The windows 7 system does not create a lnk file for the file being accessed from it as a network share
  • Creating a file in Windows 10 in the GUI will trigger an ObjectID being created on a network share hosted by a Windows 7 system
You can watch the video here:

Daily Blog #503: Forensic Lunch Test Kitchen 10/10/18

Hello Reader,
        We had a long night in this session of the test kitchen. Mainly because I was trying to debug making changes to Maxim Suhanov's yarp-timeline script without an IDE to help me find my dumb mistakes. In the end though we were able to find and display all of the transition states within the transaction logs for the TypedPaths key and we showed an updated build of Registry Explorer that will now show deleted values!

Here is what we learned:

  • Python's error messages leave a lot to be desired when you don't have an IDE
  • The yarp-timeline script will print which keys are changing but not their values
  • That with some hacky code modifications we can show the values that were changing in each transaction log entry
  • That all of the changes we made were in fact in the registry transaction logs, but we are not sure how long they will stay. Maxim estimates one hour. 
  • That the newest build of Registry Explorer we tested will show deleted values!
You can watch the video here:

Daily Blog #502: Forensic Lunch Test Kitchen 10/9/18

Hello Reader,
           Another night of testing on the test kitchen! This evening we revisited the TypedPath key and registry transaction logs as Maxim Suhanov pointed out I did not wait a full 60 seconds, instead I just let the clock roll over to the next minute. The timing is important as transaction logs are written to 60 seconds after the change occurred and I assumed that was every 60 seconds not 60 seconds since change. To rectify this error I made a timer in Windows 10 for 90 seconds to make sure between each action I left enough time for the system to record the change.

The only real variable left now is that I'm doing this in a VM, when this is all done I'll do it on the host OS as well to make sure there are no differences.

Here is what we learned:

  • The TypedPaths key is not being deleted and recreated, the individual keys appear to be overwritten
  • Looking into the slack space of the registry value for the entries you can see the end of the prior TypedPaths entry if it was longer than the replaced value
  • If a typedpaths entry (url(some number)) isn't present in the key that is overwriting it, then the left over values are deleted
  • The deleted values can be recovered and seen in yarp
  • The overwritten values cannot be seen in yarp even though it was my assumption the transaction logs would contain them
I'll be uploading the registry hives to the GitHub page tomorrow.

You can watch the video here:

Daily Blog #501: Forensic Lunch Test Kitchen 10/8/18

Hello Reader,
           It's Monday and it's time for another test kitchen! Tonight I tested Maxim Suhanov's assertion that waiting 60 seconds would allow the changes I made to the registry by closing file explorer would allow the transaction logs to be written to. So I did that test and even waited two minutes prior to exiting.

Here is what we learned:

  • After waiting two minutes between closing the two file explorer windows the live registry showed the second windows entries. The transaction logs and registry showed the first windows entries but no record of the second.
  • Re-extracting the registry from the disk a few minutes later cause the second windows entries to show up, but the first windows entries were lost again
  • Parsing the registry without the transaction logs does not show either windows changes initially, but did after the second registry extraction
More to test, more to learn! 

You can watch the video below:

Daily Blog #500: Sunday Funday 10/7/18

Hello Reader,
           This is the 500th Daily Blog! Which also just so happens to land on a Sunday Funday challenge which means, this one must be special .... even if it isn't. We've looked into a lot of topics this last couple weeks, lets see if you've been paying attention.

The Prize:
$100 Amazon Giftcard

The Rules:

  1. You must post your answer before Friday 10/12/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:
The TypedPaths key as we have seen recreates the key each time File Explorer exits. What other artifacts could we use to replace the data that we would have found there?

Daily Blog #499: Solution Saturday 10/6/18

Hello Reader,

     This week Kevin Pagano grabbed the win with a nice primer on registry monitoring. I m looking forward to testing more registry monitoring tools next week and trying out Maxim Suhanov's suggestion of waiting 30 seconds for transactions to be written.

The Challenge:
How would you monitor/record changes to registry keys? What could you do to get more data?

Winning answer:
There are few monitor tools that can record changes in the registry.

Nirsoft specifically has 2 different options that could be helpful:
RegistryChangesView - allows you to take snapshots of the registry at different points in time and compares two versions and export the changes as needed
RegFromApp - this one monitors the registry for changes made by specific applications

Regshot and WhatChanged are two other tools that are similar to RegistryChangesView in that it can show changes in two snapshots of the registry at different times.

Process Monitor (ProcMon) will give you real time feedback of activities in various locations but also the registry.

Registry Auditing can be turned on as such so changes will show in Event Logs:
1. Run the following command from Command Prompt:
auditpol /set /subcategory:"Registry" /success:enable
Note: if the OS has a different language pack, the name “Registry” might differ. For instance, on a German Windows, the name is “Registrierung”. To see what the name of the subcategory is you can run:
auditpol /list /subcategory:*
2. Open Registry Editor and navigate to the key which we want to audit (HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Word)
3. Right-click on the key and choose “Permissions…”
4. Click “Advanced” and switch to the Auditing tab
5. Add a user or group and select Access: Set Value
6. Apply settings
Via Microsoft

RegistryExplorer from Eric Zimmerman can be used to possibly show deleted registry keys and recover them as needed as well as interpret the registry transaction LOG files.

Daily Blog #498: Forensic Lunch 10/5/18

Hello Reader,
           We had a Forensic Lunch today! Matthew and I talked with all of you about:


  • The state of the DFIR Conference circuits with what we are told is the end of Enfuse. (Enfuse is being moved into the Opentext Conference from what we've been told). 
  • What other DFIR Conferences exist
  • The idea of going on a cruise together and doing DFIR stuff
  • And matthew demoed his /$Extend/$OBJID:$O Parsing script which is available on Github here: https://gist.github.com/forensicmatt/5d06acb11986c02cb61e9599fe9625f9
  • We talked about recovering deleted ObjectIDs from the $OBJID Index allocation
  • We talked about use cases for ObjectID analysis
You can watch the video here:

Daily Blog #497: Forensic Lunch Test Kitchen 10/4/18

Hello Reader,
        Another test kitchen! Tonight we went back to the TypedPaths overwrite mystery while Matthew finishes his $OBJID:$O parser to show tomorrow on the forensic lunch. We got YARP installed on our Windows 10 test VM and performed the same test of opening multiple file explorer windows, going to unique paths and watching the TypedPaths key get overwritten. We then extracted the registries and parsed them with YARP in an attempt to find the previously written TypedPaths files.

Here is what we learned:

  • YARP has a series of new utility scripts, we used yarp-print and yarp-timeline
  • YARP will automagically attempt to find and replay any transactions logs in the same directory as the registry file you opened
  • YARP did not find the prior TypedPaths values
More testing next week, make sure to tune into the forensic lunch tomorrow!

Here is the video:

Daily Blog #496: Forensic Lunch Test Kitchen 10/3/18

Hello Reader,
      Today we come close to a conclusion on our exploration of ObjectIDs within the MFT. We went in and both extracted MFT attributes with pytsk as well as ran/validated the same information with mftecmd to determine why we had duplicate objectids in our file system.

We learned that:

  • Duplicate ObjectIDs appear to happen in hard links to the same file
  • Every Duplicate ObjectID that we tested had the same file entry and sequence number meaning it was the same file
  • Python has a cool function called dir() which will show you all of the available methods that an object has
You can watch the video here:

Daily Blog #495: Forensic Lunch Test Kitchen 10/2/18

Hello Reader,
          Another night, another test kitchen. Tonight we continued our ObjectID testing and research to see if sequence numbers would reliably increment on reboots allowing us to find evidence of changes to the system clock and in what actual order files were created (windows 10) or opened (all other windows). Here is the summary of what we learned:


  • Sequence numbers are set in the Software registry under SOFTWARE\Microsoft\RPC\UUIDSequenceNumber
  • Windows.old backups now appear to include the users directory and are deleted after a week by a scheduled task
  • Sequence numbers will increment on each reboot, irregardless of timeset
  • Sequence numbers can jump and then settle back on the original sequence, working to understand how and why

You can watch the broadcast here:

Daily Blog #494: Forensic Lunch Test Kitchen 10/1/18

Hello Reader,
         Tonight the test kitchen continued to plumb the depths of ObjectID attributes of files in the MFT. What did we learn tonight?

We learned that:

  • The perceived duplicate timestamps from the decoded object ids were for the most part due to lack on granularity in nano seconds, when the raw values were added there were more unique values
  • That some files appear to have the same objectid and are related (the same exe file, lnk file pointing to the same resource) meaning we need to look at the MFT attributes to see if they are hard links to the same file
  • That changing the clock back will not change the base clock time used to generate ObjectIDs and sorting by the ObjectID timestamp will show you the correct order a file was created/interacted with (depending on the version of Windows) regardless of the time set by the user
We left off with a test of the sequence numbers as my VM had a Windows 10 update pending. We will continue tomorrow night!

You can watch the broadcast here: