Misty deserves a lot of credit 🙂
Anything that I've ever written denotes Misty as one of the most helpful contributors to WinFE's development in WinBuilder/PEBakery, as well as many others to every aspect of the development of WinFE.
[...] Paladin [...] will automount the drives
https://dfir.ru/2018/07/25/a-live-forensic-distribution-writing-to-a-suspect-drive/
@thefuf thanks for pointing this out. Just to make sure I got this right:
- Is this reported problem only an issue in terms of making forensic conclusions legally valid (i.e. different checksum for the same drive, as reported in the note) or does that mean erasure of forensically-useful data?Â
- Does the same happen with WinFE?
Â
Â
- Is this reported problem only an issue in terms of making forensic conclusions legally valid (i.e. different checksum for the same drive, as reported in the note) or does that mean erasure of forensically-useful data?Â
- Does the same happen with WinFE?
Â
This (and other) behaviours may happen on Linux systems that have not been fully vetted for forensics use, even if they only happen in "edge" cases, they are "disturbing".
WinFE has been developed EXACTLY to avoid these kind of issues and each and every "automount" features of the OS have been disabled.
Only for the record, and now outdated by WinFE, the greater risks in attaching a disk to a NT system were:
1) change of disk signature (in the MBR)[1]Â
2) automount of partitions (and then autostart programs might write to them)[2]
Both could be easily worked around by:
1) boot to a grub4dos (from another device)
2) copy the MBR to a file (on another device)
3) wipe the MBR (or just write 00 over the Magic Bytes 55 AA)
This way the disk - for all *any* Windows NT knows - is uninitialized and as such nothing will be changed/automounted/whatever.
4) attach the disk to a machine running NT
5) make a (dd) image of the disk
6) restore the MBR from file onto first sector of the disk image
7) reboot to grub4dos
8) restore the MBR from file to disk
jaclaz
Â
[1] automatic and not preventable in a number of situations, that are actually 2 of which only 1 can actually happen in real life (disk haveing a blank disk signature, i.e. having been never connected to a NT system)
[2] extremely rare and only happening if the NT system has been setup and managed by a moron
- Is this reported problem only an issue in terms of making forensic conclusions legally valid (i.e. different checksum for the same drive, as reported in the note) or does that mean erasure of forensically-useful data?
Wiping the $LogFile journal on an NTFS volume? Syncing data on RAID-1 drives? That's lots of useful data. However, vendors use different wording.
Compare this (not related to PALADIN but to a different distro):
OSFClone may not be forensically sound when imaging drives with ext2/3/4 filesystems. During internal testing it was found that if the evidence drive is connected during system start up, it is possible the first superblock (typically offset 1024 within the partition) on the ext2/3/4 filesystem the drive may be altered. Values that were changed include the last mount time, last write time, mount count and a byte at location 0x0178 within the superblock.
To this:
OSFClone is not forensically sound when imaging drives with Ext3/4 file systems. It can recover such a file system using its journal, if this file system is in an unclean state (e.g., hibernated or after pulling the plug). This means that file system metadata (including file timestamps) can be altered without any user interaction (the amount of modified file system metadata can't be estimated in advance, it can be several bytes only or, for heavily loaded systems, it can affect hundreds of files). If data journaling is enabled, this can affect file contents too. In many cases, you don't know what file system types are on a storage media you need to acquire, what are their states, and how many file system operations have been logged but not committed yet. Also, under some conditions you won't be able to tell if any modifications have been done by an acquisition tool after you finish the imaging and power off the system, so if anyone (like a court) asks you whether an acquisition tool modified the drive or not, the right answer in this situation will be "I don't know".
Or compare that post linked before to a typical reply: "our software is NIST-validated".
Do yourself a favor and buy some good screwdrivers, disassemble the laptop, take out the hard drive and go the forensic sound way. Obviously this is some kind of insider case....getting rid of an employee should be worth the acquisition of screwdrivers and a write-blocker.
I am using my own version of WinPE for forensic purposes (this here is from me)Â and I never ever had a case, where I had to use my bootable WinPE/ WinFE for a case that could potentially go to a court. If it is a case, that could make it to the lawyers, I always go the forensic sound way (see first sentence).Â
In all other cases I have used a bootable Windows, we were facing an Incident Response scenario, where the bad guys are unreachable for prosecution. Therefore, my bootable Windows PE is on automount to get the relevant IOC as fast as possible. Simply do not want to waste time playing around with diskpart.
Â
my 2 cent for this,
Robin
DI never ever had a case, where I had to use my bootable WinPE/ WinFE for a case that could potentially go to a court. If it is a case, that could make it to the lawyers, I always go the forensic sound way (see first sentence).
I had several cases with an acquisition using a live distribution being the only option.
Like a laptop with a solid-state drive and a fake RAID-0 setup (this solid-state drive is exposed as 4 physical drives to an operating system, its driver is responsible for rebuilding those drives into a single virtual drive, and the firmware (BIOS) is responsible for doing the same before the driver is loaded by providing a custom handler for the INT13h interrupt). The RAID metadata wasn't stored on the drive, there was FDE (TrueCrypt) enabled with an unknown password (and a large list of possible passwords was given). Also, there was a proprietary connector to the motherboard.
If you manage to acquire 4 exposed drives of that single solid-state drive, you won't know how to rebuild the encrypted array (the order of drives, the block size, etc.). Tools that guess RAID parameters won't help because of FDE and an unknown password.
So, I had to use my custom GRUB boot CD. 😉
Also, I would never say that all bootable acquisition methods are not forensically sound.
Do yourself a favor and buy some good screwdrivers, disassemble the laptop, take out the hard drive and go the forensic sound way.Â
1) you can also use a dremel just fine:
https://hackaday.com/2015/04/28/upgrading-a-microsoft-surface-to-a-1-tb-ssd/
2) that is not "forensic sound" is "very likely" or maybe "more likely" forensic sound, remember that write blockers may have defects like anything else:
jaclaz