攻撃者がクラウドロギングプラットフォームを悪用して悪意ある活動を隠蔽

攻撃者は、検知を回避し侵害された環境への継続的な可視性を維持するため、クラウドロギングプラットフォームを標的とするケースが増えています。

本レポートでは、包括的な監査証跡を提供するために設計された AWS CloudTrailやGoogle Cloud Loggingなどの重要なサービスが、脅威アクターによってログの改ざん・無効化・リダイレクトに積極的に悪用されている実態が明らかにされています。これにより、セキュリティチームは事実上「盲目化」され、侵害後のステルス操作が可能となっています。

クラウドロギングプラットフォームを悪用する攻撃者

クラウドロギングシステムは、クラウドインフラ内で実行されるすべての操作の権威ある記録として機能し、SIEM、SOAR、クラウドセキュリティポスチャ管理（CSPM）ツールに不可欠なテレメトリを供給しています。

しかし、この中心的な役割ゆえに、高価値な標的ともなっています。Unit 42の研究者は、2つの主要な攻撃目的を特定しました。1つは「防御回避」であり、攻撃者が検知を避けるためにロギングを妨害または改ざんするものです。もう1つは「継続的な可視性の確保」であり、攻撃者がログを自分たちの管理下にある環境へリルートして継続的な偵察活動を行うものです。

最も単純な回避手法の一つは、ログ収集を完全に停止させることです。AWSでは、十分な権限を持つ攻撃者がCloudTrailのStopLogging APIを呼び出すことで、S3バケットへのログ配信を即座に停止させることができます。

同様に、Google Cloudでは、logging.sinks.Update権限を使ってロギングシンクを無効化することが可能です。これにより即座に可視性のギャップが生じ、防御側はリアルタイムで悪意ある活動を検知できなくなります。

もう一つの一般的な手法は、ログの保存先を削除することです。AWSのs3:DeleteBucketやGoogle Cloudのlogging.buckets.deleteといった権限を持つ攻撃者は、ログが保管されているストレージの保存先を削除することができます。これにより、進行中のロギングが妨害されるだけでなく、過去のフォレンジック証拠も破壊されます。

場合によっては、CloudTrailトレイルやGoogle Cloudシンクを削除することでログルーティングレイヤー自体を標的とし、ログをストレージに配信するパイプラインを事実上切断することもあります。

より高度な手法としては、暗号化キーを操作することでロギング機能を損なう方法があります。AWS環境では、攻撃者がログの暗号化に使用されているKey Management Service（KMS）キーを変更し、そのキーへのアクセスを無効化することができます。

その結果、設定は正常に見えるにもかかわらず、暗号化エラーによってCloudTrailはログの書き込みに失敗します。Google Cloudでも同様のアプローチが可能であり、顧客管理暗号化キー（CMEK）のキー権限を変更することで、ログへのアクセスや読み取りができなくなります。

Unit 42はまた、ログポイズニング攻撃も確認しています。これは、攻撃者が保存されたログファイルを改ざんして悪意ある活動の証拠を削除または変更するものです。ログはクラウドストレージ内でJSON形式で保存されることが多いため、オブジェクトレベルの権限を持つ攻撃者はログファイルをダウンロード・編集・上書きすることができます。

AWS CloudTrailのログファイル整合性検証のような完全性検証メカニズムがない場合、こうした改ざんは検知されないまま、インシデント対応の取り組みを誤った方向に導く恐れがあります。

回避にとどまらず、攻撃者はロギングシステムを継続的な可視性の確保にも活用しています。新しいログルーティング設定を作成したり既存の設定を変更したりすることで、脅威アクターはログを攻撃者が管理するストレージにリダイレクトできます。たとえばAWSでは、攻撃者が自分たちのS3バケットを指す新しいCloudTrailトレイルを作成することが可能です。

Google Cloudでも同様に、シンクを設定して外部へログをエクスポートすることができます。これにより、APIアクティビティ、IAMの変更、データアクセスパターンを含む被害者環境を、従来のアラートを発生させることなく受動的に監視することが可能になります。

これらの手法の影響は、可視性の完全な喪失から秘密裏なデータ窃取、長期的な持続性の確保にまで及びます。ログのリダイレクトやロギングの無効化といった高リスクな操作は、悪意ある活動の強力な指標であり、より広範な攻撃の前兆となることが多いです。

これらのリスクを軽減するために、組織はロギングリソースに対して厳格なアクセス制御を実施し、トレイルやシンクを変更するための権限を制限し、ストレージの保存先を保護する必要があります。

AWSの変更不可能な90日間のイベント履歴やGoogle Cloudの_Requiredログバケットなどの組み込み保護機能はある程度の耐性を提供します。しかし、適切に保護されていない場合、カスタム設定は依然として脆弱なままです。

この調査結果は、攻撃者の行動における重大な変化を示しています。攻撃者はログを回避するのではなく、ロギングインフラ自体を積極的に操作するようになっています。

クラウドの採用が拡大するにつれ、ロギングサービスの完全性と可用性を確保することは、効果的な検知・対応・フォレンジック調査のための基盤となる要件になりつつあります。

CISOおよびセキュリティリーダーの皆様：次の侵害には「顔」がないかもしれません。ISC2のライブウェビナー 「Ghost in the Machine」にご参加ください。