O DEEP#DOOR combina dropper em lote, payload Python embutido, persistência no Windows, evasão de telemetria e acesso remoto por bore[.]pub para manter controle sobre hosts comprometidos.
| Componente | Framework de backdoor DEEP#DOOR, com dropper install_obf.bat e payload Python svc.py executado em hosts Windows comprometidos. |
| Vetor | Execução de um script em lote provavelmente distribuído por phishing; o script desativa controles de segurança, reconstrói o payload Python embutido e configura persistência. |
| Impacto | Acesso remoto persistente, execução de comandos, vigilância, movimentação lateral, operações pós-exploração e roubo de credenciais de Chrome, Firefox, Windows Credential Manager, AWS, Google Cloud e Microsoft Azure. |
| Prioridade | Isolar hosts com sinais do dropper, revisar persistências em Startup, chaves Run, tarefas agendadas e WMI, restaurar controles de segurança e rotacionar credenciais de navegador, Windows e nuvem. |
| Artefatos | install_obf.bat, svc.py, comunicação com bore[.]pub, persistência por Startup folder scripts, Registry Run keys, scheduled tasks e assinaturas WMI opcionais. |
| Evasão | Detecção de sandbox, depurador e máquina virtual; patching de AMSI e ETW; unhooking de NTDLL; adulteração do Microsoft Defender; bypass de SmartScreen; supressão de logs do PowerShell; limpeza de logs e alteração de timestamps. |
O DEEP#DOOR é um framework de backdoor escrito em Python que opera como um RAT com foco em persistência prolongada, coleta de credenciais e operação pós-comprometimento em sistemas Windows. A cadeia começa com o install_obf.bat, um script em lote ofuscado que contém o payload Python dentro do próprio dropper. Em vez de baixar continuamente componentes externos, o script extrai, reconstrói e executa o svc.py em tempo de execução. Esse desenho reduz dependências de infraestrutura externa, diminui eventos de rede iniciais e complica a reconstrução forense quando o analista procura apenas por downloads tradicionais ou por artefatos separados no disco.
Depois da execução, o implante estabelece comunicação com bore[.]pub, um serviço público de tunelamento TCP escrito em Rust. O uso de um serviço de túnel público evita que o operador precise expor diretamente uma infraestrutura C2 dedicada no payload e permite misturar parte do tráfego malicioso com tráfego legítimo associado ao serviço. A capacidade descrita inclui execução remota de comandos, vigilância, movimentação lateral e roubo de credenciais armazenadas em Google Chrome, Mozilla Firefox, Windows Credential Manager e ambientes de nuvem, incluindo Amazon Web Services, Google Cloud e Microsoft Azure. Não há indicação clara, no material analisado, de uma campanha ampla, altamente ativa ou sistematicamente direcionada a setores ou geografias específicas; o uso observado é descrito como limitado e possivelmente mais direcionado.
A etapa inicial depende da execução do install_obf.bat. O vetor é avaliado como compatível com distribuição por phishing, mas a extensão real da atividade e o número de infecções bem-sucedidas não estão confirmados. Quando o script é executado, ele tenta enfraquecer os controles locais do Windows antes de iniciar o payload principal. A lógica do dropper inclui extração dinâmica do svc.py, reconstrução do código Python embutido e ativação do implante no host. Essa abordagem desloca parte relevante da cadeia para script local, o que pode escapar de controles que esperam um binário convencional ou que dependem apenas da inspeção de downloads subsequentes.
O implante também cria várias formas de persistência. Os mecanismos citados incluem scripts na pasta Startup, chaves Run do Registro, tarefas agendadas e assinaturas WMI opcionais. Além disso, há um watchdog que verifica se os artefatos de persistência foram removidos e tenta recriá-los automaticamente. Para resposta a incidente, esse detalhe muda a ordem de contenção: remover apenas uma tarefa agendada ou uma chave do Registro pode não encerrar a presença do malware se o watchdog continuar ativo. A eliminação precisa considerar processo em execução, script original, payload reconstruído, mecanismos redundantes e qualquer assinatura WMI associada.
A evasão é parte central do funcionamento. O DEEP#DOOR incorpora detecção de sandbox, depurador e máquina virtual, o que pode alterar comportamento durante análise automatizada. Ele também tenta interferir em mecanismos de visibilidade do Windows por meio de patching de AMSI e Event Tracing for Windows (ETW), unhooking de NTDLL, adulteração do Microsoft Defender, bypass de SmartScreen, supressão de logging do PowerShell, limpeza de logs, alteração de timestamps e limpeza de linha de comando. Esses recursos indicam preocupação explícita com telemetria, análise dinâmica e reconstrução histórica da execução.
A superfície principal é composta por estáções e servidores Windows onde um usuário ou processo execute o install_obf.bat. O contexto não fornece versões específicas do Windows, nomes de organizações afetadas, setor, país ou volume de infecções, portanto a priorização deve se basear em exposição operacional: endpoints com execução de scripts em lote, Python disponível ou payload Python executável, permissões suficientes para alterar controles de segurança e capacidade de criar persistência em Startup, Registro, tarefas agendadas ou WMI. Ambientes em que usuários recebem anexos, links ou arquivos por canais de phishing devem tratar a execução do dropper como hipótese inicial de investigação.
O impacto sobre credenciais amplia a superfície para além do endpoint. O malware mira credenciais armazenadas em Google Chrome, Mozilla Firefox e Windows Credential Manager, além de credenciais de cloud relacionadas a AWS, Google Cloud e Microsoft Azure. Mesmo que o host seja contido rapidamente, segredos extraídos podem permitir acesso posterior a consoles, APIs, pipelines, buckets, máquinas virtuais, identidades de serviço ou outros recursos, dependendo do escopo das permissões roubadas. A resposta precisa assumir que credenciais presentes no sistema no momento do comprometimento podem ter sido expostas, sem afirmar vazamento confirmado quando não houver evidência local.
- Hosts Windows com execução observada de
install_obf.batou presença desvc.pyreconstruído em tempo de execução. - Perfis de usuário com credenciais salvas em Google Chrome, Mozilla Firefox ou Windows Credential Manager.
- Ambientes com credenciais de AWS, Google Cloud ou Microsoft Azure armazenadas no endpoint comprometido.
- Sistemas onde controles como Microsoft Defender, SmartScreen, AMSI,
ETWou logging do PowerShell foram desativados, adulterados ou tiveram comportamento anômalo.
A investigação deve começar pela cadeia de execução. Procure eventos de criação ou execução de install_obf.bat, processos de script em lote lançando Python, arquivos temporários ou artefatos relacionados a svc.py e comandos que precedam alterações em controles de segurança do Windows. Como o payload é embutido no dropper, a ausência de download externo não elimina comprometimento. A telemetria de endpoint deve ser revisada para criação de scripts na pasta Startup, novas entradas em chaves Run, criação ou modificação de tarefas agendadas e registros WMI recentes ou incomuns.
Na camada de rede, o ponto observável mais direto é comunicação com bore[.]pub. A presença desse destino não prova automaticamente atividade maliciosa em todos os ambientes, pois se trata de serviço público de tunelamento, mas conexões originadas de estáções de usuário, servidores que não deveriam usar túneis TCP ou processos Python sem justificativa operacional devem ser investigadas. Combine destino, processo pai, linha de comando, horário, persistência local e alteração de controles de segurança para reduzir falso positivo.
Os sinais de evasão também são relevantes para hunting. Eventos de falha ou interrupção de telemetria do PowerShell, lacunas incomuns em logs, limpeza de eventos, adulteração de timestamps, alterações em Defender ou SmartScreen e sinais de patching de AMSI ou ETW devem ser correlacionados com a execução do dropper. A limpeza da linha de comando e a tentativa de reduzir rastros indicam que a ausência de parâmetros completos em logs não deve encerrar a análise. Quando houver EDR, compare a árvore de processos com artefatos persistentes ainda ativos para identificar o watchdog ou recriação automática de persistência.
- Execução de
install_obf.batseguida por criação ou execução desvc.pyou de processo Python sem justificativa administrativa. - Novas persistências em Startup, Registry
Runkeys, scheduled tasks e assinaturas WMI opcionais. - Conexões de processos Python ou scripts para
bore[.]pubem hosts que não usam tunelamento TCP de forma aprovada. - Alterações em Microsoft Defender, SmartScreen, AMSI,
ETW, logging do PowerShell, timestamps e logs do Windows próximas ao horário de execução do dropper.
A contenção deve preservar evidência antes da remoção completa quando a organização tiver capacidade forense. Isole hosts com sinais do DEEP#DOOR, colete memória, árvores de processo, tarefas agendadas, chaves Run, artefatos em Startup, registros WMI e eventos de rede relacionados a bore[.]pub. Em seguida, encerre processos associados ao implante e ao watchdog, remova persistências redundantes e restaure controles de segurança adulterados. A ordem importa porque o watchdog pode recriar artefatos removidos se permanecer ativo.
A correção não termina no endpoint. Como o malware tem capacidade de coletar credenciais de navegadores, Windows Credential Manager e provedores de nuvem, a resposta deve incluir rotação de senhas, revogação de sessões, invalidação de tokens e revisão de chaves ou credenciais usadas para AWS, Google Cloud e Microsoft Azure nos sistemas afetados. Em nuvem, revise logs de autenticação, uso de credenciais, criação de recursos, alterações de IAM e acessos fora do padrão temporal do comprometimento. A remoção local sem rotação de segredos mantém risco de acesso posterior por credenciais já copiadas.
Medidas preventivas devem reduzir a probabilidade de execução inicial e limitar pós-exploração. Restringir execução de scripts em lote recebidos por canais não confiáveis, aplicar controle de aplicação, monitorar criação de persistência, reforçar proteção contra adulteração do Defender e manter logging do PowerShell habilitado aumentam a visibilidade. Bloqueios ou alertas para serviços de tunelamento público devem ser avaliados conforme necessidade operacional, com exceções documentadas para usos legítimos. Para equipes de DFIR, o ponto crítico é tratar DEEP#DOOR como presença persistente e orientada a credenciais, não como artefato único removível por exclusão de arquivo.
- Isolar hosts suspeitos e coletar evidência de processos, memória, persistências, WMI, tarefas agendadas e tráfego para
bore[.]pub. - Remover o implante somente depois de neutralizar o watchdog e todos os mecanismos de persistência conhecidos.
- Restaurar Microsoft Defender, SmartScreen, AMSI,
ETWe logging do PowerShell quando houver sinais de adulteração. - Rotacionar credenciais de Chrome, Firefox, Windows Credential Manager, AWS, Google Cloud e Microsoft Azure presentes nos hosts afetados.
- Revisar logs de identidade e nuvem para uso posterior de credenciais expostas, incluindo acessos fora de padrão e alterações de permissão.
0 Comentários