I'm dealing with a malware which has multiple threads monitoring each other, I'm unable to kill all of them at once so I can't get rid of it, how do I go about this? I was thinking about using a kernel-debugger but maybe there's a better alternative.
If you can either identify how the malware is started on boot or where it is stored one possible option would be to shutdown the machine, boot from another medium (such as a Linux or Windows PE live USB) and make changes from there to stop it launching on next boot. This will involve either removing files containing the malwares executable code or modifying system configuration to stop it from launching again on boot.
If you are strugling to identify the executables follow the steps suggested by baldPrussian -
Get the names of the threads, which can tell you the executable that runs. Find where the exes are and the reg keys (possibly the run key) that call them
I would suggest checking the system multiple times over the next few days to ensure nothing was left on the system to allow reinfection. You also want to do everything possible to determine the infection vector - again so you can take steps against becoming reinfected.
If worst comes to worst swallow your losses and nuke it from orbit.
You didn't specify what operating system this is. On Linux, all threads that are tied together are given the same PID. Confusingly, what is visible as the PID is often actually the TID, or Thread ID, and the (real) PID is called the TGID, which is the ID of the entire POSIX.1 process. I'll be referring only to the TID and TGID to avoid confusion when an application can't make up its mind as to whether it should label the TID or TGID as the PID.
Any threaded process will have the same TGID for all threads, even if the TID is different. When you send a signal to the TGID, the kernel sends the signal round-robin to each TID in that thread group. Most signals, like SIGTERM, can be trapped and ignored. There are two which cannot be trapped, SIGKILL and SIGSTOP. The former, with very few exceptions*, will ensure that the process is unable to execute any more code in userspace from the moment it receives the signal. It will forcefully exit. The latter is similar, ensuring no more code will be executed, but rather than closing the process, it simply pauses it (until a SIGCONT signal is received). This can be handy for analyzing the malware while it is frozen and helpless to do anything to stop you.
Note that this will only work if they actually are threads, and not just a bunch of different, separate processes, there is no mechanism in place for the malware to restart itself, e.g. through another compromised process or a cron job, and your environment has not been compromised, meaning kill is actually kill.
kill -KILL $malwarepid
kill -STOP $malwarepid
* The only exceptions are when the parent process is not ready to receive its exit information, leaving the process as a zombie, or when the process is in the middle of a non-interruptible syscall, requiring the syscall actually complete before the process exits. None of these exceptions allow the process to execute any more of its own code before it exits.