Campanha de phishing usa `SimpleHelp` e `ScreenConnect` para manter acesso remoto persistente

Operação ativa desde pelo menos abril de 2025 atingiu mais de 80 organizações e instalou ferramentas RMM legítimas como canais redundantes de acesso interativo a estáções Windows comprometidas.

Componente	Clientes RMM legítimos SimpleHelp e ConnectWise ScreenConnect instalados em hosts Windows por meio de isca de phishing.
Vetor	E-mail que se passa pela Administração da Seguridade Social dos EUA instrui a vítima a verificar endereço de e-mail e baixar uma suposta declaração a partir de links externos.
Impacto	Acesso remoto persistente, execução silenciosa de comandos, transferência bidirecional de arquivos, leitura de tela, injeção de teclas e possível movimento lateral.
Prioridade	Investigar instalações não autorizadas de RMM, validar serviços persistentes em Windows, bloquear os domínios observados e revisar telemetria de privilégios e presença de usuário.
Versões	A campanha implantou SimpleHelp versão 5.0.1 empacotado em executável Windows com JWrapper.
Artefatos	Domínios observados: gruta[.]com.mx como site legítimo comprometido e server[.]cubatiendaalimentos[.]com.mx como domínio controlado por operador para entrega do executável.
Técnicas	Persistência como serviço Windows, persistência em Modo de Segurança, watchdog de reinício, consulta WMI em root\SecurityCenter2, aquisição de SeDebugPrivilege e uso de elev_win.exe para privilégio de nível SYSTEM.

Resumo técnico

Uma campanha de phishing rastreada como VENOMOUS#HELPER vem usando software legítimo de monitoramento e gerenciamento remoto como mecanismo de acesso inicial e persistência. A atividade é observada desde pelo menos abril de 2025 e já afetou mais de 80 organizações, com concentração maior em ambientes dos Estados Unidos. O ponto central da operação não é a exploração de uma vulnerabilidade pública específica, mas a instalação induzida de ferramentas RMM por usuários enganados por uma isca documental. Depois que o executável é aberto, o host passa a oferecer acesso remoto interativo ao operador, com capacidade de administração compatível com produtos usados por equipes legítimas de suporte técnico.

O fluxo técnico combina engenharia social, infraestrutura intermediária comprometida e binários que aparentam ter finalidade administrativa. A primeira ferramenta implantada é SimpleHelp, entregue como um executável Windows empacotado com JWrapper e apresentado como uma suposta declaração vinculada à Administração da Seguridade Social dos EUA. Depois da instalação, o operador usa o acesso elevado obtido pelo cliente remoto para baixar e instalar ConnectWise ScreenConnect, criando dois canais independentes de controle. Essa redundância aumenta a resiliência operacional: se um canal for bloqueado por proxy, EDR, equipe de resposta ou política de aplicação, o segundo ainda pode preservar acesso ao endpoint comprometido.

Fluxo técnico

A cadeia começa com um e-mail de phishing que instrui a vítima a verificar seu endereço de e-mail e baixar uma suposta declaração. O link inicial aponta para gruta[.]com.mx, um site empresarial mexicano legítimo que foi comprometido e usado como etapa intermediária. Esse uso de um domínio real reduz a chance de bloqueio por filtros que dependem apenas de reputação de domínio, idade do site ou heurísticas simples de spam. A carga indicada como documento é obtida em seguida a partir de server[.]cubatiendaalimentos[.]com.mx, domínio controlado pela operação. O contexto indica que o binário foi hospedado após acesso a uma conta única de usuário cPanel em um servidor legítimo de hospedagem, o que reforça o uso de infraestrutura mista entre ativos comprometidos e ativos controlados pelo operador.

Quando a vítima executa o arquivo, o SimpleHelp é instalado como serviço Windows e passa a manter persistência mesmo em Modo de Segurança. O executável inclui comportamento de autocorreção por watchdog, reiniciando o componente quando ele é encerrado. Também há enumeração periódica de produtos de segurança registrados por WMI no namespace root\SecurityCenter2 a cada 67 segundos e verificação de presença de usuário a cada 23 segundos. Esses intervalos indicam que o operador busca adaptar a sessão remota ao estado do endpoint: identificar controles instalados, observar se há interação humana ativa e manter a sessão pronta para operação manual.

Para obter acesso interativo completo à área de trabalho, o cliente remoto solicita SeDebugPrivilege por meio de AdjustTokenPrivileges. A cadeia também usa elev_win.exe, executável legítimo associado ao próprio software, para atingir privilégios de nível SYSTEM. Com esse nível de permissão, o operador consegue ler a tela, enviar teclas, acessar recursos disponíveis no contexto do usuário e executar ações administrativas locais. O segundo estágio instala ScreenConnect, criando um fallback de comunicação. Em um cenário de ransomware precursor ou corretagem de acesso inicial, esse modelo permite reconhecimento manual, coleta de arquivos, validação de privilégios, preparação de movimento lateral e transferência de acesso para outra equipe operacional.

Superfície afetada

A superfície primária são estáções Windows cujos usuários recebem e executam o arquivo apresentado como documento. O risco é maior quando a política de aplicação permite execução de binários baixados de navegadores ou clientes de e-mail, quando ferramentas RMM legítimas não são rigidamente inventariadas e quando serviços Windows recém-criados não geram alerta contextual. Como SimpleHelp e ScreenConnect têm uso administrativo legítimo, controles baseados apenas em reputação do fornecedor ou assinatura digital podem tratar a instalação como atividade benigna. A condição de exploração depende da interação do usuário com a isca e da ausência de bloqueios preventivos para executáveis não aprovados.

Organizações que já usam RMM em operação normal precisam separar instâncias autorizadas de instâncias impostas por atacante. Isso inclui validar servidores de gerenciamento configurados, caminhos de instalação, nomes de serviço, conta de execução, horário de criação, origem do instalador e associação com chamados de suporte legítimos. A presença simultânea de SimpleHelp versão 5.0.1 e ScreenConnect em uma estáção sem justificativa operacional deve ser tratada como indicador de comprometimento até prova contrária. O mesmo vale para instalações que aparecem após acesso a domínios externos incomuns, especialmente quando o usuário abriu arquivo baixado logo após e-mail com tema governamental ou financeiro.

• Endpoints Windows com novos serviços relacionados a SimpleHelp ou ScreenConnect sem aprovação formal de TI.
• Usuários que receberam e-mails sobre verificação de endereço ou suposta declaração da Administração da Seguridade Social dos EUA.
• Ambientes que permitem execução de arquivos baixados sem controle de reputação, sandbox, bloqueio por origem ou política de allowlist.
• Servidores e proxies que registraram acesso a gruta[.]com.mx seguido de download a partir de server[.]cubatiendaalimentos[.]com.mx.

Hunting e telemetria

A investigação deve começar pela linha do tempo do usuário e do endpoint. Procure eventos de navegação ou proxy para gruta[.]com.mx, seguidos por requisições a server[.]cubatiendaalimentos[.]com.mx e execução de arquivo Windows em diretórios de download, temporários ou perfil do usuário. No host, correlacione criação de serviço, instalação de software, eventos de elevação, criação de processos filhos e conexões de saída associadas aos clientes RMM. A consulta periódica ao namespace root\SecurityCenter2 é um bom ponto de caça porque revela enumeração de produtos de segurança logo após a instalação; esse comportamento deve ser cruzado com o processo chamador, usuário logado e horário de recebimento do e-mail.

A telemetria de identidade também é importante. Sessões RMM interativas podem resultar em ações no contexto do usuário, acesso a compartilhamentos, abertura de consoles administrativos e leitura de arquivos corporativos. Busque alterações de privilégio incomuns, uso de SeDebugPrivilege, execução de elev_win.exe, processos iniciados como SYSTEM a partir de diretórios associados ao RMM e transferência de arquivos para caminhos pouco usados. Em redes com EDR, a detecção deve diferenciar instalação legítima por equipe de suporte de instalação iniciada por usuário final sem chamado, sem ferramenta de distribuição corporativa e sem origem em repositório interno aprovado.

A presença de dois RMMs no mesmo endpoint aumenta a necessidade de hunting por continuidade de acesso. Mesmo que SimpleHelp seja removido, ScreenConnect pode permanecer ativo, com outro serviço, outro identificador de sessão e outro destino de rede. Por isso, a resposta não deve encerrar a investigação após a remoção do primeiro artefato visível. É necessário pesquisar instalações recentes de qualquer ferramenta de acesso remoto, validar conexões persistentes, revisar tarefas agendadas e analisar autenticações de rede feitas a partir da máquina comprometida durante a janela em que o operador teve controle interativo.

• Criação de serviços Windows relacionados a SimpleHelp ou ScreenConnect após execução de arquivo baixado pelo usuário.
• Chamadas WMI recorrentes para root\SecurityCenter2 em intervalos curtos, especialmente próximas à instalação do RMM.
• Uso de AdjustTokenPrivileges para obtenção de SeDebugPrivilege por processo ligado a cliente remoto.
• Execução de elev_win.exe e processos subsequentes com privilégio de nível SYSTEM.
• Conexões para gruta[.]com.mx e server[.]cubatiendaalimentos[.]com.mx na mesma linha do tempo de e-mail, download e execução.
• Instalação de dois canais RMM no mesmo host sem justificativa em inventário ou chamado de suporte.

Mitigação

A resposta deve priorizar contenção de acesso remoto e preservação de evidências. Isole endpoints com instalações não autorizadas de SimpleHelp ou ScreenConnect, colete artefatos de serviço, binários, logs de instalação, histórico de navegação, eventos de processo e conexões de rede antes de remover os componentes. Bloqueie os domínios observados em DNS, proxy e gateway seguro, mas trate o bloqueio como medida parcial, porque a infraestrutura pode mudar. Em seguida, revise todas as ferramentas RMM permitidas pela organização e mantenha uma lista explícita de produtos, servidores, versões, caminhos de instalação e grupos autorizados a iniciar sessões.

A correção operacional envolve restringir execução de binários baixados, exigir allowlist para ferramentas de administração remota e gerar alerta quando um usuário final instala software RMM fora do fluxo corporativo. Políticas de controle de aplicação devem bloquear instaladores desconhecidos em diretórios de usuário, enquanto EDR e SIEM devem correlacionar criação de serviço com eventos de e-mail e proxy. Para reduzir o impacto de uma sessão interativa, aplique privilégio mínimo em estáções, limite acesso a compartilhamentos por grupo, monitore transferência de arquivos e revise credenciais expostas no host, incluindo tokens de sessão, chaves de acesso, senhas salvas e material de navegador.

Depois da contenção, execute uma revisão de escopo. Verifique se o operador acessou outros sistemas a partir do endpoint, se houve transferência de arquivos, se ferramentas administrativas foram abertas e se credenciais foram usadas fora do padrão. Quando houver evidência de acesso interativo com privilégio elevado, a rotação de credenciais do usuário afetado e de contas administrativas usadas no host deve ocorrer após a remoção dos canais remotos e a invalidação de sessões. A validação final deve confirmar ausência de serviços remanescentes, ausência de novas ferramentas RMM, bloqueio dos indicadores conhecidos e melhoria de detecções para novas instalações do mesmo tipo.

• Isolar hosts com SimpleHelp ou ScreenConnect não autorizados e coletar artefatos antes da remoção.
• Bloquear gruta[.]com.mx e server[.]cubatiendaalimentos[.]com.mx em controles de DNS, proxy e inspeção de tráfego.
• Auditar inventário de RMM e permitir apenas servidores, versões e instaladores aprovados pela organização.
• Criar alerta para instalação de serviço Windows por executáveis originados de diretórios de download, temporários ou perfil de usuário.
• Pesquisar e remover canais RMM redundantes; não encerrar a resposta após encontrar apenas um cliente remoto.
• Rotacionar credenciais expostas no endpoint quando houver evidência de sessão interativa ou execução com privilégio elevado.