脅威アクターがGitHubとJiraから自動化されたメールを乗っ取り、SPF、DKIM、およびDMARCチェックを簡単にバイパスするフィッシング罠を配信していると、Cisco Talosが警告しています。
これらの信頼されたサービス型ソフトウェア（SaaS）通知システムをプラットフォーム型プロキシ（PaaP）として悪用することで、攻撃者はエンタープライズゲートウェイが安全として扱うように条件付けられた正当なメッセージ内にソーシャルエンジニアリングコンテンツを埋め込みます。
PaaPモデルでは、攻撃者は自分のインフラストラクチャからメールを送信せず、代わりにSaaSプラットフォームにメールを生成させます。
これらのメッセージはGitHubまたはAtlassianの検証済みSMTPサーバーから発信され、SPF、DKIM、およびDMARCで正しく認証されているため、レピュテーションベースのメールフィルタはそれらをクリーントラフィックと見なします。
Talosの研究者は、これが悪意のある意図を技術的シグナルから切り離し、フィッシングコンテンツに、従来のセキュアメールゲートウェイが滅多にチャレンジしない組み込みの「承認の証」を与えることを指摘しています。
Talosおよびその他の研究者は、PaaPキャンペーンからの防御には、「信頼できるドメイン対信頼できないドメイン」という二項対立的な考え方を放棄し、アイデンティティと活動中心の検証を優先する必要があると主張しています。
SPF、DKIM、およびDMARCはメールがSaaSプラットフォームによって送信されたことのみを確認し、基礎となるアクションが正当であったことを確認するわけではないため、組織は既知の認可されたインスタンスおよびユーザー行動と相関するまで、すべてのSaaS発信通知を信頼できないものとして扱う必要があります。
推奨される制御の1つはインスタンスレベルの認可です。メールゲートウェイは、組織の検証されたSaaSテナント、送信者アドレス、およびIPレンジにマップバックできる通知のみを受け入れます。
セキュリティチームは、GitHubとJira通知を承認されたリポジトリ、プロジェクト、およびユーザーアイデンティティの内部インベントリと照らし合わせて確認し、完全な認証に合格した場合でも、不明なテナントまたはアカウントから発信されたメッセージを自動的に隔離できます。
これにより、検証の枠組みが、メールを送信したサーバーではなく、リポジトリ、プロジェクト、または招待を作成したユーザーまたはインスタンスなど、アクティビティを開始した者を中心に変わります。
アップストリームAPIレベルの監視は、焦点をインボックスからSaaS制御プレーンへさらにシフトさせます。
GitHubおよびAtlassian監査ログをSIEMまたはSOARプラットフォームに取り込むことで、防御者は異常なリポジトリ作成、疑わしいプロジェクト名、一括招待、または非典型的な地域からのアクセス試行または業務時間外のアクティビティなどの前駆行動を検出できます。
新しいプロジェクト招待の受け入れや認証情報または支払い詳細の提供など、SaaS通知を介してトリガーされた機密アクションの場合、ポリシーはプラットフォーム生成コードの入力や埋め込みリンクをクリックするのではなく公式サイトへの直接ナビゲーションなど、アウトオブバンド検証を要求できます。
不正なリポジトリとJiraプロジェクトをプロバイダーの信頼とセーフティチームに迅速に報告する自動削除ワークフローと組み合わせると、これらの措置はPaaPの運用コストを増やし、攻撃者を監視されたエコシステムに押し込み、彼らのアクティビティがあらゆるステップで組織的なビジネスロジックとの一貫性について評価されます。
翻訳元: https://cyberpress.org/github-jira-phishing-lures/
