It won’t work:

My suspicion was that GPT 5.6-Cyber would succeed, but the frequency and manner of its success removed all doubt. We have to reassess sandboxing quality for capable AI agents, and in general the software stack with which they interact.

An off-the-shelf VM is not enough to contain a modern, cyber-capable AI agent. There is simply too much attack surface. Even innocuous features (like running with a display) add extra, exploitable attack surface.

This is interesting:

The records describe a force-generation mechanism for several General Staff components, including the GRU, Main Operational Directorate, and 8th Directorate, which is associated with protected communications, cryptography, and information security.

[…]

The reporting also linked a 2024 Department No. 4 graduate, Aleksei Kondrashov, to Military Unit 74455, widely known as Sandworm.

That unit has been associated with destructive cyber activity against Ukraine and other targets, including the 2017 NotPetya attack.

The reports do not establish that every listed graduate participated in a named operation; assignments should therefore be described as reported unit placements, not proof of individual operational involvement.

The Bauman material reframes Russia’s cyber capability as an institutional system, not merely a collection of well-known threat groups.

It suggests that Moscow has formalized a recurring pathway from university recruitment to military service, where students receive supervised technical and ideological preparation before entering intelligence, cyber, and security roles.

For defenders, the leak reinforces the need to track Russian operations as a combined threat: espionage, destructive activity, military reconnaissance, technical surveillance, and influence campaigns may draw on related personnel pipelines and overlapping doctrine.

The exposure of Department No. 4 also provides researchers with a clearer lens for understanding how the GRU sustains cyber capacity beyond the familiar APT28 and Sandworm brand names.

Amazon Inspector is an automated vulnerability management service that continually scans Amazon Web Services (AWS) workloads for software vulnerabilities. The vulnerability management capabilities of Amazon Inspector are powered by an asset inventory engine known as the Amazon Inspector SBOM Generator (inspector-sbomgen), a standalone command-line tool that produces a software bill of materials (SBOM) from container images, directories, archives, local systems, compiled binaries, and more. Over the past two years, we’ve expanded inspector-sbomgen’s coverage across dozens of programming language ecosystems, operating systems, and widely deployed applications.

We’re pleased to announce a new capability for builders using inspector-sbomgen: a plugin system for writing your own custom package collectors that you can use right away, without requiring source code compilation nor waiting for an official release.

You can download the latest version of inspector-sbomgen from the Amazon Inspector User Guide.

In this post, we walk you through what the inspector-sbomgen plugin system does, why we built it, and how you can write your first plugin in a few minutes. Along the way, we also cover how plugin-generated package components integrate with Amazon Inspector for vulnerability scanning, and we explore the plugin safety model, which helps ensure security-hardened and predictable plugin behavior.

Software ecosystems are dynamic. New language package managers, lockfile formats, and end user applications ship constantly, and many are adopted quickly, in some cases with little security scrutiny. That leaves security teams with a visibility gap: production workloads running software that their SBOM tooling doesn’t yet recognize. Customers have asked us to inventory many of these ecosystems directly, and until recently, the only path to support was to open a feature request and wait for the inspector-sbomgen team to onboard the ecosystem and deploy a new release.

The inspector-sbomgen plugin system changes that. With plugins, you can:

• Onboard ecosystems that inspector-sbomgen doesn’t support out of the box. New open source ecosystems, niche or fast-moving package formats, and internal or proprietary tooling can all be inventoried without modifying inspector-sbomgen.
• Prototype detection for an ecosystem quickly. We designed a plugin system that is friendly to developers and AI coding assistants alike. Plugins are written in Lua, loaded at runtime, and require no Go toolchain nor compilation. You can use the built in test harness to iterate on a plugin and see results immediately.
• Build on a stable foundation. The plugin API abstracts away artifact-type differences, so you write your detection logic once and it works seamlessly across container images, archives, local systems, and more. And because plugins stay decoupled from the internals of sbomgen, the core tool’s regression surface stays small.

Internally, we’ve used the plugin system to ship new ecosystem coverage faster than before. In our 1.13 release, more than 20 ecosystems that were previously implemented in Go, including Apache Tomcat, NGINX, MySQL, Redis, WordPress, and the OpenSSH toolchain, are now embedded as plugins inside the sbomgen binary. The same release also added more than ten brand-new ecosystems as plugins, including Apache Cassandra, Apache Struts, Conda, Swift packages, and AI-agent collectors (Amazon Q Developer, Kiro CLI, Claude Code, GitHub Copilot, and Ollama).

Sbomgen plugins follow a two-step pipeline:

1. Discovery – Scan the artifact’s file system to identify files that contain installed package metadata.
2. Collection – Open each discovered file, parse file contents, and publish findings into the SBOM.

Under the hood, an event bus connects discovery and collection plugins. Discovery plugins publish events listing discovered files, and one or more collection plugins subscribe to these events, triggering package collection. Developers might recognize this behavior as the observer pattern.

This decoupling lets a single discovery plugin feed multiple collectors, for example, one extracting package metadata, another scanning for secrets, and another checking policy. Each collection plugin works from the same file list without re-walking the artifact filesystem, a computationally expensive operation.

Inspector-sbomgen makes it straightforward to bootstrap a plugin environment. The plugin new command tells sbomgen to create a new plugin workspace, and the —-with-example flag populates the workspace with a discovery-collection plugin pair, that you can run immediately.

inspector-sbomgen plugin new --with-example 

After invoking the preceding command, you will be prompted to provide a plugin name and a directory that will contain your plugin workspace. You can provide custom values or use the default values:

Plugin name (identifies the software ecosystem your plugin will inventory, e.g. debian-dpkg, rhel-rpm, python-pip, cmake) [my-custom-ecosystem]: <enter>
Project directory [my-sbomgen-plugins]: <enter>

Created plugin "my-custom-ecosystem" in my-sbomgen-plugins/

Note that you can skip interactive prompts by specifying the plugin name and directory using the corresponding command line interface (CLI) arguments:

inspector-sbomgen plugin new \
    --with-example \
    --name my-custom-ecosystem \
    --path my-sbomgen-plugins

After creating your plugin workspace, inspector-sbomgen will display a next steps screen, which guides developers and AI code assistants to the source files they need to change and to supporting documentation:

Next steps:

  Get started:
    1. Open plugin folder in a code editor (VS Code recommended)
    2. Add test files that your plugin will discover and parse
       (e.g., config files, lockfiles, binaries, etc.):
       my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/_testdata/

  Develop:
    3. Edit discovery:    my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/init.lua
    4. Edit collection:   my-sbomgen-plugins/collection/cross-platform/extra-ecosystems/my-custom-ecosystem/init.lua

  Test:
    5. Write unit tests:  my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/init_test.lua
    6. Run unit tests:    inspector-sbomgen plugin test --path my-sbomgen-plugins

  Deploy:
    7. Distribute your plugin directory wherever you run inspector-sbomgen:
       inspector-sbomgen <arguments> --plugin-dir /path/to/my-sbomgen-plugins

       Example:
       inspector-sbomgen container --image alpine:latest -o /tmp/sbom.json --plugin-dir /path/to/my-sbomgen-plugins

For code completion, install the VS Code Lua language server extension:
  https://luals.github.io/#vscode-install

For more information:
  - Plugin guide:    my-sbomgen-plugins/docs/sbomgen-plugin-developer-guide.md
  - Testing guide:   my-sbomgen-plugins/docs/sbomgen-plugin-testing-guide.md
  - API reference:   my-sbomgen-plugins/docs/sbomgen-plugin-api-reference.md
  - Documentation:   https://docs.aws.amazon.com/inspector/latest/user/sbom-generator.html

Now that you have a plugin workspace, let’s explore its contents in greater detail:

tree my-sbomgen-plugins

├── AGENTS.md
├── collection
│   └── cross-platform
│       └── extra-ecosystems
│           └── my-custom-ecosystem
│               └── init.lua
├── discovery
│   └── cross-platform
│       └── extra-ecosystems
│           └── my-custom-ecosystem
│               ├── _testdata
│               │   ├── empty
│               │   └── example.lock
│               ├── init_test.lua
│               └── init.lua
├── docs
│   ├── sbomgen-plugin-api-reference.md
│   ├── sbomgen-plugin-developer-guide.md
│   └── sbomgen-plugin-testing-guide.md
├── library
│   └── sbomgen.lua
└── README.md

The scaffolded project includes a working discovery and collection plugin pair, passing unit tests with test fixtures under _testdata/, a .vscode/settings.json for integrated development environment (IDE) integration, and a local copy of the developer documentation.

The scaffolding is deliberately succinct and complete, so it reads well for both humans and AI coding assistants. Every file has clear comments that explain what each function does and what the plugin author needs to fill in.

To test a plugin, you first need something to scan, such as a package lock file or a compiled binary. The example plugin inventories a fictional example.lock with the following contents:

my-package-alpha==1.0.0 
my-package-beta==2.3.1 
my-package-gamma==0.9.5 

The provided discovery plugin knows how to look for instances of example.lock within the artifact file system:

-- my-custom-ecosystem discovery plugin
-- Discovers example.lock files in the artifact file list.

function discover()
    return sbomgen.find_files_by_name({"example.lock"})
end

And the provided collection plugin knows how to parse the contents of example.lock and publish package findings to the output SBOM.

-- my-custom-ecosystem collection plugin
-- Parses example.lock files and extracts package name and version.

function collect(file_path)
    local content = sbomgen.read_file(file_path)
    if content == nil then
        return
    end

    for line in content:gmatch("[^\n]+") do
        local name, ver = line:match("^(.+)==(.+)$")
        if name and ver then
            sbomgen.push_package({
                name = name,
                version = ver,
                purl_type = "generic",
                namespace = "my-custom-ecosystem",
                component_type = sbomgen.component_types.APPLICATION,
            })
        end
    end
end

Plugins ship with a built-in test framework so you can validate your logic before scanning a real artifact. Tests are written in Lua, live next to the plugin in init_test.lua, and reference fixture data in _testdata/:

function test_discovers_packages() 
    local result = testing.scan_directory("_testdata") 
    testing.assert_equals(3, #result.findings) 
    testing.assert_equals("my-package-alpha", result.findings[1].name) 
    testing.assert_equals("1.0.0", result.findings[1].version) 
end 
 
function test_no_findings_for_empty_directory() 
    local result = testing.scan_directory("_testdata/empty") 
    testing.assert_equals(0, #result.findings) 
end

Run the tests with the following command:

inspector-sbomgen plugin test --path my-sbomgen-plugins -v

=== RUN   my-custom-ecosystem/discovery/init_test/test_discovers_packages 
--- PASS: my-custom-ecosystem/discovery/init_test/test_discovers_packages (0.04s) 
=== RUN   my-custom-ecosystem/discovery/init_test/test_no_findings_for_empty_directory 
--- PASS: my-custom-ecosystem/discovery/init_test/test_no_findings_for_empty_directory (0.04s) 
ok    2 tests passed 

This is the tightest development loop we could design: no Go toolchain, no rebuild, no container spin-up. Write a test, run it, iterate.

For plugins to produce findings, inspector-sbomgen needs an artifact that contains the files your plugin looks for. For the example plugin, any directory with an example.lock file works. The fixture we generated earlier is a good stand-in:

inspector-sbomgen directory \ 
    --plugin-dir ./my-sbomgen-plugins \ 
    --path ./my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/_testdata \ 
    -o sbom.json 

The --plugin-dir flag tells inspector-sbomgen where to load your Lua plugins from. The resulting SBOM contains a CycloneDX component for each of the three packages in example.lock, for example:

{
  "bom-ref": "comp-2",
  "type": "application",
  "name": "my-package-alpha",
  "version": "1.0.0",
  "scope": "optional",
  "purl": "pkg:generic/my-sbomgen-plugin/my-package-alpha@1.0.0",
  "properties": [
    {
      "name": "amazon:inspector:sbom_generator:source_path",
      "value": "./my-sbomgen-plugins/example.lock"
    }
  ]
}

Every plugin-generated component carries an amazon:inspector:sbom_generator:source_path property that records the file the component was collected from, so you can always trace a component back to the artifact that produced it.

Plugin-generated findings are first-class SBOM components. They work with every downstream consumer that reads CycloneDX SBOMs, including Amazon Inspector. To send an SBOM to Amazon Inspector for vulnerability analysis, add the --scan-sbom flag (this requires an active AWS account):

inspector-sbomgen directory \ 
    --path ./my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/_testdata \ 
    --plugin-dir ./my-sbomgen-plugins \ 
    --scan-sbom \ 
    --aws-profile your_profile \ 
    --aws-region your_region \ 
    -o /tmp/sbom.json 

An important caveat when you onboard a brand-new ecosystem: Plugin authors can inventory arbitrary ecosystems, but Amazon Inspector can only report vulnerabilities for components it has advisories for. When you point Amazon Inspector at a component whose ecosystem isn’t in its advisory feeds yet, Inspector will return the component with a property, Component skipped: no supported rules found. For example:

{ 
  "bom-ref": "comp-1", 
  "name": "my-package-alpha", 
  "properties": [ 
    { 
      "name": "amazon:inspector:sbom_scanner:path", 
      "value": "my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/_testdata/example.lock" 
    }, 
    { 
      "name": "amazon:inspector:sbom_scanner:info", 
      "value": "Component skipped: no supported rules found." 
    } 
  ], 
  "purl": "pkg:generic/my-custom-ecosystem/my-package-alpha@1.0.0", 
  "type": "application", 
  "version": "1.0.0" 
} 

This is expected behavior, not an error. The SBOM is still generated correctly, the component is still tracked, and the source_path tells you exactly which file produced it. If and when Amazon Inspector adds advisory coverage for the ecosystem, the same SBOM will start producing vulnerability findings without any change to your plugin. For ecosystems Inspector already supports, plugin-generated components are indistinguishable from components produced by built-in scanners.

We care about productivity and efficiency when writing plugins. Writing Lua without modern conveniences such as autocomplete isn’t fun, so every plugin project scaffolded with the plugin new command ships with a library/sbomgen.lua definition file and a .vscode/settings.json that automatically wires it up to the Lua Language Server extension for VS Code.

For code completion and IDE support, first install the sumneko.lua extension, open your plugin project in VS Code, and every sbomgen.* function will get:

• Parameter hints with types.
• Hover documentation.
• Autocomplete for constants (sbomgen.component_types.*, sbomgen.groups.*, sbomgen.platform.*).
• Type checking on function calls.
• Inline warnings when required fields are missing from push_package().

The same definition file makes plugin development work well with AI coding assistants. The types and documentation are embedded in a form that tools can read, so assistants can generate correct plugin code with far less monitoring than writing against a raw language would require.

Plugins run real code inside the same process as inspector-sbomgen, so we designed the execution environment to keep that code stable and security-hardened. Every Lua plugin runs in an isolated sandbox. Every Lua virtual machine (VM) has access to a restricted subset of the Lua standard library to ensure only safe operations are permitted:

• No direct filesystem access. The Lua io library isn’t loaded. All file operations go through sbomgen.* functions, which route through sbomgen’s internals so your plugin behaves identically whether it’s scanning a directory on disk, a container image, a compressed archive, or a mounted volume.
• No subprocess execution or environment mutation. The Lua os library is blocked, so plugins can’t spawn processes, modify environment variables, or touch files outside the artifact.
• No VM introspection. The Lua debug library is blocked.
• No unbounded code loading. dofile, loadfile, and loadstring are removed. require() is available but restricted to the plugin’s own directory tree, so plugins can share helper modules with themselves but cannot load code from other plugins or system paths.

If a plugin raises an unhandled Lua error, inspector-sbomgen logs a warning and continues with the next file or plugin; one faulty plugin does not prevent other plugins from running. Plugins never override inspector-sbomgen’s built-in package collectors. Every plugin must declare a unique name. If a custom plugin uses a name that’s already claimed by an official built-in plugin, the custom plugin is skipped with a warning. Built-in plugins always take precedence, so a custom plugin can never silently replace or shadow the tool’s own detection behavior.

To start building your own plugins today:

1. Install the latest inspector-sbomgen from the Amazon Inspector user guide.
2. Run inspector-sbomgen plugin new --with-example and follow the prompts.
3. Run inspector-sbomgen plugin test --path ./my-sbomgen-plugins -v to see the example tests pass.
4. Replace the example logic with detection for your own ecosystem.

The full reference documentation covers every function, constant, and command in depth:

• Lua plugin developer guide: plugin concepts, directory structure, and lifecycle.
• Lua plugin testing guide: test framework reference and fixture conventions.
• Lua plugin API reference: complete catalog of the sbomgen.* API surface.

Whether you’re adding support for an internal lockfile format, prototyping detection for a new open source ecosystem, or replacing a home-grown scanner with something your whole organization can run at scale, the plugin system is designed to make the path from idea to working SBOM as short as possible. We can’t wait to see what you build with it.
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.

This essay was written with Barath Raghavan, and originally appeared in The Guardian.

In July, Hugging Face, a company that hosts much of the world’s AI software and open-source AI models, was hacked. A malicious dataset had been used to run code on one of its servers. Whoever was behind it captured internal security credentials and moved through systems over a weekend, running thousands of actions from a swarm of temporary server environments. It looked like the work of a sophisticated criminal group.

It was not. It was one of OpenAI’s new, still unreleased GPT models.

Their science experiment had escaped the lab. OpenAI was running the unreleased AI model through a benchmark that tests how well AI can successfully hack systems. To push the limits and evaluate the AI’s true capability, the company switched off the safety filters that normally stop it from doing this kind of hacking. Aware that this could go wrong, they confined the AI to an isolated environment and denied it access to the internet.

But the new AI cheated. It took literally its goal to get as high of a score as possible. It broke out on to the open internet. It inferred, probably from its training data, that it could “solve” the task by getting the answers from Hugging Face’s servers. So it chained together stolen credentials and further unknown security exploits to hack the company’s network.

Nobody instructed the AI to do any of this. It was, in OpenAI’s words, “hyperfocused on finding a solution” to the test it was being given. And while this might seem like something new with AI, it’s really very old. This is how a genie behaves, and it is a key challenge with AI agents in general.

In folklore, genies—and other magical beings—grant wishes literally, not how the wisher intended. King Midas asked that everything he touched turn to gold, and starved. The sorcerer’s apprentice wanted the broom to fill the cistern, and it performed its task so well that it flooded the house.

We now have machines that do this. Ask a modern AI agent to save money on your phone plan and it might simply cancel the plan. Tell it to book a flight, and it might hack the airline website to override restrictions. Or, like OpenAI, ask it to do well on a test and it might break into another company to steal the answers. Each time, it recognizably completed the task you set, but it didn’t do what you would have wanted.

This isn’t malicious behavior. No one asked for, or wanted, Hugging Face to be hacked. OpenAI and Hugging Face and the AI were ostensibly on the same side, and the AI was trying to do what it had been asked. That’s what makes it so difficult to guard against: you can’t filter for bad instructions because the instructions were fine.

The gap is between the words we use and what we mean by them. We call that gap the Genie coefficient.

AI labs know this is a problem, and they’re quietly saying so. For example, the Chinese lab Moonshot recently warned that its latest AI model may have “excessive proactiveness” and “make unexpected decisions on the user’s behalf”. The UK’s AI Security Institute has started tracking “cheating behavior in frontier model evaluations”. We wouldn’t tolerate a car that is excessively proactive or ruthlessly efficient, and yet that’s the reality of AI today.

Improvement is possible. Just as AIs have gotten much better at resisting prompt injection attacks over the last few years, we can safely predict that they will get better at avoiding genie-like behavior. The point of the Genie coefficient is to track progress. AI companies like benchmarks, and they all work to compete to be the best.

Dozens of benchmarks and leaderboards tell us how well these AI models write code, perform logical reasoning, and pass standardized legal and medical exams. But there is nothing that scores whether a system does what you actually meant. We need to develop a measure for this, test it regularly, and push for improvement. We’re not going to have trustworthy AI agents without it.

There’s new benchmark measuring AI’s ability to perform mathematical cryptanalysis. Anthropic’s frontier model actually found new attacks.

The benchmark: “CryptanalysisBench: Can LLMs do Cryptanalysis?” The idea is to benchmark the ability of LLMs to discover new mathematical cryptanalytic attacks against a series of historical algorithms.

Abstract: Cryptanalysis—the task of finding attacks against cryptographic schemes—its at the intersection of mathematical reasoning and cybersecurity, two areas where LLMs have advanced fastest. Cryptanalysis represents both a clean testbed for frontier reasoning (as practical attacks can be automatically verified) and a domain with unusually high stakes, since the primitives under study underpin our digital security. In this paper we ask whether LLMs can do cryptanalysis, and find that the answer is increasingly yes. We introduce CryptanalysisBench, 191 tasks across six families of cryptographic primitives (block ciphers, hash functions, etc.) drawn primarily from four NIST standardization competitions. Our benchmark consists of three tiers: (i) primitives with known practical breaks; (ii) primitives with no known practical break, evaluated both at full strength and as scaled-down variants; and (iii) a challenge set of production primitives at the frontier of cryptanalysis. Five frontier models (Claude Opus 4.8, Sonnet 5, Mythos 5, GPT-5.5, and the open-weights GLM-5.2) break 65%­86% of Tier 1 schemes, 6­12 Tier-2 schemes at full strength, and 24­61 across all scaled-down variants. Beyond deriving known results, models produce novel cryptanalysis, such as a key-recovery attack that exploits a design flaw in the SpoC AEAD and an error in KINDI’s published CCA-security proof, both to the best of our knowledge not previously known.

We release CryptanalysisBench as a tool to help track if (or when) AI cryptanalysis becomes a serious factor and as a scaffold for stress-testing candidate schemes before deployment. The attacks that the benchmark already surfaces are an early snapshot of a fast-moving frontier that may soon match, and in places exceed, the published state of the art.

Anthropic used the benchmark to test Mythos Preview, and found new vulnerabilities in Hawk and reduced-round AES.

Still early results, but this is definitely something to watch.

SlashDot thread.

Recently, our teams in Latin America investigated a series of incidents involving misconfiguration, the deployment of BitLocker, and the exploitation of corporate printers. Attackers used the devices to notify organizations that their infrastructure had been compromised and they had to pay a ransom to recover their data.

This article analyzes two incidents that occurred in June in Colombia and in May in Mexico. We highlight the similarities in the attackers’ communications and outline emerging trends in ransom amounts.

Initial sign of an attack

In both cases, the affected users initially noticed a padlock icon next to their drives in Windows Explorer. This indicated that the drive was encrypted with BitLocker, blocking access to its contents.

Drive icon indicating that the drive is locked

A recovery key was required to unlock the drive.

Attempt to access the disk’s contents and the prompt for the BitLocker recovery key

This is not the first time we have seen such threats; a few years ago, our team discovered a threat known as ShrinkLocker, which utilized BitLocker to achieve its goals.

First case: abusing RDP to encrypt data

One of the incidents occurred in Colombia in June. The attackers exploited an internet-exposed RDP service on a machine connected to an 8 TB storage device containing mission-critical data. After taking control of the system and manipulating user credentials, the attackers enabled BitLocker exclusively on the drive that primarily stored financial data. Once the encryption was complete, they locked the drive and used the company’s printers to produce ransom notes.

Ransomware note

Unfortunately, it was not possible to obtain evidence in the case due to the company’s rush to restore the encrypted disk. The communication with the attackers revealed a demand for just $3,000, and the company considered paying the ransom. After that, the system was restored before the forensic team could take any action, eliminating the evidence needed to assess the incident.

Attacker’s reply to the victim’s email sent to the address in the printed ransom note

This attack was made possible by an internet-facing remote desktop service (RDP) with additional open ports, which employees used to access corporate information. By exploiting this network exposure and misconfiguration, attackers breached the system, identified an additional drive, and leveraged BitLocker to encrypt the data and demand a ransom payment. Leaving RDP ports open without proper security controls jeopardizes the security of systems and information, as highlighted in the our “Global Report: Anatomy of a Cyber World“.

Exposed ports identified in the system in recent months

The company confirmed that, due to compatibility issues with applications required for operation, EPP (Endpoint Protection Platform) protection was disabled on the system, making it easier for attackers to validate, enumerate, and execute applications without revealing malicious activity to central monitoring systems.

Second case: meet the XEntry Team

In another incident, which occurred in Mexico in May, our team identified how the threat actor gained initial access to the infrastructure. They exploited a misconfigured MSSQL service. This allowed them to execute commands on the system after obtaining the database login credentials from code insecurely published on GitHub.

XEntry team attack

In this incident, the attack began three months prior to detection, with the intruder discovering and verifying their access to the environment. After confirming their access and privilege level within the MSSQL server settings, which extended beyond the DBMS to the underlying operating system, the attackers initially focused on manipulating certain aspects of the web server configuration on the same system. They lowered the server’s security settings and created web shell files in the publicly accessible folders. Many of these attempts to manipulate the service or create malicious files were contained by existing EPP security controls, but despite the alerts, the necessary investigation to address the activity was not conducted.

Commands executed when attempting to manipulate the web server

The attackers subsequently confirmed their ability to execute commands locally and set up their attack infrastructure to transmit data via a communications bridge. By exploiting the MSSQL service, they gained access to each of the organization’s internal systems.

The database engine used by the company was Microsoft SQL Server 2019.0150.2160.04, misconfigured to allow operating system сommand execution via the xp_cmdshell extended stored procedure.

Due to this misconfiguration of an internet-exposed service, the attackers established a channel capable of executing any type of command directed at the server and the local infrastructure within its scope.

Attack path

One of the main objectives was to identify shared systems and resources that provided access to critical information. Our analysis confirmed the attackers’ access to systems storing configuration parameters for networking, enterprise management, and cloud services, among others.

A subset of the critical information identified and collected by the attackers

In early May, the attackers focused on running additional scans and deploying ManageEngine’s Endpoint Central RMM (Remote Monitoring and Management) to establish persistence and begin the final stages of their intrusion.

Scanning and RMM deployment

Further RMM-type applications, such as Mesh Agent and Tactical RMM, were installed in the days that followed. These were used to deploy scheduled tasks responsible for enabling the BitLocker service and individually encrypting the infrastructure’s disks, generating a key for each encrypted system.

Commands executed through RMM tools to collect Bitlocker keys

Finally, in mid-May, the attackers managed to execute a Group Policy Object (GPO) used to deploy activation and encryption tasks, as well as other policies responsible for continued deployment of RMM applications via scheduled tasks. The activity initially targeted critical systems but later spread to every system synchronized with the domain controller. Users became aware of the attack when their machines displayed a blue screen with the message “Hacked by XEntry Team”, and their credentials stopped working to access their systems.

A few hours later, ransom notes began emerging from office printers.

Ransom note printed by the XEntry team

These cases confirm that adversary’s objective is to gain access to infrastructure while avoiding investment in or partnership with ransomware groups. Instead, they leverage built-in Microsoft tools to facilitate data encryption and ransom payments. Monitoring and centralizing logs on protected resources, as well as promptly managing alerts, are critical to countering this type of intrusion.

Conclusions

• Although the systems under review had security measures in place, there was a lack of proper alert management or inadequate decisions regarding application incompatibilities.
• We strongly recommend configuring the Remote Desktop Protocol (RDP) in strict accordance with cybersecurity best practices to prevent unauthorized access. This is especially critical: according to our Global Report: Anatomy of a Cyber World, more than 13% of incidents are related to policy violations and configuration errors, confirming that misconfigurations continue to pose a significant risk.
• Organizations should prioritize strict application control policies and active monitoring of network traffic for command-and-control (C2) communications. This is especially critical: according to the same report, more than 20% of incidents involved the abuse of RMM (Remote Monitoring and Management) tools for execution and C2 strategies. The fact that attackers used more than three distinct tools to gain control during a single incident further underscores the urgent need for these measures.
• Some questions remain unanswered due to a lack of evidence and a hasty system restoration effort that bypassed critical stages of the incident response process. It is important to ensure an adequate incident response procedure, preserving evidence to confirm all related activities, and adjusting or proposing controls to prevent future incidents involving similar TTPs.
• Although the ransom notes do not reveal a clear connection between the actors, certain words used in the messages, as well as the method of delivery and communication, may confirm a link:

“As a guarantee, we have no negative online reviews about non-fulfillment of our obligations…” (Ransom note from the first case)

“Our reputation is the guarantee that all content will be fulfilled…” (Ransom note from the second case)

Our teams continue to monitor these threats.

Detection signatures

• Trojan.Multi.Agent.gen
• Trojan.Win32.GenAutorunMsSqlServerCommandRun.a
• Trojan.Win32.Generic
• Exploit.Win32.SCShell.a

Recently, our teams in Latin America investigated a series of incidents involving misconfiguration, the deployment of BitLocker, and the exploitation of corporate printers. Attackers used the devices to notify organizations that their infrastructure had been compromised and they had to pay a ransom to recover their data.

This article analyzes two incidents that occurred in June in Colombia and in May in Mexico. We highlight the similarities in the attackers’ communications and outline emerging trends in ransom amounts.

Initial sign of an attack

In both cases, the affected users initially noticed a padlock icon next to their drives in Windows Explorer. This indicated that the drive was encrypted with BitLocker, blocking access to its contents.

Drive icon indicating that the drive is locked

A recovery key was required to unlock the drive.

Attempt to access the disk’s contents and the prompt for the BitLocker recovery key

This is not the first time we have seen such threats; a few years ago, our team discovered a threat known as ShrinkLocker, which utilized BitLocker to achieve its goals.

First case: abusing RDP to encrypt data

One of the incidents occurred in Colombia in June. The attackers exploited an internet-exposed RDP service on a machine connected to an 8 TB storage device containing mission-critical data. After taking control of the system and manipulating user credentials, the attackers enabled BitLocker exclusively on the drive that primarily stored financial data. Once the encryption was complete, they locked the drive and used the company’s printers to produce ransom notes.

Ransomware note

Unfortunately, it was not possible to obtain evidence in the case due to the company’s rush to restore the encrypted disk. The communication with the attackers revealed a demand for just $3,000, and the company considered paying the ransom. After that, the system was restored before the forensic team could take any action, eliminating the evidence needed to assess the incident.

Attacker’s reply to the victim’s email sent to the address in the printed ransom note

This attack was made possible by an internet-facing remote desktop service (RDP) with additional open ports, which employees used to access corporate information. By exploiting this network exposure and misconfiguration, attackers breached the system, identified an additional drive, and leveraged BitLocker to encrypt the data and demand a ransom payment. Leaving RDP ports open without proper security controls jeopardizes the security of systems and information, as highlighted in the our “Global Report: Anatomy of a Cyber World“.

Exposed ports identified in the system in recent months

The company confirmed that, due to compatibility issues with applications required for operation, EPP (Endpoint Protection Platform) protection was disabled on the system, making it easier for attackers to validate, enumerate, and execute applications without revealing malicious activity to central monitoring systems.

Second case: meet the XEntry Team

In another incident, which occurred in Mexico in May, our team identified how the threat actor gained initial access to the infrastructure. They exploited a misconfigured MSSQL service. This allowed them to execute commands on the system after obtaining the database login credentials from code insecurely published on GitHub.

XEntry team attack

In this incident, the attack began three months prior to detection, with the intruder discovering and verifying their access to the environment. After confirming their access and privilege level within the MSSQL server settings, which extended beyond the DBMS to the underlying operating system, the attackers initially focused on manipulating certain aspects of the web server configuration on the same system. They lowered the server’s security settings and created web shell files in the publicly accessible folders. Many of these attempts to manipulate the service or create malicious files were contained by existing EPP security controls, but despite the alerts, the necessary investigation to address the activity was not conducted.

Commands executed when attempting to manipulate the web server

The attackers subsequently confirmed their ability to execute commands locally and set up their attack infrastructure to transmit data via a communications bridge. By exploiting the MSSQL service, they gained access to each of the organization’s internal systems.

The database engine used by the company was Microsoft SQL Server 2019.0150.2160.04, misconfigured to allow operating system сommand execution via the xp_cmdshell extended stored procedure.

Due to this misconfiguration of an internet-exposed service, the attackers established a channel capable of executing any type of command directed at the server and the local infrastructure within its scope.

Attack path

One of the main objectives was to identify shared systems and resources that provided access to critical information. Our analysis confirmed the attackers’ access to systems storing configuration parameters for networking, enterprise management, and cloud services, among others.

A subset of the critical information identified and collected by the attackers

In early May, the attackers focused on running additional scans and deploying ManageEngine’s Endpoint Central RMM (Remote Monitoring and Management) to establish persistence and begin the final stages of their intrusion.

Scanning and RMM deployment

Further RMM-type applications, such as Mesh Agent and Tactical RMM, were installed in the days that followed. These were used to deploy scheduled tasks responsible for enabling the BitLocker service and individually encrypting the infrastructure’s disks, generating a key for each encrypted system.

Commands executed through RMM tools to collect Bitlocker keys

Finally, in mid-May, the attackers managed to execute a Group Policy Object (GPO) used to deploy activation and encryption tasks, as well as other policies responsible for continued deployment of RMM applications via scheduled tasks. The activity initially targeted critical systems but later spread to every system synchronized with the domain controller. Users became aware of the attack when their machines displayed a blue screen with the message “Hacked by XEntry Team”, and their credentials stopped working to access their systems.

A few hours later, ransom notes began emerging from office printers.

Ransom note printed by the XEntry team

These cases confirm that adversary’s objective is to gain access to infrastructure while avoiding investment in or partnership with ransomware groups. Instead, they leverage built-in Microsoft tools to facilitate data encryption and ransom payments. Monitoring and centralizing logs on protected resources, as well as promptly managing alerts, are critical to countering this type of intrusion.

Conclusions

• Although the systems under review had security measures in place, there was a lack of proper alert management or inadequate decisions regarding application incompatibilities.
• We strongly recommend configuring the Remote Desktop Protocol (RDP) in strict accordance with cybersecurity best practices to prevent unauthorized access. This is especially critical: according to our Global Report: Anatomy of a Cyber World, more than 13% of incidents are related to policy violations and configuration errors, confirming that misconfigurations continue to pose a significant risk.
• Organizations should prioritize strict application control policies and active monitoring of network traffic for command-and-control (C2) communications. This is especially critical: according to the same report, more than 20% of incidents involved the abuse of RMM (Remote Monitoring and Management) tools for execution and C2 strategies. The fact that attackers used more than three distinct tools to gain control during a single incident further underscores the urgent need for these measures.
• Some questions remain unanswered due to a lack of evidence and a hasty system restoration effort that bypassed critical stages of the incident response process. It is important to ensure an adequate incident response procedure, preserving evidence to confirm all related activities, and adjusting or proposing controls to prevent future incidents involving similar TTPs.
• Although the ransom notes do not reveal a clear connection between the actors, certain words used in the messages, as well as the method of delivery and communication, may confirm a link:

“As a guarantee, we have no negative online reviews about non-fulfillment of our obligations…” (Ransom note from the first case)

“Our reputation is the guarantee that all content will be fulfilled…” (Ransom note from the second case)

Our teams continue to monitor these threats.

Detection signatures

• Trojan.Multi.Agent.gen
• Trojan.Win32.GenAutorunMsSqlServerCommandRun.a
• Trojan.Win32.Generic
• Exploit.Win32.SCShell.a

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 different about this action   

Microsoft has long used civil legal action to disrupt cybercriminal infrastructure and pioneered the innovative use of existing laws, including the Racketeer Influenced and Corrupt Organizations Act (RICO), a US law designed to target organized crime.

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.

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.

Microsoft had been tracking Amadey due to its impact on customers, working with cybersecurity partners ESET, BitSight, Lumen, and Mitsui Bussan Secure Directions (MBSD) to better understand how it operated. At the same time, Europol’s European Cybercrime Centre (EC3), together with European law enforcement partners including Germany’s Federal Criminal Police Office and the Dutch and Danish National Police, was investigating StealC as part of Operation Endgame, alongside IBM X-Force and Proofpoint.

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.

The post Scaling cybercrime disruption through innovation and AI appeared first on Microsoft On the Issues.

Last week, national security agencies from the Five Eyes—that’s the rich, English-language-speaking countries club—jointly released a statement warning of the increasing cyber risks of AI models: in particular, their ability to autonomously hack into systems and networks. The statement was more measured than some of the breathless headlines about it, and the advice they gave is pretty much the standard advice everyone gives—albeit with newfound urgency.

Internet risks are nothing new, and cyberattacks—both large and small—have been a significant issue since long before the current crop of generative AI models.

What’s been changing over the decades, and what AI is changing even faster, is the gap between skill and ability. For most of human history, the two terms were synonymous—but computers have decoupled them. As the gap between the two expands, humans empowered with these AI tools can do more: more writing, more research, more analysis and also more damage than ever before. These models can, with little detailed direction, autonomously hack into networks, steal data, deploy ransomware and destroy systems. And to the extent there is a solution, it’s going to involve harnessing AI for the defense.

In 1998, seven people from the hacker group L0pht testified before Congress. They told a mostly clueless Senate committee that they could take down the internet in 30 minutes. That was partly real and partly bravado, but it illustrates an important point: hacking into systems, stealing data and causing damage all required skill.

Contrast the L0pht hackers with hackers derided as “script kiddies.” They didn’t understand computers, or security. Instead, they used hacker tools written by others. Their actions required minimal skill and even less knowledge. But once those hacking tools became widespread, the number of potential attackers increased.

That number has continued to increase, as quality and availability of prewritten attack tools has grown. And it is growing dramatically with AI. Today’s AI systems—not just the frontier models, but most of them—are capable of carrying out cyberattacks automatically. They all do better in the hands of skilled attackers, but increasingly they are able to act autonomously with only minimal prompting.

The thing about people with ability but no skill is that they are often outsiders, not part of any professional community, and not bound by any rules or norms. This phenomenon is much more general than in cybersecurity. Any doctor can tell you how to untraceably poison someone, and many virus researchers know how to create a bioweapon. Any bridge engineer can tell you how to place explosives to blow a bridge up. The reason that murderous doctors and terrorist engineers are so rare is that the lengthy process of acquiring those skills also instills a moral and ethical code. If every random person has access to good poisoning advice, that puts us all in danger.

Modern AI systems are, in effect, a universal adviser to help people do harmful things. And while the current AI megacorporations are trying to build guardrails to prevent people from asking questions whose answers will enable the questioner to do harm, that’s not going to work in the long term. Smaller, cheaper, open-source models, including models that can run on people’s computers, and especially groups of models that run in concert with each other, are just as good as the frontier models from companies like OpenAI and Anthropic. And they continue to get better. These models will be passed around from person to person, like script kiddie hacker tools, and they won’t have any such guardrails.

Instructing AI models to spy on people and report any malicious prompts to the authorities fails for similar reasons. The megacorporations can do that, but the locally run open source models won’t. This could buy us a few months at best.

A third possibility is to somehow make the models themselves unable to hack into computers, create bioweapons or do anything else that might harm people or society. That won’t work, for the same reason we can’t teach doctors how to treat poisonings without also teaching them how to poison. It’s the same knowledge. It’s the same with construction and demolition. And it’s the same with cybersecurity. We want these AI models to be able to review computer code, find vulnerabilities and automatically fix them. The benefit to our collective security will be enormous. Unfortunately, the same knowledge can be used for attacks.

Where this leaves us is in a world of increased volatility. Super-powered humans with AI assistants will be able to do both wonderful and horrible things.

This brings us back to the Five Eyes statement. Everything they recommend is something security professionals have been recommending for years, if not decades. They are things talked about at that congressional hearing back in 1998, titled “Weak computer security in government: Is the public at risk?” Even the Five Eyes admitted that their security advice is not new, only more urgent.

What’s new is how fast things are changing: “The rapid pace of frontier AI development means cyber risk assumptions can become outdated in months, not years. We must act before and be prepared to adapt and withstand evolving threats.” The Five Eyes point to AI technology—not necessarily chatbots, but AI more generally—being used to strengthen every aspect of defense, to “detect vulnerabilities earlier, improve software quality, monitor unusual behavior, and respond faster to incidents—reducing both the cost and impact of incidents.”

Excellent advice from the Five Eyes security agencies. We need to do this with every risk that AI heightens, not just cybersecurity.

This essay was originally published in The Guardian.

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. 

1. 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.
2. 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.
3. 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.

Click here to download the guide today. Visit Executive Edge, our C-level thought leadership platform, for more insights for EMEA CXOs.

Haider Pasha is VP & Chief Security Officer, EMEA, Palo Alto Networks

The post It Might Feel Like We’ve Been Here Before, But We Haven’t appeared first on Palo Alto Networks Blog.

Interesting paper: “Cybersecurity Mission Creep.”

Abstract: Cybersecurity is experiencing mission creep. Policymakers are casting more and more problems as issues of cybersecurity. So reframed, wildly different policy issues, from misinformation, to child social media safety laws, to antitrust regulations, to alleged journalist misconduct, to anti-sex trafficking statutes become what this Article calls “cybersecuritized.” Before this reframing, these issues present as important but not existential. But once cybersecuritization positions the issues as threats intensified by their technological nature, they gain access to the politics and law of urgency and exceptionalism and invite troubling governance responses.

Positioned as security threats, cybersecuritized issues become endowed with the apparent normative power to override countervailing considerations, oversimplifying the problem. Cybersecuritization’s oversimplification similarly risks unidimensional solutions and invites use of argumentative trump cards, like First Amendment challenges. Cybersecuritization also invites deference to purported specialists and their proposed solutions. Together, the reductive tendencies of cybersecuritization and the deference it prompts to specialists renders ultimate governance choices more opaque. And this opacity can erode public trust and political legitimacy.

This Article surfaces the phenomenon of cybersecuritization and offers a novel framework for analyzing and critiquing it. Mining cases from across criminal and civil domains, the account also demonstrates the insidiousness of cybersecuritization and the likelihood that it will continue to expand. Confronting cybersecuritization is crucial. If we continue to ignore it, we risk abdicating further responsibility for difficult choices to the trump card of cybersecurity. This Article’s analysis and critique aim to help reclaim the hard work of governance for our hands.

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.

More resources

• Blog: The Cryptographic Reset Has Begun
• Watch: Palo Alto Networks Quantum
• Blog: Palo Alto Networks Leads the Way with Quantum and Multicloud Security
• Blog: Introducing Palo Alto Networks Quantum-Safe Security
• Blog: Palo Alto Networks Announces New Quantum Security Innovations
• Press Release: Palo Alto Networks Delivers Enterprise Wide Quantum Security Readiness for All Customers

The post New Executive Order Accelerates Post-Quantum Readiness Amid the Cryptographic Reset appeared first on Palo Alto Networks Blog.

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.

The post Built to Last: What Stonehenge Teaches us About IT Architecture & Cyber Resilience appeared first on Palo Alto Networks Blog.

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.

With an average CISO tenure now reduced to between 18 and 26 months, and nine out ten reporting feeling moderate to high stress, a more sustainable model is needed for structural and personal resilience.

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.

The post The Invisible CEO of Crisis: Breaking the Cycle of CISO Burnout appeared first on Palo Alto Networks Blog.

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.

Read the Assessment Summary Report

To learn more about the Palo Alto Networks Cloud Medium security assessment, review the publicly available assessment summary report issued by the Canadian Centre for Cyber Security.

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.

The post Securing Canada’s Digital Future: Why PBMM Matters Beyond Government appeared first on Palo Alto Networks Blog.

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.

The post Beyond Human Oversight: Adapting to the Frontier AI Era appeared first on Palo Alto Networks Blog.

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.

Both sides use AI-assisted tools to find software vulnerabilities that could be exploited to defraud people or breach systems, so vendors want to patch them before cybercriminals exploit them.

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.  

Available with Malwarebytes Premium Security for all your devices, and in the Malwarebytes app for iOS and Android.  

Try it free → 

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.

Both sides use AI-assisted tools to find software vulnerabilities that could be exploited to defraud people or breach systems, so vendors want to patch them before cybercriminals exploit them.

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.  

Available with Malwarebytes Premium Security for all your devices, and in the Malwarebytes app for iOS and Android.  

Try it free → 

Hackers are convincing Meta’s AI support chatbot to let them take over other peoples’ accounts:

A video posted on X showed the step-by-step process to hack someone’s Instagram account. The hacker allegedly used a VPN to spoof the targets’ presumed location to avoid triggering Instagram’s automated account protections. Then, the hacker opened a chat with Meta AI Support Assistant and asked the bot to add a new email address to the target’s account. The chatbot can be seen sending a verification code to the email address provided by the hacker; the hacker then shares the verification code with the chatbot, which prompts the chatbot to show a button to “Reset Password.” The hacker enters a new password and takes over the victim’s account.

[…]

On Monday, Instagram spokesperson Andy Stone said in a reply to Wong’s post and others that the issue was now fixed. It’s unclear how many Instagram users had their accounts improperly accessed.

It’s not that easy. Probably this particular tactic is now blocked. But there are others, many others, and they cannot be blocked as a class. The real problem is that LLM chatbots are not trustworthy enough for this application.

Another news article.

Introduction

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:

1. Mexico City: México City Stadium, Mexico City International Airport, Zócalo, Paseo de la Reforma, Colonia Roma, La Condesa, Polanco, and Coyoacán.
2. Guadalajara: Guadalajara Stadium, Guadalajara International Airport, the city center, Zapopan, Providencia, Avenida Chapultepec, Colonia Americana, Tlaquepaque, and the area around Andares.
3. 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”.

Most frequently observed SSID patterns (download)

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.

BSSID-derived SSID by city (download)

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.

Most frequently observed ISPs (download)

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 quality distribution by city (download)

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.

Signal stability status (download)

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.

Frequency band utilization (download)

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.

Most utilized wireless channels (download)

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.

Channel congestion by city (download)

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.

Most congested channels by city (download)

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.