Visualização de leitura

Nvidia’s $500B AI investment pool could impact enterprise chip pricing, availability

Nvidia and six financial partners are creating a $500 billion investment pool to help Nvidia customers including frontier AI labs, AI clouds, and other enterprises buy its chips on credit. 

The impact of such a cash infusion on enterprise AI is uncertain, but analysts fear that it could both further increase enterprise AI infrastructure costs and exacerbate the shortage of AI chips for data centers

The announcement from Nvidia and financial partners Apollo, BlackRock, Blackstone, Brookfield, Goldman Sachs and KKR said that their memorandums of understanding describe a fund “to establish the first compute financing platforms of their kind at global scale to enable the AI infrastructure buildout across Nvidia’s ecosystem, including leading frontier AI labs, enterprises and AI clouds.”

The group added that the fund would “create dedicated pools of capital at significant scale at attractive rates for Nvidia customers.”

Although the statement said the goal was to help AI infrastructure “across Nvidia’s ecosystem, including leading frontier AI labs, enterprises and AI clouds,” analysts and consultants agreed that it is highly unlikely any of these funds would be dispensed directly to enterprises, but would instead impact the overall AI supply chain.

Even the precise amount of money earmarked for the fund was unclear, with the statement merely saying that the amount would be more than $500 billion. 

Nvidia did not respond to requests for clarification about details of the proposed fund, but one financial partner did comment on the amount.

“We can clarify that this is a number that’s been totaled up by Nvidia,” said Simon Maine, managing director for communications at Brookfield Asset Management, in an email. “The finance partners are not collaborating together on this, but rather it is a series of individual partnerships. We therefore cannot comment on how the total figure has been arrived at.”

CIO concerns: chip pricing, availability

The top concern for CIOs around such a fund is the question of whether it would impact chip pricing along with that of components and devices using those chips, and if it would impact chip availability. Almost all of the analysts and consultants willing to speculate on that agreed that it would likely increase prices and worsen chip shortages. However, one optimistic interpretation of the fund was that it could help reduce chip shortages. 

“It remains to be seen what kind of downstream impact this initiative will have on enterprise spend,” said Ashish Nadkarni,  a group VP for IDC, but “there is an assumption here that these investments will go toward building fab capacity, and that the fabs will produce chips to address a chip shortfall.”

Other analysts disagreed, and argued that the fund would likely make the chip shortage worse, at least initially. 

“The current chip demand is taking all of the capacity and there is only so much chip fabrication capacity available,” said Mark Tauschek, a distinguished analyst at Info-Tech Research Group. “It will also take years to build new chip fabs. [The proposed Nvidia fund] will probably exacerbate the shortage.”

In fact, for enterprises, Tauschek projected a 15%-20% cost hike.

Sanchit Vir Gogia, chief analyst at Greyhound Research, agreed with Tauschek on both counts. 

He estimated that AI chip prices would be roughly the same for another year, and increasingly only at a good price if customers sign a long-term commitment. “The discount for committing is shrinking, not growing,” he said.

Thus, he pointed out, “more financing therefore means more new capacity is spoken for before it exists, and the open market gets whatever is left. The queue is no longer sorted by who can pay. It is sorted by who will commit.”

But he added that these numbers will likely improve eventually. “It does add real capacity in the end,” he noted. “Enterprises planning for 2028 will benefit. Those reacting to 2026 will not.”

Mike Wilkes, enterprise CISO at Aikido Security, said that one of the key impacts of the fund will be the way in which enterprises should view AI financing. That change, he argued, is both good and bad.

The improved availability of funds could “finance the AI buildout at much greater scale. That could accelerate enterprise access to compute, but it could also connect AI infrastructure much more tightly to the financial system,” Wilkes said. “This financing is likely to lower the cost of getting access to AI infrastructure in the near term, but not necessarily lower the price enterprises ultimately pay for AI.”

He suggested that potential enterprise impact will vary over time.

For large enterprises, the infusion of funds would allow their infrastructure vendors to build large datacenters without requiring financial help from the enterprise, he said, and this added capacity should eventually put downward pressure on the unit cost of compute.

“But,” he noted, “in the next few years, I would expect vendors to use cheaper financing primarily to build faster and lock customers into longer-term capacity contracts, rather than simply pass all of those savings through. In other words, enterprises may get more AI for the same dollar before they get the same AI for fewer dollars. So I think the biggest effect on enterprise readers is that this could remove one bottleneck while creating another.”

He expects that capital may cease to be the limiting factor in building AI infrastructure, giving CIOs considerably more capacity and more financing options available to them. “But,” he said, “the resulting competition may increasingly focus on who can persuade enterprises to make the longest and largest commitments to future AI consumption. If hundreds of billions of dollars of infrastructure are financed based on assumptions about future utilization, somebody ultimately has to pay when those assumptions prove wrong.”

Things will brighten, but not for awhile

Justin Greis, CEO of consulting firm Acceligence,  agreed that the short-term impact of this agreement may not be good for enterprise IT. 

“My view is that this financing will accelerate the creation of AI infrastructure, but it will not provide meaningful near-term price relief for most enterprises. In fact, I think the next 12-18 months could remain a period of elevated costs and constrained availability as the market absorbs this new wave of investment,” Greis said. The reason, he noted, is that the limiting factor today is not capital, it is the physical capacity to manufacture components.

“Adding hundreds of billions of dollars of available financing will create more buyers with the ability to compete for those resources,” he said. “My expectation is that the largest AI infrastructure providers and hyperscalers will continue to secure a significant share of available capacity because they have the scale, existing relationships, and ability to commit to long-term purchases.”

But eventually he believes that the enterprise picture should brighten. 

“Where I do expect enterprises to see benefits is further out. As this capital turns into actual infrastructure capacity, the market should become more competitive and enterprises should have more options in how they access compute,” Greis said.

“From a CIO perspective, I would not respond to this announcement by trying to secure more hardware. That is likely to become an expensive race that most enterprises cannot win.”

This article originally appeared on NetworkWorld.

Gerenciamento dos riscos de agregadores de LLM e proxies de API de IA | Blog oficial da Kaspersky

À medida que as organizações integram a IA em um espectro cada vez mais amplo de fluxos de trabalho, elas inevitavelmente enfrentam obstáculos em relação à confiabilidade e ao custo das ferramentas de IA. Esses desafios vão desde o tempo de inatividade temporário causado por interrupções técnicas e interrupções regulatórias de modelos críticos (como aconteceu com o Fable 5 há pouco tempo), até o bloqueio inesperado de casos de uso específicos (adeus, OpenClaw) ou excessos orçamentários significativos (como aconteceu com a Uber no início deste ano, uma dura lição para a empresa).

Para evitar o abandono de ferramentas críticas de IA, as empresas frequentemente usam serviços de terceiros que apresentam um único painel de controle que possibilita acessar vários modelos de IA. O fluxo de trabalho é direto: o usuário configura seu agente de IA ou acessa no navegador um endereço designado de um servidor proxy (um proxy de API), que consulta os modelos de destino em nome do usuário e retorna suas respostas.

Algumas plataformas neste espaço priorizam uma ampla seleção de modelos, rastreamento de uso simplificado e balanceamento de carga em APIs oficiais. Outras baseiam toda a sua estratégia de marketing na redução agressiva de custos. Esses últimos provedores oferecem serviços com descontos de dezenas de por cento, às vezes até por uma fração do custo em comparação com fornecedores oficiais, ao mesmo tempo em que prometem uma maneira de contornar quaisquer limites. Mas é claro que eles não alertam sobre os riscos graves que essas soluções alternativas representam para o desempenho, a confiabilidade e a segurança dos negócios.

Como os proxies de IA maliciosos operam

De acordo com um estudo recente do Oxford China Policy Lab, o modelo de negócios desses intermediários baratos depende muito da criação de contas. Os provedores configuram contas em dezenas de computadores, concluindo a verificação de identidade usando documentos falsos ou credenciais compradas de indivíduos em países em desenvolvimento. Para abastecer essas contas, eles aproveitam os períodos de avaliação gratuita ou créditos promocionais de API de valor fixo, ou compram assinaturas premium de primeira linha e dividem o acesso entre vários usuários finais por meio de automação.

O modo de operação dessas plataformas frequentemente chega a constituir crime cibernético. Suas estruturas de preços extremamente baixos são mantidas não apenas pela maximização dos limites de uso de contas, mas também pela utilização de credenciais roubadas de usuários legítimos e pela aquisição de assinaturas em massa com cartões de crédito comprometidos. Esses serviços são altamente automatizados: no momento em que um fornecedor de IA detecta e bane uma conta suspeita, o sistema substitui perfeitamente a credencial comprometida por uma nova.

Para os usuários, o problema vai muito além das implicações da obtenção de acesso ilícito. Um proxy de API obtém visibilidade total do tráfego entre o usuário final e o modelo, capturando prompts, caminhos de raciocínio e resultados. E o que é mais impactante: o proxy também tem a capacidade de manipular dados em ambas as direções. Vamos analisar os riscos que isso traz para as organizações.

Vazamentos de dados e roubo de propriedade intelectual

O estudo indica que o objetivo real de muitos desses serviços é coletar dados de interação de alta qualidade de modelos de primeira linha para treinar IA de terceiros. Em essência, a venda de acesso barato a uma API é apenas um chamariz; o verdadeiro produto são os usuários e seus dados.

Além das informações dos clientes e financeiras, a propriedade intelectual corre um sério risco. Muitas empresas investem recursos significativos no desenvolvimento de arquiteturas RAG complexas ou prompts de sistema exclusivos. Ao redirecionar consultas por meio de um proxy de procedência duvidosa, elas acabam transferindo seu conhecimento e lógica de negócios para terceiros desconhecidos.

Violações regulamentares e de conformidade

Para uma empresa, o simples ato de redirecionar dados de clientes usando um serviço de proxy não verificado, especialmente um que opera sob uma legislação ambígua, constitui uma violação direta das leis de privacidade de dados e, provavelmente, das obrigações contratuais firmadas com parceiros e clientes. Isso faz com que as organizações tenham que arcar com multas pesadas e danos à reputação, ainda que os dados comprometidos nunca sejam expostos ao público.

Falsificação e substituição de modelos

Certos serviços de proxy reduzem seus custos operacionais redirecionando algumas ou todas as consultas dos usuários para modelos de código aberto baratos em vez dos modelos proprietários premium solicitados. Essas respostas inferiores são então rotuladas novamente como se viessem do LLM caro. Testes conduzidos por pesquisadores do CISPA Helmholtz Center revelaram que, embora o envio de uma consulta envolvendo questões de saúde complexas diretamente ao Google Gemini 2.5 produza uma taxa de precisão de mais de 83%, o redirecionamento da mesma consulta por meio de vários proxies não verificados reduz essa taxa para 37%. A decisão de trocar os modelos é feita dinamicamente usando uma lógica obscura para maximizar as margens de lucro do provedor de proxy.

Manipulação secreta de solicitações e respostas

Um servidor proxy tem a capacidade técnica para executar um ataque man-in-the-middle. Um proxy malicioso pode injetar instruções ocultas nos prompts do usuário sem que ele perceba ou manipular as saídas do modelo. Por exemplo, se uma organização utiliza assistentes de codificação de IA para o desenvolvimento de softwares, o proxy pode instruir o LLM a gerar um código que contenha vulnerabilidades ou backdoors. Como consequência, os usuários não têm qualquer garantia de que sua base de código está sendo gerada por um modelo verificado e seguro que foi submetido a uma verificação de qualidade e segurança.

Tempo de inatividade e interrupções do serviço

Embora um dos principais fatores para migrar para um proxy de API seja mitigar as interrupções técnicas do lado dos fornecedores e permitir o failover contínuo entre diferentes provedores de modelos, muitas plataformas maliciosas sofrem com uma baixa confiabilidade operacional. Esses serviços ficam off-line com frequência, interrompendo o acesso a todos os LLMs conectados a eles simultaneamente.

A alternativa ética: agregadores oficiais

Existem provedores legítimos no mercado que oferecem serviços de agregação de API de maneira transparente e ética. Essas plataformas declaram quais modelos usam, oferecem redirecionamento flexível e definem os preços de seus serviços em valores próximos aos praticados pelos fornecedores oficiais.

Embora a OpenRouter seja, sem dúvidas, a plataforma mais reconhecida nesse espaço, as organizações podem explorar alternativas como a Poe.ai (que oferece um modelo de agregador baseado em assinatura com preço unificado) ou a Hugging Face (que oferece acesso extensivo a modelos de código aberto), ou manter contratos diretos com os principais fornecedores de IA enquanto centralizam o acesso, a confiabilidade e o gerenciamento de segurança internamente por meio de um proxy de API auto-hospedado criado no LiteLLM.

A estratégia de negócios dessas estruturas legítimas se concentra em mitigar a dependência de um único fornecedor, para que, por exemplo, caso a OpenAI aumente seus preços ou seja forçada a encerrar sua API, uma empresa possa redirecionar seus fluxos de trabalho de IA para fornecedores alternativos, como o Claude ou o Llama, sem precisar reescrever uma única linha de código. Esse é um mecanismo compatível com a otimização das despesas operacionais e a garantia da continuidade do negócio.

Cinco regras para a integração segura de modelos de IA

Para proteger dados e orçamento, siga as instruções de segurança:

  1. Utilize somente serviços verificados. Confie nas APIs oficiais para desenvolvedores ou em agregadores renomados que sejam validados pelos principais agentes do mercado e tenham certificações de segurança robustas.
  2. Desconfie de preços suspeitos. Se um serviço de terceiros prometer acesso a um modelo como o Opus 4.8 por um décimo do valor cobrado pelo fornecedor oficial, evite o serviço.
  3. Faça comparações rigorosas. Antes de implementar uma solução em escala, faça avaliações internas independentes. Verifique se os modelos fornecem consistentemente a qualidade de saída esperada e atendem aos requisitos de latência.
  4. Mantenha o controle sobre o redirecionamento. Você deve saber exatamente qual modelo recebe suas consultas e como o serviço executa o balanceamento de carga. Isso requer não apenas os meios técnicos de monitoramento, mas também obrigações contratuais explicitamente definidas pelo fornecedor do proxy da API.
  5. Processamento de dados de segmento com base na sensibilidade. Além do que foi exposto acima, evite redirecionar informações de identificação pessoal, segredos comerciais, códigos-fonte ou quaisquer outros dados confidenciais por meio de qualquer endpoint de API baseado em nuvem. Para essas cargas de trabalho, recomendamos implementar modelos de código aberto locais na sua própria infraestrutura e que estejam sob seu controle operacional total.

Ataques de phishing direcionados a empresas de manufatura | Blog oficial da Kaspersky

Identificamos uma nova campanha de phishing direcionada em que cibercriminosos tentaram atacar empresas de manufatura. O ataque envolveu uma abordagem em múltiplas etapas: antes de enviar o link de phishing diretamente, eles iniciaram uma conversa com a vítima por meio de e-mails a fim ganhar sua confiança. É provável que as conversas tenham sido geradas usando grandes modelos de linguagem. No momento desta postagem, o ataque ainda estava ocorrendo, por isso recomendamos atenção!

O esquema de phishing

Os invasores tentam se passar por clientes em potencial. Os e-mails são enviados por endereços registrados em serviços de e-mail gratuitos. Esses serviços não têm uma má reputação conhecida e geralmente são usados para o envio de e-mails corporativos, especialmente por pequenas empresas. Seja qual for o idioma nativo da vítima (vimos ataques direcionados a empresas na Rússia, República Tcheca, Malásia e Egito), os e-mails dos atacantes são sempre escritos em inglês.

No primeiro contato, eles fazem perguntas sobre os produtos oferecidos, citando nomes reais de produtos. Isso indica uma preparação minuciosa para os ataques. Eles não enviam e-mails idênticos para empresas de manufatura com perfis semelhantes, mas pesquisam cuidadosamente informações públicas disponíveis on-line sobre cada vítima. Se alguém responder ao primeiro e-mail, os invasores continuam a conversa. Às vezes, antes de ir direto ao seu objetivo, que é extrair credenciais de contas de e-mail corporativas, eles trocam várias mensagens nas quais, como distração, esclarecem certos detalhes ou fazem perguntas adicionais. Mas, na maior parte das vezes, eles enviam o link de phishing já no segundo e-mail.

Os invasores enviam especificações detalhadas de um produto no qual afirmam estar interessados, perguntam se o produto pode ser gravado de acordo com um esboço ou usam qualquer outro pretexto para tentar fazer com que a vítima abra o arquivo enviado.

Uma cadeia de e-mails que termina com um link de phishing

Site de phishing

Na realidade, não há nenhum arquivo. O site de phishing que é aberto quando a vítima clica no link imita um serviço na nuvem popular para editar documentos em PDF. O botão “Baixar” leva a um formulário de login no qual a vítima é solicitada a inserir seu endereço de e-mail corporativo e sua senha para acessar o arquivo confidencial. Obviamente, isso é “por motivos de segurança”. Se um funcionário da empresa alvo não parar para pensar por que inseriria suas credenciais de login corporativas em um site completamente sem relação com a empresa, um site que claramente não tem como verificar sua autenticidade, seu endereço de e-mail e a senha associada serão enviados para o servidor dos invasores.

Como se manter em segurança?

Os ataques de phishing modernos estão se tornando cada vez mais sofisticados e, graças ao uso de ferramentas de IA pelos atacantes, também mais convincentes. É por isso que, em primeiro lugar, recomendamos aumentar a conscientização sobre segurança dos funcionários sempre que possível. E para garantir que eles tenham que colocar esse conhecimento em prática o mínimo possível, recomenda-se implementar uma solução de segurança no nível do gateway de e-mail. O Kaspersky Secure Mail Gateway detecta esse ataque de phishing antes mesmo de os atacantes passarem para a tentativa de phishing propriamente dita.

Cloudflare wants to provide the operating system for the AI-first enterprise

Traditional operating systems (OS) were built to manage hardware, files, apps, and users on a device, but Cloudflare says the agentic AI era requires a whole new format.

The company this week announced Cloudflare OS, which connects AI agents, enterprise data and context, internal systems, and workflows together in one secure workspace. It is open source and browser-based, sparing companies the need to build all-new infrastructure.

The OS is launching alongside several other new security, identity, spending, and user insight tools that Cloudflare has built for the AI-based workplace.

“Cloudflare OS isn’t a traditional desktop OS,” said Rita Kozlov, VP of product at Cloudflare. “It reimagines the workplace computing environment for AI.”

Open source OS runs in a browser

Cloudflare OS serves as a secure, AI-equipped workspace that is plugged into internal company systems. Available now through Cloudflare’s open source repository, it is accessible directly in a browser, and runs inside an enterprise’s Cloudflare account.

“It is a browser-based workspace that begins with a conversation,” Kozlov explained. Users can ask an agent to research, create slides, spreadsheets, and documents, build full-stack apps, or automate workflows without the need for a terminal. Those outputs are then shareable, but kept in isolated databases with access controls.

Enterprises will soon be able to access the OS directly through Cloudflare or via a “select group” of partners that will build tailored offerings on Cloudflare’s architecture, the company says. Because it is open source, organizational processes, internal system connections, and context aren’t locked into a vendor product or AI model provider. Customers can use whatever models they choose.

Cloudflare OS is built on Cloudflare Workers, Dynamic Workers, Durable Objects, and Access, the company’s zero trust network access (ZTNA) tool that verifies every user and request. Agents start with zero permissions by default and are only granted access to tools required for a specific task. Organizations configure their own Access policies, models, branding, skills, and integrations, Kozlov explained.

Governed connectors known as gatekeepers give admins control over what AI can see, what it can change, and when the system needs human sign-off. They can also control budgets, set rate limits, and delegate tasks to different models.

“Because agents act on people’s behalf and produce work others can access and modify, they require a new security model,” Kozlov said. Thus, Cloudflare OS tracks the resources an agent requires so the right access controls follow its work when it is shared.

Cloudflare initially built the OS for internal use, and employees “across every team” use it daily. Kozlov estimated that, over the last 30 days, internal users have used it to create more than 4,000 apps, automations, and tools. Over that same period, she claimed, the company’s sales team saved an estimated 10,000 hours by automating previously manual tasks like territory planning and proposal creation.

“We open sourced Cloudflare OS so any organization can build ‘Your Company OS,’” Kozlov said. Open source is critical because “you cannot put your company into software you do not own. Organizations need to be able to inspect the platform, customize it, connect their own systems, and make it their own,” she explained.

A more cohesive bundle

Cloudflare deserves credit for packaging Cloudflare OS as an operating system, noted tech analyst Carmi Levy.

“This very much is not Windows, macOS, or Linux, and it isn’t an operating system by its common definition,” he said. “But Cloudflare’s use of this terminology implies familiarity to enterprise IT buyers.”

This makes for an easier discussion as enterprises struggle to understand how to best incorporate AI-related platforms and workflows into infrastructure that wasn’t initially designed for it.

Microsoft has marketed the combination of its Azure, Entra, Fabric, Windows, and Microsoft 365 offerings as an operating system of sorts, but hasn’t pulled all the pieces into a common brand, Levy said. And Google’s Gemini, Workspace, Vertex AI, and Cloud Run are “circling similar territory.”

But, he noted, Cloudflare OS is “more cohesively bundled” and infrastructure-focused, offering a single pane of glass platform for buyers worried about stitching together otherwise disparate AI-aware networking pieces. The company recognizes that AI introduces new architectural realities such as inference and model routing “over and above” traditional OS core competencies.

“While competing offerings generally leave the infrastructure heavy lifting to enterprise decision-makers, Cloudflare is marketing itself as a single-source vendor, which potentially frees IT planners from having to integrate all the AI pieces on their own,” Levy said.

An infrastructure-first, application-agnostic approach means Cloudflare OS can coexist with whatever AI applications already exist in an enterprise, he said. It will “play nice” with OpenAI, Anthropic, Google, Microsoft, Meta, or open source layers, allowing employees to begin working in familiar workflows after sign-in.

“Its open-source architecture also minimizes the potential for vendor lock-in as enterprises gradually figure out how to evolve their stacks to align with new AI-era realities,” Levy said.

Managing identities and budgets for both humans and AI

As AI agents emerge across the enterprise, tracking their use can be challenging, causing problems from both a security and a spend standpoint. Along with Cloudflare OS, the company has launched a way to address this issue with its new Identity-Aware AI Gateway, now in beta.

Also integrated with Access, the offering gives admins visibility into what users (both human and AI) are requesting from AI models. It allows security teams to set up custom domains in front of their gateways and replace shared API keys by integrating with their identity provider, like Okta or Entra, and ZTNA infrastructure, Cloudflare explained.

Every request is tied to Access-verified identities, and enterprises can filter each user’s logs, analytics, and spend. IT teams can track redundancies, limit usage rates, and apply filters that strip out employee names, passwords, and other sensitive data before requests go to outside model providers.

A companion feature, AI Spend, tracks every user’s behavior over time to create a baseline of normal AI usage. When spending deviates from that pattern, the system alerts the IT team.

A new tab, User Insights, tracks cost and identifies over-spend caused by activities such as low cache-hit rates or oversized context windows. The capability scores sessions and compares them against account history using a 95th percentile session cost over the previous 30 days, Cloudflare product managers Ming Lu, Kenny Johnson, and Ayush Kumar explain in a blog post. Anything above 2x an account’s 95th percentile is a “strong candidate for anomalous behavior.”

For instance, one Cloudflare customer had an employee who left a rogue AI session running, generating a $30K bill. “User Insights helped them identify the problem and shut off access before the problem was further exacerbated,” Kozlov said.

Cloudflare is also building prompt classification functionality that sorts requests into categories such as coding or writing. This can help enterprises understand what AI is being used for.

“Once business traffic is separated from everything else, personal use becomes visible,” the project managers explained. “From the outside, someone running a side hustle on company time and someone quietly moving data out through a model look the same. Telling them apart is central to catching insider risk.”

Looking at the bigger picture

Identity-Aware AI Gateway and AI Spend address the visibility problem that has dogged so many recent AI deployments where enterprises failed to monitor usage, Levy noted. Projects “crashed and burned” as users unwittingly blew through token allocations.

These platforms provide single-point visibility into what is being used, how it’s being used, and where the potential lies for raising the productivity bar, he said. They overlay with existing models; in doing so, they enhance security with more precise control over resource allocations, and via automated anonymization protocols that prevent inadvertent sharing of sensitive data.

Ultimately, he said, vendors who free IT from having to independently assemble the pieces of their own AI implementations, and who assist them with answers to AI-specific questions, “will gain advantage over vendors that aren’t looking at the bigger picture.

Combate a ataques BEC com IA | Blog oficial da Kaspersky

Não é segredo que os cibercriminosos vêm usando grandes modelos de linguagem para otimizar suas operações. Como resultado, as inúmeras campanhas de phishing e malware direcionadas às organizações tornaram-se muito mais sofisticadas. Esses e-mails agora contêm menos erros evidentes, e o tom deles se aproxima muito de uma correspondência comercial legítima. No entanto, os métodos usados para distribuir essas campanhas sempre apresentam um indício claro: uma tentativa de roubar credenciais ou executar código malicioso. Os ataques de comprometimento de e-mail comercial (BEC), no entanto, representam um desafio ainda maior.

Os ataques BEC normalmente dependem inteiramente da engenharia social, induzindo um funcionário legítimo a executar as ações solicitadas pelos invasores. Esses ataques também se tornaram muito mais sofisticados desde o surgimento dos LLMs. Se as táticas forem bem-sucedidas, por exemplo, se eles conseguirem convencer um funcionário a transferir fundos para uma conta de terceiros em vez da conta de um prestador de serviços, a empresa poderá perder muito dinheiro em questão de instantes. Foi por isso que desenvolvemos uma tecnologia especializada para detectar e-mails de BEC gerados com IA.

Um exemplo de um e-mail de BEC gerado por LLM.

Um exemplo de um e-mail de BEC gerado por LLM.

Como funciona a tecnologia de detecção de BEC gerado com IA

Sem entrar em muitos detalhes técnicos, veja como essa nova tecnologia funciona. Como você deve saber, os grandes modelos de linguagem não produzem textos da mesma forma que os seres humanos. Em vez disso, eles preveem as palavras que têm maior probabilidade de se adequar à tarefa descrita no prompt. Além disso, os cibercriminosos tendem a seguir o caminho mais fácil: em vez de reinventar a roda, recorrem aos modelos de IA mais amplamente disponíveis.

Como o objetivo dos invasores é relativamente claro, podemos extrair do texto frases-chave específicas de ataques de BEC. Além disso, aprendemos a identificar quando um texto foi gerado por uma máquina. Esses indicadores são um dos pilares da nossa tecnologia de detecção. Como resultado, nossa solução de segurança agora consegue identificar e bloquear tentativas de ataques BEC logo no estágio inicial, antes mesmo que o invasor tenha a oportunidade de enganar um funcionário. Atualmente, a tecnologia detecta e-mails de BEC gerados com IA em inglês, russo, alemão, francês, italiano, espanhol, português e turco.

Quais de nossas soluções apresentam a tecnologia de detecção de BEC gerada com IA?

Nosso portfólio de soluções de segurança corporativa inclui o Kaspersky Security for Mail Server, que incorpora o Kaspersky Secure Mail Gateway. É no gateway seguro de e-mail que nossa tecnologia de detecção de e-mails BEC gerados por IA está implementada. Mais especificamente, o recurso está disponível na licença KSMS Plus após a recente atualização para o KSMG 3.1. Visite a página oficial do Kaspersky Secure Mail Server para saber mais sobre nossas soluções de segurança de e-mail e os recursos adicionados na atualização mais recente.

O ataque FROST: como atrasos no acesso ao SSD expõem a atividade dos usuários | Blog oficial da Kaspersky

Cientistas da Universidade de Tecnologia de Graz, na Áustria, publicaram recentemente um artigo detalhando um novo método para monitorar a atividade de usuários em navegadores. O aspecto mais fascinante dessa nova técnica (batizada de FROST) é que ela usa a unidade de estado sólido (SSD) do computador para espionar o usuário. Sem entrar demais em detalhes técnicos, o ataque funciona assim: um hacker atrai a vítima para um site especialmente criado; enquanto a página permanecer aberta, o hacker consegue rastrear exatamente quais aplicativos o usuário está abrindo e quais outras páginas da Web está visitando.

Mas como isso é possível? A primeira reação, naturalmente, é culpar o navegador. Porém, nos navegadores modernos, cada site é executado em um sandbox e normalmente não consegue acessar outras guias, muito menos o hardware do computador. Embora hackers encontrem brechas nessas proteções de tempos em tempos, não é isso o que acontece aqui. O ataque FROST funciona perfeitamente mesmo com todas as medidas padrão de proteção do navegador ativadas. Em vez disso, ele explora um recurso totalmente legítimo chamado Origin Private File System (OPFS), que fornece aos sites um espaço virtual próprio para armazenar dados. No entanto, embora o armazenamento seja isolado digitalmente, os dados continuam sendo gravados no mesmo SSD usado pelos demais aplicativos e páginas abertos no computador. Pesquisadores descobriram que uma página maliciosa pode identificar o que está sendo executado no computador ao enviar solicitações contínuas ao SSD e analisar pequenas variações nos tempos de acesso. Antes de entrar nos detalhes de como isso funciona, vale entender rapidamente a teoria por trás do ataque.

Introdução rápida aos ataques de canal lateral

O termo “canal lateral” se refere a um método de espionar um computador, ou mesmo um único microchip, de forma indireta. Em vez de interceptar os dados em si, um invasor pode analisar variações no consumo de energia, monitorar a temperatura de componentes específicos ou até monitorar a radiação eletromagnética, entre outras coisas. Em teoria, isso significa que alguém poderia escutar uma conversa em uma sala usando apenas um mouse, já que o sensor óptico consegue captar vibrações sonoras. Da mesma forma, monitorar oscilações na frequência do processador pode permitir que um hacker roube uma chave de criptografia. Até mesmo um simples LED em um leitor de crachá pode revelar informações suficientes sobre o funcionamento interno do dispositivo para permitir a clonagem de um cartão inteligente.

O grande atrativo desses vazamentos indiretos, pelo menos do ponto de vista do hacker, é que eles são difíceis de detectar. Os fabricantes raramente levam esse tipo de comportamento em consideração ao projetar sistemas de segurança. Por outro lado, há uma limitação evidente: extrair informações por um mecanismo que nunca foi criado para transmitir dados costuma ser um processo complexo, lento e trabalhoso. Os pesquisadores austríacos concentraram seus estudos em um subtipo específico conhecido como ataque de canal lateral por contenção. Nesse caso, o vazamento acontece porque vários processos disputam o mesmo recurso. Aqui, o recurso disputado é a largura de banda da unidade de armazenamento.

Por dentro do ataque FROST

Esse canal lateral específico já havia sido estudado antes, inclusive em um artigo publicado em 2025. Na época, porém, o cenário era relativamente simples: os pesquisadores executavam um programa no computador para gerar os dados, enquanto um segundo programa, rodando na mesma máquina, tentava interceptá-los. Embora isso funcione bem para um estudo acadêmico teórico, o modelo de ataque não era exatamente revolucionário. Afinal, se um hacker já consegue executar qualquer programa no computador, não precisa recorrer a canais laterais complexos; existem várias formas diretas de roubar dados.

Ainda assim, o estudo do ano passado não foi em vão. Ele comprovou que a resolução obtida ao monitorar um SSD é alta, que o vazamento de dados é real e que as informações capturadas podem, de fato, ser úteis. O ataque FROST é essencialmente uma continuação lógica dessa mesma ideia.

Veja como ele funciona na prática. Imagine um arquivo relativamente grande armazenado em um SSD e preenchido com dados aleatórios. Um processo específico lê esse conteúdo em intervalos regulares e mede quanto tempo leva para obter uma resposta. Essa velocidade varia dependendo do nível de ocupação da unidade com outras tarefas. Esses atrasos de acesso funcionam como sinais reveladores da atividade da unidade. Os pesquisadores austríacos demonstraram que registrar esses atrasos ao longo do tempo permite identificar com boa precisão qual outra tarefa está sendo executada naquele exato momento.

Gráficos de latência

Padrões distintos de latência gerados ao abrir sites específicos Fonte

Os pesquisadores elaboraram gráficos de latência, como os acima, para vários sites e aplicativos executados localmente. O que eles encontraram foram padrões distintos, ou assinaturas digitais geradas toda vez que um site específico é carregado ou que um aplicativo é iniciado. Capturar essas janelas extremamente rápidas de carregamento exige monitoramento contínuo do SSD por um longo período. Mesmo assim, os padrões se mantiveram consistentes entre diferentes sistemas; os autores validaram o método em um desktop Linux e em um Apple Mac Mini. A partir daí, parece simples: criar um catálogo de assinaturas conhecidas, medir os atrasos reais do SSD, comparar os dois conjuntos e descobrir exatamente quais aplicativos o usuário está abrindo e quais sites está visitando. Mas como realizar esse tipo de vigilância sem levantar suspeitas e sem instalar malwares no computador da vítima?

É aí que entra um recurso relativamente novo dos navegadores chamado Origin Private File System (OPFS). Um invasor hipotético não precisa convencer o usuário a baixar um cavalo de Troia malicioso. Basta fazer a vítima visitar uma página especialmente criada, que usará o OPFS para monitorar silenciosamente a atividade do SSD. A sigla reúne todos esses elementos: FROST significa Fingerprinting Remotely using OPFS-based SSD Timing (identificação remota por assinatura digital com temporização de SSD baseada em OPFS). Veja o passo a passo de como todo o ataque acontece:

Fluxo do ataque FROST

Como o método FROST pode ser usado para espionar a atividade de um computador Fonte

Limitações do método

Como qualquer ataque de canal lateral, o FROST definitivamente não foi feito para ser rápido. É um processo lento e estruturado. Para descobrir exatamente o quanto, os pesquisadores construíram um ambiente de testes dedicado para medi-lo.

Configuração do ambiente de testes do FROST

Estrutura de testes usada para medir a velocidade de extração de dados via OPFS Fonte

A equipe executou um programa em um computador para transmitir dados de forma indireta. Pense nisso como um espião digital transmitindo uma mensagem secreta alterando a forma como interage com a unidade de armazenamento. Por exemplo, um 1 no código binário da mensagem pode indicar que o programa está usando o SSD, enquanto um 0 indica que está inativo. Ao mesmo tempo, os pesquisadores configuraram no navegador um receptor que acessava a unidade de armazenamento via OPFS. Como tanto o receptor no navegador quanto o programa transmissor disputavam a largura de banda do SSD, o navegador sofria pequenos atrasos de acesso sempre que o transmissor estava enviando dados ativamente.

Essa configuração inusitada conseguiu transmitir dados a 661 bits por segundo, com quase 90% de precisão em um desktop Linux com processador AMD. Em um Apple Mac Mini executando o macOS, a taxa de transferência chegou a 719 bits por segundo, também com precisão próxima de 90%. Embora esses números sejam um pouco inferiores aos do estudo do ano passado, que dependia de aplicativos instalados diretamente no computador, a diferença não é tão grande assim.

Dito isso, a verdadeira ameaça do ataque FROST não está na transmissão bruta de dados, mas no rastreamento da atividade do usuário. Mesmo com um banco de dados de assinaturas digitais de aplicativos e sites específicos, as informações vazadas por uma página maliciosa usando OPFS são pouco precisas e difíceis de correlacionar. Afinal, um computador está constantemente lendo e gravando dados no SSD em segundo plano. Para separar esse ruído digital, os pesquisadores recorreram a uma ferramenta que está se tornando padrão em ataques cibernéticos modernos: uma rede neural. Uma IA treinada com assinaturas conhecidas de SSDs conseguiu identificar com segurança a atividade do usuário mesmo em meio a um cenário caótico de dados em segundo plano. Os resultados finais são impressionantes. No Apple Mac Mini, a IA identificou corretamente qual site o usuário abriu em 89% dos casos e detectou a abertura de aplicativos locais com 96% de precisão. Mais importante: ela conseguiu identificar até quais sites foram abertos em um navegador completamente diferente daquele que estava executando a guia maliciosa. À primeira vista, parece um cenário ideal para os hackers, exceto por uma longa lista de limitações no mundo real.

O ataque FROST representa uma ameaça real?

O simples fato de saber quais aplicativos foram abertos ou quais sites foram visitados não dá ao invasor muita vantagem. Esse tipo de dado costuma ser mais útil para anunciantes interessados em traçar o perfil digital de um usuário sem autorização; ainda assim, aplicar esse método de rastreamento em larga escala é pouco realista. O principal obstáculo é a forma como os computadores gerenciam dados: o sistema move os dados mais acessados para a memória RAM, tornando-os praticamente invisíveis ao FROST, que depende da medição da largura de banda mais lenta do SSD físico. Para contornar esse obstáculo, a página maliciosa precisaria forçar o OPFS a criar um arquivo gigantesco, com bem mais de 1 GB. Nem é preciso dizer que um site consumindo recursos do disco de forma tão agressiva levantaria suspeitas imediatamente. Soluções de EDR ou XDR provavelmente marcariam isso como atividade anômala.

No fim das contas, isso significa que o ataque FROST, como a maioria dos métodos de espionagem por canal lateral, só é viável em operações altamente direcionadas. Mas isso nos leva de volta ao ponto inicial: descobrir quais aplicativos alguém abre ou quais páginas acessa é uma recompensa relativamente pequena diante do enorme esforço necessário para executar um ataque tão sofisticado.

Ainda assim, o FROST está muito à frente da maioria dos ataques acadêmicos de canal lateral quando o assunto é aplicabilidade no mundo real. Ele não exige malware pré-instalado, e a vítima não precisa fazer nada além de abrir uma página maliciosa. No mínimo, essa pesquisa serve como um lembrete importante de como os computadores modernos são complexos e de quantos pontos cegos inesperados podem acabar abrindo caminho para vazamentos de dados. Ao desenvolver sistemas ultrasseguros para informações sigilosas, é essencial considerar as particularidades do hardware. Se o objetivo for valioso o suficiente, um invasor determinado investirá tempo para criar um ataque altamente específico e complexo. Pesquisas como esta mostram que, no universo da cibersegurança, esse cenário não é impossível.

Guia para desativar o Copilot, o Gemini e o Apple Intelligence | Blog oficial da Kaspersky

Recentemente, desenvolvedores de software têm integrado recursos de IA a ferramentas de trabalho, sistemas operacionais e navegadores. Em alguns casos, eles são realmente úteis. No entanto, sua presença introduz riscos específicos, o que faz com que muitas empresas hesitem em conceder acesso a essas ferramentas aos funcionários. Em uma postagem anterior, categorizamos sistemas de IA indesejados, analisamos sua identificação em redes e endpoints e abordamos a solução definitiva: o gerenciamento de acesso OAuth em plataformas corporativas. Nesta análise aprofundada, vamos focar nas medidas práticas: detalhar como desativar ou restringir a IA integrada em plataformas populares.

Aviso rápido: grandes fornecedores de software podem alterar ocasionalmente os nomes das configurações de IA e seu funcionamento. Se alguma das opções abaixo estiver ausente ou não funcionar como esperado, uma busca rápida pelo nome da configuração normalmente levará à sua nova localização ou nome de marca.

Como desativar o Microsoft 365 Copilot

Detecção: você pode verificar o uso real do Copilot nos logs acessando Administração do Microsoft 365 (Microsoft 365 admin)Relatório de uso do Copilot (Copilot usage report).

Desativação por meio de políticas: no Centro de administração do Microsoft 365, acesse Configurações (Settings)Aplicativos integrados (Integrated Apps), localize Copilot na lista Aplicativos disponíveis (Available Apps) e selecione Bloquear (Block). Políticas de configuração mais granulares estão disponíveis em Personalização (Customization)Gerenciamento de políticas (Policy Management). A página Políticas (Policies) aqui contém mais de duas mil entradas, portanto, convém filtrá-las pela palavra-chave “Copilot” (guia detalhado). Como o Copilot é um complemento pago do Office, outra forma de bloqueá-lo e reduzir custos é evitar atribuir aos usuários SKUs que o incluam.

Recomendamos bloquear separadamente o Copilot Chat, disponível no Teams, Edge, Outlook e vários outros serviços. Sim, não é o Copilot em si. E sim, ele precisa ser bloqueado separadamente seguindo este guia.

Camada adicional de proteção: você pode bloquear os domínios copilot.cloud.microsoft e m365.cloud.microsoft/chat no filtro da Web ou no NGFW. No entanto, a Microsoft recomenda evitar essa prática, pois ela pode impedir o funcionamento correto de outros recursos do Microsoft 365.

Como desativar o Windows Copilot

Além da versão do Copilot para Office, também é necessário gerenciar a versão voltada ao consumidor.

Detecção: no NGFW ou em outros logs de rede, procure tráfego direcionado a copilot.microsoft.com, bing.com/chat ou edgeservices.bing.com.
Desativação por meio de políticas: na Política de Grupo do Windows, navegue até Configuração do computador (Computer Config)Modelos de administração (Admin Templates)Componentes do Windows (Windows Components)Windows Copilot. Na Política de Grupo do Microsoft 365, acesse Centro de administração (Admin center)Bloquear o Copilot voltado para o consumidor para contas organizacionais (Block consumer Copilot for organizational accounts).

Camada adicional de proteção: bloqueie totalmente a execução do executável Copilot.exe.

Como desativar a barra lateral do Copilot no Edge

Detecção: no NGFW ou em outros logs de rede, procure tráfego direcionado a copilot.microsoft.com, bing.com/chat ou edgeservices.bing.com.

Bloqueio: configure as seguintes Políticas de Grupo do MS Edge: HubsSidebarEnabled = falso, EdgeShoppingAssistantEnabled = falso, CopilotPageContext = Desativado (falso), CopilotNewTabPageEnabled = falso, Microsoft365CopilotChatIconEnabled = falso, GenAILocalFoundationalModelSettings = 1 (observe que desativar isso exige inesperadamente um 1 em vez de 0).

Camada adicional de proteção: bloqueie os domínios copilot.cloud.microsoft e m365.cloud.microsoft/chat no filtro da Web ou no NGFW. No entanto, a Microsoft não aconselha fazer isso, pois pode quebrar outros recursos.

Como desativar o Gemini Assistant no Google Workspace

Detecção: verifique o Console de administração do Workspace (admin.google.com), na seção Relatório de uso do Gemini (Gemini usage).

Bloqueio por meio de políticas: no Console de administração, navegue até Aplicativos (Apps)Serviços adicionais do Google (Additional Google services) → > Aplicativo Gemini (Gemini app) e defina-o como DESATIVADO (OFF). Em seguida, acesse Gerenciar configurações dos recursos inteligentes do Workspace (Manage Workspace smart feature settings)Recursos inteligentes no Google Workspace (Smart features in Google Workspace) e defina-o como DESATIVADO (OFF).

Camada adicional de proteção: bloqueie o tráfego de rede para os domínios gemini.google.com, bard.google.com e aistudio.google.com.

Como desativar o Gemini no Google Chrome

Detecção: verifique seus relatórios do Chrome Enterprise (Gerenciamento do Chrome (Chrome management)Relatórios (Reports)) ou procure nos registros de tráfego de rede conexões com os domínios mencionados anteriormente.

Bloqueio por meio de políticas: nas políticas do Chrome Enterprise, defina as seguintes configurações: GenAILocalFoundationalModelSettings = 0, HelpMeWriteSettings = 2 (desativado), TabOrganizerSettings = 2, CreateThemesSettings = 2, DevToolsGenAiSettings = 2.

Camada adicional de proteção: bloqueie o tráfego de rede para os domínios gemini.google.com, bard.google.com e aistudio.google.com. Além disso, bloqueie instalações não autorizadas do Chrome/Chromium (aquelas que estão fora do gerenciamento de políticas) com a ajuda de ferramentas de controle de aplicativos baseadas em host, como EPP/EDR ou AppLocker.

Como desativar a Apple Intelligence

Detecção: no NGFW e filtros da Web, o tráfego direcionado a apple-relay.apple.com e *.apple-cloudkit.com é um indicador claro de que a Apple Intelligence está ativa.

Bloqueio por meio de políticas: qualquer dispositivo Apple gerenciado permite desativar recursos individuais de IA, embora não haja um botão central que você possa usar para desativar “todos os recursos de IA”. Em seu perfil de MDM, você precisa definir as seguintes chaves como false (desativado): allowWritingTools, allowMailSummary, allowGenmoji, allowImagePlayground, allowImageWand, allowPersonalizedHandwritingResults, allowExternalIntelligenceIntegrations, allowExternalIntelligenceIntegrationsSignIn, allowNotesTranscription e allowNotesTranscriptionSummary. Veja este pequeno snippet de configuração:

<dict>

<key>PayloadType</key>

<string>com.apple.applicationaccess</string>

<key>allowWritingTools</key>

<false/>

<key>allowMailSummary</key>

<false/>

</dict>

Apesar da mudança da Apple para o gerenciamento declarativo de dispositivos, esses recursos de IA ainda precisam ser gerenciados por meio das configurações tradicionais de carga do MDM.

Camada adicional de proteção: bloqueie o tráfego de rede para os hosts mencionados acima; embora isso tenha a desvantagem óbvia de não funcionar em dispositivos móveis fora da rede corporativa.

KASG: gateway de segurança para veículos autônomos | Blog oficial da Kaspersky

De acordo com uma pesquisa internacional, a participação de mercado de veículos sem motorista e altamente automatizados está crescendo rapidamente. Os analistas estimam que os próximos 10 a 15 anos marcarão uma grande mudança de projetos-piloto para a adoção em massa do transporte autônomo. O impulso está crescendo em todo o mundo: a Europa já implementou mais de 35 projetos-piloto de veículos autônomos, enquanto os EUA e a China registram mais de 450 mil e 250 mil viagens comerciais respectivamente por semana. No entanto, o relatório observa vários obstáculos que retardam esse progresso. Uma dessas barreiras é a incerteza em torno da responsabilidade legal e da regulamentação, inclusive nas áreas de segurança e proteção. A alocação de responsabilidade entre fornecedores, fabricantes, clientes corporativos e usuários finais continua sendo um ponto importante de discussão.

Cada player do mercado vê a questão de garantir a segurança de veículos autônomos de forma diferente. Para as montadoras, significa assumir a responsabilidade por como um veículo se comporta na estrada e por verificar seus fornecedores. Para os próprios fornecedores, significa projetar mecanismos de segurança diretamente na sua arquitetura de solução desde o primeiro dia e garantir sua adequação. Para as seguradoras, isso significa revisar completamente seus modelos de risco para considerar não apenas acidentes, mas também possíveis falhas de software e ataques cibernéticos. Em última instância, todos concordam em um ponto fundamental: a segurança deve ser um recurso fundamental do veículo, não um complemento opcional.

Como garantir a segurança veicular na era moderna

Durante anos, as discussões sobre segurança automotiva se concentraram estritamente na segurança funcional. Em outras palavras, o objetivo era garantir que os sistemas veiculares funcionassem corretamente e que os riscos associados a possíveis falhas fossem totalmente mitigados ou reduzidos a um nível aceitável. A norma ISO 26262 “Veículos rodoviários — Segurança funcional” ajuda a enfrentar esse desafio e serve como parâmetro para a indústria automotiva.

No entanto, o veículo conectado moderno é um sistema ciberfísico complexo que armazena e processa grandes quantidades de dados, incluindo informações confidenciais. Como consequência, isso leva ao surgimento de novas necessidades fundamentais. Para traçar uma analogia com dois níveis da hierarquia de necessidades de Maslow, um veículo moderno deve:

  • Satisfazer a necessidade de “estima”. Isso significa que o sistema deve armazenar de forma segura e confiável os dados do perfil do usuário, como credenciais da conta, dados biométricos, detalhes de pagamento e muito mais.
  • Satisfazer as necessidades cognitivas do usuário, o que significa que o sistema deve fornecer conectividade segura com a internet, transmitir a telemetria do veículo e enviar lembretes para manutenção programada ou de emergência.

Tudo isso significa equipar os veículos com uma ampla gama de interfaces (telemática, Bluetooth, Wi-Fi, conectividade celular, atualizações OTA e V2X), o que abre as portas para ataques remotos. Portanto, é necessário garantir não apenas a segurança funcional, mas também a segurança das informações no veículo. Como resultado, normas especializadas do setor que ajudam a enfrentar os desafios de segurança cibernética automotiva surgiram na maioria dos países. As principais normas internacionais são ISO/SAE 21434 “Veículos rodoviários — Engenharia de segurança cibernética”, UNECE R155 e UNECE R156.

As regulamentações na China também estão evoluindo. Em 2024, o país publicou a norma nacional GB 44495-2024 “Requisitos Técnicos para Segurança Cibernética de Veículos”, que entrou em vigor em 1º de janeiro de 2026. O documento introduz requisitos obrigatórios de segurança cibernética para veículos, incluindo proteção de comunicações, gerenciamento de eventos de segurança, monitoramento de ameaças e interação segura do veículo com a infraestrutura externa.

Compreender e aplicar essas normas está se tornando absolutamente crítico. A pesquisa mostra que os riscos de segurança cibernética estão aumentando diariamente e o impacto na segurança funcional pode eventualmente desencadear incidentes muito mais perigosos do que uma falha interna do sistema. O que acontece se um invasor obtiver acesso ao sistema de controle remoto de um caminhão autônomo ou conseguir atualizar uma unidade de controle eletrônico crítica durante uma sessão de diagnóstico não autorizada?

Um dos principais componentes para mitigar esses cenários é um gateway de segurança, que isola a arquitetura do veículo em diferentes domínios com base na criticidade, ao mesmo tempo em que fornece roteamento, filtragem e controle de tráfego seguros. Desenvolver esse tipo de solução de software é precisamente o foco de nossa equipe à medida que criamos o Kaspersky Automotive Secure Gateway com base em KasperskyOS.

Qual o diferencial do Kaspersky Automotive Secure Gateway?

O objetivo principal do Kaspersky Automotive Secure Gateway (KASG) é proteger o domínio CAN do veículo, pois o barramento CAN é usado para transmitir uma grande quantidade de comandos de controle críticos. Isso afeta quase 80% das unidades de controle eletrônico dentro do veículo, que lidam com o gerenciamento do motor, frenagem, eletrônica da carroceria e muito mais. Por isso, utilizamos a abordagem de Cibersegurança Protetiva, uma arquitetura unificada que considera os requisitos de segurança funcional e de segurança cibernética.

Por exemplo, os mecanismos padrão de Proteção de ponta a ponta (E2E) são normalmente usados para mitigar os riscos associados a mensagens CAN perdidas, fora de ordem ou corrompidas. No entanto, esses mecanismos não foram originalmente projetados para combater ciberataques direcionados. Se um invasor conseguir construir um quadro malicioso que esteja em conformidade com o formato E2E necessário, o sistema poderá aceitá-lo como válido.

Isso introduz um novo fator: é fundamental não apenas verificar se uma mensagem foi entregue sem erros, mas também garantir que foi realmente gerada por uma unidade de controle eletrônico (ECU) confiável e não foi alterada em trânsito. Isso é particularmente vital para transmitir comandos de controle, como aqueles enviados ao sistema de frenagem do veículo, ou para implementar sistemas de entrada sem chave (NFC).

Para enfrentar esse desafio, os mecanismos de Comunicação Segura A Bordo (SecOC) são integrados à arquitetura do veículo. Esses sistemas usam métodos criptográficos para verificar a autenticidade e a integridade da mensagem, protegendo o sistema contra ataques de spoofing e repetição de mensagens. O KASG implementa com sucesso esses mecanismos, que, além da verificação de mensagens, executam a função crucial de gerenciamento centralizado de chaves. Isso permite que as chaves de criptografia sejam distribuídas e atualizadas a partir de um único ponto dentro do veículo, reduzindo o custo e a carga de processamento nas ECUs envolvidas na troca de dados apoiada pelo SecOC.

IDS automotivo

No entanto, em sistemas complexos, não é mais suficiente aplicar mecanismos de segurança somente a mensagens individuais ou segmentos de rede separados. É essencial fornecer monitoramento e controle em todo o veículo, rastreando anomalias comportamentais, interações incomuns entre domínios e tentativas de adulteração não autorizadas. No domínio de TI, isso é conhecido como um Sistema de Detecção de Intrusão (IDS). Esses sistemas também foram adotados com sucesso pela indústria automotiva.

Ao mesmo tempo, é importante perceber que, para um veículo moderno, um IDS não é um único ponto mágico de coleta e análise de dados. O veículo requer um sistema de monitoramento distribuído. O monitoramento é realizado em vários níveis de arquitetura: dentro dos domínios, no nível do controlador individual e nos limites da rede.

O gateway de segurança se torna um ponto de monitoramento crítico porque toda a interação entre domínios passa por ele. Além disso, o gateway fornece visibilidade da troca de dados em diferentes segmentos da rede veicular. Sua missão é detectar desvios do comportamento normal e gerar eventos de segurança.

Quando se trata do monitoramento do domínio CAN implementado no KASG, o IDS observa os seguintes critérios para análise de tráfego:

  • Alinhamento dos parâmetros da mensagem CAN (CAN ID, DLC) com suas descrições na especificação DBC.
  • Frequência e periodicidade das mensagens CAN.
  • Faixas permitidas para sinais CAN.

Na prática, no entanto, uma limitação importante fica clara: mesmo com um IDS integrado, é necessário mais contexto para determinar as características exatas de um ataque. Além disso, ao operar veículos altamente automatizados, onde o monitoramento de toda a frota é essencial, essa análise isolada torna-se inerentemente insuficiente.

Conectar um veículo a um SIEM

O monitoramento de múltiplos objetos, a correlação de dados e a análise de dados podem ser tratados externamente com eficiência, especificamente em sistemas SIEM (Gerenciamento de Eventos e Informações de Segurança), que são tradicionalmente usados em centros de operações de segurança cibernética corporativos e industriais. Portanto, utilizar um sistema SIEM em toda a frota é uma etapa lógica que torna possível:

  • Coletar eventos de segurança de vários veículos.
  • Correlacione eventos ao longo do tempo e entre contextos.
  • Detecte ataques avançados e distribuídos.
  • Fornecer auditoria e investigação de incidentes.
  • Responda a incidentes individuais e gerencie os riscos cibernéticos em toda a frota.

Ao integrar com sistemas SIEM externos, várias tarefas críticas devem ser abordadas: garantir uma conexão segura, ajustar o processo de transmissão de eventos de segurança e estabelecer regras de linha de base para o processamento e a correlação de eventos. Estamos trabalhando ativamente em todos esses desafios usando nosso próprio sistema SIEM Kaspersky Unified Monitoring and Analysis Platform como plano-base.

Ainda há muitos desafios pela frente que precisam ser resolvidos. Este artigo abordou apenas uma fração das metodologias atualmente usadas no KASG para garantir a segurança e proteção veicular. No entanto, mesmo esta pequena seção demonstra que a segurança automotiva não pode ser alcançada resolvendo um único problema ou aplicando um único mecanismo. Alcançar a proteção eficaz requer uma abordagem que permita o desenvolvimento metódico da arquitetura, equilibrando diversos requisitos para a funcionalidade, segurança e confiabilidade veicular.

Critical SearchLeak Flaw in Microsoft 365 Copilot Exposed Sensitive Enterprise Data

SearchLeak vulnerability

A newly disclosed SearchLeak vulnerability in Microsoft 365 Copilot Enterprise exposed a critical pathway for attackers to steal sensitive organizational data through a specially crafted URL. The flaw chain, now tracked as CVE-2026-42824, was patched by Microsoft earlier this month and assigned a critical severity rating due to its potential impact. Security researchers at Varonis discovered the issue by combining three separate weaknesses that, on their own, posed limited risk. Together, however, they enabled attackers to silently extract emails, calendar information, SharePoint documents, OneDrive files, and other indexed enterprise content accessible through Microsoft 365 Copilot Enterprise.

How the SearchLeak Vulnerability Worked 

According to the researchers, the SearchLeak vulnerability combined an AI-specific flaw known as Parameter-to-Prompt Injection (P2P) with two traditional web security issues: an HTML rendering race condition and a server-side request forgery (SSRF) vulnerability involving Bing.  The first stage exploited the search function of Microsoft 365 Copilot Enterprise, where the "q" URL parameter was passed directly to Copilot as an executable prompt. Instead of being treated as a simple search query, attacker-controlled input could be interpreted as instructions.  Researchers demonstrated that a malicious URL could instruct Copilot to search a victim’s mailbox, retrieve email titles or other sensitive content, and embed the extracted data inside an image URL without requiring any user interaction beyond a click. 

Chaining Three Flaws into One Attack 

The second stage relied on an HTML rendering race condition. While Microsoft attempted to neutralize potentially dangerous HTML by wrapping responses inside code blocks, that protection occurred only after Copilot completed generating its response. During the streaming phase, raw HTML, including image tags, could briefly render and trigger outbound requests before sanitization took effect.  The final component of the SearchLeak vulnerability involved a Content Security Policy bypass through Bing. Since Bing domains were allowlisted, attackers leveraged Bing’s image search endpoint, which performs server-side fetching of image URLs. By embedding stolen data within those URLs, Bing unknowingly acted as a proxy, forwarding the information to attacker-controlled servers.  As described by Varonis, the attack required no plugins, elevated privileges, additional clicks, or suspicious domains. Victims only needed to open a trusted Microsoft link. 

Potential Impact of CVE-2026-42824 

Because Microsoft 365 Copilot Enterprise operates with the user's existing permissions, successful exploitation of CVE-2026-42824 effectively granted attackers access to whatever information the targeted employee could access.  Potentially exposed data included email content, one-time passwords, password reset links, calendar events, meeting notes, attendee information, confidential communications, SharePoint files, OneDrive documents, earnings reports, salary information, acquisition plans, and other sensitive business records.  The researchers noted that the novelty of the SearchLeak vulnerability lies in how AI-enabled prompt injection made older attack techniques practical in a new environment. Without the P2P flaw, attackers could not inject malicious instructions; without the race condition, the HTML would be neutralized; and without the SSRF weakness, the Content Security Policy would block data exfiltration.  Microsoft has since remediated the issue under CVE-2026-42824, but researchers say the case highlights how AI systems can introduce new attack paths by connecting previously understood vulnerabilities in unexpected ways. 

Splunk Urges Immediate Patching of Critical Flaw Enabling Arbitrary File Operations

CVE-2026-20253

A newly disclosed security vulnerability in Splunk Enterprise has prompted urgent patching efforts after researchers revealed that the flaw could allow unauthenticated attackers to perform arbitrary file operations and potentially achieve remote code execution. The issue, identified as CVE-2026-20253, affects certain versions of Splunk Enterprise and carries a critical CVSS score of 9.8.  The vulnerability stems from weaknesses in a PostgreSQL sidecar service used within affected deployments. While Splunk Cloud remains unaffected, organizations running vulnerable on-premises versions of Splunk Enterprise are being urged to install security updates as soon as possible. 

CVE-2026-20253 Affects Multiple Splunk Enterprise Versions 

According to a security advisory issued by Splunk, the flaw exists in Splunk Enterprise versions below 10.2.4 and 10.0.7.  The company explained the issue in the following statement:  "In Splunk Enterprise versions below 10.2.4 and 10.0.7, an unauthenticated user could create or truncate arbitrary files through a PostgreSQL sidecar service endpoint."  Splunk further noted:  "The vulnerability exists because the PostgreSQL sidecar service endpoint lacks authentication controls, allowing any network-reachable user to invoke file operations without credentials."  Because the affected PostgreSQL endpoint does not enforce authentication requirements, attackers with network access can interact with it without providing valid credentials, creating a security risk for exposed systems. 

Patched Versions and Affected Releases 

Splunk has released updates to address CVE-2026-20253 across affected product lines.  The impacted and fixed versions are: 
  • Splunk Enterprise 10.0.0 through 10.0.6 — fixed in 10.0.7 
  • Splunk Enterprise 10.2.0 through 10.2.3 — fixed in 10.2.4 
  • Splunk Enterprise 10.4 — not affected 
The company also clarified that Splunk Cloud is not vulnerable to this issue because the platform does not utilize the PostgreSQL sidecars associated with the flaw. 

How Attackers Could Exploit the PostgreSQL Weakness 

Security researchers explained that threat actors could exploit CVE-2026-20253 by abusing PostgreSQL functionality to write attacker-controlled files onto a target system.  One key component of the attack involves lo_export, a PostgreSQL function capable of extracting a BLOB (Binary Large Object) from a database and saving it as a file on the underlying filesystem. By creating a malicious function that leverages lo_export, an attacker could write arbitrary content to files on the Splunk server.  The attack becomes more dangerous when the malicious function is executed during a database restoration process. This allows the attacker-controlled content to be written directly to the filesystem, opening a pathway to further compromise. 

From Arbitrary File Write to Remote Code Execution 

Researchers noted that obtaining arbitrary file-write capabilities within Splunk Enterprise can serve as a stepping stone toward full remote code execution.  An attacker could overwrite Python scripts that are routinely executed by Splunk services. One example highlighted is:  /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py  By replacing or modifying such scripts with malicious code, an attacker could cause the payload to execute automatically when the script runs, effectively granting remote code execution on the affected system. 

Attack Chain Associated With CVE-2026-20253 

The disclosed exploitation sequence involves several steps: 
  1. Create a database and configure it to allow user authentication without a password while granting permissions required to execute functions such as lo_export. 
  2. Use the /backup endpoint to place a dump of the remote database onto the Splunk filesystem. 
  3. Use the /restore endpoint to import the malicious database dump, triggering execution of the attacker-created function during restoration and writing a malicious Python script to the filesystem. 
Through this process, attackers can leverage the vulnerable PostgreSQL sidecar service to transform a file-write capability into a mechanism for executing arbitrary code. 

Como desativar ferramentas de IA não aprovadas para toda a organização | Blog oficial da Kaspersky

Enquanto muitas empresas estão lançando intencionalmente a IA para impulsionar qualidade e eficiência, ferramentas de IA não autorizadas estão surgindo em ambientes corporativos com ainda mais velocidade. Os fornecedores de software estão incorporando a IA diretamente nos produtos que as empresas já usam (veja o caso do Microsoft Copilot e no Google Gemini), enquanto os funcionários estão entrando em ação por conta própria e instalando ferramentas às escondidas. Como resultado, as empresas estão encarando um canal de vazamento de dados mal gerenciado: a equipe cola informações de sistemas corporativos em chatbots de IA, enviando dados não apenas para o provedor de SaaS, mas diretamente para os desenvolvedores por trás do modelo de IA subjacente. Tanto os riscos quanto as estratégias de mitigação variam dependendo do tipo de sistema de IA em jogo. Dividimos esse tópico amplo, concentrando-nos fortemente em ferramentas para detectar e bloquear a IA em dois níveis distintos.

Tipos de sistemas de IA indesejados

Dependendo do tipo de IA em questão, gerenciar e bloquear seu uso requer um método diferente. É fundamental dividir a IA em quatro categorias distintas:

  • Recursos de IA nativos de plataformas. Esse é o caso do Microsoft Copilot, Google Gemini e Apple Intelligence, juntamente com recursos de IA incorporados diretamente nos navegadores. O complicado sobre essas soluções é que elas são incorporadas aos elementos essenciais de rotina, estão instantaneamente disponíveis para todos os usuários (às vezes aparecendo de forma agressiva) e, o mais importante, os fornecedores tentam ativá-las por padrão.
  • Complementos de IA incorporados em aplicativos de negócios. Esse grupo inclui a IA do Slack, Zoom AI Companion, a IA do Notion, o assistente Rovo do Jira e outras soluções semelhantes. Elas estão vinculadas a um único aplicativo e são completamente inseparáveis dele.
  • Chatbots independentes baseados na web e em aplicativos. ChatGPT, Claude, Perplexity, Character AI, configurações locais como LM Studio, extensões de navegador e navegadores agênticos como Comet. Os aplicativos e serviços nesta categoria geralmente são adotados pelos funcionários por conta própria sem permissão e são exemplos clássicos da IA paralela.
  • Agentes multifuncionais nativos da área de trabalho. Este grupo apresenta ferramentas como OpenClaw, NanoClaw, NemoClaw e outras. Elas representam a maior ameaça porque vêm com amplos direitos de acesso por padrão e processam ativamente dados não confiáveis da web aberta.

Como lidar com IA indesejada?

Cada empresa, dependendo do setor de atividade, apetite por inovação e tolerância ao risco, precisa traçar sua própria linha divisória entre casos de uso recomendados, aprovados caso a caso e os completamente proibidos para produtos de IA específicos. Setores regulamentados, como os de saúde, seguem um conjunto de regras, enquanto as empresas de varejo operam sob um playbook totalmente diferente. De qualquer forma, depois de analisar exatamente quais ferramentas de IA já entraram na organização, as políticas corporativas precisam ser ajustadas. É por isso que o imperativo de negócios número um é empregar as ferramentas de registro e segurança da informação existentes para verificar a infraestrutura corporativa.

Dependendo da estratégia escolhida, os sistemas de IA descobertos podem ser:

  • Desativado ou restritos usando as configurações de política corporativa incorporadas nas próprias ferramentas
  • Bloqueados no endpoint ou no nível da rede para criar uma rede de segurança contra soluções alternativas de política ou erros de configuração
  • Transicionados para o acesso gerenciado, em que a ferramenta não é completamente bloqueada, mas roteada por meio de um gateway corporativo dedicado que verifica as permissões de acesso e monitora os padrões de uso

Detecção de sistemas de IA

A detecção de IA requer uma abordagem em várias camadas, pois diferentes métodos de detecção se complementam e funcionam melhor em tipos específicos de IA.

Tecnologia O que a solução é capaz de detectar?
DNS Qualquer ferramenta de IA com um domínio identificável
Gateway da web ou NGFW Qualquer ferramenta de IA com uma impressão digital de solicitação e resposta reconhecível (caminhos de endpoint da API, domínios e outros indicadores). Os filtros da web podem inspecionar o conteúdo do tráfego, e muitos gateways/NGFWs agora apresentam uma categoria dedicada para detectar e bloquear a IA generativa
EPP/EDR LLMs implementados localmente (executando via Ollama, LM Studio e shells semelhantes), aplicativos de desktop nativos para ChatGPT ou Claude, navegadores de agentes e agentes de IA de código aberto. Um sinal de alerta indireto, mas forte, é a presença de Node.js, Python, Git, Docker ou outras ferramentas de conteinerização em máquinas pertencentes à equipe não técnica
Controle de aplicativos Semelhante ao EPP/EDR, isso permite bloquear aplicativos indesejados imediatamente
Controle do navegador Extensões de navegador com foco em IA e visitas a sites com tema de IA. Este é um salva-vidas se o gateway da web corporativo não puder inspecionar o tráfego criptografado
Gerenciamento de Postura de Segurança SaaS (SSPM) / Governança de Identidade Permissões de OAuth solicitadas por aplicativos e serviços de IA, bem como quaisquer integrações de terceiros que se conectam aos principais hubs de produtividade (Microsoft 365, Google Workspace etc)

Quase todas essas ferramentas permitem fazer mais do que apenas detectar a IA: elas permitem bloqueá-la completamente ou, no mínimo, alertar a equipe responsável.

De olho na OAuth

As soluções populares de IA administrativa, especialmente assistentes de reunião, agentes de automação de e-mail e calendário e semelhantes, obtêm acesso aos dados corporativos solicitando permissões OAuth diretamente das plataformas de comunicação, fluxo de trabalho de documentos ou videoconferência. Se um usuário tiver a oportunidade de conceder essas permissões a aplicativos de terceiros, os vazamentos de dados resultantes ignorarão completamente o perímetro da organização. Ferramentas como EDR e NGFW não detectarão nada se uma ferramenta como Read.ai capturar gravações de cada reunião realizadas no Microsoft Teams, por exemplo.

A medida mais drástica, que geralmente é a melhor, é impedir que usuários comuns concedam OAuth em primeiro lugar. Veja como lidar com a parte técnica (são necessários direitos de Administrador Global, Administrador de Aplicativos ou equivalentes):

Microsoft 365 / Entra ID

No centro de administração do Microsoft Entra, acesse Identidade > Aplicativos > Aplicativos empresariais > Consentimento e permissões > Configurações de consentimento do usuário. Nessa seção, o Consentimento do usuário para aplicativos pode ser desativado (confira guia completo da Microsoft).

Google Workspace

No Console de Administração do Google, acesse Segurança > Controle de acesso e dados > Controles de API. Em Gerenciar acesso ao aplicativo, o nível de confiança de todos os aplicativos pode ser definido: Confiável, Limitado, Dados específicos do Google ou Bloqueados. No entanto, a chave está na subseção Configurações do aplicativo não configurado, que determina o que acontece quando um usuário tenta conectar um aplicativo desconhecido. Para fechar essa brecha, selecione Não permitir que os usuários acessem aplicativos de terceiros.

Uma subseção separada, Gerenciar serviços do Google, permite ajustar exatamente como os aplicativos de terceiros interagem com os serviços do Google Workspace e do Google Cloud. Isso permite vetar o acesso para cada produto individual do Google (consulte o guia oficial do Google).

Salesforce

Em Configuração, use a caixa Busca rápida para pesquisar aplicativos conectados e selecione Gerenciar aplicativos conectados nos resultados. Embora as configurações sejam definidas para cada aplicativo externo individualmente, todos os usuários podem aprovar o acesso por padrão. Não há um botão de bloqueio geral aqui. Em vez disso, o Salesforce permite optar por usuários pré-autorizados aprovados pelo administrador (consulte o guia completo do Salesforce sobre isso).

Slack

No menu de configurações de administração, acesse Aplicativos e fluxos de trabalho -> Configurações de gerenciamento de aplicativos. Ajuste a configuração Exigir aplicativos aprovados selecionando Permitir somente aplicativos pré-aprovados. Depois de bloqueado, verifique novamente se nenhuma ferramenta de IA não autorizada foi inserida na lista de aplicativos aprovados.

Arte ASCII em e-mails de phishing | Blog oficial da Kaspersky

Já escrevemos várias vezes sobre como códigos QR são usados em esquemas de phishing. Nosso gateway seguro de e-mail até inclui tecnologia para ler esses códigos (não apenas em e-mails, mas também em anexos) e verificar os links incorporados. Ainda assim, os criminosos não desistem de enviar códigos QR às suas vítimas. Recentemente, temos observado um aumento no uso de arte ASCII para essa finalidade. Trata-se de imagens criadas a partir de caracteres de texto. Isso é particularmente irônico, considerando que, no passado, os phishers tentavam escapar da verificação de links escondendo-os em imagens e, agora, estão tentando burlar a análise de imagens voltando ao uso de texto. Mas com algumas adaptações.

A arte esquecida do ASCII e como os criminosos a utilizam

Hoje pode parecer difícil acreditar, mas houve uma época em que os computadores não eram capazes de exibir imagens gráficas. Por isso, as primeiras imagens digitais eram construídas com caracteres de texto. Após a adoção do padrão ASCII (American Standard Code for Information Interchange) em 1963, seus caracteres passaram a ser amplamente utilizados para criar esse tipo de arte, garantindo que as imagens fossem exibidas da mesma forma em diferentes computadores. Com o passar do tempo, outros símbolos de texto, como os presentes no conjunto Unicode expandido, também passaram a ser utilizados na criação dessas imagens. Ainda assim, o termo “arte ASCII” continuou sendo usado para descrever esse estilo artístico de forma geral. Houve artistas que se dedicaram seriamente a essa técnica. Os primeiros sites da Internet utilizavam arte ASCII em seu design e até mesmo os primeiros conteúdos pornográficos digitais eram representados exclusivamente por caracteres de texto.

Com a evolução das tecnologias gráficas, a arte ASCII perdeu popularidade. Ela voltou a ganhar destaque nos anos 2000, durante o auge do spam por e-mail. Naquela época, os spammers utilizavam a técnica principalmente para disfarçar palavras associadas a spam que poderiam acionar filtros de e-mail. Além disso, mensagens compostas por texto consumiam menos recursos dos servidores do que imagens. Outro fator era que muitos usuários pagavam pelo volume de tráfego de Internet utilizado e, por isso, frequentemente desativavam o carregamento de imagens em seus clientes de e-mail. Naturalmente, naquela época, ampliamos nossas soluções de segurança para e-mail com tecnologias específicas para detectar e bloquear arte ASCII maliciosa.

Agora, a técnica de ASCII foi redescoberta, desta vez por criminosos que buscam contornar sistemas capazes de reconhecer códigos QR presentes em imagens.

Como é um ataque de phishing com arte ASCII?

Veja um exemplo recente. O pretexto em si é bem comum: alguém supostamente enviou à vítima um documento confidencial via DocuSign, mas, para abri-lo, o destinatário precisa escanear o código QR no e-mail para acessar um site e inserir suas credenciais corporativas.

Um código QR criado com arte ASCII

Código QR criado com caracteres Unicode. Parte do código foi desfocada para impedir que o link malicioso fosse escaneado

À primeira vista, o código parece estranho. Isso acontece porque ele é desenhado utilizando caracteres pseudo-gráficos e até mesmo os espaços entre as linhas ficam visíveis. Na realidade, não há nenhuma imagem propriamente dita no código da mensagem de e-mail. Nos bastidores, o código QR se parece com algo assim:

Arte ASCII presente no código do e-mail

Arte ASCII presente no código do e-mail

Como resultado, os mecanismos de verificação de links não conseguem identificar o endereço, e as ferramentas de análise de imagens não conseguem detectar a URL oculta no código QR. Com isso, os criminosos acreditam que o e-mail de phishing chegará à vítima sem problemas. Spoiler: não esquecemos como bloquear arte ASCII.

É normal receber um código QR por e-mail?

Em teoria, existem situações legítimas em que o uso de um código QR faz sentido. Ele é uma forma prática de compartilhar contatos, links para aplicativos móveis, localizações em mapas ou informações de configuração. Em outras palavras, funciona bem quando o objetivo é transferir informações diretamente para um dispositivo móvel.

No entanto, se alguém pedir que você utilize um código QR para inserir credenciais corporativas em um smartphone, isso deve ser considerado um forte sinal de alerta. E quando esse código QR é criado com arte ASCII, trata-se claramente de uma tentativa de phishing ou de direcionamento para uma URL maliciosa. Esse tipo de técnica tem apenas uma finalidade: tentar contornar mecanismos de segurança.

Como se proteger?

Para impedir que e-mails de phishing, contendo ou não arte ASCII, cheguem às caixas de entrada dos colaboradores, recomendamos a adoção de um gateway de e-mail seguro antiphishing. Como camada adicional de defesa, é importante instalar soluções de segurança em todos os dispositivos utilizados para acessar a Internet.

Também recomendamos a realização periódica de treinamentos de conscientização em segurança, para que os colaboradores conheçam as táticas de phishing mais recentes. Vale destacar, especificamente, que a presença de arte ASCII em e-mails modernos pode ser um indicativo importante de uma tentativa de ataque de phishing.

A evolução das regras de correlação do SIEM | Blog oficial da Kaspersky

Em termos simples, a lógica do sistema SIEM funciona assim: se o evento A ocorrer seguido do evento B, isso pode indicar um ataque, e um especialista em segurança da informação deverá ser notificado. Mas, no cenário atual, esse modelo simples está se mostrando cada vez menos eficaz. Recentemente, nossos especialistas analisaram um incidente de grande repercussão: invasores comprometeram a infraestrutura de atualização do popular software Notepad++ e distribuíram malware por meio do mecanismo de atualização. É simplesmente impossível ter regras previamente definidas e especificamente projetadas para neutralizar cenários desse tipo.

Os próprios ataques tornaram-se mais sofisticados: os invasores usam ferramentas legítimas, atacam a cadeia de suprimentos comprometendo softwares fora do perímetro corporativo, estendem seus cenários ao longo do tempo e disfarçam suas ações como atividades normais. Em outras palavras, eles não “invadem” a infraestrutura; na maioria das vezes, eles fazem login e usam software legítimo. Como resultado, as regras fixas clássicas do passado não são acionadas ou geram muitos alertas falsos. Foi isso que levou à mudança para cenários de correlação mais flexíveis.

Conteúdo SIEM atualizado dinamicamente

Atualmente, o conteúdo de correlação não é mais um conjunto estático de regras, mas sim um processo: ele evolui e se adapta constantemente às ameaças atuais. Somente em 2025, lançamos 55 atualizações de pacotes de regras para diferentes versões e idiomas do nosso sistema Kaspersky SIEM. Em apenas um ano, adicionamos 10 novos pacotes de regras, além de 250 regras de detecção e diversas melhorias no conteúdo existente. Neste ano, já adicionamos 43 novas regras e refinamos outras 63. No total, isso equivale a mais de 850 regras que abrangem uma parte significativa da estrutura MITRE ATT&CK.

As regras do Kaspersky SIEM são desenvolvidas com base nos insights de nossos especialistas, que analisam ataques recentes no mundo real, principalmente a partir das descobertas do nosso serviço de detecção e resposta gerenciada (MDR) e das nossas pesquisas sobre ameaças. Como resultado, nossas regras abrangem cenários (do reconhecimento à escalação de privilégios) que envolvem as abordagens mais recentes utilizadas pelos invasores. Por exemplo, detectamos o uso de novas técnicas de ataque, como a campanha ToolShell.

Além das atualizações programadas, a equipe também lança regularmente o chamado conteúdo emergencial: conjuntos de regras voltados à resposta rápida a técnicas de ataque novas e inesperadas. Em fevereiro, por exemplo, regras de detecção foram lançadas para contornar a autenticação em produtos Fortinet por meio do mecanismo de SSO: os invasores usaram solicitações SAML especialmente elaboradas para obter acesso a sistemas sem credenciais.

De eventos a cadeias de ataque

Além disso, as regras SIEM modernas não descrevem mais eventos individuais, mas sequências de ações. Os cenários são estruturados em torno das etapas de um ataque: desde o acesso inicial até a escalação de privilégios e a persistência. A eficácia do Kaspersky SIEM é ampliada por meio da integração com o Kaspersky EDR e de conjuntos de regras dedicados ao Active Directory, que implementam dezenas de cenários de detecção de ataques em diferentes estágios. Essa abordagem nos permite ver não apenas sinais individuais, mas o quadro completo.

Integração e visibilidade interna

Outra maneira de melhorar a eficácia de um sistema SIEM é expandir as fontes de dados. Um SIEM clássico agrega eventos de diferentes níveis da infraestrutura: desde logs até telemetria de endpoints e sistemas internos. Além disso, nosso sistema SIEM inclui conjuntos especializados de regras para nossas outras soluções (Kaspersky Security Center, Kaspersky Security for Mail Groups, plataforma Kaspersky Anti Targeted Attack), que permitem o monitoramento de ações de administradores, autenticação e status do serviço. Como resultado, o sistema se torna uma ferramenta não somente para detectar ataques, mas também para monitorar a atividade interna.

No geral, o SIEM deixou de ser apenas um conjunto de regras e evoluiu para um sistema de detecção continuamente atualizado. A eficácia é determinada não pela quantidade de detecções, mas sim pela relevância delas, pela coerência e pela precisão com que refletem as ações reais dos invasores. Acompanhe as novidades sobre nossa solução Kaspersky Unified Monitoring and Analysis Platform (SIEM) na página oficial do produto.

Uso real do Kaspersky Container Security | Blog oficial da Kaspersky

Entre as várias ferramentas no portfólio da Kaspersky está uma plataforma dedicada para proteger ambientes em contêineres. Mas nesta postagem, quero falar sobre o Kaspersky Container Security (KCS), não como um representante do fornecedor, mas como membro de uma equipe que usa ativamente essa solução em sua rotina de trabalho. Nossa Equipe de Segurança de Produto é responsável por estabelecer processos de desenvolvimento seguros em toda a empresa. Estamos envolvidos em todas as etapas do ciclo de vida de desenvolvimento de software, e nossa prioridade é ajudar as equipes de produto a detectar problemas de segurança com antecedência para que possam cumprir o cronograma de seus lançamentos. Para isso, criamos vários fluxos de trabalho, um dos quais se concentra especificamente na segurança do contêiner. É nesse contexto que contamos com nossa própria plataforma Kaspersky Container Security.

As soluções de segurança para contêineres geralmente são vistas principalmente como verificadores de imagens para registros de contêineres. No entanto, o Kaspersky Container Security (KCS) é uma plataforma de segurança mais abrangente para ambientes de contêiner que lida com várias tarefas em virtude de sua integração de ponta a ponta no fluxo de trabalho do contêiner. Embora certamente inclua um cenário de verificação do contêiner, o que é inegavelmente importante, nossa experiência com o KCS mostrou que seu valor real se torna aparente quando ele é integrado em vários pontos ao longo do fluxo de trabalho de uma só vez:

  • Compilações regulares
  • Verificação de artefato antes de lançamento ou implementação
  • Monitoramento de contêineres já em execução no cluster

O cenário de referência: como o KCS verifica imagens

Em sua essência, o processo é padrão. O KCS verifica as imagens em busca de problemas comuns em contêineres: vulnerabilidades conhecidas, malware, segredos codificados diretamente no código (hardcoded) e configurações incorretas. No entanto, o resultado da verificação não é apenas um veredicto único e abstrato. O sistema calcula uma classificação de risco com base nas descobertas, fornecendo uma imagem clara da postura de segurança do ativo. Na prática, isso é incrivelmente útil porque as equipes não veem apenas uma mensagem de “imagem ruim”; elas obtêm um detalhamento claro do que está de fato gerando o risco e do que precisa ser corrigido primeiro.

Mas isso não é tudo. O KCS funciona bem para cenários em que não é suficiente apenas encontrar um problema: é necessário vinculá-lo ao ciclo de vida do artefato. Quando uma equipe gerencia centenas de compilações, a verificação periódica do registro não é suficiente e quase sempre requer intervenção manual. É preciso saber qual pipeline introduziu o risco, quais políticas foram acionadas e quais são as próximas etapas. O KCS fornece esse vínculo essencial.

Cenário avançado: integração de CI/CD

Uma característica menos conhecida do KCS é seu recurso de verificação em grande escala dentro de pipelines de CI/CD. Para nossa equipe, essa é a maneira mais eficaz de usar o KCS. A lógica é direta: você integra o verificador no pipeline e os resultados da verificação aparecem diretamente nos logs de execução. Eles também são enviados para o console central da solução, onde são registrados em uma seção de CI/CD dedicada que vincula as descobertas ao nome do artefato, horário de verificação, pipeline e nível de gravidade.

Em um ambiente de CI/CD, é possível verificar imagens de arquivos compactados TAR ou diretamente de repositórios Git. Pronto para uso, é compatível com GitLab, Jenkins, TeamCity e GitHub Actions; na prática, o KCS pode ser integrado em qualquer orquestrador de pipeline.

Outro aspecto crítico do uso do KCS no CI/CD envolve as políticas de segurança. Nossa solução usa um modelo em que as políticas permitem não apenas coletar resultados, mas também controlar o comportamento do próprio pipeline. Isso é útil para implementações em fases. Você pode iniciar no modo de auditoria e, em seguida, avançar gradualmente para compilações com falha quando forem detectados segredos, configurações incorretas críticas ou vulnerabilidades. Essa abordagem evolutiva geralmente funciona melhor do que simplesmente apertar um botão para bloquear tudo de uma vez.

Como o KCS ajuda em nossos fluxos de trabalho

Executamos nosso próprio sistema de análise de composição, portanto, não tratamos o KCS como uma fonte de verdade única. Em vez disso, serve como uma poderosa camada extra em nossos fluxos de trabalho, e é nesse aspecto que ele entrega mais valor.

Enquanto nosso sistema interno de análise de composição lida com rastreamento de componentes, dependências e avaliação de risco em nível de código, o KCS se destaca na proteção do perímetro do contêiner. Ele cuida da verificação técnica de imagens e da segurança de CI/CD, ao mesmo tempo em que agrega relatórios sobre artefatos de contêiner. Não entra em conflito com nossa análise interna; ele a reforça exatamente no ponto em que os contêineres recebem cargas de trabalho reais.

Isso é particularmente útil para nós em dois cenários. Primeiro, ele fornece controle de artefatos em estágio inicial durante o desenvolvimento. Em segundo lugar, ele atua como um gatekeeper durante o aprovação de versão. Não debatemos mais os riscos algum tempo depois do lançamento; nós os detectamos no ponto exato em que a equipe ainda pode corrigir rapidamente um Dockerfile, um gráfico do Helm ou um conjunto de configurações sem uma longa cadeia de aprovação.

O modo como ele lida com uma lista de materiais de software (SBOM) também merece destaque. Nosso sistema depende principalmente de SBOMs relevantes e atualizados. O KCS oferece modos específicos para o processamento de SBOMs e pode até mesmo gerar resultados de verificação no mesmo formato. Nesse sentido, o KCS se integra perfeitamente aos nossos processos internos, permitindo incorporá-lo aos nossos fluxos de trabalho existentes, em vez de precisarmos adaptar nossos fluxos a ele.

Por que, para nós, o KCS é mais do que apenas um verificador

Sua outra camada poderosa é a segurança do cluster. Neste estágio, o KCS evolui para além de ser apenas uma ferramenta de verificação de imagens. Ele apresenta políticas de tempo de execução para contêineres e nós, modos de auditoria e bloqueio, além de um conjunto de perfis de segurança. Em termos práticos, isso significa que o KCS pode ser usado não apenas para encontrar vulnerabilidades em uma imagem, mas também para monitorar o que o contêiner está realmente fazendo quando ativo. As políticas podem considerar a proveniência da imagem, assinaturas digitais, restrições de recursos e volumes, bem como até mesmo os processos e as conexões de rede em execução dentro do contêiner.

Quando um problema é detectado, você tem a opção de registrar os resultados no modo de auditoria primeiro, em vez de bloquear o processo imediatamente. Em ambientes de produção, essa é sempre a decisão mais inteligente. Outra ferramenta vital é garantir a procedência confiável das imagens. O KCS é compatível com a verificação de assinatura digital, o que muda o foco de simplesmente encontrar CVEs para proteger toda a cadeia de fornecimento de software da empresa.

Recursos de relatórios

O KCS faz mais do que apenas exibir os problemas que detecta; ele serve como uma fonte abrangente de relatórios. Ele pode gerar relatórios sobre imagens, riscos aceitos e benchmarks do Kubernetes.

Os relatórios gerados estão disponíveis nos formatos HTML, PDF, CSV, JSON e XML, com compatibilidade específica para SARIF em relatórios detalhados, o que é ideal para integração em fluxos de trabalho AppSec. Quanto aos SBOMs mencionados acima, os cenários de verificação podem gerar artefatos e resultados nos formatos CycloneDX e SPDX, facilitando a conexão a processos existentes.

Por que continuamos a usar o KCS

Para simplificar, o KCS complementa nossos fluxos de trabalho perfeitamente: não porque resolve todos os problemas, mas porque se integra de forma muito eficaz aos cenários de engenharia.

Também valorizamos o fato de que a equipe do produto considera o nosso feedback. A equipe do KCS realmente incorpora nossas solicitações operacionais práticas em seu roteiro de desenvolvimento. Por exemplo, a integração profunda do SBOM e os tipos de relatório específicos foram adicionados ao KCS como resultado direto de nossa experiência prática.

Em resumo, quando integrado corretamente, o Kaspersky Container Security ajuda a abranger várias áreas ao mesmo tempo: desde a verificação básica de contêineres até CI/CD e segurança de clusters. Em nossa experiência, ele fornece valor real em um ecossistema de contêiner ativo. Saiba mais sobre a solução na página oficial do KCS.

Como proteger sua organização contra vulnerabilidades de Wi-Fi do AirSnitch

Na conferência de segurança da informação NDSS Symposium 2026, realizada em fevereiro em San Diego, um renomado grupo de pesquisadores apresentou um estudo que revelou o ataque AirSnitch, capaz de contornar o recurso de isolamento de clientes Wi-Fi, também conhecido como rede de visitantes ou isolamento de dispositivos. Esse ataque permite conectar-se a uma rede sem fio por meio de um ponto de acesso e, a partir daí, acesse outros dispositivos conectados, inclusive os que usam identificadores de rede (SSIDs) diferentes no mesmo hardware. Os dispositivos-alvo podem facilmente estar em sub-redes sem fio protegidas por WPA2 ou WPA3. Na verdade, o ataque não quebra a criptografia; ele explora a maneira como os pontos de acesso lidam com chaves de grupo e roteamento de pacotes.

Na prática, isso significa que redes de visitantes oferecem um nível muito baixo de segurança real. Se as redes corporativa e de visitantes estiverem no mesmo dispositivo físico, o AirSnitch permite que um invasor conectado injete tráfego malicioso em SSIDs vizinhos. Em alguns casos, ele pode até realizar um ataque man-in-the-middle (MitM) completo.

A segurança do Wi-Fi e o papel do isolamento

A segurança do Wi-Fi está em constante evolução. Sempre que surge um ataque viável contra a geração de proteção mais recente, o setor responde com algoritmos e processos mais complexos. Esse ciclo começou com os ataques FMS, usados para quebrar chaves de criptografia WEP, e continua até hoje. Exemplos recentes incluem os ataques KRACK ao WPA2 e os FragAttacks, que afetam todas as versões do protocolo de segurança WEP até WPA3.

Atacar redes Wi-Fi modernas de forma eficaz (e discreta) não é uma tarefa simples. A maioria dos profissionais considera que usar WPA2/WPA3 com chaves complexas e separar redes por finalidade costuma ser suficiente para a proteção. No entanto, apenas especialistas sabem que o isolamento de clientes nunca foi padronizado nos protocolos IEEE 802.11. Fabricantes diferentes implementam esse isolamento de formas distintas, usando a Camada 2 ou 3 da arquitetura de rede (ou seja, no roteador ou no controlador Wi-Fi), o que significa que o comportamento de sub-redes isoladas varia bastante dependendo do ponto de acesso específico ou do modelo do roteador.

Embora o marketing afirme que o isolamento de clientes é ideal para impedir que visitantes de restaurantes ou hotéis ataquem uns aos outros, ou para garantir que visitantes corporativos não possam acessar nada além da Internet, na prática, esse isolamento muitas vezes depende do fato de ninguém tentar explorá-lo. É justamente isso que a pesquisa sobre o AirSnitch demonstra.

Tipos de ataques AirSnitch

O nome AirSnitch não se refere a uma única vulnerabilidade, mas a toda uma família de falhas de arquitetura em pontos de acesso Wi-Fi. Também é o nome de uma ferramenta de código aberto usada para testar roteadores quanto a esses pontos fracos específicos. Ainda assim, os profissionais de segurança precisam lembrar que a linha entre teste e ataque é bastante tênue.

O modelo desses ataques é sempre parecido: um cliente malicioso se conecta a um ponto de acesso com isolamento ativado. Outros usuários (as vítimas) estão conectados ao mesmo SSID ou a SSIDs diferentes no mesmo ponto de acesso. Esse cenário é comum; por exemplo, uma rede de visitantes pode estar aberta e sem criptografia, ou um invasor pode simplesmente obter a senha do Wi-Fi de visitante se passando por um visitante legítimo.

Para determinados ataques AirSnitch, o invasor precisa saber previamente o endereço MAC ou o IP da vítima.  Em última análise, a eficácia de cada ataque depende do fabricante do hardware (veja mais detalhes abaixo).

Ataque de GTK

Após o handshake do WPA2/WPA3, o ponto de acesso e os clientes compartilham uma Group Transient Key (GTK) para lidar com o tráfego de broadcast. Nesse cenário, o invasor encapsula os pacotes destinados a uma vítima específica dentro de um pacote de tráfego de transmissão. Em seguida, ele envia esses pacotes diretamente à vítima, falsificando o endereço MAC do ponto de acesso. Esse ataque permite apenas a injeção de tráfego, o que significa que o invasor não recebe uma resposta. Mesmo assim, já é suficiente para enviar anúncios de roteamento ICMPv6 maliciosos ou mensagens DNS e ARP ao cliente, ignorando efetivamente o isolamento. Essa é a forma mais universal do ataque, funcionando em redes WPA2/WPA3 que usam uma GTK compartilhada. Alguns pontos de acesso corporativos, no entanto, permitem a randomização da GTK por cliente, o que neutraliza esse método.

Redirecionamento de pacotes de transmissão

Nessa versão do ataque, o invasor nem precisa se autenticar primeiro no ponto de acesso. Ele envia pacotes ao ponto de acesso com um endereço de destino de transmissão (FF:FF:FF:FF:FF:FF) e a sinalização ToDS definida como 1.  Como resultado, muitos pontos de acesso tratam esse pacote como tráfego de transmissão legítimo, o criptografam usando a GTK e o enviam para todos os clientes na sub-rede, incluindo a vítima. Assim como no método anterior, é possível encapsular o tráfego especificamente destinado a uma única vítima dentro dos pacotes.

Redirecionamento via roteador

Esse ataque explora uma falha de arquitetura entre as Camadas de segurança 2 e 3 presente no hardware de alguns fabricantes. O invasor envia um pacote ao ponto de acesso, definindo o endereço IP da vítima como destino na camada de rede (L3).  No entanto, na camada sem fio (L2), o destino é definido como o próprio endereço MAC do ponto de acesso, evitando que o filtro de isolamento seja acionado. O subsistema de roteamento (L3) depois encaminha o pacote de volta à vítima, contornando completamente o isolamento da L2. Assim como nos métodos anteriores, trata-se de um ataque apenas de transmissão em que o invasor não vê a resposta.

Roubo de porta para interceptação de pacotes

O invasor se conecta à rede usando uma versão falsificada do endereço MAC da vítima e inunda a rede com respostas ARP dizendo: “este endereço MAC está na minha porta e SSID”.  O roteador da rede alvo atualiza suas tabelas MAC e começa a enviar o tráfego da vítima para essa nova porta. Com isso, o tráfego destinado à vítima acaba sendo recebido pelo invasor, mesmo que a vítima esteja conectada a outro SSID.

Se o invasor estiver em uma rede aberta e sem criptografia, isso significa que o tráfego destinado a um cliente em uma rede protegida por WPA2/WPA3 pode acabar sendo transmitido “em claro”, permitindo que qualquer pessoa próxima o capture.

Roubo de porta para envio de pacotes

Nessa versão, o invasor se conecta diretamente ao adaptador Wi-Fi da vítima e o bombardeia com solicitações ARP, falsificando o endereço MAC do ponto de acesso. Como resultado, o computador da vítima passa a enviar seu tráfego ao invasor em vez da rede. Ao combinar essas duas técnicas de roubo de porta, um invasor pode, em vários cenários, realizar um ataque completo de MitM.

Consequências práticas dos ataques AirSnitch

Ao combinar várias dessas técnicas, um hacker pode realizar algumas ações bastante graves:

  • Interceptação completa de tráfego bidirecional para um ataque MitM. Isso significa que o invasor pode capturar e modificar dados entre a vítima e o ponto de acesso sem que ela perceba.
  • Movimentação entre SSIDs. Um invasor em uma rede de visitantes pode alcançar hosts em uma rede corporativa restrita, desde que ambas usem o mesmo ponto de acesso físico.
  • Ataques ao RADIUS. Como muitas empresas usam a autenticação via RADIUS no Wi-Fi corporativo, um invasor pode falsificar o endereço MAC do ponto de acesso para interceptar os pacotes iniciais de autenticação RADIUS. A partir daí, ele pode tentar descobrir o segredo compartilhado por força bruta. Com isso em mãos, ele pode criar um servidor RADIUS e um ponto de acesso falsos para capturar dados de qualquer dispositivo que se conecte a eles.
  • Exposição de dados não criptografados em sub-redes “seguras”: o tráfego que deveria estar protegido por WPA2/WPA3 pode ser retransmitido a um cliente em uma rede de visitantes aberta, ficando exposto a qualquer pessoa próxima.

Para executar esses ataques com eficiência, um hacker precisa de um dispositivo capaz de transmitir e receber dados simultaneamente com o adaptador e o ponto de acesso da vítima. Em um cenário do mundo real, isso geralmente envolve um notebook com dois adaptadores Wi-Fi usando drivers Linux configurados especificamente para esse tipo de operação. Vale destacar que o ataque não é totalmente discreto: ele gera um grande volume de pacotes ARP, pode causar pequenas instabilidades no Wi-Fi quando é iniciado e reduzir a velocidade para cerca de 10 Mbps. Mesmo com esses sinais, ainda representa uma ameaça real em muitos ambientes.

Dispositivos vulneráveis

Como parte do estudo, vários pontos de acesso e roteadores corporativos e domésticos foram testados. A lista incluiu produtos da Cisco, Netgear, Ubiquiti, Tenda, D-Link, TP-Link, LANCOM e ASUS, além de roteadores com firmwares populares na comunidade, como DD-WRT e OpenWrt. Todos os dispositivos testados apresentaram vulnerabilidade a pelo menos algumas das técnicas descritas. Mais preocupante ainda: os modelos D-Link DIR-3040 e LANCOM LX-6500 foram vulneráveis a todas as variações do AirSnitch.

Curiosamente, alguns roteadores já contam com mecanismos de proteção que bloqueiam esses ataques, mesmo que as falhas de arquitetura de base continuem presentes. Por exemplo, o Tenda RX2 Pro desconecta automaticamente qualquer cliente cujo endereço MAC apareça simultaneamente em dois BSSIDs, o que na prática impede o roubo de porta.

Os pesquisadores destacam que qualquer administrador de rede ou equipe de segurança de TI que leve a proteção a sério deve testar suas próprias configurações. Essa é a única maneira de identificar exatamente quais ameaças se aplicam ao ambiente da organização.

Como proteger a rede corporativa contra o AirSnitch

O risco é maior para organizações que operam redes Wi-Fi de visitantes e corporativa no mesmo ponto de acesso, sem segmentação adicional por VLAN. Também há riscos significativos para empresas que utilizam RADIUS com configurações desatualizadas ou segredos compartilhados fracos para autenticação sem fio.

Em resumo, é preciso deixar de tratar o isolamento de clientes como uma medida real de segurança e passar a vê-lo apenas como um recurso de conveniência. A segurança real precisa ser tratada de outra forma:

  • Segmentar a rede com VLANs. Cada SSID deve ter sua própria VLAN, com marcação de pacotes 802.1Q aplicada de ponta a ponta: do ponto de acesso até o firewall ou roteador.
  • Implementar inspeção de pacotes mais rigorosa no nível de roteamento, dependendo dos recursos de hardware. Recursos como Inspeção dinâmica de ARP, DHCP snooping e limitação do número de endereços MAC por porta ajudam a proteger contra a falsificação de IP/MAC.
  • Ativar chaves GTK individuais por cliente, se o equipamento for compatível.
  • Usar configurações mais robustas de RADIUS e 802.1X, incluindo conjuntos de cifras modernos e segredos compartilhados robustos.
  • Registrar e analisar anomalias de autenticação EAP/RADIUS no SIEM. Isso ajuda a identificar diversas tentativas de ataque além do AirSnitch. Outros sinais de alerta a serem observados incluem um mesmo endereço MAC aparecendo em diferentes SSIDs, picos de solicitações ARP ou clientes alternando rapidamente entre BSSIDs ou VLANs.
  • Aplicar segurança em camadas superiores na topologia de rede. Muitos desses ataques perdem força se a organização tiver implementado TLS e HSTS de forma abrangente em todo o tráfego de aplicações corporativas, exigir o uso de VPN ativa em todas as conexões Wi-Fi ou tiver adotado plenamente uma arquitetura de confiança zero.

Ataque à cadeia de suprimentos por meio do DAEMON Tools | Blog oficial da Kaspersky

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ésticoscorporativos 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.

Seu sistema de segurança está realmente protegido? | Blog oficial da Kaspersky

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.

❌