Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
本文の内容は、2026年6月25日に Crystal Morin が投稿したブログ (https://www.sysdig.com/blog/the-fulcrumsec-playbook-how-to-detect-and-stop-the-group-behind-the-novo-nordisk-breach) を元に日本語に翻訳・再構成した内容となっております。
FulcrumSec という脅威アクターグループは先日、Ozempic および Wegovy の製造元であるグローバル製薬企業 Novo Nordisk から 1 テラバイトを超えるデータを窃取したと主張しました。この侵害のニュースは世界中で大きく報じられていますが、彼らが今年、大手組織を侵害したのはこれが初めてではありません。しかし、このグループの最近の「成功」にもかかわらず、FulcrumSec のプレイブックにはいくつかの明確なパターンが表れています。そして、パターンが存在するところには、防御側が先手を打つ機会があります。
FulcrumSec は国家支援型の脅威アクターでもランサムウェアグループでもありません。彼らは初期アクセスのためにゼロデイエクスプロイトや著名な脆弱性を追い求めることはしませんでした。その代わりに、よくあることですが、組織の何気ないミスが大規模なデータ流出につながりました。機密性の高い認証情報が漏洩したまま放置されていたのです。よくある話ですが、そこから学べることがあります。
では、FulcrumSec がどのように活動しているかについて何が分かっており、セキュリティチームはどうすれば可視性と検知を改善できるのでしょうか？
FulcrumSec とは何者で、誰を標的にするのか？
FulcrumSec は、機密データを狙ってクラウドネイティブ企業を標的とする、金銭目的の脅威アクターグループです。被害者の環境を侵害できると、このグループはそのデータを恐喝に利用します。要求が満たされない場合、FulcrumSec は窃取したデータを売却します。また、FulcrumSec の侵害には暗号化や業務妨害が一切伴わない点も重要です。彼らは自らの恐喝モデルを「窃取して締め上げる（steal and squeeze）」と呼んでいます。
「The Threat Thespians」としても知られる FulcrumSec は、少なくとも 2025 年 9 月から活動しています。現在までに、11 か国のおよそ25 の被害者を主張しており、その多くは米国に本社を置いています。標的は主にビジネスおよびコンシューマー向けサービス、テクノロジー、ヘルスケアの各セクターに分類されますが、彼らに共通する標的の優先事項は、最終的にはクラウドホスティングと不十分なアイデンティティの衛生管理です。
FulcrumSec のプレイブック
クラウド攻撃は諸刃の剣です。繰り返しやすい反面、防御側にとってはより予測しやすくなることも多いのです。FulcrumSec の戦術・技術・手順（TTP）は、これまでの侵害を通じて一貫しています。グループ自身も自らの手法についてオープンで、今年初めの LexisNexis 侵害後には技術的詳細を記したマニフェストを公開しました。つまり、いくらかの分析と積極的な取り組みがあれば、防御側には彼らを阻止する機会があるということです。
そうしたパターンのいくつかを見ていきましょう。
ステージ 1：初期アクセス
FulcrumSec は 3 つの扉のいずれかから侵入しますが、そのいずれも目新しい技術やカスタムツールを必要としません。彼らは、組織がどの扉に鍵をかけ忘れているかを探します。
扉その 1：ハードコードされた、あるいは漏洩した認証情報。 Novo Nordisk を侵害した際、FulcrumSec は本来プライベートであるべきで、おそらく忘れ去られていた2 つのインターネット公開のサンドボックスおよび開発用サブドメイン、dev.nnedl.pub.aws.novonordisk.com と datahub-sand.novonordisk.com 経由で侵入したと主張しています。それらの JavaScript には、Azure コンテナレジストリの認証情報と、数百のプライベートリポジトリにアクセスできる GitHub パーソナルアクセストークンが含まれていました。
2026 年 2 月のフィンテックプラットフォーム youX の侵害では、このグループは 2021 年から本番環境で有効だった認証情報や、ローテーションされていない JSON Web Token（JWT）署名シークレットを悪用しました。
何が検知できるか？ 認証情報の窃取は、多くの場合クラウド上での活動よりも前に発生します。したがって、シークレットが持ち出される瞬間を捉えることはできなくても、それが予期しないコンテキストで最初に使用される瞬間は捉えられます。これには、新たに有効化されたコンテナアイデンティティからの異常な API 呼び出し、通常の時間帯外や予期しない送信元 IP から使用されるコンテナレジストリの認証情報、あるいは新しい権限を使用する GitHub トークンといった挙動が含まれます。認証情報そのものは正規のものであっても、それが使用される不規則なコンテキストこそが危険信号なのです。
扉その 2：パッチ未適用のインターネット公開アプリケーション。 LexisNexis では、FulcrumSec は React Server Components における最大深刻度のリモートコード実行（RCE）脆弱性であるCVE-2025-55182（React2Shell）を悪用しました。この組織は 2025 年 12 月の公開以降この脆弱性にパッチを適用しておらず、FulcrumSec はやすやすと侵入することができました。
何が検知できるか？ これはケースバイケースで異なります。検知要件は、その性質上、ほぼすべての脆弱性で異なるからです。この場合、React2Shell は Web サーバーのエクスプロイトであるため、Web サーバープロセスからの予期しないプロセスの生成、不規則なコマンド実行、アウトバウンド接続、あるいは API 呼び出しに対してアラートがトリガーされる必要があります。
扉その 3：インターネットに公開された設定ミスのあるストレージ。 認証情報や脆弱性に加えて、FulcrumSec は設定ミスもスキャンします。実際、彼らのリークサイトには「Index of /Shame」と称するセクションがまるごと用意されています。youX から入手できた認証情報や鍵に加え、セキュリティ保護されていない MongoDB Atlas クラスタも存在しました。彼らが文書化している標的リストには、Azure ストレージアカウント、Databricks ノートブック、AWS S3 バケット、Qualtrics 環境も含まれています。
さらに、2025 年 9 月のテクノロジー企業 Avnet に対する FulcrumSec 初の確認済み侵害では、社内の営業ツールに接続された、インターネット公開で設定ミスのあるクラウドストレージサービスを通じて初期アクセスが行われました。その後、彼らは窃取した OpenAI API キーを使い、被害者の認証情報を被害者自身に対して武器化しました。
何が検知できるか？ 通常はアクセスしないアイデンティティによる、クラウドストレージのバケットやコンテナの予期しない列挙に注意してください。特に、複数のサービスにまたがるListやDescribe呼び出しが立て続けに行われる場合はなおさらです。これは偵察の典型的な例です。
ステージ 2：認証情報の収集
クラウド環境の内部に侵入し、単一の認証情報にアクセスできるようになると、攻撃者には独自の機会が生まれます。しかし、手が届く範囲のすべてを活用するには、彼らは「音を立てる」必要があります。これは FulcrumSec の侵害でも変わりません。違いは、クラウドでは、従来のラテラルムーブメントを行う攻撃者のようにネットワークを通じてピボットするのではないという点です。彼らは権限を通じてピボットします。
LexisNexis では、React コンテナを通じた最初の足がかりによって、彼らは Amazon Elastic Container Service（ECS）タスクロール（LawfirmsStoreECSTaskRole）の内部に入り込みました。このロールは、AWS アカウント内のあらゆるシークレットへの読み取りアクセス権を持っていました。この設定ミスのある単一の IAM ロールが、本番環境の Redshift、VPC データベース、Salesforce、Oracle、分析プラットフォームのマスター認証情報を含む、53 件のプレーンテキストの AWS Secrets Manager エントリを解錠しました。これは、権限昇格を一切必要としない、深刻なブラストラディウス（影響範囲）です。
Novo Nordisk については、FulcrumSec は最初の GitHub トークンを使ってアクセス可能な社内リポジトリをクローンし、追加の認証情報を掘り起こしたと主張しています。その後、彼らは 2 か月間かけて、それらの認証情報を使って Azure DevOps、GitHub、AWS、Hugging Face を横断してラテラルムーブメントを行いました。
何が検知できるか？ 単一のロールやアイデンティティから複数のサービスにまたがって行われるList*、Describe*、Get*の API 呼び出しは、クラウドの列挙を示唆する明確な手がかりとなり得ます。また、Secrets Manager を一度も呼び出したことのないコンテナアイデンティティが突然すべてのエントリを読み取る、あるいは 1 つのリージョンでしか稼働していなかったロールが新しいリージョンから API を呼び出す、といった兆候も見逃さないようにしましょう。開発者側の不規則性も検知できます。通常の CI/CD パターンの範囲を超えた大量のリポジトリのクローン、通常の稼働場所や時間帯を外れたトークンの使用、通常のアイデンティティ経路ではない環境をまたぐラテラルムーブメントなどです。
ステージ 3：データ収集
現代のクラウドネイティブ攻撃の中には、数分でエンドツーエンドに完遂できるものもあります。攻撃者は3 分で認証情報を窃取したり、1 時間未満でデータベースを外部に持ち出したりできます。しかし、FulcrumSec は派手に奪って逃げることはせず、静かに情報を蓄積していきます。これこそが、検知の隙間がある環境において彼らを危険な存在にしている点です。
Novo Nordisk での作戦は、報じられているところによれば 3 月から 6 月まで続きました。これは 2 か月を超える継続的なアクセスです。youX の侵害でも、同様に長い滞留時間がありました。FulcrumSec は必要なものを計画的に取っていきます。ソースコード、社内 AI モデル、独自のリサーチ、臨床データ、従業員記録、あるいは製造の詳細などです。被害者が問題に気づく頃には、攻撃者はすでに広範なインテリジェンスとデータのコレクションを構築し終えています。
何が検知できるか？ ここでは行動ベースラインを持つことが鍵となります。通常はそれらのリソースにアクセスしない、あるいはアクセスするとしてもその頻度や範囲ではないアイデンティティからの、データベース、オブジェクトストレージ、コードリポジトリに対する持続的で低ボリュームの読み取りといった兆候に注意してください。ワークロードの挙動とその背後にあるアイデンティティを文脈的に結びつけるランタイムの可視性は、追跡可能なタイムラインを明らかにするのに役立ちます。
ステージ 4：持ち出し
FulcrumSec は数週間かけて静かにデータを持ち出します。26 の被害者のうち 5 者だけで、圧縮された窃取データはほぼ 5 テラバイト、すなわち数十万件の機密ファイルに上ると主張されています。FulcrumSec は rclone のような正規の転送ツールを使ってデータを持ち出します。彼らがデータの移動を開始したことを示す分かりやすい侵害指標（IOC）はありません。マルウェアのシグネチャも、カスタムの C2 フレームワークも、公開された YARA ルールやファイルハッシュもありません。従来のエンドポイント型・シグネチャベースの検知では何も見えないのです。
何が検知できるか？ 通常はそれらのリソースにアクセスしないアイデンティティから、通常とは異なる時間帯に、予期しない宛先へと、クラウドストレージ、データベース、リポジトリから予期しない量のデータが移動していないかを探してください。
ステージ 5：恐喝
FulcrumSec が被害者に接触するとき、彼らは準備を整えています。ファイルの一覧、サンプルデータ、交渉のタイムラインを提示します。被害者が支払わない場合、あるいは沈黙を続ける場合、そこで FulcrumSec は公に事態をエスカレートさせます。彼らはダークウェブや公開のリークサイトに公表し、侵害フォーラムに投稿し、時には経営幹部の名前まで挙げます。そしてその後、データを個別売却に出します。
パターンが私たちに教えてくれること
文書化されたすべての FulcrumSec の作戦、そして実際にほぼすべてのクラウドネイティブ侵害にわたって、同じ構造的な欠陥が現れます。
- あるべきでない場所のコード内にシークレットが存在する。 JavaScript 内のハードコードされたトークン、リポジトリ内の認証情報、CI/CD ログ内の API キーが侵入口となります。
- クラウドアイデンティティに過剰な権限が付与されている。 AWS アカウント全体を解錠した LexisNexis の ECS タスクロールが最も分かりやすい例ですが、根底にある問題は普遍的です。サービスアカウント、コンテナロール、開発者トークンといったマシンアイデンティティは、必要をはるかに超える権限を蓄積していきます。忘れ去られた、あるいは侵害されたクラウドアイデンティティが実際にどこまで到達し得るかを見てください。それは痛手であり、あなたが思っているよりもはるかに一般的です。Sysdig 2025 Cloud-Native Security and Usage Report の Nordics 地域ハイライトによると、Nordics 地域の組織の 60% がリスクの高いサービスアイデンティティを保持しています。
- 検知の隙間が滞留時間を積み重ねさせる。 FulcrumSec はスピードを必要としません。彼らは見えないことから利益を得ているからです。クラウドアイデンティティ、リポジトリへのアクセス、ランタイムのワークロード活動に対する行動検知のない環境は、彼らに数週間を与えてしまいます。場合によっては、組織が最初の侵入を検知した後でさえ、窃取された認証情報が他のどこですでに使用されているかを把握できないこともあります。
- パッチ適用は依然として競争に負けている。 React2Shell 脆弱性（CVE-2025-55182）は、7 日間の修正期限付きで CISA KEV に掲載されていました。LexisNexis はその期限が過ぎてから 2 か月後に侵害されました。ただし、これは LexisNexis に固有の話ではありません。これはインターネットに面したアプリケーションインフラに関する体系的な問題であり、悪化の一途をたどっています。2026 年も深まった今、私たちは新たな脆弱性が公開からわずか 4 時間以内に悪用される様子を目にしています。
クラウド恐喝からどう防御するか
FulcrumSec のプレイブックはそれほど大きくありません。彼らは数十のクラウドネイティブな標的にわたって同じ隙間を特定してきました。予測可能なプレイブックは防御可能なプレイブックです。そこで、着手できるポイントを次に示します。
コードとビルド成果物からシークレットを排除する
Git のコミット履歴、CI/CD パイプラインのログ、コンテナイメージ、クライアントサイドの JavaScript を、認証情報が出荷される前にスキャンして漏洩を検出しましょう。これは一度きりの監査ではなく、継続的に行うべきです。漏洩したシークレットは侵害されたものとして扱うべきです。ローテーションは予防策ではなく封じ込めの実践です。
長期間有効なパーソナルアクセストークンや静的なレジストリ認証情報は、可能な限り、有効期間が短く、スコープを厳密に絞った代替手段に置き換えましょう。有効期限が 90 日でスコープが狭い認証情報は、広範なリポジトリアクセス権を持つ何年も前のローテーションされていないトークンよりも劇的に小さな問題です。とはいえ、絞れば絞るほど良いのです。
マシンアイデンティティのブラストラディウスをマッピングして削減する
IAM ロール、サービスアカウント、ECS タスクロール、コンテナアイデンティティ、開発者トークンなど、あらゆるマシンアイデンティティについて、侵害された場合にどこまで到達できるかを問いましょう。ほとんどの組織は、この作業を体系的に行ったことがありません。手間のかかるプロセスだからです。それでいて、そうした組織の多くは、数千から数十万ものマシンアイデンティティを保持しています。
最小権限を強制し、広範なロールをサービスごとのロールに分解しましょう。そして、法務リサーチのフロントエンドを実行しているコンテナがアカウント内のあらゆるシークレットへの読み取りアクセスを必要としないのであれば、それを取り消しましょう。
インターネットに面したアプリケーションに…より速くパッチを適用する
攻撃者は、LexisNexis が FulcrumSec に侵害されるはるか前から React2Shell を活発に悪用していました。隙間はインテリジェンスにあったのではありません。実行にあったのです。インターネットに面したアプリケーション、とりわけ認証を扱うものやクラウドロールの下で稼働しているものは、内部システムに比べて加速したパッチ適用のペースに乗せる必要があります。脆弱性の優先順位付けのスケジュールが鍵となります。
ポスチャーだけでなく、挙動を検知する
ポスチャは重要です。シークレットをハードコードしないこと、そしてロールに過剰な権限を与えないこと。しかし、積極的なポスチャー管理だけでは、FulcrumSec のような脅威グループがひとたび環境内に入り込んだ後に彼らを捉えることはできません。彼らを捉えるのは、異常の行動検知です。不規則なリージョン、呼び出し、移動、あるいはアクセスです。これらの行動シグナルは、攻撃者のツールやシグネチャを知る必要がありません。彼らの活動そのものから検知できるのです。
アイデンティティ、クラウド、ランタイムを横断して相関付ける
FulcrumSec の作戦は、コードリポジトリ、IAM、ワークロード、クラウドストレージという複数のコントロールプレーンにまたがります。1 つのレイヤーでしか発火しない検知では、物語の一部しか見えません。それはインスタンスメタデータサービスに問い合わせるコンテナから始まります。その挙動は、予期しない Secrets Manager 呼び出しを行う IAM ロールにつながり、それが異常なデータベース活動につながります。各イベントを単独で見れば、説明がついてしまうかもしれません。しかし、それらを合わせて見れば、疑いの余地はありません。
アイデンティティイベント、クラウドのコントロールプレーン活動、ランタイムのワークロード挙動を統一されたタイムラインに相関付けるセキュリティプログラムは、調査担当者に影響範囲を素早く把握する能力を与えます。それらは単にインシデントが発生したことを確認するだけでなく、ブラストラディウスがどこまで及び、何がアクセスされたかを正確に追跡します。
まとめ
すべてのクラウドネイティブな脅威アクターが、国家支援型の脅威アクターほど技術的に高度であるわけではありませんし、その必要もありません。FulcrumSec は同じ隙間を見つけ、同じミスを悪用し、数十の被害者にわたって同じプレイブックを一貫した結果とともに実行しています。Novo Nordisk の侵害は最も新しいものですが、それは LexisNexis、youX、Avnet などで彼らが行ったことと構造的に類似しています。
居心地の悪い真実は、こうした侵害が、多くの場合、クラウド環境がほとんどのセキュリティプログラムが追跡・対処できるよりも速く認証情報の負債とアイデンティティの乱立を蓄積してしまうために起こる、ということです。環境の内部に潜む攻撃者を暴き出す行動シグナルは、多くの場合ただの隙間にすぎませんが、そうしたパターンを浮き彫りにする適切な検知を導入すれば、防御側はその隙間を塞ぐことができます。