IT threat evolution in Q3 2026. Non-mobile statistics
IT threat evolution in Q3 2026. Mobile statistics

The statistics in this report are based on detection verdicts returned by Kaspersky products unless otherwise stated. The information was provided by Kaspersky users who consented to sharing statistical data.

Quarterly figures

In Q3 2026:

• Kaspersky products blocked more than 311 million attacks launched from online resources.
• Web Anti-Virus responded to 47 million unique links.
• File Anti-Virus blocked more than 23 million malicious and potentially unwanted objects.
• There were 4470 new ransomware variants discovered.
• More than 81,000 users experienced ransomware attacks.
• 15% of all ransomware victims whose data was published on threat actors’ data leak sites (DLSs) were victims of Qilin.
• More than 217,000 users were targeted by miners.

Ransomware

Quarterly trends and highlights

Threat actor disruption

In August, the creator and lead administrator of the Ransom Cartel ransomware-as-a-service (RaaS) operation was sentenced to 16 years in prison. The convict developed the ransomware Trojan and at the time of his arrest played a central role in the RaaS operation: running the affiliate program, recruiting affiliates, supplying them with information and attack tools, working with initial access brokers, communicating with victims, and processing payments.

In September, a member of the Ryuk RaaS group was sentenced to two years in prison and three years of supervised release. In 2019 and 2020, he and his accomplices breached organizations’ networks and encrypted data with the Ryuk Trojan. According to public reports, hundreds of workstations and servers were compromised. According to the prosecution, the attacker received a total of about 1610 BTC in ransom payments from victims.

Also in September, a member of the Conti RaaS group was sentenced to four years in prison. He was charged with attacking companies in 2021 and 2022. In addition to carrying out attacks, he developed part of the group’s malware toolkit.

Vulnerabilities and attacks

In July, researchers published a report on the Qilin group exploiting the CVE-2026-0257 vulnerability in Palo Alto Networks firewall software. The vulnerability allowed attackers to bypass authentication and compromise victims’ networks without valid accounts.

CISA published information in its Known Exploited Vulnerabilities Catalog (KEV) on several CVEs actively exploited by ransomware groups:

• CVE-2026-15409/CVE-2026-15410 in SonicWall SMA1000 remote access gateways. CISA doesn’t specify which groups exploited these vulnerabilities, but researchers have linked this activity to INC Ransom.
• CVE-2026-45659 in Microsoft SharePoint Server allowed an authenticated, low-privileged attacker to achieve remote code execution.
• CVE-2025-60710 in Microsoft Windows allowed attackers to escalate privileges locally.
• CVE-2026-59310 in VMware vCenter enabled unauthenticated remote code execution.
• CVE-2025-14733 in WatchGuard Firebox also enabled unauthenticated remote code execution.
• CVE-2026-63077 in JetBrains TeamCity allowed OS commands to run with the privileges of the TeamCity server process by way of an authentication bypass through the agent polling protocol. Command execution at that level could give access to configurations, credentials, CI/CD pipelines, and more.

The most prolific groups

This section highlights the most prolific ransomware gangs by number of victims added to each group’s DLS. Qilin (15.39%) holds first place, as it did last quarter. Qilin is followed by The Gentlemen (7.89%), which was especially active in Q1 but did not make the list in Q2. A notable newcomer on the list is Deadlock (4.46%), a relatively young ransomware family first reported in July 2025.

Number of each group’s victims according to its DLS as a percentage of all groups’ victims published on all the DLSs under review during the reporting period (download)

Number of new ransomware variants

In Q3, Kaspersky products detected three new ransomware families and 4470 new variants, more than 1.5 times last quarter’s count.

Number of new ransomware modifications, Q3 2025 – Q3 2026 (download)

Number of users attacked by ransomware Trojans

During the reporting period, our products protected 81,556 unique users from ransomware attacks. Users encountered ransomware most often in September.

Number of unique users attacked by ransomware Trojans, Q3 2026 (download)

TOP 10 countries and territories attacked by ransomware Trojans

* Excluded are countries and territories with relatively few (under 50,000) Kaspersky users.
** Unique users whose computers were attacked by ransomware Trojans as a percentage of all unique Kaspersky users in the country/territory.

TOP 10 most common families of ransomware Trojans

* Unique Kaspersky users attacked by the specific ransomware Trojan family as a percentage of all unique users attacked by this type of threat.

Miners

Number of new miner variants

In Q3 2026, Kaspersky solutions detected 2197 new miner variants. After the spike in the second quarter, it’s fair to say the pattern has returned to the calmer one typical of last year.

Number of new miner modifications, Q3 2026 (download)

Number of users attacked by miners

In Q3, we detected miner attacks on the computers of 217,024 unique Kaspersky users worldwide.

Number of unique users attacked by miners, Q3 2026 (download)

TOP 10 countries and territories attacked by miners

* Excluded are countries and territories with relatively few (under 50,000) Kaspersky users.
** Unique users whose computers were attacked by miners as a percentage of all unique Kaspersky users in the country/territory.

Attacks on macOS

Quarterly highlights

At the beginning of the third quarter, Jamf researchers discovered a new stealer, PamStealer. What sets it apart is its use of Pluggable Authentication Modules (PAM) to verify the administrator password the user enters.

During the quarter, Socket researchers discovered several supply chain attacks that compromised popular npm, PyPI and Cargo (the Rust package manager) packages. The malicious payloads in these packages targeted macOS systems along with others. For example, on July 11, an infected npm package, jscrambler, was published. Its malicious module was an infostealer written in Rust. The infostealer targeted crypto wallets, secrets from various services and browsers, MCP server configurations, and API keys for AI agents. In August, an attack was detected on the arrayref, internment, and append-only-vec Rust crates; it delivered a Rust backdoor to the victim’s device. In September, malicious versions of the MemTensor npm and PyPI packages were published. They delivered a Go backdoor that targeted secrets, configurations, and API tokens of various services.

In August, Jamf researchers also reported discovering a new backdoor, Overlord. It was distributed as fake Zoom installers and had fairly broad spyware functionality, which is not often seen in macOS backdoors: it could eavesdrop through the microphone, watch the user through the camera, capture the screen, and log keystrokes.

In the third quarter, we discovered an updated version of the MacSync crypto stealer and backdoor with a significantly changed payload delivery method.

TOP 20 threats to macOS

Unique users who encountered this malware as a percentage* of all attacked users of Kaspersky security solutions for macOS (download)

* Data for the previous quarter may differ slightly from previously published data due to certain verdicts being retrospectively revised.

The share of Ngrok, a network tunneling tool suite with both legitimate and malicious uses, continued to grow, bringing it to the top of the list. We’re also seeing more detections of the well-known Amos malware, both the traditional stealer and a version with backdoor functionality.

TOP 10 countries and territories by share of attacked users

* Unique users who encountered threats to macOS as a percentage of all unique Kaspersky users in the country/territory.

IoT threat statistics

This section presents statistics on attacks targeting Kaspersky IoT honeypots. The geographic data on attack sources is based on the IP addresses of attacking devices.

Distribution by protocol

In Q3 2026, the share of devices attacking Kaspersky honeypots over SSH grew to 18.42%.

Distribution of attacked services by number of unique IP addresses of attacking devices (download)

The distribution of attacks over the Telnet and SSH protocols shows the same trend.

Distribution of cybercriminal sessions in Kaspersky honeypots (download)

TOP 10 threats delivered to IoT devices

Share of each threat delivered to an infected device as a result of a successful attack, out of the total number of threats delivered (download)

Mirai’s share of the overall IoT threat distribution declined, while other botnet threats that deliver malware grew.

Attacks on IoT honeypots

In the distribution of SSH attacks, the Netherlands, Bulgaria, and the US accounted for the largest shares, with the share of attacks originating from Bulgaria having grown fourfold. Germany comes next, with its share down by about half.

Pakistan’s share of Telnet attacks kept growing, reaching 47.73%.

Attacks via web resources

The statistics in this section are based on detection verdicts by Web Anti-Virus, which protects users when suspicious objects are downloaded from malicious or infected web pages. These malicious pages are purposefully created by cybercriminals. Websites that host user-generated content, such as message boards, as well as compromised legitimate sites, can become infected.

TOP 10 countries and territories that served as sources of web-based attacks

The following statistics show the distribution by country/territory of the sources of internet attacks blocked by Kaspersky products on user computers (web pages redirecting to exploits, sites containing exploits and other malware, botnet C&C centers, and so on). One or more web-based attacks could originate from each unique host.

To determine the geographic source of web attacks, we matched each domain name to the actual IP address hosting it, then geolocated that address (GeoIP).

In Q3 2026, Kaspersky solutions blocked 311,083,655 attacks launched from online resources across the globe. Web Anti-Virus was triggered by 46,936,926 unique URLs.

Web-based attacks by country/territory, Q3 2026 (download)

Countries and territories where users faced the greatest risk of online infection

To assess the risk of malware infection via the internet for users’ computers in different countries and territories, we calculated the share of Kaspersky users in each location on whose computers Web Anti-Virus was triggered during the reporting period. The resulting data provides an indication of the aggressiveness of the environment in which computers operate in different countries and territories.

This ranked list includes only attacks by malicious objects classified as Malware. Our calculations leave out Web Anti-Virus detections of potentially dangerous or unwanted programs, such as RiskTool or adware.

* Excluded are countries and territories with relatively few (under 10,000) Kaspersky users.
** Unique users targeted by web-based Malware attacks as a percentage of all unique users of Kaspersky products in the country/territory.

On average over the quarter, 4.34% of internet users’ computers worldwide were targeted by at least one web-based Malware attack.

Local threats

Statistics on local infections of user computers are an important indicator. They include objects that penetrated the target computer by infecting files or removable media, or initially made their way onto the computer in non-open form. Examples of the latter are programs in complex installers and encrypted files.

Data in this section is based on analyzing statistics produced by anti-virus scans of files on the hard drive at the moment they were created or accessed, and the results of scanning removable storage media. The statistics are based on detection verdicts from the On-Access Scan (OAS) and On-Demand Scan (ODS) modules of File Anti-Virus and include detections of malicious programs located on user computers or removable media connected to the computers, such as flash drives, camera memory cards, phones, or external hard drives.

In Q3 2026, our File Anti-Virus recorded 23,733,652 malicious and potentially unwanted objects.

Countries and territories where users faced the highest risk of local infection

For each country and territory, we calculated the percentage of Kaspersky users whose computers had the File Anti-Virus triggered at least once during the reporting period. These statistics reflect the level of personal computer infection in different countries and territories worldwide.

Note that this ranked list includes only attacks by malicious objects classified as Malware. Our calculations leave out File Anti-Virus detections of potentially dangerous or unwanted programs, such as RiskTool or adware.

* Excluded are countries and territories with relatively few (under 10,000) Kaspersky users.
** Unique users on whose computers Malware local threats were blocked, as a percentage of all unique users of Kaspersky products in the country/territory.

On average worldwide, Malware local threats were detected at least once on 10.88% of users’ computers during Q3.

Russia scored 9.37% in these rankings.

IT threat evolution in Q3 2026. Non-mobile statistics
IT threat evolution in Q3 2026. Mobile statistics

The mobile section of the quarterly cyberthreat report includes statistics on malware, adware, and potentially unwanted software for Android, as well as descriptions of the most notable threats for Android and iOS discovered during the reporting period. These statistics are based on detection alerts from Kaspersky products, collected from users who consented to provide statistical data to Kaspersky Security Network.

The quarter in figures

According to Kaspersky Security Network, in Q3 2026:

• More than 1.66 million attacks involving mobile malware, adware, or unwanted software were blocked.

• The Trojan-Banker category was the prevalent mobile malware threat with a 31.63% share of all detected malicious apps.
• Over 378,000 malicious installation packages were detected, including 119,688 mobile banking Trojan packages.

Quarterly highlights

In July, we discovered a malicious app targeting Brazilian users that may have used AI to automate fraud. The app was disguised as Google Play Protect, a suite of security services for Android devices.

Malicious app imitating Google Play Protect

The app’s code used the DistilBERT model to interpret natural-language commands sent from the C2 server. Traces left in the code suggest the server-side commands may also have been generated by a large language model (LLM).

In August, we discovered a Trojan that analyzed images saved in the device’s gallery and took screenshots to look for banking data, including CVV codes. The malware used an on-device AI model to classify images. The app could also update this model, which gave the scammers a way to expand the Trojan’s functionality.

In the third quarter, the infamous subscription Trojan detected as Trojan.AndroidOS.Subscriber.bh made it into Google Play again. This time, it was disguised as an app for creating keyboard themes.

Subscription Trojan disguised as a keyboard theme app

The Trojan opened a subscription link in a hidden WebView and intercepted the message containing the confirmation code. According to our data, the scammers mainly targeted users in Thailand.

There were also new attacks on iOS users. In August, researchers at Socket discovered 13 infected PHP packages in the Packagist repository. The malicious payload injected links to fraudulent casinos into sites that used these packages and, on iOS devices only, a hidden iframe that loaded the DarkSword exploit kit. The attack delivered a spyware module that stole keychain contents, Wi-Fi passwords, SMS messages, photos, and other personal data. Other modules found in this campaign were used to steal crypto wallet data and the seed phrases used to recover them.

SlowMist researchers found the same DarkSword exploit chain used in a fake app, FomoPeek. FomoPeek was published in the App Store, presenting itself as a crypto wallet tracker. The malware was designed to steal data from notes and crypto wallet apps.

Also in August, we discovered infected versions of popular iOS apps distributed through Telegram (link in Russian). To install such an app, the attackers asked users to buy a developer certificate. The modified versions contained a malicious module that collected device information, took screenshots, and sent this data to a server.

Mobile threat statistics

The downward trend in attacks on mobile devices involving malware, adware, or unwanted software continued: the number fell to 1,668,368 in Q3 from 1,996,823 in Q2.

Attacks on users of Kaspersky mobile solutions, Q1 2025 – Q3 2026 (download)

In the third quarter, this decline was driven in part by fewer adware attacks, which we examine in more detail below.

The number of Android malware samples grew compared to the previous reporting period, reaching 378,456.

Detected malicious and potentially unwanted installation packages, Q3 2025 – Q3 2026 (download)

The distribution of detected installation packages by type was as follows:

Detected mobile apps by type, Q2*–Q3 2026 (download)

* Data for the previous quarter may differ slightly from previously published data due to certain verdicts being retrospectively revised.

The sharp rise in Trojan-Dropper apps comes from more droppers delivering known banking Trojans such as Mamont and Creduz. In the previous quarter, we described the trend of attackers “packaging” banking Trojans. The resulting malware is classified as droppers, which explains the growth. Note that standalone banking Trojans still rank first. Together with droppers, they account for more than half of all detected malicious apps.

Share* of users attacked by the given type of malicious or potentially unwanted apps out of all targeted users of Kaspersky mobile products, Q2–Q3 2026 (download)

* The total percentage may exceed 100% if the same users encountered multiple attack types.

The number of AdWare.AndroidOS.HiddenAd and AdWare.AndroidOS.MobiDash attacks continued to decline, although adware traditionally ranks first by the number of attacked users. The growing share of Trojan-Dropper correlates with the increase in packaged banking Trojans described in the previous section. Among Trojan-Spy attacks, the biggest growth came from the BTMOB and SpyNote RAT Trojans, which are used to steal money.

TOP 20 types of mobile malware

Note that the malware rankings below exclude riskware or potentially unwanted software, such as RiskTool or adware.

* Unique users who encountered this malware as a percentage of all attacked users of Kaspersky mobile solutions

Most of the list is made up of variants of Trojans that were already popular last quarter: several versions of the preinstalled Triada Trojan, Mamont bankers, and BTMOB spyware.

The main newcomer among Q3’s most widespread malware was the Trojan-Proxy.AndroidOS.Vo1d.b apps, delivered by preinstalled Trojans. These apps turn the device into an exit node of a VPN service. These attacks are dangerous for two reasons. First, they burn through internet traffic, which the user may be paying for, to relay other people’s data. Second, cybercriminals can use the infected device to attack online services and visit banned websites, breaking the law in the victim’s name.

Mobile banking Trojans

In Q3 2026, the number of Trojan-Banker installation packages began rising again after a drop last quarter.

Number of installation packages for mobile banking Trojans detected by Kaspersky, Q3 2025 – Q3 2026 (download)

By type, Creduz again accounts for the largest share of banking Trojans. However, as in Q2, the statistics of actual attacks tell a different story: Mamont variants were again the most active Trojans.

TOP 10 mobile bankers

* Unique users who encountered this malware as a percentage of all Kaspersky mobile security solution users who encountered banking threats

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.

Anyone who has signed in to a streaming app on a smart TV by typing a short code into a phone has used a device code flow. Microsoft supports the same mechanism for Microsoft 365 accounts, and attackers have turned it against the people it was designed to help. Through 2026, ready-made Phishing-as-a-Service (PhaaS) kits such as EvilTokens, Kali365, and Tycoon2FA have put the technique within reach of almost anyone willing to pay for it.

• Cisco Talos observed a new AI-integrated command-and-control (C2) framework in the wild called “NIK C2.”
• NIK C2 contains a Windows implant, using which, an actor can dump credentials, stream the victim's keystrokes to collect the targeted victim’s sensitive data, and instruct an integrated AI model to analyze the harvested data, all within the compromised session.
• In this framework, the actor has abused the OpenAI Chat Completions application programming interface (API), which is a HTTP endpoint that enables ChatGPT-style conversations programmatically.
• In addition to the features that enable theft, an actor can also deploy desktop screen-locking ransomware via the NIK C2 implant onto the victim machine, leading to a ransom demand in Bitcoin or USDT cryptocurrencies.
• NIK C2 reshapes adversary tradecraft by collapsing collection and exploitation into a single continuous session, effectively erasing the offline processing delays that historically granted defenders critical detection windows. 
• Such AI-enabled adversarial frameworks require defenders to move beyond traditional detection and embrace continuous behavioral vigilance as the new baseline.

NIK C2 implant: AI-integrated remote access tool

The NIK C2 implant is a Go-based, 64-bit Windows remote access tool that grants persistent control over compromised hosts using a resilient dual-channel C2 architecture. It communicates over TLS-secured WebSockets on port 443 alongside an HTTP fallback polling loop every 250 milliseconds, protecting all traffic with AES-256-GCM encryption derived from a hardcoded seed. To survive takedowns, the implant routes traffic across three prioritized C2 tiers, which are runtime-updated URLs, an embedded encrypted server list, and a hardcoded fallback address. Beyond standard operations, the implant features surveillance, theft, lateral movement, and evasion capabilities, including credential dumping, RDP session hijacking, process hollowing, and a C2-driven screen lock ransomware module. 

Notably, the NIK C2 implant embeds a fully integrated OpenAI API client via its ai_generate command, allowing operators to route arbitrary prompts to the OpenAI Chat Completions API directly through the infected host. The NIK C2 implant manages API key resolution, request assembly, and response parsing locally, returning the encrypted generative AI results to the actor's C2.

The observed NIK C2 implant samples in the wild contains an embedded build path (/opt/nik_panel/data/build_52b79724a1fc4b8f/main.go), which identifies the project as "nik_panel" and indicates that the implant was cross compiled for Windows from a Linux development environment. Furthermore, the embedded eight-byte hex token matching the build identifier highlights that the threat actor's infrastructure actively tracking and versioning the implants. 

NIK C2 implant evolution timeline 

Talos observed that the NIK C2 implant development trajectory spans at least three distinct versions. All binaries observed in the wild were compiled with Go 1.23.4 (which was released in December 2024), placing the entire sample set compiled no earlier than late 2024. The actor has Zeroed PE TimeDateStamp fields and near-epoch filesystem timestamps (manifesting as Nov 29, 1979) are applied consistently across all samples.  

We developed a timeline based on the initial sighting dates of NIK C2 implant variants in OSINT. 

The pace of capability addition across the three versions indicates a technically proficient team with prior malware operations experience is actively expanding NIK C2 towards a full-service adversarial framework. 

Active NIK C2 server seen in the wild  

During our research, we observed that a threat actor hosted the NIK C2 framework on a server at IP address “87.120.196[.]120”, resolving the domain “total-sitevv[.]lol”. The C2 server hosted an SSL/TLS certificate (serial number 7d16381a9de823943b5a0987dbd0f26edf22052b and jarm:"28d28d28d00000000042d42d0000001f361a1bf80ed39a1e352adeb016a07b" ) with the Common Name (CN) set to nik-panel. This CN value matches strings embedded within the implant binary. Observing the NIK C2 infrastructure active in the wild allowed us to assess with moderate confidence that NIK C2 is not merely a proof of concept, but a fully functional, AI-integrated C2 framework. 

NIK C2 implant integrates OpenAI’s API 

AI integration is one of the most architecturally distinct features of NIK C2 implant. It constructs a fully formed HTTP request to OpenAI’s production inference endpoint, transmits it from the victim machine IP address, parses the JSON response, and returns the AI-generated text to the actor’s panel. The entire operation from receiving the actor prompt to returning the large language model (LLM) reply is executed synchronously with a 60-second timeout. 

The implant begins by extracting three fields from the command payload received from the C2. The first field, identified by the key prompt, is the text the actor wants to send to the AI model. If the prompt string has zero length, the handler immediately constructs an error response and returns without making any outbound network call. The second field, identified by the key api_key is the OpenAI API key to use for authentication. The third field, identified by the key model, specifies which OpenAI model to use.  

After extracting the three parameters, the implant checks whether the actor supplied an API key. If not, it calls the operating system's environment variable reader with the string OPENAI_API_KEY and uses the victim’s API key.  This fallback is not a backup mechanism for API key resolution. It is a deliberate design with significant operational implications. If the victim has configured an OpenAI account on their machine, that account's API key will be used to fund the actor's AI inference. OpenAI's billing system will charge the victim's payment method, and OpenAI's access logs will show the victim's API key as the one that made the requests, allowing no trace attributable to the threat actor.  

If the actor does not specify a model name, the implant falls back to a five-character default string stored in the binary data section. Decoding the five-character value showed gpt-4 confirming that GPT4 is the default when no model is specified. The actor can override this by passing any valid OpenAI model identifier in the command payload, allowing selection of newer models as they become available without requiring a binary update.  

The implant builds the OpenAI API request body by constructing a map with four fields. The first field uses the key model and contains the resolved model name. The second field uses key messages and contains a two-element array of message maps. The third field uses the key temperature and contains a floating-point value read from a constant in the binary data section. The fourth field uses the key max_tokens and contains an integer value also read from binary. 

The message array is constructed in the order that the OpenAI Chat Completions API expects. The system message is first followed by the user message. The system message map has the role system and a content string that is exactly 68 bytes long hardcoded in the binary. This 68-byte string is the implant's behavioral instruction to the AI. It defines the model's operational role and response style for the duration of the session. The user message map has the role user and contains the actor's prompt text verbiage. The complete map structure is then serialized to JSON. The JSON message is sent to the URL https:// api.openai.com/v1/chat/completions, the OpenAI Chat Completions endpoint, through an HTTP POST request. 

When the HTTP response arrives with a 200 status code, the handler uses Golang's JSON decoder to parse the response body directly into a generic map structure without defining a typed schema. It then navigates the decoded map by string key lookups in the sequence that the OpenAI Chat Completions API response structure defines. The outermost map is queried for the key choices which in a successful response contains an array. The implant checks that this array is non-empty, then accesses its element keys message and content. The string value at key content is the AI model-generated text response.  

After successfully extracting the AI-generated content, the handler assembles a result map with four entries. The key status is set to a constant string that reads as generated. The key code is set to the AI model's response text, so that the actor receives the full content of the model’s replies. The key model is set to the resolved model name that was used for the request, confirming which model produced the output. The key usage is set to the raw usage object from the OpenAI response, which contains the prompt token count, completion token count, and total token count. This usage data allows the actor to track how many tokens are consumed per request. The completed result map is ultimately transmitted to the C2 server over WebSocket or through the HTTP fallback C2 address. 

Dual execution modes of NIK C2 implant

Upon execution, the implant inspects its command-line arguments to determine its execution path. The argument watchdog activates supervisory monitoring to relaunch the core process if terminated, the copywatchdog tracks file copy operations, and the absence of either defaults execution to primary agent mode.  

In primary mode, it uses a named mutex to enforce single-instance execution, logs a message reading [NIK] Starting, generates a 32-byte cryptographic session key if uninitialized, decodes its obfuscated C2 address, and sets its masquerade name to “svchost.exe” or “simvol.exe”. 

After initial setup, the binary records its process ID (PID) in the victim's temporary application folder and executes its persistence and evasion routines. These routines include copying to %appdata%/Roaming/Microsoft/Network with modified access controls, configuring Windows autostart registry entries, and masquerading its process. Finally, it starts the local proxy server, initiates the WebSocket communication loop in a separate goroutine, and enters a continuous heartbeat polling loop on the main thread. 

Implant’s C2 command surface overview 

The implant command dispatcher module facilitates over 52 commands that are directed by the C2 panel. The dispatcher module uses byte-level string matching to map the associated modules that are launched as concurrent goroutines, allowing multiple operations to run in parallel.  

The following table shows the NIK C2 implant’s command categories: 

Implant deploys screen-locking ransomware  

The ransomware module of the implant operates as a multi-stage attack controller that the actor runs in sequence to prepare, deploy, and retract a screen-locking ransomware payload.  

At first, it executes PowerShell to execute a raw disk copy command that reads directly from the physical drive device path (“\\.\PhysicalDrive0”) and writes the first sector, which is Master Boot Record (MBR), to a file named “mbr_backup.bin” in the Windows temporary directory.  

Next, the module constructs a complete self-contained HTML lock screen code entirely at runtime from a hardcoded format string, parameterized with actor supplied Bitcoin and USDT wallet addresses, prices, contact email, timer duration, and custom text from the C2 command message, allowing the actor to fully customize the ransom demands. 

After generating the HTML code, the binary writes it to the file “lock_screen.html” in the system temporary directory. It then generates a Windows batch script that calls mshta.exe with the path to the HTML file, followed by an infinite loop construct with a five-second timeout between iterations, ensuring that if the user somehow closes the window it reopens within five seconds. This batch file is written to the temp directory as “lock_start.bat”. 

The implant then runs a reg add command that writes a registry Run key named “SystemLock” under the current user's autostart path, pointing to a cmd /c invocation of the batch file, so the lock screen is executed on every user's logon. Additionally, a background goroutine is spawned that continuously monitors and relaunches the lock screen process. Finally, the module sends a confirmation response to C2 with the path of the deployed HTML file and the timer value. 

The design of this ransomware module is notable for several reasons. It does not encrypt any files, which means it leaves no forensic trail of file modification timestamps or encryption markers. It relies entirely on a screen lock, which is considerably faster to deploy than a file encryption ransomware. The persistence via registry Run key and a self-healing loop ensures the screen lock survives user attempts to dismiss it and survives a system restart.  

Implant’s bootkit preparation feature 

The bootkit preparation module of the implant is designed to survey the victim machine's boot firmware environment and then stage a bootkit payload file.  

It executes bcdedit /enum, the Windows Boot Configuration Data editor, with the output flag that enumerates all boot entries while hiding the console window. The implant reads the full output and searches for three specific substrings in sequence including EFI, Windows Boot Manager, and Windows Legacy OS Loader. If any of these are found, the boot type is classified as UEFI. The binary also searches for ntldr, the legacy Windows NT loader used by BIOS-mode systems as a fallback. Based on which string was matched, the boot type is recorded as either "UEFI" or "BIOS" as a string of the appropriate length. Separately, the binary runs a PowerShell command invoking Confirm-SecureBootUEFI, which is a built-in PowerShell command that returns to the current Secure Boot state. The output is searched for the string True to detect an enabled Secure Boot and for False to detect an explicitly disabled Secure Boot.  If neither is present, the value is recorded as unknown. The result is sent back to the C2, a map containing the boot type classification and the Secure Boot status string. 

Then the implant writes a 16-byte placeholder file named “bootkit.bin” to the system temporary directory. The bytes written spell out "NIK_BOOTKIT_PREP" in ASCII, which serves as a staging marker rather than an actual bootkit binary. This placeholder confirms that the target path is writable by the current process, establishes the file location that subsequent operations will reference, and can be overwritten by the actual bootkit binary delivered through the implant's file-upload or file-write command handlers. The path to the staged file is returned to the C2 in response.  

Implant’s theft functionality  

When the actor issues the theft category commands from the C2, the implant executes the associated goroutines to collect the targeted data into a result map space in the victim machine memory: 

WiFi password theft (wifi_steal) 

The implant executes netsh commands directly via Go’s exec.Command function by passing arguments as discrete tokens rather than through a shell string. Harvested results are formatted under specific labels: plaintext Wi-Fi passwords appear under Key Content:, saved network names are cataloged under WiFi Profiles: (with missing entries flagged using the per-entry format [%s] not found), and execution failures or absent interfaces return standardized error strings such as [WiFi] no wireless adapter or access denied and No WiFi profiles found. 

netsh wlan show profiles 
netsh wlan show profile name="" key=clear  

Browser credential extraction (passwords, quick_steal) 

The implant stages targeted browser database files into an archive alongside the Local State file, which contains the AES master key protected by Data Protection Application Programming Interface (DPAPI). The implant imports and executes the CryptUnprotectData Windows API to unwrap the AES key and decrypt the databases locally. Otherwise, it exfiltrates the raw encrypted databases to the C2 server for offline extraction. 

Targeted browser database files are shown in the table: 

Token and cookie theft (token_grab, quick_steal) 

The implant extracts Discord tokens and session cookies from the levelDB store on the victim machine. The extracted outputs are labelled as === Discord Tokens === and DISCORD TOKENS. The browser session cookies (Discord_Cookies) are extracted from the copied Cookies database.  

Cryptocurrency wallet theft (crypto_steal, wallet_export) 

Victim’s desktop-based wallets are collected directly from the wallet storage paths. Browser extension wallets are extracted from chromium LevelDB stored by extension ID. 

Desktop based wallet storage paths targeted are listed below: 

• /AppData/Roaming/Exodus/exodus.wallet 
• /AppData/Roaming/Electrum/wallets 
• /AppData/Local/Electrum/data/wallets 
• /AppData/Roaming/Ethereum/keystore 
• /AppData/Local/LedgerLive 
• wallet.dat (Bitcoin Core) 
• /AppData/Roaming/atomic (Atomic Wallet) 
• Electrum\wallets 

Browser extension wallets targeted: 

Seed phrase, private key file, and system reconnaissance 

The implant performs two regular expression patterns to search on the entire filesystem of the victim machine. These two regular expressions are designed to scan file names for sensitive cryptographic assets and credentials, functioning as case-insensitive patterns ?i. The first expression targets cryptocurrency recovery materials and wallet backups by matching keywords like "seed," "mnemonic," or "wallet" paired with common plain-text and data file extensions (.txt, .md, .csv, .dat), while the second seeks out asymmetric private keys and general secrets using terms like "private," "privkey," or "secret" paired with both text files and standard cryptographic key containers (.key, .pem). Because both patterns use unanchored, greedy matching (.*) without start (^) or end ($) boundary anchors, they capture any file where these sensitive terms precede the target extensions. Matched data are collected under the label of seed candidates and archived into “browserdata.zip”.   

(?i)(seed|phrase|mnemonic|recovery|backup|wallet).*(\.txt|\.md|\.csv|\.dat) 
(?i)(private|privkey|secret).*(\.txt|\.md|\.key|\.pem) 

The implant also performs victim machine reconnaissance by executing the following commands and uses chcp 65001 prefix to force the output in UTF-8 format.  

chcp 65001 >nul 2>&1 & systeminfo 
chcp 65001 >nul 2>&1 & wmic os get lastbootuptime /value 
chcp 65001 >nul 2>&1 & wmic /namespace:\\root\SecurityCenter2 path AntiVirusProduct get displayName 2>nul 
chcp 65001 >nul 2>&1 & Get-Process | Select-Object Id, ProcessName | ConvertTo-Json -Compress 

After all collection paths are complete, the implant assembles all collected data into a single document that looks like a formatted report with clearly labeled sections for each data category such as === CRYPTO ===, === WIFI ===, === BROWSER ===.  

Keylogger: Keystrokes livestreamed to C2 

The keylogger module of the implant uses a persistent background goroutine that polls all 256 Windows virtual key codes, detecting keypresses via dynamically resolved API calls, and transmits the captured input. When a compromised victim presses a valid key on the keyboard, it is simultaneously streamed live as an AES-256-GCM encrypted JSON payload over WebSocket to C2 and also appends to an in-memory buffer capped at 10,000 entries and halved when full to prevent memory leaks. On an actor's dump command, this buffer is concatenated into a single string and returned to C2 via WebSocket or HTTP fallback, ensuring complete data transfer even during network interruptions. 

Stolen data exfiltration to C2 

Once the archive is assembled, the entire result map is handed to the result transmission routine of the implant. That routine constructs a new JSON object containing five specific fields. It includes the command identifier echoed back from the original command. It also contains the agent's persistent identifier, formatted as ag_<16 hex chars>. The type field is set to the string quick_steal_response. Finally, the data field holds the complete result map. 

Once constructed, this object is forwarded to the encryption routine. The routine serializes the object into JSON. It then generates 12 fresh random bytes to serve as a nonce. Next, it encrypts the serialized JSON using AES-256-GCM with a static key derived from a hardcoded seed. It concatenates the nonce, the ciphertext, and the 16-byte authentication tag and Base64-encodes the entire payload. The encrypted payload is placed in a wrapper object under the "e" key alongside the plain-text agent ID, and the wrapper is JSON marshaled into the final payload. 

This encrypted payload is then delivered through an available transmission path. The sending routine first checks whether the WebSocket connection is live. If it is, the payload is written directly into a WebSocket text frame on the existing connection, reaching the actor's panel with minimal latency. If the WebSocket is not currently connected, the routine falls back to an HTTP POST request to the endpoint path /api/c2/result on the C2 server, using the same encrypted body format. This dual-path design ensures stolen data is delivered even during WebSocket interruptions, as the HTTP channel remains functional independently of the WebSocket state. 

Implant’s C2 protocol 

The implant C2 architecture is designed for two independent, simultaneously operating communication channels. The primary channel is a persistent WebSocket connection over TLS. The secondary channel is an HTTP polling loop that posts to a fixed API endpoint at regular intervals. 

With the primary channel, the connection begins with a TCP dial to the C2 server address with an eight-second timeout. If the port is not explicitly present in the configured address, port 443 is appended automatically. Once the TCP socket is established, it is wrapped in a TLS session using a custom certificate configuration that pins to a specific certificate rather than validating against the system's certificate authority store. This prevents standard TLS interception proxies from observing traffic. 

Immediately after a successful WebSocket handshake but before any command is received, the implant transmits a full system registration message. The implant collects victim data such as the machine hostname, the local LAN IP address, the Windows username from the environment, a user security identifier, the local reverse-proxy port number that was assigned when the embedded proxy server was started, and the detected upstream proxy configuration derived from the Windows registry proxy settings. All of this is assembled into a JSON object and encrypted and sent to the C2.  

The HTTP polling channel runs independently. Every approximately 250 milliseconds, the agent collects a fresh snapshot of victim state hostname, watchdog status, local IP, username, current timestamp, and system uptime encrypts it in the same wire format and posts it to the /api/c2/update endpoint on the C2 server.  

Below table shows the C2 endpoints that the implant communicates: 

Every message on both channels, in both directions, uses the same symmetric encryption scheme. A hardcoded seed value stored in obfuscated form in the binary data section is decoded at startup and produces a 32-byte AES key. 

Decoded AES seed: d791dd0ff3228ed29a8d7333d4567be829159c5632ea347780992006f91c5295 
32-byte AES key: 4887AFC0A574E9419A9695EF083460F58E4EF9A1C40793523CE112251273BDF9 

The C2 server then responds with an encrypted payload, whose inner map contains a command array identical in structure to those delivered over WebSocket. Commands received through HTTP are dispatched through the same logic. If the HTTP POST fails, the agent rotates to the next server address before retrying. 

The result transmission to the C2 is performed by the implant when a command handler completes its operation, the result is packaged into a response envelope containing the original command's identifier, the implant's own identifier, a type string formed by appending _response to the command name, the result data payload, and a top-level type marker of "result". This object is encrypted and delivered through either directly over the WebSocket connection if it is active, or via an HTTP POST to /api/c2/result. 

Implant’s defense evasion and anti-analysis techniques 

The NIK C2 implant deploys a layered set of defense evasion measures that activate immediately at startup and operate across the full compromise session. On launch, It hides its console window via API ShowWindow, renames the binary to “csrss.exe” in the Windows temp directory to impersonate a legitimate system process, disables Windows Recent Documents telemetry through a registry write action, and applies a critical-process flag via API NtSetInformationProcess with the parameter value 0x1D for  ProcessBreakOnTermination that causes a Blue Screen of Death if any attempt is made to terminate the process through Task Manager or taskkill actions.  

Alongside these, two anti-debug checks IsDebuggerPresent and CheckRemoteDebuggerPresent run silently and call os.Exit(0) on detection, leaving no exception record or crash evidence. When directed by the C2, the implant can also escalate privileges without a UAC prompt using the fodhelper.exe COM hijack, which writes the implant path into HKCU\Software\Classes\ms-settings\Shell\Open\command, triggers elevation, and cleans the registry key within two seconds. 

The implant bypasses the Antimalware Scan Interface (AMSI) by executing a hardcoded, embedded PowerShell script that patches memory inside “System.Management.Automation.dll”. Specifically, it overwrites the AmsiInitFailed field with a six-byte stub (MOV EAX, E_INVALIDARG; RET), forcing initialization to report failure and disabling content inspection for the remaining of the PowerShell session. 

Conclusion 

The emergence of NIK C2, an AI-enabled command-and-control framework, underscores a critical shift in modern malware design: the transition from static intrusion toolsets to dynamic, modular implants that adapt on demand. By embedding a live AI pipeline directly into the C2 loop, the compromised host is no longer a passive foothold but an autonomous operational asset. Operators can dynamically generate context-aware lure material, execute localized deception, synthesize operational intelligence, and craft targeted payloads directly on the compromised hosts — all while lowering the technical barrier which was traditionally required for such sophisticated tradecraft. 

Coverage 

The following ClamAV signature detects and blocks this threat:  

 Win.Trojan.GoDiscorder-10060526-0 

Indicators of compromise (IOCs)

IOCs for this research can be found at our GitHub repository here.

Explore the latest tactics, techniques, and procedures (TTPs) our incident response (IR) experts are actively facing in the quarterly TTP Briefing, a report built on frontline threat intelligence from our global incident response investigations across LevelBlue during Q3 2026.

• Download the full report

• Register for the Global Webinar

• Register for EMEA Webinar

A Unified View of the Threat Landscape

This TTP Briefing is based on threat intelligence derived directly from LevelBlue incident response engagements worldwide over the past quarter. These engagements are technology-agnostic, providing a clear view into the real-world tactics, techniques, and procedures adversaries are using today.

The latest edition also incorporates threat intelligence from LevelBlue SpiderLabs, which broadens the dataset behind our findings.

Trusted Access Fuels Data Theft

The theme of the quarter: trusted access fuels data theft. Attackers didn’t need to break in so much as log in. Session tokens captured by phishing kits, OAuth apps users consented to, VPN appliances that accepted forged authentication, and remote management tools that look like routine IT all gave threat actors a foothold that looked legitimate from the inside. Once there, they went after data. We observed data exfiltration appearing in 83% of intrusion cases, while encryption is at 67%. In Q2, both were 77%. Non-ransomware network intrusions were the second most common incident type, and for the first time, exfiltration overtook viewing or accessing files as the most common outcome when data was at risk.

This briefing breaks down what our IR teams saw this quarter: who was targeted, how attackers got in, what they did once inside, and how fast they moved. Each section closes with guidance defenders can act on now.

Across our investigations this quarter, four themes stood out: attackers are diversifying initial access methods, identity has become a primary battleground, data theft is increasingly replacing encryption as the preferred source of leverage, and both attackers and defenders are moving faster than ever.

For additional insights, join our IR experts on November 10 at 11:00am ET or November 12 at 11:00am GMT for live webinars where they will explore our findings in more detail. Come armed with questions and walk away with actionable intelligence, detection priorities, and recommendations to strengthen your defenses.

Let’s explore a few key findings:

Most Common Threat Types

Figure 1. Most common threat types.

• BECs continued to be the most common threat incident type, accounting for 32% of incidents.

• Network intrusions without ransomware held steady as the 2nd most common incident type at 22%. This is largely due to threat actors focusing on exfiltration and extortion, rather than encryption.

• Ransomware was the 3rd most common incident type, accounting for 20% of incidents this quarter.

Detection built around encryption events will miss a growing share of intrusions. Watch for large outbound transfers, unusual archive creation, and new cloud storage destinations.

Data Exfiltration Becomes the Focus for Attackers

Exfiltration/extortion-only attacks were the fastest-growing category in Q3, with attackers stealing data and threatening to publish it without deploying ransomware. Attacks that combine encryption with exfiltration remain the most common, but their share has fallen each quarter. This suggests encryption is no longer a given in ransomware cases, and the leverage increasingly comes from the stolen data itself.

Figure 2. Intrusions.

The tools observed during investigations reinforce this trend. Utilities such as rclone, MegaSync, WinSCP, 7-Zip, and WinRAR continue to play an important role in attacker workflows, helping collect, package, and transfer sensitive information outside the organization.

Protecting systems remains essential, but organizations must also understand where their most sensitive information resides, who has access to it, and how they will detect abnormal movement or exfiltration activity before data leaves the environment.

Initial Intrusion Vector (How Are They Getting In?)

Figure 3. Initial intrusion vectors.

Phishing remained the top initial intrusion vector in Q3 at 42%, down from 65% in Q2. External remote services (RDP, VPN) and exploited vulnerabilities tied for second at 14% each. Together, those two internet-facing routes now account for more than a quarter of initial access.

Identity Is the Thread Through the Intrusion

• Valid-account abuse has grown in each quarter. It is still a small share of initial access, but the direction is clear.

• Social engineering often ends in stolen identities. Phishing/social engineering remains the most common way in, and that category includes vishing and help-desk impersonation. Many of those cases result in stolen credentials or tokens, so identity likely plays a larger role than the valid-accounts bar alone shows.

Most Commonly Observed CVEs – Q3

These are the vulnerabilities our incident response teams saw actively exploited in real incidents this quarter, which makes them a sharper patching priority list than any CVSS score.

Inside the CVE Numbers:

Inventory internet-facing business applications, not just network appliances. If it touches sensitive data and faces the internet, it belongs on the emergency patch list.

Exploitation Is Back, and Initial Access Diversifies

While social engineering remains a top concern, internet-facing flaws have increased as an initial access route, with CVEs and external remote services both rising in Q3. Attackers are using a wider mix of entry points, including vulnerabilities like Metabase.

A look at Metabase - CVE-2026-72898

A vulnerability was discovered earlier this quarter in Metabase, an open-source business intelligence and data visualization platform. Identified as CVE-2026-72898, this vulnerability allows for unauthenticated SQL Injection that could lead to remote code execution with a cvss score of 10. If exploited, this vulnerability could allow a threat actor to hijack an account and gain admin access to the connected Metabase instance. From there, we observed threat actors creating new admin accounts, and leveraging the AI engines to gain access to 3rd parties connected to Metabase, and exfiltrating data from there and extorting the victim. This vulnerability allowed for a fully self-contained intrusion path from initial access through end goal.

MFA Bypass

Figure 4. MFA bypass.

MFA is close to universal among the organizations we respond to, yet it no longer stops business email compromise attacks. In Q3, threat actors bypassed MFA in 79% of BEC incidents where it was enabled.

Although MFA remains widely deployed, attackers are increasingly sidestepping it through vishing, convincing victims to enroll an attacker-controlled device on their account. Because the victim approves the registration, the access appears legitimate, reflecting a shift from token interception to abuse of trusted device enrollment. Additionally, threat actors are relying more on machine identity and token abuse, rather than a normal user account attack, which does not involve bypassing MFA, contributing to the dip in our bypass stat.

Because attackers increasingly rely on valid tokens rather than defeating the prompt, pair MFA with continuous session-token monitoring, short token lifetimes, and conditional-access policies that flag anomalous token use.

The lesson is clear: identity security cannot be a standalone initiative. Organizations should pair phishing-resistant MFA with stronger monitoring of enrollment activity, conditional access controls, and greater visibility into account misuse across cloud and on-premises environments.

Most Targeted Industries and Company Sizes

Figure 5. Most targeted industries.

Targeted industries saw a shift in Q3. Financial services, which had been the top impacted sector for the last few quarters, dropped to #4, accounting for only 11% of incidents in Q3, down from 28%. Technology & Software surged to the top spot, accounting for 14% in Q3, up from 5% in Q2, and 3% in Q1. Healthcare and Manufacturing tied for the 2nd spot at 13%. This shift demonstrates that no industry is off limits to threat actors, and every sector should focus on cyber resilience.

Technology & Software spike: We observed an increase in compromised custom software and applications via exposed API keys, a trend that became more common in Q3 as threat actors used AI to hunt for exposed keys as an entry point into custom technologies. Because API keys are often long-lived, over-permissioned, and bypass MFA, a single exposed key can give direct access to sensitive data and connected systems. That reach, which can extend to a provider’s customers, makes the sector an attractive target.

Organizations with revenue between $1M–$100M accounted for the largest share of incidents in Q3, reinforcing that threat actors increasingly view mid-market companies as high-value, lower-resistance targets.

Tactics Across the Intrusion Path

Figure 6. Trends across the intrusion path.

The TTP Briefing provides data across the five stages of the intrusion path, from initial access to persistence and escalation techniques, to exfiltration and monetization tactics. Noteworthy findings include:

• Back door/remote access tools remain the most common tool type leveraged to gain persistence, using tools like ScreenConnect and MeshAgent to maintain access.

• Credential stealers, like mimikatz and DCSync, continue to be commonly used to escalate privileges, as identity compromise remains a top concern.

• During the data at risk stage of the intrusion path, files were most often exfiltrated, surpassing viewed/accessed for the first time, highlighting that threat actors are focusing heavily on data exfiltration.

A Look Into Dwell Time

Figure 7. Dwell time.

In the TTP Briefing, we exclude any MDR clients and measure dwell time from the initial date of the compromise until our IR team is engaged. This quarter, average dwell time continued to decrease, with 56% of incidents being resolved between 0-10 days. Shorter windows can mean faster detection, faster attacker execution, or both, and in Q3 we saw plenty of the latter.

What the shift says: Attackers are executing faster than we have ever seen. Some intrusions now play out in hours instead of days, with threat actors using AI tools to move through networks. Detection is improving, but so is attacker speed.

Review the full findings:

• Download the full report

• Register for the Global Webinar

• Register for EMEA Webinar

If you would like more information about this report, our team is available 24/7 at response@levelblue.com

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.

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.

Update Oct 22 2026: New sections were added for “Observed Threat Activity and Indicators” and “Mitigations and Recommendations.”

LevelBlue SpiderLabs has been tracking multiple waves of Wazza, a newly observed multi-stage phishing kit that deploys device code phishing targeting Microsoft 365 accounts. In addition to recent reporting by The Hacker News, our analysis examines the kit's evolving techniques and infrastructure, highlighting key changes observed across analyzed variants.

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.

Key Takeaways

A new proof of concept called BigDiskBuster, published on GitHub on September 19, 2026, by the actor known as MSNightmare, shows that Defender doesn't need to be disabled to stop receiving updates, it just needs a much simpler dependency: disk space.

TIKTOUK brings together WordPress probing, collection of exposed configuration data, recovery of encrypted email credentials, and JavaScript secret scanning. Its two Python components and Go-based Linux crawler turn website responses into structured results for a central hub: an HTTP service that distributes target tasks and receives collected data and status reports.

With contributions from James Rodriguez, Gus Stamatinos, and Timmy Lister.

Unit 42 is aware of possible 0-day activity against NetScaler devices. Citrix reports CVE-2026-88771, CVE-2026-88772 have been exploited in the wild.

The post Threat Brief: NetScaler Zero Days CVE-2026-88771 and CVE-2026-88772 Exploited in the Wild (Updated September 30) appeared first on Unit 42.

On Sept 27, Citrix released patches for two critical vulnerabilities being exploited in the wild. Based on current information, we confirm there has been no exposure or impact to LevelBlue or our clients. CISA has already added these vulnerabilities to the Known Exploited Vulnerabilities (KEV) list.

A recent trend has emerged where threat actor groups (e.g., ShinyHunters, PEAR, HELIX, etc.) have been leveraging phishing and vishing techniques to gain access to M365 email accounts. Through identity and token abuse, these actors have then automated large-scale file exfiltration and extortion campaigns targeting SharePoint, OneDrive, Microsoft Entra ID (formerly Azure AD), and email data through abuse of the Microsoft Graph API.

(Edit - Sept 17, 2026): The originally released PoC had issues that broke exploitation. That PoC has been revised by the author. We have reviewed the revised version of the exploit and have validated that it now functions as expected in our lab. We have added a section at the end of our original article discussing this update and our results.