Hello 0x00’ers!
I’m new here so if I haven’t categorized my question properly I apologize. Thanks 0x00Sec for providing a forum to discuss and learning together.
I have a problem about malware that has bothered me for a long time.
Background:
I work as a security, and sometimes dealing with malicious is part of my job. Once a host was infected malware by unauthorized hadoop yarn api. This malware was run by a ordinary user hadoop, and this hadoop user did not have much privilege to modify settings or files on the system.
Strange Things:
Under normal circumstances, I will use cp /proc/pid/exe /tmp/malware to restore the executable program of the malicious process. Even if the file has been deleted or the memfd_create call that fileless malicious program is used, it can be successfully restored the executable program by the cp command, unless it is a system kernel thread. But when I used the cp command to recover a malware process, the command return
cp: cannot stat ‘/proc/pid/exe’: No such file or directory.
This is very strange, it is worth mentioning that I am a root user and use busybox cp
What magic does this malware may use:
I very curious about the magic used by this malicious program. It can hide its executable program well, even if it is a ordinary user hadoop. I currently know that there are the following methods to achieve similar hiding:
fuse: Ordinary users can mount fuse file system and run their own executable program, and then umount fuse, as far as I know, the executable program of the process cannot be restored by using the cp command at this time
nfs: similar to method 1
But these two methods of hiding one’s own executable program that I know above are not the method used by the hadoop malicious program I encountered that time. so here to consult, does any 0x00’ers know what strange magic the malicious program may use?
That’s interesting… What kernel is running the machine? Did you checked if the PID exist?. Have you verified your hypothesis with fuse/nfs?
An old technique to avoid being caught is to just fork again and again every few seconds, so your PID gets changing and it is just hard to target the process.
Hi pico!
OS is centos7, kernel 3.10 and the specific release version is not recorded.
What is certain is that the process exists, and it is not a zombie process and the pid is not constantly changing.(So it is inferred that the malware did not fork call)
I did experiment with fuse and nfs. Although the goal of hiding executable programs was achieved after umount fs(fuse&nfs）, I was able to confirm that this malicious program did not use these two methods based on my experimental phenomena.
The only way I can think about to dump a running process in this circumstances is to attach to it with gdb and dump the text segment to do some static analysis. For that you need to:
Get the addresses for the text segment from /proc/PID/maps. It should be the first one with executable permissions
Connect to the process using gdb --pid
Dump the memory with something like dump binary memory my_dump.bin start_addr end_address (where start and end address come from the first step… remember to add 0x in the command to let gdb know the values are hexadecimal)
You can try to dump the rest of segments and rebuild the original ELF, but I’m not sure if all the information would be available in memory (for instance symbol tables)
This should dump the text segment into the file. The ELF header should be there (it is usually at the beginning of the text program header) so you should be able to find the offset for the entry point and try to reverse the initial code to figure out if the program does something fancy
There is a chance that the trick is done in the command-line when launching the program… In that case you may be lucky and may find something in the user history file, but I won’t bet on that. This stack overflow user reported something like this playing with symbolic links but I have not been able to reproduce it.
thanks pcio!
This is a good method. Next time I encounter a similar malicious program, I will try it.
If there is no gdb on the system, can also use cp /proc/PID/map_files/xxxx to dump it.
I miss this kind of magical malicious program.
