SHOW:
|
|
- or go back to the newest paste.
| 1 | The default encryption scheme is AES in XTS mode. In XTS mode, primary and secondary 256-bit keys are concatenated together to form one 512-bit (64 bytes) master key. An advantage you gain right off the bat is that patterns in AES keys can be distinguished from other seemingly random blocks of data. This is how tools like aeskeyfind and bulk_extractor locate the keys in memory dumps, packet captures, etc. In most cases, extracting the keys from RAM is as easy as this: | |
| 2 | ||
| 3 | $ ./aeskeyfind Win8SP0x86.raw | |
| 4 | f12bffe602366806d453b3b290f89429 | |
| 5 | e6f5e6511496b3db550cc4a00a4bdb1b | |
| 6 | 4d81111573a789169fce790f4f13a7bd | |
| 7 | a2cde593dd1023d89851049b8474b9a0 | |
| 8 | 269493cfc103ee4ac7cb4dea937abb9b | |
| 9 | 4d81111573a789169fce790f4f13a7bd | |
| 10 | 4d81111573a789169fce790f4f13a7bd | |
| 11 | 269493cfc103ee4ac7cb4dea937abb9b | |
| 12 | 4d81111573a789169fce790f4f13a7bd | |
| 13 | 0f2eb916e673c76b359a932ef2b81a4b | |
| 14 | 7a9df9a5589f1d85fb2dfc62471764ef47d00f35890f1884d87c3a10d9eb5bf4 | |
| 15 | e786793c9da3574f63965803a909b8ef40b140b43be062850d5bb95d75273e41 | |
| 16 | Keyfind progress: 100% | |
| 17 | ||
| 18 | Several keys were identified, but only the two final ones in red are 256-bits (the others are 128-bit keys). Thus, you can bet by combining the two 256-bit keys, you'll have your 512-bit master AES key. That's all pretty straightforward and has been documented in quite a few places - one of my favorites being Michael Weissbacher's blog. | |
| 19 | ||
| 20 | The problem is - what if suspects change the default AES encryption scheme? TrueCrypt also supports Twofish, Serpent, and combinations thereof (AES-Twofish, AES-Twofish-Serpent). Furthermore, it supports modes other than XTS, such as LWR, CBC, outer CBC, and Inner CBC (though many of the CBCs are either deprecated or not recommended). | |
| 21 | ||
| 22 | What do you do if a suspect uses non-default encryption schemes or modes? You can't find Twofish or Serpent keys with tools designed to scan for AES keys -- that just doesn't work. As pointed out by one of our Twitter followers (@brnocrist), a tool by Carsten Maartmann-Moe named Interrogate could be of use here (as could several commercial implementations from Elcomsoft or Passware). | |
| 23 | ||
| 24 | Another challenge that investigators face, in the case of file-based containers, is figuring out which file on the suspect's hard disk serves as the container. If you don't know that, then having the master keys is only as useful as finding the key to a house but having no idea where the house is. | |
| 25 | ||
| 26 | To address these issues, I wrote several new Volatility plugins. The truecryptsummary plugin gives you a detailed description of all TrueCrypt related artifacts in a given memory dump. Here's how it appears on a test system running 64-bit Windows 2012. | |
| 27 | ||
| 28 | $ python vol.py -f WIN-QBTA4959AO9.raw --profile=Win2012SP0x64 truecryptsummary | |
| 29 | Volatility Foundation Volatility Framework 2.3.1 (T) | |
| 30 | ||
| 31 | Process TrueCrypt.exe at 0xfffffa801af43980 pid 2096 | |
| 32 | Kernel Module truecrypt.sys at 0xfffff88009200000 - 0xfffff88009241000 | |
| 33 | Symbolic Link Volume{52b24c47-eb79-11e2-93eb-000c29e29398} -> \Device\TrueCryptVolumeZ mounted 2013-10-11 03:51:08 UTC+0000
| |
| 34 | Symbolic Link Volume{52b24c50-eb79-11e2-93eb-000c29e29398} -> \Device\TrueCryptVolumeR mounted 2013-10-11 03:55:13 UTC+0000
| |
| 35 | File Object \Device\TrueCryptVolumeR\$Directory at 0x7c2f7070 | |
| 36 | File Object \Device\TrueCryptVolumeR\$LogFile at 0x7c39d750 | |
| 37 | File Object \Device\TrueCryptVolumeR\$MftMirr at 0x7c67cd40 | |
| 38 | File Object \Device\TrueCryptVolumeR\$Mft at 0x7cf05230 | |
| 39 | File Object \Device\TrueCryptVolumeR\$Directory at 0x7cf50330 | |
| 40 | File Object \Device\TrueCryptVolumeR\$BitMap at 0x7cfa7a00 | |
| 41 | File Object \Device\TrueCryptVolumeR\Chats\Logs\bertha.xml at 0x7cdf4a00 | |
| 42 | Driver \Driver\truecrypt at 0x7c9c0530 range 0xfffff88009200000 - 0xfffff88009241000 | |
| 43 | Device TrueCryptVolumeR at 0xfffffa801b4be080 type FILE_DEVICE_DISK | |
| 44 | Container Path: \Device\Harddisk1\Partition1 | |
| 45 | Device TrueCrypt at 0xfffffa801ae3f500 type FILE_DEVICE_UNKNOWN | |
| 46 | ||
| 47 | Among other things, you can see that the TrueCrypt volume was mounted on the suspect system on October 11th 2013. Furthermore, the path to the container is \Device\Harddisk1\Partition1, because in this case, the container was an entire partition (a USB thumb drive). If we were dealing with a file-based container as previously mentioned, the output would show the full path on disk to the file. | |
| 48 | ||
| 49 | Perhaps even more exciting than all that is the fact that, despite the partition being fully encrypted, once its mounted, any files accessed on the volume become cached by the Windows Cache Manager per normal -- which means the dumpfiles plugin can help you recover them in plain text. Yes, this includes the $Mft, $MftMirr, $Directory, and other NTFS meta-data files, which are decrypted immediately when mounting the volume. In fact, even if values that lead us to the master keys are swapped to disk, or if TrueCrypt (or other disk encryption suites like PGP or BitLocker) begin using algorithms without predictable/detectable keys, you can still recover all or part of any files accessed while the volume was mounted based on the fact that the Windows OS itself will cache the file contents (remember, the encryption is transparent to the OS, so it caches files from encrypted volumes in the same way as it always does). | |
| 50 | ||
| 51 | After running a plugin such as truecryptsummary, you should have no doubts as to whether TrueCrypt was installed and in use, and which files or partitions are your targets. You can then run the truecryptmaster plugin which performs nothing short of magic. | |
| 52 | ||
| 53 | $ python vol.py -f WIN-QBTA4.raw --profile=Win2012SP0x64 truecryptmaster -D . | |
| 54 | Volatility Foundation Volatility Framework 2.3.1 (T) | |
| 55 | ||
| 56 | Container: \Device\Harddisk1\Partition1 | |
| 57 | Hidden Volume: No | |
| 58 | Read Only: No | |
| 59 | Disk Length: 7743733760 (bytes) | |
| 60 | Host Length: 7743995904 (bytes) | |
| 61 | Encryption Algorithm: SERPENT | |
| 62 | Mode: XTS | |
| 63 | Master Key | |
| 64 | 0xfffffa8018eb71a8 bbe1dc7a8e87e9f1f7eef37e6bb30a25 ...z.......~k..% | |
| 65 | 0xfffffa8018eb71b8 90b8948fefee425e5105054e3258b1a7 ......B^Q..N2X.. | |
| 66 | 0xfffffa8018eb71c8 a76c5e96d67892335008a8c60d09fb69 .l^..x.3P......i | |
| 67 | 0xfffffa8018eb71d8 efb0b5fc759d44ec8c057fbc94ec3cc9 ....u.D.......<. | |
| 68 | Dumped 64 bytes to ./0xfffffa8018eb71a8_master.key | |
| 69 | ||
| 70 | You now have a 512-byte Serpent master key, which you can use to decrypt the roughly 8 GB USB drive. It tells you the encryption mode that the suspect used, the full path to the file or container, and some additional properties such as whether the volume is read-only or hidden. As you may suspect, the plugin works regardless of the encryption algorithm, mode, key length, and various other factors which may complicate the procedure of finding keys. This is because it doesn't rely on the key or key schedule patterns -- it finds them in the exact same way the TrueCrypt driver itself finds the keys in RAM before it needs to encrypt or decrypt a block of data. |
