詐欺師が、DellとStaplesの正規の注文通知を悪用し、コールバック型フィッシングを仕掛けています。認証チェックを通過するトランザクションメールに偽のヘルプライン番号を埋め込む手口です。
Cisco Talosは、2件のキャンペーンにまたがる約1,400通のメッセージを確認しました。送信元の偽装や悪意あるリンクに頼らなくても、信頼された小売事業者のインフラ経由で攻撃者が指定した指示を届けられることが浮き彫りになっています。
この動きは、より広範な傾向の延長線上にあります。Talosは過去1年間に、コラボレーション、生産性向上、ファイル共有、アンケート、決済、AIサービスなど、25を超える正規プラットフォームの悪用を追跡してきました。
Staplesのキャンペーンでは、[email protected]から届いたように見える注文確認メールが使われました。件名には注文番号9939818875が記載されていました。
整った書式の本文には、Apple iPadの購入が記載されていました。価格、配送情報、請求先の詳細、企業の標準的なブランド表示まで揃っています。
ところが、本来は配送先や請求先の情報が入る欄に、「Helpline 806 283 7712」と「Order Confirmed」という文字列が入っていました。
この挿入された文言は、身に覚えのない購入に驚いた受信者に対し、公式の窓口で確認させず、攻撃者へ電話をかけさせようとするものです。
Dellのキャンペーンも同じ手口でした。注文通知にはDellの購入ID 2009829958247が記載され、Microsoft Project Standard 2024の購入として合計736.09ドルと表示されていました。
「Ship To」欄と「Bill To」欄には、「Helpline 808 232 6397」「Confirmed Order」「Call Our Sales Team」といった文字列が入っていました。
どちらのキャンペーンも、受信者をメールから電話での会話に誘導することが狙いです。電話に出た詐欺師は、支払い詐欺や認証情報の窃取、リモート支援を装った詐欺に及ぶ可能性があります。
Cisco Talosの研究者は、SaaS（Software as a Service）の通知パイプラインの悪用について、これらのプラットフォームが悪意ある意図の代理（プロキシ）として転用されるケースが増えていると指摘しています。
なお、今回公表された調査結果からは、その後どのような行為が行われたかは確認できていません。
悪用されたDellとStaplesのメール
Staplesのサンプルでは、orders.staples.comに対するDKIM認証が一致し、DMARCも合格していました。Dell関連のインフラでもDKIMは合格し、order.dell.comのDMARCも合格しています。
攻撃者は、暗号資産をテーマにした誘導文のような「悪意ある文字列」を、氏名、会社名、肩書きを入力するための欄に入力します。これにより、プラットフォームはそのデータを正当なユーザー情報として扱わざるを得なくなります。
こうした認証結果が裏付けるのは配信経路の正当性であり、購入内容や埋め込まれた電話番号の正当性ではありません。
Staplesの例では、Microsoft 365やProton Mailなどのサービスを経由して転送されていました。そのため送信元の追跡は複雑になりましたが、上記の区別は変わりません。
この仕組みは、Talosが以前に調査した「プラットフォームのプロキシ化」による悪用と同じです。当時、攻撃者はGitHubのコミットメッセージや、Jiraのプロジェクト欄・招待欄に詐欺の文言を挿入していました。
信頼されたサービスがその入力内容を認証済みの通知に取り込み、サービス自身の評判を悪意ある指示に貸し与える形になります。
Talosはまた、攻撃者が指定した氏名、会社情報、プロジェクト名を自動送信メールに反映してしまう登録ワークフローについても説明しています。
リストボミング（大量のメールで受信箱を溢れさせる攻撃）の一部のケースでは、これが単なる妨害ではなく、標的を絞ったコンテンツ配信に変わります。
配信状況通知（バウンスメール）も、運び屋として使われます。返送されたメッセージ本文や入れ子のMIMEコンテンツに、フィッシングの誘導文をそのまま残せるためです。そのため、本物の配信失敗レポートの中にフィッシングが紛れ込みます。
確認された例の一つには、WeTransferを装った誘導文が含まれていました。ただし、別の配信手段でも似たようなメッセージは作れます。
小売事業者は、保存や表示の前にユーザーが入力できる欄を検証する必要があります。電話番号やURL、緊急のサポート案内など、本来その欄に入るはずのない値は検知して警告すべきです。
注文通知についても、支払い状況、アカウント履歴、配送の状況、承認済みのサポート窓口と照合して確認すべきです。
セキュリティゲートウェイは、送信元の評判や認証結果だけに頼ってはいけません。レンダリング後のHTML、プレーンテキスト、添付ファイル、リダイレクト、入れ子のMIMEオブジェクトまで検査する必要があります。
業務上の文脈をチェックすれば、住所欄に埋め込まれたキャンセル手順のような不審な指示も見つけられます。
これはインフラの認証とトランザクションの検証を分けて考えるということです。この二つの対策は、根本的に異なるリスクに対処するものです。
受信者は、身に覚えのない購入を確認する際、疑わしい通知に記載された電話番号ではなく、自分で直接アクセスした小売事業者のアカウントや、既知のサポート窓口を使ってください。
根本的な問題は、信頼の置き場所を誤っていることにあります。メールの外形上の身元が本物であっても、正規のインフラが悪意あるコンテンツを届けてしまう可能性があるのです。
平均対応時間（MTTR）を21分短縮し、被害が出る前にサイバー脅威を阻止します。ANYRUNのサンドボックスをSOCに統合。
翻訳元: https://gbhackers.com/dell-and-staples-emails-exploited/
