2026-06-27 AI创业新闻

FBI Warns Russian Intelligence Hackers Target Signal Backup Recovery Keys

The FBI and CISA have updated their March warning about Russian intelligence phishing Signal accounts, and the operators have added a step: they now coax targets into handing over their Signal Backup Recovery Key. Hand it over once, and the attacker can restore the account’s backup, read the private and group message history, and take over the account. Worse, the key keeps working. Make a new account on the same phone number, and the old key can still be used against it, the advisory warns.

The fix is blunt: generate a new key in Settings, which kills the old one for future backup downloads, and accept that anything the attacker already pulled is gone. The updated advisory, PSA I-062626-PSA , adds two public tracking names the March notice lacked: UNC5792 and UNC4221. The FBI ties the activity to multiple Russian Intelligence Services (RIS) groups, including FSB officers embedded with the FSB Border Guards and others working for the Russian military services. The campaign hits Signal and WhatsApp accounts; the new recovery-key tactic the advisory describes is specific to Signal.

The targets are individuals of high intelligence value: current and former U.S. and international government officials, military personnel, political figures, journalists, and officials in Ukraine. The March notice said the broader campaign had already compromised thousands of accounts worldwide. The phishing message poses as Signal support.

Earlier waves asked for SMS verification codes and account PINs, or used doctored “group invite” links that silently linked an attacker’s device to the account. The updated version walks the target through turning on Signal backups, opening the Recovery Key, and pasting it into the chat. The advisory prints two sample messages: one dressed up as a mandatory two-factor rollout, the other as an urgent “data recovery” fix for messages supposedly at risk of loss. As in March, the agencies are clear that none of these breaks Signal’s encryption or the app itself.

The actors compromise individual accounts through social engineering, then walk in through a legitimate feature. Alongside the update, the State Department’s Rewards for Justice program is offering up to $10 million for information on UNC5792. The activity overlaps with warnings from Dutch intelligence (AIVD and MIVD), Germany’s BfV and BSI , and France’s ANSSI earlier this year. Google’s Threat Intelligence Group first documented UNC5792 abusing Signal’s linked-device feature in early 2025, and saw the same tradecraft turn up against WhatsApp and Telegram.

What to do now Treat any in-app message from “Signal support” as hostile. Real support does not message you inside the app to ask for codes, PINs, or your Recovery Key. Never paste your Backup Recovery Key, verification code, or PIN into a chat. Nothing legitimate asks for them that way.

Open Settings, check Linked Devices, and remove anything you do not recognize. If you think you handed over your Recovery Key, generate a new one in Settings now, and assume any backup made before that is already in someone else’s hands. The March notice warned the tactics would shift. They have, from chasing one-time codes to taking the key that opens the entire archive.

The encryption holds. The account is the weak point, and the person holding it is the target. Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

New SharkLoader Malware Deploys Cobalt Strike in StrikeShark Cyberattacks

A newly discovered cyber attack campaign has been observed delivering a previously undocumented malware family called SharkLoader that acts as a loader for deploying Cobalt Strike Beacon on compromised hosts. Kaspersky, which is tracking the activity under the moniker StrikeShark , said the campaign has targeted a diplomatic organization in Indonesia, government organizations in Taiwan, software development companies across multiple countries, and entities associated with other sectors located in Hong Kong, Lebanon, Syria, Colombia, North Macedonia, Nepal, and Serbia. “The observed victimology suggests a campaign with broad geographic reach and a diverse target set rather than a narrow focus on a specific industry or region,” the Russian cybersecurity vendor said . The campaign does not exhibit direct links to any known threat actor or group, although the operators have utilized several open-source post-compromise tools like FScan and Pillager , commonly put to use by Chinese-speaking developers.

It’s believed that the campaign is the handiwork of a Chinese-speaking threat actor. Attack chains involve the two initial access pathways: the exploitation of known Exchange Server flaws, such as CVE-2021-26855 (aka ProxyLogon), to strike the Indonesian diplomatic entity, or through a path traversal vulnerability impacting Openfire ( CVE-2023-32315 ) in the case of Taiwanese software development organizations, or a critical remote code execution bug in GeoServer ( CVE-2024-36401 ) to target a Colombian organization. Other remote code execution and authentication bypass vulnerabilities weaponized by the threat actor are listed below - Apache Shiro: CVE-2016-4437 Hikvision Products: CVE-2021-36260 Microsoft SharePoint: CVE-2021-27076 Zimbra Collaboration Suite: CVE-2022-27925 Microsoft Exchange Server: CVE-2022-41082 (aka ProxyNotShell ) F5 BIG-IP: CVE-2023-46747 Fortinet FortiOS: CVE-2024-21762 React Server Components: CVE-2025-55182 Fortinet FortiOS: CVE-2022-40684 Cisco IOS XE Web UI: CVE-2023-20198 It’s assessed that the threat actors are likely employing publicly available proof-of-concept (PoC) exploits hosted on GitHub or other open-source platforms to gain initial access in an opportunistic manner. Upon gaining a foothold, the threat actors establish persistence by deploying web shells to trigger a DLL side-loading chain involving “ SystemSettings.exe “ ( CVE-2021-27076 ) to deliver SharkLoader (“SystemSettings.dll”).

A second method used by StrikeShark to distribute the loader is via custom dropper executables masquerading as legitimate software installers or applications like Google Update and Cisco AnyConnect, and executing the malware loader once the installation process completes. The method by which these droppers are delivered is currently unknown. “In addition to installer-themed lures, several SharkLoader droppers use decoy PDF documents to persuade victims to open the malicious file,” Kaspersky explained. “However, not all samples employ this technique, as some droppers function solely as a delivery mechanism for SharkLoader without presenting any lure content.” Once the DLL is loaded, SharkLoader implements what’s called Perfect DLL Hijacking , a technique detailed by security researcher Elliot Killick in October 2023, to execute malicious code while bypassing Windows Loader Lock , a system-wide lock held by the operating system when loading and unloading DLLs.

Specifically, it’s engineered to decrypt and load “DscCoreR.mui,” which is then used to decompress and load Cobalt Strike in a new thread created in a suspended state, along with two other components - SyncRes.dat, which installs multiple Windows API hooks by using the Microsoft Detours library to monitor exceptions generated during runtime. MinHook DLL, which installs API hooks for the VirtualAlloc and Sleep functions to copy the decompressed Cobalt Strike Beacon into the allocated memory region using VirtualAlloc. The Sleep-related hook is triggered when the Beacon calls Sleep, likely in an attempt to evade memory scanning techniques that identify executable (RWX) code regions in memory. “Finally, after the API hooks are installed and the Cobalt Strike Beacon shellcode has been written to the thread buffer, the malware calls the ResumeThread API to resume the suspended thread and begin execution of the beacon,” Kaspersky explained.

While SharkLoader does not come with persistence mechanisms built into it, the threat actor has been found to leverage Registry Run keys and scheduled tasks as a way to activate the launch of “SystemSettings.exe” either when a user logs in, or even if no user is logged in. The attacks also involve an extensive reconnaissance phase following initial compromise and persistence, with the threat actor engaging in Active Directory enumeration, credential theft by targeting the LSASS process and the NTDS database file, and deploying open-source scanners and information gathering tools like FScan, Searchall, and Pillager. Given the absence of active data exfiltration, it’s unclear what the end goals of StrikeShark are. However, the targeting of government and software development organizations suggests a cyber espionage bent with a potential interest in hoovering political intelligence or intellectual property.

“At the same time, the use of SharkLoader and Cobalt Strike, alongside the exploitation of public-facing applications and malicious installers and droppers, suggests the attacker may also be opportunistically targeting vulnerable systems,” Kaspersky said. “The absence of clear evidence of data exfiltration thus far does not exclude this possibility, as Cobalt Strike’s file operation and data exfiltration modules could be employed at a later stage.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Chinese-Speaking APT Deploys New TinyRCT Backdoor in Southeast Asia Campaign

A Chinese-speaking advanced persistent threat (APT) actor has been linked to a new custom backdoor called TinyRCT as part of cyber attacks aimed at government entities and critical infrastructure in Southeast Asia. The activity, particularly aimed at state-owned enterprises in the energy and government sectors, has been attributed to a threat actor called CL-STA-1062 , which Palo Alto Networks Unit 42 said shares overlaps with UAT-7237 , a hacking group that was first flagged by Cisco Talos in August 2025 in relation to a campaign directed against web infrastructure entities in Taiwan. Unit 42 said it also observed CL-STA-1062 campaigns in prior operations targeting strategic sectors in East Asia since March 2022, suggesting a broader but sustained focus in the region. “From a technical standpoint, the attackers behind CL-STA-1062 rely on a hybrid toolkit,” Unit 42 said in a technical report.

“While they frequently use common open-source tools such as SoftEther VPN, Mimikatz, and VNT, they have recently introduced TinyRCT, a bespoke, previously undocumented backdoor.” TinyRCT is equipped to run arbitrary commands, enumerate files and exfiltrate them, capture the device’s screen, and delete itself from the compromised host. In one campaign detected in September 2025, the threat actor is said to have infiltrated a Southeast Asian government entity and deployed a web shell to exfiltrate data from an MS SQL server. During the same attack, the threat actors have been found to conduct network reconnaissance on a separate government entity in the same country. “This suggests an effort to identify lateral movement opportunities and broaden their access.

In one case, we observed the attacker staging and exfiltrating an entire directory of web server source code from the government entity,” Unit 42 said, adding it detected the breach of at least 10 different organizations in Southeast Asia between October and December 2025. Since at least mid-2025, CL-STA-1062 has trained its sights on the critical infrastructure, with the adversary scanning multiple entities in the region for vulnerabilities and then establishing a foothold via ASPX web shells that facilitate initial reconnaissance and outbound requests from the infected networks to attacker-controlled infrastructure, leading to the deployment of additional payloads. This includes SoftEther VPN components and RAR archives containing the group’s toolset, including open-source utilities such as Yuze (a SOCKS5 proxy) and VNT (a VPN), often disguising them as VMware executables or an XDR agent (e.g., “XDRAgent.exe,” “vmtools.exe,” and “vmwared.exe”). Further analysis of the campaign’s infrastructure has led to the discovery of a previously undocumented .NET backdoor dubbed TinyRCT (“PerfWatson2.exe”), a lightweight remote access trojan that enables system reconnaissance, command execution, file uploads, screenshot capture, remote control, and wipe traces of itself, while taking steps to avoid running in sandboxed environments.

It establishes a persistent communication channel with a remote server (“45.32.113[.]172”) over HTTP, but encrypts the exchanged data using AES-128 encryption in CBC mode. “The malware operates on a beaconing model, with a default 10-second sleep interval between requests,” Unit 42 explained. “It polls the C2 server for instructions using GET requests, while it sends exfiltrated data via POST requests.” As for how TinyRCT is delivered, it takes the form of a malicious archive named “chrome_setup.zip” containing a legitimate executable (“chrome_setup.exe”), a configuration file (“chrome_setup.exe.config”), and a rogue DLL (“MyAppDomainManager.dll”) that’s used to trigger an AppDomainManager injection attack to load the malicious DLL, which functions as a downloader by contacting “139.180.134[.]221” to retrieve “PerfWatson2.exe.” “The combination of tools observed in this activity cluster reflects a pragmatic approach to tool selection and attack capabilities,” Unit 42 concluded. “The attackers behind this cluster continue to leverage common open-source tools such as SoftEther VPN and VNT to facilitate lateral movement.” “Our discovery of the TinyRCT backdoor in the attackers’ infrastructure underscores their ability to customize tools to gain specific capabilities.

The combination of targeting critical infrastructure and the development of custom malware suggests that CL-STA-1062 activity will continue to pose a threat to the region.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

New Linux pedit COW Exploit Enables Root Access by Poisoning Cached Binaries

A flaw in the Linux kernel’s traffic-control subsystem can let a local unprivileged user gain root on affected systems. CVE-2026-46331 , nicknamed “ pedit COW ,” is an out-of-bounds write in the packet-editing action (act_pedit) that corrupts shared page-cache memory. A public, working exploit appeared within a day of the CVE assignment on June 16. Red Hat rates the flaw as important .

The exploit never touches the file on disk. It poisons the cached copy of a setuid root binary (/bin/su) in memory, injects a small payload, and runs that altered image as root. File-integrity checks come back clean while a root shell is already open. The exploit needs two things: act_pedit being loadable and unprivileged user namespaces being open, giving the attacker a namespace-local networking capability (CAP_NET_ADMIN) needed to trigger the bug.

On the tested RHEL and Debian targets, both conditions were present. How the Bug Works Linux’s tc traffic-control tool can rewrite packet headers in flight using an action called pedit. The kernel function that does this, tcf_pedit_act(), is supposed to make a private copy of the data before editing it, the standard copy-on-write pattern. It checked the writable range once, before the final offsets were known.

Some edit keys only resolve their offset at runtime. When that happens, the write lands outside the privately copied region, so the kernel modifies a shared page-cache page instead of a private copy. If that page belongs to a cached file, the file’s in-memory image is corrupted. The pattern is familiar.

Dirty Pipe , Copy Fail , DirtyClone , and Dirty Frag all share the same shape: a kernel fast path writes into a page it does not exclusively own, and the page cache takes the hit. What is new here is the entry point. An unprivileged user can configure tc actions from inside a user namespace, which gives them the CAP_NET_ADMIN that the exploit needs. Affected Systems The PoC author reported unprivileged-to-root exploitation on RHEL 10 and Debian 13 (trixie), where unprivileged user namespaces are open by default.

Ubuntu 24.04 required routing execution through AppArmor profiles that still permit user namespaces. Ubuntu 26.04 blocks that path by default because its AppArmor profiles restrict unprivileged user namespaces, though the underlying kernel remains vulnerable. Fixes are split by vendor. Debian has fixed trixie through its security channel.

Debian 11 and 12 are still listed as vulnerable. Ubuntu lists supported releases from 18.04 through 26.04 as vulnerable as of June 25. Red Hat lists RHEL 8, 9, and 10 as affected; RHEL 7 is not listed in the bulletin. What to Do Install the patched kernel and reboot.

Prioritize systems where “local user” does not mean trusted user: multi-tenant hosts, CI/CD runners, Kubernetes nodes, build workers, and shared research or lab machines. If you cannot patch yet, two mitigations kill the exploit chain. On systems that do not need tc pedit rules, check whether the module is in use (lsmod | grep act_pedit), then block it from loading: echo ‘install act_pedit /bin/true’ | sudo tee /etc/modprobe.d/disable-act_pedit.conf Alternatively, disable unprivileged user namespaces (user.max_user_namespaces=0 on RHEL, kernel.unprivileged_userns_clone=0 on Debian/Ubuntu). That removes the namespace-local capability the exploit needs, but it breaks rootless containers, some CI sandboxes, and sandboxed browsers.

Test first. Because the overwrite targets cached memory, file-integrity checks may not catch it. Dropping the page cache (echo 3 > /proc/sys/vm/drop_caches) clears the poisoned in-memory copy, but does nothing about the root shell the attacker already opened. Treat the host as compromised.

The fix landed on the netdev mailing list in late May, framed as a routine data-corruption patch. The exploitable detail sat on a public mailing list for weeks. No CVE, no security warning. The CVE was assigned when the fix was merged on June 16.

The weaponized proof-of-concept followed within a day. For kernel page-cache corruption bugs, waiting for a scanner rule is too slow. Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Amazon Q Developer Flaw Could Let Malicious Repos Run Code via MCP Configs

A high-severity flaw in Amazon Q Developer let a malicious repository run commands and steal a developer’s cloud credentials. The path was short: a developer opens the repo, trusts the workspace, and Amazon Q does the rest. Amazon has patched it. Tracked as CVE-2026-12957 (CVSS 8.5), the bug sat in how Amazon’s AI coding assistant handled Model Context Protocol (MCP) servers.

Wiz Research, which found and reported it, showed that a single config file dropped in a repo was enough to go from git clone to cloud compromise. How the attack worked Amazon Q read an MCP configuration file, .amazonq/mcp.json, from the open workspace and launched the servers it defined. MCP servers are local processes that an AI assistant can spawn to reach databases, APIs, or build tools, so starting one means running commands on the machine. Those processes inherited the developer’s full environment.

That usually means AWS keys, cloud CLI tokens, API secrets, and SSH agent sockets. Put the two together, and a file sitting in a cloned repo could run arbitrary code with the developer’s live cloud session attached. No password, no second sign-in. In its proof of concept , Wiz had the file run aws sts get-caller-identity and ship the output to an attacker server, capturing the active AWS session.

What comes next depends on that developer’s cloud permissions: backdoor an IAM user for persistence, reach internal services, or pivot toward production. AWS and Wiz frame the consent step differently. Amazon’s advisory says the user has to trust the workspace when prompted, and CVSS rates the user interaction as passive. Wiz reported there was no separate consent step for the MCP servers themselves before the fix.

The patch closes that gap: Amazon Q now flags an untrusted MCP server and lets the developer reject the command before it runs. The flaw lives in Language Servers for AWS , the runtime that powers Amazon Q across VS Code, JetBrains, Eclipse, and Visual Studio. All four plugins bundle it, so all four were exposed by versions that shipped an older copy. What to do Update.

CVE-2026-12957 is fixed in Language Servers for AWS 1.65.0, but AWS’s bulletin tells customers to move to 1.69.0. That build also closes a second issue, CVE-2026-12958 , a missing symlink check that could allow arbitrary file writes outside the workspace trust boundary. The patched plugin minimums: VS Code: 2.20 or later JetBrains: 4.3 or later Eclipse: 2.7.4 or later Visual Studio toolkit: 1.94.0.0 or later The language server auto-updates unless the network blocks it, and reloading the IDE pulls the latest build. There is no known public exploitation; CISA’s ADP entry for CVE-2026-12957 lists it as none.

Wiz found the flaw through research and disclosed it in coordination with Amazon, reporting it on April 20 and seeing a fix on May 12, ahead of the June 26 public write-up. A pattern, not a one-off Amazon Q is not the first coding assistant to trip over MCP trust. The bugs are not identical, but they rhyme: project configuration turns into executable behavior, and the trust checks around that handoff keep failing. Claude Code (CVE-2025-59536) and Cursor (CVE-2025-54136) both had project-level MCP config that led to command execution.

Windsurf (CVE-2026-30615) reached the same end by a different path, with attacker-controlled content rewriting the local MCP config to register a malicious server. The convenience of letting a project folder configure an AI agent is also the attack surface. Repo-carried config is untrusted input. Turning it into a running process should take an explicit yes.

Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

CISA Adds Exploited PTC Windchill RCE Flaw to KEV as Web Shell Attacks Continue

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Thursday added a critical remote code execution vulnerability impacting PTC Windchill PDMlink and PTC FlexPLM enterprise Product Data Management (PDM) and Product Lifecycle Management (PLM) software to its Known Exploited Vulnerabilities ( KEV ) catalog, citing evidence of active exploitation. The vulnerability in question is CVE-2026-12569 (CVSS score: 9.3), a case of improper input validation that could allow an attacker to execute arbitrary code by sending a malicious request to the network. “The vulnerability is a remote code execution (RCE) issue that may be exploited through deserialization of untrusted data,” according to an advisory released by PTC.

Although patches for the flaw were released last week, PTC has since confirmed, as of June 25, that “we’ve received continued reports of heightened threat activity,” with the company disclosing that unknown attackers are exploiting the vulnerability to deploy JSP web shells against susceptible systems. PTC has also released the following indicators of compromise (IoCs) associated with the activity - 172.111.38.31 216.152.148.54 104.243.35.131 74.50.76.146 5.180.41.35 216.152.148.54 5.180.41.35 (Attacker command-and-control address) Web shell files following the naming pattern /Windchill/login/[0-9a-f]{16}.jsp As mitigations, users are advised to perform the following actions - Block 5.180.41.35 at the perimeter firewall immediately Search HTTP access logs for any POST requests to /Windchill/login/*.jsp Scan the filesystem for JSP files matching the 16-hex-char pattern /Windchill/login/[0-9a-f]{16}.jsp Hash-check any suspicious JSP files against 55a1eb4c2d3da04376df39d7ba832569c6af1a37a0cf2b95f754ac898023a30c Check for flst.txt in /tmp or the Windchill working directory, the presence of which confirms attacker file-listing activity Add WAF / IDS rule blocking any request containing the header X-windchill-req: Restrict internet exposure of the Windchill login endpoint where operationally possible The development makes it the first-ever PTC product vulnerability added to CISA’s KEV catalog, not to mention highlighting how threat actors are rapidly weaponizing newly disclosed vulnerabilities to their advantage. Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

New DirtyClone Linux Kernel Flaw Lets Local Users Gain Root via Cloned Packets

DirtyClone is a new Linux kernel privilege escalation in the DirtyFrag family. JFrog Security Research published a working exploit walkthrough for the flaw on June 25, the first public demonstration for this variant. Tracked as CVE-2026-43503 (CVSS 8.8), it lets a local user corrupt file-backed memory through a cloned network packet and gain root. The patch landed in mainline on May 21; if your kernel does not have it, update now.

When the kernel copies a network packet internally, two helper functions drop a safety flag that marks the packet’s memory as shared with a file on disk. That missing flag is the entire vulnerability. The attacker loads a privileged binary like /usr/bin/su into memory, wires those memory pages into a network packet, and forces the kernel to clone it. The cloned packet passes through an IPsec tunnel that the attacker controls, and the decryption step overwrites the binary’s login checks with attacker-chosen bytes.

The next time anyone runs su, it hands over root. The file on disk never changes. The modification lives only in the kernel’s in-memory copy, so file-integrity tools miss it, the attack leaves no audit trail, and a reboot restores the original binary. The attacker already has root by the time anyone might think to check.

Exploitation requires CAP_NET_ADMIN to configure the loopback IPsec tunnel. On Debian and Fedora, unprivileged user namespaces are enabled by default, so a local user can obtain that capability inside a new namespace. Ubuntu 24.04 and later restrict namespace creation via AppArmor, blocking the default exploit path. Page cache is shared at the host level, so modifications made inside a namespace affect every process on the machine.

The exposed systems are multi-tenant servers, CI runners, container hosts, and Kubernetes clusters where untrusted users can create namespaces. JFrog confirmed the exploit on Debian, Ubuntu, and Fedora systems with default namespace configurations. Fourth in a Series This is the fourth recent privilege escalation with the same failure mode: file-backed memory gets treated as packet data, then an in-place network operation writes where it should have copied. Copy Fail (CVE-2026-31431) came first in late April, exploiting the algif_aead module for a four-byte page-cache write.

DirtyFrag (CVE-2026-43284 and CVE-2026-43500) followed on May 7, chaining IPsec ESP and RxRPC paths for a full write primitive. Fragnesia (CVE-2026-46300) appeared on May 13, bypassing the DirtyFrag patch through a flag-dropping bug in skb_try_coalesce(). Each fix closed one code path and left others open. DirtyClone’s demonstrated exploit centers on __pskb_copy_fclone(), with skb_shift() also affected; the broader CVE fix covers additional frag-transfer helpers where the same flag could be lost.

The underlying problem is not one bad helper function. It is a contract problem: every code path that moves skb fragments has to preserve the shared-frag bit, every time. The kernel’s zero-copy networking lets file-backed memory serve as packet data, and a single dropped flag anywhere in the chain turns a performance optimization into a write primitive. Each variant found a path where the contract was not honored.

The original DirtyFrag researcher, Hyunwoo Kim, had submitted a broader multi-site patch covering several remaining frag-transfer helpers on May 16. The combined fix was merged on May 21 (commit 48f6a5356a33), assigned CVE-2026-43503 on May 23, and shipped in Linux v7.1-rc5 on May 24. What to Do Install your distribution’s kernel update. The fix landed upstream in v7.1-rc5 and has been backported to stable and LTS branches.

Ubuntu , Debian , and SUSE have published advisories; Red Hat has a Bugzilla tracking entry . If you cannot patch today, two workarounds reduce the attack surface. Restrict unprivileged user namespaces: on Debian and Ubuntu, set kernel.unprivileged_userns_clone=0 (other distributions use different mechanisms). Alternatively, blacklist the esp4, esp6, and rxrpc kernel modules, though that breaks IPsec and AFS and only works when those features are loadable modules rather than compiled into the kernel.

Both are temporary controls, not fixes. The DirtyFrag class is probably not done. Any function that moves fragment descriptors without propagating the shared-frag flag is a potential new CVE, and auditing should cover every path that touches skb_shinfo()->flags during fragment transfer. Found this article interesting?

Guardian Agents: The Next Layer of Identity Governance

AI agents are moving through enterprise environments, inheriting permissions, traversing systems, and executing decisions at machine speed with minimal oversight. The identity infrastructure built to govern human access wasn’t designed for autonomous actors, and the gap between what enterprises are deploying and what their governance programs actually cover is widening fast. This guide breaks down how the guardian agents emerged, why it matters, and what operationalizing it looks like in practice. The Governance Gap Agentic AI Created Identity governance has always lagged behind infrastructure change, but the arrival of production-grade agentic AI didn’t just widen the gap.

It changed its shape entirely. The assumptions baked into every IAM architecture built over the past two decades are no longer sufficient for the environment most enterprises are actually running today. Agents Aren’t Service Accounts Security teams have spent years getting reasonably good at governing non-human identities. Service accounts get provisioned, rotated, and scoped.

API keys get vaulted. Machine identities get enrolled in PAM workflows. The controls aren’t perfect, but the mental model is coherent: a non-human identity performs a defined function against a known set of resources, and you govern it by constraining what it can reach. AI agents break every part of that model.

An agent doesn’t execute a fixed function. It receives an instruction, reasons about how to accomplish it, dynamically selects tools, chains calls across multiple systems, and delegates sub-tasks to other agents, all within a single session. The permission footprint of a single agent invocation can span a CRM, a code repository, a document store, and an internal API, touching resources that no human explicitly authorized the agent to access. The Permission Inheritance Problem The deepest architectural problem isn’t that agents carry too much access.

It’s that they inherit access from the human or service identity they operate on behalf of, and that inherited access was scoped for an entirely different context. When an agent executes on behalf of a sales director, it carries that person’s OAuth tokens, their delegated permissions, and any overprivileged access accumulated over years of role changes. The agent doesn’t distinguish between what the human would have done and what it’s been instructed to do. It executes with full inherited authority across every application that identity can reach.

Traditional IAM governance was built around authentication events. A human presents credentials, the system validates them, and access is granted or denied at login. Agents don’t follow that sequence. They authenticate once, often via a long-lived token or API credential, and then operate continuously across sessions, systems, and contexts without an intervening governance checkpoint.

An Architectural Problem, Not a Configuration One IAM tools weren’t designed to observe what happens after authentication. They record the login event and stop. The entire sequence of tool calls, permission uses, data accesses, and cross-system traversals an agent performs inside a session remains invisible to the governance layer. Agents find existing identity dark matter and move through it at machine speed.

Stale delegations and over-scoped credentials that IAM teams have long deprioritized become an active attack surface the moment an agent touches them. Governing that requires a layer purpose-built to operate where identity actually executes, not just where it authenticates. Why Adoption Is Accelerating Now The speed of agentic AI deployment inside enterprise environments has less to do with hype and more to do with three converging forces: models that now reliably complete multi-step reasoning tasks, infrastructure that makes orchestrating those models straightforward, and business pressure to automate knowledge work at a scale that headcount alone can’t support. The Infrastructure Maturity Inflection Point Twelve months ago, deploying a reliable multi-agent workflow required significant custom engineering.

Today, frameworks like LangGraph, AutoGen, and Anthropic’s Model Context Protocol provide development teams with standardized primitives for agent orchestration, tool calling, memory management, and inter-agent communication. The cost of inference has dropped sharply across all major model providers, making it economically viable to run agents continuously rather than on demand. Together, these shifts moved agentic AI from proof of concept to production pipelines on timelines most security organizations didn’t anticipate. Enterprise adoption reflects that shift.

Agents now handle procurement workflows, customer support escalations, code reviews, financial reconciliations, and internal knowledge retrieval across organizations of all sizes. Line-of-business teams deploy them via low-code platforms and vendor-supplied integrations, often without any security review during provisioning. Security Teams Are the Last to Know The deployment pattern for agentic AI consistently repeats itself: engineering or operations teams identify a workflow to automate, a vendor provides an agent-enabled feature or API, and the agent goes live. Security teams discover it later, sometimes during an incident review, sometimes during an audit, sometimes not at all.

The 2026 market guide on guardian agents documents exactly this pattern across enterprise deployments. Governance readiness consistently lags deployment timelines, not because security teams are inattentive but because the provisioning motion for agents bypasses the identity lifecycle entirely. Agents don’t go through access request workflows. They don’t get onboarded into IGA systems.

They inherit credentials from existing identities and start executing. The result is an expanding population of autonomous identities operating across enterprise systems with no formal governance record, no ownership mapping, and no behavioral baseline. The agents are running. The question is whether anyone knows what they’re doing.

What Guardian Agents Are A guardian agent is a purpose-built autonomous control layer that governs the identity and behavior of AI agents operating inside enterprise environments. Where traditional IAM tools govern human access and static machine identities, a guardian agent for AI operates at the execution layer, observing, analyzing, and enforcing policy against autonomous systems that act, reason, and move across applications in real time. The term has moved from conceptual to operational. Enterprises running production agentic workloads now require a dedicated governance mechanism that keeps pace with agent activity, not one that audits it quarterly.

Continuous Identity Inventory The first function of a digital guardian agent is discovery. Every AI agent operating in an environment carries an identity, inherits permissions, and leaves an access trail, but most enterprises lack a systematic way to enumerate which agents are running, which identities they’re acting on behalf of, or which applications they’ve touched. A guardian agent for AI maintains a continuous, live inventory of every autonomous entity in the environment. It maps each agent to its originating identity, its owner, its permission scope, and the applications it interacts with.

When a new agent spins up, provisioned through a vendor integration or deployed by a development team, the guardian agent registers it immediately rather than waiting for a manual review cycle that may never happen. Behavioral Baselining and Anomaly Detection Inventory alone doesn’t constitute governance. A guardian AI agent builds a behavioral baseline for each autonomous identity it monitors, tracking the pattern of tool calls, data accesses, API interactions, and cross-system movements an agent makes during normal operation. Deviation from that baseline is where risk surfaces.

An agent that begins accessing file stores outside its typical scope, calling APIs it has never used before, or escalating through a chain of delegated permissions signals a potential compromise, a prompt injection attack, or a misconfigured policy that has expanded its reach beyond its intended scope. The guardian AI agent surfaces these deviations in real time, with enough context to distinguish a legitimate workflow change from a genuine anomaly. Runtime Policy Enforcement and Permission Scoping Detection without enforcement is monitoring. A digital guardian agent applies a least-privilege policy at runtime, constraining what it can access during a given session based on the context of its current task, rather than the full scope of permissions its inherited identity technically allows.

Runtime scoping is the technical capability that separates guardian agents from conventional identity tooling. Rather than relying on pre-provisioned roles defined before anyone knew an agent would use them, a guardian agent for AI evaluates the current execution context and enforces permissions accordingly, dynamically tightening access as the agent moves through its workflow. A Distinct Category from AI Security Posture Tools A guardian AI agent is not an AI-SPM tool. AI security posture management focuses on the configuration and risk posture of AI infrastructure: model access controls, training data exposure, and API security.

A guardian agent operates one layer down, governing the identity execution behavior of agents themselves, tracking what they do with the access they have, and enforcing boundaries at the moment of action rather than at the point of configuration. How Guardian Agents Differ from Traditional IAM Tools The instinct to govern AI agents using existing IAM tooling is understandable, and it’s wrong. Not because those tools are poorly built, but because they were engineered against a fundamentally different model of what an identity is and how it behaves. Mapping that tooling onto agentic workloads creates dangerous blind spots rather than adequate coverage.

What IGA Was Built to Do Identity governance and administration platforms were designed to manage the lifecycle of human identities: joiner, mover, and leaver workflows, access certifications, role mining, and separation-of-duties enforcement. They work well when identities are enumerable, when access requests follow defined workflows, and when the relationship between a user and their permissions changes on a human timescale. AI agents violate every one of those assumptions. An agent’s identity isn’t provisioned through a request workflow.

Its permission scope shifts dynamically within a session. Its lifecycle doesn’t map to employment status. IGA platforms have no native concept of an agent that inherits a human identity, operates autonomously for the duration of a task, and then becomes dormant, only to reactivate under a different context with different inherited permissions the next time it runs. Access certification campaigns can’t capture what a guardian agent for AI continuously tracks: the actual runtime behavior of an autonomous identity as it moves across systems.

Where PAM Falls Short Privileged access management tools address a different problem. PAM assumes that high-risk access is bounded, that a human operator checks out credentials for a session, performs a defined task, and returns the credentials. The session is recorded, the access is time-limited, and the human is accountable. Agents don’t check out credentials.

They operate through inherited OAuth delegations, service account bindings, or API keys embedded in orchestration configurations. A PAM tool sees none of that. It governs the vault, not the execution path the agent takes once it’s operating with credentials obtained entirely outside the PAM workflow. When an agent traverses four systems in a single session using a delegated OAuth token, PAM has no visibility into any part of that traversal.

A digital guardian agent does. The CIEM Boundary Problem Cloud infrastructure entitlement management tools brought meaningful progress on the non-human identity problem, particularly for cloud service principals, IAM roles, and workload identities operating within a single cloud environment. The limitation is the boundary itself. Agentic workloads routinely span multiple clouds, SaaS applications, self-hosted systems, and third-party API integrations within a single workflow.

CIEM tools govern entitlements within their supported platforms. They don’t follow an agent as it moves from an AWS service role to a SaaS CRM to an internal document management system, accumulating effective permissions across each hop. A guardian AI agent operates across that entire surface, maintaining a unified view of what each autonomous identity can access and what it actually did, regardless of which platform boundary it crossed. The Core Architectural Difference Traditional IAM tools answer identity questions at provisioning time or at the authentication boundary.

A guardian agent for AI answers them at execution time, inside the session, at the application layer, where permissions are actually exercised. The difference isn’t incremental. Governing an autonomous identity that reasons, delegates, and acts requires a control plane that reasons alongside it, observing behavior in motion rather than auditing access after the fact. Common Risks: How Unmanaged Agents Become Identity Dark Matter Unmanaged AI agents don’t announce themselves as a security problem.

They accumulate as one. Each agent that deploys without a governance record, inherits permissions without review, and operates without behavioral oversight adds to a growing population of autonomous identities that security teams can’t see, audit, or control. Orchid Security calls this identity dark matter: the mass of identity activity that exists and exerts real risk inside an environment while remaining invisible to the tools responsible for governing it. Over-Privileged Agent Identities The most pervasive risk pattern starts at provisioning.

When an agent deploys by binding to an existing service account or human identity, it inherits the full permission scope of that identity, regardless of what the agent actually needs. A code review agent bound to a senior engineer’s identity might inherit access to production infrastructure, financial systems, and HR data accumulated over years of role changes. The agent needs none of it, but carries all of it into every session it runs. Over-privileged agent identities are the rule in unmanaged deployments.

Because agents bypass access-request workflows, no one applies least-privilege scoping at provisioning time. The permissions are already there, and binding an agent to an existing identity is the path of least resistance. Orphaned Sessions and Stale Credentials Agent sessions don’t always terminate cleanly. Long-running agents and scheduled automation tasks can maintain active credentials well beyond the duration of the task they were created for.

When an agent is decommissioned or simply forgotten, the credentials it used often remain valid. Stale agent credentials are particularly dangerous in SaaS environments where token revocation requires deliberate action against each connected application. An orphaned agent operating through a long-lived OAuth token can retain access to sensitive systems for months after anyone last intentionally invoked it. Prompt Injection as a Privilege Escalation Vector Prompt injection attacks target agents directly.

An attacker embeds malicious instructions in content the agent processes: a document it summarizes, a web page it retrieves, a ticket it reads. The agent incorporates those instructions into its reasoning and takes actions that the legitimate user never authorized. In environments where agents operate with overprivileged inherited identities, prompt injection becomes a reliable path to privilege escalation without touching credentials at all. Lateral Movement Through Chained Agent Calls Multi-agent architectures introduce compounding risk.

When an orchestrator agent delegates sub-tasks to specialized child agents, each delegation transfers a portion of the orchestrator’s authority. A compromise at any point in that chain propagates downstream, giving an attacker effective access to every system the trust chain touches. The audit trail problem makes all of this harder to contain. Agents operating across unmanaged SaaS applications leave no coherent forensic record in existing security tooling.

When an incident occurs, security teams reconstruct what happened from fragmented logs across disconnected systems, often without enough fidelity to determine which agent took which action on whose behalf. Putting this into your identity governance program requires treating agent identities with the same rigor applied to privileged human accounts: continuous inventory, ownership mapping, behavioral monitoring, and a full audit record across every application each autonomous identity touches. How to Bring AI Agents into the Light Getting AI agents under governance control is an operational capability that security and identity teams need to continually build as agent deployments continue to grow. The following sequence reflects how mature organizations are approaching it, moving from visibility to classification to enforcement to integration.

Start with Discovery: Know What’s Running Governance starts with an accurate inventory, and most enterprises don’t have one. The first operational step is deploying discovery mechanisms that identify every AI agent active in the environment, regardless of how it was provisioned or which team deployed it. Effective discovery operates at the application layer.

Network-level monitoring captures traffic patterns but can’t attribute them to specific agent identities or map them to the human identities those agents act on behalf of. Application-layer discovery surfaces the agent, its credential bindings, its permission inheritance, and its operational context, all the information needed to make a governance decision. 2. Classify by Trust Level and Permission Scope Not every agent carries the same risk.

Once an inventory exists, classify each agent by the sensitivity of the permissions it holds, the systems it can reach, and the trust level of its originating identity. An agent operating with read-only access to a single internal knowledge base carries a fundamentally different risk profile than one holding delegated OAuth tokens to a financial system and a customer data platform simultaneously. Classification drives prioritization. Agents with broad permission inheritance and connections to sensitive systems warrant immediate least-privilege remediation.

Agents with narrow, well-scoped access warrant monitoring and periodic review. Without classification, every agent looks the same, and remediation effort is distributed without regard to the actual concentration of risk. 3. Enforce Least-Privilege at Runtime, Not at Provisioning Static scoping at provisioning time degrades quickly.

As agents are reused for new tasks, their permissions drift, and the inherited credentials they carry rarely get updated to reflect actual requirements. Runtime enforcement through a guardian agent for AI dynamically applies least privilege, constraining what each agent can access based on the context of its current task rather than on the broadest permissions its identity technically allows. Runtime enforcement also contains the blast radius of a compromise. A prompt injection attack against an agent operating under tight runtime scoping reaches far less than the same attack against an agent running with its full inherited permissions active.

Integrate with Existing IAM and IGA Stacks A guardian AI agent doesn’t replace the IAM infrastructure already in place. It extends it. Agent identity data feeds into IGA platforms to enable access certification, into PAM tools to flag credential exposure, and into SIEM systems to enrich alert context with agent behavioral history.

The integration layer transforms agent governance from a standalone capability into a live input to the broader identity security platform , giving every downstream tool more accurate information about what’s actually executing in the environment. How Orchid Security Helps The governance gap described throughout this guide is what Orchid Security is built to close. The platform operates as a continuous identity control plane across human, machine, and agentic identities, providing security and identity teams with the visibility and enforcement capabilities that existing IAM tooling doesn’t provide. Continuous Discovery Across Every Identity Type Orchid’s discovery engine automatically inventories every application, account, and authentication flow in an environment, managed or otherwise.

When AI agents spin up, whether through vendor integrations, internal deployments, or low-code automation platforms, Orchid surfaces them, maps them to their originating identities, and enriches them with ownership, permission scope, and business context. Security teams get an accurate, continuously updated picture of what’s running rather than a static snapshot that degrades the moment it’s produced. From Visibility to Enforcement The guardrails for the autonomous identity use case apply Orchid’s identity control plane directly to agentic workloads. Every agent gets mapped to an accountable human owner.

Runtime guardrails enforce least-privilege at the execution layer. Behavioral observability tracks what agents actually do across tool calls, data accesses, and cross-system movements, surfacing anomalies before they become incidents. Orchid also integrates with existing IAM programs and GRC workflows, feeding continuous agent identity telemetry into the tools already governing the rest of the environment. For teams building out their identity governance program, that telemetry becomes the connective tissue between agent activity and enterprise-wide identity policy.

The result is an identity infrastructure that governs the autonomous workforce with the same rigor it applies to human identities, at the speed agents actually operate. Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Miasma Malware Targets npm Packages and GitHub Actions in Supply Chain Attack

Cybersecurity researchers have flagged yet another evolution of the supply chain attack linked to the Mini Shai-Hulud, Miasma, and Hades malware family that has compromised a new set of npm packages, even as it has propagated to the Go ecosystem. “The latest activity includes malicious npm releases affecting LeoPlatform and RStreams packages, GitHub Actions workflow abuse, and a related Go module compromise involving the Verana Blockchain project,” Socket said . The end goal of the campaign, as before, is to harvest developer or maintainer credentials and weaponize the stolen data to spread across package registries, repositories, and trusted developer workflows. The list of affected packages is below - hexo-deployer-wrangler@1.0.4 hexo-shoka-swiper@0.1.10 leo-auth@4.0.6 leo-aws@2.0.4 leo-cache@1.0.2 leo-cdk-lib@0.0.2 leo-cli@3.0.3 leo-config@1.1.1 leo-connector-elasticsearch@2.0.6 leo-connector-mongo@3.0.8 leo-connector-mysql@3.0.3 leo-connector-oracle@2.0.1 leo-connector-redshift@3.0.6 leo-cron@2.0.2 leo-logger@1.0.8 leo-sdk@6.0.19 leo-streams@2.0.1 prism-silq@1.0.1 rstreams-metrics@2.0.2 rstreams-shard-util@1.0.1 serverless-convention@2.0.4 serverless-leo@3.0.14 solo-nav@1.0.1 github.com/verana-labs/verana-blockchain@v0.10.1-dev.20 (Go) It’s suspected that an npm developer account associated with the LeoPlatform (“ czirker “) was breached, likely via leaked credentials, to enable the attack, allowing the threat actors to leverage an npm token belonging to the maintainer to push trojanized versions within a six-second window.

The new wave leverages many of the tactics observed in prior campaigns, including npm registry poisoning, binding.gyp install-time execution, Bun-staged JavaScript malware, GitHub dead-drop infrastructure, GitHub Actions secret theft, IDE and AI coding assistant persistence, and encrypted credential exfiltration. The malicious npm packages, while lacking a lifecycle hook typically added to the package.json file, incorporates a binding.gyp file to execute arbitrary code during installation, resulting in the launch of a JavaScript loader that downloads and installs the Bun runtime if not present, and then initiate the stealer payload responsible for harvesting secrets, credentials, and tokens. The malware , besides featuring a Russian locale killswitch and checking for the presence of endpoint security software, drops a workflow named “Run Copilot” to capture CI/CD environment secrets from the runner memory. The information is then uploaded to a public GitHub repository with description “Alright Lets See If This Works.” As of writing, there are 559 repositories matching the description.

The token relay marker has also witnessed a change in the latest iteration. While earlier waves used strings like “IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner,” the current artifact uses “RevokeAndItGoesKaboom,” a string that has been used as GitHub dead drop resolver in connection with the recent compromise of the “codfish/semantic-release-action” GitHub Action. “On June 24, 2026 at 15:39:06 UTC, an attacker force-pushed a malicious commit to codfish/semantic-release-action and redirected several version tags to point at the malicious commit,” StepSecurity said . “Any workflow that ran against one of these tags after that timestamp executed the attacker’s payload directly inside the GitHub Actions runner.

The payload steals GitHub OIDC tokens, harvests Personal Access Tokens matching known GitHub token patterns, encrypts the collected material with AES-128-GCM, and attempts to propagate a backdoor into other repositories accessible with the stolen credentials.” This indicates that all these events are linked to the same operational cluster or tooling lineage. According to Endor Labs and OX Security , the malware also polls GitHub every hour for commits matching the string “ firedalazer “ to retrieve and execute the Hades variant of the malware. “The Leo/RStreams package set is tied to cloud-native and serverless workloads,” JFrog said. “A compromise here can expose developer workstations, CI/CD systems, AWS-backed applications, GitHub repositories, package publishing credentials, and downstream package consumers.” “The notable story is not that the payload is radically new.

It is that Shai-Hulud continues to move across legitimate package ecosystems while changing just enough indicators to make stale detections less effective.” What’s more, the poisoning of the Verana GitHub expands the scope of the campaign beyond npm. That having said, the attack employs the same Miasma execution pattern observed in malicious npm packages without relying on native Go module resolution or build logic. “Unlike the npm packages, this sample does not rely on binding.gyp,” Socket explained. “The risk is source-repository execution: a developer who clones or opens the repository in a trusted IDE or AI coding assistant environment may trigger the payload through project configuration.” “This reinforces the larger campaign theme: Miasma is moving across package ecosystems by targeting developer workflows, not just package-manager install hooks.” Found this article interesting?

Microsoft Warns of Photo ZIP Phishing Campaign Targeting Hotels with Node.js Implant

An active phishing campaign has been targeting hotel and other hospitality organizations across Europe and Asia since April 2026, using photo-themed ZIP files to drop a Node.js implant and dig into front-desk machines, Microsoft says. The company has not attributed the activity to a known threat actor, and the operators’ end goal is still unclear. The lure plays to how hotels work. Phishing emails carry the display name “Booking Manager (via Calendly)” and reference guest complaints, bedbug infestations, room inquiries, health inspections, and stay reviews.

The lures came in Japanese, Danish, and Dutch, with Japanese the most common. The subject line names no recipient or property, which points to high-volume, list-driven sending rather than tailored spear phishing. The pressure is reputational: complaints, final warnings, threatened inspections. The delivery is the interesting part.

The operators route messages through Calendly’s email notification system and Google’s URL redirect service, a trick Microsoft calls authentication laundering . Emails sent through the direct Calendly path pass SPF, DKIM, and DMARC, because they really are sent from authorized infrastructure. The checks confirm the sender is allowed to send. They say nothing about what the message is for.

A multi-hop chain then walks the victim from a Calendly link through share.google and a Google redirect to a freshly registered, Cloudflare-fronted .cfd domain. That domain sits behind a Turnstile challenge that doubles as anti-analysis. Click through, and the target downloads a file named photo-.zip. Inside is a shortcut posing as an image: IMG-.png.lnk in the first wave, PHOTO-.png.lnk in the second.

Opening it fires PowerShell. The script uses BigInt arithmetic to decode a hidden download URL, pulls a .ps1 to %TEMP%, and drops a legitimate Node.js v24.13.0 runtime from nodejs.org into user space, which then runs the JavaScript implant. No system-wide Node install is needed. The implant is tracked as TonRAT .

It resolves its C2 domains through the TON blockchain API, then opens an encrypted WebSocket channel, per SOC Prime . Fetching domains on the fly makes static blocklists less useful. After the compromise, the implant beaconed to fixed IPs over non-standard ports: 8443, 8445, 8453, 5555, and 56001 to 56003. Some hosts also showed headless browser automation (–headless –no-sandbox), an ip-api.com geolocation check, and a forced shutdown via cmd /c shutdown -s -t 0.

Microsoft has not reported confirmed data theft, ransomware, or named victims. Full remediation has to hit both persistence paths: the RunOnce entry pointing into ProgramData and the Node.js Run key, plus the runtime and .js files under AppData\Local\Nodejs. Pulling one leaves the other alive. Reception, reservations, and front office systems are the first places to look.

The campaign is not brand new. SOC Prime and ITOCHU documented the same hotel phishing and the LNK-to-PowerShell-to-Node.js chain about two weeks earlier, and Microsoft says its findings line up with that reporting. Booking-themed phishing aimed at hotel staff has been a recurring pattern, including ClickFix campaigns that dropped PureRAT to steal Booking.com logins. What none of the reports can answer yet is what these operators want.

The access is durable, the cleanup is easy to get wrong, and the final payload has not been pinned down. That is enough to treat this as more than another booking-themed phish. Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Russia Used Cellebrite on Jailed Activist’s iPhone Months After Sales Cutoff

Russian authorities used Cellebrite’s UFED forensic tools to break into the iPhone of detained opposition activist Andrey Pivovarov in June 2021, three months after Cellebrite said it would stop selling its tools and services to Russia and Belarus. The finding, published June 25 by the Citizen Lab , rests on two things that rarely line up: traces on the phone itself and an official Russian government report that names the tool. Investigators searched the extracted data for political contacts, opposition figures, and the names of activist organizations. This was not remote spyware.

It was a forensic tool run on a seized device in custody, used to build a case in a political prosecution. Pivovarov ran Open Russia , an opposition group the Kremlin had branded “undesirable,” a label that turned continued involvement into a criminal offense. He was pulled off a flight at St. Petersburg airport on May 31, 2021, and his iPhone 12 and MacBook were confiscated.

He never gave consent to a search and never handed over his passwords. The devices stayed in custody until 2023. In July 2022, he was sentenced to four years; he was freed in August 2024 in a prisoner exchange . Pivovarov gave the phone to Citizen Lab researchers in the fall of 2025.

The traces on it dated to 2021, when the device was in Russian custody. MobileLockdown records, which track an iPhone’s trusted USB pairings, showed a connection on June 17, 2021, to a host ID matching a Cellebrite fingerprint the researchers had identified in a prior case in Jordan. They rate it high-confidence evidence that Cellebrite’s UFED was used. Russia’s own paperwork backs the forensic read.

Pivovarov received a report titled “Forensic Expert Report No. 1269-17” in the course of his prosecution, prepared for Russia’s Investigative Committee by the Interior Ministry’s forensic center, and he gave a copy to the Citizen Lab. It names Cellebrite’s UFED Physical Analyzer and UFED 4PC by product. It documents pulling data from WhatsApp, Telegram, and Viber, and shows investigators running searches for “Open Russia Civic Movement” and for named opposition figures, including Mikhail Khodorkovsky, lawyer Anastasiya Burakova, and Pivovarov’s partner Tatiana Usmanova.

The MacBook held. The MVD report describes a failed extraction, blocked by encryption, and the Citizen Lab found matching failed login attempts on the same date, indicating the authorities never had Pivovarov’s password. The timing is the point. Cellebrite announced in March 2021 that it would stop selling to Russia and Belarus, a move that cut off updates but left existing hardware running.

Much of UFED keeps working offline long after support ends, the Citizen Lab says, which is the hole in the cutoff: the risk was never only future sales, it was the installed base already sitting in police and intelligence offices. That matches earlier reporting that Russia kept using Cellebrite on detainees’ phones after the announcement. Asked for comment on June 22, Cellebrite told the Citizen Lab and Access Now that any use of its legacy hardware in Russia after March 2021 is “entirely unauthorized.” It said that hardware runs without its support or consent and that, today, it would be incompatible with modern devices. Russia stays permanently on its restricted-customer list, the company said, and it is shifting to subscription licenses that stop working when they expire.

The distinction matters more legally than operationally: the tool still worked when Russian investigators had the phone in 2021. One overlap is worth watching: the people whose names were searched on Pivovarov’s phone later surfaced as targets of COLDRIVER , an FSB-linked phishing operation, and Burakova was targeted but did not bite. The Citizen Lab does not claim a direct link, but the mechanism is plain: extract one activist’s social graph, and you have the target list for the next campaign. Citizen Lab’s advice for anyone at risk of seizure is blunt, and none of it is foolproof against a forensic tool.

Use a strong alphanumeric passcode. Keep the OS current. Turn on Lockdown Mode on iPhones, or Advanced Protection on Android 16 and up. Encrypt the disk on computers.

Power the device fully off before walking into a high-risk situation. If a seized device comes back, change every account password and have it examined before wiping it. Russia joins Serbia , Kenya , and Jordan in a growing list of Cellebrite abuse cases backed by forensics. The sharper lesson is narrower: a sales cutoff that leaves old, offline-capable tools running is not much of a cutoff once the phone is already in a custody room.

Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Google Details Turla’s New STOCKSTAY Backdoor Used in Ukraine Espionage Attacks

The Russian state-sponsored threat actor known as Turla has been attributed to a previously undocumented .NET backdoor called STOCKSTAY that has been deployed against government and military organizations in Ukraine, and entities that have an interest in Italian foreign policy. Describing the Windows backdoor as continually developed by the hacking group, Google Threat Intelligence Group (GTIG) said the cyber espionage tool shares significant code and functional overlaps with Kazuar , a staple implant put to use by the adversary since 2017. Suspected development activity of malware dates back to December 2022. “STOCKSTAY is a multi-component backdoor written in .NET, using the Windows Forms framework, which communicates with its command-and-control (C2) via a secure WebSocket connection, utilizing the open-source websocket-sharp library,” GTIG said .

“STOCKSTAY consists of several distinct components that communicate with one another via an inter-process communication (IPC) channel, based on the exchange of WM_COPYDATA messages.” Evidence indicates that the implant was originally designed to mimic a stock market data viewing tool, before being adapted to masquerade as other harmless programs like PDF viewers and calculator utilities. The starting point is a downloader component codenamed STOCKSTAY.MARKETMAKER that installs and executes three additional modules - STOCKSTAY.STOCKBROKER , a proxy-aware tunneler that facilitates network communication capabilities to the wider STOCKSTAY suite by establishing a secure WebSocket connection to a specified remote server. STOCKSTAY.STOCKTRADER , the main backdoor that enables information gathering. STOCKSTAY.STOCKMARKET , an orchestrator or controller that parses the backdoor’s configuration to set several options regarding the malware’s execution, such as the WebSocket server, time interval, and the days it’s not supposed to work.

It also communicates with STOCKSTAY.STOCKBROKER to provide the server details and receive messages via the established WebSocket connection, as well as STOCKSTAY.STOCKTRADER to issue commands to be run on the compromised host. STOCKSTAY malware architecture Some of the support commands of STOCKSTAY.STOCKTRADER is listed below - Del, to delete the specified files Dir, to enumerate the specified directories Get, to fetch one or more specified files matching certain extensions MkDir, to make one or more directories RmDir, to delete the specified directories Image, to perform a screen capture of the device’s screen MultyTask, to run a semi-colon-separated list of tasks at once Put, to upload a file to the device RegRead, to read a Windows Registry value RegDelete, to delete a Windows Registry value RegWrite, to set a Windows Registry value Run, to execute a new process Sysinfo, to gather system information UnpackArchive, to extract the specified ZIP file to its current directory Google said it identified a publicly accessible GitHub repository (“ ChikenFresh/google-ai-labs-it “) containing a Python implementation of the victim-facing STOCKSTAY WebSocket server controller that’s responsible for handling inbound messages from a connected client and logging its IP address. “The inability for the server to decrypt inbound messages prevents introspection by platform operators, and further obfuscates the location of the threat actor’s dedicated infrastructure,” GTIG noted. “This architecture somewhat resembles Turla’s multi-hop Kazuar C2 infrastructure.” Attacks distributing STOCKSTAY have consistently leveraged academic- or diplomatic-themed lures to target government and military organizations within Ukraine, with early versions of the backdoor used in attacks aimed at entities in Italy, the Netherlands, Poland, and Germany.

That said, it’s unknown which European entities were singled out in these attacks. Timeline of STOCKSTAY observations In at least one instance observed in early 2025, the Turla actors are said to have employed a phishing email containing a malicious RDP file attachment that, when opened, sets up a connection between the victim’s device and actor-controlled infrastructure, through which additional payloads, including STOCKSTAY, can be deployed. As recently as November 2025, an email phishing wave targeting Ukraine was found to deliver the implant via RAR archives that exploit CVE-2025-8088, a WinRAR vulnerability that has been exploited by a number of Russian hacking groups such as Sandworm, Gamaredon , and RomCom . Other campaigns have leveraged MSI installers (in one case hosted on GitHub) and RAR files containing an HTML Application (HTA) script, the latter of which is designed to execute a variant of STOCKSTAY.MARKETMAKER.

The downloader then retrieves a ZIP archive containing the main STOCKSTAY components that’s hosted on a compromised WordPress instance. One noteworthy aspect of the malware is that it has been employed by Turla at multiple distinct stages of their operations, one as a way to obtain initial access into environments that haven’t been profiled previously and during post-exploitation following reconnaissance for execution on a specific host. “This configuration implies that, at this stage, the actor knows exactly which machine is being targeted, likely through existing accesses to the target environment,” GTIG explained. This was seen within Ukrainian networks where STOCKSTAY was deployed toward the end of an operation which had previously relied heavily on the group’s other tools, such as Kazuar.” STOCKSTAY’s overlaps with Kazuar stem from the similarities in how the responsibilities are delineated among different components.

Kazuar’s use of Kernel, Bridge, and Worker modules within Kazuar was extensively detailed by the Microsoft Threat Intelligence team last month. The separation of distinct role-based components in STOCKSTAY was first detected in a sample uploaded to VirusTotal in December 2023 from the Netherlands. These commonalities have raised the possibility that both STOCKSTAY and Kazuar may have been developed and maintained in-part by the same developer or team. “We believe that STOCKSTAY is being developed in KAZUAR’s image, with several design decisions likely spawning from the threat actor’s wealth of experience in conducting operations using this long-standing toolkit,” Google said.

“Both ecosystems rely heavily on .NET development, and have been observed using compromised WordPress sites during various stages of their operations.” “We assess with low confidence that our observations of STOCKSTAY being deployed alongside KAZUAR during active operations may be a result of the threat actor seeking to test new capabilities in active operations, particularly where they may be expecting their existing access to be remediated in the near future.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.