「急速な流転」が管理者をもてあそぶ
「Fast-Flux」を利用した高度なフィッシングテクニック
2007年夏以来、大規模なFast-Fluxボットネットが爆発的に増加した。悪党たちは異なるシステム間で素早く移動することにより捜査の目をくらます。
何年か前までは、攻撃者たちは犯罪的な金もうけ計画の要となる重要なマシンを1台か2台しか持っていないのが普通だった。このため、悪党どもはその犯罪インフラの1カ所あるいは2カ所で単一障害点を抱えることが多かった。フィッシング詐欺のWebサイトが排除される場合もあれば、スパマーのメールサーバがブラックリストに追加される可能性もあった。またボットハーダー(ボットを操る人)の場合、IRCサーバ(ボットに感染したすべてのホストにコマンドを配布する目的で多くのボットネットで使われてきたサーバ)が停止させられるかもしれない。
では、自ら築き上げた犯罪帝国から何百万ドルもの大金を稼いでいる今日の先進的なボットハーダーたちは、こういった単一障害点にどのように対処したのだろうか――彼らが用いたのは「Fast-Flux」という手法だ。
2007年夏以来、大規模なFast-Fluxボットネットが爆発的に増加した。この手法を利用すれば、悪党たちは何千台もの「使い捨て」のゾンビマシンを利用して異なるシステム間で素早く移動することにより、捜査の目をくらますことができる。捜査する側からすれば、追跡すべきターゲットが絶えず変化するからだ。
Fast-Fluxの仕組み
一例として、データ泥棒が大手銀行を装ったWebサーバを持っているというフィッシングのシナリオを考えてみよう。このマシンを「EvilServer」と呼ぶことにする。IPアドレスは「w.x.y.z」とする。
攻撃者はこの偽銀行に顧客をおびき寄せるために、ユーザーをだまして電子メールで配信したリンクをクリックさせようとする。このリンクは、攻撃者がコントロールするドメイン名に関連付けられている。このドメイン名を「www.fakebank.com」としよう(この名前ではユーザーをだますことはできないだろうが、そこは大目に見ていただきたい)。
通常のフィッシング攻撃では、リンクに含まれる名前(www.fakebank.com)は、w.x.y.z(EvilServerのアドレス)に解決される。このため、ユーザーがこのリンクをクリックすると、EvilServerに直接接続することになる。しかしFast-Fluxでは、www.fakebank.comはいかなる形でもEvilServerを参照しない。
というのは、www.fakebank.comに関連したDNSサーバは、ラウンドロビンDNSと呼ばれる手法を用いるからだ。ラウンドロビンDNSは、1つの名前に対するDNSクエリへの応答として多数のIPアドレス(5つ以上の場合が多い)を返すことができる。ラウンドロビンDNSそのものが悪いわけではない。これは複数のサーバ間で負荷を分散するために開発された技術だ。しかし、Fast-FluxはラウンドロビンDNSを悪用してwww.fakebank.comに対して複数の応答を返し、このサイトに複数のIPアドレスを対応付けることができる。これらのアドレスを「a.b.c.d」「e.f.g.h」「i.j.k.l」などと呼ぶことにする。
そして、ユーザーがwww.fakebank.comというリンクをクリックすると、ユーザーのブラウザはこれらのIPアドレスの1つに対応したWebサーバに接続しようとする。しかし、これらのアドレスに対応したマシンは実際にはボットに感染したマシンで、透過型Webプロキシを動作させている。Webリクエストを受信すると、感染マシン上で動作している各Webプロキシはw.x.y.zにあるEvilServerにリクエストを送信する。
だがそれだけでは終わらない──何しろこの手法は「Fast-Flux」(急速な流転)と呼ばれているのだ。攻撃者はラウンドロビンDNSレコードのTTL(Time To Live)を非常に小さな値に設定できる(DNSのTTLとは、DNSクライアントが廃棄されるまでの間、レコード内に保持される時間を示す)。悪党がFast-Fluxを利用すれば、DNSレコードを素早く時間切れにできる(TTLが3~10分に設定されることが多い)。それだけでなく、彼らはプロキシとして機能するほかのボット感染マシンのIPアドレスを使って、新しいDNSエントリを絶えず追加するのだ。
DNSとプロキシを利用したこの技は、捜査員がEvilServerを見つけるのを難しくする。例えばa.b.c.dというIPアドレスにあるマシンを停止するよう各ISPに要請しても、それはWebプロキシが動作しているユーザーの感染マシンであり、実際の偽銀行ではない。
捜査員がISPを説得してa.b.c.dへのトラフィックを遮断させたとする。しかし、彼がそのリンクを再びクリックすると、今度はe.f.g.hに移動し、偽銀行がまだそこに存在することを知るのだ。捜査員はもぐらたたきのように多数のプロキシを次々とつぶしていくことはできるが、悪党は短いTTLでIPアドレスを補充し続け、これらのアドレスを順番にwww.fakebank.comという名前に割り振るのだ。
それならば、捜査員は悪党がwww.fakebank.comの名前解決に用いているDNSサーバを停止させればいいのではないだろうか。しかし、こういった停止要求を無視する企業が提供している商用DNSサービスを利用している悪党もいる。それに、Fast-Fluxを利用する攻撃者は、サイバー犯罪法が甘い(あるいは存在しない)国のISPを選ぶものだ。また、攻撃者たちはそのドメインに対して権威を持つDNSサーバを絶えず変えるようにFast-Flux手法に工夫を加えたりしているのだ。
エンタープライズ環境でのFast-Flux攻撃の調査
大抵の企業は、自社に対してFast-Flux手法が使われているかどうかなど知る必要はない。フィッシングおよびボット全般に対処するだけで十分だ。すなわち、以下のような対策を講じればいいのだ。
- 不正なリンクをクリックしないようユーザーを教育する
- パッチおよびウイルスシグネチャを更新する
- ファイアウォールを出入りするネットワークトラフィックを制限する
とはいえ、Fast-Flux攻撃手法が用いられている可能性をどうしても調べたいのであれば、その方法を幾つか紹介しよう。「DNSstuff Tools」にアクセスし、フィッシングメールのURLを「Deobfuscator」フィールドにペーストする。このシンプルなWebアプリケーションは、不自然にエンコードされたURLを人間が理解しやすいURLに変換する。
次に、変換によって明確にされたURLからドメイン名を取り出し、それに関連したIPアドレスを調べる。これにはDNSstuffの「DNS Lookup」オプションを利用すればいい。もし多数のアドレスレコード(「A」レコード)がまったく同じ名前に対応していれば、何らかの形のラウンドロビンDNSが利用されている可能性が高いということだ。また、TTLフィールドも調べること。600(10分)以下の低い値に設定されていれば怪しいといえる。しかし、正規の銀行でもラウンドロビンDNSと短いTTLを使用している場合がある。Fast-Fluxが使用されているかどうか確認するには、10分後に再度DNS Lookupを行い、まったく新しいアドレスレコード/IPアドレスのセットが表示されるかチェックすればいい。
WindowsにはDNSレコードを分析するためのツールが組み込まれている。このツールを使うには、マシンのDNSキャッシュにドメイン名を読み込ませる。これには、ドメイン名に対してpingを実行する(例えば、「ping www.fakebank.com」という具合だ)。
DNSキャッシュにレコードを読み込ませたら、「ipconfig /displaydns」コマンドを実行してレコードを表示させる。キャッシュには各ドメインレコードのTTL値が含まれているはずだ。このコマンドを1~2秒ごとに繰り返し実行すれば、TTL値が減少するのが分かる。分析の焦点を絞るためにエントリを消去するには、「ipconfig /flushdns」を実行する。次に、目的のホストに再びpingを実行してそれをキャッシュに読み込ませた上で、「ipconfig /displaydns」を実行する。
レコードのTTLが小さな数であれば、そのIPアドレスを記録した後、レコードが時間切れになるまで待ち、再びターゲットに対してpingを実行する。キャッシュ内のIPアドレスが絶えず変化するようであれば、Fast-Flux環境に遭遇した可能性がある。
さらに詳しく調べるには、「DNSstuff tools」サイトに戻り、そこにある「Whois」検索ツールを利用する。Whois検索は必ずしも正確とは限らないが、所与のドメイン名やIPアドレスに関連した人々、場所、組織に関する情報を提供してくれる。
Whoisツールにドメイン名を入力し、きちんとした結果が返されるかどうか確認する。信頼できる組織に対して古くから登録されているドメイン名なのか、それとも多くの信頼できる銀行をホスティングしているという話は聞かない遠い国の企業に対して最近登録されたドメイン名なのか、といったことをチェックするのだ。「ipconfig /displaydns」のIPアドレスにWhois検索をかけることもできる。コンシューマーを対象としたISPに関連した多数のエントリが見つかった場合には、これらのシステムはISPのネットワーク上でボットに感染したホストである可能性が高い。ボットネットの可能性がある場合は、ISPに報告するか、新たなフィッシング攻撃に強い関心を抱いているAPWG(Anti-Phishing Working Group)に報告すべきだ。
本稿筆者のエド・スコウディス氏は、ワシントンD.C.に本社を置く情報セキュリティコンサルティング会社、インテルガーディアンズの創業者で、同社の上級セキュリティコンサルタントを務める。専門分野はハッカーの攻撃と防御対策、情報セキュリティ業界、コンピュータプライバシー問題など。「Counter Hack Reloaded」(Prentice Hall)や「Malware: Fighting Malicious Code」(Prentice Hall)などの著作がある。同氏は2004年、2005年、2006年にセキュリティ分野のMicrosoft MVPを受賞したほか、Honeynet Projectにも携わった。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社MatrixFlow] 「物流リソース最適化」ガイド:人員・配車・傭車を出庫依頼の確定前に決めきる -
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か? PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える? 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
2
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
3
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
4
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
-
5
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
6
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
7
「結局使わなくなる」Microsoft 365 Copilotを半年で定着 キリンの3施策
-
8
「Wi-Fi 7」経由でWindowsが乗っ取られる? 最高権限奪取の恐怖
-
9
「中堅・中小企業のネットワーク・セキュリティ運用実態」に関するアンケート
-
10
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
3
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは
-
8
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー