A operação observada contra uma franquia de serviços alimentícios no Sudeste Asiático combinou exfiltração para Wasabi, ferramentas de uso duplo, acesso remoto e desativação de defesa antes da criptografia.
| Componente | Ransomware Osiris, driver malicioso POORTRY, Rclone, buckets Wasabi, ferramentas Netscan, Netexec, MeshAgent e versão customizada do Rustdesk. |
| Vetor | Intrusão corporativa com uso de ferramentas de administração e acesso remoto, habilitação de RDP e ataque BYOVD para desativar soluções de segurança antes da implantação do ransomware. |
| Impacto | Exfiltração de dados sensíveis para armazenamento em nuvem, interrupção de serviços e processos, remoção de capacidade defensiva local e criptografia de arquivos com chave única por arquivo. |
| Prioridade | Revisar exposição de RDP, monitorar ferramentas de uso duplo, bloquear drivers suspeitos, validar cópias de backup fora do ambiente principal e investigar tráfego para buckets Wasabi. |
| Artefatos | POORTRY, KillAV, Rclone, Netscan, Netexec, MeshAgent, Rustdesk customizado e arquivo kaz.exe associado a uso anterior em intrusões envolvendo INC ransomware. |
| Atribuição | Os desenvolvedores do Osiris não foram identificados; há apenas indícios de possível relação operacional com ataques associados ao INC, sem confirmação de autoria. |
Uma nova família de ransomware chamada Osiris foi observada em uma intrusão contra um grande operador de franquias de serviços alimentícios no Sudeste Asiático em novembro de 2025. O caso combina elementos clássicos de extorsão moderna com um estágio técnico relevante: o uso do driver malicioso POORTRY em uma abordagem BYOVD para enfraquecer a proteção do endpoint antes da fase de criptografia. O incidente não deve ser confundido com a variante Osiris associada ao Locky em 2016; o material analisado descreve uma linhagem nova, sem similaridade indicada com aquela família antiga.
A cadeia teve exfiltração prévia de dados sensíveis por meio do Rclone para buckets Wasabi, seguida por preparação do ambiente, uso de ferramentas de uso duplo e execução do ransomware. O Osiris foi descrito como uma carga de criptografia efetiva, com esquema híbrido e chave única por arquivo. A amostra também oferece flexibilidade operacional: pode interromper serviços, encerrar processos, definir pastas e extensões de interesse e gravar nota de resgate. Esse conjunto de funções indica uma operação orientada a maximizar pressão sobre a vítima, combinando roubo de dados, degradação de defesas e impacto direto sobre disponibilidade.
A autoria permanece aberta. Não há confirmação sobre desenvolvedores, modelo de ransomware como serviço ou operador responsável. O vínculo mais concreto no contexto é a presença de pistas que aproximam a intrusão de ataques envolvendo INC ransomware, também conhecido como Warble. Essa hipótese se apoia em dois pontos: o envio de dados para buckets Wasabi e o uso de uma versão do Mimikatz com o mesmo nome de arquivo, kaz.exe, já visto em operações relacionadas ao INC. Isso sustenta correlação operacional, mas não prova que a mesma equipe desenvolveu ou controla o Osiris.
A atividade maliciosa começou com sinais de exfiltração antes da implantação do ransomware. O uso do Rclone para enviar dados a buckets Wasabi coloca a etapa de roubo de informação antes da criptografia, padrão comum em extorsão dupla. Para defesa, esse detalhe muda a ordem de investigação: a criptografia não é o início do incidente, mas um estágio final após reconhecimento, movimentação, coleta e transferência de dados. Logs de proxy, DNS, firewall, EDR e armazenamento em nuvem devem ser correlacionados para reconstruir o período anterior à execução do payload.
O operador usou Netscan, Netexec, MeshAgent e uma versão customizada do Rustdesk. Esses artefatos têm valor defensivo porque também aparecem em ambientes legítimos, o que exige análise por contexto e não apenas por nome de binário. Execução fora de diretórios esperados, uso por contas administrativas incomuns, criação de sessões remotas em horários anômalos, enumeração concentrada de sub-redes e conexões para destinos externos não aprovados são sinais mais úteis do que uma regra estática baseada apenas na presença dessas ferramentas.
O ponto mais sensível da cadeia é o uso do POORTRY. Em ataques BYOVD tradicionais, o invasor leva para o sistema um driver legítimo, porém vulnerável, e o explora para executar ações privilegiadas no núcleo do sistema operacional. Neste caso, o POORTRY é descrito como um driver malicioso feito para elevar privilégios e terminar ferramentas de segurança, o que o diferencia de um simples abuso de driver legítimo vulnerável. A presença adicional do KillAV reforça que a fase de pré-criptografia tinha como objetivo reduzir visibilidade e resistência defensiva.
Após a redução de controles, o Osiris encerra uma lista extensa de processos e serviços relacionados a Microsoft Office, Exchange, Mozilla Firefox, WordPad, Notepad, Volume Shadow Copy e Veeam, entre outros. O encerramento de serviços de backup, cópia de sombra e aplicativos em uso aumenta a probabilidade de criptografar arquivos sem bloqueio e dificulta recuperação local. A capacidade de escolher pastas e extensões também permite ao operador adaptar o impacto ao ambiente encontrado, priorizando dados de negócio, repositórios compartilhados e sistemas com maior valor operacional.
A superfície exposta inclui endpoints Windows capazes de carregar drivers, servidores com ferramentas de segurança que podem ser terminadas por um componente em modo núcleo, estáções com sessões administrativas e recursos de rede acessíveis por contas comprometidas. O contexto também menciona que RDP foi habilitado no ambiente, provavelmente para manter acesso remoto. Isso torna serviços de acesso remoto, contas privilegiadas e políticas de autenticação pontos centrais de contenção.
Ambientes com permissões amplas para execução de ferramentas portáteis, baixa restrição de drivers, ausência de allowlisting e monitoramento fraco de tráfego para provedores de armazenamento em nuvem ficam mais expostos. A intrusão também mostra risco em ambientes nos quais ferramentas legítimas de administração remota não têm inventário e proprietário definidos. Rustdesk, MeshAgent e utilitários de enumeração podem ser usados por equipes internas, mas a ausência de baseline torna difícil distinguir administração autorizada de preparação para extorsão.
O cenário mais amplo de ransomware em 2025 reforça a mesma direção técnica. Foram citados 4.737 ataques reivindicados em sites de vazamento durante 2025, ante 4.701 em 2024. Entre os grupos mais ativos aparecem Akira, Qilin, Play, INC, SafePay, RansomHub, DragonForce, Sinobi, Rhysida e CACTUS. O dado mostra estabilidade em volume, mas mudança constante em operadores, marcas, parcerias e métodos de intrusão.
- Endpoints e servidores nos quais drivers não confiáveis ou suspeitos possam ser carregados com privilégio elevado.
- Serviços RDP habilitados, especialmente quando expostos sem autenticação multifator e sem segmentação rígida.
- Contas administrativas usadas para execução de ferramentas de enumeração, acesso remoto e transferência de dados.
- Sistemas de backup, Volume Shadow Copy e plataformas como Veeam, que aparecem como alvos de interrupção antes da criptografia.
A investigação deve começar antes do horário de criptografia. O primeiro eixo é transferência de dados: execuções do Rclone, criação ou uso incomum de perfis de sincronização, tráfego de alto volume para armazenamento Wasabi e autenticações externas associadas a contas que normalmente não movimentam grandes volumes. Como o contexto aponta exfiltração para buckets Wasabi, a defesa deve buscar padrões de saída, não apenas arquivos criptografados ou notas de resgate.
O segundo eixo é preparação de acesso e reconhecimento. Netscan e Netexec devem gerar atenção quando aparecem em servidores que não fazem administração de rede, quando são lançados por contas de usuário sem função operacional ou quando há enumeração rápida de múltiplos segmentos. MeshAgent e Rustdesk customizado devem ser avaliados por caminho de instalação, assinatura, hash interno, persistência, serviço registrado, conexões de controle e divergência em relação ao pacote aprovado pela organização.
O terceiro eixo é ataque contra controles de segurança. Carregamento de driver fora de inventário, eventos de instalação de serviço em modo núcleo, falhas súbitas de EDR, interrupção de processos defensivos e execução de KillAV ou POORTRY são sinais de escalada crítica. Mesmo quando o sensor é encerrado, logs do Windows, telemetria de kernel, inventário de drivers, registros de serviço e alertas de tamper protection podem preservar rastros suficientes para delimitar o intervalo de comprometimento.
A telemetria de identidade também é essencial. O uso de uma versão do Mimikatz nomeada como kaz.exe indica tentativa ou capacidade de acesso a credenciais. A defesa deve revisar autenticações anômalas, logons administrativos em sequência, uso de RDP entre estáções, criação de contas locais, alteração de grupos privilegiados e acesso a compartilhamentos de arquivos fora do padrão normal da conta envolvida.
- Execução de Rclone seguida de tráfego volumoso para buckets Wasabi ou destinos de armazenamento em nuvem não aprovados.
- Carregamento ou tentativa de carregamento do driver POORTRY e eventos de encerramento de processos de segurança.
- Presença de KillAV,
kaz.exe, Netscan, Netexec, MeshAgent ou Rustdesk customizado em caminhos temporários ou administrativos incomuns. - Habilitação recente de RDP, novas regras de firewall para acesso remoto ou sessões RDP laterais entre sistemas internos.
- Interrupção de Volume Shadow Copy, Veeam, Exchange, Office e outros serviços imediatamente antes da criação de arquivos criptografados.
O contexto de 2025 também registra uso recorrente de BYOVD e ferramentas legítimas abusadas por diferentes famílias. Campanhas Akira exploraram driver vulnerável do Throttlestop e abusaram de componentes como Windows CardSpace User Interface Agent e Microsoft Media Foundation Protected Pipeline para sideload do Bumblebee em ataques de meados ao fim de 2025. Outras campanhas Akira usaram SonicWall SSL VPNs para entrar em ambientes de pequenas e médias empresas durante processos de fusão e aquisição, buscando alcançar empresas adquirentes maiores. Também foi descrito uso de iscas de verificação do tipo ClickFix para entregar o trojan de acesso remoto SectopRAT como ponte para controle remoto e ransomware.
LockBit manteve infraestrutura mesmo após operação policial no início de 2024 e, em outubro de 2025, apareceu em parceria com DragonForce e Qilin. As variantes LockBit 5.0 miram múltiplos sistemas operacionais e plataformas de virtualização, com modelo de implantação em dois estágios que separa carregador e payload principal. Esse desenho aumenta modularidade e pode ampliar evasão, porque artefatos observados em uma fase não necessariamente carregam toda a lógica destrutiva.
Sicarii surgiu no fim de 2025 como uma nova operação de ransomware como serviço, mas reivindicou apenas uma vítima no período descrito. O grupo se apresenta como israelense ou judaico, porém há indícios de atividade primária em russo e erros gramaticais e semânticos no conteúdo em hebraico, levantando hipótese de falsa bandeira. O operador principal usou a conta de Telegram @Skibcum para comunicação e promoção, afirmando foco em pequenas empresas e manutenção deliberada de perfil baixo.
Storm-2603, também referido como CL-CRI-1040 ou Gold Salem, foi observado usando a ferramenta legítima Velociraptor em atividade precursora à implantação de Warlock, LockBit e Babuk. A cadeia também recorreu aos drivers rsndispot.sys e kl.sys, além de vmtools.exe, para desabilitar soluções de segurança por BYOVD. Makop, por sua vez, mirou entidades na Índia, Brasil e Alemanha por meio de RDP exposto e inseguro, combinando varredura, escalada de privilégio, desativação de defesa, coleta de credenciais e implantação do ransomware. Nessa atividade apareceram hlpdrv.sys, ThrottleStop.sys e GuLoader, sendo este o primeiro caso documentado de distribuição do Makop por meio de loader.
Outros casos mostram variação no acesso inicial e no impacto. Algumas intrusões usaram credenciais RDP já comprometidas para reconhecimento, escalada, movimentação lateral via RDP, exfiltração para temp[.]sh no sexto dia e implantação do Lynx três dias depois. O Obscura apresentou falha no processo de criptografia que torna grandes arquivos irrecuperáveis, porque arquivos acima de 1 GB não recebem o rodapé necessário com a chave temporária criptografada. Já o 01flip, escrito em Rust, atingiu um conjunto limitado de vítimas na Ásia-Pacífico, com suporte a Windows e Linux e cadeias que exploraram vulnerabilidades conhecidas, incluindo CVE-2019-11580, para obter acesso inicial.
A resposta defensiva para um caso como Osiris deve priorizar contenção de acesso, preservação de evidência e validação de exfiltração. Isolar sistemas com sinais de Rclone, POORTRY, KillAV ou execução de ferramentas de acesso remoto suspeitas reduz a chance de nova criptografia, mas a análise precisa considerar que dados podem ter sido extraídos antes do impacto visível. Bloqueios de saída para armazenamento em nuvem não aprovado, revisão de logs de proxy e captura de artefatos de execução ajudam a dimensionar o incidente.
RDP deve ser tratado como superfície crítica. A exposição precisa ser reduzida por segmentação, VPN corporativa controlada, autenticação multifator e política de acesso por necessidade. Contas com uso administrativo devem ter sessões auditadas, privilégios mínimos e separação entre administração de endpoint, servidor e backup. Sempre que possível, ferramentas de acesso remoto devem ser padronizadas, assinadas, inventariadas e alertadas quando executadas fora do caminho aprovado.
Contra BYOVD, a organização deve combinar bloqueio de drivers vulneráveis ou não autorizados, proteção contra adulteração no EDR, regras de integridade de código e revisão periódica do inventário de drivers carregados. A mitigação também depende de backup fora do ambiente principal: cópias offline ou imutáveis, testes de restauração e segregação de credenciais de backup são controles centrais, porque o Osiris tenta interromper serviços ligados a cópia de sombra e Veeam antes de criptografar dados.
Depois da contenção, a validação deve procurar sinais de credenciais acessadas, incluindo uso de kaz.exe ou ferramentas equivalentes, logons administrativos incomuns e movimentação lateral por RDP. Senhas e chaves associadas a contas tocadas durante a janela de intrusão devem ser rotacionadas de forma ordenada. A recuperação deve considerar reconstrução limpa de sistemas críticos, restauração validada de backups e monitoramento reforçado de tráfego para serviços de armazenamento externo.
- Restringir RDP, exigir autenticação multifator e limitar acesso remoto por segmentação e grupos autorizados.
- Monitorar e bloquear drivers suspeitos, especialmente POORTRY e artefatos associados a KillAV ou desativação de segurança.
- Criar baseline para Rclone, Netscan, Netexec, MeshAgent e Rustdesk, alertando execução fora de proprietários e caminhos aprovados.
- Manter backups fora do ambiente principal, com cópias offline ou imutáveis e testes regulares de restauração.
- Revisar tráfego para Wasabi e outros provedores de armazenamento em nuvem quando houver sinais de compressão, enumeração ou transferência anômala de dados.
0 Comentários