In an industrial network, malicious activity can be hard to tell apart from normal data exchange between devices. Malicious actors routinely rely on legitimate tools and the Living-off-the-Land technique, so a single network connection may show no known signs of an attack: the device uses a familiar protocol and transmits ordinary data. An anomaly can hide in subtle details: the data source, the time of access, or the volume of transferred data may be atypical for a particular device. However, to detect this kind of anomaly, you need to understand the roles of the devices at both ends of the connection and know which network activity patterns are typical for them.

But an organization’s asset inventory data is often incomplete, which makes it harder to catch unauthorized connections in time. Suppose monitoring detects a host that regularly exchanges data with programmable logic controllers (PLCs). Its IP address is known, but the inventory does not specify what role it plays: is it an engineering workstation, a process data server, or a piece of contractor’s equipment? The host may also have been on the industrial network for a long time, with its record going out of date after a network upgrade.

In the joint OT asset inventory guidance released by CISA and its partners in 2025, inventorying devices and classifying them by role are treated as part of OT asset management. For organizations, this is one of the most important areas: according to the SANS 2025 ICS security survey, 50% of respondents had deployed or significantly expanded ICS inventory and visibility tools over the previous 12 months, and 54% named them as investment priorities for the next 12–24 months.

Device inventory in Kaspersky Industrial CyberSecurity for Networks

In Kaspersky Industrial CyberSecurity for Networks, the Asset Discovery technology is the foundation of asset visibility. Passive network traffic analysis detects devices and their interactions, while recognition rules help determine the device category and extract available information about it, such as the vendor, model, or software version. Exactly which attributes the system can obtain depends on the protocol and the traffic it observes. We covered this in more detail at the Kaspersky Industrial Cybersecurity Conference.

The product also supports active polling modules (APMs): where polling is allowed, they can request additional configuration and firmware version details from devices. This kind of inventory is far more detailed than a list of IP addresses.

However, even accurate hardware information doesn’t always explain what function a host performs in a specific industrial facility. Gaps appear for various reasons. Some devices send identifying information only at startup or during configuration, while others rarely communicate. Proprietary protocols can’t always be parsed, and encryption may leave only connection metadata for analysis. If the monitoring system doesn’t receive traffic from every segment of the industrial network, some network activity goes unobserved. Active polling doesn’t suit every device or every operating condition.

When there isn’t enough direct information about a device, its category can be refined by looking at the patterns of its recurring network interactions. Analyzing these interactions is the job of Machine Learning Event Processor (MLEP), a service included in Kaspersky Industrial CyberSecurity for Networks 5.0. This machine-learning-based event processor can both refine device categories and detect anomalies in their network behavior.

What data does MLEP analyze?

To compare device behavior, you don’t need to store every packet as a separate observation (a data object) in the ML model. MLEP represents network sessions as a sequence of short 15-second fragments. For each fragment, MLEP stores information about the endpoints (IP, MAC, and port), the direction of data exchange, the protocol, and the number and size of the packets transmitted. Together these make up an event, which then gets a timestamp. Traffic thus becomes a sequence of events showing which hosts a device communicated with, when, and how communication intensity changed.

Aggregating data into events also sets the method’s limits. An aggregated fragment can’t be used to reconstruct the exact order of individual packets or the content of commands. MLEP can draw conclusions about a new protocol only if another KICS technology has managed to recognize it. That said, comparing stable network connections and changes in exchange volume doesn’t require a detailed record of every packet. These observations form the basis of the device’s behavioral history.

From observations to MLEP results

Each object has its own behavioral history, and one object’s history can’t be applied to another. But the principles of behavior analysis, along with some common rules, work across different objects.

Let’s look at how this works in MLEP, which is built on a spiking neural semantic network (NSN).

Event identification

Neurosemantic networks structure information as a multilayer ordered graph, where the data in each consecutive layer builds on the data in the previous one. The nodes of this graph — that is, the units of information in each layer — act as neurons.The NSN creates dedicated channels to handle different event parameters (port, IP, and so on). Unique parameter values for each channel are stored as neurons in layer 0. The event itself, which consists of a set of parameter values, is stored as a neuron in layer 1 of the network. If an event occurs for the first time, neurogenesis creates a new neuron with input connections to the corresponding parameter neurons. This lets the network learn and operate on the event stream at the same time. If the event has occurred before, the network activates the same neuron that was created when the event first appeared. This way, the network identifies each event precisely. Each neuron that corresponds to an event also collects basic statistics: when it was last activated and how many times it has been activated.
 

Event history

In NSN-based event processing, layer 2 and above store sequences of events over time: recurring patterns and the full history. However, categorization and statistical anomaly detection don’t require storing the full packet sequence or a detailed timeline of every network event. As we noted earlier, events are themselves aggregates, which means the order of network packets has already been averaged out. So MLEP keeps history only temporarily, within each episode (30,000 aggregated events by default), which saves computing resources.

Statistics processing in MLEP

MLEP processes statistics mainly through specialized listener neurons on layer −1 (minus one) of the network. Attention heads and monitors are built on these neurons.

When an event arrives, the corresponding neuron is activated, and the network instantly knows whether that neuron is new or was created earlier. Each attention head subscribes to the events or event features it needs and takes in only the activations of the matching neurons. If an event occurs for the first time, all heads are notified and then decide whether to subscribe (grow a connection to the relevant neuron) and receive information about activations of such neurons from then on.

It is called a spiking network because activation information is a spike, not a number. This spike tells the head that something it’s interested in has happened.

An attention head is configured according to scenarios — the situations that MLEP should send alerts about. The core of a head’s configuration is a query, which filters incoming information and serves as the subscription criterion. Unlike regular database queries, this query runs on the stream, so it can react to an event instantly.

Attention heads work very much like the semantics of ordinary human language. A query has a subject of attention (one or more grammatical subjects) and conditions (the other parts of the sentence). In the infrastructure of an industrial enterprise, the subjects are devices on the network, and the conditions are various aspects of network communication, such as ports, protocol, and average packet size. If a head has many subjects (for example, if it’s interested in every device on an industrial network), it fans out: it creates a child head for each individual value of the subject of attention, that is, each device. The child head then watches a specific device and reports to the parent head.

Attention heads don’t accumulate or process statistics. They only filter event streams. When an attention head receives a relevant event, it activates and sends a spike to the monitor subscribed to that head.

Monitors, in turn, have stacks for accumulating and processing events. They can also have their own queries and post-filter information from the head. For example, they can select only new events from those filtered by the head.

There are several types of monitors:

• Stat monitors track changes in the average count of specific events (for example, device activity) over time intervals typical for those events, or in the average values of numeric event parameters (for example, changes in device traffic volume).
• Monitors work from the event alone: they fire when an event has occurred a certain number of times within a given interval, or has occurred for the first time.
• Similar-behavior monitors work with heads that can generalize events, that is, extract just a few parameters whose combination is shared (generalized) across many events.

MLEP uses these monitor types to implement scenarios for categorizing devices and detecting their anomalous behavior:

1. For categorization, MLEP uses attention heads and monitors that identify common behavior across different assets and group devices accordingly. MLEP then takes information from Asset Discovery about the known categories of some assets and extends those categories to other assets in the same group. Because a device can show different types of activity, it may land in several groups. MLEP then makes a weighted assessment across all relevant groups.
   

   Groups of devices with similar network behavior

   At the final stage, the system verifies that assigning the category to the asset is permissible. This is again done by special rule monitors loaded into the NSN at system startup. The rules rely on asset metadata available from Asset Discovery and APMs.

2. MLEP takes a similar approach to anomaly detection: an attention head and a monitor define an anomaly scenario, often loosely. When a monitor activates on such a scenario, MLEP generates an alert about unusual behavior.

The current version of MLEP ships with preconfigured heads and monitors.

The functional dynamic diagram below shows how events from devices on an industrial network are processed.

MLEP in practice: how behavior helps complete the asset inventory

At a facility with several similar production lines, device information may be more complete on some lines than on others. On one line, devices are identified as PLCs, while on another, after an upgrade, some hosts show up only as addresses: the available traffic didn’t provide enough information to determine their category. Still, these devices communicate with the same types of HMIs and process data collection servers. Their communication directions, frequency, and volumes may be similar.

That’s where MLEP comes in. It takes the categories of already known assets and matches recurring features of their network behavior against those of uncategorized devices. When the observed interactions turn out to be similar, MLEP can add a category for that host to the inventory.

Once the category is refined, the industrial network map provides more context about the equipment on the network. When analyzing network activity, the analyst immediately sees the device’s suggested category and can skip looking up each IP address in the design diagrams. This approach is especially useful where equipment changes faster than the documentation is updated.

The suggested category is also checked against existing device information and defined constraints. This helps filter out some contradictory options, but prediction quality still depends on how much of the traffic is visible, especially if the device communicates only rarely.

Anomalous activity and streaming statistics

Investigations of real-world attacks show that attackers actively use both standard tools and permitted protocols. You don’t always need to know an attacker’s specific technique in advance to spot potentially malicious activity. Signature-based detection helps find known signs of an attack, but it doesn’t assess how typical an observed interaction is for a particular device. MLEP compares current activity with the device’s usual network profile: which hosts it communicates with, which protocols it uses, when and how much data it transmits, its average packet size, and so on. The changes it detects help guide the direction of the investigation. Correlating these changes with other events and the operational context helps determine whether malicious actions could be behind them. When investigating an incident that has already been detected, anomalies help reconstruct the sequence of actions.

The first version of MLEP comes with six preconfigured monitors, one for each type of deviation from the device’s usual network profile:

Anomaly	How it helps with event analysis
New external host	Flags a new external connection that wasn’t previously seen in the device’s observed behavior, even if the IP address isn’t listed among known IoCs. Helps check whether this connection appeared at the same time as other suspicious events.
New combination of destination address and port	Shows that the device has begun using a service it hasn’t used before. Once an incident has been detected, this helps trace new connections after the more critical events have been analyzed.
Unusually large volume of data sent	Highlights data transfers that are atypical for the device and helps correlate their timing and direction with other events.
Atypical activity time	Shows that the device was active at a time that’s unusual for it. In an already detected incident, this helps reconstruct the timeline of actions around the main alert.
New protocol	Helps spot a new method of communication, even when the device is communicating with familiar hosts.
Activity with signs of scanning	Shows that the device has started contacting an unusually large number of neighboring hosts. This signal helps reveal possible reconnaissance ahead of attempts to access equipment.

During an investigation, anomalies help reconstruct the sequence of changes: when a specific host established new connections, switched protocols, increased its data transfer volume, or shifted its operating hours. Matching events by device and time shows an analyst how activity unfolded around an incident that has already been detected.

This is especially useful when some of the attacker’s actions fell outside the monitored scope or didn’t trigger other KICS technologies. Correlating these changes with the device’s role, protocol analysis data, and events from other technologies gives the analyst a more complete timeline. Behavioral anomalies show exactly where to look for the missing links and which network interactions need attention.

In the event list, anomalies detected by MLEP are marked with an AI label. Each event shows its name, source, destination, timestamp, and the ID of the triggered scenario.

Conclusion

In an industrial network, whether behavior is anomalous depends on the host where it occurs and that host’s place in the industrial process. The repetitive nature of many communications makes a change in normal data exchange easier to spot, while knowing a device’s function and criticality helps gauge the possible consequences. Taken together, these observations make network traffic more than a list of connections: it helps assess new events in the context of a specific facility, even without an attack scenario known in advance. Machine learning technologies are well suited to this kind of comprehensive analysis, as they can process and organize huge streams of heterogeneous data. Starting with version 5.0, Kaspersky Industrial CyberSecurity for Networks handles this function with MLEP, which works effectively alongside the product’s existing functionality.

A modern organization protects its information systems with a whole suite of technologies that generate thousands of security alerts every day. Looking at these alerts in bulk, you’ll see that a significant share are false positives. Ideally, these alerts would be filtered out automatically so that analysts could focus on the ones that may point to a real incident. However, writing filters is a time-consuming task in itself. To create a correct filter, an analyst needs to:

• Review the logs
• Identify the source of the activity
• Define filtering boundaries
• Choose filtering criteria
• Write a rule
• Check that the filter is robust

This post looks at how filter creation itself can be automated to reduce analyst workload.

Filter validity criteria

In the context of security alerts, a filter is a combination of event field values that marks a detection as a false positive and not worth the analyst’s attention. Filters can be generated for any combination of event fields, but not every combination yields a valid filter. That’s why we need to define validity criteria: conditions showing that a specific filter actually removes noise and doesn’t suppress useful alerts.

Detection rules in security systems typically contain a set of conditions, and each of them can generate an alert. A specific event triggers a given fragment of a detection rule. The set of events that a given fragment responds to is what we’ll call its context. A good filter should cover the entire context where possible, without going beyond it. Filters that are too broad or too narrow are useless. For example, a filter based solely on PowerShell would exclude too many events, including some that deserve the analyst’s attention. Most of the filtered events would also be unrelated to the rule in question. A filter on a specific ID, on the other hand, would cover only one event, which may never recur.

Problems in filter generation

We can run into a number of problems when creating filters. First, events often contain an excessive number of fields (around 400 on average), and most of them aren’t needed for filtering. At the same time, generating and ranking combinations of these fields is also fairly resource-intensive. So, the first step is to discard the irrelevant fields and keep only those worth using in the filter. For example, out of 400 fields in an event, four may be enough for filtering.

Another problem is string normalization. Field values (for example, the path to the same application on different systems) can vary depending on system settings, user folder names, and so on. For a filter to account for all these variations, the strings must be normalized. For file paths, in particular, you can replace the drive letter and user folders with standard environment variables and convert all paths to a single case.

Finally, if a filter completely mirrors the query of a detection rule, it effectively disables that rule. To fix this, remove the event fields used in the detection rule from the filter. For example, if a rule triggers on a file path, there are two ways to filter out unwanted alerts:

• In the filter, use fields other than the file path.
• Use a part of the file path that the rule doesn’t use. For example, for the rule file_path: ".../something.exe", you can set up a filter that excludes events with the user/unique_files/ directory in the file path.

Filtering security alerts with an algorithm

Given the problems described above, automatically generating filters for security alerts should consist of the following steps:

1. An analyst receives a security alert that they assess as a false positive and uses the filter generator.
2. The generator takes the 400-field event from the alert, along with the rule that triggered on it, and determines the context.
3. The generator selects the fields that are relevant to the filter.
4. The generator normalizes the strings.
5. The generator builds different combinations of the selected fields. To do this, we applied the FP-Growth (frequent pattern growth) algorithm to the context determined earlier. FP Growth builds a tree of frequently occurring items (fields) from a dataset (in our case, the context) and discards items that aren’t frequent enough. This reduces the number of combinations to check, which lowers the cost of finding the most relevant ones.
6. The generator ranks the resulting combinations and offers the analyst the top three to choose from.

For example, consider an event described by the following JSON:

After generating and ranking the combinations, we got three filters based on file paths:

• processcmdline:("nodejs\\node.exe" AND "*****\\appdata\\roaming\\npm\/node_modules\/pi-coding-agent\/dist\/cli.js")

• file_path:"*****/.pi\\agent\\bin\\fd.exe"

• processcmdline: "programfiles\\nodejs\\node.exe"

The last filter turned out to be too broad, but the analyst marked the other two as valid.

Pros and cons of the algorithmic approach

The algorithmic approach to filter generation has several advantages. First, it’s simple and deterministic: the same alert always produces the same result. Second, it’s interpretable, meaning we can see why a given combination ranked near the top of the list and why a particular field didn’t make it into the list of candidate fields at all. Third, the stages of the process are independent of each other, so individual steps can be improved and tuned without the risk of breaking the algorithm elsewhere. Finally, it has no external dependencies or models, which makes it easy to deploy in any customer environment.

However, it also has drawbacks. The first is its dependence on context. If there’s no context for some reason — for example, the rule’s first-ever trigger — a filter can’t be created. The second problem is string normalization. There’s a high chance of running into atypical cases that the normalization rules don’t cover. Often such cases can’t be described correctly at all, because they contradict each other.

These problems can be solved with large language models (LLMs). When an LLM generates the filters, no context is needed, because the LLM doesn’t iterate over or rank combinations. The LLM also takes a more flexible approach to string normalization, including non-standard cases. That said, an LLM doesn’t have to be involved at every stage of the generation process. We decided to keep the algorithmic solution where it works well. For example, a simple algorithm selects suitable fields without errors, so we didn’t move this stage to the model.

Filter generation with an LLM

The LLM-based filter generation looks like this:

The input is still an alert containing an event with 400 fields, plus the rule that triggered on that event. Then an algorithm selects the most suitable fields for the filter. Next, the LLM processes the input — the event, the selected fields, and the detection rule — and generates three filter options along with an explanation for them. The explanation helps the analyst understand why these particular filters were suggested and make an informed choice.

Consider the following event in JSON format:

The LLM suggested three filter options that all contain the same command line fragment:

• file_path: "\\WindowsPowerShell\\powershell.exe" AND filecmdline: "Get-VM -Name kafka\*"

• filecmdline: "Get-VM -Name kafka\*"

• filecmdline: "kafka*"

As in the previous example, two of the three output filters were valid. The last one was too broad to be usable. The analyst chose the first filter with minor edits:

file_path: "powershell.exe" AND filecmdline: "Get-VM -Name kafka\*"

Pros and cons of generating filters with an LLM

Using an LLM solved the problems of purely algorithmic filter generation: dependence on context and errors in string normalization. However, the single-request approach had its own drawbacks. First, it had no output validation. The LLM returned filters as-is, with no syntax check and no way to correct errors. Second, unlike in the algorithmic version, all filter generation tasks were handled by a single system prompt. As a result, a minor fix in one place could break the logic in another.

Using multiple AI agents

To address the problems of generating filters with a single model and a single system prompt, we tried distributing the tasks across different LLM agents. In this version, we brought in agents as early as the stage of selecting relevant fields. The chain includes four agents in total:

• Selector: selects the relevant fields.
• Generator: generates filters.
• Validator: evaluates the generated filters. If the filters are found to be invalid, it returns the task to the generator. If the selected fields are found to be irrelevant, it starts a new field selection cycle. If the filters pass validation, or the limit on regeneration attempts is reached, the valid filters (or the best ones available) are passed to the analyst.
• Commentator: analyzes the output filters and explains which field values were used and why.

For the following JSON event, the agents produce three valid filters based on the file path.

The filters differ in the additional parameters that support the detection:

• file_path:"sysvol\\domain\\scripts\\logon.bat"

• file_path:"sysvol\\domain\\scripts\\logon.bat" AND file_md5:"0x7..6E"

• autorun_entry: "Group Policy\\State" AND file_path: "SYSVOL\\domain\\scripts\\logon.bat"

Pros and cons of the agent-based approach

LLM agents give us a system that can validate and correct filters. Its modular architecture also lets us tune and improve different stages of generation independently. However, this approach makes more LLM calls than the previous ones, so the system is slower. It also depends on access to a model, which may not be available in the organization’s isolated environment.

Evaluating the filter generation system

To evaluate how well the filter generation system works, we use two main metrics:

• Approval rate. For each security alert, the system suggests three filters. If the analyst selects at least one of them, we count the generation as successful. For example, in the case below, the approval rate is 2/3.
  
• False positive reduction rate (FP drop). This metric shows how much a filter helps reduce the number of false positives. It can only be measured over time, because we need to compare the number of false positive alerts received during a set period before and after the filter is deployed.

Below is a comparison of the three filter generation approaches by these metrics:

As the results show, LLMs significantly improve the efficiency of filter generation. At the same time, the LLM agentless and agent-based approaches perform almost identically. So we chose the simpler and faster option: an LLM with a single system prompt. As a result, we cut false positives by 99%, increased the number of filters generated per day by 28%, and made analysts’ alert handling 17% more efficient.

Takeaways

Practice has shown that filter generation can be automated effectively. We’ve looked at several options for automatically generating filters for false-positive security alerts: a purely algorithmic approach, an LLM-based approach, and an approach built on a group of LLM agents. All of them can generate valid filters and make the analyst’s work much easier, but each has its own pros and cons.

The algorithmic approach scored lower on the evaluation metrics, but in two-thirds of cases, it still produces filters that satisfy the analyst. It works especially well when there’s already a set of similar events to filter out, meaning enough context has accumulated. The algorithmic generator can also be deployed in any environment. Both standalone LLM and multi-agent LLM approaches show high accuracy, and their results differ only slightly, so the slower agent-based approach looks excessive at this stage. If an LLM is available, the best option appears to be a single model that handles several stages of the generation cycle.

Introduction

AI agents and associated tooling are becoming increasingly common in corporate infrastructure. Agents can perform a range of actions with the user’s privileges, such as accessing data, running commands, and interacting with external services. This creates new security risks, especially when these tools are used without the security team’s oversight or well-designed policies.

Detecting, tracking, and controlling AI agents is becoming one of the most pressing tasks for security teams today. We closely follow technological developments and continuously update our solutions to respond to new threats in a timely manner amid a rapidly changing technology landscape. This post describes new expertise built into Kaspersky products that helps counter the threats posed by the proliferation of AI agents. We approach this problem from several angles.

First, you need to thoroughly understand the threat you are dealing with. To this end, we added profiles to the Kaspersky Threat Intelligence Portal that describe various AI agents and how attackers exploit them. At their core, AI agents are programs (processes) that run in the operating system on endpoints and can also launch other processes. This means that Endpoint Detection and Response solutions are among the key endpoint controls for this threat. These solutions detect the presence and launch of AI agents, track their activity, and identify potentially dangerous behavior. When needed, they also take action, such as stopping a suspicious process, blocking the activity, or isolating the host, to reduce the likelihood of an incident escalating. For this purpose, we developed specially adapted detection rules.

You can use Kaspersky Endpoint Security, now also available as Kaspersky Next, to control and restrict the launch of AI agents. This solution uses two components to detect AI agents and control how they are used. Application Control categorizes the application processes launched on endpoints, and Web Control manages access to specific categories of web resources for users on endpoints.

Finally, even harmless AI agents can contain malicious instructions (skills), such as those downloaded from unsafe external sources. Kaspersky Scan Engine analyzes installed applications to detect these threats and also checks LLM files for malicious code. Let’s take a closer look at these solutions and technologies.

Popular AI applications and services in organizations

Tools from Anthropic and OpenAI take the top spots in the September 2026 ranking of AI agents by popularity among Kaspersky users. This list is based on telemetry from Kaspersky solutions. It shows the number of users who had the relevant AI vendors’ products installed at the time of the study.

#	AI product
1	Claude
2	Claude Code
3	Codex
4	OpenCode
5	Zed
6	Wispr Flow
7	LM Studio
8	ZCode
9	Chatbox
10	Cherry Studio

The data shows that agentic systems, especially AI agents for software development, are the most popular AI applications. The TOP 10 also includes an application for running large language models locally (LM Studio) and a voice note-taking app (Wispr Flow).

According to open sources, these are the most widely used AI services in 2026:

#	AI service
1	ChatGPT
2	Google Gemini
3	Claude
4	Grammarly
5	DeepSeek

While analyzing the most popular and widely used apps, our experts also noticed a sharp rise in vulnerable versions of AI-related software and services. From 2025 to date, more than 2500 vulnerabilities have been published:

Number of published vulnerabilities in LLMs, AI tools, and plugins with similar functionality, 2025–2026 (download)

* Data for previous quarters was updated and may differ slightly from previously published data.

Application Control and Web Control

To enforce the organization’s security policy for AI agents and other AI applications on the corporate network, Kaspersky products offer application control based on KL categories. These categories classify installed software and give you granular control over which approved applications can run in the organization.

Application Control analyzes the processes launched on endpoints, tracking which AI agents are running in corporate systems at any given moment, on which hosts, and under which accounts. Application Control also shows how long a given program has been in use.

This makes it easier for the Kaspersky Security Center (KSC) administrator to control applications. Administrators can use KL categories to allow or block AI agents inside the company for specific groups of employees.

Here is what this functionality looks like to KSC administrators:

For details on how to configure Application Control in KSC, follow this link.

In Kaspersky Endpoint Security (KES), Application Control can operate in two modes:

• Denylist. In this mode, Application Control lets users run any applications except those blocked by Application Control rules. This is the default mode.
• Allowlist. In this mode, Application Control blocks users from running any applications except those explicitly allowed by Application Control rules.

Below are the steps to configure Application Control to block AI tools.

Configuring Application Control for the AI Tools category in KES

With this setup, when a user tries to launch an AI agent, they get a notification and the agent doesn’t start.

For more on how to configure Application Control in KES, follow this link. Our public portal also lets you explore information on KL categories and the applications that fall under them, in particular details on how AI agents are categorized and how popular they are.

The View applications drop-down list shows products for a specific vendor.

Similarly, Web Control lets you manage user access to web resources. If a user tries to open a denylisted website, KES blocks access and shows a warning.

When configuring access, the administrator can block websites that provide AI as a service.

For more on configuring Web Control, follow this link. The help portal also provides information on website categories that can be assigned to resources to configure access control.

Kaspersky Endpoint Detection and Response

To an EDR solution, an AI agent is a regular process. It has its own executable, a tree of child processes, and network communications, all of which need to be monitored for suspicious activity. An attacker can use an AI agent as an automation tool. An AI agent installed as a legitimate user tool can also be leveraged in a ClickFix attack, where it executes a malicious instruction received from an untrusted source, such as a document, web page, or email. That said, unsafe actions by an agent do not always indicate an attack. There may be no malicious intent in the chain at all. An incident can result from what looks like an ordinary instruction from a user who doesn’t fully understand the consequences of having it executed. The mere fact that an agent was launched does not reveal whether it is being used in an attack. That is why Kaspersky EDR (KEDR) uses both conventional behavioral rules and rules written and adapted to detect AI tools. The latter identify risky agent actions and settings, and help determine which AI tool was involved in suspicious activity.

Conventional KEDR rules detect the vast majority of familiar malicious techniques, including when performed by an AI agent. A suspicious PowerShell launch, persistence via Task Scheduler, or an attempt to steal credentials leaves clear, identifiable traces. These traces look the same no matter what initiated the actions. The rules analyze launch parameters, process relationships, affected files, network activity, and other telemetry events.

For example, in a recent Armored Likho campaign, we found signs that AI had been used to create loader and dropper samples, which were later compiled with NSIS (Nullsoft Scriptable Install System). The key telltale artifacts were icons in the scripts and excessive comments on every function, which is uncharacteristic of human-written code. In addition, the group continues to generate new modules for its BusySnake Stealer and BusySnake RAT samples. For example, the attackers used AI to develop a module that runs multiple checks for virtual environment artifacts and calculates a score. Depending on the score, the sample either runs or exits with code 0. Even though the initial access samples, payloads, and their modules were AI-generated, the commands they execute via rundll32 and PowerShell are detected by the shell_creation_by_rundll32 and suspicious_powershell_cmd_or_script_spawning rules.

So, for detecting an attack like this, it is not important who wrote the loader, the payload, or its modules: they are given away by the commands they execute, process relationships, and other traces of activity in the system. AI can be involved both in preparing the code and in carrying out the attack directly on the device.

In the latter case, the attacker uses the agent to carry out their tasks and lets it choose and run the required commands within the privileges it has. For effective protection, it is critical to link suspicious actions back to the AI tool and the conditions under which it operates. In KEDR, several specialized rules handle this task.

We have created separate rules for popular AI agents, ai_agent_*_access_to_sensitive_file_**, where * is the tool name and ** is the operating system. They generate alerts when an agent accesses files that contain credentials, tokens, or keys.

The ai_agent_dangerous_execution_mode rule detects agents launched with auto-approval of all actions (so-called YOLO mode) or with the sandbox disabled. These settings do not indicate an attack on their own, but they let the agent perform dangerous actions without user confirmation.

The suspicious_mcp_server_artifact rule triggers when MCP server scripts are created or modified in hidden, temporary, or cache directories. Attackers can place an MCP server in these locations to quietly connect it to the agent: through the MCP server, they can pass instructions to the agent, call third-party tools, and access the user’s data.

The llm_api_access_by_unusual_apps rule generates an alert when an application on Windows, Linux, or macOS connects to the API of a known external LLM service, unless this activity falls under predefined exclusions. This helps spot model access by applications that do not normally behave this way.

Some Kaspersky EDR rules tag events for investigation but do not generate alerts. For example, the ai_agent_**_execution rules flag launches of known agents on Windows, Linux, and macOS. The local_ai_model_artifact rule records the creation or modification of AI model files in typical application, runtime, and cache directories. These events reveal AI tools on the device, including tools that run on local models and never call an external API.

Kaspersky Threat Intelligence Portal

AI agent profiles

The Kaspersky Threat Intelligence Portal offers a large number of software profiles, including profiles of AI agents. You can sort them by the ai_ prefix:

The profile of an AI agent such as Claude Desktop includes a detailed description of the software, the privilege level required to run it, supported platforms, and threat actor groups known to use it. It also lists tactics and techniques mapped to the MITRE ATT&CK framework, with descriptions of the procedures the tool can be used for.

The description also lists ways to detect the software through standard system auditing mechanisms:

• Windows: events from standard audit logs and Sysmon events
• Linux: syscall audit events and Sysmon events
• Network auditing: a set of protocols and the traffic generated by the software

The detection section lists the main artifacts the software leaves in the system: command lines, possible launch parameters, names of the services and scheduled tasks it creates, and the key network artifacts.

Hunt Hub

In December 2025, the Kaspersky Threat Intelligence Portal added Hunt Hub (HH), a repository of detection rules. This is a unique Kaspersky project, and we developed it in response to growing market demand.

This functionality is available in the Threat Landscape section of the portal. It gives analysts access to detection rules: their descriptions and their mapping to MITRE ATT&CK tactics and techniques, as well as to the associated cybercriminal groups.

In the Hunt Hub section, customers can explore the detection logic of EDR, NDR, and NGFW products, including the logic for detecting AI agents.

The rule card provides:

• Detailed description
• Rule’s severity level, confidence level, and alert format
• Detection tips
• Description of possible false positives
• Platforms the rule can run on
• Tactics, techniques, and sub-techniques covered by the rule
• Groups that use the technique covered by the rule
• Detection logic that shows what exactly triggers the rule

Kaspersky Scan Engine

Skills are a key component of the AI agent ecosystem. They’re prewritten sets of natural-language instructions that extend agent functionality. We previously covered the risks that malicious skills pose to agent users. A skill can require the usage of additional programs and services, come with helper scripts (for example, written in Python), or contain a malicious command embedded right in the instruction text. This means that adding skills to an originally harmless AI agent opens up several new ways for malicious code to enter the system. To prevent this, any skills obtained from external sources must be scanned. Kaspersky Scan Engine is well suited for this task. This is a cyberthreat detection and response solution that seamlessly integrates with various applications. It can detect malicious code in agent skills, associated scripts, and in files generated by running agents.

Trained LLMs come in many formats. Some of them (PTH, PT, PKL, KERS, and others) also store parameters and weights (training datasets). These files can also contain malicious code, so it’s critical to scan them before running and using them. Kaspersky Scan Engine scans potentially dangerous LLM formats for infected data. It can deserialize and analyze models to detect malicious code regardless of model size.

Conclusion

AI agents are rapidly making their way into corporate environments: they help employees work faster and take on a wide range of tasks, but they also open up new opportunities for attackers. To take advantage of this technology without compromising security, organizations need to build multi-layered protection and minimize risks. A range of Kaspersky solutions can help with this:

• Kaspersky TIP keeps you up to date on current scenarios in which attackers use AI agents, and its Hunt Hub section provides rules for detecting suspicious AI agent activity.
• Kaspersky EDR detects AI agents in the infrastructure and monitors their activity on endpoints. If it detects potentially dangerous actions, the product can log the event, notify the SOC, and take response actions, such as stopping the process or isolating the host.
• Application Control in Kaspersky products can fully restrict the use of AI agents within the company by using application categorization. The Web Control component can restrict access to AIaaS web resources.
• Kaspersky Scan Engine can be integrated into various company processes to detect malicious code in any files, including AI agent skills and LLMs.

When companies combine the tools described above in a comprehensive approach, they can adopt AI agents in an informed way: with an understanding of the associated risks and effective means of minimizing them.

Introduction

Imagine you’ve ordered a small paper unicorn from an online marketplace. You clicked “Buy”, received a cheerful notification, and expect a courier to bring the box tomorrow. If the unicorn is delayed by a day, it will be annoying but not catastrophic: an apology, a discount promo code — and the incident is forgotten.

Now let’s multiply one late unicorn by several hundred thousand orders.

Packages start heading to the wrong cities. The website shows an item is in stock, even though the required bin is empty. Conveyors stop, boxes get stuck between floors, the cargo piles up with no freight manifest. Trucks line up at the gates, and every minute of downtime turns into blown schedules, support tickets, fines, and lost sales.

It is at exactly this scale that a cyberincident in a warehouse becomes a problem for the entire business. A modern warehouse is no longer just a big building with shelving. It is a tightly interconnected hybrid system: web applications, radio channels, and an automated factory. Physical processes here depend on data, and errors in data have very physical consequences. Examples include an outage that affected warehouse management systems at the grocery giant Morrisons, and the 2025 Form 10-K annual report of United Natural Foods, Inc. (UNFI), which confirmed unauthorized activity on information technology systems that impacted order fulfillment. More recently, reports emerged that a cyberattack disrupted eight CEVA Logistics warehouses across Europe and exposed customer delivery data.

This paper follows a single order through a warehouse to show where the operation is vulnerable, the stages it traverses, the systems that drive it, and the points where an attacker can reach them. We then set out the threat model: what is at risk, who is in a position to take it, and how each risk lands on the business. From there, we look at how an attacker gets in, and what reaching the warehouse management system costs in practical terms: orders unshipped, inventory records nobody can trust, and an operation that stops. We close with recommendations on where the controls that matter actually sit.

Tracing the unicorn

A modern warehouse is a sequence of stages involving many machines and people, all working together to keep the business process stable so that, in the end, your order gets delivered. This process consists of eight main stages, shown in the figure below.

So let’s assume we’ve ordered our paper unicorn and are waiting for it at home. Let’s follow our order through all the main stages, from its arrival at the warehouse to the final stop on its journey.

1. Unloading
   First, the unicorn arrives in the unloading zone, packed in a big truck. The driver is assigned a gate, for example, via a tablet with kiosk mode enabled, or an outdoor display board, indicating where the truck should park and where the cargo will be unloaded. Even at this very first step, a digital command (the gate number on the screen) is already triggering a physical action. Therefore, incorrectly assigned gates can create a queue, delay unloading, or send goods into the wrong workflow.
2. Receiving
   At this stage, employees identify the cargo. They scan a barcode using a portable data terminal (PDT) and the central system receives a message indicating that this object arrives at the warehouse. From this moment, the unicorn exists in two forms at once: as a real box and as a record in the information system. If these two versions diverge, the error is inherited by all subsequent processes.
3. Putaway
   Next, the goods are moved into internal storage. Two new devices come into play here. First, a thermal printer, connected to the internal network over Wi-Fi, creates an internal label for each item. Then an employee, forklift, or automated system moves the goods to the assigned bin, often with the help of lifts controlled by PLCs. Both of these devices can be valuable attack entry points: one can let an adversary pivot into the internal network, while the other can give them control over an electric motor.
4. Storage
   Then the unicorn goes into storage. Many distribution centers use multi-level mezzanine structures: several floors of metal shelving inside a huge space. They allow efficient use of the building’s height, but at the same time complicate control over the technical infrastructure. Wi-Fi access points, cameras, switches, cables, and sensors may be mounted high overhead or buried deep inside the rows. A forgotten Ethernet cable or misconfigured networked device (access point or switch) left behind in a dark corner can become a convenient initial access point into critical infrastructure.
5. Picking
   When the customer places an order, picking begins if the goods were already stored in the warehouse or as soon as they are unloaded. A PDT, workstation, light indicator, or voice terminal directs the employee to the required bin where they pick the goods and move them to the next stage. These devices are themselves potential attack entry points: compromising a workstation or PDT could allow an attacker to manipulate picking information, which could misdirect employees to the wrong bin. Here, both the speed and integrity of the information are critical, and any manipulation or disruption can lead to wrong orders, delays, or problems in subsequent stages.
6. Sorting
   At the sorting stage, the warehouse starts to look more like a factory. Boxes move through conveyor belts and pass through different scanners, diverters, and chutes. The sorting plans are usually stored and managed by dedicated servers, while PLCs are responsible for controlling the machinery and executing these plans. For example, when the warehouse management system (WMS) decides that our unicorn should take route A, the control system needs to activate the right diverter at the right moment, sometimes within a fraction of a second.
7. Packing
   During packing, an employee or a robotic arm places the goods into the final box, prints the shipping label, and sometimes measures the dimensions and weight of the package. Safety mechanisms usually prevent robotic arms from leaving the controlled zone and harming nearby operators, but their compromise might inflict physical damage on the packages being processed.
8. Shipment
   Finally, at the shipping stage, the parcel heads to the gates. Automated guided vehicles (AGVs) and autonomous mobile robots (AMRs) move containers and pallets across the warehouse, while the dock management system coordinates the truck that will carry the unicorn onward to a store, a sorting center, or straight to the customer. These robots are themselves a potential target for attackers. Attacks can be conducted against AGVs and AMRs to interfere with their operation, for example by affecting their navigation or preventing them from reaching their intended destination.

All eight stages are coordinated by the WMS. It looks like a large web application, but in its role it’s closer to the operating system of the entire warehouse: it knows which goods exist, where they’re located, who or what should move them, and where they go next, linking employees, inventory levels, storage addresses, tasks, and orders. It also exchanges data externally: with ERP systems, transport platforms, marketplaces, dark stores, and external carriers.

Surrounding the WMS is an even larger digital ecosystem: identity services, databases, APIs, printers, carrier systems, technicians’ laptops, video surveillance, access control, fire and gas alarms, power supply, and a building management system (BMS).

That is why a single “warehouse network” doesn’t really exist. As we’ve seen, there are many overlapping technologies — IT infrastructure, OT systems, radio, cloud services, building security, and automation — layered on top of one another. A lone vulnerability scanner will never tell you whether a warehouse is secure.

Hunting the unicorn

Securing an environment such as a warehouse requires a comprehensive security assessment covering all of its interconnected systems. This involves identifying vulnerabilities across each system and understanding how weaknesses can be combined into attack paths that a real attacker could exploit. But a vulnerability only matters in proportion to what it exposes and who is able to reach it, so before looking at the weaknesses themselves, we need to understand what an attacker in this environment is actually after, because in a warehouse, the blast radius extends well beyond data. Everything we just traced — the systems, the devices, and the people operating them — exists to keep goods moving, and attacks in various parts along that chain can affect the business differently. The chart below shows what is at risk in the warehouse and where those risks land for the business. The segment on the left groups them under the three core security properties: integrity, availability, and confidentiality. The segment on the right maps each property to the business outcomes a failure can cause.

The first area at risk is integrity. Inventory counts, locations, orders, and shipment data must stay in sync with the physical world. Corrupting a record silently desynchronizes the operation, and because the eight stages form a dependency chain, one falsified entry early on is inherited downstream, surfacing later as stockouts and mis-shipments. In its deliberate forms, this lets an attacker redirect goods, release stock, and perform other actions on behalf of the platform’s vendors under cover of legitimate records. Integrity is also a safety concern: when people or machines act on information that no longer reflects the physical environment, a data failure can become a physical incident. This is why integrity is the only property linked to all five outcomes, including harm to people.

The second is availability, the warehouse’s ability to keep goods moving. Halting a conveyor, a sorter, label printing, or the WMS stops orders from shipping, and in a business built on speed, every hour of downtime means delayed deliveries and broken promises. Ransomware can bring the whole warehouse to a standstill. The impact shows up as operational disruption, lost revenue, and reputational damage.

The third is confidentiality. Customer data, business records, and system credentials are valuable targets. Their exposure leads to legal liability and reputational damage, and stolen credentials often open the door to further attacks. Where the WMS connects to financial or ERP processes, the risk extends to theft of funds.
Knowing what is at risk tells us what an attacker stands to gain; the next question is who is in a position to take it. Threat actors differ in the access they already hold. For example, an attacker may be authenticated and privileged, have limited physical or remote access, or have no legitimate access to the environment at all. Based on their relationship with the warehouse and their level of access, threat actors can generally be divided into two categories:

1. External. An attacker with no legitimate relationship with the warehouse or the organization, operating without authorized access. External attackers can be divided into two categories based on their physical proximity to the environment:
   1. Remote. An attacker operating from outside the site’s physical area, reaching the environment through whatever the organization exposes or makes reachable over the internet, including web services, remote access infrastructure, and third-party connections used by suppliers, carriers, and integrators.
   2. Proximate. An attacker with no legitimate access who has nevertheless moved within physical range of the site’s locally reachable technologies. They may, for example, be in a parking lot, a neighboring unit, or a delivery bay. Their proximity may allow them to interact with wireless, radio, Bluetooth, or other short-range interfaces without possessing an account, badge, employment relationship, or other authorized access.
2. Internal. An individual with legitimate access to the warehouse, its systems, or its information, who intentionally or unintentionally creates a security risk. This includes employees, administrators, operators, contractors, and temporary staff.

Combining these threat actors and their access levels with the risks identified earlier, the vulnerabilities present in each system, the resulting attack surfaces, and the potential attack paths between them provides a threat model for the warehouse environment. This allows an organization to understand how different systems and people could be targeted, how individual weaknesses could be combined, and where security controls are most needed.

Cornering the unicorn

Knowing what is at risk and who might come after it still leaves the most practical question open: how they would actually get in, and how far they could go once they did. The diagram below sets out the warehouse’s attack surface: every point where an attacker can get in, organized by the access that reaching each point requires.

On the left are the attacker categories discussed above, distinguished by where they stand and what access they already hold. Each reaches the environment through a different set of entry points, and the impact of a successful attack can land on several systems, from the WMS to OT systems such as robots, sorters, and physical access control system (PACS). The WMS is highlighted because it is the most significant of these: it coordinates the OT systems, so compromising it can affect the entire operation rather than a single process.

Next, we will cover the initial access vectors, the points a threat actor can use to reach the warehouse environment. Following that, we turn to the impact on the logistics processes themselves, focusing on the WMS, since its compromise affects every logistics operation that depends on it.

Initial attack vectors

Internet-facing services

Remote access through internet-facing services, third-party connections, and corporate networks gives an external attacker a foothold on the warehouse network infrastructure. It is a well-covered problem and not specific to this environment, so we note it here as an entry point but will not examine it further.

Wi-Fi, Bluetooth, and other radio channels

Wi-Fi connects handhelds, tablets, printers, cameras, and workstations. Bluetooth serves scanners, headsets, and positioning beacons. Zigbee and similar low-power protocols run lighting, sensors, and building automation, while LoRaWAN carries telemetry over long distances. Cellular provides a backup channel for kiosks and contractor equipment, and proprietary protocols control industrial panels and specialized machinery.

Radio passes through windows, gates, roofing, and thin external panels, so a network built for receiving and processing goods may be reachable from the parking lot and, with a directional antenna, from considerably farther away.

That reach matters in two ways. It gives an external attacker a place to start, as proximity alone is enough to reach the Wi-Fi and the low-power protocols, and from there to gain an initial foothold in the warehouse networks.

However, radio does not only lead into the network. It also connects directly to the field devices and carries the live control traffic of warehouse operations, which makes availability a first-order concern. If hundreds of handhelds lose their connection at once, picking stops. If an AGV loses its control channel, the safe reaction may be to halt in place, and a stopped machine can block an entire route.

Physical network

The scale of the warehouse itself is part of the attack surface. A fulfillment warehouse can run up to tens of thousands of square meters, with racking climbing several stories and walkways threading through it. Structured cabling runs along that racking, cameras and access points are mounted on that, and wall jacks sit behind pallets that have not moved in months. Almost none of it is in anyone’s line of sight.

That gives a person in the warehouse something a normal office does not: unsupervised access to live network infrastructure. Unplugging a ceiling camera leaves an active port. An unused jack behind a shelf leaves another. Neither requires tools, credentials, or any interaction with a system that logs anything. And since the camera or access point sits on the same segment as the rest of the site, the compromised port, not being isolated, opens a path to the network core.

Barcode scanners

Barcode scanners are everywhere in a warehouse. They are the main tool workers use to tell the system what is moving and where, supporting receiving, picking, packing, and inventory management. A typical setup has handheld scanners communicating with a base station, which is in turn connected to a workstation or another business system.

This makes the scanner an entry point into the core network in two ways.

First, through the barcode itself. Since the scanner acts as a keyboard to the connected host, a maliciously crafted barcode or QR code can inject keystrokes when scanned, potentially giving the attacker an initial foothold on the host without directly accessing the network.

Second, through the scanner’s wireless link. During a customer engagement, with the provided test stand of such a device, we discovered that an attacker within range could inject keystrokes into the connected host and potentially achieve remote code execution without user interaction. This attack pattern was observed across multiple vendors, including, for example, Honeywell devices affected by CVE-2026-4272.

In both cases, the result is the same: a foothold on a host inside the warehouse network. The scanner is simply the entry point; the significance of that foothold comes from the host’s trusted position within the operational environment and its connectivity to core systems.

Portable data terminals

Portable data terminals (PDTs) are essentially ordinary Android devices with an embedded barcode scanner, carried by workers to scan items; each scan is passed to a dedicated application that forwards it to a remote server over an API. To keep workers on task, the devices usually run in kiosk mode, locking the user to that single application and preventing interaction with the rest of the Android system.

That lockdown is exactly what an attacker wants to break, and breaking it is what turns the terminal into an initial access vector: escaping the kiosk can expose the Wi-Fi password of the network the terminal is connected to, or allow malicious software to be installed that gives the attacker remote access to the network over the internet.

Printers

Warehouses contain different types of printers. Alongside the usual IT printers used for documents and paperwork, there are specialized thermal printers, small devices that use heated elements on the printhead to create labels, barcodes, and tags. As we mentioned earlier, these are mainly used to print the labels, usually containing barcodes, that are attached to goods during the putaway stage.

Here we focus on mobile thermal printers: small, battery-powered devices that workers can carry or wear. They typically connect to the internal network over Wi-Fi to receive print commands, while also supporting Bluetooth for connecting to nearby devices. This combination makes them a potential entry point into the internal network.

Some models, such as the Zebra ZQ630, support multiple interfaces and can run applications directly on the device. During a security assessment, we discovered that apps can be uploaded and executed over Bluetooth. By exploiting a pairing misconfiguration, an attacker within Bluetooth range could bypass pairing, upload malicious software, and gain an initial foothold through the printer.

Impact on logistics processes (attacks on WMS)

With a foothold in the network, an attacker can pivot to the logistics processes themselves: from the WMS through the warehouse infrastructure to the PLCs and the machinery they drive. As we saw earlier, all OT systems and devices are interconnected and the WMS sits at the head of that chain: it is the system of record every other process reads from and writes to, so compromising it reaches all of them at once. That, and its being specific to this environment, is why it is the focus here.

Warehouse management systems (WMS) are the software platforms that optimize warehouse processes from the entry of goods to their exit. They provide real-time visibility into inventory and orchestrate end-to-end fulfillment by integrating with many warehouse subsystems and pieces of automation equipment, such as conveyors, PLCs, robotics, scanners, and voice systems. A typical WMS includes modules for receiving, inventory control, order management, labor management, shipping, and reporting. Major vendors include SAP EWM, Oracle Warehouse Management, Manhattan Active, Blue Yonder, Infor, Körber/HighJump, Microsoft, and TECSYS.

To picture how central this is, think back to our unicorn. From the moment it was scanned at receiving, it stopped being only a physical box and became a record inside the WMS, a record the system then used to decide where it should be stored, when it should be picked, how it should be sorted, and where it should ship. Every device employed along the way — the PDT at receiving, the printer at putaway, the workstation at picking, the conveyor at sorting — was really just talking to the WMS. It is the thread that ties all eight stages together, which is exactly what makes it such a valuable target.

Because modern WMS platforms are usually web-based and heavily interconnected, they inherit common web and API vulnerabilities alongside flaws specific to the WMS itself. A recent example is CVE-2026-70774 in Oracle Warehouse Management, part of Oracle E-Business Suite. Oracle rated it High and described it as an easily exploitable authorization bypass flaw in which a low-privileged attacker with network access can compromise the application, affecting integrity and availability by allowing unauthorized creation, deletion, or modification of critical data.

A flaw like this may look like a typical web application issue, but its consequences in a warehouse are more serious, because the WMS is the system of record. If an attacker can modify its data, they can alter stock levels, bin locations, receiving records, picking tasks, or shipment information, silently corrupting the digital twin of the warehouse. And since the eight stages form a dependency chain, that corruption doesn’t stay contained: a falsified record at receiving is inherited by putaway, picking, and everything downstream. The physical box and its record diverge, and every later process trusts the record.

The most direct version of this attack comes from an authorization bypass flaw like the Oracle vulnerability above. Here the threat actor can be an external attacker who has reached the application over the network, or an insider such as a low-privileged operator or storekeeper who already holds a legitimate account.

The danger grows when such a flaw is chained with others. An external attacker who combines remote code execution with SQL injection could generate shipment orders to arbitrary addresses together with the documents needed for goods to physically leave the warehouse, fabricate waybills, acceptance or transfer records, and registers, while also exposing customer data such as names and delivery addresses. In effect, the goods are sent out with legitimate-looking paperwork.

This is why ordinary web vulnerabilities carry considerable weight in a WMS. For an external attacker or an insider probing beyond their assigned role, broken access control could open a path into another warehouse zone, allow manipulation of other workers’ tasks, permit unauthorized exception operations, or expose administrative APIs. A server-side request forgery flaw could force the WMS server to reach resources an external attacker cannot touch directly, and if the network is flat or only formally segmented, that server may in turn reach internal management panels, cloud service interfaces, or systems sitting close to the operational network, turning a single web bug into a bridge between IT and OT.

Attacks on a WMS don’t always target the application directly, though. As we saw while tracing the unicorn, the warehouse is full of connected devices that already hold trusted access. A handheld terminal carries authenticated WMS API access as a matter of course, and anyone who gains control of that terminal inherits it (by escaping the kiosk, for example). Depending on the device’s permissions, that might mean confirming picks that never occurred, falsifying receiving operations, adjusting stock counts, or marking orders complete — something warehouse employees themselves could use to avoid their assigned duties.

Where the WMS is connected to control and automation systems, access to the WMS can extend into physical operations, including conveyors, sorting systems, lifts, doors, and pumps.

PLCs translate WMS instructions and sensor inputs into physical actions. Compromising a system that controls them therefore creates an opportunity to manipulate those actions. The impact can be as simple as a sorting diverter sending boxes down the wrong route, a conveyor repeatedly entering an error state and creating a backlog, or a falsified sensor value causing a line to be treated as clear when it is full.

However the WMS is compromised, the business consequence is the same: inventory corruption, unauthorized shipments, and operational disruption, each reaching the customer in the end as a late or missing delivery, the wrong item in the box, or a personal address exposed to a stranger.

Securing the unicorn

We followed our unicorn through web applications and databases, radio channels and PDTs, printers, conveyors, robots, and the loading zone. Because warehouse environments combine IT, OT, wireless, physical, and human components, security controls should be implemented as a single, coordinated security architecture rather than as isolated measures. Network segmentation should be a foundational control, with clear separation between corporate IT, warehouse OT, operational devices, management networks, and externally connected systems. Segmentation should also extend across facilities and customer environments so that each site and customer integration is isolated from the others, limiting the potential impact of a compromise. A zero-trust approach should reinforce this architecture by requiring explicit authentication and authorization for connections between systems, regardless of their network location, and by applying least-privilege access wherever possible. Regular penetration testing of the corporate IT environment, including domain services, identity infrastructure, and endpoints, should be incorporated into the warehouse security program.

Physical and network access controls should be implemented together. Access to warehouse facilities, network rooms, communication cabinets, and operational areas should be restricted according to business need, with appropriate authentication, monitoring, and access logging. Network infrastructure should be hardened through controls such as switch port security, MAC-based access restrictions where appropriate, and IEEE 802.1X with EAP-TLS for strong device and user authentication. Network equipment should also be securely configured and regularly reviewed to ensure that unused interfaces, insecure management protocols, default credentials, and unnecessary services are disabled.

Web applications and their supporting infrastructure should be governed through a secure software development lifecycle (SSDLC), including security requirements, secure coding practices, code and dependency review, and application security assessment before deployment and throughout the application’s lifecycle. Third-party applications and components should be continuously monitored and updated, with a defined vulnerability and patch management process. This should explicitly include warehouse management systems (WMS), warehouse portals, APIs, and other applications that provide operational or customer-facing functionality.

Wireless technologies should be subject to dedicated security assessment and engineering. Radio-frequency surveys should be conducted to establish expected coverage, identify unauthorized or unexpected signals, validate the availability and protection of operational communications, and determine whether wireless deployments create unintended access paths into warehouse networks. Wireless security should be assessed not only from a connectivity perspective but also in terms of authentication, encryption, device provisioning, protocol exposure, interference resilience, and the potential impact of unauthorized devices.

Warehouse operational devices should be incorporated into the organization’s endpoint security and vulnerability management processes. Devices should receive security updates and firmware patches on a defined schedule, with accelerated remediation for critical vulnerabilities. Security assessments should be performed periodically to identify weaknesses in device configuration, applications, exposed services, and authentication mechanisms.

Personnel security should form an additional layer of the warehouse security architecture. In most industrial and ICS environments, getting inside means clearing background checks, holding relevant qualifications, or proving prior experience; the hiring process itself acts as a filter. A warehouse is different. Roles in sorting, packing, and courier work are hired quickly and in volume, and they typically require no prior expertise, certification, or specialized background at all. An ordinary person can walk in off the street, be hired within days, and immediately hold legitimate physical access to the facility. Therefore, a more restrictive and risk-based approach to hiring should be considered, particularly for roles that provide access to sensitive areas, operational systems, network infrastructure, or customer assets.

Ultimately, all of these measures serve the same objective: protecting the continuity and reliability of the warehouse as a whole. This matters because real warehouses handle food, medicines, machine parts, and the millions of ordinary things people and companies depend on every day. Protecting their journey means seeing the warehouse as it has actually become: a single digital system with doors, motors, shelving, and radio signals, and with entirely real consequences when it fails. And if the security program works, the customer never knows any of this happened. The unicorn simply arrives at the scheduled time.

If your warehouse operations rely on interconnected systems like these, we can help identify the gaps before an adversary does. Reach out to discuss a security assessment.

Introduction

Once the attacker has breached the corporate network, subsequent stages of the attack often involve leveraging standard domain infrastructure protocols: using Kerberos, running DNS queries, accessing internal services, opening network shares, and other common networking actions. Because this activity is virtually indistinguishable from legitimate network traffic, it is extremely difficult to detect it with traditional network attack detection tools.
Kerberoasting and DNS tunneling have long ceased to be exotic techniques. They are becoming standard methods in modern attacks because they allow attackers to execute critical compromise stages while remaining undetected by traditional security tools. A clear example of this trend is seen in latest campaigns, employing both Kerberoasting and DNS tunneling.

Traditional network security tools perform well when the attack features a distinct and identifiable indicator: a characteristic query string, a known malicious traffic pattern, or the source code of an already discovered exploit. While this approach to threat detection remains effective, it cannot always be applied to discovering network attacks that blend seamlessly with legitimate traffic inside a corporate network.

Instead of searching for explicit indicators of attack, Network Anomaly Detection (NAD) analyzes all traffic for suspicious artifacts that deviate from the host’s typical network activity. Within Kaspersky’s solution portfolio, this technology is implemented specifically in the Kaspersky Anti Targeted Attack (KATA) platform.

The system analyzes network traffic data (DNS, DCE/RPC, Kerberos and other packets) and extracts key parameters used to identify anomalous behavior. This approach enables searching for attacks on domain controllers, signs of traffic tunneling and exfiltration, C2 communications, and other scenarios that may point to compromise of network infrastructure.

However, Network Anomaly Detection is not built on a single, universal set of indicators. Each attack scenario employs tailored detection models that account for the specifics of the corresponding network protocol, typical host behavior, and characteristic deviations from that baseline. This article examines two practical examples – detecting Kerberoasting and DNS tunneling – to demonstrate how these principles are implemented in KATA’s NAD rules and why this approach proves more effective than traditional signature-based analysis.

Kerberoasting attack detection by KATA

Why standard tools have a hard time detecting Kerberoasting

The Kerberoasting attack leverages the standard operational logic of the Kerberos protocol. The attacker identifies service accounts configured with a Service Principal Name (SPN), requests a Ticket-Granting Service (TGS) ticket for them, and attempts to crack the password offline using a dictionary attack against the retrieved ticket. If the password is weak or hasn’t been changed in a long time, the adversary can bruteforce it to get it in cleartext. Subsequently, these compromised credentials can be leveraged for both vertical and horizontal movement across the network.

The essence of a Kerberoasting attack is that an adversary possessing a compromised low-privileged account and a valid Ticket-Granting Ticket (TGT) for that account can request TGS tickets with weakened encryption for service accounts with SPNs. Crucially, it doesn’t matter whether the compromised account actually holds access permissions for those services. Having obtained these tickets, the attacker can then take them offline and bruteforce the service account’s password by trying to decrypt the corresponding ticket locally, without generating any network activity. As the encryption key is based on the password hash, the adversary can guess the password upon finding the correct key.

The attacker’s objective is to find a service account that has a simple password. Most likely, this will be an account created manually by the administrators of the infrastructure or a service. This is precisely why attackers are not interested in system service accounts with SPNs (such as CIFS/fileserver.company.local); these are generated automatically and feature highly complex passwords that are impossible to bruteforce.

We should note that the TGS ticket requests made by attackers are identical to standard, legitimate requests. Every domain naturally exhibits a high volume of Kerberos traffic. Therein lies the primary challenge of detecting Kerberoasting: legitimate service ticket requests (TGS-REQ) are indistinguishable from those issued by attackers. Consequently, the primary detection method relies on correlating indirect indicators rather than signature matching. Key indicators include an anomalous request source (atypical host or user account), a surge in requested SPNs within a short time window, attempts to obtain service tickets for sensitive or privileged service accounts, and off-hour timing or unusual request volume when benchmarked against the historical profile of both the user and the host.

Most of these indicators can be detected using NAD technology, which helps analysts cut through high volumes of Kerberos traffic to establish a concrete hypothesis: who initiated the Kerberoasting attack, which service accounts are at risk, and why this activity deviates from the baseline.

In the context of this attack, the network anomaly stems from a single host – likely using a single user account (cname) – receiving TGS tickets ("msg_type": "KRB_TGS_REP") for numerous unique services with SPNs (sname) within a short timeframe. These service accounts are non-system accounts.

To detect this anomaly, the NAD rule titled “Signs of a Kerberoasting attack” implements the following logic:

1. From Kerberos network sessions during the search depth period, select only those with a successful Kerberos TGS-REP response, subject to the following conditions:
   • The IP address that initiated the session must not be excluded in the excl_sip variable.
   • The requesting client name (cname) must not be included in the excluded users list (excl_users variable).
   • The SPN (sname) must not be excluded within the rule. System SPNs are omitted from detection logic because they exist across most corporate environments and hold no interest for adversaries in this attack vector; including them in the total count of unique SPNs could lead to predefined threshold being exceeded, triggering false positives.
2. Extract the cname (the name of the client requesting the TGS-REQ) and sname (SPN itself) from these qualifying sessions.
3. Group the sessions by the source IP address and client account name (cname), while aggregating sessions with unique SPNs.
4. Generate an alert if a single IP address using a single client account receives TGS-REP responses for N unique SPN names within the specified search depth window, where N equals or exceeds the threshold variable count_spns.
5. Within the event regeneration window, group under the initial alert all subsequent alerts associated with the same client IP address. This avoids creating duplicate event records by incrementing the aggregation counter (Total appearances).

We should note that this type of logic cannot be implemented using IDS signatures. Consider creating a Suricata rule designed to detect Kerberos TGS-REP packets. To minimize false positives, we’ll exclude system SPNs (which carry highly complex passwords) and apply a threshold for the number of responses a single client can receive. However, such a rule cannot evaluate the uniqueness of the requested SPNs; it can only track packet counts. As a result, this signature would produce a high volume of false positives because any domain naturally generates large amounts of identical legitimate TGS-REP messages.

Furthermore, adding exclusions and tuning thresholds to fit your specific infrastructure environments is significantly more practical when managed through user variables in the interface rather than directly modifying the underlying structure of the IDS rule itself.

Creating a Network Anomaly Detection rule

Network Anomaly Detection (NAD) rules are written as SQL queries executed against KATA’s ClickHouse database. Below, we demonstrate how to add and deploy a rule.

To begin working with NAD rules, navigate to the “Custom rules” section of the interface and select “Intrusion detection”. Under the “Network Anomaly Detection” tab, you can create a new rule.

When adding a new rule, an analyst can select an appropriate rule template from the prebuilt set supplied with product updates. They can also manually modify the rule added from the template (converting it to a custom rule while keeping the original template intact) or author a rule from scratch using the provided guide.

Upon selecting a template, the analyst can review the rule description and either adjust or leave the default values for the following settings:

• Search depth (the lookback window over which the SQL query will run)
• Schedule (the execution frequency for running the query against the specified search depth)
• Event regeneration period (the timeframe during which identical alerts will be aggregated into a single record rather than displayed as distinct events)

To ensure the rule functions correctly, we recommend navigating to the “SQL-specific query” tab before deployment to review the variables used within the rule – a description for each variable is available by hovering over the question mark icon.

The variables are lists of IP addresses, dates, strings or numeric values that define the network infrastructure – such as domain controllers, DNS servers, time ranges, critical segments, and other entities. This allows you to tailor each rule to different network environments and incorporate specific infrastructure characteristics without modifying the underlying logic.

In our example, using variables allows you to adjust the “Signs of a Kerberoasting attack” rule as follows without altering the underlying SQL query:

• Exclude the source IP address of the TGS-REQ requests from the scope of detection logic (you can specify a single address, a subnet mask, or a dictionary containing addresses and subnets) as well as the requesting client account (accepts a single value or a dictionary with multiple values).
• Adjust the threshold value required to trigger an alert based on the number of unique SPNs in the TGS-REQ messages.

On this same page, you can test if the rule is functional prior to saving it.

When this rule triggers, an NDR:NAD alert is generated. In the alert card, the analyst can review basic information: IP addresses, ports, and participating network endpoints.

From there, the analyst can navigate to the associated event, which provides a detailed breakdown of the anomaly alongside links to the affected hosts.

If needed, the analyst can view and export the network sessions associated with the alert. These sessions can be accessed directly from the alert or within the event card via the “Show related” drop-down list.

Within an individual session, the analyst can inspect standard details including interacting parties, data volume sent and received, and other fields and metrics. On the “Attributes” tab, the analyst can review the specific events recorded within that session.

Detecting DNS tunneling in KATA

How DNS tunnels work

DNS tunneling is a technique used to transmit data or control malware through firewalls by encoding information within DNS protocol requests and responses. Instead of performing standard name resolution, an infected host transmits data encoded within subdomain strings and receives response data via DNS records. This covert channel can be leveraged for C2 communication, bypassing network restrictions, or data exfiltration.

One method of implementing DNS tunneling involves utilizing TXT records. In this scenario, the client issues DNS TXT record queries for domain names where the right-hand portion of the domain name (the higher-level domains) remains static, while the left-hand portion (the lowest-level subdomain) carries encoded or encrypted data sent from the client to the server. Under this structure, a sample domain name might look like ZFcABQAIBA[.]testlab[.]local, where testlab[.]local serves as the static right-hand portion and ZFcABQAIBA represents the variable left-hand string containing the data transmitted by the client.

In response to these queries, the server delivers commands or messages inside the data field of the TXT response. Because the right-hand portion of the domain name remains static, all client queries are consistently routed to the same C2 server, even if the intermediate DNS resolvers targeted by the client change.

It is rather challenging to identify this malicious activity within DNS traffic without generating false positives. DNS traffic is permitted across almost all corporate networks, long domain names occur routinely in both internal and external environments, and TXT records are frequently leveraged for legitimate operational purposes.

Suspicion is established through a combination of indicators: a high volume of long, seemingly random subdomains associated with a single top-level domain, high request frequency, an unusually large number of unique names, non-standard record types, and significant data transfer volumes within a single DNS session.

By analyzing DNS traffic for threat detection, we identified three primary fields of interest:

• Requested DNS name
• DNS record type
• TXT data field within the response

As shown in the image above, all of these fields are present in the DNS response. In a real-world scenario, a tunnel of this nature will transmit a volume of data that is abnormally large compared to standard DNS traffic.

Thus, in the context of DNS tunneling, a network anomaly occurs when 1) a single query source host sends data embedded in the variable left-hand portion of domain names (rrname) while 2) maintaining a static right-hand portion (rrname) and 3) receives DNS server responses containing TXT records (rtype) with varying data (rdata), while 4) the total volume of data transmitted in the left-hand portion of the requested domain name together with the TXT data response (rdata + rrname) exceeds a predefined threshold.

When detecting DNS tunneling, the following nuances must be considered:

• A single tunnel will not be constrained to a single DNS session; data may be transmitted across multiple sessions with the DNS server, or each individual request may occur within a separate session.
• A client DNS query can contain more than one requested domain name.
• A DNS response can contain multiple TXT records, as well as a large volume of various non-TXT record types.
• Traffic between DNS servers must be excluded, as it duplicates client requests and can trigger false positives.
• Although the factors outlined above (an abnormally large or frequently changing left-hand subdomain alongside a static right-hand domain, or an unusually long string in a TXT record) serve as key indicators of DNS tunneling, they can also occur within legitimate network traffic.

These challenges create a high likelihood of false positives when detecting DNS tunneling, particularly when using IDS-based tools. Writing an accurate IDS rule for this type of activity is practically impossible. With rare exceptions, DNS tunneling tools possess static markers that can be leveraged for signature-based detection. However, in the absence of such markers, signature methods fail to deliver high detection accuracy without generating an overwhelming number of false positives. In these cases, a comprehensive approach combining multiple correlated indicators is essential to improve overall detection quality.

DNS tunneling detection logic

To add a rule for detecting this anomaly, you can use the prebuilt “DNS data tunneling via TXT records” template in the new rule creation interface. The “SQL-specific query” tab will display the list of variables used:

• user_DNS_servers: a list of internal DNS server addresses within the infrastructure, required for the rule to function correctly and minimize potential false positives
• excl_sip: IP addresses to be excluded from the scope of the rule (you can specify a single address, a subnet mask, or a list containing both addresses and subnets)
• traffic_size: the threshold value for the total volume of data (in bytes) transmitted through the tunnel

The detection logic for this network anomaly is structured as follows:

1. From network sessions using the DNS protocol within the timeframe defined by the rule’s search depth, select only those sessions containing at least one TXT response.
   Additionally:
   • The IP address that initiated the session must not be excluded in the excl_sip variable.
   • The source IP address that initiated the session must not belong to the internal DNS servers listed in the user_DNS_servers variable.
   • The DNS names requested by the client must not be excluded within the rule.
2. Split qualifying DNS sessions into individual log lines, each corresponding to an individual request or response. Retain only DNS responses containing TXT data.
3. Extract DNS names and their associated TXT data from these DNS responses. Retain only unique values.
4. Group all resulting records by the session’s source IP address, aggregating all unique DNS names and TXT data blocks.
5. Generate an alert if the combined size (in bytes) of the unique DNS names and TXT response data for a single IP address within the search depth window exceeds the specified threshold (the traffic_size parameter).
6. Within the event regeneration window, group under the initial alert all subsequent alerts associated with the same client IP address. This avoids creating duplicate event records by incrementing the aggregation counter (Total appearances).

The primary value of NAD technology in this scenario lies in noise reduction – by minimizing false positives – and faster investigation times. A DNS tunnel rarely presents itself as a single, blatantly malicious request. Instead, it leaves behind a behavioral footprint: repetition, length, domain structure, unusual record types, numerous subdomains branching off an unchanging root domain, and anomalous host behavior. KATA consolidates these indicators into a single alert, presenting the analyst with an actionable attack hypothesis rather than a set of fragmented DNS events.

Prebuilt rules for detecting network anomalies in KATA

KATA users should note that Network Anomaly Detection (NAD) rules are not enabled by default. Rules must be added manually using the procedure described in the preceding sections. This design ensures that analysts can fine-tune rules to fit specific network infrastructures using variables.

Analysts have three ways of creating new rules:

1. Adding a rule from a prebuilt template and adjusting custom variables. In this case, the rule is classified as a system rule.
2. Adding a rule from a prebuilt template and modifying its underlying SQL query (which requires enabling the “Unlock all template values” option) to create a custom rule based on the template. When modified this way, the rule transitions from a system rule to a custom rule.
3. Authoring a custom rule from scratch, which requires a basic understanding of ClickHouse SQL queries and familiarity with the product documentation.

As of this publication, the product ships with 59 prebuilt NAD rule templates (with additional templates delivered via product updates). KATA supports running up to 200 active rules simultaneously.

Prebuilt rules are divided into six categories:

• Large Data Transfers: tracking abnormally large network sessions across various protocols during regular hours, at night, or over weekends.
• Suspicious Connections: detecting suspicious connections that may indicate hazardous activity, shadow IT, evasion of attack detection mechanisms, and other threats.
• Domain Attacks: detecting classic attacks targeting domain network infrastructures using offensive tooling.
• Reconnaissance Activity: identifying suspicious activity within domain protocol sessions (Kerberos, DCE/RPC, LDAP, DNS) resembling domain reconnaissance.
• Connections to Suspicious Resources: detects actions that violate security policies, potential data exfiltration beyond the perimeter, and unauthorized internet access originating from secured network segments.
• C2 Communication: identifies network sessions characteristic of a potential C2 communication channel or tunnel.

The table below lists the rule templates for detecting network anomalies in KATA:

Rule category	Rule name	Protocols used
Large Data Transfers	Data tunneling in DNS traffic	DNS
	ICMP, TCP, UDP, RDP, SSH or LDAP sessions with a large volume of traffic (6 rules)	ICMP, TCP, UDP, RDP, SSH, or LDAP (depends on selected rule)
	ICMP, TCP, UDP, RDP, SSH or LDAP sessions with a large volume of traffic at nighttime (6 rules)	ICMP, TCP, UDP, RDP, SSH, or LDAP (depends on selected rule)
	ICMP, TCP, UDP, RDP, SSH or LDAP sessions with a large volume of traffic on non-working days (6 rules)	ICMP, TCP, UDP, RDP, SSH, or LDAP (depends on selected rule)
Suspicious Connections	Queries to unknown DNS servers	DNS
	Use of unauthorized routes	TCP, UDP
	Use of suspicious ports for connections to external addresses	TCP, UDP
	Use of non-typical protocols for connections	TCP, UDP, HTTP, HTTPS, DNS, SMTP
Inconsistencies with firewall configuration	TCP, UDP
	Use of unauthorized ports for RDP or SSH sessions (2 rules)	RDP or SSH (depends on selected rule)
	Interactions with external IP addresses over the RDP or SSH protocol (2 rules)	RDP or SSH (depends on selected rule)
	Suspicious RDP sessions with domain controllers	RDP
	Connection to an unknown server via Kaspersky Security Center ports	TCP, UDP
Domain Attacks	Signs of a DCSync attack	DCE/RPC
	Signs of a DCShadow attack	DCE/RPC
	Signs of DHCP spoofing	DHCP
	DNS queries to Canarytoken domains	DNS
	Signs of a Kerberoasting attack	Kerberos
	Signs of an AS-REP Roasting attack	Kerberos
	Signs of a brute-force password attack on SSH	SSH
	Signs of SOAPHound usage	LDAP
	Large-volume Active Directory object data collection via LDAP queries	LDAP
Reconnaissance Activity	Getting information about a task in the Task Scheduler	DCE/RPC
	Getting a list of Kerberos users	Kerberos
	LDAP queries to rights delegation attribute	LDAP
	LDAP queries to attribute for getting administrator passwords	LDAP
	Signs of an internal horizontal port scan	TCP, UDP
	Signs of an internal vertical port scan	TCP, UDP
	DNS zone data replication requests sent from sources other than DNS servers	DNS
	Successfully completed requests for DNS zone data replication sent from sources other than DNS servers	DNS
	LDAP query targeting a critical attribute of insecure credentials	LDAP
	Enumeration of domain accounts via LDAP queries	LDAP
	Exceeding the threshold for requested critical attributes in LDAP queries	LDAP
	LDAP search queries containing a high number of critical attributes	LDAP
Connections to Suspicious Resources	Queries to unauthorized domain names	DNS
	Transmission of large data volumes to cloud storages	TCP, UDP, DNS
	Connections to cloud storages or file transfer services	TCP, DNS
	Connections to public repositories	TCP, DNS
	Connections to resources of programs for traffic tunneling	TCP, DNS
С2 Communication	Possible queries to DGA domains	DNS
	DNS data tunneling via TXT records	DNS
	Numerous blocked connections to external addresses	TCP, UDP

Conclusion

The examples of Kerberoasting and DNS tunneling clearly demonstrate why modern security defenses cannot rely solely on looking for known signatures and indicators of compromise. Both attack techniques abuse protocols that operate inside corporate networks every day. At the individual event level, they may look like legitimate activity, yet in behavioral context, they stand out as clear indicators of compromise.

NAD directly addresses this gap. Instead of relying purely on signature matches across Kerberos or DNS traffic, it highlights deviations from established baselines: who initiated the activity, how frequently it recurred, which services or domains were targeted, and why that matters for a specific infrastructure.

As a result, analysts gain a clear, actionable starting point for investigation. This capability is especially valuable for spotting the signs of APT group activity, which runs stealthily and is designed to blend in with legitimate operations. The importance of this capability will only grow: as attack techniques evolve, detecting suspicious activity at its earliest stages – before it escalates into critical service compromise or a data breach – becomes increasingly vital.

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.

Introduction

Containerization using Docker has become firmly established in modern development standards, significantly increasing the speed and convenience of deploying various services. Developers often use ready-made Docker images, making only minimal changes. The largest repository of container images is the Docker Hub service.

Container-hosted infrastructure is an attractive target for attackers. At a minimum, a compromised container can be used for DDoS attacks, cryptocurrency mining, or traffic proxying. The list of threats does not end there: once an attacker gains control of a container, they can steal or destroy data directly from it, access neighboring containers, or even attempt to escape the container, compromising the entire enterprise network.

At the same time, the infrastructure inside containers is typically updated less frequently and may contain outdated and vulnerable software versions. When deploying third-party images or modifying them for a specific environment, it is easy to make configuration errors that attackers can later exploit. And due to the architectural characteristics of containers, developers often face constraints when preparing images; to overcome these, they may resort to insecure solutions they find online.

In other words, containerized infrastructure can be both the simplest and the most lucrative target to exploit. Therefore, its security requires heightened attention. To minimize the risk of successful attacks on container infrastructure, it is essential to check the final Docker images, including all underlying layers, for vulnerabilities and misconfigurations. The easiest way to do this is by analyzing the Dockerfile; however, it is not always available for inspection. Moreover, it typically defines how to build layers on top of a base image from an external repository whose reliability cannot be guaranteed.

To help users identify insecure configurations and potential vulnerabilities within them, we have added our AI assistant to Kaspersky Container Security.KIRA (the assistant’s name) uses artificial intelligence to analyze the image and identify potential issues within, along with recommendations on how to fix them.

As part of this study, we asked KIRA to analyze a number of popular community images, and later in this article, we’ll show you the results.

Software vulnerabilities and compromise of update sources

One of the key security issues with using pre-built images is that developers do not update them in a timely manner. A Docker image is, by its very nature, a snapshot of a specific Linux distribution after packages have been installed on it. However, in most cases, it does not receive security updates on its own, unlike traditional Linux servers, where these updates are automatically installed by specialized services, such as unattended-upgrades in Debian-based distributions and dnf-automatic in RedHat-based distributions.

To apply updates to a Docker image, it must be rebuilt and redeployed. Often, this process is not automated, and some updates require additional effort to verify their correct operation, modify configurations when upgrading to new software versions, and so on. As a result, many popular images do not receive timely updates, which significantly increases the risks associated with their use.

An image that was secure at build time accumulates vulnerabilities as they are discovered in the packages installed within it, which over time significantly increases the opportunities for a successful attack on the container.

Vulnerable versions of web applications and network services accessible from the internet immediately become targets of various malicious campaigns. For example, just one day after the discovery of the CVE-2025-55182 vulnerability in React Server Components, our honeypots recorded numerous attack attempts related to this vulnerability. It was adopted by operators of many malicious campaigns, ranging from classic cryptocurrency miners to variants of Mirai and Gafgyt. Attackers are constantly adding new distribution methods and can use dozens of exploits targeting various vulnerabilities and configuration errors in popular services. Often, the same vulnerabilities are used in self-propagation mechanisms from already compromised hosts. For example, in a malicious campaign to spread the Dero miner, attackers use infected containers to automatically search for and infect new targets.

In addition to vulnerabilities that can be exploited remotely, attackers are rapidly adding local vulnerabilities to their arsenal, used to gain root privileges and escape the container: in the Kinsing malware campaign, attackers used CVE-2023-4911 (Looney Tunables) to elevate privileges, and in the perfctl campaign, the CVE-2021-4034 (PwnKit) vulnerability was used for the same purpose. The access gained was used to install a rootkit that hides the presence of perfctl on the system.

To assess the situation with unpatched vulnerabilities in containers, we took a random sample of 100 images, which included various popular solutions with 10,000 to 1 million downloads on DockerHub. In the 64 images we scanned, we found outdated software versions with critical vulnerabilities. For example, some images contained the CVE-2025-49844 vulnerability in the Redis server, leading to RCE by leveraging a vulnerability in the Lua parser; the current CVE-2026-24061 vulnerability in nginx, which in some configurations leads to a server process crash, and with ASLR disabled, again, to RCE; vulnerabilities CVE-2025-32463 in sudo and CVE-2023-4911 in glibc, allowing an attacker to gain root privileges with local access. At the same time, only one in ten Docker images from the analyzed sample is fully up to date.

It is worth noting that, of course, not every discovered vulnerability can be directly exploited by attackers. A practical risk arises when the vulnerable application or library is actually in use, and the conditions necessary for exploitation – which vary significantly from vulnerability to vulnerability – are met. Nevertheless, updates must not be ignored, as the risk of vulnerabilities being exploited – both individually and in various combinations – cannot be predicted in each specific case, and even vulnerabilities that seem harmless at first glance can ultimately pose a serious risk of compromise.

However, frequent updates have a downside. Every rebuild that downloads new packages from source repositories introduces an additional risk of a supply chain attack – a compromised dependency or a modified base image could silently inject malicious code into your environment precisely through an update. During our analysis of images from the sample, we did not find any signs of supply chain attacks. However, in March 2026, a supply chain incident occurred in the Trivy and LiteLLM projects. In the case of Trivy, the infected file was injected directly into the container image in the official repositories.

This leads to a difficult choice: infrequent updates leave known vulnerabilities unpatched within the image, while frequent updates increase the risk of supply chain compromise. Therefore, to protect your infrastructure, you need not only to regularly update base images but also to take a more comprehensive approach, specifically by pinning dependencies to known-good versions and scanning the resulting images for malware upon update.

Configuration vulnerabilities

Even a container with a fully updated image can be compromised if it is configured incorrectly. Embedding keys and secrets in the image, disabling authentication in network services, default passwords, and insecure file access permissions – all of these can be exploited by attackers in one way or another to achieve their goals.

The situation is exacerbated by the fact that errors may be introduced by the authors of the original image, which complicates their detection, as this requires analyzing every layer and the command that generated it. As with vulnerabilities, not every configuration error leads to compromise: it all depends on the container’s role, its network accessibility, and many other factors. But the very use of insecure settings will sooner or later lead to errors appearing in images where their consequences will be significantly more dangerous.

Standard rules are often insufficient for analyzing problematic configurations. To gain a deeper understanding of the context and assess potential risks, AI tools can be used. Later in this section, we will examine examples of typical insecure configurations we discovered while scanning public images from Docker Hub, along with the descriptions of issues and risk mitigation methods provided by the KIRA AI assistant.

Insecure handling of credentials

Use of default passwords

In some cases, containers may use default passwords set via environment variables or directly in Dockerfile. If these passwords are not overridden, attackers will be able to access the application by using the default password.

RUN |1 DEBIAN_FRONTEND=noninteractive /bin/sh -c echo [removed]:[removed] | chpasswd

According to KIRA’s analysis, the user’s password is stored in plain text in the image layer history. Anyone who gains access to the image – whether through a public registry, a compromised build environment, or other means – will be able to extract the password. If SSH or another form of interactive access is enabled in the container, this could lead to its complete compromise and allow attackers to move laterally within the infrastructure.

Passwords may be present in environment variables. Consider the following Dockerfile snippet:

ENV SERVERNAME=localhost WWW_PATH_CONF=/etc/apache2/apache2.conf WWW_PATH_ROOT=/var/www HTTPS=on PKP_CLI_INSTALL=0 PKP_DB_HOST=db PKP_DB_NAME=pkp PKP_DB_USER=pkp PKP_DB_PASSWORD=changeMePlease PKP_WEB_CONF=/etc/apache2/conf-enabled/pkp.conf PKP_CONF=config.inc.php PKP_CMD=/usr/local/bin/pkp-start

In this example, the environment variable PKP_DB_PASSWORD is set to changeMePlease. If the user forgets to override it, the application will use the password that can be obtained from Dockerfile.

Let’s look at another image:

/bin/sh -c #(nop)  ENV MOODLE_URL=<a href="http://0.0.0.0/">http://0.0.0.0</a> MOODLE_ADMIN admin       MOODLE_ADMIN_PASSWORD [removed]      MOODLE_ADMIN_EMAIL admin@example.com MOODLE_DB_HOST     MOODLE_DB_PASSWORD       MOODLE_DB_USER     MOODLE_DB_NAME    MOODLE_DB_PORT 3306

For this image, Dockerfile specifies that the administrator password is hardcoded in the ENV directive and remains in the image metadata (layer history, docker inspect). Anyone who gains access to the image (registry, build cache) will be able to extract this secret and compromise the account.

To eliminate these risks, ensure that no passwords are specified in Dockerfile. If authentication is required, you can use orchestrator mechanisms (secrets) or generate a temporary password when starting the container via the entrypoint script, without saving it in the layers. We also recommend using mechanisms for securely passing secrets at runtime (Docker secrets, Kubernetes Secrets) or, as a last resort, passing them via --secret during the build with BuildKit, but under no circumstances should they be left in the final image.

Passing passwords via command arguments

In some cases, passwords may be exposed when passed via command-line arguments, as these arguments are visible to all users on the system:

/bin/sh -c #(nop)  HEALTHCHECK &{[""CMD-SHELL"" ""mysql --protocol TCP -u\""root\"" -p\""$MYSQL_ROOT_PASSWORD\"" -e \""SELECT 1;\""""] ""15s"" ""30s"" ""0s"" '\x05'}

In the example provided, the MySQL superuser password is passed into the healthcheck command in plaintext, making it visible when viewing the process list (ps aux), in audit logs, and in monitoring systems. If the attacker gains read access to the container’s processes or logs, they can extract the password and gain full control of the database.

To fix this issue, the healthcheck should use a local connection via a Unix socket with default authentication (if the auth_socket plugin is configured for root), or create a dedicated user with minimal privileges (e.g., only USAGE), without a password or with a password passed via a secure file (--defaults-file with restricted permissions). You can also use the MYSQL_PWD environment variable for healthcheck authentication, but it remains visible in /proc.

Privilege escalation in the container

One of the most common vectors for initial compromise of Linux systems is RCE in web applications and network services. Typically, these services have minimal privileges, which complicates attackers’ subsequent actions: dumping credentials, covering their tracks, attempting to escape the container, and much more.

The situation worsens significantly if the attacker gains root privileges, as this allows them to fully control all processes within the container, conceal their activity, and use methods to escape the container. For example, they can compromise the host if the container is privileged, a Docker socket is mounted inside it, or other insecure configurations and vulnerabilities exist that cannot be exploited with standard user privileges.

Similarly, this simplifies network attacks on neighboring containers, the orchestrator, and various internal services, making this configuration error a potential link in the chain for compromising the entire network.

Attacks on sudo

One of the simplest privilege escalation methods is executing arbitrary commands as root using sudo without entering a password. Consider the following example:

/bin/sh -c set -xe;     apt-get update &&       apt-get -y install sudo;       echo ""solr ALL=(ALL) NOPASSWD: ALL"" >/etc/sudoers.d/solr;

Analyzing this configuration using KIRA immediately highlights the main issue: by installing the sudo package and setting NOPASSWD: ALL for the solr, the user severely violates the principle of least privilege. The Solr platform does not require such broad privileges to run within a container; instead, they create an easy path for escalating to root.

echo 'postgres ALL=(ALL:ALL) NOPASSWD:ALL' >> /etc/sudoers

In another example of an insecure configuration, NOPASSWD:ALL privileges are granted to a PostgreSQL database user, which is a direct and severe weakening of the access control policy. If an attacker gains the ability to execute code on behalf of the postgres user – through a vulnerability in a network service, an SQL injection, or by compromising of one of the processes – they will immediately and unconditionally be able to execute any commands on behalf of the root user. This is equivalent to the entire container running as root.

As a risk mitigation measure, we recommend completely removing this directive. The minimum necessary commands requiring privileges should be delegated on a case-by-case basis via sudoers with explicit specification of allowed executables and parameters, using NOPASSWD only as a last resort and for specific utilities.

Our AI assistant KIRA can identify even more complex insecure configurations, such as allowing passwordless sudo for the entire sudo group — by modifying existing rules.

perl -i -pe 's/\bALL$/NOPASSWD:ALL/g' /etc/sudoers

The risk in this example is that the command replaces standard declarations requiring authentication with passwordless execution of all commands for any user within the sudo group – potentially including postgres, should it be assigned to that group. This expands the attack surface to all group members, turning each of them into a potential point for instant privilege escalation.

To mitigate the risks, we recommend not modifying the global sudoers policy, keeping the standard password requirement, or using a more secure escalation mechanism – such as gosu to run a specific process on behalf of another user without permanent privileges.

Insecure file permissions

Another common vector for privilege escalation is insecurely configured file and directory permissions. Most often, for convenience, container image authors use 777 permissions, which allow anyone – including unprivileged users – to freely create and delete files, as well as modify their contents. This can lead to both privilege escalation and the ability for an unprivileged attacker to delete or modify logs, among other undesirable consequences.

Consider the following command:

chmod 0777 /usr/share/cargo /usr/share/cargo/bin

The risk is that directories containing binary files and scripts will become writable by any container user. This allows a low-privileged attacker to replace utilities included in cargo or add new malicious executables. When these tools are subsequently invoked, especially as the root user or via sudo, the attacker’s code will execute with the inherited privileges of the calling process, leading directly to a local privilege escalation.

To mitigate the risks, you can set the minimum necessary permissions: chmod 0755 for directories and chmod 0755/0644 for the corresponding files. The owner should be root, and only the owner should be allowed to write. Do not use chmod 777 on any system paths.

Lack of integrity checks

Downloading software without verifying its integrity can make the infrastructure vulnerable to software tampering.

For example, this risk may arise when downloading a distribution via HTTP:

RUN /bin/sh -c wget -qO- ""<a href="http://acestream.org/downloads/linux/acestream_3.1.49_debian_9.9_x86_64.tar.gz">http://acestream.org/downloads/linux/acestream_3.1.49_debian_9.9_x86_64.tar.gz</a>"" | tar --extract --gzip -C /opt/acestream

Using HTTP without verifying the archive’s integrity creates conditions for a man-in-the-middle attack during the image build phase. An attacker controlling the communication channel or DNS can replace the archive with malicious content, which will compromise the container and the entire environment in which it runs.

To mitigate the risks, you can configure connections to web resources to use HTTPS only — if the resource supports this protocol. You can also download the archive without extracting it, compare its checksum (SHA256) with the checksum from a trusted source, and only then extract it. It is advisable to store the verified archive in an internal artifact repository to avoid direct downloads from the network.

There will still be a MitM risk even if certificate verification is disabled:

wget --no-check-certificate<a href="https://github.com/phpvirtualbox/phpvirtualbox/archive/refs/heads/7.2-dev.zip"> https://github.com/phpvirtualbox/phpvirtualbox/archive/refs/heads/7.2-dev.zip</a> -O phpvirtualbox.zip

The absence of TLS certificate verification allows an attacker controlling the network segment to replace the downloaded ZIP archive with malicious content. Since the archive contains PHP code that will be executed by the web server, compromise during the build phase will result in the deployment of a backdoor or data leakage.

To mitigate the risks, remove the --no-check-certificate flag; after downloading, calculate the SHA256 hash of the archive and verify it against a known reference value (the release page or a local repository of trusted hashes). Additionally, consider using a fixed release (tag) rather than the floating 7.2-dev branch.

Conclusion

Docker containers have become a very popular means of deploying software, and attackers are by no means oblivious to this trend. They are rapidly adding software vulnerabilities and configuration errors to their arsenal and carrying out attacks on supply chains. They can compromise container infrastructure for a wide variety of purposes, from cryptocurrency mining to encrypting data for ransom or stealing information critical to the company.

Our research found that 64 out of 100 container images for popular applications contain critically vulnerable software, and only 10% are fully up to date. We also identified numerous insecure configurations, including passwords stored in plaintext in Dockerfiles and excessive privileges granted to users and processes.

To detect and prevent these threats, it is essential to strictly adhere to security measures: audit image configurations, securely manage secrets used in images, apply security updates in a timely manner, scan their contents for malware with every update, and follow industry-standard best practices for enhancing security.

This approach requires specialized solutions built to accommodate the unique characteristics of container environments. Kaspersky Container Security ensures the security of containerized applications at every stage of their lifecycle, from development to operation. The product protects an organization’s business processes, helps ensure compliance with industry standards and security regulations, and enables the implementation of secure software development practices.