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.
💲 Pix na linha de fogo: o que o ataque à Sinqia revela sobre risco de terceiros no sistema financeiro
O ataque que atingiu a Sinqia — integradora que conecta bancos e fintechs à infraestrutura do Banco Central — elevou o alerta sobre o risco de terceiros em serviços essenciais. Segundo comunicados e a cobertura da imprensa, criminosos movimentaram cerca de R$ 710 milhões em transações Pix não autorizadas na sexta-feira, 29 de agosto, valor que supera estimativas iniciais e cuja maior parte teria sido direcionada a contas ligadas ao HSBC; a SCD Artta também foi afetada. A companhia informou que parte do montante foi recuperada e que interrompeu temporariamente o processamento em seu ambiente Pix para conter o incidente e viabilizar a perícia. Elemento central da investigação: o uso de credenciais legítimas de fornecedores de TI para acionar rotinas transacionais.
A dinâmica do ataque reforça como a superfície de exposição não está apenas no código das plataformas, mas na cadeia de integrações e permissões operacionais que sustentam o negócio. Ao explorar credenciais de terceiros — muitas vezes com acessos amplos para suporte, automação ou contingência —, invasores conseguem operar “por dentro” dos fluxos, gerando transações válidas do ponto de vista do protocolo e, portanto, mais difíceis de bloquear em tempo real. O episódio ecoa um padrão observado semanas antes no caso da C&M Software, quando outro provedor da malha de mensageria do Pix foi alvo de desvio milionário, evidenciando que o elo frágil pode estar no perímetro de parceiros que prestam serviços críticos para diversas instituições.
A contenção combinou medidas operacionais da Sinqia e respostas do próprio regulador. Além do bloqueio de parte dos recursos nas trilhas de liquidação, o Banco Central anunciou, em 5 de setembro, novas restrições para reduzir o impacto de fraudes conduzidas via provedores de TI por instituições não autorizadas: um teto de R$ 15 mil por transferência para certos arranjos e a antecipação do prazo de licenciamento obrigatório dessas instituições para maio de 2026. A sinalização é clara: endurecer o controle sobre elos indiretos do sistema e forçar atacantes a pulverizar operações, elevando o atrito e a chance de detecção.
Para bancos e fintechs, as lições são práticas. Primeiro, governança de acessos de terceiros: revisar contratos e escopos de permissão (least privilege), exigir MFA forte e segregação de funções para contas técnicas de fornecedores, impor janelas e justificativas para elevação de privilégios, registrar todas as ações administrativas e girar credenciais com frequência. Segundo, blindagem de integrações: inventariar APIs expostas, parametrizar limites transacionais por contexto (valor, horário, geografia, conta), assinar e verificar mensagens ponta a ponta e ativar listas de bloqueio emergenciais para padrões anômalos. Terceiro, observabilidade: enriquecer o SIEM com telemetria específica de Pix, usar detecção comportamental para clusters de destinatários recém-criados e correlação entre múltiplas origens de eventos (core bancário, antifraude, mensageria, identidade). Por fim, exercitar playbooks de fraude em escala — do “kill switch” de integrações à comunicação coordenada com clientes, regulador e polícia — para reduzir a janela entre a descoberta e a interrupção. (Análise própria baseada em fatos reportados.)
Também é crucial diferenciar vulnerabilidade técnica de abuso de credenciais. No caso Sinqia, o vetor preliminarmente descrito aponta para mau uso de acessos válidos, e não para um “bug” de protocolo ou falha estrutural do Pix. Isso exige que o setor invista tanto em hardening de parceiros quanto em controles de compensação: limites dinâmicos, dupla verificação para fluxos atípicos, listas cinzas para contas receptoras recém-abertas, quarentena transacional por risco e automação de bloqueios coordenada com o Bacen. A consistência dessas camadas — combinada a auditorias independentes e métricas de tempo de detecção, bloqueio e recuperação — definirá a resiliência do ecossistema diante de ataques que exploram exatamente onde a cadeia é mais longa: nos terceiros que mantêm o sistema funcionando
🤖 IA no arsenal ofensivo: agentes autônomos encurtam o ciclo de ataque
A integração de LLMs e agentes automatizados aos toolkits de intrusão está mudando o jogo a favor dos atacantes. Em vez de scripts estáticos e checklists manuais, grupos criminosos já acoplam modelos capazes de explorar repositórios públicos, documentação técnica e metadados expostos para sugerir, em minutos, caminhos de ataque com maior probabilidade de sucesso. Esses agentes “leem” banners de serviços, correlacionam versões vulneráveis, geram payloads compatíveis e até escrevem variações de comandos para contornar listas de bloqueio, reduzindo a distância entre reconhecimento e execução.
Na prática, o fluxo fica mais agressivo em três frentes. Primeiro, descoberta e priorização: o agente avalia superfícies expostas (DNS, Git, pacotes, IaC) e classifica o que vale atacar agora, o que exige preparação e o que deve ser ignorado. Segundo, automação de exploração: com base em POCs públicas, o agente monta cadeias de exploração, testa credenciais prováveis e aciona “living-off-the-land” para permanecer furtivo. Terceiro, persuasão e extorsão: modelos geram e-mails e chats altamente personalizados para acelerar engenharia social, negociar resgates e pressionar vítimas com mensagens coerentes e instantâneas.
Para a defesa, “combater automação com automação” deixa de ser slogan e vira requisito. SOCs precisam de pipelines que ingiram telemetria diversa (identidade, endpoint, rede, cloud) e a enriqueçam com contexto de negócio, permitindo detecção comportamental em vez de depender apenas de assinaturas. Playbooks devem incluir controles de velocidade e de volume (rate limiting, timeboxing de privilégios), listas cinzas para destinos recém-criados, política de “duas pessoas” para ações sensíveis e “kill switches” transversais para encerrar integrações sob suspeita.
É hora também de treinar a equipe para lidar com extorsionistas mediados por bots, com protocolos de comunicação claros, limites de informação e registro completo das interações. Em paralelo, exercícios de red team precisam simular adversários aumentados por IA, testando desde a coleta automatizada de indícios até a negociação final. A diferença entre sobreviver e ceder ficará, cada vez mais, na capacidade de detectar padrões acelerados e responder no mesmo ritmo.
❌ SAP S/4HANA em alerta: CVE-2025-42957 já é explorada e pode entregar controle total do ERP
A falha crítica CVE-2025-42957 no SAP S/4HANA saiu do campo teórico para a exploração ativa, elevando o risco para ambientes on-prem e Private Cloud. Trata-se de uma injeção de código ABAP acessível via RFC que, a partir de uma conta de baixo privilégio, permite escalar até controle administrativo do sistema e até do sistema operacional subjacente. Pesquisadores descrevem o ataque como de “esforço mínimo”, o que reduz a barreira para agentes maliciosos e acelera o tempo entre intrusão e impacto no negócio.
O peso dessa vulnerabilidade decorre do lugar que o ERP ocupa. Um atacante com privilégios elevados no S/4HANA pode manipular ordens de compra, notas fiscais, parametrizações financeiras e saldos, além de criar usuários persistentes e portas de saída de dados. A superfície se amplia quando contas técnicas e integrações de terceiros mantêm acessos permanentes. A documentação oficial da SAP lista versões afetadas do S4CORE 102 a 108 e confirma pontuação CVSS 9,9, refletindo ataque remoto, baixa complexidade e alto impacto em confidencialidade, integridade e disponibilidade.
A primeira medida é aplicar imediatamente as correções liberadas no Patch Day de agosto, com a Security Note 3627998 para o S/4HANA. Ambientes com SLT ou DMIS relacionados devem verificar notas correlatas. Em paralelo, recomenda-se restringir o uso de RFC com UCON, revisar permissões de contas técnicas, exigir MFA onde couber e auditar criações de usuários e mudanças de papel com foco em segregação de funções. Monitorar logs por chamadas RFC incomuns e por elevação súbita de privilégios ajuda a identificar tentativas de abuso ainda na janela inicial.
Na caça a sinais de comprometimento, procure por transportes fora de ciclo, jobs suspeitos, alterações emergenciais em autorizações sensíveis e trilhas de extração de dados acima do normal. Rotacione credenciais de integrações, revalide escopos de APIs e aplique bloqueios temporários a funções de alto risco até concluir a verificação. Por fim, teste backups e procedimentos de recuperação para garantir que eventuais ajustes de emergência não tenham degradado a capacidade de voltar ao estado seguro rapidamente..
📨 Transparência, ruído e responsabilização: o que SBOM, o “alarme falso” do Gmail e o caso PowerSchool ensinam
A semana expôs três forças que moldam a segurança digital: exigência regulatória por transparência na cadeia de software, necessidade de comunicação técnica precisa para conter boatos e avanço da responsabilização jurídica de fornecedores após incidentes. No front regulatório, o governo dos EUA abriu consulta sobre os “Elementos Mínimos 2025” de SBOM, aprofundando requisitos para que softwares tragam um inventário confiável de componentes. Com SBOMs mais padronizadas e verificáveis, CISOs conseguem mapear rapidamente exposição a novas CVEs, priorizar correções por criticidade de ativos e exigir evidências de integridade de builds e dependências em contratos com terceiros. Em termos práticos, isso empurra o ecossistema a tratar transparência de componentes como requisito de conformidade, não como boa prática opcional.
No mesmo período, circularam relatos de um suposto “alerta massivo” de segurança do Gmail. O Google desmentiu, afirmando que a proteção do serviço segue eficaz e que a confusão nasceu de um incidente em plataformas de automação de vendas, onde tokens OAuth de terceiros foram abusados para acessar um subconjunto limitado de contas integradas. O caso é um estudo de pós-incidente: quando o fornecedor explica com rapidez o que aconteceu e o que não aconteceu, reduz-se espaço para pânico, golpes oportunistas e decisões precipitadas em escala, como resets indiscriminados. Para clientes corporativos, a lição é auditar integrações de apps de terceiros, revogar escopos desnecessários e monitorar criação e uso de tokens com a mesma disciplina aplicada a credenciais humanas.
Por fim, a ação do Procurador-Geral do Texas contra a PowerSchool, após a violação que expôs dados estudantis em 2024, sinaliza uma era de consequências mais duras para falhas de proteção em provedores críticos do setor público. O processo destaca a magnitude do vazamento global e o impacto local para cerca de 880 mil alunos e docentes no estado, além de alegações de controles insuficientes. Para gestores, o recado é inequívoco: contratos devem refletir responsabilidades por segurança, exigir controles auditáveis e prever sanções claras por descumprimento, sobretudo quando crianças e serviços essenciais estão em jogo.
Caso Sinqia / Pix e resposta do Banco Central
- IstoÉ Dinheiro — “Ataque hacker desviou R$ 700 milhões via Pix” (reportagem inicial). IstoÉ Dinheiro
- InfoMoney — “Desvio no ataque à Sinqia vai a R$ 710 mi; maior parte bloqueada”. InfoMoney
- EXAME — “Hackers desviam R$ 420 mi; HSBC e Artta entre afetados” (atualizada com posicionamentos). Exame
- Reuters — “BC do Brasil reforça segurança; teto de R$ 15 mil e licenciamento até mai/2026”. Reuters
- CNN Brasil — “BC cria teto de R$ 15 mil para Pix/TED em instituições via PSTI”. CNN Brasil
Agentes de IA no crime / PromptLock
- The Register — “Here’s how ransomware crims are abusing AI tools”. theregister.com
- The Register — “The crazy, true story behind the first AI-powered ransomware (PromptLock)”. theregister.com
- CyberScoop — “NYU team behind AI-powered malware dubbed ‘PromptLock’”. CyberScoop
- Tom’s Hardware — “AI-powered PromptLocker ransomware is an NYU research project”. Tom’s Hardware
SAP S/4HANA — CVE-2025-42957 (exploração ativa)
- Dark Reading — “Critical SAP S/4HANA Vulnerability Under Attack, Patch Now”. Dark Reading
- The Register — “Critical, make-me-super-user SAP S/4HANA bug under active exploitation”. theregister.com
- NVD/NIST — Ficha da CVE-2025-42957 (detalhes técnicos oficiais). NVD
- TechRadar Pro — “SAP users patch now — S/4HANA vuln being exploited in the wild”. TechRadar
SBOM, “alarme falso” do Gmail e ação contra a PowerSchool
- Google Workspace (blog oficial) — “Claims of a major Gmail security warning are false”. blog.google
- Ars Technica — “Google says reports of massive Gmail data breach are entirely false”. Ars Technica
- TechRadar Pro — “Google: no major security issue affecting Gmail (contexto Salesloft/Drift)”. TechRadar
- The Register — “Infosec in brief: Google clears up Gmail concerns; NSA drops SBOM bomb; Texas sues PowerSchool”. theregister.com
- CISA + parceiros globais — “A Shared Vision of SBOM for Cybersecurity” (guia conjunto). CISA+1
- Procuradoria-Geral do Texas — Press release sobre a ação contra a PowerSchool. Procurador-Geral do Texas
- The Record — “Texas sues PowerSchool for breach exposing data of students and teachers”. The Record from Recorded Future
- Houston Chronicle — “Paxton processa PowerSchool por vazamento que afetou ~880 mil no Texas”.
Para acompanhar todo lançamento do Eskudo News, nos siga no Linkedin do Eskudo e também no da 2R Datatel