Sumo Logic Cloud SIEMでSlack環境を保護

Slackは、社内外コミュニケーションからプロジェクトワークフローに至るまで、多くの組織にとって不可欠なものとなっています。しかし、導入が進むにつれ、リスクも高まっています。Slackには知的財産、認証情報、貴重な偵察情報が含まれていることが多いため、ハッカーがSlackを標的にするケースが増えています。

Sumo Logic Cloud SIEM は、 監査ログ を監視して不審なアクティビティを検知することで、 内部および第三者からの脅威に対して Slack の利用を保護し、貴社とそのデータの安全を確保します。

盗まれた10ドルのSlackクッキーが、いかにして大規模な侵害を引きこしたか

例として Electronic Arts（EA） の情報漏えい事件を取り上げましょう。このデータ侵害では、 攻撃者は盗まれた Slack のクッキーを 10ドルで購入しました。その購入によって社内の Slack チャンネルへのアクセス権を得た攻撃者は、 EA の IT チームにソーシャルエンジニアリング攻撃を行い、EA の社内ネットワークへのアクセス・トークンを取得しました。攻撃者はその後、『FIFA 21』のゲームのソースコードや独自のソフトウェア開発キットを含む 780GB のデータを盗み出しました。 

EA だけではありません。 Disney、 Rockstar、 Uberや Twitter などの有名企業も、Slack が攻撃成功の主要な要因となったインシデントの被害を受けています。 

Slackが攻撃者にとって重要な拠点、あるいは最終目標となる理由は、理解に難くないといえるでしょう。なぜならSlackは、初期アクセスや発見、資格情報の盗難、抽出など、さまざまな戦術を実行するのに格好のプラットフォームであるからです。 

Slackの監査ログがセキュリティ向上の鍵となる理由

Slackが攻撃のための魅力的なターゲットであることをよく理解し、悪意のある動作が見られないか、継続的なSlack環境の監視が必要となります。

監視を始める 1つの方法は、ログを活用することです。 Slack には、監査ログやアクセスログなど、複数種類のログが用意されています。本記事では、Slack が「継続的なコンプライアンスの確保、不適切なシステムアクセスの防止、そして企業内の不審な行動を監査できるようにする」ために生成している 監査ログに焦点を当てて説明します。

監査ログと、これらにAPI経由でアクセスするための機能は、 Sumo LogicのようなSIEMソリューション がセキュリティ監視や統合を実行する上で不可欠となります。 

Slackの監査ログを使用して脅威検出を実行

 Slack 監査ログ の有用な機能の 1つが「異常イベント」です。これは、Slack が通常と異なる操作や挙動を検知したときに自動的に生成されます。すべての異常イベントに対応が必要なわけではなく、イベントの種類ごとに確信度レベルも異なります。異常イベントがトリガーされた際に、それを精査し、対応が必要かどうか判断するために、追加の調査が必要になることが多いでしょう。

Slackは異常イベントの信頼レベルを提供していませんが、一部のイベントに関しては、侵害指標の信頼度が高いとみなされることを明確にしています。 

 異常イベント対応機能 を見ると、Slack がどの異常イベントを高確信度とみなしているかについての手がかりも得られます。この機能は、特定の異常イベントがユーザーに関連付けられた場合、そのユーザーセッションを自動的に終了します。デフォルトで対象となっている 2つのイベントは「Tor の出口ノードから Slack にアクセスしている場合」と「データスクレイピング」であり、Slack のエンジニアリングチームがこれら 2つの検知を高確信度と考えていることがうかがえます。

Slackの異常イベントは、SIEMで取り込んで分析できるため、セキュリティチームにとって特に有用です。Sumo Logic Cloud SIEMはSlack異常イベントを完全にサポートしています。これらのイベントは 脅威アラート として正規化され、「正規化セキュリティシグナル」（MATCH-S00402）というルールをトリガーします。つまり、異常イベントはエンティティの アクティビティスコアに貢献できます。これにより、アナリストは不審な挙動を示すユーザやシステムを迅速に特定できます。

Sumo Cloud SIEMシグナルとして渡されるSlackの異常イベント

Slackの異常イベント対応におけるデフォルト設定

Sumo LogicでSlackの監査ログを収集して取り込む方法

Sumo LogicでSlackの監査ログを収集する方法は非常に簡単です。 詳細ガイド ではSlackからログを収集する方法を説明していますが、ここでは手順の概要だけをご紹介します。

1. Slack Enterprise Gridアカウントを持っていることを確認します。Enterprise GridアカウントなしではSlackの監査ログの収集ができません。
2.  auditlogs:read 権限を持つSlackアプリを作成します。
3. Enterprise Gridでアプリをインストールします。
4. Sumo Logic Slack Cloud-to-Cloud Connectorをインストールし、設定します。
5. 重要：「SIEMに転送」チェックボックスが選択されており、SlackのログソースがSIEMにログを転送するように設定されていることをご確認ください。  

セキュリティアナリストが脅威の検出、調査、および対応にSlackのログを活用する方法 

Slackは、自社のプラットフォーム上でどのような動作が異常とみなされるべきかについて独自の定義を行っているため、異常な動作の検出や異常イベントの生成は顧客にとって非常に価値のあるサービスとなります。

ただし、Slack Engineeringは異常イベント生成における検出基準を公開していません。その理由は想像に難くありません。基準が公開されていれば、攻撃者が防御を回避するテクニックを考案しやすくなるからです。

しかし、セキュリティアナリストにとっては、これは物事を難しくします。アラートがトリガーされた理由を正確に知らなければ、異常イベントをトリガーした監査ログを検索するためのクエリの策定に多くの時間を費やすことになるでしょう。分析のチューニングや偽陰性の評価も同様の理由で難しくなり、推測が必要になるかもしれません。

異常イベント検出の理由によっては、イベントのトリガーとなった原因が他の理由よりも明確に示される場合があります。これに対し、「excessive_downloads」などのケースは曖昧になりがちで、イベントに至るまでのダウンロードアクティビティを検索し、ダウンロード内容を確認するか、以前の期間と比較することで、ユーザーによるダウンロード量の「正常」性を評価する必要が生じます。 

それでは、実際にこれらの異常イベントを調査する方法を掘り下げていきましょう。 

Slackにおける潜在的なクッキー盗難の調査 

EA の情報漏えいの例に戻りましょう。ここでは攻撃者が盗まれたクッキーを使って社内システムにアクセスしました。盗まれたクッキーが再利用された場合、どの Slack の異常イベントが発生すると考えられるでしょうか？ もし異常イベントがログとして記録されているなら、それらをどのように調査できるでしょうか？

SlackセッションIDを理解するということ

ユーザーが Slack にログインするたびに、セッション ID が生成されます。このセッションは、デバイス上のクッキーとして保持されます。通常、各セッション ID は 1つのデバイスに対応していると考えられます。もしクッキーが盗まれ、別のデバイスで使用された場合、次のような証拠に差異が現れる可能性が高くなります。

• ユーザーエージェント文字列
• IPアドレスと場所
• TLSハンドシェイク（ja3フィンガープリント） 

これらのシグナルは、不審なクッキー再利用の特定に役立ちますが、Slack の監査ログは対話的なアクションに対してのみ生成されることに要注意です。メッセージをクリックやダウンロードせずに閲覧だけといった受動的なアクセスでは、ログが記録されない場合があります。そのため、クッキー再利用の検知は、ユーザーの行動内容に大きく依存します。

これらの違いは、同じセッションIDに関連付けられたログに反映されます。

Sumo Logic Cloud SIEMレコードに表示されるSlackセッションIDの例

Cookieの盗難を示唆する異常イベント

Cookieの盗難によってトリガーされる Slackの異常イベント としては、いくつかの候補があります。 

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

Sumo Logicを活用した潜在的なCookie盗難の追跡

以上の知識を元に、まずは広範囲にわたる調査を行い、過去2週間に自社環境内で発生したSlackの異常イベントをすべて検索します。次の検索では、Slackにおけるすべての異常イベントが返され、理由別にグループ化されます。

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

図4：理由別にグループ化されたSlackの異常イベント

こちらの例では、323件の検索結果が返されました。注目すべき点は2つあります。

•  asn|ip_address や unexpected_user_agent|user_agentなどの結果から明らかなように、異常には複数の理由が割り当てられる場合があります。
• 異常の理由として最も多いのはasn|ip_addressです。これらのイベントは、 除外リストにAPI経由で信頼性のある自律システム番号（ASN）とIPアドレス範囲の追加で調整が可能です。

次に、 unexpected_user_agent および user_agentの理由が関連付けられたイベントに焦点を絞ることで、盗まれたCookieの追跡を続行します。次のクエリを使用し、これらのイベントおよびセッションIDを取得します。

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

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

調査すべき異常が見つかり次第、詳細を掘り下げていきます。

異常イベントの詳細を確認することで、イベントがトリガーされた理由についてのコンテキストを得ることができます。

異常イベント unexpected_user_agent|user_agent の詳細

異常イベントの分析

異常イベントの details メタデータには、イベントがトリガーされた理由（IPアドレスとユーザーエージェントの変更）が表示されます。 

IPアドレスの変更：

• 現在のIPアドレス： 172.59.222.55
• 以前のIPアドレス： 204.16.138.54

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)」

ユーザーエージェントの変更はデバイスが変更されたことを示しているでしょうか？

• ユーザーエージェント文字列が偽装されていないと仮定すると、デバイスはOSバージョン18.4を搭載したiPhoneです。 
• Tiny SpeckはSlackを開発した会社の元の名前です。ユーザーエージェントの文字列 com.tinyspeck.chatlyio/25.04.10 は、おそらくSlack iOSクライアントに対応しています。
  AppleCoreMedia はiOSがストリーミングとメディア再生を処理するために使用するフレームワークです。
• このことから、AppleCoreMediaユーザーエージェントはSlack内でメディアファイル（ビデオなど）がストリーミングされたときに表示され、Tiny SpeckエージェントはSlackの一般的な使用法を反映するものである、と考えることができます。この動作は公開文書からは確認できませんが、当社のログ分析ではこの解釈が裏付けられています。
• AppleCoreMediaは、iOSにおけるメディアのストリーミングに使用されます。

つまり、Tiny SpeckユーザーエージェントはSlackの通常使用に適しており、AppleCoreMediaユーザーエージェントはSlackにおけるメディアストリーミング向けであるということでしょうか？

異常なイベントに貢献した個々のログをレビューすることで、この理論をテストできます。セッション ID を検索し、アクションに関連するユーザエージェントを調べることから始めましょう：

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

セッションは長時間続く可能性があるため、検索時に設定する時間範囲には余裕を持たせる必要があります。本稿で調査されたセッションは、90日以上にも及ぶものでした。

監査されたSlackアクションと関連するユーザーエージェント文字列

2025年4月9日の異常イベントの前の数日間に焦点を当てます。異常発生の1時間に、ユーザーエージェントはTiny Speck（Slack）エージェントからAppleCoreMediaに変更されていました。なぜでしょうか？おそらく file_downloaded アクションに関係するファイルタイプがストリーミングを必要としたためです。検索結果の表示に file_mimetype フィールドを追加するため、フィールド一覧の「非表示フィールド」セクションから該当フィールド名を選択します。

フィールド8：検索結果の表示へのfile_mimeTypeフィールドの追加

 file_mimeType の表示により、MP4ファイルをダウンロードする際のユーザーエージェントがAppleCoreMediaであり、JPGファイルのダウンロード時はTiny Speckであることが明らかになります。

図9：ダウンロードされたファイルタイプに関連付けられたユーザーエージェント文字列の分析

この例において、Slackの異常イベントは悪意のある動作を発見しませんでした。ユーザーエージェントが変更されたセッションがありましたが、これは複数のデバイスが同じセッションクッキーを使用していたことによるものではありませんでした。 

カスタム分析コンテンツにおけるSlackの異常イベントタイプの使用

Slack はセキュリティ上の観点から、異常検知の正確なロジックは公開していません。しかし、 異常イベントの種類 そのものが、ダッシュボードの設計、ハンティング、そして独自のカスタム分析を行う際の良いヒントになります。 

これらは次のようなイベントの監視に使用できます。

• 標準外の管理アクション （First Seenルール）
• ダウンロード、ファイル共有、またはメッセージ削除の急増 （Outlierルール） 

クッキー窃取の話に戻ると、複数のユーザーエージェント文字列が関与している Slack セッションをどのようにハントできるでしょうか？そのためには  count_distinct演算子を使用できます。

(_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

sessionIdごとに異なるユーザーエージェント文字列の数

関心のあるセッションが見つかったら、次のようなクエリを使用してすべてのログを返せます。

(_index=sec_record_notification OR _index=sec_record_audit) metadata_vendor="Slack" sessionId=[insert session ID here]
| count by http_userAgent

Slackベースの脅威を先取り

Slackは豊富な企業情報源であるため、ハッカーにとって格好の標的となります。異常イベントを含むSlackの監査ログを監視することは、侵害を早期に発見するために非常に重要です。 

Sumo Logicを使用すると、これらのログを簡単に収集、分析、および対処できるため、企業チームは脅威に対し先手を打てます。 

Sumo Logic Cloud SIEMの詳細については、 インタラクティブなCloud SIEMデモをご覧ください。