Could be nearly anything. The one time I was root-kitted (about 1999, on Linux, the attack actually failed), the attacker inserted a directory called "/usr/bin/..." (yes, three dots), which was a real directory, and contained their attack executables. I noticed the attack pretty quickly (because their root kit was so stupidly written, it tried to send mail, but with wrong parameters to the mail program, duh), and then it took me 10 minutes to find out where they were hiding their files. Note that no files were changed, only a directory entry created.
If you are wondering about files being changed: I vaguely remember that one of the daily or weekly security jobs takes checksums of all files in somewhere (like /bin or /usr/bin or similar), and reports when they change. Or is that only for setuid files? You might start by reading the periodic infrastructure.
Forget it. The fact that it is not Linux becomes immediately obvious when you look at the places things are stored. For example /usr/local being full of stuff. Or look for the difference between /etc/syconfig/... and /etc/sysctl.conf. While you can easily change the kernel to return a different answer from the uname() system call, that will A: break a lot of software, and B: immediately be noticed as fake by anyone who knows what they're doing. And then there are things that you just can't fix. Like:
Code:
# file /bin/ls
/bin/ls: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=c132aa35afa3aeb96336b2241f38e2edcbc3b945, stripped
/bin/ls: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 11.3, FreeBSD-style, stripped
So you can change the file command, the the executable loader in the kernel, and the elf linker, and nm and ... really? It just won't work.
What makes you think that your attackers are actually issuing commands from a shell? Today, real attackers are more likely to use things like the mail server or the web infrastructure on your machine than logins. That's why securing the machine against remote logins (things like ssh passwords) and bugs in the shell have become of little use: those things are typically so well secured, the real attacks are elsewhere.
Anyway: As you certainly know, anytime a user executes a "command" from a shell, that either runs a process, or it doesn't; the "it doesn't" case is using shell built-ins. Most damage can be done by running processes, for example "rm -f /boot/kernel/kernel", which runs the /bin/rm executable. That kind of attack you could audit by turning on process accounting (there is a handbook chapter for that). But beware: once you have process accounting on, the audit log of accounting (all process creations!) will be extraordinarily long. You will find thousands of times that someone runs for example the /bin/rm executable. Which of those are an attacker? Good luck. And then you find that someone runs "/usr/local/bin/perl foo.pl" ... and you have no idea what that did; and from inside, interpreters like perl or python or ruby can do nearly anything, without running a process. And shell builtins also don't create processes, and saying "echo foo > /boot/kernel/kernel" is just as damaging as deleting the kernel.
Have you looked at security auditing? There is a handbook chapter about that.
Sorry, but you have it exactly backwards. Please read the handbook. You are currently making a fool of yourself in public. That makes it quite unlikely that you will receive meaningful help.
Most of the details you are asking are in the handbook. What is not in the handbook is basics (like what is a process and what isn't), and common sense (like finding the needly in the haystack).