LESIS - Laboratory of Engineering Studies in Information Security

Nossa primeira observação de um grupo malicioso assistido por IA mirando fintechs brasileiras de pequeno e médio porte

2026-06-29T18:00:00+00:00

O trabalho da LESIS nos coloca, com frequência, em diferentes frentes de segurança ofensiva, resposta a incidentes e inteligência de ameaças. Em uma oportunidade recente, fomos acionados para apoiar uma investigação envolvendo uma instituição financeira brasileira. Nosso papel inicial era responder a uma pergunta objetiva: qual foi o vetor de entrada utilizado pelo agente malicioso?

Para isso, conduzimos uma análise orientada por simulação adversária. Partimos da mesma premissa operacional do atacante: comprometer uma aplicação ou recurso adjacente que permitisse, direta ou indiretamente, chegar a sistemas com potencial de movimentação financeira. Essa abordagem nos permitiu reconstruir parte da cadeia de ataque, identificar o vetor inicial e, posteriormente, localizar mecanismos de persistência usados pelo threat actor.

Durante a investigação, observamos que a persistência implantada pelo grupo se comunicava com infraestrutura externa controlada pelos operadores. A partir desse ponto, aprofundamos a análise da infraestrutura de comando e controle, com o objetivo de entender se havia elementos adicionais que pudessem contribuir para a resposta ao incidente e para a proteção de outros possíveis alvos.

Por razões operacionais, não iremos publicar IoCs, payloads, endereços, nomes de arquivos, caminhos internos ou detalhes que possam comprometer investigações. Ainda assim, os artefatos analisados revelaram um conjunto consistente de comportamentos, ferramentas e padrões de operação.

O que foi observado

A infraestrutura analisada continha payloads, artefatos de apoio à exploração, logs de requisições, scripts de recebimento de dados e evidências de tentativas anteriores contra múltiplos alvos. Em alguns casos, a mesma infraestrutura mantinha informações relacionadas a mais de um alvo ou operação, incluindo tentativas mal sucedidas, atividades em andamento e dados obtidos após comprometimento.

A análise desses materiais nos levou a seis conclusões principais.

Os alvos observados eram fintechs brasileiras, em especial organizações de pequeno e médio porte, com menor exposição midiática e menor maturidade pública em segurança quando comparadas a grandes instituições financeiras.
As evidências indicam a atuação de um grupo, e não de um operador isolado. Essa avaliação é baseada em múltiplos sinais: diferentes identificadores de acesso, atividade concorrente partindo de origens distintas, padrões operacionais incompatíveis com uma única sessão humana contínua e diferenças estilométricas em artefatos de código.
Ao menos um dos operadores aparenta ter familiaridade com o português brasileiro. Essa conclusão vem do uso do idioma em artefatos operacionais e comentários observados durante a análise.
Identificamos evidências de uso de LLMs no apoio à construção de tooling ofensivo. Os artefatos indicam o uso de modelos de linguagem para auxiliar na criação ou adaptação de exploits, web shells, mecanismos de bypass, scripts de exfiltração e componentes auxiliares usados durante a operação.
Observamos tentativas de contornar guardrails de LLMs por meio de contextualização enganosa, em especial levando o modelo a operar sob a premissa de um pentest autorizado. Esse padrão é relevante porque mostra que o uso de IA pelo grupo não se limitou à produtividade: ele também foi incorporado ao processo de desenvolvimento ofensivo.
Um ponto relevante observado foi a duração de uma das operações associadas a esse conjunto de artefatos. Em um dos alvos, identificamos atividade distribuída ao longo de aproximadamente três meses, o que indica uma intenção direta e contínua contra a organização comprometida. Esse comportamento reduz a hipótese de uma tentativa oportunista isolada e reforça a avaliação de que o grupo mantinha interesse operacional no alvo, adaptando sua abordagem conforme encontrava barreiras, novas oportunidades de acesso e caminhos potenciais para ampliar o impacto.

Cadeia de ataque

O vetor comum observado foi a exploração de vulnerabilidades em nível de aplicação. O grupo não parecia depender exclusivamente de aplicações diretamente ligadas a fluxos financeiros. Pelo contrário: buscava aplicações na mesma infraestrutura ou em ambientes adjacentes que pudessem servir como ponto de entrada para movimentação lateral.

Após o acesso inicial, o grupo procurava credenciais, arquivos de configuração, variáveis de ambiente, integrações internas e recursos de administração que pudessem ampliar o acesso.

Nos casos em que o comprometimento avançou, a persistência foi simples. Não observamos, nos artefatos analisados, um esforço sofisticado de ocultação. O objetivo parecia ser funcionalidade e velocidade operacional, não furtividade avançada. Isso não reduziu o impacto potencial da operação: mesmo implantes simples podem ser suficientes quando combinados com credenciais válidas, segmentação fraca, permissões excessivas e baixa visibilidade de tráfego egresso.

Em pelo menos um caso, os controles existentes impediram a comunicação direta entre o implante e a infraestrutura externa. A resposta do grupo foi adaptar a operação. Observamos tentativas de entrega de payloads blinds, probing de diferentes portas e ajustes sucessivos para entender o controle aplicado e decidir como contorná-lo. Esse comportamento indica capacidade operacional e persistência, ainda que o tooling em si não seja particularmente sofisticado.

Também observamos foco na exfiltração de credenciais. O grupo buscava acesso a outras aplicações e serviços usados por colaboradores da organização comprometida, sugerindo interesse em escalar o ataque para além do primeiro sistema explorado.

Por que isso importa

Há três pontos que tornam essa campanha relevante:

O primeiro é a escolha dos alvos: as fintechs brasileiras de pequeno e médio porte podem operar ativos financeiros relevantes, integrações críticas e fluxos transacionais sensíveis, mas nem sempre possuem a mesma capacidade de detecção, resposta e hardening encontrada em grandes instituições financeiras. Isso cria uma superfície atrativa para grupos financeiramente motivados.
O segundo é o papel das aplicações como ponto de entrada: a operação reforça um padrão recorrente em muitas organizações, o caminho até o impacto financeiro não começa necessariamente no sistema financeiro principal. Ele pode começar em uma aplicação legada, um serviço administrativo, uma integração pouco monitorada ou um componente interno que compartilha infraestrutura com sistemas mais críticos.
O terceiro é o uso de IA como acelerador: o uso de LLMs não transforma automaticamente um operador comum em um ator avançado, mas reduz custo, acelera iteração e facilita a adaptação de tooling. Na prática, isso permite que grupos com capacidade intermediária produzam mais variações de payloads, testem hipóteses mais rapidamente e contornem obstáculos com menor dependência de conhecimento especializado profundo.

TTPs observadas — MITRE ATT&CK

Descrição comportamental (TTPs) do grupo, não inclui IoCs (IPs, hashes, nomes de arquivos, caminhos internos ou nomes de vítimas).

Tática	Técnica (ATT&CK)	Comportamento observado
Desenvolvimento de Recursos (TA0042)	Obtain Capabilities: Tool (T1588.002)	Uso de exploits públicos prontos em conjunto com scripts próprios (assistida por IA / agêntica)
Desenvolvimento de Recursos (TA0042)	Develop Capabilities (T1587)	Geração de tooling, playbooks e relatórios assistida por IA / agêntica
Acesso Inicial (TA0001)	Exploit Public-Facing Application (T1190)	Exploração em nível de aplicação contra serviços expostos (aplicações legadas e modernas)
Descoberta (TA0007)	Network Service Discovery (T1046)	Reconhecimento da rede interna, a partir do acesso obtido, contra serviços adjacentes
Execução / Movimentação Lateral (TA0002 / TA0008)	Server-Side abuse → console de administração (T1190 → T1505.003)	Pivô para console de administração/deploy a fim de implantar código
Persistência (TA0003)	Web Shell (T1505.003) + Masquerading (T1036)	Web shells disfarçados de endpoints legítimos da própria aplicação (health check)
Escalonamento de Privilégios (TA0004)	Escape to Host (T1611)	Acesso container-para-host por isolamento deficiente do contêiner
Acesso a Credenciais (TA0006)	Credentials in Files / Private Keys (T1552.001 / .004)	Coleta de credenciais em arquivos de configuração e chaves, e de segredos expostos em artefatos
Acesso a Credenciais (TA0006)	Steal Application Access Token (T1528)	Furto de tokens de acesso para reuso (replay)
Acesso a Credenciais (TA0006)	Brute Force: Password Cracking (T1110.002)	Quebra offline de hashes exfiltrados com wordlists contextuais
Coleta (TA0009)	Email Collection (T1114)	Download em massa de caixas de e-mail e busca direcionada por credenciais de acesso remoto e de sistemas financeiros
Evasão de Defesas (TA0005)	Account Manipulation (T1098)	Alteração do hash de senha de um administrador para um valor conhecido
Comando e Controle (TA0011)	Non-Standard Port / Fallback Channels (T1571 / T1008)	Quando o tráfego egresso foi bloqueado: payloads blind, varredura de múltiplas portas e ajuste iterativo de canal
Impacto (TA0040)	Financially-motivated targeting (intenção)	Foco em dados e credenciais de pagamento, crédito e banking

Conclusão

Essa investigação mostra um grupo com motivação financeira, foco setorial claro e capacidade de adaptar tooling conforme os controles encontrados no ambiente da vítima. O uso de IA aparece como um elemento de aceleração operacional, especialmente na criação e modificação de ferramentas ofensivas, mas não substitui os fundamentos tradicionais da intrusão: exploração de aplicação, coleta de credenciais, movimentação lateral, persistência e busca por impacto financeiro.

Não publicaremos IoCs ou detalhes técnicos sensíveis neste momento. A decisão é intencional: preservar vantagem de inteligência, proteger vítimas potenciais e evitar que a infraestrutura ou os métodos observados sejam rapidamente alterados pelos operadores.

Caso sua organização queira acesso ao relatório técnico detalhado, entre em contato conosco. Estamos sempre disponíveis para colaboração com times de segurança, resposta a incidentes e inteligência de ameaças.

Dependabot: automatizando a atualização de dependências no GitHub

2026-06-25T11:00:00+00:00

Manter dependências atualizadas é uma das tarefas mais negligenciadas no ciclo de vida de um projeto de software. Não por descuido ou desconhecimento, mas porque o trabalho cotidiano impõe prioridades mais visíveis: funcionalidades, correções de bugs, prazos. Dependências desatualizadas raramente geram sintomas imediatos. Os problemas que elas introduzem costumam aparecer tarde, e quando aparecem, o custo é alto.

Foi partindo desse diagnóstico que decidimos configurar o Dependabot nos nossos repositórios. Este texto descreve o que é a ferramenta, como ela funciona, como fizemos a configuração e o que aprendemos no processo.

O problema das dependências

Todo projeto de software moderno depende de bibliotecas externas. Essas bibliotecas, por sua vez, têm suas próprias dependências. À medida que o tempo passa, versões novas são publicadas, com correções de bugs, melhorias de desempenho e, principalmente, correções de vulnerabilidades de segurança.

Quando uma vulnerabilidade é descoberta em uma biblioteca amplamente usada, ela pode receber um identificador CVE (Common Vulnerabilities and Exposures) e passar a ser registrada em bases públicas de vulnerabilidades e advisories. A partir desse momento, a falha deixa de ser apenas um risco teórico: ela passa a ser uma informação conhecida publicamente, inclusive por pessoas com intenção maliciosa. Projetos que ainda utilizam a versão vulnerável permanecem expostos até que a atualização seja feita.

O problema é que acompanhar esse fluxo manualmente, em vários repositórios, com várias linguagens e gerenciadores de pacotes diferentes, é inviável na prática. Sem automação, esse processo tende a se tornar inconsistente, atrasado ou simplesmente esquecido.

O que é o Dependabot

O Dependabot é uma ferramenta do GitHub que monitora as dependências dos repositórios e abre pull requests automaticamente quando identifica versões mais recentes ou vulnerabilidades conhecidas. Ele opera diretamente dentro da infraestrutura do GitHub, sem necessidade de instalação ou configuração de servidores externos.

A ferramenta funciona em dois modos complementares. O primeiro é o monitoramento de segurança. Quando uma vulnerabilidade é registrada no GitHub Advisory Database e afeta uma dependência presente no projeto, o GitHub pode gerar um alerta no repositório. Quando os security updates estão habilitados, o Dependabot pode abrir automaticamente um pull request com a versão corrigida ou com uma atualização que remova a exposição identificada.

O segundo modo é a atualização de versão. Independentemente de vulnerabilidades, o Dependabot verifica periodicamente se há versões mais recentes das dependências e propõe as atualizações de forma automatizada.

Em ambos os casos, o resultado é um pull request que o time pode revisar, testar e aprovar. A decisão final permanece com as pessoas. O que muda é que o trabalho de monitoramento e de preparação da atualização deixa de ser manual.

Como configurar

A configuração do Dependabot é feita por meio de um arquivo chamado dependabot.yml, que deve estar dentro da pasta .github do repositório.

Um exemplo básico para projetos que usam npm é:

version: 2

updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"

Esse arquivo instrui o Dependabot a verificar, uma vez por semana, as dependências npm declaradas na raiz do projeto. A partir dessa configuração, a ferramenta passa a acompanhar novas versões disponíveis e pode abrir pull requests automaticamente quando houver atualizações.

Em repositórios com muitas dependências, uma configuração um pouco mais controlada pode ser mais adequada:

version: 2

updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "monday"
      time: "09:00"
      timezone: "America/Sao_Paulo"
    open-pull-requests-limit: 5

Nesse caso, além de definir a frequência, também especificamos o dia, o horário e o fuso horário da verificação. O parâmetro open-pull-requests-limit ajuda a controlar o volume de pull requests abertos ao mesmo tempo, evitando que a primeira execução da ferramenta gere mais trabalho do que o time consegue revisar.

A configuração também aceita variações relevantes: é possível ignorar pacotes específicos, definir labels, configurar mensagens de commit, agrupar atualizações e declarar múltiplos ecossistemas dentro de um mesmo repositório, caso o projeto utilize linguagens ou gerenciadores de pacotes diferentes em pastas distintas.

No caso do blog da LESIS, por exemplo, a configuração precisou contemplar mais de um ecossistema. Além das dependências Ruby gerenciadas pelo Bundler, também configuramos o Dependabot para acompanhar atualizações dos workflows do GitHub Actions:

version: 2

updates:
  - package-ecosystem: "bundler"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "monday"
      time: "03:00"
      timezone: "America/Sao_Paulo"
    open-pull-requests-limit: 5
    labels:
      - "dependencies"
      - "ruby"
    commit-message:
      prefix: "chore(deps)"
      prefix-development: "chore(deps-dev)"
      include: "scope"
    groups:
      production:
        dependency-type: "production"
        update-types:
          - "minor"
          - "patch"
      production-major:
        dependency-type: "production"
        update-types:
          - "major"

  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "monday"
      time: "04:00"
      timezone: "America/Sao_Paulo"
    open-pull-requests-limit: 5
    labels:
      - "dependencies"
      - "github-actions"
    commit-message:
      prefix: "ci"
      include: "scope"
    groups:
      minor-patch:
        update-types:
          - "minor"
          - "patch"
      major:
        update-types:
          - "major"

Nesse exemplo, o bundler monitora as gems do projeto, enquanto github-actions monitora as actions utilizadas nos workflows do repositório. A configuração também define labels específicas para cada ecossistema, prefixos de commit e agrupamentos de atualização.

Os agrupamentos ajudam a organizar o volume de pull requests. No caso das dependências de produção, por exemplo, atualizações minor e patch podem ser agrupadas separadamente das atualizações major, que tendem a exigir mais atenção durante a revisão. O mesmo raciocínio foi aplicado às atualizações do GitHub Actions.

Quando a tarefa foi atribuída, o ponto de partida foi o estudo da ferramenta. O Dependabot não era algo familiar até então, então antes de qualquer configuração foi necessário entender como funcionava, o que ele monitorava e quais eram as opções disponíveis. Esse tempo de estudo foi necessário e valeu a pena: a configuração em si, depois de compreender a ferramenta, foi direta. A documentação do GitHub cobre os casos mais comuns com clareza, e os primeiros pull requests gerados automaticamente apareceram logo após a adição do arquivo.

Limitações que encontramos

Um aprendizado importante do processo foi que o Dependabot não oferece suporte a todos os gerenciadores de pacotes. Em nosso caso, alguns projetos utilizam CPAN, o gerenciador de dependências do Perl, que não está na lista de ecossistemas suportados pela ferramenta. Nesses repositórios, o monitoramento automatizado não é possível com o Dependabot, e o acompanhamento precisa ser feito por outros meios.

Para projetos Perl, o Bunkai, uma ferramenta de análise de composição de software desenvolvida pela LESIS, cobre parte dessa lacuna ao identificar dependências desatualizadas e vulnerabilidades conhecidas em projetos que usam CPAN.

Além disso, vale mencionar que o Dependabot não é a única ferramenta disponível para esse tipo de automação. Uma alternativa livre bastante conhecida é o Renovate, uma ferramenta open source para atualização automatizada de dependências. Assim como o Dependabot, o Renovate identifica dependências desatualizadas e pode abrir pull requests com as atualizações necessárias.

O Renovate pode ser especialmente interessante para equipes que não utilizam GitHub, já que foi projetado para funcionar em diferentes plataformas de hospedagem de código, como GitLab, Bitbucket, Azure DevOps, Forgejo e Gitea. Ele também costuma ser uma opção considerada quando o projeto exige maior flexibilidade de configuração, políticas de atualização mais específicas ou fluxos mais customizados.

No nosso caso, o Dependabot foi uma escolha natural por já estar integrado ao GitHub e exigir pouca configuração inicial. Ainda assim, para projetos fora do ecossistema do GitHub ou com necessidades mais complexas de automação, o Renovate é uma alternativa que vale ser avaliada.

Antes de configurar a ferramenta, vale verificar se os gerenciadores de pacotes utilizados no projeto estão entre os suportados. A lista oficial de ecossistemas compatíveis está disponível na documentação do GitHub e cobre os casos mais comuns, como npm, pip, Maven, Gradle, Composer e RubyGems, entre outros, mas não é universal.

Outro ponto que merece atenção é o volume inicial de pull requests. Em repositórios com muitas dependências que não foram atualizadas há algum tempo, a primeira execução do Dependabot pode gerar um número expressivo de propostas ao mesmo tempo. Isso pode sobrecarregar o fluxo de revisão se não houver um limite configurado. O parâmetro open-pull-requests-limit, no arquivo de configuração, permite controlar esse comportamento.

Por que isso importa

A gestão de dependências não é apenas uma questão de organização interna. É uma questão de segurança com consequências externas. Bibliotecas desatualizadas são um vetor de ataque documentado e explorado ativamente. A diferença entre um projeto vulnerável e um projeto mais seguro, em muitos casos, está na existência de um processo que mantenha as dependências monitoradas e atualizadas.

O Dependabot não substitui uma postura de segurança abrangente, mas resolve uma parte específica do problema de forma confiável e com baixo custo de configuração. Ele transforma uma tarefa que tenderia a ser esquecida em um processo contínuo, auditável e integrado ao fluxo normal de trabalho do time.

Conclusão

A experiência de configurar o Dependabot nos nossos repositórios foi positiva. O esforço inicial é pequeno, a integração com o GitHub é nativa, e o resultado, dependências monitoradas de forma contínua, justifica com folga o tempo investido.

As limitações existem e devem ser conhecidas antes de criar expectativas. Nem todos os ecossistemas são suportados, e o volume de pull requests pode exigir ajuste fino na configuração. Mas, para os repositórios compatíveis, a ferramenta entrega exatamente o que promete.

Mais do que uma conveniência, manter dependências atualizadas é uma responsabilidade. A automação não elimina essa responsabilidade; ela ajuda a garantir que ela seja cumprida de forma consistente.

Referências

Escolhendo o método correto para compartilhar identificadores

2026-05-05T11:00:00+00:00

Introdução

Alguns problemas de segurança aparecem justamente quando duas empresas legítimas querem colaborar.

Imagine uma instituição financeira digital com uma base muito grande de clientes e um marketplace preparando uma promoção exclusiva para clientes dessa instituição. O marketplace precisa saber, durante a campanha, quais pessoas também são clientes da instituição financeira para aplicar o benefício corretamente.

O problema parece simples: uma empresa tem a lista de clientes elegíveis, a outra tem sua própria base de usuários, e a promoção deve valer apenas para a interseção entre as duas bases.

Mas existe uma pergunta importante: como permitir essa comparação sem expor mais dados pessoais do que o necessário?

O cenário

A necessidade de negócio era direta: uma campanha promocional deveria ser oferecida por um parceiro comercial apenas para clientes da instituição financeira.

Como a instituição financeira tinha uma base de clientes maior do que a base do parceiro, simplesmente enviar todos os CPFs de seus clientes para o parceiro permitiria a comparação, mas exporia muito mais pessoas do que o necessário.

A primeira proposta do time responsável pela integração era criptografar um arquivo contendo todos os CPFs dos clientes elegíveis e transmiti-lo por um canal seguro. O parceiro receberia o arquivo, descriptografaria, compararia com sua própria base e identificaria quais usuários eram elegíveis.

Do ponto de vista de transporte, isso parece razoável. O arquivo estaria protegido durante o envio. O canal poderia ser autenticado. O acesso poderia ser restrito.

Mas o problema principal não era apenas transporte. O problema era minimização.

Ao final do processo, o parceiro teria acesso a uma lista completa de CPFs de clientes da instituição financeira, inclusive pessoas que talvez nem tivessem conta no marketplace, nunca participassem da campanha ou nunca precisassem ser conhecidas pelo parceiro. A criptografia protegeria o arquivo no caminho, mas não reduziria o dado revelado ao destinatário.

Criptografia resolve outro problema

Criptografia é uma ferramenta de confidencialidade. Ela protege dados contra quem não deve acessá-los durante armazenamento ou transmissão. Se um arquivo criptografado é interceptado por alguém sem a chave, o conteúdo permanece protegido.

Mas, em muitos fluxos de integração, o destinatário legítimo precisa abrir o arquivo. Depois que ele descriptografa o conteúdo, passa a enxergar os valores originais.

Nesse caso, criptografia respondia à pergunta:

Como enviar a lista de CPFs sem que terceiros leiam o arquivo no caminho?

Mas havia uma segunda pergunta que ainda precisava ser respondida:

Como permitir que o parceiro descubra apenas quais clientes já existem na própria base, sem receber a lista completa da instituição financeira?

Essas perguntas parecem parecidas, mas são problemas diferentes. A primeira é sobre confidencialidade em trânsito e continuava sendo necessária. A segunda é sobre minimização de dados e exposição ao destinatário. O ponto não era substituir criptografia, mas reconhecer que ela precisava ser combinada com um desenho que revelasse menos informação.

Onde hashes ajudam

Um hash criptográfico transforma uma entrada em uma saída de tamanho fixo. Para a mesma entrada, o resultado é sempre o mesmo. Para entradas diferentes, espera-se que os resultados sejam diferentes. Bons algoritmos de hash também tornam impraticável recuperar a entrada original a partir da saída, desde que a entrada tenha entropia suficiente.

Essa propriedade determinística permite comparação sem transmitir o valor original.

Por exemplo, em vez de compartilhar:

123.456.789-10

uma empresa poderia compartilhar:

sha256("12345678910") = 01b6...f3a9

Se o parceiro normalizar seus próprios CPFs da mesma forma e calcular o mesmo hash, ele pode comparar os hashes. Quando houver igualdade, existe um CPF em comum.

O ganho de privacidade é intuitivo: em vez de revelar diretamente os CPFs, as empresas comparam representações derivadas. O parceiro só deveria conseguir reconhecer os CPFs que já conhece, porque precisa ter o valor original em sua própria base para gerar o mesmo hash.

Essa ideia é útil, mas há uma armadilha importante.

CPF é enumerável

Desenvolvedores muitas vezes aprendem hash no contexto de senhas. Nesse contexto, a entrada idealmente é secreta, escolhida pelo usuário e difícil de adivinhar. Mesmo assim, senhas exigem algoritmos específicos como Argon2, bcrypt ou scrypt, além de salt, custo computacional e boas políticas de armazenamento.

CPF é diferente.

CPF tem formato conhecido, quantidade limitada de combinações e dígitos verificadores. Isso significa que um atacante pode gerar muitos CPFs candidatos, calcular seus hashes e comparar com uma lista vazada. Esse é o princípio de ataques por dicionário ou rainbow table.

Por isso, a seguinte abordagem é fraca:

sha256(cpf_normalizado)

Ela não revela o CPF de forma direta, mas também não deve ser tratada como anonimização. Para identificadores previsíveis, hash simples costuma ser reversível por força bruta ou pré-computação.

Esse ponto é essencial: hash não é mágica. A segurança depende tanto do algoritmo quanto da natureza da entrada.

Normalização importa

Antes de qualquer comparação, os dois lados precisam chegar exatamente à mesma representação do identificador.

No caso de CPF, isso normalmente significa remover pontuação, validar comprimento, preservar zeros à esquerda e rejeitar valores inválidos ou malformados. Caso contrário, o mesmo CPF pode produzir hashes diferentes:

123.456.789-10
12345678910

Essas duas strings têm aparência equivalente para uma pessoa, mas são entradas diferentes para um algoritmo de hash.

Toda estratégia de comparação precisa documentar a normalização antes de documentar o algoritmo. Sem isso, o processo produz falsos negativos, inconsistência operacional e dificuldades de auditoria.

Salt nem sempre resolve

Uma reação comum é adicionar salt:

sha256(salt || cpf_normalizado)

Em armazenamento de senhas, salt é fundamental porque impede que o mesmo valor gere o mesmo hash em bases diferentes e dificulta tabelas pré-computadas genéricas. Mas, em um processo de comparação entre duas empresas, as duas partes precisam gerar o mesmo resultado para o mesmo CPF.

Se cada empresa usar um salt diferente, os hashes não baterão. Se o salt for compartilhado entre as empresas, ele ajuda contra algumas tabelas pré-computadas externas, mas não impede que uma parte com acesso ao salt enumere CPFs candidatos e calcule seus hashes.

Salt é útil, mas não resolve sozinho o problema de identificadores previsíveis em uma integração de matching.

HMAC com API como caminho pragmático

Uma alternativa melhor do que hash simples é usar HMAC:

hmac_sha256(chave_secreta, cpf_normalizado)

HMAC usa uma chave secreta no cálculo. Sem a chave, um terceiro que obtenha a lista de HMACs não consegue calcular facilmente os valores correspondentes para CPFs candidatos. Isso reduz bastante o risco de ataques offline por terceiros.

Mas há uma questão de desenho. Se a chave for compartilhada com o parceiro para que ele calcule HMACs sobre a própria base, ele também consegue calcular HMACs para CPFs candidatos por conta própria. Isso pode ser aceitável em alguns cenários, desde que a chave seja específica para a campanha, tenha rotação, escopo limitado e controles de auditoria, mas muda o modelo de confiança.

Um caminho pragmático seria combinar HMAC com uma API controlada pela instituição financeira. Nesse desenho, o marketplace prepara a própria base, normaliza os CPFs, calcula os identificadores derivados conforme a especificação da campanha e envia um lote para a API. A instituição financeira compara esses valores contra uma representação equivalente da própria base e devolve apenas o resultado necessário para a campanha. Esse resultado não precisa ser uma nova lista de CPFs. Pode ser uma marcação de elegibilidade associada aos usuários do próprio marketplace.

Um exemplo simples seria:

Marketplace envia:
user_id=10, hmac_cpf=aaa
user_id=20, hmac_cpf=bbb
user_id=30, hmac_cpf=ccc

Após a comparação, a API poderia responder:

user_id=10, eligible=true
user_id=20, eligible=false
user_id=30, eligible=true

Com isso, o marketplace consegue aplicar a campanha dentro da própria base, mas não recebe a lista completa de CPFs da instituição financeira. O CPF é usado como chave técnica de comparação, mas o resultado operacional é uma marcação de elegibilidade.

Essa abordagem muda o problema para um modelo de consulta controlada. Se a API permite testar CPFs arbitrários, mesmo que com autenticação e HMAC, ela pode virar um oráculo de elegibilidade. Por isso, esse tipo de solução precisa de controles adicionais: aceitar apenas lotes associados à base declarada do parceiro, limitar reprocessamentos, auditar consultas, impor janelas de campanha e definir claramente o que é permitido testar. Em outras palavras, HMAC e API podem formar uma solução prática, mas a garantia passa a depender de governança e controle operacional. Para cenários que exigem uma garantia técnica mais forte sobre o que cada parte aprende, existe uma abordagem mais sofisticada.

Uma alternativa mais sofisticada: interseção privada de conjuntos

Uma alternativa mais sofisticada para esse tipo de problema é conhecida como interseção privada de conjuntos, ou Private Set Intersection (PSI).

Em termos simples, PSI é uma família de protocolos criptográficos que permite que duas partes comparem conjuntos e descubram uma interseção sem compartilhar os conjuntos em claro. A ideia não é “criptografar uma lista e entregar para o outro lado”. A ideia é executar um processo em que cada parte mantém seu conjunto e participa de uma comparação protocolada.

Um exemplo pequeno ajuda a visualizar o objetivo. Suponha que a instituição financeira tenha os CPFs 111, 222, 333 e 444. O parceiro tem os CPFs 222, 444 e 555. O resultado necessário para a campanha é saber que 222 e 444 estão nos dois conjuntos. O parceiro não precisa aprender que 111 e 333 existem na base da instituição financeira. A instituição financeira também não precisa aprender que 555 existe na base do parceiro, a menos que o desenho do protocolo ou da campanha exija isso.

Em uma comparação comum usando arquivo, uma das partes recebe uma lista e faz a interseção localmente. Isso é simples, mas obriga essa parte a enxergar valores que não fazem parte do resultado final. Em uma API de consulta, por outro lado, a instituição financeira pode evitar entregar sua base inteira ao marketplace, mas passa a observar o lote que o marketplace está consultando. Isso pode ser aceitável. Mas, se o requisito também for reduzir o que a instituição financeira aprende sobre a base do marketplace, uma API centralizada pode não ser suficiente.

Existem diferentes formas de implementar PSI. Algumas usam criptografia de chave pública, outras usam oblivious transfer, circuitos garbled ou construções baseadas em hashing e chaves efêmeras. O detalhe matemático muda conforme o protocolo, mas o objetivo de segurança permanece: permitir matching entre conjuntos sem transformar uma integração em compartilhamento amplo de base.

Também é importante observar que PSI não define apenas “como comparar”. Ele ajuda a definir “quem aprende o quê”. Em alguns desenhos, as duas partes aprendem a interseção. Em outros, apenas uma parte aprende quais usuários são elegíveis. Para o caso da promoção, esse segundo modelo faz mais sentido: o marketplace precisa aplicar o benefício dentro da própria base, enquanto a instituição financeira não precisa necessariamente aprender quais clientes também estão no marketplace.

Aplicado ao caso da promoção, o resultado desejado talvez não fosse uma nova lista de CPFs compartilhada entre empresas. Poderia ser apenas uma forma de o parceiro marcar, dentro da própria base, quais usuários são elegíveis. Essa distinção reduz exposição porque mantém o foco no resultado operacional da campanha, não na circulação de identificadores.

PSI, porém, não elimina todos os riscos. Se uma parte puder escolher livremente o conjunto de entrada, ela ainda pode tentar testar identificadores que não pertencem à sua base legítima. Por isso, PSI não substitui contrato, auditoria, controles de escopo e validação do processo. O que ele melhora é outro ponto: reduz a necessidade de uma parte entregar sua base inteira em claro, e pode reduzir também o quanto a outra parte observa durante a comparação.

Na prática, PSI é mais complexo do que uma API com HMAC. Ele exige biblioteca adequada, entendimento do protocolo, cuidado com normalização, tratamento de erros, auditoria, testes de performance e avaliação do que cada parte aprende durante o processo. Nem todo caso exige esse nível de sofisticação. Mas ele deve ser considerado quando o requisito não é apenas evitar que o marketplace receba a base inteira da instituição financeira, mas também reduzir o quanto a instituição financeira aprende sobre o conjunto do marketplace durante o matching.

Uma hierarquia prática de soluções

Nem toda integração precisa do mesmo nível de proteção. Uma forma pragmática de pensar é organizar as opções por redução de exposição.

Um arquivo com CPFs criptografado em trânsito protege contra interceptação, mas revela a lista completa ao destinatário. É simples, mas fraco em minimização.

Hash simples dos CPFs evita exposição direta casual, mas é vulnerável a enumeração porque CPF é previsível. Não deve ser tratado como anonimização.

HMAC com chave controlada melhora a proteção contra terceiros e vazamentos da lista derivada, mas exige governança forte sobre a chave. Em vez de compartilhar a chave com o parceiro, uma API autenticada usando HMAC pode ser uma alternativa prática quando o objetivo é responder elegibilidade sem entregar a base inteira da instituição financeira, desde que não permita consultas arbitrárias sem controle.

PSI ou um protocolo equivalente é uma opção mais sofisticada quando também há interesse em reduzir o que a instituição financeira aprende sobre o conjunto consultado pelo marketplace, além de evitar a entrega da base inteira ao parceiro.

Essa hierarquia ajuda a explicar por que a resposta inicial de “vamos criptografar o arquivo” era insuficiente. A pergunta não era apenas como transportar dados com segurança. A pergunta era quanto dado precisava ser revelado para atingir o objetivo.

Conclusão

Uma revisão de segurança para esse tipo de compartilhamento deve começar por perguntas simples. Antes de escolher algoritmo, é necessário entender qual é o objetivo exato da comparação, quem precisa aprender o resultado e qual formato esse resultado precisa ter. O resultado precisa ser uma lista de CPFs, uma lista de usuários elegíveis, um booleano por usuário ou apenas uma contagem agregada?

Também é preciso avaliar quais dados de pessoas fora da interseção seriam expostos pela solução proposta. Essa é uma pergunta central, porque uma solução pode parecer segura por usar criptografia e ainda assim revelar um conjunto muito maior do que o necessário ao destinatário legítimo.

Outro ponto importante é a natureza do identificador usado. Se o identificador é previsível ou tem baixa entropia, hash simples não deve ser tratado como proteção forte. A existência de normalização documentada também precisa ser verificada, porque pequenas diferenças de formato podem quebrar a comparação ou criar exceções difíceis de auditar.

Por fim, a revisão deve cobrir quem controla chaves, salts ou segredos, se o processo é auditável e reexecutável, e se existe retenção limitada dos arquivos intermediários e resultados. Essas perguntas evitam que a discussão fique limitada a “o arquivo está criptografado?”. Segurança do transporte importa, mas minimização, finalidade, retenção e modelo de confiança importam tanto quanto.

Criptografia, hash, HMAC, APIs e PSI são ferramentas diferentes para problemas diferentes. A decisão correta depende menos da familiaridade com uma técnica específica e mais do que cada parte precisa aprender durante o processo.

O aprendizado principal desse caso é que “transmitir com segurança” não é o mesmo que “revelar o mínimo necessário”. Em integrações entre empresas, especialmente envolvendo identificadores pessoais, a arquitetura deve começar pela minimização: quem precisa saber o quê, por quanto tempo, e com qual garantia técnica?

Às vezes, a melhor solução não é criptografar melhor o arquivo. É evitar que o arquivo exista daquele jeito.

Referências

Orientações para ofuscação e mascaramento de PII

2026-05-04T13:00:00+00:00

Introdução

Muitas aplicações lidam com informações pessoais identificáveis, conhecidas pela sigla PII: nomes, endereços, e-mails, telefones, documentos, identificadores de dispositivo e outros dados capazes de identificar uma pessoa direta ou indiretamente.

Quando essas informações aparecem em telas de aplicação, logs, relatórios, ferramentas de suporte, notificações ou ambientes não produtivos, o sistema deve evitar expor mais do que o usuário ou operador realmente precisa. Uma forma comum de reduzir essa exposição é mascarar ou ofuscar parte do valor.

Essa prática é familiar. Um fluxo de recuperação de senha pode mostrar apenas parte de um e-mail. Um painel de suporte pode exibir somente os últimos dígitos de um telefone. Uma interface bancária pode mostrar um identificador fiscal parcialmente oculto. Ainda assim, os detalhes costumam ser inconsistentes. Sistemas diferentes escolhem caracteres visíveis diferentes, quantidades diferentes e formatos diferentes.

Essa inconsistência importa. Se a mesma PII é mascarada de formas diferentes em várias aplicações, cada aplicação pode revelar um fragmento diferente. Um atacante capaz de acionar ou observar esses fluxos pode combinar os fragmentos e reconstruir o valor original.

Este artigo propõe orientações práticas para mascarar campos comuns de PII. O objetivo não é definir um padrão legal universal, mas fornecer uma base técnica para pessoas de engenharia, segurança e produto que precisam de comportamento consistente ao exibir ou processar dados pessoais.

Ofuscação, mascaramento e anonimização

Os termos costumam ser usados como sinônimos, mas não significam a mesma coisa.

Mascaramento é a substituição de parte de um valor por um marcador fixo, normalmente para ocultar caracteres sensíveis enquanto preserva contexto suficiente para reconhecimento. Por exemplo, user.name@example.com pode se tornar u*******e@e*****e.com.

Ofuscação é uma prática mais ampla de tornar dados mais difíceis de entender ou interpretar. Mascaramento é um tipo de ofuscação, mas nem toda ofuscação é mascaramento. Ofuscação também pode incluir tokenização, redação, truncamento ou transformações que preservam formato.

Um exemplo de ofuscação que não é apenas mascaramento é substituir um e-mail por um identificador opaco. Em vez de exibir heitor.gouvea@lesis.lat como h***********a@l***s.lat, o sistema poderia exibir user_8f3a91. Nesse caso, o valor original não aparece parcialmente. Ele foi substituído por um identificador opaco. Isso pode ser tokenização ou pseudonimização, dependendo de como o mapeamento com o valor original é mantido.

Anonimização significa transformar dados para que uma pessoa não possa mais ser identificada, direta ou indiretamente, usando meios razoavelmente disponíveis. Mascaramento parcial não deve ser tratado como anonimização por padrão. Um e-mail ou telefone mascarado ainda pode ser associado a uma pessoa, especialmente quando combinado com outros dados.

Na prática, o mascaramento é mais útil como controle de minimização de dados. Ele reduz exposição desnecessária. Ele não substitui criptografia, controle de acesso, trilhas de auditoria, limites de retenção ou descarte seguro.

Por que consistência importa

Considere uma pessoa que usa o mesmo alias público em várias redes sociais. Um atacante quer descobrir o e-mail associado a esse alias. Ele não consegue ver o e-mail completo, mas consegue acionar fluxos de recuperação de senha em várias plataformas.

Se cada plataforma mascara o e-mail de uma forma diferente, o atacante pode receber fragmentos como estes:

Plataforma	E-mail mascarado
Instagram	`h*********a@g*l.com`
Twitter	`*************@gmail.com`
LinkedIn	`*****ouvea@gm******`
Facebook	`hei********@gma*om`
Telegram	`***r.**ea@g***.com`

Figura 1: fragmentos de um mesmo e-mail revelados por diferentes regras de mascaramento podem ser combinados para reconstruir o valor original.

Individualmente, cada fragmento pode parecer inofensivo. Juntos, eles podem revelar estrutura suficiente para reconstruir o endereço.

O mesmo problema pode acontecer dentro de uma organização. Se duas aplicações leem o mesmo banco de dados e mascaram um CPF de formas diferentes, cada aplicação pode expor uma parte diferente do valor. Com o tempo, logs, tickets, e-mails, capturas de tela e conversas de suporte podem acumular fragmentos suficientes para enfraquecer a proteção.

Por esse motivo, o mascaramento deve ser tratado como uma decisão compartilhada de política, não como um detalhe local de formatação de interface. O mesmo campo deve ser mascarado da mesma forma em produtos, ferramentas internas, APIs e fluxos operacionais.

Quando mascarar PII

Mascaramento de PII é útil sempre que o valor completo não é necessário para o usuário, operador ou ação de sistema que está sendo executada.

Em sistemas de suporte, atendentes frequentemente precisam confirmar que estão olhando para o cliente correto, mas raramente precisam do documento completo, telefone completo ou e-mail completo. Mostrar um fragmento limitado pode ser suficiente para verificação enquanto reduz a exposição na interface de suporte.

Em testes de restauração de backup, times podem precisar de formato e volume de dados realistas, mas não deveriam precisar de acesso a identificadores reais de clientes. Mascarar ou substituir PII durante a restauração pode preservar o valor operacional do teste sem expor dados pessoais desnecessariamente em ambientes não produtivos.

Em analytics e treinamento de modelos, dados de produção podem conter sinais que dados sintéticos não reproduzem bem. Mesmo assim, o padrão deve ser remover, mascarar, agregar ou tokenizar PII, a menos que o valor completo seja estritamente necessário e legalmente justificado.

Em logs e sistemas de observabilidade, o mascaramento é especialmente importante porque logs costumam ser copiados, indexados, retidos, exportados e acessados por grupos operacionais mais amplos. Um campo seguro em um banco de produção restrito pode se tornar arriscado quando repetido em pipelines de logs.

Princípios gerais de mascaramento

Decisões de mascaramento devem seguir algumas regras simples.

Revele o mínimo necessário para completar o fluxo. Se a pessoa usuária só precisa distinguir entre dois telefones, os dois ou quatro últimos dígitos podem ser suficientes. Se um operador só precisa saber que um e-mail foi enviado para o domínio esperado, a parte local completa não deve ficar visível.

Mantenha o formato reconhecível quando isso ajudar a usabilidade. Por exemplo, preservar pontuação em um CPF ou telefone pode ajudar a reconhecer o tipo de campo sem expor o valor completo.

Evite revelar informações estruturais de alto valor. Em alguns identificadores, certos dígitos têm significado. Em CPFs brasileiros, por exemplo, os dois últimos dígitos são verificadores e o nono dígito pode indicar a região de emissão. Uma regra de mascaramento deve considerar essa semântica em vez de ocultar caracteres aleatórios.

Use uma regra de mascaramento por tipo de campo e aplique-a em todos os lugares. Se a política para um e-mail é revelar o primeiro e o último caractere da parte local e do rótulo principal do domínio, toda aplicação deve usar a mesma regra.

Não use mascaramento parcial como única proteção para armazenamento sensível. Se o valor original precisa ser mantido, proteja-o com controle de acesso, criptografia quando apropriado, auditoria rigorosa e limites de retenção. O mascaramento deve controlar principalmente exposição na camada de apresentação, exportação, logging ou dados derivados.

O mascaramento deve acontecer o mais perto possível da superfície de exposição: interface, logs, exportações, mensagens, relatórios e ambientes derivados. Ele não deve ser confundido com transformar o dado original no banco sem uma necessidade clara.

Padrões recomendados

Os padrões abaixo oferecem um ponto de partida prático. Eles são exemplos de baseline, não regras universais. Cada organização deve validar os campos conforme jurisdição, ameaça e necessidade operacional, mas o ponto central é a consistência.

Campo	Valor original	Valor mascarado	Orientação
CPF	`111.222.333-00`	`**.222.33-**`	Oculte os três primeiros dígitos, o nono dígito e os dois dígitos verificadores. Preserve a pontuação apenas para legibilidade.
E-mail	`user.name@example.com.br`	`u*****e@e***e.com.br`	Revele apenas o primeiro e o último caractere da parte local e do rótulo principal do domínio. Preserve sufixos públicos, como `.com.br`, quando necessário para reconhecimento.
Telefone	`(11) 91234-5678`	`(11) 9**-78`	Preserve código de país ou DDD apenas quando necessário para roteamento ou reconhecimento. Revele a menor quantidade possível de dígitos finais exigida pelo fluxo.
Endereço IPv4	`203.0.113.42`	`203.0.113.***`	Para exibição, oculte o octeto de host. Para analytics, prefira agregação por sub-rede quando possível.
Endereço IPv6	`2001:db8:abcd:0012:0000:0000:0000:0001`	`2001:db8:abcd:0012:**:::**`	Preserve apenas o prefixo de rede necessário para uso operacional. Oculte segmentos específicos de interface.
Documento	`12.345.678-9`	`*.345.67-*`	Trate documentos nacionais ou regionais como identificadores estruturados. Oculte dígitos verificadores e evite expor todas as posições semânticas.
Placa de veículo	`ABC1D23`	`A*123`	Revele apenas o mínimo necessário para reconhecimento pelo usuário. Evite expor caracteres suficientes para identificar unicamente o veículo em bases pequenas.
IMEI	`356938035643809`	`35693803*****09`	Revele apenas o TAC ou dígitos finais quando houver necessidade operacional. Evite mostrar o identificador completo do dispositivo em logs ou ferramentas de suporte.

Esses exemplos são intencionalmente conservadores. A quantidade exata de caracteres visíveis pode mudar conforme o fluxo, mas cada sistema deve tomar essa decisão explicitamente.

Orientações de implementação

A lógica de mascaramento deve viver em código compartilhado, não ser reimplementada independentemente em cada tela ou serviço. Uma pequena biblioteca ou serviço compartilhado reduz inconsistência e facilita futuras mudanças de política.

Em organizações com múltiplos sistemas, a forma mais prática de garantir consistência é adotar uma biblioteca padrão de mascaramento. Em vez de explicar a política completa para cada time e revisar manualmente cada implementação, a empresa pode recomendar uma interface única para campos como CPF, e-mail, telefone, IP e documentos.

Isso torna a verificação mais simples. Em vez de validar se cada projeto implementou corretamente cada regra, a revisão passa a verificar se o projeto está usando a biblioteca aprovada. A política continua importante, mas sua aplicação fica centralizada, testável e mais fácil de evoluir.

Em algumas empresas, pode fazer sentido desenvolver uma biblioteca interna para isso, especialmente quando existem regras regulatórias, formatos locais, requisitos de auditoria ou padrões de produto específicos. Essa biblioteca pode incluir testes, documentação, exemplos de uso e versionamento claro para mudanças de comportamento.

Mudanças em regras de mascaramento devem ser versionadas e comunicadas, porque podem afetar suporte, auditoria, testes e integrações que dependem do formato exibido. Se uma regra muda, a alteração deve ser tratada como mudança de comportamento da biblioteca, não como detalhe interno invisível.

Para empresas que usam LLMs ou GenAI no desenvolvimento, o mesmo princípio também se aplica. A recomendação de mascaramento pode fazer parte de uma skill, guideline ou pacote de contexto usado pelos assistentes internos, instruindo o modelo a usar a biblioteca padrão em vez de gerar novas implementações de mascaramento a cada projeto.

Cada função de mascaramento deve receber um valor normalizado e retornar uma representação mascarada. Normalização e mascaramento são preocupações relacionadas, mas separadas. Por exemplo, um telefone pode ser normalizado internamente para o formato E.164, enquanto a camada de exibição pode formatá-lo para a localidade do usuário antes de aplicar o padrão visível.

Campos de PII devem ser mascarados antes de entrar em pipelines de log, observabilidade ou analytics. Depois que o dado sensível foi indexado, replicado e retido, a correção fica muito mais difícil.

O tamanho da entrada importa. Valores curtos não devem vazar informação demais por acidente. Se a parte local de um e-mail tem apenas dois caracteres, revelar o primeiro e o último caractere revela a parte local inteira. Nesses casos, mascare o segmento inteiro ou revele apenas um caractere.

A política também deve definir o que acontece com valores inválidos ou inesperados. Uma função de mascaramento deve falhar de forma fechada: se ela não conseguir interpretar um valor com segurança, deve retornar uma representação totalmente mascarada ou redigida em vez da entrada original.

Por fim, teste comportamento de mascaramento como lógica relevante para segurança. Testes unitários devem cobrir valores normais, valores curtos, valores malformados, formatos internacionalizados, separadores, valores vazios e valores já mascarados. Testes de regressão são úteis porque mudanças acidentais no mascaramento podem aumentar exposição silenciosamente.

Hashing e criptografia são controles diferentes

Mascaramento, hashing e criptografia resolvem problemas diferentes.

Criptografia protege confidencialidade transformando dados com uma chave criptográfica. Se o sistema precisa recuperar o valor original, criptografia pode ser apropriada para armazenamento ou transmissão, dependendo do modelo de ameaça e da gestão de chaves.

Hashing transforma dados em um resumo de tamanho fixo. Ele é útil para verificações de integridade e, com algoritmos adequados de hash de senha, para armazenamento de senhas. Hashes simples de PII previsível costumam ser fracos porque muitos identificadores têm espaços de busca pequenos ou enumeráveis. Se for necessário usar hash de PII para correspondência ou deduplicação, use uma construção com chave ou outro desenho adequado ao risco.

Mascaramento muda o que é exibido ou exportado. Ele não protege o valor original onde esse valor ainda existe. Um campo mascarado em uma interface não significa que o banco de dados está criptografado. Um valor mascarado em um log não significa que sistemas anteriores deixaram de processar a PII original.

Boa engenharia de privacidade normalmente combina esses controles: minimizar coleta, restringir acesso, mascarar exibição, criptografar armazenamento e transporte sensíveis, auditar uso e apagar dados quando eles não forem mais necessários.

Conclusão

Mascaramento de PII é um controle prático para reduzir exposição desnecessária de dados pessoais, mas só funciona bem quando é intencional e consistente.

O risco principal não é apenas mostrar caracteres demais em um lugar. É mostrar caracteres diferentes em lugares diferentes, permitindo que fragmentos sejam combinados. Uma política compartilhada de mascaramento ajuda a prevenir esse modo de falha e dá às pessoas de engenharia um padrão claro para aplicar em aplicações, logs, ferramentas de suporte, exportações e fluxos de dados não produtivos.

Mascaramento deve ser tratado como parte de um programa mais amplo de privacidade e segurança. Ele apoia minimização de dados, melhora a privacidade do usuário e reduz exposição operacional, mas não substitui criptografia, controle de acesso, revisão legal ou boa governança de dados.

Referências

Primitivas e vulnerabilidades

2026-04-26T19:20:00+00:00

Introdução

Na última semana, testei o uso de LLMs para apoiar no processo de pesquisa de vulnerabilidades. Isso me fez pensar: como “ensinar” o modelo a realmente ajudar a encontrar bugs válidos?

Refleti sobre o meu próprio processo: como analiso código, modelo ameaças e chego ao ponto em que algo se torna, de fato, uma vulnerabilidade.

Entendendo, ou criando, primitivas

Em resumo, percebi que tento responder a três perguntas durante as análises:

O que esse código, feature, componente ou endpoint está tentando fazer?
O que ele realmente faz?
O que é possível fazer com ele?

Escolho uma primitiva: a menor parte do sistema que executa uma ação, como uma função, endpoint ou componente. Primeiro tento entender o que ela deveria fazer, usando documentação, nomes e contexto.

Depois observo o que ela realmente faz: executo, testo entradas válidas e inválidas, inspeciono logs e comparo com o comportamento esperado.

Quando encontro uma discrepância entre intenção e realidade, me pergunto: o que dá para fazer com isso? A partir daí mapeio o que um ator malicioso poderia controlar, quais ações ele conseguiria executar e qual seria o impacto.

Se essa diferença permite causar um impacto real, então é uma vulnerabilidade.

Pequenas discrepâncias isoladas às vezes não geram impacto relevante, mas quando encadeadas quase sempre revelam vetores interessantes. Após o olhar no micro, é preciso ter um entendimento do macro: como todas essas primitivas podem ser combinadas.

Agora estou usando alguns prompts que gerei a partir desse entendimento no dia a dia, de maneira automatizada e integrada ao meu workflow. Eles me apoiam no entendimento mais rápido de componentes, na sugestão de entradas de dados mais contextuais, na criação de entradas de teste e na tradução de discrepâncias em possíveis cenários.

Um exemplo simples

Em uma análise passada, testei uma aplicação web e identifiquei uma tela de login. Fiz vários testes, incluindo o uso de um e-mail válido com senhas incorretas, tentando gerar feedbacks diferentes da aplicação para entender melhor o comportamento do fluxo.

Depois de mais de cinco tentativas de login com a senha errada, a aplicação retornou um aviso: a conta estava bloqueada porque o limite de tentativas havia sido excedido.

Pela primeira pergunta, a intenção parecia clara: esse controle existia para prevenir ataques de força bruta.

Pela segunda pergunta, o comportamento real tinha detalhes importantes. O bloqueio não expirava automaticamente, o usuário não tinha uma forma simples de desbloquear a própria conta e nenhuma notificação era enviada por e-mail avisando sobre o bloqueio. Para recuperar o acesso, era necessário entrar em contato com o suporte.

Pela terceira pergunta, o impacto possível ficava mais claro. Um ator malicioso não precisava descobrir a senha nem acessar a conta. Bastava conhecer ou enumerar e-mails válidos e realizar tentativas de login com senhas incorretas para bloquear contas reais. Um controle criado para proteger contra força bruta poderia ser usado como uma primitiva de negação de serviço contra usuários legítimos.

Conclusão

Pensar em primitivas ajuda a transformar a análise em um processo mais explícito. Em vez de olhar para o sistema apenas como um conjunto grande e complexo de funcionalidades, passo a observar pequenas ações, comparar intenção e realidade, e depois entender como essas diferenças podem ser usadas.

Esse raciocínio é útil para pesquisa manual e também para o uso de LLMs. Quanto melhor eu consigo descrever a primitiva, sua intenção, seu comportamento real e seu possível impacto, melhor consigo usar modelos e automações como apoio ao processo de investigação. No fim, encontrar vulnerabilidades continua dependendo de julgamento técnico, mas estruturar o caminho até elas torna esse julgamento mais claro, repetível e comunicável.

Segurança digital para crianças: preparando a próxima geração

2026-04-26T18:30:00+00:00

A segurança da informação precisa chegar mais cedo às pessoas. Durante muito tempo, tratamos esse tema como algo restrito a profissionais, empresas e equipes técnicas. Mas a realidade mudou: crianças crescem conectadas, usam dispositivos desde cedo, conversam em ambientes digitais, jogam online, assistem conteúdos, compartilham informações e constroem parte importante de suas relações dentro do ciberespaço.

Esse ambiente oferece oportunidades enormes, mas também expõe crianças e famílias a riscos que nem sempre são fáceis de perceber. Golpes, engenharia social, roubo de contas, exposição de dados, desinformação e hábitos inseguros já fazem parte do cotidiano digital. Por isso, preparar a próxima geração não é apenas uma escolha educativa. É uma responsabilidade coletiva.

Foi nesse contexto que conhecemos O Cibernauta, um projeto que usa a linguagem infantil para aproximar crianças, pais e educadores de temas essenciais de segurança digital e cidadania online. O primeiro livro, O Cibernauta em A Super Senha Secreta, publicado pela Editora Brasport, transforma um tema técnico - a criação e o cuidado com senhas - em uma aventura acessível, lúdica e útil para diferentes idades.

A proposta é simples e poderosa: ensinar cedo, de forma leve, para que a segurança digital faça parte da formação das crianças antes que os problemas apareçam. Quando uma criança entende por que uma senha importa, por que não deve compartilhar certas informações ou por que precisa desconfiar de pedidos estranhos, ela não aprende apenas uma regra. Ela começa a desenvolver senso crítico para navegar em um mundo cada vez mais complexo.

O projeto foi idealizado por Daniel Meirelles e Eduardo Argollo, que identificaram dentro de suas próprias famílias a dificuldade de conversar sobre segurança da informação de maneira clara e prática. A partir disso, construíram uma iniciativa que conecta tecnologia, educação e afeto, mostrando que crianças e adultos podem aprender juntos sobre proteção digital.

A LESIS decidiu apoiar esse movimento de forma concreta. Compramos 30 exemplares do livro e estamos doando esses materiais para pessoas e instituições que podem multiplicar esse conhecimento. Também seguimos apoiando os autores com conexões para eventos, conversas e possíveis parcerias que ajudem o projeto a chegar mais longe.

Essa ação é pequena quando comparada ao tamanho do desafio. Ainda assim, ela representa uma convicção importante: segurança da informação não se fortalece apenas com pesquisa, ferramentas, auditorias ou resposta a incidentes. Ela também se fortalece quando ajudamos uma criança a entender melhor o ambiente digital onde ela já vive.

Ao apoiar O Cibernauta, apoiamos uma visão de futuro em que a cultura de segurança começa antes da vida profissional, antes da primeira conta bancária, antes do primeiro incidente. Começa na formação de hábitos, no diálogo dentro de casa, na escola e nos espaços onde crianças podem aprender com curiosidade, imaginação e cuidado.

Queremos contribuir para um ecossistema de segurança mais maduro, acessível e humano. Isso inclui apoiar profissionais, comunidades técnicas, iniciativas educacionais e também projetos que olham para quem ainda está começando sua relação com a tecnologia.

Seguiremos buscando formas de apoiar iniciativas que usam educação como instrumento de transformação. Porque proteger o futuro também significa preparar melhor as pessoas que vão construí-lo.

Saiba mais sobre o projeto em O Cibernauta no Instagram e na Editora Brasport.

Máquina de estados para gestão de vulnerabilidades

2026-04-09T03:00:00+00:00

Em muitas organizações, o processo de gestão de vulnerabilidades sofre com um problema recorrente — mas frequentemente negligenciado: a inconsistência na definição e no uso de status. É comum ver os mesmos status sendo usados com significados diferentes por equipes distintas, ou existir status redundantes, mal definidos ou desnecessários, que mais confundem do que ajudam. Isso compromete a rastreabilidade, dificulta a comunicação entre áreas, inviabiliza métricas confiáveis e enfraquece a capacidade da organização de responder a riscos reais.

Para enfrentar esse cenário, adotar uma máquina de estados formalizada é uma estratégia eficaz. De forma clara e objetiva, ela representa o ciclo de vida de uma vulnerabilidade: cada transição tem significado preciso, e todos os times compartilham o mesmo entendimento sobre o que cada status representa.

O fluxo começa com Draft, que indica um rascunho em construção pelo analista/pentester. A vulnerabilidade ainda está sendo documentada e não foi submetida à triagem — pode faltar contexto, evidências ou detalhes técnicos. Após essa etapa, passa para Identified, quando se avaliam impacto e prioridade. Se for encaminhada para correção, assume o status Fixing, refletindo o trabalho ativo de mitigação. Durante o processo, pode-se identificar que se trata de uma repetição de um caso anterior, passando então para Duplicated. Se a análise mostrar que não há risco real — por exemplo, devido a uma condição de exploração inviável — o status passa a False Positive. Em certos casos, a organização opta por aceitar o risco, seja por limitações técnicas, custo de correção ou impacto considerado baixo; nesses casos, o status é Accepted Risk. Após a correção, a falha entra em Retest, sendo reavaliada. Se validada, o processo se encerra com o status Fixed.

A definição rigorosa dessa máquina de estados não é burocracia: é uma fundação necessária. Ao eliminar ambiguidades e redundâncias, ela melhora a colaboração entre áreas, reduz retrabalho e viabiliza decisões mais bem embasadas. Também permite gerar métricas consistentes, úteis para identificar gargalos, medir eficiência e sustentar auditorias.

Essa proposta de máquina de estados é, ao mesmo tempo, enxuta e completa. É o modelo mais eficaz que já encontrei na prática: simples o bastante para adoção rápida e abrangente o suficiente para cobrir os principais cenários. Tem se mostrado um excelente ponto de partida para padronizar processos, fortalecer a governança e facilitar a integração entre segurança, produto e engenharia.

Abaixo, o diagrama que representa esse fluxo:

Taxonomia econômica de vulnerabilidades

2026-02-08T16:52:02+00:00

No campo da cibersegurança, uma das perguntas mais relevantes — e, simultaneamente, uma das mais difíceis de responder com precisão — é: qual é o custo financeiro de uma vulnerabilidade? Embora existam diversos programas e práticas voltadas ao gerenciamento de vulnerabilidades, o desafio de atribuir um valor monetário a cada falha, especialmente quando ainda não explorada, permanece pouco abordado sob uma ótica objetiva e quantitativa.

Com o aumento da sofisticação dos ataques, das exigências regulatórias e da complexidade dos ecossistemas digitais contemporâneos, torna-se fundamental compreender o custo real de uma vulnerabilidade. Tal compreensão possibilita que decisões estratégicas em segurança da informação sejam fundamentadas não apenas em percepções de risco, mas também em análises econômicas tangíveis.

Contexto e dados analíticos

Historicamente, decisões relacionadas à priorização e ao investimento em segurança têm se baseado em avaliações qualitativas e modelos de risco construídos a partir de cenários hipotéticos. Embora úteis, essas abordagens nem sempre oferecem argumentos sólidos para justificar a alocação de recursos frente a áreas como finanças, produto ou liderança executiva.

Nesse cenário, surge a necessidade de uma análise centrada na mensuração econômica das vulnerabilidades, utilizando dados reais. A partir de uma nova análise de dados, este estudo busca responder com maior precisão à seguinte questão:

Qual é o custo de uma vulnerabilidade, considerando diferentes níveis de severidade e categorias?

A resposta a essa pergunta fornecerá subsídios importantes para estratégias de priorização, definição orçamentária e tomada de decisão em segurança da informação.

Premissas

A fim de conduzir a análise de forma objetiva, clara e relevante para a tomada de decisão, estabeleceram-se as seguintes premissas, que delimitam o escopo do estudo e fundamentam a abordagem metodológica adotada.

1. Vulnerabilidades possuem valor econômico mensurável: cada vulnerabilidade pode ser associada a um valor monetário, refletindo o esforço necessário para sua descoberta e reporte, bem como os riscos que ela representa. Programas de bug bounty são considerados referência de mercado para essa mensuração.

2. O valor de uma vulnerabilidade cresce conforme sua severidade: assume-se que a severidade de uma vulnerabilidade — determinada pelo impacto e pela probabilidade de exploração — está diretamente relacionada ao seu custo. Vulnerabilidades críticas tendem a implicar riscos maiores e, portanto, custos mais elevados.

3. Recompensas de bug bounty são proxies válidos para estimativa de custo: os valores pagos em programas de bug bounty são utilizados como estimativas conservadoras para o custo de descoberta de uma vulnerabilidade. Para maior rigor, adotar-se-á sempre o menor valor dentro de cada faixa divulgada.

4. O foco está exclusivamente na fase de descoberta da vulnerabilidade: a análise não contempla etapas subsequentes do ciclo de vida da vulnerabilidade (como correção, revalidação, comunicação ou impacto da exploração), concentrando-se unicamente no custo estimado para sua identificação.

5. Recursos de segurança são limitados e exigem alocação estratégica: partindo do princípio de que os orçamentos em segurança são finitos, compreender o custo unitário das vulnerabilidades permite decisões mais eficazes quanto à alocação de esforços e investimentos.

Fora de escopo

Embora relevantes, os seguintes tópicos não fazem parte do escopo deste estudo:

1. Elaboração de uma estratégia completa de gerenciamento de vulnerabilidades: esse documento não propõe um framework completo de gestão de vulnerabilidades, restringindo-se à análise de custo de identificação. Questões como priorização de correções, políticas de remediação, processos de resposta ou integração com sistemas de gestão de riscos não serão abordadas.

2. Avaliação ou comparação de fornecedores, ferramentas ou métodos específicos: não se objetiva comparar soluções ou recomendar plataformas. Dados de bug bounty são utilizados exclusivamente como insumo empírico para estimativa de custo, sem juízo de valor sobre sua efetividade ou eficiência em comparação a outras abordagens.

3. Estimativas de impacto financeiro de incidentes reais: não serão modeladas consequências financeiras de explorações bem-sucedidas, como vazamentos de dados, interrupções operacionais, penalidades regulatórias ou perdas de reputação. O foco é a mensuração do custo de descoberta, não do impacto final de uma vulnerabilidade explorada.

4. Propostas orçamentárias ou recomendações diretas de alocação de recursos: embora os dados obtidos possam auxiliar na tomada de decisões sobre investimentos em segurança, não se propõe aqui qualquer recomendação prescritiva de alocação orçamentária. A aplicação prática dessas informações dependerá do contexto e das prioridades de cada organização.

5. Análise de vulnerabilidades desconhecidas ou zero-day: a análise se restringe a vulnerabilidades conhecidas e catalogadas. Questões relacionadas a falhas ainda não descobertas, incluindo aquelas exploradas por atores maliciosos antes da divulgação pública (zero-day), estão fora do escopo deste estudo.

Abordagem

Inspirado pela teoria da assimetria de informação apresentada em The Market for Lemons: Quality Uncertainty and the Market Mechanism [1], este estudo parte do princípio de que mercados conseguem revelar preços mesmo em contextos de incerteza quanto à qualidade do bem transacionado, desde que existam mecanismos de sinalização minimamente estáveis.

No contexto da segurança da informação, programas de bug bounty funcionam como tais mecanismos, ao atribuírem valores monetários diferenciados a vulnerabilidades conforme sua severidade percebida. Assume-se, portanto, que as recompensas oferecidas refletem, de maneira conservadora, um valor de mercado associado à descoberta e ao reporte de falhas, mitigando parcialmente a assimetria entre quem identifica a vulnerabilidade e quem sofre seu risco. Com base nessa premissa, a metodologia adota uma abordagem quantitativa e comparativa, utilizando dados reais de programas de bug bounty para estimar níveis típicos de payout organizacional entre categorias de severidade.

Embora tais recompensas não representem o custo total decorrente da existência ou exploração de uma vulnerabilidade, elas constituem um proxy padronizado e empiricamente observável para sua mensuração econômica. Sob a ótica da assimetria de informação, programas de bug bounty operam como mercados de incentivos, nos quais o preço sinaliza não apenas o valor percebido da vulnerabilidade, mas também o esforço esperado para sua descoberta. Nesse arranjo, pesquisadores independentes tendem a investir racionalmente apenas quando o valor esperado da recompensa líquida supera seus custos marginais de descoberta, validação e reporte, condição necessária para manter lucro e viabilidade operacional.

Quando os valores oferecidos são percebidos como insuficientes frente à complexidade da superfície de ataque ou aos requisitos de validação, a tendência é a redução do engajamento e do volume de relatórios submetidos. De forma simétrica, organizações ajustam dinamicamente os valores das recompensas como mecanismo de atração ou desincentivo, elevando-os quando há escassez de relatórios qualificados ou reduzindo-os quando a oferta de vulnerabilidades reportadas excede sua capacidade de triagem e correção.

Esse ciclo de entrada, saída e migração entre programas atua como mecanismo autocorretivo. Assim, embora a assimetria de informação não desapareça por completo, ela tende a permanecer em níveis residuais e operacionalmente aceitáveis, pois desequilíbrios persistentes entre esforço requerido e payout são rapidamente detectados pelos pesquisadores e precificados pelo mercado.

Escopo da análise

A análise se restringe à etapa de descoberta da vulnerabilidade — isto é, ao esforço necessário para identificá-la e reportá-la com evidências técnicas. As fases de correção, revalidação e comunicação estão fora do escopo. Os dados são obtidos exclusivamente em fontes, priorizando:

Plataformas de bug bounty com informações abertas;
Recompensas categorizadas por severidade;
Diversas geografias, para maior representatividade.

Justificativa da abordagem

Ao utilizar dados de mercado — recompensas efetivamente pagas — evita-se a subjetividade típica das estimativas de impacto e se adota um critério reconhecido por diversos setores como referência prática de valor. Esse método também permite realizar comparações posteriores com outros modelos de investimento em segurança, como testes de intrusão (pentests) ou ferramentas automatizadas, fornecendo uma base concreta para avaliar retorno sobre investimento (ROI) e orientação de alocação de recursos.

Metodologia

A metodologia adotada em neste estudo foi desenvolvida com o objetivo de garantir transparência, reprodutibilidade e consistência na análise dos dados extraídos de plataformas públicas de bug bounty. A seguir, são detalhadas as etapas principais do processo:

A coleta de dados se dará pela utilização de scrapers próprios, desenvolvidos para extrair informações de programas ativos que:

Divulguem valores financeiros atribuídos a vulnerabilidades;
Classifiquem claramente as falhas por severidade.
Serão incluídos programas de empresas de diversos portes e setores, com abrangência nacional e internacional, a fim de capturar um panorama representativo do mercado.

Após a coleta, os dados são submetidos em um processo de filtragem, com os seguintes critérios de exclusão:

Programas do tipo VDP (Vulnerability Disclosure Program) que não oferecem recompensas financeiras;
Programas com dados inconsistentes ou incompletos sobre severidade ou valores;
Recompensas genéricas sem vinculação à severidade.

As recompensas são classificadas nas seguintes categorias, com base em descrições fornecidas pelos próprios programas ou, na ausência destas, segundo critérios compatíveis com o padrão CVSS:

Informativa
Baixa
Média
Alta
Crítica

Normalização dos valores, para evitar distorções nos resultados:

Em faixas de valores (ex: $ 1.000 a $ 5.000), será utilizado o valor mínimo da faixa, adotando-se uma postura conservadora;
Todos os valores serão convertidos para dólar (USD), — com base em uma taxa de câmbio de referência.

Análise

Foram analisados 808 programas de bug bounty, distribuídos entre as plataformas HackerOne, Bugcrowd, YesWeHack, Intigriti, BugHunt e Bugpay. A amostra contempla programas ativos de organizações com diferentes portes, setores e localizações geográficas, oferecendo um panorama amplo e representativo do mercado de recompensas por vulnerabilidades.

Figura 1: distribuição de programas de bug bounty por plataforma.

Os dados utilizados nesta análise estão disponíveis para reprodução e verificação no repositório: https://huggingface.co/datasets/lesis-lat/bug-bounty-programs-rewards/viewer/default/train

Figura 2: distribuição de programas de bug bounty por tipo de visibilidade (público vs privado).

A tabela a seguir apresenta os valores mínimos e máximos de recompensa observados em cada categoria de severidade, evidenciando a ampla variação existente entre programas e plataformas. Em particular, nota-se que, embora vulnerabilidades de baixa severidade apresentem recompensas mínimas simbólicas, as faixas superiores — especialmente para severidades altas e críticas — alcançam valores significativamente elevados, refletindo diferentes estratégias de incentivo e percepção de risco.

	Baixo	Médio	Alto	Crítico
Mínimo	$1.00	$3.00	$5.00	$50.00
Máximo	$2,000.00	$47,175.93	$58,969.91	$100,000.00

Tabela 1: valores mínimo e máximo das recompensas por severidade (USD).

Esses valores delimitam a faixa completa de variação dos dados observados, servindo como base para análises estatísticas mais robustas.

Complementarmente, a análise de tendência central revela padrões mais estáveis de precificação por severidade. A tabela a seguir apresenta os valores de média, mediana e moda, indicando que, apesar da presença de outliers relevantes, a concentração das recompensas ocorre em patamares bem definidos para cada categoria.

Severidade	Média	Mediana	Moda
Baixa	$154,75	$100,00	$100,00
Média	$563,93	$350,00	$500,00
Alta	$1825,83	$1000,00	$1000,00
Crítica	$4601,35	$3000,00	$3000,00

Tabela 2: média, mediana e moda das recompensas por severidade (USD).

Figura 3: comparação da mediana de recompensas por plataforma e severidade.

A comparação entre média e mediana, à luz dos coeficientes de assimetria, indica que a média aritmética não representa adequadamente o comportamento típico das recompensas por vulnerabilidade. Todas as categorias de severidade apresentam assimetria positiva elevada (skewness variando aproximadamente entre 6,49 e 21,72), evidenciando distribuições fortemente concentradas em valores baixos, com poucos pagamentos excepcionalmente altos. Embora a intensidade da assimetria varie entre severidades — com destaque para vulnerabilidades de severidade média — esse padrão explica a divergência sistemática entre média e mediana e confirma a sensibilidade da média a valores extremos, tornando medidas robustas mais adequadas para a interpretação dos dados.

Figura 4: preço típico de vulnerabilidades por severidade entre plataformas.

A variabilidade dos valores de recompensa foi avaliada por meio do intervalo interquartil (IQR), que captura a dispersão do núcleo central da distribuição. Observa-se um aumento consistente da variabilidade típica conforme a severidade da vulnerabilidade cresce. Para vulnerabilidades de baixa severidade, o IQR é de aproximadamente USD 141,03, indicando maior concentração dos valores praticados. Esse intervalo se amplia para USD 300,00 em severidade média, USD 1.410,30 em severidade alta e USD 3.500,00 em vulnerabilidades críticas, evidenciando uma expansão progressiva da faixa na qual se concentram as recompensas mais frequentes. Esse comportamento indica que vulnerabilidades mais severas estão associadas não apenas a valores mais elevados, mas também a maior incerteza econômica quanto à sua precificação.

Figura 5: mediana de recompensas por severidade em programas públicos vs privados.

Em conjunto, os resultados demonstram que, embora existam padrões consistentes de precificação por severidade, o mercado de bug bounty apresenta elevada heterogeneidade e presença recorrente de valores extremos. Ainda assim, as estatísticas de tendência central e dispersão permitem afirmar que a descoberta de vulnerabilidades possui um valor econômico observável e diferenciado por nível de severidade.

Assim, é metodologicamente adequado afirmar faixas de custo por severidade, desde que essas faixas sejam definidas a partir de medidas robustas, como a mediana e o intervalo interquartil, e não interpretadas como limites determinísticos. Com base nos dados analisados, a descoberta de vulnerabilidades de baixa severidade apresenta custo típico concentrado entre aproximadamente USD 59 e USD 200, com mediana de USD 100. Para severidade média, a faixa típica situa-se entre USD 200 e USD 500, com mediana em torno de USD 350. Vulnerabilidades de alta severidade apresentam maior dispersão, com valores concentrados entre USD 590 e USD 2.000, e mediana de USD 1.000, enquanto vulnerabilidades críticas exibem as maiores faixas de custo, aproximadamente entre USD 1.500 e USD 5.000, com mediana de USD 3.000. Essas faixas refletem o comportamento típico do mercado e evidenciam o aumento progressivo da incerteza econômica conforme a severidade da vulnerabilidade cresce.

Conclusão

Este estudo investigou a economia das recompensas (payouts) por vulnerabilidade a partir de uma abordagem quantitativa baseada em dados reais de programas de bug bounty. Neste contexto, “custo” refere-se ao valor pago pelas organizações por relatórios de vulnerabilidade aceitos, e não ao custo operacional do pesquisador para descobrir e reportar vulnerabilidades. Partindo da premissa de que tais programas funcionam como mecanismos de mercado sob assimetria de informação, a análise buscou estimar de forma objetiva como os valores de payout variam conforme sua severidade.

Os resultados demonstram que a descoberta de vulnerabilidades possui um valor econômico observável e sistematicamente diferenciado por severidade. As análises estatísticas evidenciaram distribuições fortemente assimétricas em todas as categorias, com presença recorrente de valores extremos, o que torna a média aritmética inadequada como medida representativa isolada. Em contraste, medidas robustas como a mediana e o intervalo interquartil mostraram-se mais apropriadas para capturar o comportamento típico do mercado.

Com base nesses indicadores, foi possível estimar faixas típicas de payout associadas à descoberta de vulnerabilidades. Vulnerabilidades de baixa severidade apresentam valores concentrados entre aproximadamente USD 59 e USD 200, com mediana de USD 100. Para severidade média, a faixa típica situa-se entre USD 200 e USD 500, com mediana em torno de USD 350. Vulnerabilidades de alta severidade concentram-se entre USD 590 e USD 2.000, com mediana de USD 1.000, enquanto vulnerabilidades críticas apresentam as maiores faixas de payout, entre aproximadamente USD 1.500 e USD 5.000, com mediana de USD 3.000. Essas faixas refletem o comportamento típico do mercado e evidenciam o aumento progressivo da variabilidade econômica conforme a severidade cresce.

Sob a perspectiva econômica, esses achados reforçam a interpretação de programas de bug bounty como mercados de incentivos, nos quais as recompensas funcionam como sinais que equilibram a oferta de esforço especializado por parte dos pesquisadores e a demanda por descoberta de falhas por parte das organizações. Nesse ambiente, pesquisadores tendem a direcionar esforço apenas quando o retorno esperado excede seu custo marginal, o que sustenta a lógica de lucro e continuidade da operação. A assimetria informacional, embora presente, é disciplinada pela migração entre programas e tende a permanecer em patamares baixos e aceitáveis. Embora tais recompensas não representem o custo total associado à existência ou exploração de uma vulnerabilidade, elas constituem um proxy empírico padronizado para o payout organizacional associado à sua identificação e reporte.

Do ponto de vista prático, a estimativa do Expected Vulnerability Discovery Cost (EVDC) por severidade oferece subsídios objetivos para apoiar decisões de priorização, planejamento orçamentário e avaliação de investimentos em segurança da informação. Ao traduzir vulnerabilidades em faixas econômicas mensuráveis, o estudo contribui para reduzir a dependência exclusiva de avaliações qualitativas e aproxima a gestão de vulnerabilidades de uma lógica econômica comparável a outros investimentos em tecnologia e risco.

Por fim, embora limitado ao escopo da descoberta e a programas de bug bounty, este trabalho estabelece uma base empírica para futuras pesquisas que explorem a relação entre custo de descoberta, custo de correção e impacto de exploração, bem como para comparações com outros modelos de investimento em segurança. Nesse sentido, a análise apresentada não busca fornecer valores determinísticos, mas oferecer referências econômicas robustas para compreender e discutir o custo das vulnerabilidades em ambientes digitais contemporâneos.

Referências

Considerações sobre a elaboração de relatórios de segurança

2026-01-15T18:15:10+00:00

Após dias ou semanas de trabalho, você identificou falhas relevantes, compreendeu a superfície de ataque do ambiente avaliado e reuniu evidências suficientes para demonstrar riscos reais ao negócio. Tecnicamente, a avaliação terminou. O que ainda falta é transformar esse conhecimento em um relatório claro, acionável e compreensível.

Em qualquer atividade de segurança da informação — testes técnicos, auditorias, avaliações de maturidade ou análises de risco — o relatório é o principal artefato entregue ao cliente. Ele é o meio pelo qual descobertas técnicas se convertem em decisões estratégicas. Sem um bom relatório, até o melhor trabalho técnico perde impacto.

Relatórios de segurança documentam objetivos, contexto, escopo, metodologia, achados, riscos e recomendações. A quantidade de informação envolvida é grande, e por isso a forma como ela é organizada e apresentada é tão importante quanto o conteúdo em si. Este texto não propõe um modelo fixo, mas orientações práticas para melhorar a qualidade da comunicação escrita em segurança da informação.

Tenha clareza sobre o objetivo

Todo relatório de segurança deve partir de uma pergunta simples: qual era o objetivo da avaliação? Sem essa resposta bem definida, o documento tende a se tornar uma coleção de achados desconectados. É comum focar excessivamente em detalhes técnicos. Embora eles façam parte do trabalho, o objetivo de uma avaliação de segurança não é demonstrar conhecimento, e sim reduzir risco. O relatório deve refletir essa intenção.

Manter o objetivo em mente durante a escrita ajuda a definir o que incluir, o nível de detalhe adequado e o tom do texto. Criar um esboço antes de escrever costuma facilitar esse processo, reduzindo repetições, evitando lacunas e tornando a escrita mais fluida.

Entenda quem vai ler

Relatórios de segurança raramente têm um único leitor. Executivos, gestores e equipes técnicas costumam consumir o mesmo documento com expectativas diferentes. Por isso, o texto deve ser compreensível mesmo para quem não domina os detalhes técnicos. Isso não significa simplificar excessivamente, mas explicar conceitos e impactos de forma clara e contextualizada.

A inclusão de um resumo executivo é uma prática consolidada. Ele apresenta uma visão de alto nível dos principais riscos e da postura geral de segurança, normalmente sendo a única parte lida por decisores. O restante do relatório deve ser mais técnico, desde que forneça contexto suficiente e não pressuponha conhecimento prévio.

Seja criterioso com o conteúdo

Um relatório de segurança não precisa ser extenso para ser completo. Ele precisa ser relevante. Tudo o que é incluído deve contribuir para o entendimento do risco ou para a tomada de decisão. Resultados brutos de ferramentas, capturas de tela repetitivas ou informações redundantes tendem a dificultar a leitura e diluir a mensagem principal. O foco deve estar em evidências que sustentem conclusões claras. Avaliar constantemente como cada informação se conecta ao objetivo da avaliação ajuda a manter o texto coeso e direcionado.

Busque referências e padrões

Escrever bons relatórios é uma habilidade desenvolvida com prática e observação. Analisar relatórios bem estruturados ajuda a identificar padrões de mercado, estilos de escrita eficazes e boas práticas de comunicação. Relatórios públicos, programas de bug bounty e repositórios com exemplos reais são boas fontes de referência. Buscar inspiração não significa copiar modelos, mas compreender como outros profissionais comunicam riscos de forma clara e objetiva.

Cuide da apresentação

A apresentação influencia diretamente a credibilidade do relatório. Um conteúdo tecnicamente sólido, mas mal escrito ou visualmente inconsistente, transmite descuido. Padronização de títulos, espaçamento adequado e linguagem clara fazem diferença. Erros gramaticais e frases ambíguas comprometem a percepção profissional do documento. Independentemente do idioma, revisão cuidadosa é essencial. No fim, o relatório representa tanto os achados quanto quem o produziu.

Documente desde o início

Um bom relatório começa durante a avaliação, não após seu término. Anotações feitas desde o início economizam tempo, evitam retrabalho e facilitam revisões futuras. Registrar comandos, resultados, evidências e observações permite reconstruir o raciocínio por trás de cada achado. Com o tempo, é natural desenvolver modelos próprios de documentação ajustados ao fluxo de trabalho de cada profissional. A qualidade do relatório final depende diretamente da qualidade dessas informações.

Organização, ferramentas e segurança das informações

Mais importante do que a ferramenta utilizada é o processo adotado. As informações precisam estar organizadas, acessíveis e protegidas, especialmente porque avaliações de segurança frequentemente envolvem dados sensíveis. Automatizar a captura de saídas, complementar com observações pessoais e usar capturas de tela com critério ajuda a não perder informações relevantes. O objetivo final é que os dados sejam claros, confiáveis e fáceis de consultar.

A importância dos backups

Backups raramente recebem atenção até se tornarem necessários. Documentação perdida representa tempo desperdiçado e, em alguns casos, impacto direto na entrega ao cliente. Manter cópias seguras da documentação, arquivos relevantes e snapshots de ambientes deve fazer parte da rotina. Em segurança da informação, prevenção quase sempre custa menos do que correção.

A importância da revisão por pares e de olhares externos

Nenhum relatório deveria ser considerado final sem revisão. A revisão por pares melhora a qualidade técnica, ajuda a identificar inconsistências e fortalece a narrativa dos achados.

Além disso, a leitura por alguém de fora do contexto da avaliação é fundamental para validar clareza e compreensão. Se esse leitor não entende o risco ou o raciocínio apresentado, é provável que o cliente também não entenda.

Quando a revisão humana não é possível, modelos de linguagem podem ser usados como apoio para identificar erros gramaticais, problemas de coesão e oportunidades de melhoria. Eles não substituem revisores humanos, mas funcionam como um segundo par de olhos quando usados com critério.

Ferramentas conceituais

Ferramentas conceituais ajudam a organizar o pensamento antes e durante a escrita. Modelos como 5W e 5W2H forçam o autor a refletir sobre propósito, contexto, escopo e método, evitando relatórios sem direção clara.

Estruturas como Problema, Causa, Impacto e Recomendação ajudam a conectar achados técnicos a riscos reais e ações práticas. Abordagens baseadas em cenários de ameaça facilitam a comunicação de consequências, especialmente para públicos não técnicos.

Conceitos como pirâmide invertida e a separação entre fato, evidência e interpretação aumentam a clareza e a credibilidade do texto. Perguntar constantemente o que o leitor precisa entender ou decidir após cada seção ajuda a manter o relatório objetivo e focado.

Conclusão

Relatórios de segurança são instrumentos de comunicação. Eles conectam análises técnicas a decisões que afetam pessoas, processos e negócios. Produzir bons relatórios exige clareza de propósito, entendimento do público, organização da informação e cuidado com a forma. Revisões, boas práticas de documentação e ferramentas conceituais não são burocracia, mas mecanismos de qualidade.

Um relatório bem escrito não é apenas um registro do que foi encontrado. Ele é a ponte entre descoberta e ação. Investir tempo nessa etapa é uma das formas mais eficazes de gerar impacto real em segurança da informação.

Referências

Fortalecendo a comunidade brasileira de cibersegurança através da educação

2026-01-14T22:13:00+00:00

Em 2026, a LESIS dará mais um passo concreto no seu compromisso com o desenvolvimento sustentável do ecossistema de tecnologia e segurança da informação no Brasil. Realizaremos uma doação financeira para a ONG Mente Binária, uma organização que atua diretamente na formação de novos profissionais para a área de cibersegurança.

Acreditamos que segurança da informação não se constrói apenas com tecnologia, mas com pessoas capacitadas, acesso ao conhecimento e oportunidades reais de crescimento profissional. É nesse ponto que a atuação da Mente Binária se torna essencial: ao investir em educação técnica acessível e de qualidade, a organização ajuda a transformar trajetórias individuais, impactando famílias, comunidades e, em última instância, o próprio país.

A formação de novos profissionais em segurança fortalece toda a cadeia — reduz o déficit de talentos no mercado, eleva o nível técnico da indústria e contribui para um ambiente digital mais seguro, resiliente e preparado para os desafios atuais e futuros. Cada pessoa formada representa não apenas uma nova carreira, mas um avanço coletivo para o setor de segurança da informação como um todo.

Nossa contribuição financeira é, por si só, uma ação pontual. No entanto, ela carrega uma convicção maior: quando os recursos certos chegam às pessoas certas, o impacto se multiplica. Pequenas ações, quando feitas de forma consistente e alinhadas a um propósito claro, constroem mudanças duradouras.

Como instituição, a LESIS entende que seu papel vai além da atuação comercial. Temos a responsabilidade de contribuir positivamente para o ecossistema em que estamos inseridos, apoiando iniciativas que geram valor social, técnico e humano.

Seguiremos buscando formas de apoiar projetos que acreditam na educação como motor de transformação. Porque, mesmo que cada ação individual pareça pequena, é assim — passo a passo — que se constrói um grande impacto.

Porque patrocinamos eventos de Segurança da Informação

2025-11-30T12:33:00+00:00

O ano de 2025 tem sido marcante para a LESIS. Entre projetos, pesquisas e o crescimento de nossa atuação no mercado, também assumimos um compromisso que consideramos fundamental: contribuir diretamente para e com a comunidade de Segurança da Informação. Acreditamos que a inovação nasce do encontro entre pessoas, da troca constante de conhecimento e da construção coletiva de soluções que tornam o mundo digital mais seguro. Por isso, apoiar eventos ao redor do país se tornou uma prioridade e uma maneira concreta de contribuir com o desenvolvimento do setor.

Ao longo deste ano, patrocinamos financeiramente e participamos de iniciativas como o Hacking na Web Day RJ, no Rio de Janeiro; o XibéSec, em Belém; o RioCyberSec, também no Rio; o FortalSec, em Fortaleza; e o Hack in Cariri, em Juazeiro do Norte. Cada um desses eventos possui sua identidade e seu público: alguns com forte vínculo acadêmico, outros mais voltados à indústria, alguns maiores e já consolidados, outros ainda em expansão. Para nós, essa pluralidade é exatamente o que torna a comunidade tão rica — e apoiar diferentes perfis é uma forma de garantir que o conhecimento chegue cada vez mais longe.

Além dos patrocínios, também fizemos questão de estar presentes como participantes em eventos de destaque, como o SBSEG, o Web Summit e a BSides RJ. São espaços onde as discussões mais atuais da cibersegurança ganham força, novas conexões surgem e parcerias estratégicas se desenvolvem. Estar próximos dessas conversas é fundamental tanto para o crescimento da LESIS quanto para a nossa capacidade de contribuir efetivamente com avanços na área.

Naturalmente, como empresa, parte desse investimento retorna em forma de posicionamento de marca, networking e oportunidades de negócios. Porém, esse não é o fator que nos move. A motivação principal é retribuir à comunidade tudo aquilo que ela representa para nós , que é o conhecimento compartilhado, a inspiração constante e a formação de profissionais que constroem um futuro mais seguro para todos. Queremos participar da base que sustenta esse ecossistema, incentivando o surgimento de novos talentos e fortalecendo iniciativas que fazem diferença para quem está entrando na área e para quem já trilha uma longa jornada.

Também fazemos questão de distribuir nosso apoio por diferentes regiões do Brasil. Enquanto alguns polos como São Paulo já contam com maior volume de investimentos e eventos, outras localidades ainda enfrentam escassez de iniciativas e oportunidades. Apoiar encontros no Norte e no Nordeste, por exemplo, é uma forma de contribuir para um cenário mais equilibrado, em que talentos não sejam limitados pela geografia.

Esse movimento está apenas começando. Seguimos abertos a colaborar com quem compartilha da mesma visão: uma comunidade forte, diversa, acessível e em constante evolução.

Se você organiza um evento e acredita no impacto da educação, da troca e do desenvolvimento da segurança da informação, queremos fazer parte dessa construção ao seu lado.

Dinheiro de graça, descontos sem esforço: hackeando o loop dos gift cards

2025-10-04T16:29:00+00:00

Com certa frequência, surge a oportunidade de realizar pesquisas de vulnerabilidades em e-commerces. Apesar do contexto ser o mesmo, cada uma das oportunidades é única, pois sempre há peculiaridades em cada aplicação. Nesta publicação busco demonstrar um caso envolvendo gift cards que considero interessante.

Sites que comercializam qualquer tipo de produto possuem uma enorme complexidade em suas implementações de lógicas, e essa complexidade frequentemente dificulta a garantia de que todos os fluxos contenham as medidas de seguranças adequadas. Nesta publicação, abordaremos especificamente dois itens frequentemente presentes em e-commerces: gift cards e cupons de descontos, em um estudo de caso onde foi localizada primitivas que permitiram a exploração de uma vulnerabilidade.

Gift cards: virtual ou físico, é uma espécie de cartão pré-pago que os clientes podem adquirir para si ou para presentear outras pessoas. Ele possui um valor monetário associado, que pode ser usado para compras no site, permitindo ao destinatário escolher os produtos ou serviços que deseja adquirir até que o saldo do gift card seja totalmente utilizado.

Cupom de desconto: trata-se de um código, geralmente alfanumérico, fornecido aos clientes para reduzir o valor de compra de produtos ou serviços. Ao aplicar o cupom durante o processo de pagamento, o cliente recebe um desconto ou benefício específico, como uma porcentagem de desconto ou frete grátis, tornando a compra mais vantajosa.

Rocking the gift card loop

Figura 1: Listagem de um Gift Card para venda;

Durante um ciclo de atividades de testes, identifiquei o seguinte cenário: um site oferece a opção de compra de gift cards e, simultaneamente, permite o uso de cupons de desconto ainda nessa mesma compra. Por exemplo, ao comprar de um gift card no valor de R$150,00, é permitido o uso de um cupom de desconto chamado “15OFF”, que concede desconto de R$ 15. Dessa forma, o valor a ser pago é de apenas R$135,00 por um gift card que ainda tem a capacidade de compra do valor de R$150,00.

Figura 2: Comprando um Gift Card com cupom de desconto em e-commerce

O problema neste cenário é: esse gift card pode ser utilizado durante a compra de outro gift card, com a possibilidade de aplicar o cupom de desconto novamente. Assim, na próxima transação, é possível adquirir um gift card de R$150,00, utilizando um gift card que custou apenas R$ 135,00. Aplicando outra vez o cupom de desconto de R$ 15,00.

Surge então um padrão: a cada utilização desse fluxo, ocorre a geração indevida de R$15,00 em saldo adicional. Em termos práticos, a cada transação o usuário amplia o valor de crédito disponível sem efetuar novo desembolso financeiro.

Para ilustrar, caso o processo seja repetido em 10 ciclos consecutivos, o crédito inicial de R$150,00 evolui para R$300,00, representando um aumento de 100% no saldo sem qualquer contrapartida financeira. Tal situação caracteriza um cenário de fraude sistêmica, uma vez que possibilita a criação de saldo fictício dentro da plataforma.

Adicionalmente, é importante considerar que cada transação realizada está sujeita à cobrança de taxas operacionais por parte dos intermediadores de pagamento. Assim, além do prejuízo decorrente da geração indevida de saldo, o recorrente processamento de transações aumenta os custos da operação, ampliando o impacto financeiro negativo para a plataforma.

Conclusão

A vulnerabilidade identificada tem origem em falhas de lógica de negócios, e a sua mitigação demanda ajustes estruturais no fluxo de compra. A primeira e mais direta medida consiste em restringir o uso de gift cards como forma de pagamento para a aquisição de novos gift cards. Essa regra simples elimina a possibilidade de encadeamento de transações que resultam na geração artificial de saldo.

De forma complementar, recomenda-se estabelecer políticas específicas para cupons de desconto, impedindo que sejam aplicados em operações de compra de gift cards. Essa prática é comum no mercado e visa preservar a integridade financeira do sistema, já que os gift cards funcionam, na prática, como instrumentos de valor armazenado e não devem ser objeto de promoções que reduzem seu custo de aquisição.

Adicionalmente, é altamente recomendável a implementação de mecanismos de prevenção e detecção de fraudes. A utilização de uma engine antifraude, integrada ao processo de checkout, permite identificar padrões suspeitos, como múltiplas transações de baixo risco aparente, mas que na prática revelam tentativas de exploração sistêmica. Esse tipo de controle, associado a monitoramento contínuo e políticas de limitação de uso (ex.: valor máximo de gift cards adquiridos por cliente em determinado período), fortalece a resiliência da plataforma contra abusos semelhantes.

Em conjunto, essas medidas representam uma abordagem de mitigação em múltiplas camadas, reduzindo a exposição da empresa ao risco de fraude financeira e garantindo maior confiabilidade.