#DFIR: Duty to know and understand; Need to know

Hi, minions:

On December 9, 2018, Brett Shavers published an article on the DFIR Training site entitled "Something I see with forensic software preferences". If you haven't read it yet, I strongly recommend that you do so, (only if you like to be made to think a little). Since the first reading I did of it, (I've read it several times), I've been wanting to write something related to the content of that article. Today is that day.

As you may have seen, the title of this article is "Duty to know and understand; Need to know". What the hell does that mean?

Each one of us will always have some kind of preference, predisposition, when using a type of system, a type of tools. Likewise, each one of us will always be more reluctant to use another type of system, another type of tool. All this can be done even unconsciously. Personally, I try to be equidistant in this sense. It is indifferent to me to use a Windows System than a Linux System. I don't care whether I use a tool with a graphical interface or a system console. Because you should know that everything has its advantages and disadvantages.
There's no such thing as the perfect tool.
For that very reason, because there is no perfect tool, it is an inexcusable duty of the analyst to know what tools he has at his disposal, what alternatives he can use to achieve his goal: to carry out his work satisfactorily. In DFIR there are multiple ways to reach the same result.

The analyst must also understand how the tool he or she is using works. It can happen that you use a tool with all your default settings and you don't find what you are looking for because of that: because you use the default settings. Do you then need to switch to another tool? Or, is it possible that by changing some value of your configuration you find what you are looking for?

The tools have been developed to serve a specific purpose. From the 'smallest' utility, (in size), to the most advanced and expensive forensic suite in this industry, they have been written to fulfill a purpose and each one will present a series of advantages and disadvantages, which can be substituted for each other. If there is a tool that does not meet your expectations and you do not know other tools because you cling to the first one, how do you intend to carry out your work?

You should know that a tool that runs on one System on one target may not work in the same way if it runs on another System on the same target.


On the other hand, the analyst must know what he needs to look for. It seems obvious, doesn't it? You can't carry out an analysis if you don't know what you're going to look for, if you don't mark a purpose. I have always believed that no question is too much when it comes to obtaining information on a case, however absurd it may seem. Any detail can help the analyst in his work.

Just as important as everything I have told you so far, is that you must know that you have to seek a balance. The analyst must take into consideration the resources used, the effort expended, the time invested, the purpose of the case, ... And that, in my opinion, is not achieved by insisting on the use of a single tool

If we know the tools and understand how they work, we will be able to meet our objective in a much more effective way than it might seem in principle.

Let me explain this in a much more dynamic way.

A very simple example


On January 8 of this year 2019, at 13.09, my phone rang. On the other side was a relative who needed my help, my knowledge. This relative was doing a job with a file '.psd' hosted on a USB device and told me that I had 'lost' it and needed to recover it. only that file. To top it all, instead of not touching it, instead of moving away from that device and not even looking at it, he reconnected it to his computer to try to recover it, without knowing very well what he executed.

When I went to pick up the USB device I proceeded to ask him some questions:

* When did you 'lose' the file?
* How did you 'lose' the file?
* When did you create the file?
* When was it last used?
* What was the file called?
* What format was the file?
* What was inside the file?
* How big was the file?
* Where was the file hosted?
* What version of Photoshop was it working with?
* How many coffees was it going to invite me to? 😉

And a few more questions. As I told you before, no question is more than enough to do an effective job.

Before plugging the USB device into the workstation, I proceed to block, and verify, the writing of USB devices:

'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StorageDevicePolicies'
'WriteProtect=1'


I am not going to work directly on the device, despite having it connected in read-only mode in the System. I will create a forensic image. For this case I have chosen to use Magnet Acquire. I like how it works because it presents a very detailed log of the device and the acquisition process.


Now, with the image created, I return the USB device to its owner and it's time to comply with the request.


You may be thinking that the most viable option for this case would be to carve the forensic image. That's right. It is an option. Let's look at it with a couple of examples.

I'm going to show you the process with two tools that are very widely used, and very powerful: Foremost' and 'Photorec'.

Foremost


We can run the tool and tell it to only look for files with the extension '.psd'.


But it looks like we have a problem. We tried to run it without indication of file extension.


The tool has worked, but we have not obtained any file '.psd'. What happens? That the configuration file 'foremost.conf' does not contain the information related to the 'magic numbers' of the files '.psd'.


So, if we do not have examples of such files on our workstation, we can consult sites such as https://www.garykessler.net/library/file_sigs.html or https://www.filesignatures.net/, where we can look for that data relating to the header and footer of a file type.


Once we have found the data we are interested in we must introduce them into a file 'foremost.conf'.


Again, we proceed to run 'Foremost' with indication of the type of file we want to recover. But the tool doesn't work this way either.


If we use 'Foremost' with a custom configuration file we should look for all the file types found in it. This way, we run the tool again without specifying the file type. This time he has managed to extract 9 files '.psd'.


Agreed. Now what? What do we do? 

Can you say that we can deliver these results to the 'client', to which I will say: Without checking them?

Can you say that we can check the results, to which I will say: Are you going to open all the extracted files, one by one? In this case there have only been 9 files. If it were a few tens or hundreds?

As we know the content of the file, and we know that it has a part of text inside, we can look for that content in the recovered files, making use of 'egrep'.


And we can try to open it if we get a positive result, but depending on the type of file, it is very possible that we may encounter errors when opening the file. And this type of error is very common in files that do not have a 'footer', a 'magic number' at the end of the file, as is the case of files '.psd'.


At this point, value the time invested, the effort spent, and the results obtained: In this example, it has not been possible to recover the file of the request.

If you want to see a more detailed article on 'Foremost' you can read the article "My name is #Foremost: I’ve seen things you people wouldn’t believe".

Photorec


We can run 'Photorec' directly on the forensic image.


In this case, 'Photorec' does allow us to directly select the file type '.psd' without having to enter its configuration.


We leave the rest of the configuration by default and process the whole disk.


In this case, the application has managed to extract 3 files '.psd'. We can now look for which file from which it has managed to recover contains the information we are interested in. In principle, the file with the name 'f1110816.psd', with a size of 156.864 KB, is the one we are interested in.


Indeed, we open it and the result is positive. However, we proceed to run 'Photorec' again, but this time varying its configuration.


With this new run the application extracts 2 files. After searching for the content of interest within them, it tells us that the file we are interested in is the one named 'f1110784.psd', with a size of 74.800 KB.


Indeed, we open it and it is the file that we have to recover. You should know that depending on the configuration that we carry out in the application, we will be shown some results or others.



At this point, where we have two candidate files to be recovered, which of them do you choose? Because the two have different names, with different size and, therefore, different content, although the image of the file is the same. 

Again, value the time invested, the effort spent, and the results obtained: In this example, it has been possible to recover two files that, apparently, correspond to that of the request.

The easy way


Never, ever, should you underestimate the information you provide to meet an objective because the solution to the case, with the information at your disposal, may be in plain sight. Likewise, you should never, ever underestimate any tool, because the solution may be there.

In order to do an effective job in this case I have not chosen to use any carving tool. I have chosen to use 'The Sleuth Kit'.

The first thing I do is to see what partitions the USB device has, using the utility 'mmls'.


After that, I generate a timeline, only with the content of '.psd' files, using the utilities 'fls' and 'mactime', filtering the results with 'egrep'.


After studying the timeline, by means of the dates provided and the name of the file, I proceed to see the information of a file located in inode 83, under the name '_ote.psd', which is presented as deleted, by means of the utility 'istat'.


This is the file I'm looking for. So I extract it using the 'icat' utility.


And I proceed to its opening to check it out.

If you want to see more about 'The Sleuth Kit' you can read the article "About the timelines: The limit, your imagination".

Conclusions


As you may have noticed, with 'Foremost', in this case, it was not possible to extract the file of interest. The opposite has happened with 'Photorec', which has recovered two files, with different names and sizes. 

If we compare the files extracted using carving tools with the file extracted with 'The Sleuth Kit' you can see the difference.


This is just a small example. But,

The solution to one case does not have to be the same as for another case. The solution may be something more complex, such as manual file recovery using 'xxd', or something very simple, such as forensic image processing in an advanced forensic suite. 

Sometimes the solution will be somewhat convoluted and other times it will be found with the naked eye. Sometimes no data will be available and other times the data will provide a gateway to solving the problem.

What you have to take into account is that, for each case, you have to find a balance weighing time, resources, effort... And all this cannot be carried out if you do not know the tools, if you do not understand how they work and, of course, if you do not know what you are looking for.

Therefore, do not hold on to a tool as if it were the only one, as if it were the best. Think of the wide range you can have, of the use each of these tools can have.

That's all.
Share:
spacer

No hay comentarios:

Publicar un comentario