Sumo Logic Cloud SIEMでSlack環境を保護

Slackは、社内・社外コミュニケーションからプロジェクトのワークフローに至るまで、多くの組織に不可欠な存在としてあらゆる業務の強化を行っています。しかし、ツール導入の増加は、同時にリスクの増加を意味します。Slackには知的財産や資格情報、貴重な偵察情報が含まれていることが多いため、昨今ではハッカーがSlackをターゲットにするケースが増えています。

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

Slackから盗まれた10ドルのCookieが、いかにして大規模な情報漏洩を引き起こしたか

 エレクトロニック・アーツ（EA）の侵害 を例にとってみましょう。問題のデータ侵害において、 攻撃者は盗まれたSlackのCookieを10ドルで購入しました。このことにより、攻撃者は社内のSlackチャネルへのアクセスを取得し、これを利用してEAのITチームにソーシャルエンジニアリングを仕掛けることで、社内ネットワークへのアクセストークンを入手しました。攻撃者はその後、ゲーム「FIFA 21」のソースコードや独自のソフトウェア開発キットを含む780GBのデータを盗み取りました。 

このような被害を受けているのはEAだけではありません。 ディズニーや Rockstar、 Uber、 Twitter など、きわめて知名度の高い企業の数々が攻撃を受けていますが、これらの攻撃の成功にはSlackが大きな役割を果たしています。 

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

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

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

監視を開始する1つの方法として、ログを使ったメソッドを挙げることができます。 Slackは、監査ログからアクセスログまで、さまざまなタイプのログを提供しています。このブログでは、Slackが「継続的なコンプライアンスの確保、不適切なシステムアクセスの防止、および企業内における不審な動作の監査のために」生成する 監査ログに焦点を当てます。

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

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

 Slackの監査ログ における貴重な機能として、Slackが異常なアクションや動作を検出したときに自動的に生成される異常イベントが挙げられます。すべての異常イベントに対しアクションが必要となるわけではなく、信頼度レベルもイベントによって異なります。異常イベントがトリガーされた場合、適切な評価とアクションの要否決定のため、さらなる調査が必要になることが考えられます。

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

Slackがどの異常イベントの信頼度を高いとみなしているかに関しては、 異常イベント対応機能 も手がかりになります。この機能では、特定の異常イベントがユーザーに起因する場合、ユーザーセッションを自動的に終了します。デフォルトで選択される2つのイベントは、「Tor Exit NodeからSlackへのアクセス」と「データスクレイピング」であり、Slack Engineeringがこれら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における潜在的なCookie盗難の調査 

攻撃者が盗んだCookieを使用して社内システムにアクセスしたEA侵害の例を再検証しましょう。盗まれたCookieの再利用により、Slackにおいてはどのような異常イベントが発生するでしょうか？異常イベントがログに記録された場合、どのような調査が可能でしょうか？

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

セッションIDは、ユーザーがSlackにログインするたびに生成されます。当該セッションは、デバイス上にCookieとして保存されます。各セッションIDは単一のデバイスにマッピングされることが予想されます。Cookieが盗まれて別のデバイスで使用された場合、次のようなアーティファクトに変化がみられる可能性があります。

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

これらのシグナルは不審な再利用を特定するのに役立ちますが、Slackの監査ログはインタラクティブなアクションに対してのみ生成されることに注意する必要があります。受動的なアクセス（クリックやダウンロードを行わずにメッセージを読むなど）ではログエントリがトリガーされない場合があるため、Cookie再利用の検出状況はユーザーアクティビティの性質によって異なります。

これらの違いは、同じセッション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です。 
• Slackを開発した元の企業の名前はTiny Speckでした。このため、ユーザーエージェント文字列 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の異常イベントは悪意のある動作を発見しませんでした。ユーザーエージェントが変更されたセッションがありましたが、これは複数のデバイスが同じセッションCookieを使用していたことによるものではありませんでした。 

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

Slackは、異常検出の裏にある正確なロジックを明らかにしていませんが、これはセキュリティの観点からは理にかなった選択であるといえるでしょう。とはいえ、これらの 異常イベントタイプ 自体が、ダッシュボードや追跡、そして独自のカスタム分析にインスピレーションを与えてくれます。 

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

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

（Cookie盗難についての再考）複数のユーザーエージェント文字列が関係する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デモをご覧ください。