volana: Shell command obfuscation to avoid SIEM/detection system
volana – Shell command obfuscation to avoid SIEM/detection system
During pentest, an important aspect is to be stealthy. For this reason, you should clear your tracks after your passage. Nevertheless, many infrastructures log commands and send them to a SIEM in real-time making the afterward cleaning part alone useless.
volana provide a simple way to hide commands executed on compromised machine by providing its self shell runtime (enter your command, volana executes for you). Like this, you clear your tracks DURING your passage.
Use
You need to get an interactive shell. (Find a way to spawn it, you are a hacker, it’s your job! otherwise). Then download it on a target machine and launch it. that’s it, now you can type the command you want to be stealthy executed
Keyword for volana console:
- ring: enable ring mode ie each command is launched with plenty others to cover tracks (from a solution that monitor system call)
- exit: exit volana console
from non-interactive shell
Imagine you have a non-interactive shell (webshell or blind rce), you could use encrypt and decrypt subcommand. Previously, you need to build volana with an embedded encryption key.
On attacker machine
Copy encrypted command and execute it with your rce on a target machine
Why not just hide the command with echo [command] | base64? And decode on target with echo [encoded_command] | base64 -d | bash
Because we want to be protected against systems that trigger alerts for base64 use or that seek base64 text in command. Also, we want to make investigation difficult and base64 isn’t a real brake.
Detection
Keep in mind that volana is not a miracle that will make you totally invisible. Its aim is to make intrusion detection and investigation harder.
By detected we mean if we are able to trigger an alert if a certain command has been executed.
Hide from
Only the volana launch command line will be catch
- Detection systems that are based on history command output
- Detection systems that are based on history files
- .bash_history, “.zsh_history” etc ..
- Detection systems that are based on bash debug traps
- Detection systems that are based on sudo built-in logging system
- Detection systems tracing all processes syscall system-wide (eg opensnoop)
- Terminal (tty) recorder (
script,screen -L,sexonthebash,ovh-ttyrec, etc..)- Easy to detect & avoid: pkill -9 script
- Not a common case
- screen is a bit more difficult to avoid, however, it does not register input (secret input: stty -echo => avoid)
- Command detection Could be avoid with volana with encryption
Visible for
- Detection systems that have alerts for unknown commands (volana one)
- Detection systems that are based on keylogger
- Easy to avoid: copy/paste commands
- Not a common case
- Detection systems that are based on syslog files (e.g. /var/log/auth.log)
- Only for sudo or su commands
- syslog file could be modified and thus be poisoned as you wish (e.g for /var/log/auth.log:`logger -p auth.info “No hacker is poisoning your syslog solution, don’t worry”
- Detection systems that are based on syscall (eg auditd, LKML/eBPF)
- Difficult to analyze, could be made unreadable by making several diversion syscalls
- Custom LD_PRELOAD injection to make a log
- Not a common case at all
Source: https://github.com/ariary/
