Integração e Gestão de Sistemas de Informação

Metasploit multi/handler: opções, jobs e sessões

Terminal com msfconsole -q e o comando run -j em destaque, ilustração do guia HJFR sobre o módulo multi/handler do Metasploit em laboratório

Escrito por

Artificial Inteligence

em

,

Num laboratório de testes de intrusão, quase todas as sessões do Metasploit chegam pelo mesmo sítio: o módulo exploit/multi/handler. É o mais usado da framework e um dos menos estudados a sério. Não ataca nada nem explora vulnerabilidade nenhuma: fica à espera de ligações e transforma-as em sessões.

Este guia fica-se pelo handler: o que é, o modelo de jobs e sessões, as opções avançadas e as diferenças entre handlers TCP, HTTPS e bind. Não gera nem entrega payloads e não trata de evasão. É matéria para laboratório próprio, CTF ou teste de intrusão com autorização escrita; endereços e máquinas (kali-lab, alvo-lab) são fictícios. No fim, o ângulo de quem defende.

Veja o guia em vídeo

Prefere ver antes de experimentar? No canal HJFR-IT no YouTube mostramos o módulo exploit/multi/handler do Metasploit opção a opção, com o resultado de cada comando no ecrã — narrado em português e com legendas.

Metasploit multi/handler — apanhar payloads e gerir sessões explicado — canal HJFR-IT no YouTube. Se o áudio não arrancar em português, abra as definições do vídeo (ícone da roda dentada) → Faixa de áudio → Português.

O que faz o multi/handler

O info diz tudo: é um stub, sem código de ataque, e por isso tem a classificação Manual, a mais baixa. Limita-se a emprestar o sistema de payloads do Metasploit a código lançado fora da framework. Serve Android, Java, Linux, Windows, PHP ou Python porque nunca toca no alvo: só espera. O único alvo é o genérico Wildcard Target.

msf6 > use exploit/multi/handler
[*] Using configured payload generic/shell_reverse_tcp
msf6 exploit(multi/handler) > set PAYLOAD <payload>
msf6 exploit(multi/handler) > set LHOST <endereço>
msf6 exploit(multi/handler) > set LPORT <porta>
msf6 exploit(multi/handler) > run -j

Configurar o handler é configurar o payload

No show options, a secção Module options está vazia: o LHOST e o LPORT pertencem ao payload.

Module options (exploit/multi/handler):

   Name  Current Setting  Required  Description
   ----  ---------------  --------  -----------

Payload options (generic/shell_reverse_tcp):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LHOST                   yes       The listen address (an interface may be specified)
   LPORT  4444             yes       The listen port

Troque para windows/x64/meterpreter/reverse_https e a folha muda: surgem EXITFUNC e LURI (o caminho HTTP) e o LPORT salta para 8443, o valor por omissão desse payload. Não decore opções do handler; decore opções de payloads.

Staged ou stageless

Com barra, meterpreter/reverse_tcp é staged: um pequeno stager liga-se e é o handler que lhe envia o segundo andar (o Sending stage da consola). Com sublinhado, meterpreter_reverse_tcp é stageless: já leva tudo. O PAYLOAD do handler tem de ser exatamente o do payload que se liga; se não for, a sessão abre e é descartada como inválida.

Atalhos: handler, -x e resource scripts

O comando handler faz o mesmo numa linha e arranca-o logo em segundo plano; a partir da shell, o msfconsole -x aceita os comandos entre aspas, separados por ponto e vírgula. Guarde o número do job: é a chave de tudo o que vem a seguir.

msf6 > handler -H 192.0.2.10 -P 4444 -p linux/x64/meterpreter/reverse_tcp
[*] Payload handler running as background job 0.
[*] Started reverse TCP handler on 192.0.2.10:4444

$ msfconsole -q -x "use exploit/multi/handler; set PAYLOAD linux/x64/meterpreter/reverse_tcp; set LHOST 192.0.2.10; run -j"

Para não reescrever tudo todas as manhãs, makerc handler.rc grava os comandos da consola num ficheiro, que resource handler.rc (ou msfconsole -q -r handler.rc) volta a executar. E jobs -p ID torna um handler persistente: a consola levanta-o sozinha a cada arranque.

Jobs: o handler em segundo plano

O modelo de jobs é o que separa um handler de um listener qualquer. Com run, o handler fica em primeiro plano e prende a consola; com run -j passa a job e devolve o prompt. jobs -l lista o que está à escuta, jobs -v acrescenta a hora de início e o endereço real, jobs -k ID termina um job e jobs -K termina todos.

Handler failed to bind

Quase nunca é falha do Metasploit: é um handler antigo, esquecido em segundo plano, na mesma porta. A mensagem sai duas vezes porque o handler tenta o endereço configurado e o 0.0.0.0. A cura: jobs -v para ver quem lá está e jobs -k para libertar a porta.

[-] Handler failed to bind to 192.0.2.10:4444:-  -
[-] Handler failed to bind to 0.0.0.0:4444:-  -

ExitOnSession e ListenerTimeout

No show advanced, só duas opções são realmente do handler. ExitOnSession está a true por omissão: à primeira sessão, o handler fecha-se. Para continuar à escuta, set ExitOnSession false (o comando handler só fecha se lhe passar -e). ListenerTimeout a 0 espera para sempre; outro valor é o número de segundos até desistir.

Gerir sessões

Com o ExitOnSession a false, um único handler alimenta várias sessões em simultâneo:

msf6 exploit(multi/handler) > sessions -l

  Id  Name  Type                   Information       Connection
  --  ----  ----                   -----------       ----------
  1         meterpreter x64/linux  aluno @ alvo-lab  192.0.2.10:4444 -> 192.0.2.50:41862 (192.0.2.50)
  2         meterpreter x64/linux  aluno @ alvo-lab  192.0.2.10:4444 -> 192.0.2.50:41878 (192.0.2.50)
  • sessions -i ID entra numa sessão; background ou Ctrl+Z devolve-o à consola sem a fechar.
  • sessions -c CMD -i 1,2 executa o mesmo comando em várias sessões de uma vez.
  • sessions -k ID fecha uma sessão; sessions -K fecha todas.

As opções avançadas do payload

O show advanced do payload é longo; o grep da consola lê-o por partes (grep Session show advanced).

Arranque e verificação da sessão

AutoRunScript corre um comando ou resource script quando a sessão nasce e InitialAutoRunScript corre antes dele. AutoVerifySession confirma que do outro lado está uma sessão viva, e não um scanner a bater à porta.

Os quatro temporizadores

  • SessionCommunicationTimeout (300): cinco minutos sem um pacote e a sessão morre.
  • SessionExpirationTimeout (604800): uma semana e termina, faça o que fizer.
  • SessionRetryTotal (3600) e SessionRetryWait (10): o payload tenta voltar durante uma hora, de dez em dez segundos. Por isso uma sessão perdida às vezes reaparece sozinha.

set, setg e save

set escreve no datastore do módulo e perde-se com back; setg escreve no global, válido para toda a consola, o sítio certo para o LHOST. get mostra o valor em vigor e save grava-o em ~/.msf4/config para a próxima consola.

Reverse, bind e o tipo de sessão

Com um payload bind_tcp, o LHOST desaparece e surge um RHOST. Num reverse é o alvo que liga ao handler, que abre um socket à escuta; num bind é o handler que se liga ao alvo, e o LPORT passa a ser a porta onde o payload espera. Aqui, o handler é cliente, não servidor.

Com um payload de shell simples, a sessão é do tipo shell e a coluna Information fica vazia: sem sysinfo, sem getuid, sem canais. Percebe-se assim quanto do «Metasploit» é, na verdade, o Meterpreter.

Certificado, UUID e NAT

Num handler HTTPS, por omissão o certificado é gerado no momento, nunca verificado, e aceita-se qualquer ligação que fale o protocolo. HandlerSSLCert aponta um certificado PEM próprio e StagerVerifySSLCert exige que o outro lado o valide; PayloadUUIDTracking e PayloadUUIDName dão identidade a cada payload e IgnoreUnknownPayloads recusa os desconhecidos.

Atrás de NAT, o endereço que o payload contacta não é onde se abre o socket: ReverseListenerBindAddress e ReverseListenerBindPort dizem onde escutar localmente, LHOST e LPORT ficam com o endereço público e o grupo Override força o valor que o handler anuncia.

O multi/handler em cibersegurança

Um handler é uma porta à escuta. Cada handler reverse é um socket em escuta que o sudo ss -tlnp mostra, com o processo ruby do msfconsole como dono. Numa rede de produção, uma porta alta à escuta fora do inventário, sobretudo num posto de trabalho, é para investigar.

Uma sessão é uma ligação de saída que não larga. Na máquina comprometida, uma sessão reverse é uma ligação persistente para o mesmo IP e a mesma porta, que volta de dez em dez segundos se for cortada. O ss -tnp state established e o lsof -nP -i mostram o processo e o utilizador, os registos de saída da firewall mostram o padrão repetido e o EDR e o IDS costumam reconhecer o Meterpreter. Antes de matar o processo, registe as saídas, preserve /proc/<PID> e isole a máquina.

O handler é uma peça, não o fim. Num teste autorizado, o valor está no que o teste revela à defesa: que alertas dispararam, em quanto tempo e o que passou despercebido. Trabalhe dentro do âmbito escrito, registe o que faz e limpe tudo no fim.

Experimente no simulador interativo

O simulador recria um laboratório fictício: a consola msf6 no kali-lab e um alvo-lab com payloads já em execução (como lá chegaram fica fora do âmbito). À esquerda vê o datastore do handler, com as opções em falta realçadas, as ligações entre as duas máquinas e as listas de jobs e sessões; à direita, a saída de cada comando. Demonstrar tudo segue a ordem do vídeo até à vista da defesa e à limpeza final; Anterior e Seguinte avançam ao seu ritmo e Repor estado volta ao início.

Erros comuns e boas práticas

  • Esquecer o ExitOnSession: por omissão, o handler fecha-se à primeira sessão.
  • Um PAYLOAD que não corresponde: staged e stageless, plataforma ou protocolo diferentes dão sessões que abrem e morrem logo.
  • Culpar o Metasploit pelo Handler failed to bind: quase sempre é um job antigo na mesma porta; veja com jobs -v.
  • Prender a consola com run: use run -j e controle tudo com jobs e sessions.
  • Ignorar o NAT: o LHOST que o payload contacta pode não ser onde o socket abre.
  • Deixar handlers e sessões abertos: no fim, sessions -K, jobs -K e nenhum handler persistente esquecido. E nunca fora do âmbito autorizado por escrito.

Conclusão

O multi/handler é um stub sem opções próprias: escolher o payload é configurar o handler. O ExitOnSession a false mantém-no vivo para várias sessões, os jobs permitem ter vários à escuta, os temporizadores explicam as sessões que morrem sozinhas e os grupos de certificado, UUID e Override separam um handler improvisado de um bem configurado. Do lado de quem defende, aprenda a encontrar portas à escuta e ligações persistentes com o comando ss e o comando lsof.

Workshop — Linha de Comandos Linux

Ferramentas como esta assentam num terminal bem dominado. No workshop Linha de Comandos Linux da HJFR pratica, com exercícios reais e acompanhamento, a base de qualquer trabalho de segurança — ofensiva autorizada ou defensiva.

Conhecer o workshop

Este artigo faz parte dos guias de cibersegurança do blog HJFR — use estas ferramentas apenas em laboratório próprio ou com autorização escrita.

Mais artigos