Tags: forensics
Rating:
# Home Computer (forensics)
[Attachment](https://github.com/shawnduong/ctf-writeups/blob/master/2019-GOOGLE/attachments/day2.zip)
Let's go ahead and unzip the challenge and see what's in store for us.
Looks like we're dealing with an NTFS filesystem, and we're going to be doing some forensics on it. While Linux uses the open source ext4 and Mac OS X uses the proprietary APFS (Apple File System), NTFS stands for the New Technology File System, and is basically the proprietary filesystem that Windows systems use as Windows falls under the Windows NT (New Technology) family of operating systems.
Now, even though we have an NTFS filesystem right here, we can't just `cd` right on into it as we would a directory. We have the filesystem, not a directory that leads into the filesystem. In order to actually access the contents of the filesystem, we need to mount it to our own system at a specified mount point. After mounting the filesystem, then we can actually access it as if it were a directory.
We first need to create a mount point. The standard for mounting is to create mount points in the `/mnt` directory. We create a mount point by creating a directory, and so we can use `mkdir` as we would any regular directory. You'll often times need to do this as a higher privileged user, though, since it is of course being done in the `/mnt` directory and the nature of this operation warrants higher security measures.
After creating a mount point, we can then mount the NTFS filesystem to the mount point using `mount`. We'll also pass `-t ntfs` to specify that the type of filesystem we're mounting is NTFS, and we'll pass into the required positional arguments our filesystem in question as well as the desired mount point.
After successfully mounting, we'll go ahead and `cd` into the filesystem via the mount point and then list the contents using `ls`.
Let's navigate around and see if the flag is around here anywhere or if there are otherwise any clues. On Windows NT filesystems, user home directories can be found in `C:\Users`, so we'll snoop around there.
We stumble upon a hint in `C:\Users\Family\Documents\credentials.txt`.
It looks like the flag is an image file kept in extended attributes. Extended attributes are an interesting feature part of NTFS filesystems. Extended file attributes are used to attach metadata to files while being basically invisible as the system itself doesn't have much use for the data that they hold. Extended file attributes can store data of arbitrary lengths. They are not necessarily embedded into a file, per se, but are much closer along the lines of "abstractly linked."
On NTFS systems, extended file attributes can be found in alternate data streams, a particularly interesting feature of NTFS filesystems. Alternate data streams are essentially invisible to the untrained person in almost all ways, but anybody who knows what they're looking for can easily uncover them. Alternate data streams are often times used to hide data or, in more malicious circumstances, hide malware or parts of malware.
One of my favorite tools when it comes to filesystem forensics is The Sleuth Kit. I highly recommend them and they are the ones that I used for this challenge. They are, of course, free and open source, as all things should be.
In order to uncover the alternate data stream supposedly associated with `C:\Users\Family\Documents\credentials.txt`, we need to find its inode, and then we'll display the contents of the said inode. A file's inode is essentially a structure that stores all the information about a file except for its name and data, and in this case, we need to discover it to use as an identifier in order to display its contents.
Before we continue any further, we no longer have a purpose for the mounted filesystem. Everything from here forwards will be done on the NTFS filesystem file. We can go ahead and unmount the mounted filesystem using `umount`, and then we can remove the mount point created earlier using `rmdir`. This will, once again, require higher user privileges.
We can list all the file and directory names on the disk image using `fls`. We'll also pass `-r` so that it lists files recursively. Then, we're going to pipe the output into `grep` and look for the `credentials.txt` file in order to filter out everything else.
Looks like we've uncovered the extended attributes found in the alternate data stream associated with this file! We'll use its identifier, `13288-128-4`, in order to display its contents using `icat` (image `cat`). We can expect a lot of data to be outputted to the terminal that we don't need to understand since it's just image data, so let's instead do something more useful with it like piping it into `file` to see if it is indeed the image file (with image in this case meaning picture) that `credentials.txt` was talking about. We'll pass `-` into `file` to specify that we want it to read from STDIN. `file`, oddly, doesn't understand that from pipes.
Looks like we got it! Let's go ahead and `icat` its contents again, but this time redirecting the output into a file, and then opening it up using an image viewer.
This challenge was a lot of fun, and I learned a lot from it, especially since I didn't know a single thing about NTFS filesystems before this. Well done, Google. It sent me on a rabbit hole and I learned a lot more than I probably needed to about NTFS filesystems, but the more the merrier.
## Flag
```
CTF{congratsyoufoundmycreds}
```
# Next Stop
Next stop: [Government Agriculture Network](https://github.com/shawnduong/ctf-writeups/blob/master/2019-GOOGLE/beginners-quest/day3-government-agriculture-network.md)
