This is a thesis to obtain the Degree of Licenciatura (~ MsC) in Computer Science at the Faculty of Mathematics, Astronomy, Physics and Computer Science (FaMAF) of the National University of Cordoba (UNC).
Damage caused by malware has been ramping up in the last five years. One kind of malware is fileless malware, which increased 900 percent in 2020, and it is expected to be half of the attacks against enterprise environments in 2022. To detect fileless malware, we matched code segments from the executables loaded into Random Access Memory to the original executable file stored on hard disk, using Endpoint Detection and Response tools to implement it. Furthermore, we tested the technique against real malware families, resulting in a detection rate of 77.78 percent, with a sensitivity rate of 92.11 percent. In summary, we present a technique to detect fileless malware, and the results of the testing phase sound promising.
Los daños causados por el malware se han disparado en los últimos cinco años. Un tipo de malware es el fileless malware, que aumentó un 900 por ciento en 2020, y se espera que sea la mitad de los ataques contra entornos empresariales en 2022. Para detectar el fileless malware, comparamos los segmentos de código de los ejecutables cargados en la Random Access Memory con el archivo ejecutable original almacenado en el disco duro, utilizando para ello herramientas de Endpoint Detection and Response. Además, probamos la técnica con familias de malware reales, obteniendo una tasa de detección del 77,78 por ciento, con una tasa de sensibilidad del 92,11 por ciento. En resumen, presentamos una técnica para detectar fileless malware, y los resultados de la fase de pruebas parecen prometedores.
This work is licensed under a 
- Import the velociraptor artifact(s)
- Run Mem2Disk
- query compares executables on disk to the text-segment in RAM. By that, RAM-injections can be detected (like commonly used by malware and C2 frameworks).
- Parameter: IgnoreOneByteOffsets - runs a powershell script (temporary file) to ignore changes in RAM of 1 byte. This is cause by the Base of Data offset (see below).
- Parameter: UploadFindings - uploads the findings to the velociraptor server. Warning: can take lots of disk space on velociraptor server if run on the entire network. Only use on selected machines.
- Run ExtraX (rather experimental)
- detects if an executable on disk has extra executable sections in RAM. This might be appended attacks (something we realized during experiments with malware). However, often this will be legitimate as some programs do this themselves (e.g. browsers).
The following table gives an overview which C2 frameworks can be detected:
| C2 | Detection | Date | Used commands |
|---|---|---|---|
| Sliver | detected | 2025-01-20 | execute-assembly --ppid <ppid> --process calc.exe ./beacon.exe |
| Mythic | detected | 2025-03-28 | shinject -PID <pid> -File shellcode.bin |
| Havoc | detected | 2025-03-28 | shellcode inject x64 <pid> /path/to/shellcode |
Shellcode:
from pwn import *
context.update(arch="amd64")
pay=(asm(shellcraft.amd64.windows.winexec("C:\\Program Files\\example\\example.exe")))
with open("shellcode.bin", "wb") as bf:
bf.write(pay)
BaseOfData is a Relative Virtual Address (RVA) that introduces offsets during runtime. See https://0xrick.github.io/win-internals/pe4/ for a detailed explanation.
In our experiments, Base of Data introduced changes in the RAM section including the code of the program (text-segment) of only 1 byte. It causes false positives in our detection and, thus, we created an option to ignore all 1 byte changes. This was not possible in Velociraptor Query Language (VQL) directly and required an external script. Velociraptor supports powershell and so we chose that. It affects performance, so the option can be turned off, too.