Simplifying Cloud Network Security When securing cloud landscapes, it’s critically important to eliminate any downtime or performance degradation that firewall or gateway implementation may cause. To address these challenges, Check Point is proud to announce our support for Google Cloud Network Security Integration. This innovation creates a nondisruptive approach to cloud firewall deployment, increasing network security without negatively impacting performance. Scaling Hybrid Cloud Network Security Network security and performance are critical to any organization, but this is especially true for industries under heavy regulations like financial services, healthcare, and government. So over time these organizations gain comfort, expertise, and confidence […]

The post Check Point Supports Google Cloud Network Security Integration appeared first on Check Point Blog.

Cybersecurity thrives on diverse skills, not just coding and engineering. From writers to designers, there’s a place for you in this field.

The post Who Does Cybersecurity Need? You! appeared first on Unit 42.

A SIEM is a complex system offering broad and flexible threat detection capabilities. Due to its complexity, its effectiveness heavily depends on how it is configured and what data sources are connected to it. A one-time SIEM setup during implementation is not enough: both the organization’s infrastructure and attackers’ techniques evolve over time. To operate effectively, the SIEM system must reflect the current state of affairs.

We provide customers with services to assess SIEM effectiveness, helping to identify issues and offering options for system optimization. In this article, we examine typical SIEM operational pitfalls and how to address them. For each case, we also include methods for independent verification.

This material is based on an assessment of Kaspersky SIEM effectiveness; therefore, all specific examples, commands, and field names are taken from that solution. However, the assessment methodology, issues we identified, and ways to enhance system effectiveness can easily be extrapolated to any other SIEM.

Methodology for assessing SIEM effectiveness

The primary audience for the effectiveness assessment report comprises the SIEM support and operation teams within an organization. The main goal is to analyze how well the usage of SIEM aligns with its objectives. Consequently, the scope of checks can vary depending on the stated goals. A standard assessment is conducted across the following areas:

• Composition and scope of connected data sources
• Coverage of data sources
• Data flows from existing sources
• Correctness of data normalization
• Detection logic operability
• Detection logic accuracy
• Detection logic coverage
• Use of contextual data
• SIEM technical integration into SOC processes
• SOC analysts’ handling of alerts in the SIEM
• Forwarding of alerts, security event data, and incident information to other systems
• Deployment architecture and documentation

At the same time, these areas are examined not only in isolation but also in terms of their potential influence on one another. Here are a couple of examples illustrating this interdependence:

• Issues with detection logic due to incorrect data normalization. A correlation rule with the condition deviceCustomString1 not contains <string> triggers a large number of alerts. The detection logic itself is correct: the specific event and the specific field it targets should not generate a large volume of data matching the condition. Our review revealed the issue was in the data ingested by the SIEM, where incorrect encoding caused the string targeted by the rule to be transformed into a different one. Consequently, all events matched the condition and generated alerts.
• When analyzing coverage for a specific source type, we discovered that the SIEM was only monitoring 5% of all such sources deployed in the infrastructure. However, extending that coverage would increase system load and storage requirements. Therefore, besides connecting additional sources, it would be necessary to scale resources for specific modules (storage, collectors, or the correlator).

The effectiveness assessment consists of several stages:

• Collect and analyze documentation, if available. This allows assessing SIEM objectives, implementation settings (ideally, the deployment settings at the time of the assessment), associated processes, and so on.
• Interview system engineers, analysts, and administrators. This allows assessing current tasks and the most pressing issues, as well as determining exactly how the SIEM is being operated. Interviews are typically broken down into two phases: an introductory interview, conducted at project start to gather general information, and a follow-up interview, conducted mid-project to discuss questions arising from the analysis of previously collected data.
• Gather information within the SIEM and then analyze it. This is the most extensive part of the assessment, during which Kaspersky experts are granted read-only access to the system or a part of it to collect factual data on its configuration, detection logic, data flows, and so on.

The assessment produces a list of recommendations. Some of these can be implemented almost immediately, while others require more comprehensive changes driven by process optimization or a transition to a more structured approach to system use.

Issues arising from SIEM operations

The problems we identify during a SIEM effectiveness assessment can be divided into three groups:

• Performance issues, meaning operational errors in various system components. These problems are typically resolved by technical support, but to prevent them, it is worth periodically checking system health status.
• Efficiency issues – when the system functions normally but seemingly adds little value or is not used to its full potential. This is usually due to the customer using the system capabilities in a limited way, incorrectly, or not as intended by the developer.
• Detection issues – when the SIEM is operational and continuously evolving according to defined processes and approaches, but alerts are mostly false positives, and the system misses incidents. For the most part, these problems are related to the approach taken in developing detection logic.

Key observations from the assessment

Event source inventory

When building the inventory of event sources for a SIEM, we follow the principle of layered monitoring: the system should have information about all detectable stages of an attack. This principle enables the detection of attacks even if individual malicious actions have gone unnoticed, and allows for retrospective reconstruction of the full attack chain, starting from the attackers’ point of entry.

Problem: During effectiveness assessments, we frequently find that the inventory of connected source types is not updated when the infrastructure changes. In some cases, it has not been updated since the initial SIEM deployment, which limits incident detection capabilities. Consequently, certain types of sources remain completely invisible to the system.

We have also encountered non-standard cases of incomplete source inventory. For example, an infrastructure contains hosts running both Windows and Linux, but monitoring is configured for only one family of operating systems.

How to detect: To identify the problems described above, determine the list of source types connected to the SIEM and compare it against what actually exists in the infrastructure. Identifying the presence of specific systems in the infrastructure requires an audit. However, this task is one of the most critical for many areas of cybersecurity, and we recommend running it on a periodic basis.

We have compiled a reference sheet of system types commonly found in most organizations. Depending on the organization type, infrastructure, and threat model, we may rearrange priorities. However, a good starting point is as follows:

• High Priority – sources associated with:
  • Remote access provision
  • External services accessible from the internet
  • External perimeter
  • Endpoint operating systems
  • Information security tools
• Medium Priority – sources associated with:
  • Remote access management within the perimeter
  • Internal network communication
  • Infrastructure availability
  • Virtualization and cloud solutions
• Low Priority – sources associated with:
  • Business applications
  • Internal IT services
  • Applications used by various specialized teams (HR, Development, PR, IT, and so on)

Monitoring data flow from sources

Regardless of how good the detection logic is, it cannot function without telemetry from the data sources.

Problem: The SIEM core is not receiving events from specific sources or collectors. Based on all assessments conducted, the average proportion of collectors that are configured with sources but are not transmitting events is 38%. Correlation rules may exist for these sources, but they will, of course, never trigger. It is also important to remember that a single collector can serve hundreds of sources (such as workstations), so the loss of data flow from even one collector can mean losing monitoring visibility for a significant portion of the infrastructure.

How to detect: The process of locating sources that are not transmitting data can be broken down into two components.

1. Checking collector health. Find the status of collectors (see the support website for the steps to do this in Kaspersky SIEM) and identify those with a status of Offline, Stopped, Disabled, and so on.
2. Checking the event flow. In Kaspersky SIEM, this can be done by gathering statistics using the following query (counting the number of events received from each collector over a specific time period):

SELECT count(ID), CollectorID, CollectorName FROM `events` GROUP BY CollectorID, CollectorName ORDER BY count(ID)

It is essential to specify an optimal time range for collecting these statistics. Too large a range can increase the load on the SIEM, while too small a range may provide inaccurate information for a one-time check – especially for sources that transmit telemetry relatively infrequently, say, once a week. Therefore, it is advisable to choose a smaller time window, such as 2–4 days, but run several queries for different periods in the past.

Additionally, for a more comprehensive approach, it is recommended to use built-in functionality or custom logic implemented via correlation rules and lists to monitor event flow. This will help automate the process of detecting problems with sources.

Event source coverage

Problem: The system is not receiving events from all sources of a particular type that exist in the infrastructure. For example, the company uses workstations and servers running Windows. During SIEM deployment, workstations are immediately connected for monitoring, while the server segment is postponed for one reason or another. As a result, the SIEM receives events from Windows systems, the flow is normalized, and correlation rules work, but an incident in the unmonitored server segment would go unnoticed.

How to detect: Below are query variations that can be used to search for unconnected sources.

• SELECT count(distinct, DeviceAddress), DeviceVendor, DeviceProduct FROM events GROUP BY DeviceVendor, DeviceProduct ORDER BY count(ID)
• SELECT count(distinct, DeviceHostName), DeviceVendor, DeviceProduct FROM events GROUP BY DeviceVendor, DeviceProduct ORDER BY count(ID)

We have split the query into two variations because, depending on the source and the DNS integration settings, some events may contain either a DeviceAddress or DeviceHostName field.

These queries will help determine the number of unique data sources sending logs of a specific type. This count must be compared against the actual number of sources of that type, obtained from the system owners.

Retaining raw data

Raw data can be useful for developing custom normalizers or for storing events not used in correlation that might be needed during incident investigation. However, careless use of this setting can cause significantly more harm than good.

Problem: Enabling the Keep raw event option effectively doubles the event size in the database, as it stores two copies: the original and the normalized version. This is particularly critical for high-volume collectors receiving events from sources like NetFlow, DNS, firewalls, and others. It is worth noting that this option is typically used for testing a normalizer but is often forgotten and left enabled after its configuration is complete.

How to detect: This option is applied at the normalizer level. Therefore, it is necessary to review all active normalizers and determine whether retaining raw data is required for their operation.

Normalization

As with the absence of events from sources, normalization issues lead to detection logic failing, as this logic relies on finding specific information in a specific event field.

Problem: Several issues related to normalization can be identified:

• The event flow is not being normalized at all.
• Events are only partially normalized – this is particularly relevant for custom, non-out-of-the-box normalizers.
• The normalizer being used only parses headers, such as syslog_headers, placing the entire event body into a single field, this field most often being Message.
• An outdated default normalizer is being used.

How to detect: Identifying normalization issues is more challenging than spotting source problems due to the high volume of telemetry and variety of parsers. Here are several approaches to narrowing the search:

• First, check which normalizers supplied with the SIEM the organization uses and whether their versions are up to date. In our assessments, we frequently encounter auditd events being normalized by the outdated normalizer, Linux audit and iptables syslog v2 for Kaspersky SIEM. The new normalizer completely reworks and optimizes the normalization schema for events from this source.
• Execute the query:

SELECT count(ID), DeviceProduct, DeviceVendor, CollectorName FROM `events` GROUP BY DeviceProduct, DeviceVendor, CollectorName ORDER BY count(ID)

This query gathers statistics on events from each collector, broken down by the DeviceVendor and DeviceProduct fields. While these fields are not mandatory, they are present in almost any normalization schema. Therefore, their complete absence or empty values may indicate normalization issues. We recommend including these fields when developing custom normalizers.

To simplify the identification of normalization problems when developing custom normalizers, you can implement the following mechanism. For each successfully normalized event, add a Name field, populated from a constant or the event itself. For a final catch-all normalizer that processes all unparsed events, set the constant value: Name = unparsed event. This will later allow you to identify non-normalized events through a simple search on this field.

Detection logic coverage

Collected events alone are, in most cases, only useful for investigating an incident that has already been identified. For a SIEM to operate to its full potential, it requires detection logic to be developed to uncover probable security incidents.

Problem: The mean correlation rule coverage of sources, determined across all our assessments, is 43%. While this figure is only a ballpark figure – as different source types provide different information – to calculate it, we defined “coverage” as the presence of at least one correlation rule for a source. This means that for more than half of the connected sources, the SIEM is not actively detecting. Meanwhile, effort and SIEM resources are spent on connecting, maintaining, and configuring these sources. In some cases, this is formally justified, for instance, if logs are only needed for regulatory compliance. However, this is an exception rather than the rule.

We do not recommend solving this problem by simply not connecting sources to the SIEM. On the contrary, sources should be connected, but this should be done concurrently with the development of corresponding detection logic. Otherwise, it can be forgotten or postponed indefinitely, while the source pointlessly consumes system resources.

How to detect: This brings us back to auditing, a process that can be greatly aided by creating and maintaining a register of developed detection logic. Given that not every detection logic rule explicitly states the source type from which it expects telemetry, its description should be added to this register during the development phase.

If descriptions of the correlation rules are not available, you can refer to the following:

• The name of the detection logic. With a standardized approach to naming correlation rules, the name can indicate the associated source or at least provide a brief description of what it detects.
• The use of fields within the rules, such as DeviceVendor, DeviceProduct (another argument for including these fields in the normalizer), Name, DeviceAction, DeviceEventCategory, DeviceEventClassID, and others. These can help identify the actual source.

Excessive alerts generated by the detection logic

One criterion for correlation rules effectiveness is a low false positive rate.

Problem: Detection logic generates an abnormally high number of alerts that are physically impossible to process, regardless of the size of the SOC team.

How to detect: First and foremost, detection logic should be tested during development and refined to achieve an acceptable false positive rate. However, even a well-tuned correlation rule can start producing excessive alerts due to changes in the event flow or connected infrastructure. To identify these rules, we recommend periodically running the following query:

SELECT count(ID), Name FROM `events` WHERE Type = 3 GROUP BY Name ORDER BY count(ID)

In Kaspersky SIEM, a value of 3 in the Type field indicates a correlation event.

Subsequently, for each identified rule with an anomalous alert count, verify the correctness of the logic it uses and the integrity of the event stream on which it triggered.

Depending on the issue you identify, the solution may involve modifying the detection logic, adding exceptions (for example, it is often the case that 99% of the spam originates from just 1–5 specific objects, such as an IP address, a command parameter, or a URL), or adjusting event collection and normalization.

Lack of integration with indicators of compromise

SIEM integrations with other systems are generally a critical part of both event processing and alert enrichment. In at least one specific case, their presence directly impacts detection performance: integration with technical Threat Intelligence data or IoCs (indicators of compromise).

A SIEM allows conveniently checking objects against various reputation databases or blocklists. Furthermore, there are numerous sources of this data that are ready to integrate natively with a SIEM or require minimal effort to incorporate.

Problem: There is no integration with TI data.

How to detect: Generally, IoCs are integrated into a SIEM at the system configuration level during deployment or subsequent optimization. The use of TI within a SIEM can be implemented at various levels:

• At the data source level. Some sources, such as NGFWs, add this information to events involving relevant objects.
• At the SIEM native functionality level. For example, Kaspersky SIEM integrates with CyberTrace indicators, which add object reputation information at the moment of processing an event from a source.
• At the detection logic level. Information about IoCs is stored in various active lists, and correlation rules match objects against these to enrich the event.

Furthermore, TI data does not appear in a SIEM out of thin air. It is either provided by external suppliers (commercially or in an open format) or is part of the built-in functionality of the security tools in use. For instance, various NGFW systems can additionally check the reputation of external IP addresses or domains that users are accessing. Therefore, the first step is to determine whether you are receiving information about indicators of compromise and in what form (whether external providers’ feeds have been integrated and/or the deployed security tools have this capability). It is worth noting that receiving TI data only at the security tool level does not always cover all types of IoCs.

If data is being received in some form, the next step is to verify that the SIEM is utilizing it. For TI-related events coming from security tools, the SIEM needs a correlation rule developed to generate alerts. Thus, checking integration in this case involves determining the capabilities of the security tools, searching for the corresponding events in the SIEM, and identifying whether there is detection logic associated with these events. If events from the security tools are absent, the source audit configuration should be assessed to see if the telemetry type in question is being forwarded to the SIEM at all. If normalization is the issue, you should assess parsing accuracy and reconfigure the normalizer.

If TI data comes from external providers, determine how it is processed within the organization. Is there a centralized system for aggregating and managing threat data (such as CyberTrace), or is the information stored in, say, CSV files?

In the former case (there is a threat data aggregation and management system) you must check if it is integrated with the SIEM. For Kaspersky SIEM and CyberTrace, this integration is handled through the SIEM interface. Following this, SIEM event flows are directed to the threat data aggregation and management system, where matches are identified and alerts are generated, and then both are sent back to the SIEM. Therefore, checking the integration involves ensuring that all collectors receiving events that may contain IoCs are forwarding those events to the threat data aggregation and management system. We also recommend checking if the SIEM has a correlation rule that generates an alert based on matching detected objects with IoCs.

In the latter case (threat information is stored in files), you must confirm that the SIEM has a collector and normalizer configured to load this data into the system as events. Also, verify that logic is configured for storing this data within the SIEM for use in correlation. This is typically done with the help of lists that contain the obtained IoCs. Finally, check if a correlation rule exists that compares the event flow against these IoC lists.

As the examples illustrate, integration with TI in standard scenarios ultimately boils down to developing a final correlation rule that triggers an alert upon detecting a match with known IoCs. Given the variety of integration methods, creating and providing a universal out-of-the-box rule is difficult. Therefore, in most cases, to ensure IoCs are connected to the SIEM, you need to determine if the company has developed that rule (the existence of the rule) and if it has been correctly configured. If no correlation rule exists in the system, we recommend creating one based on the TI integration methods implemented in your infrastructure. If a rule does exist, its functionality must be verified: if there are no alerts from it, analyze its trigger conditions against the event data visible in the SIEM and adjust it accordingly.

The SIEM is not kept up to date

For a SIEM to run effectively, it must contain current data about the infrastructure it monitors and the threats it’s meant to detect. Both elements change over time: new systems and software, users, security policies, and processes are introduced into the infrastructure, while attackers develop new techniques and tools. It is safe to assume that a perfectly configured and deployed SIEM system will no longer be able to fully see the altered infrastructure or the new threats after five years of running without additional configuration. Therefore, practically all components – event collection, detection, additional integrations for contextual information, and exclusions – must be maintained and kept up to date.

Furthermore, it is important to acknowledge that it is impossible to cover 100% of all threats. Continuous research into attacks, development of detection methods, and configuration of corresponding rules are a necessity. The SOC itself also evolves. As it reaches certain maturity levels, new growth opportunities open up for the team, requiring the utilization of new capabilities.

Problem: The SIEM has not evolved since its initial deployment.

How to detect: Compare the original statement of work or other deployment documentation against the current state of the system. If there have been no changes, or only minimal ones, it is highly likely that your SIEM has areas for growth and optimization. Any infrastructure is dynamic and requires continuous adaptation.

Other issues with SIEM implementation and operation

In this article, we have outlined the primary problems we identify during SIEM effectiveness assessments, but this list is not exhaustive. We also frequently encounter:

• Mismatch between license capacity and actual SIEM load. The problem is almost always the absence of events from sources, rather than an incorrect initial assessment of the organization’s needs.
• Lack of user rights management within the system (for example, every user is assigned the administrator role).
• Poor organization of customizable SIEM resources (rules, normalizers, filters, and so on). Examples include chaotic naming conventions, non-optimal grouping, and obsolete or test content intermixed with active content. We have encountered confusing resource names like [dev] test_Add user to admin group_final2.
• Use of out-of-the-box resources without adaptation to the organization’s infrastructure. To maximize a SIEM’s value, it is essential at a minimum to populate exception lists and specify infrastructure parameters: lists of administrators and critical services and hosts.
• Disabled native integrations with external systems, such as LDAP, DNS, and GeoIP.

Generally, most issues with SIEM effectiveness stem from the natural degradation (accumulation of errors) of the processes implemented within the system. Therefore, in most cases, maintaining effectiveness involves structuring these processes, monitoring the quality of SIEM engagement at all stages (source onboarding, correlation rule development, normalization, and so on), and conducting regular reviews of all system components and resources.

Conclusion

A SIEM is a powerful tool for monitoring and detecting threats, capable of identifying attacks at various stages across nearly any point in an organization’s infrastructure. However, if improperly configured and operated, it can become ineffective or even useless while still consuming significant resources. Therefore, it is crucial to periodically audit the SIEM’s components, settings, detection rules, and data sources.

If a SOC is overloaded or otherwise unable to independently identify operational issues with its SIEM, we offer Kaspersky SIEM platform users a service to assess its operation. Following the assessment, we provide a list of recommendations to address the issues we identify. That being said, it is important to clarify that these are not strict, prescriptive instructions, but rather highlight areas that warrant attention and analysis to improve the product’s performance, enhance threat detection accuracy, and enable more efficient SIEM utilization.

This report describes a phishing campaign in which attackers impersonate legitimate Google generated messages by abusing Google Cloud Application Integration to distribute malicious emails that appear to originate from trusted Google infrastructure. The emails mimic routine enterprise notifications such as voicemail alerts and file access or permission requests, making them appear normal and trustworthy to recipients. In this incident, attackers sent 9,394 phishing emails targeting approximately 3,200 customers over the past 14 days. All messages were sent from the legitimate Google address noreply-application-integration@google.com, which significantly increased their credibility and likelihood of reaching end users’ inboxes. Method of attack Based on […]

The post Phishing Campaign Leverages Trusted Google Cloud Automation Capabilities to Evade Detection appeared first on Check Point Blog.

Introduction

If you’re a penetration tester, you know that lateral movement is becoming increasingly difficult, especially in well-defended environments. One common technique for remote command execution has been the use of DCOM objects.

Over the years, many different DCOM objects have been discovered. Some rely on native Windows components, others depend on third-party software such as Microsoft Office, and some are undocumented objects found through reverse engineering. While certain objects still work, others no longer function in newer versions of Windows.

This research presents a previously undescribed DCOM object that can be used for both command execution and potential persistence. This new technique abuses older initial access and persistence methods through Control Panel items.

First, we will discuss COM technology. After that, we will review the current state of the Impacket dcomexec script, focusing on objects that still function, and discuss potential fixes and improvements, then move on to techniques for enumerating objects on the system. Next, we will examine Control Panel items, how adversaries have used them for initial access and persistence, and how these items can be leveraged through a DCOM object to achieve command execution.

Finally, we will cover detection strategies to identify and respond to this type of activity.

COM/DCOM technology

What is COM?

COM stands for Component Object Model, a Microsoft technology that defines a binary standard for interoperability. It enables the creation of reusable software components that can interact at runtime without the need to compile COM libraries directly into an application.

These software components operate in a client–server model. A COM object exposes its functionality through one or more interfaces. An interface is essentially a collection of related member functions (methods).

COM also enables communication between processes running on the same machine by using local RPC (Remote Procedure Call) to handle cross-process communication.

Terms

To ensure a better understanding of its structure and functionality, let’s revise COM-related terminology.

1. COM interface
   A COM interface defines the functionality that a COM object exposes. Each COM interface is identified by a unique GUID known as the IID (Interface ID). All COM interfaces can be found in the Windows Registry under HKEY_CLASSES_ROOT\Interface, where they are organized by GUID.
2. COM class (COM CoClass)
   A COM class is the actual implementation of one or more COM interfaces. Like COM interfaces, classes are identified by unique GUIDs, but in this case the GUID is called the CLSID (Class ID). This GUID is used to locate the COM server and activate the corresponding COM class.

   All COM classes must be registered in the registry under HKEY_CLASSES_ROOT\CLSID, where each class’s GUID is stored. Under each GUID, you may find multiple subkeys that serve different purposes, such as:

   • InprocServer32/LocalServer32: Specifies the system path of the COM server where the class is defined. InprocServer32 is used for in-process servers (DLLs), while LocalServer32 is used for out-of-process servers (EXEs). We’ll describe this in more detail later.
   • ProgID: A human-readable name assigned to the COM class.
   • TypeLib: A binary description of the COM class (essentially documentation for the class).
   • AppID: Used to describe security configuration for the class.
3. COM server
   A COM is the module where a COM class is defined. The server can be implemented as an EXE, in which case it is called an out-of-process server, or as a DLL, in which case it is called an in-process server. Each COM server has a unique file path or location in the system. Information about COM servers is stored in the Windows Registry. The COM runtime uses the registry to locate the server and perform further actions. Registry entries for COM servers are located under the HKEY_CLASSES_ROOT root key for both 32- and 64-bit servers.

Client–server model

1. In-process server
   In the case of an in-process server, the server is implemented as a DLL. The client loads this DLL into its own address space and directly executes functions exposed by the COM object. This approach is efficient since both client and server run within the same process.
   

   In-process COM server

2. Out-of-process server
   Here, the server is implemented and compiled as an executable (EXE). Since the client cannot load an EXE into its address space, the server runs in its own process, separate from the client. Communication between the two processes is handled via ALPC (Advanced Local Procedure Call) ports, which serve as the RPC transport layer for COM.

What is DCOM?

DCOM is an extension of COM where the D stands for Distributed. It enables the client and server to reside on different machines. From the user’s perspective, there is no difference: DCOM provides an abstraction layer that makes both the client and the server appear as if they are on the same machine.

Under the hood, however, COM uses TCP as the RPC transport layer to enable communication across machines.

Certain requirements must be met to extend a COM object into a DCOM object. The most important one for our research is the presence of the AppID subkey in the registry, located under the COM CLSID entry.

The AppID value contains a GUID that maps to a corresponding key under HKEY_CLASSES_ROOT\AppID. Several subkeys may exist under this GUID. Two critical ones are:

• AccessPermission: controls access permissions.
• LaunchPermission: controls activation permissions.

These registry settings grant remote clients permissions to activate and interact with DCOM objects.

Lateral movement via DCOM

After attackers compromise a host, their next objective is often to compromise additional machines. This is what we call lateral movement. One common lateral movement technique is to achieve remote command execution on a target machine. There are many ways to do this, one of which involves abusing DCOM objects.

In recent years, many DCOM objects have been discovered. This research focuses on the objects exposed by the Impacket script dcomexec.py that can be used for command execution. More specifically, three exposed objects are used: ShellWindows, ShellBrowserWindow and MMC20.

1. ShellWindows
   ShellWindows was one of the first DCOM objects to be identified. It represents a collection of open shell windows and is hosted by explorer.exe, meaning any COM client communicates with that process.

   In Impacket’s dcomexec.py, once an instance of this COM object is created on a remote machine, the script provides a semi-interactive shell.

   Each time a user enters a command, the function exposed by the COM object is called. The command output is redirected to a file, which the script retrieves via SMB and displays back to simulate a regular shell.

   Internally, the script runs this command when connecting:

   cmd.exe /Q /c cd \ 1> \\127.0.0.1\ADMIN$\__17602 2>&1

   This sets the working directory to C:\ and redirects the output to the ADMIN$ share under the filename __17602. After that, the script checks whether the file exists; if it does, execution is considered successful and the output appears as if in a shell.

   When running dcomexec.py against Windows 10 and 11 using the ShellWindows object, the script hangs after confirming SMB connection initialization and printing the SMB banner. As I mentioned in my personal blog post, it appears that this DCOM object no longer has permission to write to the ADMIN$ share. A simple fix is to redirect the output to a directory the DCOM object can write to, such as the Temp folder. The Temp folder can then be accessed under the same ADMIN$ share. A small change in the code resolves the issue. For example:

   OUTPUT_FILENAME = 'Temp\\__' + str(time.time())[:5]

2. ShellBrowserWindow
   The ShellBrowserWindow object behaves almost identically to ShellWindows and exhibits the same behavior on Windows 10. The same workaround that we used for ShellWindows applies in this case. However, on Windows 11, this object no longer works for command execution.
3. MMC20
   The MMC20.Application COM object is the automation interface for Microsoft Management Console (MMC). It exposes methods and properties that allow MMC snap-ins to be automated.

   This object has historically worked across all Windows versions. Starting with Windows Server 2025, however, attempting to use it triggers a Defender alert, and execution is blocked.

   As shown in earlier examples, the dcomexec.py script writes the command output to a file under ADMIN$, with a filename that begins with __:

   OUTPUT_FILENAME = '__' + str(time.time())[:5]

   Defender appears to check for files written under ADMIN$ that start with __, and when it detects one, it blocks the process and alerts the user. A quick fix is to simply remove the double underscores from the output filename.

   Another way to bypass this issue is to use the same workaround used for ShellWindows – redirecting the output to the Temp folder. The table below outlines the status of these objects across different Windows versions.

   	Windows Server 2025	Windows Server 2022	Windows 11	Windows 10
   ShellWindows	Doesn’t work	Doesn’t work	Works but needs a fix	Works but needs a fix
   ShellBrowserWindow	Doesn’t work	Doesn’t work	Doesn’t work	Works but needs a fix
   MMC20	Detected by Defender	Works	Works	Works

Enumerating COM/DCOM objects

The first step to identifying which DCOM objects could be used for lateral movement is to enumerate them. By enumerating, I don’t just mean listing the objects. Enumeration involves:

• Finding objects and filtering specifically for DCOM objects.
• Identifying their interfaces.
• Inspecting the exposed functions.

Automating enumeration is difficult because most COM objects lack a type library (TypeLib). A TypeLib acts as documentation for an object: which interfaces it supports, which functions are exposed, and the definitions of those functions. Even when TypeLibs are available, manual inspection is often still required, as we will explain later.

There are several approaches to enumerating COM objects depending on their use cases. Next, we’ll describe the methods I used while conducting this research, taking into account both automated and manual methods.

1. Automation using PowerShell
   In PowerShell, you can use .NET to create and interact with DCOM objects. Objects can be created using either their ProgID or CLSID, after which you can call their functions (as shown in the figure below).
   

   Shell.Application COM object function list in PowerShell

   Under the hood, PowerShell checks whether the COM object has a TypeLib and implements the IDispatch interface. IDispatch enables late binding, which allows runtime dynamic object creation and function invocation. With these two conditions met, PowerShell can dynamically interact with COM objects at runtime.

   Our strategy looks like this:

   

   As you can see in the last box, we perform manual inspection to look for functions with names that could be of interest, such as Execute, Exec, Shell, etc. These names often indicate potential command execution capabilities.

   However, this approach has several limitations:

   • TypeLib requirement: Not all COM objects have a TypeLib, so many objects cannot be enumerated this way.
   • IDispatch requirement: Not all COM objects implement the IDispatch interface, which is required for PowerShell interaction.
   • Interface control: When you instantiate an object in PowerShell, you cannot choose which interface the instance will be tied to. If a COM class implements multiple interfaces, PowerShell will automatically select the one marked as [default] in the TypeLib. This means that other non-default interfaces, which may contain additional relevant functionality, such as command execution, could be overlooked.
2. Automation using C++
   As you might expect, C++ is one of the languages that natively supports COM clients. Using C++, you can create instances of COM objects and call their functions via header files that define the interfaces.However, with this approach, we are not necessarily interested in calling functions directly. Instead, the goal is to check whether a specific COM object supports certain interfaces. The reasoning is that many interfaces have been found to contain functions that can be abused for command execution or other purposes.

   This strategy primarily relies on an interface called IUnknown. All COM interfaces should inherit from this interface, and all COM classes should implement it.The IUnknown interface exposes three main functions. The most important is QueryInterface(), which is used to ask a COM object for a pointer to one of its interfaces.So, the strategy is to:

   • Enumerate COM classes in the system by reading CLSIDs under the HKEY_CLASSES_ROOT\CLSID key.
   • Check whether they support any known valuable interfaces. If they do, those classes may be leveraged for command execution or other useful functionality.

   This method has several advantages:

   • No TypeLib dependency: Unlike PowerShell, this approach does not require the COM object to have a TypeLib.
   • Use of IUnknown: In C++, you can use the QueryInterface function from the base IUnknown interface to check if a particular interface is supported by a COM class.
   • No need for interface definitions: Even without knowing the exact interface structure, you can obtain a pointer to its virtual function table (vtable), typically cast as a void*. This is enough to confirm the existence of the interface and potentially inspect it further.

   The figure below illustrates this strategy:

   

   This approach is good in terms of automation because it eliminates the need for manual inspection. However, we are still only checking well-known interfaces commonly used for lateral movement, while potentially missing others.

3. Manual inspection using open-source tools
   As you can see, automation can be difficult since it requires several prerequisites and, in many cases, still ends with a manual inspection. An alternative approach is manual inspection using a tool called OleViewDotNet, developed by James Forshaw. This tool allows you to:
   • List all COM classes in the system.
   • Create instances of those classes.
   • Check their supported interfaces.
   • Call specific functions.
   • Apply various filters for easier analysis.
   • Perform other inspection tasks.
   

   Open-source tool for inspecting COM interfaces

   One of the most valuable features of this tool is its naming visibility. OleViewDotNet extracts the names of interfaces and classes (when available) from the Windows Registry and displays them, along with any associated type libraries.

   This makes manual inspection easier, since you can analyze the names of classes, interfaces, or type libraries and correlate them with potentially interesting functionality, for example, functions that could lead to command execution or persistence techniques.

Control Panel items as attack surfaces

Control Panel items allow users to view and adjust their computer settings. These items are implemented as DLLs that export the CPlApplet function and typically have the .cpl extension. Control Panel items can also be executables, but our research will focus on DLLs only.

Attackers can abuse CPL files for initial access. When a user executes a malicious .cpl file (e.g., delivered via phishing), the system may be compromised – a technique mapped to MITRE ATT&CK T1218.002.

Adversaries may also modify the extensions of malicious DLLs to .cpl and register them in the corresponding locations in the registry.

• Under HKEY_CURRENT_USER:
  HKCU\Software\Microsoft\Windows\CurrentVersion\Control Panel\Cpls

• Under HKEY_LOCAL_MACHINE:
  • For 64-bit DLLs:
    HKLM\Software\Microsoft\Windows\CurrentVersion\Control Panel\Cpls
  • For 32-bit DLLs:
    HKLM\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Control Panel\Cpls

These locations are important when Control Panel DLLs need to be available to the current logged-in user or to all users on the machine. However, the “Control Panel” subkey and its “Cpls” subkey under HKCU should be created manually, unlike the “Control Panel” and “Cpls” subkeys under HKLM, which are created automatically by the operating system.

Once registered, the DLL (CPL file) will load every time the Control Panel is opened, enabling persistence on the victim’s system.

It’s worth noting that even DLLs that do not comply with the CPL specification, do not export CPlApplet, or do not have the .cpl extension can still be executed via their DllEntryPoint function if they are registered under the registry keys listed above.

There are multiple ways to execute Control Panel items:

• From cmd: control.exe [filename].cpl
• By double-clicking the .cpl file.

Both methods use rundll32.exe under the hood:

rundll32.exe shell32.dll,Control_RunDLL [filename].cpl

This calls the Control_RunDLL function from shell32.dll, passing the CPL file as an argument. Everything inside the CPlApplet function will then be executed.

However, if the CPL file has been registered in the registry as shown earlier, then every time the Control Panel is opened, the file is loaded into memory through the COM Surrogate process (dllhost.exe):

What happened was that a Control Panel with a COM client used a COM object to load these CPL files. We will talk about this COM object in more detail later.

The COM Surrogate process was designed to host COM server DLLs in a separate process rather than loading them directly into the client process’s address space. This isolation improves stability for the in-process server model. This hosting behavior can be configured for a COM object in the registry if you want a COM server DLL to run inside a separate process because, by default, it is loaded in the same process.

‘DCOMing’ through Control Panel items

While following the manual approach of enumerating COM/DCOM objects that could be useful for lateral movement, I came across a COM object called COpenControlPanel, which is exposed through shell32.dll and has the CLSID {06622D85-6856-4460-8DE1-A81921B41C4B}. This object exposes multiple interfaces, one of which is IOpenControlPanel with IID {D11AD862-66DE-4DF4-BF6C-1F5621996AF1}.

I immediately thought of its potential to compromise Control Panel items, so I wanted to check which functions were exposed by this interface. Unfortunately, neither the interface nor the COM class has a type library.

Normally, checking the interface definition would require reverse engineering, so at first, it looked like we needed to take a different research path. However, it turned out that the IOpenControlPanel interface is documented on MSDN, and according to the documentation, it exposes several functions. One of them, called Open, allows a specified Control Panel item to be opened using its name as the first argument.

Full type and function definitions are provided in the shobjidl_core.h Windows header file.

It’s worth noting that in newer versions of Windows (e.g., Windows Server 2025 and Windows 11), Microsoft has removed interface names from the registry, which means they can no longer be identified through OleViewDotNet.

Returning to the COpenControlPanel COM object, I found that the Open function can trigger a DLL to be loaded into memory if it has been registered in the registry. For the purposes of this research, I created a DLL that basically just spawns a message box which is defined under the DllEntryPoint function. I registered it under HKCU\Software\Microsoft\Windows\CurrentVersion\Control Panel\Cpls and then created a simple C++ COM client to call the Open function on this interface.

As expected, the DLL was loaded into memory. It was hosted in the same way that it would be if the Control Panel itself was opened: through the COM Surrogate process (dllhost.exe). Using Process Explorer, it was clear that dllhost.exe loaded my DLL while simultaneously hosting the COpenControlPanel object along with other COM objects.

Based on my testing, I made the following observations:

1. The DLL that needs to be registered does not necessarily have to be a .cpl file; any DLL with a valid entry point will be loaded.
2. The Open() function accepts the name of a Control Panel item as its first argument. However, it appears that even if a random string is supplied, it still causes all DLLs registered in the relevant registry location to be loaded into memory.

Now, what if we could trigger this COM object remotely? In other words, what if it is not just a COM object but also a DCOM object? To verify this, we checked the AppID of the COpenControlPanel object using OleViewDotNet.

Both the launch and access permissions are empty, which means the object will follow the system’s default DCOM security policy. By default, members of the Administrators group are allowed to launch and access the DCOM object.

Based on this, we can build a remote strategy. First, upload the “malicious” DLL, then use the Remote Registry service to register it in the appropriate registry location. Finally, use a trigger acting as a DCOM client to remotely invoke the Open() function, causing our DLL to be loaded. The diagram below illustrates the flow of this approach.

The trigger can be written in either C++ or Python, for example, using Impacket. I chose Python because of its flexibility. The trigger itself is straightforward: we define the DCOM class, the interface, and the function to call. The full code example can be found here.

Once the trigger runs, the behavior will be the same as when executing the COM client locally: our DLL will be loaded through the COM Surrogate process (dllhost.exe).

As you can see, this technique not only achieves command execution but also provides persistence. It can be triggered in two ways: when a user opens the Control Panel or remotely at any time via DCOM.

Detection

The first step in detecting such activity is to check whether any Control Panel items have been registered under the following registry paths:

• HKCU\Software\Microsoft\Windows\CurrentVersion\Control Panel\Cpls
• HKLM\Software\Microsoft\Windows\CurrentVersion\Control Panel\Cpls
• HKLM\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Control Panel\Cpls

Although commonly known best practices and research papers regarding Windows security advise monitoring only the first subkey, for thorough coverage it is important to monitor all of the above.

In addition, monitoring dllhost.exe (COM Surrogate) for unusual COM objects such as COpenControlPanel can provide indicators of malicious activity.
Finally, it is always recommended to monitor Remote Registry usage because it is commonly abused in many types of attacks, not just in this scenario.

Conclusion

In conclusion, I hope this research has clarified yet another attack vector and emphasized the importance of implementing hardening practices. Below are a few closing points for security researchers to take into account:

• As shown, DCOM represents a large attack surface. Windows exposes many DCOM classes, a significant number of which lack type libraries – meaning reverse engineering can reveal additional classes that may be abused for lateral movement.
• Changing registry values to register malicious CPLs is not good practice from a red teaming ethics perspective. Defender products tend to monitor common persistence paths, but Control Panel applets can be registered in multiple registry locations, so there is always a gap that can be exploited.
• Bitness also matters. On x64 systems, loading a 32-bit DLL will spawn a 32-bit COM Surrogate process (dllhost.exe *32). This is unusual on 64-bit hosts and therefore serves as a useful detection signal for defenders and an interesting red flag for red teamers to consider.

If 2025 proved anything, it’s that no one wins alone in cybersecurity. AI-driven threats accelerated, and environments grew more complex while enterprises pushed hard for simplicity, integrated protection and security outcomes that deliver measurable results and meaningful value.

In response, we saw our partners around the globe lean into integration, treat AI as a built-in advantage and use the strength of our ecosystem as a force multiplier. The result: What could have been a disruptive year instead became one defined by growth and learning across our partner community.

Now, those lessons are guiding how Palo Alto Networks plans to partner with even greater precision in 2026. We remain a channel-first company that’s all-in on our ecosystem and united with our partners in a shared purpose to protect our customers’ digital future. But we also intend to double down in several areas in the year ahead, and we’re asking our partners to join us in doing the same.

1. Simplifying Security Through Integration

One message from customers that came through loud and clear in 2025 is that complexity is the enemy of resilience. Many enterprises are grappling with tool sprawl – multiple consoles, disconnected policies and overlapping investments that slow down their teams when speed and agility matter most.

The partners who delivered some of the most transformative results for organizations this year were those who chose integration over complexity and collaboration over siloed tools. With a laser focus on simplifying security, they were able to help customers:

• Consolidate fragmented point tools onto a unified security platform.
• Align visibility across the network, cloud and security operations center (SOC), so teams can respond faster.
• Build architectures with zero trust and AI-powered detection at the core.

We saw this simplifying-security trend through integration across our ecosystem. Partners unified cloud security and detection workflows through Cortex^® Cloud™ and Cortex. Teams modernized network architectures with tighter integration across our platform. We expect this activity to only accelerate in the coming year as our cloud security offerings continue to evolve.

When we innovate together, customers gain stronger defenses and a faster time-to-value. That’s why Palo Alto Networks has invested so heavily in platformization. When you connect our capabilities across network security, cloud security and security operations (wrapping them with your consulting, delivery and managed services) customers can experience something fundamentally better. With fewer gaps and clearer signals, they can build a security posture that’s built for the speed of modern threats.

In 2026, deep integration will remain a cornerstone of how we partner with precision. We’ll continue aligning our portfolio, programs and joint engagement model, so you can build offerings that reduce complexity for customers and create stronger differentiation for your business.

2. Making AI a Built-in Advantage

At Palo Alto Networks, our approach to AI in cybersecurity is straightforward. We believe AI must be embedded, not bolted on. It has to live in the data, analytics and workflows your teams rely on every day. That’s the thinking behind Precision AI^®, and it’s why we built AI capabilities into our platform’s core.

Partners who treated AI as a platform capability rather than a standalone tool delivered some of the strongest outcomes for customers in 2025. They were able to meet customers’ needs and deliver business outcomes in a single, unified approach. They helped organizations:

• Detect and respond to threats faster with AI-assisted analytics.
• Use automation to streamline change, investigation and response workflows.
• Tie AI to tangible outcomes, such as reduced risk, higher productivity and a better user experience.

In 2026, we’ll double down on AI across the platform and invest in the tools, content and enablement you need to bring those capabilities to life. Our focus is on making it easier for you to build AI-powered services that are repeatable and aligned to the outcomes customers expect.

Upcoming program changes reflect that intent. We’ll promote next-generation security as a growth engine and invest in ways that strengthen partner profitability across consulting services, resale, quality delivery, technical support and managed security services.

3. Ensuring Our Ecosystem Can Be a Growth Engine for Everyone

As AI raised the bar for both attackers and defenders in 2025, the partners who leaned into platformization and outcome-driven services were the ones who helped customers stay ahead of the curve. Those successes are now shaping how we strengthen and scale the partner ecosystem in 2026.

Our ecosystem isn’t just a route to market; it’s intended to be an economic engine for everyone involved. This year, many partners grew their business by building practices around our platform and aligning their services with where customers needed the most support: strategy, implementation, optimization, ongoing operations. We saw especially strong momentum from partners’ expansions:

• Consulting and advisory services around zero trust and AI-driven transformation.
• Resale opportunities centered on platform consolidation and next-generation security.
• Quality delivery and technical support that keep deployments reliable and current.
• Managed security services that give customers 24/7 protection and expert oversight.

These achievements reflect the value exchange at the heart of our ecosystem. Palo Alto Networks invests in platformization, AI and enablement, while our partners bring delivery expertise, regional insight and service innovation. Together, we create outcomes neither of us could deliver alone.

In 2026, we plan to build on that momentum and drive even greater partner profitability. Program evolutions will focus on growth across the full lifecycle, from initial design and implementation to long-term operation and optimization. We’re also expanding collaboration with our technology alliances to build new joint offerings and solution plays that the ecosystem can take to market together.

When we combine our platform, your expertise and the capabilities of our Alliance partners, then customers gain more paths to adopt next-generation security with confidence, and you gain more opportunities to develop differentiated, high-value practices.

Keeping Customers at the Center

At the heart of every partner collaboration is the customer, of course. Everything we build, integrate and advance together starts and ends with protecting them. This year, ecosystem alignment delivered measurable impact for our customers across industries. When partners lead with integrated solutions anchored in our platform, organizations saw visible improvements:

• Faster deployment of secure solutions.
• Reduced complexity with unified visibility.
• Greater confidence in defending against today’s AI-driven threats.

We saw this firsthand in joint wins across cloud security transformations, zero trust modernization and AI-assisted threat detection. When our ecosystem moves together, customers can move faster, operate more securely and achieve meaningful outcomes. Customer success is the foundation of everything we do as a partner-led organization, and it will remain our North Star in 2026.

Partnering with Precision in 2026 and Beyond

What we learned and achieved together in 2025 points us toward a clear focus for 2026 to advance ecosystem-led innovation, so we can deliver outcomes that matter most to our customers.

With that mission in mind, we will focus on the following four priorities:

• Deeper Integration – Expanding API partnerships and strengthening interoperability across the platform.
• Co-Innovation – Enabling partners to build solutions tailored to industry needs and use cases.
• Empowered Enablement – Investing in learning, automation and AI capabilities that fuel differentiated, profitable services.
• Simplified Engagement – Streamlining programs and tools, so that partnering with us is faster and more rewarding.

These priorities highlight the real strength of our ecosystem: How platformization, AI and partner expertise come together to enable what we could not build alone.

Finally, to our partners and customers, thank you. Your trust, collaboration and commitment push us to innovate boldly and continuously. As we enter the new year, I’m excited about what we’ll build together. When we align our AI-powered platform, our partner programs and your expertise in delivery, services and managed security, we can deliver something far greater than a set of solutions.

We’re a powerful team that’s not just defending against what’s next; we’re defining the future of cybersecurity. And together, we’re unstoppable.

Partners, join us in shaping the next chapter of secure, AI-powered innovations. Connect with your Channel Business Manager to align on 2026 opportunities, upcoming program updates and ways we can elevate customer outcomes together. Visit the partner portal to learn more.

---

Key Takeaways

• Integration beats complexity.
  Unifying technology, data and expertise drove the strongest outcomes in 2025, helping partners reduce risk and accelerate time-to-value for customers.
• AI is a built-in advantage.
  By tapping into AI embedded across our cybersecurity platform, partners can address security and business outcomes simultaneously and deliver repeatable, profitable, AI-powered services.
• The partner ecosystem is a growth engine, and together, we’re unstoppable.
  Our 2026 priorities focus on deeper integration, coinnovation, empowered enablement and simplified engagement that drive partner profitability and stronger customer outcomes.

The post Partnering with Precision in 2026 appeared first on Palo Alto Networks Blog.

Cyber hygiene is just as vital as personal hygiene. Unit 42 shares tips for people of all experience levels to keep their digital lives secure.

The post Stay Secure: Why Cyber Hygiene Should Be Part of Your Personal Hygiene appeared first on Unit 42.

From Fragmented Fences to Cohesive Control

The attack surface for today’s enterprises is incredibly heterogeneous and dynamic. Applications and data are in constant motion, spanning public clouds, private data centers and edge locations. Users connect from anywhere.

For security leaders, this environment has led to an explosion in not only operational complexity, but in many cases, uncertainty. ​​Together, Nutanix and Palo Alto Networks enable security to finally match the speed and scale of these dynamic hybrid cloud environments.

The security ecosystem has become vast and complex. Point solutions accumulate to address specific gaps, yet each adds another interface, another policy language and another integration to manage. However well intentioned, this sprawl can lead directly to fractured visibility, overlapping tools and operational fatigue.

Elevate Perimeter Protection to Defense-in-Depth

Enterprises today face unprecedented security complexity as hybrid and multicloud environments become the new normal. Currently, 94% of enterprises use some form of cloud service, while 89% report having a multicloud strategy in place. This distributed reality means security is paramount: while managing cloud spending is the number one operational challenge (82% overall), security remains a major concern, affecting 79% of all organizations.

Hybrid cloud adoption offers agility, but it also introduces distinct security challenges that strain traditional approaches. Adversaries have taken notice. Hybrid and multicloud environments are prime targets because they connect sensitive data, privileged accounts and critical systems across public, and on-premises infrastructure. Perimeter-based security models, built for static networks and centralized data centers, cannot keep pace in a world where apps and data continuously move between platforms.

Defense-in-depth has become essential for addressing the inherent dynamism of today’s environments. Network visibility is required to monitor and contain east-west traffic and lateral movement of threats inside cloud environments. Identity controls must verify every user, device and interaction across a distributed workforce. Data protection must follow sensitive information as it traverses multiple clouds, data centers and edge locations.

Yet managing these protections as distinct layers is no longer viable. Each cloud provider introduces its own native security controls. Each additional tool adds another interface and another policy set to maintain. Defense-in-depth only achieves its purpose when its layers are fully unified, providing consistent control enforcement from the edge to the core, comprehensive visibility across traffic, and essential data protections for all workloads, wherever they reside.

Freedom of Choice Without Fragmentation

Hybrid environments span public clouds, private infrastructure, SaaS ecosystems and legacy on-premises systems. No single vendor can realistically cover that entire landscape, and forcing security into a single closed ecosystem risks creating gaps where those environments meet.

The answer lies in an open ecosystem approach that allows organizations to assemble best-of-breed capabilities rather than being locked into a single provider’s stack.

This flexibility empowers security teams to adapt to the unique requirements of each environment while still operating through a unified security model. Policies can be applied consistently, intelligence can be shared across layers, and protections can move in step with workloads, regardless of platform. In short, this model can effectively support freedom of choice while relieving the operational burden of managing hybrid and multicloud security.

A Unified Security Layer Across Every Environment

Open ecosystems solve the problem of choice. What remains is the challenge of bringing those best-of-breed capabilities together into a solution that is coherent and scalable.

To transform defense-in-depth from a conceptual framework into a practical system aligned to the realities of hybrid and multicloud deployments, this unified layer should be built on core capabilities:

• Inline visibility for east-west traffic within virtualized and cloud environments, enabled by deploying next-generation firewalls directly inside virtual private networks:
  This approach inspects workload-to-workload traffic, identifies anomalous behavior and stops lateral movement before it spreads.
• Consistent policy enforcement across public cloud, private data centers and edge locations through a centralized management plane:
  A single set of policies should be authored once and pushed everywhere, assuring a consistent security posture across all clouds and environments.
• Abstraction of security intent from network coordinates through tag-driven automation, an approach that allows security policies to be expressed in terms of workload attributes (rather than IPs or locations):
  These protections follow workloads automatically as they move. Through integration with orchestration pipelines, this approach aligns controls with rapid application rollouts in CI/CD workflows, all without manual reconfiguration.

With these core capabilities, security can finally catch up to the fluidity promised by hybrid cloud operating models.

Explore how Palo Alto Networks and Nutanix, work together to make this unified vision a reality, including joint offerings, like Palo Alto Networks secured Nutanix clusters with VM-Series Firewalls for AWS^® and Microsoft^® Azure.

The post Untangling Hybrid Cloud Security appeared first on Palo Alto Networks Blog.

We are proud to announce that Frost & Sullivan has recognized Palo Alto Networks Prisma^® Browser as the best-positioned market leader in the Frost Radar: Zero Trust Browser Security (ZTBS), 2025 report, securing the premier position for innovation and a leadership position on growth.

This recognition comes at a pivotal moment. For the modern enterprise, the browser is no longer just an application; it is your new OS. With 85% of the work happening in browsers, it has become the focal point where revenue is generated and sensitive data is accessed. However, this shift has transformed your primary workspace into the primary attack vector, with 95% of organizations having reported a security incident originating in the browser, placing it on the frontline against sophisticated AI^® threats and critical vulnerabilities. The risk of evasive, AI-driven phishing attempts is compounded by the widespread use of managed and unmanaged devices, creating blind spots that allow sensitive data to be exfiltrated faster than ever.

To combat this, enterprises need a browser that doesn't just display the web but actively defends it with its users, apps, data and devices. This is a necessity that drives our latest industry recognition.

Proven Leadership Validated by the Market

Prisma Browser’s recognition as the best-positioned leader, securing the premier position for innovation and a leadership position on growth, is a testament to our commitment to deliver best-in-class security that is both easy to deploy and that IT and users love to use. By integrating Palo Alto Networks Precision AI^® technology, Cloud-Delivered Security Services (CDSS) and Enterprise DLP, we ensure our customers benefit from the power of our security engines. And because they are natively integrated in the browser, we are mitigating threats hiding in encrypted traffic, blind spot web channels, AI-powered spear phishing and other evasive web threats that legacy security tools simply cannot identify.

Prisma Browser’s Innovation Advantage

Our leadership is driven by continuous strategic innovation in the secure browser space. Prisma Browser delivers critical "last-mile" protection through the native integration of CDSS, including Advanced WildFire^® for zero-day malware analysis and Advanced URL Filtering instantly at the point of user interaction. Building on this foundation, our latest innovations extend secure work to all applications, including those beyond SSO, providing full visibility and last-mile protection for unmanaged applications, such as GenAI apps, closing gaps left by incomplete identity coverage. We further solidify this best-in-class security through additional cutting-edge innovations: Advanced Web Protection for real-time evasive threat protection, Advanced Browser Protection for zero-day browser exploitation defense, and Advanced Extension Security for runtime extension security.

At the core of this defense is Precision AI, our proprietary engine that combines machine learning, deep learning and generative AI to automate detection, prevention and remediation with industry-leading accuracy. Unlike standard security tools that rely on static signatures, Prisma Browser, powered by Precision AI, inspects live, fully rendered content. It detects evasive phishing attempts (such as AI-generated cloaking) and malicious reassembly attacks that legacy tools miss, effectively fighting AI with AI. Fueled by intelligence from over 70 thousand customers, Prisma Browser delivers unmatched threat detection, identifying and blocking up to 8.95 million new and unique attacks every single day.

The Frost Report says this about Palo Alto Networks Innovation:

Key differentiating capabilities include last-mile data leakage protection with browser-level visibility; AI-powered web attack detection and prevention with full page runtime visibility; detection and disabling of malicious extensions using behavioral monitoring; an advanced AI-powered DLP engine; in-browser anti-exploit protection; and a rich library of AI applications and agents.

Crucially, Enterprise DLP capabilities are embedded directly into the rendering engine, granting granular control over sensitive data that traditional network-level tools effectively miss. This helps ensure that data on both managed and unmanaged devices remains secure against exfiltration via clipboard restrictions, screenshot blocking, real-time redaction and more, without disrupting the user experience.

Prisma Browser’s Growth Advantage

Central to the widespread adoption of Prisma Browser is our proven ability to secure the managed workforce at scale without disrupting daily workflows. One of our key differentiators is our 100% license portability, which allows organizations to deploy Prisma Browser across their entire fleet of devices, whether as full browsers, extensions, mobile solutions and firewall connectors with complete flexibility. This frictionless deployment model enables IT teams to instantly layer enterprise-grade security and unified policies onto the same native browser UX employees already know and use.

For CISOs and CIOs focused on streamlining operations, Prisma Browser is also offered as a fully integrated solution within the Prisma^® SASE platform, enabling unified policies across all Palo Alto Networks solutions.

Looking Ahead

While we are proud of our position on the Frost Radar: Zero Trust Browser Security (ZTBS) report, we are just getting started. By accelerating initiatives in GenAI security, complete web protection, modern data protection and VDI reduction, we are redefining the browser. We don't just want the browser to be where you work; we are transforming it from the primary attack vector into one of the organization's most robust lines of defense and the single point where they can identify AI driven attacks and fight AI with AI.

Read the full Frost Radar: Zero Trust Browser Security (ZTBS), 2025 report to explore the details behind our market leadership. Then, schedule a demo to witness how Prisma Browser transforms your primary workspace into your strongest line of defense.

The post Redefining Workspace: Prisma Browser Secures Leadership in Frost Radar appeared first on Palo Alto Networks Blog.

There’s a clear trend emerging with many organizations transitioning from legacy SIEMs to Google SecOps. While the Google SIEM platform is powerful, in our experience working with enterprise clients, that power only reveals itself when security leaders make three early decisions correctly:

• Detection strategy: Whether to migrate existing rules or start fresh with a green-field approach.
• Data onboarding: How to scale ingestion across multi-cloud environments without breaking pipelines.
• Operating model: Building workflows that prevent “alert debt” from piling up on day one.

The strategic message is clear. Treat SIEM detection management with the same diligence you treat core security architecture, and augment your analysts with AI-powered triage so your humans can focus on higher-order investigations.

Here’s a practical checklist for discovery, migration, and operational success, designed for CISOs and SOC leaders evaluating a move to Google SecOps.

NOTE: This blog post is relevant to anyone considering a Chronicle SIEM migration as Google SecOps is the new Google branding for Chronicle.

The tl;dr version of the Google SIEM migration checklist 

Phase	Key focus
Pre-Migration	Inventory, pain-point assessment, business justification
Migration	Tool selection, data ingestion, rule/dashboard migration, Integration, governance & risk
Post-Migration	Measurement of success, continuous improvement, cost optimisation, governance & reporting

Full Google SecOps migration checklist

Let’s dive into the details for each phase of the migration process.

Pre-migration checklist: Establishing the baseline

1. Inventory current environment
   
   • Catalogue all data sources feeding Splunk: log types, volumes (GB/day), retention policies, on-prem vs cloud vs multi-cloud.
     
   • Map all current detections, dashboards, reports, playbooks, SOAR workflows.
     
   • Identify any compliance/regulatory retention obligations (audit logs, legal hold).
     
   • Establish current licensing costs, infrastructure (forwarders, indexers), staffing.
     
2. Assess SIEM performance & pain points
   
   • Are you seeing cost escalation vs benefit (slower detection, high false positives, low automation)?
     
   • Is the SIEM struggling with data volume growth, scalability, multi-cloud telemetry?
     
   • Are SOC analysts spending more time on infrastructure/configuration than investigations?
     
   • Are you able to integrate newer requirements (cloud workloads, containers, IoT/OT, multi-cloud) effectively? This 451 Research report indicates many orgs run multiple SIEMs due to tool sprawl.
     
3. Define business & security objectives
   
   • What do you hope to achieve? E.g., faster detection/response, lower cost, improved coverages, cloud alignment.
     
   • What are the key metrics: mean time to detect (MTTD), mean time to respond (MTTR), cost-per-alert, false positive rate, regulatory coverage, etc.
     
   • What is your target SOC maturity in e.g., 12-24 months? Are you planning a cloud-first strategy, heavier automation/AI, less on-prem infrastructure?
     
4. Build the migration justification
   
   • Prepare a comparative TCO/ROI: legacy SIEM vs cloud-native. Google SecOps materials claim e.g., “ingest and analyse your data at Google speed and scale” and highlight cost benefit.
     
   • Understand what it will cost to migrate: re-write detections, dashboards, data flows, training, potential downtime.
     
   • Present risk assessment: What happens if you don’t migrate (risk of obsolete tool, scaling failure, cost spirals)? The “Great SIEM Migration” guide argues that legacy tools may become “dinosaurs”.

Migration-phase checklist: Executing the transition

5. Select migration path & vendor/partner support
   
   • Decide: full rip & replace vs phased migration vs augmentation (run new platform in parallel).
     
   • Choose a partner / vendor with proven migration experience (for example: Netenrich claims “Seamless SIEM Migration from Splunk to Google SecOps” with week-by-week plan).
     
   • Evaluate tooling for data-migration, rule conversion, playbook migration.
     
6. Data ingestion, normalization & compatibility
   
   • Ensure: all of your log types/sources in Splunk are supported by the new platform. Google SecOps supports ingestion of Splunk CIM logs.
     
   • Plan for data mapping: Splunk field names, dashboards, custom fields → new schema.
     
   • Address historic data: Will you migrate archives? Will you keep Splunk as store-only? Community posts warn that mapping old archives can be complex.
     
   • Validate performance: test ingestion, query latency, retention policies on the new platform.
     
7. Detection rules, dashboards, SOAR workflows
   
   • Catalogue existing detection rules, dashboards, SOAR playbooks in Splunk.
     
   • Determine which can be reused, which need rewriting. Ensure parity: detection coverage, mapping to MITRE ATT&CK, business use-cases. Splunk claims strong out-of-box detection library.
     
   • Build and test new rules/playbooks in Google SecOps; validate they meet or exceed current performance (MTTD, MTTR, false positives).
     
   • Ensure analyst training and new workflows are adopted: new UI, new query language, new incident-investigation flows (Google SecOps offers “Gemini in security operations” natural-language assistant).
     
8. Integration & ecosystem fit
   
   • Ensure that Google SecOps integrates with your existing tool-stack (EDR, identity, network, cloud logs, SOAR, threat intel). Google advertises 300+ SOAR integrations.
     
   • Confirm multi-cloud/on-prem data ingestion: check vendor statements.
     
   • Validate APIs, custom connectors, forwarder architecture. Splunk vs Google SecOps comparison note: Splunk emphasizes hybrid flexibility.
     
9. Governance, compliance & retention
   
   • Check how historic data will be retained, archived, accessed, both for compliance (audits/regulators) and investigations.
     
   • Confirm where the data resides (region/residency rules), encryption, access controls. Google SecOps claims to treat all data as first-party.
     
   • Align on SLAs, incident response metrics, roles & responsibilities.
     
   • Define cut-over strategy: Will Splunk be decommissioned or kept in read-only mode? Define freeze date, dual-runs, parallel operations.
     
10. Risk management & business continuity
    
    • Define fallback/rollback plans: If the new platform fails, do you have the old SIEM in warm standby?
      
    • Monitor for data loss/misalignment during migration (NXLog warns of risks).
      
    • Communicate to stakeholders: SOC analysts, business units, auditors. Ensure training and change-management.
      
    • Set benchmarks and metrics: Time to detect/resolve in new platform vs old; cost per alert; staff utilisation; alert volumes; false positives.

Post-migration checklist: Optimizing & sustaining value

11. Validate outcomes & measure success
    
    • Measure MTTD, MTTR, alert volumes, analyst productivity pre- and post-migration.
      
    • Compare actual cost savings vs business case.
      
    • Assess detection coverage: Are all critical use-cases still covered? Are any gaps emerging?
      
    • Run periodic health checks (some vendors like CardinalOps offer detection-rule health monitoring with MITRE ATT&CK coverage for Google SecOps).
      
12. Continuous improvement & SOC maturity evolution
    
    • SOC maturity doesn’t stop at migration. Use freed-up resources to focus on advanced use-cases (threat hunting, proactive detection, automation, investigations).
      
    • Tune detection rules, remove noise, refine playbooks.
      
    • Leverage AI/natural-language features (Google SecOps touts “Gemini in security operations”).
      
    • Plan for future: hybrid/multi-cloud expansions, new telemetry sources, OT/IoT, supply-chain threats.
      
13. Decommission legacy infrastructure & optimise cost
    
    • If the migration path included decommissioning the old SIEM (or reducing its role), ensure you turn off unneeded licences/infra.
      
    • Monitor the cost model of the new platform: ingestion volumes, retention policies—ensure you don’t inadvertently pay for excess.
      
    • Re-allocate resources: freed licences, server hardware, staff time — invest into SOC capability rather than maintenance.
      
14. Governance, audit and stakeholder reporting
    
    • Update your SOC governance frameworks: incident-response playbooks, escalation paths, KPIs aligned with the new platform.
      
    • Communicate to board/executive leadership key outcomes: improved detection/response, cost rationalization, strategic alignment.
      
    • Ensure audit/compliance reports reflect the new tooling (document changes, validate controls).
      
    • Set up periodic reviews of tool performance, vendor roadmap, SOC maturity.
      

Final thoughts

Migrating to Google SecOps isn’t a simple platform swap, it’s a redesign of how your SOC operates. The upside: cost efficiency, scale, and automation can be immediate. The risks: migration complexity, content gaps, and operational disruption are real and must be managed deliberately.

As a CISO or SOC leader, treat this as a transformation program. Use the table and/or the full Checklist above to drive decisions; follow a strategic landing plan to sequence work; and anchor on the three non-negotiables outlined above:

1. A clear detection strategy (migrate only if the value is there; rebuild the rest in YARA-L),
   
2. Data onboarding at scale with a parser matrix and cost guardrails, and
   
3. An operating model that prevents alert debt from day one through automation and measurable KPIs.

If you want help getting there faster, we can provide a SIEM jumpstart (curated + bespoke YARA-L rules, MITRE gap analysis and coverage, detection reviews, continuous improvement with Intezer engineers), a parser/ingestion plan for multi-cloud, and of course, Intezer Forensic AI SOC’s triage to meet on day-one, 100% alert coverage with full auditability so your analysts focus on the few cases that truly need their context and expertise.

Learn more about how Intezer can help you with your SecOps migration.

The post Comprehensive Google SecOps migration checklist for CISOs and SOC leaders appeared first on Intezer.

We are excited to announce the launch of Saved Searches in Google Threat Intelligence (GTI) and VirusTotal (VT), a powerful new feature designed to streamline your threat hunting workflows and foster seamless collaboration across your security team.

Every CIO and CISO we speak with describes the same paradox: AI is now central to their transformation agenda, yet the fastest way to derail that agenda is to lose control of AI. As generative AI, agentic systems and embedded AI features spread across the enterprise, leaders are no longer asking if they need AI security; they’re asking what kind of AI security strategy will actually scale.

Gartner^® has published two recent reports that validate this reality and outline the strategic direction enterprises must take to secure their AI:

• GMs: Win the AI Security Battle With an AI Security Platform (available as a complimentary reprint from Palo Alto Networks).
• AI Vendor Race: Palo Alto Networks Is the Company to Beat in AI Security Platforms, published December 8, 2025.

Why AI Security Is a Platform Game

Point products can plug individual gaps, but they can’t keep up with the speed, complexity and interconnected nature of AI adoption. And more importantly, they struggle to deliver the trust, consistency or scale AI transformation requires.

Many organizations are already experiencing AI adoption outpacing traditional security tools. Security teams are under pressure on three fronts:

• Risk – Shadow AI, unmanaged agents and custom LLMs create new pathways for data loss, intellectual property exposure and model misuse.
• Cost – Each new AI use case brings yet another tool, driving up license, integration and operations costs.
• Complexity – Fragmented controls across network, data, identity and application stacks create blind spots exactly where AI is moving fastest.

From a CIO or CISO’s perspective, this isn’t just a technical concern but the fault line beneath their entire AI agenda. CIOs are under pressure to deliver productivity gains, cost efficiencies and new AI-powered capabilities faster than ever before.

CISOs, on the other hand, see a parallel reality: custom-built AI applications that may be insecure by default, agents that can act unpredictably, and a constant risk that company secrets or customer data could leak into third-party GenAI tools.

If AI moves forward without security, the enterprise is exposed. If AI slows down because security can’t keep up, the business misses its transformation goals. This is why AI security isn’t a feature; it’s the determining factor in whether AI becomes a competitive advantage or a strategic setback.

Gartner recommends the path forward as “an integrated modular AI security platform (AISP) with a common UI, data model, content inspection engine and consistent policy enforcement.”

Gartner further recommends prioritizing investments in two phases.

Phase 1

Start with AI usage control to secure the consumption of third-party AI services.

Phase 2

Expand into AI application protection to securely develop and run AI applications.

Phase 1: Securing Generative AI Usage Is the “Right Now” Challenge

Before enterprises can secure how AI is developed, they must first understand how it is already being used across the organization. The earliest risks often emerge not from the AI-enabled apps built in-house, but from the external generative AI tools and copilots employees adopt, and often without the IT teams’ knowledge.

That’s why we think the report identifies AI usage control as phase one and why we recommend IT leaders start with these immediate questions to assess their organization’s AI usage.

• Where is AI actually being used in my organization?
• Which tools, copilots and agents are in play, and on what data?
• How do I enable productivity without losing control?

Phase 2: Securing AI Development Early Into the AI Lifecycle

Once public generative AI use is understood, the harder challenge emerges: Securing the AI apps and tools that your organization creates for itself. As models, agents and pipelines move into production, the questions shift from visibility to integrity, safety and scale.

Key questions that organizations must answer in phase two include:

• What AI applications, models and agents are my teams building, and where do they live?
• How do I manage the integrity, safety and compliance of AI apps before they reach production?
• How do I protect models and AI applications from prompt injection, misuse or agentic threats?
• How do I scale AI innovation without creating security bottlenecks for developers?

Palo Alto Networks Delivers the AI Security Platform

Although organizations can separate the work around securing AI usage and AI development, they are not two separate problems. The same organization that needs visibility into employees using public GenAI apps also needs to protect the AI applications and agents they’ve built as they move into production. A platform approach is what allows shared policies, shared guardrails and shared context across both sides of the AI usage and development equation.

That is exactly the philosophy behind our Secure AI by Design approach:

• Secure how GenAI is used with Prisma^® Browser and Prisma SASE to discover AI tools in use, govern access and prevent sensitive data from flowing into public models, all while keeping users productive with GenAI and enterprise copilots.
• Secure how AI is built with capabilities of Prisma AIRS, such as model and agent security, AI security posture management, runtime protection, automated testing with AI Red Teaming, as well as coverage for agentic protocols, like MCP, securing custom AI applications, agents and pipelines.

Gartner identifies Palo Alto Networks as “the company to beat” in their newly released report as of December 8, 2025: “AI Vendor Race: Palo Alto Networks Is the Company to Beat in AI Security Platforms.”

We believe we are the AI Security Platform to beat because:

• Palo Alto Networks product portfolio across network, edge, cloud and data provides a strong foundation for AI usage visibility and control.
• The acquisition of Protect AI integrated industry-leading AI talent and products resulting in the recently announced Prisma AIRS 2.0, which delivers comprehensive end-to-end AI security, seamlessly connecting deep AI agent and model inspection in development with real-time agent defense at production runtime. The platform, continuously validated by autonomous AI red teaming, secures all interactions between AI models, agents, data and users. This gives enterprises the confidence to discover, assess and protect their entire AI ecosystem, accelerating secure innovation.
• Complementing the platform, Unit 42^®’s deep expertise and Huntr’s bug bounty program, provide security thought leadership that directly improves product effectiveness and threat intelligence. These programs help us continuously uncover new attack patterns, misconfigurations and supply chain risks unique to AI systems, as well as feed those insights directly back into the product roadmap.
• Our large installed base and distribution channels create a flywheel for AI security platform adoption and learning from our customers and partners.

We also believe that underneath the technical requirements is a deeper truth: CIOs and CISOs want to move fast on AI, but they only feel safe doing so with a partner who has the scale, signal and staying power. This is where our breadth, research depth and ecosystem matter.

Leading Responsibly Means Listening, Innovating and Evolving

Being early is an advantage, but staying ahead requires humility and continuous learning. Leading means seeing what comes next, and Gartner’s insights accelerate our own roadmap as we continue to evolve.

• Simplifying the Experience: We are integrating capabilities across Prisma AIRS, Prisma SASE and Prisma Browser to make AI security easier to adopt, operate and scale through Strata Cloud Manager as the single entry point.
• Going Deeper into the AI Engineering Pipeline: We recognize that securing AI must start early in the developing environment and ML pipeline, not just at runtime. Our integrations with AI development tools and code repositories will continue to expand.
• Keeping Pace with a Fast-Moving Market: We are investing in open standards, partnerships and research, so our customers don’t have to chase every point solution that appears. Palo Alto Networks is also a contributing member to OWASP Standards and Threat analysis to help create an industry standard on AI security.
• Working Along Native AI Controls: Cloud providers and AI platforms are adding their own security features. We aim to complement, not replace, those controls, providing unified visibility, advanced protection and consistent policies across a fragmented AI landscape.

For us, being “the company to beat” is not a finish line. It’s a responsibility to listen carefully to customers, adapt as AI evolves, and keep delivering practical, integrated outcomes rather than isolated features.

If you are a GM, CIO, CISO or AI leader trying to make sense of a rapidly crowding AI security landscape, we believe “GMs: Win the AI Security Battle With an AI Security Platform”​​ is essential reading.

In the end, the real race isn’t about features; it’s about who helps enterprises accelerate transformation safely, reduce risk and compete better with AI they can trust.

 

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

Gartner, AI Vendor Race: Palo Alto Networks is the Company to Beat in AI Security Platforms, By Mark Wah, Neil MacDonald, Marissa Schmidt, Dennis Xu, Evan Zeng, 8 December 2025. 

Gartner, GMs: Win the AI Security Battle With an AI Security Platform, By Neil MacDonald, Tarun Rohilla, 6 October 2025.

GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.

The post Winning the AI Race Starts with the Right Security Platform appeared first on Palo Alto Networks Blog.

Posted by Liz Prucka, Hamzeh Zawawy, Rishika Hooda, Android Security and Privacy Team

Last year, Google's Android Red Team partnered with Arm to conduct an in-depth security analysis of the Mali GPU, a component used in billions of Android devices worldwide. This collaboration was a significant step in proactively identifying and fixing vulnerabilities in the GPU software and firmware stack.

While finding and fixing individual bugs is crucial, and progress continues on eliminating them entirely, making them unreachable by restricting attack surface is another effective and often faster way to improve security. This post details our efforts in partnership with Arm to further harden the GPU by reducing the driver's attack surface.

The Growing Threat: Why GPU Security Matters

The Graphics Processing Unit (GPU) has become a critical and attractive target for attackers due to its complexity and privileged access to the system. The scale of this threat is significant: since 2021, the majority of Android kernel driver-based exploits have targeted the GPU. These exploits primarily target the interface between the User-Mode Driver (UMD) and the highly privileged Kernel-Mode Driver (KMD), where flaws can be exploited by malicious input to trigger memory corruption.

Partnership with Arm

Our goal is to raise the bar on GPU security, ensuring the Mali GPU driver and firmware remain highly resilient against potential threats. We partnered with Arm to conduct an analysis of the Mali driver, used on approximately 45% of Android devices. This collaboration was crucial for understanding the driver’s attack surface and identifying areas that posed a security risk, but were not necessary for production use.

The Right Tool for the Job: Hardening with SELinux

One of the key findings of our investigation was the opportunity to restrict access to certain GPU IOCTLs. IOCTLs act as the GPU kernel driver’s user input and output, as well as the attack surface. This approach builds on earlier kernel hardening efforts, such as those described in the 2016 post Protecting Android with More Linux Security. Mali ioctls can be broadly categorized as:

• Unprivileged: Necessary for normal operation.
• Instrumentation: Used by developers for profiling and debugging.
• Restricted: Should not be used by applications in production. This includes IOCTLs which are intended only for GPU development, as well as IOCTLs which have been deprecated and are no longer used by a device’s current User-Mode Driver (UMD) version.

Our goal is to block access to deprecated and debug IOCTLs in production. Instrumentation IOCTLs are intended for use by profiling tools to monitor system GPU performance and are not intended to be directly used by applications in production. As such, access is restricted to shell or applications marked as debuggable. Production IOCTLs remain accessible to regular applications.

A Staged Rollout

The approach is iterative and is a staged rollout for devices using the Mali GPU. This way, we were able to carefully monitor real-world usage and collect data to validate the policy, minimizing the risk of breaking legitimate applications before moving to broader adoption:

1. Opt-In Policy: We started with an "opt-in" policy. We created a new SELinux attribute, gpu_harden, that disallowed instrumentation ioctls. We then selectively applied this attribute to certain system apps to test the impact. We used the allowxperm rule to audit, but not deny, access to the intended resource, and monitored the denial logs to ensure no breakage.
2. Opt-Out Policy: Once we were confident that our approach was sound, we moved to an "opt-out" policy. We created a gpu_debug domain that would allow access to instrumentation ioctls. All applications were hardened by default, but developers could opt-out by:

• Running on a rooted device.
• Setting the android:debuggable="true" attribute in their app's manifest.
• Requesting a permanent exception in the SELinux policy for their application.

This approach allowed us to roll out the new security policy broadly while minimizing the impact on developers.

Step by Step instructions on how to add your Sepolicy

To help our partners and the broader ecosystem adopt similar hardening measures, this section provides a practical, step-by-step guide for implementing a robust SELinux policy to filter GPU ioctls. This example is based on the policy we implemented for the Mali GPU on Android devices.

The core principle is to create a flexible, platform-level macro that allows each device to define its own specific lists of GPU ioctl commands to be restricted. This approach separates the general policy logic from the device-specific implementation.

Official documentation detailing the added macro and GPU security policy is available at:

SELinux Hardening Macro: GPU Syscall Filtering

Android Security Change: Android 16 Behavior Changes

Step 1: Utilize the Platform-Level Hardening Macro

The first step is to use a generic macro that we built in the platform's system/sepolicy that can be used by any device. This macro establishes the framework for filtering different categories of ioctls.

In the file/sepolicy/public/te_macros, a new macro is created. This macro allows device-specific policies to supply their own lists of ioctls to be filtered. The macro is designed to:

• Allow all applications (appdomain) access to a defined list of unprivileged ioctls.
• Restrict access to sensitive "instrumentation" ioctls, only permitting them for debugging tools like shell or runas_app when the application is debuggable.
• Block access to privileged ioctls based on the application's target SDK version, maintaining compatibility for older applications.

Step 2: Define Device-Specific IOCTL Lists

With the platform macro in place, you can now create a device-specific implementation. This involves defining the exact ioctl commands used by your particular GPU driver.

1. Create an ioctl_macros file in your device's sepolicy directory (e.g., device/your_company/your_device/sepolicy/ioctl_macros).
2. Define the ioctl lists inside this file, categorizing them as needed. Based on our analysis, we recommend at least mali_production_ioctls, mali_instrumentation_ioctls, and mali_debug_ioctls. These lists will contain the hexadecimal ioctl numbers specific to your driver.

   For example, you can define your IOCTL lists as follows:

   define(`unpriv_gpu_ioctls', `0x0000, 0x0001, 0x0002')
   define(`restricted_ioctls', `0x1110, 0x1111, 0x1112')
   define(`instrumentation_gpu_ioctls', `0x2220, 0x2221, 0x2222')

Arm has provided official categorization of their IOCTLs in Documentation/ioctl-categories.rst of their r54p2 release. This list will continue to be maintained in future driver releases.

Step 3: Apply the Policy to the GPU Device

Now, you apply the policy to the GPU device node using the macro you created.

1. Create a gpu.te file in your device's sepolicy directory.
2. Call the platform macro from within this file, passing in the device label and the ioctl lists you just defined.

Step 4: Test, Refine, and Enforce

As with any SELinux policy development, the process should be iterative. This iterative process is consistent with best practices for SELinux policy development outlined in the Android Open Source Project documentation.

Conclusion

Attack surface reduction is an effective approach to security hardening, rendering vulnerabilities unreachable. This technique is particularly effective because it provides users strong protection against existing but also not-yet-discovered vulnerabilities, and vulnerabilities that might be introduced in the future. This effort spans across Android and Android OEMs, and required close collaboration with Arm. The Android security team is committed to collaborating with ecosystem partners to drive broader adoption of this approach to help harden the GPU.

Acknowledgments

Thank you to Jeffrey Vander Stoep for his valuable suggestions and extensive feedback on this post.

Posted by Nathan Parker, Chrome security team

Chrome has been advancing the web’s security for well over 15 years, and we’re committed to meeting new challenges and opportunities with AI. Billions of people trust Chrome to keep them safe by default, and this is a responsibility we take seriously. Following the recent launch of Gemini in Chrome and the preview of agentic capabilities, we want to share our approach and some new innovations to improve the safety of agentic browsing.

The primary new threat facing all agentic browsers is indirect prompt injection. It can appear in malicious sites, third-party content in iframes, or from user-generated content like user reviews, and can cause the agent to take unwanted actions such as initiating financial transactions or exfiltrating sensitive data. Given this open challenge, we are investing in a layered defense that includes both deterministic and probabilistic defenses to make it difficult and costly for attackers to cause harm.

Designing safe agentic browsing for Chrome has involved deep collaboration of security experts across Google. We built on Gemini's existing protections and agent security principles and have implemented several new layers for Chrome.

We’re introducing a user alignment critic where the agent’s actions are vetted by a separate model that is isolated from untrusted content. We’re also extending Chrome’s origin-isolation capabilities to constrain what origins the agent can interact with, to just those that are relevant to the task. Our layered defense also includes user confirmations for critical steps, real-time detection of threats, and red-teaming and response. We’ll step through these layers below.

Checking agent outputs with User Alignment Critic

The main planning model for Gemini uses page content shared in Chrome to decide what action to take next. Exposure to untrusted web content means it is inherently vulnerable to indirect prompt injection. We use techniques like spotlighting that direct the model to strongly prefer following user and system instructions over what’s on the page, and we’ve upstreamed known attacks to train the Gemini model to avoid falling for them.

To further bolster model alignment beyond spotlighting, we’re introducing the User Alignment Critic — a separate model built with Gemini that acts as a high-trust system component. This architecture is inspired partially by the dual-LLM pattern as well as CaMeL research from Google DeepMind.

A flow chart that depicts the User Alignment Critic: a trusted component that vets each action before it reaches the browser.

The User Alignment Critic runs after the planning is complete to double-check each proposed action. Its primary focus is task alignment: determining whether the proposed action serves the user’s stated goal. If the action is misaligned, the Alignment Critic will veto it. This component is architected to see only metadata about the proposed action and not any unfiltered untrustworthy web content, thus ensuring it cannot be poisoned directly from the web. It has less context, but it also has a simpler job — just approve or reject an action.

This is a powerful, extra layer of defense against both goal-hijacking and data exfiltration within the action step. When an action is rejected, the Critic provides feedback to the planning model to re-formulate its plan, and the planner can return control to the user if there are repeated failures.

Enforcing stronger security boundaries with Origin Sets

Site Isolation and the same-origin policy are fundamental boundaries in Chrome’s security model and we’re carrying forward these concepts into the agentic world. By their nature, agents must operate across websites (e.g. collecting ingredients on one site and filling a shopping cart on another). But if an unrestricted agent is compromised and can interact with arbitrary sites, it can create what is effectively a Site Isolation bypass. That can have a severe impact when the agent operates on a local browser like Chrome, with logged-in sites vulnerable to data exfiltration. To address this, we’re extending those principles with Agent Origin Sets. Our design architecturally limits the agent to only access data from origins that are related to the task at hand, or data that the user has chosen to share with the agent. This prevents a compromised agent from acting arbitrarily on unrelated origins.

For each task on the web, a trustworthy gating function decides which origins proposed by the planner are relevant to the task. The design is to separate these into two sets, tracked for each session:

• Read-only origins are those from which Gemini is permitted to consume content. If an iframe’s origin isn’t on the list, the model will not see that content.
• Read-writable origins are those on which the agent is allowed to actuate (e.g., click, type) in addition to reading from.

This delineation enforces that only data from a limited set of origins is available to the agent, and this data can only be passed on to the writable origins. This bounds the threat vector of cross-origin data leaks. This also gives the browser the ability to enforce some of that separation, such as by not even sending to the model data that is outside the readable set. This reduces the model’s exposure to unnecessary cross-site data. Like the Alignment Critic, the gating functions that calculate these origin sets are not exposed to untrusted web content. The planner can also use context from pages the user explicitly shared in that session, but it cannot add new origins without the gating function’s approval. Outside of web origins, the planning model may ingest other non-web content such as from tool calls, so we also delineate those into read-vs-write calls and similarly check that those calls are appropriate for the task.

Iframes from origins that aren’t related to the user’s task are not shown to the model.

Page navigations can happen in several ways: If the planner decides to navigate to a new origin that isn’t yet in the readable set, that origin is checked for relevancy by a variant of the User Alignment critic before Chrome adds it and starts the navigation. And since model-generated URLs could exfiltrate private information, we have a deterministic check to restrict them to known, public URLs. If a page in Chrome navigates on its own to a new origin, it’ll get vetted by the same critic.

Getting the balance right on the first iteration is hard without seeing how users’ tasks interact with these guardrails. We’ve initially implemented a simpler version of origin gating that just tracks the read-writeable set. We will tune the gating functions and other aspects of this system to reduce unnecessary friction while improving security. We think this architecture will provide a powerful security primitive that can be audited and reasoned about within the client, as it provides guardrails against cross-origin sensitive data exfiltration and unwanted actions.

Transparency and control for sensitive actions

We designed the agentic capabilities in Chrome to give the user both transparency and control when they need it most. As the agent works in a tab, it details each step in a work log, allowing the user to observe the agent's actions as they happen. The user can pause to take over or stop a task at any time.

This transparency is paired with several layers of deterministic and model-based checks to trigger user confirmations before the agent takes an impactful action. These serve as guardrails against both model mistakes and adversarial input by putting the user in the loop at key moments.

First, the agent will require a user confirmation before it navigates to certain sensitive sites, such as those dealing with banking transactions or personal medical information. This is based on a deterministic check against a list of sensitive sites. Second, it’ll confirm before allowing Chrome to sign-in to a site via Google Password Manager – the model does not have direct access to stored passwords. Lastly, before any sensitive web actions like completing a purchase or payment, sending messages, or other consequential actions, the agent will try to pause and either get permission from the user before proceeding or ask the user to complete the next step. Like our other safety classifiers, we’re constantly working to improve the accuracy to catch edge cases and grey areas.

Illustrative example of when the agent gets to a payment page, it stops and asks the user to complete the final step.

Detecting “social engineering” of agents

In addition to the structural defenses of alignment checks, origin gating, and confirmations, we have several processes to detect and respond to threats. While the agent is active, it checks every page it sees for indirect prompt injection. This is in addition to Chrome’s real-time scanning with Safe Browsing and on-device AI that detect more traditional scams. This prompt-injection classifier runs in parallel to the planning model’s inference, and will prevent actions from being taken based on content that the classifier determined has intentionally targeted the model to do something unaligned with the user’s goal. While it cannot flag everything that might influence the model with malicious intent, it is a valuable layer in our defense-in-depth.

Continuous auditing, monitoring, response

To validate the security of this set of layered defenses, we’ve built automated red-teaming systems to generate malicious sandboxed sites that try to derail the agent in Chrome. We start with a set of diverse attacks crafted by security researchers, and expand on them using LLMs following a technique we adapted for browser agents. Our continuous testing prioritizes defenses against broad-reach vectors such as user-generated content on social media sites and content delivered via ads. We also prioritize attacks that could lead to lasting harm, such as financial transactions or the leaking of sensitive credentials. The attack success rate across these give immediate feedback to any engineering changes we make, so we can prevent regressions and target improvements. Chrome’s auto-update capabilities allow us to get fixes out to users very quickly, so we can stay ahead of attackers.

Collaborating across the community

We have a long-standing commitment to working with the broader security research community to advance security together, and this includes agentic safety. We’ve updated our Vulnerability Rewards Program (VRP) guidelines to clarify how external researchers can focus on agentic capabilities in Chrome. We want to hear about any serious vulnerabilities in this system, and will pay up to $20,000 for those that demonstrate breaches in the security boundaries. The full details are available in VRP rules.

Looking forward

The upcoming introduction of agentic capabilities in Chrome brings new demands for browser security, and we've approached this challenge with the same rigor that has defined Chrome's security model from its inception. By extending some core principles like origin-isolation and layered defenses, and introducing a trusted-model architecture, we're building a secure foundation for Gemini’s agentic experiences in Chrome. This is an evolving space, and while we're proud of the initial protections we've implemented, we recognize that security for web agents is still an emerging domain. We remain committed to continuous innovation and collaboration with the security community to ensure Chrome users can explore this new era of the web safely.

What It Means and How to Counter Autonomous Offensive Cyber Agents

For years, we've anticipated this day. With the release of Anthropic's landmark report (detailing the disruption of a cyberespionage operation orchestrated by AI agents with minimal human intervention), the reality of autonomous offensive cyber agents has moved from speculation to an active, machine-speed threat. The report covers their internal identification and analysis of artifacts from the GTG-1002 campaign, which was conducted against over 30 different enterprise targets. This event is independently being tracked in the AI Incident Database as incident 1263. To have a successful defense in the age of AI, we need an immediate shift from human-led, reactive security to a proactive, machine-driven security paradigm.

The GTG-1002 campaign is the first open report of an AI agent, powered by Claude Code, targeting multiple enterprise environments. Using Claude Code as the primary orchestration framework, the agent was effective in all key phases of the attack:

• Mapping attack surfaces without human guidance.
• Exploit vulnerabilities using custom code generation.
• Moving laterally by autonomously harvesting and testing credentials.
• Conducting an intelligence analysis to identify and prioritize high-value data, rather than just exfiltrating raw dumps.

It was a watershed moment for several key reasons:

• Stealth – Traffic analysis of the inputs and outputs to Claude Code were the initial indicators of this attack, however, the attack was only observable in aggregate.
• Self-Configuration – The agent autonomously adapted its attack strategy to achieve actions on an objective.
• Machine-Speed – The agent both orchestrated AND executed the campaign across all attack vectors.
• Autonomous Context and Persistence – Using structured markdown files, the execution agent maintained a persistent state of the attack, providing context and autonomous continuity between distributed sub-actions and attack phases.

This campaign, executed at “multiple operations per second,” marks the end of the necessity for the "human-in-the-loop” attacker and the arrival of the "human-on-the-loop" supervisor. Transitions between attack phases were controlled by the human to validate sufficient completion of the current phase before progressing. It was a thin layer of supervisory human control. With the whiplash pace of AI, defenders should anticipate the necessity of any human control to fade.

In the reported attack campaign, “commodity tools” were leveraged by the threat actor, which at first glance, may not seem particularly novel. However, the autonomous orchestration of these tools across multiple attack phases by Claude Code, using Model Context Protocol (MCP) servers, represents a sophisticated technical advancement in offensive agents. Critically, this method improved more than just the speed of the attack, it also introduced the concept of autonomy with negligible human supervision, supporting dynamic and contextual reasoning in attack path planning across multiple target systems (even beyond typical human analyses, particularly for non-intuitive/interpretable event logging). Custom tools can bring very targeted actions within the same or similar offensive agent architectures, and defenders should be ready for this inevitable evolution.

We Need Agents to Fight Agents

With the debut of real-world offensive agent operations, it is now crystal clear: Defenders cannot combat autonomous, offensive AI with manual, static human driven security operations. Defenses must blend machine-speed responses with on-the-fly adaptability to maintain effectiveness against the self-optimizing campaigns now being observed. The pivot to autonomous agent-driven security operations will require transforming many elements of the traditional security operations lifecycle. All stages from preparation to response processes need to be resilient and robust to changes in adversary speed, stealth, evasion, orchestration frameworks and indicators of compromise.

Meeting the Challenges of Machine-Speed Defense Head-On

A new defense paradigm must be adopted to effectively combat AI attacks that are both orchestrated AND executed beyond human reaction time. To transform security operations and outpace AI-driven threats, organizations need to employ the following core principles:

• Precision of AI for Cybersecurity: Operating at machine speed requires precision and accuracy. Security systems must be capable of ingesting the right data, at the right time, and understanding the system context to detect and block threats in real-time, thwarting AI-generated attacks without generating erroneous alerts. Producing false positives is problematic at human speeds, and the problem compounds at machine speed.
• Proactive Cybersecurity for AI Systems: We must safeguard AI systems with real-time security solutions, preventing the models and applications from being directly or indirectly co-opted for malicious use. This demands a deep and continuous understanding of how AI agents might be abused via their application interfaces, permissions, provenance, identity and wider interactions across organizations.
• Transform Visibility into Observability: Visibility only encompasses a direct presence or absence. Observability is the combination of visibility plus some degree of cognitive and contextual reasoning. The visibility of a traffic sign does not guarantee a driver will observe and respond to it. The GTG-1002 attack evaded detection by splitting and distributing small, seemingly benign fragments of the full campaign across numerous sessions. The requests were visible, but the scope of the malicious campaign was not observed from the isolated requests. To identify and help stop such techniques, defenses need distributed observability, which can only be achieved from context-aware agents that understand the nature and impact of disparate events and can disrupt such attacks when they are identified.
• Agentic Security Operations: As an industry, we must also acknowledge the difference between autonomous and automated systems. The industry has been integrating elements of automation for years. Scripting, decision trees and playbooks are mechanisms for speeding up the response in specific context, but do not necessarily generalize or work across different phases. If the attacker is using an agentic system for 90% of the attack lifecycle, security operations centers (SOCs) must also implement an agentic system for 90% of their triage, investigation, remediation and threat hunting workflows. This must be the rule, rather than the exception. By combining observability with dynamic AI agents capable of coordinated decision making and task execution, SOCs can deliver proactive autonomous protection at scale.

The Future Is Now. Are You Ready?

The GTG-1002 campaign is a clear signal that offensive AI agents are being used in the wild. The adoption of AI agents by threat actors will accelerate and demand a decisive transformation of defensive security operations to include agent orchestration tools customized to respond to the uniqueness of offensive AI agents.

At Palo Alto Networks, our platformization strategy was built precisely for this moment. This interconnectivity between tools and systems transforms visibility into observability necessary for AI agent orchestration.

In light of GTG-1002, there is an unequivocal need for the security community to accelerate the pivot from automated to autonomous security operations. AI agents can quickly find and exploit vulnerabilities, moving stealthily across the attack chain. We must shift from human-led, reactive defense to fast, proactive machine-driven security to ensure cyber resilience in the age of AI.

Are you ready? Learn about securing AI agents and how to create a trustworthy AI ecosystem.

---

Key Takeaways

• Autonomous Orchestration and Execution: The GTG-1002 campaign was a watershed event because the AI agent, powered by Claude Code, autonomously orchestrated and executed all key phases of the attack, from mapping surfaces and exploiting vulnerabilities to moving laterally and conducting intelligence analysis at machine speed.
• Shift to Machine-Driven Security Paradigm: The emergence of autonomous offensive cyber agents, as demonstrated by the GTG-1002 campaign, demands an immediate pivot from human-led, reactive security to a proactive, machine-driven security defense model.
• Distributed Observability is Essential to Agentic Defenses: To counter new attack techniques like GTG-1002, which evade detection by splitting the campaign into small, distributed, and seemingly benign fragments, defenses must adopt distributed observability to connect disparate events using context-aware agents.

Further Reading:

• Lohn, Andrew, et al. "Autonomous Cyber Defense." A roadmap from lab to ops. Online. Centre for Emerging Technology and Security (CETaS) at The Alan Turing Institute (2023).
• Principles for the Secure Integration of Artificial Intelligence in Operational Technology

The post Crossing the Autonomy Threshold appeared first on Palo Alto Networks Blog.

The post Digital Supply Chain Risk: Critical Vulnerability Affecting React Allows for Unauthorized Remote Code Execution appeared first on Flashpoint.

Posted by Aden Haussmann, Associate Product Manager and Sumeet Sharma, Play Partnerships Trust & Safety Lead

Android uses the best of Google AI and our advanced security expertise to tackle mobile scams from every angle. Over the last few years, we’ve launched industry-leading features to detect scams and protect users across phone calls, text messages and messaging app chat notifications.

These efforts are making a real difference in the lives of Android users. According to a recent YouGov survey¹ commissioned by Google, Android users were 58% more likely than iOS users to report they had not received any scam texts in the prior week².

But our work doesn’t stop there. Scammers are continuously evolving, using more sophisticated social engineering tactics to trick users into sharing their phone screen while on the phone to visit malicious websites, reveal sensitive information, send funds or download harmful apps. One popular scam involves criminals impersonating banks or other trusted institutions on the phone to try to manipulate victims into sharing their screen in order to reveal banking information or make a financial transfer.

To help combat these types of financial scams, we launched a pilot earlier this year in the UK focused on in-call protections for financial apps.

How the in-call scam protection works on Android

When you launch a participating financial app while screen sharing and on a phone call with a number that is not saved in your contacts, your Android device³ will automatically warn you about the potential dangers and give you the option to end the call and to stop screen sharing with just one tap. The warning includes a 30-second pause period before you’re able to continue, which helps break the ‘spell’ of the scammer's social engineering, disrupting the false sense of urgency and panic commonly used to manipulate you into a scam.

Bringing in-call scam protections to more users on Android

The UK pilot of Android’s in-call scam protections has already helped thousands of users end calls that could have cost them a significant amount of money. Following this success, and alongside recently launched pilots with financial apps in Brazil and India, we’ve now expanded this protection to most major UK banks.

We’ve also started to pilot this protection with more app types, including peer-to-peer (P2P) payment apps. Today, we’re taking the next step in our expansion by rolling out a pilot of this protection in the United States⁴ with a number of popular fintechs like Cash App and banks, including JPMorganChase.

We are committed to collaborating across the ecosystem to help keep people safe from scams. We look forward to learning from these pilots and bringing these critical safeguards to even more users in the future.

Notes