ドメイン スプーフィング

セキュリティ & 脅威
悪意のある攻撃者が正規のドメインになりすましてユーザーやシステムを欺く攻撃。
← 用語集に戻る

ドメインスプーフィングとは?

ドメインのスプーフィングは、攻撃者が正当なドメインを偽装し、ユーザーを欺く、セキュリティシステムを迂回し、不正なアクセスを得るためのサイバー攻撃技術です。 これは、メールヘッダを鍛造したり、ルカライラドメインを登録したり、DNS脆弱性を悪用したりしてトラフィックをリダイレクトしたりすることができます。

ドメインスプーフィングの種類

電子メールのスプーフィング

信頼できるドメインから表示されるメールの「From」アドレスを鍛造します。

Legitimate:

From: support@paypal.com

Actual sender: PayPal's mail servers

Spoofed:

From: support@paypal.com

Actual sender: attacker's server

Without SPF/DKIM/DMARC, appears legitimate

##表示名スプーフィング

異なる電子メールを使用して送信者の表示名を操作する:

Display: CEO John Smith <john.smith@company.com>

Actual email: attackercontrol@malicious.com

Many email clients show only display name prominently

##Lookalikeドメインスプーフィング

正当なドメインの登録:

Legitimate: paypal.com

Lookalikes:

paypa1.com (1 instead of l)

paypal-secure.com (added word)

paypai.com (typo)

paypаl.com (Cyrillic 'а' instead of Latin 'a')

DNS のスプーフィング (キャッシュ・ポジショニング)

DNS キャッシュを強制してトラフィックをリダイレクトします。

User types: bank.com

DNS poisoned: Returns attacker's IP instead of real bank

User arrives at: Fake bank.com (phishing site)

User thinks: They're on real site (URL shows bank.com)

発信者 ID のスプーフィング (VoIP)

偽の電話番号を表示(ドメインに関係なく、関連する概念)。

電子メールのスプーフィングの仕組み

SMTPプロトコルギャップ

SMTP (電子メールの議定書)は作り付けの送信者の確認を持っていません:

SMTP Conversation:

Client: HELO attacker.com

Server: 250 Hello

Client: MAIL FROM: <ceo@victimcompany.com>

Server: 250 OK (accepts without verification)

Client: RCPT TO: <employee@victimcompany.com>

Server: 250 OK

Client: DATA

From: ceo@victimcompany.com

Subject: Urgent wire transfer needed

→ Server delivers it

SMTP では、送信機が victimcompany.com を実際に制御しているかどうかを検証します。

ヘッダー操作

攻撃者は基本的なフィルタを迂回するヘッダーを生成します。

From: "CEO John Smith" <ceo@legitimate.com>

Reply-To: attacker@malicious.com

User sees trusted sender

Replies go to attacker

リアル·ワールド·スプーフィング攻撃シナリオ

##ビジネスメール侵害(BEC)

1. Attacker researches company structure

2. Spoofs CEO's email to CFO

3. "Urgent wire transfer needed for acquisition"

4. CFO transfers funds thinking it's legitimate

5. Company loses millions

##フィッシングキャンペーン

1. Spoof bank or tech company domain

2. Send emails about "suspicious activity"

3. Link goes to lookalike domain

4. User enters credentials on fake site

5. Attacker steals credentials

##インボイス詐欺

1. Attacker spoofs supplier's domain

2. Sends updated invoice with attacker's bank details

3. Victim pays attacker instead of real supplier

4. Legitimate supplier never receives payment

##マルウェア配布

1. Spoof trusted software company

2. Email with "critical security update"

3. Attachment contains malware

4. User trusts "legitimate" sender and opens it

ドメインスプーフィングの検出

メールヘッダー分析

一貫性のための完全なヘッダーを調べる:

From: support@paypal.com

Return-Path: <random@suspicious.com> ← Red flag

Received: from unknown.net [1.2.3.4] ← Not PayPal's servers

Real email would have:

Received: from mx.paypal.com [verified PayPal IP]

Return-Path: <support@paypal.com>

SPF/DKIM/DMARCの特長 チェックイン

Authentication-Results: recipient.com;

spf=fail smtp.mailfrom=paypal.com ← Spoofed

dkim=none ← Not signed

dmarc=fail ← Failed policy

正当なPayPalメールは、すべてのチェックを通過します。

外観検査

微妙な相違を探して下さい:

Real: paypal.com

Fake: paypal-secure.com (extra word)

Fake: paypαl.com (Cyrillic character)

Fake: paypal.co (missing 'm')

##行動異常

ドメインスプーフィング防止

メール認証(Critical)を実行

SPF (Sender Policy Framework):
example.com.    IN    TXT    "v=spf1 include:_spf.google.com -all"

Authorizes which servers can send for your domain

DKIM (ドメインキー識別メール):
Cryptographically signs outgoing emails

Receivers verify signature using DNS public key

Tampered emails fail verification

DMARC(ドメインベースのメッセージ認証):
_dmarc.example.com.    IN    TXT    "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Tells receivers to reject emails that fail SPF/DKIM

Provides reports on spoofing attempts

執行レベル:
p=none       Monitor only (start here)

p=quarantine Send failures to spam

p=reject Block failures completely (goal)

防御ドメインを登録する

一見したドメインを積極的に登録する:

Primary: company.com

Register:

  • Common typos: conpany.com, compamy.com
  • Different TLDs: company.net, company.org, company.co
  • Hyphenated: com-pany.com, company-inc.com
  • Plurals: companies.com

それから:

モニターブランドメンション

不正なドメイン登録を検知するためにサービスを利用する:

ツール:

-ツールドメイン

社員研修

定期的なセキュリティ教育:

技術的な制御

DMARCの執行:
p=reject (block spoofed email entirely)
電子メール ゲートウェイのフィルタリング: 注意事項:
[EXTERNAL EMAIL] This email originated outside the organization
リンク書き:

配信前のメールにURLをチェックしてサニタイズします。

ベンダーポリシーフレームワーク:

承認された送信方法(SMTPなし)のみを許可します。

高度なスプーフィング技術

##ホモグリフ攻撃

異なるアルファベットから視覚的に同様の文字を使用する:

Latin 'a' vs Cyrillic 'а' (U+0430)

Latin 'o' vs Cyrillic 'о' (U+043E)

googlе.com (Latin 'e' replaced with Cyrillic 'е')

Looks identical to: google.com

検出:Punycodeエンコーディング
googlе.com → xn--googl-6nd.com (encoded)

Browsers show: ⚠️ xn--googl-6nd.com

##サブドメインスプーフィング

異なるドメインのように見えるサブドメインを作成する:

legitimate-bank.attacker.com

Appears as: legitimate-bank (subdomain of attacker.com)

Users see: "legitimate-bank" and assume it's safe

##DNSハイジャックとマン・イン・ザ・ミドル

1. Attacker compromises DNS server or router

2. Changes bank.com resolution to attacker's IP

3. Serves fake bank site

4. Uses valid SSL cert (from Let's Encrypt, free)

5. User sees https://bank.com with padlock

6. User thinks it's safe, enters credentials

防衛:DNSSEC、証明書ピン留め、HSTSプリロード。

法的および規制の側面

アンチサイバースクワッティング消費者保護法(ACPA)

商標と同等なドメインの登録を禁止する米国法

##制服ドメインネーム争訟政策(UDRP)

商標紛争を解決するためのICANNポリシー:

##刑事罰

不正行為のためのドメインのスプーフィングは、以下に訴えられます。

罰金と懲罰を含む。

ドメインスプーフィングへの対応

ドメインが侵害されている場合

1. p=reject の実装 DMARC

_dmarc.example.com.    TXT    "v=DMARC1; p=reject; rua=mailto:abuse@example.com"

2. 警報顧客/パートナー

- スプーフィングキャンペーンについて

- インジケータを提供(探すべきもの)

- レポートチャネルを付与する

3. 当局に報告

- FBI IC3(米国)

- ローカルサイバー犯罪ユニット

- アンチフィッシングワーキンググループ(apwg.org)

4. Takedownリクエスト

- ホスティングプロバイダにフィッシングサイトを報告

- ドメインレジストラへの報告

- Googleの安全なブラウジングレポートを使用する

5. モニターDMARCレポート

- スプーフィングソースを特定する

- 攻撃ボリュームとパターンを追跡

Lookalikeドメインを発見した場合

1. 文書証拠

- スクリーンショット

- WHOISデータ

- メールヘッダー

2. UDRP 苦情 (商標を所有している場合)

3. 登録者虐待報告

4. 法的行為 (重大な害がある場合)

あなたの防衛をテストする

テスト電子メールのスパム保護

# Send test spoofed email to yourself

swaks --to employee@yourcompany.com \

--from ceo@yourcompany.com \

--server test-smtp-server.com \

--header "Subject: Test Spoofed Email"

# Check if it's delivered or blocked

# Check authentication results in headers

DMARCの設定をチェックする

dig _dmarc.example.com TXT

# Should return policy (p=reject ideally)

_dmarc.example.com. 300 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

##SPFとDKIMの検証

# SPF

dig example.com TXT | grep spf

# DKIM (check common selectors)

dig google._domainkey.example.com TXT

dig default._domainkey.example.com TXT

ツールを使用する

ドメインのスプーフィングは深刻な脅威ですが、適切なメール認証、監視、ユーザー教育を通じて効果的に軽減することができます。

この知識を実践する

DomScan の API を使用してドメインの可用性、状態などを確認します。