Executive summary

In 2025, several threat actors exploited CVE-2025-53770 and CVE-2025-53771 (ToolShell vulnerabilities) in on-premises Microsoft SharePoint to achieve remote code execution through crafted HTTP requests. One of the threat actors deployed ransomware on the target’s systems after successful exploitation. Microsoft attributed this ransomware-related ToolShell activity to Storm-2603, distinguishing it from other actors whose observed activity was primarily focused on credential theft, espionage, and data exfiltration.

In December, our retrospective analysis identified activity consistent with Storm-2603’s TTPs. This activity involved the attacker using the IIS worker process as an in-memory bridge to the customer’s infrastructure, keeping the access and control layer entirely within w3wp.exe without writing anything to disk. Although subsequent post-exploitation activity generated disk artifacts, the bridge used to maintain access remained memory-resident.

Let’s look in more detail at this attack.

The attack chain, from reconnaissance to infrastructure compromise

Intrusion timeline: Strategic latency and exploitation

The intrusion analyzed in this report occurred in two stages, with a temporal gap between initial access and subsequent exploitation activity. The attack timeline was as follows:

• Dec 20 – Vulnerability fingerprinting: A single HTTP request targeted a SharePoint administrative endpoint associated with the ToolPane component to determine whether the host was vulnerable to CVE-2025-53770.
• Dec 21-23 – Tactical latency: A three-day period of silence followed the initial probe, separating the vulnerability fingerprinting from subsequent malicious activity and potentially reducing the likelihood of immediate detection.
• Dec 24 – High-intensity re-engagement: On Christmas Eve, when security staffing at many companies is reduced, the full RCE chain was executed through the IIS worker process (w3wp.exe) on the same endpoint as the initial probe.
• Dec 26 – Incident discovery: The three-day gap initially prevented the December 20 probe from being correlated with subsequent malicious activity, marking the event as low priority. Retrospective analysis established that the probe was the initial phase of the subsequent intrusion.

Intrusion timeline

Initial access validation phase

Vulnerability fingerprinting

A vulnerability fingerprinting request on December 20 marked the first observed interaction with the target. The request originated from infrastructure associated with ONYPHE, an internet-scale attack surface discovery and management platform for identifying exposed assets, vulnerabilities, and cyberthreats. Unlike widely used tools such as Shodan and Censys, which merely provide a list of internet-facing assets correlated with the open-source data about known vulnerabilities, ONYPHE actually checks if the target system is vulnerable.

Fingerprinting with ONYPHE

The request characteristics were consistent with ONYPHE’s vulnerability checks, which use active, non-intrusive probes to identify internet-exposed systems vulnerable to specific CVEs. For ToolShell, ONYPHE adopted the approach used by Niels Hofmans (hazcod). Namely, it attempts to inject a harmless marker into the target server to find out if it is vulnerable.

OFFICIAL ONYPHE CVE CHECKER (TOOLSHELL)

This phase served as a validation step against the SharePoint execution surface exposed over HTTP:

• The target processed structured requests through the ASP.NET pipeline without rejection.
• The request path reached application logic capable of handling serialized input.
• No defensive controls interrupted or altered the execution flow at the application boundary.

Approximately 12 minutes later, a second inbound connection originated from infrastructure associated with Pfcloud UG, a provider operating under a bulletproof hosting (BPH) model. Given the timing and the IP’s documented history of scanning and abusive activity, the connection may represent follow-on reconnaissance against the newly identified target. No exploitation was attempted at this stage.

A connection from an IP address belonging to Pfcloud UG BPH

Active exploitation: Santa took your data and left a backdoor

The main malicious activity occurred on December 24. The actor targeted the same SharePoint host with a crafted request from 45.91.94.204 (45.91.92.0/22, ASN 63473, HostHatch, LLC). This resulted in a webshell execution within the IIS worker process (w3wp.exe). The payload was not written to disk; rather, it was loaded directly into the ASP.NET runtime and used during subsequent request processing. The implant remained resident for the lifetime of the affected application domain. This runtime state was lost when the application pool was recycled or IIS was restarted.

Attack originated from an SPN node

The IP address 45.91.94.204 is a Safing Privacy Network (SPN) node. SPN routes each connection through a multilayer VPN path with multiple relay nodes that can obscure the originating IP.

SPN promotes itself as a network that offers strong privacy protection for internet traffic. Its infrastructure resembles Tor’s in many ways, but with some differences. It features the following capabilities:

• Speed: Near-VPN performance for high-speed data transfer.
• Layer 3 support: Supports multiple protocols like TCP, UDP, ICMP (unlike Tor, which only supports TCP).
• App-routing: Direct tunneling without a browser.
• Multi-identity: Simultaneous exit nodes to bypass IP rate limits.
• Fixed-size packets and padding make it harder to analyze its traffic.

It is less common than Tor, and frequently bypasses standard Tor blocklists.

Webshell architecture

The webshell the attackers injected into the w3wp.exe runtime is a multi-module in-memory framework, where execution is orchestrated through the main component (G.cs) and extended via multiple functional units across namespaces.

The implementation follows a modular C# project structure in which each capability is isolated into its own compilation unit and invoked dynamically at runtime.

Webshell components

“G.cs” pipeline control and C2

Pipeline control

The main webshell component is G.cs. It orchestrates the implant’s execution context, lifecycle, C2 and session management.

To ensure persistence within the runtime, G.cs performs the following actions:

• Registers a custom VirtualPathProvider using the non-public RegisterVirtualPassProviderInternal method from the ASP.NET HostingEnvironment class so that ASP.NET uses it for virtual-path processing. The provider is automatically added to the chain of registered virtual path providers.
  
• Delegates the provider’s .NET Remoting lifetime policy to the previous provider in the chain, preserving the existing lifetime behavior.
  

Additionally, to evade defenses and enable the VirtualPathProvider to be registered even if the application in whose AppDomain the webshell is running is precompiled, the module implements the trust control subversion (T1553) technique:

• Uses reflection to check if the application is precompiled.
• Extracts pointers for internal state fields for the BuildManager class, which manages application compilation, and modifies them at runtime.
  
• Uses reflection once again to force runtime injection.

G.cs uses the GetCacheKey() function as the interception point for the virtual path processing flow. It processes incoming requests to the SharePoint server and checks their headers to filter out requests from the attacker.

The specific User-Agent in the request headers triggers the webshell execution. If the request doesn’t match this condition, the implant remains dormant, making its traffic harder to recognize.

Command and control layer (in-memory transport)

The same core module (G.cs) implements the communication layer.

Instead of relying on external frameworks or standard beacons, it uses a custom binary protocol with XOR-based obfuscation to exchange data with the C2. These communications blend into normal application traffic. The module uses the GetCacheKey() hook to intercept standard HTTP requests. When a specific User-Agent is detected in the request headers, the module parses it, extracts the payload, and establishes a TCP connection to a target host inside the target’s network if needed.

Bidirectional TCP tunnel initialization

G.cs establishes a full-duplex proxy tunnel to support interactive control. It stores active target sockets in memory to pair concurrent HTTP read and write channels.

TCP connections from the C2 server to arbitrary hosts inside the target network are supported for pivoting and lateral movement. The traffic is proxied through the SharePoint host.

Target-to-attacker data channel

Attacker-to-target data channel

As can be seen in the screenshots, the attackers used the suo5 tool to implement traffic proxying. Its authors promote it as a stable forward-proxying tool for scenarios where outbound internet connections are prohibited.

To increase its performance, G.cs manipulates ThreadPool by raising its limits for concurrent operations and maximum timeout.

ThreadPool manipulation

“Prog.cs”: Execution entry point and task dispatcher

Prog.cs is the entry point that receives command-line arguments and passes them to uk/London.cs. The latter acts as the orchestrator, handling command parsing and privilege escalation (via named pipe impersonation). We’ll review it in more detail later. If the “suo5” command is provided, London.cs triggers G.cs to hook into the ASP.NET runtime as a memory shell. Once active, G.cs independently processes incoming web traffic inside the web server memory.

Host interaction modules

The following modules provide direct system interaction capabilities, each implemented as a separate unit. London.cs triggers these modules when it receives a corresponding command from Prog.cs.

“FileDownloader.cs”

The FileDownloader.cs module downloads arbitrary files from external URLs provided by the C2. It stores the downloaded files in the Program Data directory without any user interaction.

“LoggedOnUsers.cs”

This module enumerates logged-on users and identifies their session types (interactive, service, remote). The results are stored in memory. The attackers can retrieve them using the proxy and tunneling capabilities provided by G.cs.

“ProcessList.cs”

This module lists running processes with full paths to the corresponding executables on the disk. The results are stored in memory and the attackers can retrieve them via G.cs.

“NetworkInfo.cs”

This module extracts information about existing network connections, including protocols, local and remote IPs and ports, and connection state. It also enumerates network interfaces and headers. The results are stored in memory and can be retrieved by the attackers via G.cs.

“MSI.cs”

This module silently installs and executes MSI packages previously downloaded by FileDownloader.cs.

“User.cs”

This module creates administrative accounts using the native SAM RPC subsystem (SAMRPCNative namespace) rather than standard command-line tooling. This may indicate an attempt to evade detection and provide the attackers with privileged stealthy access to target systems that persists after the webshell has finished its work.

SAMRPCNative

The SAMRPCNative namespace implements a low-level C# P/Invoke wrapper for the native Windows samlib.dll library, comprising three types: SAMStructs.cs, SAMMethods.cs, and SAMEnums.cs.

“SAMEnums.cs”

Implements structured bitwise lists and constant flags mapping numeric codes to their security meaning in SAM, and translates system status return codes.

“SAMStructs.cs”

Defines native data structures required for P/Invoke memory alignment and for marshalling. It securely formats and aligns data structures.

“SAMMethods.cs”

Contains external API declarations (P/Invoke) imported from samlib.dll to perform actions such as connecting to the SAM server, creating users and opening domains.

This layer is crucial for the attackers because it enables account operations.

Privilege escalation

The uk namespace contains offensive primitives for privilege escalation. To elevate privileges to SYSTEM, it uses a local token impersonation technique via the Encrypting File System Remote Protocol (EFSRPC) interface adopted from the EfsPotato tool.

This functionality is implemented in the uk/London class. It creates a malicious named pipe while the EfsrTiny class (a tiny version of the EfsPotato tool) connects to the LSASS.exe RPC server. Then it’s London.RpcThread function calls the EfsRpcEncryptFileSrv function from EfsrTiny with a crafted \\localhost path. This tricks LSASS.exe into connecting back to the attacker’s named pipe. Finally, the London.Exp function uses ImpersonateNamedPipeClient to coerce and impersonate the LSASS.exe token and spawn a new process via CreateProcessAsUser with SYSTEM privileges. As the webshell resides in the IIS worker process, it has the necessary SeImpersonatePrivilege to perform this technique.

The uk namespace also implements a minimal MSRPC client layer by explicitly defining structures such as RPC_CLIENT_INTERFACE and MIDL_STUB_DESC, thereby spoofing an interface stub. This enables direct interaction with the Windows RPC runtime (Rpcrt4.dll) without relying on MIDL-generated stubs or higher-level RPC abstractions. This provides direct control over binding and marshaling that goes beyond the constraints of standard client APIs.

Post-exploitation activity

Shortly after the webshell injection, the infected worker process spawned msiexec.exe to install a remote MSI payload hosted in Supabase cloud storage. The payload was Velociraptor, an open-source digital forensics and incident response tool – namely version 0.73.4.0 vulnerable to CVE-2025-6264 – that the attackers abused for command execution on the target network.

In October 2025, Cisco Talos reported Velociraptor being leveraged by threat actors as a post-compromise execution framework and attributed this activity to Storm-2603. This tool enables arbitrary command execution, and can be used for various purposes. In our case, it was used for persistence, discovery, data collection and payload execution.

The threat actor used Velociraptor to deploy multiple independent tunneling mechanisms, including Zoho Assist-Unattended Support for unauthorized remote access, VS Code CLI tunneling, Cloudflare Tunnel, and a lightweight reverse proxy utility. By doing so, they attempted to maintain access even if some of their tools were detected and deleted. At this stage, they also no longer depended on the IIS worker process lifecycle and ToolShell vulnerability.

EDR-killing attempts

Once the threat actor had access to the target system, they were able to upload a vulnerable driver that is used by many attackers to terminate EDR solutions. We were able to detect the main driver at C:\programdata\rsndispot.sys (054a32d6033b1744dca7f49b2e466ea2). In addition, the adversary used a malicious DLL (2d9ebf9c042f596f435865b40edad928) in a sideloading attack. This DLL was identified as Warlock ransomware’s AV killer. It was possibly intended to kill security solutions using the vulnerable rsndispot.sys driver.

Ransomware deployment attempt

The attackers made attempts to launch ransomware on the compromised system. However, the Proactive Defense Module in Kaspersky Endpoint Security blocked the ransomware process, effectively preventing this activity. The malware DLL we obtained was identified as Warlock ransomware.

What defenders really need to look for

ToolPane deserialization and CLR artifacts

When the attackers tried to access ToolPane, both the dynamically compiled App_Web_toolpane.aspx assembly and the Microsoft.GeneratedCode helper assembly were present within the same application domain.

Both assemblies are used in legitimate scenarios. App_Web_* assemblies are generated during normal ASP.NET page compilation, while Microsoft.GeneratedCode is typically produced by the XmlSerializer during legitimate serialization workflows. However, a request to the ToolPane endpoint that results in immediate loading of Microsoft.GeneratedCode within the same execution window indicates that the runtime is processing serialized data supplied through the request.

Detecting deserialization exploitation

First, it is highly recommended to read this article (in Russian) on how deserialization exploit attempts in the CLR should be detected, with examples of YARA rules and monitoring recommendations. A summary of the main idea of the detection logic is provided below.

Deserialization vulnerabilities should be treated as a distinct class of exploitation events. In the CLR, deserialization is not merely the conversion of bytes into values – it is the reconstruction of an object graph from an incoming stream. Serialization and deserialization are performed by formatters. One of the most widely used formatters is BinaryFormatter. It uses the NRBF format, which defines the stream as a sequence of records describing classes, arrays, primitives, and references between objects. The shape of the resulting graph is determined by the data supplied to the deserializer. This means that the input stream defines not only the values but also the specific types, relationships, and lifecycle points that the runtime must materialize.

Microsoft states explicitly that BinaryFormatter is unsafe and cannot be made safe; beginning with .NET 9, the in-box implementation is effectively removed from ordinary use. However, Microsoft continues to use it in its products, including SharePoint, because it is powerful and easy to use. To fix BinaryFormatter-related issues, architectural changes are needed. Similar warnings also apply to related unsafe mechanisms, including LosFormatter (used in the vulnerable page).

The primary risk of unsafe deserialization is that the CLR may resolve unexpected types, instantiate objects outside normal constructor invariants, and invoke special lifecycle mechanisms such as ISerializable, IObjectReference, IDeserializationCallback, and methods marked [OnDeserialized]. In other words, the attacker-controlled data can force the runtime to construct a graph containing types with executable side effects.

A practical detection strategy should therefore focus on graph-construction artifacts. CLR loader events identify the relevant assemblies and application domains. Memory and metadata inspection then reveal the type names and generated serializer structures associated with the suspected gadget chain. In ToolShell-like scenarios, unsafe deserialization usually produces helper assemblies (evidence in loader events) with metadata containing fully qualified type names, gadget class names, and string representations of the constructed generic types (just scan via YARA for it). In our case, the artifacts to look for include Microsoft.GeneratedCode, App_Web_toolpane.aspx* (evidence of deserialization in loader events) as well as strings identifying ObjectDataProvider, ExpandedWrapper, and LosFormatter (evidence that the input stream was deserialized into dangerous objects). Note that these indicators are not significant in isolation; their value lies in the fact that they show the runtime has already received data requiring helper code generation to reconstruct a dangerous object graph.

Gadget objects that exploit vulnerabilities like those associated with ToolShell are conveniently represented in corpus-style tooling such as ysoserial.net/YSoNet, which aggregate known gadget chains for unsafe .NET deserialization. For defensive purposes, the value of these projects lies not in their offensive capability but in the catalog of types and structures that can be searched for in streams, memory, and helper assemblies. The presence of any of them in memory or in a helper assembly should be treated as a strong indicator of exploitation.

To simplify deserialization exploit detection, we created a tool named CLRDeserializationExploitFinder. It can detect ToolShell exploitation attempts, as well as other gadget chains covered by ysoserial.net.

Detecting a VPP-based webshell/runtime implant

A mechanism based on VirtualPathProvider should be treated as a separate class of runtime implant (no files involved). In ASP.NET, HostingEnvironment.RegisterVirtualPathProvider registers a new virtual-path provider (VPP) in the application’s compilation system. Once registered, the application can serve virtual paths during dynamic compilation as though they were ordinary on-disk pages. Dynamic compilation does not require the payload to exist as a file in the filesystem. It operates entirely within the trust boundary of the application itself. During the compilation process, temporary files may be generated, but they cannot be treated as reliable forensic artifacts. Because VPPs can also be used for legitimate purposes, the defensive model should begin with an inventory of the legitimate VirtualPathProvider implementations. In all other cases, the registration or use of a new VPP should be considered anomalous.

To see how the dynamic generation of virtual pages using ASP.NET, IIS, and the CLR works, and to learn how to detect such activity, use our project VirtualPathProvider Lab.

The most useful telemetry source for this technique is the Microsoft-Windows-IIS-Configuration ETW provider. To detect virtual paths, events 25 and 47 are of primary value. Event 25 records the mapping of ConfigPath to PhysicalPath, and event 47 records the mapping of the configuration path to a directory. In the case of a VPP-backed path, these events create an inconsistency: IIS and ASP.NET behave as if the path has a physical representation, while the corresponding file does not exist on disk. In the example provided by VirtualPathProvider Lab, this appears as a mapping of the virtual resource googlecheck.aspx to a physical path where no real file is present. This discrepancy between configuration resolution and filesystem reality is the primary indicator of virtual content.

The second indicator is more negative than positive. For disk-backed files, IIS normally creates a FileChangeNotificationMonitor chain, as reflected in events 17, 18, 19, and 21. For virtual paths served by a custom VirtualPathProvider, this chain is absent or does not match the normal profile of an ordinary file because there is no physical object or corresponding on-disk change lifecycle. Consequently, the presence of positive events 25 and 47 combined with the absence of the expected events 17, 18, 19, and 21 for the same path forms a reliable detection pattern: the path exists for IIS as a configuration-resolved resource, yet it is not backed by the filesystem and is not accompanied by normal file-change monitoring.

To sum up, the hunting target here is the discrepancy between how IIS/ASP.NET resolves a resource and what is actually present on the disk and in the change-monitoring chain. For known applications, such cases can be filtered through an allowlist of legitimate VirtualPathProvider implementations. Anything else should be treated as a potential runtime implant and examined using ETW, filesystem verification, and memory inspection of the w3wp.exe process.

Attribution

Microsoft tracks Storm-2603 as a standalone threat actor with no known links to other groups. While they are careful about assessing the actor’s motivation, they mention that it has previously deployed Warlock and LockBit ransomware following active exploitation of on-premises SharePoint vulnerabilities. In the analyzed incident, we observed similar SharePoint exploitation activities, as well as an EDR killer associated with Warlock ransomware and unsuccessful Warlock launch attempts.

Other documented intrusions have identified Storm-2603 as leveraging known flaws within perimeter mail gateways to achieve initial access, subsequently staging the Velociraptor framework with elevated privileges and establishing persistent encrypted tunnels via commercial remote management software to orchestrate secondary lateral movement. This aligns with the post-exploitation behavior we observed in our case. Together with the ToolShell exploitation scenario, this allows us to attribute this case to Storm-2603 with moderate confidence.

Conclusion

From the incident analyzed in this article, the main defensive lesson is that exploiting an internet-facing SharePoint server can enable fileless code execution directly inside the application trust boundary. Storm-2603 did not require a conventional dropper, persistent service, or exposed C2 endpoint; instead, it deployed a webshell inside w3wp.exe, from which tunneling, privilege escalation, credential access, and lateral movement could be orchestrated. Detection therefore needs to move beyond file-based webshell hunting toward runtime behavior, such as anomalous w3wp.exe activity, unexpected outbound connections, RPC coercion, token impersonation, and the introduction of remote-management or DFIR tooling after application compromise.

To correctly attribute malicious activity and develop appropriate response measures, defenders should reconstruct execution chains and temporal relationships across application, host, and identity layers. They should also preserve memory and IIS telemetry, and correlate low-signal reconnaissance with subsequent privileged activity rather than evaluating events in isolation. A confirmed SharePoint exploit with code execution should trigger host-level containment, persistence hunting, credential and exposed MachineKey rotation, and TTP-driven investigation rather than remediation limited to the initial exploit or known IOCs.

Kaspersky products detect the threats mentioned in this article as:

• Trojan.MSIL.Agent.gen
• Trojan.Win64.DLLhijack.cdp

Indicator of compromise

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

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

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

Device inventory in Kaspersky Industrial CyberSecurity for Networks

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

Hardware and software information in the device card

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

Installed modules and their placement in a PLC rack

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

Devices of unknown category

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

What data does MLEP analyze?

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

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

From observations to MLEP results

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

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

Event identification

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

Event history

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

Statistics processing in MLEP

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

Key components of the NSN

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

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

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

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

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

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

There are several types of monitors:

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

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

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

   Groups of devices with similar network behavior

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

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

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

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

Event processing flow (click to play)

MLEP in practice: how behavior helps complete the asset inventory

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

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

Device category suggested by MLEP

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

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

Anomalous activity and streaming statistics

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

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

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

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

Atypical Activity Time anomaly card

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

Conclusion

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

The extension performed host reconnaissance and attempted to create a reverse SSH tunnel.

The post Malicious Claude Code Extension Served in Cursor Supply Chain Attack appeared first on SecurityWeek.

Today, in most countries around the world, virtually every reasonably large city is packed with video cameras. On the one hand, the idea, of course, is to “keep us safe”: to monitor security in the streets, improve road safety and enforce traffic rules, and so on. But there’s the other side of the coin — ubiquitous video surveillance creates both privacy risks and opportunities for unauthorized surveillance We’ve repeatedly posted on our blog about how to protect yourself from surveillance involving IP cameras.

There’s another problem, too: relying too heavily on video surveillance systems can also be dangerous. If your cameras aren’t adequately cyber-secure, attackers may be able to disable them remotely to be able to then enter physical areas supposedly protected by video surveillance without being detected. This issue is especially relevant to home and privately managed surveillance systems — large companies generally do a better job of securing their devices (although there are exceptions there as well).

Disabling or replacing a camera feed is an almost obligatory plot device in heist movies. But unfortunately, this isn’t just a screenwriter’s invention: our recent research uncovered a vulnerability that makes it possible to remotely disable IP cameras made by Intelbras — a popular camera manufacturer. Read on to learn what the problem is, and how to protect your surveillance systems; a detailed technical analysis of the vulnerability is available on our expert blog, Securelist.

When an update does more harm than good

A surveillance camera is essentially a fully-fledged mini-computer, and its firmware needs to be updated regularly. In this case, however, the vulnerability was hidden in the firmware update procedure itself.

Intelbras provides firmware update files on its official website. The firmware can be updated manually from an SD card, or over the local network via the web interface or mobile app. However, during a firmware update, the camera neither required (past tense; a patch has since been issued – see below) authentication nor validated the firmware file before starting the update. As a result, anyone connected to the same Wi-Fi network as the camera could send it an update request. When an update is initiated, the camera reboots, taking it offline for about a minute before it becomes available again. But if the requests are sent repeatedly in a loop, the camera can be kept offline indefinitely.

We investigated this vulnerability on an Intelbras iM3 C (iM3B-C) camera running firmware version v240927 — the latest available at the time of our research. The iM3 C is a smart Full-HD Wi-Fi camera designed for both home surveillance and as a baby monitor. According to Intelbras, the firmware for the iM3 C is also compatible with the iMX C, iM4 C, iM5 SC, iME 360 C, and iM7+ FC models.

Intelbras iM3 C smart Wi-Fi camera used for the investigation. Its firmware is also compatible with the iMX C, iM4 C, iM5 SC, iME 360 C, and iM7+ FC models. Source

This vulnerability has a medium severity rating. However, because of the large number of potentially affected users, the impact of successful exploitation could be significant. Intelbras Mibo Smart — Intelbras’s app for setting up and managing these camera models — has been downloaded more than four million times, with most of its users based in Brazil and elsewhere in Latin America.

We notified Intelbras about the vulnerability, and the company promptly fixed it in a new firmware release — R.260804 (installation instructions for the update are available here).

How to secure your cameras and other smart devices

First and foremost, all Intelbras owners should update their camera firmware as soon as possible — and continue to do so regularly. More generally, it’s a good idea to secure your smart-home infrastructure in advance to reduce the risk posed by other potential vulnerabilities.

• One of the simplest yet most important steps is to change the default settings on both your smart devices and your home network. Be sure to replace the factory-default passwords on all smart devices and on your router — default username/password combinations such as admin/admin or root/admin provide no meaningful protection.
• Protect your home Wi-Fi with a strong password; otherwise, attackers could easily gain access to your local network.
• Disable WPS on your router. WPS is designed to simplify network setup and authentication: you can connect by pressing dedicated buttons on the router and respective device, or by entering an eight-digit PIN. The problem is that this PIN can be brute-forced relatively easily, allowing an attacker to recover the key to your Wi-Fi network fairly quickly.
• Use a strong, unique password for every account that can be used to manage your smart devices through official apps or websites. Where possible, enable two-factor authentication (2FA); the most secure option is generally to use one-time codes generated by authenticator apps. For generating and storing passwords, as well as creating one-time codes, it’s most convenient to use a password manager.
• Put your IP cameras and other smart devices on a separate Wi-Fi network — isolating them from phones, laptops, tablets, NAS devices, and so on. Most modern routers can create at least two Wi-Fi networks (a primary and a guest network). Use the guest network for smart-home devices, but make sure it’s protected with a strong password. If your router supports multiple Wi-Fi networks, consider putting the cameras on a dedicated network of their own. That way, even if the cameras are compromised, attackers won’t be able to reach your other devices.
• Use Smart Home Monitor, available in Kaspersky Plus and Kaspersky Premium. This feature shows all devices connected to your home network, lets you check their security status, and alerts you if an unknown device joins your home Wi-Fi.

More camera-security and smart-device tips and stories:

• Five rules to stop IP cameras from spying on you
• Webcam hacking, Korean-style: 120,000 IP cameras compromised
• Camera surveillance: myth or reality
• Network camera security: bad, worse, and terrible
• How to secure your smart home

Certificates both protect TLS connections and digitally sign applications, and forged ones turn up in real-world attacks from time to time. We’ve seen forged or stolen certificates abused by the DarkHotel APT and the Flame malware, and in 2011 we saw attack attempts after the certificate authority Comodo was compromised. Pulling off this trick usually takes serious expertise. But attacking eMudhra certificates in 2026 doesn’t take much effort at all. An attacker just has to guess a number from 1 to 255. Private keys for intermediate certificate authorities are normally gigantic numbers. But in this case, eight of them were the following: 4, 56, 66, 115, 155, 156, 230, and 237. They could be guessed using the public keys (available in public certificates) in under a second. As a result, a hypothetical attacker could issue certificates for anything by signing them with one of the compromised private keys.

Six of these keys were meant for issuing TLS certificates, and the other two were for code signing. All eight intermediate certificate authorities (CAs) were also cross-signed by the Sectigo CA. This means clients with different trust chains could trust a forged certificate.

The major browsers have already blocked the dangerous certificate chains. But IT and security teams still need to assess and remediate the risk in many other systems across their organizations. Scripts for scheduled data-processing, corporate NGFWs, monitoring servers, applications with built-in certificate stores, and devices that don’t get regular updates may accept forged certificates and be vulnerable to man-in-the-middle (MitM) attacks. The keys needed for this are already built into publicly available interception tools.

Timeline of the eMudhra certificate authority incident

The problematic keys came from a batch of 24 intermediate CAs that eMudhra created on April 30, 2025. Instead of cryptographically random values for a 384-bit elliptic curve, eight of the keys turned out to be small numbers. According to eMudhra’s own description, a “key wrap/unwrap step” during key generation created a second, weak set of keys. Because keys are created and stored in a dedicated device called a hardware security module (HSM), a weak key is hard to notice on its own. It’s still unclear what error caused the keys to be generated twice and the weak set to be used; the investigation is ongoing.

In May 2025, the Sectigo CA signed all eight intermediate certificates. Then, on October 17, 2026, an independent researcher notified the security teams at Mozilla, Google, and Apple, as well as the CA itself, that the keys were recoverable. On October 20, Mozilla publicly disclosed the incident. This means that for almost a year and a half the keys could have been recovered and certificates forged.

On October 22, eMudhra announced that it was exiting the global SSL/TLS certificate business.

What an attacker can do

Using the vulnerable intermediate CAs, an attacker can sign a forged certificate for someone else’s domain. Clients that still trust that chain and have no other safeguards will take the forgery for the real server.

A certificate alone isn’t enough to intercept HTTPS traffic. The attacker also needs a way to tamper with the victim’s traffic or redirect the connection. That’s possible, for example, in a compromised office network, on a Wi-Fi access point the attacker controls, or by interfering with routing and DNS. And all of this does happen in the wild, as the DarkHotel attacks, among others, have shown.

There’s one more danger: two of the keys can be used for code signing. In theory, that would let an attacker deliver malware that appears to come from a trusted vendor and doesn’t trigger scary OS warnings during installation.

Was it exploited?

Experts from various companies who analyzed the after-effects of the incident haven’t found any malicious attacks that used these certificates. eMudhra and CERT-In have also reported finding no abuse. The Chrome team found no certificates from the six CAs in public Certificate Transparency logs.

This means that systems where browsers check certificates through Certificate Transparency (CT) were most likely not attacked. But many devices and applications — especially servers and IoT devices, don’t check CT at all, so we can’t say anything about them. Today, malicious actors no longer need to write their own hacking tools to pull off an attack like this. Version 12.3 of mitmproxy — a popular tool among security researchers — already has built-in support for compromised keys.

Where the risk has been eliminated, and where that isn’t guaranteed

Major platforms quickly revoked the compromised certificates. As early as October 17, Chrome did so through CRLSets, and Firefox — through OneCRL. On October 18, eMudhra itself revoked the certificates, citing “CA Compromise”. Apple took action on October 19, and the Sectigo CA also revoked the cross-signed copies. Microsoft revoked the certificates on October 20. Depending on the settings of a specific application and OS, revocation may have taken effect even without an application update, since blocklists are often updated separately.

At the same time, a more radical measure is under way: withdrawing trust from the root CA. Chrome has announced the planned removal of “emSign ECC Root CA – G3” from the browser. Certificates issued under the “emSign Root CA – G1” root, and the root itself, aren’t affected. According to eMudhra’s estimate, about 30 000 certificates will need to be migrated.

But certificate revocation only works where the client can find out about the revocation to then be able to actually act upon it. Many applications check the signature, server name, and certificate validity period, but don’t retrieve or update blocklists. Here are the typical cases:

Outdated and LTS systems. LTS (long-term support) status alone doesn’t mean a system is vulnerable. By definition, a system with this status receives support. But old containers, frozen OS images, and systems that are no longer updated can keep trusting revoked CAs for a long time. It all depends on updates to ca-certificates and TLS libraries, and the settings of the specific application.

Automated systems and servers. On emudhra.we-have-a-problem.com — a site created by enthusiasts where you can check any client software for misplaced trust — curl and Zabbix dominate the list of the most vulnerable systems. For HTTP checks, Zabbix usually uses libcurl and the certificate store configured for it. Similar behavior is also documented in the built-in curl in macOS. At the OS level and in Safari, the certificate is revoked, but curl reads a plain /etc/ssl/cert.pem file, and that’s precisely where the fix has to be made. This is a good example: even when system-level trust and revocation mechanisms work, individual applications — including ones that ship with the OS by default — can remain vulnerable.

Python, Ruby, Go, Java, and containers. An application may use its own set of root CAs, which isn’t updated along with the OS. Endor Labs found more than 25 popular packages that contain the affected root.

Slack, GitHub Desktop, and other apps built on the Electron framework. These apps ship with their own Electron/Chromium, so updating a separately installed Chrome doesn’t update Slack. The certificate revocations are already in the new Electron version, but now every developer has to rebuild and distribute their app, and every user has to install the update. That said, not every Electron app is necessarily vulnerable. The outcome depends on the version, how the app updates its blocklists, and which network stack it uses.

Mobile browsers and IoT devices. Mobile Chrome, Firefox, and Safari get certificate revocation data as quickly as their desktop counterparts do. With the stock browsers from smartphone makers, this isn’t the case. In a published test, Samsung Browser 31.0.0.64 accepted all six test chains from emSign while rejecting the ones from Sectigo. For HarmonyOS 6 and 7, researchers found the affected CAs in Huawei’s published list of root CAs, and those CAs can’t be revoked manually.

For unsupported devices, home appliances, and old firmware, a certificate store update may never be released. In those cases, the problem could linger for years.

Impact on TLS inspection in a corporate network

When an NGFW or web gateway inspects encrypted traffic, it maintains two connections: one with the client and the other with the external server. The client receives a certificate signed by the corporate CA, while the gateway itself verifies the authenticity of the external server.

If the gateway accepts a forged eMudhra certificate, even an updated browser on an employee’s computer won’t see the dangerous chain. Instead, it will receive the familiar corporate certificate. In this scenario, the security tool itself hides the problem from the client. That said, carrying out such an attack would also require intercepting traffic.

To fix the validation policy and certificate lists on the inspection device itself, follow the vendor’s instructions — if the vendor has published any, that is.

At Cisco, the status of the issue is documented in detail for all products. Most of them are still listed as “under investigation”, but mitigation measures are recommended for vulnerable devices.

Sophos and Check Point promise device software updates and, in the meantime, advise removing the certificates manually. Neither company has published a security advisory, but employees of each posted recommendations on its support forum.

For Fortinet devices, instructions for checking and removing emSign certificates can be found here. Palo Alto offered only general advice instead of specifics for its own products.

Of course, a properly configured gateway can indeed temporarily protect outdated client devices that trust the dangerous certificates.

To check specific devices, services, containers, and virtual machines, you can use a dedicated website. One possible scenario for proactively hunting for threats that exploit or have previously exploited weak keys is described here.

CISA added the Brotli flaw to its KEV catalog, and two honeypot operators logged attempts, including one that used a broken exploit.

The post CISA Warns of Node2Shell Exploitation as Honeypots Log Attack Attempts appeared first on SecurityWeek.

By Jeremy Hehl

Agents can triage, enrich and correlate at machine speed. But someone still has to own the risk call. On Episode 18 of EC-Council’s The Cybersecurity Podcast, Foresite Cybersecurity’s Jeremy Hehl tells host Jay Bavisi why the fully autonomous SOC is further off than vendors suggest, and why governance is the next real frontier.

Every security operations center now claims to be “AI-powered.” For MSSPs, saying anything else risks being labeled old school. So what does an agentic AI SOC actually look like in production?

Jay Bavisi, founder of EC-Council and host of The Cybersecurity Podcast, put that question to Jeremy Hehl, Chief Cybersecurity Evangelist at Foresite Cybersecurity, where he leads the company’s Google SecOps partnership. Their 40-minute conversation covered the limits of autonomy, the future of the SIEM, the fate of L1 analysts, ISO 42001, and the post-quantum risk that keeps Hehl awake at night.

Agents compute, humans decide

Hehl sees real promise in autonomous security operations. Investigation, triage, data aggregation, enrichment and correlation can already be handled by agents “pretty seamlessly,” he said. The hurdle is risk determination: deciding whether something actually matters to the business.

“The question I always ask customers who come to us and say that they want a fully autonomous SOC is: who do we fire when something goes wrong? Do we just dismiss the agent?”

Foresite’s approach treats agents as force multipliers rather than replacements. Hehl compared it to handing analysts a tricorder, a tool that scans and characterizes a threat instantly so the human can decide what to do. Bavisi summed up the model as “agents compute, human decides,” and Hehl agreed, adding that the risk call is the deciding factor.

Is the SIEM on borrowed time?

Asked why Foresite’s Google work matters when most premier SIEMs already ship with AI built in, Hehl pointed to a coming paradigm shift in where data lives. Data sovereignty, regulated industries and ever-growing telemetry volumes are straining the traditional model.

Today, a SIEM aggregates logs into a central plane, normalizes them into fields, and runs detection logic over the result. Hehl expects that to change. Logs will increasingly stay where they reside, in a hyperscaler such as Google, Azure or AWS, and agents will synthesize the raw telemetry in place.

“The idea of a SIEM may become something that is deprecated pretty rapidly.”

He likened the economics to cell phones in the 1990s, when minutes and text messages became commoditized. Data storage will become an assumption, and providers will bill for agent activity and “token burn” instead. Keeping telemetry in BigQuery, he noted, is far cheaper than keeping it hot in a separate SIEM. “The technology has to support it, and we’re not quite there yet,” he added.

The platform is also open by design. Foresite builds primarily on Google’s Vertex AI and Gemini, but Hehl said almost any model, including Claude, can be wired in through APIs and credentials. Agents are, in effect, privileged users, though wiring in other models takes real engineering, parsing and upkeep.

Is the SIEM on borrowed time?

Bavisi raised a trend seen worldwide: L1 roles vanishing, then L2, leaving only L3. Is that simply where agentic technology is heading?

Hehl said Foresite’s experience runs the other way. “We haven’t eliminated jobs. We’ve only grown,” he said. Adding agents to triage, threat hunting and analysis has let analysts handle 10 to 15 times the workload. They dismiss false positives quickly and spend the time saved on learning and more meaningful work.

He invoked the Industrial Revolution in England and France, when coal-powered textile machinery drew a Luddite backlash and even riots. Over time, workers using the machines became far more productive, and business owners demanded more output. This is the pattern known as Jevons Paradox, and Hehl sees agentic AI in the SOC following the same path.

Having started his own career red-teaming banks and working in a SOC, Hehl knows the burnout of triaging the same alert queue “over and over and over again.” Agents that correlate alerts into single cases, surface heuristic patterns and flag statistical outliers do that work “really, really well,” he said. The drudgery goes away; the analyst does not.

The few vendors promising fully autonomous SOC operations, he added, are narrow and tightly focused. Agents that reach a decision and enforce an action must be rigorously tested and simulated, and without clean data they hallucinate. Removing human control over security posture “is pretty unlikely in the next decade or so.”

Taming a non-deterministic technology

Bavisi pressed on a core engineering problem. Ask a frontier model the same question five times and you may get five different answers. How do you build a SOC on that without hallucinations and with consistent results?

Hehl’s answer: a measured, staged deployment. Start with narrow, targeted use cases where machines clearly beat humans, such as data manipulation, API access, running queries and writing code. Then build up capability and maturity step by step.

In enterprise engagements, Foresite first gets data normalization to “basically four nines.” Only then do agents go into the automation playbooks. Hehl argued that calling an agent today is not much different from calling a cloud function that once sat as Python inside a SOAR playbook.

“If you set up markdowns and guidelines and files and restrict the identity of the agent to only do very prescriptive things, as opposed to being all-encompassing, those are the outcomes that customers are looking for.”

He also described three types of MSSP customer. Some just want their brand and stakeholders protected. Some want an extension of their blue team bench. Others come to learn the “massive wall of knobs and levers” in Google’s security portfolio. Mid-market and SMB clients mostly treat agentic capability as part of the service. Enterprises usually already run agents elsewhere in the business and need a careful path to using them for security.

Governance: the next frontier for MSSPs

The industry has swung from “fire all humans and buy all the tokens” to “fire all the tokens and hire all the humans,” Bavisi observed, and is now wobbling in the middle. Where does AI governance fit for customers?

Hehl called it “the next real frontier” for managed security providers, with ISO/IEC 42001 emerging as the benchmark in the US. As public sector bodies adopt hyperscale platforms with agentic capabilities built in, they will need observability into what fleets of agents with permissive access are doing and saying to each other. That raises hard questions: where the harness sits, what protocols apply, and how to read intent from prompts and agent behavior.

“There’s a difference between an agent that sits there and does a prescriptive task … and when we start allowing agents to quantify risk and call other tools.”

He cited Wiz, which maps every model and agent in an environment and the lines of communication between them, and partner Safe AI for observability of agent activity. The CISO’s real dilemma, he said, is simple: “I’m being told I have to deploy AI. I am deploying AI. How do I secure this?”

The forgotten middle

Bavisi divided the world into three tiers. The top 5%, such as Google, Salesforce and Microsoft, have ISO 42001, red teams and consultants. At the other end are organizations that think two ChatGPT subscriptions make them an AI company. The vast majority sit in the middle. They know AI is more than chatbots but don’t know how to adopt, defend or govern it, and they cannot afford tier-one observability tools that may cost a million dollars.

How, he asked, should a business in Hokkaido, Jordan or New Zealand handle intent drift, blast radius, agent-to-agent communication and the transfer of governance between agents?

Hehl noted a related trap. Niche AI startups often build a narrow agentic product, only for the next frontier model or hyperscaler update to build that feature in and make the company irrelevant. For the mid-market, he argued, the answer is partnership: managed providers that deliver governance and observability as part of the service, “a Sherpa through the valley.”

Having ISO 42001 vs. living it

Bavisi pointed out that ISO 42001 has more than 190 controls, and as with ISO 27001, holding the certificate and operating by it are two different things. Do organizations show compliance for regulators while running with serious gaps?

“All the time,” Hehl said. Agentic adoption remains limited in US classified environments (IL-4 to IL-6) and in multinational bodies such as the European Space Agency, a Foresite client. In the commercial world, the most governed vertical with the largest gap is healthcare and life sciences, which holds sensitive patient data and research.

His prescription is to move telemetry into the cloud. Once workloads move from physical data centers into a hyperscaler, “the policies are native by default. And when agents are deployed, they’re governed by default.” The next big push, he said, is identity and privileged access management for agents, treating them as users. Bavisi added temporal context as another layer to solve.

Consolidation, and a $250,000 query

Bavisi argued the industry has a duty to bring along the businesses “where the actual civilization exists.” How? Hehl’s one-word answer: consolidation.

By around 2035, he expects hyperscalers such as Google, Microsoft and AWS, along with CrowdStrike, Palo Alto Networks, Cisco and to some extent Oracle, to keep absorbing companies and technologies. That will make enterprise-grade tooling usable by businesses of every size from one platform. Startups will keep flourishing, and Israeli startups will stay disruptive, but Hehl predicts acquisition values will fall as vibe coding lets almost anyone build a product. He also sees Chinese and Indian AI models closing the gap with American ones, with major implications for global security over the next 20 years.

On Anthropic’s Mythos, Hehl was blunt: it is “the greatest sales tool ever created.” It has stirred fears of boogeyman vulnerabilities, but he said it is genuinely capable of discovering zero-days and attack paths that need fixing. That in turn creates business for defensive tools such as Google’s CodeMender. None of it changes the basic discipline: find attack paths, shore them up, test, repeat. “We’re never really more than 99% of the way there.”

The other barrier for the middle market is cost predictability. Token-based pricing is not yet predictable. Hehl admitted Foresite once ran an accidental $250,000 query on Gemini during iterative testing and had to ask Google for forgiveness. Predictable pricing, he said, is what will let more customers lean in.

What really blocks the move to AI-era security

Asked about the biggest obstacle to moving an organization from traditional security to an AI-era culture, Hehl named three:

• Financial opacity. Customers lack transparency on what AI will actually cost.
• Unclear goals. Organizations often lack a clear picture of what they want AI to achieve, which calls for education and enablement.
• Reluctance to hand over control. Teams that have built careers around a security posture over the past decade ask why they should introduce new pain when nothing hurts now.

Winning them over is part of the “trust motion,” he said, and some will never make the shift because of requirements that keep them where they are.

Machine-speed attacks and a post-quantum dam

What keeps Hehl up at night is machine-speed attacks, which he said “are absolutely accelerating,” and frontier models built explicitly to break software and create new attacks. Beyond that is the prospect of cryptography being cracked faster than it can be rotated.

Bavisi shared the concern. He sees cracks already forming in encryption and fears the day “the dam breaks, and we’re not ready for a PQC world.” Hehl pointed to the downstream effects on blockchain, financial systems and energy grids, and the limits of what any single defender can do.

“There’s nothing we could do as an MSSP or a security practitioner to reset global cryptography … to reset the keys that we hold dear in order for us to maintain those chains of custody, privacy, and command over those systems.”

The takeaway from the conversation, Bavisi said in closing, is that the agentic SOC “is not just in the labs. It’s already in production.” The open question is whether governance, cost models and the cryptographic foundations underneath can keep up.

Watch the full episode of The Cybersecurity Podcast by EC-Council, Episode 18, featuring Jeremy Hehl.

Jeremy Hehl, Chief Evangelist at Foresite Cybersecurity

Jeremy Hehl is Chief Evangelist at Foresite Cybersecurity, a Google Cloud Premier Partner and the 2026 Google Cloud Security Partner of the Year.

The post Who Do We Fire When the Agent Gets It Wrong? Inside the Agentic AI SOC appeared first on CISO MAG | Cyber Security Magazine.

Yesterday, two critical vulnerabilities were disclosed in PHP, the scripting language used by many websites and online services: CVE-2026-109618 and CVE-2026-109619. Attackers can exploit them to remotely execute commands on any server running PHP, with no authentication required. The exploit has been dubbed PHP2Shell.

The PHP security team announced an upcoming emergency update on October 20 and released patches fixing the vulnerabilities the following day.

We’ve already covered the technical details of these vulnerabilities and explained what companies and server administrators should do. You may have safely skipped that news because you don’t run any servers — but unfortunately, the issue is not limited to businesses.

Nearly 70% of websites run on PHP, including services we use every day: wikis, online stores, smart devices with web interfaces, home network-attached storage (NAS), smart-home controllers, and much more.

Today, we explain how these vulnerabilities could affect you personally and what you can do to reduce the risks.

How the vulnerabilities can affect home users

Account and personal-data theft

The vulnerability allows an attacker to steal authentication tokens from server memory. These tokens essentially act like electronic passes — telling a website that the user has already signed in. As a result, an attacker may be able to access someone else’s account without entering a password or two-factor authentication code, putting messages, documents, delivery addresses, order histories, and other confidential information at risk.

Loss of files on home devices

If you have network-attached storage (NAS) or a video surveillance system at home that uses a vulnerable PHP version, it may also be at risk. Depending on what level of access they gain, attackers could potentially copy, delete or encrypt files they can access.

Malware infection

If an attacker gains access to a vulnerable website, they can use it in virtually any way they want: trick visitors into downloading a malicious file or clicking on a phishing link, display dangerous instructions, replace payment forms or login pages with malicious ones — the list goes on and on. As a result, someone visiting a legitimate website could not only lose access to their account, but also lose money or accidentally infect their device with malware.

Below are examples of services directly affected by the vulnerabilities.

Which services are affected by the PHP vulnerabilities

Jeedom

Jeedom is a smart-home platform that lets users control lighting, sensors, heating, blinds and home IoT devices. Attackers could abuse this in many ways: they could disable the alarm, track when the homeowner is away, access video from the door intercom, and more.

The developers confirmed that the new vulnerability affects their application, and have already released an emergency update — Jeedom 4.6.2. Users need to run the update twice for it to work. The developers say a fully fixed version for home users will be released in the coming days.

Websites we use every day

As mentioned above, PHP is used by roughly 70% of websites. This doesn’t mean every one of them is vulnerable: it depends on the PHP version in use and whether the site owners have already updated it. Many government websites in Europe have already suspended operations because of the new vulnerability.

Unfortunately, a website may still be vulnerable even if it appears to be working normally. An attacker could potentially take control of any legitimate website whose server hasn’t been patched yet. They could fake payment or login pages, host malicious files, or persuade users to download an “urgent update” that is actually malware.

Ordinary users have no reliable way to check whether such instructions or files are safe, so be sure to use reliable anti-phishing and antivirus protection. If you suspect that your data may have been stolen, check the active sessions in your account settings. If you spot suspicious activity or devices you don’t recognize, sign out of all active sessions and change your password. Use a password manager — it can generate a truly strong, unique password that you won’t have to memorize yourself.

Computer games

Bad news for gamers: some video games whose servers use PHP are also at risk. If you don’t want attackers to get hold of your accounts, be sure to update the passwords for your gaming platforms, stores and accounts.

To buy time for updates, some developers temporarily took their services offline. Final Fantasy XIV, Pokemon Champions, games from Bandai Namco Entertainment, Uma Musume: Pretty Derby, Granblue Fantasy, Shadowverse: Worlds Beyond, and many others went into emergency maintenance. Nintendo Switch Online and the GOG and Steam stores were also affected.

Unfortunately, there’ve also been more drastic consequences. Yesterday, the developers of World Quest announced that the game would shut down permanently after 15 years: it relied on outdated infrastructure that would have been extremely difficult and costly to fix. For the same reason, the mobile game Please Save My Pandemonium! shut down after more than ten years of operation.

Home network-attached storage (NAS)

“Home clouds” have become popular in recent years for good reason: many users prefer to keep backups of their data at home rather than online. A number of companies make NAS devices, and at least three — QNAP, Synology and ASUSTOR — have said the vulnerabilities affect their products. An update has also been released for Unraid, an operating system for home servers, network storage and media servers.

QNAP

The manufacturer confirmed that the vulnerabilities affect several versions of its NAS operating systems — QTS and QuTS hero — as well as applications including QuMagie, Note Station 3 and certain versions of QVR Surveillance. A successful attack could put photos, documents, notes and camera recordings at risk.

At the time of publication of this blogpost, QNAP is still preparing updates, so the main priority is to temporarily disconnect NAS from the internet. QNAP recommends disabling port forwarding on the router — to prevent NAS from automatically opening ports — and allowing access to the management panel only from the home network or through a VPN.

Synology

Both vulnerabilities have been officially confirmed in PHP packages 7.3, 7.4, and 8.0–8.4, as well as in Mail Station and Synology Calendar. Fixes have already been released for PHP, starting from version 7.4, as well as for Mail Station and Synology Calendar. PHP 7.3 won’t be fixed. The company separately notes that the PHP component built into its operating system cannot be reached from outside the device, so the risk of attack is very low.

ASUSTOR

ASUSTOR also officially confirmed both vulnerabilities, and immediately removed PHP 7, 7.3, 7.4, and 8.1 packages from App Central. The company recommends immediately backing up your data, removing older PHP packages, and using PHP 8.3 or 8.4.

Unraid

In today’s operating-system update, PHP was upgraded to version 8.4.27 with fixes for the vulnerabilities. The developers recommend that all users update to Unraid 7.3.4. Containers with their own PHP installation must be updated separately: the new PHP version in the operating system doesn’t replace PHP inside containers.

At the time of publication, we haven’t found public confirmation from other major manufacturers (such as TerraMaster, UGREEN, Buffalo, or Western Digital) that their devices are affected by these vulnerabilities — only user discussions on forums.

But the fact that only some NAS manufacturers have confirmed the problem so far doesn’t guarantee that your devices are safe — especially if they’re fairly old or come from a lesser-known or defunct manufacturer. In that case, first disconnect the devices from the internet while keeping them accessible only on the local network, and then investigate whether they’re vulnerable.

Nextcloud cloud storage

Nextcloud is a free, open-source platform for creating your own cloud storage, serving as an alternative to Google Drive, Dropbox, and Microsoft OneDrive. It lets you store and synchronize files across devices, share them with other users, and work with documents, photos, calendars and contacts. The data can be stored on your own server or NAS rather than on a third-party company’s servers.

If you store important data in Nextcloud, check how your cloud instance is configured. If you use Nextcloud All-in-One, update to version 14.4.1 where the vulnerability has already been fixed.

If your Nextcloud installation is configured differently, you need to update PHP yourself on the device or server.

How to protect your devices and data

• Use phishing and malware protection. Our security solution automatically blocks phishing pages and malware, even when attackers place them on legitimate websites.
• Keep an eye on updates. If you have network-attached storage, a smart-home system, a home server, a media server, or any other device with a web interface, first check the manufacturer’s website and install all available updates. If no update is available yet, temporarily disable internet access to the device.
• Use strong passwords. Most people reuse the same password, or variations of it, across multiple websites. If an attacker finds one of those passwords on a vulnerable server, they may be able to compromise your other accounts as well. We recommend generating and storing strong, unique passwords in Kaspersky Password Manager so you don’t have to remember your credentials yourself. Be sure to enable two-factor authentication on all important accounts — ideally using one-time codes generated by the same password manager.
• Keep an offline backup of important files. Don’t rely on cloud storage alone — make sure you keep a backup of all important documents on both a hard drive and an external device. For more information on how to make backups properly, see our article The internet remembers not quite everything.

What other risks can your home devices face? Read our articles:

• Trojan TV, or the new risks of malicious proxies
• Ransomware now taking aim at personal backups
• Is your TV box renting out your network?
• Is your router secretly working for foreign intelligence?
• Three common attacks on Linux in homes
• How to secure your smart home

Detection engineering is both a role and an activity. It’s the discipline of building and maintaining the logic that identifies malicious or risky behavior within your organization. It’s where security analysis meets software engineering, turning raw logs and telemetry into actionable detections that defenders can rely on.

Detection engineers bridge the gaps between security operations, threat intelligence, and infrastructure. They understand how attackers operate, how defenders respond, and how systems generate the data that supports those detections. A well-built detection can mean the difference between an alert that matters and one that drowns in noise.

Precision and Recall: The Balancing Act

Every detection faces a trade-off between precision and recall.

Precision measures how much you can trust your alerts: of everything that fired, how much was actually malicious? High precision = fewer false positives = analysts trust the tool.

Recall measures how much you’re catching: of everything malicious that happened, how much did you detect? High recall = fewer blind spots = threats don’t slip through.

Detection engineering lives in the tension between the two: too much precision risks missing subtle threats; too much recall floods analysts with false positives. The goal is calibration through testing, iteration, and feedback.

Core Components of Detection Engineering

1. Scoping and Prioritization

Start with intent. What are you trying to detect, and why? Define the threats, behaviors, or assets that matter most, then align your work with frameworks such as MITRE ATT&CK®. Evaluate risk and value to determine which detections provide the highest impact for the effort required. Prioritize based on business importance and available telemetry.

2. Data and Telemetry

Great detections rely on great data. Keep inventory of your logs. Validate that each contains the data you need. Normalize and enrich your logs so detections remain consistent across tools and environments. Understanding how logs are generated is essential to writing logic that fits your environment.

3. Detection Logic Development

This is where hypothesis meets code. Write queries or rules that detect behaviors, not just static indicators. Combine multiple approaches:

• Signatures for known indicators of compromise (IoCs)
• Behavioral logic for Tactics, Techniques, and Procedures (TTPs) and patterns
• Anomaly models for statistical outliers

4. Testing and Validation

Use adversary emulations or frameworks like Atomic Red Team to verify that your detections actually fire and your logging is working. Measure quality through precision, recall, and additional factors like confidence (how certain you are it’s malicious) and criticality (how severe the impact would be).

5. Deployment and Tuning

Monitor performance, including trigger frequency, false positive rates, and analyst response time. Detection engineering is iterative and ongoing, not “write once and done.”

6. Documentation and Knowledge Transfer

Good detections come with context. Record what the detection looks for, why it matters, what data it uses, and how it was tested. Version control your rules using Git and promote collaboration so analysts, hunters, and engineers can learn from one another. Playbooks and detection libraries ensure institutional knowledge does not disappear when staff change roles.

7. Metrics and Continuous Improvement

Track measurable outcomes such as coverage across ATT&CK® techniques, number of validated detections, false positive rates, and mean time to detect. Regularly retire stale detections, update ones that drift, and automate validation wherever possible. Detection-as-Code practices keep everything maintainable and scalable.

Building the Skillset

Detection engineering requires a strong foundation in logging, security tooling, and incident response. You should understand when it’s best to detect, when to block, and how to use data sources effectively.

Whether you’re building your first rule or managing hundreds, the mindset remains the same: test everything, learn constantly, and make each detection better than the last.

Get Started

Explore resources like:

detectionengineering.net and SigmaHQ.

Follow community leaders like:

Zack Allen (Detection Engineering Weekly) and Haider Dost (Threat Detection Maturity Framework).

Study detections and see how others approach logic design at:

research.splunk.com

Read:

Practical Threat Detection Engineering.

For more resources check out:

https://bit.ly/notlogic

Eight compromised eMudhra intermediate CA private keys risk unauthorized TLS signing and MitM interception. Read our analysis and containment guide.

The post EMudhra Intermediate CA Certificates Compromised appeared first on Unit 42.

Anonymous imageboards have long been places where users could chat under pseudonyms without revealing their real names. But now people on these forums are discussing and testing AI tools for doxing — that is, for finding, matching, and publishing users’ data without their consent. Often this goes hand in hand with stalking the victim, hacking their accounts, bullying, and blackmail, and ultimately leads to a damaged reputation or even worse.

In this post, we explain how artificial intelligence helps malicious actors leak other people’s data — and how to stand up for your right to online privacy.

How bad actors uncover information about users

Analysts at Open Measures have reported that, since October 2025, users of Soyjak.party, an imageboard popular with young people on the far right, have been discussing and using AI to deanonymize other users. Their victims are often activists, bloggers, and members of other “hostile” forums.

The tools the experts found run right in the browser, and automate almost the entire process of collecting information about a victim. They can search open sources and leak databases, and they use any new leads — for example, an email address linked to a username — to dig even deeper. They also extract metadata from photos and videos, estimate a person’s approximate location from IP addresses they find, and finally put everything together into one huge digital dossier. These Soyjak.party tools are no longer functional, but similar ones have been spreading across other imageboards.

In February 2026, researchers demonstrated that sometimes ordinary forum chatter is enough to reveal who you are. They put together summaries of posts by 338 Hacker News users, removed names, usernames, and social media links, and then asked AI to work out who was behind them. The AI compared details about jobs, interests, and personal background with information available online — and correctly identified 226 of the people, or about two-thirds of the sample. The price of deanonymization turned out to be laughably low — at between US$1 and US$4 per user.

To be fair, people knew how to build digital dossiers even before the generative AI boom. For starters, there are OSINT tools that search for data in open sources. Journalists and investigators were the first to use them, but, as you might guess, malicious actors soon mastered these tools too. Unlike AI models and agents, traditional OSINT services follow set scripts and can’t “think” or make decisions on the fly.

An agent out for revenge: the OpenClaw case

If you think doxing always needs a person with ill intent, we’ve bad news: sometimes the one settling scores can be… artificial intelligence itself.

Here’s a story that started out innocuously enough. An AI agent running on the much-hyped OpenClaw platform suggested an improvement for Matplotlib, a popular tool for building graphs and charts. But the project’s rules said that code submitted by AI agents wasn’t accepted. One of the project’s volunteers, Scott Shambaugh, simply turned down the AI’s suggestion.

You’d think that would be the end of it. Think again! The AI agent decided the rejection deserved some publicity, so it published an “exposé” about the developer on its blog (yes, you read that right: the agent had its own blog). It gathered information about Shambaugh from open sources, studied his public activity, and accused him of being biased against AI. It even started speculating about the developer’s psychological motives, and suggested he was afraid of competition from artificial intelligence.

Once this “private” conversation between Shambaugh and the AI agent went public, other users rallied behind the developer — and the agent had to publish an “apology” post.

It’s a pretty absurd story, but it teaches a good lesson: always read the privacy policy of any AI service carefully, and steer clear of new models from unknown sources.

How to avoid becoming a doxing victim: a guide

If AI speeds up searches and connects the dots between details that used to be scattered across dozens of websites, the next logical question is: what can you do to shrink your digital footprint?

Disappearing from the internet completely is almost impossible. So protecting your data isn’t so much about leaving as few traces as possible, but cutting the number of links that can be used to piece together your identity. If you’re an advanced user, we recommend reading our post, How to disappear from the internet, in addition to the tips below.

Manage your digital footprint

• Search for yourself online. Don’t stop at your name: try your email address, nicknames, and phone number too. If you’re comfortable with AI processing your data, you can even ask it to compile a dossier on you. Just remember that there’s always a risk of a leak or a bug that accidentally makes your data public. And no, big, reputable services are no exception.
• Make private any profiles you don’t want to share with everyone. That makes it harder for search engines to index your new posts, and for scrapers and OSINT tools to collect them. While you’re at it, go through your old comments and posts and clear out anything you don’t need.
• Delete your ghost accounts. Go through your inboxes and check which websites you’ve signed up for. Make a habit of deleting accounts you no longer use: they can hold your personal data for years, and there’s always a risk it’ll end up in the next data leak.
• Set up two-factor authentication. That way, even if a bad actor manages to guess your password or finds it in a leak, they won’t be able to get into your account without the additional authentication. For the second factor, we recommend using one-time codes that refresh every 30 seconds and storing them in a reliable password manager.
• Strip metadata before posting photos and videos. Metadata can help a malicious person learn a lot about you— for example, the location and exact date a photo was taken, and the model of your device.
• Use a different password for every account you have. Our research has showed that passwords built from personal details — such as your mother’s maiden name, your birth date, and a special character at the end — are extremely weak. This kind of information often ends up in leaks, or can be pieced together from public sources, so the passwords can be easily brute-forced by smart algorithms. Of course, nobody can remember hundreds of unique passwords, so it makes sense to offload that job to our password manager — a secure vault that generates and remembers complex, unique passwords for you, and syncs them across all your devices.
• Find out about new leaks as fast as possible. Some online services will send you a free alert if your email address shows up in a known data leak. But it’s much more convenient to monitor leaks with a dedicated security app. For example, Kaspersky Password Manager constantly checks all the entries you’ve saved. It warns you if you use the same password on different websites, or if any of your saved login and password pairs has been compromised. Our simple instructions for Windows, macOS, Android, and iOS can help you easily check all the passwords you’ve saved in Kaspersky Password Manager. Your passwords are never sent to Kaspersky. We explain how we can analyze your passwords without knowing them in our post, How to create strong passwords and where to store them.
• Use reliable protection that tracks and blocks leaks of your data. While Kaspersky Password Manager only checks the active password entries you’ve added to it, Kaspersky Premium can monitor for compromised accounts linked to your email addresses (you can add up to 50 addresses to check), and for digital identity theft linked to your phone numbers. And besides reporting leaks that have already happened, our security solutions can also stop data about you from being collected online.
• Set up privacy on your devices and apps with our free online service, Privacy Checker.

Keep your accounts separate

The more websites that know your email, the more often it will show up in advertising profiles and potential leaks. For one-time and minor sign-ups, you can use an email masking service. All Apple users get this feature by default (Hide My Email). If you use another OS, you could try Firefox Relay, for example.

The service then creates a separate proxy email address for the website where you’re trying to sign up. Messages sent to that address are automatically forwarded to your real inbox, but the website never sees your real email address.

If you want to go all in, you can try splitting your digital life into several sub-personas by hand. Create several email addresses for different purposes. For example, use one for online stores, banks, and government services, a second for public social media, and a third for forums and social networks where you want to stay anonymous.

Keep in mind that all this is a challenge: you’ll need to keep coming up with new nicknames, and make sure your sub-personas never overlap. If you use an email address for an anonymous profile, don’t link it to services that already have your real details, and don’t use it as a backup email for a public account. One accidental link can easily undo all your effort.

Check what you share with exes

If you’ve recently broken up with a partner, make sure you check which parts of your shared digital life they can still access. Sadly, it’s very often ex-partners who become doxers or stalkers — spying on their former other half and stopping at nothing to do so. For more details on exactly what to do in this situation, read our article Post-breakup digital hygiene: what to check and shut down.

Use your right to be forgotten

Many countries have a right-to-be-forgotten law. It lets you ask search engines to remove links to pages that contain your personal data.

You can send the links to those pages, explain why you want them hidden, and request that they be removed from search results. Keep in mind that the page with your data isn’t deleted. Other search engines may still show it, and it may still turn up for other search queries.

To submit a request like this, use the dedicated forms from Google or Bing. But remember that a search engine can turn you down if it decides the information is in the public interest, or that the law requires it to be published.

There are more effective, though more time-consuming, ways to remove your data from the internet. We covered them in detail in our post, Why data brokers build dossiers on you, and how to stop them doing so.

Looking for more ways to protect your digital identity? Check out our other posts:

• How to disappear from the internet
• Doxing — another online danger for women
• Post-breakup digital hygiene: what to check and shut down
• The Naked Truth
• AI and the new reality of sextortion

Introduction

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

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

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

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

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

Tracing the unicorn

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

Stages of order fulfillment

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

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

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

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

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

Hunting the unicorn

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

Warehouse risks

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

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

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

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

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

Cornering the unicorn

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

Warehouse attack surface

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

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

Initial attack vectors

Internet-facing services

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

Wi-Fi, Bluetooth, and other radio channels

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

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

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

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

Physical network

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

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

Barcode scanners

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

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

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

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

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

Portable data terminals

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

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

Printers

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

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

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

Impact on logistics processes (attacks on WMS)

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

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

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

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

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

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

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

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

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

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

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

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

Securing the unicorn

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

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

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

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

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

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

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

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

Introduction

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

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

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

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

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

Tracing the unicorn

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

Stages of order fulfillment

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

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

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

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

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

Hunting the unicorn

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

Warehouse risks

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

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

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

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

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

Cornering the unicorn

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

Warehouse attack surface

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

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

Initial attack vectors

Internet-facing services

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

Wi-Fi, Bluetooth, and other radio channels

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

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

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

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

Physical network

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

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

Barcode scanners

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

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

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

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

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

Portable data terminals

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

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

Printers

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

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

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

Impact on logistics processes (attacks on WMS)

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

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

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

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

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

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

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

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

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

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

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

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

Securing the unicorn

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

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

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

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

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

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

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

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

Finding a job these days is playing on hard mode. You send your resume to a company, and a couple of minutes later, an automated rejection lands in your inbox. And then it happens again. And again. Sound familiar?

In this post, we look at how recruiting platforms work from the HR side. We also show how to use AI safely as a copy editor so you can prepare a resume for recruiters without turning it into a lifeless pile of keywords. At the end, we share a ready-made prompt to help you improve your resume’s structure and content.

Protecting your data

Before you give your resume to a chatbot, remove all sensitive information: your name, phone number, home address, email, company names, and scans of documents. Any language model you chat with can sometimes memorize personal information contained in their training data. That means there’s always a chance the AI may accidentally “learn” to give your data to other users. On top of that, even the biggest services aren’t immune to glitches and leaks. For example, last year a researcher found a bug in Meta AI that let users gain access to other people’s conversations with the chatbot by changing their request ID.

The ability to read other people’s chats sometimes isn’t even a bug. For example, it recently came to light that Grok users who clicked the Share chat button to send a conversation to a friend or to themselves were also allowing search engines to index that conversation. As a result, thousands of conversations ended up in public view. These included personal data, requests to come up with complex passwords, complaints about health problems, trade secrets, and other information the chat owners clearly never meant to publish.

So before you use any chatbot, first check its privacy policy, and then go to the settings to turn off all the features you don’t need. Most importantly, turn off training the AI on your requests. And remember the golden rule: don’t send an AI anything you wouldn’t be okay with seeing on the internet.

If you work with sensitive information all the time, the safest option is to run language models locally right on your own computer. We previously explained how to do this, using DeepSeek as an example. The same approach works with any other open-weight model.

Finally, don’t feed your personal data to chatbots from unknown developers that promise to write you a flawless resume. Often, these are just slick wrappers around popular models. And you probably won’t ever find out who actually gets access to your data, where it’s stored, or what happens to it next.

Malicious actors can use this information for follow-up attacks. For example, they can send fake interview invitations and attractive job postings that match your work experience and career interests a little too well. From there, the scam can go in many directions: a malicious file disguised as a job invitation, a link to a phishing page that steals your account, a request to install “corporate software” or to continue the chat in a messaging app, and so on.

When choosing an AI tool, ask yourself these questions:

• Does the service have a clear privacy policy?
• Does it say what happens to your file after you upload it — will it be stored or deleted?
• Does the service explain whether your data will be used to train AI?
• Who owns the service? Can you trust this company?
• Is the site protected with HTTPS?

Who reads your resume: a human or a robot?

Most large and mid-sized companies have long used an applicant tracking system (ATS). This is specialized software for HR teams (human resources specialists or, put simply, recruiters) that collects and sorts job applications.

A company having an ATS doesn’t mean their applicants are scored automatically. It’s a fairly old type of system that dates back to when artificial intelligence looked very different. Then, as AI tech evolved, some companies started building AI modules into their ATS. But how common this is varies a lot from country to country and market to market. According to a LinkedIn study, 37% of HR leaders surveyed worldwide use AI in hiring, but only 11% actively integrate AI tools into their HR platforms.

The takeaway: you can optimize your resume for AI, but you still need to write it for a human. Even if your resume clears the AI screening, an HR person will read it next — and flat, machine-sounding prose will only hurt their impression of you.

Keep in mind that instant rejections don’t come only from AI. In some ATS, recruiters can set up automatic rejection rules by hand. For example, these rules can rely on a candidate’s answers about education, work authorization, required experience, licenses and certifications, ability to work the required schedule, and so on. So take a moment to check that your resume contains up-to-date and complete information relevant to the vacancy.

How to write a resume that passes both AI and HR screening

Write the first draft yourself

It’s ok to turn to AI for help, but the resume has to have substance, and a real person with real work experience has to shine through.

Start by writing your resume yourself. It doesn’t have to be perfect, and it can have mistakes. Only then ask AI for a fresh pair of eyes. Here, AI shouldn’t act as your personal biographer. It should act as a copy editor that polishes the wording and structure.

Keep the formatting simple

Unless the employer asks for something specific, skip the photos, tables, complex graphics, and custom fonts. And definitely don’t try to design something fancy in a graphic editor. Any of these can make your document unreadable for an ATS. The gold standard is a plain PDF or DOCX file with headings, a standard font, clear sections, and bulleted lists.

Tailor your resume to each job

Copy the job description and ask a chatbot to work its key phrases into your resume. Don’t just sprinkle keywords around. Put them in context and back them up with examples from your experience. Remember: you should be able to prove every word in your resume.

Show what your effort achieved

Skip the generic phrases, personality labels, and bare lists of duties like “responsible”, “did data analysis”, or “prepared reports”. Both recruiters and AI look for specifics, ideally with numbers and timeframes. Show what you did your job for, not just what you did.

Stick to the action + tool + result formula: “Automated report generation with Python and cut preparation time by 80%”, “Launched a new pricing model and grew annual revenue from US$400 000 to US$600 000 in 12 months”, “Developed a corporate messaging app that more than a thousand employees use today”. Don’t overdo the numbers. If you don’t have exact figures, or they don’t apply, don’t make them up.

Put the most important things first

Start with a short paragraph of two to three sentences that covers the key points and contains a link to your portfolio. Use it to give a brief overview of your work experience, skills, and key achievements. If you’re new to the field, write about your education and career goals instead.

List your work experience in reverse chronological order so your latest career achievements are the first thing people see.

AI prompt

You’ve got the tips — now it’s time to ask AI for help. Here’s a prompt that works. We’ve tested it on several chatbots:

Review before sending

• Check for extraneous information: make sure your resume doesn’t include unnecessary personal data or information covered by an NDA.
• Check for readability: make sure your resume has the right headings, dates, and section order, and that the file is in DOCX or PDF format. Remove any complex graphics from the document.
• Check for accuracy: reread every statement and ask yourself, “Could I back this up in an interview?” Remember: AI doesn’t know all the details of your work and may exaggerate some of the wording.

More on how to use AI safely without compromising your privacy:

• Privacy settings in ChatGPT
• The pros and cons of AI-powered browsers
• How phishers and scammers use AI
• Hacking Black Friday: using LLMs to save on the “sale of the year”
• Would you entrust your vacation travel plans to AI?

CVE-2026-109618 and CVE-2026-109619 are Critical vulnerabilities in PHP, a scripting language used globally for web servers and CMS systems.

The post Threat Brief: Critical Vulnerabilities in PHP: CVE-2026-109618, CVE-2026-109619 (Updated October 29) appeared first on Unit 42.

Cybercriminals have been relying on the same trick for years: hide malicious content where traditional email security tools cannot easily inspect it. Password-protected attachments, QR-coded URLs, and redirector-wrapped links have often acted as convenient hiding places for attackers. But it's possible to stop these threats.

Many businesses still fear ransomware attacks. But is this threat still as relevant today? A few years ago, at the peak of ransomware’s popularity, the term “ransomware” was practically synonymous with malicious encryption of data. But in reality blocking access to information had long been little more than a symbolic gesture. In a May Securelist post on shifts in the ransomware threat landscape, our experts noted that in 2026, attackers are encrypting company data for ransom less and less frequently. Here’s a striking example: while investigating an incident, Kaspersky’s Global Emergency Response Team (GERT) uncovered the PAYLOAD extortion campaign, whose operators didn’t even bother using ransomware. They took a different route instead.

In this campaign, instead of using ransomware, the attackers seized control of the Active Directory environment, and created a malicious group policy object (GPO). They used it to deploy a ransom note, change wallpapers, and lock screens on workstations, and set up a banner to display at system login. Naturally, they also disabled local administrator accounts while they were at it. This move let the attackers demonstrate their presence in the compromised infrastructure and prove they’d accessed confidential information — just as effectively as encryption would have. Detailed information about this incident, along with indicators of compromise, can be found in the same Securelist post. What interests us more, though, is the trend of abandoning encryption.

Why data encryption has lost relevance

Let’s start with the fact that in a large company with thousands of infected computers, decrypting data is an extremely effort-intensive process. Restoring data from backups, which has become common practice largely thanks to mass ransomware attacks, is far easier than waiting for criminals to hand over a key, hoping it’s genuine, and trusting that the ransomware itself didn’t have bugs that made the data unrecoverable. As a result, cybercriminals found it harder and harder over time to actually collect a ransom for the decryption key.

Attackers tried to adapt to this shift. Alongside encryption, they increasingly began stealing confidential data and threatening to publish it. Publishing confidential information puts a company’s reputation, its security, and the safety of its business partners at risk. This is especially true if the data includes people’s personal information: more than 140 countries around the world have data protection laws, so a leak puts an organization at a fairly high risk of a hefty fine. Sometimes that’s far scarier than simply losing data, and no backup can help with that.

Data exfiltration has another advantage from the attackers’ perspective: it’s usually much harder to detect than malware activity. File encryption, for instance, triggers a spike in disk activity that endpoint protection tools pick up fairly quickly. By contrast, data exfiltration is easy to disguise as normal traffic. This is precisely what the ShinyHunters group exploits, building its attacks around the standard OAuth mechanism. On top of that, attackers can steal data much quicker if they don’t bother with encryption, which also makes it harder to catch the threat in time.

As a result, encryption has become a kind of calling card — proof that the attackers had access to the data. So cybercriminals finally decided to drop this optional step altogether.

What businesses should do

Standard cyberhygiene practices can help protect against a wide range of extortion schemes — regardless of whether or not they involve encryption:

• Run regular, automatic backups. By storing backups on two types of media — physical and cloud — a business need not fear serious disruption to its operations. After all, the downtime required to restore from backups is nothing compared with the consequences of losing all of its data.
• Install patches and updates promptly. For attackers, vulnerabilities remain one of the main entry points into infrastructure. To reduce the risk, we recommend setting up automated update management for operating systems, software, and drivers. It’s also important to scan systems regularly for security gaps, and triage the found vulnerabilities with a focus on critical flaws. Specialized vulnerability management solutions can help with this.
• Strengthen endpoint protection. Set up multi-factor authentication for every system in an infrastructure, and deploy a reliable workstation and server security solution. A SIEM or EDR solution can help security specialists gain full visibility into events, and respond to incidents quickly.
• Monitor external perimeter. Regularly check the company’s infrastructure (servers, databases, clouds, and legacy subdomains) for open ports and services exposed to the internet.
• Adhere to the principle of least privilege. This means giving users, systems, and processes only the access privileges they need to do their jobs. Revoke unused privileges, and fully disable access for former employees.
• Invest in staff training. Attackers still exploit the human element to break into a company’s infrastructure. Raising threat awareness among employees can keep them from falling victim to phishing.

Gamers around the world are holding their breath for November 19, 2026, the day Grand Theft Auto VI is expected to drop. Many of them have been waiting for the next installment in the hit series for over a decade. For die-hard fans, the final months before launch could prove especially agonizing. Sadly, scammers know all about this hotly anticipated release too, and they’ve decided to use it as a lure to launch all sorts of attacks on gamers. We’ve spotted a great many bait sites aimed at impatient GTA VI fans. Today, we walk you through exactly how these crooks try to trick gamers, and how you can avoid becoming their next target.

1. “GTA VI has already leaked, and all you have to do is pay”

One site our experts found, called CyberLeek, claims to have an early build of GTA VI, and pretends to offer three different ways to get hold of the game before its official release. The first and priciest option is to buy the “full game” of GTA VI for US$1000. For that price, buyers are offered an early build of the game, exclusive content, and a direct download link. This is claimed to be a limited offer: only one copy per customer.

An alleged GTA VI leak advertised for US$1000

For those not ready to part with a thousand dollars, there’s a cheaper option: for a hundred dollars, users can get 24-hour access to the GTA VI demo.

Finally, the third option relies on crowdfunding. Playing modern-day Robin Hoods, the site’s creators claim they’ll raise $50,000 and then release the game to the public for free, with everyone who donates at least $100 getting priority early access. But dig into the fine print, and the fundraising goal for that paid early access suddenly jumps from $50,000 to $500,000. Looks like one of the scammers sat on their keyboard hit an extra zero by accident.

An urgent fundraiser for US$50,000 — or is it US$500,000? — to release a leaked GTA VI build, plus advertising opportunities for businesses

But CyberLeek’s lineup of tempting “offers” doesn’t stop there; there are also services for businesses. For US$5000, the site’s creators offer to place an ad right inside Grand Theft Auto VI: a logo, a product, or a brand mention that will supposedly show up in some unspecified “upcoming Grand Theft Auto video content”. What exactly that means is unclear: in-game clips or cutscenes, trailers, or just some gameplay footage. And honestly, the price seems suspiciously low for product placement in one of the most anticipated games in recent years.

This offer looks especially amusing next to the supposedly complete early build of the game with full access available on the same website. So, apparently, the game is already finished enough to sell in full, but you can still somehow slap ads into it.

One can only pay for all these incredible services with cryptocurrency. CyberLeek accepts Bitcoin, Ethereum, USDT, and Litecoin, and the site’s creators make a point of saying that all payments are final and no refunds are possible. Well, we weren’t expecting refunds anyway.

That said, this is just one example. CyberLeek started out as the nickname of the hacker behind both the recent Rockstar Games breach and GTA VI content leak. Later on, other cybercriminals began using that same name to build a whole bunch of fake sites. Despite having completely different designs, all of these sites attempt to project an association with CyberLeek, enticing users with (false) promises of access to “official” leaked versions of GTA VI. Whichever of these sites you come across, we’d strongly advise against using your own computer to check what’s actually hiding inside the archives and installers they hand out.

Another CyberLeek site offering access to a “leaked build” of GTA VI invites the user to download some unknown launcher, or “unlock” the full version of the game — whatever that means

2. Preordering Grand Theft Auto VI — with a catch

This bait targets slightly more sensible gamers — the kind who aren’t trying to download GTA VI right this second but wouldn’t say no to grabbing a free preorder code ahead of time. Our experts found a site that is claiming to hand out a redeem code for the PlayStation 5 or Xbox Series X|S. All one needs do is pick a platform and provide an email address.

To make it all look convincing, the site even shows off its own “statistics”: it supposedly has 3480 active users, and only 121 codes are still available as of today.

To get the “exclusive code”, the user is asked to pick a console and provide their email address

After picking a console, entering an email address, and clicking Reveal Code, the user lands on a new page. It shows the first four characters of a supposedly generated code, and to get the rest the user is asked to complete an additional check. They’re given 15 minutes to do so.

The site shows the first four characters of the coveted code, and promises to send the rest after an additional check, which the user has 15 minutes to complete

Nobody tells the gamer upfront what this check actually involves. But the next page, which opens after clicking Reveal Full Code, inexplicably turns out to be in German. Here, the user is asked to pass a “human verification”: download a free AI chat app for their computer, run it, and accept the terms of use.

The real point of this “verification” most likely boils down to driving traffic to third-party, often shady, or outright fraudulent sites, with GTA VI simply used as bait to pump up visitor numbers.

To get the rest of the “code”, the site demands that the user download and run an AI chat app and accept its terms of use

A simpler variation involves fake sites that simply collect money under the pretext of placing preorders for Grand Theft Auto VI. For example, a fake PlayStation Store site targeting Brazilian users offers preorders for R$449.9, which actually matches the official price in the real PS Store. The user can pay with a credit card or through Pix (Brazil’s instant payment system), but along with their money, they’d also have to hand over personal data, including their CPF — the Brazilian equivalent of a taxpayer identification number.

In Brazil, a fake PlayStation Store site collects money for GTA VI preorders at a price that looks legit

3. You’ve missed it: GTA VI is already out!

Some scammers don’t even bother with elaborate stories about leaks, beta tests, or preorder deals. They simply build websites that copy the look and feel of GTA, and invite users to start playing GTA VI right here, right now. We came across a few examples of these sites.

No leaks, no tests, no codes needed: visitors are simply invited to click Try GTA 6 and start playing

One of these sites tells users they can download GTA VI, as long as they first pick their platform. The range of options is surprisingly generous: a PC version as well as versions for PlayStation 5 and Xbox Series X|S.

Users are invited to pick a version of GTA VI for PlayStation 5, Xbox Series X|S, or PC

Just to be clear, GTA VI’s official release is still more than a month away, so there’s no way one can download and install the game right now. Nobody knows exactly what users would be getting on their devices instead of the game if they download from one of these sites, but it’s definitely nothing useful. And no matter how carefully scammers copy GTA’s signature style and slap on the Rockstar logo, the address bar usually gives the game away: check the domain and compare it with the official Rockstar Games website address.

4. The icing on the cake: GTA VI for tokens

And finally, what would 2026 be without cryptocurrency? We found a site whose creators were probably inspired by the CyberLeek story and decided to ride the wave of GTA VI’s popularity to promote a token with the refreshingly straightforward name $GTAVI. The whole site is styled after GTA VI and Vice City.

The creators of the project have gone out of their way to highlight the perks of holding the token. They call $GTAVI “the only GTA VI coin that actually rewards its holders”. Whatever the meaning of that tagline, the project’s declared ultimate goal sounds even more tempting: every token holder will get access to Grand Theft Auto VI just by virtue of owning $GTAVI. Think about that for a second: it’s not exactly a direct promise of a free copy of GTA VI, but more like an aspiration on the part of the crypto developers.

The token’s creators claim that they’re striving to eventually provide every $GTAVI holder with access to GTA VI

To add a bit of credibility, the page also throws in some crypto stats. The claimed market cap of $GTAVI is 51,600 dollars, with a 24-hour trading volume of 7880 dollars. There’s also a mysterious metric called “Characters” with a value of 12, and what exactly it means is anyone’s guess. There’s also a separate mention of a certain $BOOBIE as the Top Gainer — apparently, this is how the site’s creators labeled whoever supposedly made the most money off $GTAVI. The site doesn’t explain where any of these numbers come from or how accurate they actually are.

All in all, this looks like an attempt to hype up yet another meme coin by riding the wave of GTA VI’s popularity. Projects like this often end up following the classic pump-and-dump playbook: the token gets promoted for a while to drive its price up, and then the insiders and major holders cash out, leaving everyone else stuck with heavily devalued crypto. As for the stated goal behind $GTAVI — letting every token holder get a copy of GTA VI just for owning it — the site gives us no reason to believe that’s actually going to happen.

How to wait for GTA VI without falling for scammers

Unfortunately, we don’t know of a legitimate way to get early access to GTA VI, and honestly, we doubt anyone else does either. It looks like we’ll all just have to wait until November. To make sure you don’t fall for tempting scam offers in the meantime, here’s what we recommend:

• Only install games from official sources.
• Check the website address. Even if a page looks like the official Rockstar Games website or the PlayStation Store, carefully examine the domain in the address bar.
• Never enter your payment details on sites promising GTA VI before its official release — especially if they ask you to pay in some unusual way like with cryptocurrency.
• Don’t download unknown launchers, archives, or installation files, even if they’re billed as a “leaked build” or as software you need in order to be a beta tester.
• Don’t hand over your personal information for a “beta test”, “key”, “early access”, or any other offer that sounds too good to be true.
• Never disable security features just because a website tells you to. If a site asks you to ignore a Windows warning, run some mysterious command, or launch an unknown file as an administrator, treat it as a giant red flag.
• Install a reliable security solution built for gamers, one that warns you before you land on a scam site and blocks malicious files, but won’t slow your games down.

What other tricks do scammers pull to fool even the tech-savviest gamers? Find out in our other posts:

• Bad advice for gamers:ClickFix hits Steam forums
• Hentai games with a nasty twist
• Stealka stealer: the new face of game cheats, mods, and cracks
• Gamers under fire: malware on official websites
• Arcane stealer instead of Minecraft cheats

ClingSTUN operates as a back-connect proxy backdoor, sets up persistence, and contains exploits for self-propagation.

The post Linux Backdoor Abuses STUN Protocol, Exploits Dozens of Flaws appeared first on SecurityWeek.

Blogs

Blog

Insider Threat Report: Dark Web Recruitment & Access Trends

Flashpoint’s monthly analysis of insider threat recruitment, illicit access advertising, and threat actor activity targeting enterprise environments.

SHARE THIS:

Flashpoint Intel Team

October 15, 2026

Table Of Contents

Table of Contents

The Insider Threat Landscape: September 2026

Where Insider Threats Activity is Concentrated

Protect Against Insider Threats Using Flashpoint

Frequently Asked Questions (FAQs)

More

subscribe to our newsletter

Unknowingly, a member of key personnel is living two separate lives. On the clock, they are a highly-trusted systems administrator, but in their personal time, they moonlight on the deep and dark web, advertising their trust and access to the highest bidder. One day, they get a simple offer: $15,000 in the crypto of their choice to approve a single push notification at 2 AM. They accept. By morning, the attacker walks away  with active domain admin credentials without the need for malware or cracking firewalls.

This is just one example of how insider threats lead to modern enterprise breaches. As perimeter security, EDR coverage, and other security tools mature, threat actors continue to target the human element, seeking employees and contractors willing to provide access to corporate systems or facilitate fraudulent activity.

In a threat landscape where identity is becoming the primary attack surface, monitoring illicit marketplaces and recruitment efforts is critical. This new monthly report leverages Flashpoint’s Primary Source Collection (PSC) to analyze insider threat tactics, tracking active recruitment and advertising on dark web forums and encrypted networks.

The Insider Threat Landscape: September 2026

In September 2026, Flashpoint analysts identified a total of 9,787 insider-related posts across 1,216 channels and 1,778 authors. While the volume of observed activity decreased, threat actors continued to actively seek and advertise insider access, particularly within industries where legitimate employee privileges can be exploited to facilitate fraud. These communications included threat actors attempting to recruit insiders at target organizations, insiders advertising their services, and general discussions involving insider-related threat activity.

Of these communications, Flashpoint observed 857 unique posts between September 1 and September 30, 2026.

The majority of these posts appeared in mid-tier English-language Telegram channels, where threat actors sought or advertised insider access to organizations across several industries. Much of the observed activity focused on recruiting insiders to facilitate fraud operations.

Where Insider Threat Activity is Concentrated

Retail, telecommunications, and financial services remained prominent targets for insider threat activity in September 2026. However, a significant portion of the observed activity could not be attributed to a specific industry.

Flashpoint found that 45.7% of unique insider posts fell into the “Unknown” category, meaning analysts could not determine the targeted organization or industry. Among posts with an identifiable industry, retail accounted for the largest share, followed by telecommunications, financial services, and technology.

Together, these four industries accounted for 419 unique posts, or nearly 49% of all unique insider-related activity observed during the month.

The concentration of activity in retail, telecommunications, and financial services reflects continued threat actor interest in insiders who may be positioned to facilitate fraud, provide access to customer accounts, or exploit legitimate organizational privileges.

The following table shows a breakdown of unique insider posts by industry in September 2026:

Industry	Posts
Other	392
Retail	135
Telecom	116
Financial	85
Technology	83
Public Sector	41
Healthcare	3
Media	2
Total	857

Insider Threats: Recruiting vs. Advertising

Active insider threats generally involve two types of activity: an insider is recruited by a malicious outside party, or an insider advertises their access and services to interested threat actors. These arrangements can enable adversaries to exfiltrate sensitive data, install malware, compromise accounts, or carry out fraudulent activities such as SIM swaps.

In September 2026, Flashpoint analysts identified 15 notable insider recruitment and advertising posts across underground communities and chat forums. Of these, nine involved threat actors attempting to recruit insiders, while six involved actors advertising insider services.

Telecommunications accounted for the largest number of notable posts, with five instances of recruitment or advertising. Retail and technology followed with three each, while financial services and the public sector accounted for two each.

These examples illustrate how threat actors continue to seek access across industries, with particular interest in employees and contractors who can facilitate fraud or provide privileged access to organizational systems.

Flashpoint also observed numerous insider solicitations repeated across multiple discussion threads, often with limited details about the access or services being offered. Analysts could not independently verify the legitimacy of the recruitment and advertising claims.

Protect Against Insider Threats Using Flashpoint

Insider threats are inherently difficult to detect using internal security controls alone because the malicious activity relies on valid credentials and legitimate access privileges. Relying solely on internal logs means security teams often only detect an insider threat after data exfiltration or system sabotage has already occurred.

Flashpoint protects organizations against insider threats through our Primary Source Collection (PSC) and specialized intelligence platforms:

• External Threat Intelligence & Early Warning: Flashpoint monitors deep and dark web forums, invite-only threat communities, and encrypted chat platforms to identify employee solicitations, stolen corporate domain mentions, and active recruitment attempts before an intrusion develops.
• Identity Protection & Infostealer Tracking: By tracking illicit marketplaces and infostealer activity, Flashpoint identifies compromised corporate credentials and active session tokens, preventing threat actors from utilizing purchased access.
• User & Entity Behavior Context: Flashpoint’s intelligence equips SOC, Security Operations, and Risk Management teams with adversary TTPs, enabling security operations to look for anomalous data downloads, off-hours access, or unauthorized software installation.

To learn more about how Flashpoint can help protect your enterprise from insider risk and monitor illicit underground communities, Request a Demo Today.

Frequently Asked Questions (FAQs)

What is the Flashpoint Insider Threat Report?

The Flashpoint Insider Threat Report is a monthly intelligence brief that analyzes trends, volume, targeted industries, and tactics surrounding insider threat recruitment and illicit access advertising on the deep web, dark web, and encrypted chat channels.

How does Flashpoint collect insider threat data?

Flashpoint collects data using its Primary Source Collection (PSC) engine, which actively monitors thousands of dark web forums, illicit marketplaces, and underground chat networks where threat actors and malicious insiders communicate.

What is the difference between insider recruitment and insider advertising?

Insider recruitment occurs when an external cybercriminal attempts to entice a corporate employee into assisting with a cyberattack. Insider advertising occurs when an employee or contractor proactively lists their legitimate access or services for sale on illicit marketplaces.

The post Insider Threat Report: Dark Web Recruitment & Access Trends appeared first on Flashpoint.