MuddyWater implanta backdoor BugSleep em campanhas de phishing no Oriente Médio

A cadeia usa contas de e-mail comprometidas, links no Egnyte e iscas em PDF para entregar RMMs legítimos ou o backdoor BugSleep, com persistência por tarefa agendada e comunicação cifrada com C&C.

Componente	Backdoor BugSleep, campanhas de phishing do grupo MuddyWater, abuso do serviço legítimo Egnyte e uso alternado de RMMs como Atera Agent e Screen Connect.
Vetor	E-mails de spear phishing enviados a partir de contas organizacionais comprometidas, com iscas setoriais ou genéricas e links em anexos PDF que direcionam a arquivos compartilhados no Egnyte.
Impacto	Execução de comandos do operador, transferência de arquivos entre a máquina comprometida e o servidor C&C, persistência por tarefa agendada e tentativa de reduzir inspeção por soluções EDR em algumas amostras.
Prioridade	Investigar e-mails externos ou internos comprometidos com links para subdomínios Egnyte, validar endpoints que criaram tarefas agendadas com nomes como PackageManager ou DocumentUpdater e conter hosts com comunicação C&C suspeita.
Alvos	Campanhas observadas contra municípios, governo, mídia, companhias aéreas, agências de viagem e outros setores, com maior volume direcionado a Israel e atividade também relacionada a Arábia Saudita, Turquia, Azerbaijão, Índia e Portugal.
Artefatos	Mutexes PackageManager e DocumentUpdater, comentário de tarefa agendada sample comment, arquivo temporário C:\users\public\a.txt em uma amostra e identificação inicial composta por nome do computador e nome do usuário.

Resumo técnico

O grupo MuddyWater, associado ao Ministério de Inteligência e Segurança do Irã, ampliou campanhas de phishing no Oriente Médio e passou a distribuir o backdoor BugSleep em parte das operações. A atividade mantém um padrão já conhecido do grupo: mensagens enviadas por contas de e-mail organizacionais previamente comprometidas, iscas adaptadas ao setor do alvo e encaminhamento para conteúdo hospedado em serviços legítimos. A mudança relevante é que, além de ferramentas de gerenciamento remoto legítimas, como Atera Agent e Screen Connect, algumas cadeias recentes entregam um implante próprio voltado a execução de comandos e transferência de arquivos.

Desde fevereiro de 2024, foram identificados mais de 50 e-mails de spear phishing direcionados a mais de 10 setores e enviados para centenas de destinatários. O maior volume citado envolve organizações em Israel, mas há atividade relacionada também a Arábia Saudita, Turquia, Azerbaijão, Índia e Portugal. Os temas das iscas mudaram de mensagens bastante específicas, como ofertas voltadas a municípios, para convites mais reutilizáveis de webinars e cursos on-line. Essa alteração permite reaproveitar o mesmo texto em múltiplas regiões, inclusive com uso mais frequente do inglês, enquanto o payload final varia conforme o alvo.

Fluxo técnico

A cadeia começa com e-mails de phishing enviados por contas comprometidas, o que aumenta a credibilidade da mensagem e dificulta controles que dependem apenas de reputação do remetente. As mensagens podem trazer anexos PDF com links para arquivos compartilhados no Egnyte, uma plataforma legítima de compartilhamento. Os subdomínios usados foram alinhados aos nomes de empresas mencionadas nas iscas, e a interface do compartilhamento pode exibir um suposto proprietário com nome localmente plausível. Esse uso de infraestrutura legítima reduz o atrito para o usuário e pode atravessar filtros que bloqueiam apenas domínios recém-criados ou claramente maliciosos.

O payload entregue não é uniforme. Em uma campanha com isca semelhante, alvos na Arábia Saudita receberam um RMM, enquanto alvos em Israel receberam o BugSleep. O backdoor é descrito como malware sob desenvolvimento ativo desde maio de 2024, com várias versões distribuídas em intervalos curtos. As diferenças entre amostras incluem melhorias, correções e erros novos, indicando desenvolvimento iterativo. A lógica principal observada começa com chamadas repetidas à API Sleep, provavelmente para atrasar a execução e reduzir a eficácia de ambientes automatizados de análise. Em seguida, o malware carrega APIs necessárias, cria um mutex e decifra sua configuração.

As configurações e strings do BugSleep usam uma rotina simples de ofuscação baseada em subtração de um valor fixo por byte. A configuração contém endereço IP e porta do C&C. Em muitas amostras, o malware cria uma tarefa agendada com o mesmo nome do mutex, incluindo nomes como PackageManager e DocumentUpdater, e adiciona o comentário sample comment. Essa tarefa executa o malware a cada 30 minutos em base diária, fornecendo persistência sem depender de técnicas mais ruidosas de inicialização automática.

A comunicação com o C&C também é cifrada por uma transformação simples, com adição de 3 a cada byte módulo 256. As mensagens seguem o formato lógico composto por tamanho do dado e conteúdo. No início da sessão, o implante envia um identificador da vítima formado pelo nome do computador seguido pelo nome do usuário. O material disponível confirma que o malware executa comandos enviados pelo operador e transfere arquivos entre o host comprometido e o servidor C&C, mas não detalha uma lista completa de comandos. Portanto, a avaliação defensiva deve focar no comportamento confirmado: persistência, beaconing, identificação do usuário e operações de arquivo.

Uma versão incluiu mecanismos voltados a dificultar inspeção por EDR. A amostra habilita o sinalizador MicrosoftSignedOnly em ProcessSignaturePolicy, restringindo o carregamento de imagens não assinadas pela Microsoft no processo e reduzindo a possibilidade de injeção de DLLs de terceiros. Também habilita ProhibitDynamicCode em ProcessDynamicCodePolicy, o que impede geração de código dinâmico ou modificação de código executável existente. Essa escolha pode interferir em técnicas de monitoramento em espaço de usuário que dependem de hooks em APIs. Uma amostra adicional veio com loader próprio, capaz de decifrar shellcode e carregá-lo em memória por escrita remota e criação de thread em outro processo, sem que a lista de processos escolhidos esteja suficientemente descrita no material recebido.

Superfície afetada

A exposição principal recai sobre organizações que recebem mensagens de parceiros, fornecedores ou entidades públicas por e-mail e permitem acesso a serviços de compartilhamento externos. Municípios, entidades governamentais, veículos de mídia, companhias aéreas, agências de viagem e empresas de transporte aparecem como setores citados. A campanha não depende de uma vulnerabilidade específica de produto; ela explora confiança operacional, contas de e-mail já comprometidas e a aparência legítima de plataformas de compartilhamento.

Ambientes Windows são relevantes para a análise do BugSleep, porque os artefatos descritos envolvem mutexes, tarefas agendadas, APIs de processo, políticas de assinatura e caminho local como C:\users\public\a.txt. A presença de RMMs legítimos na mesma linha operacional exige cuidado adicional: a instalação de Atera Agent ou Screen Connect pode ser administrativamente permitida em algumas empresas, mas, nesse caso, deve ser correlacionada com e-mail de origem, usuário que iniciou a cadeia, momento de criação do agente, destino de rede e ausência de chamado de suporte legítimo.

O uso do Egnyte amplia a superfície para além de anexos executáveis. Mesmo quando o e-mail inicial contém apenas um PDF ou link, a cadeia pode chegar a binários hospedados em compartilhamentos aparentemente confiáveis. O risco cresce quando controles de navegação permitem todos os subdomínios do serviço, quando anexos PDF não passam por detonação com seguimento de links e quando a equipe de segurança não correlaciona o nome do suposto proprietário do compartilhamento com a entidade real esperada.

• Organizações que recebem convites de webinar, curso on-line ou oferta setorial com link externo em PDF.
• Endpoints Windows que executaram binários após acesso a subdomínios Egnyte relacionados a iscas de phishing.
• Ambientes onde RMMs legítimos podem ser instalados sem aprovação explícita, inventário centralizado e alerta por origem incomum.
• Contas de e-mail corporativas comprometidas usadas como remetentes para mensagens de grande volume direcionadas ao mesmo setor.

Hunting e telemetria

A investigação deve começar pela camada de e-mail e identidade. Procure mensagens enviadas por contas organizacionais legítimas, mas com padrão anormal de distribuição para dezenas de destinatários do mesmo setor, temas de webinar, curso, solução municipal ou convite profissional, e anexos PDF que contenham links externos. A telemetria precisa correlacionar remetente, destinatários, idioma usado, hora de envio, reputação histórica da conta remetente e presença de autenticação incomum antes do disparo.

No endpoint, sinais de persistência são mais objetivos. A criação de tarefas agendadas com nomes iguais a mutexes observados, como PackageManager e DocumentUpdater, combinada com comentário sample comment e execução a cada 30 minutos, é um artefato acionável. A análise também deve cobrir binários que chamam Sleep repetidamente antes de carregar APIs, processos que aplicam ProcessSignaturePolicy com MicrosoftSignedOnly e ProcessDynamicCodePolicy com ProhibitDynamicCode, e eventos de escrita de memória seguida de criação de thread remota quando associados ao mesmo fluxo de entrega.

Na rede, a defesa deve procurar conexões de saída posteriores ao acesso a links Egnyte, especialmente quando o host envia um identificador compatível com concatenação de nome do computador e usuário antes de iniciar troca cifrada simples. Como o material não fornece IoCs completos, a busca deve priorizar comportamento e encadeamento temporal: e-mail suspeito, download ou execução de arquivo, criação de persistência, beaconing para IP e porta definidos em configuração e operações de transferência de arquivos. Em ambientes com proxy, registros de URL e TLS devem ser preservados para reconstruir o caminho do PDF ao arquivo baixado.

• Mensagens de phishing com anexos PDF e links para subdomínios Egnyte alinhados ao nome de empresas ou eventos citados na isca.
• Criação de tarefas agendadas chamadas PackageManager ou DocumentUpdater, principalmente com comentário sample comment e recorrência de 30 minutos.
• Execução de binários que fazem chamadas repetidas à API Sleep antes de atividade de rede ou criação de persistência.
• Uso de políticas de processo MicrosoftSignedOnly e ProhibitDynamicCode em executáveis sem justificativa operacional clara.
• Instalação inesperada de Atera Agent ou Screen Connect após e-mails de convite, curso, webinar ou proposta setorial.
• Acesso ao arquivo C:\users\public\a.txt quando correlacionado a um binário suspeito da mesma cadeia.

Mitigação

A resposta deve tratar a campanha como combinação de comprometimento de e-mail, abuso de serviço legítimo e execução de malware. O primeiro passo é preservar evidências de mensagens recebidas e enviadas, incluindo cabeçalhos, anexos e URLs, e verificar se alguma conta interna foi usada para encaminhar iscas. Contas suspeitas devem ter sessões revogadas, senha redefinida e autenticação multifator revisada. A análise de caixa postal precisa identificar mensagens semelhantes enviadas para outros setores ou regiões, porque a campanha foi observada em volume e com reutilização de temas.

Nos endpoints, hosts que executaram arquivos após acesso a links de compartilhamento devem ser isolados para coleta de memória, artefatos de tarefas agendadas, binários recentes, eventos de criação de processo e tráfego de saída. A remoção da persistência só deve ocorrer depois da preservação dos dados necessários à investigação. RMMs legítimos encontrados no fluxo precisam ser validados com inventário e chamados de suporte; quando não houver justificativa, devem ser removidos, com revogação de credenciais ou tokens associados ao agente e revisão de conexões remotas estabelecidas.

Para reduzir recorrência, controles de e-mail devem detonar PDFs com seguimento controlado de links, aplicar políticas de alerta para serviços de compartilhamento usados fora do padrão e bloquear instalação não autorizada de RMMs. Em vez de bloquear integralmente plataformas legítimas como Egnyte, a defesa deve combinar reputação, idade do compartilhamento, nome do proprietário exibido, domínio remetente, volume de destinatários e histórico de relacionamento com a organização. No endpoint, alertas comportamentais para tarefas agendadas incomuns, políticas de processo usadas por binários não aprovados e criação de thread remota ajudam a capturar variantes mesmo quando hashes e infraestrutura mudam.

• Revisar contas de e-mail que enviaram ou receberam a isca, revogar sessões suspeitas e confirmar MFA ativo.
• Isolar endpoints que acessaram links da campanha e coletar tarefas agendadas, binários recentes, eventos de processo e conexões de saída.
• Validar qualquer instalação de Atera Agent ou Screen Connect contra inventário, autorização e chamado de suporte.
• Criar detecções para tarefas PackageManager e DocumentUpdater, comentário sample comment e recorrência de execução a cada 30 minutos.
• Monitorar links Egnyte em anexos PDF quando o tema envolver webinar, curso, oferta municipal ou convite profissional inesperado.
• Bloquear execução de RMMs não aprovados e exigir fluxo formal de exceção para ferramentas de suporte remoto.