Quando o seu dispositivo IoT faz login como administrador, é tarde demais! (Diário do Convidado)

(Este é um diário de convidado de Adam Thorman, estagiário do ISC como parte do SANS.edu BACS programa)

Introdução

Você já instalou um novo dispositivo no roteador de sua casa ou empresa? Mesmo quando as instruções de configuração são simples, os usuários finais geralmente ignoram a etapa mais importante: alterar as credenciais padrão. A excitação de implementar um novo dispositivo frequentemente supera a disciplina de protegê-lo.
Este diário explica um pequeno conto do mundo real e, em seguida, percorre minhas próprias observações de estágio supervisionando um honeypot e uma avaliação de vulnerabilidade que demonstram a rapidez com que as credenciais padrão são descobertas e abusadas.

Credenciais padrão em um exemplo do mundo real

Nomes de usuário e senhas padrão continuam sendo o vetor de ataque mais explorado para dispositivos de Internet das Coisas (IoT). Quer a instalação seja realizada por um usuário final ou por um fornecedor contratado, as organizações devem ter um processo definido para garantir que as credenciais sejam alteradas imediatamente. Sem esse processo, o compromisso é muitas vezes uma questão de quando, e não de se.
Durante uma avaliação de vulnerabilidade de rotina no trabalho, identifiquei vários endereços IP que eram acessíveis usando credenciais padrão. Esses IPs pertenciam a um sistema de segurança recém-instalado que monitorava materiais confidenciais. A situação foi pior do que o esperado:

• O sistema não foi colocado na VLAN adequada
• Máquinas básicas de usuários finais poderiam alcançá-lo
• O nome de usuário “raiz”permaneceu inalterado e senha“senha”foi alterado para“administrador”

Essa configuração ainda era fácil de adivinhar e explorar, independentemente de o acesso ser interno ou externo. Do meu ponto de vista, foi facilmente adivinhado e acessado, como na Figura 1 abaixo.

Figura 1 – Meme de controles de segurança facilmente contornáveis

Quais registros foram exibidos?

Para entender melhor o quão comum é esse problema, analisei o tráfego SSH e Telnet durante um período de oito dias (18 a 25 de janeiro) e comparei-o com dados mais recentes. Isso está relacionado à história acima com base em quantos dispositivos são mantidos com suas configurações padrão ou ligeiramente alterados com combinações triviais comuns. Esses gráficos foram extraídos da página My SSH Reports do Internet Storm Center (ISC) (2), enquanto a comparação foi gerada com a ferramenta ChatGPT.

27 DE JANEIRO DE 2026

17 DE FEVEREIRO DE 2026

COMPARAÇÃO

Em ambos os conjuntos de dados:

• O nome de usuário “raiz”permaneceu dominante em ~39%
• A senha “123456”aumentou de 15% para 27%
• Essas combinações se assemelhavam muito ao comportamento automatizado de verificação de botnets

Isso se alinha com listas de credenciais conhecidas publicamente que os invasores usam para reconhecimento em larga escala.

Conexões bem-sucedidas

Durante a janela de análise, observei:

• 44.269 tentativas de conexão malsucedidas
• 1.286 logins bem-sucedidos
• Uma taxa de sucesso de apenas 2,9%

Essa percentagem pode parecer baixa, mas ainda assim resultou em mais de mil sessões comprometidas.
Para realizar esta análise, analisei os logs JSON do Cowrie usando jqconverteu-os em arquivos CSV e consolidou-os em uma única planilha.

Das 1.286 conexões bem-sucedidas:

• 621 usou o nome de usuário raiz
• 154 usado administrador como a senha
• 406 compartilhou a mesma impressão digital HASSH 2ec37a7cc8daf20b10e1ad6221061ca5
• 47 sessões corresponderam aos três indicadores

A sessão correspondente a esse hash é mostrada no APÊNDICE A.

O que os invasores fizeram após o login?

Quatro IDs de sessão se destacaram durante a análise do relatório completo:
1.eee64da853a9
2.f62aa78aca0b
3.308d24ec1d36
4.f0bc9f078bdd

As sessões 1 e 4 focaram no reconhecimento, executando comandos para coletar detalhes do sistema, como CPU, tempo de atividade, arquitetura e informações de GPU.

Com o uso do ChatGPT (3), consegui comparar cada sessão e os comandos que o invasor tentou usar. Foi divulgado que as sessões 1 e 4 tiveram reconhecimento da impressão digital superior HASSH. Ambos tinham o mesmo comando, mas com carimbos de data/hora diferentes. Consulte o APÊNDICE B para obter as saídas dos comandos ID de sessão 1 e 2.

Sessões 2 e 3 demonstrou comportamento mais avançado:

• Persistência de chave SSH
• Manipulação de credenciais
• Tentativas de modificar senhas de contas

Sessão 308d24ec1d36 classificado como o mais grave devido a tentativas de alteração de senha e mecanismos de persistência que poderiam ter resultado em controle de longo prazo se tentassem em um meio do mundo real. Consulte o APÊNDICE C para obter as saídas dos comandos ID de sessão 2 e 3.

Tentativas fracassadas contam uma história maior

Tentativas de autenticação malsucedidas revelaram ainda mais.

Somente uma impressão digital foi responsável por 18.846 tentativas fracassadas, sugerindo fortemente uma atividade de verificação conduzida por botnets.

Em 19 de janeiro de 2026, houve 14.057 tentativas fracassadas em um único dia – um aumento significativo em comparação com as datas vizinhas.

Do ponto de vista de um analista do Centro de Operações de Segurança (SOC), esse nível de atividade representa um sério risco de exposição. Isso poderia significar uma campanha de varredura de botnet como a observada pela GreyNoise no final de agosto de 2025 (4).

Abaixo está um visual dos principais nomes de usuário, senhas e hashes no período analisado.

Figura 2 – Principais nomes de usuário, senhas e impressões digitais

Para observar em comparação com os outros dias, onde não chega nem a metade de 14k, a Figura 3 abaixo dita o spread.


Figura 3 – Tentativas de conexão malsucedidas ao longo do tempo

Melhores práticas a serem seguidas para resolver credenciais padrão

O modelo de política de segurança cibernética SANS para padrão de construção de senhas afirma que “se aplica a todas as senhas, incluindo, entre outras, contas de nível de usuário, contas de nível de sistema, contas da web, contas de e-mail, proteção de tela, correio de voz e logins de roteador local”. Mais especificamente, o documento também afirma que “para senhas fortes e longas, quanto mais caracteres uma senha tiver, mais forte ela será” e “recomendam um mínimo de 16 caracteres em todas as senhas relacionadas ao trabalho (6)”.

Estabeleça uma política imediata para alterar a senha padrão dos dispositivos IoT. Um exemplo é uma impressora de rede que é enviada com nomes de usuário e senhas padrão (7).

Experiência prática sem o desastre do mundo real

Ter acesso a um ambiente sandbox controlado, como um laboratório honeypot, proporciona uma experiência prática valiosa para profissionais de segurança cibernética.
Às vezes, você pode precisar lidar e ver o desastre do mundo real em um ambiente controlado para lidar com ele e ver o efeito cascata que ele pode produzir.

Por que isso pode se aplicar a você?

MITRE ATT&CK documenta explicitamente o uso adversário de credenciais padrão definidas por fabricantes em sistemas de controle. Eles enfatizam que deve ser alterado o mais rápido possível.
Este não é apenas um problema empresarial. Os mesmos riscos se aplicam a:

• Roteadores domésticos
• Câmeras em rede
• Impressoras
• Dispositivos NAS

Para gerentes de contratação, até mesmo anúncios de emprego que divulgam detalhes específicos da infraestrutura podem ajudar involuntariamente os invasores na busca por credenciais padrão.
Em última análise, é importante implementar deliberadamente medidas de segurança de dados para se proteger contra violações de dados em sua casa ou local de trabalho.

Quem pode obter informações valiosas sobre essas informações?

Qualquer pessoa com internet ou impressão digital. Mais especificamente, liderança e gestão organizacional, quando se trata de treinar sua força de trabalho e treinar seus substitutos.
Um departamento de tecnologia do cliente, onde uma equipe se dedica a testar o software ou dispositivos na rede, incluindo a validação da versão do mesmo por meio de uma ferramenta de gerenciamento de patches ou biblioteca de referência para saber quando as versões estão desatualizadas. Relatórios rotineiros de software “não autorizado” ou “proibido” são absolutamente essenciais em seu local de trabalho.
Administradores de sistema e analistas de SOC são essenciais não apenas para conhecê-lo, mas também para mantê-lo. Para continuar a tendência, estudantes ou profissionais de segurança cibernética, como equipes Vermelhas vs.5), por exemplo, ganhará um valor significativo nesta informação.

Seguindo em frente mesmo com boa defesa

A defesa em profundidade continua crítica:

• Credenciais fortes e exclusivas
• Autenticação multifator sempre que possível (7)
• Impressão digital do dispositivo
• Monitoramento contínuo

SANS também incentiva a utilização de senhas, senhas compostas de múltiplas palavras. (6)

Um ditado comum em segurança cibernética é: “quanto mais seguros são os dados, menos convenientes são os dados – quanto menos seguros, mais convenientes”.
As organizações também devem manter uma Análise de Impacto nos Negócios (BIA) dentro do seu programa de segurança cibernética. Mesmo com fortes medidas defensivas, as organizações devem assumir que alguns controlos de segurança podem eventualmente falhar. Uma Análise de Impacto nos Negócios (BIA) ajuda as organizações a priorizar quais ativos exigem a proteção mais forte, identificando dependências críticas e operacionais e limites de tempo de inatividade aceitáveis.

Amarrando tudo junto. Esta recomendação combinada com uma estratégia de defesa profunda, a BIA garante que os sistemas mais importantes recebam múltiplas camadas de proteção, tais como segmentação de rede, controlos de autenticação fortes, monitorização contínua e planeamento de resposta a incidentes. Sem esta abordagem estruturada, as organizações poderão ter dificuldades em recuperar de um compromisso ou minimizar perturbações operacionais.

Figura 4 – Exemplos de tipos de ativos empresariais empresariais (9)

Apêndice A – Amostra de Registro

(1) https://www.sans.edu/cyber-security-programs/bachelors-degree/
(2) https://isc.sans.edu/mysshreports/
(3) https://chatgpt.com/
(4) https://eclypsium.com/blog/cisco-asa-scanning-surge-cyberattack/
(5) https://www.techtarget.com/searchsecurity/tip/Red-team-vs-blue-team-vs-purple-team-Whats-the-difference
(6) https://www.sans.org/information-security-policy/password-construction-standard
(7) https://owasp.org/www-project-top-10-infrastructure-security-risks/docs/2024/ISR07_2024-Insecure_Authentication_Methods_and_Default_Credentials
(8) https://attack.mitre.org/techniques/T0812/
(9) https://csrc.nist.gov/pubs/ir/8286/d/upd1/final (PDF: Usando análise de impacto nos negócios para informar a priorização de riscos)

———–
Guy Bruneau IPSS Inc.

Minha página GitHub
Twitter: Guy Bruneau
gbruneau em isc dot sans dot edu