A campanha de ransomware mirou principalmente empresas israelenses, publicou dados de vítimas que não pagaram e teve pagamentos em Bitcoin rastreados até uma infraestrutura associada à Excoino.
| Componente | Ransomware Pay2Key, notas de resgate, carteiras Bitcoin usadas para pagamento e site Onion de vazamento operado pelos extorsionários. |
| Vetor | Execução do Pay2Key em redes corporativas já acessadas pelos operadores; o vetor inicial de intrusão não foi detalhado, mas a operação resultou em criptografia rápida de partes relevantes da rede. |
| Impacto | Criptografia de ativos internos, pressão por pagamento, ameaça de publicação de dados corporativos e vazamento de informações de pelo menos três empresas israelenses que não pagaram. |
| Prioridade | Isolar rapidamente sistemas afetados, preservar evidências de nota de resgate e carteiras, investigar exfiltração, revisar backups e monitorar qualquer exposição em infraestrutura Onion relacionada à campanha. |
| Artefatos | Carteiras Bitcoin em notas de resgate, carteira intermediária reutilizada em pagamentos de múltiplas vítimas, cluster de alta atividade associado a entidade financeira e identificador de cluster 00045af14c no WalletExplorer. |
| Atribuição | O fluxo financeiro e o foco em organizações israelenses sustentam a hipótese de operador baseado no Irã, mas a atribuição permanece condicionada aos elementos observados na cadeia de pagamento e no perfil de vítimas. |
A campanha Pay2Key evoluiu de uma onda de criptografia corporativa para um caso de extorsão dupla com vazamento seletivo de dados. O ransomware foi observado em ataques contra empresas principalmente israelenses, com um relato adicional indicando pelo menos uma vítima na Europa. Depois da execução dentro dos ambientes comprometidos, o Pay2Key criptografava partes significativas da rede e deixava uma nota de resgate com ameaça de publicação de informações corporativas caso a negociação não avançasse. A operação, portanto, não se limitava à indisponibilidade causada pela criptografia: os operadores também buscavam aumentar a pressão sobre áreas jurídicas, financeiras e executivas por meio de exposição pública de dados.
A fase de vazamento foi materializada em um site Onion criado para publicar conteúdo de vítimas que não pagaram. Até o momento descrito, três empresas israelenses apareciam como vítimas de não pagamento, cada uma com uma pasta dedicada e mensagens personalizadas. As mensagens incluíam informações sensíveis sobre ativos digitais, como domínio, servidores e backups, além de referências a volumes expressivos de dados supostamente obtidos pelos operadores. Em um caso envolvendo uma empresa de desenvolvimento de jogos, os operadores publicaram inicialmente uma árvore de arquivos de servidores NAS e, depois, uma pasta relacionada a finanças. Em outro caso, envolvendo um escritório de advocacia, o vazamento ocorreu de forma mais direta após o prazo definido pelos extorsionários.
O acompanhamento de pagamentos em Bitcoin criou uma trilha de inteligência financeira. Pelo menos quatro vítimas efetuaram pagamentos, permitindo observar o fluxo entre as carteiras citadas nas notas de resgate, uma carteira intermediária reutilizada e uma carteira final associada a um cluster de alta atividade. A análise desse cluster indicou relação com uma entidade financeira ligada ao mercado de Bitcoin e, por correlação com uma carteira conhecida, apontou para a exchange iraniana Excoino. Esse dado não prova sozinho a identidade civil dos operadores, mas fortalece a hipótese de que a operação tenha vínculos com indivíduos baseados no Irã, especialmente quando combinado ao foco recorrente contra organizações israelenses.
O fluxo operacional conhecido começa após os operadores obterem capacidade de executar o ransomware dentro do ambiente da vítima. O material disponível não descreve o vetor inicial, credenciais usadas, exploração de vulnerabilidade, phishing ou movimento lateral específico; por isso, a análise defensiva deve separar claramente a fase comprovada da fase desconhecida. O que está documentado é que o Pay2Key se espalhava rapidamente pela rede comprometida, criptografava partes relevantes do ambiente e deixava uma nota de resgate. Essa nota era o ponto de convergência entre a operação técnica e a negociação financeira, pois continha a ameaça de vazamento e a carteira Bitcoin atribuída à vítima.
A extorsão dupla acrescentava uma camada de coerção. Em vez de depender apenas da perda de disponibilidade, os operadores criaram um mecanismo de exposição controlada: uma área Onion com diretórios por vítima, mensagens individualizadas e amostras ou estruturas de dados destinadas a demonstrar acesso a material interno. A publicação de uma árvore de arquivos de servidores NAS, antes do vazamento de conteúdo financeiro, indica uso de prova incremental para pressionar a vítima sem liberar todo o acervo de uma vez. No caso do escritório de advocacia, a exposição imediata de conteúdo sensível após o prazo reforça que a ameaça de vazamento era parte efetiva da campanha, e não apenas linguagem de negociação.
A cadeia de pagamento observada seguia uma sequência consistente. As notas de resgate indicavam carteiras Bitcoin específicas; após o depósito, os fundos eram movidos para uma carteira intermediária, vista em pagamentos de várias vítimas, e depois para uma carteira final associada a um cluster de alta atividade. Clusters desse tipo frequentemente aparecem quando há consolidação por entidades que processam muitas transações, como serviços financeiros ou exchanges. A correlação com uma carteira conhecida da Excoino e o compartilhamento do cluster 00045af14c no WalletExplorer sustentaram a ligação entre o destino final e a exchange iraniana. Como a Excoino exige número de telefone iraniano, código nacional e, para negociação, cópia de documento, a trilha sugere que os controladores finais dos fundos podem ter relação com cidadãos iranianos ou contas abertas sob documentação iraniana.
A inferência de atribuição deve ser tratada com cuidado operacional. A concentração em vítimas israelenses e a convergência financeira para uma exchange iraniana são sinais relevantes, mas não substituem evidências de infraestrutura de intrusão, artefatos de malware, chaves, servidores de comando, logs de operador ou sobreposição técnica com campanhas anteriores. Para equipes de inteligência, o valor principal está em transformar a cadeia de pagamento, o padrão de pressão por vazamento e os ativos expostos no site Onion em hipóteses verificáveis, sem assumir que toda transação posterior representa diretamente o operador do ransomware.
A superfície de risco inclui organizações com redes Windows ou ambientes corporativos capazes de permitir execução distribuída do ransomware, armazenamento centralizado e ativos de backup acessíveis aos operadores. O conteúdo disponível cita domínio, servidores, backups e NAS como elementos mencionados ou expostos pelos extorsionários. Isso mostra que a operação procurava ativos de alto valor para continuidade do negócio e para pressão reputacional. Mesmo sem detalhes sobre credenciais ou exploração inicial, a presença de informações sobre backups nas mensagens dos operadores é relevante: em incidentes de ransomware, a capacidade de restaurar sistemas depende tanto da integridade técnica do backup quanto de seu isolamento em relação ao ambiente comprometido.
Os setores atingidos no material incluem pelo menos uma empresa de desenvolvimento de jogos e um escritório de advocacia, ambos em Israel, além de outras empresas israelenses não nomeadas. O perfil é consistente com alvos que mantêm dados sensíveis, propriedade intelectual, documentação financeira, comunicações comerciais e material de clientes. A menção a uma vítima europeia amplia a hipótese de alcance além de Israel, mas o foco predominante descrito permanece em entidades israelenses. Para triagem interna, a localização geográfica sozinha não deve ser usada como critério de exclusão: organizações que observem notas Pay2Key, padrões de carteira semelhantes ou exposição em infraestrutura Onion devem tratar o caso como incidente ativo de ransomware.
A exposição não se restringe a servidores criptografados. Diretórios de NAS, pastas financeiras, inventários de domínio, informações de servidores e dados de backup podem revelar arquitetura interna, nomes de sistemas, caminhos de compartilhamento e prioridades operacionais. Mesmo quando o conteúdo publicado é parcial, ele pode ajudar terceiros a entenderem a organização, identificar fornecedores, mapear superfícies de ataque e preparar abordagens de fraude ou engenharia social. Por isso, a resposta precisa integrar DFIR, jurídico, privacidade, comunicação e inteligência de ameaças desde as primeiras horas.
- Empresas israelenses foram o foco principal descrito, com pelo menos um relato de vítima na Europa.
- Três organizações israelenses que não pagaram tiveram dados ou estruturas de dados publicados em site Onion.
- Pelo menos quatro vítimas pagaram resgate, permitindo análise do fluxo financeiro em Bitcoin.
- Ativos citados nas mensagens dos operadores incluíam domínio, servidores, backups, NAS e conteúdo financeiro.
- O vetor inicial de acesso não foi especificado; qualquer conclusão sobre phishing, exploração de vulnerabilidade ou credencial roubada ficaria sem sustentação.
A investigação interna deve começar pela preservação dos artefatos que conectam criptografia, extorsão e pagamento. A nota de resgate precisa ser coletada com metadados de caminho, horário, host e usuário associado, porque pode conter a carteira Bitcoin usada como marcador da vítima. A partir dessa carteira, equipes de inteligência financeira podem correlacionar movimentações posteriores com carteiras intermediárias reutilizadas e clusters de alta atividade. Essa análise não exige publicação de endereços para a equipe inteira: basta manter os indicadores em repositório controlado, com acesso restrito, para preservar cadeia de custódia e reduzir o risco de erro em comunicações externas.
Nos endpoints e servidores, a telemetria deve priorizar sinais de execução em massa, criação simultânea de notas de resgate, alterações abruptas em extensões ou entropia de arquivos, erros de acesso em compartilhamentos, varredura de diretórios e tentativa de tocar repositórios de backup. Como o material não descreve o binário, nomes de processo, extensão usada ou mecanismo de persistência, o hunting não deve depender de uma assinatura única. A abordagem mais útil é comportamental: identificar o primeiro host com criptografia, reconstruir sessões administrativas recentes, levantar conexões laterais, revisar autenticações privilegiadas e verificar se compartilhamentos NAS e servidores de backup foram acessados antes da criptografia.
A dimensão de extorsão exige outra frente de monitoramento. O site Onion usado para vazamento não deve ser acessado indiscriminadamente por usuários ou equipes sem procedimento, mas a organização pode manter coleta controlada por time autorizado para confirmar se houve publicação de amostras, nomes de diretórios, mensagens personalizadas ou referência a volume de dados. Qualquer evidência de árvore de arquivos, pasta financeira ou descrição de ativos internos deve ser tratada como indício de exfiltração ou, no mínimo, de acesso a metadados sensíveis. A ausência de publicação imediata não elimina risco, já que os operadores demonstraram uso de vazamento gradual para aumentar pressão.
- Notas de resgate com carteiras Bitcoin únicas por vítima e mensagens de ameaça de vazamento.
- Movimentação de fundos da carteira da nota para carteira intermediária reutilizada e, depois, para cluster de alta atividade.
- Criação ou modificação em massa de arquivos em múltiplos servidores e compartilhamentos de rede.
- Acesso incomum a NAS, pastas financeiras, diretórios jurídicos, backups e servidores de domínio antes ou durante a criptografia.
- Publicação em site Onion de diretórios por vítima, árvores de arquivos, mensagens personalizadas e referências a centenas de gigabytes de dados.
A resposta deve tratar Pay2Key como incidente combinado de ransomware e possível exposição de dados. A primeira ação defensiva é conter a propagação: isolar hosts com criptografia ativa, bloquear contas administrativas suspeitas, preservar controladores de domínio e impedir que sistemas de backup sejam montados ou alterados pelo ambiente comprometido. Em paralelo, é necessário coletar notas de resgate, amostras de arquivos afetados, logs de autenticação, registros de acesso a compartilhamentos e eventos de criação de processos. A restauração só deve começar após validação de que o mecanismo de execução e as credenciais abusadas foram contidos; restaurar cedo demais pode recriar a mesma superfície para nova criptografia.
A análise de exposição deve ser formal. Como os operadores publicaram conteúdo de vítimas que não pagaram e mencionaram ativos internos, a organização precisa identificar quais repositórios foram acessados, quais dados estavam presentes e se houve transferência externa observável. Quando houver indício de vazamento, a resposta deve mapear tipos de dados, titulares afetados, contratos, obrigações regulatórias e impacto para clientes, sem divulgar valores sensíveis ou artefatos brutos. A comunicação deve evitar afirmar ausência de exfiltração apenas porque não há confirmação inicial; no modelo de extorsão dupla, metadados e amostras podem aparecer depois como forma de pressão.
A mitigação de longo prazo depende de reduzir a capacidade de execução distribuída e a utilidade dos dados roubados. Contas privilegiadas devem ser revisadas, credenciais expostas devem ser rotacionadas, backups precisam ser testados em restauração offline e acessos a NAS devem ser segmentados por necessidade real. Controles de endpoint com detecção comportamental para criptografia em massa e tentativa de afetar backups são úteis, mas precisam ser acompanhados de telemetria centralizada e resposta rápida. Para inteligência de ameaças, carteiras Bitcoin, padrões de mensagem, estrutura do site Onion e correlação com clusters financeiros devem alimentar casos de monitoramento, não listas públicas amplas de indicadores.
A hipótese de operador baseado no Irã muda a prioridade de inteligência, mas não altera o núcleo da resposta técnica. Organizações com presença em Israel, relações comerciais sensíveis ou dados jurídicos e financeiros devem revisar exposição de backups, segmentação, autenticação privilegiada e capacidade de contenção. Equipes que já receberam nota Pay2Key devem evitar qualquer interação improvisada com extorsionários, preservar evidências e coordenar resposta por canais jurídicos e técnicos autorizados. A decisão sobre pagamento envolve risco legal, operacional e financeiro; tecnicamente, o pagamento observado em outras vítimas não impediu que a campanha continuasse, e a existência de um site de vazamento mostra que a pressão pública fazia parte central do modelo de operação.
- Isolar hosts afetados e sistemas com sinais de criptografia antes de iniciar restauração.
- Preservar notas de resgate, carteiras Bitcoin, horários de criação de arquivos, logs de autenticação e acessos a compartilhamentos.
- Verificar NAS, servidores financeiros, ambientes jurídicos, controladores de domínio e plataformas de backup para acesso incomum.
- Rotacionar credenciais privilegiadas e revisar sessões administrativas usadas antes da criptografia.
- Validar restauração de backups offline e confirmar que os repositórios não foram acessados ou alterados pelos operadores.
- Monitorar exposição controlada em infraestrutura Onion apenas por equipe autorizada e com procedimento de evidência.
- Correlacionar carteiras e clusters financeiros em ambiente restrito de inteligência, sem publicar indicadores ativos desnecessários.
0 Comentários