Infraestrutura do IcedID é rastreada por certificado TLS autoassinado e validação criptográfica

Servidores de comando e controle associados ao IcedID foram identificados por uma combinação de campos incomuns em certificados TLS e uma verificação baseada em hash da chave pública.

Componente	Infraestrutura HTTPS de comando e controle do malware bancário IcedID, também conhecido como BokBot.
Vetor	A cadeia descrita usa documentos DOC/XLS com macros, um primeiro estágio e um segundo estágio composto por carregador DLL de 64 bits e bot criptografado disfarçado como arquivo .dat.
Impacto	O IcedID possui capacidades confirmadas de hooking em navegador, roubo de credenciais, proxy MiTM e módulo VNC, além de comunicação com servidores C2 por HTTPS.
Prioridade	Validar servidores suspeitos por características do certificado TLS, correlação entre número de série e hash da chave pública, e aplicar bloqueio apenas após confirmação técnica.
Artefatos	Certificados autoassinados com emissor e assunto usando CN=localhost, país AU, estado Some-State e organização Internet Widgits Pty Ltd.
IoCs	Exemplos defangados citados incluem 152[.]89[.]247[.]60, formgotobig[.]top, ponduroviga[.]top, tranmigrust[.]club e aswenedo[.]space.

Resumo técnico

A análise descreve uma forma de rastrear infraestrutura associada ao IcedID sem depender, em primeiro lugar, da coleta contínua de amostras, engenharia reversa completa de cada binário ou extração manual de configurações. O ponto central é que parte dos servidores de comando e controle expõe, na porta HTTPS, certificados TLS autoassinados com campos incomuns e suficientemente estáveis para serem usados como pivô de investigação. A técnica não prova por si só que todo servidor encontrado é malicioso, mas reduz a área de busca para um conjunto de candidatos que pode ser validado com uma propriedade adicional do próprio mecanismo de comunicação do malware.

O IcedID é apresentado como malware bancário em evolução desde 2017, também chamado de BokBot, com recursos que vão além do furto simples de credenciais. O conjunto de capacidades citado inclui hooking em navegador, roubo de credenciais, configuração de proxy MiTM e módulo VNC. Essa combinação torna a infraestrutura de comando e controle particularmente relevante para equipes de defesa, porque o servidor C2 não é apenas um destino de rede: ele é o ponto de coordenação que sustenta entrega de etapas posteriores, comunicação do bot e controle operacional sobre máquinas infectadas.

A cadeia de infecção descrita contém três componentes maliciosos. O primeiro é o documento de entrada em formato DOC ou XLS com macros. Em seguida vem um primeiro payload. Por fim, a segunda etapa inclui duas partes: um carregador DLL de 64 bits e o bot criptografado, disfarçado como arquivo .dat. Cada payload de segunda etapa costuma embutir de dois a quatro domínios únicos, todos resolvendo para o mesmo endereço IP. Esse detalhe torna a infraestrutura rastreável por DNS passivo e por varredura de certificados, desde que a validação seja tratada com cuidado para evitar falsos positivos.

Fluxo técnico

A comunicação de vítimas com a infraestrutura observada ocorre por HTTPS. A inspeção do certificado apresentado pelos servidores revelou um padrão incomum: o certificado é autoassinado e usa valores genéricos, incluindo CN=localhost, país AU, estado Some-State e organização Internet Widgits Pty Ltd. Em servidores públicos legítimos, o campo de nome comum normalmente refletiria um nome plenamente qualificado associado ao serviço exposto. O uso de localhost no certificado, combinado com os demais campos, fornece um marcador de busca útil em plataformas de varredura de internet, porque reduz o universo inicial de servidores candidatos.

A etapa de descoberta usa a observação de que os servidores C2 precisam apresentar esse certificado para permitir a comunicação esperada pelo malware. Plataformas de indexação de serviços expostos na internet podem ser consultadas por campos de certificado, incluindo emissor e assunto. Quando a busca exige apenas valores genéricos como organização ou estado, o volume de resultados cresce muito e perde valor operacional. Quando o nome comum localhost é mantido como parte da condição, o conjunto fica mais restrito e passa a servir como ponto inicial para validação técnica.

A validação adicional vem de uma lógica observada antes da comunicação com o C2. O bot calcula um hash Fowler-Noll-Vo de 32 bits sobre a chave pública do certificado e compara o resultado com o número de série do próprio certificado, também aceitando uma variação com operação XOR citada no contexto. Como os certificados são autoassinados, os operadores controlam o número de série e conseguem ajustá-lo para satisfazer essa condição. Para a defesa, esse comportamento transforma o certificado em artefato verificável: um servidor que apresenta os campos esperados e também satisfaz a relação entre chave pública e número de série fica muito mais fortemente associado à infraestrutura do IcedID do que um servidor encontrado apenas por coincidência de texto.

A aplicação desse método reduziu os candidatos para 52 servidores avaliados como relacionados ao IcedID. A conclusão se apoia na combinação entre propriedade incomum do certificado e algoritmo de verificação específico, não apenas em reputação ou em presença de uma porta aberta. Esse ponto é importante para operações defensivas: bloquear qualquer servidor que use certificado genérico pode causar erro; correlacionar certificado, serial, chave pública, DNS passivo e histórico de resolução oferece uma base de decisão muito mais robusta.

Superfície afetada

A superfície exposta envolve principalmente endpoints Windows que recebem a cadeia inicial por documentos Office com macros e passam a executar estágios posteriores do IcedID. A infraestrutura de rede associada aparece nos destinos HTTPS usados pelo bot e nos domínios embutidos em payloads de segunda etapa. Como cada amostra pode carregar entre dois e quatro domínios que apontam para o mesmo IP, a defesa precisa correlacionar tanto nomes quanto endereços, evitando tratar cada domínio como evento isolado.

Os servidores identificados tinham porta 443 disponível em todos os casos observados. A maioria também expunha porta 80, e uma parcela significativa mantinha SSH na porta 22. Esses elementos não são, isoladamente, prova de atividade maliciosa, mas ajudam a caracterizar o perfil da infraestrutura. Também foram observadas concentrações geográficas em Romênia, Estados Unidos e Alemanha. A distribuição por país não deve ser usada como bloqueio amplo, porque infraestrutura criminosa pode mudar rapidamente e serviços legítimos podem coexistir nas mesmas regiões.

O uso de HTTPS pelos operadores cria uma tensão técnica. Por um lado, dificulta inspeções simples de conteúdo e ajuda a proteger a comunicação contra interferência direta. Por outro, obriga os servidores a apresentarem um certificado visível no handshake TLS. Quando esse certificado carrega valores incomuns e ainda precisa obedecer a uma relação verificável com a chave pública, a própria camada de transporte passa a funcionar como sinal de detecção.

• Endpoints que abrem documentos DOC/XLS com macros e permitem execução de código de macro ficam expostos à primeira etapa da cadeia.
• Servidores HTTPS com certificado autoassinado contendo CN=localhost e os demais campos observados entram no conjunto de candidatos a C2.
• Domínios embutidos em payloads de segunda etapa podem apontar para o mesmo endereço IP, permitindo expansão por DNS passivo.
• Portas 443, 80 e 22 aparecem como características de exposição em muitos servidores analisados, mas exigem correlação com certificado e validação criptográfica.

Hunting e telemetria

A investigação defensiva deve começar por telemetria de rede e TLS. Em ambientes com logs de proxy, firewall, inspeção TLS autorizada, EDR com metadados de conexão ou sensores de rede, vale procurar conexões de endpoints para servidores que apresentem certificados com assunto e emissor contendo CN=localhost, Some-State e Internet Widgits Pty Ltd. A presença desses campos deve ser tratada como sinal de hunting, não como veredito automático. O próximo passo é validar se o número de série do certificado está relacionado à chave pública pelo algoritmo observado.

No endpoint, a cadeia inicial sugere atenção a documentos Office com macros que antecedem execução de payload, criação ou carregamento de DLL de 64 bits e presença de artefato criptografado com extensão .dat associado ao segundo estágio. Como o contexto não fornece nomes de arquivos específicos além da extensão e do papel do artefato, a detecção deve privilegiar sequência comportamental: abertura de documento, execução de macro, lançamento de processo filho incomum, gravação de componente adicional e comunicação HTTPS posterior para infraestrutura recém-observada.

Em DNS e reputação, a busca pode ser expandida a partir de endereços confirmados para domínios historicamente resolvidos. Um exemplo citado foi o endereço 152[.]89[.]247[.]60, associado a domínios como formgotobig[.]top, ponduroviga[.]top, tranmigrust[.]club e aswenedo[.]space. Esses indicadores devem permanecer defangados em relatórios e controles humanos, e a implementação técnica de bloqueio deve usar listas internas validadas. O volume completo de endereços não deve ser publicado ou aplicado sem curadoria, porque a infraestrutura pode mudar e endereços reaproveitados podem introduzir risco de falso positivo.

A telemetria de navegador também é relevante quando houver suspeita de infecção, porque o IcedID possui capacidade de hooking. A defesa deve correlacionar alertas de credenciais, sessões bancárias anômalas, proxy local ou remoto inesperado e possível uso de VNC com os eventos de instalação da cadeia. A presença de uma conexão HTTPS para infraestrutura validada por certificado deve elevar a prioridade do incidente, especialmente quando aparece após execução de documento com macro.

• Handshakes TLS com certificado autoassinado contendo CN=localhost, Some-State e Internet Widgits Pty Ltd.
• Relação verificável entre número de série do certificado e hash Fowler-Noll-Vo de 32 bits calculado sobre a chave pública.
• Conexões HTTPS de endpoints após abertura de DOC/XLS com macro e execução de payload intermediário.
• Arquivos .dat usados como contêiner do bot criptografado em conjunto com carregador DLL de 64 bits.
• Resoluções DNS para domínios defangados associados a IPs confirmados, com análise de histórico por DNS passivo.

Mitigação

A resposta deve separar descoberta, validação e contenção. Na descoberta, a equipe pode usar metadados de certificados e logs de rede para levantar candidatos. Na validação, o servidor suspeito deve ser conferido contra a lógica de correlação entre chave pública e número de série, além de ser comparado com domínios resolvidos historicamente e eventos de endpoint. Na contenção, bloqueios de domínio, IP e certificado devem ser aplicados somente quando houver confiança suficiente, com monitoramento de impacto e revisão periódica para evitar dependência de indicadores obsoletos.

Em endpoints, a mitigação passa por reduzir a exposição ao vetor inicial. Macros em documentos recebidos devem permanecer desabilitadas ou restritas por política, especialmente quando o documento vem de zona externa ou não confiável. Controles de execução devem impedir que aplicativos Office criem processos filhos desnecessários, gravem binários em locais temporários ou acionem carregamento de DLL fora de caminhos esperados. Quando houver indício de infecção, a máquina deve ser isolada, as sessões do usuário invalidadas e credenciais potencialmente expostas revisadas, porque o malware possui capacidade de roubo de credenciais.

No perímetro e em ferramentas de segurança, a detecção baseada em certificado é útil porque independe do domínio específico embutido na amostra. Ainda assim, ela não substitui análise comportamental. Operadores podem alterar campos do certificado, trocar algoritmo interno ou migrar infraestrutura. Por isso, a regra defensiva deve ser tratada como técnica de hunting de alto valor, acompanhada por telemetria de processo, DNS, proxy, EDR e identidade. A prioridade operacional é transformar a descoberta em bloqueios curados e em alertas que expliquem por que um destino foi classificado como provável C2.

Também é recomendável revisar caches de proxy, registros de DNS recursivo, histórico de firewall e eventos de autenticação próximos ao primeiro contato com a infraestrutura. Como o IcedID inclui recursos de MiTM, VNC e roubo de credenciais, a contenção não deve terminar no bloqueio do endereço remoto. É necessário avaliar persistência, processos carregados, arquivos associados ao segundo estágio e qualquer atividade autenticada realizada depois da infecção provável.

• Bloquear indicadores confirmados por domínio, IP e certificado após validação, mantendo revisão periódica contra falsos positivos.
• Restringir macros em documentos DOC/XLS de origem externa e monitorar processos filhos iniciados por aplicativos Office.
• Investigar carregamento de DLL de 64 bits e presença de arquivo .dat relacionado ao segundo estágio do malware.
• Isolar endpoints com comunicação confirmada para C2 e revisar credenciais usadas após o horário provável de infecção.
• Correlacionar logs de proxy, DNS, firewall, EDR e identidade antes de encerrar o incidente.