組織全体を可視化してインサイトを獲得し、セキュリティの強化、信頼性の向上、イノベーションの加速を図りましょう。SPL全ての製品を見るソリューション将来を見据えたSOCインテグレーションとオープンエコシステムを活用して、サイバー防御を強化しましょう。包括的な可視化と迅速なトラブルシューティングにより、パフォーマンスと信頼性を維持できます。統合されたセキュリティ、フルスタックのオブザーバビリティ、カスタムアプリケーションを1つのプラットフォームで実現できます。世界の名だたる組織がデジタルシステムのセキュリティと信頼性を維持するためのソリューションとしてSplunkを選択しています。Splunkと他社製品の比較Splunkのセキュリティとオブザーバビリティの統合プラットフォームで、お客様のデジタルレジリエンスを強化する方法をご紹介します。会社概要SplunkについてSplunkが目指すのは、より安全でレジリエントなデジタル世界を創造することです。Splunkは、組織の安定運用を支えるセキュリティ、IT運用、DevOpsの各チームを支援することで、この目標に着実に近づいています。組織全体を可視化してインサイトを獲得し、セキュリティの強化、信頼性の向上、イノベーションの加速を図りましょう。SPL全ての製品を見る将来を見据えたSOCインテグレーションとオープンエコシステムを活用して、サイバー防御を強化しましょう。包括的な可視化と迅速なトラブルシューティングにより、パフォーマンスと信頼性を維持できます。統合されたセキュリティ、フルスタックのオブザーバビリティ、カスタムアプリケーションを1つのプラットフォームで実現できます。世界の名だたる組織がデジタルシステムのセキュリティと信頼性を維持するためのソリューションとしてSplunkを選択しています。Splunkと他社製品の比較Splunkのセキュリティとオブザーバビリティの統合プラットフォームで、お客様のデジタルレジリエンスを強化する方法をご紹介します。Appを開発SplunkサービスSplunkへの投資を最大限に活用.conf24Splunkの理解を深められる大規模な年次イベントをご紹介SplunkについてSplunkが目指すのは、より安全でレジリエントなデジタル世界を創造することです。Splunkは、組織の安定運用を支えるセキュリティ、IT運用、DevOpsの各チームを支援することで、この目標に着実に近づいています。365)は、Microsoft社が提供するクラウドベースの生産性向上ツールスイートで、メールクライアント、コラボレーションプラットフォーム、業務アプリケーションなどをひとつにまとめたソリューションです。ADと呼びます)と統合されています。M365は、組織のデータが集約される場所であり、どこからでもアクセス可能で広く利用されていることから、サイバー攻撃の主要な標的のひとつになっています。初期アクセスは、攻撃者が組織の環境内に最初に侵入する攻撃の足場です。クラウドコンピューティング環境では、IDが新たな境界になっています。アカウントを乗っ取れば、攻撃を重ねることでデータの窃取が可能になります。逆にブルーチームにとっては、初期アクセスの段階で攻撃に対応できれば、実害を防ぐことができます。その点で、初期アクセス技法への警戒は重要です。Splunk脅威調査チームによるこのブログ記事では、まず、M365の監視に利用できるデータソースについて概説します。その後、M365テナントに対する初期アクセスでよく使われる6つの一般的な技法を紹介し、これらの技法のシミュレート方法とSplunkによる検出方法について解説します。データソース効果的な脅威検出は、分析の基盤となるデータソース選びから始まります。データソースの対象範囲と品質を理解することが、検出戦略を立てる鍵となります。このセクションでは、対象となるデータソースの概要、それらのデータソースの違い、Splunkへの取り込み方法について説明します。ADなど、各種サービスのログが集約されます。このデータを統合することで、M365環境全体のユーザーアクティビティを一元的に把握できます。これらのログを検索するには、PowerShellコマンドレット「Search-UnifiedAuditLog」を使用します。APIを使って、外部分析ツールからログにアクセスすることもできます。365を使用するのがお勧めです。APIを介してアクティビティ監査ログを簡単に取得できます。ADのログはセキュリティ監視で重要な役割を果たします。ADのサインインログと監査ログはスキーマが充実しているため、コンテキストを詳しく調査できます。SDKなどのRESTクライアントを使用します。Hubsを使えば、データストリーミングパイプラインと簡単に統合できます。Azureを使用するのがお勧めです。API経由でデータを取得できます。Hubsと統合できます。Managerアプリケーションを使って簡単にデータを取り込めます。ADログのどちらもM365のセキュリティ監視において重要な役割を果たしますが、その目的は異なり、スキーマにも違いがあります。UALは、M365の各種サービスの監査ログが幅広く記録され、ユーザーアクティビティを包括的に理解するのに役立ちます。ADログに記録されるような認証イベントやID管理イベントの一部の詳細は記録されません。UALでは「UserLoggedIn」イベントでユーザー認証アクティビティの基本情報を確認できます。サービスプリンシパルサインイン、非対話型サインイン、マネージドIDサインインなど、一部の重要な認証イベントはログに記録されません。これらのイベントで提供される情報が限定され、詳細な分析には物足りないこともよくあります。activity」イベントは対象が広く、サービスプリンシパルサインイン、非対話型サインイン、マネージドIDサインインを含め、認証のサブカテゴリも個別に記録されます。ログの対象範囲が広いため、アクセストークンの窃取や、サービスプリンシパルやAzureリソースIDの悪用など、M365への攻撃を検出するために十分な情報を収集できます。ADログの認証イベントでは、ユーザーとアプリケーションの情報、場所、デバイス、条件付きアクセス、使用された認証方法(単一要素認証と多要素認証(MFA)のどちらが使われたか)などの詳細を含む、包括的なデータセットが提供されます。Protectionによるサインインリスク情報も記録され、豊富なコンテキストを獲得できます。activity」イベントこうした違いを理解しておくことは、精度の高い脅威分析を行うために非常に重要です。UALは、M365の各種サービスの悪用リスクを分析するために最適です。ADログは、認証とIDに関する脅威を分析するうえで主要なソースになります。両方のデータソースから得られたインサイトを統合すれば、状況をより包括的に把握できます。Splunk脅威調査チームのアプローチSplunk脅威調査チームは、脅威の迅速な検出と無力化に必要なツールやインサイトを提供してセキュリティチームをサポートする専門チームです。ADログの両方を活用した分析手法をこれまでに30種以上開発してきました。このアプローチを取り入れれば、どのようなデータソースを活用していても、Splunkを使ってM365に迫る脅威の検出やハンティングだけでなく、M365環境の保護も行えます。Takeoverのリンク先からダウンロードできます。初期アクセス技法このセクションでは、攻撃者がM365テナントに侵入するために使用する一般的な初期アクセス技法について説明します。各技法について、次の点を取り上げます。実践的なシミュレーション戦略テレメトリから得られるインサイトSplunk脅威調査チームが公開している検出ルールパスワードスプレーパスワードスプレーは、よく使われる少数のパスワードとさまざまなユーザー名を組み合わせて有効な認証情報を探し出す攻撃技法です。Microsoft社による基本認証の廃止により、安全性の高い先進認証への移行が大幅に進みました。実際、MFAの導入率は、2017年の0.7%から2023年には37%に伸びています。した進歩はあったものの、パスワードスプレーの脅威は現在も続いており、攻撃ベクトルとして広く利用されています。後ほど詳しく説明するように、攻撃者は認証情報の取得後に、MFAによる制御を回避する方法を取り入れ始めています。「Microsoftデジタル防衛レポート2023」では、Microsoftプラットフォームに対してパスワードの窃取を狙う攻撃が急増し、パスワードスプレーのインシデントが10倍以上に増加していることが報告されています。Protectionやスマートロックアウトなどのセキュリティ対策を回避する高度なパスワードスプレー攻撃についても警告しています。図3:複数の送信元IPアドレスを使ったパスワードスプレーシミュレーション従来型のパスワードスプレー攻撃のシミュレーションには、MSOLSpray、o365spray、Go365など、さまざまなオープンソースツールを利用できます。複数の送信元IPアドレスを使った分散型のパスワードスプレーをシミュレートするときは、FireProxが効果的です。Gatewayを使って透過型プロキシを構築し、リクエストごとに送信元IPアドレスをローテーションします。その際、URLパラメーターを活用してFireProxとMSOLSprayをネイティブに統合します。ADラボ環境に模擬ユーザーを登録します。図4:MSOLSprayテレメトリから得られるインサイト認証要求の失敗はエラーコード50126として記録され、説明に「無効なユーザー名またはパスワードによる資格情報の検証中にエラーが発生しました」と表示されます。説明を見る限り、このエラーコードはユーザー名が無効な場合にも生成されるように思えますが、今回の実験でそうでないことがわかりました。実際、Microsoft社のドキュメントによると、入力されたユーザーアカウントが存在しない場合にはエラーコード50034が別に割り当てられ、その説明には、テナントディレクトリにユーザーアカウントが存在しないことが示されます。ADログには記録されません。Directoryの設定では、ユーザーが存在しない場合の認証失敗はKerberosエラー0x6で報告されます。ADログのどちらでもエラーコード50126を監視することで、短時間の間に同じ送信元IPアドレスを使う多数のユーザーが認証に失敗する従来型のパスワードスプレー攻撃を検出できます。Spike複数の送信元IPアドレスを使った分散型のパスワードスプレー攻撃を検出するには、独自の戦略が必要です。この分析手法では、同じ特徴を持つ認証要求が短時間で急増する状況を監視し、失敗したログイン試行の主要なメトリクスとして以下の値を算出します。一意のユーザーエージェント数これらのメトリクスのしきい値をカスタマイズすることで、通常の動作から逸脱したパターンを見つけ出すことができます。Spikeを使用します。不正な同意の付与M365環境では、サードパーティアプリケーションが組織のデータにアクセスするのを許可するためにOAuth認証プロトコルが使われます。この仕組みを悪用する攻撃者は、悪質なAzureアプリケーションを登録し、ユーザーをだましてアクセス許可に同意させます。不正な同意を得た攻撃者は、アクセストークンを手に入れて、機密情報にアクセスしたり、メールを盗み見たり、ユーザーになりすまして操作を実行したりできるようになります。この手口を使えば、多要素認証(MFA)を回避することも可能です。この問題に対応するため、Microsoft社は発行者の確認やリスクに基づくステップアップ同意などの対策を取り入れて、不正な同意の付与攻撃のリスクを大幅に緩和しました。それでも、攻撃者がこれらの対策を回避する可能性が残るため、この攻撃ベクトルへの警戒は引き続き必要です。今年初めにProofpoint社が公開したブログによると、攻撃者がMicrosoft社の「発行者確認済み」のステータスを悪用して、一部のOAuthの配布要件を満たした事例が確認されました。み」のステータスを偽装する手口を実証する調査報告を公開しました。シミュレーション不正な同意の付与攻撃のシミュレーションに利用できるオープンソースツールには、PwnAuth、o365-attack-toolkit、365-Stealerなど、いくつかあります。ここでは、365-Stealerを使用する方法をご紹介します。このツールのGitHubページで説明されているように、マルチテナントアプリケーションを登録する必要があります。すべての要件を満たしたら、ツールを設定して実行し、模擬ユーザーに送信するフィッシングリンクを作成します。図5:365Stealerデフォルトでは、前述のセキュリティ対策により、新しく作成したマルチテナントアプリケーションの登録に対する同意要求が即座にブロックされます。何らかの方法でこれらの対策を回避する攻撃者をシミュレートするために、こちらのガイドに従って、PowerShellを使ってリスクに基づくステップアップ同意を無効にします。図6:OAuth同意のブロックリスクに基づくステップアップ同意を無効にした状態でユーザーが悪質なリンクをクリックすると、次の画面が表示されます。この例では、ユーザーではなく悪質なアプリケーションが、メールの読み取りやメールの送信をするためのアクセス権を要求しています。具体的には、Mail.Read、Mail.ReadWrite、Mail.Sendの権限が要求されます。図7:不正な同意の付与のリクエスト標的のユーザーがこれに同意すると、攻撃者がアクセストークンを取得することになります。application」イベントが生成されます。このイベントには、同意の成否、対象ユーザーのID、アプリケーション名、要求された権限など、重要な情報が含まれます。ADログには、UALに含まれない情報として、IPアドレスフィールドが記録されます。このIPアドレスは、標的のユーザーのものでも攻撃者のものでもありません。実験では、このIPアドレスは通常、Microsoft社が所有するIPアドレス帯でした。両方のデータソースにある「ModifiedProperties」の「ConsentAction.Permissions」フィールドには、アプリケーションが要求した権限が含まれます。このフィールドを抽出して分析することで、目的の脅威検出のための分析を作成できます。APIで取得できる権限はさまざまですが、M365のコンテキストに沿えば、特に重要なのは「Read.*」と「Files.*」の2つのカテゴリに絞られます。application」イベントに含まれる詳細に基づいて、通知が必要な状況を検出するための分析を作成できます。user」の3つのイベントが生成されます。Application防止対策は、脅威のブロックだけでなく、標的となるユーザーのプロファイルに関するインサイトを獲得し、防御戦略を強化するためにも役立ちます。この検出ルールでは、M365でユーザーによるアプリケーションへの同意の付与が危険または悪質な可能性があると判断されてブロックされた挙動を検出できます。Disabled実験では、リスクに基づくステップアップ同意をわざと無効にしました。policy」カテゴリのイベントが生成されます。そのため、このカテゴリのイベントを監視すれば、攻撃を継続的に仕掛ける攻撃者がセキュリティ対策を弱体化させようとしたり、管理者が誤ってこの機能を無効にしたりした場合に、そのアクティビティを検出できます。APIの特定の権限を取得して、ユーザーに代わってメールの読み取りや送信、OneDriveやSharePoint上のファイルへのアクセスを行えるようになったことを検出します。`security_content_ctime(lastTime)`デバイスコードフィッシングM365とその認証プロセスではOAuthプロトコルが使われます。このプロトコルでは、さまざまなデバイス機能やユーザーエクスペリエンスに対応するための各種の認証フローがサポートされています。これらのフローは柔軟性と利便性を高めると同時に、新しい攻撃ベクトルとして悪用されることがあります。8628で取り上げられている、「デバイス認可フロー」と呼ばれるOAuthプロトコル拡張です。このプロトコル拡張は、スマートテレビなど、入力機能に制限のあるデバイスに対応することを目的としています。このプロトコル拡張を使えば、ユーザーが認証情報を入力することなく、デバイスでOAuthの認証および認可プロセスを実行することができます。その際は、認証情報の代わりに一意のコードを生成し、ユーザーにPCなどの別のデバイスでこのコードを入力するように求めます。図11:デバイスコードの入力要求この仕組みを悪用することで、攻撃者はMFAを回避してM365サービスに不正アクセスし、さまざまな攻撃につなげることができます。シミュレーションデバイス認可フローを悪用する攻撃者はまず、デバイスコードの認可フローを自身で開始して一意のユーザーコードを取得します。Webサイトで入力させます。ユーザーがだまされてコードを送信すると、攻撃者はその結果として送られるアクセストークンを手に入れることができます。この手口を自動化するTokenTacticsというオープンソースツールも出回っています。Webサイトにコードを送信すると、攻撃者はアクセストークンを取得してM365サービスにアクセスできるようになります。図13:盗まれたBearerトークンテレメトリから得られるインサイトUALのテレメトリでは、残念ながら、デバイスコード認証の試行を効果的に検出するための十分なコンテキストを得られません。activity」イベントに、この試行の検出に役立つ詳細なデータセットが含まれています。中でも重要なのが「authenticationProtocol」フィールドです。Authenticationデバイスコード認証の検出は簡単です。「authenticationProtocol」フィールドの値が「deviceCode」の認証イベントを見つけるだけです。`security_content_ctime(lastTime)`MFA疲労攻撃プッシュ通知によるMFAを回避するためによく使われる手口のひとつが、あらかじめ盗んでおいた認証情報を悪用して認証要求を繰り返し発生させる方法です。狙いは、ひっきりなしに続く要求に標的のユーザーが疲れたり混乱したりして認証を許可してしまうことです。場合によっては、攻撃者がインスタントメッセージや電話などの代替手段を通じて標的のユーザーに直接連絡を取り、不正な認証要求を承認するように強く迫ることもあります。テレメトリから得られるインサイトMFA疲労攻撃は、MFA試行の失敗が頻発していないかを監視することで検出できます。ADのエラーコード500121「強力な認証の要求時に、認証に失敗しました」によって捕捉できます。このエラーコードを監視すれば、MFA要求のいわゆる「プロンプト爆撃」を受けているユーザーによる異常な回数の認証失敗を検知できます。ADログの「additionalDetails」フィールドを確認すれば、認証の失敗がユーザーによる拒否なのかタイムアウトなのかを区別できます。この情報を使えば、検出ルールの精度を向上させて、一部の誤検知を回避できます。UALにはこの詳細は記録されません。User「異常な回数」とみなせるしきい値は組織によって異なるため、各組織の環境でのユーザーの正常な行動パターンに合わせてしきい値を調整してください。認証情報を盗み出した攻撃者が、標的テナントのMFA適用状況を調査することがあります。条件付きアクセスポリシーの複雑さを考えれば、管理者の見落としによって一部の認証ソースが単一要素認証のままになっていても不思議はないでしょう。攻撃者はそのことをよく認識しており、さまざまなデバイスタイプをシミュレートする自動化ツールを使って調査を行い、こうしたセキュリティの抜け道を探します。これらの不備が見つかると、盗んだ認証情報を使ってMFAによる保護対策を回避し、サービスに不正アクセスします。シミュレーションMFASweepやTeamFiltrationなどのツールを用いれば、有効な認証情報を使って異なるユーザーエージェントで各種のMicrosoftクラウドサービスに認証を行うプロセスを自動化できます。図15:MFASweepテレメトリから得られるインサイトこの手口の痕跡には、同じユーザーがさまざまなユーザーエージェントと幅広いアプリケーションIDを使って認証に複数回成功するという特徴があります。通常であれば、ユーザー認証で使われるユーザーエージェントは、ブラウザやモバイルデバイスなどのクライアントに応じて、せいぜい2つか3つです。短時間で5種類以上のユーザーエージェントを使うのは異常であり、攻撃者が盗んだ認証情報を使ってMFA対象サービスの列挙を実行している可能性があります。2中間者攻撃(AiTM)従来のフィッシング攻撃は、攻撃者がユーザーを偽のWebサイトに誘導して認証情報を入力させるものでした。このタイプの攻撃では認証情報が盗まれても、MFAを導入していればアカウントへの不正アクセスを防ぐことができます。攻撃者はそれに適応し、MFA対策を回避する新しい方法を考え出しています。中間者攻撃(AiTM)でも、攻撃者はまず、標的のユーザーを悪質なサイトに誘導します。これまでとの違いは、そのフィッシングサイトはプロキシサーバーのように機能し、ユーザーのリクエストを正規のWeb認証サイトにそのまま転送しながら、ユーザーと正規サイト間でやり取りされる機密情報を取得する点です。これにより、認証プロセスでやり取りされる認証情報やセッションCookieなどの重要データを盗み出すことができます。この方法を使えば、有効なセッションCookieを手に入れ、追加の検証なしで正規サイトと認証済みのセッションを確立することで、MFAを回避できます。図16:AiTM攻撃の流れ(出典)シミュレーションAiTM攻撃のシミュレーションには、Modlishka、Muraena、Evilginxなど、いくつかのオープンソースツールを利用できます。ここでは、強力で柔軟性の高いフィッシングフレームワークを提供するEvilginxを使用します。phishletを使用し、攻撃のホストとしてsplunkphish.comドメインを用意しました。図17:Evilginx次の図のように、Evilginxのリバースプロキシ機能によって、標的のユーザーは攻撃側のドメインでMFAセッションを確立することになります。認証に成功すると、ユーザーは任意のページにリダイレクトされ、攻撃者はユーザーの認証情報とセッションCookieを手に入れます。この時点で攻撃は成功であり、以降は、手に入れたセッションCookieを使って、認証を行わずに、ユーザーになりすましてMicrosoftサービスを利用できます。図19:Evilginxに表示された、盗まれたセッションCookieテレメトリから得られるインサイトAiTM攻撃では、フィッシングサーバーがすべての通信を転送するプロキシとして機能します。そこでやり取りされる情報には、平文のパスワード、MFAコード、プロトコルヘッダー、ユーザーエージェントなどの機密情報が含まれます。この場合、認証ログのエントリは、ユーザーがブラウザから正規にサインインするときと同じになるため、問題ないように見えます。その中で唯一通常とは異なるのがIPアドレスです。このときログには、ユーザーが使うIPアドレスではなく、フィッシングサーバーのIPアドレスが記録されます。実験では、UALの分析から、あるパターンを特定しました。標的のユーザーが悪質なドメインで認証に成功すると、「UserLoggedIn」イベントが生成されます。その後、攻撃者が盗んだセッションCookieを自身のブラウザにインポートしてM365テナントにアクセスすると、「UserLoggedIn」イベントが改めて生成されます。フィッシングサーバーと攻撃者のアクセスポイントでIPアドレスが異なる場合、この2つのイベントでは、SessionIdが同じでもIPアドレスが異なることになります。ADログには「SessionId」フィールドはありませんが、非対話型ユーザーサインインのログイベントから同様のインサイトを得られます。非対話型サインインは、ブラウザやデスクトップアプリケーションがユーザーに代わって実行するもので、ユーザー操作を必要としません。攻撃者が盗んだセッションCookieをインポートして標的のテナントにアクセスすると、非対話型サインインイベントが生成されます。検出ルールハンティングの方法はいくつかありますが、成功するかどうかは攻撃の実行方法に大きく左右されます。こちらのサイトやこちらのサイトで紹介されている、条件付きアクセスを使ったAiTM攻撃防止策の導入も検討してください。`security_content_ctime(lastTime)`最後にサイバーセキュリティの状況は、特にM365のようなクラウドベースの環境では、変化が激しく、先手を打つのが困難です。この記事で説明したように、攻撃技法の中には、MFAのような高度なセキュリティ対策を回避するものもあります。効果的な検出戦略を立てるには、IDベースの攻撃に対する理解を深め、初期アクセス技法を警戒することが重要です。この記事を参考に、セキュリティ運用を強化して、実害が出る前に攻撃を検出するための態勢を整備しましょう。次回のブログ記事では、M365アカウントを乗っ取った攻撃者による偵察や情報窃取について解説する予定です。悟史によるレビューです。先進的なサイバーセキュリティ対策を推進する組織がどのように課題を克服し、AIを活用してイノベーションを推進し、デジタルレジリエンスを強化しているかをご確認ください。共有に注意!:ネットワーク共有検出のハンティングこのブログ記事では、攻撃者がよく使う手口であるネットワーク共有検出を防ぐための実践的なガイドを提供します。分程度Splunkで脅威ハンティング:アクティブなハンターのためのハンズオンチュートリアルSplunkを使った脅威ハンティングに興味がある方や、悪者を見つけ出すスキルに磨きをかけたい方のために、このブログ記事では、Splunkでハンティングをする場合に役立つ、エキスパートによる記事をご紹介します。Hands-Onを数回開催し、沢山のセキュリティ運用担当のお客様にご参加いただきました。その中で頂いたご意見として「自分達でplaybookを準備できるようになるまでに色々な具体例を紹介してほしい」がありました。本Blogにてご紹介していきたいと思います。SplunkについてSplunkプラットフォームは、データを行動へとつなげる際に立ちはだかる障壁を取り除いて、オブザーバビリティチーム、IT運用チーム、セキュリティチームの能力を引き出し、組織のセキュリティ、レジリエンス(回復力)、イノベーションを強化します。Splunkは、2003年に設立され、世界の21の地域で事業を展開し、7,500人以上の従業員が働くグローバル企業です。取得した特許数は1,020を超え、あらゆる環境間でデータを共有できるオープンで拡張性の高いプラットフォームを提供しています。Splunkプラットフォームを使用すれば、組織内のすべてのサービス間通信やビジネスプロセスをエンドツーエンドで可視化し、コンテキストに基づいて状況を把握できます。Splunkなら、強力なデータ基盤の構築が可能です。Splunkの詳細はこちらブログのメール配信Splunkの最新ブログ記事をメールでお知らせします。無断複写・転載を禁じます。無断複写・転載を禁じます。