O Eskudo News retorna com mais uma edição, trazendo os principais acontecimentos do último mês nos temas de cibersegurança, inteligência artificial, nuvem e inovação digital. Esta edição resume os fatos mais relevantes que impactam diretamente empresas, governos e profissionais da área.
“Socorristas” do ransomware viram algozes
Como a prisão de negociadores acusados de operar o BlackCat expõe fragilidades de governança, due diligence e ética na resposta a incidentes
Quando as algemas fecham no pulso de quem deveria abrir cadeados, o setor precisa olhar no espelho. Foi o que aconteceu nos EUA com a acusação formal contra dois negociadores de ransomware e um ex-gestor de resposta a incidentes, suspeitos de participar ativamente de ataques ligados ao grupo ALPHV/BlackCat — inclusive exigindo resgates milionários. Segundo a denúncia, os acusados teriam usado o conhecimento íntimo do “lado da defesa” para invadir empresas, exfiltrar dados e implantar o ransomware, em pelo menos cinco alvos, entre eles um fabricante de dispositivos médicos da Flórida que teria pago mais de US$ 1,2 milhão. As informações vieram à tona a partir de documentos do FBI e do Departamento de Justiça, e foram confirmadas por reportagens que identificam vínculos de dois envolvidos com uma negociadora de resgates (DigitalMint) e de um terceiro com uma empresa global de IR (Sygnia). TechCrunch+1
O caso desmonta uma premissa confortável: a de que “negociadores” e “limpadores” estão automaticamente do lado do bem. Em esquemas RaaS (ransomware-as-a-service) como o do BlackCat, a divisão de trabalho é clara: operadores desenvolvem o malware, afiliados conduzem intrusões e ambos repartem os lucros. Inseridos nesse arranjo, profissionais com acesso privilegiado a vítimas e processos passam a ser um elo extremamente perigoso quando cruzam a fronteira ética. A acusação descreve justamente esse atalho: usar acesso, linguagem e rotinas aprendidos no front de resposta para maximizar pressão, credibilidade e payout durante a extorsão. TechCrunch
Para quem contrata resposta a incidentes, a lição é dura e prática. “Confiar” não basta; é preciso comprovar. Due diligence deve sair do marketing e virar processo: verificação criminal e financeira, referências checadas com clientes reais, análise de conflitos de interesse, segregação de funções (quem negocia não opera ferramentas forenses nem toca em chaves), trilhas de auditoria assinadas e cadeia de custódia validada por terceiros. Contratos precisam de cláusulas claras para auditoria independente, proibição expressa de interação direta com atores de ameaça fora de protocolos aprovados, transparência total sobre pagamentos e relação com corretoras de cripto, além de sanções contratuais severas para violação de ética. CSO Online
O episódio também expõe riscos de governança interna do lado das vítimas. Muitas organizações “terceirizam” a decisão de pagar ou não, a comunicação com criminosos e até o controle das chaves de descriptografia. Isso é receita para desastre reputacional e jurídico. Um programa maduro estabelece, antes da crise, critérios objetivos para eventual pagamento (impacto a vidas, continuidade operacional, obrigações regulatórias), define quem decide (jurídico, CISO, negócio, seguradora), como a decisão é registrada e quando autoridades são envolvidas. A presença de seguradoras e MSSPs deve vir acompanhada de mecanismos anti-conflito: rotação de fornecedores por função, separação entre detecção, resposta, negociação e recuperação, e avaliação periódica por comitês de risco. CSO Online
Há, ainda, um ponto sensível sobre o mercado de “negociação”. Na prática, esse nicho opera em zona cinzenta, conversando com criminosos e, não raro, transmitindo “melhores práticas” que acabam profissionalizando a extorsão (por exemplo, como montar “provas de vida” de dados ou como estruturar “descontos” por rapidez). Sem políticas éticas rígidas e supervisão, a atividade pode alimentar o ecossistema que pretende conter. O DOJ já havia sinalizado esse risco ao buscar criminalmente integrantes e negociadores de grupos de extorsão como Karakurt e outros, e a prisão atual reforça o recado: o enforcement está disposto a atravessar a névoa onde mercado e crime se tocam. The Verge
No curto prazo, CIOs e CISOs deveriam revisar imediatamente playbooks: (1) lista pré-aprovada e auditada de parceiros de IR/negociação, com escrow e segregação; (2) “duas-pessoas” para qualquer contato com atores de ameaça; (3) proibição de carteiras cripto não custodiadas por instituições supervisionadas; (4) logging e gravação integrais de todas as interações; (5) supervisão do conselho/risco para movimentações financeiras relacionadas a incidentes. Paralelamente, vale instituir monitoramento de reputação dos parceiros (processos, sanções, mudanças de equipe) e exigir atestados de independência, como se faz com auditorias financeiras. CSO Online
Por fim, é preciso fugir do cinismo de que “todos fazem” ou de que “sem pagar não volta nada”. A melhor defesa continua sendo reduzir a superfície de ataque e a capacidade de extorsão: backups imutáveis testados, MFA universal, EDR bem afinado, segmentação, gestão de credenciais expostas e exercícios de crise frequentes. Casos como este lembram que, em segurança, confiança é um controle — não um sentimento. E controle se mede, se audita, se prova. TechCrunch
Vazamento “quase total”: o que significam os 1,96 bilhão de e-mails e 1,3 bilhão de senhas recém-indexados no HIBP
A confirmação de que o Have I Been Pwned (HIBP) adicionou 1.957.476.021 endereços de e-mail únicos e 1,3 bilhão de senhas — sendo 625 milhões inéditas — muda a régua de risco para empresas e usuários em 2025. Não se trata de um único “megavazamento”, mas de um corpus consolidado a partir de múltiplas fontes onde criminosos haviam publicado dados ao longo do tempo, reunido pela plataforma Synthient e fornecido ao HIBP para notificação das vítimas. É, nas palavras do próprio Troy Hunt (criador do HIBP), o conjunto mais extenso já processado pelo serviço. Troy Hunt
Por que isso é grave? Primeiro, porque listas desse porte alimentam ataques de credential stuffing em escala industrial: bots testam combinações de e-mail/senha contra bancos, e-commerce, SaaS e webmails até encontrarem onde houve reaproveitamento de credenciais. Segundo, porque a presença de 625 milhões de senhas “nunca vistas” expande significativamente o espaço de ataque — mesmo quem vinha checando suas senhas contra vazamentos anteriores agora pode estar exposto. Terceiro, porque parte considerável do material vem de infostealers (malwares que extraem senhas dos navegadores, cookies e tokens de sessão), o que inclui credenciais ainda válidas no momento da coleta. Relatos independentes reforçam que a origem predominante são dumps agregados por ferramentas e canais de crime digital, não uma falha isolada em um provedor específico. Tom’s Guide+1
No Brasil, a combinação de reuso de senhas, uso massivo de WhatsApp/Instagram para negócios e a popularização do Pix agrava o impacto. O caminho típico do golpe é previsível: o atacante valida a senha em um serviço “menos crítico” (um marketplace ou streaming), toma a caixa de e-mail via reset, sequestra redes sociais para engenharia social e, em seguida, mira bancos/fintechs — às vezes sem precisar da senha, apenas reaproveitando cookies e códigos de recuperação. Em ambientes corporativos, o risco transborda para VPNs, painéis de nuvem e e-mail corporativo, com sequestro de threads legítimas para golpes BEC (Business Email Compromise). Nesse contexto, ignorar MFA e políticas de senha robustas deixa de ser um inconveniente e passa a ser um passivo direto. Troy Hunt
O que fazer hoje, de forma pragmática? Para empresas: (1) habilitar bloqueio automático de “password exposure” — negar senhas que apareçam em bases conhecidas, usando referências como o repositório de senhas do HIBP; (2) impor MFA resistente a phishing (FIDO2/Passkeys) em contas administrativas e de e-mail; (3) revisar políticas de reset e recuperação (inclusive eliminar SMS isolado); (4) caçar sessões de longa duração e tokens válidos em SSO; (5) ativar monitoramento formal de credenciais de domínios (search de domínio do HIBP) com fluxo jurídico-LGPD para notificação. Para MSSPs/SOCs, isso vira baseline: tarefa recorrente de varredura de credenciais expostas, correlação com tentativas de login por ASN/país e playbooks para rotação forçada de senhas e invalidação de sessões. Have I Been Pwned
Para usuários e equipes, as regras de ouro continuam válidas — e ganham urgência: gerenciador de senhas para garantir unicidade; ativação de MFA em tudo; higienização do navegador (remover senhas salvas e avaliar uso do cofre do gerenciador em vez do browser); desconfiança de “avisos de troca urgente” por e-mail/SMS, que surfam a onda de notícias para aplicar phishing de confirmação. Vale, ainda, checar e-mails no HIBP, cadastrar alertas de novas ocorrências e trocar de imediato qualquer senha identificada — inclusive em serviços “secundários” que possam ser porta de entrada. Cobrir o básico fecha portas por onde boa parte dos ataques realmente entra. Have I Been Pwned+1
Em síntese, o anúncio não é “mais do mesmo”: a escala e a natureza das fontes (especialmente infostealers) criam um choque de realidade. O lado bom é que a resposta também está madura e acessível: com MFA robusta, gestão de senhas, verificação automática de exposição e processos de contenção, é possível reduzir drasticamente o risco — tanto para indivíduos quanto para organizações. O que não dá é para adiar: os bots já estão testando essas combinações neste exato momento. Troy Hunt
Quando o Slack vira porta de entrada: lições do incidente da Nikkei e o risco invisível do BYOD
O caso da Nikkei — que informou impacto a cerca de 17 mil pessoas após o comprometimento de contas do Slack, originado em malware instalado no computador pessoal de um funcionário — é um estudo de caso sobre como colaboração em nuvem e BYOD (Bring Your Own Device) podem colidir com segurança. Não houve “exploit zero-day” sofisticado; houve, sim, a combinação de credenciais capturadas por infostealer, token persistente de sessão e ausência de controles suficientes para impedir que um endpoint fora do domínio corporativo se tornasse vetor. Em ambientes onde o Slack concentra conversas estratégicas, links para dashboards internos, chaves de API e integrações com repositórios de código, um sequestro de conta é, na prática, uma brecha de perímetro.
O primeiro ponto crítico é entender a anatomia do ataque. Infostealers modernos vasculham navegadores e aplicativos em busca de cookies, tokens e credenciais salvas. Se o uso corporativo ocorre em dispositivo pessoal, a organização perde visibilidade e capacidade de impor higiene mínima (EDR, atualização, hardening de navegador). Com um token válido, o invasor contorna senhas e, em certos cenários, até o MFA — especialmente quando o provedor aceita sessões long-lived ou quando o desafio de múltiplos fatores ocorre apenas em novos dispositivos. Uma vez “dentro” do workspace, o atacante pode baixar históricos, mapear a topologia humana (quem decide o quê) e usar o próprio Slack para phishing lateral, pedindo aprovações, acessos temporários e chaves “para um teste urgente”.
O segundo ponto é a superfície de ataque ampliada por integrações. Workspaces maduros costumam ter dezenas de apps conectados — desde bots internos até conectores de terceiros com escopos generosos (“read/write” em canais, acesso a arquivos privados, triggers em eventos). Um intruso com conta sequestrada pode instalar apps maliciosos, gerar webhooks e criar “exfiltração por design”: todo arquivo novo em um canal sensível é enviado automaticamente para um endpoint externo. O risco se multiplica quando o workspace contém canais compartilhados com parceiros, permitindo que a violação transborde para outras organizações.
Que lições práticas emergem? Primeiro, governança de identidade no Slack precisa ir além de “ativar MFA”. É necessário exigir MFA por aplicativo (TOTP/FIDO2), encurtar a validade de sessões, bloquear logins de ASNs e países anômalos e ativar alertas para novos dispositivos e instalações de apps. Segundo, hardening de BYOD: se a empresa autoriza uso de dispositivos pessoais, deve impor EDR com política mínima, isolamento de perfis, exigência de criptografia e atualização automática. Onde BYOD não comportar esse nível de controle, o acesso deve ocorrer via navegador endurecido e CASB, com DLP para padrões sensíveis (tokens, segredos, CPFs, chaves) e bloqueio de download em canais de alto risco.
Terceiro, higiene de integrações: inventariar apps, remover escopos excessivos, isolar bots de produção em workspaces separados e exigir publishers verificados. Quarto, resposta a incidentes específica para colaboração: botões de “desautenticar tudo” (revogar sessões), rotação de chaves e webhooks, bloqueio temporário de convites e auditoria forense dos canais e DMs com maior sensibilidade. Quinto, educação direcionada: playbooks de “mensagem suspeita no Slack”, exemplos de engenharia social e treino para reconhecer apps “úteis” demais recém-instalados.
Por fim, não negligencie o aspecto regulatório. Mesmo que o dado vazado seja “apenas” metadado de conversa, a combinação de nomes, e-mails, anexos e decisões de negócio é, muitas vezes, dado pessoal e competitivo. Mapear bases legais, tempos de retenção e critérios de minimização dentro do Slack reduz o estrago quando a técnica falha. Em 2025, segurança de colaboração é tão central quanto segurança de e-mail: se o Slack é seu “cérebro operacional”, trate-o como tal — com identidade forte, telemetria rica e o mesmo rigor aplicado ao seu SIEM, ao seu repositório de código e ao seu ERP.
E-mails de confiança em xeque: por que o ataque ao CBO preocupa todo o ecossistema do Congresso dos EUA
O incidente de cibersegurança no U.S. Congressional Budget Office (CBO) é mais do que “apenas” uma violação em um órgão técnico: ele atinge a espinha dorsal da comunicação interinstitucional no Capitólio. Segundo o CBO, a intrusão foi contida e medidas de monitoramento adicional foram implantadas; ainda assim, o Escritório do Sargento-de-Armas do Senado alertou gabinetes sobre a possibilidade de e-mails comprometidos e a chance concreta de spear phishing que imite conversas legítimas da agência. É um ponto de inflexão porque o CBO, embora não guarde segredos militares, transita diariamente por estimativas, minutas e esclarecimentos que moldam a tomada de decisão legislativa — e, portanto, fornece “material vivo” para operações de engenharia social altamente convincentes. Reuters
A preocupação central não é apenas o conteúdo eventualmente acessado, mas a “autenticidade” reaproveitável: threads reais, linguagem conhecida, anexos verossímeis e contatos previamente estabelecidos. Em campanhas modernas de intrusão, esse arsenal permite golpes sem malware — basta induzir assessores e consultores a baixar documentos “atualizados”, aprovar acessos temporários ou repassar credenciais em portais internos. Relatos indicam, inclusive, que escritórios reduziram a confiança no canal de e-mail com o CBO até que a higienização fosse validada, um sinal de quão corrosivo pode ser o dano reputacional da própria infraestrutura de comunicação. The Washington Post
Do ponto de vista de ameaça, a hipótese de ator estrangeiro — reportada pela imprensa, mas não confirmada publicamente pelo CBO — encaixa-se em padrões de coleta silenciosa com vistas a vantagem informacional, não necessariamente à interrupção imediata de serviços. O alvo é o “contexto” que cerca o processo legislativo: quem negocia com quem, quais temas estão amadurecendo, quais concessões aparecem nos bastidores. Em um cenário de shutdowns, votações apertadas e disputas orçamentárias, essa inteligência vale ouro, seja para influenciar agendas, seja para preparar futuras campanhas de desinformação alavancadas por e-mails autênticos previamente roubados. Reuters+1
Para times SOC/MSS que atendem órgãos públicos (ou entidades que interagem com eles), o recado é operacional e imediato. Primeiro, identidade: MFA resistente a phishing (FIDO2/passkeys) para contas com qualquer relação com o CBO; revisão de durações de sessão, dispositivos confiáveis e tokens ativos; e políticas de “step-up” para anexos de alto risco. Segundo, e-mail: DMARC em p=quarantine/reject, verificação de domínios sósias e bannerização agressiva de mensagens externas, com workflows de confirmação fora de banda para solicitações incomuns. Terceiro, caça de ameaças orientada a narrativa: regras que detectem “reply-chain” suspeito, anexos com nomes que imitam rotinas do CBO (por exemplo, “score_update”, “baseline_adjustment”) e tentativas de exfiltração a partir de clientes de e-mail de staffers. Reuters
Governança também conta. Em ambientes legislativos, a pressão por velocidade favorece atalhos (encaminhar PDFs, compartilhar planilhas por e-mail, usar contas pessoais durante recessos). É vital padronizar canais “seguros por padrão” para trocas com o CBO, endurecer listas de permissão (allowlists) e instituir mecanismos de “mensagens sensíveis” com proteção adicional (IRM, marca d’água, restrição de encaminhamento). Além disso, exercícios de mesa (tabletop) devem simular spear phishing com base em threads reais, para treinar o staff na decisão correta sob pressão: desacelerar, verificar, escalar. Reuters
Por fim, comunicação clara é parte da contenção. O CBO afirma que segue operando e reforçou a vigilância — isso ajuda a reduzir o vácuo explorável por boatos e golpes oportunistas que surfam a notícia do ataque. Ainda assim, o episódio deixa uma lição duradoura: na arena política, a credencial técnica do remetente vale quase tanto quanto a mensagem. Quando essa credencial é sequestrada, todo o ecossistema precisa recalibrar seus reflexos — trocando confiança implícita por validação explícita, sem paralisar a máquina que faz as leis acontecerem. AP News
Para acompanhar todo lançamento do Eskudo News, nos siga no Linkedin do Eskudo e também no da 2R Datatel!