{"id":1841,"date":"2020-11-12T13:11:00","date_gmt":"2020-11-12T13:11:00","guid":{"rendered":"http:\/\/www.halkynconsulting.co.uk\/a\/?p=1841"},"modified":"2020-11-12T13:11:00","modified_gmt":"2020-11-12T13:11:00","slug":"linux-dfir-workflow-for-a-busy-responder","status":"publish","type":"post","link":"http:\/\/www.halkynconsulting.co.uk\/a\/2020\/11\/linux-dfir-workflow-for-a-busy-responder\/","title":{"rendered":"Linux DFIR: Workflow for a busy responder"},"content":{"rendered":"

Linux DFIR may feel like it is a complicated and arcane process, but it doesn’t need to be. Yes, there are challenges around memory collection and lots of modern EDR tools perform badly, but this should never be an issue for a good incident responder. The biggest issue tends to be that IR in this environment is rare, so you are less likely to have a “go-to” mental list of commands and steps to follow.
\n

\"Linux
Linux DFIR Guide<\/figcaption><\/figure> This guide will help you solve that. <\/p>\n

However, there are some important points to bear in mind. Most importantly, Linux is a very configurable platform so you may find that the system you are responding to is very, very different from other machines even if they run the same base OS. <\/p>\n

This means that while you should go in with a plan, you also need to be open-minded enough to adapt things on the fly – especially if you discover your tools are producing unexpected output. If at all possible, test this on your Linux machines while there isn’t an incident, during the preparation phase<\/a>, and this will allow you to fine-tune things to maximise the chance of success.<\/p>\n

With that out of the way, let’s look at some key parts of the process.<\/p>\n

Linux DFIR Workflow<\/h2>\n

As with everything in IR, it is really important to have an idea of the workflow you want to follow. The more you can document this, the better quality your evidence is. Even if you never intend to set foot in a court, a good evidence process means you can be more confident about findings and you can trust that you haven’t overlooked anything important.<\/p>\n

NOTE:<\/em> This guide is based on a responder who has direct access to the live system and will be working locally. This is not a guide for dead box\/image-based forensics. The activity here will<\/strong> change the state of the target system and will<\/strong> generate log entries\/history records. This reinforces the need to keep detailed notes so that the investigator’s activity can be eliminated from the evidence.<\/p>\n

Example Collection Workflow<\/h3>\n

Set up documentation<\/strong>. You can keep notes by hand but Linux also includes the script<\/code> command which logs output of each command as you type it and saves the data to file when you exit. You can invoke script -a<\/code> to save the file to a separate device if you want to retain off-disk evidence. You can find out more about this often-overlooked command on the script man page<\/a>.<\/p>\n

Ensure you have trusted tools<\/strong>. Remember if you are on a compromised system, the attackers can modify binaries and you have no way to trust the output. Even simple tools like ls can be compromised effectively. Ideally, you will bring your own tools, either from bootable media or via statically linked binaries. If you have to use commands on the operating system bear in mind the risk and try to find multiple ways to validate the output.<\/p>\n

Gather data<\/strong>. Your organisation may have specific requirements here but we would recommend something along the following lines:<\/p>\n