MFT and pagefile.sys

I don't follow your reasoning here…

How is the executable "showing" itself in the pagefile?

If the executable is "in" the pagefile, why do you think it should also be in the MFT, as well?

Thanks.

It is from a lab for my class and I have never seen anything like this and the book is not really helping. This is the last question of the lab and no one seems to be able to figure it out.

Additionally, you examine one of the compromised servers and find a reference to takeover.exe in the pagefile.sys file. Upon examining the data, you see FILE0 in the preceding data and again in the data that follows. From the F in the preceding FILE0 and the F in the one that follows, there are 1,024 bytes. When you examine the MFT, there is no such entry. What have you most likely found, and how can you explain the presence in the paging file but not in MFT?

Well you're asking two different questions here. One, ""an executable in the pagefile" and two, "no MFT record for that executable in the MFT". It's also confusing in that you talk about "additionally, when you examine a compromised server"…

So how many pagefiles, MFTs, boxes we talking about? Each one has the executable/mft record issue?

Since you came clean and indicated it's for homework, just copy/paste the question and maybe someone will take a stab at it rather than just trying to interpret your summary.

I assume you mean that you looked in the pagefile.sys and did a string extraction.
In the collection of strings that were extracted you found a string that looked like a file name.
But you now can't find a record of that file on the system.

The obvious explanation would be that the file was deleted. NTFS records can be overwritten very quickly, especially on the boot drive.

It is from a lab for my class and I have never seen anything like this and the book is not really helping. This is the last question of the lab and no one seems to be able to figure it out.

Okay, that helps. What exactly, is the question?

It seems to me at this point that the issue isn't that there is an executable file in the pagefile, but that there's an MFT record that points to a "takeover.exe" in the pagefile. When you said, "<i>I have found an executable that is showing itself in the pagefile…</i>", I think that most folks would assume that you had carved the pagefile, found an MZ identifier, followed by a legitimate PE header, etc.

Additionally, you examine one of the compromised servers and find a reference to takeover.exe in the pagefile.sys file. Upon examining the data, you see FILE0 in the preceding data and again in the data that follows. From the F in the preceding FILE0 and the F in the one that follows, there are 1,024 bytes. When you examine the MFT, there is no such entry. What have you most likely found, and how can you explain the presence in the paging file but not in MFT?

Well, let's reason through this a bit…

First, I'm assuming that you're using a Windows system…so, which version is it? On the surface, that may not matter for the immediate question, but it may matter later on…

Second, MFT records are not deleted from the MFT. When a file is deleted, the record is marked as not in use, and then reused. This would explain why there doesn't seem to be a corresponding record in the MFT.

So, the question might be, how did the record end up in the pagefile? Well, we know that the pagefile is relatively unstructured (I use that term loosely) data that acts as additional memory. One way for the record to appear in the pagefile would be that it was opened in a viewer, maybe copied to the clipboard, etc. Now, there will likely be other ways for this to occur, and this is just one possibility. In short, the idea is that for the record to appear in the pagefile, it had to have been in active memory (ie, RAM) and gotten swapped out.

What I might do in your case is look in the Registry for the user account (whichever was the most active), and look for any interaction with the file, or with a viewer of some kind.

The record that you extracted from the pagefile should include a reference to the parent record…files are not children of files, they're children of directories/folders. Parse the MFT record header, and get the pointer to the parent, and then parse the MFT in order to determine which record that is…if the folder wasn't deleted, this can tell you which folder takeover.exe was "in" when it was "live" on the system. Then go to that directory and look for the $I30 file…this is a metadata file that you won't see through normal browsing of the directory, but it should be visible in FTK Imager. Parse this file, or just look in it to see if you can locate a reference to the file name in question.

Another avenue of analysis might be to determine when the .exe file last existed on the system…you could approximate when it was deleted, and validate that by comparing it to the MFT entry change time that you found in the record you extracted from the pagefile (assuming that that was actually *when* the file was deleted). Then, use that time as a "pivot point" in timeline analysis to determine what activity was occurring on the system at that time…see what the user was doing, etc. This is where the version of the OS comes into play…you might have System Restore Points, or better yet, Volume Shadow Copies, to provide additional, historical data.

HTH

Second, MFT records are not deleted from the MFT. When a file is deleted, the record is marked as not in use, and then reused. This would explain why there doesn't seem to be a corresponding record in the MFT.

I might add that a $MFT entry or record has a number, so it is easy to compare the entry in the $MFT with the same numbered $MFT entries of all volumes mounted on the server, and determine if (by chance) that same numbered entry is still unallocated or it has been re-used for another file (more likely).
Of course it could be a copy of an entry of the $MFT of a removable volume that is not anymore mounted, but there would most probably be other traces of the usage of an external volume (such as a USB or firewire or e-sata device).

jaclaz

jaclaz,

I might add that a $MFT entry or record has a number, so it is easy to compare the entry in the $MFT with the same numbered $MFT entries of all volumes mounted on the server, and determine if (by chance) that same numbered entry is still unallocated or it has been re-used for another file (more likely).
Of course it could be a copy of an entry of the $MFT of a removable volume that is not anymore mounted, but there would most probably be other traces of the usage of an external volume (such as a USB or firewire or e-sata device).

Where is the number that you're referring to? If it's in the MFT record, where (offset) could the original poster find it in the data he extracted from the pagefile?

Wow, forgot to check in yesterday and come back today to find awesome respones. I feel that the route KeyDet89 is the one that the lab wants me to take. A lot of the learning this week has been about registries and what we can find in them. Although using your technique I can see how getting the information and tracing it back to the MFT can be very useful in a case or lab.

Also it was a USB device attached to the computer so finding trace of that in the MFT is likely.

jaclaz,
Where is the number that you're referring to? If it's in the MFT record, where (offset) could the original poster find it in the data he extracted from the pagefile?

MFT record number or "Number of this MFT Record", offset 0x2C, 4 bytes
http//www.reddragonfly.org/ntfs/concepts/file_record.html

jaclaz