Forensic artifacts and traces showing NTFS mounted in Linux

Linux drivers for NTFS file systems don't use the write-ahead log ($LogFile). Check the latest recorded operation there and compare it against other data. Also, look for file records with LSNs set to 0.

And here is a tool to do that https://github.com/msuhanov/dfir_ntfs

I'm an examiner analysing a Windows 7 (non-encrypted) system and find very unusual results. Most deleted files are shown under EnCase (6 & 8.0) as scrambled (secure erase characteristics) despite it being marked as deleted (not overwritten) - overwritten files do exist and some deleted files can be recovered. Many deleted files appear within the EnCase "Lost" folder.

Just a word of caution…reading through your post, it seems that you're relying very heavily on what EnCase is "telling" you.

Aside from what EnCase is telling you, what other indications do you have that the deleted files show evidence of being securely erased? For example, if you understand that file structure format of OLE files, fragments of these files could possibly look "scrambled" when viewed via a hex viewer.

It might be worth your while to revisit your base assumption, and consider what has led you (assumptions, etc.) to where you are now.

Looking at the prefetch directory, it doesn't have any records of a secure file wiping tool like eraser / cipher being run. Web history, registry keys, VSC, MFT, Windows Event Logs, Shellbags, Link Files, do not show any evidence of anti forensic tools.

Can you elaborate on what you're looking for, specifically?

Don't take this the wrong way (because it's not intended as such) but if you do believe that anti-forensics tools were used, then perhaps by definition, you may not find anything. Or at least not what you may think you'd find.

I'm starting to wonder if the user used a Linux boot USB containing anti-forensic tools to erase / wipe the files of interest (MS office documents), and if there is a way to determine if a NTFS partition / volume has been mounted (with read-write) using Linux.

That's a good thought, but I have to ask…what have you done to investigate that? Have you tried imaging a system, booting to Linux USB, doing something, and then performing analysis?

I'm not asking to call you out. I'm asking because this is something that a lot of analysts have thought of, and most have done exactly what you did…post to a public forum. Over tiem, some have gone out and tested their theory, and shared findings via comments and blog posts.

As such, have you done your own investigation into the effects of booting a Windows 7 system via Linux USB, or have you done a "literature search" for anything that may discuss the effects of doing so?

Alternatively, has anyone heard of any tool that runs in Windows to perform secure file erase and does not leave a forensic trace after wiping?

I can't say that I have, but then, most of the tools that I'm aware of are pretty easy to hide from an examiner relying on the forensic application to tell them about it.

I may add that there is no real need of Linux to partially or integrally overwrite (possibly with digital garbage) a given file (or set of files), it seems to me that you are focused on "high level" tools/operating systems whilst a "modest" grub4dos by (cleverly) using the blocklist and dd commands or a similar approach from within Windows (yep, direct disk access 😯 ) would do just fine.

jaclaz

Hi all,

Appreciate all your comments, feedback, and thoughts. Thanks @thefuf for suggesting a tool and @jaclaz for sharing another possible explanation to the scenario I'm encountering. I'm also extremely honored to have @keydet89 (H. Carvey himself?) respond to my query. Perhaps I could assist to elaborate a bit below

Just a word of caution…reading through your post, it seems that you're relying very heavily on what EnCase is "telling" you.

Aside from what EnCase is telling you, what other indications do you have that the deleted files show evidence of being securely erased? For example, if you understand that file structure format of OLE files, fragments of these files could possibly look "scrambled" when viewed via a hex viewer.

It might be worth your while to revisit your base assumption, and consider what has led you (assumptions, etc.) to where you are now.

I rely on EnCase as one of the preliminary tools to view and analyse an E01, and I chose to use this tool to illustrate that I have taken into account files that have been overwritten, and have the expectation that the file contents are scrambled. However, for many files marked as deleted, and the hex shown as "scrambled", I can't help but wonder if a secure erase tool was involved. Several of these deleted files seem to have their "active" (non-deleted) counterparts with the exact file name and size (to the byte), suggesting that the file has been securely erased.

Also, I might have left out a key point by not stating that this is a corporate computer which is locked down (and Domain admins have records of installed applications) and the user does not have administrative rights. One loophole I noted was the BIOS was not password protected and OS was not encrypted - thus explaining how I came suggest the user might have used a Linux boot disk.

Can you elaborate on what you're looking for, specifically?

Don't take this the wrong way (because it's not intended as such) but if you do believe that anti-forensics tools were used, then perhaps by definition, you may not find anything. Or at least not what you may think you'd find.

Given the scenario, I was hoping to locate traces (and artifacts) of tools like SDelete, Eraser, CCleaner, etc. on the drive.

That's a good thought, but I have to ask…what have you done to investigate that? Have you tried imaging a system, booting to Linux USB, doing something, and then performing analysis?

I'm not asking to call you out. I'm asking because this is something that a lot of analysts have thought of, and most have done exactly what you did…post to a public forum. Over tiem, some have gone out and tested their theory, and shared findings via comments and blog posts.

As such, have you done your own investigation into the effects of booting a Windows 7 system via Linux USB, or have you done a "literature search" for anything that may discuss the effects of doing so?

I have not tested my theory, but was hoping a fellow CF examiner could share some of their experiences and save some time instead of having to "reinvent the wheel". o

Note Other tools used include RegRipper (thanks @keydet89), Axiom, Triforce, and a few other NTFS artefact parsers.

Thanks again everyone and will update if I find anything new.

I rely on EnCase as one of the preliminary tools to view and analyse an E01, and I chose to use this tool to illustrate that I have taken into account files that have been overwritten, and have the expectation that the file contents are scrambled. However, for many files marked as deleted, and the hex shown as "scrambled", I can't help but wonder if a secure erase tool was involved. Several of these deleted files seem to have their "active" (non-deleted) counterparts with the exact file name and size (to the byte), suggesting that the file has been securely erased.

Can you explain better (or provide an example)? (I am not understanding what you mean by (scrambled) file and "its counterpart".

Also what do you mean by "scrambled"?
I mean, when a file is "deleted" the extents it occupies are "marked as free" and the contents of *any* other file may take the place it occupied.

So, a file can be "deleted" (and partially overwritten) but not "scrambled".

Usually - but not always - there could be a noticeable difference between "scrambled" and "parts of other files that happen to have been written on that location" as the entropy of the contents will be different, see
http//www.forensickb.com/2013/03/file-entropy-explained.html

jaclaz

I rely on EnCase as one of the preliminary tools to view and analyse an E01, and I chose to use this tool to illustrate that I have taken into account files that have been overwritten, and have the expectation that the file contents are scrambled. However, for many files marked as deleted, and the hex shown as "scrambled", I can't help but wonder if a secure erase tool was involved. Several of these deleted files seem to have their "active" (non-deleted) counterparts with the exact file name and size (to the byte), suggesting that the file has been securely erased.

As with Jaclaz, I'm having a bit of a time wrapping my head around this one, as well…particularly the part about deleted files having an "active" counterpart.

From my perspective, this is what I'm envisioning…the deleted files were found, not as a result of file carving; if that were the case, they wouldn't have file names such that you could find an "active counterpart". Instead, it sounds as if (and please correct me if I'm wrong…) what's happened is that the "deleted" files are actually MFT records marked as "not in use". This would result in the conditions you mentioned, specifically having an "active" counterpart, meaning that there are two MFT records for files of the same name, one of which is marked as "not in use". This would give you a file of the same name and size, but one appearing to be 'scrambled'. In this case, the 'scrambledness' would be the result of the run list from the MFT record pointing to sectors that no longer make up a file, but are just whatever binary junk is sitting on the disk.

Something to consider in this case is file system tunneling…see 'test 3' at the blogpost below

https://windowsir.blogspot.com/2014/07/file-system-ops-effects-on-mft-records.html

I'm not stating that this is the case, I am just suggesting that this might be a possibility.

Also, if the 'deleted' files are OLE format files, they might appear to be 'scrambled' based on a casual view.

HTH