フィーチャのランサムウェアによるサイバー攻撃、GitHubリポジトリ144個の外部コピーを確認|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年05月14日更新日時: 2026年05月14日

SEOディスクリプション：フィーチャ株式会社は、ランサムウェア被害に関する最終報で、32台への不正アクセス、13台のランサムウェア感染、GitHubリポジトリ144個の外部コピーを確認したと公表しました。添付の犯行声明とみられる投稿では、同社のGitHubコードや顧客別プロジェクトコードに関する主張も確認されています。公表内容と情報システム部門が確認すべき対策を解説します。

1 フィーチャがランサムウェア被害の調査結果を公表
2 添付の犯行声明とみられる投稿で確認できる内容
3 公式発表と犯行声明を照合して分かること
4 GitHubリポジトリ流出のリスク
5 復旧状況と継続監視
6 再発防止策として示された対応
7 情報システム部門が確認すべきポイント
8 リポジトリ流出時に優先すべき対応
9 ログ保全と調査可能性の確保
10 出典

フィーチャがランサムウェア被害の調査結果を公表

フィーチャ株式会社は2026年5月13日、同年2月に公表していた同社サーバーにおけるランサムウェア被害について、外部専門家の支援を受けた調査が完了したとして、調査結果と再発防止策を公表しました。

同社によると、不正アクセスおよびランサムウェア感染が確認され、不正アクセスが確認されたサーバー等は合計32台、そのうち13台がランサムウェアに感染していました。また、攻撃者が同社の1台のサーバー上に集約したファイルを、ファイル転送ツールを用いて攻撃者管理のクラウドストレージであるOneDriveへ送信したことも確認されています。

添付の犯行声明とみられる投稿で確認できる内容

セキュリティ対策Labでハッカーフォーラムを確認すると、2026年4月9日付で投稿タイトルには、フィーチャ株式会社のドメインとみられる表記と、同社のGitHubコード全体を示唆する文言が含まれています。

投稿本文では、同社のGitHubコードプラットフォームには、開発コードに加えて顧客固有のプロジェクトコードが含まれると主張されています。また、表示されている範囲では、SDK基盤や顧客別の派生プロジェクト、複数の顧客固有ブランチに言及する内容が確認できます。

ただし、この投稿は攻撃者側または第三者側の主張であり、記載内容がすべて事実であるとは限りません。

公式発表と犯行声明を照合して分かること

フィーチャの最終報では、GitHubサーバーから144個のGitHubリポジトリが外部にコピーされたことが確認されています。また、窃取された可能性のある情報の一部について、複数の一般サービスサイト上での掲載が確認されていると説明されています。

さらに、同社データに関連する情報および外部ストレージへのリンクが、一般のWebブラウザから閲覧可能なフォーラム上に掲載されていることも確認されています。この点は、添付画像で確認できるフォーラム投稿の存在と整合します。

一方で、フィーチャはURL等の詳細について、二次被害防止および捜査・封じ込めの観点から公表していません。

また、同社が把握していたものとは異なる外部ストレージへのリンクが第三者により公開されていたことも確認されていますが、当該ファイルはパスワードで保護されており、現時点で内容の確認や第三者による実質的な取得事実は確認されていないとしています。

GitHubリポジトリ流出のリスク

GitHubリポジトリの外部コピーは、単にソースコードが見られるという問題にとどまりません。リポジトリには、製品の設計思想、アルゴリズム、設定ファイル、CI/CD設定、依存ライブラリ、内部ツール、開発履歴、顧客別カスタマイズ情報が含まれる場合があります。

添付の犯行声明とみられる投稿では、顧客固有のプロジェクトコードや顧客別の派生プロジェクトに関する主張が確認できます。この主張が事実であれば、影響は自社製品コードだけでなく、顧客ごとの実装、検証環境、個別仕様、共同開発情報に及ぶ可能性があります。

特に注意すべきなのは、過去コミットに含まれるシークレットです。現在のコードからAPIキーや接続文字列を削除していても、Gitの履歴に残っている場合があります。リポジトリが外部コピーされた場合、現行ブランチだけでなく、履歴全体を対象にシークレットスキャンを行う必要があります。

復旧状況と継続監視

フィーチャは、被害拡大防止措置および復旧対応を進め、現在は通常業務を再開していると説明しています。また、外部公開状況の確認およびダークウェブ監視を含む継続的なモニタリングを実施しています。

今回の添付画像のような投稿が確認されている場合、継続監視の重要性はさらに高まります。攻撃者は、最初に一部情報を公開し、その後に追加情報を分割して掲載したり、別のフォーラムや外部ストレージへ再投稿したりすることがあります。

監視では、社名、ドメイン、製品名、リポジトリ名、顧客名、プロジェクト名、メールアドレス、ファイル名、ハッシュ値などを手掛かりに、外部公開状況を継続的に確認する必要があります。ただし、公開データの取得や拡散は二次被害につながるため、確認範囲と証跡管理は慎重に行う必要があります。

再発防止策として示された対応

フィーチャは、本件を重大なセキュリティインシデントとして受け止め、侵入防止、社内拡散防止、権限管理、端末対策、監視体制の各段階で多層的な対策を実装・強化しているとしています。

主な取り組みとして、外部接続基盤の刷新、多要素認証の導入、不審ログイン監視、ネットワーク分離等による社内拡散防止、管理者権限分離などのアカウント管理強化、EDRの導入、外部SOCを含む監視体制の強化を挙げています。加えて、インシデント対応プロセスや社内ルールの整備・見直しも継続するとしています。

これらの対策は、ランサムウェア対策として基本である一方、導入していても運用が不十分だと効果が限定されます。特にGitHubリポジトリの外部コピーが確認されている以上、端末やサーバーだけでなく、ソースコード管理環境、CI/CD、開発者アカウント、シークレット管理まで含めた見直しが必要です。

情報システム部門が確認すべきポイント

同様の事案に備えるうえで、情報システム部門はまず外部接続基盤を棚卸しする必要があります。VPN、ファイアウォール、リモートデスクトップ、保守用接続、委託先接続、クラウド管理画面など、社外から到達可能な経路を洗い出し、多要素認証、アクセス元制限、脆弱性対応、ログ監視が適切に行われているか確認すべきです。

次に、GitHubやGitLabなどのソースコード管理環境を、開発部門任せにしないことが重要です。リポジトリへのアクセス権限、退職者や委託先アカウントの残存、個人アクセストークン、SSH鍵、GitHub Actions Secrets、外部アプリ連携、監査ログの保存期間を確認する必要があります。

特に、顧客別コードや共同開発コードを扱う組織では、顧客ごとにリポジトリや権限を分離し、必要最小限の開発者だけがアクセスできる設計にするべきです。すべての顧客プロジェクトを同一基盤・同一権限で扱っている場合、1つの侵害が複数顧客へ波及する恐れがあります。

リポジトリ流出時に優先すべき対応

GitHubリポジトリの外部コピーが確認された場合、最初に行うべきなのはシークレットの確認とローテーションです。APIキー、クラウドアクセスキー、DB接続文字列、SSH秘密鍵、証明書、Webhookシークレット、GitHubトークン、CI/CDトークン、SaaS連携トークンが含まれていないかを確認します。

次に、過去コミット履歴を含めたスキャンが必要です。現在のコードに秘密情報がなくても、過去の履歴に残っていれば、外部コピーされたリポジトリから復元される可能性があります。見つかった認証情報は、削除ではなく無効化またはローテーションが必要です。

さらに、顧客別コードが含まれる場合は、顧客ごとに影響可能性を整理し、必要に応じて個別連絡を行うべきです。顧客側で使うAPIキー、証明書、接続先、テスト環境、共通認証情報がコード内に含まれていた場合、顧客側の対応も必要になります。

ログ保全と調査可能性の確保

フィーチャの公表では、関連ログがランサムウェアで暗号化されていたことや、攻撃者によるログの消去により、原因や窃取ファイルの全容を断定できない制約が示されています。

これは多くの企業にとって重要な教訓です。ログが攻撃対象システムの中だけに保存されている場合、攻撃者に削除されたり、ランサムウェアに暗号化されたりすると、調査に必要な証跡が失われます。

情報システム部門では、認証ログ、VPNログ、ファイアウォールログ、EDRログ、ファイルアクセスログ、GitHub監査ログ、クラウド監査ログを、攻撃者が容易に改ざんできない外部のログ基盤へ転送しておく必要があります。初期侵入から発覚まで数か月かかる事案を想定し、ログ保存期間も数か月単位で設計することが望まれます。