Sumo Logic Cloud SIEM で Slack 環境を保護する

  今回はSumo Logic社が公開している、Slackの監査ログをSumo Logicに取り込み、Cookie窃取などの高度な脅威を早期調査する方法に関する記事を日本語化しました。

原文はこちらをご参照ください。

Slackは多くの組織にとって不可欠なツールであり、社内外のコミュニケーションからプロジェクトのワークフローに至るまで、あらゆる業務を支えています。

しかし、Slackの導入・利用が拡大するにつれ、セキュリティリスクもまた高まっています。
Slackには知的財産や認証情報、攻撃の偵察に役立つ貴重な情報が蓄積されているため、ハッカーの標的となるケースが急増しているのです。 

 Sumo Logic Cloud SIEMを活用して監査ログの不審なアクティビティを監視することで、内部関係者や第三者の脅威からSlack環境を保護し、企業とデータを守ることができます。 

盗まれたセッションCookieが大規模な侵害を引き起こす

上述した攻撃されるケースとしてElectronic Arts (EA) のデータ侵害事件では、攻撃者は盗まれたSlackのクッキーを10ドルで購入し、攻撃者は社内のSlackチャンネルへのアクセス権を入手、EAのITチームに対してソーシャルエンジニアリングを仕掛け社内ネットワークへのアクセストークンを発行させました。

その結果、攻撃者はゲーム『FIFA 21』のソースコードや独自のソフトウェア開発キットを含む、780GBものデータを盗みました。

 被害はEAにとどまらず、Disney、Rockstar、Uber、Twitterといった著名企業でも、Slackが攻撃成功の「鍵」となっています。

攻撃者がSlackを足がかり、あるいは最終目標として狙う理由は明白です。
Slackは初期アクセス、内部探索、認証情報の窃取、データの持ち出しといった攻撃を実施するのに、まさに格好の場となっているからです。 

なぜ、Slackの監査ログがセキュリティの要となるのか

上記の通りSlackは攻撃者にとって非常に魅力的な標的であるため、環境内に悪意のある振る舞いがないかを継続的に監視する必要があります。

そのための有効な手段がログの活用です。
Slackは監査ログの他にアクセスログなどを提供していますが、本記事では「継続的なコンプライアンスの確保、不適切なアクセスの防止、疑わしい行動の監査」を目的として生成される監査ログに焦点を当てます。

この監査ログとAPI経由でのアクセス機能は、Sumo LogicのようなSIEMソリューションでセキュリティ監視を行う上で必要不可欠な要素です。

脅威検知における異常イベントの活用

Slack監査ログの有用な機能の一つに、異常なアクションや振る舞いを検知した際に自動生成される異常イベントがあります。
すべてのイベントに対処が必要なわけではなく、重要度も異なります。
そのため、本当に対処すべき脅威かを見極める追加調査が必要です。

Slackは各イベントの詳細なスコアを公開していませんが、特定の異常イベントとユーザーを紐付け、自動的にセッションを終了させる機能を提供しています。
デフォルトで選択されているのは以下の2つであり、これはSlackのエンジニアリングチームがこれらを「ほぼ確実に悪意ある行為」とみなしていることを示唆しています。

• 出口ノードからのSlackアクセス
• データスクレイピング

Sumo Logic Cloud SIEMは、これらSlackの異常イベントを完全にサポートしています。
イベントは「脅威アラート」として正規化され、ルール（MATCH-S00402)がトリガーされます。
これによりエンティティのアクティビティスコアが加算され、アナリストは不審な挙動を示すユーザーやシステムを迅速に特定できるようになります。

図1：Slackの異常イベントは、Sumo Cloud SIEM シグナルとして生成

図2：Slackにおける異常イベント機能でのデフォルト設定

Sumo LogicへのSlack監査ログの取り込み方法

Sumo Logicでの監査ログ収集手順は非常にシンプルです。

1. Slack Enterprise Gridアカウントの確認（※必須条件です）
2. Slack Appの作成とauditlogs:read権限の取得
3. Enterprise GridへのAppの適用
4. Sumo Logic Slack Cloud-to-Cloud Connectorのインストールと設定

重要:  設定時、Slackログソース画面で「Forward to SIEM」のチェックボックスが選択され、SIEMにログが送信されていることを必ず確認してください。

図3：Sumo Logic上でのSlack ログソース設定画面

セキュリティアナリストによる脅威の調査と対応

攻撃者による回避を防ぐため、Slackは異常検知の正確な判定ロジックを公開していません。
これはセキュリティアナリストにとって、アラート発生条件の把握や分析ロジックのチューニング、検知漏れの評価を困難にする要因となります。

例えば excessive_downloadsのような原因が曖昧なイベントが発生した場合、アナリストは過去の正常な活動と比較して、そのダウンロード量が異常かどうかを手動で評価する必要があります。

それでは、これらの異常イベントのいくつかを実際にどう調査すべきか、詳しく見ていきましょう。

SlackにおけるCookie窃取の調査手法

EAの事例のように、盗まれたCookieが再利用された場合、どのように検知・調査すればよいでしょうか。

ユーザーがSlackにログインすると、デバイスのCookieとして保持される「セッションID」が生成されます。
通常、1つのセッションIDは1つのデバイスに紐づきます。
もしCookieが盗まれ、別のデバイスで使用された場合、以下のような情報に変化が現れます。

• ユーザーエージェント
• IPアドレスと位置情報
• TLSハンドシェイク (ja3 フィンガープリント)

注意: Slackの監査ログはメッセージ送信やダウンロードなど 能動的なアクションでのみ生成されます。メッセージを読むだけの受動的なアクセスではログが記録されない場合があるため、検知はユーザーのアクティビティに依存します。

図4：Cloud SIEMのレコードにおけるSlack session IＤ例

Cookie窃取を示唆する異常イベントの候補

クッキー窃盗によって引き起こされる異常イベントのリストを確認してみると、いくつかの候補が挙げられます。

• asn
• ip_address
• session_fingerprint
• tor
• unexpected_client
• unexpected_user_agent
• user_agent

Sumo Logicを使った追跡の具体例

まず、過去2週間のすべてのSlack異常イベントを検索し、「発生理由」ごとにグループ化します。

_index=sec_record_notification
metadata_vendor="Slack" metadata_deviceEventId="anomaly"
| count by threat_signalName

図5: Sumo Logic GUI上でSlack 異常イベントが発生理由ごとにまとめて表示

今回、23件の結果が出ました。
ここで重要なポイントは以下の2点です。

1. 1つの異常イベントに複数の原因（例：unexpected_user_agent|user_agent）が含まれる場合がある
2. 最も多い原因である asn|ip_addressは、API経由で信頼できるIPやASNを除外リストに追加することでチューニングが可能

次に、Cookie窃取の疑いがあるunexpected_user_agent と user_agentに絞り、対象のセッションIDを取得します。

index=sec_record_notification
metadata_vendor="Slack"
metadata_deviceEventId="anomaly"
| where threat_signalName = "Anomaly Event : unexpected_user_agent|user_agent"
| count by sessionId


図6：異常イベントunexpected_user_agent の セッションID

調査すべき対象が見つかったので、そのうちのいくつかを深掘りしてみましょう。
異常イベントの詳細を見ていくことで、何故イベントが発生したのかという背景が分かります。
図7：unexpected_user_agent|user_agenti異常イベントの詳細

図7の異常イベントの詳細からIPとユーザーエージェントの変更

調査対象のイベントメタデータを確認すると、以下のような変化が見られました。

IPアドレスの変更：

• 現在の IP アドレス： 172.59.222.55
• 過去の IP アドレス： 204.16.138.54

疑問1：IPアドレスの変更はデバイスが変わったということであり、ユーザが攻撃者に変わった可能性があるということか？

その可能性もありますが、モバイルデバイスであること、そしてGeoIP情報から両方のアドレスがノースカロライナ州シャーロット地域にあることを考慮すると、デバイスの変更は疑わしいとは考えられません。

ユーザエージェントの変更：

• 現在のユーザエージェント: “AppleCoreMedia/1.0.0.21F90 (iPhone; U; CPU OS 17_5_1 like Mac OS X; en_us)”
• 過去のユーザエージェント: “com.tinyspeck.chatlyio/25.04.10 (iPhone; iOS 17.5.1; Scale/3.00)“
  

疑問2：ユーザエージェントが変わることは、デバイスが変わったことを意味するのか？

ユーザエージェント文字列の記載は以下を意味しており、AppleCoreMediaのユーザエージェントはSlack内からメディアファイル（動画など）がストリーミングされる際に表示され、Tiny Speckエージェントは通常のSlack使用を反映している可能性が高いと言えます。 

• com.tinyspeck.chatlyio/ 25.04.10
  Tiny Speckは、Slackを開発した企業の旧社名です。
  現在でもiOS版Slackアプリの内部的な識別子としてこの文字列が使用されています。 
  
• AppleCoreMedia
   AppleCoreMediaは、iOSがストリーミングやメディア再生を処理するために使用するフレームワークです。 
  

この仮説を検証するため、個々のログのアクションとユーザーエージェントを突き合わせます（※セッションは90日以上続くこともあるため、検索期間は長めに設定します）。 

(_index=sec_record_notification OR _index=sec_record_audit)
metadata_vendor="Slack" sessionId=8475310491012
| fields action, http_userAgent

図8：監査対象のアクションと関連するユーザエージェント文字列 

図8から2025年4月9日の異常イベント発生の1時間前を確認すると、ユーザエージェントがTiny SpeckからAppleCoreMediaに変更されました。
これはおそらく、file_downloadedアクションに関係するファイル形式がストリーミングを必要としていたためです。

フィールドリストのDisplayed Fieldsセクションからフィールド名を選択し、検索結果の表示にfile_mimetypeフィールドを追加します。

 
図9・10：検索結果の表示にfile_mimeTypeフィールドを追加 

図9・10によりfile_mimeTypeが表示されることで、MP4ファイルをダウンロードする際のユーザエージェントがAppleCoreMediaであり、JPGファイルをダウンロードする際のユーザエージェントがTiny Speckであることがわかります。

つまり、このケースはCookie窃取のような悪意のあるデバイス変更ではなく、ダウンロードしたファイル形式によってユーザーエージェントが切り替わっただけの正常な動作であることが判明しました。 

カスタム分析での異常イベントの活用

Slackの検知ロジックは非公開ですが、イベントタイプそのものをヒントにして、Sumo Logic上で独自の脅威ハンティングやカスタムルールを構築できます。

• First Seen（初回検出）ルール: 普段とは異なる管理者アクションの監視
• Outlier（外れ値）ルール: ダウンロード、ファイル共有、メッセージ削除の急増の監視

Cookie窃取の調査において、1つのセッションに複数のユーザーエージェントが混在しているかを追跡するには、count_distinct Operatorが役立ちます。

(_index=sec_record_notification OR _index=sec_record_audit) metadata_vendor="Slack" metadata_product="Slack"
| count_distinct(http_userAgent) by sessionId
| sort by _count_distinct

図11：セッションIDごとのユニークなユーザーエージェント文字列の件数

その後、対象となるセッションが見つかった場合、次のようなクエリで対象セッションの全ログを取得できます:

(_index=sec_record_notification OR _index=sec_record_audit) metadata_vendor="Slack" sessionId=[対象セッションID を記載]
| count by http_userAgent

脅威の一歩先を行くために

Slackは企業情報の宝庫であり、ハッカーにとって非常に魅力的な標的です。
セキュリティ侵害を早期に発見するためには、異常イベントを含む監査ログの監視が不可欠です。

Sumo Logicを活用すれば、これらのログの収集から分析、アクション（インシデント対応）の実行までをシームレスに行うことができ、セキュリティチームは常に脅威の一歩先を行く体制を構築できます。

☆note

SumoLogic社では、SumoLogic社の日々のスタンドアップでCloud SIEMダッシュボードを使用しており、これにより効率、協力、重要な指標への焦点が大幅に改善されています。
-------

Cloud SIEMの実際の動作を確認したい、デモ環境を利用したいなどその他ご要望がございましたら、下記よりテリロジーへ、お問合せください。

https://cloudsolution.terilogy.com/sumologic/contact