Digital Forensics & Incident Response & Reverse Engineering
Have you ever encountered on-disk artifacts originating from another system?
Typically, this is something you see when a custom operating system image had been deployed to multiple computers by IT staff (on-disk artifacts appeared before the image is captured become a part of that image).
But there are some minor artifacts existing in installation images coming from Microsoft!
This is a reply to the Sunday Funday 4/5/20 challenge. The goal of this post is to document the process, not just the results. You have been warned.
The Background Activity Moderator (BAM) is a Windows 10 thing that does… something! Because we don’t know much about it.
We know that this thing provides evidence of execution by listing executables under the following registry key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\bam\State\UserSettings\<User SID>
Each piece of evidence is stored as a registry value (REG_BINARY), its name is set to an executable path and its data is set to a binary structure with a FILETIME timestamp inside (this is believed to be the last execution timestamp).
In the Linux world, a deleted file which is still open isn’t actually removed from a disk. Instead, it’s just unlinked from the directory structure. This is why a system call used to remove files is named “unlink”.
unlink() deletes a name from the filesystem. If that name was the last link to a file and no processes have the file open, the file is deleted and the space it was using is made available for reuse.
If the name was the last link to a file but any processes still have the file open, the file will remain in existence until the last file descriptor referring to it is closed.
(Source.)
The same behavior can be observed in other Unix-like operating systems.
But in Windows 10, similar behavior can be seen too!
Have you ever heard of scoped shadow copies? They have been around since the release of Windows 8, but not much information is available on this topic.
A shadow copy becomes scoped when data blocks not required by the system restore process are excluded from copy-on-write operations. When you create a restore point, a scoped shadow copy is created by default for a system volume (in Windows 8, 8.1 & 10).
Many unexpected things happen under the hood when you do live forensics. Tools used to acquire data from running Windows systems often utilize direct access to logical drives to copy locked files and extract NTFS metadata. But did you know that NTFS metadata is updated when you read a logical drive directly?
Continue reading “You write to a logical drive when you read from it”
There are forensic tools capable of carving file records and index entries ($I30) from memory dumps, but there is much more NTFS-related metadata which isn’t exposed by usual memory forensics frameworks. For example, file control blocks.
Continue reading “Carving file control blocks from memory dumps”
Here is a list of open research topics in Windows forensics. All topics in this list are relevant to my research. Feel free to pick one for your research. Originally, I wrote this list for myself, but it’s better to make it public.
More topics and ideas (in other areas too) can be found here and here.
During the development of the parser for shadow copies, I observed many systems containing invalid data in shadow copies. For unknown reasons, some allocated files may contain null blocks instead of valid data blocks as well as blocks of data which should not be there.
Continue reading “Things you probably didn’t know about shadow copies”
A small addition to this post.
Starting from Windows 10 “Redstone 3” (Fall Creators Update), it’s possible to create an NTFS volume using one of the following cluster sizes: 128K, 256K, 512K, 1M, 2M. Previously, the largest supported cluster size was 64K.
Currently, I’m not aware of any third-party tools that support such large clusters: there is no support in the NTFS-3G driver, no support in the Linux kernel (#1, #2), no support in The Sleuth Kit, no support in RawCopy, no support in several proprietary forensic tools.
This update also changed the way how the “sectors per cluster” field (located in an NTFS boot sector) is treated. Previously, this was an unsigned byte and its value was treated literally. Now, this is a signed byte and its value is used as shown in the following pseudocode:
// Argument:
// - SectorsPerCluster: a signed byte (from the offset 13 in an NTFS boot sector).
// Return value:
// - A true number of sectors per cluster.
NtfsGetTrueSectorsPerCluster(SectorsPerCluster)
{
if ((unsigned)SectorsPerCluster > 0x80)
return 1 << -SectorsPerCluster
else
return (unsigned)SectorsPerCluster
}
This isn’t the same as the algorithm used when dealing with the “file record segment size” and “index record size” fields in an NTFS boot sector, note the edge case when the byte is equal to 0x80 (this corresponds to a negative value, but it’s still used as unsigned for backward compatibility, because 0x80 is used for 64K clusters).
A sample file system image can be found here.
Memory images, page files, hibernation files, crash dumps are standard targets for memory forensics. But there are unusual ones: for example, chunks of disclosed (leaked) uninitialized kernel memory found on a drive.
Continue reading “Forensic analysis of disclosed uninitialized kernel memory”
