How did the suspect...
 
Notifications
Clear all

How did the suspect hide these folders?

18 Posts
10 Users
0 Likes
2,902 Views
(@anucci)
Posts: 21
Eminent Member
Topic starter
 

Hello Everyone.

I am working a CP case in which the suspect used a method (still unidentified) to hide hundreds of folders containing CP.

Using a hardware write blocker, I previewed the SD card to determine if CP was present in order to do a more in depth examination. *Due to the number of devices we seize in these investigations I've found that previewing to determine evidentiary value works best in these instances*

I previewed the directory structure using File Explorer on a Windows 7 forensic station just to review what was visible to the user. I then loaded the physical drive with FTK imager to have a better look at anything in unnallocated space …and…SURPRISE! there are numerous folders (not showing deleted), in the regular directory which I can clearly review and examine in FTK imager, but they are no where to be found if I inspect the SD card using File Explorer.

I checked to see if the user set the folders to be hidden (as a Windows protected file or hidden folder) and this was not the case. I was able to see all of my OS protected and hidden folders, but these from the SD card were not visible.

I also used the command line to navigate the directory, and I was still unable to see the folders within the directory using CMD.

I then tried inspecting the folders using 7-ZIP file manager… and I was not able to see any of the folders that FTK imager was displaying in the directory.

I tripple checked that I was looking at the same piece of evidence in File Explorer as in FTK, and I was.

I researched online for several tools that claim they can hide folders and make it so that you cannot see them even in CMD… but after testing… I noted the hidden folders were visible if you connected the removable media to another device that did not had the software installed.

I am always looking for hidden crates and caches in computers and I have had users set their folder properties to be hidden, but this is simple to explain.

Has anyone encountered anything like this before? Maybe I am missing something very simple… but I just cant seem to figure out how the user hid the folders in a way CMD can't see them. The folders do not appear to be deleted and are allocated within the directory structure.

Any ideas?

 
Posted : 27/06/2018 7:11 pm
kastajamah
(@kastajamah)
Posts: 109
Estimable Member
 

Do you know what kind of device the SDcard was in? Is it possible that it has a proprietary folder structure that Windows does not see, but FTK Imager does?

Also, what is the file system on the card? NTFS, ExFAT, FAT32? Is it possible it was once in a Mac and formatted ExFAT? I have seen ExFAT drives that were used in a Mac that had file folders I could see in the Mac but not in Windows.

 
Posted : 27/06/2018 7:21 pm
(@anucci)
Posts: 21
Eminent Member
Topic starter
 

Do you know what kind of device the SDcard was in? Is it possible that it has a proprietary folder structure that Windows does not see, but FTK Imager does?

No. The folder structure screams Windows to me but I could be wrong. I can see several deleted folders, among them some that look like recycle bins. I also noted that the folder structure did not have any of the ".blahblah" hidden files you would generally see in a MAC.

The file system is FAT32

There is a possibility this was in fact used in some other system, but I was trying to gather ideas as to what could have potentially been done to hide these folders. Your suggestion gave me an idea … so I will try mounting the image using a Linux Distribution and see if I can see the folders.

My next thing will be to examine the computer seized in this case and see if I can tie the SD card to the PC…then determine if there's any software installed that would be capable of such a functionality. But so far… not knowing how they managed to hide them is killing me with curiosity.

Thanks for your reply

 
Posted : 27/06/2018 7:31 pm
JimC
 JimC
(@jimc)
Posts: 86
Estimable Member
 

If the file system is FAT32 that greatly narrows the possible ways this could be done.

All of the possibilities below "abuse" the FAT specification in some way

1. Overwrite proceeding directory entry with 0

In most implementations this causes the directory parsing to stop. However, the subsequent directory entries remain and critically so do the allocated data clusters. If the "hidden" entry contains a sub-directory it and all child folders will also be hidden. In this case, it isn't even necessary to overwrite the whole directory entry, simply replacing the first character of the filename with 0 is sufficient.

You can re-create this scenario easily by

a. Create a new small FAT volume
b. Create 3 small files
c. List the directory. All three files should be visible
d. Overwrite the first character of the middle file with 0
e. List the directory again. Only the first file remains

This situation would show up in your Hex editor like this

http//www.binarymarkup.com/ForensicFocus/badfat.jpg

2. Create a new "root" directory

Unlike FAT12/16, FAT32 allows the root directory to be in any data cluster. The root directory is specified in the VBR. A user could create this scenario by

a. Create sub-folder called "Root"
b. Populate this folder with harmless content
c. Modify VBR to point to the new root

3. Modify attribute bits

FAT uses a single byte in the directory entry to describe the attributes of the file/directory. Changing a single bit in this can change a sub-directory to apparently become a 0 byte file. This will have the effect of hiding the contents of the sub-directory from a casual observer.

4. Use non-standard characters in filename

I haven't tested this scenario but the specification reserves certain characters. It is possible that replacing the first character of the filename with such a character would confuse the directory parsing.

I wouldn't be surprised that there are other methods I haven't thought of and look forward to hearing about them shortly…

Jim

www.binarymarkup.com

 
Posted : 27/06/2018 11:29 pm
MDCR
 MDCR
(@mdcr)
Posts: 376
Reputable Member
 

Could it be as simple as

attrib +h foldername
or

mkdir {ALT+255}Foldername
We used to do stuff like that in the 90s on old FAT filesystems to hide stuff from an overzealous administrator with a god complex. Does not work on NTFS formatted partitions.

 
Posted : 28/06/2018 6:16 am
(@athulin)
Posts: 1156
Noble Member
 

I previewed the directory structure using File Explorer on a Windows 7 forensic station just to review what was visible to the user. I then loaded the physical drive with FTK imager to have a better look at anything in unnallocated space …and…SURPRISE! there are numerous folders (not showing deleted), in the regular directory which I can clearly review and examine in FTK imager, but they are no where to be found if I inspect the SD card using File Explorer.

Difference of behaviour may only indicate a bug. If so, you have to find just what triggers it.

Remember to run 'chkdsk -f' or equivalent on the volume you want to know that it contains a FAT32 file system. If it doesn't, interpretation based on the assumption that it is will be incorrect.
(I don't remember if you can fsck a FAT32 volume on Unix? if you can, try that too.

You want to know if there are any reports of inconsistency. If there are none, that's also a result.

Get and read the FAT32 specification in FATGEN103 document. (The use of 0x00 as first directory entry character is described and documented on p. 23, as are use of 0x05 and 0xE5. Is that how you established that these files were not deleted? No 0x00 or 0x05? ) (It's unfortunate that the document is old – I'm not aware of a later version …)

One possibility of hiding that hasn't been mentioned yet in the thread (?) is files with ATTR_VOLUME_ID. This flag says that this file is not a real file, but its name is used as a volume name only, and there should be no cluster chain associated with it. This type of file is supposed to be restricted to one instance, and directory record is located in root directory only, and is generally not displayed as a file. But … what if those assumptions are broken? What if more than one file is flagged as ATTR_VOLUME_ID? A normal dir lister would probably not list them … but something like FTK Imager might. Will chkdsk find it? No idea … What if a directory is flagged as ATTR_VOLUME_ID?

 
Posted : 28/06/2018 7:19 am
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

Usually (but not necessarily) 7-zip can *see* files with malformed fillenames (like the ALT+0160 or 0255 trick).

On command line, try anyway

DIR /X
(that usually shows these mis-named files).

Another (possible) technique is that of using two non-copies of a single FAT (normally there are two of them and they are automatically synchronized by the filesystem driver) but for at least FAT16 it is perfectly possible to use a single File Allocation Table in normal operation, and one could switch from the one to the other by changing an offset field in the VBR, but if this was the case most probably the FTK would find those only by carving and not as "normal" directory.

Check also if the used space is "counted" by the Windows tools, i.e. if the volume appears more full than it should be if only the sizes of "visible" files in Explorer are added up.

As a side-side note and tested on FAT16 only

One possibility of hiding that hasn't been mentioned yet in the thread (?) is files with ATTR_VOLUME_ID. This flag says that this file is not a real file, but its name is used as a volume name only, and there should be no cluster chain associated with it. This type of file is supposed to be restricted to one instance, and directory record is located in root directory only, and is generally not displayed as a file. But … what if those assumptions are broken? What if more than one file is flagged as ATTR_VOLUME_ID? A normal dir lister would probably not list them … but something like FTK Imager might. Will chkdsk find it? No idea … What if a directory is flagged as ATTR_VOLUME_ID?

that would be a "flag"for the name of the volume (i.e. normally the LABEL command) that different OS set differently as either 0x08 or 0x28
https://msfn.org/board/topic/154648-dos-format-b-and-label/

jaclaz

 
Posted : 28/06/2018 8:33 am
JimC
 JimC
(@jimc)
Posts: 86
Estimable Member
 

@athulin I don't think this is a bug. The FAT spec says the directory "ends" when when the first directory record starting with 00 is encountered. This behavior is by design and isn't a bug. FTK is no doubt wise to this trick and keeps parsing.

@jaclaz You are correct that you can effectivly ignore a FAT table by moving the offset in the VBR and changing the number of FAT tables accordingly. This could be used to "hide" the allocation of clusters in a "private" FAT. However, this technique wouldn't itself hide a directory entry. I think this can probably only be done by abusing the 32-byte directory entry itself. As noted already, the main candidates are the first byte of the filename, the attribute byte or the file size (see below).

To expand on this further, I would suggest the following subtle variations to my original post

3b. Modify attribute bits - Remove directory flag (0x10)

Removing the directory flag (0x10) from the attribute byte (offset 0x0b) converts the directory to a zero byte file. This file would still be visible in a directory listing but access to the sub-directory and it's contents would no longer be available. This would show up as an error with CHKDSK.

3c. As above, but also change size to 1 byte

This would make the file "valid" and casually looking at the file would reveal it contained as single "." character. I made a screenshot of this here

http//www.binarymarkup.com/ForensicFocus/badfat2.jpg

This would make quite a good competition - To find the best way to hide a file on a FAT drive that still passed CHKDSK…

Jim

www.binarymarkup.com

 
Posted : 28/06/2018 9:45 am
(@anucci)
Posts: 21
Eminent Member
Topic starter
 

Hello Everyone.

Thanks for your suggestions. A couple of things…

The SD card itself only has one visible directory called "Documents" when inspecting this folder I can only see files such as .xls, .doc, .pdf, and .zip files, among others. However this Folder does not show any "subfolders" despite having 39 identified by FTK Imager. None of these folders are visible in File Explorer.

While using FTK Imager to inspect the "Documents" folder, I get a message from FTK saying "cached_drive_imageread_blocksindex out of bounds". Not sure if this has anything to do with it but figured I would mention it.

I am still expanding my knowledge in FAT32 and going about editing the files as suggested by JimC, but I am having difficulties…so I may need a bit more guidance if possible. I am trying to test this on my own to see what possibilities could have been used to hide the files.

By looking at the Hex of the root directory I can only see a lot of files that show as "previously deleted in FTK" and then the single "Documents" folder. I then navigate to this folder and get the above referenced message from FTK.

Within the "Documents" directory, I can see all the files and folders listed as expected, but I did not note any "0" in front of the directory names for the hidden folders, or anything similar. In fact they have an "A" appended to the name…

Again, sorry about the simplicity of my explanation. Maybe I should start by learning more and refreshing my memory on the file system and how its structured.

Thanks again for any help, and sorry about the hand holding. )

 
Posted : 28/06/2018 10:22 pm
(@athulin)
Posts: 1156
Noble Member
 

While using FTK Imager to inspect the "Documents" folder, I get a message from FTK saying "cached_drive_imageread_blocksindex out of bounds". Not sure if this has anything to do with it but figured I would mention it.

Unless someone else here knows what that is, you need to ask Access Data for the exact meaning … or perhaps look in the AD knowledgebase/equivalent for discussion of it. (I hope you're using the latest version of the software?)

My guess would be that a directory entry somewhere (which?) references a disk cluster that is not found within the image. That could mean

… that the image or the volume is truncated. When that happened is not clear – it might be that the device you're looking at earlier was the destination for a block copy that eventually failed. It might be that the image of the device was truncated at some later point, and what you have is only the 'first half' of a FAT32 file system. (Should be easy to test the FAT bitmap size should tell you.)

… or that the cluster calculations are messed up FTK Imager does it one way, while the software that created the volume did it another way. The FATGEN103 document identifies this problem as known, and provides The True Algorithm, but until you know what software created the volume, you can't say for certain that it was used. There is, for example, an ISO standard for a subset of FAT that is slightly different. (I would think this would be less likely, though.)

… or something else. The fact that you get an error message is significant, as it affects interpretation. You must report it.

This very probably changes the question you are no longer looking at a sound file system. That means that all interpretations ('how did X hide these files?') are off until you know exactly to what extent the file system is sound. As far as I can see, you can't even say that the files were hidden at this point, only that they seem to have been deleted at some point.

You almost certainly want to use some tool with better diagnostic capability in order to get a better idea of the extent of the problems.

By looking at the Hex of the root directory I can only see a lot of files that show as "previously deleted in FTK" and then the single "Documents" folder. I then navigate to this folder and get the above referenced message from FTK.

The only way I can think of to explain that seems to be that you do have a 0x00 situation, but that it applies to an previous directory entry than 'Documents', as the first character of the directory name has not been overwritten.

You can't rely on further interpretation until you know what the error message refers to, and how it affects the operation of FTK Imager. Does FTK Imager manage to read the directory contents? or does it read only part of it? or perhaps none of it, and what you see is consequence of poor error recovery? (You have to find out.)

On the assumptions that some part of it is read …

Within the "Documents" directory, I can see all the files and folders listed as expected, but I did not note any "0" in front of the directory names for the hidden folders, or anything similar. In fact they have an "A" appended to the name…

The 0x00-conventions applies to deletion of a subset of directory entries (I think). When an entire directory is deleted (such as by CMD-line X>\RMDIR /S DOCUMENTS) I would not expect such details.

 
Posted : 29/06/2018 6:22 am
Page 1 / 2
Share: