A big myth around investigating Linux malware is that the first tool you need is a debugger and deep knowledge of assembly to understand what it does. It’s easy for admins and security personnel responding to an incident to get discouraged by the thought. But, we’re going to let you in on a secret: For live process investigations it is unusual to need to pull out the debugger and in fact it has particular risks.
Most Linux malware and suspicious activity can be investigated using simple and fast command line methods that are easy to use, especially when under pressure, to find out what is going on quickly. Attaching a debugger to a live process often is the last thing you want to do for a variety of reasons:
- Often debugging tools aren’t installed. You’ll have to load the software and support libraries which can stomp on data on the file system you may need to recover later.
- Accessing the tools may be difficult depending on how the system is configured and secured.
- Poking around the processes with a debugger can cause the system to become unstable or freeze requiring a reboot which can destroy valuable clues.
- The malware may have mechanisms in place to detect debugging activity and activate a logic bomb to destroy itself or system data.
The fourth point is not academic. There has been an increase in malware with anti-debugging and anti-sandbox detection techniques in place. Running any kind of debugger before doing basic investigations on the host can be seriously counter-productive.
If you want a simple plan to investigate a suspicious Linux process, check out this article on command line tools that are less invasive and can provide immediate information on what Linux malware may be doing on a host:
Basic Linux Malware Process Forensics for Incident Responders