Microsoft is taking a new approach to fighting cybercrime, targeting the cyberattack supply chain, not just individual services. In a case unsealed today, we are simultaneously targeting two widely used cybercrime tools, Amadey and StealC, after AI-assisted analysis revealed they rely on the same infrastructure.
This action goes after the cybercrime “assembly line,” where coordinated tools drive ransomware, financial fraud, and disruptions to public services. Amadey and StealC are often used alongside each other: Amadey helps attackers gain access to devices, while StealC steals passwords and sensitive information. Together, they form a critical link in the chain. In the first two weeks of May alone, Amadey and StealC were linked to more than 140,000 infected computers globally, highlighting how widely they are used.
Working with Europol and industry partners, we targeted both tools at once. The goal: break the chain. Since the start of the operation, Microsoft has identified more than 18,000 victim computers, severed criminal control of those devices, and is working with telecommunications providers to help protect affected customers globally.
When multiple parts of an operation are disrupted together, attacks are harder to launch, scale, and recover from. The result: fewer disrupted services, fewer opportunities for cybercriminals to profit, and more friction when they try to rebuild.
It’s no longer enough to go after threats one by one.We need to interrupt how the attacks are put together.
What’s new is how we’re combining AI analysis with an expanded use of that law.
Amadey and StealC were developed by separate cybercriminals, but they relied on the same infrastructure. To understand how they worked, investigators used AI, including Copilot, to quickly analyze the malware, asking questions in plain English instead of manually combing through complex code. That helped surface key details, uncover hidden data, and test findings in a fraction of the time, turning what would have taken hours or days into minutes and enabling the team to spot connections faster.
Those insights allowed the legal team to treat both malware families as part of a single conspiracy. Instead of going after each tool separately, as we have done in the past, we used RICO to charge multiple complicit enablers involved across the operation. In total, Microsoft’s Digital Crimes Unit disrupted over 200 command-and-control servers—the systems criminals use to control infected devices, steal data, and keep attacks running.
By targeting tools together, we can disrupt the cybercrime chain more efficiently and more effectively, in a way that better reflects how these networks actually operate today.
Cybercrime now runs like an assembly line
Cybercrime is no longer a series of isolated attacks—it’s a coordinated system.
Specialized tools handle each step: one gains access, another steals credentials, and others sell or exploit that access for fraud, ransomware, espionage, or other nefarious purposes. Different actors may be involved at each stage, but together they turn access into profit, quickly and at scale.
How cybercrime tools are built to be modular
That structure also creates a point of vulnerability. The people behind these cybercriminal tools may never interact directly, but their tools are designed to work together. If those connections can be identified, multiple stages of an attack can be disrupted at once.
How these attacks play out in the real world
Most people will never hear the names Amadey or StealC, but they feel the effects. A hospital locked out of critical systems. A city unable to deliver essential services. A small business losing access to accounts overnight. A retiree who lost their life savings.
These attacks don’t happen all at once. They unfold step by step: attackers get in, passwords are stolen, access is reused or sold, and sometimes repurposed for more targeted operations. For example, Microsoft has observed Russian-affiliated actor Secret Blizzard leveraging Amadey infections to deploy custom malware against targets in Ukraine.
By targeting multiple points in that chain at once, we reduce the chance that a single compromise turns into widespread harm. Put simply: fewer attacks succeed and fewer people feel the impact when they do.
No one organization can do this alone
Actions like this underscore a fundamental reality: we’re successful when we collaborate. No single organization, whether government or industry, has full visibility into how cyber threats operate across borders and sectors. What makes this effort effective is the combination of perspectives and data.
Bringing those efforts together expanded our collective datasets and made it possible to identify the connections between the two tools and act on them quickly. That shared understanding enabled a coordinated response that went further than any single organization could achieve alone.
This shows why partnerships matter. Industry shares technical insight, government brings visibility, and we need trusted ways to exchange that information. Only by working from the same picture can we stay ahead of attackers, disrupting not just individual tools but also the systems that make cybercrime possible.
Creating sustained pressure on cybercrime
This work doesn’t end with a single action. Cybercriminals adapt quickly, which is why we continue tracking how these operations evolve and working with partners to disrupt them.
Microsoft’s court-authorized disruption in this case is paired with ongoing efforts to track how cybercriminals rebuild, identify new infrastructure, and work with partners to disrupt the services they rely on to operate. It also includes incorporating the findings from this disruption into initiatives like Microsoft’s Statutory Automated Disruption program, which helps accelerate the removal of malicious domains and infrastructure.
The goal is not just to stop one operation but to slow the system itself—making attacks harder to launch, scale, and recover from. By combining AI-driven insight, legal action, and strong partnerships, we can continue to raise the cost of cybercrime and reduce its impact.
For more than a decade, Microsoft’s Digital Crimes Unit (DCU) has worked to disrupt cybercrime and nation-state threats, filing around 40 cases since 2008 and partnering with law enforcement to take down criminal networks. Learn more about the team’s efforts here.
As artificial intelligence (AI) adoption surges and organisations move from the ‘should we?’ phase to the ‘how do we?’ phase, it’s natural to evaluate the likelihood of positive returns on AI investments. That’s always been the case with the onset of each new technology paradigm: C-suite executives, guided by their boards and aided by technical and business teams, remain keenly focused on traditional metrics such as return on investment, shareholder equity, developing and extending competitive advantage, and ensuring superior customer relationships.
This time is different, however. I recently experienced that firsthand when I went to visit a major customer. My contact, a senior decision maker, gave me a pointed piece of advice about how to talk about AI with his boss, the CEO: “Please don’t say anything negative about AI.” The subtext was clear: The company was fully committed to AI and didn’t want any cognitive dissonance to dissuade them from their mission.
It's hard to imagine a CEO taking such an absolutist stance on previous technology waves, such as cloud, bring your own device, or the internet of things. CEOs, board members, and technical leaders would be pragmatic in evaluating the benefits of investments and put mileposts in place to gauge progress – and to determine if and how to proceed.
AI is certainly a different kind of paradigm, though. While no one is casting aside careful evaluation and monitoring of AI investments, the underlying assumption is that we’re stepping on the accelerator. We’re all enthused not only by its potential for transformation and innovation, but also by how this technology can be leveraged for remarkable societal good.
However, while the accelerating momentum toward AI and agentic systems is undeniable, it is vitally important to set aside the fervour around AI and take a sober look at how to deliver safe, secure, and tightly governed systems at enterprise scale.
Many organisations are underestimating the challenges of AI governance, in large part because they think they’ve been here before. They already have many experiences of ensuring robust cybersecurity and strict governance for new technologies, as they’ve done for remote systems, cloud computing, the internet of things, and more. They already have a corporate commitment to doing governance correctly and a sound governance model.
But this new era of AI and agentic systems is different. New challenges abound, and AI strategy, build-out, and governance must be in alignment from the start to ensure proper operational, ethical, and regulatory outcomes.
Our intention with this Peer Insights guide is to raise what we believe are existential issues around governance for this powerful, complex, and unprecedented technology wave. Few technologies have merited the often overused phrase ‘inflection point’ more than AI. The speed of AI adoption is nothing short of breathtaking; however, today’s runaway embrace of AI is far stronger than our current ability to govern it. That’s because AI represents a fundamental shift in how organisations do their business, interact with customers, make vital decisions, and execute their plans. This isn’t just a technology play: It’s a strategy for success and survival for entire industries and our global economy. The stakes have never been higher.
CEOs care so passionately about AI because they see it changing nearly everything we’ve learned and believed to be true about organisational success and failure. CEOs are in their positions for one purpose: to grow the business. AI can do that by transforming their processes and sparking new ideas. When that customer representative forewarned me, I really wasn’t surprised to hear his CEO felt so strongly about AI: Research from BCG indicates that more than 94% of CEOs say they still plan to deploy AI irrespective of demonstrated business value, even if there is a lack of tangible ROI or financial benefits from the start.
Which brings us to the central role of AI governance. As we all know, there are many fundamental elements to any governance strategy, starting with robust, scalable, and intelligent cybersecurity. Cybersecurity - the foundation of governance - also includes the twin imperatives of accountability (‘rogue AI’ being a real thing, after all) and regulatory compliance.
But good AI governance has to go even further. Operational integrity is key to good governance because so much sensitive and even proprietary data is poured into AI models and accessed through powerful agentic AI systems. Now more than ever, organisations have to be transparent with customers and trading partners about how their AI systems operate, what kind of data is accessed, and how it is protected. And that doesn’t just mean being upfront with customers by telling them when they are interacting with an AI agent. Let’s take a typical retail use case: Imagine you’re on a website looking at clothing, and the agent recommends specific styles of clothing in specific colours. True operational integrity would allow you to discover why and when the agent made those recommendations. Was it based on your prior purchasing history, or on your browsing patterns on a recent web session? AI and agentic governance take the guesswork out of the equation for those interacting with the system and help breed greater confidence and trust.
It's critically important for decision makers to view AI governance holistically, rather than through a series of narrow lenses. For instance, even though cybersecurity is the foundation of good AI governance, it’s a mistake to treat AI governance primarily as a cybersecurity problem. If asked about ownership of AI governance, CEOs cannot and should not reply, “Oh yeah, the CISO has that covered.”
AI governance is fundamentally an enterprise risk problem, which means everyone must be involved in creating, deploying, managing, evaluating, and adjusting AI governance guardrails on a real-time basis. Again, AI is a different kind of risk environment than any we’ve previously encountered. For the most part, organisations are simply not adequately prepared to apply the right level and right type of governance to AI and agentic systems. I’ve spent much of the past 15 years of my career building governance frameworks, and while it has never been easy, we have had the advantage of being able to control many of the variables – such as infrastructure and network access – impacting governance decisions. With AI and agentic, we no longer have that advantage.
To explore the critical and complex issues of AI governance, we’ve enlisted five leading voices to bring their real-world experience to the discussion. Together, our five authors help lay out the new rules of the road for governing AI and agentic systems at scale.
Just as my customer gave me a heads up about the realities of speaking with his boss about AI, I’d like to offer you a heads up about the realities of AI governance challenges before you read this Peer Insights guide.
Visibility is paramount for successful AI governance. As we learned during the growth of trends such as cloud, bring your own device, and remote work, our employees will push the envelope with a do-it-yourself mindset. These tech-savvy and resourceful users are already making rogue AI a reality, so organisations need more visibility than ever into where AI ‘science projects’ and sandboxes are operating without anyone’s knowledge.
AI governance must reflect the stunning velocity of change in AI development and deployment. Not only does AI have its own never-imagined rate of change, but the technology is changing everything else faster – product development, supply chains, marketing programmes, and more. AI governance has to evolve just as rapidly. Governance in the AI world must be a living system, constantly evolving with new technology use cases.
Trust boundaries are incredibly different and difficult to manage in AI governance. AI represents a new class of identity that simply didn’t exist before. That means AI doesn’t fit neatly into your existing identity management framework, making things like application whitelists and zero trust network access less effective.
Unfortunately, many CEOs, board members, and business executives simply don’t understand the profound importance and complexity of these issues. They may have been heartened by how they integrated generative AI into their technology frameworks and their business processes, but GenAI was pretty familiar territory for CIOs, CTOs, and CISOs. Agentic AI is different for several reasons, including its automation and self-learning capabilities. Don’t be lulled into a false sense of security: Agentic AI is not simply a refresh of GenAI.
As you get ready to dive into the following chapters, rethink how you define governance when applying it to AI systems and agentic AI. Most traditional governance models are imagined, constructed, and deployed as gates, preventing people from doing things or going places they shouldn’t. Instead, think of AI governance as a guardrail to guide and direct people to get the most out of AI without creating problems. With so much excitement and investment around AI, organisations – and their employees – want to get the most out of their AI and agentic systems. We all know people don’t want to hear “no, you can’t do that”, so an effective governance system should use guardrails to drive proper, responsible, and safe usage of the technology.
Finally, as complex as AI and agentic governance are and will continue to be, don’t overthink things in hopes of creating the perfect model – it doesn’t exist. My advice is to start now, even if the model and framework are imperfect, and then bring the business along with you.
We at Palo Alto Networks are excited to give you insights, ideas, and actions you can take away from the chapters of this guide. We encourage you to share what you learn with your colleagues, peers, and team members – and to take prudent steps to build an AI governance model that rewards innovation without allowing your organisation to drift into dangerous waters.
The White House Executive Order on securing the nation against advanced cryptographic attacks accelerates the mandatory timeline for post-quantum readiness.
For years, post-quantum cryptography has been discussed as an important, yet abstract future technical migration. Because of the uncertain timeline for quantum computing, it has been difficult for most organizations to prioritize quantum readiness against more immediate security demands.
That is changing.
Signed on June 22, 2026, the Executive Order mandates the transition of federal information systems to post-quantum cryptography and establishes a national policy to migrate them to NIST-approved standards. It also extends the urgency beyond government by directing support for critical infrastructure owners and operators, advancing requirements for federal contractors, and calling for cryptographic bill of materials guidance.
The order directly addresses harvest now, decrypt later risk and sets transition milestones for federal high-value assets and high-impact systems: 2030 for key establishment and 2031 for digital signatures.
While the order directly applies to U.S. Federal civilian agencies, it should be seen as a signal of broader policy and procurement momentum. Organizations that do business with the government, support critical infrastructure, or operate in regulated industries such as energy, financial services, and healthcare should expect post-quantum readiness expectations to accelerate.
Quantum risk has shifted from a long-term research concern to a national cybersecurity priority tied to sensitive data, critical infrastructure, federal systems, procurement, and the broader digital economy. For security teams, the challenge now is turning that urgency into an operational plan.
Operationalizing the quantum mandate
As quantum computing advances, widely used public-key cryptography will become vulnerable to future attacks. Even before a cryptographically relevant quantum computer exists, adversaries can capture encrypted data now with the goal of decrypting it later.
This “harvest now, decrypt later” risk is especially concerning for organizations that protect sensitive information with a long shelf life. The response cannot wait until the threat fully materializes.
The broader ripple effect matters because compliance alone will not equal readiness. As requirements flow into federal acquisition rules and contractor obligations, the vendor ecosystem will be pushed to support quantum-safe capabilities in the products and services that enterprises, critical infrastructure organizations, and regulated industries rely on.
Adding support for post-quantum algorithms is not the same as safely migrating to them. Support means a system can use new algorithms. Readiness means the organization knows where cryptography exists, which systems are exposed, which dependencies matter most, and how to execute changes without creating disruption or new risk.
That matters because post-quantum migration can affect more than cryptographic libraries. Larger cryptographic objects, new protocol behaviors, hybrid modes, hardware acceleration requirements, interoperability constraints, and legacy system limitations can create real performance, availability, and compatibility challenges if changes are made blindly.
This is why cryptographic visibility must lead to actionable migration planning.
Security teams cannot migrate what they cannot see. But visibility by itself is not enough. They also need to classify exposure, prioritize high-value systems and long-lived data, understand operational dependencies, and plan changes in a way that avoids disruption, downgrade risk, or incomplete migration.
Cryptographic bill of materials guidance will be an important step toward mapping cryptographic assets. But a CBOM should be the starting point, not the finish line. An inventory can show where cryptography exists, but readiness requires understanding business impact, migration complexity, interoperability risk, ownership, and the order in which changes should happen.
Post-quantum readiness is not just an algorithm swap. It is an operating model for managing cryptographic change at scale.
Five actions for post-quantum readiness
The path forward starts with five practical actions.
First, see cryptographic exposure. Organizations must gain visibility into cryptographic usage across all environments to mitigate the risks associated with undocumented encryption.
Second, prioritize what matters most. Cryptographic exposure varies in urgency. Organizations should prioritize protecting authentication, high-value assets, and long-lived sensitive data based on risk and business impact.
Third, modernize trust infrastructure. Existing systems rely on fixed cryptographic assumptions. Post-quantum readiness demands flexible infrastructure and trust services that support evolving standards.
Fourth, automate cryptographic change. Manual tracking with spreadsheets provides an incomplete, point-in-time snapshot that quickly becomes outdated and is insufficient for the coming changes. Automation allows organizations to manage cryptographic updates and trust operations in a consistent, controlled manner.
Fifth, govern readiness over time. Post-quantum migration requires continuous governance to track progress, align ownership, and adapt to evolving threats and standards.
These actions help security leaders move from awareness to readiness.
What this means for cybersecurity now
The Cryptographic Reset is already underway, driven by post-quantum risk, shorter certificate lifecycles, machine identity growth, fragmented cryptographic ownership, CA distrust events, and expanding digital infrastructure.
The organizations that move first will not simply be the ones that adopt new algorithms the fastest. They will be the ones that build the visibility, operating model, and governance needed to manage cryptographic change continuously.
Take the next step
Read the guide: The Post-Quantum Readiness Race Is On: Five Actions Security Leaders Can Take to Accelerate Crypto Agility.
Anyone who has seen the impressive frame of Stonehenge against the morning’s sunrise cannot help but be struck by its resilience, how it has withstood time and the unpredictable impact of nature and humans. And partly because of this, a recent conversation I had with the CIO of a large healthcare technology company made me realize that it was a fitting metaphor for cybersecurity.
As our conversation wove through familiar topics — the challenges and breakthroughs in enterprise IT architecture — we recognised and discussed a recurring pattern throughout most EMEA and multinational enterprises. Those organisations have gradually but surely evolved into a mosaic of vendor fragmentation, ‘micro-platforms’ across vendor-specific technologies, and rapidly developing data silos that no single IT architecture can solve on its own.
The increased heterogeneity of hardware, operating systems, and cloud architectures now comes with a dizzying mix of cybersecurity tools and services, often optimised for Vendor X’s platform. This has led to the situation that a large organisation typically has more than 30 cybersecurity point solutions in place to protect their digital assets. And now that we have thrown AI into that mix, designing the right cybersecurity solution is as confusing as it is imperative.
That’s when I was reminded of Stonehenge. Its lintel-and-joinery design is strikingly simple and elegant, and it stands as a brilliant monument to long-term resilience. Just as Stonehenge has endured against natural and human threats, so organisations must build a cybersecurity architecture that endures a revolutionary rate of change and threat diversity, including geopolitical turbulence and AI entering the value chain.
For CISOs, CIOs, board members, C-suite executives and line-of-business leaders concerned with operational resilience, cybersecurity architecture matters—deeply.
And we should not forget that cybersecurity is a data problem. The more telemetry data you have, the more effectively you can execute security algorithms and protect your digital essentials across all your enterprise IT pillars, i.e., IT, OT, Clouds, Networks, Workplace, Endpoints, etc. We at Palo Alto Networks are able to combine relevant telemetry data from networks, firewalls, clouds, browsers, endpoints and the internet.
Stonehenge was built from massive, self-reinforcing pillars and platforms of stone. The lintels and joinery help hold together the overall structure as a cohesive unit, and they have striking similarities to how IT architects are now thinking about cybersecurity. In today’s technology architecture, Stonehenge’s vertical pillars are an IT organisation’s specialised, vendor-specific IT domains—sometimes with its own security tools and capabilities rather than as a strategically integrated zero-trust cybersecurity framework across your enterprise IT pillars.
Now, Stonehenge’s with its unique resilience, can also serve in its own construction as a model for modern cybersecurity architecture. Like our evolution towards modular platformisation evolved deliberately and assuredly over time and it spans all key domains of cybersecurity, ie network, cloud, AI, identity security and all key building blocks for an AI-driven SOC, the last line of defense that has to be real-time. In other words, it is the linchpin of our strategy for enterprise security built upon such key areas as Identity, the Autonomous SOC, and Network Security.
Stonehenge’s lintel is analogous to cybersecurity platformization, a growing trend rapidly replacing the now-outdated best-of-breed point solution mindset. This employs a modular approach that gives flexibility and control to the security architect looking to add security domain capabilities as needs evolve. The mortise-and-tenon joinery of Stonehenge works because the parts fit together rather than being stacked as an afterthought, in much the same way modern cybersecurity frameworks are built upon the concept of embedded functionality rather than being bolted on.
An important example here is Palo Alto Networks’ decision to power the cybersecurity platform core with Precision AI, rather than its technology being added as a separate tool. This approach enables Precision AI to power data, analytics, and workflows, making it an omnipresent resource for smarter and faster prevention, detection and response.
Another important element of any enduring architecture is its ability to provide stability to the overall framework. In cybersecurity architecture, this is the all-important cyber data layer across an integrated zero trust framework. As organisations continue to struggle with data silos across networks, cloud environments, security operations centres, and edge systems, the cybersecurity data lake takes on a heightened role of importance for the resilience of the entire cyber framework. Again, let’s not forget, cybersecurity is a data problem, a domain in its own right across all vertical IT pillars.
Now, Stonehenge with its unique resilience, can also serve in its own construction as a model for modern cybersecurity architecture. Like our evolution towards modular platformization evolved deliberately and assuredly over time and it spans all key domains of cybersecurity, i.e. network, cloud, AI, endpoints, identity security and all key building blocks for an AI-driven SOC, the last line of defense that has to be real-time. In other words, it is the linchpin of our strategy for enterprise security built upon such key areas as Identity, the Autonomous SOC, and Network Security/SASE.
Another critical element of the cyber platform is something even Stonehenge hasn't had to face: securing AI itself, especially the opportunity and threat represented by agentic AI. AI security must become part of the platform design and implementation, as we have done with our Prisma AIRS (AI Runtime Security) platform for enabling an organisation's growing AI portfolio to remain a vital asset and not an inviting attack vector. Agents now are not just another non-human identity; they are an entirely new class of identity, with a striking mismatch in speed between agent decision-making and human governance. The inside-out attack paths taken by hackers' ill-intentioned agents represent a major threat to under-protected AI supply chains. The same pressure now also comes from geopolitics and from AI moving into the value chain itself, such as in the case of the Factory of the Future.
Similarly, our recent acquisition of CyberArk gives us what we believe is the industry’s strongest identity security platform, Idira, positioning it as yet another vertical pillar connected to the overall cybersecurity platform lintel. Cortex XSIAM and its security data lake are deliberately open — ingesting and correlating third-party telemetry alongside our own, over 17 petabytes of telemetry data each day — to form a secure data layer that is accessible to users based on policy management and credentials validation. Palo Alto Networks leverages this mountain of data, along with around-the-clock scanning of more than 5 billion daily security events, to feed Precision AI in order to detect and block potentially devastating attacks. Currently, we detect about 9,6m new attacks per day that have not been there the day before. The use of automated AI in attack vectors has been accelerating the time of exfiltration of data from the compromise of an organization. This delay was 9 days about 3 years ago, now data is exfiltrated in most cases in less than a day, sometimes already within less than one hour!
In this context, it's also important to highlight the importance of an Autonomous SOC pillar, particularly since compliance reporting windows are continuously contracting from days to mere hours calling for real-time, highly automated defence. Today, mean-time-to-detect and mean-time-to-respond are board-level imperatives commanding more conversation and attention at an organisation’s highest levels. The Autonomous SOC pillar is a vital element in helping enterprises achieve even faster detection and remediation, ideally down into single minutes. If it also integrates the historic enterprise SIEM you can further simplify your SOC operations and gain solid financial benefits by platformization of your security relevant data.
Finally, keep in mind the use of supply chains to build the actual platform. For Stonehenge, that was an impressive physical supply chain: The bluestones used in the structure were hauled about 250 kilometers from Wales without the benefit of air, rail, or truck transport. For Palo Alto Networks’ cybersecurity platform, the supply chain was no less impressive, but more virtual than physical, often faced with attacks on third-party interdependencies such as SaaS applications, APIs and in times of Frontier AI models, the Open Source components.
Like the pyramids, the Great Wall of China, and the Roman road system, the most remarkable aspect to Stonehenge isn’t just its engineering elegance, but its ability to withstand changing conditions and threats over time. Whether you’re a CEO, board member, CIO, CISO or security engineer, the decisions you make about cybersecurity carry significant impact and implications. In order to achieve Stonehenge-like resiliency, technical and business leaders should commit to an architectural model designed not only for today’s needs, but for what those needs are likely to be over the long term.
Therefore, cybersecurity should be architected as a horizontal, dedicated platform across all your IT domains and businesses. With this you are able to provide real-time and platformized cybersecurity for tomorrow. And tomorrow is going to be a more and more AI-driven business world.
Helmut Reisinger is CEO for Europe, Middle East, and Africa at Palo Alto Networks.
When a major cyber incident hits, all eyes are on the CISO.
They become the invisible CEO of crisis, steering the entire enterprise through the storm, managing stakeholders and making major decisions under immense pressure. The clock is ticking. Every minute can mean more systems affected, more data exposed, greater operational disruption and a growing risk to customer trust and corporate reputation.
And this on top of an already expanded day-to-day role, where they are expected to make decisions with incomplete information, brief the board, support legal and communications teams, manage technical response and reassure the business, all while knowing that any delay could increase the damage.
But a troubling pattern often emerges once the smoke clears. The CISO may find themselves held responsible for the incident that just happened, and in some cases personally liable, while still being expected to prevent the next one. Yet, at the same time, their influence over the strategic decisions that shape cyber risk can quickly diminish.
This cycle takes a toll. Across EMEA, we are seeing the personal and organisational impact of that pressure, from burnout and leadership turnover to growing concerns about long-term resilience.
That pressure often comes at a demanding stage of life too. Many security leaders reach the CISO role when career responsibility is peaking at the same time as responsibilities outside work, from ageing parents and family commitments to their own health.
Cybersecurity is far more complex than it was a decade ago. AI-powered attacks and autonomous agents are increasing the speed and scale of threats. At the same time, the CISO has never had more potential influence over business strategy. The challenge is ensuring the support around the role evolves as quickly as the threat landscape.
That is why it’s time to stop treating cybersecurity as a technical function alone and recognise the CISO as a strategic business leader.
Structural equity - breaking the cycle of isolation
The burden of cyber resilience should not rest on one individual. Yet too often, organisations place responsibility on the CISO without providing the support, influence or measures of success needed to help them thrive.
Part of the problem is how the role is measured. CISOs are judged by whether incidents happen, rather than by the quality of preparation, resilience planning, risk reduction and secure business enablement.
And preparation can really help reduce the pressure. Regular red teaming, tabletop exercises and incident simulations mean the CISO is not carrying the crisis alone when a breach happens. The organisation has rehearsed its roles, decision points and escalation paths before the stakes are at their highest.
But after a crisis, organisations also often fall back into day-to-day survival mode, undoing the progress made when security was treated as a critical part of business planning rather than a technical function. Strong resilience requires the CISO to have a permanent seat at the table for all strategic decisions, from M&A to digital transformation.
That influence only comes with strong foundations. This includes visibility of critical assets and risks, security controls that are fit for purpose and the operational discipline to maintain them over time.
Invest in leadership as much as certifications: The modern CISO needs diplomacy, judgement and the ability to translate risk into business terms. Different backgrounds can strengthen that role, bringing fresh perspective when solving problems that are no longer purely technical
The ‘Shared CISO’ model: Cyber resilience should not rest on one pair of shoulders. The most resilient organisations embed responsibility for cybersecurity across the business, while creating stronger support structures around the CISO through deputies, shared ownership of cyber risk and clear succession planning. This reduces pressure on individual leaders and helps ensure resilience is built into the organisation itself
Strategic diplomacy - aligning people and purpose
Cyber resilience depends on people as much as technology,and a CISO’s success depends on building alliances across the business. The strategic diplomat CISO focuses on moving the conversation from ‘no’ to ‘how?’ by building deep relationships with other leaders, every team and every department across the organisation.
By understanding the business’ growth drivers, the CISO can align security goals with the board’s priorities. That means agreeing meaningful measures of risk and readiness, preparing for difficult questions and giving the business a clear view of where it is exposed.
Security and growth must be seen as a single strategic fabric. Integrating security into the development of internal AI tools and customer-facing products helps ensure innovation is secure by design, rather than being a hurdle to overcome later.
Palo Alto Networks is pleased to announce the successful completion of a new Cloud Medium security assessment conducted by the Canadian Centre for Cyber Security (Cyber Centre), significantly expanding the number of Palo Alto Networks cloud services assessed for Protected B / Medium Integrity / Medium Availability (PBMM) environments. This assessment includes a broad range of capabilities across our Cortex®, Cortex Cloud and Strata™ platforms. By achieving this milestone, Palo Alto Networks enables organizations handling Canada’s most sensitive data to leverage a unified, AI-driven security architecture without compromising on compliance or operational resilience.
For years, many organizations viewed PBMM as something that only mattered to the Canadian federal government. It was often seen as a procurement requirement—a framework tied to public sector cloud adoption, relevant for departments handling Protected B information, but not necessarily for the private sector.
That assumption is changing.
The reality is that the challenges driving PBMM are no longer unique to government environments. Banks, energy providers, transportation networks, healthcare organizations, crown corporations, and other critical infrastructure operators are now facing many of the same pressures:
Expanding attack surfaces across hybrid and multi-cloud environments.
Increased regulatory scrutiny and privacy obligations.
Greater operational dependence on cloud and AI technologies.
Increased reliance on third-party providers and software supply chains.
The need to maintain operational resilience during cyber incidents and disruptions.
A growing expectation that organizations can demonstrate—not just claim—security maturity.
That is why PBMM matters far beyond Ottawa. At its core, PBMM represents a rigorous approach to validating whether enterprise-grade security platforms can operate securely in environments where trust, resilience, and operational continuity are critical.
Increasingly, that level of assurance matters to everyone.
What PBMM Really Represents
PBMM, a rigorous cybersecurity and data classification standard used by the Canadian Centre for Cyber Security, stands for Protected B / Medium Integrity / Medium Availability. While often associated with federal cloud security requirements, PBMM is not simply a checkbox exercise. It is a comprehensive assessment framework aligned to Canadian cybersecurity guidance and operational security expectations.
What makes PBMM important is that it evaluates whether platforms and services can securely support sensitive and mission-critical workloads in real-world environments.
Palo Alto Networks meeting these rigorous PBMM requirements through three core pillars:
Strata (Network Security): Secures data resiliency and zero trust connectivity, driving robust perimeter and cloud edge protection.
Cortex Cloud (Cloud Security): Provides complete visibility, security governance, and data protection across complex cloud-native architectures.
Cortex (Security Operations): Powers the agentic SOC, combining unified data, AI, and automation to detect and respond to threats in real time.
These are not theoretical requirements. They are practical operational expectations designed for environments where downtime, visibility gaps, or security failures can have significant consequences.
Organizations today are no longer evaluating cybersecurity solely based on features. They are evaluating whether platforms can be trusted to support critical operations at scale.
Why Security Expectations Are Changing
The cybersecurity landscape has evolved dramatically. Infrastructure is distributed across cloud providers, SaaS applications, remote users, third-party integrations, operational technology (OT), AI platforms, and interconnected supply chains. At the same time, attacks have become faster, more automated, and more disruptive.
In this environment, security can no longer be treated as a compliance exercise. Organizations need confidence that their platforms, operational processes, and security controls can function effectively under pressure.
This is why Palo Alto Networks has undertaken independent PBMM assessments across its portfolio, providing customers with greater assurance and trust. By meeting these rigorous standards into Strata and Cortex, we enable non-government entities—like financial institutions and utility providers—to deploy the same defensive rigor used to protect national security systems.
Transforming Critical Infrastructure with a Unified Platform
To effectively manage risk, critical infrastructure operators require a platform approach that helps eliminate security silos, reduce manual intervention, and accelerate threat mitigation.
Key Portfolio Advantages for Critical Infrastructure & Enterprise:
AI-Driven Threat Detection & Response:Cortex XSIAM® and Cortex XDR® unify telemetry across endpoints, network, and cloud to deliver unparalleled visibility and automated threat stitching, neutralizing advanced cyberthreats before they disrupt operations.
Comprehensive Cloud Native Protection:Cortex Cloud secures applications from code to cloud to SOC, offering posture security, data protection, and continuous compliance monitoring tailored to stringent Canadian data standards.
Zero Trust Network Security:Strata enables secure access and consistent policy enforcement across campus, branch, and data center environments, protecting critical OT and IT systems from lateral threat movement.
Elite Incident Response: Backed by Unit 42®, organizations gain access to threat intelligence and rapid incident response services to augment their teams and build long-term cyber resilience.
Operational Resilience Is Becoming a Strategic Requirement
One of the most significant shifts occurring across industries today is the growing focus on operational resilience. Organizations are increasingly asking questions that extend beyond traditional cybersecurity controls:
Can we maintain critical services during a cyber attack?
Do we have visibility across our cloud environments and supply chain dependencies?
Can we rapidly detect, respond to, and recover from disruptions?
Are our governance processes keeping pace with cloud adoption and AI innovation?
As organizations adopt cloud-native architectures, AI-driven technologies, and interconnected digital ecosystems, resilience has become a board-level concern. The ability to prevent incidents remains important, but organizations are equally focused on their ability to withstand, respond to, and recover from them.
This is where frameworks like PBMM provide value. Beyond evaluating security controls, PBMM assesses the governance, operational processes, monitoring capabilities, and risk management practices that help organizations operate securely.
For critical infrastructure operators, resilience is no longer simply an IT objective—it is a business imperative. Increasingly, the organizations that earn trust are those that can demonstrate they are prepared to operate effectively when disruption occurs.
Final Thoughts: PBMM Reflects the Future of Trust
PBMM may have started solely as a government assessment framework, but its relevance now extends far beyond federal environments. It represents something universal: the ability to operate securely, reliably, and transparently in environments where trust matters most.
By expanding our PBMM-assessed offerings across Cortex and Strata, Palo Alto Networks underscores its commitment to securing Canada's digital future. We provide the validated foundation organizations need to innovate with confidence, protect sensitive data, and maintain operational continuity under any circumstance.
Ready to modernize your defenses with PBMM-assessed solutions? Schedule a demo with our team or contact Unit 42 to learn how we can help elevate your organization's resilience against emerging cyber threats.
Frontier AI is moving faster than most governance and response systems were designed to handle.
The corporate landscape across the Japan and Asia-Pacific (JAPAC) region is facing an unprecedented regulatory and operational reckoning. The rise of hyper-autonomous ‘frontier’ AI models is pushing cyber security out of human hands and into a real-time war of machine against machine. This shift has triggered a highly coordinated enforcement wave cascading through JAPAC’s premier digital hubs, where regulators and enterprises are moving in lockstep to address machine-speed threats.
With corporate watchdogs Australian Prudential Regulation Authority (APRA) and Australian Securities and Investments Commission (ASIC) firing warning shots via urgent market letters, and neighbouring authorities like the Monetary Authority of Singapore and South Korea’s central government enacting strict new AI safety rules, organisations are being forced to completely overhaul their defensive architecture. Decades of relying on slower, committee-based governance are being shattered by new threat intelligence showing that autonomous AI agents can now exploit vulnerabilities and exfiltrate critical data within minutes—turning traditional 72-hour regulatory reporting windows into mere post-mortems.
The warning comes as the gap between corporate readiness and technological reality widens right across the JAPAC corridor. Much of the region’s current governance and cyber risk architecture still reflects a legacy system engineered for predictable, slower-paced environments. We have spent years building risk models where vulnerability discovery, incident escalation, and defensive response unfold gradually enough for traditional executive oversight and committee structures to remain effective. But that comfortable pace has officially vanished.
The Machine-Speed Reality
The sheer velocity of this shift was highlighted during restricted testing of Anthropic’s advanced frontier model, Claude Mythos, under an initiative known as Project Glasswing. Palo Alto Networks was among a select group of technology and cyber security organisations chosen to evaluate the implications of the model before its broader release. Mythos demonstrated an unprecedented capability to identify and exploit vulnerabilities across major operating systems at a level matching or exceeding advanced human experts.
During combined testing involving Mythos, Claude Opus 4.7, and OpenAI’s GPT-5.5-Cyber, the real-world impact of machine speed became starkly visible. In a single month, Palo Alto Networks disclosed 26 Common Vulnerabilities and Exposures (CVEs) representing 75 distinct issues, a massive surge compared to a typical monthly volume of fewer than five CVEs.
While discovering flaws at that scale would historically have raised uncomfortable questions around software quality, the landscape has fundamentally shifted. In this new era, radical transparency, paired with the ability to reflect and act instantly, has emerged as a critical corporate superpower. Frontier AI is accelerating both sides of the digital chessboard simultaneously: while attackers are gaining unprecedented speed, defenders are gaining a level of visibility that simply did not exist a few years ago. Real-time warfare between AI defenders and AI attackers is rapidly becoming the standard operating model.
AI Agents: The New Corporate ‘Insiders’
This shift introduces a profound dilemma for corporate leadership. Recent regulatory guidance repeatedly emphasises the necessity of human supervision, and for good reason—ultimate accountability must always remain with people. Boards must still set risk appetite, Chief Information Security Officers (CISOs) must determine operational thresholds, and security teams must decide how much authority autonomous systems should hold inside critical environments.
However, organisations must now look a step further. Autonomous AI agents—operating on behalf of employees, suppliers, or automated workflows—are quickly becoming the new corporate ‘insiders’. If not managed with extreme care, they represent massive, systemic blind spots.
Current identity and access frameworks are starting to buckle under the strain because they were never built to distinguish between human users and autonomous agents acting on their behalf. Traditional identity systems assume a predictable human pattern: a user authenticates, requests access, and operates within set boundaries. Autonomous agents, by contrast, interact continuously with APIs, generate code on the fly, move fluidly across workflows, and operate with delegated authority from trusted users.
When these agents begin operating deep inside critical infrastructure, financial services, or government workflows, the risk profile changes entirely. Security teams are no longer just dealing with stolen passwords or human misuse; they are managing autonomous systems capable of acting at machine speed across highly interconnected environments, with potentially devastating consequences if control is lost.
The Failure of the 72-Hour Window
This acceleration has effectively broken traditional regulatory reporting timelines. Recent threat observations from Unit 42 reveal that in approximately 20 percent of modern breaches, attackers successfully exfiltrate data within the very first hour of a compromise.
When data theft occurs inside 60 minutes, a 72-hour reporting window ceases to function as an effective defense mechanism. Instead, it becomes a post-mortem.
For example Australia’s current reporting obligations—including those under the SOCI Act, CPS 234, and the Privacy Act—were largely designed for static environments where defenders had sufficient time to investigate, escalate internally, and coordinate remediation before damage spread. Today, many CISOs quietly acknowledge the immense operational strain created by overlapping reporting frameworks during a live crisis. In the chaotic early stages of a compromise, security teams frequently find themselves managing compulsory reporting requirements from different regulators while their engineering teams are still actively trying to contain a fast-moving incident.
A Region-Wide Regulatory Reckoning
Australia is far from alone in this challenge. The regulatory anxiety echoing through the halls of APRA and ASIC is part of a highly coordinated, region-wide crackdown across the Japan and Asia-Pacific (JAPAC) tech corridor. As frontier models shrink the ‘time-to-exploit’ to near zero, neighbouring digital economies are rapidly realising that their legacy frameworks are equally vulnerable.
In Singapore, the regulatory response has been immediate. The Cyber Security Agency (CSA) recently issued a stark advisory warning that advanced frontier models can examine complex codebases and automate attacks faster than human developers can write patches. In lockstep, MAS finalised its Guidelines on AI Risk Management. Under these new rules, financial institutions are now mandated to perform continuous ‘AI Cyber Stress Testing’— requiring boards to prove that complex, autonomous AI-to-AI interactions within their systems won't trigger an unmanageable domino effect.
Meanwhile, South Korea has shifted from guidelines to hard law. The nation's landmark AI Basic Act (Framework Act on Artificial Intelligence) has officially entered into force, creating strict compliance mandates, mandatory data audits, and extraterritorial penalties for any enterprise deploying high-impact AI systems without ironclad human guardrails.
Across JAPAC, a uniform regulatory shift is underway: voluntary AI ethics frameworks are being replaced by proactive, real-time enforcement measures.
Moving with Discipline
Organisations broadly acknowledge that AI demands a distinct approach, yet implementation gaps remain. Businesses must move away from managing AI like standard software and instead commit the significant defensive resources needed to protect complex AI supply chains.
The language coming from regulators reflects these exact challenges. ASIC Commissioner Simone Constant warned that frontier AI capability could expose vulnerabilities at unprecedented speed and scale, creating systemic consequences across entire sectors. Her message to corporate Australia was direct: do not wait for perfect clarity to address the threat posed by new AI models. Instead, organisations must act now, and act with discipline, to strengthen the cyber resilience fundamentals that underpin their businesses.
The testing conducted within Project Glasswing ultimately proved that while frontier models can expose weaknesses at terrifying speed, that exact same capability can be weaponised defensively. By deploying AI to reduce exposure and identify vulnerabilities before adversaries can operationalise them, organisations can effectively level the playing field.
The most resilient organisations over the next few years will be those that combine real-time frontier AI defensive capabilities with disciplined human supervision, rather than treating the two as separate priorities. In the era of machine-speed warfare, you cannot successfully have one without the other.
To learn more about how we are securing the frontier of technology, visit the Palo Alto Networks Trust Center and explore the latest threat insights from Unit 42.
Public attitudes toward Artificial Intelligence (AI) are changing, and we wanted to understand why.
A recent Pew Research survey found that about half of adults say the increased use of AI in daily life makes them more concerned than excited, and that concern has grown over the last few years. People tend to worry most about long‑term social effects (jobs, creativity, relationships, misinformation), even while many do use AI tools and see some practical benefits, particularly for data analysis and routine tasks.
Data from an older UK survey already showed something similar. Awareness of highly visible AI technologies, such as driverless cars and facial recognition is high, but awareness of AI in welfare assessments, loan decisions, or care services is much lower. Concern about many of these use cases has risen since 2022. In other words, people feel AI is everywhere, but don’t always understand where or how it’s being used, and that makes people cautious.
The concern is usually less about science‑fiction extinction scenarios and more about social and economic harm. People worry about their jobs disappearing, a loss of creativity, the spread of disinformation, and increased surveillance, more than about killer robot scenarios.
Research into public attitudes towards AI repeatedly finds that people hold conflicting views, shaped by narratives of admiration and hype on one side and threat and dystopia on the other.
They see genuine benefits in the technology, but are increasingly wary of how companies, governments, and criminals might use it. Basically, people aren’t scared of AI itself, but about who’s using it and for what purpose.
Cybersecurity
AI in cybersecurity is a special case. When asked in which field of AI research they would invest an unlimited amount of money, people chose the fields of medicine and cybersecurity.
People increasingly recognize that AI is now a tool used by both defenders and cybercriminals. Few would feel comfortable with defenders refusing to use AI while attackers continue to adopt it.
Security products use machine learning to process huge volumes of data, detect unusual behavior, prioritize alerts, and identify threats faster than human analysts could alone.
At the same time, cybercriminals are using AI to create more convincing phishing emails, clone voices, generate fake images and videos, automate research on victims, and develop malware that can evade traditional detection techniques.
While studies consistently show that cybersecurity is one of the AI applications people worry about most, they also see that AI is increasingly necessary to keep pace with modern threats. A 2025 study focusing on AI in cybersecurity found that the public widely recognizes the technical benefits of AI‑driven defenses (speed, scale, accuracy), while remaining concerned about privacy, bias, and job displacement in security operations.
That is why the AI debate in cybersecurity feels different from the debate in many other fields. People may be uneasy about AI, but they also understand that the threat landscape no longer moves at human speed. Attackers already use automation, scale, and increasingly AI‑assisted workflows, so defensive teams that refuse to adapt would simply be slower and less effective.
Our mission at Malwarebytes is twofold: reduce the risks created by AI, and use AI to prevent, detect, and respond to threats. We’ve been using machine learning in our security products for nearly two decades, developing proprietary detection systems that help identify malicious code and suspicious behavior at a scale and speed that would be impossible manually.
Coming soon: How AI is changing trust online
Malwarebytes recently surveyed 1,500 adults across the US, UK, Austria, Germany, and Switzerland about their experiences with AI. The findings reveal a growing uncertainty about what people can trust online, alongside increasing concern about scams, impersonation, and AI-generated deception.
Stay tuned for the full Malwarebytes report on how AI is reshaping trust, identity, and scams.
Use AI safely
If you use AI in a security context, keep your data hygiene strict. Don’t paste passwords, customer data, or sensitive incident details into public AI tools. Treat AI-generated outputs as untrusted until verified, especially when they touch code, logs, indicators, or policy decisions.
AI can be useful for summarizing information, indentifying patterns, and producing first drafts, but keep a human in the loop for anything that affects access, containment, legal decisions, or public communications. Where possible, prefer enterprise or local deployments with logging, access control, and clear data-retention rules.
Also remember that AI can hallucinate confidently. In security work, that means every output needs validation against logs, documentation, source code, or other primary evidence before you act on it.
Something feel off? Check it before you click.
Malwarebytes Scam Guard helps you analyze suspicious links, texts, and screenshots instantly.
Mexico is one of the host countries for the 2026 FIFA World Cup, with matches to be played in three major cities: Mexico City, Monterrey, and Guadalajara. These locations are expected to see a large influx of international visitors, increasing the potential security risks. Many of those risks arise from users connecting to public wireless networks.
To better understand the wireless environments that visitors may encounter, we at Kaspersky GReAT conducted a wardriving assessment in the three host cities. The aim of the study was to analyze characteristics, deployment patterns, security configurations and potential exposure risks of public Wi-Fi infrastructure in urban wireless environments.
The information collected during the assessment was used exclusively for passive observation and infrastructure analysis. No attempts were made to authenticate, intercept communications, exploit systems or interact with the detected wireless networks beyond the publicly broadcast management information.
During processing of the collected data, one step involved filtering out networks belonging to cars or cell phones categorized as mobile hotspots because they do not represent networks that can be considered part of the assessment.
Research scope
The cities included in the study have high population density and extensive wireless infrastructure deployments. We chose areas with the most prominent wireless network activity and highly concentrated public access points. We carried out wardriving research in Monterrey back in 2008, but the city’s hotspot landscape has changed since then.
We chose the following analysis areas for each of the cities:
Mexico City: México City Stadium, Mexico City International Airport, Zócalo, Paseo de la Reforma, Colonia Roma, La Condesa, Polanco, and Coyoacán.
Guadalajara: Guadalajara Stadium, Guadalajara International Airport, the city center, Zapopan, Providencia, Avenida Chapultepec, Colonia Americana, Tlaquepaque, and the area around Andares.
Monterrey: Monterrey Stadium, Monterrey International Airport, Fundidora Park, Cintermex Monterrey, the downtown area, Barrio Antiguo, MacroPlaza, and the San Pedro financial district.
The wireless information was collected using passive wireless reconnaissance techniques. The collected information included:
SSID analysis and information exposure, including BSSID-derived SSIDs
Default router configurations and ISP deployments
Frequency and signal characteristics
Channel congestion and spectrum usage
Wireless security configurations, including:
Open and insecure wireless networks
WPS-enabled networks
Secure networks (WPA2/WPA3) with WPS enabled
We performed a wireless infrastructure analysis in Mexico City, Guadalajara, and Monterrey. We drove through the areas surrounding the World Cup stadiums, tourist zones, and other places where fan concentrations are likely to be largest. Our goal was to evaluate the security status, deployment characteristics and operational exposure of detected wireless networks.
In total, we recorded 84,588 signals with 69,473 unique Service Set Identifiers (SSIDs) in busy locations and World Cup zones across the three cities. Mexico City accounted for 61.4% of the signals, Guadalajara for 23.6%, and Monterrey for 14.8%. Approximately 82% of the signals had a single SSID (81.9%, 81.34%, and 84% respectively). Notably, they all operate under the IEEE 802.11 standard protocol.
Particular attention was given to identifying standard deployment patterns, legacy configurations, default vendor settings and information disclosure through publicly broadcast wireless identifiers.
The following sections present the results that were obtained by analyzing wireless infrastructure across the three locations.
Our findings
SSID analysis and information exposure
SSID analysis was conducted to evaluate naming conventions, deployment standardization and potential information exposure.
Only a few networks (0.0047%) have an invisible SSID, meaning the names of these networks are not broadcast. Some users prefer to hide the SSID for various reasons, such as the network’s purpose, the profile of its users, internal policies, etc. In contrast, the rest of the networks maintained active SSID broadcasting.
SSID structures may unintentionally disclose operational details about internet service providers (ISPs), device manufacturers, deployment practices, organizational ownership or user identity. The repeated presence of default SSID naming patterns across the analyzed locations indicates a significant degree of infrastructure homogeneity and reuse of default wireless configurations. It may also facilitate passive infrastructure profiling by revealing standard characteristics in use.
Approximately 34% of the detected networks retained the default SSID naming conventions provided by the manufacturer or ISP, while 66% used customized identifiers.
Distribution of SSID naming conventions (download)
Several recurring SSID naming conventions associated with ISP-provided deployments were identified in the three cities. The most frequently observed patterns include identifiers such as “Club_Totalplay_WiFi”, “izzi WiFi”, and “Megacable WiFi”, which suggests extensive standardization of wireless infrastructure deployment. Additionally, we observed distinctive location-specific SSIDs in each area of analysis, such as “XXXX-Internet para Todos-CDMX” or “RED JALISCO”.
Sequential SSID naming structures were also identified during the analysis. Patterns such as “INFINITUMXX” and “IZZI-XX” suggest automated ISP deployment and large-scale deployment strategies.
We identified 33 unique sequential naming structures among the 137 sequential SSIDs in total, representing approximately 0.16% of the detected wireless networks.
The following graph shows the top five sequential SSID patterns found in the largest number of networks:
Five most frequently observed sequential patterns (download)
Several customized SSIDs contained personal or organizational identifiers, including family names, professions, addresses or internal department references. Although personalized SSIDs may simplify local network identification for users, they may also expose sensitive information that could be useful for social engineering, physical targeting, or organizational profiling.
BSSID-derived SSID
During the analysis, multiple networks were identified that used the physical MAC address of a Wi-Fi access point (BSSID) as the visible SSID. This practice exposes hardware-level information that could facilitate vendor fingerprinting and targeted reconnaissance activities.
The organizationally unique identifier (OUI) contained in the first bytes of the BSSID identifies the equipment manufacturer. Threat actors can correlate exposed manufacturers with device-specific vulnerabilities.
Notably, we found that more than 30% of networks in all three cities reuse the MAC address as the SSID.
Default router configurations and ISP deployments
We performed wireless infrastructure profiling to identify the most common wireless equipment manufacturers and ISP deployments across the three locations.
Large-scale ISP deployments frequently use standardized wireless configurations and vendor-specific hardware platforms. Identifying dominant manufacturers and ISP naming conventions can provide insight into infrastructure and deployment practices facilitating the mapping of standardized attack surfaces.
The following figure shows the distribution of the most commonly used manufacturers.
Most frequently observed wireless equipment manufacturers (download)
The manufacturer analysis revealed a strong concentration of wireless infrastructure among a limited number of vendors. Across the three locations, Huawei Technologies, MediaTek-based devices, and other manufacturers’ equipment that is distributed through ISP channels represented a significant portion of the detected deployments. Mexico City had the most diverse infrastructure, while Monterrey and Guadalajara had a greater concentration of wireless equipment known as SOHO (small office/home office) or residential-grade hardware. The widespread presence of standard vendor platforms may facilitate infrastructure fingerprinting and large-scale targeting of known device-specific vulnerabilities.
Most frequently observed wireless equipment manufacturers across the three cities (download)
ISP deployments frequently exhibited standardized configuration patterns and recurring manufacturer identifiers. Our ISP deployment analysis revealed a high concentration of access points associated with major residential internet providers. Deployments associated with Infinitum, Totalplay and Izzi represented a substantial portion of the detected wireless infrastructure across all locations. These findings suggest a high degree of deployment standardization across networks associated with major residential internet providers. This observation was supported by the repeated presence of ISP-associated SSIDs such as “Infinitum”, “Totalplay”, and “Izzi”, combined with manufacturer identifiers frequently associated with consumer equipment, including Huawei, ZTE and other residential wireless equipment vendors.
It is important to note that, for this analysis, ISPs were primarily inferred from SSID naming conventions and manufacturer fingerprint data. A significant portion of the detected wireless networks fell into the “UNKNOWN/CUSTOM” category. This classification includes custom hotspots and networks whose naming conventions did not expose identifiable ISP-associated patterns. The findings suggest that many users and organizations (as we saw previously, approximately 66%) use custom network names, limiting direct provider attribution.
The following figure illustrates the distribution of ISP-associated wireless deployments in general.
To better understand this distribution, we took the most frequently observed ISPs by city.
Most frequently observed ISPs across the three cities (download)
Frequency and signal characteristics
We also analyzed wireless signal characteristics to evaluate coverage quality, signal strength, and frequency band utilization in the three cities. In dense urban environments, signal quality and frequency spectrum distribution can affect wireless reliability, client connectivity, roaming performance, and overall network efficiency.
Signal quality analysis revealed that a substantial portion of the detected access points operated under weak or very weak signal conditions. Monterrey had the highest percentage of very weak signals, with approximately 50% of detected deployments. Similar patterns were observed in Guadalajara and Mexico City, suggesting high-density wireless environments with overlapping coverage areas. Only a limited percentage of networks were classified within the very good or excellent signal categories across the three locations.
Signal stability analysis revealed that most detected wireless deployments exhibited stable beacon transmission behavior. More than 96% of the detected access points across all locations were classified as stable, while only a small percentage exhibited unstable or indeterminate signal behavior.
These findings imply that the majority of the wireless infrastructure observed during the assessment corresponded to permanently deployed access points rather than transient or intermittent wireless devices.
Frequency band analysis revealed the strong prevalence of 2.4 GHz wireless deployments across the three locations. More than 95% of the detected wireless networks operated within the 2.4 GHz spectrum, while only a small percentage of deployments were classified under the unknown or non-standard frequency categories. This uneven distribution reflects the continued prevalence of legacy-compatible wireless infrastructure and SOHO deployments.
These findings are consistent with dense urban wireless environments with large numbers of access points in restricted spectrum allocations.
Channel congestion and spectrum usage
Next, we analyzed wireless channel utilization to evaluate frequency spectrum congestion and channel allocation patterns across the three cities. Our analysis focused on the 2.4 GHz spectrum, where channel overlap and high access point density commonly produce interference and degraded wireless performance. In densely populated wireless environments, an excessive concentration of access points on a limited number of channels can lead to co-channel interference, packet collisions, reduced throughput, and degraded network stability.
Spectrum congestion analysis revealed that the 2.4 GHz band consistently experienced elevated congestion levels across the three cities. The detailed results showed a strong concentration of deployments on channels 11, 6 and 1, which are traditionally recommended as non-overlapping channels within the 2.4 GHz spectrum. Channel 11 was the most utilized channel, accounting for 25.2% of the detected access points, followed by channel 6 with 22.5% and channel 1 with 19.5%. This distribution indicates that most wireless deployments adhere to standard channel allocation practices for 2.4 GHz Wi-Fi environments.
The following figure illustrates the overall distribution of the most frequently utilized wireless channels.
To further assess wireless spectrum saturation, the detected access points were grouped according to channel congestion levels: VERY_HIGH, HIGH, UNKNOWN, MEDIUM, LOW and NONE.
Mexico City had the highest proportion of heavily congested wireless channels, with approximately 7% of detected access points operating under HIGH congestion conditions. Guadalajara followed with nearly 5% of deployments categorized as HIGH congestion, while Monterrey had the lowest percentage at approximately 3.29%.
These findings suggest that wireless spectrum saturation increases proportionally with urban infrastructure density and access point concentration. Despite the presence of congested deployments, most detected access points were categorized as LOW or MEDIUM congestion, suggesting severe spectrum saturation was localized rather than uniformly distributed.
A thorough analysis of individual channel utilization revealed that channels 11, 6 and 1 consistently experienced the highest congestion levels across the three cities, which correlates with our previous findings. These channels accounted for the majority of VERY_HIGH congestion classifications, particularly within the 2.4 GHz band.
In Mexico City, channel 11 alone accounted for more than 25% of detected deployments and consistently exhibited VERY_HIGH congestion levels.
This behavior reflects the limited availability of non-overlapping channels within the 2.4 GHz spectrum and the widespread reliance on default wireless configurations.
Overall, the channel utilization analysis showed that wireless deployments are concentrated heavily within the traditional, non-overlapping 2.4 GHz channels. While this strategy reduces adjacent-channel interference, excessive access point density on the same channels can still produce significant co-channel contention and poor wireless performance in high-density urban environments.
Wireless security configurations
The next thing we evaluated was the security posture of the detected wireless networks. We analyzed the wireless security configurations advertised by access points in each of the locations.
Overall security configuration distribution
The analysis revealed that WPA2 was the dominant wireless authentication mechanism across the three cities. Mexico City had the highest WPA2 adoption rate at 81.19%, followed by Monterrey at 79.19% and Guadalajara at 77.59%.
The study found that every 6th open access point (17%) was unsafe, namely 16.5% in Mexico City, 18.5% in Guadalajara, and 17.2% in Monterrey. Open wireless deployments were consistently present across all locations, ranging between 10% and 12% of detected access points. These findings show that despite the widespread deployment of modern wireless security standards, encryption adoption remains incomplete.
Distribution of wireless authentication mechanisms across the three locations (download)
To simplify the interpretation of wireless security posture, we grouped detected networks into four categories:
Secure (WPA2/WPA3)
Insecure (Open/WEP)
Weak (WPA)
Unknown
Across the three locations, secure networks comprised most of detected deployments, accounting for approximately 82% of all access points. However, insecure open networks still account for between 10% and 12% of detected wireless infrastructure, consistent with our previous findings. It is important to mention that networks within the unknown category are not considered secure.
Mexico City had the highest percentage of secure deployments at 83.54%, while Guadalajara had the highest percentage of insecure open networks at 12.46%. Although Monterrey had the lowest percentage of insecure networks, open deployments still accounted for more than 10% of the detected access points.
Wireless security posture grouping across the three locations (download)
Although modern WPA2/WPA3 encryption standards dominate current wireless deployments, the continued presence of open and legacy WPA deployments indicates that insecure wireless configurations remain relevant from an operational standpoint. These networks may expose users to passive traffic interception, unauthorized monitoring, rogue access point attacks, and credential harvesting techniques.
WPS-enabled networks
We also analyzed Wi-Fi Protected Setup (WPS) in all the locations to evaluate additional attack surfaces. WPS is a standard feature on wireless routers that enables devices such as printers, repeaters or mobile phones to connect to a secure Wi-Fi network without manually entering a long password, typically through a PIN-based enrolled mechanism. Although WPA2 and WPA3 provide strong encryption mechanisms, the presence of WPS can introduce security weaknesses due to inherently vulnerable PIN-based enrollment methods.
By combining detections from the three locations, we found that 55% of all detected access points did not advertise WPS capabilities, leaving 45% of deployments vulnerable to WPS-based abuse. These results suggest that, despite the adoption of modern encryption standards, a significant portion of wireless infrastructure continues to expose legacy convenience features.
During the analysis, we found that Mexico City had the highest proportion of WPS-enabled networks, with 46.61% of the detected access points advertising WPS capabilities. Guadalajara was second with 43.45%, while Monterrey had the lowest proportion at 40.93%.
The percentage of detected access points advertising WPS capabilities across the three locations (download)
Almost half of the detected wireless networks in each city continued to advertise WPS, indicating that WPS prevalence is consistently high across the three cities.
Secure networks with WPS enabled
In many cases, networks classified as secure because of WPA2/WPA3 encryption still had WPS functionality enabled, which effectively increased the available attack surface.
To further assess the relationship between encryption strength and WPS exposure, we conducted a secondary analysis of secure networks (WPA2/WPA3) only. The results showed that around half of all secure deployments still exposed WPS, with the following breakdown for each city:
Mexico City: 53.7%
Guadalajara: 50.9%
Monterrey: 47.5%
The proportion of secure networks with WPS enabled across the three locations (download)
These findings indicate that encryption strength alone is not enough to evaluate wireless security posture because additional protocol features, such as WPS, may still expose exploitable attack vectors.
Additional security considerations
Overall, travelers operating within dense public environments are exposed not only to insecure wireless infrastructure but also to various risks associated with digital interactions. These risks include many threats, from public USB charging systems and phishing QR codes to proximity-based protocols and exposure to shared public devices, such as interactive totems or kiosks. One particular point that should be taken into account in light of our research is the issue of rogue wireless deployments.
Rogue access points are not necessarily malicious; they may be set up accidentally by misconfiguring router settings. An entry point for potential compromise might be caused by various misconfigurations, from a weak password to an insecure protocol. However, attackers deploy such unauthorized hotspots with malicious intent to infiltrate a network. Threat actors may deploy rogue access points posing as legitimate public wireless networks in airports, hotels, cafés and tourist areas. These deployments are called “evil twins” and can trick users into connecting to attacker-controlled infrastructure capable of intercepting traffic, harvesting credentials, or performing man-in-the-middle attacks. Further risk lies in the potential compromise of local network devices or even malware distribution. Such threats complement our findings, underscoring the importance of implementing traffic encryption, using a security solution and exercising extreme caution while browsing via public networks.
Conclusion
The wardriving assessment conducted in Mexico City, Guadalajara, and Monterrey revealed that modern wireless infrastructure continues to present multiple forms of operational exposure despite the widespread adoption of WPA2 and WPA3 security standards. The analysis demonstrated that wireless environments are highly standardized in all the locations, with recurring ISP deployments, default SSID naming conventions, homogeneous manufacturer distribution, and predictable channel allocation practices observed in all three cities.
Although most of the detected networks were classified as secure under WPA2/WPA3 authentication mechanisms, a significant proportion were exposing additional attack surfaces through enabled WPS functionality, default configurations, sequential SSID structures, and infrastructure metadata disclosure. This demonstrates that encryption strength alone is insufficient for evaluating the overall security posture of wireless infrastructure. Additionally, the prevalence of open networks and legacy wireless configurations indicates that insecure deployments are still operationally relevant in all the locations.
The results also showed that wireless infrastructure is heavily concentrated within the 2.4 GHz spectrum, particularly around channels 11, 6, and 1. This leads to elevated congestion and increased co-channel interference in densely populated urban environments.
SSID analysis further revealed that publicly broadcast wireless identifiers frequently expose valuable operational information about ISPs, equipment manufacturers, deployment templates, organizational ownership, and user-defined naming practices. The identification of default ISP naming conventions, sequential SSID structures, and BSSID-derived SSIDs demonstrated that many deployments prioritize operational convenience and simplicity over exposure minimization and privacy.
The scope of the threats stemming from vulnerable wireless configurations poses serious digital exposure risks for users. The widespread presence of standard deployments, predictable SSID naming and publicly exposed infrastructure identifiers can facilitate passive reconnaissance, infrastructure fingerprinting and opportunistic targeting.
Recommendations
To minimize the risks of wireless-based exposure and the attack surface related to hotspot infrastructure, we recommend taking the following measures:
Disable WPS functionality on wireless routers whenever possible, particularly within WPA2/WPA3 deployments.
Avoid using default SSID naming conventions that disclose ISP providers, router manufacturers, or deployment templates.
Refrain from using personal, organizational, or location-based identifiers in wireless network names.
Avoid configuring SSID using BSSID or naming conventions derived from MAC addresses, as these may expose hardware fingerprinting information.
Promote migration toward modern WPA3-capable infrastructure while removing legacy wireless protocols when operationally feasible.
Reduce wireless congestion by optimizing channel allocation strategies and minimizing excessive dependence on the 2.4 GHz spectrum.
Encourage adoption of 5 GHz and newer wireless technologies to reduce interference and improve spectrum efficiency.
The findings presented in this assessment emphasize the importance of combining strong wireless encryption standards, secure deployment practices, exposure minimization strategies, and user awareness to enhance the overall security posture of wireless environments.
Modern infrastructures universally rely on containerization to deploy applications, scale services, and build cloud platforms. The use of Docker, Kubernetes, and similar technologies has become the corporate standard for efficient automation. However, as containers grow in popularity, so does the interest of malicious actors — a trend we actively track in our research into advanced cyberthreats. For instance, in one of its recent attacks, the APT group TeamPCP compromised Checkmarx KICS across multiple attack chains for different vectors. This included poisoning a Docker Hub repository to later steal Kubernetes secrets and other sensitive data. The tainted images distributed a stealer that was loaded during the KICS scanning process.
Today, attacks on container environments have evolved into full-fledged, multi-stage scenarios involving supply chain compromises, Kubernetes secrets theft, orchestration API abuse, and container escape attempts. This article examines the primary container attack vectors that retain top relevance today.
Principles of containerization
A container is an isolated code execution environment, designed to partition resources so applications can run correctly and independently. Unlike a virtual machine, a container uses the single underlying kernel of the host operating system.
To isolate the environment, a container uses a distinct process namespace and a virtual file system. Container resources are capped and shared with the host system. This container isolation is built on top of Linux kernel features such as namespaces, cgroups, capabilities, and seccomp.
Compromising a container can help attackers achieve their objectives on the host system itself. Below, we examine the current vectors relevant to container implementation architecture and infrastructure.
Current attack vectors
The primary and most critical attack vectors targeting container environments that are actively exploited by malicious actors include:
Exploiting vulnerabilities in the host system and container runtime components
Malicious activity inside a compromised container
Container escape followed by host compromise
Exploiting misconfigurations and the insecure use of containerization and orchestration APIs
Supply chain attacks, including container image poisoning and CI/CD pipeline compromise
Each of these vectors can be utilized either independently or as part of a complex, multi-stage attack chain. In practice, attackers rarely stop at compromising a single container; their primary objective is often to gain access to the Kubernetes cluster, secrets management systems, or other mission-critical environment components. This is why securing container infrastructure requires a comprehensive approach that spans configuration auditing, runtime protection, activity monitoring, and software supply chain security. Let’s take a closer look at each of these vectors.
Exploiting host system vulnerabilities
Because a container does not have its own isolated OS, vulnerabilities affecting the Linux kernel or runtime components remain just as critical when exploited from within a container.
Any vulnerability that allows for privilege escalation, arbitrary code execution, or isolation bypassing can potentially be leveraged by an attacker once the container is compromised. Successful exploitation of these flaws can lead to a container escape, compromise of the Kubernetes node or the entire cluster, lateral movement across the infrastructure, secrets theft, and malicious actions potentially culminating in a complete service disruption. It is worth noting that the mere presence of a vulnerability does not always guarantee a compromise, as exploitation sometimes requires specific configuration settings or privileges to work.
Below are examples of several vulnerabilities leveraged in attacks on container environments:
CVE-2019-5736 is one of the most prominent and illustrative vulnerabilities associated with containerization. It affected the runC runtime environment and allowed an attacker, who already had root access inside the container, to execute arbitrary code on the host system with root privileges. The root cause of the vulnerability was runC’s improper handling of the file descriptor for its own executable via the /proc/self/exe mechanism. When a container was started, the runC process temporarily executed within the container’s context while remaining a host system process. This allowed an attacker to gain access to the runC binary and overwrite its contents.
CVE-2022-0492 is a critical Linux kernel vulnerability that allows for container escape and arbitrary command execution on the host system. The flaw stemmed from improper privilege validation when interacting with the cgroups release_agent mechanism. This vulnerability posed a particular risk for container infrastructures because it allowed an attacker who already possessed code execution capabilities inside a container to break out of isolation and gain control of the host system.
CVE-2024-21626 is a critical vulnerability in runC that allowed an attacker to access the host file system from within a container, and in specific scenarios, even perform a complete container escape. The root cause of the issue was runC’s improper handling of file descriptors and the process’ current working directory when spinning up containers or executing commands via docker exec or similar mechanisms.
Malicious actions inside the container
Sometimes, an attacker does not need to exploit complex attack chains involving container escapes, Kubernetes cluster compromise, or lateral movement to achieve their goals. In many cases, the container itself already houses data and resources that are highly valuable to the attacker. For example, a container may contain:
User and service credentials
API keys
Access tokens
SSH keys
Environment variables containing secrets
Kubernetes ServiceAccount tokens
Configuration files
Application service data or databases
These types of data are especially prone to exposure due to configuration mistakes or specific operational processes. For instance, secrets might be passed via environment variables, baked into Docker images during the build phase, or mounted directly inside the container. In Kubernetes environments, automatically mounted ServiceAccount tokens are of particular interest to attackers, as they provide a direct pathway to interact with the Kubernetes API.
Even a single compromised container frequently provides an attacker with sufficient leverage for next steps: gaining access to external services, compromising cloud infrastructure, stealing user data, impersonating a trusted service, or establishing persistence within the environment. Beyond data theft, malicious actors can use a compromised container as a staging ground for further malicious activity. This is why securing container infrastructure is about much more than just preventing escapes. Even a fully isolated container, if it houses sensitive data or holds access to internal services, can become a major foothold for an infrastructure breach.
In the context of this vector, approaches and techniques applicable not only to container environments but also to traditional systems are frequently applied. Once an attacker gains access to a container, they usually find themselves in a full-featured Linux environment, allowing them to deploy standard post-exploitation, reconnaissance, and persistence methods.
We explored container configuration errors and other unsafe practices that attackers could exploit to carry out malicious activities in more detail in this article.
Container escape
Container escape is one of the most dangerous and prevalent attack vectors targeting container infrastructure. The term refers to the bypassing of container isolation, allowing an attacker to directly interact with the host system.
The opportunity to escape a container can arise from a multitude of sources: the exploitation of vulnerabilities, container misconfigurations, or the insecure use of containerization and orchestration APIs. Indeed, container escape is the logical conclusion of most attacks on container infrastructure, as the attacker’s ultimate goal is frequently to break out of the isolated environment and gain access to the host system or the broader Kubernetes cluster. As such, container escape ties together a significant portion of the attack vectors discussed in this article. In practice, misconfigurations remain one of the most common root causes of successful container escapes, as they occur far more frequently than the exploitation of complex vulnerabilities. With that in mind, we will take a closer look at container misconfigurations and their associated attack scenarios below.
To better understand the risks associated with container misconfigurations, let’s explore the concept of capabilities in Linux systems. This is a mechanism for granularly granting extended permissions to processes, allowing them to perform privileged actions without needing full root access.
Privileged containers
One of the most dangerous configurations is running a container with the --privileged flag. In this mode, the container is granted all Linux capabilities, direct access to host devices, and the ability to interact with kernel interfaces. A container configured this way virtually ceases to be an isolated environment and, in many cases, possesses capabilities comparable to root access on the host system.
Let’s look at a basic example of a container escape attack involving the --privileged flag. Using the capsh utility, you can see that such a container possesses virtually all Linux capabilities. Furthermore, if the PID namespace matches the host’s, the process with PID=1 corresponds to init, the first system process in Linux. In a different configuration, PID 1 would belong to the process that created the container. If we spawn a shell from the init process using the nsenter utility, the expected behavior is the creation of a process outside the container, which can easily be verified by using the hostname command.
Container privilege misconfigurations open up a broad attack surface. Let’s dive deeper into how specific capabilities can be used to execute a container escape.
CAP_SYS_ADMIN
CAP_SYS_ADMIN is considered one of the most dangerous Linux capabilities in the context of container security. Although Linux capabilities were originally intended to break down superuser privileges into discrete categories, over time, CAP_SYS_ADMIN became a catch-all for a massive number of sensitive kernel operations. As a result, a container granted this capability gains access to a wide array of system mechanisms that directly impact container isolation. It inherits the ability to mount file systems, interact with the cgroups mechanism responsible for resource allocation, modify kernel parameters within certain limits, work with loop devices, and utilize various namespace management features. In practice, this heavily blurs the line between the container and the host system.
This capability becomes especially dangerous when combined with other configuration errors. For instance, if the container is configured to use the hostPath parameter, an attacker can leverage a container compromise to mount the host system’s directories right into their own environment and access critical host files. Similarly, having access to /proc or /sys allows for direct interaction with internal Linux kernel mechanisms, which can drastically expand the blast radius of the breach.
Let’s look at a clear example of how having CAP_SYS_ADMIN can help an attacker escape a container. Illustrated below is the sequence of actions inside a container possessing CAP_SYS_ADMIN privileges and access to host directories. By mounting the host’s disk to a folder inside the container, the attacker can freely interact with all files on the host system. In this specific example, it shows the ability to overwrite the root user’s shell configuration by injecting an arbitrary malicious payload.
CAP_SYS_MODULE
CAP_SYS_MODULE provides direct access to the kernel module loading and unloading mechanism. This direct interaction with kernel space makes CAP_SYS_MODULE a high-risk capability, unlike many other capabilities that are restricted purely to user space.
From a Linux architectural standpoint, kernel modules consist of code executing with maximum privileges inside kernel space. These modules can extend system functionality, manage devices, handle the network stack, interface with file systems, and control other mission-critical components. This is why the ability to dynamically load these modules via CAP_SYS_MODULE equates to having the power to manipulate the behavior of the entire operating system.
In practice, modern containerized applications rarely require CAP_SYS_MODULE. The presence of this capability is typically tied to legacy architectures, monitoring systems, or specialized drivers that must interact directly with the kernel. This is why CAP_SYS_MODULE is almost universally banned in modern infrastructures. In most environments, it is considered an unacceptable risk because its compromise does not just lead to localized privilege escalation within the container, but to code execution directly in kernel space.
A container escape using this capability happens in several stages. The goal of the attack in this case is to load a malicious Linux kernel module. It is worth noting that the module must match the specific kernel version in use, requiring the attacker to perform additional reconnaissance to identify it. These attacks can be executed entirely within the container if it contains the necessary build tools to compile the module and has access to kernel dependency directories. However, because these utilities are typically stripped from container images, attackers usually compile the malicious payload with the required dependencies on an external host. They then either transfer it over the network or drop it into a binary file on the target by using a command like echo.
Let’s look at a container escape using a kernel module with the following payload example:
Upon loading, this module triggers the reverse shell. Once the payload is built and successfully delivered to the container, all the attacker needs to do is start a listener on the IP address and port specified in the payload, and then load the module into kernel space.
CAP_SYS_PTRACE
The CAP_SYS_PTRACE capability grants a process elevated permissions to interact with other system processes via the ptrace system call. While it is designed for debugging and code tracing, its misconfiguration in containerized environments can severely weaken isolation and, under certain conditions, enable a container escape leading to host system compromise.
The primary risk of CAP_SYS_PTRACE is that it allows a process to read and modify the memory of other processes, control their execution, inject code, and extract sensitive data directly from memory. Furthermore, CAP_SYS_PTRACE enables process injection techniques.
If a container is compromised, an attacker can use ptrace to attach to host processes. Crucially, this is only possible if the host’s PID namespace is shared with the container — this is configured via hostPID: true. This configuration allows the attacker to target a process running on the host, inject code, and trigger a reverse shell — though in most cases, this requires additional malicious code. The image below demonstrates this kind of an attack, implemented using a publicly available PoC.
CAP_NET_ADMIN
CAP_NET_ADMIN provides extensive privileges to manage the network stack of a Linux system. If a container is compromised, the presence of this capability significantly weakens network isolation and creates additional opportunities for further exploitation.
A container equipped with CAP_NET_ADMIN can modify network interface configurations, manipulate routing tables, interact with traffic filtering mechanisms, and alter the behavior of the network stack. Although most of these operations are formally restricted to the container’s own network namespace, in practice, this capability is frequently combined with other misconfigurations — such as the hostNetwork: true parameter — which grants direct access to the host’s network resources.
Once inside the container, an attacker can leverage this capability to modify its network behavior and launch further attacks across the infrastructure. One of the most common scenarios involves manipulating iptables rules to redirect traffic. This enables man-in-the-middle (MitM) attacks, allowing the attacker to intercept internal traffic or mask their own malicious activities.
It is important to emphasize that there are many other Linux capabilities that can lead to a container escape when combined with specific misconfigurations; we have highlighted only a few of the most severe and frequently encountered.
Exploitation of orchestration APIs
One of the most dangerous and common attack vectors in containerized infrastructure is the exploitation of misconfigured container management and orchestration APIs. Unlike attacks that require complex kernel vulnerability exploits or container escape, this scenario is often remarkably straightforward: the attacker simply needs to gain access to the control interfaces of the container environment.
The fundamental risk stems from the fact that container platform APIs possess inherent administrative privileges over the entire infrastructure. The Docker API, Kubernetes API, and kubelet API are designed to spin up containers, modify configurations, access host file systems, and execute commands inside running containers. When misconfigured, these interfaces immediately become a point of failure for the entire environment.
One of the most notorious examples of this vector is an exposed Docker API. If the Docker daemon is accessible over TCP without TLS or authentication, an attacker can remotely interact with the host system with permissions equivalent to a local administrator. They can deploy new containers custom-configured for attacks, mount the host’s entire root file system, and execute arbitrary commands within any container via the API. In practice, compromising an unauthenticated Docker API typically leads to a complete host takeover after just a few API requests.
Similar risks exist within Kubernetes environments. The Kubernetes API server acts as the central control point for the entire cluster. If an attacker manages to compromise a ServiceAccount token, exploit weak RBAC policies, or discover an inadvertently exposed API server, they can execute a broad spectrum of destructive operations.
For the sake of this attack example, let us assume that an attacker has compromised a Kubernetes API token for a privileged account. First, they enumerate the token’s permissions, typically by running a script to query each individual capability. This gives them a full list of Kubernetes privileges.
The script’s output reveals that the compromised API token grants exceptionally high privileges within the cluster. The logical next step in the attack chain is to deploy a malicious, privileged container to execute any of the host escape techniques described above. In our example, the attacker used a curl POST request to the API to create the container:
Once the privileged container is deployed, the attacker can execute an escape to compromise the underlying host system.
However, this is not the only high-risk scenario involving API requests. For instance, when a Docker socket is mounted inside a container, an attacker gains the ability to interact with the Docker daemon directly. Once that container is compromised, the attacker effectively inherits the privileges of the daemon, which means they gain control over all containers on the host.
To execute the attack, adversaries look for containers with mounted sockets. The further progression of the attack replicates what has been described above: an API request is made to create a privileged container, after which any escape method is similarly exploited using the API.
Supply chain attacks
Unlike classic attacks aimed at exploiting vulnerabilities in already deployed containers, this approach focuses on compromising components before they are even launched in the runtime environment. Modern container infrastructure is tightly integrated with a large number of external components. As a result, container security directly depends not only on the application itself, but on the entire image build and delivery chain. Compromising any of these stages potentially allows an attacker to inject malicious code into multiple containers and services simultaneously.
One of the most common scenarios involves attacks that contaminate container images. In many organizations, developers use public images from Docker Hub or other available sources without a full verification of their origin or contents. Threat actors frequently publish contaminated images that masquerade as popular services and utilities. Once a container like that is launched within the infrastructure, the attacker gains the ability to execute their own code right inside the organization’s trusted environment.
Furthermore, CI/CD container deployment systems are among the most frequent targets of these attacks. Application build and delivery platforms typically possess elevated privileges. For instance, after gaining access to a CI/CD system, an attacker can covertly modify the Docker image build stages. Instead of altering the application’s source code, the attacker can inject the malicious logic directly into the pipeline itself. An additional command during the build process can download a third-party binary, add a hidden script, modify the container configuration, or implant a remote management mechanism. Externally, the container will look completely legitimate because its core functionality remains unchanged.
Takeaways
Overall, modern attacks on container environments demonstrate that the primary threat arises not just from within the container itself, but from the implementation of the container infrastructure as a whole. Containers are frequently exploited as an initial foothold to establish persistence within a system; following an initial compromise, attackers aim to either escalate to the host OS level or gain control over infrastructure management via containerization and orchestration APIs. To achieve this, they exploit weak configurations, excessive capabilities, and isolation flaws.
Furthermore, there is a visible trend of attacks shifting toward CI/CD pipelines, where compromising a single component can lead to a full infrastructure takeover. Therefore, under current realities, securing containerized environments requires an approach that encompasses host protection, strict access control within the orchestrator, minimization of container capabilities, and comprehensive validation of the entire supply chain. Our solution Kaspersky Container Security has been designed with the specific characteristics of container environments in mind and provides protection at various levels from container images to the host system helping to implement the principles of secure software development.
Containerization using Docker has become firmly established in modern development standards, significantly increasing the speed and convenience of deploying various services. Developers often use ready-made Docker images, making only minimal changes. The largest repository of container images is the Docker Hub service.
Container-hosted infrastructure is an attractive target for attackers. At a minimum, a compromised container can be used for DDoS attacks, cryptocurrency mining, or traffic proxying. The list of threats does not end there: once an attacker gains control of a container, they can steal or destroy data directly from it, access neighboring containers, or even attempt to escape the container, compromising the entire enterprise network.
At the same time, the infrastructure inside containers is typically updated less frequently and may contain outdated and vulnerable software versions. When deploying third-party images or modifying them for a specific environment, it is easy to make configuration errors that attackers can later exploit. And due to the architectural characteristics of containers, developers often face constraints when preparing images; to overcome these, they may resort to insecure solutions they find online.
In other words, containerized infrastructure can be both the simplest and the most lucrative target to exploit. Therefore, its security requires heightened attention. To minimize the risk of successful attacks on container infrastructure, it is essential to check the final Docker images, including all underlying layers, for vulnerabilities and misconfigurations. The easiest way to do this is by analyzing the Dockerfile; however, it is not always available for inspection. Moreover, it typically defines how to build layers on top of a base image from an external repository whose reliability cannot be guaranteed.
Image analysis results in Kaspersky Container Security
To help users identify insecure configurations and potential vulnerabilities within them, we have added our AI assistant to Kaspersky Container Security.KIRA (the assistant’s name) uses artificial intelligence to analyze the image and identify potential issues within, along with recommendations on how to fix them.
As part of this study, we asked KIRA to analyze a number of popular community images, and later in this article, we’ll show you the results.
Software vulnerabilities and compromise of update sources
One of the key security issues with using pre-built images is that developers do not update them in a timely manner. A Docker image is, by its very nature, a snapshot of a specific Linux distribution after packages have been installed on it. However, in most cases, it does not receive security updates on its own, unlike traditional Linux servers, where these updates are automatically installed by specialized services, such as unattended-upgrades in Debian-based distributions and dnf-automatic in RedHat-based distributions.
To apply updates to a Docker image, it must be rebuilt and redeployed. Often, this process is not automated, and some updates require additional effort to verify their correct operation, modify configurations when upgrading to new software versions, and so on. As a result, many popular images do not receive timely updates, which significantly increases the risks associated with their use.
An image that was secure at build time accumulates vulnerabilities as they are discovered in the packages installed within it, which over time significantly increases the opportunities for a successful attack on the container.
Vulnerable versions of web applications and network services accessible from the internet immediately become targets of various malicious campaigns. For example, just one day after the discovery of the CVE-2025-55182 vulnerability in React Server Components, our honeypots recorded numerous attack attempts related to this vulnerability. It was adopted by operators of many malicious campaigns, ranging from classic cryptocurrency miners to variants of Mirai and Gafgyt. Attackers are constantly adding new distribution methods and can use dozens of exploits targeting various vulnerabilities and configuration errors in popular services. Often, the same vulnerabilities are used in self-propagation mechanisms from already compromised hosts. For example, in a malicious campaign to spread the Dero miner, attackers use infected containers to automatically search for and infect new targets.
In addition to vulnerabilities that can be exploited remotely, attackers are rapidly adding local vulnerabilities to their arsenal, used to gain root privileges and escape the container: in the Kinsing malware campaign, attackers used CVE-2023-4911 (Looney Tunables) to elevate privileges, and in the perfctl campaign, the CVE-2021-4034 (PwnKit) vulnerability was used for the same purpose. The access gained was used to install a rootkit that hides the presence of perfctl on the system.
To assess the situation with unpatched vulnerabilities in containers, we took a random sample of 100 images, which included various popular solutions with 10,000 to 1 million downloads on DockerHub. In the 64 images we scanned, we found outdated software versions with critical vulnerabilities. For example, some images contained the CVE-2025-49844 vulnerability in the Redis server, leading to RCE by leveraging a vulnerability in the Lua parser; the current CVE-2026-24061 vulnerability in nginx, which in some configurations leads to a server process crash, and with ASLR disabled, again, to RCE; vulnerabilities CVE-2025-32463 in sudo and CVE-2023-4911 in glibc, allowing an attacker to gain root privileges with local access. At the same time, only one in ten Docker images from the analyzed sample is fully up to date.
TOP 10 Critical Vulnerabilities with PoC/Exploits available as shown in the Kaspersky Container Security Dashboard
It is worth noting that, of course, not every discovered vulnerability can be directly exploited by attackers. A practical risk arises when the vulnerable application or library is actually in use, and the conditions necessary for exploitation – which vary significantly from vulnerability to vulnerability – are met. Nevertheless, updates must not be ignored, as the risk of vulnerabilities being exploited – both individually and in various combinations – cannot be predicted in each specific case, and even vulnerabilities that seem harmless at first glance can ultimately pose a serious risk of compromise.
A record number of vulnerabilities in a single image
However, frequent updates have a downside. Every rebuild that downloads new packages from source repositories introduces an additional risk of a supply chain attack – a compromised dependency or a modified base image could silently inject malicious code into your environment precisely through an update. During our analysis of images from the sample, we did not find any signs of supply chain attacks. However, in March 2026, a supply chain incident occurred in the Trivy and LiteLLM projects. In the case of Trivy, the infected file was injected directly into the container image in the official repositories.
Detecting potentially malicious software using one of the images as an example
This leads to a difficult choice: infrequent updates leave known vulnerabilities unpatched within the image, while frequent updates increase the risk of supply chain compromise. Therefore, to protect your infrastructure, you need not only to regularly update base images but also to take a more comprehensive approach, specifically by pinning dependencies to known-good versions and scanning the resulting images for malware upon update.
Configuration vulnerabilities
Even a container with a fully updated image can be compromised if it is configured incorrectly. Embedding keys and secrets in the image, disabling authentication in network services, default passwords, and insecure file access permissions – all of these can be exploited by attackers in one way or another to achieve their goals.
Insecure image configurations detected by KCS based on rules
The situation is exacerbated by the fact that errors may be introduced by the authors of the original image, which complicates their detection, as this requires analyzing every layer and the command that generated it. As with vulnerabilities, not every configuration error leads to compromise: it all depends on the container’s role, its network accessibility, and many other factors. But the very use of insecure settings will sooner or later lead to errors appearing in images where their consequences will be significantly more dangerous.
Standard rules are often insufficient for analyzing problematic configurations. To gain a deeper understanding of the context and assess potential risks, AI tools can be used. Later in this section, we will examine examples of typical insecure configurations we discovered while scanning public images from Docker Hub, along with the descriptions of issues and risk mitigation methods provided by the KIRA AI assistant.
Example of container analysis using KIRA
Insecure handling of credentials
Use of default passwords
In some cases, containers may use default passwords set via environment variables or directly in Dockerfile. If these passwords are not overridden, attackers will be able to access the application by using the default password.
RUN |1 DEBIAN_FRONTEND=noninteractive /bin/sh -c echo [removed]:[removed] | chpasswd
According to KIRA’s analysis, the user’s password is stored in plain text in the image layer history. Anyone who gains access to the image – whether through a public registry, a compromised build environment, or other means – will be able to extract the password. If SSH or another form of interactive access is enabled in the container, this could lead to its complete compromise and allow attackers to move laterally within the infrastructure.
Passwords may be present in environment variables. Consider the following Dockerfile snippet:
In this example, the environment variable PKP_DB_PASSWORD is set to changeMePlease. If the user forgets to override it, the application will use the password that can be obtained from Dockerfile.
For this image, Dockerfile specifies that the administrator password is hardcoded in the ENV directive and remains in the image metadata (layer history, docker inspect). Anyone who gains access to the image (registry, build cache) will be able to extract this secret and compromise the account.
To eliminate these risks, ensure that no passwords are specified in Dockerfile. If authentication is required, you can use orchestrator mechanisms (secrets) or generate a temporary password when starting the container via the entrypoint script, without saving it in the layers. We also recommend using mechanisms for securely passing secrets at runtime (Docker secrets, Kubernetes Secrets) or, as a last resort, passing them via --secret during the build with BuildKit, but under no circumstances should they be left in the final image.
Passing passwords via command arguments
In some cases, passwords may be exposed when passed via command-line arguments, as these arguments are visible to all users on the system:
In the example provided, the MySQL superuser password is passed into the healthcheck command in plaintext, making it visible when viewing the process list (ps aux), in audit logs, and in monitoring systems. If the attacker gains read access to the container’s processes or logs, they can extract the password and gain full control of the database.
To fix this issue, the healthcheck should use a local connection via a Unix socket with default authentication (if the auth_socket plugin is configured for root), or create a dedicated user with minimal privileges (e.g., only USAGE), without a password or with a password passed via a secure file (--defaults-file with restricted permissions). You can also use the MYSQL_PWD environment variable for healthcheck authentication, but it remains visible in /proc.
Privilege escalation in the container
One of the most common vectors for initial compromise of Linux systems is RCE in web applications and network services. Typically, these services have minimal privileges, which complicates attackers’ subsequent actions: dumping credentials, covering their tracks, attempting to escape the container, and much more.
The situation worsens significantly if the attacker gains root privileges, as this allows them to fully control all processes within the container, conceal their activity, and use methods to escape the container. For example, they can compromise the host if the container is privileged, a Docker socket is mounted inside it, or other insecure configurations and vulnerabilities exist that cannot be exploited with standard user privileges.
Similarly, this simplifies network attacks on neighboring containers, the orchestrator, and various internal services, making this configuration error a potential link in the chain for compromising the entire network.
Attacks on sudo
One of the simplest privilege escalation methods is executing arbitrary commands as root using sudo without entering a password. Consider the following example:
Analyzing this configuration using KIRA immediately highlights the main issue: by installing the sudo package and setting NOPASSWD: ALL for the solr, the user severely violates the principle of least privilege. The Solr platform does not require such broad privileges to run within a container; instead, they create an easy path for escalating to root.
In another example of an insecure configuration, NOPASSWD:ALL privileges are granted to a PostgreSQL database user, which is a direct and severe weakening of the access control policy. If an attacker gains the ability to execute code on behalf of the postgres user – through a vulnerability in a network service, an SQL injection, or by compromising of one of the processes – they will immediately and unconditionally be able to execute any commands on behalf of the root user. This is equivalent to the entire container running as root.
As a risk mitigation measure, we recommend completely removing this directive. The minimum necessary commands requiring privileges should be delegated on a case-by-case basis via sudoers with explicit specification of allowed executables and parameters, using NOPASSWD only as a last resort and for specific utilities.
Our AI assistant KIRA can identify even more complex insecure configurations, such as allowing passwordless sudo for the entire sudo group — by modifying existing rules.
The risk in this example is that the command replaces standard declarations requiring authentication with passwordless execution of all commands for any user within the sudo group – potentially including postgres, should it be assigned to that group. This expands the attack surface to all group members, turning each of them into a potential point for instant privilege escalation.
To mitigate the risks, we recommend not modifying the global sudoers policy, keeping the standard password requirement, or using a more secure escalation mechanism – such as gosu to run a specific process on behalf of another user without permanent privileges.
Insecure file permissions
Another common vector for privilege escalation is insecurely configured file and directory permissions. Most often, for convenience, container image authors use 777 permissions, which allow anyone – including unprivileged users – to freely create and delete files, as well as modify their contents. This can lead to both privilege escalation and the ability for an unprivileged attacker to delete or modify logs, among other undesirable consequences.
Consider the following command:
chmod 0777 /usr/share/cargo /usr/share/cargo/bin
The risk is that directories containing binary files and scripts will become writable by any container user. This allows a low-privileged attacker to replace utilities included in cargo or add new malicious executables. When these tools are subsequently invoked, especially as the root user or via sudo, the attacker’s code will execute with the inherited privileges of the calling process, leading directly to a local privilege escalation.
To mitigate the risks, you can set the minimum necessary permissions: chmod 0755 for directories and chmod 0755/0644 for the corresponding files. The owner should be root, and only the owner should be allowed to write. Do not use chmod 777 on any system paths.
Lack of integrity checks
Downloading software without verifying its integrity can make the infrastructure vulnerable to software tampering.
For example, this risk may arise when downloading a distribution via HTTP:
RUN /bin/sh -c wget -qO- ""<a href="http://acestream.org/downloads/linux/acestream_3.1.49_debian_9.9_x86_64.tar.gz">http://acestream.org/downloads/linux/acestream_3.1.49_debian_9.9_x86_64.tar.gz</a>"" | tar --extract --gzip -C /opt/acestream
Using HTTP without verifying the archive’s integrity creates conditions for a man-in-the-middle attack during the image build phase. An attacker controlling the communication channel or DNS can replace the archive with malicious content, which will compromise the container and the entire environment in which it runs.
To mitigate the risks, you can configure connections to web resources to use HTTPS only — if the resource supports this protocol. You can also download the archive without extracting it, compare its checksum (SHA256) with the checksum from a trusted source, and only then extract it. It is advisable to store the verified archive in an internal artifact repository to avoid direct downloads from the network.
There will still be a MitM risk even if certificate verification is disabled:
The absence of TLS certificate verification allows an attacker controlling the network segment to replace the downloaded ZIP archive with malicious content. Since the archive contains PHP code that will be executed by the web server, compromise during the build phase will result in the deployment of a backdoor or data leakage.
To mitigate the risks, remove the --no-check-certificate flag; after downloading, calculate the SHA256 hash of the archive and verify it against a known reference value (the release page or a local repository of trusted hashes). Additionally, consider using a fixed release (tag) rather than the floating 7.2-dev branch.
Conclusion
Docker containers have become a very popular means of deploying software, and attackers are by no means oblivious to this trend. They are rapidly adding software vulnerabilities and configuration errors to their arsenal and carrying out attacks on supply chains. They can compromise container infrastructure for a wide variety of purposes, from cryptocurrency mining to encrypting data for ransom or stealing information critical to the company.
Our research found that 64 out of 100 container images for popular applications contain critically vulnerable software, and only 10% are fully up to date. We also identified numerous insecure configurations, including passwords stored in plaintext in Dockerfiles and excessive privileges granted to users and processes.
To detect and prevent these threats, it is essential to strictly adhere to security measures: audit image configurations, securely manage secrets used in images, apply security updates in a timely manner, scan their contents for malware with every update, and follow industry-standard best practices for enhancing security.
This approach requires specialized solutions built to accommodate the unique characteristics of container environments. Kaspersky Container Security ensures the security of containerized applications at every stage of their lifecycle, from development to operation. The product protects an organization’s business processes, helps ensure compliance with industry standards and security regulations, and enables the implementation of secure software development practices.
When intimate images are shared without consent—whether real or AI-generated—the harm is immediate, deeply personal, and often long-lasting. It can affect someone’s sense of safety, dignity, and control, both online and offline. Protecting people from harms like non-consensual intimate imagery (NCII) has long been a priority for Microsoft. And as technology advances, our response continues to evolve to tackle very real challenges like the proliferation of highly realistic synthetic imagery. With the US Take It Down Act coming into force this month, establishing new federal protections against the spread of NCII, it’s important to share how we’re evolving our approach: making it easier to report harm, taking new steps to detect known NCII, and enabling more effective enforcement across our services.
Expanding protections across Microsoft services
Our goal is to make it simpler forindividuals, or their representatives, to report violativecontent to Microsoft. We have strengthened our global reporting processes for NCII with a more intuitive form, with clear options to describe harm, including both real and AI‑generated images. These changes are designed to ease the burden for people in a distressing moment and enable faster, more effective action by our teams. Microsoft’s NCII policy is applied consistently across real and synthetic content, recognizing that the harm to individualsis the same, regardless of how an image was created. To report content on Microsoftservices,hit “Report A Concern”or in the product where you encounterthe content.
We also want to proactively detect and prevent the spread of known NCII byworking with StopNCII.org,areporting platform that enables individuals to create a digital “fingerprint,” or hash, of their images. Two years ago, weprovided StopNCII.org witha new version of PhotoDNA that enables victims to create a hashwithout an image ever leaving their device. This can then be used by StopNCII.org partners to detect and remove matching NCII content across platforms, allowing industry to work together to prevent re-sharingand protect individuals’ privacy. We have been piloting the use of these hashes in Bing since September 2024.
We have now expanded our use of validated StopNCII.org hashes across Microsoft consumer services, including Teams Free, OneDrive, and Xbox. We will implement these changes carefully to advance effectiveness and accuracy—accelerating removals, automating where appropriate, maintaining human review for reported cases, and providing clear, accessible paths for users to appeal decisions.
Enhancing our collective response to this harm
No single company can address NCII alone. It requires coordination across industry, governments, and civil society. Microsoft will continue working with partners to improve shared tools and approaches that help prevent this content from spreading. We will also continue to advocate for clear, effective policies that protect victims, support innovation, and strengthen accountability across the ecosystem.
We will also continue to advocate for policies that support efforts to advance laws that prevent and deter image-based abuse. Microsoft advocated in support of the US Take It Down Act and welcomes the European Union’s work to strengthen protections against “nudification” apps, alongside global efforts to criminalize this misuse of technology. We are closely tracking Ofcom’s recent announcement that new measures will be required under the UK Online Safety Act to address illegal NCII harms. We believe our proactive work in this area will help us maintain trust with survivors, users, and regulators, among others.
Speed, clarity, and trust matter for people affected by intimate image abuse. When someone reaches out for help, we will strive to respond quickly, respectfully, and effectively. Our goal, though, is to invest in technologies and partnerships that reduce the likelihood of harm. We have joined forces with Childnet, a UK NGO that aims to safeguard children online, and created educational materials to prevent the misuse of AI to create intimate imagery among teens. These materials have now been released in the UK, as well as localized with partners in Singapore, South Korea, and Japan.
I am proud to learn from our digital safety team, which is carefully charting our path, and from the many industry and community leaders contributing to this work. This is an evolving challenge. We are committed to the journey, grounded by the voices of experts and survivors.
In 2025, we observed pervasive SSH tunnel activity, which has remained active into 2026, affecting many government organizations and commercial companies in Russia and Belarus. Behind some of this activity is Cloud Atlas, a group we have known since 2014. During our investigation, we identified new tools used by this group, as well as indicators of compromise.
The group is back to sending out archives containing malicious shortcuts that launch PowerShell scripts. This technique is employed in addition to the previously described use of malicious documents, which exploit an old vulnerability in the Microsoft Office Equation Editor process (CVE-2018-0802) to download and execute malicious code. We have observed the use of third-party public utilities (Tor/SSH/RevSocks) to gain a foothold in infected systems and create additional backup control channels.
Technical details
Initial infection
As for the primary compromise, Cloud Atlas remains consistent in using phishing. In the observed campaigns, the attackers emailed a ZIP archive containing an LNK file as an attachment.
Malware execution flow
Attackers use LNK shortcuts to covertly execute PowerShell scripts hosted on external resources. The command line of the shortcut:
Example of the PowerShell script downloaded and executed by the shortcut:
Example of the PowerShell script downloaded by the shortcut
Actions performed by the downloaded PowerShell:
Step
Action
Description
1
Drops “$temp\fixed.ps1”
Pre-staging: places the main payload locally in advance to ensure an execution capability independent of subsequent network connectivity or C2 availability.
2
Creates “Run” registry key “YandexBrowser_setup” for “$temp\fixed.ps1” startup
Early persistence: guarantees execution upon the next logon or reboot. If the script is interrupted during later stages, the payload will still activate automatically.
3
Downloads and drops “$temp\rar.zip”
Extracts “*.pdf” from the downloaded “$temp\rar.zip”
Payload delivery: retrieves the decoy archive from the remote server to prepare user-facing content for the distraction phase.
4
Extracts “*.pdf” from the downloaded “$temp\rar.zip”
Decoy preparation: unpacks the legitimate-looking document so it can be executed silently without requiring user interaction.
6
Opens extracted decoy document “*.pdf” with user’s default software
User distraction: opens a convincing document to maintain user engagement and creates a legitimate workflow appearance to buy additional 30–120 seconds for background operations.
6
Executes “taskkill.exe /F /Im winrar.exe”
Process concealment: terminates the archive extractor to prevent the user from seeing the archive contents or noticing unexpected file extraction activity.
7
Searches and deletes “rar.zip”, “*.pdf.zip” and “*.pdf.lnk”
Anti-forensic cleanup: removes the initial infection artifacts before activating the main payload, reducing the number of disk traces available for incident response or EDR correlation.
8
Executes “$temp\fixed.ps1”
Controlled execution: launches the main payload only after persistence is secured, the user is distracted, and access traces are cleaned up.
Fixed.ps1 (loader)
The primary purpose of the Fixed.ps1 script is to deliver and install subsequent malware onto the compromised system, specifically VBCloud and PowerShower. Fixed.ps1 establishes persistence (by adding itself to registry Run keys), creates a decoy for the user (by opening a PDF document), and executes the next stages of the attack.
Fixed.ps1::Payload (VBCloud dropper)
Example of the fixed.ps1::Payload (VBCloud dropper)
This module functions as a dropper for the VBCloud backdoor. It drops two files onto the infected machine:
video.vbs: the loader of the backdoor,VBCloud::Launcher. This is a VBScript that decrypts the contents of video.mds (typically using RC4 with a hardcoded key) and executes it in memory.
video.mds: the encrypted body of the backdoor, VBCloud::Backdoor. This is the main module that connects to a C2 server to receive additional scripts or execute built-in commands. This backdoor is designed to function as a stealer, specifically targeting files with extensions of interest (such as DOC, PDF, XLS) and exfiltrating them.
Fixed.ps1::Payload (PowerShower)
This module installs a second backdoor called PowerShower on the system. We don’t have the specific script that performs this installation, but we assume it’s performed by a script similar to fixed.ps1::Payload (VBCloud dropper).
Unlike VBCloud, which focuses on file theft, PowerShower is primarily used for network reconnaissance and lateral movement within the victim’s infrastructure. PowerShower can perform the following tasks:
Collect information about running processes, administrator groups, and domain controllers.
Download and execute PowerShell scripts from the C2 server.
Conduct “Kerberoasting” attacks (stealing password hashes of Active Directory accounts).
PowerShower is dropped onto the system via the path ‘C:\Users\[username]\Pictures\googleearth.ps1’.
Contents of the googleearth.ps1(PowerShower)
PowerShower::Payload (credential grabber)
PowerShower downloads an additional script for stealing credentials. It performs the following actions:
Creates a Volume Shadow Copy of the C:\ drive.
Copies the SAM (stores local user password hashes) and SECURITY system files from this shadow copy to C:\Users\Public\Documents\, disguising them as PDF files.
The script is launched in several stages. To execute with high privileges, the script uses a UAC bypass technique via fodhelper.exe (a built-in Windows utility). This allows PowerShell to run as an administrator without directly prompting the user, which could otherwise raise suspicion.
The full launch chain looks like this:
The full Base64-decoded script is given below.
Multi-user RDP by patching termsrv.dll
Moving laterally across the victim’s network, the attackers executed a suspicious PowerShell script named rdp_new.ps1 (MD5 1A11B26DD0261EF27A112CE8B361C247):
The script is designed to allow multiple RDP sessions in Windows 10 by patching the termsrv.dll file. Termsrv.dll is the core Windows library that enforces Remote Desktop Services rules.
By default, Windows limits the number of simultaneous RDP sessions. Removing this restriction allows attackers to operate on the machine in the background without disconnecting the legitimate user, thereby reducing the likelihood of detection.
At first, the script enables RDP on the firewall and downgrades the RDP security settings:
Before modifying termsrv.dll, the script takes ownership and assigns itself full permissions. Then the script finds the sequence of bytes 39 81 3C 06 00 00 ?? ?? ?? ?? ?? ?? and replaces it with B8 00 01 00 00 89 81 38 06 00 00 90. After these manipulations, the script restarts the RDP service.
Example of script
The patched version allows multiple concurrent logins so attackers can stay connected without disrupting the legitimate user, thereby reducing suspicion.
Reverse SSH tunneling
As mentioned above, during this wave of attacks, the adversaries widely deployed reverse SSH tunnels to many hosts of interest. The compromised machine initiates an SSH connection to an attacker-controlled server, which allows attackers to bypass standard firewall rules via establishing outbound connections.
That way, even if the primary backdoor is discovered, the attackers can maintain control through the SSH tunnel.
To install a reverse SSH tunnel on a victim’s host, the attackers run VBS scripts via PAExec or PsExec.
We’ve seen three types of scripts:
Gen.vbs (WriteToSchedulerGenerateKey.vbs) generates key for SSH tunnel.
Kill.vbs (WriteToSchedulerKillSSH.vbs) stops reverse SSH tunnel via taskkill.exe.
To achieve persistence, the attackers added a new scheduled task in Windows:
In some cases, before establishing a reverse SSH tunnel, attackers set new access permissions to the folder containing the private key to prevent the legitimate user or system administrators from easily accessing or modifying it:
Patched OpenSSH
Some OpenSSH binaries used by the attackers had their imports modified. Instead of libcrypto.dll, the SSH executable imports syruntime.dll, which was placed in the same folder as the binary. This was likely done to evade detection and ensure stealth.
In addition, we found a portable version of OpenSSH, presumably compiled by the adversaries:
RevSocks
In addition to Reverse SSH tunnels, the attackers installed RevSocks using the same infrastructure. RevSocks is an alternative tool to SSH for establishing tunnels and proxy connections, written in Golang. This tool allows direct connection to workstations on the local network. It also allows attackers to gain access to other segments of the victim’s network by using the machine as a gateway. In some cases, C2 addresses were hardcoded into the binary; in other cases, the C2 was passed in command line arguments.
There were also reverse SOCKS samples with hardcoded C2 addresses:
Tor tunneling
To maintain control over the compromised host, the Tor network was used in some cases. A minimal set of a Tor executable and configuration files, necessary for launching HiddenService, was copied to the system directories of infected devices. The name of the Tor Browser executable file was modified. As a result, the infected machine was accessible via RDP from the Tor network when accessing the generated .onion domain.
Below is an example of a configuration file for routing connections from Tor to RDP ports on the local network, as well as example command lines for logging into Tor.
Example of TOR configuration file
PowerCloud
We analyzed a new Cloud Atlas tool, PowerCloud. It collects user data with administrator privileges and writes this information to Google Sheets in Base64 format.
The tool represents an obfuscated PowerShell script. In most cases, it is packaged into an executable file using the PS2EXE utility, but we have also encountered variants in the form of a separate PowerShell script.
To find administrators on the victim host, the tool executes the following command:
This information is appended with the computer name and current date, the data is encoded in base64, and then the collected data is added to an existing Google Sheet.
PowerCloud script
Browser checker
Additionally, the attackers used another PowerShell script (MD5 5329F7BFF9D0D5DB28821B86C26D628F), compiled into an executable file via PS2EXE, which checks whether browser processes (Chrome, Edge, Firefox, and other) are running. This helps detect when the user is working on the computer. This can be used to choose the optimal time for conducting attacks (for example, when the user is away but their browser is still open) or simply to gather information about the victim’s habits.
The information about running browsers is written to a log file on the local host.
Fragment of the deobfuscated script
Victims
According to our telemetry, in late 2025 and early 2026, the identified targets of the described malicious activities are located in Russia and Belarus. The targeted industries mostly include government agencies and diplomatic entities.
We attribute the activity described in this report to the Cloud Atlas APT group with a high degree of confidence. The group used techniques and tools described previously, such as the initial access vector, the Python script for information gathering, and the Tor application for forwarding ports to the Tor network. The victim profile and geography also matches the Cloud Atlas targets.
We couldn’t help but notice some parallels with recent Head Mare activity. The PhantomHeart backdoor (available in Russian only), attributed to Head Mare and used to create an SSH tunnel, was placed in directories actively used by Cloud Atlas:
C:\Windows\ime
C:\Windows\System32\ime
C:\Windows\pla
C:\Windows\inf
C:\Windows\migration
C:\Windows\System32\timecontrolsvc
C:\Windows\SKB
However, TTPs are still differentiated.
Conclusion
For more than ten years, the Cloud Atlas group has continued its activities and expanded its arsenal. Over the course of last year, many targeted campaigns in general were found to employ ReverseSocks, SSH and Tor, and the use of these utilities was no exception for Cloud Atlas. Creating such backup control channels using publicly available utilities significantly complicates the complete disruption of attackers’ actions on compromised systems. We will continue to closely monitor the group’s activity and describe their new tools and techniques.
Every day, we decide what software to trust in seconds guided by simple labels such as “verified,” “secure,” and “safe to install.” The problem is that those signs can be manipulated.
Today, Microsoft unsealed a legal case in the US District Court for the Southern District of New York targeting a cybercrime service known as Fox Tempest, which, since May 2025, has enabled cybercriminals to disguise malware as legitimate software. The malware-signing-as-a-service (MSaaS) worked by fraudulently accessing and abusing code signing tools, such as Microsoft’s Artifact Signing, a system designed to verify that software is legitimate and hasn’t been tampered with. Cybercriminals used the service to deliver malware and enable ransomware and other attacks, infecting thousands of machines and compromising networks worldwide.
For the first time, Microsoft is taking public action against a powerful, but often unseen, enabler within the cybercrime ecosystem, targeting how cybercriminals prepare and employ techniques to optimize their rate of success. To disrupt the service, we seized Fox Tempest’s website signspace[.]cloud, took offline hundreds of the virtual machines running the operation, and blocked access to a site hosting the underlying code. This action builds upon persistent internal efforts to revoke fraudulently obtained code‑signing certificates and enhance our defenses and employ new security features to detect and thwart such malicious activity. It’s already having an impact: cybercriminals are complaining about challenges accessing the current service.
Our impact extends beyond one actor. The lawsuit targets Fox Tempest’s infrastructure and also names Vanilla Tempest as a co-conspirator, a prominent ransomware group that used the service to deploy malware like Oyster, Lumma Stealer, and Vidar, and ransomware, including Rhysida, in multiple recent cyberattacks. Vanilla Tempest has targeted schools, hospitals, and other critical organizations worldwide, while Rhysida, a highly evolved ransomware variant that both encrypts files and steals data, often used for double extortion, has been used by various actors in numerous high-profile attacks globally, including to steal and leak internal documents from the British Library and to disrupt operations at Seattle-Tacoma International Airport. Microsoft’s investigation further linked Fox Tempest to various additional ransomware affiliates and families, including INC, Qilin, Akira, and others.
More broadly, this case points to how cybercrime is changing. What once required a single group to carry out an attack from start to finish is now broken into a modular ecosystem where services are bought and sold and work interchangeably with one another. Some services are inexpensive and widely used. Others, like Fox Tempest, are highly specialized and expensive because they remove friction or bypass obstacles that make attacks fail, making them both more reliable and harder to detect. As seen with Fox Tempest, when these services are combined with AI-powered tactics, attacks can scale more easily, reaching more people and becoming more convincing.
This kind of abuse isn’t new, but it is evolving
Illicit code-signing certificates have been sold and trafficked for more than a decade. That includes its use by nation-state actors to target critical infrastructure organizations in Europe. What’s changed is how this activity is marketed, packaged, and sold as a service, along with the scale at which it is now used across ransomware campaigns. Instead of buying certificates one-by-one, criminals upload their malware to a service that signs it for them.
What also makes this model notable is the level of investment. Unlike lower-cost services like RedVDS, a cybercriminal infrastructure provider that costs as little as $24 per month, which Microsoft disrupted earlier this year, Fox Tempest shows that more sophisticated actors are willing to pay thousands of dollars for advanced capabilities that make attacks easier to carry out, harder to detect, and more likely to succeed.
How Fox Tempest sold “legitimacy” at scale
Fox Tempest’s business model was straightforward: sell fraudulent code-signing capability, let others package malware, and enable attacks downstream. The model has generated millions in proceeds, demonstrating significant financial profit.
Behind the scenes, the operators built access at scale. Using fabricated identities and impersonating legitimate organizations, they created hundreds of fraudulent Microsoft accounts to obtain real code-signing credentials in volume. Customers who paid for Fox Tempest’s services could then upload malicious files via an online portal for them to be signed using Fox Tempest-controlled certificates. Cybercriminals paid thousands of dollars for the service, reflecting how valuable this capability was.
Fox Tempest’s pricing model form and Telegram channel where you could purchase the service. The more you pay, the quicker you get access to the service.
Once signed, their malware appeared legitimate. Attackers then distributed the signed malware through tactics such as search manipulation and malicious ads, where users are more likely to trust what they encounter. AI then helped generate and refine these campaigns to reach a broader audience.
How code-signed malware appears in search results.Fake Microsoft Teams download page and delivery mechanism for disguised code-signed malware
That changed the odds. Malicious software that should have been blocked or flagged by antivirus and other safeguards was more likely to be opened, allowed to run, or pass security checks—essentially allowing malware to hide in plain sight. Instead of forcing their way in, attackers could slip through the front door by masquerading as a welcomed guest.
An overview of malware‑signing‑as‑a‑service.
As Microsoft disabled fraudulent accounts, revoked fraudulently obtained certificates and introduced enhanced protections, the Fox Tempest operators continually adapted. In February 2026, they ultimately shifted to networks of third-party-hosted virtual machines to maintain and scale operations. That kind of rapid change is part of the model: these services evolve quickly in response to pressure and friction. In fact, Microsoft has observed further adaptations in response to our layered disruption efforts, with Fox Tempest attempting to shift operations and customers to another code-signing service.
Fox Tempest’s response to the disruptive efforts—translated from Russian by a third-party partner
In addition to seizing the core infrastructure behind the operation and degrading its ability to function at scale, we have taken further steps to prevent similar abuse, removing fraudulent accounts, strengthening verification, and limiting how this type of access can be reused. More technical details on the operation and the steps we’re taking to prevent similar abuse are available in this Microsoft Threat Intelligence blog.
Cutting off a critical enabler of cybercrime
This action wasn’t about stopping one actor. It sought to strategically neutralize a vital service that many attackers, particularly ransomware groups, rely on. When legitimate code signing services are weaponized, everything downstream gets easier: malware looks legitimate, security warnings are less likely to trigger, and attacks are more likely to succeed. Degrading that capability adds friction and forces a reset. The success rates of attacks decrease, and attackers have to rebuild, find new ways in, and accept more risk with each attempt—driving up both the cost and the time required to operate.
Importantly, disruption actions don’t happen in isolation and are never one-and- done. Collaboration is critical, as different organizations and sectors have visibility into different parts of the cybercrime ecosystem. In this case, we are working closely with cybersecurity company Resecurity, whose insights help us better understand how Fox Tempest operates. We are also collaborating closely with Europol’s European Cybercrime Centre (EC3) and the Federal Bureau of Investigation (FBI). As we’ve seen in previous efforts, we expect actors to try to rebuild. Collectively, we will continue to take action and keep the pressure on. That also means strengthening the code signing ecosystem through intelligence sharing and partnering with other code signing services, so it’s harder for malicious actors to regain that ground in the first place.
When attackers can make malicious software look legitimate, it undermines how people and systems decide what’s safe. Disrupting that capability is key to raising the cost of cybercrime. As threats evolve, the Microsoft Digital Crimes Unit will continue working with partners across industry and law enforcement to persistently identify and cut off the services that enable them.
For more than a decade, the Microsoft Digital Crimes Unit (DCU) has persistently disrupted cybercrime and nation-state threats targeting people, organizations, and critical infrastructure. Explore major disruptions—and the ongoing cases and operations behind them here: Disrupting cyberthreats since 2008 | Microsoft
Modern phishing campaigns are no longer trying to convince users. They are trying to outrun them. By forcing an automatic progression from click to download, attackers eliminate the moment of hesitation entirely by forcing files to download instantly using trusted cloud platforms like Dropbox and Google Drive.
Detecting when these legitimate SaaS auto-download features are being weaponized is an immense challenge for traditional defenses. This is exactly where Cortex® Email Security steps in. By combining deep static analysis with advanced behavioral intelligence, the module can distinguish in this attack between a benign file share and a malicious, forced-momentum trigger.
This technical detection is vital because while the autodownload method is the primary cause of infection, its effectiveness relies on a clever strategy, using a wide range of changing social engineering lures. By alternating between lures like 'Invoices' or 'Quotes,' attackers rotate their themes to catch a wider variety of victims. This strategy allows attackers to convert trusted email links into rapid, dangerous file executions that effectively evade standard security measures.
How Forced Momentum Drives Auto-Downloads
The core of this attack leverages the infrastructure of real SaaS providers to eliminate the user's preview buffer. Typically, cloud sharing directs users to a webpage for file examination. In this campaign, however, forced-download parameters (such as ?dl=1 on Dropbox) are used instead. To ensure the victim executes the file once it lands on their machine, attackers hide the danger behind "visual anchors." By using double extensions like PDF and .EXE, the threat actor exploits default settings in certain operating systems that hide known extensions. The user's eyes stop at the familiar ".PDF" or ".ZIP," leading them to believe the file is a harmless document rather than a malicious executable.
When the targeted victim clicks the link in the email, it triggers an immediate file download in the browser, effectively bypassing any intermediary steps.
Attack Flow: From Email to Execution
The Bait: A highly personalized email arrives, using a trusted cloud link (like Dropbox) to lower the victim's guard.
The Trap: Clicking the link skips the usual "preview" screen and instantly drops a file onto the victim's computer.
The Disguise: The file is cleverly named to look like a safe PDF or document, hiding its true identity as a harmful program.
The Lock: In many cases, the attacker ensures only the intended victim can open the file, preventing security tools from scanning it first.
The Takeover: Once the victim opens the file, the attacker gains remote access to the system.
Multi-step attack flow, starting from targeted phishing email, to bypass security and establish persistence.
The Library of Lures Strategy
To fuel the autodownload machine, attackers employ a flexible strategy by switching between various social engineering themes. This spear phishing campaign targets specific inboxes, such as "Orders," to exploit professional routines. Some common lures found in this campaign include:
Financial Urgency – Fake "Invoices" or "Receipts" that induce anxiety. These often set close-day payment deadlines, pressuring recipients to click quickly.
Business Operations – "Quote Requests" or "Purchase Orders" that exploit professional habits.
Deceptive Naming – Concealing the download as a safe document, using display text like "invoice.pdf" in the email body to hide the underlying Dropbox URL.
Government Domain Impersonation
Attackers often leverage high-authority lures designed to paralyze a user's critical thinking. In one sophisticated wave, we observed threats impersonating a government entity by exploiting the high-reputation, official government domain. By borrowing the reputational authority associated with official infrastructure, the attacker successfully maneuvered an "Unidentified Payment Notice" past standard "Untrusted Sender" filters. To the recipient, the email carries the weight of a sanctioned document. Fearing legal or financial ramifications, they feel a heightened sense of urgency to click "View Invoice" to resolve the issue immediately.
Employee Impersonation
When government authority isn’t the angle, attackers shift to impersonating internal staff. In one case, the sender’s display name was spoofed to match a real employee in the target organization. Attackers rely on a “Momentum of Trust” tied to familiar names to overwhelm user judgment. Even when a generic Gmail address is used, users, especially those on mobile devices, rarely pause to check the underlying headers.
Internal Trust Amplification ("Human Relay")
The most effective aspect of this campaign occurs through Internal Laundering, where the threat shifts from external suspicion to a trusted internal message. This was observed when a Finance Department employee received a "Quote Analysis" file and, believing it to be a valid inquiry, mistakenly forwarded the link to the Procurement department.
At that stage, the attack no longer depended on deception, it propagated through trusted human workflows. These various tactics illustrate the sophistication and adaptability of phishing campaigns and highlight the importance of vigilance in email security.
How We Uncovered a Single Threat Actor
Although the lures appeared diverse, a deeper technical analysis revealed that they were all orchestrated by a single, coordinated threat actor.
By mapping the campaign, we uncovered a significant pattern: Each autodownload link pointed to a different file hash to evade signature detection, but all unique executables were ultimately associated with the same parent installer hash.
The file was identified as a specific Remote Monitoring and Management (RMM) executable, an administrative software used to manage computers remotely. Because RMM tools are legitimate, they often trigger fewer alerts than traditional Trojans. This allows the attacker to maintain persistent access under the guise of “authorized” system activity.
How Cortex Email Security Addresses the Threat
To defend against a campaign that emphasizes speed and rotation, behavioral analysis is essential.
The Cortex® Email Security Module addresses this threat:
Advanced URL Analysis – Detection of forced-download parameters, combined with delivery of high-risk files via URLs.
Deep Metadata Correlation– Correlating sender identity with behavioral anomalies to flag threats that traditional scanners might overlook.
The security engine triggers an alert by synthesizing LLM analysis with real-time email telemetry, global threat intelligence and behavioral signals.
Securing the Click
The combination of autodownload links and rotating lures is crafted to exploit user momentum and the "psychology of trust."
This campaign represents a shift from deception to acceleration. Attackers no longer need perfect lures, they only need to remove friction. Defenders must evolve accordingly, focusing not only on what a link is, but on what it forces a user to do.
Palo Alto Networks Cortex Advanced Email Security was built for this evolution. By moving beyond static file analysis to identify the behavioral "red flags" of autodownloads and forced-momentum URLs, we provide the visibility needed to stop these attacks before they reach the device.
The module examines email metadata, content, and behavior to uncover hidden malicious intent and sophisticated impersonation, including AI-crafted threats. By assigning precise risk scores to every detection, the system filters out the noise, allowing analysts to move past alert fatigue and focus on the most critical threats first.
Why is the "Auto-Download" parameter so effective? It removes the "moment of doubt." By bypassing the preview page, the attacker forces the file onto the computer instantly, prompting the user to "Open" it out of habit.
How does the use of rotating lures benefit the attacker? It maximizes both psychological and technical success. People have different "blind spots" (e.g., finance professionals are likely to click on invoices), and variety increases the chances of finding a template that can bypass specific customers' security filters.
Why might a sandbox fail to catch the malicious file? Because the link was "Identity-Bound." To the scanner, the link appeared to lead to a harmless error page (cloaking), resulting in a false negative.
Cloaking involves showing different content to security scanners than what is presented to the victim. By using Identity-Bound access, the file only reveals itself to the intended target.
When a major cyber incident hits, the first decisions aren’t technical—they’re human. Who takes the lead? How quickly can information be shared? When should governments step in, and how do you protect public trust while keeping essential services running?
These questions are at the heart of Microsoft’s Advancing Regional Cybersecurity (ARC) initiative, launched in 2025 to help governments strengthen cyber preparedness through practical, public-private collaboration. Today, we’re sharing the first tangible output of that work: the ARC Kenya Exercise Report & Toolkit, developed through a tabletop exercise held in Nairobi in December 2025.
Developed with Kenya’s National Computer and Cybercrime Coordination Committee (NC4) and RiskSight, the toolkit is a practical planning resource designed to help government and cross-sector leaders prepare for cyber crises before they occur. It is grounded in real conversations among leaders from government, regulators, critical infrastructure operators, law enforcement, academia, and the private sector working through what a serious cyber incident would demand of them, together.
Stress‑testing decisions before a crisis hits
The ambition of the “Silicon Savannah” makes Kenya a compelling setting for this work. Its digital economy is expanding rapidly—from mobile‑first financial services to cloud‑enabled public infrastructure—positioning the country as a regional technology leader. But rapid digital growth also brings increased exposure to more sophisticated cyber threats. As systems become more interconnected, a serious cyber incident can quickly disrupt essential services, undermine public trust, and threaten economic stability.
Kenya’s approach recognizes this reality and reflects a critical principle: cybersecurity is not separate from innovation; it is one of the conditions that allows digital transformation to scale safely. The ARC initiative embodies this philosophy and helps decision makers confront the practical realities of coordination, escalation, and response in this complex environment.
This is exactly what the ARC Kenya tabletop exercise was designed to do. The objective was not to test tools but to stress‑test decision making under pressure. Participants were challenged with complex scenarios—including AI‑enabled breaches, ransomware attacks, and infrastructure‑level disruptions. The focus was not on technical fixes but on leadership clarity, cross‑agency coordination, and real‑time decision making in high‑pressure environments.
The outcome was both a roadmap for the unknown and a clear recognition of the need for shared expectations before a crisis begins—particularly around leadership and authority, trusted information sharing channels, and agreed response frameworks. These gaps, identified by participants themselves, now form the backbone of the ARC Kenya Toolkit.
What the ARC Kenya toolkit delivers
The toolkit translates the lessons of the exercise into concrete actions that leaders can take now—before the next incident occurs. It also serves as a practical and specific 12‑month roadmap for strengthening Kenya’s cyber preparedness, moving from lessons identified to durable, institutional capability. Specifically, the toolkit provides recommendations to:
Clarify national leadership during major cyber incidents, enabling government, regulators, law enforcement, and critical infrastructure operators to coordinate more quickly, with fewer gaps and overlaps.
Establish practical, standards‑aligned incident response models for the entire country, including priority playbooks that teams can train on and execute consistently.
Strengthen operational readiness across sectors, with better coordination between security operations centers (SOCs), clearer escalation thresholds, and more reliable incident reporting pathways.
Deepen trusted information sharing and public‑private collaboration through common handling rules, safer “good‑faith” reporting mechanisms, and regular joint exercises to build muscle memory before a crisis.
Taken together, these elements enable leaders not only to respond more effectively to cyber incidents, but to institutionalize preparedness, coordination, and resilience across the national cyber ecosystem. For African countries more broadly, the model also offers a practical pathway to strengthen regional cyber cooperation—by aligning expectations around escalation, information sharing, and public‑private coordination before a cross‑border incident occurs. By translating high‑level principles into practical, repeatable approaches to crisis readiness, the toolkit underscores the value of trusted international partnerships and alignment with global norms for responsible state behavior in cyberspace.
Why Kenya’s approach matters beyond its borders
Many countries across the Global South are grappling with similar challenges: fragmented ownership of critical infrastructure, uneven cyber capacity across sectors, and the need to coordinate rapidly under pressure. While firmly grounded in Kenya’s national context, the lessons from ARC Kenya are therefore intentionally designed to resonate far beyond its borders and to be highly transferable.
Importantly, this work does not end in Kenya. We are already building on these lessons through ARC engagements in other regions, including a new workstream in Mexico, applying the same approach to strengthen preparedness, coordination, and resilience across different national contexts.
By design, the ARC initiative is not simply a record of a single exercise. It is a foundation others can build on—at a national or regional level—offering leaders a practical starting point to turn shared responsibility into sustained capability.
For more than a decade, the Microsoft Digital Crimes Unit (DCU) has persistently disrupted cybercrime and nation-state threats targeting people, organizations, and critical infrastructure. Explore major disruptions—and the ongoing cases and operations behind them here: Disrupting cyberthreats since 2008 | Microsoft
Cybersecurity is at a turning point. Advanced AI models are dramatically accelerating vulnerability discovery and creating conditions ripe for exploitation, underscored by the announcement of Claude Mythos Preview. This marks a shift, and whether this technology will favor defenders or attackers will depend on the choices we make now.
With the right safeguards, these capabilities can help trusted defenders identify and fix vulnerabilities across critical systems in hospitals, power grids, water, and telecommunications. Released irresponsibly or not properly secured, however, those same capabilities could be abused by malicious actors, threatening the foundations of our digital ecosystem.
Much of the discussion has rightly focused on risks. As advanced AI models speed up the discovery of vulnerabilities, the way we fix them must speed up too. That means stronger pre-deployment risk assessments and close collaboration between governments, frontier AI developers, software providers, and the broader ecosystem to ensure these tools reduce, rather than increase, cyber risk. This is particularly important as AI systems themselves have become high‑value targets, requiring stronger protection of models, systems, data, and underlying infrastructure.
This is ultimately an international challenge. Neither software supply chains nor threat actors stop at borders. Neither can our response. Meeting this moment will require shared approaches across countries, sectors, and systems—rooted in trust, shared standards, resilience, and responsible use.
This moment is also an opportunity. Security has been and remains the top priority at Microsoft. Over the last two years, through our Secure Future Initiative, we have strengthened our security foundations for this age of AI, in part by using AI to accelerate vulnerability discovery and remediation. We have also invested in fundamental AI for security research, including the development of open-source industry benchmarks that can be used to evaluate whether models are ready for real-world security work. We are accelerating that work through deeper public-private collaboration and in partnership with AI, including Anthropic’s Project Glasswing and OpenAI’s Trusted Access for Cyber program.
Securing our digital ecosystem with next‑generation AI is within reach but is not automatic.
Building secure foundations for the era of frontier AI
Ensuring advanced AI technologies are used to strengthen cybersecurity requires deliberate and urgent action. We are sharing the following recommendations as practical steps governments, industry, and the broader ecosystem can take to ensure these tools, often referred to as “frontier AI”, reinforce the security foundations on which digital societies depend. And we hope to continue to partner with model providers, industry and government so we can work together to improve security outcomes for all.
1. Reinforce core cybersecurity practices
Advanced AI can strengthen cybersecurity only when strong, consistent cyber hygiene is already in place. As frontier AI accelerates vulnerability discovery and response, core practices such as rapid patching, access control, and system resilience become more critical, not less.
Security gains in the frontier AI era depend on close coordination between technology providers advancing new capabilities and the organizations responsible for operating, updating, and securing real‑world systems. Without this interdependence, advanced AI cannot deliver durable improvements in security. No organization can solve these cybersecurity problems alone.
That is why sustained investment in what we know works remains essential: secure‑by‑design product lifecycles, Zero Trust architectures, multi‑factor authentication, least‑privileged access, and ongoing security training. Broad adoption and harmonization of established cybersecurity frameworks to ensure consistent resilience across AI‑enabled systems. Trusted cloud environments that enable these practices at scale, supporting secure data handling, continuous patching, and the secure deployment of AI‑enabled tools for defenders.
2. Release advanced capabilities responsibly
As frontier AI systems gain reasoning, coding, and agentic capabilities, some of the most serious security risks arise before deployment, including realistic misuse involving multi‑step reasoning, tool use, and reconnaissance. Technical safety benchmarks remain important, but they are insufficient without rigorous, real‑world testing.
As a result, governments are increasingly establishing pre‑deployment evaluations that combine technical testing with threat modeling. These assessments are most effective when frontier developers work closely with organizations that track national‑security risks. Investing in secure evaluation environments and modern testing methods can help governments keep pace as capabilities advance.
Responsible release practices, including phased and controlled access, are a critical extension of this approach. Our work with Anthropic in Project Glasswing offers one practical model, enabling trusted defenders to evaluate advanced capabilities in constrained settings prior to broader release. Similarly, OpenAI and Microsoft work closely through Trusted Access for Cyber program, and we already support OpenAI’s use of scoped, early deployments for safety and security testing.
AI is changing both the speed of vulnerability discovery and what constitutes meaningful security risk. Faster discovery only improves security if triage, validation, and remediation can keep up.
As AI accelerates discovery, vulnerability management must shift from tracking raw volume to reducing real‑world risk. That means prioritizing vulnerabilities that are genuinely exploitable, assigning clear responsibility for triage and remediation, and using phased, risk‑based disclosure when private coordination improves safety. Above all, systems must be designed around validation and realistic remediation capacity, not the assumption that more findings automatically lead to better security.
Developers of frontier AI models should embed vulnerability coordination and disclosure directly into responsible‑release frameworks. And work with governments and industry to ensure findings are routed to the right owners, acted on early, and supported by clear coordination pathways.
4. Fix faster: Strengthen and accelerate response and remediation
As AI accelerates vulnerability discovery, remediation must keep pace. Initiatives such as DARPA’s AI Cyber Challenge show how AI can help both find and fix flaws in open‑source software. Hardening defenses requires investment not just in detection tools but in the people, processes, and infrastructure responsible for fixing vulnerabilities, especially in critical sectors.
Much of the software underpinning critical infrastructure relies on open‑source components maintained by small teams or volunteers with limited security capacity. A surge in AI‑enabled discovery risks overwhelming existing triage and disclosure processes. Efforts such as the GitHub Secure Open Source Fund, alongside investments by Microsoft and others through the Linux Foundation, Alpha‑Omega, and OpenSSF, are helping maintainers adapt in ways that are practical and aligned with existing workflows.
Governments should treat remediation capacity as a core resilience priority, including sustained investment in and support for maintainers, surge capacity during large discovery events, and modernized disclosure pathways—recognizing that effective remediation still largely depends on human judgment, coordination, and time.
5. Advance AI security internationally
AI security is essential to deploy AI at scale. Because AI systems, supply chains, and the risks they introduce operate across borders, national approaches alone will not be sufficient.
Governments and industry should work together to build interoperable international foundations for AI security, including risk evaluation, coordinated vulnerability disclosure, and information sharing. Priorities should include strengthening the defensive use of AI, preventing misuse through shared norms and safeguards, and securing AI systems- and the AI technology stack.
Global participation is critical. Countries and organizations with limited cybersecurity resources or legacy infrastructure are often the most exposed. International cooperation should prioritize capacity‑building, ensuring that the security benefits of AI are realized broadly and equitably.
AI security is not just a safeguard; it is an enabler for innovation and growth. By acting collectively and moving quickly, governments and industry can strengthen global digital resilience and unlock the trusted adoption of AI across economies, critical infrastructure, and public services.
Meeting the moment: Usefrontier AI capabilities to build trust and confidence
Meeting this moment is ultimately about trust: not in any single technology or provider, but in our collective ability to introduce advanced AI responsibly.
Used deliberately and built on strong security foundations, these capabilities can strengthen cybersecurity and reinforce confidence in the systems society depends on. The choice is not between innovation and security but whether we enable them to reinforce one another.
That outcome is within reach. With governments, industry, and infrastructure operators aligned, advanced AI can be deployed in ways that match real‑world defensive capacity and support trusted, lawful action. Done right and working together, frontier AI can help protect the digital infrastructure that underpins modern life and build lasting confidence in its resilience.
For more than a decade, the Microsoft Digital Crimes Unit (DCU) has persistently disrupted cybercrime and nation-state threats targeting people, organizations, and critical infrastructure. Explore major disruptions—and the ongoing cases and operations behind them here: Disrupting cyberthreats since 2008 | Microsoft
Palo Alto Networks recently joined the DNS-OARC community as a Platinum Member. Together, our organizations share a commitment to advancing collaboration in research and operational excellence across the global DNS ecosystem. DNS is critical to both internet infrastructure and security, and this collaboration facilitates the sharing of real-world insights among researchers and practitioners.
Our Contribution
We help organizations secure their digital environment with a comprehensive portfolio of cybersecurity solutions spanning Network, Cloud, Security Operations, AI and Identity. Trusted by more than 70,000 customers worldwide and informed by Unit 42® Threat Intelligence, their AI-driven platforms help organizations reduce complexity, modernize with confidence, and securely enable innovation.
As a Platinum Member, our subject matter experts will actively participate in the DNS-OARC community by engaging in discussions and contributing to research on evolving DNS threats and network challenges. The growing intersection of DNS and security makes access to intelligence and experience increasingly important. It strengthens the community’s ability to respond to emerging challenges and improves resilience across the internet.
Through our participation, our customers will gain stronger protection informed by community-driven intelligence and real-world operational insight. These learnings are continuously integrated into our threat intelligence and security capabilities. Our participation signals our support for DNS-OARC’s mission of fostering open dialogue and shared learning across the DNS ecosystem. This collaboration helps bridge DNS operations with broader security practices, improving coordination between operators, researchers and security practitioners.
Our Commitment to the DNS-OARC and Global Communities
Collaboration between our organizations strengthens the connection among DNS operations and modern security practices by bringing together operational insight and a global community dedicated to advancing the internet’s resilience.
For the DNS-OARC community, our commitment enhances knowledge sharing around evolving DNS threats, large-scale network operations and practical approaches to emerging challenges.
For organizations and customers, it reinforces a stronger alignment between DNS infrastructure and security, expands access to community-driven intelligence and supports more resilient, well-informed defenses.
Tong Zhao, Senior Manager of DNS Security Engineering, Palo Alto Networks:
We recognize the critical role of DNS-OARC in DNS operations and research. The teams from Palo Alto Networks believe that our DNS-OARC membership aligns perfectly with our goals. We are eager to participate in and contribute to the DNS community.
Our partnership with the DNC-OARC highlights the value of open collaboration in helping both the community and its participants stay ahead of an increasingly complex threat landscape. To learn more about how our expertise and insights support DNS-OARC’s mission to improve the security and stability of the internet’s DNS, visit DNS-OARC.
In the race to digitise public services, the UK’s digital estate has grown into a vast, borderless ecosystem that manual audits can no longer track. For UK Government departments, local authorities and NHS trusts, it is a sprawling, shifting landscape of cloud workloads, legacy infrastructure, shadow IT and third-party supplier connections.
This complexity creates blind spots that modern threats exploit. Recognising this vulnerability, the UK Government is moving toward a secure-by-design digital infrastructure, with the 2026 Government Cyber Action Plan (GCAP) setting a high bar for resilience. A central theme of the GCAP is the urgent need for the government to have better visibility of cyber security and resilience risk. Fundamentally, organisations cannot secure what they cannot see. As the GCAP explicitly states, the Government will use “data sources from across the government to truly understand government-wide and departmental cyber risks.”
The Challenge: Visibility in a “Landscape”
Many public sector organisations rely on a complex web of spreadsheets, data calls, legacy tools and manually curated lists to create an inventory of their internet-connected assets. But attackers do not look at an organisation's internal lists; they scan the internet for what they have forgotten to secure. Whether it is an unpatched server from a legacy project or a misconfigured database in a department, these "unknown unknowns" are the primary entry points for attackers.
The Strategic Mission: Empowering the Public Sector and Critical Industries
Palo Alto Networks Cortex Xpanse® is an active external attack surface management (EASM) solution that provides an outside-in view of organisations' entire digital footprint. It helps leaders meet national resilience goals:
Comprehensive, Continuous Visibility: Xpanse scans the global internet space continuously and identifies every asset associated with an organisation, without requiring software agents to be installed on your systems.
Accelerate Response: Leveraging automation, the solution streamlines response processes and enhances collaboration across dispersed teams from the sharing of findings to tracking actions and remediation.
Supply Chain Integrity: Inline with the new Cyber Security and Resilience Bill (bringing managed service providers and critical third parties into scope), Xpanse allows organisations to assess the internet-facing security posture of third-party partners and suppliers, ensuring a weak link elsewhere doesn't compromise the broader mission.
Alignment with GovAssure: Xpanse provides a consolidated risk profile and inventory for all internet-facing and cloud assets required for GovAssure assessments, turning a manual, months-long audit process into a continuous, data-driven cycle.
Investment prioritisation: Xpanse provides that much needed visibility to help executive committees and boards prioritise investment decisions on legacy IT and technical debt.
Aligning to National Cybersecurity Centre (NCSC) Guidance
Palo Alto Networks Cortex Xpanse aligns with the National Cyber Security Centre (NCSC) external attack surface management (EASM) buyer's guide by providing automated discovery, continuous monitoring and risk prioritisation of internet-facing assets. It replaces manual, point-in-time audits with a proactive, agentless solution. By automating the discovery of all internet-accessible assets (including shadow IT and unmanaged cloud operations) the platform fulfills the NCSC’s core requirement for continuous global monitoring and rapid attribution. This data-driven approach allows for the automated prioritisation of critical exposures, such as RDP, and integrates seamlessly with multiple third-party automation and visualisation tools, including Cortex XSOAR® and XSIAM, to accelerate remediation with national incident response standards.
In fact, with Palo Alto Networks deployment of Cortex Xpanse, we were able to achieve a 95% reduction in external vulnerability management spending across more than 700,000 cloud instances, while improving coverage and outcomes.
Palo Alto Networks Cortex Xpanse Capabilities
Discover Assets: Leveraging organisations' known asset inventory and other data points, Xpanse performs continual, automated discovery of all internet-accessible assets, effectively eliminating blind spots created by shadow IT and unmanaged cloud operations.
Obtain Information: Always-on, continuous monitoring of an organisation's entire attack surface through daily scans of the global IP address space, ensuring that newly exposed services are identified quickly and accurately.
Perform Analysis: Xpanse automates and prioritises alerts on all identified risks by severity, enabling organisations to optimise resolution and risk management, allowing teams to properly allocate resources and focus on the most critical risks to the organisation.
Display Information and Provide Advice: Leveraging a unified view of the internet facing and cloud-based estate, Xpanse provides specific resolver guidance for every identified issue, supporting and monitoring automated resolution through multiple native integrations.
Monitor Risk: Always on, discreet continual monitoring provides an independent real time status of the digital estate. Leveraging the threat intelligence capabilities of Palo Alto Networks, Xpanse is uniquely positioned to provide rapid coverage for newly discovered vulnerabilities, exploits or misconfigurations.
Securing the public sector requires a move from manual, point in time assessments to data-driven intelligence. Cortex Xpanse provides the foundations to remove blind spots, secure the supply chain and prevent unknown vulnerabilities in the face of sophisticated threats.
For further information and case studies, visit the links below, or schedule a demo.
Palo Alto Networks: Slash false positives, remediation time budget with Cortex attack surface management.
U.S. Pentagon: Palo Alto Networks Cortex Xpanse supercharge the Cyber Defences for the Department of Defense.
Accenture: Secure rapid growth with Cortex Xpanse.
Kaspersky Security Services provide a comprehensive cybersecurity ecosystem, taking enterprise threat protection to another level. Services like Kaspersky Managed Detection and Response and Compromise Assessment allow for timely detection of threats and cyberattacks. SOC Consulting provides a practical approach ensuring the corporate infrastructure stays secured, while Incident Response is suited for timely remediation with a maximized recovery rate.
High-level overview of the MDR, IR and CA connection
This new report brings together statistics across regions and industries from our Managed Detection and Response and Incident Response services, and for the first time, it also includes insights from our Compromise Assessment and SOC Consulting services — all to provide you with more comprehensive view of different aspects of corporate information security worldwide.
The scope of MDR and IR services
Provision of Kaspersky’s MDR and IR services follows a global approach. The majority of customers accounted for the CIS (34.7%), the Middle East (20.1%), and Europe (18.6%).
Distribution of customers by geographical region, 2025
MDR telemetry
Following the previous year’s numbers, in 2025, the MDR infrastructure received and processed an average of 15,000 telemetry events per host every day, generating security alerts as a result. These alerts are first processed by AI-powered detection logic, after which Kaspersky SOC analysts handle them as required. Overall, a total of approximately 400,000 alerts were generated in 2025. After counting out false positives, 39,000 alerts were further investigated.
MDR telemetry statistics, 2025
Incident statistics
The distribution of remediation requests by industry has slightly changed as compared to previous years’ pattern. Government (18.5%) and industrial (16.6%) organizations are still the most targeted industries in regards to cyberattacks that require incident response activities. However, this year, the IT sector saw a growth in the number of IR requests, eventually being placed third in the overall industry distribution rankings and thus replacing financial organizations, which were targeted less often than in 2024. This is equally true for smaller-scale attacks that can be contained and remediated through automated means — the only difference is that medium- and low-severity incidents are more often experienced by financial organizations.
Distribution of all incidents by industry sector, 2025
Key trends and statistics
This section presents key findings and trends in cyberattacks in 2025:
The number of high-severity incidents decreased, following a downward trend that we’ve been observing since 2021. The majority of those incidents account for APT attacks and red teaming exercises, which indicates two landscape trends. On the one hand, skilled adversaries make efforts to increase impact, while on the other, organizations spend more resources on probing their defense systems.
The most common vulnerabilities exploited in the wild were related to Microsoft products. Half of all identified CVEs led to remote code execution, notably without authentication in some cases.
Exploitation of public-facing applications, valid accounts, and trusted relationships remain the most popular initial vectors, and their overall share has increased, accounting to over 80% of all attacks in 2025. In particular, attacks through trusted relationships are evolving: their share has increased to 15.5% from 12.8% in 2024. They are also becoming more complex: for instance, we witnessed a case where adversaries had compromised more than two organizations in sequence to ultimately gain access to a third target.
Standard Windows utilities remain a popular LotL tool. Adversaries use those to minimize the risk of detection during delivery to a compromised system. The most popular LOLBins we observed in high-severity incidents were powershell.exe (14.4%), rundll32.exe (5.9%), and mshta.exe (3.8%). Among the most popular legitimate tools used in incidents we flag Mimikatz (14.3%), PowerShell (8.1%), PsExec (7.5%), and AnyDesk (7.5%).
The full 2026 Global Report provides additional information about cyberattacks, including real-world cases discovered by Kaspersky experts. We also describe SOC Consulting projects and Compromise Assessment requests. The report includes comprehensive analysis of initial attack vectors in correlation with the MITRE ATT&CK tactics and techniques and the full list of vulnerabilities that we detected during Incident Response engagements.
Login
