Magnet Goblin usa vulnerabilidades de um dia para comprometer servidores expostos

Magnet Goblin usa vulnerabilidades de um dia para comprometer servidores expostos

Campanhas associadas ao grupo financeiro combinam exploração rápida de serviços públicos, backdoors Linux da família Nerbian, roubo de credenciais VPN e ferramentas RMM em ambientes Ivanti, Magento, Qlik Sense e possivelmente ActiveMQ.

ComponenteServidores e dispositivos expostos à internet, incluindo Ivanti Connect Secure VPN, Magento, Qlik Sense e possivelmente Apache ActiveMQ, com implantação de NerbianRAT, MiniNerbian, WARPWIRE, Ligolo, ScreenConnect e AnyDesk.
VetorAdoção rápida de vulnerabilidades de um dia após divulgação pública ou disponibilidade de prova de conceito, seguida por download de payloads a partir de infraestrutura controlada pelo operador ou servidores Magento comprometidos.
ImpactoExecução de backdoors Linux, roubo de credenciais VPN via WARPWIRE, comunicação C2 por sockets TCP ou HTTP, tunelamento e uso de ferramentas RMM para manter acesso e ampliar controle operacional.
PrioridadeInventariar serviços de borda expostos, corrigir Ivanti Connect Secure e demais plataformas afetadas, buscar artefatos Nerbian em Linux, revisar credenciais VPN e bloquear infraestrutura defangada associada às campanhas.
ArtefatosA família Nerbian inclui NerbianRAT, com variantes Windows e Linux, e MiniNerbian, uma backdoor Linux menor voltada principalmente à execução de comandos.
IoCsExemplos defangados citados no contexto incluem 172.86.66[.]165, 94.156.71[.]115, 23.184.48[.]132, miltonhouse[.]nl, biondocenere[.]com, who-international[.]com e fernandestechnical[.]com.
Resumo técnico

Magnet Goblin é descrito como um ator financeiramente motivado que concentra parte de sua atividade em servidores e appliances publicamente acessíveis. A característica operacional mais relevante é a velocidade com que o grupo incorpora vulnerabilidades recém-divulgadas, chamadas de falhas de um dia, ao fluxo de intrusão. Em vez de depender apenas de phishing ou credenciais previamente obtidas, o operador aproveita a janela entre a publicação de uma correção, a exposição de detalhes técnicos e a aplicação efetiva de patches por organizações que mantêm serviços de borda conectados à internet.

A atividade recente associada ao grupo envolve exploração de Ivanti Connect Secure VPN e implantação de uma variante Linux de NerbianRAT. O mesmo conjunto operacional também aparece ligado historicamente a Magento, Qlik Sense e, com menor grau de confirmação, Apache ActiveMQ. Essa combinação indica uma estratégia voltada a ativos com alta exposição, grande valor para movimentação inicial e, em muitos casos, menor cobertura de EDR tradicional, especialmente quando o alvo é um appliance ou servidor Linux tratado como infraestrutura estável e não como endpoint monitorado em detalhe.

O conjunto de ferramentas observado vai além de uma única backdoor. A cadeia inclui NerbianRAT para Linux, MiniNerbian como backdoor menor, uma variante de WARPWIRE para coleta de credenciais VPN, Ligolo para tunelamento e ferramentas RMM legítimas abusadas, como ScreenConnect e AnyDesk, em ambientes Windows. O uso dessas peças sugere uma operação modular: primeiro, a exploração de serviço exposto; depois, coleta de credenciais, estabelecimento de canal de controle, tunelamento e eventual uso de software administrativo para manter presença ou facilitar acesso interativo.

Fluxo técnico

Nas intrusões envolvendo Ivanti Connect Secure, a exploração das falhas divulgadas em janeiro de 2024 levou ao download de payloads de infraestrutura controlada pelo operador. O contexto associa essa fase a CVE-2023-46805 e a uma segunda falha citada no material com identificadores relacionados a CVE-2023-21887 e CVE-2024-21887, exigindo que a validação defensiva seja feita contra os avisos oficiais e o inventário local de correções. Em ao menos um trecho, a incorporação de uma exploração atribuída a CVE-2024-21887 teria ocorrido em até um dia após a publicação de uma prova de conceito, o que reforça a importância de reduzir drasticamente o tempo entre divulgação e mitigação em serviços de borda.

Após o comprometimento, uma variante Linux de NerbianRAT foi implantada e passou a se comunicar com o endereço defangado 172.86.66[.]165. A variante Linux carrega configuração do arquivo tmp/debconf.socket, usa AES com chave embutida e vetor de inicialização composto por bytes nulos para proteger a configuração, e contém parâmetros que controlam janelas de atividade, frequência de comunicação e seleção de host primário ou secundário. Essa configuração permite ao operador modular o comportamento da backdoor sem expor todo o fluxo em parâmetros visíveis na linha de comando.

A variante Linux difere da versão Windows por usar sockets TCP brutos e um protocolo próprio baseado em estruturas binárias para troca de dados com o C2. A criptografia principal do canal é AES, com possibilidade de uso de RSA dependendo do tipo de dado transmitido. O binário também realiza verificação de duplicidade por segmentos de memória compartilhada e faz fork após essa checagem, um comportamento que pode aparecer em telemetria de processos Linux. O contexto indica que o binário foi compilado com informações DWARF, incluindo nomes de funções e variáveis globais, o que reduz a sofisticação anti-análise, mas não elimina o risco operacional quando a execução ocorre em servidores pouco monitorados.

MiniNerbian representa uma versão menor da família, mas não apenas uma remoção de módulos de NerbianRAT. O código compartilha bibliotecas de criptografia e rotinas de descriptografia de strings, porém tem foco principal em execução de comandos. Sua configuração contém poucos campos, incluindo intervalo entre requisições, janela de atividade e C2 usado. Ao contrário de NerbianRAT, que usa sockets brutos, MiniNerbian se comunica por HTTP e envia dados para um endpoint /dashboard/, detalhe útil para caça em logs de proxy, inspeção de tráfego e registros de servidores intermediários.

Superfície afetada

A superfície de maior risco é formada por servidores e appliances de borda que aceitam conexões diretas da internet e que receberam correções tardiamente. Ivanti Connect Secure aparece como alvo recente, enquanto Magento surge tanto como alvo de exploração anterior quanto como infraestrutura comprometida reutilizada para C2 ou distribuição de ferramentas. Qlik Sense aparece associado ao download de RMMs e ferramentas semelhantes, enquanto Apache ActiveMQ é citado como alvo provável a partir de um arquivo XML compatível com formato usado em exploração remota do produto.

O padrão mais importante para defesa não é apenas a lista de produtos, mas o tipo de ativo: sistemas publicados, com alto privilégio na rede, frequentemente excluídos de cobertura de endpoint e com janelas de manutenção mais lentas. VPNs, painéis de BI, plataformas de e-commerce e brokers de mensagem costumam ter acesso a credenciais, sessões, integrações internas ou rotas privilegiadas. Quando um ator instala uma backdoor nesse ponto, o impacto pode incluir persistência, roubo de credenciais, tunelamento, controle remoto e preparação para etapas posteriores, mesmo quando não há confirmação de vazamento de dados ou ransomware em um caso específico.

O uso de servidores Magento comprometidos como infraestrutura operacional merece atenção adicional. O contexto cita domínios defangados como miltonhouse[.]nl, biondocenere[.]com e fernandestechnical[.]com em papéis ligados a recebimento de credenciais, implantação de ferramentas ou C2. Para equipes que operam Magento, o risco não se limita ao próprio ambiente de e-commerce: um servidor comprometido pode ser convertido em nó de apoio para outras campanhas, confundindo atribuição, reputação de tráfego e resposta a incidentes.

  • Ivanti Connect Secure VPN exposto e não corrigido durante a janela posterior à divulgação das falhas de janeiro de 2024.
  • Servidores Magento comprometidos usados como alvo inicial, ponto de distribuição ou infraestrutura C2 em campanhas da família Nerbian.
  • Ambientes Qlik Sense associados ao download de ScreenConnect, AnyDesk e ferramentas similares a partir de infraestrutura controlada pelo operador.
  • Possível exposição de Apache ActiveMQ inferida por artefatos XML compatíveis com exploração remota observados em servidor associado à infraestrutura Nerbian.
Hunting e telemetria

A caça deve começar por inventário e linha do tempo. Equipes de segurança precisam correlacionar datas de divulgação, aplicação de correções, reinicializações, alterações de configuração e picos de requisições incomuns contra serviços de borda. Em Ivanti, a prioridade é revisar logs de autenticação, chamadas administrativas, artefatos web, processos gerados pelo appliance e conexões de saída para infraestrutura não reconhecida. Em Magento, a análise deve incluir diretórios públicos de mídia, arquivos recém-criados, scripts inesperados, processos executados pelo usuário do serviço web e comunicação HTTP ou TCP para hosts externos sem relação com a operação do site.

Em hosts Linux, sinais relevantes incluem binários ELF recém-gravados em diretórios temporários ou públicos, processos persistentes com diretório de trabalho em /tmp/, acesso ao arquivo tmp/debconf.socket, alocação de memória compartilhada por processo desconhecido e conexões TCP brutas para endereços externos. A presença de DWARF em um binário suspeito pode ajudar reversores a confirmar relação com a família Nerbian, mas a detecção operacional não deve depender disso. O comportamento de comunicação, a criação de arquivos e a origem do processo costumam ser mais úteis em ambientes de produção.

A variante de WARPWIRE citada no contexto envia credenciais VPN para um endpoint externo por requisições HTTP. Isso torna essencial revisar logs de saída de appliances e servidores comprometidos para POSTs anômalos, especialmente quando o destino é um domínio de e-commerce ou caminho PHP sem relação com a função do ativo. O endereço defangado hxxps://www.miltonhouse[.]nl/pub/opt/processor.php é um exemplo pontual, mas a defesa deve procurar o padrão: coleta de credenciais seguida de envio discreto para infraestrutura aparentemente legítima, muitas vezes hospedada em site previamente comprometido.

Em Windows, a telemetria deve cobrir instalação ou execução de ScreenConnect e AnyDesk sem ticket, mudança planejada ou proprietário interno. O uso de RMM legítimo reduz a eficácia de bloqueios simples por nome de produto; por isso, a validação deve considerar origem do instalador, servidor de controle, conta que iniciou o processo, linha do tempo com exploração prévia e conexões para endereços como 94.156.71[.]115 e 23.184.48[.]132, sempre tratados de forma defangada em relatórios e regras internas.

  • Conexões de saída para 172.86.66[.]165 a partir de servidores Linux, appliances VPN ou hosts que não deveriam iniciar sessões externas persistentes.
  • Criação ou leitura de tmp/debconf.socket e execução de ELF desconhecido com diretório de trabalho em /tmp/.
  • Requisições HTTP POST para caminhos como /dashboard/ ou PHPs externos sem relação funcional com o serviço monitorado.
  • Download ou execução não autorizada de ScreenConnect, AnyDesk ou Ligolo em sequência próxima a exploração de serviço público.
  • Uso de domínios Magento comprometidos como destino de C2, recebimento de credenciais ou estágio de payload.
Mitigação

A resposta deve priorizar ativos de borda antes de endpoints convencionais. O primeiro passo é confirmar a exposição e o nível de correção de Ivanti Connect Secure, Magento, Qlik Sense e ActiveMQ quando esses produtos existirem no ambiente. Em sistemas corrigidos tardiamente, a aplicação de patch não deve encerrar a investigação: é necessário assumir que a janela vulnerável pode ter sido explorada e procurar artefatos de pós-exploração, credenciais coletadas, tarefas persistentes, binários desconhecidos e conexões externas recorrentes.

Para Ivanti e outros serviços de autenticação, a rotação de credenciais deve ser considerada quando houver indício de WARPWIRE ou tráfego de coleta. Isso inclui contas VPN, contas administrativas, segredos de integração e sessões persistentes. A revisão também deve contemplar logs de acesso e uso posterior das credenciais em horários incomuns, a partir de origens novas ou com sequência incompatível com o padrão do usuário. Como o contexto mostra uso de credenciais e RMMs, a contenção precisa cobrir identidade, endpoint e rede ao mesmo tempo.

Em servidores Linux, equipes devem isolar hosts com sinais de Nerbian, preservar imagem ou artefatos relevantes, coletar binários suspeitos para análise interna, revisar crontabs, serviços, scripts web e diretórios graváveis pelo usuário da aplicação. Bloqueios de saída devem limitar comunicação direta de servidores de borda para a internet, principalmente quando não houver necessidade operacional. Em redes onde appliances não podem receber EDR completo, telemetria de proxy, NetFlow, DNS, firewall e logs administrativos precisa compensar a falta de visibilidade local.

Em ambientes Windows, ferramentas RMM devem ser controladas por política explícita. ScreenConnect e AnyDesk só devem ser permitidos quando instalados por canais aprovados, com servidor de controle conhecido, inventário registrado e dono operacional definido. Execuções fora desse padrão precisam gerar alerta de alta prioridade, especialmente quando aparecem após exploração de Qlik Sense, Magento ou outro serviço público. Como há uma possível correlação pública com intrusões de Cactus Ransomware, mas sem verificação conclusiva no material analisado, a resposta deve tratar o risco como cadeia pós-comprometimento potencial, sem afirmar ransomware como consequência confirmada.

  • Aplicar correções dos produtos expostos e validar se a correção ocorreu antes ou depois da janela de exploração observada.
  • Investigar hosts corrigidos tardiamente em busca de backdoors, web shells, credenciais coletadas e conexões C2, em vez de limitar a resposta ao patch.
  • Rotacionar credenciais VPN e administrativas quando houver qualquer sinal de WARPWIRE, requisições HTTP suspeitas ou acesso anômalo pós-exploração.
  • Restringir tráfego de saída de appliances e servidores de borda para destinos estritamente necessários e monitorar exceções novas.
  • Permitir RMM apenas por política aprovada, bloqueando instaladores e sessões que não correspondam ao inventário corporativo.

Postar um comentário

0 Comentários