#1 Search for deleted scripts/apps


I saw cracked server running DoS agent which dont use any of advanced hiding method... but, agent itself (running in memory) has been deleted from disk, so I must export binary from /proc to debug it.
Can you please add feature/test which will check that running applications/scripts still exist on disk?

Thank you


  • Patrick G.

    Patrick G. - 2012-10-03


    This test can easily be coded but I'm not totally sure it should be a part of unhide: the process is not hidden :).
    Could you provide more information ?
    What was the 'ps' output for this malware ?
    How did you determine that there is no executable on disk ? Did the /proc/PID/exe point on an inexistant file ?
    Or did it point on nothing, which can indicate the presence of a LKM malware ?
    What was reported by /proc/PID/cmdline and /proc/PID/comm ?

    I'm somewhat surprised: what kind of malware don't want to survive a reboot ?

  • Patrick G.

    Patrick G. - 2012-10-03
    • labels: --> unhide-linux
    • assigned_to: nobody --> patrick-g
  • Martin Čmelík (cm3l1k1)

    Hi Patrick,

    yes, as you said /proc/PID/exe point to non-existent. As far as I know it has been child process of init, so maybe that process has been hidden somewhere on filesystem as well. I have no evidence about it anymore, but I believe that /proc/PID/exe pointing to nonexistent file is strange and should be monitored.
    What do you think?

    Thank you

  • Patrick G.

    Patrick G. - 2012-10-15


    /proc/PID/exe pointing on a nonexistant files is not completely strange, There are several legitimate reasons for this to happen. I can think at least to these ones:
    - file removed or modified (by a system update for example),
    - the use of prelink command,
    - chrooted environment.
    Particularly, in case of system update, deamons are rarely restarted.
    Are you sure you weren't in one of these case ?
    However, although the file doesn't appears in a 'ls', you can access it via the /proc/PID/exe link because a lock is maintained on the file while it is running, e.g.:

    $ cp /bin/vim /tmp
    $ /tmp/vim foo
    $ ps ax | grep foo
    8904 pts/3 S+ 0:00 ./vim foo
    8960 pts/4 S+ 0:00 grep --color=auto foo
    $ rm /tmp/vim
    $ readlink /proc/8904/exe
    /tmp/vim (deleted)
    $ cat /proc/8904/exe > /tmp/vim.out
    $ ll /tmp/vim.out
    -rw-rw-r--. 1 breeves breeves 2097656 Jul 17 09:41 /tmp/vim.out
    $ file /tmp/vim.out
    /tmp/vim.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
    dynamically linked (uses shared libs), for GNU/Linux 2.6.32,
    BuildID[sha1]=0x695009d204a46dd413af6afc12207ee5f21fabf5, stripped
    $ md5sum /tmp/vim.out
    21f4752d9efdb68e6af1ff22b2652fde /tmp/vim.out
    $ md5sum /bin/vim
    21f4752d9efdb68e6af1ff22b2652fde /bin/vim

    Being a child of init process could also happen if the real parent kills itself after launching the deamon. the orphan process is automatically attach to init.

    You didn't give lot of information about the process. What name (comm and cmdline) 'ps' reports for it ? Did you determine which malware it is ? Do you report it to some security list, or to rkhunter team ?

    I'll probably add the test but with many warnings as I fear it will generate lot of false positives. maybe as a separate executable.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks