ドメインスプーフィングとは?
ドメインのスプーフィングは、攻撃者が正当なドメインを偽装し、ユーザーを欺く、セキュリティシステムを迂回し、不正なアクセスを得るためのサイバー攻撃技術です。 これは、メールヘッダを鍛造したり、ルカライラドメインを登録したり、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')
##行動異常
- 緊急言語(「今すぐ行動!」、すぐに無線転送」)
- 不正な要求(ギフトカードを求めるCEO)
- 文法/スペルミス
- 支払いの詳細を変更する要求
- 比類のないドメインへのリンク
ドメインスプーフィング防止
メール認証(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
それから:
- プライマリドメインへのリダイレクト
- 情報ページのある公園
- 正当な目的のために使用
モニターブランドメンション
不正なドメイン登録を検知するためにサービスを利用する:
- ドメイン名を含むドメイン登録のためのGoogleアラート
- 証明書の透明性のログ(発行されたSSL証明書のモニター)
- 新規登録のWHOISモニタリング
-ツールドメイン
- クラウドフレアによるシフト
- ブランドシールド
- ボルスター
社員研修
定期的なセキュリティ教育:
- 不正なメールを識別する方法
- 代替チャネルを介して疑わしい要求を検証
- 予期しないメールのリンクをクリックしないでください
- 送信者ドメインを慎重にチェック
- ITに疑わしいメールを報告する
技術的な制御
DMARCの執行:p=reject (block spoofed email entirely)
電子メール ゲートウェイのフィルタリング:
- 外観ドメインのスキャン
- 内部に見える外部メールのフラグ
- 既知の悪い送信者IPをブロックする
[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
ツールを使用する
- MXToolboxドメイン健康チェック
- dmarcian DMARCインスペクター
- Googleの管理者ツールボックスメッセージヘッダー
- PhishTank(ドメインが報告されているかどうかを確認してください)
ドメインのスプーフィングは深刻な脅威ですが、適切なメール認証、監視、ユーザー教育を通じて効果的に軽減することができます。