BYOB is intended to be a beginner friendly tool for those interested in learning about offensive security. Below are details on the architecture and design choices of this project.

This web application uses a version of the original console-based application BYOB which has been modified for use with a web-based front-end.

BYOB uses "staged" payloads, which work something like this:

---

Dropper

The main "dropper" file is first thing to be executed. It is a tiny file which only purposes is to fetch and execute the next stage of code). It is the only file which actually exists on the disk of the target machine.

The dropper is heavily obfuscated and compressed, and is usually compiled into a binary executable. It contains a hardcoded address where an encrypted file containing the next stage of the of payload is located. It downloads this encrypted file, decrypts it in memory, and executes the decrypted code.

---

Stager

The "stager" file is the second stage of code. It only exists in memory on the target machine. The stager's purpose is to run some environment checks, which can do things like test if a debugger is attached to the currently running process and abort execution if so, or test if it is running in a virtual machine or sandbox environment and abort execution if true.

This is all to prevent analysis of the code running in memory. Finally if all checks pass, it download another encrypted file containing the main payload code. It decrypts it in memory and runs it.

Note that these anti-anlysis features are disabled by default in order not to confuse new users trying to run a BYOB payload on a virtual machine.

---

Payload

The main payload is the "meat and potatoes" and contains all of the main functionality to control the target machine, remotely import Python packages and post-exploitation modules from the server, and operate as a reverse TCP shell.

Throughout all of this, the only data that exists on the disk is the original tiny dropper file, which contains obfuscated code and also usually is compiled into a binary executable file, which makes reverse-engineering that much more tedious.

In a real life scenario, this is not fool-proof obviously, as a determined analyst could reverse-engineer this and find the C2 server. The idea is to make it as tedious, time consuming, and difficult as possible so that they may conclude it is not worth the time/resources to follow the trail (which in all likely hood will just lead down a rabbit hole of proxies and/or TOR nodes to a bulletproof hosted server).

---

Security

Staged payloads can add security through anti-analysis techniques, and minimizing the on-disk memory footprint of the payload. However, encrypting communication between client and server is also essential to ensuring security.

Encrypted Connection

This main payload's first step is to establish a secure, AES-256-CBC encrypted TCP connection with the C2 server. It does this via the Diffie-Hellman Internet Key Exchange Protocol, which is a way of generating a shared secret between two people in such a way that the secret can't be seen by observing the communication. That's an important distinction: you're not sharing information during the key exchange, you're creating a key together.

This is particularly useful because you can use this technique to create an encryption key with someone, and then start encrypting your traffic with that key. And even if the traffic is recorded and later analyzed, there's absolutely no way to figure out what the key was, even though the exchanges that created it may have been visible.

Encrypted Payloads

At this time the stagers and payloads can be encrypted via a simple XOR cipher with a 128 bit key. However, there are plans to make this more robust in the future.

The goal of encrypting stager and payloads is that they are hosted online and externally exposed to the world, so encrypted the payload forces an analyst forces them to study the behavior of the payload to reverse-engineer its implementation details. This is much more difficult for them than if they could simply read the code.

---

Portability

Real attackers generally don't use a scripting language like Python for the payload, which is much easier to reverse-engineer, requires Python be installed on the target machine to run, and many third party packages are required to do anything useful. However, BYOB gets around these problems in 2 ways:

Executables

By selecting the "executable" format when generating a payload, the Python payload is compiled into a binary executable with an embedded Python interpreter, so it will run on a machine that does not have Python installed. BYOB accomplishes this by running Docker containers and Wine servers for different platforms and architectures, and running PyInstaller within the appropriate environment based on the platform and architecture selected by the user.

Remote Imports

The C2 server also runs a simple HTTP server to host the third party Python packages that some of the post-exploitation modules use. If a post-exploitation module attempts to import a third party package that isn't available, it will then remotely import the package from the server over HTTP. This allows the payloads to import third party packages directly the same way as if they were installed on the machine locally.

The 2 features above combine to make the payload quite portable.

---