Intrusão em múltiplas ondas usou o mesmo ponto de entrada no Exchange para tentar implantar Deed RAT, TernDoor e uma variante modificada com comunicação para sentinelonepro[.]com.
| Componente | Microsoft Exchange Server em ambiente de uma empresa não identificada de óleo e gás do Azerbaijão |
| Vetor | Exploração recorrente da cadeia ProxyNotShell para acesso inicial, seguida por tentativas de web shell, movimento lateral e carregamento de backdoors por DLL side-loading |
| Impacto | Persistência operacional, retomada de acesso após remediações parciais, implantação ou tentativa de implantação de Deed RAT, TernDoor e uma variante modificada de Deed RAT |
| Prioridade | Corrigir integralmente o Exchange, remover web shells, rotacionar credenciais comprometidas e validar que caminhos de retorno e cargas persistentes foram eliminados |
| Artefatos | Deed RAT, Snappybee, TernDoor, Mofu Loader, binário legítimo do LogMeIn Hamachi usado em DLL side-loading |
| IoCs | sentinelonepro[.]com foi observado como infraestrutura de comando e controle em uma variante modificada de Deed RAT |
| Atribuição | Atividade atribuída com confiança moderada a alta a FamousSparrow, também rastreado como UAT-9244, com sobreposição tática parcial com Earth Estries e Salt Typhoon |
Uma empresa não identificada do setor de óleo e gás do Azerbaijão foi alvo de uma intrusão prolongada entre o fim de dezembro de 2025 e o fim de fevereiro de 2026. A operação foi conduzida em três ondas distintas e manteve o Microsoft Exchange Server como ponto de entrada recorrente. A atividade foi atribuída com confiança moderada a alta a FamousSparrow, também conhecido como UAT-9244, um agrupamento associado à China que apresenta sobreposição tática parcial com clusters rastreados como Earth Estries e Salt Typhoon. O caso é relevante para inteligência de ameaças porque demonstra expansão de vitimologia para infraestrutura energética do Azerbaijão e, tecnicamente, mostra como uma correção incompleta de Exchange pode permitir reentrada mesmo depois de contenções pontuais.
A sequência começou em 25 de dezembro de 2025 com implantação de Deed RAT, também conhecido como Snappybee, uma backdoor descrita como sucessora do ShadowPad e utilizada por múltiplos grupos de espionagem associados à China. A segunda onda ocorreu no fim de janeiro ou início de fevereiro de 2026, quando o operador tentou introduzir TernDoor por meio do Mofu Loader, um carregador de shellcode previamente associado a GroundPeony; essa tentativa de uso de DLL side-loading para TernDoor não teve êxito. A terceira onda ocorreu no fim de fevereiro de 2026 e envolveu nova tentativa de implantar uma versão modificada de Deed RAT, com comunicação de comando e controle apontando para sentinelonepro[.]com.
O elemento central da campanha não foi apenas o uso de backdoors diferentes, mas a reutilização do mesmo caminho de acesso. O operador teria explorado a cadeia ProxyNotShell para obter acesso inicial ao Exchange e retornou ao ambiente mesmo após tentativas de remediação. Esse padrão indica que a resposta anterior não eliminou todas as condições necessárias para o comprometimento: vulnerabilidade original sem correção completa, credenciais que ainda permitiam uso adversário, web shells ou artefatos residuais e ausência de validação efetiva de persistência. Para defesa, a lição operacional é tratar exploração de Exchange como incidente de intrusão completa, não como simples aplicação de atualização.
O fluxo observado começa com exploração de Microsoft Exchange Server por uma cadeia compatível com ProxyNotShell. Após acesso inicial, o operador tentou implantar web shells para manter controle sobre o servidor exposto e criar um ponto de execução persistente. Em ambientes Exchange comprometidos, web shells costumam permitir execução de comandos, upload de arquivos, movimentação para outros sistemas e preparação de cargas adicionais. O material analisado não informa nomes de arquivos, caminhos, hashes ou comandos usados nesses web shells, portanto a análise defensiva deve focar no comportamento: criação de arquivos incomuns em diretórios acessíveis pelo serviço web, requisições HTTP atípicas ao Exchange, processos filhos inesperados gerados por componentes do servidor e autenticações administrativas fora do padrão.
Na primeira onda, o operador implantou Deed RAT usando uma técnica evoluída de DLL side-loading. O carregamento abusou de um binário legítimo do LogMeIn Hamachi, que foi usado como hospedeiro para carregar uma DLL maliciosa responsável por executar a carga principal. A técnica não se limitou à substituição simples de uma biblioteca no caminho de busca. O artefato malicioso sobrescreveu duas funções exportadas específicas, criando um acionamento em dois estágios que dependia do fluxo natural de execução do aplicativo legítimo. Esse desenho aumenta a evasão porque a carga passa a ser disparada por chamadas esperadas do próprio binário assinado ou legítimo, reduzindo a visibilidade de controles que buscam apenas execução direta de payloads desconhecidos.
A segunda onda mostra adaptação de ferramental. Quase um mês após a intrusão inicial, o operador tentou usar o Mofu Loader para entregar TernDoor, uma backdoor observada previamente em ataques contra infraestrutura de telecomunicações na América do Sul desde 2024. A tentativa de DLL side-loading nessa etapa foi malsucedida, mas ainda é tecnicamente importante porque mostra troca de família de malware e teste de outro caminho de execução. Mofu Loader atua como carregador de shellcode, o que normalmente desloca parte da lógica maliciosa para memória e reduz dependência de um executável final diretamente visível em disco. Mesmo sem confirmação de execução bem-sucedida do TernDoor nesse caso, a presença do carregador é um sinal de tentativa de ampliar o acesso e diversificar persistência.
Na terceira onda, no fim de fevereiro de 2026, os operadores voltaram a uma versão modificada de Deed RAT. A variante observada usava sentinelonepro[.]com como endereço de comando e controle. A escolha de um domínio visualmente semelhante a uma marca legítima de segurança sugere tentativa de mascarar tráfego ou reduzir suspeita durante revisão superficial de conexões de saída, embora o contexto não traga detalhes sobre protocolo, URI, certificado, porta, frequência de beaconing ou formato de mensagens. O ponto defensivo é que a alteração da infraestrutura e da carga ocorreu depois de tentativas anteriores, indicando operação ativa, monitoramento de resultados e ajuste de ferramentas conforme a resposta da vítima.
A superfície diretamente afetada é o Microsoft Exchange Server usado pela organização de óleo e gás. O servidor Exchange, por natureza, costuma concentrar autenticação, caixas postais, regras de transporte, dados sensíveis de comunicação corporativa e integração com diretórios internos. Quando um Exchange exposto é explorado, o risco vai além do servidor: credenciais e sessões podem permitir acesso a contas de usuário, administradores, aplicações internas e sistemas conectados. Neste caso, houve movimento lateral e criação de pontos redundantes de presença, indicando que a intrusão buscou ampliar o alcance para além do host inicial.
A exposição também inclui sistemas que confiam no Exchange ou compartilham credenciais, contas com privilégios administrativos usadas durante manutenção, endpoints que receberam ferramentas de movimentação lateral e servidores que podem ter sido acessados a partir do ponto inicial. Como a campanha explorou o mesmo caminho em ondas separadas, qualquer organização que tenha tratado apenas a carga final, sem validar a correção do Exchange e sem revisar credenciais, permanece vulnerável a reentrada. Remover uma DLL, encerrar um processo ou bloquear um domínio de comando e controle não corrige a condição que permitiu acesso inicial.
Para ambientes de energia, o impacto operacional deve ser avaliado com cuidado, mas sem extrapolar além dos dados disponíveis. O contexto confirma uma empresa de óleo e gás e uma operação de espionagem com backdoors, web shells e movimento lateral. Não há informação de sabotagem, interrupção de produção, acesso a tecnologia operacional, manipulação de sistemas industriais ou vazamento público de dados. A resposta defensiva deve, portanto, priorizar reconstrução técnica da intrusão, escopo de acesso e validação de sistemas adjacentes, evitando assumir efeitos não comprovados.
- Servidores Microsoft Exchange expostos que tenham sido explorados pela cadeia
ProxyNotShellou que não tenham recebido correção completa. - Contas administrativas e de serviço usadas no Exchange, em diretórios corporativos ou em processos de manutenção durante o período da intrusão.
- Hosts internos alcançados por movimento lateral a partir do servidor comprometido.
- Sistemas com execução do binário legítimo do
LogMeIn Hamachiem diretórios ou contextos incomuns, especialmente quando acompanhado por DLLs não reconhecidas. - Conexões de saída para
sentinelonepro[.]comou resolução DNS associada a esse domínio durante ou após fevereiro de 2026.
A caça deve começar no Exchange, cobrindo logs HTTP, logs de autenticação, criação de arquivos, execução de processos e alterações em diretórios relacionados ao serviço web. Como o vetor indicado é ProxyNotShell, a equipe deve revisar tráfego e requisições compatíveis com exploração do Exchange no período de dezembro de 2025 a fevereiro de 2026, sem restringir a busca apenas às datas conhecidas das três ondas. Tentativas repetidas podem ter ocorrido antes ou depois das implantações observadas. A análise deve correlacionar requisições anômalas com criação de arquivos, execução de shells, processos filhos incomuns e autenticações que indiquem uso interativo ou automatizado de contas internas.
No endpoint, a telemetria mais importante envolve DLL side-loading. A execução do LogMeIn Hamachi deve ser revisada quando ocorrer em servidores onde o software não faz parte do inventário aprovado, a partir de caminhos temporários, compartilhamentos, diretórios de usuário, diretórios do Exchange ou locais usados por operadores para staging. A presença de uma DLL próxima ao binário legítimo, com exportações manipuladas ou comportamento divergente, é sinal de carregamento abusivo. Como o método descrito depende de duas funções exportadas específicas para acionar o loader de Deed RAT, a análise de binários suspeitos deve incluir export table, assinatura, metadados, caminho de carga e cadeia de processos.
Na rede, a busca deve cobrir DNS, proxy, firewall e EDR para comunicação com sentinelonepro[.]com, além de conexões persistentes ou periódicas saindo de servidores Exchange e hosts de administração. A ausência de um único domínio não encerra a investigação, porque as ondas anteriores usaram backdoors diferentes e a infraestrutura pode ter sido alterada. Para TernDoor e Mofu Loader, os sinais podem estar mais próximos de execução em memória, chamadas de carregamento de shellcode e processos com comportamento de rede sem arquivo malicioso evidente. A equipe deve comparar a linha do tempo de alertas com eventos de remediação para identificar retorno do adversário após limpeza parcial.
- Requisições HTTP anômalas ao Exchange seguidas de criação de arquivos ou execução de processos pelo contexto do servidor.
- Web shells ou arquivos recém-criados em diretórios servidos pelo Exchange durante o período de dezembro de 2025 a fevereiro de 2026.
- Execução do binário do
LogMeIn Hamachiem servidores onde ele não é esperado ou com DLLs adjacentes fora do inventário. - DLLs com exportações suspeitas usadas para acionar loaders por meio do fluxo de uma aplicação legítima.
- Eventos de movimento lateral originados do servidor Exchange, incluindo autenticações administrativas incomuns e conexões para hosts internos.
- Resolução DNS, proxy ou conexão de saída envolvendo
sentinelonepro[.]com. - Execução ou tentativa de execução de artefatos associados a
Deed RAT,TernDoorouMofu Loader, quando houver cobertura por EDR, sandbox ou análise de memória.
A contenção deve tratar o Exchange como origem provável da intrusão e como ativo crítico para escopo. A primeira medida é isolar ou restringir o servidor afetado conforme a tolerância operacional, preservar evidências e aplicar correções completas relacionadas à cadeia explorada. A aplicação de atualização deve ser acompanhada de validação de versão, revisão de configuração e verificação de que mitigação temporária não substituiu correção definitiva. Em paralelo, a equipe deve remover web shells, DLLs maliciosas, loaders, tarefas ou serviços criados pelo operador e qualquer binário legítimo usado fora do contexto esperado.
A rotação de credenciais é obrigatória quando há evidência de exploração persistente e movimento lateral. Devem ser priorizadas contas administrativas, contas de serviço usadas pelo Exchange, credenciais de manutenção, contas com acesso remoto e identidades que apresentaram autenticação a partir do servidor comprometido. A rotação precisa ocorrer depois da contenção do ponto de entrada; caso contrário, novas credenciais podem ser capturadas pelo mesmo acesso residual. Também é necessário invalidar sessões, revisar tokens, remover permissões adicionadas indevidamente e confirmar que contas criadas ou modificadas durante a intrusão foram analisadas.
A erradicação precisa considerar redundância adversária. A campanha criou ou tentou criar múltiplos pontos de presença, e as ondas separadas mostram que o operador retornou depois de tentativas de remediação. A equipe deve reconstruir a linha do tempo desde o acesso inicial, listar hosts tocados pelo Exchange comprometido, revisar eventos de autenticação entre servidores, analisar endpoints alcançados por movimento lateral e confirmar que não há cargas remanescentes de Deed RAT, TernDoor ou Mofu Loader. Bloquear sentinelonepro[.]com ajuda a reduzir comunicação de uma variante específica, mas não substitui erradicação do acesso inicial nem investigação de infraestrutura alternativa.
Após a limpeza, a validação deve combinar nova varredura do Exchange, revisão de integridade de arquivos, comparação com baseline de processos, monitoramento reforçado de DNS e proxy e simulação controlada de detecção para os comportamentos observados. Em ambientes de energia, a equipe também deve revisar segmentação entre sistemas corporativos e redes operacionais, mesmo sem evidência confirmada de impacto em tecnologia operacional. O objetivo não é apenas remover a carga final, mas demonstrar que o adversário perdeu o caminho de retorno, que credenciais expostas não funcionam mais e que tentativas futuras de exploração ou DLL side-loading serão detectadas em tempo útil.
- Aplicar correções completas no Microsoft Exchange Server afetado e confirmar a versão instalada, sem depender apenas de mitigação temporária.
- Procurar e remover web shells, DLLs maliciosas, loaders, serviços, tarefas agendadas e binários colocados em diretórios incomuns.
- Rotacionar credenciais administrativas, contas de serviço e identidades usadas a partir do Exchange comprometido após conter o ponto de entrada.
- Investigar movimento lateral a partir do Exchange e revisar todos os hosts internos acessados durante as três ondas.
- Bloquear e monitorar
sentinelonepro[.]com, preservando logs DNS, proxy e firewall para análise histórica. - Adicionar detecções para DLL side-loading envolvendo
LogMeIn Hamachifora de caminhos aprovados e para execução de bibliotecas com exportações suspeitas. - Executar revisão pós-incidente para confirmar que vulnerabilidade, credenciais, web shells e persistências redundantes foram removidos em conjunto.
0 Comentários