Em 19 de fevereiro de 2026, o nome da Woovi atravessou redes sociais e grupos de tecnologia. A empresa, que opera pagamentos e Pix, aparecia ligada a um incidente. No mesmo dia, o CEO publicou um posicionamento: o caso teria começado com um e-mail de domínio governamental e um PDF, descrito naquele momento como parte da exploração de uma vulnerabilidade zero-day.

À primeira vista, parecia um ataque sofisticado e isolado. A equipe de Cyber Threat Intelligence (CTI) do QuimeraX leu o caso de outro jeito.

O vetor batia com uma campanha de phishing que já circulava contra o setor financeiro brasileiro. As mensagens partiam de infraestrutura institucional realmente comprometida, sem o spoofing clássico. O PDF induzia a vítima a baixar um suposto “certificado digital”. Naquele momento, não havia evidência técnica de exploração de um zero-day.

Aquele caso público tornou o padrão visível. Mas não era o começo da história.

Ao longo do monitoramento, identificamos o mesmo padrão em diversas outras organizações do ecossistema financeiro e de serviços. Instituições de pagamento, fintechs, prestadores e organizações adjacentes apareceram no mesmo fluxo ao longo de 2026. Não as nomeamos aqui. Para o defensor, entender como a operação funciona é mais importante do que conhecer o inventário de vítimas.

O hunting que se seguiu, e o monitoramento que mantemos desde então, revelou uma operação mais antiga, mais persistente e mais industrializada do que aquele episódio sugeria. No QuimeraX, acompanhamos essa atividade como um cluster próprio, ao qual damos o nome de Shadow Ledger.

Por que Shadow Ledger e não PLUMP SPIDER?

Durante o monitoramento das campanhas, identificamos análises de outras equipes de segurança associando parte dessa atividade ao PLUMP SPIDER, outro grupo brasileiro conhecido por atuar contra o setor financeiro.

Nossa avaliação é diferente.

O QuimeraX trata o Shadow Ledger como um agrupamento distinto do PLUMP SPIDER. Essa separação não foi feita apenas com base em diferenças de modus operandi, infraestrutura ou TTPs.

Ao longo da investigação, correlacionamos informações sobre as duas operações que vão além da análise puramente técnica. Temos evidências, incluindo informações não públicas, sobre indivíduos envolvidos na operação desses grupos que sustentam nossa avaliação de que se tratam de atores distintos.

Por razões operacionais, não vamos detalhar neste post identidades, fontes ou outros elementos que possam expor a investigação. Ainda assim, temos confiança suficiente nessa avaliação para não tratar Shadow Ledger como um alias, braço ou cluster do PLUMP SPIDER.

Essa distinção importa porque semelhança de alvo, ferramenta ou técnica não significa necessariamente identidade entre operadores. No cibercrime brasileiro, diferentes grupos podem atacar o mesmo setor, reutilizar ferramentas semelhantes e até circular pelos mesmos ambientes. A atribuição precisa considerar o conjunto das evidências, não apenas aquilo que aparece no endpoint.

Ao longo de quase um ano de acompanhamento, vimos o que o grupo manteve, o que mudou e como ofícios, ClickFix e uma aplicação Electron trojanizada baseada no BoostNote passaram a fazer parte da mesma operação.

Como acompanhamos essa operação

A equipe de CTI do QuimeraX acompanha o Shadow Ledger com monitoramento de ameaças, análise de amostras, correlação de campanhas e, quando o padrão aparece num ambiente sob resposta, coleta a partir de Resposta a Incidentes. Também olhamos a superfície pública que o grupo abusa: sites .gov.br e .jus.br que passam a hospedar páginas de "documento", links de ofício e payloads.

O que interessa aqui é reconhecer um modus operandi que se repete quando o domínio, o remetente e o nome do arquivo mudam.

O grupo tem foco financeiro. O impacto que vimos no monitoramento combina com fraude, roubo de sessão e abuso de infraestrutura de alta credibilidade. Este post descreve a atuação, persistência e evolução. Deixamos de fora nomes, células internas do grupo e detalhes que pouco ajudam quem está na defesa e só aumentariam o ruído.

Quando a operação veio à tona: Woovi e o falso ofício

Em 19/02/2026, as primeiras menções públicas e privadas apontavam para um possível comprometimento da Woovi (CNPJ 54.811.417/0001-63, ISPB 54811417).

O posicionamento público descreveu um e-mail com aparência governamental e um PDF malicioso. A campanha apresentava quatro características principais:

1. Remetente institucional real, associado à Polícia Civil do Amapá (@policiacivil.ap.gov.br), sem indício de falsificação clássica de remetente.
2. Linguagem de autoridade: intimação, ofício, certificado, advertência legal.
3. PDF como estágio intermediário, e não como payload final.
4. Redirecionamento para infraestrutura externa, apresentada como etapa necessária para “obter o certificado digital”.

O fluxo era este:

1. A vítima recebe o e-mail institucional.
2. Abre o PDF.
3. Clica no botão ou link de “Certificado Digital”.
4. É levada a um servidor externo.
5. Baixa e executa um instalador com nome de documento oficial.

Naquela onda, o executável observado foi o Certificado_PCAP.exe. O nome faz o trabalho da engenharia social, parece burocracia e não um malware.

A análise da infraestrutura utilizada nessa campanha também revelou um painel de C2 identificado na interface como Forever v1.0, utilizado para gerenciamento dos hosts conectados e execução de tarefas.

A leitura técnica daquele dia continua válida quase um ano depois. O sucesso da campanha não dependia de uma falha inédita no software. Dependia de uma conta oficial já comprometida, de um documento crível e de um usuário treinado para obedecer a um ofício.

Por isso o hunting começou. Se o vetor não era zero-day, então o mesmo padrão poderia estar em outras caixas, outros Estados e outras organizações. A Woovi tornou o padrão visível. O restante do ano mostrou que aquele caso era apenas uma peça de uma operação muito maior, com alcance nacional.

Quem é o Shadow Ledger

O Shadow Ledger é um agrupamento de cibercrime com atuação observada no Brasil desde setembro de 2025. Seus ataques têm como foco principalmente o setor financeiro, incluindo instituições de pagamento, fintechs e prestadores de serviço. Ao mesmo tempo, órgãos públicos aparecem na operação tanto como alvos quanto como infraestrutura para entrega das campanhas.

Na prática, a operação que acompanhamos funciona em duas frentes:

1. Frente técnica. O grupo explora serviços web expostos, painéis de hospedagem e aplicações vulneráveis a falhas já conhecidas. Uma vez comprometida, essa infraestrutura passa a ser usada para manter acesso e distribuir novas etapas da campanha.
2. Frente de engenharia social. Contas de e-mail e sites já comprometidos são usados para enviar ofícios, intimações, procurações e falsos “certificados digitais”. Como a mensagem parte de uma infraestrutura legítima, ela já chega acompanhada de uma confiança que o atacante não precisou construir.

Esse ciclo se auto-alimenta. Um portal municipal comprometido hospeda o malware. Uma caixa de e-mail de um policial comprometida envia o PDF. A vítima corporativa executa o arquivo. A sessão roubada abre caminho para sistemas financeiros. E novos ofícios passam a sair de novos remetentes.

Não estamos falando de casos pontuais. Ao longo do monitoramento e dos trabalhos de Resposta a Incidentes realizados em 2026, vimos esse mesmo fluxo se repetir em diversas organizações. Mudavam a isca, o remetente, o arquivo e a infraestrutura de C2, mas a forma de operar continuava praticamente a mesma.

É justamente aí que tratar cada ocorrência como um incidente isolado se torna um problema. O defensor enxerga um ofício malicioso, um ClickFix ou uma extensão suspeita. O Shadow Ledger utilizava tudo isso como partes da mesma operação.

Por isso, uma defesa baseada apenas em listas de IoCs envelhece rápido. Hoje o remetente pode ser do Amapá; amanhã, de outro Estado. Em uma semana, o arquivo se chama Certificado_PCAP.exe; na seguinte, OficioPC.exe. Os indicadores sempre mudam mas o comportamento permanece.

Uma operação, vários braços

No começo de 2026, era fácil olhar para essas ondas como campanhas separadas. De um lado, PDFs de ofício, QR Codes e ClickFix. Do outro, instaladores Inno Setup que terminavam em um aplicativo Electron trojanizado. Os nomes dos arquivos mudavam. Os hosts mudavam. Até as análises automatizadas de algumas sandboxes chegavam a classificar partes da cadeia como software legítimo.

A correlação mostra outra coisa: são braços da mesma operação.

Três evidências sustentam essa leitura:

1. Infraestrutura pública compartilhada. Os mesmos portais .gov.br e .jus.br comprometidos distribuíram, em períodos próximos, tanto conteúdo de ofício e ClickFix quanto instaladores da cadeia BoostNote. Prefeituras, sistemas de protocolo, portais de documentos e até ativos ligados à segurança pública aparecem nos dois braços.
2. Tema e logística se repetem. Polícia Civil, intimação, procuração digital, certificado. A isca jurídica continua a mesma. O que muda é o caminho até a execução e o ponto em que conseguimos observar a cadeia.
3. Cadeia de compilação recorrente. Mesmo quando o C2 muda, o instalador continua surgindo da mesma combinação: binário Delphi, empacotamento Inno Setup e runtime Node.js/Electron com um index.js malicioso.

Há ainda um detalhe importante que ajuda a explicar por que o braço dos ofícios consegue atravessar filtros de e-mail. As mensagens partem de contas institucionais válidas que realmente foram comprometidas e, por isso, podem passar normalmente pelas validações de SPF, DKIM e DMARC. Não é o spoofing em que o atacante tenta se passar por um remetente legítimo. Aqui, ele está usando uma identidade legítima que já foi comprometida para enviar o e-mail de ofício.

Para o SOC, essa diferença importa. Um ofício que parece “limpo” no gateway e um instalador que não chama atenção na sandbox podem fazer parte do mesmo incidente, apenas em momentos diferentes da cadeia. Quando esses braços são tratados separadamente, a investigação se fragmenta, e a contenção também.

Linha do tempo

A narrativa abaixo organiza as evidências na ordem em que foram correlacionadas. Não é uma lista completa de incidentes, mas uma forma de acompanhar a evolução da operação e entender o que o grupo manteve, o que mudou e como essas mudanças permitiram que continuasse operando.

Setembro de 2025: os primeiros sinais

Os primeiros sinais que correlacionamos ao Shadow Ledger aparecem em setembro de 2025. Naquele momento, o caso da Woovi ainda estava a meses de acontecer e se tornar público. O que já víamos, porém, era uma operação com objetivo financeiro claro e capacidade de transformar acessos comprometidos em oportunidades de movimentação.

Esse ponto é importante para entender o restante da história. A operação não começa com o e-mail de fevereiro. Aquele episódio foi apenas o momento em que o grupo atingiu um alvo que ganhou visibilidade pública e, para nós, se tornou um ponto de partida para conectar as evidências.

O interesse por ambientes de pagamento e os sinais de monetização já estavam no nosso radar meses antes da manchete de fevereiro, em outros processos de resposta a incidentes que realizamos.

Janeiro a fevereiro de 2026: a esteira já estava montada

Antes do caso da Woovi ganhar visibilidade, amostras e e-mails do mesmo agrupamento já circulavam. Janeiro e fevereiro mostram os dois braços operando em paralelo: de um lado, os ofícios acompanhados de PDFs; do outro, os instaladores que levavam ao BoostNote.

Em fevereiro, a operação ganha visibilidade pública. Nesse momento, a cadeia que passamos a observar de forma recorrente fica mais clara:

• E-mail institucional comprometido;
• PDF de ofício, intimação, procuração ou certificado;
• loader com nome burocrático;
• persistência via BoostNote trojanizado;
• estágios seguintes entregues sob demanda.

Já naquele período havia remetentes de diferentes Estados e URLs de entrega hospedadas em portais públicos comprometidos. Não era um disparo isolado. Era uma estrutura que já estava funcionando.

Fevereiro e março de 2026: o ClickFix entra na esteira

Nas semanas seguintes, o grupo deixa de depender só do clique no PDF. Entra o ClickFix.

A vítima acessa um site aparentemente legítimo, muitas vezes um .gov.br, .jus.br ou .com.br comprometido, e encontra uma página de “verificação” semelhante a um anti-bot do Cloudflare. A instrução é simples: copiar um comando, abrir o Executar com Win+R, colar e confirmar.

Em uma das variantes, a vítima recebe um PDF que simula um ofício ou uma intimação da Polícia Civil e contém um QR Code. Ao escanear o código, ela passa por um serviço que analisa seu perfil antes de liberar o acesso à mesma página de verificação, conforme os critérios do atacante. O comando observado costuma usar PowerShell para baixar e executar o próximo estágio em memória.

A partir daqui, o acesso inicial muda. O navegador deixa de ser o único palco e a própria vítima leva a execução para o Windows ao seguir as instruções apresentadas na página. Depois disso, entram em cena loaders, ferramentas comerciais de acesso remoto e o mesmo núcleo de persistência observado em outras campanhas que vamos detalhar logo mais.

Os intermediários que ficaram para trás

O ClickFix também revelou outra característica da operação: o grupo não dependia apenas de infraestrutura própria para conduzir a vítima até o próximo estágio. Durante o hunting, identificamos diversos sites brasileiros legítimos, principalmente domínios .com.br, que haviam sido comprometidos e transformados em páginas intermediárias da campanha.

Em vários desses ativos, encontramos JavaScript injetado diretamente no HTML. O código realizava uma requisição para kak[.]is e utilizava a resposta recebida para carregar dinamicamente a próxima etapa da campanha. Dessa forma, uma página legítima comprometida podia ser incorporada ao fluxo do ClickFix sem que o atacante precisasse hospedar toda a cadeia em infraestrutura própria.

O acompanhamento desses intermediários revelou ainda um detalhe importante. Meses depois, parte das páginas continuava com o código malicioso injetado. Elas já não direcionavam novas vítimas ao ClickFix porque a infraestrutura em kak[.]is utilizada naquele estágio havia deixado de responder. O código, porém, permanecia presente no HTML.

Isso evidencia uma diferença importante entre interromper a cadeia e remediar o comprometimento. Quando uma dependência externa deixa de funcionar, a campanha pode parar de entregar o próximo estágio, mas isso não significa que os sites utilizados como intermediários tenham sido efetivamente corrigidos.

Março e abril de 2026: a extensão, o roubo de sessão e a escala nacional

A campanha ganha um estágio mais silencioso: uma extensão maliciosa para Chrome, apresentada como certificado ou componente de segurança do navegador.

O pacote observado usa Manifest V3, um nome enganoso como “Certificado SSL Chorme” e permissões amplas, incluindo cookies e <all_urls>. Depois de instalada, a extensão passa a acompanhar a navegação da vítima e aguarda o acesso a páginas de interesse para atuar sobre sessões já autenticadas.

A análise do código revelou que os alvos não estavam definidos de forma fixa dentro da extensão. A seleção era controlada remotamente por meio de goingg[.]is/whitelist.extension.txt. Sempre que uma navegação era concluída, a URL acessada era comparada com essa lista. Caso houvesse correspondência, a extensão ativava a próxima etapa.

Isso permitia ao operador alterar os sites monitorados sem precisar reinstalar ou distribuir uma nova versão da extensão. A lista era armazenada em cache por apenas cinco minutos e depois podia ser consultada novamente na infraestrutura da campanha.

A segunda peça era ainda mais interessante. A extensão buscava dinamicamente o script goingg[.]is/pipiteimosa.extension.js, também mantido em cache por cinco minutos. Quando a vítima acessava um endereço selecionado, a extensão utilizava chrome.cookies.getAll() para recuperar os cookies associados àquela página e os disponibilizava no contexto principal do navegador através de:

Em seguida, o conteúdo de pipiteimosa.extension.js era injetado na própria página. Na prática, a extensão criava uma ponte entre uma sessão autenticada da vítima e uma lógica que podia ser atualizada remotamente pelo operador.

Esse estágio ajuda a explicar boa parte do impacto observado depois. O objetivo deixa de ser apenas descobrir uma senha. O navegador da vítima já possui sessões que passaram pelo processo de autenticação e podem dar acesso a sistemas administrativos e financeiros.

Não é preciso “quebrar” o MFA quando o alvo passa a ser uma sessão que já está autenticada.

A análise de outros artefatos da mesma cadeia mostrou que o grupo também desenvolveu uma forma específica de instalar essa extensão no Chrome e no Edge.

Em vez de depender apenas da instalação convencional pelo usuário, o código manipula diretamente os perfis locais dos navegadores. No Chrome, ele identifica os perfis disponíveis e altera os arquivos Preferences e Secure Preferences, habilitando o modo de desenvolvedor e adicionando a extensão às configurações do perfil. A extensão é registrada como externa à Chrome Web Store, com from_webstore definido como false e permissões que incluem cookies, tabs, scripting e <all_urls>.

O código vai além de simplesmente editar esses arquivos. Para manter as alterações consistentes com as estruturas de integridade utilizadas pelo Chromium, ele recalcula os HMACs das preferências modificadas e o super_mac armazenado no Secure Preferences. Depois da alteração, o próprio instalador verifica se os valores gravados e seus respectivos MACs permanecem válidos.

A mesma lógica foi implementada para o Microsoft Edge, com uma etapa adicional para localizar o resources.pak do navegador e identificar uma seed compatível a partir dos MACs existentes no perfil. Essa seed é então utilizada para recalcular as estruturas de integridade depois da modificação.

Outro detalhe mostra como a cadeia foi construída para continuar mudando. O endereço de download da extensão não precisava permanecer fixo dentro do instalador. O código consultava um conteúdo externo no Pastebin para obter dinamicamente a URL do pacote que deveria ser baixado. Assim, o operador podia trocar a localização da extensão sem necessariamente distribuir uma nova versão do instalador.

A extensão, portanto, era apenas uma das peças. Havia uma cadeia dedicada a colocá-la dentro do navegador, enquanto sua configuração de alvos e sua lógica de atuação continuavam controladas remotamente.

No mesmo período, os disparos de ofícios deixam de parecer regionais. Contas de e-mail da Polícia Civil, órgãos estaduais e municípios de vários Estados passam a aparecer como remetentes, enquanto portais públicos comprometidos são usados para hospedar e distribuir conteúdo. Paraná, Espírito Santo, Rio de Janeiro, São Paulo, Santa Catarina, Amapá e outros Estados aparecem ao longo das campanhas. A abordagem muda de acordo com o órgão, mas a lógica por trás do ataque continua a mesma.

Nos trabalhos de Resposta a Incidentes realizados ao longo de 2026 pelo time do QuimeraX, esse padrão apareceu mais de uma vez: uma estação corporativa comprometida com uma extensão instalada ou stealer customizado, sessões administrativas e financeiras ainda válidas e um operador interessado não apenas em credenciais, mas no acesso que aquela identidade já possuía.

O padrão não ficou restrito a um único incidente público. Ele reapareceu em diversas organizações.

Maio a agosto de 2026: o ".gov.br" vira fábrica e o C2 passa a rotacionar por onda

Na primeira metade de 2026, os dois braços continuam ativos em paralelo. Os PDFs de ofício tiveram maior visibilidade no começo do ano, enquanto a cadeia Inno/Electron permaneceu ativa nos meses seguintes. O monitoramento contínuo começou a deixar uma característica cada vez mais clara: a infraestrutura mudava de uma onda para outra, mas a forma de operar permanecia.

Em maio, a operação ainda combinava e-mails institucionais comprometidos, ClickFix, extensões e a cadeia Inno/Electron. Uma das ondas utilizava o C2 policiacivilmg[.]com, seguido por xx[.]kak[.]is, enquanto remetentes comprometidos aparecem em diferentes Estados (SP, SC, PR, AP, ES, PE).

Em uma das campanhas observadas nesse período, o e-mail simulava uma requisição complementar da Polícia Civil de Pernambuco e utilizava linguagem jurídica para pressionar a vítima a consultar um suposto certificado. O link apresentado na mensagem direcionava para conteúdo hospedado em infraestrutura governamental comprometida:

• hxxps://poa[.]sp[.]gov[.]br/arquivofiscal/*

Poucos dias depois, muda também a aparência da persistência. O boost.exe observado anteriormente dá lugar ao draw.io.exe, instalado em %LOCALAPPDATA%\EasySuiteAutoTool\, acompanhado pelo loader DocumentoPCPE.exe e pelo C2 pccvill[.]com. Os nomes mudam, mas o runtime Electron continua o mesmo por baixo.

Em junho, a fábrica de assuntos fica ainda mais evidente, além dos ofícios policiais, aparecem temas de ofício judicial, lavagem de dinheiro, sigilo, intimação, requisição, mandado e notificação. Algumas campanhas passam a utilizar caminhos únicos por vítima, como /levantamento/<id>, enquanto os loaders aparecem como NotificacaoPCPE.exe, ProcuracaoDigital.exe e RequerimentoPC.exe.

A persistência também volta a aparecer como Boost Note.exe, dessa vez dentro de um diretório chamado QuickPlusSmartPlusator. Enquanto isso, os C2s continuam rotacionando. taaeiuep[.]com aparece em uma onda e dahieenloo[.]com na seguinte. Praticamente cada nova campanha estreia uma infraestrutura diferente, enquanto o vetor inicial continua apoiado em documentos oficiais e ativos públicos comprometidos.

Em julho, o monitoramento desses ativos mostrou a escala da estrutura. Sites de prefeituras, câmaras, fundos previdenciários, protocolos municipais e outros órgãos públicos passaram a servir executáveis com temas de ofício, intimação, procuração, requerimento e notificação. Em alguns casos, qualquer caminho dentro de diretórios como /oficio/ ou /doc/ entregava o malware. Em outros, o endereço era criado especificamente para uma vítima, isso dificultou o trabalho da nossa equipe de realizar o tracking exato de cada vitima.

Arquivos como OficioPC.exe e Procuracao_Digital.exe repetiam o comportamento observado nas ondas anteriores, agora associados ao C2 zsxocjarsate[.]com. Em portais já comprometidos, observamos ainda a criação de novas caixas de e-mail utilizadas especificamente para os disparos.

Esses portais não eram, na maior parte dos casos, o destino final da fraude, eram parte da infraestrutura da campanha. Um .gov.br reduz a suspeita, ajuda a atravessar filtros e oferece ao operador caminhos que parecem pertencer a processos, protocolos ou atendimentos legítimos.

Em agosto, não há sinal de encerramento. Uma nova onda utiliza remetentes ligados à educação no Amapá, um ZIP de “certificado” hospedado em marapoama[.]sp[.]gov[.]br, o loader CertificadoLeitorPCAP.exe e um novo C2, eoplpfoepnwel[.]com.

Novas caixas. Novos arquivos. Novos C2s. E o mesmo ciclo se repete novamente.

Setembro de 2026: o ofício hospedado e o search-ms

No começo de setembro, a entrega ainda segue o padrão já conhecido: caixas @policiacivil.pe.gov.br e relacionadas, ZIPs e EXEs com tema de certificado hospedados em previpaulista[.]pe[.]gov[.]br e novamente em Marapoama.

Dias depois, o fluxo muda. O grupo passa a hospedar o próprio documento fraudulento diretamente em um .gov.br comprometido. A vítima já não depende apenas de um anexo recebido por e-mail, ao acessar o endereço, encontra uma página que simula um ofício da Polícia Civil, com elementos visuais de uma comunicação oficial, número de documento, solicitação de dados bancários e um botão para “instalar certificado digital”.

Nessa onda, o PDF ou link leva ao protocolo search-ms:. Ao clicar abre o Windows Search apontando para um compartilhamento WebDAV hospedado na infraestrutura do próprio município comprometido, em mail[.]marapoama[.]sp[.]gov[.]br. A partir daí, a cadeia leva a vítima até uma ferramenta comercial de RMM, o Zoho Assist.

A isca continua sendo o ofício, porém desta vez o caminho até a execução é que mudou.

Os disparos partem de várias caixas do mesmo Estado, enquanto o path em /documento continua sendo criado de forma individual para cada alvo. A confiança continua vindo da infraestrutura institucional comprometida, mas o executável baixado diretamente dá lugar ao uso de um protocolo nativo do Windows e, na sequência, ao acesso remoto via RMM.

As campanhas de setembro também trouxeram dois novos C2s, policiacivilba[.]com e policiacivilpe[.]com. Eles seguem o mesmo padrão dos lookalikes observados anteriormente, como policiacivilmg[.]com, pccvill[.]com e pccvioo[.]com: domínios .com construídos para lembrar endereços da Polícia Civil, agora fazendo referência à Bahia e a Pernambuco.

A configuração observada nesses hosts indica que a infraestrutura estava sendo preparada para novas ondas da campanha.

O que se manteve: o BoostNote

Se a infraestrutura muda de uma onda para outra, o host Electron quase não muda. O nome do arquivo, por outro lado, muda bastante.

Em maio de 2026, o grupo abandona o boost.exe observado na onda anterior e passa a persistir como draw.io.exe, em %LOCALAPPDATA%\EasySuiteAutoTool\. Em junho, o mesmo componente volta a aparecer como Boost Note.exe, agora em outro diretório inventado, QuickPlusSmartPlusator. Mais tarde surgem Grape.exe e App.exe.

A análise das amostras desde a campanha de fevereiro mostra uma cadeia relativamente estável:

1. Pré-estágio: PDF, QR Code ou ClickFix conduz a vítima até o loader.
2. Loader: executável com nome relacionado a certificado ou ofício, compilado em Delphi e empacotado com Inno Setup.
3. Persistência: instalação de um host Electron trojanizado, que pode aparecer como BoostNote, draw.io.exe ou outro nome. Entre os caminhos observados estão %LOCALAPPDATA%\ProSoftionTechMax\boost.exe, %LOCALAPPDATA%\EasySuiteAutoTool\draw.io.exe e %LOCALAPPDATA%\QuickPlusSmartPlusator\Boost Note.exe. Outras ondas usam diretórios com nomes de produtos inventados, como UltraSuiteSmartCoreware e ProSoftxUltraToolator.
4. Beacon: o index.js do aplicativo é desofuscado, envia informações da estação ao C2 e passa a consultar o servidor em busca de novas tarefas.
5. Estágios seguintes: o C2 pode devolver JavaScript para execução no próprio processo via eval ou entregar um executável, gravado em %TEMP% e iniciado na estação.

O BoostNote original é um aplicativo legítimo de anotações baseado em Electron. Para o atacante, essa escolha traz algumas vantagens. O processo parece um software de produtividade, o diretório de instalação parece pertencer a um produto e a comunicação com o C2 fica escondida dentro de um runtime comum.

Nas construções mais recentes, até o nome BoostNote começa a desaparecer. O binário passa a assumir nomes genéricos, como Grape.exe ou App.exe, e pode ser extraído em diretórios temporários is-*.tmp. A intenção parece simples: mudar aquilo que o defensor aprendeu a procurar sem abandonar aquilo que mantém a operação funcionando.

É justamente o index.js malicioso que atravessa essas mudanças. Depois da desofuscação, a lógica observada se repete:

• cria um identificador persistente da máquina em %APPDATA%;
• lê uma etiqueta de campanha ou afiliado ao lado do instalador;
• coleta o nome do computador e do usuário;
• estabelece persistência por chave Run e setLoginItemSettings;
• consulta o C2 em intervalos de alguns minutos em busca de novas tarefas;
• executa o que receber, seja um script ou um binário.

Ao longo de 2026, redirectors, IPs, domínios e nomes de arquivos mudaram com frequência. O host Electron permaneceu como uma das peças mais estáveis da operação. Quando a estação passa pelo primeiro estágio de comprometimento, o que permanece em execução já não é o PDF, o ofício ou a página usada como isca. É esse núcleo que mantém a comunicação com a infraestrutura do grupo e permite a entrega dos próximos estágios.

Para hunting, essa diferença é importante. Bloquear Certificado_PCAP.exe pode resolver a onda daquela semana. Procurar por ProSoftionTechMax, EasySuiteAutoTool, QuickPlusSmartPlusator, por execuções inesperadas de boost.exe ou draw.io.exe, por hosts Electron carregando index.js ofuscado e pelos padrões de beacon associados à família permite procurar justamente aquilo que o grupo continua carregando de uma campanha para outra.

O que se manteve: o protocolo do backdoor

Domínios e IPs são peças fáceis de substituir nesta operação. O protocolo usado pelo beacon muda bem menos.

Na análise das amostras, observamos pelo menos duas gerações de comunicação convivendo:

1. Geração GET. Requisições para caminhos no formato /laravel.php?api=api&hash=<base64>&message=PT1n<base64>, com os dados enviados diretamente pela query string.
2. Geração POST (mais comum). Requisições para um caminho curto, observado como /nbw/ ou /f/ ou /zta e etc, com um corpo em JSON contendo o identificador da máquina, COMPUTERNAME, USERNAME e a etiqueta associada à campanha.

Apesar da diferença na comunicação, as duas gerações compartilham a mesma cadeia de build, com Inno Setup, Electron e index.js, além da mesma lógica de entrega modular dos estágios seguintes.

É por isso que bloquear apenas o domínio resolve pouco. O C2 de uma onda pode ser um lookalike de Polícia Civil, como policiacivilmg[.]com, e na seguinte assumir um nome completamente aleatório, como dahieenloo[.]com ou zsxocjarsate[.]com.

Em parte das amostras, o C2 observado durante a análise já nem corresponde à infraestrutura que estava ativa durante a campanha. O delivery pode continuar hospedado em um .gov.br comprometido enquanto o beacon aponta para uma infraestrutura que já foi substituída.

Parte desses C2s também fica atrás da Cloudflare, adicionando mais uma camada entre o domínio observado e a infraestrutura de origem. Para o defensor, o indicador mais duradouro não é o domínio. É a forma como o malware se comunica e a cadeia que o coloca em execução, analisar padrão de beaconing é essencial para detectar este comportamento.

O que mudou: o ClickFix

O ClickFix foi uma das principais adaptações no acesso inicial depois da campanha da Woovi.

Em fevereiro, a vítima ainda precisava abrir o PDF e clicar no suposto certificado. Funcionava, mas mantinha um fluxo mais tradicional de phishing com documento. O ClickFix amplia as possibilidades de entrada:

• o site pode estar hospedado em um portal público já comprometido;
• a página simula uma verificação rotineira;
• a ação solicitada, abrir o Executar com Win+R, colar e confirmar, parece fazer parte da própria verificação;
• a execução sai do navegador e chega diretamente ao sistema da vítima.

A infraestrutura usada nesse fluxo também se expandiu. Primeiro aparecem portais .gov.br e .jus.br. Depois, dezenas de sites .com.br comprometidos passam a funcionar como páginas intermediárias. Para o defensor, o domínio específico perde valor rapidamente. O que permanece é a sequência: infraestrutura aparentemente confiável, página de verificação e execução pelo próprio usuário.

Em várias ondas, o ClickFix não substituiu o ofício. Ele foi acrescentado à cadeia. O e-mail levava ao PDF. O PDF levava ao site, em alguns casos por meio de um QR Code. O site, então, instruía a vítima a executar o comando. Em outras campanhas, a ordem mudava, mas o objetivo continuava sendo levar a execução do navegador para o Windows.

Há ainda uma etapa de filtragem no meio desse caminho. Serviços intermediários avaliam o visitante antes de entregar a página maliciosa. Com isso, crawlers, sandboxes e acessos que não interessam ao operador podem receber um conteúdo diferente ou simplesmente não avançar na cadeia. Para uma vítima considerada válida, a campanha continua. Para uma análise automatizada, pode parecer que não há nada ali.

Para o nosso monitoramento, essa foi uma das primeiras evidências claras de que o Shadow Ledger trata a entrega como uma parte adaptável da operação. Quando um caminho começa a perder eficiência, outro pode assumir seu lugar sem que o restante da cadeia precise mudar.

O que mudou: o delivery dos ofícios

O ofício é uma das marcas mais estáveis da engenharia social do grupo. Mas a forma de entregá-lo, não.

Fase 1: o ofício como anexo

Na campanha associada à Woovi, o fluxo ainda era relativamente simples: e-mail, PDF e, na etapa seguinte, o suposto “certificado”. A credibilidade vinha principalmente do remetente institucional comprometido e da aparência oficial do documento.

Fase 2: o ofício como site oficial

Nas ondas seguintes, o grupo passa a usar sites públicos comprometidos como parte da entrega. O e-mail continua existindo, mas a vítima agora é direcionada para caminhos que parecem pertencer ao próprio portal:

• /oficio
• /oficio/*
• /doc
• /documento
• /levantamento
• /intermediacao
• /procedimento
• /protocolo

O /* aqui é importante. Não existe necessariamente um único arquivo ou URL para bloquear. Diferentes subcaminhos dentro daquele diretório podem levar ao mesmo malware. Em algumas campanhas, o path ainda recebe um identificador exclusivo para cada vítima, fazendo o endereço parecer parte de um processo, protocolo ou atendimento individual.

Fase 3: o ofício como operação em escala

Em julho e agosto de 2026, a estrutura vai além do documento. O grupo passa a operar com múltiplas caixas institucionais comprometidas, reutiliza painéis de correio e alterna remetentes entre diferentes Estados.

Em junho, os assuntos dos e-mails já eram gerados em lote, com substituição do nome do intimado (um template literalmente). Em julho, observamos novas caixas sendo criadas dentro de ambientes municipais já comprometidos especificamente para os disparos (Após comprometer o sistema de e-mails da cidade, eles criavam e-mails como [email protected] por exemplo). O texto jurídico e aparência institucional continua.

Fase 4: o ofício vira uma página e o clique no link chega ao Windows "Search"

Em setembro de 2026, o ofício deixa de existir apenas como anexo ou como caminho para o download de um .exe. Ele passa a ser apresentado como uma página hospedada diretamente em um .gov.br comprometido, mantendo a aparência de uma comunicação oficial.

O clique seguinte usa search-ms: para abrir o Windows Search apontando para um compartilhamento WebDAV na própria infraestrutura institucional comprometida. Nessa onda, o próximo estágio observado leva a uma ferramenta comercial de RMM, o Zoho Assist, e não ao mesmo loader Electron visto nas campanhas anteriores.

Essa evolução ajuda a fechar o ciclo descrito no começo do post. Comprometer um .gov.br não significa apenas controlar um site, para o grupo, esse acesso pode fornecer:

• um local para hospedar o payload ou o próprio ofício;
• um domínio com maior confiança para atravessar filtros e reduzir suspeitas;
• contas de e-mail e, em alguns casos, infraestrutura WebDAV para continuar a cadeia;
• uma identidade institucional que torna a abordagem muito mais convincente.

Por isso, o delivery dos ofícios talvez seja o exemplo mais claro da evolução do Shadow Ledger ao longo de 2026. A isca permaneceu em todos os casos mas a forma de entregá-la sempre evoluiu. O servidor de C2, nome do binário, hashes, domínio, caminho e até o mecanismo usado no clique podem mudar sem que o objetivo da operação mude junto.

Quando o acesso inicial encontra um ambiente permissivo

O phishing explica como o atacante entra, mas ele não explica, sozinho, por que esse acesso consegue avançar tanto.

Nos trabalhos de Resposta a Incidentes e nas análises realizadas ao longo do monitoramento, encontramos outro fator recorrente: controles que aumentavam desnecessariamente a superfície disponível depois do comprometimento de uma estação ou identidade.

Isso apareceu de diferentes formas.

Backoffices expostos diretamente à Internet. Painéis administrativos e sistemas internos acessíveis externamente sem uma necessidade operacional clara ou sem uma camada adicional de controle de acesso. Para um operador que acabou de obter uma sessão corporativa válida, encontrar esse tipo de aplicação reduz significativamente o caminho entre o comprometimento inicial e um sistema sensível.

Artefatos relacionados à operação do Pix em hosts onde não precisavam estar. Em alguns ambientes, encontramos arquivos e certificados utilizados em processos de validação e integração relacionados a fluxos de cash-in e cash-out armazenados em estações ou servidores sem uma justificativa operacional clara. O problema não é apenas a presença do arquivo. É o valor que aquele host passa a ter depois de comprometido.

Usuários com privilégios acima do necessário. Contas utilizadas no dia a dia mantinham acesso a sistemas, painéis e funções que não eram necessários para aquela atividade. Quando uma sessão desse usuário é roubada, o atacante herda parte dessa superfície de acesso.

Sessões sensíveis concentradas na mesma estação. Correio corporativo, painéis administrativos, plataformas financeiras e outros sistemas permaneciam autenticados no mesmo navegador. Nesse cenário, comprometer o endpoint deixa de significar obter acesso a uma única aplicação. Significa assumir uma identidade que já possui caminhos abertos para diferentes partes da operação.

Nenhum desses pontos, isoladamente, explica o sucesso do Shadow Ledger. O problema aparece quando eles se encontram.

Uma campanha de phishing não precisa terminar em uma vulnerabilidade crítica quando a identidade comprometida já consegue alcançar diretamente sistemas críticos.

É aí que a maturidade de segurança passa a fazer diferença. Segmentar backoffices, restringir exposição externa, aplicar menor privilégio, proteger adequadamente certificados e outros artefatos sensíveis e reduzir a concentração de sessões privilegiadas não impede o ofício de chegar à caixa de entrada, mas reduz drasticamente o que o atacante consegue fazer depois do primeiro comprometimento.

O que esse caso ensina

O Shadow Ledger mostra que uma operação não precisa de um zero-day para ser eficiente. Persistência, escala e capacidade de adaptação podem ser suficientes.

Depois de um ano de monitoramento, alguns aprendizados ficam claros:

• Um caso público não representa toda a campanha. A Woovi tornou o padrão visível, mas a operação já existia antes e continuou aparecendo em outras organizações nos meses seguintes.
• Remetente oficial não significa remetente seguro. Uma conta institucional realmente comprometida pode passar por SPF, DKIM e DMARC e carregar uma credibilidade que um domínio desconhecido dificilmente teria.
• O ofício funciona porque explora uma confiança que já existe. Polícia, intimação, processo, procuração e certificado não são temas escolhidos por acaso. São comunicações que naturalmente induzem atenção e urgência.
• IoCs rotacionam. TTPs permanecem por mais tempo. A partir de junho, praticamente cada nova onda estreia um C2 diferente. A cadeia Electron, o ClickFix, o uso de search-ms:, caminhos como /oficio e os padrões de comunicação do beacon oferecem pontos de correlação mais duradouros do que o IP ou domínio de uma única campanha.
• Sites públicos comprometidos viram infraestrutura de campanha. Prefeituras, câmaras, fundos previdenciários e portais de protocolo passam a hospedar documentos, páginas e payloads. Em muitos casos, o órgão não é o alvo final. É parte do caminho até ele.
• Roubar uma sessão muda o problema de autenticação. Com uma sessão já autenticada em mãos, o operador pode reutilizar o acesso sem necessariamente passar novamente pelo fluxo de login e pelo desafio de MFA.
• Uma amostra “limpa” não encerra a investigação. Um instalador Inno, um host Electron ou um ofício institucional podem parecer pouco relevantes quando analisados isoladamente. É a correlação entre eles que revela a campanha.
• IR e CTI acabam olhando para as mesmas peças por perspectivas diferentes. O ofício observado durante o monitoramento é o mesmo que reaparece no endpoint. O C2 identificado pela inteligência ajuda o hunting. E o artefato encontrado durante a resposta ajuda a entender a próxima onda.

Nada disso depende de uma operação sofisticada no sentido cinematográfico. Depende de tempo, escala, repetição e adaptação. O Shadow Ledger encontrou uma forma de explorar não apenas vulnerabilidades técnicas, mas algo mais difícil de bloquear: a confiança que empresas e pessoas depositam em instituições legítimas.

Conclusão

O caso Woovi foi o momento em que o Shadow Ledger ganhou visibilidade pública. Para o nosso monitoramento, foi quando uma operação que já estava em circulação começou a revelar um padrão maior.

Quase um ano depois, a operação continua reconhecível pelos mesmos elementos: a confiança em comunicações oficiais, uma estrutura de entrega que se adapta e o uso recorrente de Electron para persistência. O que mudou foi a forma de chegar até a vítima. ClickFix, novos C2s a cada onda, draw.io.exe no lugar de boost.exe, ofícios hospedados em .gov.br, search-ms: e ferramentas comerciais de RMM tornaram a operação mais difícil de conter com um único bloqueio.

A Woovi não foi um incidente isolado. O mesmo ciclo reapareceu em diversas outras organizações e utilizou dezenas de ativos públicos como parte da infraestrutura de entrega. Enquanto uma comunicação oficial continuar carregando confiança por si só, essa confiança continuará sendo explorada como parte do ataque.

No QuimeraX, esse tipo de acompanhamento existe para ir além do que aconteceu no dia do incidente. O objetivo é entender como a operação continua quando a manchete já passou, quais peças o grupo mantém, quais ele troca e onde a defesa ainda está procurando pelo domínio, IP ou arquivo da semana passada enquanto o comportamento permanece praticamente o mesmo.

Mais do que contar a história de um incidente específico, o Shadow Ledger reforça uma ideia simples: no Brasil, a confiança institucional ainda funciona como um controle de segurança. Confiamos no domínio, no remetente, no documento e na aparência de uma comunicação oficial. O grupo aprendeu a explorar exatamente isso.

Quando essa confiança é comprometida, o atacante não precisa mais parecer legítimo. Ele já parte de uma infraestrutura que é.

Quer o time do QuimeraX acompanhando ameaças que podem afetar sua empresa?
Solicite uma demonstração e veja o QuimeraX em ação na sua empresa: https://quimerax.com

Indicadores úteis para hunting

A lista abaixo é curta de propósito. A infraestrutura do Shadow Ledger muda com frequência, então uma lista extensa de domínios e IPs envelhece rápido.

Para hunting, vale procurar primeiro aquilo que sobrevive às trocas de infraestrutura.

Os nomes usados para persistência realmente variaram entre boost.exe, draw.io.exe, Boost Note.exe, Grape.exe e App.exe, enquanto a operação também abusou de diferentes ferramentas comerciais de acesso remoto.

IoCs históricos

A lista abaixo consolida IoCs observados entre setembro de 2025 e setembro de 2026 durante o acompanhamento das atividades do Shadow Ledger.

A infraestrutura do grupo muda com frequência. Por isso, estes indicadores devem ser usados principalmente para hunting retrospectivo, correlação e enriquecimento de investigações, e não como uma blocklist permanente. Todos os indicadores de rede estão apresentados de forma defanged.

Rede: endereços IP

Os endereços abaixo foram associados, em diferentes momentos da operação, a infraestrutura de C2, redirecionamento, distribuição de payloads, stealers e envio de campanhas.

Rede: domínios de C2 e infraestrutura de campanha

Os domínios abaixo foram observados em diferentes funções dentro da operação, incluindo C2, exfiltração, distribuição de payloads, ClickFix, extensão maliciosa e redirecionamento.

Eles são apresentados separadamente dos domínios institucionais comprometidos, como .gov.br e .jus.br, utilizados pelo grupo como infraestrutura de delivery.

URLs de delivery, C2 e infraestrutura associada

As URLs abaixo foram observadas em diferentes etapas das campanhas, incluindo redirecionamento, entrega de payloads, ClickFix, comunicação com C2, distribuição da extensão e abuso de infraestrutura institucional comprometida.

A presença de um domínio .gov.br nesta tabela representa uma observação histórica de abuso ou comprometimento durante a campanha. Não significa que o ativo permaneça comprometido atualmente e não deve ser interpretada como recomendação de bloqueio do domínio institucional.

Arquivos, hashes e artefatos de persistência

Os artefatos abaixo foram observados em diferentes ondas da operação e incluem loaders, documentos, componentes da cadeia Electron, pacotes de extensão e arquivos utilizados para persistência.

Os hashes são apresentados como indicadores históricos. Nomes de arquivos, por outro lado, devem ser correlacionados com caminho, comportamento e outros sinais da cadeia, já que podem ser alterados entre campanhas.

Persistência, extensão e ferramentas de acesso remoto

Além dos hashes, alguns artefatos de endpoint permaneceram úteis para hunting mesmo quando a infraestrutura ou o nome das amostras mudou.

Remetentes institucionais observados

As contas e os domínios abaixo foram observados como canais de envio em diferentes campanhas associadas ao Shadow Ledger. Em diversos casos, as mensagens partiram de infraestrutura institucional legítima comprometida, o que permitia que o e-mail mantivesse características esperadas de uma comunicação autêntica.

A presença de um endereço ou domínio nesta tabela representa uma observação histórica. Não significa que a conta, o usuário ou a instituição permaneça comprometida atualmente e não deve ser interpretada como recomendação de bloqueio do domínio.

Sites intermediários de ClickFix

Além da infraestrutura institucional, uma onda observada em abril de 2026 utilizou diversos sites .com.br como páginas intermediárias na cadeia de ClickFix.

Assim como ocorre com os ativos governamentais, estes são indicadores históricos de abuso observado durante a investigação. A presença de um domínio nesta lista não significa que o site permaneça comprometido atualmente.

Infraestrutura institucional comprometida

Ao longo da investigação, identificamos uma quantidade significativa de portais municipais, estaduais e outros ativos institucionais comprometidos associados às campanhas do Shadow Ledger.

Esses ativos apareceram em diferentes funções, incluindo hospedagem de payloads, páginas de ofício, ClickFix, distribuição de extensões e outros componentes da cadeia de delivery. Em alguns casos, a mesma infraestrutura foi reutilizada em diferentes ondas da operação.

A lista abaixo não é exaustiva e representa observações históricas. A presença de um domínio não significa que o ativo permaneça comprometido atualmente e não deve ser interpretada como recomendação de bloqueio do domínio institucional.