Author: anonymousmedia_tal70o

Ravie LakshmananMar 24, 2026Endpoint Security / Social Engineering

A large-scale malvertising campaign active since January 2026 has been observed targeting U.S.-based individuals searching for tax-related documents to serve rogue installers for ConnectWise ScreenConnect that drop a tool named HwAudKiller to blind security programs using the bring your own vulnerable driver (BYOVD) technique.

“The campaign abuses Google Ads to serve rogue ScreenConnect (ConnectWise Control) installers, ultimately delivering a BYOVD EDR killer that drops a kernel driver to blind security tools before further compromise,” Huntress researcher Anna Pham said in a report published last week.

The cybersecurity vendor said it identified over 60 instances of malicious ScreenConnect sessions tied to the campaign. The attack chain stands out for a couple of reasons. Unlike recent campaigns highlighted by Microsoft that leverage tax-themed lures, the newly flagged activity employs commercial cloaking services to avoid detection by security scanners and abuses a previously undocumented Huawei audio driver to disarm security solutions.

The exact objectives of the campaign are currently not clear; however, in at one instance, the threat actor is said to have leveraged the access to deploy the endpoint detection and response (EDR) killer and then dump credentials from the Local Security Authority Subsystem Service (LSASS) process memory, as well as use tools like NetExec for network reconnaissance and lateral movement.

These tactics, per Huntress, align with pre-ransomware or initial access broker behavior, suggesting that the threat actor is looking to either deploy ransomware or monetize the access by selling it to other criminal actors.

What’s more, the landing page is protected by a PHP-based Traffic Distribution System (TDS) powered by Adspect, a commercial cloaking service, to ensure that a benign page is served to security scanners and ad review systems, while only real victims see the actual payload.

This is achieved by generating a fingerprint of the site visitor and sending it to the Adspect backend, which then determines the appropriate response. In addition to Adspect, the landing page’s “index.php” features a second cloaking layer powered by JustCloakIt (JCI) on the server side.

“The two cloaking services are stacked in the same index.php—JCI’s server-side filtering runs first, while Adspect provides client-side JavaScript fingerprinting as a second layer,” Pham explained.

The web pages lead to the distribution of ScreenConnect installers, which are then used to deploy multiple trial instances on the compromised host. The threat actor has also been found to drop additional Remote Monitoring and Management (RMM) tools like FleetDeck Agent for redundancy and ensuring persistent remote access.

The ScreenConnect session is leveraged to drop a multi-stage crypter that acts as a conduit for an EDR killer codenamed HwAudKiller that uses the BYOVD technique to terminate processes associated with Microsoft Defender, Kaspersky, and SentinelOne. The vulnerable driver used in the attack is “HWAuidoOs2Ec.sys,” a legitimate, signed Huawei kernel driver designed for laptop audio hardware.

“The driver terminates the target process from kernel mode, bypassing any usermode protections that security products rely on. Because the driver is legitimately signed by Huawei, Windows loads it without complaint despite Driver Signature Enforcement (DSE),” Huntress noted.

The crypter, for its part, attempts to evade detection by allocating 2GB of memory and filling it with zeros, and then freeing it, effectively causing antivirus engines and emulators to fail due to high resource allocation.

It’s currently not known who is behind the campaign, but an exposed open directory in the threat actor-controlled infrastructure has revealed a fake Chrome update page containing JavaScript code with Russian-language comments. This alludes to a Russian-speaking developer in possession of a social engineering toolkit for malware distribution.

“This campaign illustrates how commodity tooling has lowered the barrier for sophisticated attacks,” Pham said. “The threat actor didn’t need custom exploits or nation-state capabilities, they combined commercially available cloaking services (Adspect and JustCloakIt), free-tier ScreenConnect instances, an off-the-shelf crypter, and a signed Huawei driver with an exploitable weakness to build an end-to-end kill chain that goes from a Google search to kernel-mode EDR termination.”

“A consistent pattern across compromised hosts was the rapid stacking of multiple remote access tools. After the initial rogue ScreenConnect relay was established, the threat actor deployed additional trial ScreenConnect instances on the same endpoint, sometimes two or three within hours, and backup RMM tools like FleetDeck.”

TeamPCP, the threat actor behind the recent compromises of Trivy and KICS, has now compromised a popular Python package named litellm, pushing two malicious versions containing a credential harvester, a Kubernetes lateral movement toolkit, and a persistent backdoor.

Multiple security vendors, including Endor Labs and JFrog, revealed that litellm versions 1.82.7 and 1.82.8 were published on March 24, 2026, likely stemming from the package’s use of Trivy in their CI/CD workflow. Both the backdoored versions have since been removed from PyPI.

“The payload is a three-stage attack: a credential harvester sweeping SSH keys, cloud credentials, Kubernetes secrets, cryptocurrency wallets, and .env files; a Kubernetes lateral movement toolkit deploying privileged pods to every node; and a persistent systemd backdoor (sysmon.service) polling ‘checkmarx[.]zone/raw’ for additional binaries,” Endor Labs researcher Kiran Raj said.

As observed in previous cases, the harvested data is exfiltrated as an encrypted archive (“tpcp.tar.gz”) to a command-and-control domain named “models.litellm[.]cloud” via an HTTPS POST request.

In the case of 1.82.7, the malicious code is embedded in the “litellm/proxy/proxy_server.py” file, with the injection performed during or after the wheel build process. The code is engineered to be executed at module import time, such that any process that imports “litellm.proxy.proxy_server” triggers the payload without requiring any user interaction.

The next iteration of the package adds a “more aggressive vector” by incorporating a malicious “litellm_init.pth” at the wheel root, causing the logic to be executed automatically on every Python process startup in the environment, not just when litellm is imported.

Another aspect that makes 1.82.8 more dangerous is the fact that the .pth launcher spawns a child Python process via subprocess.Popen, which allows the payload to be run in the background.

“Python .pth files placed in site-packages are processed automatically by site.py at interpreter startup,” Endor Labs said. “The file contains a single line that imports a subprocess and launches a detached Python process to decode and execute the same Base64 payload.”

The payload decodes to an orchestrator that unpacks a credential harvester and a persistence dropper. The harvester also leverages the Kubernetes service account token (if present) to enumerate all nodes in the cluster and deploy a privileged pod to each one of them. The pod then chroots into the host file system and installs the persistence dropper as a systemd user service on every node.

The systemd service is configured to launch a Python script (“~/.config/sysmon/sysmon.py”) – the same name used in the Trivy compromise – that reaches out to “checkmarx[.]zone/raw” every 50 minutes to fetch a URL pointing to the next-stage payload. If the URL contains youtube[.]com, the script aborts execution – a kill switch pattern common to all the incidents observed so far.

“This campaign is almost certainly not over,” Endor Labs said. “TeamPCP has demonstrated a consistent pattern: each compromised environment yields credentials that unlock the next target. The pivot from CI/CD (GitHub Actions runners) to production (PyPI packages running in Kubernetes clusters) is a deliberate escalation.”

With the latest development, TeamPCP has waged a relentless supply chain attack campaign that has spawned five ecosystems, including GitHub Actions, Docker Hub, npm, Open VSX, and PyPI, to expand its targeting footprint and bring more and more systems into its control.

“TeamPCP is escalating a coordinated campaign targeting security tools and open source developer infrastructure, and is now openly taking credit for multiple follow-on attacks across ecosystems,” Socket said. “This is a sustained operation targeting high-leverage points in the software supply chain.”

In a message posted on their Telegram channel, TeamPCP said: “These companies were built to protect your supply chains yet they can’t even protect their own, the state of modern security research is a joke, as a result we’re gonna be around for a long time stealing terrabytes [sic] of trade secrets with our new partners.”

“The snowball effect from this will be massive, we are already partnering with other teams to perpetuate the chaos, many of your favourite security tools and open-source projects will be targeted in the months to come so stay tuned,” the threat actor added.

Users are advised to perform the following actions to contain the threat –

• Audit all environments for litellm versions 1.82.7 or 1.82.8, and if found, revert to a clean version
• Isolate affected hosts
• Check for the presence of rogue pods in Kubernetes clusters
• Review network logs for egress traffic to “models.litellm[.]cloud” and “checkmarx[.]zone”
• Remove the persistence mechanisms
• Audit CI/CD pipelines for usage of tools like Trivy and KICS during the compromise windows
• Revoke and rotate all exposed credentials

“The open source supply chain is collapsing in on itself,” Gal Nagli, head of threat exposure at Google-owned Wiz, said in a post on X. “Trivy gets compromised → LiteLLM gets compromised → credentials from tens of thousands of environments end up in attacker hands → and those credentials lead to the next compromise. We are stuck in a loop.”

On February 25, 2026, Gartner published its inaugural Market Guide for Guardian Agents, marking an important milestone for this emerging category. For those unfamiliar with the various Gartner report types, “a Market Guide defines a market and explains what clients can expect it to do in the short term. With the focus on early, more chaotic markets, a Market Guide does not rate or position vendors within the market, but rather more commonly outlines attributes of representative vendors that are providing offerings in the market to give further insight into the market itself.”

And if Guardian Agent is an unfamiliar term, Gartner defines it quite simply. “Guardian agents supervise AI agents, helping ensure agent actions align with goals and boundaries.” Enterprise security and identity leaders can request a limited distribution copy of the Gartner Market Guide for Guardian Agents.

Learning 1: Why Guardian Agent technology is important

One need only to read the news- in the Wall Street Journal, The Financial Times, Forbes, Bloomberg, the list goes on- to see that AI agents are a thing now. But Team8’s 2025 CISO Village Survey quantified it, finding that:

• Nearly 70% of enterprises already run AI agents (any system that can answer and act) in production.
• Another 23% are planning deployments in 2026.
• Two-thirds are building them in-house. 

However, in the market guide, Gartner asserts that this fast enterprise adoption is outpacing traditional governance controls. This raises the risk that “as AI agents become more autonomous and embedded in critical workflows, the risks of operational failure and noncompliance escalate.”

We concur, having read about the recent cloud provider outages stemming from autonomous AI agent actions, which do not surprise us. What we see across early adoption is that, even more so than traditional service accounts, AI agent deployment creates more identity dark matter- the invisible and unmanaged layer of identity. It includes the local credentials authentication that may be offered. The never-expiring tokens that are easily forgotten. Full permission access is granted, regardless of the user or job. And more.

Not only that, as we shared in our piece on “Lazy LLMs,” AI agents are, by design, shortcut seekers; always looking for the most efficient path to return a satisfactory outcome to each prompt. However, in doing so, they often exploit identity dark matter- orphan, dormant accounts or loose tokens, usually with local clear-text credentials and excessive privileges- that allow them to reach the “end of job,” regardless of whether they should have been allowed to do so. This is how unintended or unimaginable incidents arise.

As if that weren’t enough business risk, we note that the 2026 CrowdStrike Global Threat Report goes one step further, sharing that “Adversaries are also actively exploiting AI systems themselves, injecting malicious prompts into GenAI tools at more than 90 organizations and abusing AI development platforms.”

To learn more about how AI agents both expand what we call “Identity Dark Matter” and even exploit it themselves, check out our previous article in The Hacker News.

Learning 3: Different vendor approaches to Guardian AI

That said, even when vendors try to address the same Guardian Agent requirements, they often solve the problem using very different architectural models.

Gartner outlines six emerging delivery and integration approaches, which, for adopters, matter more than they may first appear. These are not just packaging choices. They determine where control lives, how much visibility you actually get, how enforceable the policy is, and how much of your agent estate will fall outside coverage.

Here is our quick take on each model:

• Standalone Oversight Platforms are typically the easiest place to start. They collect logs, telemetry, and events into one place and can provide meaningful posture visibility, auditability, and analysis. But many of these platforms still lean more toward observation than intervention. That is useful, but it is not the same as control. If your AI risk posture depends on stopping bad actions before they happen, visibility alone will not be enough.
• AI/MCP Gateways are the most intuitive model: put a control point in the middle and force agent traffic through it. That can create a powerful centralized layer for monitoring and policy enforcement across multiple agents. But it only works if traffic actually goes through that layer. In practice, gateways can become both a bottleneck and a false comfort. If teams bypass them, or if agent interactions happen outside the governed path, visibility breaks down quickly.
• Embedded or In-Line Run-Time Modules sit closer to execution, inside the agent platform, an AI management platform, or an LLM proxy. That makes them appealing because they are often easier to turn on and can act with more immediacy. The downside is that they are usually platform-bound. They govern the environment they live in, not the broader enterprise. For adopters, that means great local control, but weak enterprise-wide consistency if your agents span multiple stacks.
• Orchestration Layer Extensions are attractive in environments where orchestration already acts as the operating layer for multi-agent workflows. They can add policy, visibility, and oversight at the workflow level. But they also assume orchestration is where meaningful control should sit. That is only true if the organization actually runs its agents through a common orchestration layer. Many will not. So for adopters, this model is powerful in the right architecture and irrelevant in the wrong one.
• Hybrid Edge – Cloud Models are where things start to get more realistic. As Gartner notes, these are becoming more important as agent ecosystems become more endpoint-centric. This model spreads oversight between local execution environments and cloud analysis, which can reduce latency and improve runtime relevance. For adopters, the value is clear: it avoids over-centralizing everything in one choke point. But it also raises the complexity bar. Distributed governance is stronger in theory, but harder to implement well. 
• Coordination Mechanisms standards, APIs, and hooks are less a deployment model than the connective tissue between them. And today, that tissue is immature. Gartner is explicit that integration across AI agent platforms remains difficult because standard interfaces are still lacking. That means adopters should be careful not to mistake “supports standards” for “works seamlessly in production.” The coordination layer is necessary, but it is not yet mature enough to be treated as solved.

Regardless of technical approach, Gartner gives clear guidance about the need for something more than the governance of individual AI agents built into a single cloud provider, identity tool, or AI platform. Specifically, they call out the following:

“A neutral, trusted guardian agent layer with multiple guardian agents performing separate but integrated oversight functions enforces routing across all providers. Thus, the guardian agent acts as the missing universal enforcement mechanism.”

Learning 4: Guardian Agents Will Become an Independent Layer of Enterprise Control

Perhaps the most important long-term takeaway for us from the Market Guide is that Guardian Agents will not simply be another feature embedded in AI platforms. As we read it, Gartner is quite explicit: “enterprises will require independent guardian agent layers that operate across clouds, platforms, identity systems, and data environments.”

Why? Because AI agents themselves do not live in one place.

Agents interact with APIs, applications, data repositories, infrastructure, and even other agents across multiple environments. A cloud provider may be able to supervise agents running inside its own ecosystem, but once those agents call tools, delegate tasks, or operate across providers, no single platform can enforce governance alone.

That is why we believe Gartner argues that organizations will increasingly deploy enterprise-owned guardian agent layers that sit above individual platforms and supervise agents across the full enterprise environment.

In other words, governance cannot live only inside the platforms that create or host AI agents. It needs to live above them.

Put simply: the future of agent governance will not be platform-native supervision. It will be enterprise-owned oversight. And the organizations that adopt that architecture early will be far better positioned to scale agentic AI safely, without introducing a new generation of invisible automation risk across their infrastructure, data, and identities.

Learning 5: There is Still Time, But Not Forever

For all of the excitement about AI agents and the big brand news stories about them replacing jobs, the Guardian Agent market is still early. According to Gartner, “Today, guardian agent deployments are mainly prototypes or pilots, although advanced organizations are already using early versions of them to supervise AI agents.” 

But it’s coming fast. They note that “the guardian agent market — encompassing technologies for the oversight, security, and governance of autonomous AI agents — is entering a phase of accelerated growth, underpinned by the rapid adoption of agentic AI across industries.”

Frankly, we would make a similar statement about the Agentic market overall. Yes, we have implemented AI agents within Orchid- the company and the product. But organizations, ourselves included, are just scratching the surface of what’s possible. Have individual employees started using their own personal AI agents? Yes. Do many technology vendors offer built-in AI agents, beyond the simple chatbot? Yes. Have some of the earliest adopters implemented a corporate standard platform to augment or replace jobs? Yes (but said with some skeptical hesitation).

However, as the saying goes, it’s too late to bar the door after the horse is out of the barn. Orchid Security recommends that you ensure AI agent visibility sooner rather than later, and for sure, establish the same identity and access management guardrails and governance required for human users are indeed in place to similarly guide their AI companions, before the horse is out of the barn. 

The Bottom Line (We Will Say it Again)

AI agents are here. They are already changing how enterprises operate.

The challenge is not whether to use them, but how to govern them.

Safe adoption of AI agents requires applying the same principles that identity practitioners know well, least privilege, lifecycle management, and auditability, to a new class of non-human identities that follow this protocol.

If identity dark matter is the sum of what we can’t see or control, then unmanaged AI agents may become its fastest-growing source, if left unchecked. The organizations that act now to bring them into the light will be the ones who can move quickly with AI without sacrificing trust, compliance, or security. That’s why Orchid Security is building identity infrastructure to eliminate dark matter, and make Agent AI adoption safe to deploy at enterprise scale.