マイクロソフト セキュリティ レポートは、BEC 攻撃のルートとして基本認証を指し示す

マイクロソフト セキュリティ レポートは、BEC 攻撃のルートとして基本認証を指し示す

フィッシング、受信トレイルール、転送

A マイクロソフトの脅威インテリジェンス センターからの 6 月 14 日のレポート (MSTIC) は、ビジネス電子メールの侵害 (BEC) 攻撃のコンテキストで、今回も問題を強調表示します。基本的に、電子メールを使用したフィッシングの成功 請求書要求 又は 不在着信したボイスメール 結果は、ユーザー資格情報の収集につながります。攻撃者は、資格情報を使用してメールボックスにサインインし、受信トレイ ルールを作成して、請求書、支払い、明細書などの用語を含むメッセージのコピーをシステムに転送します。次に、別の受信トレイ ルールによって、転送されたメッセージのコピーがクリーンアップされ、メールボックスの所有者が[送信済みアイテム]フォルダにメッセージを表示することがないようにします。私は、攻撃者がCFOのメールボックスからメッセージをコピーし、最終的に資金を確保するためにBECメッセージを送信しようとする技術を使用した会社でこのような攻撃の経験があります。

フィッシングが継続的な問題であり、違法な利益を得ることを目的としてユーザー資格情報などの機密データを収集したい人々が使用する攻撃ベクトルであることを知ることは驚くべきことではありません。

基本認証はまだ実施中

悲しい事実は、多くの Microsoft 365 テナントが、ユーザーが Exchange Online メールボックスにアクセスするために POP3 や IMAP4 のような古い接続プロトコルと基本認証の組み合わせを使用することを許可し続けているということです。マイクロソフトは、できるだけ多くの接続プロトコルの基本認証をオフにするために組織に最善を尽くしており、その理由の証拠を提示しています 基本認証が非常に悪い.最新の認証 (MFA) に移行すると、パスワード スプレー攻撃が成功する可能性が低くなります。多要素認証を使用すると、アカウント侵害攻撃の 99.9% がブロックされます。また、条件付きアクセス ポリシーをミックスに追加すると、さらに改善されます。

そのすべては、組織がハッカーに利益をもたらすだけの危険な道を歩み続けるときに理解するのが難しくなります。

MSTIC レポートでは、攻撃者が POP3 または IMAP4 を使用して、メールボックスにルールを作成する前に資格情報をテストする方法 (MFA はこの問題を解決します) を説明します。マイクロソフトは最近 電子メール転送を取り締まる 送信スパム フィルタ ポリシーで許可されていない限り、ユーザーが転送を構成できないようにします。Microsoft が問題を発見した組織が送信スパム フィルター ポリシーを使用して転送をブロックしたかどうかは明らかではありませんが、取り締まりのため、メール転送ルールを使用する BEC キャンペーンの脅威が大幅に減少することに注意してください。

テナント管理者向けチェックリスト

送信スパム ポリシーでの転送ブロックの導入は、大きな前進です。しかし、ユーザーが例外のケースを主張し、組織外でいくつかの電子メールを転送することを許可するケースを構築することも事実です。リスクを最小限に抑える上で、テナント管理者は何をすべきでしょうか。チェックリストを次に示します。

最も重要な手順は次のとおりです。

  • 制限された例外を使用して送信スパム ポリシーを構成し、転送をできるだけ少なく抑えます。
  • MFA を使用して、すべてのユーザー アカウントを保護します。MFA を使用すると、攻撃を受けるユーザー アカウントの脆弱性の多くが排除されることを覚えておいてください。できます PowerShell を使用して、アカウントの MFA ステータスを検索してレポートする.
  • まだ行っていない場合は、 セキュリティの既定値を使用するように Azure AD を構成する.Microsoft では、すべての新しいテナントにセキュリティの既定値を設定して、管理者アカウントの MFA を有効にするなどの基本的な手順を確実に行うことができます。テナントが私のテナントと似ていて、既に条件付きアクセス ポリシーを使用している場合は、セキュリティの既定値を有効にすることはできません (図 1)、テナントを保護する方法が既に整っているので、問題ありません。Azure AD は、サインインが成功した後に条件付きアクセス ポリシーを評価するため、攻撃者が侵入するのを阻止しません。ただし、攻撃者が管理されていないデバイスや不明な場所から機密情報にアクセスするのを阻止できます。条件付きアクセス ポリシーには、Azure AD プレミアム ライセンスが必要です。
Azure AD のセキュリティの既定値を有効にする
図 1: Azure AD のセキュリティの既定値を有効にする
  • マイクロソフトは、 最新の認証をサポートするために POP3 プロトコルと IMAP4 プロトコルをアップグレードしました.人々がこれらのプロトコルを使用することを主張する場合は、最新の認証をサポートするクライアントにアップグレードしてもらいます。
  • テナントで発生している状況を監視します。Office 365 E5 をお持ちの場合は、Office 365 のマイクロソフト クラウド アプリ セキュリティを使用できます。ポイントは、管理者が使用する必要がありますテナントをチェックするために使用できるデータとツール。Office 365 監査ログを定期的に参照しても、原因不明のイベントや疑わしいイベントが発生し、調査に値する可能性があります。

MSTIC レポートは、次の点を指摘しています。 Office 365 のマイクロソフト ディフェンダー には、不審な転送アクティビティを検出してテナント管理者に報告するための標準アラートポリシーが含まれています。別のアラートは、ユーザーが電子メールを転送するルールを作成したときに管理者に通知します (図 2)。これらのアラートは、発生するたびに処理する必要があります。

ユーザーが電子メールを転送する受信トレイ ルールを作成するため、アラート
図 2: ユーザーが電子メールを転送する受信トレイ ルールを作成するための警告

メールボックスの確認

Office 365 用 Microsoft Defender がない場合は、PowerShell を使用して、転送アドレスまたは受信トレイ ルールで構成されたアカウントをスキャンして電子メールを転送できます。送信スパム ポリシーは、ユーザーがポリシーに例外としてリストされていない限り、電子メールの転送をブロックします。それでも、メールボックスの設定やルールを介して転送が構成されている場所を知っておいそう。ここでは、メールボックスで構成された転送を検索し、転送アクションを含む受信トレイ ルールを確認するコードを示します。

$Mbx = (Get-ExoMailbox -RecipientTypeDetails UserMailbox, SharedMailbox -Properties ForwardingSmtpAddress -ResultSize Unlimited)
Write-Host $Mbx.Count "user and shared mailboxes found. Now checking..."
$NumberMbxWithRules = 0; $NumberForwards = 0
ForEach ($M in $Mbx) {
    Write-Host "Processing" $M.DisplayName
    $Rule = $Null
    If ($M.ForwardingSmtpAddress -ne $Null) { # Mailbox has a forwarding address
       $NumberForwards++
       Write-Host $M.DisplayName "is forwarding email to" $M.ForwardingSmtpAddress.Split(":")[1] } 
    $InboxRules = (Get-InboxRule -Mailbox $M.Alias | ? {$_.ForwardTo -or $_.ForwardAsAttachmentTo })
    If ($InboxRules -ne $Null) {
       Write-Host "Processing inbox rules"
       ForEach ($Rule in $InboxRules) {
          $Ex = $Null
          $ForwardTo = @()
          $ForwardTo = ($Rule.ForwardTo | ? { ($_ -Match "SMTP") -or ($_ -Match "EX:") } )
          $ForwardTo += ($Rule.ForwardAsAttachmentTo | ? {($_ -Match "SMTP") -or ($_ -Match "EX:")})
          If ($ForwardTo.Count -gt 0) {
             ForEach ($Recipient in $ForwardTo) {
                If ($Recipient -Match "EX:") {
                   # Recipient known in Exchange directory
                   $Ex = (Get-Recipient -Identity ($Recipient-Split "Ex:")[1].trim("]}")) 
                   $EmailAddress = $Ex.PrimarySmtpAddress }
                Else  {
                  # Simple SMTP address
                   $EmailAddress = ($Recipient -Split "SMTP:")[1].Trim("]") 
                   $Ex = (Get-Recipient -Identity $EmailAddress) }
             }
             Write-Host $M.RecipientTypeDetails $M.DisplayName "has a rule to forward email to" $EmailAddress -ForegroundColor Red
             # Remove the rule if the address is unknown to the directory
              If ($Ex -eq $Null) {
                 Remove-InboxRule -Identity $Rule.Identity -Confirm:$False
                 Write-Host "Rule" $Rule.Name "removed from mailbox!" }
              Else {
                 Write-Host "Destination is known to the tenant directory. Please remove" $Rule.Name "manually if necessary" }
             $NumberMbxWithRules++ }
       }
     }
}

ユーザーのメールボックスから受信トレイ ルールを削除しない場合は、関連する行をコメントアウトします。できます GitHub からスクリプトをダウンロードします 組織のニーズに合わせて修正します。

基本認証を削除するための長い道のり

マイクロソフトは、Exchange オンライン接続プロトコルから基本認証を削除する意向を発表しました。 2019年9月.これまでのところ、顧客を教育し、説得し、移動するには多くの労力が必要でした。その兆候は、変換を完了するためにさらに多くの努力が必要になることです。あなたがぶら下がっている場合は、テナントのセキュリティを向上させるために飛び込んで検討する時が良いかもしれません。結局のところ、あなたは次のMSTICレポートの主題になることを好まないでしょう。

サブスクリプションを使用して Exchange オンラインおよび Office 365 の残りの部分を保護する方法について説明します。 IT 担当者向け Office 365 電子書籍。テナントを保護する上で重要な内容と最善の方法を理解するために、経験を活かしてください。


未分類

Posted by admin