金融機関は、ドメイン偽装やフィッシングの頻繁な標的となっています。これは、攻撃者が顧客が銀行、信用組合、決済プロバイダー、フィンテックブランドに寄せる信頼を悪用できるためです。

正規の金融機関に酷似した不正なドメインは、認証情報の窃取、支払いのリダイレクト、決済カード情報の収集、マルウェアの配布、またはより広範なソーシャルエンジニアリングキャンペーンのサポートに使用される可能性があります。

銀行にとって、脅威は偽サイトだけにとどまりません。攻撃者は、なりすましドメインをフィッシングメール、SMSメッセージ、不正な広告、侵害されたアカウント、偽の顧客サポート電話、または悪意のあるログインページと組み合わせる可能性があります。目的は往々にしてシンプルです:被害者に、既に信頼している金融機関とやり取りしていると信じ込ませることです。

米国の銀行規制当局は、このリスクについて長年取り組んできました。OCC(通貨監督庁)のガイダンスでは、ウェブサイトスプーフィングを正規の銀行ウェブサイトに似せた不正サイトの作成と説明し、これらの攻撃が銀行と顧客の両方をプライバシー、詐欺、業務、戦略、評判のリスクにさらす可能性があると警告しています。

このガイドでは、金融サービスにおけるドメインスプーフィングやなりすましドメイン攻撃がどのように機能するか、なぜ銀行が特に魅力的な標的なのか、DMARCやメール認証がどこで役立ち、どこで役立たないのか、そして機関がブランド偽装に対する多層防御をどのように構築できるかを説明します。

I. 金融サービスにおけるドメインスプーフィングとは?

「ドメインスプーフィング」は、悪意のあるデジタルアイデンティティを信頼された組織に関連付けて見せかける攻撃の総称としてよく使用されます。

実際には、セキュリティチームはいくつかの異なる技術を区別する必要があります。

直接的なドメインスプーフィング

直接的なドメインスプーフィングは、攻撃者が許可なく正規機関の実際のドメインから発信されたように見えるメールを送信しようとする場合に発生します。

例:

From: [email protected]

このメッセージは、examplebank.comによって承認されたインフラストラクチャを介して送信されていません。

SPF、DKIM、DMARCは、この攻撃タイプに直接関連しています。

なりすましドメイン偽装

なりすましドメイン攻撃は異なります。

実際のドメインをスプーフィングする代わりに、攻撃者はそれに似た別のドメインを登録します。

例:

example-bank-security.com

または:

examplebnk.com

攻撃者はそのドメインを制御し、有効なDNS、SPF、DKIM、DMARC、およびTLS証明書を設定できます。

したがって、メール認証だけでは、ドメインが欺瞞的であるかどうかを判断できません。

CISAは、敵対者の技術としてドメイン取得を文書化し、悪意のある活動のために視覚的に類似したドメインを作成するための国際化ドメイン名の使用を特に指摘しています。

タイポスクワッティング

タイポスクワッティングは、予測可能なタイプミス、欠落した文字、入れ替わった文字、または信頼されたドメインのその他のバリエーションに基づくドメインの登録を含みます。

例:

examplebnk.com
examplebannk.com
examplbank.com

金融機関にとって、リスクは特に重大です。悪意のあるサイトがログイン体験を複製し、認証情報、認証コード、支払い情報、またはその他の機密データを要求する可能性があるためです。

IDNおよび同形異字攻撃

国際化ドメイン名(IDN)は、基本的なASCII文字セット以外の文字を許可します。

攻撃者は、異なるアルファベットから視覚的に類似した文字を使用して、悪意のあるホスト名がユーザーに表示されたときに信頼されたブランドに似て見えるようにすることがあります。

これらの攻撃は、一般的にIDN同形異字攻撃と呼ばれます。

最新のブラウザ、レジストリ、セキュリティプラットフォームは、多くの形態のIDN悪用に対する防御を実装していますが、視覚的に欺瞞的なドメインは、フィッシングやマルウェアキャンペーンに依然として関連しています。

誤解を招くドメイン構造

攻撃者は、ユーザーが信頼できる金融サービスと関連付ける単語を含むホスト名を作成することもできます。

例:

secure.examplebank-login.com

注意力が散漫なユーザーは、次のことに焦点を当てる可能性があります:

secure

または:

examplebank

実際の登録可能なドメインが攻撃者によって制御されていることを認識していません。

次のような単語:

secure
login
verify
account
support
banking
authentication

は、ドメインを正当化するものではありません。

ユーザーとセキュリティシステムは、単にその中に埋め込まれた信頼できそうな単語ではなく、実際の登録ドメインを評価する必要があります。

II. 銀行が主要ターゲットである理由

金融機関は、ブランド偽装を攻撃者にとって特に価値のあるものにする、いくつかの特性を組み合わせています。

1. 金融資産への直接アクセス

銀行の認証情報は、次のものへのアクセスを潜在的に提供できます:

• 口座残高
• 支払い機能
• 保存された受取人
• 与信枠
• 決済カード情報
• 個人金融記録
• 法人向け銀行システム

後で収益化する必要があるデータとは異なり、侵害された金融認証情報は、攻撃者に詐欺への比較的直接的な道を提供する可能性があります。

2. 顧客はセキュリティメッセージを期待している

銀行は正当に次のような顧客向けの通信を送信します:

• 不審な取引
• 新しいデバイスからのログイン
• 詐欺アラート
• パスワードリセット
• アカウント確認
• 支払い確認
• カード活動
• セキュリティ更新

攻撃者は、これらと同じワークフローを悪用します。

次のように主張するフィッシングメッセージ:

「お客様のアカウントで異常な活動が検出されました」

は、顧客が注意深く検査する前に不正なドメインと対話するのに十分な緊急性を生み出すことができます。

消費者保護機関は、疑わしいメッセージに含まれるリンクや連絡先の詳細を使用せず、代わりに独立して検証されたチャネルを通じて金融機関に連絡するよう顧客に定期的にアドバイスしています。

3. 銀行には大きなデジタル攻撃面がある

現代の金融機関は、もはや単一のウェブサイトを通じて運営されていません。

顧客は次のものとやり取りする可能性があります:

• ウェブバンキング
• モバイルアプリケーション
• 決済ポータル
• カード管理システム
• 資産管理プラットフォーム
• ローンポータル
• 顧客サポートシステム
• 投資プラットフォーム
• サードパーティの金融サービス
• 認証プロバイダー

金融セクターのガイダンスは、デジタルバンキング、API、モバイルアクセス、リモートサービス、およびサードパーティ接続が潜在的な攻撃面の数を増加させることを繰り返し強調しています。

正規のデジタルエコシステムがより複雑になるにつれて、顧客が正規のインフラストラクチャと説得力のある模倣を区別することが難しくなる可能性があります。

4. 金融ブランドには組み込みの信頼がある

攻撃者は、既知の銀行になりすます際に、被害者との新しい関係を確立する必要はありません。

関係は既に存在しています。

顧客は次のことを認識しています:

• 機関の名前
• そのロゴ
• その色
• その用語
• 一般的なアカウントワークフロー

クローンされたページは、これらのなじみのある視覚的な手がかりを悪用できます。

目的は、必ずしも未知の会社が信頼できると被害者を納得させることではありません。それは、正規の金融機関が既に獲得した信頼を借りることです。

III. 金融ドメイン偽装攻撃の仕組み

高度な攻撃には、いくつかの段階が含まれる可能性があります。

段階1:ドメイン登録

攻撃者は、機関に似たドメインを登録します。

例:

examplebank-security.com

ドメインには次のものが含まれる可能性があります:

• タイプミス
• 追加された単語
• 削除された文字
• 代替トップレベルドメイン
• ハイフネーション
• 音声的類似性
• Unicode文字
• セキュリティ用語と組み合わされたブランド名

ドメイン自体には、最初は悪意のあるコンテンツが含まれていない可能性があります。

つまり、登録中または登録直後の早期検出が価値がある可能性があります。

段階2:インフラストラクチャのセットアップ

攻撃者は、次のものを使用してドメインを設定できます:

• DNSレコード
• ウェブホスティング
• MXレコード
• TLS証明書
• SPF
• DKIM
• DMARC

これにより、重要なセキュリティ上の区別が生まれます:

悪意のあるなりすましドメインは、技術的に適切に構成されている可能性があります。

有効なTLS証明書は、ウェブサイトが偽装されている機関に属していることを証明するものではありません。

同様に:

SPF: pass
DKIM: pass
DMARC: pass

は、examplebank-security.comが正規の銀行ドメインであることを証明するものではありません。

これらの制御は、使用されているドメインの認証を確立します。ドメイン自体が欺瞞的であるかどうかを判断するものではありません。

段階3:ブランドのクローン

攻撃者は、正規機関のオンラインアイデンティティの要素を複製します。

これらには次のものが含まれる可能性があります:

• ロゴ
• ナビゲーション
• ログイン画面
• フォント
• 色
• セキュリティ言語
• アカウント確認画面
• MFAプロンプト
• 詐欺警告ページ

結果として得られるウェブサイトは、特にモバイル画面では非常に説得力があるように見える可能性があります。

段階4:トラフィックの生成

攻撃者は、被害者を悪意のあるインフラストラクチャに到達させる必要があります。

配布は次を通じて行われる可能性があります:

• フィッシングメール
• SMS
• QRコード
• 検索広告
• ソーシャルメディア
• 悪意のあるリダイレクト
• 侵害されたウェブサイト
• メッセージングプラットフォーム
• 偽の顧客サポートのやり取り

最も安全なユーザー行動は、未承諾のリンクを通じて銀行サービスにアクセスすることを避け、代わりに公式の銀行アプリ、検証済みのブックマーク、または既知の正規ウェブサイトを使用することです。

段階5:認証情報またはデータの収集

ユーザーが不正なページに到達すると、攻撃者は次のことを要求する可能性があります:

ユーザー名
パスワード
カード番号
PIN
ワンタイムパスワード
セキュリティの質問への回答
個人情報

より高度な攻撃は、被害者が提供した情報が実際のサービスに対してすぐに使用されるように、正規のログインプロセスをリアルタイムでプロキシしようとする可能性があります。

段階6:後続の詐欺

盗まれたデータは、次のことをサポートできます:

• アカウント乗っ取り
• 不正な送金
• カード詐欺
• 個人情報盗難
• 法人詐欺
• ソーシャルエンジニアリング
• 認証情報の再利用
• さらなるフィッシング

したがって、最初のなりすましドメインは、より広範な詐欺キャンペーンの最初の段階に過ぎない可能性があります。

銀行を標的とする一般的なドメイン偽装技術

IV. タイポスクワッティング

攻撃者は、予測可能なスペルミスを登録します。

例:

securebank.com

は次のように模倣される可能性があります:

securbank.com
securebnk.com
secure-bank.com

攻撃者は、タイプミスまたは受信者がメール、SMSメッセージ、広告、またはブラウザ内のバリエーションに気付かないことに依存しています。

V. ブランド+キーワードドメイン

もう1つの一般的なパターンは、認識可能なブランドとセキュリティ関連の言語を組み合わせます。

例:

examplebank-verification.com
examplebank-login.com
examplebank-support.com

これらのドメインは、追加された単語が文脈的に適切に見えるため、特に説得力がある可能性があります。

VI. 代替トップレベルドメイン

攻撃者は、別のトップレベルドメイン下で認識可能な文字列を登録することもできます。

例:

examplebank.example

機関の正規ドメインの代わりに。

機関の正確なドメインポートフォリオに精通していないユーザーは、その代替が正規であると仮定する可能性があります。

VII. 同形異字およびUnicodeバリエーション

視覚的に類似した文字は、欺瞞的なホスト名を作成できます。

これは、ユーザーがURLを素早く検査する場合や、小さなモバイル画面で検査する場合に特に関連しています。

VIII. 誤解を招くサブドメイン

次を制御する攻撃者:

bank-security.example

は、次を作成できます:

login.bank-security.example
secure.bank-security.example
accounts.bank-security.example

loginまたはsecureの存在は、正当性を示すものではありません。

登録可能なドメインは次のままです:

bank-security.example

ドメイン偽装のビジネスへの影響

成功した偽装キャンペーンによる被害は、最初に侵害されたアカウントを超えて広がる可能性があります。

IX. 金融詐欺

盗まれた認証情報により、不正な取引やその他の形式のアカウント悪用が可能になる場合があります。

金融損失には、次のものも含まれる可能性があります:

• 調査
• 詐欺の払い戻し
• インシデント対応
• 顧客サポート
• 法的レビュー
• テイクダウン作業
• 脅威インテリジェンス
• 追加の認証対策

正確な金融責任は、アカウントの種類、管轄区域、状況、および適用される消費者保護規則によって異なります。

X. 顧客信頼の低下

顧客は、銀行が制御するインフラストラクチャと銀行になりすますインフラストラクチャを必ずしも区別しません。

したがって、説得力のある偽サイトは、実際のシステムが侵害されていなくても、正規機関への信頼を損なう可能性があります。

ブランド悪用は、異常なセキュリティ問題を生み出します:

攻撃者は、組織のネットワークを侵害することなく評判の損害を生み出すことができます。

XI. 業務の混乱

アクティブなフィッシングキャンペーンには、次の間の調整が必要になる場合があります:

• セキュリティチーム
• 詐欺チーム
• 法律顧問
• 顧客サポート
• レジストラ
• ホスティングプロバイダー
• 証明機関
• 法執行機関
• 脅威インテリジェンスプロバイダー

これらの対応活動は、機関の内部インフラストラクチャが侵害されていない場合でも、重要な業務リソースを消費する可能性があります。

XII. 規制および証拠要件

すべてのフィッシングキャンペーンが自動的に報告可能な規制インシデントを作成するわけではありません。

ただし、偽装攻撃が不正アクセス、保護された情報の露出、詐欺、またはその他の報告可能なイベントをもたらした場合、機関は適用される規制枠組みに応じて、通知、調査、文書化、または証拠保全義務に直面する可能性があります。

したがって、金融機関は、次の方法を示すことができるべきです:

• 脅威の検出
• 認証システムの保護
• 不審な活動の監視
• ユーザーの教育
• インシデントへの対応
• 適切な記録の維持

DMARCができることとできないこと

DMARCは金融機関にとって重要な制御ですが、その範囲は正しく理解される必要があります。

XIII. DMARCは銀行の実際のドメインを保護するのに役立ちます

正規機関が次を使用するとします:

examplebank.com

攻撃者が次を送信しようとします:

From: [email protected]

不正なインフラストラクチャを介して。

SPFおよび/またはDKIMアライメントとDMARC施行が次のように正しく設定されている場合:

p=quarantine

または:

p=reject

参加している受信システムは、保護されたドメインから発信されたと主張する認証されていないメッセージに機関のDMARCポリシーを適用できます。

したがって、DMARCは、機関が実際に制御するドメインの直接的なスプーフィングを大幅に削減します。

XIV. DMARCは攻撃者所有のなりすましドメインを止めません

今、攻撃者が次を登録するとします:

examplebank-security.com

攻撃者はそのドメインを所有しています。

彼らはそれに対して次を公開できます:

SPF: pass
DKIM: pass
DMARC: pass

次に対するDMARCポリシー:

examplebank.com

は次を制御しません:

examplebank-security.com

これは完全に異なるドメインだからです。

この区別は重要です。

DMARCは認証されたドメインアイデンティティを保護します。犯罪者が制御する欺瞞的なドメインの登録を防ぐことはできません。

これが、金融機関がメール認証と外部なりすましドメイン監視の両方を必要とする理由です。

金融機関の多層防御

効果的な保護には、いくつかの層にわたる制御が必要です。

XV. 1. 正規ドメインでDMARCを施行する

金融機関は、正規のメール送信元の完全なインベントリを維持し、正規の送信者を検証した後、対象ドメインをDMARC施行に移行する必要があります:

p=quarantine

または:

p=reject

DMARCは、次のように正しく設定されたものによってサポートされる必要があります:

• SPF
• DKIM
• アライメント
• 集約レポート
• 送信者の発見
• 継続的な監視

DMARC施行は、正規の送信インフラストラクチャが特定および検証された後にのみ導入される必要があります。

XVI. 2. なりすましドメインを監視する

認証は、組織が所有するドメインを保護します。

外部ドメイン監視は、組織が所有しないドメインに対処します。

金融機関は、次を含む登録を監視する必要があります:

• スペルミス
• ブランドのバリエーション
• 音声的類似性
• ハイフネーション付きバリアント
• 追加のセキュリティ単語
• 代替TLD
• Unicodeバリエーション
• 不審なMXレコード
• アクティブなクローンページ

Skysnag BrandGuardは、組織がフィッシング、詐欺、ブランド偽装に関連するなりすましドメインと不審な登録を監視するのを支援します。

XVII. 3. 証明書透明性データを監視する

証明書透明性データは、不審なインフラストラクチャを調査する際の別のシグナルを提供できます。

セキュリティチームは、次に関連する証明書を監視できます:

• 正規ドメイン
• 不審なブランドバリエーション
• 新しく発見されたなりすましドメイン

ただし、有効なTLS証明書は、サイトが機関に属していることの証明として決して解釈されてはなりません。

攻撃者が次を正当に制御している場合:

examplebank-login.com

彼らはそのドメインのTLS証明書も正当に取得できる可能性があります。

TLSは、ユーザーとそのサイト間の接続を保護します。

サイトがユーザーが考える銀行であることを証明するものではありません。

XVIII. 4. DNSおよびWebフィルタリングを使用する

金融機関は、既知の悪意のあるインフラストラクチャへのアクセスをブロックすることにより、内部的にも露出を制限できます。

制御には次が含まれます:

• セキュアDNS
• URLフィルタリング
• ドメインレピュテーション
• ブラウザ保護
• エンドポイント検出
• Web分離
• 脅威インテリジェンスフィード

DNSおよびレピュテーションベースのフィルタリングは、既知の悪意のあるおよび不審なドメインへの従業員の露出を削減できます。

XIX. 5. IDおよび認証制御を強化する

ドメイン監視は、すべてのユーザーがすべての攻撃を認識すると想定することはできません。

機関は、次のような制御を通じて盗まれた認証情報の価値を削減する必要があります:

• 多要素認証
• リスクベース認証
• デバイスインテリジェンス
• 取引監視
• 行動分析
• セッション制御
• ステップアップ検証

多層認証は、すべての欺瞞的な登録がユーザーが遭遇する前に検出されることを保証できるドメイン監視システムがないため、特に重要です。

XX. 6. 銀行偽装攻撃に対して顧客を準備させる

「文法の誤りを探す」などの一般的なアドバイスは、ますます不十分になっています。

顧客は、説得力のあるフィッシングページには次が含まれる可能性があることを理解する必要があります:

• 正しいブランディング
• HTTPS
• 有効なTLS証明書
• プロフェッショナルな言語
• なじみのあるセキュリティ用語

金融機関は、顧客に次を通じてサービスにアクセスすることを奨励する必要があります:

• 公式の銀行アプリケーション
• 保存された、以前に検証されたブックマーク
• 既知の公式ウェブサイト
• 不審なメッセージとは独立して取得された連絡先の詳細

顧客は、次を通じて受信したアカウントアクセスリンクに注意する必要があります:

• 未承諾のメール
• SMS
• ソーシャルメディア
• 検索広告
• メッセージングアプリケーション

7. ドメインテイクダウンプロセスを確立する

検出は、不審なインフラストラクチャが調査され、対処される場合にのみ有用です。

成熟した対応プロセスは、次を確立する必要があります:

1. ドメインの発見
2. リスク分類
3. 証拠収集
4. ホスティングプロバイダーの特定
5. レジストラのエスカレーション
6. 商標または悪用証拠
7. テイクダウン要求
8. 必要に応じて顧客への通知
9. 再登録の継続的な監視

攻撃者はインフラストラクチャを急速に回転させる可能性があるため、1つのドメインを削除してもインシデントを自動的に閉じるべきではありません。

関連する登録とインフラストラクチャも調査する必要があります。

メール認証となりすまし保護が連携する必要がある理由

銀行は、直接的なスプーフィングとなりすましドメイン偽装を同じ技術的問題として扱うことがあります。

それらは異なります。

これらの2つの攻撃を考えてみましょう。

攻撃A

From: [email protected]

不正な送信インフラストラクチャ

これは直接的なメール認証の問題です。

SPF、DKIM、DMARCが関連する制御です。

攻撃B

From: [email protected]

攻撃者がexamplebank-security.comを所有

攻撃者はSPF、DKIM、DMARCを正しく設定する可能性があります。

これは主にドメイン偽装の問題です。

制御は異なります:

• なりすましドメイン検出
• 脅威インテリジェンス
• Web分析
• ドメインレピュテーション
• 証明書監視
• テイクダウンプロセス
• ユーザーの意識

成熟した金融サービスセキュリティプログラムには、両方が必要です。

金融セクターの規制上の考慮事項

次のように述べる単一の普遍的な規制はありません:

「すべての銀行は、なりすましドメイン監視を展開しなければならない。」

要件は、管轄区域と機関の種類によって異なります。

ただし、金融セクターのセキュリティガイダンスは、フィッシング、認証、監視、詐欺防止、およびデジタルチャネルセキュリティに対する多層的でリスクベースのアプローチを一貫してサポートしています。

関連する制御には次が含まれる場合があります:

• 多層セキュリティ
• 多要素認証
• 監視
• アンチフィッシング制御
• DMARC
• ユーザー教育
• ソーシャルエンジニアリングテスト
• DNSフィルタリング

金融機関向けの個別のガイダンスでは、フィッシングやスプーフィングを通じた機関ブランドの不正使用を監視し、対応する必要性も取り上げられています。

意味するところは、DMARCやなりすまし監視だけがコンプライアンスを生み出すということではありません。

むしろ、これらの制御は、顧客、金融システム、および機関のアイデンティティを保護するために設計されたより広範なリスクベースのセキュリティプログラムの一部を形成することができます。

Skysnag ProtectおよびBrandGuardが問題のさまざまな部分にどのように対処するか

金融ブランドの保護には、機関の正規のメールアイデンティティと、攻撃者が悪用する可能性のある外部ドメインエコシステムの両方を保護する必要があります。

Skysnag Protect:所有するドメインを保護する

Skysnag Protectは、メール認証とドメイン施行に焦点を当てています。

組織が次を管理および監視するのを支援します:

• DMARC
• SPF
• DKIM
• 送信者の発見
• 認証アライメント
• 不正な送信ソース
• DMARC施行

これにより、攻撃者が機関が制御するドメインからメールを直接スプーフィングする能力が削減されます。

詳細はこちら: Skysnag Protect

Skysnag BrandGuard:所有していないドメインを検出する

BrandGuardは、外部偽装の問題に対処します。

BrandGuardは、次に関連する不審ななりすましドメインを特定するのに役立ちます:

• フィッシング
• 詐欺
• ブランド偽装
• タイポスクワッティング
• 悪意のあるドメイン登録

これは、機関自身のDNS環境の外部に存在するインフラストラクチャに対処することにより、メール認証を補完します。

詳細はこちら: Skysnag BrandGaurd

金融機関ドメイン保護チェックリスト

組織が各層の制御を持っているかどうかを評価します:

• すべての正規企業ドメインにDMARCが展開されている
• 施行に移行する前に正規の送信インフラストラクチャが特定されている
• 運用上適切な場合、p=quarantineまたはp=rejectでDMARCが施行されている
• SPFおよびDKIMが継続的に監視されている
• 休眠および防御ドメインがインベントリされている
• なりすましドメイン監視が有効になっている
• タイポスクワッティングバリエーションが監視されている
• Unicodeおよび同形異字バリアントが考慮されている
• 不審なMXおよびDNS活動が分析されている
• 証明書透明性データが有用な場合に組み込まれている
• 既知の悪意のあるドメインに対してDNSおよびWebフィルタリングが展開されている
• 顧客フィッシング教育がなりすましウェブサイトに対処している
• MFAまたは同等の多層認証制御が実装されている
• レジストラおよびホスティングプロバイダーのエスカレーション手順が文書化されている
• テイクダウン証拠および所有権文書が事前に準備されている
• ドメイン偽装インシデントが対応プレイブックに含まれている
• 新規登録および以前に休眠していたなりすましドメインが継続的に再評価されている

重要なポイント

金融機関は、攻撃者が確立された顧客の信頼を悪用し、盗まれた認証情報を金融詐欺に変換する可能性があるため、ドメイン偽装の魅力的な標的です。

しかし、すべての形式の「ドメインスプーフィング」が同じではありません。

直接的なドメインスプーフィングは、許可なく機関の実際のドメインを悪用します。

なりすましドメイン偽装は、機関に似せて設計された別の攻撃者制御のドメインを使用します。

タイポスクワッティングは、予測可能なドメインバリエーションとタイプミスを悪用します。

IDNおよび同形異字攻撃は、視覚的に類似した文字を使用して、悪意のあるドメインをなじみのあるものに見せます。

この区別により、どの制御が効果的かが決まります。

DMARC、SPF、DKIMは、金融機関が実際に制御するドメインの不正使用を大幅に削減できます。

攻撃者が別の欺瞞的なドメインを登録することを防ぐことはできません。

悪意のあるなりすましドメインには、有効なSPF、DKIM、DMARC、HTTPS、および正規のTLS証明書があり、それでも悪意がある可能性があります。

これが、効果的な金融セクターのブランド保護に複数の層が必要な理由です:

• 強力なメール認証
• DMARC施行
• なりすましドメイン監視
• DNSおよびURLフィルタリング
• 脅威インテリジェンス
• アイデンティティ保護
• 顧客教育
• 迅速な調査とテイクダウン

Skysnag Protectは、金融機関がDMARC、SPF、DKIM、送信者の発見、および施行を通じて制御するドメインを保護するのを支援します:

Skysnag BrandGuardは、フィッシング、詐欺、ブランド偽装に使用されるなりすましインフラストラクチャを検出することにより、これらのドメインを超えて保護を拡張します:

両者は、同じ問題の異なる側面に対処します:機関の認証されたアイデンティティを保護しながら、インターネット上の他の場所でそれを模倣しようとする攻撃者を特定します。