Identification

Toolset

You want to use Linux instead of Windows:

• Extensive native file system support

• Native support of hot swapping drives and devices, mounting images, etc.

Instead Windows has the following problems:

• Tampers with drives and modifies evidence.

• Does not support image handling or hotswapping of drives.

• Does not have support for non-Windows FS (doable with 3rd-party software).

Still we could need some Windows specific tools or features. Hybrid approach is best: Linux + virtualized Windows. Using Linux as host, and Windows as guest, we can:

• Work the images with Linux, mounting them read-only and then exporting them via Samba to Windows

• Use OS-specific software that only runs on Windows

Note that it is not always doable to use Samba: if Windows must see the file system (e.g. file recovery tool or unallocated space analysis) we can mount the image as a read-only loop device under Linux, and/or use the "non-persistent" mode of VMWare.

Recall on the meaning of "scientific"

• An experiment must be repeatable: any other expert will be able to perform the same experiment, on a clone of the image, obtaining the same results I obtained.

• Result validation: logic matters, the expert must be able to perform the same analysis by hand (at least in theory)

For a forensics expert, this means that that analysis software needs to be open sourced, and possibly free, and also that proprietary or "law enforcement only" tools are not really fit for the job.

Recovery of deleted data

Information data may have been (voluntary or involuntary) deleted. We may need to deal with:

1. File deletion.

2. Drive formatting or repartitioning.

3. Damaged drives or bad blocks.

One of the most typical tasks of computer forensics is the retrieval (complete or partial) of such deleted data. In general the OS is "lazy", and optimizations cause data persistence and locality. When deleting a file, the entry in the filesystem is flagged as "deleted". This means that the file can be easily recovered by simply undoing the previous operation. After some time either one of the following events can happen:

1. The filesystem entry will be removed (when the filesystem structure is rewritten or rebalanced). Until this happens we can find metadata on the file.

2. The actual blocks (once) allocated to the file will be overwritten with other content. Until this happens, we can retrieve the actual blocks on disk.

Linux filesystem

In Linux the filesystem structure looks like a list of indexes represented by a tree-like structure made of "Inodes":

download

Inodes are data structures which describe attributes of files and directories. a single Inode is the block of metadata plus an indirect block that indicates the position of the data blocks (of the same file that is referenced by the metadata). Metadata contain a lot of information, such as:

• Filesize and physical location

• Owner and group

• Last modified and accessed timestamps

• Number of times the Inode is referenced

• Access permissions

• Pointer to disk space which contain the files

HDD recall

Schermata 2022-03-11 alle 18.07.22

The minimum part of the track that can be read is called a sector. While a cylinder is the set of tracks that are in the same position on the platters. We still divide the space of the drive in sectors, in particular, OS think in clusters ( groups of sectors). The size of the cluster is a filesystem parameter (e.g. NTFS cluster size = 4k). It's the minimum size that the OS consider.

Slack space: Padding between end of file and next cluster. It can contain portions of older files. If the current file taking up that space on disk never gets deleted (for e.g. a .dll file), the old data once contained in the slack space of the same clusters is going to remain there forever. Generally it is less than 4kb. Note also that only some type of files can be recovered like that. For e.g. chunks of zip of mp4 files are of no use. Textual based file types instead are more prone to recovery.

Anti-forensics techniques

Techniques that aim to create confusion in the analyst, to lead them off track, or to defeat tools and techniques used by analysts. Two types, which targets the two technology dependent phases of the investigation:

1. Transient anti forensics: can be defeated if detected. (targets identification), because data is hidden and not deleted.

2. Definitive anti forensics: destroying evidence, or making it impossible to acquire, unreliable or tampered (targets acquisition).

Timeline tampering

One useful thing about forensics tools: reconstructing a timeline. Anti-forensics can target data used to create timeline (MAC[E] values: Modified, Accessed, Changed, Entry Changed. The latter is NTFS only). Note that anyone who has access to the file can modify the events very easily since there is no authentication on metadata (e.g. tools like touch in Linux allows you to do that).

File recovery tampering

File recovery uses data remnants that needs to be dealt with. Some techniques:

1. Secure deletion: Instead of deleting only metadata rewrite data with 0.

2. Encryption: when metadata are deleted also keys are probably deleted, the same applies to the entire hard drive.

3. VM usage: VMs does not write disks like bare metal OSes.

4. Wiping unallocated space: Used to remove remnants of old files. Note that this does not clean slack space.

Fileless attack

Attacker does not write the drive, exploitation happens only in memory. This is not uncommon, most exploitation frameworks have this capability (e.g. commercial frameworks like Metasploit can do this).

So when the machine is shut down, evidence is lost. Then the only hope is in-memory forensics; e.g. memdump, volatility.

Filesystem Insertion and Subversion Technologies

Idea: put data in places where there's no reason for it to be there. Many partitions have chunks of space which are reserved. This space can be filled with data that can remain hidden. Some notes:

• fsck is our enemy as it may repair metadata and trash our insertion.

• Inside a partition table there is space for ~32 KB of data.

• Data recovery will ignore these files. But carving will still work.

• Some examples:

  • RuneFS: writing in bad block inodes (unlimited space).

  • WaffenFS: adds a fake EXT3 journal in an EXT2 partition (up to 32 MB storage).

  • KY FS: uses directory inodes (unlimited space).

  • Data Mule FS: puts data in padding and metadata structures of FS ignored by forensic tools (up to 1MB of space on a typical FS).

Log injection (~transient)

Logs are really informative. The hard part is finding what we need inside it (regular expressions and filters come handy). Attackers may rewrite logs in a way that breaks scripts which parse logs. More on this here.

Partition table tricks (transient)

Less used tricks. There are three main subcategories of this type of strategy:

1. Partitions not correctly aligned. Using a partition restore tool we can read them, but they may escape a forensic analyst.

2. Adding multiple extended partitions. In the old MS-DOS days there was at most one extended partition per disk partition table. Later on OSes. introduced support for more than one extended partitions, but many forensic tools didn't, so they would not work to analyze data from those addition partitions.

3. The problem is that with a high enough number of partitions forensics tools would just not work. This means that if an attacker would create a really high number of partitions (for e.g. ~1000) some forensics tools would be neutralized.

Forensic Characteristics of Solid-state Drives

Introduction

SSDs are NAND-based flash memory chips used as mass storage. They became increasingly popular as prices dropped. They are widespread in mobile devices. Their main advantages are performances and usability (on the surface they look as HDDs, they have the same form factor and the same connectors).

Still, even if they look like HDDs, they are very different, and they have a huge impact on the work of forensics analysts. Why? NAND chips have a limited lifespan, which is lower than HDD's one. At a fundamental level they save data in blocks. The only way to update data is by emptying and refilling all the blocks containing pieces of that data (blanking of blocks). Blocks have a finite number of rewrites before failure (which is not that high). Also note that some areas of the disk are very hot (high num of writes), while other are less used.

FTL

Because of how SSDs work, some policies intended to improve SSDs lifespan were implemented, which are enacted by a controller called FTL (Flash Translation Layer), a hardware/software combination that sits between the ATA channel and memory chips. The FTL presents SSDs to the PC as if they were mechanical drives, then it performs series of operations to improve the performance of the SSDs and to increase their lifespan:

1. Write caching: every time a bit is changed the block needs to be rewritten. For speed and lifespan preserving reasons, it's better to keep this change in cache for a while.

2. Trimming: when writing there are actually two actions which are being performed: blanking + writing. Blanking is time consuming, writing is not. Here **trimming ** comes handy: basically it's preemptive blanking. If a block is not in use anymore, I blank it preemptively to make writing more efficient. This is problematic for forensic analyists -> no residual data to look for.

3. Garbage collection: : figuring out which blocks can be emptied -> blank them. Similar to trimming but performed without the indication of OS.

4. Data compression: for example 200 As can be stored as $A \cdot 200$ (instead of AAA...A). Problem: balance between performance and space optimization.

5. Data encryption/obfuscation

6. Bad block handling

7. Wear leveling: Balance cells to avoid unusually high straining levels on them -> greatly improve drive lifespan.

Problem: In HDDs we can reliably physically address a sector from the OS and read it on the drive, in SDDs FTL translates logical block addresses (LBA) as requested by the OS into the respective physical block addresses (PBA) on memory chips. The underlying mapping is completely transparent and can be modified by the FTL at any time for any reason. The FTL may move data around or blank data even if the OS is not running. This is a huge problem since most forensic approaches and tools rely on the ability of the OS to access the raw data.

Solution: there is none :( It is not possible to bypass the FTL via software, and it is money and time consuming to do it vis hardware (reading directly the memory chip for e.g. with flashing tools, JTAG ports, etc.). Other problems with this metodology:

• non-repeatable, leads to alterattion or destruction of the evidence

• very brittle process depending on firmware, hardware...

• information not public and actually heavily protected IP of vendors

Conclusion: SSDs implement techniques that are potentially disruptive to black-box forensics. The combination of controller, OS, filesystem and even disk usage can deeply influence forensic procedures. Even a simple quick format will trigger the TRIM of the SSD and in less than 15s, all data are wiped from the cells. In some weird cases, trimming is not done “correctly” so you could recover some files. In general, if files are trimmed they are gone. We cant apply carving nor slack space recovering. This means that the drive keeps changing also when connected to a write blocker. This is true also for the USB key, in this case often the FTL tends to “approximate” some data read, as a consequence the hash of the image of the USB drive is not consistent, it keeps changing.