@night 1803 access accessdata active directory admissibility ads aduc aim aix ajax alissa torres amcache analysis anjp anssi answer key antiforensics apfs appcompat appcompatflags applocker april fools argparse arman gungor arsenal artifact extractor attachments attacker tools austin automating automation awards aws azure azuread back to basics backstage base16 best finds beta bias bitcoin bitlocker blackbag blackberry enterprise server blackhat blacklight blade blanche lagny book book review brute force bsides bulk extractor c2 carved carving case ccdc cd burning ceic cfp challenge champlain chat logs Christmas Christmas eve chrome cit client info cloud forensics command line computer forensics computername conference schedule consulting contest cool tools. tips copy and paste coreanalytics cortana court approved credentials cryptocurrency ctf cti summit cut and paste cyberbox Daily Blog dbir deep freeze defcon defender ata deviceclasses dfa dfir dfir automation dfir exposed dfir in 120 seconds dfir indepth dfir review dfir summit dfir wizard dfrws dfvfs dingo stole my baby directories directory dirty file system disablelastaccess discount download dropbox dvd burning e01 elastic search elcomsoft elevated email recovery email searching emdmgmt Encyclopedia Forensica enfuse eric huber es eshandler esxi evalexperience event log event logs evidence execution exfat ext3 ext4 extended mapi external drives f-response factory access mode false positive fat fde firefox for408 for498 for500 for526 for668 forenisc toolkit forensic 4cast forensic lunch forensic soundness forensic tips fraud free fsutil ftk ftk 2 full disk encryption future gcfe gcp github go bag golden ticket google gsuite guardduty gui hackthebox hal pomeranz hashlib hfs honeypot honeypots how does it work how i use it how to howto IE10 imaging incident response indepth information theft infosec pro guide intern internetusername Interview ios ip theft iphone ir itunes encrypted backups jailbreak jeddah jessica hyde joe sylve journals json jump lists kali kape kevin stokes kibana knowledgec korman labs lance mueller last access last logon leanpub libtsk libvshadow linux linux-3g live systems lnk files log analysis log2timeline login logs london love notes lznt1 mac mac_apt macmini magnet magnet user summit mathias fuchs md viewer memorial day memory forensics metaspike mft mftecmd mhn microsoft milestones mimikatz missing features mlocate mobile devices mojave mount mtp multiboot usb mus mus 2019 mus2019 nccdc netanalysis netbios netflow new book new years eve new years resolutions nominations nosql notifications ntfs ntfsdisablelastaccessupdate nuc nw3c objectid offensive forensics office office 2016 office 365 oleg skilkin osx outlook outlook web access owa packetsled paladin path specification pdf perl persistence pfic plists posix powerforensics powerpoint powershell prefetch psexec py2exe pyewf pyinstaller python pytsk rallysecurity raw images rdp re-c re-creation testing reader project recipes recon recursive hashing recycle bin redteam regipy registry registry explorer registry recon regripper remote research reverse engineering rhel rootless runas sample images san diego SANS sans dfir summit saturday Saturday reading sbe sccm scrap files search server 2008 server 2008 r2 server 2012 server 2019 setmace setupapi sha1 shadowkit shadows shell items shellbags shimcache silv3rhorn skull canyon skype slow down smb solution solution saturday sop speed sponsors sqlite srum ssd stage 1 stories storport sunday funday swgde syscache system t2 takeout telemetry temporary files test kitchen thanksgiving threat intel timeline times timestamps timestomp timezone tool tool testing training transaction logs triage triforce truecrypt tsk tun naung tutorial typed paths typedpaths uac unc understanding unicorn unified logs unread updates usb usb detective usbstor user assist userassist usnjrnl validation vhd video video blog videopost vlive vmug vmware volatility vote vss web2.0 webcast webinar webmail weekend reading what are you missing what did they take what don't we know What I wish I knew whitfield windows windows 10 windows 2008 windows 7 windows forensics windows server winfe winfe lite wmi write head xboot xfs xways yarp yogesh zimmerman zone.identifier

Daily Blog #260: Sunday Funday 3/9/14 Winner!

Hello Reader,
Another week another challenge answered. I'm hoping I can get Mark Spencer from Arsenal to expound on his version of an answer but Kyle Rhodes put a good answer this week explaining the structures used to recover deleted registry hives from freespace. Enjoy this week's answer I look forward to hitting 100 blog posts left to write in two posts.

The Challenge:
The idea of recovering deleted registry entries from within a registry is well known and implemented well in Harlan's perl scripts and yara. To show you understanding of what Mark Spencer and his team discovered answer the following questions:

1. How is it possible that registry recon can recover deleted registry entries from unallocated space
2. Where do these recoverable registries come from?
3. What additional analysis points can you determine from these recoverable keys?

The Winning Answer
Kyle Rhodes



1. How is it possible that registry recon can recover deleted registry entries from unallocated space? 

Like any other file we might want to carve out of unallocated space, registry hives contain a standard header which marks the beginning of the file. The header is ‘regf’ or 0x66676572 in hex. By simply searching unallocated space for this string of binary characters, a program like Registry Recon can identify a potentially recoverable registry hive. 

However, the recovery work doesn't stop there. Any time we find remnants of a previously existing file in unallocated space, it is possible that any part or all of the registry hive has been overwritten by other data. Further, how do we know where the end of the registry hive is on the disk? Fortunately, the structure of registry hives is helpful in that regard.

As described in Harlan Carvey's book, Windows Registry Forensics, after the ‘regf’ header in a registry hive, every 4KB is a self-contained bin of data marked off by the 4 byte binary representation of the string ‘hbin’. This means, as long as you continue to jump forward 4KB increments on the disk and find ‘hbin’, there is a high likelihood that you are looking at an intact, contiguous, registry hive. Once a 4KB offset contains something other than ‘hbin’, stop and carve out what you found. Somewhere after the last ‘hbin’, you either reached the end of the registry hive, it's been overwritten by other data, or the entire registry hive did not live in contiguous clusters on the disk.

2. Where do these recoverable registries come from?

Recoverable registries can be found in unallocated space due to hives that have been deleted in some fashion whether manually, via formatting a drive and reinstalling the OS, by anti-forensics programs, or by the OS when it is making and committing changes to the registry. They can also be found in restore points, volume shadow copies, pagefile.sys, and hyberfil.sys in unallocated or allocated space. Finally, if they are in the pagefile.sys and hyberfil.sys, they can obviously be found in memory as well.

3. What additional analysis points can you determine from these recoverable keys?

Being able to recover all of this additional data is great for us information junkies, but the fun comes when we can use it to solve our cases. Here are some ways I thought this information could be helpful, in no particular order:

                1. See which USB devices were associated with the same drive letters over time
                2. Get more than the last 20 entries from the OpenSaveMRU key
                3. Use historical registry key last write times to determine when entries were added to various MRU lists
                4. Find registry keys that were wiped
                5. Determine whether Windows has been installed multiple times
                6. Compare historical registry data over time to see anomalies created by anti-forensics tools
                7. Determine if a forensic analyst had the USB write protection turned on when imaging evidence in the past (you can never be too careful)

If you can think of any other ways historical registry data would be helpful, please tell me below in the comments!



 
Labels:

Post a Comment

[blogger][disqus][facebook][spotim]

Author Name

Contact Form

Name

Email *

Message *

Powered by Blogger.