Sorry, I just don't what other title to use...I wasn't able to come up with something witty or pithy, because all I kept thinking was "ugh".
The "ugh" comes from a question (two, actually, that are quite similar) that appear over and over again in the lists and online forums (forii??)...
I have an image of a system that may have been compromised...how do I prove that data was exfiltrated/copied from the system?
Admit it...we've all seen it. Some may have actually asked this question.
Okay, this is the part where, instead of directly answering the question, I tend to approach the answer from the perspective of getting the person who asked the question to reason through the process to the answer themselves. A lot of people really hate this, I know...many simply want to know which button to click in their forensic application that will give them a list of all of the files that had been copied from the system (prior to the image being acquired).
So, my question to you is...with just an image of supposedly victim system, how would you expect to demonstrate that data was copied or exfiltrated from that system?
Well, there are a couple of things I've done in the past. One is to look for indications of collected data, usually in a file. I've seen this in batch files, VBS scripts, and SQL injection commands...commands are run and the output is collected to a file. From there, you may see additional commands in the web server logs that indicate that the file was accessed...be sure to check the web server response code and the bytes sent by the server, if they're recorded.
In other instances, I've found that the user had attached files to web-based email. Some artifacts left after accessing a GMail account indicated that a file was attached to an email and sent to another address. In several instances, this was a resume...an employee was actively looking for a job and interviewing for that position while on company time. Based on file names and sizes (which may or may not be available), used in conjunction with file last accessed times, we've been able to provide indications that files were sent off of the system.
What else? Well, there's P2P applications...you may get lucky, and the user will have installed one that clearly delineates which files are to be shared. Again, this may only be an indication...you may have to access the P2P network itself and see if the file (name, size, hash) is out there.
What about copying? Most analysts are aware of USB devices by now; however, there is still apparently considerable confusion over what indications of the use of such devices reside within an image. One typical scenario is that a user plugs such a device in and copies files to the device...how would you go about proving this? Remember, you only have the image acquired from the system. The short answer is simply that you can't. Yes, you can show when a device was plugged in (with caveats) and you may have file last access times to provide additional indications, but how do you definitively associate the two, and differentiate the file accesses from, say, a search, an AV scan, or other system activity?
I hope that this makes sense. My point is that contrary to what appears to be popular belief, Windows systems do not maintain a list of files copied off of the system, particularly not in the Registry. If your concern is data exfiltration (insider activity, employee takes data, intruder gets on the system and exfils data...), consider the possible scenarios and demonstrate why they would or wouldn't be plausible (i.e., exfil via P2P would not be plausible if no P2P apps are installed). Reason through the analysis process and provide clear explanations and documentation as to what you did, what you found, and justify your findings.
I've been involved in a number of successful litigations where documenting the use of USB storage devices, along with a couple or a few shortcuts pointing to files opened from those devices is all the attorneys need to get a court order compelling the production of those devices for examination. In my experience, a forensic exam of the computer reveals enough clues to allow the attorneys to get their foot in the door, so to speak...
ReplyDeletePhil,
ReplyDeleteThanks, but how does that apply to the post? What does LNK files indicating that files from an attached USB drive have to do with what I was referring to? Can you elaborate, or tie your comment to the post?
Thanks.
When I am asked this question I try to be mindful of the language I use between probable, possible and certainty to get the person asking it to think about what they are requesting. When you first get a disk image it is a frozen in time relay race and you have to determine which leg you are looking at and where the other hand-offs occurred. You do your best to build a time-lime from multiple artifacts and sources to pin point where transferred occurred but it is always with a degree of certainty - most OS's and environments do not have this level of auditing. The expectations (from clients as well as examiners) that there is a "find" script/button/tool that can just pin point the hand offs has to be changed to, as Harlan said, a process of reasoning. IMO the brain is the best forensic tool - I don't know why so many are shy to use it.
ReplyDeleteHarlan
ReplyDeleteI think what Phil meant was this: let's say there is a file on the imaged system which is sensitive and should do not be taken out of the system. If you find a LNK file with same name as the sensitive file indicating it was opened from a USB device, it means the file could have been copied to USB device
Kalyan
Kaylan,
ReplyDeleteThanks, but I try to avoid making assumptions like that, which is why I asked Phil to elaborate. There was no indication in his post of the file originally existing on the system, only that LNK files indicated that files had been opened from a USB device.
Thanks.
Harlan,
ReplyDeleteI believe the disconnect is that you're focusing on the trees (i.e., the HDD image) and I'm looking at the forest (i.e., the civil litigation where the HDD image is but one piece of circumstantial evidence needed to get us to the 51% preponderance level).
You asked when "a user plugs such a device in and copies files to the device...how would you go about proving this?" the answer involves examining more than one tree (e.g., single HDD image).
As a consulting expert advising the case attorney, you don't give up at this point, because you cannot definitively prove that files were copied by examining the HDD image.
You document what you found from the USBSTOR key entries, any LNK files pointing to file objects opened from external storage devices, and any other relevant file activity. You then help the attorney draft a motion asking the Court to compel the production of the external storage devices in question.
Remember if you find a LNK file pointing to a file with a revealing file name being opened from an external storage device, you use this to introduce doubt, not to definitively prove that the files were copied. That's what allows your attorney to get his foot in the door and ask the Court to compel the production of the storage device.
Once you get to examine the external storage device(s), you then should be in a position to definitively prove that files were indeed copied--you'd have all the files that were copied along with their file creation dates, which usually point to the times when the files were copied.
I gather that from your perspective, the examination of the single HDD image is the end of the road. From my perspective, I see this as a fork on the road giving me additional options to follow.
In any case, litigations are usually not won on a single piece of definitive evidence. For example, proving that files were copied is one of the many pieces of evidence that will be introduced to win the case. The copied files must be relevant, they must contain the Intellectual Property of the client, the use of the copied data could harm the property owner, etc.
Phil,
ReplyDeleteSorry, my friend, but honestly, I still have no idea how your comments link back to or relate to my post.
I believe the disconnect is that you're focusing on the trees (i.e., the HDD image)...
Well, that's not what the post was about, sorry.
Thanks for reading, just the same...
Harlans point is that you need to think! Use that thing between your ears instead of lookimg for the EASY button. As Harlan clearly points out, when considering ONE of the the exfiltration paths of data, Windows does not track copy and paste activity. So, what do ya do based upon this. Well, you need to think, and then reason through all possible scenarios proving or disproving something using a timeline of events with Windows artifacts. Just present what you have found as the facts as they have been presented to you and your analysis. Again, exercising ya noggin. There is no EASY button. There is only room for excellence when doing this type of work.
ReplyDeleteAnon...
ReplyDeleteThanks, that's much more on track. One of the things I've been gnashing my teeth about is that analysts continue to look for artifacts in acquired images of file copy operations...they continue to ask, cross-post, etc., rather than reason through the issue and do their own testing.
Also, I honestly think that there's just too much speculation...thumb drive plugged in, and a file has a last accessed time "near" that time, but that doesn't prove that the file was copied to the thumb drive. Nor does an LNK file with a path to an external drive indicate anything other than a file was opened from the drive.
Harlan, I believe you're on track with looking for collections of files. I've found ZIP'd files containing artifacts the user then sent offsite using FTP. Looking through the FTP application log indicated the date/time the file was sent. Although the ZIP file no longer existed the FTP log showed it did and that it was transferred to a particular FTP site and account. A prefetch entry also correlated to the FTP program being run on that day/time.
ReplyDelete...you're on track with looking for collections of files.
ReplyDeleteThat's only true in some cases. Ilomo, for example, reportedly never writes anything to disk...collected data is sent out to the network directly from memory.
Although the ZIP file no longer existed the FTP log showed it did...
This is an excellent example of an indirect artifact! Listings of 'at' jobs in the schedlgu.txt file, but no corresponding .job files, is another. Prefetch files are others...