Home Archives for July 2018

Daily Blog #439: Jumplist maximum storage

Jumplist maximum storage by David Cowen - Hacking Exposed Computer Forensics Blog

Hello Reader,
There is some interesting testing going on with shell item storage. The quirks of lnk files naming and storage by extension is surprising and needs more testing before its documented. Something that has been tested though is how many items a jumplist will store.

When Eric Zimmerman was first writing Jumplist Explorer we were discussing what the maximum amount of entries stored in a single jumplist could be. So we wrote some quick automation and found that a single jumplist will store approximately 2,000 items before it purges the oldest item. I suspect the hard limit is 2048 (power of 2) but in our testing it was when we reached 2,000 that older items began being deleted from the structure.

Now this does not mean the older entries are lost, the jumplist is a compound file system and the streams are just marked as deleted and available to be recovered until a new entry gets written over it. In fact Jumplist Explorer can recover deleted entries and mark them as such. Tomorrow I'll see if I can get screenshots of this happening and show the internal record numbers.

Also Read: Validating the Windows 10 Copy Paste artifact

Validating the Windows 10 Copy Paste artifact by David Cowen - Hacking Exposed Computer Forensics Blog

Hello Reader,

If you don't read the port139 blog, you should! On the most recent post the port139 blog, translated from Japanese to English, validated the Windows 10 copy paste artifacts I wrote about earlier this month. You can read about it here:

http://port139.hatenablog.com/entry/2018/07/29/211630

I really liked reading this as it allowed me to see how another examiner approached the artifact and provided another examiner validating the artifact.

So if you were looking for something to write about, pick an artifact and test it!

Also Read: Daily Blog #434

Bitlocker Experiments Part 5 by David Cowen - Hacking Exposed Computer Forensics Blog

Hello Reader,
As I was looking at the FVE metadata header and decoding the output I realized two things.

1. There is more here than I previously understood, I didn't appreciate the layering of keys that existed.

You can read more about how this works here: https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-key-management-faq as a TLDR though there are three layers of protection that are provided. The documentation goes from the disk and up but let's go the opposite way, the way a user interfaces with Bitlocker.

The protector you have picked (TPM, Password, Pin, etc..) will be used on successful authentication to decrypt something called the Volume Master Key or VMK. As I am going through the metadata header I can see the attributes marking the VMKs that exist.

The VMK in turn once decrypted is then used to decrypt the Full Volume Encryption Key or FVEK which is what actually encrypted the data on your storage volume. So when the protectors are disabled what is happening is that the VMK key is being decrypted, allowing the FVEK and with it the raw data to be accessed. This is how encryption can be 'paused' or 'suspended' for a windows update without decrypting the drive. Very clever and it explained the huge difference within the blocks.

I was expecting to see one key change or a key exposed, instead the rest of the block that was chaning was actually the contents being decrypted allowing any system that has the ability to support this mode to access it.

This explains why some software packages that access Bitlocker volumes fail to do so without a password/pin/recovery tool as they were not programmed to check if the decrypting keys were left decrypted based on a previous command or action.

When I get back in my lab next week I am going to see how I can get Windows Update to trigger this removal of protections for me as I think this will likely allow for the imaging of a drive that is technically encrypted but allows anything that understands it to decrypt it. I am going to focus this on the scenario of a system I don't have credentials for as if I did I could just log in and get manage-bde to provide me the recovery-key I needed.

This also means for those doing onsite acquisitions if you don't want to rely on extracting the key from memory you could just get manage-bde to get you the recovery key prior to imaging and be able to access the drive in your lab.

2. I need to write what I'm doing manually into a Python script to really do this effectively. I could make an 010 template but it would seem that a Python script to parse these fields would lead to better long term results and testing.

This is likely going to start next week as well as tomorrow is a Forensic Lunch day and then I'll be reviewing the Sunday Funday submissions on the 16 hour flight home.

Thanks for reading this far and frankly for reading this at all. Forcing myself to research, test and document things everyday is already making me feel more engaged again and clearing out old lingering questions I never made time to answer. I would hope others have already discovered most of this (Jesse Kornblum and Joachim Metz have documented these things in their work) but I find a lot of value in doing it yourself if you really want to understand whats possible.

This is a 5-part series and make sure to check all the parts:

Bitlocker Experiments Part 1

Bitlocker Experiments Part 2

Bitlocker Experiments Part 3

Bitlocker Experiments Part 4

Bitlocker Experiments Part 5

Hello Reader,
I've now extracted the FVE Metadata block from a vhd encrypted with bitlocker while bitlocker is active and is protecting the VHD with a password and after I turned off protection. I was expecting to find the clearkey attribute set on the volume master key as described in the libbde documentation. Instead the protection was the same but it appears as though the decryption keys were left unprotected.

I removed the bitlocker protection using the following command
manage-bde -protectors -disable d:

I then checked the status of the bitlocker volume wit the following command
manage-bde -status d:

The protectors are still place and the recovery key has not changed:

However, comparing the same metadata block before and after removing protection shows that alot of changes occurred in the metadata block:

I'm still breaking out all the values that changed to understand them all better but this different than what I expected. Let's see what tomorrows testing brings.

This is a 5-part series and make sure to check all the parts:

Bitlocker Experiments Part 1

Bitlocker Experiments Part 2

Bitlocker Experiments Part 3

Bitlocker Experiments Part 4

Bitlocker Experiments Part 5

Bitlocker Experiments Part 3 by David Cowen - Hacking Exposed Computer Forensics Blog

Hello Reader,
I was reading the libbde specification again and noticed I was missing something in the screenshots I posted yesterday. Yesterday I stated the hostname of the computer that encrypted the drive was present as well as the date it was encrypted. What is being stored between those two values though is the name of the volume being encrypted.

So in the first example:

After the Desktop hostname you can see the Unicode string bitlocker test. This was the name of the vhd I created and formatted NTFS for this test.

In the case that there is no volume label present, as was the example with my Bitlocker ToGo example, the drive letter it was assigned at the time of encryption will be stored as seen below:

In the above screenshot after the SANS-FOR600 string and before the 7/23/2018 string you can see F:. F: was the drive letter assigned to this volume prior to its encryption with bitlocker and the volume had no name given at the time of format.

So in total from an encrypted bitlocker disk so far we can determine:
1. The Hostname that encrypted it
2. The volume label or drive letter assigned ( if there is no volume label present) when it was encrypted
3. The date if was encrypted
4. In prior research we found we find the key identifiers of the recovery keys

Why is this useful? We can match this up in the case of external drives not only with the systems that encrypted them but also to the artifacts that show what was being accessed from these drives. In addition if you needed to look up a recovery key you could so with the hostname even if the identifier doesn't help you. Lastly you can determine when something was encrypted as it might correspond to a time when your suspect became aware of an investigation.

This is a 5-part series and make sure to check all the parts:

Bitlocker Experiments Part 1

Bitlocker Experiments Part 2

Bitlocker Experiments Part 3

Bitlocker Experiments Part 4

Bitlocker Experiments Part 5

Bitlocker Experiments Part 2 by David Cowen - Hacking Exposed Computer Forensics Blog

Hello Reader,
I'm continuing my Bitlocker experiments while here in Abu Dhabi until I return home this weekend to do more MAPI testing of OWA changes. After my last post and experiment I got some help from a friend and reread the Bitlocker specification from libbde here. In my prior Bitlocker work I don't think I appreciated what information the FVE metadata blocks were providing me.

Within the Bitlocker encrypted volume (without providing any keys, just the raw encrypted data) there are three metadata blocks that i'm looking into and that Metz has documented. Looking at the first one I see the following entry on a new vhd that I created, attached and bitlocker encrypted.

If you look closely starting at 3100078 you will see the start of a Unicode string that says Desktop-IVOIVRB this hostname of the machine I did the bitlocker encryption with followed by the date I encrypted the volume.

I thought this was very interesting! We can determine the name of the machine that encrypted the volume and when it was encrypted, but this was a fixed vhd. So I decided to use my SANS instruction laptop to encrypt a flash drive with Bitlocker ToGo to see if there was any difference.

Looking here starting at Offset 2800078 you can see the beginning of the Unicode string SANS-FOR600 which is the name of my instructor laptop and the date I encrypted the drive.

So Bitlocker of Bitlocker ToGo both will tell you the hostname of the system that encrypted the volume and the date it was encrypted! Faxcinating! More to come as I begin to tweak the properties of these drives with manage-bde and see what comes to light.

This is a 5-part series and make sure to check all the parts:

Bitlocker Experiments Part 1

Bitlocker Experiments Part 2

Bitlocker Experiments Part 3

Bitlocker Experiments Part 4

Bitlocker Experiments Part 5

Timezone Challenge by David Cowen - Hacking Exposed Computer Forensics Blog

Hello Reader,
Another week already? Time for another challenge to keep your wheels turning and your research skills sharp. This week let's talk about time zones and Windows. With Windows 10 automatically changing your timezone by default based on your location its going to be come more important to know not only where but when someone was at a particular point in time.

The Prize:

$100 Amazon Giftcard

The Rules:

You must post your answer before Friday 7/27/18 7PM CST (GMT -5)
The most complete answer wins
You are allowed to edit your answer after posting
If two answers are too similar for one to win, the one with the earlier posting time wins
Be specific and be thoughtful
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.
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:

On a Windows 10 system what are the different ways you could determine what timezones a user was in prior to the whatever timezone is stored in the registry?

Also Read: Daily Blog #429

- Winning Solution for Cortana Database Challenge by David Cowen

Hello Reader,
Another week, another challenge. It came down to the wire, that I extended, but we have an answer and a winner. This week's winner Justin Boncaldo sent in the only entry, many others were talking but didn't submit! So remember that submitting is half way to winning when tomorrow's challenge gets posted!

The Challenge:

Cortana used to have a database that kept track of location information and other relevant DFIR data. As of a year ago the database has changed and the location data is nowhere to be found. For this weeks challenge please answer the following questions:
1. Where does Cortana keep it's data now
2. What data does Cortana retain now
3. Is there any location history left from Cortana

The Winning Answer from Justin Boncaldo:

My brief and initial findings of Cortana's local data. *Note: Due to my initial lack of knowledge on Cortana data, this information was compiled based on my best judgement and is possible to be incorrect.

As you know, Microsoft's Cortana used to store forensically valuable information within
- 'CortanaCoreDb.dat' [user/appdata/local/packages/Microsoft.Windows.Cortana.cw5n1h2txyewy/localstate/ESEDatabase_CortanaCoreInstance] and
- 'IndexedDB.dat' [user/appdata/local/packages/Microsoft.Windows.Cortana.cw5n1h2txyewy/appdata/indexed DB/].

1. It appears that the majority of Cortana's data is now stored in the cloud, and then requested on a necessary basis. By keeping most of a user's data on their own servers, Microsoft helps strengthen user security, allows seamless transition between devices, and allows for data to be utilized faster.

2. Although the two databases still exist on the system, not user data appears to be stored there anymore. Cortana currently mostly stores numerous json files and visual assets locally; necessary for the use of the application and a functional connection to be built with the servers. However, I was able to find two locations with potentially useful information. The first being "Local Recorder" at path [user/appdata/local/packages/Microsoft.Windows.Cortana.cw5n1h2txyewy/Localstate/LocalRecorder/Speech/SavedAudio] . This appears to contain locally stored instances of the audio recordings that Cortana takes. WAV audio files are saved using the shortname naming convention, and will automatically delete themselves from the system over time. Audio playback has not been successful for me yet, because these files are displayed with a filesize of 0 Kb. I have yet to compare this creation timestamp to that of a Cortana activation instance. The second piece of data is WIFI data located at: [user/appdata/local/packages/Microsoft.Windows.Cortana.cw5n1h2txyewy/Localstate/signals/collection/Wifi]. This file stores the network SSID that the device was connected to at the time of voice commands. Unfortunately, this information is also deleted after some time and more testing needs to be done with this.

3. I believe these two locations could both hold valuable information to support other location data. Although they are not directly connected the user to a specific location on the earth, they might be showing that the user was using Cortana's voice commands at a specific time, and that they were connected to a specific network connection at that time too. Again, this is not direct data -and is apparently extremely volatile. More testing will be done to observe more actions of Cortana.

Also Read: Daily Blog #428

Discussion with Arman Gungor on Defcon CTF

Hello Reader,
We had a great Forensic Lunch today with our guest Arman Gungor (@armangungor) from metaspike.com, talking about his research posted on the meridian discovery blog (like this one https://www.meridiandiscovery.com/articles/email-attachment-timestamps-forensics-outlook/ ) and his work on Forensic Email Collector. Matt and I also talked about the upcoming Defcon CTF and our planned live streams from Defcon providing commentary.

The video got split into two due to broadcasting software issues so here is the first video with Arman:

And here is the second video with Matt and I talking about

the CTF

There will be another Forensic Lunch next Friday 7/27/18, looking forward to seeing you then!

Also Read: Directory Copy and Paste Artifacts in Windows 10

Bitlocker Experiments Part 1 by David Cowen - Hacking Exposed Computer Forensics Blog

Hello Reader,
In a prior Sunday Funday regarding Bitlocker drives and Windows upgrades I extended my ask a bit too far in what I put into the challenge and justifiably received no submissions. I haven't stopped looking into the question though of how does Windows temporarily disable Bitlocker to allow the machine to boot for an upgrade and how can we as examiners take advantage of it.

In my research into this I've learned about the 'clearkey' which I've heard of before. The 'clearkey' means that the key to decrypt the bitlocker volume is left in plaintext within the volume. This allows for the bitlocker volume to be present and allows the user to in the future, if they so choose, to protect the volume with a password and recovery key. It appears as though some Surface computers come with this mode on when shipped.

However that did not answer my question about upgrades, as the drive isn't being re-encrypted in the upgrade process. It turns out there is an option to temporarily set an existing image into 'clearkey' mode. To do this you would execute the following command in an administrative command prompt

manage-bde -protectors -disable c:

Here is a screenshot of it successfully running

Checking the status of the drive with the command

manage-bde -status

I see the following

Notice it has left the protection off for 1 reboot by default, just enough for an update to complete.

I'm going to encrypt a vhd next week and do some testing to see how the tools recognize this. When I'm back in the office in a week (still in Abu Dhabi!) I'll let one my machines upgrade and see if 'cleartext' mode is in fact enabled on my Bitlocker drives allowing me to decrypt them!

This is a 5-part series and make sure to check all the parts:

Bitlocker Experiments Part 1

Bitlocker Experiments Part 2

Bitlocker Experiments Part 3

Bitlocker Experiments Part 4

Bitlocker Experiments Part 5

Subscribe to: Posts ( Atom )

Daily Blog #439: Jumplist maximum storage

Daily Blog #438: Validating the Windows 10 Copy Paste artifact

Daily Blog #437: Sunday Funday 7/29/18 - Windows Task Enabled Challenge

Daily Blog #436: Solution Saturday 7/28/18 - Winning Answer for Timezones Challenge

Daily Blog #435: Forensic Lunch 7/27/18 - Discussion on BitLocker, Defcon DFIR CTF and More

Daily Blog #434: Bitlocker Experiments Part 5

Daily Blog #433: Bitlocker Experiments Part 4

Daily Blog #432: Bitlocker Experiments Part 3

Daily Blog #431: Bitlocker Experiments Part 2

Daily Blog #430: Sunday Funday 7/22/18 - Timezone Challenge

Daily Blog #429: Solution Saturday 7/21/18 - Winning Solution for Cortana Database Challenge

Daily Blog #428: Forensic Lunch 7/20/18 - Discussion with Arman Gungor on Defcon CTF

Daily Blog #427: Bitlocker Experiments Part 1

Top Posts/Right Now