Posts on Security, Cloud, DevOps, Citrix, VMware and others.
Words and views are my own and do not reflect on my companies views.
Disclaimer: some of the links on this site are affiliate links, if you click on them and make a purchase, I make a commission.
Written by: Christopher Romano, Codi Starks, Garrett Mahoney, John Wolfram, Josh Murchie, K Singh, Mathew Potaczek, Mike Lombardi, Rik Dolfing
Introduction
Mandiant responded to multiple incidents in 2026 in which threat actors hijacked enterprise access to Large Language Models (LLMs), a tactic known as "LLMJacking." Spanning a variety of cloud and LLM providers, these intrusions impacted organizations in North America, South America, and Asia Pacific across the financial services, retail, technology, and transportation sectors.
Unlike the gradual resource consumption associated with cryptojacking, LLMJacking can generate large spikes in fraudulent cloud charges in a matter of hours. Across individual incidents, we observed fraudulent charges associated with resource consumption exceeding $100,000 USD in a single day, with cumulative charges at some organizations reaching $1 million USD before access was revoked.
Figure 1: Usage chart showing LLMJacking generating a spike in API requests
Analyzing the criminal ecosystem behind these frontline compromises, and building upon previous reporting on the growing underground market for LLM credentials, Google Threat Intelligence Group (GTIG) has identified a diverse set of financially motivated threat clusters operating out of multiple regions globally.
As the LLMJacking ecosystem matures, we are also tracking a division of labor between threat actors establishing initial access to compromised environments and operators managing downstream monetization infrastructure, known as “LLM Mixers”. LLM Mixers function as illicit routing gateways that proxy, aggregate, and resell unauthorized LLM access to underground subscribers. In one investigation, GTIG observed two distinct operational clusters coordinating to compromise and monetize enterprise LLM infrastructure, demonstrating the sophisticated specialization emerging in this space.
In this blog post, we describe the attack lifecycle observed across recent LLMJacking investigations and provide actionable detection, hardening, and remediation guidance to help organizations secure their infrastructure.
Initial Access
While low-level resource theft has involved the manipulation of customer support chatbots to conduct unauthorized tasks like code generation, threat actors conducting LLMJacking bypass these front-end interfaces to target backend model resources directly. Specifically, they focus on either identifying publicly exposed LLM endpoints or obtaining valid LLM application programming interface (API) keys. An example of the latter can be seen in Figure 1, where a threat actor uses an automated script to verify exposure by calling the /api/create endpoint to independently run their own models on endpoints that unsuspecting users have left publicly accessible. Leaving these services unprotected not only expands an organization's traditional attack surface, but could also introduce a significant increase in hosting costs.
Figure 2: Threat Actor tests publicly exposed Ollama endpoints and attempts to register their own models
Across multiple LLMJacking investigations, however, the dominant initial access vector has been exposed or stolen cloud identity tokens—including IAM credentials, Service Account keys, GitHub Personal Access Tokens (PATs), and active session tokens—which threat actors leverage to establish an initial foothold into target organizations' infrastructure.
For instance, in mid-2026 UNC6993 compromised a cloud instance through a misconfigured Service Account key and used this access to grant further access to an LLM API. UNC6993 also hosted a session hijacking page masquerading as an application portal to join a group of LLM users. This page tricks users into navigating to the legitimate LLM service website, and pasting their raw JSON payload containing an active access token, which was then posted to the backend API to bypass password and multifactor authentication (MFA) controls.
In another instance, one threat actor gained initial entry by combining a stolen Personal Access Token (PAT) to access private code repositories with the exploitation of a suspected web application vulnerability in a package running within a containerized cloud environment. Similarly, a different threat actor leveraged compromised IAM credentials of corporate users, using cloud federation tokens to programmatically generate fresh access keys to circumvent MFA requirements. In a separate incident, a threat actor was first observed accessing the environment with a compromised cloud Service Account key with broad project permissions.
Beyond general cloud identity credentials, threat actors also target LLM API keys. For example, a threat actor opportunistically harvested exposed corporate LLM API keys from public GitHub repositories. Demonstrating advanced evasion tradecraft, the group conducted automated credential validation sweeps using minimal single-token requests (max_tokens=1). This allowed the threat actor to stealthily confirm the viability of the stolen keys while remaining undetected by the victim’s endpoint detection and response (EDR) and SIEM volume anomaly alerts.
Lateral Movement and Persistence
After gaining an initial foothold, threat actors systematically work to escalate privileges, solidify access, and conduct internal reconnaissance to identify targets and further cloud credentials.
To expand their access, threat actors enumerated cloud services, code repositories, and data stores for sensitive credentials. In one intrusion, a threat actor conducted internal reconnaissance across multiple cloud regions to map available services and identity policies. In a separate intrusion, a threat actor compromised a containerized cloud environment. Once inside, they performed extensive repository reconnaissance, cloning sensitive codebases to search for hardcoded secrets, configuration variables, and developer credentials. They also scanned access logs to identify credentials for secondary cloud environments. Threat actors also executed targeted database queries to harvest additional credentials; in one case, the threat actor queried cloud data warehouse metadata tables to search for database credentials, administrator passwords, and sensitive columns, alongside performing cloud object storage operations associated with targeted data theft.
Across intrusions, we observed threat actors abusing cloud identity permissions and virtual machine configurations to escalate privileges and maintain persistent access. Utilizing service accounts associated with compromised workloads, one threat actor exploited token-creation privileges to generate temporary credentials for high-privilege service accounts, resulting in the exfiltration of infrastructure credentials, internal database passwords, and third-party API keys from cloud secret managers. Other threat actors established persistence by creating unauthorized IAM and service accounts and injecting SSH keys into compute instances. Specifically, one actor escalated privileges by attaching administrative policies to service roles, created unauthorized IAM accounts with full administrative rights, and established interactive management sessions into running virtual machines to inject unauthorized SSH public keys into host configuration files. Similarly, another threat actor created deceptive backdoor service accounts disguised as internal billing optimization utilities and injected environment-wide SSH keys into compute instance metadata.
Beyond exploiting traditional cloud infrastructure permissions, we have observed instances of threat actors targeting vulnerabilities specifically within LLM routing software to escalate privileges. In one case, after acquiring pre-validated Virtual Keys from the threat actor that established initial access, a follow-on cluster executed targeted application logic exploitation against the victim's LiteLLM gateway. The actor exploited a user ID rebind vulnerability in the /key/regenerate endpoint (CVE-2026-40217) to elevate standard Virtual Keys into full PROXY_ADMIN master administrative credentials, establishing deep, persistent control over the compromised environment.
LLM Abuse
The ultimate objective of LLMJacking is the monetization and resource-hijacking of foundation models, which actors achieve through token proxying, automated model streaming, and GPU hardware provisioning.
Threat actors frequently enabled a variety of managed generative platforms, and created additional API keys to scale their operations. Upon acquiring LLM API access keys, UNC6993 attempted to generate additional API keys and enable associated services within victim cloud projects, quickly accumulating over $100,000 USD in billing charges. Another threat actor subscribed victim accounts to Pay-As-You-Go agreements, selecting premium foundation models and launching high-volume inference streams. To bypass rate limits, the threat actor deployed a "burn and rotate" strategy, continuously creating and deleting short-lived service accounts while auditing the cloud provider’s billing interface to monitor financial impact.
Threat actors also leveraged their access to host their own proxy endpoints and agentic workloads. For example, one threat actor enabled agents, deployed publicly accessible reverse proxies, and used custom Node.js proxy bundles to expose endpoints compatible with multiple frontier LLMs rebranded under a persona known as D1337-KAIROS. The actor deployed a containerized backdoor using the Manus agent framework to the compromised cloud environment, which queried an upstream LLM to reason through instructions and execute resulting commands locally, supported by SearXNG metasearch and agent-infra/sandbox execution environments. To scale compute, the threat actor provisioned compute instances with powerful GPUs, attempted to spin up high-end hardware across multiple regions, and requested quota increases via the cloud provider’s API. The actor also hostedLiteLLM gateways on external servers to manage and route API traffic.
Rather than consuming hijacked compute solely for their own operations, GTIG observed evidence of threat actors monetizing compromised API quotas by selling access to these resources through LLM Mixers. The threat actors used open-source API gateways and custom relay infrastructure to pool stolen credentials, meter usage, and obscure the origin of the requests. For example, UNC6993 used open-source tools such as new-api (a centralized model hub and gateway) and gcli2api (an API proxy tool converting command line interface (CLI) tools into standard frontier model endpoints), likely to aggregate stolen keys and balance request loads across accounts. We believe the threat actor sells access to these tools via underground storefronts.
Another threat actor that executed more than 500,000 LLM API calls in less than eight hours leveraged stolen third-party API keys to power the token routing service jet-night.com. Jet Night passed nearly one million dollars in token costs to the victim organization. Given Jet Night’s per-token costs to users are so far below typical market rates GTIG believes the service relies on stolen keys to operate profitably. For example, Jet Night offers an unlimited token plan for approximately $60 USD per month with alleged access to frontier models, a consumer service level that would typically run between $100 and $250 per month. Moreover, the service has advertised multiple outages on its public Telegram channel which is likely due to stolen keys being revoked as victims discover their respective compromises.
Figure 3: Screenshot of Jet Night Plans and Pricing Structure
A threat actor deployed custom proxy relay infrastructure (ai-relay) hosted on deceptive lookalike domains. For example, they registered a domain to masquerade as the victim's legitimate internal host. This custom relay infrastructure was used to seamlessly siphon high-value commercial LLM access into the illicit newapi[.]pro resale ecosystem, directly draining the victim's corporate account quotas to serve their underground customers.
Outlook
GTIG expects that threat actors will increasingly prioritize LLMJacking over traditional resource theft like cryptojacking, driven by the immediate, high-margin monetization enabled by emerging underground LLM Mixers. As enterprises integrate higher-tier models and agentic workflows into production environments, cybercriminals will likely refine automated reconnaissance to target exposed API tokens and exploit vulnerabilities in model routing middleware. This operational specialization will sustain a growing illicit resale marketplace, allowing threat actors to rapidly siphon enterprise quotas while passing the billing costs to victims before compromises are detected.
Detection and Hunting
In the event that security measures have failed, it is critical that defenders have early visibility into abuse of cloud LLM platforms. Defenders should prioritize detection of modifications to LLM accounts and services and treat any unauthorized enablement as a critical security event. In multiple incidents that Mandiant investigated, LLM services were not enabled at the time of compromise. Abuse of access keys allowed the threat actor to modify and enable LLM API services (e.g. Bedrock, Gemini API, etc.). Once enabled, the threat actor can use the APIs to generate massive bills to the organization in just minutes or hours.
Google Security Operations
Google Security Operations customers have access to these broad category rules and more under the Cloud Threats, Mandiant Frontline Threats, Mandiant Hunting Rules rule packs. The activity discussed in the blog post is detected in Google SecOps under the rule names:
AWS Account Key Creation
AWS Create New Access Key
AWS Create User Account
AWS Delete User Account
Base64 Encoded Shell Command Execution
Create and Delete Firewall in Default Network
GCE Project SSH Keys
GCP Service Account Key Creation
GCP Create New Service Account
GCP Firewall Rule Created
Linux Archive Exfiltration via Curl or Wget
Persistence: Compute Set Instance or Project Metadata Startup Scripts or URLs
Mitigation and Remediation
To prevent attackers from abusing Cloud LLM services, defenders should prioritize Identity and Access Management (IAM) and supply chain security, two of the most common pathways for gaining access to and abusing Cloud services.
Credential Hygiene: Utilize a centralized secrets management platform to control the management and rotation of sensitive keys and secrets. Automation of secrets and keys can limit the lifespan of leaked credentials.
Least Privilege: Ensure users and service accounts only possess the permissions necessary for their specific role and required tasks. Deny all permissions that are not explicitly required, including access to Cloud LLM services.
Code Monitoring: Automate secret scanning within codebases (GitHub, Gitlab, etc.) to ensure API keys and secrets added to source code are identified and removed promptly.
Routine Configuration Audits: Perform periodic comprehensive configuration audits of Cloud services to identify potential attack paths and unintended exposure of endpoints.
Rate Limiting: Implement a WAF like Google’s Cloud Armor to enforce rate limiting for individual client connections.
Network Allow Listing: Restrict outbound connections from Cloud services via VPC firewall rules to known IP addresses where feasible.
Budget Alerts: Implement granular API quotas on LLM services to limit request volume per model. Utilize spending caps to set budgets and avoid over-spending.
Multi-Factor Authentication (MFA): Enforce phishing-resistant multi-factor authentication across all cloud identity providers, management consoles, and developer platforms to ensure that stolen credentials or session tokens cannot be easily exploited.
Shadow LLM Discovery: Utilize Security Posture Management tools to automatically scan your hybrid cloud environments and identify unauthorized or unmonitored tools, models, and infrastructure, ensuring complete visibility of your model footprint.
Granular API Key Scopes: Restrict and segment API keys by specific model endpoints, environments (dev/prod), and usage limits to ensure a compromised token for a basic utility model cannot be used to invoke expensive, high-tier frontier models.
Validation Sweep Monitoring: Monitor model gateway and API access logs for anomalous, low-volume requests (such as max_tokens=1 or zero-temperature pings). Attackers frequently use these micro-transactions for stealthy credential validation sweeps prior to launching large-scale infrastructure abuse.
Vulnerability & ML Supply Chain Patching: Integrate automated vulnerability scanning (SAST/DAST/SCA) across your custom application code, containerized workloads, and machine learning dependencies (like PyTorch and Hugging Face libraries) to prevent initial access via unpatched server vulnerabilities.
Gateway Patch Management: Extend vulnerability management programs to include centralized model proxy and routing gateways (e.g., LiteLLM), ensuring rapid patching against privilege escalation and authentication bypass flaws (such as CVE-2026-40217).
Sandboxed Execution for Dynamic Workloads: Isolate the runtime environment in highly virtualized, process-isolated, serverless sandboxes if your LLM application is required to execute generated code or database queries dynamically.
Vetted Model Repositories: Restrict and enforce model pulls and pipeline dependencies solely from trusted internal registries or approved enterprise catalogs to prevent developers from pulling compromised models containing pre-configured backdoors.
Graph-Based Exposure Modeling: Implement continuous, graph-based risk prioritization that maps cloud assets, application code, and data flows to automatically identify and remediate complex, multi-hop attack paths.
Adversarial Exposure Validation: Deploy automated offensive agents to continuously test external attack surfaces, uncover exposed endpoints, and simulate credential validation sweeps.
Monitoring Native Cloud Audit Logs
AWS: Monitor CloudTrail logs for API events from bedrock.amazonaws.com. Based on historical LLM Jacking incidents, monitor for the following API operations across the attack lifecycle:
Resource Exploitation: Monitor for direct execution of the LLM via the Converse, InvokeModel, and InvokeModelWithResponseStream API operations.
API Throttling & Error Spikes: Monitor for high-volume spikes in ThrottlingException, ValidationException, or ResourceNotFoundException errors, which could indicate an automated “spraying” methodology targeting cloud infrastructure.
Target Scoping: Monitor potential reconnaissance activity used to discover available models via the ListFoundationModels,ListInferenceProfiles, and GetFoundationModelAvailability operations. Additionally, monitor for attempts to unlock new models in the environment via the PutUseCaseForModelAccess and CreateFoundationModelAgreement API operations.
Security/Evasion: Review attempts to view, alter, or disable logging configurations to conceal prompt contents and avoid detection. Monitor the GetModelInvocationLoggingConfiguration operation, as well as PutModelInvocationLoggingConfiguration and DeleteModelInvocationLoggingConfiguration. Any calls to disable logging by non-IaC (Infrastructure as Code) principals should be treated as high severity.
Automated Tooling: Analyze User-Agent strings to identify automated tools and SDKs (e.g., claude-cli, aws-sdk-rust, and aws-sdk-go-v2) interacting directly with the target cloud infrastructure.
Azure: Monitor Azure Activity Logs (Control Plane) and Diagnostic Logs (Data Plane) for events associated with the Microsoft.CognitiveServices namespace. To hunt for or detect LLM Jacking incidents, monitor the following operations:
Resource Exploitation: Monitor for direct execution of the LLM. In Azure, model invocations occur on the data plane and require Diagnostic Logs to be enabled. Look for high volumes of POST requests to inference endpoints such as Completions or Chat Completions APIs. On the management plane (Activity Logs), monitor for unauthorized creation of new instances via the Microsoft.CognitiveServices/accounts/deployments/write operation.
Target Scoping: Monitor potential reconnaissance activity to discover available Azure LLM resources, models, and deployments via the Microsoft.CognitiveServices/accounts/read and Microsoft.CognitiveServices/accounts/deployments/read operations.
Security/Evasion: Review attempts to view or modify logging configurations (to see if data plane model invocations are being recorded) via the Microsoft.Insights/diagnosticSettings/read, Microsoft.Insights/diagnosticSettings/write, or Microsoft.Insights/diagnosticSettings/delete operations.
GCP: Monitor Cloud Audit Logging for calls to Gemini Enterprise Agent Platform endpoints (aiplatform.googleapis.com). Gemini Enterprise Agent Platform inference operations are contained within Data Access logs, which are disabled by default due to volume and ingestion costs. You must manually configure your IAM audit policies to track these.
Enablement of Agent Platform Services: Alert on enablement of Gemini Enterprise Agent Platform services via the google.api.serviceusage.v1.ServiceUsage.EnableService method.
Resource Exploitation: Monitor for direct execution of the LLM via Gemini Enterprise Agent Platform, which requires Data Access audit logging to be enabled. Look for google.cloud.aiplatform.v1.PredictionService.Predict, google.cloud.aiplatform.v1.PredictionService.GenerateContent, and google.cloud.aiplatform.v1.PredictionService.StreamGenerateContent operations.
Target Scoping: Monitor potential reconnaissance activity to discover available models and endpoints via the google.cloud.aiplatform.v1.ModelService.ListModels, google.cloud.aiplatform.v1.EndpointService.ListEndpoints, and google.cloud.aiplatform.v1.PublisherModelService.ListPublisherModels API operations.
Security/Evasion: Review attempts to view or alter logging and audit configurations. Monitor for operations like google.iam.v1.IAMPolicy.GetIamPolicy (to check if Data Access logs are enabled on the project/resource) or attempts to review log exports via google.logging.v2.ConfigServiceV2.ListSinks and google.logging.v2.ConfigServiceV2.GetSink.
Indicators of Compromise (IOCs)
To assist the wider community in hunting and identifying activity outlined in this blog post, we have included indicators of compromise (IOCs) in a GTI Collection for registered users.
Network Indicators
Indicator
Description
jet-night.com
LLM Mixer
newapi.pro
LLM Mixer
Table 1: Network Indicators
from Threat Intelligence https://ift.tt/JQhKk31
via IFTTT
Cybersecurity researchers have disclosed details of a cyber espionage campaign targeting Israel and the Kurdistan Region of Iraq by an Iran state-aligned threat actor between August and October 2026.
According to a report published by Dream Research Labs, the campaign has led to the compromise of a high-profile individual in Israel, along with additional compromises affecting a government cloud environment in the Kurdistan Region.
The activity has been attributed to a threat actor known as DarkBlinders, an Iran-nexus group assessed to be active since at least September 2024 and linked to attacks aimed at aviation infrastructure and telecommunications in the U.A.E. and Iraq. It exhibits no technical overlap with other known hacking groups.
Attacks mounted by the group are known to rely on spear-phishing as an initial access pathway to lure recipients into opening trojanized utilities or clicking on attacker-controlled websites that host similar tools as direct downloads.
Previous attack chains documented by Elastic Security Labs and Group-IB have led to the deployment of SHELBYLOADER (aka HOTAIR), which is launched via DLL sideloading to ultimately execute a backdoor called SHELBYC2 (aka AEROSTAT) that uses GitHub for command-and-control (C2), data exfiltration, and remote control. Elastic is tracking the threat cluster under the moniker REF8685.
Then early last month, Palo Alto Networks shed light on a campaign dubbed Blinder Tunnel in which the threat actor, which it calls CL-STA-1178, was observed masquerading as the Dubai Airports IT department to distribute malware-laced coding challenges to high-value targets.
The bogus recruitment scheme was first detected in late March 2026, although evidence indicates that the attackers were staging and testing attack infrastructure as far back as November 2025.
The social engineering campaign is assessed to have approached specific targets with lucrative job offers to trick them into executing a self-contained application that mimicked a career portal and instructed them to complete a questionnaire.
Submitting the questionnaire does not cause any data to be exfiltrated or initiate any response from an external domain. Instead, it's meant to serve as a harmless decoy and build credibility before delivering the next stage payload containing the malware in the form of a Microsoft Visual Studio project archive that's dressed up as a coding assessment.
The attack chain makes use of three techniques to establish persistent access: A malicious C# project ".csproj" file is used to trigger AppDomainManager injection, followed by DLL sideloading to deliver an updated version of SHELBYLOADER (aka ShelbyLoader V2), which then launches SHELBYC2. Also deployed via SHELBYC2 is a tunneling utility called Blackwood.
"The attackers behind the activity used tailored social engineering techniques to masquerade as Dubai Airports recruiters, using a trojanized Visual Studio coding challenge to target a high-value job seeker based in Iraq," Unit 42 said.
"The campaign is characterized by misuse of built-in developer tools and DLL sideloading. Attackers also used AppDomainManager hijacking to bypass security monitors like ETW [Event Tracing for Windows]."
The latest findings from Dream show that the threat actor continues to rely on social engineering, while combining both credential phishing and malware delivery. This involves the use of government, webmail, and cloud-service lookalike domains to collect credentials or present attacker-controlled file downloads. Some of the highlighted domains include -
The threat actor has also been observed setting decoy brand domains for a fake videoconferencing application called StarkMeet (stark-meet[.]com, stark-meet[.]online, and stark-meet[.]website). Installing and launching the app leads to the execution of ShelbyLoader V2 and SHELBYC2.
The development is also a sign that the threat actor is trying out different methods for malware delivery, ranging from coding assessments to counterfeit software.
Dream said the DarkBlinders activity belongs to the same operational cluster as UNC5795 and Dust Specter, citing infrastructure and malware overlaps. Dust Specter, documented by Zscaler in March 2026, refers to a suspected Iran-nexus operation targeting government officials in Iraq by impersonating the country's Ministry of Foreign Affairs.
"Historical server fingerprints, overlapping victimology, and supporting attribution research lead us to assess with medium confidence that UNC5795 and UNC5187 may represent related sub-clusters within the broader APT34 group," it added.
"Their overlapping focus on Iraqi government entities adds context to this technical connection and suggests a shared intelligence collection interest. Combined with their respective APT34 associations, these findings support a medium-confidence assessment that the two clusters are operationally related and may belong to the same broader group."
Prince of Persia Hosts C2 in the U.S. for the First Time in a Decade
The disclosure comes as Prince of Persia (aka Infy), a lesser-known threat group sponsored by the Iranian government, has been observed running one of its C2 servers ("68.65.122[.]203") from the U.S. this year. The server was likely built in July 2026.
The infrastructure is a second-stage C2 server associated with Tornado, a Tonnerre variant that's dropped via one-day software vulnerabilities and uses both HTTPS and the Telegram API for C2. The emergence of new C2 servers in late May 2026 follows three months of inactivity, which has been described as the "longest downtime in nearly two decades of activity by the threat actor."
"We have been monitoring Prince of Persia's exfiltration activity for the past six months," Tomer Bar, associate vice president of security research at Semperis, said. "The number of victims remains low, which could indicate either targeted attacks or difficulties infecting new victims."
"The Iranian threat actor decided to host its new C2 server on U.S. soil — at the same time as the beginning of the recent hostilities between Iran and the United States. This is the last place we expected to find the threat actor hiding."
from The Hacker News https://ift.tt/1dZ9XWL
via IFTTT
Giving an agent a sandbox also means deciding which files it will work on. You can share a checkout from your host, give it a separate working directory for a task, or keep the repository entirely inside the sandbox. Each arrangement changes how you, the human, participate in the work.
You might want to watch the diff in your local editor and make changes alongside the agent, or give it room to manage several tasks while you review the results. sbx supports both. The way you organize the checkout can change as you ask the agent to take on more of the work.
Mounting a repository from your host
Sharing a checkout puts the agent in the working tree you already use. Run sbx run from your project directory, and it mounts that directory at the same absolute path inside the sandbox:
$ cd ~/my-project
$ sbx run claude
Open a file in your local editor while the agent works on it, and you’ll see changes as they happen. Git works from either side, so you choose whether you want to let the agent make commits or you do it yourself. Development servers on your host can pick up the edits through hot reload, using the runtime and dependencies installed on your host.
This fits close collaboration on one task. The coordination cost comes from sharing that working tree: switching branches changes the files the agent sees, and your edits become part of its ongoing work. If you want to switch to something unrelated while the agent continues, you’ll need another checkout.
[!NOTE] Dependencies written into the shared checkout are shared too. Packages with native binaries, such as esbuild, may work in the Linux sandbox and fail on a macOS or Windows host. Reinstalling on the host can reverse the problem. Keep separate dependency installations, or run the app consistently in one environment.
Give each task a separate working tree
Git worktrees give each task a directory and branch. You can mount each worktree in its own sandbox, while your original checkout remains available for other work. The agent’s edits appear in the worktree. You can inspect either with your local editor and development tools. Each task also gets its own running environment, with tools to prepare and a sandbox and worktree to clean up afterward.
There is a Git limitation with mounting only a linked worktree. Its .git file points to metadata outside the mount, which the agent can’t reach. It can edit files, but checking status, branching, and committing have to happen on the host. The future of software development still needs you to run git status.
sbx supports a clone mode that gives the agent a separate checkout with Git available inside the sandbox. You keep your local project, but sbx mounts the host source as read-only and creates an independent clone for the agent. Its branch changes and dependency installations stay in its checkout.
Bringing the result back becomes a handoff. While the sandbox is running, you can fetch committed branches through the Git remote sbx adds on your host. Or the agent can push to the repository’s remote and you can retrieve the branch through your usual Git workflow. Your local editor and development server see the changes after you bring them into your checkout.
Keep the project inside the sandbox
A mountless sandbox has no host workspace directory attached. Clone the repository inside it, and the sandbox holds the checkout and its development environment. Your host copy of the project shares no connection with the sandbox checkout.
This workflow resembles working on a remote development machine. Agents connect to the project environment, and you can open a shell with sbx exec or connect an editor to the sandbox over SSH. Changes and dependency installations stay separate from your host. To bring work back, you push a branch to the Git remote.
One sandbox per project can be a useful mental model here. The project and its tools persist across agent sessions and sandbox restarts. An agent can create worktrees per feature it’s working on, push branches, and create pull requests for review. Starting another task doesn’t require you to prepare another host worktree and sandbox, and the agent has Git access in each working directory. Clone mode supports this internal-worktree approach too.
Those tasks share tools and services, so running servers or changing the environment still needs coordination. Separate sandboxes are useful when tasks need independent environments as well as separate files. Branches alone don’t isolate simultaneous edits in one working directory.
That independence adds some distance when you want to try the result. Your usual local editor isn’t looking at these files, and a development server running inside the sandbox needs a published port to reach it from your browser.
For a web app preview, ask the agent:
Start the development server on port 8080, bound to 0.0.0.0.
Then publish the port from another terminal on the host:
$ sbx ports my-sandbox --publish 8080:8080
Open http://localhost:8080 in your browser. It’s possible to work interactively this way, but there’s more ceremony than opening a project already on your filesystem.
An environment file can make setup repeatable, selecting tools and cloning the repository at creation with something like the community github-clone kit. Recreating the sandbox then gives you a fresh environment. Push or copy out work you want to retain first: removing a sandbox deletes files held only there.
Choose the repositories for the job
An API change might need a corresponding frontend change, or another repository might provide useful reference material. You can mount several directories into one sandbox, with read-only access for reference repositories. Local editing and previews remain available, but each writable checkout needs branch and change coordination. Task-specific checkouts also leave directories to clean up afterward.
A workspace manager such as jganoff/wsp can assemble selected repositories for a task. Mounting that workspace gives the agent the projects it needs together. These are standard clones with their own Git metadata, so the agent retains Git access, unlike a mounted linked worktree.
The same scope fits inside a mountless sandbox: clone the repositories needed there and keep the whole workspace in the sandbox. The number of repositories and where their files live are separate choices.
Combine the choices to suit the work
The checkout’s location, the sandbox’s lifetime, and the repositories it contains are choices you can combine. You can keep a project sandbox around for many tasks, or mount a workspace assembled for one job. What suits you may change when you want to work more closely with the agent, or give it more room to manage the work itself.
Forty percent of security teams now use AI every day, and another 56% are testing it. Only 4% have no plans to adopt it, according to Prophet Security's State of AI in Security Operations 2026 survey of more than 250 CISOs, SOC leaders and practitioners. For the teams still testing, the next decision is whether their own SOC is ready.
AI SOC readiness has two parts: whether a SOC has the problems AI SOC agents are built for, and whether it has the data access, context, written standards and oversight rules that AI agents need to investigate alerts accurately in its environment. A SOC does not need to be far along a maturity model to be ready. AI agents do their first work on the bottom layer, alert handling, and the analyst hours they return give a team room to work on the layers above it.
The next section describes those problems. Technical readiness covers four areas: access and context, an investigation standard with baseline metrics, rules for what the agent may do, and a plan for the time it gives back.
Which SOCs benefit the most from AI SOC agents
The SOCs that gain the most from AI SOC agents usually recognize several of the problems below, whether an outside provider works their alerts or their own analysts do.
If an MDR or MSSP works your alerts:
Your MDR flags threats too slowly. The provider works your alerts in a queue it shares with its other customers, so the escalation for a real intrusion can arrive hours after the activity started.
Your MDR hands alerts back for lack of context. An escalation arrives with a short summary and questions such as is this login expected, is this a production server, or is this user traveling? The provider often does not know your users, assets and business well enough to finish the investigation, so your analysts do the rest.
Your MDR closes alerts without showing its work. When the provider marks an alert benign, the note may not say what it checked and how it came to that conclusion, so your team either trusts the call or runs the investigation again.
Your MDR's coverage stops at the tools it supports. Many contracts cover the EDR and a set list of log sources, so alerts from everything else, such as a SaaS application or a second cloud platform, land on your team.
If your own analysts work the queue, including whatever the provider sends back:
"Are we impacted?" takes days to answer. When a critical vulnerability or a new campaign makes the news, leadership wants an answer the same day. Getting one means hunting across the environment by hand, usually by an analyst who is also working the queue.
Lower-severity alerts wait or get closed in bulk. A thorough investigation means pivoting across the SIEM, EDR, identity provider, cloud console and email tools, so the team keeps up with critical and high alerts and gets to the rest when it can. In the survey, 60% of respondents said an alert they had ignored or missed later turned into a serious issue, such as a breach or downtime.
Noisy detections get switched off. Tuning a rule that fires too often takes time the team does not have, so the rule gets disabled and the technique it watched goes uncovered.
Hunting and detection engineering wait for spare time. Proactive work happens when someone has a free afternoon, because the alert queue comes first.
A few senior analysts carry the hard cases. Only one or two people know how to work the most difficult investigations, so a single resignation can set the team back.
Nights and weekends are thinly covered. Staffing the queue around the clock takes more analysts than the budget covers, so alerts that fire after hours wait until morning or go to whoever is on call.
AI SOC agents are built for this work. They are designed to start on each alert as it arrives, whichever tool raised it and at whatever hour. They can pull the context an outside provider lacks from your own systems and record the evidence behind each conclusion, so your team can check it. Some can also run a hunt the day a new threat is disclosed, which turns "are we impacted?" into a set of queries with answers. The analyst hours they return can go to the detection and hunting work that waits today.
If several of these problems sound familiar, the need is there. The next question is whether your SOC can support a deployment.
Where AI agents fit on a SOC maturity model
Prophet Security's SOC maturity model, the SOC Hierarchy of Needs, has five levels: alert management, detection coverage, threat awareness, proactive hunting and posture improvements. Each level depends on the one below it. A team buried in alerts rarely gets to hunting, and a team that hunts without threat awareness has no clear idea what to look for.
Many SOCs have not yet stabilized the first level. In the State of AI in Security Operations 2026 survey, respondents said 28% of their alerts are never investigated.
AI SOC agents usually start at that first level, investigating alerts as they arrive. Newer platforms also run hunts and propose detections, work that reaches into levels two and four. Either way, the analyst hours they return go to work above the first level, so readiness depends on what the first level needs.
An AI agent can only investigate what it can query
An AI agent investigates by running queries against your tools, so it cannot see anything it has no access to. If it can query the EDR but not the identity provider, it can describe what happened on the endpoint but not which account was behind it.
Readiness here has three parts:
API access to the sources an investigation needs. That usually means the SIEM, EDR, identity provider, cloud platforms, email and key SaaS applications.
Context the agent can read. An agent needs asset criticality, user roles, VIP lists, business units and known-benign activity, such as scheduled scans and admin scripts, to tell an attacker from a legitimate administrator.
Healthy data pipelines. A silent or delayed log source can make an investigation look complete when key evidence is missing, so the health of the pipelines that feed investigations needs monitoring.
A quick test: take five recent incidents and list every query a senior analyst ran to close them. Any query the agent could not run marks a gap to close before a pilot.
Data access also raises the most common objection. In our survey, 44% of teams cited data privacy and how AI models are trained, the most frequent roadblock respondents named. Ask each vendor whether your data trains their models and where your data is processed.
Define a finished investigation and record your baseline
A pilot needs a written standard to grade the agent against. In many SOCs, only senior analysts know that standard, and it is rarely written down.
The standard covers which evidence closes a phishing case, when an impossible-travel alert needs a call to the user's manager, and what counts as enough to call an alert benign. Writing it down for your highest-volume alert types also gives new analysts an onboarding document.
Also keep a list of the detections that were switched off. In our survey, up to 40% of organizations had turned off some detections because they lacked the people to check them. When an agent investigates every alert, some of those rules can come back, and the list tells you where to start.
Then record the numbers you will compare against: the share of alerts investigated, mean time to investigate, time from alert to first look, and how often closed alerts are reopened. The survey gives a reference point. A thorough investigation takes an average of 75 minutes, and alerts often wait close to an hour before anyone opens them.
Decide what the agent may do, and who approves more
Investigation and action carry different risks, and most teams treat them differently. In the survey, 57% of teams require a human to review every AI decision before an alert is closed. On response, 44% have AI recommend actions that people carry out, 30% let it handle low-risk remediation on its own, and no respondent gives it full, unsupervised autonomy.
A ready SOC has these rules written down before a pilot starts:
Default approvals. A list of the actions that stay human-approved, such as isolating a host, disabling an account or blocking a domain.
How permissions widen. Who can grant the agent more autonomy for a category of action, and what track record they need to see first.
Where findings land. Agent findings should appear in the case management or ticketing tools analysts already use, so nobody has to watch another console.
Who owns feedback. A named person reviews the agent's mistakes and turns corrections into guidance it will use next time.
Starting with read-only access for investigations, then widening permissions as confidence grows, applies the same rules a SOC uses for a new human analyst. Prophet Security's framework for building trust in an AI SOC follows the same stepwise approach.
A readiness checklist mapped to the maturity model
Answer each question yes or no. Part 1 checks the need, and Part 2 checks technical readiness. The level in parentheses shows which layer of the SOC Hierarchy of Needs each item belongs to.
Part 1: Does your SOC need AI SOC agents?
Do escalations from your MDR or MSSP arrive hours after the activity started? (Level 1: alert management)
Does your provider hand alerts back because it lacked the context to finish them? (Level 3: threat awareness)
Does your provider close alerts without showing what it checked? (Level 1: alert management)
Do alerts from tools outside your provider's coverage land on your team? (Level 1: alert management)
Does it take more than a day to tell leadership whether you are impacted by a new vulnerability or campaign? (Level 4: proactive hunting)
Do low- and medium-severity alerts wait, or get closed in bulk without an investigation? (Level 1: alert management)
Have noisy detections been switched off because no one had time to tune them? (Level 2: detection coverage)
Do hunting and detection engineering wait until someone has spare time? (Level 4: proactive hunting)
Do only one or two senior analysts know how to work your hardest cases? (Level 1: alert management)
Do alerts that fire at night or on weekends wait until morning? (Level 1: alert management)
Each yes is a problem an AI SOC agent can take on, and the more yes answers, the stronger the case for a deployment.
Part 2: Is your SOC ready to deploy them?
Can a new tool query your SIEM, EDR, identity, cloud and email sources through an API? (Level 1: alert management)
Are asset criticality, user roles and known-benign activity recorded somewhere a system can read? (Level 3: threat awareness)
Is there a written standard for what a complete investigation includes, for the alert types that make up most of your volume? (Level 1: alert management)
Have you decided which actions stay human-approved, and who can widen the agent's permissions? (Level 1: alert management)
Do you monitor whether the log sources your investigations depend on are arriving? (Level 2: detection coverage)
Do you know your current share of alerts investigated and your mean time to investigate? (Level 1: alert management)
Do you keep a list of detections that were switched off for capacity reasons? (Level 2: detection coverage)
Is there a plan, with named owners, for the analyst hours an agent will return, such as scheduled hunts or detection work? (Level 4: proactive hunting)
A "no" on any of the first four is worth fixing before a production pilot. The other four can be worked on during it.
What to do if the answer is not yet
Most items on the Part 2 list are configuration and documentation work: issuing API credentials, exporting asset and user context, and writing down the investigation standard. A workable order:
Close the access gaps from the five-incident test first, since every later step depends on the agent seeing the data.
Write the investigation standards for your highest-volume alert types.
Run the agent in parallel with your analysts for a few weeks. Record the baseline before it starts, and treat every analyst override as data about where the agent needs more context.
Widen the agent's permissions one category of action at a time, as its record supports it.
Some teams that are not ready consider building their own agents instead. The survey suggests caution: 72% of AI users had tried building internal AI tools, and 46% of those projects were abandoned, never reached production, or were replaced by a commercial product.
Building a functioning prototype is only a small chunk of the work. Most of the work is engineering and maintenance of integrations that take weeks to build but break when a vendor changes an API; rate limits to work around; model deprecations every six to nine months that force a full round of evals, guardrails, and prompt injection testing; and audit trails explaining why each alert was closed.
How Prophet Security Works
Prophet Security is the leading AI SOC platforms for enterprise SOCs, recognized in Rising in Cyber 2026, an honor voted on by more than 150 CISOs and security leaders. Its platform, Prophet AI, works from the stack a team already runs. First-generation AI SOC tools stopped at alert triage. Prophet AI enables an agentic SOC, with specialist agents for investigation, threat hunting and detection engineering.
Prophet AI SOC Analyst investigates every alert at every severity, around the clock, with the depth of a senior analyst. It queries SIEM, EDR, identity, cloud and email tools directly and records every question, query and piece of evidence behind a determination, so an analyst can rerun any query and check the work. It takes response actions only within permissions the customer sets, with human approval as the default.
Prophet AI Threat Hunter is built to answer "are we impacted?" It keeps a profile of each organization's industry, technology stack and the threat actors that target it. When a severe new threat emerges, hunts for it run automatically in the background. Scheduled hunts, including hunts against coverage gaps and questions the team writes in plain language, run on the cadence the team sets. Suspicious leads go to the SOC Analyst for a full investigation.
Prophet AI Detection Engineer takes on the detection engineering work that waits for spare time. It keeps a live MITRE ATT&CK coverage map built from the organization's own investigations, showing which techniques are covered, which have gone quiet and which are dark. It builds and tunes detections from what investigations, hunts and coverage gaps reveal, writes them in the rule language of the SIEM or tool they run in, and backtests each one against the organization's own history. Each change arrives as a reviewable proposal with its rationale and backtest results, and by default nothing reaches production until the team approves it.
Each product's findings feed the others. Investigations show which detections are noisy and where coverage is thin, hunts look in those gaps, and what the hunts find becomes new detections. The team teaches Prophet AI in plain language, and that guidance shapes how investigations run, how hunts are scoped and how detections are written. Customer data never trains its models, and the data plane can run inside the customer's own VPC.
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.
from The Hacker News https://ift.tt/k5qHcjO
via IFTTT
Last week, Google and industry partners dismantled the XCPE backdoor which enrolled more than 1.3 million set-top boxes into a botnet. We assess with high confidence that the backdoor and botnet were intentionally developed, deployed, and operated for financial gain by Videostrong Technology Co., an Android Original Equipment Manufacturer (OEM) and Original Device Manufacturer (ODM).
Videostrong monetized the backdoor by selling access to criminal affiliates and loading those affiliates’ malware modules onto infected devices. These secondary modules were conducting ad-fraud; silently enrolling infected devices into residential proxy networks; and loading additional malware onto XCPE-compromised devices. We also took action to disrupt the command and control (C2) domains that operate these affiliate modules. Because these affiliates each have diversified distribution channels for their modules beyond XCPE, we assess that taking down their C2 domains will sever access to at least 10 million additional compromised devices.
We found this malicious software built directly into many different device models and brands over multiple years, supported by dedicated infrastructure and constantly evolving configurations to evade detection and manage their affiliates. We believe this campaign wasn’t an isolated rogue insider or a development oversight. As a result, Google has cut ties with Videostrong and banned them from making devices with preloaded Google apps.
Google requires OEMs go through a comprehensive suite of compatibility and security tests to ensure a consistent and safe user experience across the Android ecosystem. However, Videostrong employed obfuscation techniques to exploit a gap in our tests and load malicious code after the device's first boot. As a result, Google has implemented changes to its existing review process to better safeguard against similar activity in the future. A device manufacturer intentionally infecting their users with malware is an unacceptable breach of trust, and represents a serious risk to those users. Without users’ knowledge or consent, infected devices were offered as a distribution mechanism for a wide array of criminal actors. This led to a variety of malicious activities being conducted on and through the devices, including ad-fraud, data exfiltration, and routing malicious network traffic through the devices.
We worked closely with Japan’s National Police Agency, Lumen, HUMAN Security, Plume, Synthient, and TrendAI to analyze this malware ecosystem and disrupt its operations.
While we expect this disruption to have a significant effect on these criminal operations, this is not the end of our work combatting malicious activity. Backdoor operators, ad-fraud rings, and residential proxy providers operate as an interconnected supply chain. Point-in-time disruptions are a critical tool to protect our users, but lasting disruption in this fluid ecosystem will require continued targeting of this infrastructure.
Google undertook the following actions to support disruption of the XCPE botnet:
Legal action to take down the domains and servers Videostrong used to control the botnet and install malware modules
Legal action to take down C2 domains used by over a dozen malware families loaded as modules via this backdoor
Banned Videostrong and any future subsidiaries or affiliates from building and selling certified Android devices in the future, or supplying software to other certified vendors
Implementing improvements to how we ensure the integrity of firmware on certified Android TV devices
Overview
The x.cpe network was built for ongoing profit. By giving malware affiliates backdoor access, the operators conspired to monetize these devices long after purchase.
Figure 1: XCPE malware overview
Malware
Since at least late 2024, Videostrong has evolved its pre-installed malware from simple single-stage droppers into a modular, three-stage architecture designed for resilience and multi-tenant monetization:
Primary Backdoor: Operating at the android.uid.system privilege level, x.cpe (running as com.oemservice in some builds) is preloaded in the firmware partition. If uninstalled by a user, it automatically reinstalls from the /oem/ partition upon reboot, maintaining persistent system-level access. Its main function is to establish and facilitate communications between the C2 server and the loader and execution engine.
Loader and Execution Engine: To evade security scans, x.cpe acts primarily as the C2 communicator and offloads module execution to an external loader, com.abc.nexus. This file employs native anti-analysis utilities to thwart sandbox detection, and configures and initializes the monetization modules. Most recently, com.abc.nexus has itself been phased out in favor of using more tailored dropper malware that loads and executes single modules.
Monetization Modules: Videostrong monetizes its backdoored devices by loading monetization modules which are developed by entities other than Videostrong that act as affiliates. These modules are deployed as native ELF daemons, embedded SDKs compiled directly into the com.abc.nexus DEX bytecode, or are fetched as secondary APKs from the malware staging infrastructure. The loaded modules transform infected devices into residential proxy exit nodes (e.g., Linkfog, AppSalt, NetNut), ad-fraud engines (e.g., CBOXTV, HiddenView), or execute additional backdoors that load even more monetization modules (e.g. Moyu, Spirit).
Infrastructure
Command and Control: The botnet uses a two-stage C2 process. It first initiates HTTP POST requests to fetch dynamic configuration settings, geolocation data, and STUN server parameters. It then establishes a persistent, real-time Message Queuing Telemetry Transport (MQTT) connection to receive instructions for silent app installations, arbitrary shell commands, screen captures, and network reconnaissance. MQTT is a lightweight, publish-and-subscribe network protocol designed for low-bandwidth, high-latency, or unreliable remote networks.
Malware staging infrastructure: Additional monetization modules as well as various shell scripts and legitimate applications are hosted remotely and downloaded by infected devices upon command from the operator via the MQTT broker. A significant majority of these files are hosted as Github releases on operator-owned Github pages. Other files are hosted on operator-controlled servers and file hosting sites.
Malware Deep Dive
Backdoor Initialization
The infection chain begins with a stub package (called x.cpe in some builds and com.oemservice in others) preloaded in the system partition of the firmware and running at the android.uid.system privilege level. This stub has limited functionality. Upon boot, it checks the device's oem/ directory for the corresponding x.cpe package and initiates installation into the /data/app/ directory as outlined below.
To maintain inter-process state across the firmware ecosystem, x.cpe exports two ContentProviders, which expose structured configuration tables storing runtime parameters, device identifiers, proxy configuration blobs, and execution flags accessible by co-installed system applications. This enables other apps in Videostrong’s ecosystem, such as their YokaTV Player streaming software, to fetch configuration parameters provided by the C2 server mentioned below.
C2 Configuration
The malware utilizes a two-stage communications protocol. It first fetches initial bootstrap configurations via an HTTP request, followed by a persistent MQTT subscription to receive commands and module download instructions.
To dynamically derive the HTTP C2 bootstrap server, it follows the following routine:
Queries content://com.release.debug.provider/configs for private_url via x.cpe.util.ExtraReadUtils.
Queries the Android system property to determine if ro.mecool.device is true.
If true, it defaults to http://mcstb.anyevonline.com:8000
If false, it dynamically generates the following: http://stb[AndroidVersion][Type].anyevonline.com:8000.
Using the selected hostname, the client makes an HTTP POST request with an AES-encrypted JSON object containing hardware telemetry (SN, MAC, model, firmware version) to the following endpoints:
/router/config/mqtt: This endpoint provides MQTT broker details (including Broker Hostname, TCP Port, Authentication Tokens/Passwords, and the specific Topic structure: /device/{model}/{chipId}/{action}. After receiving this data, the device initiates a persistent, real-time socket connection to the MQTT broker.
/router/config/acs: This endpoint response returns URLs for ip-api[.]com and a Google STUN server to enable the malware to identify geolocation and public IP and port mapping to traverse network address translation (NAT) boundaries. It also returns a URL (http://ott.szbboys[.]com:8000/cpe/file/upload for uploading files, logs, or diagnostic dumps from the device, and returns flags to configure ad modules (adBwmActive, adDevourUse, adDevourCode), and to enable or disable core malware modules.
/router/config/app: This endpoint provides module-level configs, including server mappings and parameters, which x.cpe decrypts and passes to a SQLite ContentProvider named ShareProvider (com.oem.share.provider). By exposing this inter-process data interface, x.cpe enables modules to retrieve up-to-date upstream infrastructure parameters (such as URLs for additional configs, user manuals, etc).
MQTT Capabilities
Following initial configuration, persistent real-time C2 communication is managed by the MQTT library (x.cpe.mqtt.MqttUtils). All identified samples analyzed to date utilize a single broker hostname, mqtt.szbboys[.]com.
Specific MQTT topics are mapped to specific actions, including:
Silent Application Installation: Fetches remote APKs to a temporary directory.
Disable Google Play Protect: To bypass security, AppUtils.disablePackageVerify() targets the global setting "package_verifier_user_consent" via Settings.Global.putInt and sets it to -1, disabling Google Play Protect app verification.
Arbitrary Shell Execution: Executes remote commands via sh under system UID privilege level. Results are published to the MQTT broker.
Shell Script Execution: Downloads and executes shell scripts via x.cpe.util.RunCmds.
Remote Desktop Monitor & Screen Capture: Utilizes android.app.Instrumentation.sendKeyDownUpSync() to inject keycodes and Java reflection on hidden APIs (android.view.SurfaceControl.screenshot / SurfaceControl$ScreenshotHardwareBuffer) to continuously capture the screen, compress to JPEG, and publish over MQTT.
Network Reconnaissance: Invokes embedded binaries (libtraceroute.so) to fingerprint the victim network, and perform standard ping tests. The binaries also perform robust AS-lookup WHOIS routing queries.
Our analysis of the C2 data indicates the preponderance of interactions with victim devices were related to module install, uninstall, and configuration actions. We also observed Videostrong operators executing sensitive actions on the device, including capturing live screenshots; injecting keystrokes; exfiltrating sensitive data including account information, device information, package inventories, and system logs; and executing shell scripts and commands, including to establish reverse shells on devices.
Loader and Execution Engine Details
Earlier versions of x.cpe directly embedded malicious monetization modules. In late 2024 – possibly as a response to earlier Google enforcement related to BadBox – Videostrong removed malicious modules from x.cpe and introduced a separate malicious package they developed, com.abc.nexus, which x.cpe routes instructions and data to via Inter-Process Communication (IPC). Modern variants of x.cpe facilitate C2 communications but pass configuration parameters, module updates, and other payloads to com.abc.nexus as the execution engine. We believe the actor may have evolved the malware in this way in an attempt to ensure x.cpe could remain undetected.
Upon boot, com.abc.nexus.broadcast.BootReceiver broadcasts the com.abc.nexus.data intent, bootstrapping com.abc.nexus.service.CoreService. Within CoreService.onCreate, the application performs maintenance and persistence tasks. The main logic sets up a listener through RemoteMessageHandler for IPC communications from x.cpe,and parses JSON payloads received from it.
After these steps, CoreService initializes the monetization modules. com.abc.nexus services extract and orchestrate a series of nested native libraries and dynamically downloaded secondary payloads which vary significantly based on sample. Many versions of com.abc.nexus come preloaded with four or more embedded modules, while other versions contain as few as one. The most common malware modules include TitanService, BwmService, AdtimeService, lb102Service, and LinkfogService (sometimes called AgentService). Discussion of these and other modules can be found in the monetization modules section.
Persistence and Evasion
The malware operators implement a number of mechanisms to establish persistence and thwart detection and analysis.
As a system preload, x.cpe cannot be removed by the user. If x.cpe is uninstalled from /data/app/, upon reboot the x.cpe service BootReceiver follows the same routine outlined above and reinstalls the package.
The backdoor is able to silently download additional files to the device and execute them without user consent because it first wipes user consent configuration on the device and then disables Google Play Protect:
public static void disablePackageVerify() {
PreferenceUtils.setPackageVerifyFromUser(CPEApp.instance, true);
AppUtils.setPackageVerify(-1); // Actioning a bypass against GPP evaluation
}
Figure 2: Disabling Google Play Protect
In many variants of com.abc.nexus, we observed the extraction of a sophisticated anti-analysis and process hardening utility libseccomp_guard.so, which runs prior to the initialization of malware modules, to ensure they remain protected from automated sandboxes and security instrumentation. It filters system calls to prevent the pausing or termination of individual threads, denies cross-process interference to ensure isolation, and prevents the spawning of child processes.
Evolution
Since August 2026, new dropper packages have been installed via the MQTT channel, which appear to be synchronized with the mass-uninstallation of com.abc.nexus across the botnet. We assess this may represent a new evolution of the malware to further evade detection. These new packages are disguised as Android system applications, with names such as com.android.system.ntp and com.android.sso.auth.handler. Where com.abc.nexus could act as a general purpose loader and execution engine (executing instructions passed to it from x.cpe), these packages instead install single monetization modules (such as AppSalt). Multiple variants of these packages extract a native ELF file, libexploit.so, which in turn executes functions nativeAdbRoot() and nativeAdbShell(). These functions restart the local adbd service as root, and initiate an ADB shell connection. Following this, the app uses the connection to install itself in the system partition. The system partition is remounted as read-write and the payload replicates itself to a newly minted directory in /system/priv-app/ and creates an XML file at /system/etc/permissions/privapp-permissions-<app name>.xml. This file grants the malware android.permission.INSTALL_PACKAGES and android.permission.REBOOT.
The app configures the malware modules through hardcoded configuration parameters, and does not listen for x.cpe IPC messages. The app itself is controlled by the operators via shell scripts pushed via the broker and executed by x.cpe. These include setting the property persist.networkstack.uninstall (which, when read by the app, triggers uninstallation and cleanup), persist.networkstack.skip_system_install (which skips system installation, forcing it to remain running in /data/app/), and persist.networkstack.install_time (which implements timestomping, overriding the default timestamp of the app to align with the other packages installed in the system directory).
Botnet composition
The botnet is globally dispersed, with certain concentrations possibly implying market penetration for the brand distributor.
Figure 3: Global distribution of x.cpe
While the overwhelming majority of the infected devices in the XCPE botnet are Android TV set-top boxes, we observed a number of other infected Android-based IoT devices, including telehealth devices, karaoke machines, and digital signage devices.
Monetization
x.cpe loads a variety of malicious modules for monetization. Most often the modules are associated with residential proxy services and bandwidth sharing, but we've also observed ad fraud modules. Given that a single device may be running multiple modules providing the same or similar functionality (e.g., as many as three residential proxy SDKs installed on a single device) it is clear that Videostrong seeks to monetize every infected device to the greatest extent possible.
Services are loaded by com.abc.nexus via three methods:
Native Daemons: Native ELF binaries prepackaged with com.abc.nexus, which are unpacked to data directories and spawned as background processes with system/root privileges.
Embedded SDKs / Services: Java/Kotlin SDKs compiled directly into Nexus and invoked via Android Service lifecycles or IPC broadcast triggers.
Dynamic Droppers & Secondary APK Installers: Downloader function that pulls remote native ELFs or secondary standalone APKs and invokes system package managers. Nexus receives messages from x.cpe directing it to download specific modules.
Malware modules loaded via the backdoor include the following:
Residential Proxy / Bandwidth Sharing Modules
LINKFOG
Com.abc.nexus’s LinkfogService unpacks a Go binary named lw_android_agent from assets/ to local app storage and supplies it with vendor parameters. This service silently turns infected devices into residential edge computing and PCDN proxy exit nodes. It connects to FRP reverse tunnels, and uploads bandwidth accounting metrics to Linkfog API backends. Linkfog (operated by Beijing Linkfog Technology via 点心云 / Dianxinyun) brands itself as a “Peer-to-Peer Content Delivery Network”.
Jaguar
The com.abc.nexusAdtimeService extracts libjaguar.so from assets/. The file is an unobfuscated 32-bit ELF binary written in C, compiled as a native Android binary. It utilizes JNI (Java Native Interface) to initialize its core routines, dynamically derives a ChaCha20 decryption key via ARM NEON SIMD instructions to decode heavily obfuscated configurations , and establishes an encrypted C2 channel. Upon successful registration, the C2 responds with JSON configuration specifying proxy endpoints. The proxy command loop x_ctrl_do_ctrl_msg delegates proxy operations based on incoming JSON variable commands, and is capable of both TCP and UDP relay.
AppSalt / Honeygain
AppSalt SDK is the residential proxy SDK owned by Honeygain, which is in turn owned by Oxylabs. com.abc.nexus.service.CoreService initializes Appsalt SDK. First, the application obtains an Appsalt SDK API key from a native library libnative_keys.so by calling its getAppsaltKey() function. Appsalt SDK is initialized without displaying a consent screen - instead it explicitly calls the optIn() method which sets a consent flag without displaying any user interface. During Appsalt SDK startup it checks the application's installation source and stops execution if the application was installed from the official Google Play Store.
Once Appsalt is successfully initialized it establishes a WebSocket connection with the primary command and control domain. Appsalt uses JSON-formatted messages for initial check-in (registration) and heartbeat requests. Appsalt command and control servers use MessagePack formatted messages to issue commands pertaining to proxy operations. Appsalt SDK is configured with an initial set of domains that act as proxy gateways. The list of proxy gateways can be updated by the command and control server. The device establishes UDP / QUIC connections with these gateways.
BWM / IPWeb
This residential proxy and bandwidth-sharing node is implemented through the com.abc.nexus.service.BwmService component (sometimes named com.abc.nexus.service.SN4Service) and its associated SDK. Upon initialization, it secures itself within an isolated sandbox environment, captures device telemetry, and registers with a remote server over UDP. From this C2, it receives instructions to initiate a Java NIO TCP multiplexed proxy tunnel. The service functions to route arbitrary traffic through the infected device on behalf of a remote threat actor.
GaGaNode
GaGaNode is the first-party SDK owned by residential proxy operator IPCola. It connects over TCP to a primary C2 server and sends heartbeat beacon data over HTTP POST to a separate server. The SDK both contains its own proxy relay functionality, and it initializes additional proxy SDKs from affiliates. Upon device registration to the C2, com.gaganode.sdk.node.endpoint.a receives incoming packets from relay servers and places them in queue for the client to read and proxy through its exit node socket. The service manages multiple proxy sessions at once (referred to as clients), and each client has its own tcp/udp queue for messages.
We observe GaGaNode initializing PopaNet/NetNut and EarnFM Fleet residential proxy SDKs. GaGaNode/IPCola is thus likely able to further monetize its SDK and offer these affiliates access to the infected exit nodes.
NetNut / Popanet
Popanet is a residential proxy SDK developed by NetNut, a residential proxy operator. The GaGaNode module initiates the Popanet SDK (io.popanet.Popa). This malware is identical to the malware described in our previous disruption of NetNut. All C2 infrastructure used by Popanet samples connected to x.cpe was taken down as part of the earlier Netnut disruption.
Traffmonetizer
The Traffmonetizer SDK is initialized inside the primary background service com.abc.nexus.service.CoreService. CoreService operation depends on the availability of policy JSON provided by the XCPE backdoor via IPC. Before calling Traffmonetizer SDK initialization methods, the application obtains a Traffmonetizer SDK API key from the native library libnative_keys.so by calling its getTraffmonetizerKey() function.
Traffmonetizer functionality is split between two components where the Android SDK acts as a state machine which handles native library callbacks through asynchronous event dispatchers. ServiceBloc monitors connection status updates from the native callbacks and ConnectivityBlocmonitors Wi-Fi and mobile data network changes.
Traffmonetizer native library initialization and configuration is followed by a call to baseClientStart() which establishes a WebSocket connection to a C2 server. Traffmonetizer uses a single WebSocket (TLS) connection to the command and control server to multiplex control messages and tunneled connections (supports both TCP and UDP). Traffmonetizer also supports “Content Delivery” tunneling which allows nodes to tunnel bandwidth-intensive traffic.
EarnFM
EarnFM is a residential proxy provider, and Fleet SDK is the provider’s SDK that enrolls devices as exit nodes into the proxy network. In com.abc.nexus, FleetSDK is initialized by com.gaganode.sdk as mentioned above. FleetSdk then loads native binary libfleetshare.so.
FleetSDK establishes a persistent WebSocket connection with its primary C2 server for routing arbitrary network traffic. Incoming tasking frames are received over the WebSocket channel and processed in a continuous loop. Messages contain structured JSON commands instructing the daemon to connect to specific remote hosts, with support for both TCP and UDP.
Backdoor Modules
Spirit
Spirit is a dynamic code loading backdoor. Spirit employs multiple stages. The first stage payload fetches device information (hardware, operating system, and manufacturer/brand information and geolocation), posting it over HTTP to a hardcoded C2 server, and fetches a list of additional modules to download from the server. The second stage communicates with a separate server, and is used for tasking, config sync, module retrieval, heartbeats, and reporting. We have observed Spirit loading a significant amount of additional malware monetization modules, including some of the families already directly loaded by com.abc.nexus.
Moyu
Moyu is a 3-stage backdoor previously observed as part of the BadBox enterprise. On x.cpe-backdoored devices, we observed it initialized by com.abc.nexus.service.DevourService. The first stage is an offline dropper that reconstructs and loads an embedded second stage. Stage two polls an update C2 to download, decrypt, and load the third stage. Stage three implements a backdoor with hidden Double-WebView click/conversion fraud, persistent clipboard hijacking, and secondary dynamically loaded JAR execution and a separate residential proxy trojan.
Bird
Bird is a 2-stage backdoor previously tied to the BadBox enterprise. Stage 1 beacons a device and analysis-environment profile to its C2 server and, when the server approves, downloads, decrypts, and loads the Stage 2 JAR. Stage 2 implements a dynamic code loading backdoor (two plugin loaders plus a C2-driven reflective method invoker), a separate downloader (silent APK installation and Accessibility-driven Google Play installs), and ad abuse (lockscreen ads, overlays, browser launches).
Fission
Fission is a dynamic code loading (DCL) backdoor embedded within standard video applications (e.g., com.newtv.cboxtv). Upon initialization, the first stage plugin contacts its C2 server to download additional modules. The decrypted second stage payload fetches execution targets and tracking URLs from the C2. The request sends an unencrypted POST request with tracking metrics from the internal DeviceManager.
The payload we observed was configured to commit ad fraud. Rather than rendering visible advertisements in a WebView or UI component, the Stage 2 plugin executes headlessly in the background. The module queries ad server endpoints in the background to retrieve ad placement responses, parses out both primary impression beacons (pvm) and third-party tracking monitor URLs (pvtpm), and immediately fires HTTP GET requests to each tracking endpoint to register a fake ad view without displaying creative content.When executing inside specific smart-TV application stores (com.changhong.appstore or com.tcl.appmarket2), the plugin initializes and triggers the ad SDK directly to report synthetic ad exposures.
Ad-Fraud
HiddenView
We observed HiddenView loaded remotely from the attacker’s Github channel as com.ota.service. It is a standalone ad fraud application capable of running in the background using a transparent window overlay, using hidden WebViews to load targeted web pages and simulate user interaction (scrolling, clicking, typing, media playback), playing media unattended, and capturing the user’s screen.
How the pieces come together
Configuration messages pushed via MQTT (action ext/lib/config) demonstrate how x.cpe, com.abc.nexus and various monetization modules function together.
Upon registration, subscribed devices receive a ext/lib/config message, which contains configuration parameters for malicious plugins. This includes:
x.cpe passes on these configuration parameters to com.abc.nexus for the given module on the device. Devices report bandwidth usage and alarms back to serverPool to stay within the configured constraints.
When com.abc.nexus acknowledges receiving the bundle, x.cpe immediately publishes ext/lib/config/reply back to the MQTT broker:
"code": 0,
"msg": "success",
"data": "received data success and applying",
"async": true,
"immediately": false
Figure 8: x.cpe response payload
Infrastructure
As previously mentioned, devices first connect to various endpoints on *.anyevonline[.]com for initial bootstrap, registration, and configuration. Earlier malware versions used various hostnames of {*tms | *ott | *ota}.szbboys[.]com for the same purpose.
While earlier versions of the malware used HTTP for C2, and then a blended C2 approach with both HTTP and MQTT, static analysis of current versions indicate they exclusively send/receive C2 communications via MQTT. A single MQTT broker orchestrates all MQTT C2 communications for samples we’ve identified. Hostname mqtt.szbboys[.]com is resolved by hosts 219.134.163[.]210 and 219.134.163[.]211. It listens on non-standard MQTT ports 3885-3887.
The malware constructs OkHttp requests for file downloads after tasking via the MQTT broker. Files are hosted on several services:
Several Github release pages
The filemail[.]com file sharing service
Two operator-controlled servers hosted on IPs 38.145.197[.]135 and 23.94.49[.]57
Netflow telemetry on the broker nodes (219.134.163[.]210/.211) indicates that while infected devices communicate over ports 3885–3887, operators likely manage the broker and dispatch tasking via interactive HTTP REST API (port 8082), WebSocket (port 8083), and EMQX web administration console (port 18083) sessions originating from non-bot IP space.
Call to Action
While we believe our actions have seriously impacted over a dozen malicious actors, the underlying illicit market is resilient. Backdoor operators, ad-fraud rings, and residential proxy providers operate as an interconnected supply chain, and when one component is disrupted, operators quickly pivot to new loaders or rival monetization SDKs. Creating lasting change requires accountability across the hardware supply chain, the residential proxy industry, and the broader technology ecosystem.
Accountability and Reform
A device manufacturer intentionally infecting their users with malware is an unacceptable breach of trust. By turning everyday hardware into persistent beachheads for criminal affiliates, Videostrong prioritized illicit post-sale recurring revenue over the safety and privacy of its users. Downstream hardware brands, white-label resellers, telecommunications providers, and online e-commerce marketplaces also share responsibility for closing this vector. Retailers and distributors should require independent security audits from Original Design Manufacturers (ODMs) and swiftly delist manufacturers implicated in supply-chain abuse.
Residential proxy providers have been able to flourish under the guise of legitimate businesses. While some providers may claim to behave ethically and only enroll devices with the clear consent of consumers, any claims of "ethical sourcing" must be backed by transparent, auditable proof of user consent. In our analysis, these proxy operators only seek consent when they are forced due to platform policy and enforcement. Silent opt-in without user consent remains the most prevalent means by which devices are turned into exit nodes.
Empowering and Protecting the Consumer
Residential proxies are an understudied area of risk for consumers, and more can be done to raise awareness. Consumers should be extremely wary of applications that offer payment in exchange for "unused bandwidth" or "sharing your internet." These applications are primary ways for illicit proxy networks to grow, and could open security vulnerabilities on the device’s home network. We urge users to stick to app stores you trust, review permissions for third-party VPNs and proxies, and ensure built-in security protections like Google Play Protect are active.
Consumers should only purchase connected devices, such as set-top boxes, from reputable manufacturers. Our Android TV website provides the most up-to-date list of partners.
Industry Collaboration
We encourage mobile platforms, ISPs, online marketplaces and other tech platforms to continue sharing intelligence and implementing best practices to identify malicious backdoors, illicit proxy networks, and other harmful software and limit their harms.
