Webhooks do n8n são abusados em phishing para entregar malware

Campanhas observadas desde outubro de 2025 usam URLs de webhook em domínios *.app.n8n[.]cloud para acionar páginas intermediárias, fingerprinting por pixel de rastreamento e download de instaladores maliciosos associados a ferramentas RMM modificadas.

Componente	Webhooks expostos por fluxos de automação do n8n em subdomínios personalizados no formato *.app.n8n[.]cloud.
Vetor	E-mails de phishing incorporam links ou pixels invisíveis hospedados em URLs de webhook; o fluxo é acionado quando o usuário acessa o link ou quando o cliente de e-mail carrega o recurso remoto.
Impacto	Entrega condicionada de executáveis ou instaladores MSI maliciosos, uso de versões modificadas de ferramentas RMM legítimas e fingerprinting de destinatários por requisições HTTP com parâmetros de rastreamento.
Prioridade	Monitorar mensagens com URLs *.app.n8n[.]cloud, restringir carregamento automático de conteúdo remoto em e-mail, inspecionar downloads acionados por páginas intermediárias e revisar execuções de RMM não autorizadas.
Artefatos	Páginas com CAPTCHA intermediário, JavaScript embutido no HTML, executáveis, instaladores MSI, Datto e ITarian Endpoint Management modificados.
IoCs	Classe de indicador: URLs defangadas em *.app.n8n[.]cloud usadas como webhook e hosts externos de download não especificados no material disponível.
Mitigação	Aplicar controles de reputação e inspeção sobre links de automação em e-mails, bloquear RMM não aprovado, correlacionar requisições HTTP a webhooks com eventos de download e validar a origem de instaladores executados por usuários.

Resumo técnico

Campanhas de phishing vêm abusando de webhooks do n8n para transformar uma função legítima de automação em uma etapa de entrega de conteúdo malicioso. O ponto técnico central está no comportamento esperado de um webhook: uma URL pública recebe uma requisição, aciona um fluxo configurado previamente e devolve uma resposta HTTP ao cliente que fez o acesso. Quando essa URL é inserida em um e-mail, o navegador do destinatário ou o próprio cliente de e-mail pode se tornar o componente que consome a resposta. Esse modelo permite que operadores maliciosos façam a mensagem apontar para um domínio com aparência confiável, no padrão *.app.n8n[.]cloud, enquanto o fluxo acionado pelo webhook controla a página exibida, o rastreamento do alvo ou a sequência que leva ao download de outro artefato.

A atividade foi observada em uso desde outubro de 2025 e ganhou volume ao longo de 2026, com mensagens contendo essas URLs em março de 2026 cerca de 686% acima do volume registrado em janeiro de 2025. O abuso não depende de uma vulnerabilidade divulgada no n8n; o risco descrito está no uso indevido de uma capacidade legítima de automação, hospedada em infraestrutura gerenciada e acionável por URLs únicas. Para defesa, isso muda a lógica de filtragem: o domínio intermediário pode não parecer malicioso por reputação simples, mas o comportamento gerado após o clique, o conteúdo retornado ao navegador e os downloads iniciados pelo fluxo precisam ser avaliados como parte da cadeia de phishing.

Fluxo técnico

Em uma das cadeias observadas, o e-mail afirma que há um documento compartilhado e incorpora um link para um webhook hospedado no n8n. Ao acessar a URL, o usuário é direcionado para uma página intermediária que exibe um CAPTCHA. A conclusão desse desafio aciona a sequência seguinte, que resulta no download de uma carga maliciosa a partir de um host externo. O detalhe relevante para análise defensiva é que a lógica da página fica encapsulada no JavaScript do documento HTML retornado pelo fluxo. Com isso, do ponto de vista do navegador, a interação inicial parece associada ao domínio do n8n, mesmo quando o binário ou instalador final é buscado em outra infraestrutura.

O objetivo final descrito para essa cadeia é entregar um executável ou um instalador MSI que atua como condutor para versões modificadas de ferramentas legítimas de monitoramento e gerenciamento remoto, incluindo Datto e ITarian Endpoint Management. Essas ferramentas RMM, quando abusadas, oferecem ao operador uma forma de manter acesso persistente e estabelecer conexão com servidor de comando e controle. O material disponível não informa hashes, nomes de arquivos, endereços de C2, versões específicas das ferramentas nem parâmetros de execução, portanto a análise deve permanecer no nível de comportamento: phishing com link de webhook, página intermediária com CAPTCHA, download externo e posterior presença de RMM não autorizado no endpoint.

Um segundo uso recorrente envolve fingerprinting de destinatários. Nesse caso, o e-mail incorpora uma imagem invisível ou pixel de rastreamento hospedado em uma URL de webhook do n8n. Quando o cliente de e-mail carrega recursos remotos automaticamente, uma requisição HTTP GET é enviada para o webhook com parâmetros de rastreamento, incluindo o endereço de e-mail do destinatário. Essa etapa permite confirmar que a mensagem foi aberta, associar o evento a uma identidade e enriquecer a lista de alvos para ações posteriores. O impacto imediato não é execução de código, mas validação de alvo, medição de engajamento e possível preparação de campanhas mais direcionadas.

Superfície afetada

A superfície exposta envolve organizações que recebem e-mails com links para domínios de automação considerados legítimos, ambientes em que o carregamento automático de conteúdo remoto permanece habilitado e endpoints onde usuários podem baixar e executar instaladores sem validação suficiente. O componente abusado é o webhook público do n8n, não um agente local específico dentro da organização vítima. Como a plataforma permite criar fluxos por meio de serviço gerenciado, o operador malicioso não precisa expor infraestrutura própria logo na primeira etapa visível ao filtro de e-mail, o que reduz a eficácia de bloqueios baseados apenas em domínios recém-criados ou reputação de hospedagem desconhecida.

Também há uma superfície de identidade e privacidade operacional ligada aos pixels de rastreamento. Clientes de e-mail que buscam imagens remotas antes de uma análise explícita podem transmitir metadados suficientes para confirmar a validade de endereços e a abertura da mensagem. Quando esse evento é combinado com parâmetros de rastreamento no webhook, o operador consegue separar destinatários ativos de contas inativas, medir horários de leitura e priorizar usuários mais responsivos. Esse tipo de telemetria pode ser usado para refinar campanhas de malware sem que a primeira mensagem contenha um anexo malicioso ou uma URL de download diretamente exposta.

Para ambientes corporativos, a presença de ferramentas RMM legítimas modificadas aumenta a dificuldade de diferenciação entre administração autorizada e atividade abusiva. Datto e ITarian Endpoint Management aparecem como exemplos de ferramentas usadas na cadeia, mas o dado relevante para inventário é mais amplo: qualquer execução de RMM fora do catálogo aprovado, iniciada logo após clique em e-mail ou download a partir de navegador, deve ser tratada como evento de alto risco. O material não confirma exploração ativa de vulnerabilidade, vazamento de dados nem movimentação lateral; o impacto sustentado é entrega de malware, persistência por RMM abusado e comunicação com C2.

• Mensagens com links para *.app.n8n[.]cloud apresentadas como documentos compartilhados.
• Clientes de e-mail que carregam imagens remotas e disparam HTTP GET para webhooks de rastreamento.
• Endpoints em que executáveis ou instaladores MSI podem ser baixados e iniciados após interação com página intermediária.
• Ambientes que permitem ferramentas RMM fora de inventário, sem controle de origem, assinatura, instalador e destino de rede.

Hunting e telemetria

A investigação deve começar pela telemetria de e-mail e proxy, correlacionando mensagens recebidas com URLs no padrão *.app.n8n[.]cloud, cliques de usuário, redirecionamentos subsequentes e downloads iniciados na mesma sessão. Como o webhook pode retornar uma página HTML dinâmica, a captura do conteúdo entregue no momento do acesso é mais útil do que uma avaliação estática do domínio. Em campanhas com CAPTCHA, procure sequências em que a navegação passa por uma página de validação simples e, logo depois, aciona a obtenção de arquivo executável ou MSI a partir de um host externo. A ausência de um anexo na mensagem original não reduz o risco quando o fluxo pós-clique entrega o binário.

No endpoint, a linha de investigação deve observar processos de navegador ou cliente de e-mail precedendo downloads, criação de instaladores temporários, execução de binários recém-obtidos e instalação de serviços associados a RMM. O uso de Datto ou ITarian Endpoint Management só deve ser considerado normal quando houver correspondência com o inventário e com a política de administração remota da organização. Eventos de instalação fora de janela de manutenção, conexão de RMM para destinos desconhecidos, criação de persistência após clique em e-mail e execução por usuários sem função administrativa são sinais fortes para contenção.

Para o caso de fingerprinting, a defesa deve analisar logs de gateway de e-mail, proxy e DNS em busca de requisições automáticas a webhooks logo após o recebimento ou abertura de mensagens. Parâmetros contendo identificadores de destinatário, endereços de e-mail ou tokens de campanha devem ser tratados como evidência de rastreamento, mesmo sem download de malware. Essa telemetria ajuda a identificar quais caixas postais foram confirmadas pelo operador e quais usuários podem receber mensagens posteriores mais direcionadas. Quando possível, a investigação deve preservar assunto da mensagem, remetente, URL defangada, horário de abertura, user-agent e endereço de origem da requisição.

Como não há hashes, domínios de C2 ou nomes de arquivos específicos disponíveis, regras de detecção baseadas apenas em IoC terão alcance limitado. O caminho mais consistente é combinar classes de indicador: domínio de automação usado em e-mail, resposta HTML com JavaScript intermediário, CAPTCHA antes de download, obtenção de executável ou MSI e instalação de RMM não autorizado. Essa correlação reduz falsos positivos em organizações que usam automação legítima e aumenta a chance de detectar o abuso quando o domínio intermediário ainda tem reputação neutra.

• URLs defangadas com padrão *.app.n8n[.]cloud em corpo de e-mail, especialmente associadas a supostos documentos compartilhados.
• Requisições HTTP GET automáticas para webhooks contendo parâmetros de rastreamento ou endereço de e-mail do destinatário.
• Navegação que exibe CAPTCHA e, em seguida, inicia download de executável ou instalador MSI a partir de host externo.
• Execução ou instalação de Datto, ITarian Endpoint Management ou outro RMM fora do inventário aprovado.
• Conexões de RMM recém-instalado para infraestrutura externa após interação com mensagem de phishing.

Mitigação

A resposta deve priorizar controles que tratem webhooks de automação como infraestrutura legítima, mas não implicitamente confiável. Gateways de e-mail precisam avaliar a URL completa, o padrão de uso, o conteúdo retornado e o comportamento após o clique, não apenas a reputação do domínio base. Reescrita de links, análise em sandbox e inspeção de páginas intermediárias ajudam a revelar fluxos que usam CAPTCHA para atrasar a entrega do payload. Em paralelo, o carregamento automático de imagens remotas em clientes de e-mail deve ser restringido ou mediado por proxy seguro, pois o pixel hospedado em webhook pode confirmar abertura da mensagem e expor identificadores de destinatário.

No endpoint, a mitigação mais concreta é impor controle de aplicações e política explícita para ferramentas RMM. Datto, ITarian Endpoint Management e qualquer solução semelhante devem ter origem, versão, assinatura, instalador e finalidade administrativa documentados. Execuções fora desse padrão devem gerar alerta e, quando associadas a clique de e-mail, isolamento do host para impedir estabelecimento de persistência e comunicação com C2. A remoção do artefato final deve ser acompanhada de revisão de serviços, tarefas de inicialização, conexões persistentes e eventos de instalação, porque a cadeia descrita usa o RMM como meio de acesso continuado.

Para usuários e áreas de operação, a comunicação defensiva deve ser específica: mensagens que simulam documentos compartilhados e levam a páginas com CAPTCHA antes do download devem ser reportadas, mesmo quando o domínio aparente pertença a uma plataforma conhecida. O bloqueio amplo de n8n pode afetar usos legítimos, então a decisão deve considerar inventário interno, necessidade de negócio e evidência de abuso. Onde o n8n não é usado pela organização, controles mais restritivos para links vindos por e-mail podem ser aplicados. Onde há uso legítimo, listas de permissão devem ser restritas a fluxos conhecidos, proprietários internos e URLs documentadas.

Após qualquer detecção, a validação deve cobrir três frentes: caixas postais expostas ao link ou pixel, endpoints que baixaram artefatos e contas que executaram instaladores. Para mensagens com pixel, a organização deve identificar quais destinatários dispararam requisições e tratá-los como alvos validados. Para downloads, a análise deve preservar amostras em ambiente controlado, metadados de navegador, histórico de proxy e eventos de criação de processo. Para RMM, a resposta deve encerrar sessões não autorizadas, remover persistência, revisar conexões externas e confirmar que a ferramenta não permanece registrada como serviço ativo.

• Bloquear ou submeter à detonação links de e-mail que apontem para webhooks *.app.n8n[.]cloud sem relação com fluxos corporativos aprovados.
• Desabilitar carregamento automático de imagens remotas ou rotear esse tráfego por controles capazes de registrar e filtrar pixels de rastreamento.
• Aplicar allowlist para ferramentas RMM e alertar sobre instalação de Datto, ITarian Endpoint Management ou equivalentes fora do inventário.
• Correlacionar clique em e-mail, página com CAPTCHA, download de MSI ou executável e criação de serviço remoto no endpoint.
• Revisar usuários que abriram mensagens com pixel, pois a abertura pode ter confirmado o endereço para campanhas posteriores.