11

I understand the definition of fileless malware:

Malicious code that is not file based but exists in memory only… More particularly, fileless malicious code … appends itself to an active process in memory…

Can somebody please explain how this appending itself to an active process in memory works ?

Also, what (kernel) protection/hardening is available against such attacks ?

Martin Vegter
  • 358
  • 75
  • 236
  • 411
  • For example, by exploiting a buffer overflow in a network application, and then to download malicious code that runs inside the application, and spreads via the network. No files involved. The second part of the question is very broad, it essentially amounts to "what countermeasures against malware exist"? – dirkt Jun 22 '17 at 09:17
  • This question might be better answered over at https://security.stackexchange.com/. – rubynorails Jun 24 '17 at 04:20
  • @rubynorails - I am only interested in linux specific answers. SecuritySE is general. If I request linux specific answer there, they will send me over here. – Martin Vegter Jun 24 '17 at 09:12

2 Answers2

7

Fileless malware attacks the target by exploiting a vulnerability e.g. in a browser's Flash plugin, or in a network protocol.

A Linux process can be modified by using the system call ptrace(). This system call is usually used by debuggers to inspect and manage the internal state of the target process, and is useful in software development.

For instance, let's consider a process with PID 1234. This process' whole address space can be viewed in the pseudo filesystem /proc at the location /proc/1234/mem. You can open this pseudofile, then attach to this process via ptrace(); after doing so, you can use pread() and pwrite() to write to the process space.

char file[64];
pid = 1234;

sprintf(file, "/proc/%ld/mem", (long)pid);
int fd = open(file, O_RDWR);
ptrace(PTRACE_ATTACH, pid, 0, 0);

waitpid(pid, NULL, 0);
off_t addr = ...; // target process address

pread(fd, &value, sizeof(value), addr);
// or
pwrite(fd, &value, sizeof(value), addr);

ptrace(PTRACE_DETACH, pid, 0, 0);
close(fd);

(Code taken from here. Another paper about a ptrace exploit is available here.)

Concerning kernel-oriented defense against these attacks, the only way is to install kernel vendor patches and/or disabling the particular attack vector. For instance, in the case of ptrace you can load a ptrace-blocking module to the kernel which will disable that particular system call; clearly this also makes you unable to use ptrace for debugging.

Cristian Ciupitu
  • 2,510
dr_
  • 29,602
  • Just like that other answer, this too is outdated -- as explained here you no longer need to ptrace a process in order to read or write to its /proc/PID/mem. I hope you're less refractory than the other individual to updating and correcting your answer, instead of perpetuating myths and misinformation. –  Oct 24 '19 at 10:09
  • ... which is this case may have consequences, as people may wrongly assume that by ptracing a process they can prevent other processes from reading its memory. –  Oct 24 '19 at 10:11
  • @pizdelect Thanks for the link. It would be good if you add the content as another answer. – dr_ Oct 24 '19 at 10:40
  • No, I'm not going to add another answer. I'm expecting you to fix yours. –  Oct 24 '19 at 17:08
  • Remember that you can edit other people's answers, too. You seem to have a better knowledge than me about this particular topic, so you are welcome to do so. – dr_ Oct 25 '19 at 08:41
1

When you manage to crash a process, you can cause the process to insert data into memory. A very popular way to do this is to use buffer overflows.

How does this work ? You know, for example, that a process is listening on port x and has a buffer for a certain function that is, say, 15 Bytes big. You call that function with 15 Bytes of data + n Bytes (your code to be executed). If the program does not validate data properly, it will overwrite adjacent memory with your code and thus, the code lives in memory. If you can get this code to executed, you own the system. There are limitations, for example, a process cannot write to memory outside of its allocated space.

There are a long lists of vulnerabilities on all OS' where buffer overruns allow crackers to inject data into the memory of the target.

thecarpy
  • 3,935