Hello Reader,
Continuing from last weeks blogs on how to solve the 9/15/13 Sunday Funday we've covered how to quickly determine which USB devices were connected, today lets look at another method that was used to transfer data FileZilla.
This is an interesting piece of analysis for me as its fun to see what an application you use on a regular basis leaves behind. In the case of FileZilla our source of evidence is the xml configuration files that FileZilla leaves behind in the %user%\appdata\roaming\filezilla directory. For our contest image that was \users\suspect\appdata\roaming\filezilla:
The first we want to look at is the filezilla.xml file that retains user preferences:
You can see contained within this xml is the last local directory the user viewed with the FTP client. Why is this important? When uploading files the user has to pick which local directory to upload them from, in this case that's \Users\Suspect\Contacts
Next we want to know what server he was connecting to, for that we look at recentservers.xml also located in the same directory.
We can see that our suspect connected to the IP 192.168.1.229 and authenticated as the user NT-GLTY.
I've checked the $logfile and $usnjrnl neither record which files were accessed on 9/3/13 between 9:43pm and 9:47pm when these uploads occured and as this is a Win7 system no longer updates access times when a file is accessed we get no clues from the MFT. Instead we can determine that FileZilla executed from the presence of the prefetch file located in \windows\prefetch and the temp files seen in the $usnjrnl:$j:
So the conclusion we can reach is that our suspect connected to a FTP server running on 192.168.1.229 as the user NT-GLTY on 9/3/13 between 9:43pm and 9:47pm and accessed the directory C:\Users\Suspect\Contacts. As we see no file creations during this time period in the $usnjrnl::$j we can assume no files were downloaded. We can also propose that files from the contacts directory were uploaded but we won't know that without examining the FTP server logs.
The only remaining artifact to find would be the deleted journal for the queue.sqlite3 database. The database itself contains no deleted records so only the deleted journal for the sqlite database may contain this data. Matthew and I will take a look at that this week.
Thanks for following along, tomorrow lets look into what we can determine from the Gmail web accesses.
Continuing from last weeks blogs on how to solve the 9/15/13 Sunday Funday we've covered how to quickly determine which USB devices were connected, today lets look at another method that was used to transfer data FileZilla.
This is an interesting piece of analysis for me as its fun to see what an application you use on a regular basis leaves behind. In the case of FileZilla our source of evidence is the xml configuration files that FileZilla leaves behind in the %user%\appdata\roaming\filezilla directory. For our contest image that was \users\suspect\appdata\roaming\filezilla:
Next we want to know what server he was connecting to, for that we look at recentservers.xml also located in the same directory.
We can see that our suspect connected to the IP 192.168.1.229 and authenticated as the user NT-GLTY.
I've checked the $logfile and $usnjrnl neither record which files were accessed on 9/3/13 between 9:43pm and 9:47pm when these uploads occured and as this is a Win7 system no longer updates access times when a file is accessed we get no clues from the MFT. Instead we can determine that FileZilla executed from the presence of the prefetch file located in \windows\prefetch and the temp files seen in the $usnjrnl:$j:
So the conclusion we can reach is that our suspect connected to a FTP server running on 192.168.1.229 as the user NT-GLTY on 9/3/13 between 9:43pm and 9:47pm and accessed the directory C:\Users\Suspect\Contacts. As we see no file creations during this time period in the $usnjrnl::$j we can assume no files were downloaded. We can also propose that files from the contacts directory were uploaded but we won't know that without examining the FTP server logs.
The only remaining artifact to find would be the deleted journal for the queue.sqlite3 database. The database itself contains no deleted records so only the deleted journal for the sqlite database may contain this data. Matthew and I will take a look at that this week.
Thanks for following along, tomorrow lets look into what we can determine from the Gmail web accesses.
