2

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.

Trey
  • 113
  • 1
  • 9
  • 1
    Try to write a script that kills all the processes (related to the malware) and start it at the highest possible priority. It will be highly OS dependant but could work. – Serge Ballesta Nov 02 '17 at 11:05
  • 3
    You can freeze processes - see https://stackoverflow.com/questions/11010165/how-to-suspend-resume-a-process-in-windows. So you could try freezing them and then killing them all. Alternatively do you know how the processes start at boot? Shut the machine down, boot off a live USB, modify the file-system to neutralize the malware and boot back up. – Hector Nov 02 '17 at 12:03
  • @Hector what do you mean by "modify the file-system" ? What would you modify? – Trey Nov 02 '17 at 14:08
  • 1
    Either delete out the files that the malware is stored in or make the necessary changes to stop it from starting - i.e. if its registered as a service modify the registry entries to stop it from starting. – Hector Nov 02 '17 at 14:57
  • 2
    Hector's comment, IMHO, is an answer more than a comment. But I don't want to take credit for it for my reputation here. So I'll expand. 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. then boot from a USB disk and delete the executables. After rebooting, clear the reg keys and ensure that no scheduled tasks call these threads. – baldPrussian Nov 02 '17 at 15:07
  • @Hector that worked well, you might want to write that as an answer – Trey Nov 02 '17 at 16:11
  • Thanks Trey and @baldPrussian. I've added an answer and upvoted baldPrussian's comment. – Hector Nov 02 '17 at 16:51

2 Answers2

4

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.

Hector
  • 10,893
  • 3
  • 41
  • 44
  • If you identify how the malware is started does not help because the startup will be permanently refreshed by the running processes. – Overmind Nov 08 '17 at 09:26
  • Which is why you shutdown and boot from another medium. The malware is extremely unlikely to be able to run when the OS it infected isn't... Exceptions being if its managed to get into bios/firmware or has some way to launch itself inside the new OS – Hector Nov 08 '17 at 09:36
  • That is correct. – Overmind Nov 08 '17 at 10:18
1

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

or

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.

guest
  • 256
  • 1
  • 3