Grupo orientado por motivação ideológica usa webshell, coleta de credenciais administrativas e ferramentas PyDCrypt e DCSrv para propagação interna, criptografia de volumes e bloqueio de sistemas sem negociação de resgate.
| Componente | Infraestrutura externa vulnerável, webshell em IIS, malware PyDCrypt e payload DCSrv baseado em componentes do DiskCryptor. |
| Vetor | Exploração de vulnerabilidades conhecidas em serviços expostos à internet, seguida de implantação de webshell protegido por senha e uso de credenciais administrativas coletadas no ambiente da vítima. |
| Impacto | Replicação interna do malware, instalação de driver, criptografia de volumes locais de C: a Z:, substituição de bootloader e indisponibilidade dos computadores afetados; a campanha também busca divulgar dados sensíveis roubados. |
| Prioridade | Revisar exposição de serviços externos, caçar webshells em diretórios de IIS, preservar telemetria de criação de processos e parâmetros de linha de comando, conter hosts com PyDCrypt ou DCSrv e validar controles sobre drivers e serviços Windows. |
| Artefatos | Caminho de webshell C:\inetpub\wwwroot\aspnet_client\system_web\IISpool.aspx, execução observada de PyDCrypt em C:\Users\Public\csrss.exe, serviços DCUMSrv e DCDrv, driver DCDrv.sys e nomes de payload PyDCrypt e DCSrv. |
| IoCs | Hash MD5 embutido na autenticação do webshell 52a04efc6a0e7facf34dcc36a6d1ce6f; uso de nomes que imitam processos legítimos como svchost.exe e csrss.exe em caminhos suspeitos. |
MosesStaff é descrito como um grupo que começou a mirar organizações israelenses em setembro de 2021, em uma sequência de atividades destrutivas voltadas a gerar dano operacional e repercussão pública. A operação difere de campanhas tradicionais de ransomware porque a criptografia dos sistemas não aparece vinculada a negociação financeira ou cobrança de resgate. A motivação declarada pelo operador é ideológica, com foco em expor dados sensíveis roubados e impedir o uso normal das redes comprometidas.
A cadeia observada combina acesso inicial por falhas conhecidas em infraestrutura exposta, implantação de webshell em servidor IIS, reconhecimento interno, coleta de nomes de domínio, máquinas e credenciais administrativas, e geração de amostras customizadas do PyDCrypt para cada vítima. O PyDCrypt atua como componente de propagação e orquestração, enquanto o DCSrv executa a etapa destrutiva de criptografia de volumes e bloqueio do sistema por meio de driver e bootloader derivados do DiskCryptor.
A característica mais importante para defesa é que a campanha deixa rastros em várias camadas: servidor web, criação de processos, parâmetros de execução, escrita de arquivos em caminhos públicos, abertura de tráfego SMB e NetBIOS, criação de serviços Windows, instalação de driver em diretório do sistema e alterações de inicialização. Como a chave de criptografia pode ser passada por parâmetro de linha de comando em parte do fluxo, a retenção de eventos de EDR e logs de processo tem valor direto para resposta e possível recuperação.
O acesso inicial ocorre pela exploração de vulnerabilidades já conhecidas em ativos voltados para a internet. Após a entrada, o operador implanta um webshell no caminho C:\inetpub\wwwroot\aspnet_client\system_web\IISpool.aspx. O shell é protegido por senha e contém uma comparação com hash MD5 embutido; ele também é ofuscado e se baseia em código de webshell disponível publicamente. Para defesa, o ponto crítico não é a senha em si, mas a presença de script ASPX em diretório de IIS que normalmente não deveria receber lógica administrativa persistente nem execução remota pós-exploração.
Depois da primeira presença no ambiente, os operadores levantam informações internas e consolidam uma lista com domínio, nomes de máquinas e credenciais administrativas. Esses dados são incorporados a amostras do PyDCrypt, o que mostra que a operação não usa um binário genérico para todas as vítimas. Cada amostra pode conter parâmetros específicos do ambiente comprometido, incluindo identificadores de execução e material usado para acionar corretamente o payload de criptografia. Esse modelo aumenta a importância de coletar o binário intacto durante a resposta, porque a configuração embutida pode revelar escopo, máquinas previstas e chaves ou identificadores utilizados na execução.
O PyDCrypt é escrito em Python e empacotado com PyInstaller com criptografia aplicada na fase de build. Ele costuma ser executado a partir de C:\Users\Public\csrss.exe, um caminho anômalo porque csrss.exe legítimo não deve residir no diretório público de usuários. O componente espera argumentos específicos para prosseguir, incluindo um identificador observado como 113, um marcador de execução anterior e, opcionalmente, uma chave que será repassada ao DCSrv. Se os argumentos não correspondem ao esperado, o malware pode interromper o fluxo e remover a si mesmo, comportamento que dificulta análise superficial fora do ambiente previsto.
Durante a propagação, o PyDCrypt ajusta regras de firewall do Windows para permitir tráfego associado a SMB e NetBIOS, sem necessidade defensiva legítima aparente no contexto da execução. Em vez de publicar comandos operacionais, o ponto observável é a criação de regras de entrada para portas usadas por compartilhamento de arquivos e comunicação Windows. Em uma rede corporativa, esse evento deve ser tratado como suspeito quando parte de uma árvore de processo iniciada por binário em caminho público, webshell, conta administrativa recém-usada ou processo com nome de sistema fora do local esperado.
O DCSrv se mascara como svchost.exe e tem função concentrada: criptografar volumes e impedir acesso ao computador. Ele usa componentes do DiskCryptor, principalmente driver assinado e bootloaders customizados ou reaproveitados. A execução pode ser dividida em instalação de driver, criptografia de volumes e instalação de bootloader. O malware cria os serviços DCUMSrv e DCDrv; o primeiro sustenta persistência para relançar o executável com os parâmetros originais, e o segundo carrega o driver DCDrv.sys gravado em C:\windows\system32\drivers\DCDrv.sys. Como o driver é assinado, o bloqueio padrão de assinatura de driver do Windows não impede a instalação por si só.
Após instalar o driver, o malware força uma reinicialização depois de alguns minutos para tornar o componente operacional. Na execução seguinte, ele pode aguardar um horário exato definido na configuração antes de detonar a criptografia. Quando o horário configurado chega, o DCSrv percorre volumes de C: a Z: e inicia criptografia simultânea com múltiplas threads. A comunicação com o driver ocorre por chamadas IOCTL, usando códigos associados ao início e avanço da criptografia e parâmetros que incluem a chave recebida, o dispositivo-alvo e modo AES. O fluxo ainda prevê espera prolongada antes de nova reinicialização com bootloader, o que pode bloquear a máquina mesmo quando a criptografia integral não foi concluída.
A superfície mais exposta começa em serviços publicados na internet com vulnerabilidades conhecidas. O contexto não identifica produtos, CVEs ou versões específicas, portanto a conclusão defensiva deve se limitar ao padrão operacional: ativos externos não corrigidos são o ponto de entrada, e servidores IIS comprometidos podem servir como ponte para reconhecimento interno. A presença de webshell em árvore aspnet_client indica abuso de servidor web Windows e exige revisão de integridade de arquivos, permissões de escrita e histórico de requisições para o caminho afetado.
Dentro da rede, o risco se concentra em estáções e servidores Windows acessíveis com as credenciais administrativas coletadas. A campanha depende de nomes de máquinas, domínio e privilégios suficientes para copiar, executar e propagar componentes. Ambientes com compartilhamentos administrativos amplamente liberados, logging insuficiente de criação de processos, firewall permissivo para SMB/NetBIOS e EDR sem retenção de linha de comando perdem sinais essenciais para delimitar o escopo e investigar chaves usadas na criptografia.
- Servidores IIS com arquivos ASPX inesperados em
C:\inetpub\wwwroot\aspnet_client\system_web\ou diretórios equivalentes de conteúdo web. - Hosts Windows com binários chamados
csrss.exeousvchost.exeexecutados fora de diretórios legítimos do sistema. - Máquinas com criação recente dos serviços
DCUMSrveDCDrvou escrita do driverDCDrv.sysemC:\windows\system32\drivers\. - Segmentos internos onde regras de firewall foram alteradas para permitir tráfego de compartilhamento de arquivos e NetBIOS durante uma janela de incidente.
- Ambientes sem telemetria de argumentos de linha de comando, pois parte da recuperação pode depender de parâmetros capturados durante a execução do PyDCrypt ou DCSrv.
A investigação deve começar pelo ponto de entrada provável. Em servidores IIS, equipes devem revisar criação e modificação de arquivos ASPX, acessos HTTP anômalos, autenticações incomuns e processos filhos iniciados pelo worker process do servidor web. A presença do arquivo IISpool.aspx no caminho informado é um indicador direto, mas a caça não deve depender apenas desse nome; variações de webshell podem usar nomes diferentes dentro de diretórios com aparência legítima. Eventos de escrita em aspnet_client, requisições com parâmetros incomuns e execução de utilitários do sistema a partir do contexto do servidor web são sinais mais robustos.
No endpoint, a telemetria principal envolve árvores de processo que partem de caminhos públicos, nomes de binários que imitam processos do Windows e criação de serviços ligados ao DiskCryptor. C:\Users\Public\csrss.exe é altamente suspeito porque combina nome de processo sensível com local de escrita comum para abuso. svchost.exe fora do diretório esperado também deve ser tratado como desvio crítico. Em paralelo, a criação de DCUMSrv e DCDrv, a gravação de DCDrv.sys e a carga de driver recém-introduzido fornecem pontos de detecção antes ou durante a etapa destrutiva.
A rede deve ser analisada para alterações abruptas em comunicação SMB e NetBIOS entre máquinas que normalmente não se conectam dessa forma. O PyDCrypt tenta viabilizar replicação interna, portanto picos de conexão na porta 445 e portas relacionadas a NetBIOS, principalmente originados de hosts recém-comprometidos, podem indicar movimentação do componente de propagação. A detecção ganha precisão quando combinada com eventos de autenticação administrativa, cópia de arquivo para compartilhamentos administrativos e execução remota.
- Arquivo ASPX inesperado em diretórios de IIS, especialmente
IISpool.aspxou scripts ofuscados criados próximo ao início do incidente. - Processos
csrss.exeemC:\Users\Public\esvchost.exefora deC:\Windows\System32\ou caminhos equivalentes legítimos. - Criação dos serviços
DCUMSrveDCDrv, instalação deDCDrv.syse eventos de carga de driver assinado fora de mudança planejada. - Eventos de processo com parâmetros contendo identificadores de execução e chaves passadas ao DCSrv; preservar a linha de comando completa é prioridade forense.
- Alterações em regras locais de firewall para permitir tráfego SMB e NetBIOS em hosts que não passaram por manutenção autorizada.
- Reinicializações programadas ou inesperadas poucos minutos após criação de serviço, instalação de driver ou execução do payload.
- Varredura de volumes de
C:aZ:e atividade intensa de escrita associada a processo suspeito no período anterior ao bloqueio do host.
A resposta deve priorizar contenção antes da reinicialização de máquinas suspeitas. Como o DCSrv usa driver e bootloader para consolidar o bloqueio, desligamentos ou reinicializações não planejadas podem piorar a condição de recuperação. Hosts com sinais de PyDCrypt, DCSrv, serviços DCUMSrv ou DCDrv devem ser isolados da rede, preservando memória, binários, logs de processo, registros de serviço e artefatos de driver. A preservação da linha de comando é especialmente importante porque chaves e parâmetros usados pela cadeia podem estar registrados em telemetria de EDR.
Em servidores expostos, a mitigação passa por correção das vulnerabilidades conhecidas, remoção controlada de webshells, revisão de permissões de escrita, rotação de credenciais administrativas e investigação de todas as ações executadas a partir do contexto do IIS. Remover apenas o arquivo malicioso não encerra o incidente se credenciais já foram coletadas e incorporadas a amostras customizadas. A rotação deve abranger contas de domínio, contas locais reutilizadas e credenciais administrativas usadas em servidores ou estáções acessíveis a partir do ativo comprometido.
Para reduzir o risco recorrente, equipes devem restringir administração lateral, limitar SMB entre estáções, aplicar segmentação, bloquear execução a partir de diretórios públicos quando possível, registrar criação de processos com linha de comando completa e monitorar instalação de drivers e serviços. Controles de aplicação podem impedir binários empacotados e executáveis não autorizados em caminhos de usuário. Backups offline e testes de restauração continuam essenciais, mas a campanha mostra que recuperação também depende de telemetria: sem histórico de processo, a investigação perde detalhes que podem explicar o escopo da criptografia e os parâmetros usados pelo malware.
- Isolar hosts suspeitos sem reinicialização automática e preservar artefatos de memória, processo, serviço, driver e disco.
- Coletar cópias dos binários PyDCrypt e DCSrv antes de limpeza, mantendo cadeia de custódia e hashes internos para correlação defensiva.
- Remover webshells somente após registrar metadados, logs de acesso, horário de criação, conta proprietária e processos filhos associados ao servidor web.
- Corrigir vulnerabilidades dos ativos externos explorados e revisar exposição de serviços IIS e demais sistemas publicados na internet.
- Rotacionar credenciais administrativas coletadas ou potencialmente usadas na movimentação interna, incluindo contas locais compartilhadas.
- Bloquear ou alertar execução de
csrss.exe,svchost.exee nomes de sistema a partir de caminhos públicos ou diretórios temporários. - Monitorar criação de
DCUMSrv,DCDrv, gravação deDCDrv.syse alterações em bootloader como eventos de severidade alta. - Restringir tráfego SMB/NetBIOS entre estáções e exigir justificativa operacional para abertura local de portas de compartilhamento.
- Validar backups offline e executar restauração de amostras de sistemas críticos para confirmar que a recuperação não depende de hosts já comprometidos.
0 Comentários