フィッシングキットの解剖:偽ページの裏側で何が起きているか
フィッシングページが一から手作業で書かれることはほとんどありません。ほとんどの場合、それは既製のアーカイブ、つまりフィッシングキットから作られます。ダウンロードした.zipファイルを、借りた、あるいは乗っ取ったサーバーに置くだけで、数分のうちに稼働状態になります。ここでは、見た目から盗まれたデータに至るまで、その内部の仕組みを見ていきます。
5分で組み立てられる道具一式
キットの最初の部品は見た目(ファサード)です。本物のサイト(銀行、メッセージサービス、税務当局のサイトなど)のHTML、CSS、JavaScriptコードをそのまま複製したものです。このコードを手に入れるのは簡単で、どんなブラウザでも保存できます。キットの役割はそれを機能させることにあります。入力欄は、本物のサービスに対してパスワードを確認する代わりに、入力された内容をすべて取得するスクリプトに接続されます。
より長く生き延びるために、キットはしばしば自身の仕組みを隠します。データを取得するスクリプトは、たとえばBase64などでエンコードされていることが多く、そのため一見しただけでは読めず、既知のキーワードを探すクローラーや自動セキュリティスキャナーにも見つかりにくくなります。これは強固な暗号化ではありません。時間をかけてスクリプトをデコードする人間であれば、問題なく解読できます。あくまで検知されるまでの数時間から数日を稼ぐための手段にすぎません。
被害者が入力している間にページが確認していること
よくできたキットは、何でもかんでも記録するわけではありません。本物のサイトと同じように、入力内容をリアルタイムで検証します。理由は二つあります。まともなフォームであるかのように見せかけること、そして何より、使い物にならないデータで攻撃者を煩わせないことです。
- メールアドレスの形式は文字単位でチェックされます(「@」の有無、有効なドメインかどうかなど)。
- クレジットカード番号はルーンアルゴリズムにかけられます。これは、カード自体について何も知らなくても、16桁の数字の並びが本物のカードに対応しうるかを確認する単純な数式です。適当に作った番号はほぼ必ずこのテストに落ちます。キットは入力を拒否してもう一度カード情報を求め、あたかも厳格なサイトであるかのような印象を与えます。
最も効果的で、かつ最も目立たない部分は、二段階認証(MFA/2FA)に関するものです。最近の多くのキットは、パスワードが入力された直後に「確認中…」といったローディング画面を表示します。その裏では、攻撃者がまさに盗んだばかりの認証情報を使ってリアルタイムで本物のサイトにログインしています。本物のサイトは被害者にSMSで本物のコードを送信し、被害者はそれを疑うことなく偽ページに入力します。キットはそれを即座に攻撃者へ転送し、攻撃者は今度はそれを本物のサイトに入力します。被害者にはただ画面が少し長く回っているように見えるだけですが、攻撃者はワンタイムコードを含む完全なアクセス権をすでに手に入れています。
この仕組みはあくまで手作業による仕掛けであり、攻撃者が手動で確認する必要があります。人間の介入をまったく必要とせず、サーバーが被害者と本物のサイトの間に偽ページを挟み込む、はるかに自動化されたバージョンも存在します。これはAiTM:フィッシングがパスワードだけでなくセッションまで盗むときガイドのテーマです。
データが実際にどこへ行くのか:3つの出口
検証を終えたデータは、攻撃者のもとに届くためにサーバーから外へ出なければなりません。現在のキットでは、常に3つの経路が使われています。
- TelegramまたはDiscordのウェブフック:今日最もよく使われる方法です。キットは非公開のTelegramまたはDiscordチャンネルに単純なリクエストを送信し、盗まれた認証情報のひとつひとつが攻撃者のスマートフォン上の会話に即座に表示されます。速く、無料で、ページのソースコードを見ない限り気づきにくい方法です。
- メール送信:キットはPHP言語の
mail()関数を使い、入力された内容を短いテキストレポートとして、攻撃者が指定したアドレスへ送信します。 - ローカルのログファイル:より原始的な方法で、キットは盗んだデータをサーバー上の隠しファイル(
.txtまたは.csv)に直接書き込み、攻撃者は後でそれを取りに来ます。
これら3つの経路は互いに排他的ではありません。多くのキットは、即座に通知を受け取るためのウェブフックと、ウェブフックが機能しなくなった場合の予備としてのファイルを組み合わせています。
幕が下りる:リダイレクトと痕跡消去
データが送信された後、偽ページはそのまま止まるわけではありません。模倣した対象サービスの本物のログインページ(たとえばlogin.live.com)へ被害者をリダイレクトし、しばしばさりげないエラーメッセージを添えます。狙われている効果は明確です。被害者はパスワードを打ち間違えたのだと思い込み、本物のサイトで再度認証情報を入力し、普通にログインでき……何も疑わないのです。
一部のキットはさらに一歩進み、最初の攻撃が成功した後に自分自身を守ります。仕組みを暴露しかねないログを消去したり、被害者のIPアドレスをブロックしたりして、2回目のアクセス(たとえばページを再調査しに戻ってきた研究者によるもの)が完全な罠ではなく、空白ページやエラーに行き当たるようにします。
これほど周到に組まれた仕組みが最終的にどう崩壊するか
これだけ注意を払っていても、キットは利用可能な痕跡を残します。最も多いのはサーバーの設定ミスで、ディレクトリリスティング(オープンディレクトリ)と呼ばれるものです。これにより誰でもサイトのフォルダを閲覧でき、それとともに、設置された当時のままのキットの.zipアーカイブをダウンロードできてしまいます。このアーカイブを手にした調査者は、平文か、ほとんどエンコードされていない状態で、本当に重要な認証情報――Telegramボットのトークン、Discordチャンネルの識別子、受信用メールアドレス――を見つけることがよくあります。
これらの認証情報は一つのページだけに関わるものではありません。同じボットトークンは、同じ攻撃者による複数のキャンペーンで使い回されることがよくあります。そのためTelegramやDiscordに通報することで、発見された1件のサイトをはるかに超えて、一連のサイト群を一気に遮断できる場合があります。これはメール送信インフラについて詳しく解説したフィッシングを分析する:メッセージからインフラまでガイドと同じ原理です。見つかった要素の一つひとつがてこ(レバレッジ)にもなり、キットをホストするサーバーも、他のフィッシングページと同様にそのホスティング事業者へ通報できます(ホスティング事業者の適切な通報先を見つけるを参照)。
そこまで至る前に、まず取るべき最初の行動は、ページへ導いたリンクを確認することです。不審なメールをBaitbackに貼り付けると、このツールがリダイレクトをたどり、送信元サーバーとそのホスティング事業者を特定し、自分でキットのコードを調べる必要なく、通報用メッセージを直接準備してくれます。
- フィッシングページはほとんど常に、複製された後に検知を遅らせるため難読化された、既製のキットから作られる。
- リアルタイム検証(ルーンアルゴリズム、メール形式、リアルタイムで中継されるMFA)は、使い物にならないデータをふるいにかけ、ワンタイムコードを盗むために使われる。
- 盗まれたデータは、TelegramまたはDiscordのウェブフック、PHPによるメール、またはローカルのログファイルを通じて送られることが最も多い。
- 本物のサイトへの最終的なリダイレクトは、被害者の疑念を鎮めるためのものである。
- オープンディレクトリはキットの完全なアーカイブを渡してしまう可能性があり、それとともに、攻撃者のインフラ全体を一気に遮断できる認証情報も手に入ってしまう。