Domínios 'noreply' viram armadilha de dados confidenciais
Aprofundamento CEVIU
Aprofundamento
A revelação do pesquisador Cory Solovewicz sobre a compra e os dados recebidos nos domínios noreply[.]us e noreply[.]net expõe uma falha de segurança crucial que empresas e organizações globais parecem ignorar. O que ele chamou de “honeypot acidental” demonstra que muitas companhias configuram e-mails para endereços “noreply” ou “deleteduser” sem considerar que esses domínios podem ser registrados por terceiros. A expectativa de que e-mails enviados para esses endereços simplesmente desaparecerão no limbo digital é, na prática, uma aposta de alto risco com dados sensíveis.
Solovewicz registrou o noreply[.]us em 2020 e o noreply[.]net em 2024, recebendo centenas de milhares de mensagens com informações que variam de pedidos de pizza a credenciais de plataformas de teste, relatórios de acidentes de prefeituras e dados de clientes. O incidente não é isolado; Mike Sheward, da Xeal, comprou deleteduser[.]com e observou um cenário semelhante, com dados de pedidos de medicamentos e convites para reuniões governamentais. Ambos os pesquisadores agora adquirem domínios adicionais para mitigar o risco de que atores mal-intencionados explorem essa brecha, mostrando a negligência generalizada na gestão de e-mails corporativos.
Por que isso importa
Este cenário é um alerta severo para qualquer empresa que lida com dados digitais. A premissa de que endereços de e-mail como “noreply” ou “deleteduser” são seguros porque não pertencem a ninguém é perigosa e infundada. A prática pode levar ao vazamento de informações confidenciais de clientes, funcionários e até mesmo segredos comerciais, caso esses domínios caiam nas mãos erradas.
O trabalho de Solovewicz e Sheward sublinha a necessidade urgente de auditorias de segurança mais rigorosas para sistemas de comunicação. A facilidade com que dados sensíveis são direcionados a esses “honeypots” acidentais indica que muitas organizações falham em implementar políticas básicas de ciclo de vida de dados e de e-mail, expondo-se a riscos significativos de conformidade e reputação. Afinal, usar domínios internos ou o padrão .invalid é uma alternativa segura e conhecida há quase 20 anos.
Linha do tempo
Cory Solovewicz adquire o domínio noreply[.]us.
Cory Solovewicz adquire o domínio noreply[.]net.
Notícia do pesquisador Cory Solovewicz que domínios 'noreply' viraram armadilhas de dados confidenciais.
Perguntas frequentes
O que são domínios 'noreply' e 'deleteduser'?
Domínios como 'noreply[.]net' ou 'deleteduser[.]com' são geralmente usados por empresas para enviar e-mails automatizados sem expectativa de resposta. Eles também podem ser usados internamente para e-mails de usuários excluídos, na suposição de que esses endereços não existem mais ou não são monitorados. A ideia é que essas caixas de entrada não devem ser gerenciadas por humanos.
Como as empresas estão vazando dados para esses domínios?
Empresas configuram seus sistemas para enviar e-mails de notificação, alertas ou dados para endereços como 'sistema@noreply[.]com' ou 'usuarioexcluido@deleteduser[.]org'. Quando esses domínios são registrados por terceiros, como Cory Solovewicz ou Mike Sheward, os e-mails são entregues diretamente a eles, contendo informações que podem ser confidenciais. Isso ocorre por falta de verificação de propriedade do domínio ou por usar um domínio público ao invés de um interno ou inválido.
Qual o risco real de segurança desses 'honeypots' acidentais?
O risco é imenso. Se esses domínios caírem nas mãos de criminosos, dados confidenciais como informações pessoais identificáveis (PII), credenciais de acesso, segredos comerciais, detalhes de pedidos e até registros de saúde podem ser coletados e explorados. Os dados vazados podem ser usados para fraudes, ataques de phishing, extorsão ou espionagem corporativa, causando danos financeiros e reputacionais significativos.
O que as empresas podem fazer para evitar vazar dados para esses domínios?
Empresas devem auditar rigorosamente seus sistemas de e-mail para garantir que não estão enviando dados para domínios públicos que podem ser registrados por terceiros. Uma prática recomendada é usar domínios internos controlados pela própria organização, ou o domínio 'example.invalid', que é reservado para ser usado em exemplos e testes e é garantido como não existente na internet pública. Verificar a existência de catch-all em domínios também é fundamental.
Fontes
- arstechnica.comfonte original
- Categoria
- CEVIU
- Publicado
- 11 de agosto de 2026
- Editoria
- CEVIU