Pular para o conteúdo
>_ITDITDPlataforma de Segurança Web
incidents

Incidentes e Vulnerabilidades

Capital One, Equifax, Log4Shell, Heartbleed, XZ — violações e vulnerabilidades públicas detalhadas em causa, impacto, primeira resposta e prevenção, pelas lições que ainda valem.

Alto2026-07-07

Fraude no 7pay (2019) — como um app de pagamento sem 2FA foi sequestrado

Os sequestros de contas começaram no dia seguinte ao lançamento; ~808 usuários perderam ~¥38,6 milhões. A falha central foi o desenho da autenticação: (1) sem autenticação de dois fatores, então o login exigia apenas ID + senha, e (2) uma redefinição de senha que podia enviar a nova senha a um e-mail diferente do cadastrado — assim, fragmentos de dados pessoais bastavam para sequestrar uma conta. Defenda-se exigindo 2FA em ações sensíveis, restringindo a redefinição de senha a canais cadastrados, detectando e bloqueando o credential-stuffing e revisando os fluxos de autenticação antes do lançamento.

Crítico2026-07-07

Vazamento de dados da Benesse (2014) — por que um insider não pôde ser detido, e a defesa por menor privilégio

Um engenheiro de sistemas terceirizado, alocado em uma empresa do grupo, usou o acesso ao banco de dados legitimamente concedido para copiar dados de clientes em massa, transferi-los para um smartphone pessoal e vendê-los a corretores de dados. O software de monitoramento bloqueava gravações em armazenamento USB, mas não bloqueava a transferência para um smartphone (MTP). Até ~35 milhões de registros vazaram. Defenda-se minimizando privilégio (menor privilégio / need-to-know), fechando todo caminho de exfiltração com DLP, detectando acesso em massa e estendendo a supervisão até terceiros e subcontratados.

Alto2026-07-07

Ransomware na Capcom (2020) — por que um dispositivo VPN antigo foi a porta de entrada, e a defesa contra a dupla extorsão

A porta de entrada foi um dispositivo VPN antigo de backup que continuou ligado numa subsidiária norte-americana depois de unidades novas o substituírem. A partir dele a rede foi invadida, os dados foram roubados e então o ransomware criptografou os sistemas (dupla extorsão). Dados de até ~390.000 pessoas foram potencialmente expostos (nenhum dado de cartão de pagamento). A Capcom se recusou a pagar, restaurou de backup e divulgou de forma transparente. Defenda-se desativando equipamentos sem uso, aplicando patches em dispositivos de borda e cobrindo tanto o roubo quanto a criptografia (segmentação, detecção, backups).

Crítico2026-07-07

Roubo de NEM da Coincheck (2018) — como cerca de US$ 530 milhões foram levados e a defesa da gestão de chaves

A porta de entrada foi, segundo relatos, phishing direcionado / malware contra funcionários, que roubou a chave privada de uma carteira quente conectada à internet; cerca de 523 milhões de XEM (~US$ 530 milhões na época) foram então movidos para fora em uma única leva. A falha central foi manter um saldo enorme, gastável na hora, 'quente' e sem multiassinatura — uma única chave roubada moveu quase tudo. Defenda-se mantendo as chaves importantes a frio / em um cofre dedicado, minimizando o saldo quente, removendo pontos únicos de falha (múltiplas aprovações) e detectando e detendo operações em massa anormais.

Crítico2026-07-07

Ransomware na KADOKAWA / Niconico (2024) — por que se espalhou por toda a empresa, e segmentação de rede & BCP

A entrada foi descrita como phishing que roubou as credenciais de um funcionário; a partir daí a rede interna foi invadida e o ransomware rodou, derrubando muitos serviços do grupo (incluindo o Niconico) por meses e vazando dados de ~250.000 pessoas. Relatos e análises atribuem a propagação por toda a empresa a sistemas de criticidade muito diferente que dividiam a mesma rede — supostamente com pouca segmentação. Defenda-se segmentando a rede por criticidade, usando autenticação resistente a phishing e preparando continuidade de negócios (BCP) e recuperação.

Alto2026-07-07

Vazamento de dados do Takufile-bin (2019) — por que armazenar senhas em texto puro é fatal, e a defesa do hashing

Uma vulnerabilidade de servidor foi explorada para acesso não autorizado, e ~4,8 milhões de registros — nomes, e-mails, senhas de login, datas de nascimento, incluindo clientes que já haviam cancelado — vazaram. A falha decisiva foi que as senhas de login estavam armazenadas sem criptografia, em texto puro: vazadas, ficaram imediatamente utilizáveis e alimentaram o sequestro de contas em outros sites via reúso de senha. Defenda-se armazenando senhas como um hash de mão única com sal, não guardando dados de que você não precisa, corrigindo vulnerabilidades e se preparando para o reúso (2FA).

CríticoCVSS9.82026-06-12

Vazamento em massa do MOVEit (2023) — como um zero-day de SQL injection alcançou mais de 2.700 organizações, e como se defender

A entrada foi um zero-day de SQL injection (CVE-2023-34362) no MOVEit Transfer, exposto à internet. Um web shell (LEMURLOOT) foi plantado e dados foram roubados em massa do banco de dados de retaguarda, atingindo mais de 2.700 organizações e cerca de 93,3M de pessoas. A maioria das vítimas foi arrastada indiretamente porque um fornecedor usava o MOVEit. No seu ambiente: patch rápido de KEV, minimizar a exposição, menor privilégio e segmentação entre web↔DB, inventário de fornecedores e minimização de dados.

Crítico2026-06-07

Vazamento da Capital One (2019) — como um SSRF expôs mais de 100M de registros, e como se defender

Um único SSRF alcançou o endpoint de metadados → credenciais IAM temporárias com privilégios excessivos → cópia em massa do S3, vazando cerca de 106M de registros. Cada salto poderia tê-lo interrompido. No seu ambiente: IMDSv2, IAM de menor privilégio e uma allowlist para requisições de saída.

Crítico2026-06-07

Vazamento da Codecov (2021) — quando uma 'ferramenta confiável' no CI foi sequestrada e segredos vazaram

Uma ferramenta de CI confiável (o Bash Uploader curl|bash) foi alterada na origem. Como o seu próprio código permaneceu intocado, passou despercebido por cerca de 2 meses enquanto segredos de CI vazavam; uma verificação de checksum o pegou. No seu CI: verifique artefatos baixados, segredos de menor privilégio, rotação, monitoramento de egress.

CríticoCVSS10.02026-06-07

Vazamento da Equifax (2017) — como uma falha não corrigida no Apache Struts expôs 147M de pessoas

A causa foi um CVE conhecido e já corrigido (CVSS 10.0) deixado sem aplicar em um sistema público. Um certificado de monitoramento expirado ocultou a exfiltração por 76 dias. No seu ambiente: inventário de ativos, um SLA de patch, monitoramento por máquina e detecção saudável.

2026-06-07

Heartbleed (CVE-2014-0160) — quando memória vazou da base do tráfego criptografado

A leitura excessiva de memória do OpenSSL podia vazar chaves privadas e sessões. A causa: o servidor confiava num comprimento alegado e lia a memória adjacente. A lição: aja como se tudo tivesse vazado — reemita certificados, rotacione todos os segredos — além do peso do software de base e da segurança de memória.

2026-06-07

Log4Shell (CVE-2021-44228) — a noite em que o mundo temeu um bug que nem conseguia confirmar ter

O bug CVSS 10.0 do Log4j. O verdadeiro medo era a dependência transitiva — ser afetado por uma biblioteca que você nem sabia que usava. Um caminho passivo de logs virou vetor de ataque. SBOM, monitoramento por máquina, patch rápido e acompanhar os CVEs de continuação são as lições.

2026-06-07

O backdoor do XZ Utils (CVE-2024-3094) — quando a própria confiança era o alvo

Um mantenedor confiável plantou um backdoor no xz — um ataque à cadeia de suprimentos. O 'isto parece lento' de um engenheiro o pegou pouco antes da versão estável. O alvo não era o código — eram as pessoas e a confiança. Minimize dependências, fixe versões, faça builds reprodutíveis, persiga anomalias e apoie os mantenedores.