VerdantBamboo usa variante BSD do BRICKSTORM contra appliances Linux

VerdantBamboo usa variante BSD do BRICKSTORM contra appliances Linux

Grupo de espionagem ligado à China combinou falha local, credenciais administrativas roubadas e implantes em appliances para acessar ambientes Microsoft 365 e persistir fora do alcance típico de EDR.

ComponenteEgnyte Storage Sync, pfSense firewall, Synology NAS e ambiente Microsoft 365 acessados por meio de BRICKSTORM, PLENET/GRIMBOLT e AGENTPSD.
VetorComprometimento inicial com exploração de falha local de elevação de privilégio no Storage Sync, seguido por uso de credenciais comprometidas, acesso via web SSL VPN e implantação de malware em appliances.
ImpactoPersistência em sistemas com pouca ou nenhuma cobertura de EDR, proxy de tráfego por appliance comprometido, execução remota de comandos, manipulação de arquivos e acesso ao Microsoft 365 com aparência de tráfego legítimo.
PrioridadeAtualizar Egnyte Storage Sync para a versão 13.13 ou posterior, revisar acessos web SSL VPN, investigar appliances sem EDR, rotacionar credenciais administrativas e validar acessos recentes ao Microsoft 365.
ArtefatosBRICKSTORM em variante BSD, PLENET também conhecido como GRIMBOLT, e AGENTPSD como reverse shell em Python.
VersõesA falha no Egnyte Storage Sync foi corrigida na versão 13.13, lançada em março de 2026.
Resumo técnico

Uma campanha atribuída ao cluster VerdantBamboo expôs uma operação de espionagem voltada a appliances Linux e sistemas que normalmente ficam fora da instrumentação completa de endpoint. A atividade incluiu uma variante BSD do backdoor BRICKSTORM, além das famílias PLENET, também conhecida como GRIMBOLT, e AGENTPSD. O caso foi identificado durante resposta a incidente em setembro de 2025, quando um sistema Egnyte Storage Sync de uma organização não nomeada apareceu comprometido após a exploração de uma falha local de elevação de privilégio. A correção para esse problema foi disponibilizada no Storage Sync 13.13, lançado em março de 2026.

O comportamento observado indica uma estratégia centrada em appliances de armazenamento, firewall, VPN e NAS para manter acesso persistente, reduzir exposição a ferramentas tradicionais de detecção e misturar tráfego malicioso a fluxos administrativos legítimos. O Storage Sync comprometido foi acessado periodicamente por endereços IP associados à web SSL VPN da vítima. Em seguida, o operador usou as capacidades de proxy do BRICKSTORM no appliance, junto com credenciais comprometidas, para acessar o ambiente Microsoft 365. Esse encadeamento sugere tentativa deliberada de contornar políticas de Conditional Access ao fazer com que sessões maliciosas parecessem originadas de caminhos já aceitos pela organização.

Fluxo técnico

A intrusão inicial conhecida envolveu o Egnyte Storage Sync e uma falha local de elevação de privilégio. O material analisado indica que a exploração permitiu ao operador implantar o BRICKSTORM no sistema comprometido. Não há detalhes técnicos suficientes para reproduzir a falha, e o impacto deve ser entendido no limite descrito: obtenção de privilégio local em um appliance já alcançado pelo adversário e uso desse privilégio para instalar um implante persistente. A presença do BRICKSTORM forneceu uma base operacional para proxy, acesso remoto e permanência dentro de uma superfície que tende a receber menos telemetria de endpoint do que servidores Windows ou estáções de trabalho convencionais.

Depois da primeira remediação, VerdantBamboo retornou ao mesmo ambiente por outro caminho. O grupo usou credenciais administrativas roubadas para se conectar ao firewall, configurou acesso web SSL VPN ao dispositivo, conectou-se a outros sistemas e implantou malware adicional em um appliance Synology NAS por SSH. A investigação também identificou comprometimento do provedor de serviços gerenciados da vítima, incluindo infecção de um firewall pfSense do MSP com uma variante BSD do BRICKSTORM em período próximo ao comprometimento do Storage Sync. Isso sustenta a hipótese de que a vítima tenha sido alcançada por meio da violação do MSP, o que amplia a superfície de análise para relações de confiança operacionais, administração remota e credenciais compartilhadas ou herdadas.

O conjunto de malware demonstra redundância e adaptação por plataforma. PLENET/GRIMBOLT é descrito como um backdoor multiplataforma desenvolvido em.NET Core e em nova versão compilada com native ahead-of-time, recurso que pode reduzir dependências no host e facilitar execução em ambientes específicos. Suas capacidades incluem shell interativo, execução remota de comandos, manipulação de arquivos e troca de servidor de comando e controle. AGENTPSD, por sua vez, é um reverse shell baseado em Python que provavelmente atua como alternativa caso o implante principal deixe de funcionar. O BRICKSTORM em variante BSD reforça o foco em appliances e sistemas derivados de Unix, incluindo firewalls e dispositivos de infraestrutura.

Superfície afetada

A superfície mais sensível não está limitada ao produto corrigido. O caso envolve Egnyte Storage Sync, firewall pfSense em MSP, web SSL VPN, Synology NAS e Microsoft 365. O denominador comum é a combinação de appliances com função privilegiada, acesso administrativo remoto e baixa cobertura de EDR. Em ambientes reais, esses ativos concentram confiança: terminam VPN, armazenam dados sincronizados, intermediam administração de rede, mantêm chaves ou sessões e servem como ponte para provedores externos. Quando um implante opera nesses pontos, o tráfego gerado pode herdar reputação interna e dificultar diferenciação entre operação administrativa legítima e sessão de espionagem.

O uso de um MSP comprometido é particularmente relevante porque desloca a análise de um incidente isolado para a cadeia operacional de administração. Uma credencial válida ou uma conexão de gerenciamento vinda de um provedor pode não acionar a mesma suspeita que um acesso externo inesperado. Também há um ponto de atenção em políticas de Conditional Access do Microsoft 365: se a decisão de acesso privilegia origem de rede, VPN ou padrões históricos sem validação forte de identidade, dispositivo e risco de sessão, um appliance usado como proxy pode ajudar o operador a parecer parte do fluxo normal.

  • Egnyte Storage Sync anterior à correção 13.13 quando exposto a cenário que permita exploração local e implantação de implante.
  • Firewalls pfSense e acessos web SSL VPN administrados diretamente pela organização ou por MSP.
  • Synology NAS com SSH acessível a contas administrativas ou a caminhos laterais pós-comprometimento.
  • Ambientes Microsoft 365 que aceitam sessões originadas de VPN ou infraestrutura interna sem sinais adicionais de confiança de dispositivo e identidade.
Hunting e telemetria

A busca deve começar pelos appliances, não apenas por endpoints gerenciados. Em Storage Sync, pfSense e NAS, operadores devem revisar binários recém-criados, serviços persistentes, tarefas de inicialização, scripts de manutenção alterados, nomes de implante incomuns e conexões de saída persistentes para poucos destinos recorrentes. O contexto indica disciplina operacional com quantidade limitada de domínios e endereços IP por vítima, além de nomes e mecanismos de persistência customizados por dispositivo. Portanto, ausência de indicadores públicos amplos não reduz o risco: a detecção depende mais de baseline local do que de lista estática de IoCs.

No Microsoft 365, a investigação deve correlacionar sessões com origem em web SSL VPN, appliances de armazenamento ou faixas usadas por administração remota. O ponto técnico crítico é a combinação de credenciais válidas com proxy no appliance comprometido. Sinais úteis incluem acessos em horários incomuns por contas administrativas, mudanças no padrão de dispositivo ou cliente, sessões que aparentam vir da rede corporativa mas não têm postura esperada de endpoint, atividades de leitura ou administração incompatíveis com o papel do usuário e sequência temporal entre login VPN, conexão ao appliance e atividade no tenant.

Em rede, a análise deve procurar túneis, conexões de longa duração, conexões de saída de appliances que normalmente não iniciam tráfego externo frequente e uso anômalo de SSH entre dispositivos internos. Para PLENET/GRIMBOLT, as capacidades descritas de shell interativo, execução remota, manipulação de arquivos e troca de C2 sugerem observar criação, leitura, modificação e transferência de arquivos em diretórios incomuns, além de processos.NET em hosts onde isso não é padrão. Para AGENTPSD, a presença de Python em appliance ou NAS deve ser validada contra uso administrativo legítimo, especialmente quando associada a conexão reversa.

  • Acessos periódicos ao Storage Sync por IPs vinculados à web SSL VPN da própria organização.
  • Configurações novas ou alteradas de web SSL VPN após uso de credenciais administrativas roubadas.
  • Conexões SSH para Synology NAS seguidas de criação de arquivos, serviços ou processos incomuns.
  • Sessões Microsoft 365 originadas de caminhos internos ou VPN, mas sem coerência com dispositivo, usuário, horário ou função.
  • Processos.NET ou Python em appliances onde essas execuções não fazem parte da operação normal.
Mitigação

A primeira medida é corrigir o Egnyte Storage Sync para a versão 13.13 ou posterior, porque essa versão contém a correção mencionada para a falha local explorada no caso. A atualização, porém, não encerra a resposta se houver possibilidade de comprometimento anterior. A atividade inicial teria ocorrido pelo menos 18 meses antes da descoberta, o que exige revisão histórica de logs, imagens de sistema, contas administrativas, chaves, tokens, regras de VPN e trilhas de acesso ao Microsoft 365. A remediação deve tratar appliance comprometido como ponto de persistência e não apenas como produto vulnerável.

Credenciais administrativas usadas em firewalls, NAS, MSP e Microsoft 365 devem ser rotacionadas após validação de escopo. A rotação precisa considerar contas humanas, contas de serviço, credenciais armazenadas em ferramentas de administração remota e acessos mantidos pelo MSP. Também é necessário revisar Conditional Access para reduzir dependência exclusiva de origem de rede. Controles mais robustos devem combinar identidade, MFA resistente a phishing quando disponível, postura de dispositivo, risco de sessão, localização coerente e restrições para contas privilegiadas.

Para contenção, appliances suspeitos devem ser isolados de forma planejada, com preservação de evidências antes de reinstalação ou substituição. Em dispositivos com pouca visibilidade, reinstalar firmware ou sistema a partir de mídia confiável pode ser mais eficaz do que tentar remover artefatos pontuais. A validação pós-remediação deve incluir monitoramento de tráfego de saída, revisão de persistência, comparação de configuração com backup confiável anterior ao incidente e busca por novo acesso via MSP. Como o caso envolve retorno do operador após remediação inicial, a eficácia da resposta depende de encerrar caminhos de identidade e administração, não apenas apagar o malware encontrado.

  • Aplicar Egnyte Storage Sync 13.13 ou posterior e revisar evidências de exploração anterior à atualização.
  • Auditar pfSense, web SSL VPN, Synology NAS e outros appliances sem EDR com baseline de arquivos, serviços, inicialização e conexões externas.
  • Rotacionar credenciais administrativas da organização e do MSP quando houver vínculo operacional com os ativos afetados.
  • Revisar políticas de Conditional Access do Microsoft 365 para impedir confiança excessiva em origem VPN ou rede interna.
  • Isolar e reconstruir appliances suspeitos a partir de fonte confiável, preservando logs e imagens necessários à investigação.

Postar um comentário

0 Comentários