*SNIPPED *
Thankyou Jaclaz once again for helping me out here.
I appreciate the input, especially about how you would envisage something like this working.
I have added your points to my notes!*SNIPPED *
Thankyou, i appreciate the input from a different perspective!
From what you have said i have stripped out a couple of "modules" i was going to include in the software.
I think originally i was getting my lines blurred with regards to what information i would want quickly extracted and what information would actually be useful to be quickly extracted as oppose to waiting till its in the lab.
For example,
I was planning on having an MFT parser in there which will then provide you a dump of the MFT formatted nicely. But on reflection, i do not see the point. The whole point of triage (as jaclaz mentioned in another post) is priorities. An MFT can wait until its in the lab to have a look through.So, i have scaled down my project slightly to focus on important matters and added new "modules" in which would, in my opinion, be used and useful.
Thankyou minime2k9, i may take you up on the PM offer soon!
1. I do not know a great deal about how Triage is done in the real world, so i was hoping that a few members who deal with Triage forensics could give me a bit of a run down as to the process that they go through when performing their investigation. IE, from the discovery of the suspects machine, maybe at their home, to the process that you go through…
"Triage" likely comes down to different things, depending upon the nature of the work being performed.
2. How often does it occur that you have to investigate machines quickly on site rather than take an image and return the image to the lab for further investigation?
I investigate targeted threat breaches, so my response is "all the time".
Do you turn off the computer and perform your activities or do you leave it switched on and perform your activities then?
The work I do is really fast. We have a proprietary agent that we provide clients, that they roll out across their enterprise, and we examined the data that comes back. As such, all of the systems are live.
3. If you were to do Triage on-site, how much do you worry about "changing" data? IE, plugging in a USB stick would be changing data, running an piece of software Could possibly change data.
Well, the key to all of this is understanding *what* changes are made, not simply that changes are made.
Looking at your example, plugging in a USB thumb drive does change data, but with appropriate care, you can set up your USB thumb drive so that it's much easier to determine what changes were made (i.e., use a specific type of thumb drive, give the volume a specific name). And the analyst's documentation will have the date and time of the triage efforts, so from that perspective, it should be trivial to discern the analyst's activities from any other. So, at this point, your worry would be new data being added to the Registry (System and Software hives, specifically) overwriting recently deleted keys and values.
The act of logging into the system will likely cause event records to be added to several Windows Event Logs.
For the analyst to interact with the contents of the thumb drive, a user account will have to be logged in; do you create a new one, or use one that's already on the system?
When the analyst runs the software, how do they do so? Do they double-click an icon? When the software runs, on workstation systems, by default an application prefetch file will be created.
My point is not to list all of the changes that occur on systems, but to demonstrate that changes do occur. Even if you do nothing and just leave the system running, changes will occur. The key to managing all of this is documentation.
I want to create software which would actually be useful rather than just making software for the sake of completing my FYP, so im hoping to gather a fair bit of information to help me achieve that.
I'd suggest a couple of things
First, to make truly useful software, you have to know something about the work that you want the software to do or to assist an analyst with. It doesn't make sense to create software to help an analyst do their job better if you don't know what that job is.
Second, the term you're using means different things to different people. LE has one set of goals. I am not LE, so my goals are different…in many cases, extremely divergent from LE.
