Hack The Box: como o MCP Inspector transforma ferramentas de IA em um novo ponto de ataque

A máquina Kobold, do Hack The Box Season 10, mostra algo importante: os novos riscos em torno da IA não surgem apenas nos modelos, mas também nas ferramentas que os desenvolvedores usam para operá-los. Nesta análise, o ponto de partida do ataque é o MCP Inspector, uma ferramenta de desenvolvimento para servidores de IA. Dali, a cadeia segue um roteiro conhecido da segurança de infraestrutura: execução de código, leitura de arquivos locais dentro do contêiner, reutilização de credenciais e elevação de privilégios via Docker, até o controle total do sistema.

Kobold é classificada como uma máquina Easy, mas seu valor não está na dificuldade da exploração, e sim no realismo da combinação de vulnerabilidades. O autor mostra como um serviço de depuração e inspeção de componentes MCP pode, de repente, virar um perímetro externo. Para as equipes que montam um stack de IA com servidores, conectores e ferramentas auxiliares, é um lembrete incômodo: tudo o que está conectado ao modelo e tem acesso ao ambiente local passa automaticamente a fazer parte da superfície de ataque. E esses elementos costumam ser os menos protegidos, porque são vistos como internos, temporários ou «só para desenvolvedores».

A primeira etapa da cadeia é a RCE via MCP Inspector. Esse passo, por si só, muda o quadro de ameaças: o invasor não precisa quebrar a aplicação principal se ao lado existe uma ferramenta menos protegida e com recursos ampliados.

Depois de obter execução de código dentro do contêiner, o atacante passa para a LFI, isto é, a leitura de arquivos locais. Na prática, é uma das etapas mais produtivas de qualquer ataque a serviços em contêineres: configurações, variáveis de ambiente, logs, chaves, tokens de serviço e artefatos de build costumam ficar em lugares previsíveis. Mesmo que os segredos em si não sejam entregues diretamente, o vazamento da estrutura de diretórios, dos nomes de serviços ou de endereços internos já acelera o avanço.

O ponto seguinte é a reutilização de credenciais. Em projetos de IA, esse problema é especialmente comum: as equipes sobem serviços experimentais rapidamente, copiam arquivos .env, duplicam senhas entre contêineres e deixam credenciais idênticas para papéis diferentes. Na análise, é justamente a reutilização de segredos que permite sair do acesso local e chegar a componentes mais sensíveis do sistema e, em seguida, explorar erros na configuração do Docker para elevar privilégios.

O material mostra dois caminhos independentes até o controle total da máquina, o que reforça a ideia central: se o atacante já tem código dentro do contêiner, o socket do Docker, capabilities em excesso, montagens inseguras e acesso amplo demais aos recursos do host rapidamente transformam o contêiner de barreira em um ponto intermediário conveniente.

Outro ponto útil é que o autor mapeia o ataque para o MITRE ATT&CK. Isso transforma a invasão passo a passo da máquina em material prático para os defensores: dá para ver não só a sequência de ações, mas também as classes de técnicas: execução inicial, discovery, collection, credential access, lateral movement e privilege escalation. Isso ajuda as equipes de blue team e DevSecOps a relacionar o cenário de laboratório com logs, alertas e medidas de detecção reais.

A tese principal vai muito além de uma única máquina: o ecossistema MCP, que inclui inspetores, proxies, conectores e pontes locais para arquivos, rede e segredos, se torna uma nova superfície de ataque justamente porque vive na junção de várias zonas de confiança.

O que isso significa na prática?

Para quem constrói serviços de IA, já não basta proteger apenas a API do modelo e a interface do usuário. É preciso tirar as ferramentas de desenvolvimento do acesso público, ativar autenticação até em utilitários «internos», proibir a reutilização de segredos, reduzir os privilégios dos contêineres, revisar as configurações do Docker e registrar as ações em torno dos componentes MCP com o mesmo cuidado dedicado aos serviços principais em produção.

Kobold funciona bem porque, sem teoria desnecessária, mostra que o próximo incidente sério em um stack de IA pode começar não pelo modelo, mas por uma pequena ferramenta de serviço que ninguém considerava crítica.