Hello, cyber-sleuths! Today, we’re diving deep into the world of FileZilla forensics. Ever wondered what happens when an incident responder needs to retrace a user’s actions in FileZilla? It’s a fascinating journey, full of memory dumps and XML artifacts. Let’s get started!
Where Do We Look?
First, let’s understand where FileZilla leaves its footprints. One of the main sources of evidence is the XML configuration files that FileZilla leaves behind in the %user%\appdata\roaming\filezilla directory.
There are two key XML files we should look at:
- filezilla.xml: This file retains user preferences, and crucially, the last local directory the user viewed with the FTP client. This is significant because when uploading files, the user has to pick which local directory to upload them from.
- recentservers.xml: This file is where we can find out what server the user was connecting to. For instance, our suspect might have connected to a specific IP and authenticated using a particular user ID.
What Can Memory Tell Us?
But what if the user or threat actor deleted FileZilla? That’s where memory forensics steps in. By taking a RAM image and using Volatility to dump the FileZilla process from memory, we can uncover a treasure trove of information.
In the memory, we can find details like the IP address, user and password, files accessed, commands used, download and upload info, remote servers connected to, VPN connections, prefetch files, and even \Device\HarddiskVolume folders.
Remember, memory can also reveal the list of files uploaded on the FTP server. And, interestingly, even the server we connected from can be identified from the dumped process of Volatility.
Windows System Artifacts
On the Windows side, the $logfile and $usnjrnl can help us determine when FileZilla was executed. Even though these files do not record which files were accessed during a particular time, they can reveal the presence of the prefetch file located in \windows\prefetch and the temp files.
It’s important to note that conclusions drawn from this data are not definitive. For example, if our suspect connected to an FTP server at a certain time and accessed a particular directory, we can only propose that files from that directory were uploaded. To confirm this, we’d need to examine the FTP server logs.
Looking for Deleted Records?
A final area to explore is the deleted journal for the queue.sqlite3 database. While the database itself might not contain deleted records, the deleted journal for the SQLite database could potentially hold this data.
Wrapping Up
Investigating FileZilla activity can be a complex task, but with the right knowledge, you can unearth a wealth of information from seemingly nowhere. By examining XML files, conducting memory forensics, and scrutinizing system artifacts, you can piece together a user’s actions and uncover the truth. Happy hunting, cybersecurity enthusiasts!
