HTML描画型QRフィッシング、画像抽出とOCRベースのメールスキャンをすり抜ける

「クイッシング(quishing)」として知られるQRコードフィッシングは、画像ベースのペイロードを超えて進化を続けています。

攻撃者は現在、メール本文内のHTMLテーブルやテキストから直接スキャン可能なQRコードを描画する手法を使っており、画像添付ファイルや埋め込みビットマップ、<img>要素は一切残さないため、従来型のメールスキャナーでは検知できません。

ネットワークセキュリティ

この手法は、Secure Email Gateway(SEG)の構造上の死角を突いたものです。従来のアンチクイッシング対策は、画像を識別し、QRペイロードをデコードし、リンク先URLを抽出したうえで、レピュテーション情報やリダイレクトチェーン、フィッシングインテリジェンスと照合して評価する仕組みになっています。

同社によると、QRフィッシングの検知件数は2025年下半期に5倍に急増しており、QRコードを悪用したソーシャルエンジニアリングが全体として広がりを見せていることを裏付けています。

確認された事例では、取引先企業になりすましたメールが送られ、受信者に対して「機密扱いのDocuSign文書」とされるものにアクセス・署名するためQRコードをスキャンするよう指示し、最終的に認証情報を窃取するページへ誘導していました。

QRコードは本質的に、明暗のモジュールから成る格子状のパターンにすぎません。攻撃者はこの格子を表示するのに、PNGやJPEGといった画像ファイルを必要としません。

攻撃者は、何百もの小さなセルそれぞれに黒または白の背景色を割り当てたHTMLの<table>を使ってこのパターンを構築したり、Unicode文字やアスキーアート風のブロック文字を使って格子を再現したりすることができます。

受信者のメールクライアントは、これらの要素をカメラで読み取り可能な、目に見えるQRコードとして描画します。メールに従来型の画像ファイルが含まれていなくても、スマートフォンは通常どおりそれをスキャンできてしまいます。

Internet Storm Centerの研究者は、HTMLテーブルを使ってQRコードを描画する実際のキャンペーンを確認しています。

12月22日から12月26日にかけて送信されたサンプルでは、視覚的に「押しつぶされた」ようなQRブロックを使った最小限のおとりが用いられていました。

エンコードされたURLはlidoustoo[.]click配下の個別のサブドメインを指しており、受信者のメールアドレスがURLのパス内に埋め込まれていたことから、このキャンペーンが追跡や標的別配信を意図して設計されていたことがうかがえます。

この手法が問題となるのは、画像ベースの検査パイプラインが一般的に画像の抽出から処理を開始する点にあります。

ゲートウェイが画像を識別できなければ、QRデコーダーやOCRエンジンはそもそも動作しない可能性があります。悪意あるURLは、被害者がスキャンするまで、描画された視覚的な格子の中に隠されたままになります。

Image

PhishUの研究者によると、HTML描画型のQRコードがこのワークフローを崩壊させるのは、悪意あるリンク先がマークアップの視覚的な配置の中にのみ存在し、即座に抽出可能なハイパーリンクや画像オブジェクトとしては存在しないためです。

HTML描画型QRフィッシング

多くのメールクライアントはデフォルトでリモート画像の表示を抑制しており、ユーザーが「画像を表示」を選択する必要があります。この制御機能は、リモートホスト上に置かれた画像ベースのQRコードへの露出は減らせますが、メールのマークアップから描画されるQRコードは防げません。

HTMLテーブルはメッセージ本文の一部であり、メールクライアント側でローカルに描画されます。その結果、外部画像がブロックされていても、QRコードは表示されたままになる場合があります。

この攻撃は、視覚的なペイロードの問題を事実上、レイアウトの問題へとすり替えているのです。

テキスト文字によるQRコードには別の制約があります。メールクライアントはフォントサイズや文字間隔、行の高さを変更できるためです。例えばGmailのモバイル版では、等幅フォントのグリフが十分に崩れてしまい、テキストで描画されたQRコードがスキャン不能になることがあります。

テーブルベースの描画のほうが信頼性が高いのは、セルの幅や高さ、背景色がGmailやOutlookを含む旧来のメールエンジンで広くサポートされているためです。

Image

ただし、この手法には運用上の制約も伴います。単純にテーブルを実装すると、非常に大きなHTMLメッセージが生成されてしまう可能性があります。

Gmailは102KB前後のしきい値でメッセージを切り詰めることがあり、その場合QRテーブルが描画途中で分断され、視覚的なコードが壊れてしまうおそれがあります。

攻撃者やレッドチームの担当者は、同一色が連続する部分をcolspanで圧縮することでマークアップ量を削減しつつ、QRの格子パターンを維持することでこの問題を回避できます。

このセキュリティ上の含意は明快です。画像がないからといって、QRコードが存在しないとは限らないのです。防御側は、クイッシング対策の検知範囲を、添付ファイルやインライン画像、OCRパイプラインの枠を超えて拡張する必要があります。

セキュリティ意識向上トレーニング

メールセキュリティ製品は、不審なHTMLを隔離環境でレンダリングし、その結果得られる視覚的な出力を検査したうえで、スクリーンショットや再構築したDOMコンテンツからQRコードのデコードを試みるべきです。

検知ロジックでは、非常に小さな黒白のセルで構成された高密度のHTMLテーブル、bgcolor属性の不自然な使用、繰り返し現れる固定ピクセルサイズ、QRコード状の格子に配置されたUnicode文字のブロックなども検知対象に加えることができます。

組織は、こうしたシグナルを送信者のレピュテーション、ブランドなりすまし、認証失敗、リダイレクトの挙動、そして「scan to review(スキャンして確認)」「scan to sign(スキャンして署名)」「scan to access document(スキャンして文書にアクセス)」といったQR関連の文言と組み合わせて相関分析すべきです。

ユーザーの意識向上も依然として不可欠です。従業員は、企業の認証情報を求めるQRコードは疑わしいものとみなし、心当たりのないQRコードをスキャンするのではなく、既知のブックマークや承認済みアプリケーション、あるいは手入力のURLを通じて業務サービスにアクセスするべきです。

Kasperskyは、ビジネスメールにテキストで構成されたQRコードが含まれている場合、それを無害な書式上の選択とみなすのではなく、高リスクなフィッシングの兆候として扱うべきだと指摘しています。

7段階のメトリクスゲート方式によるAI SOC導入フェーズを学ぶ – 無料のAI SOC導入プレイブック2026をダウンロード

翻訳元: https://gbhackers.com/html-rendered-qr-phishing/

本記事は gbhackers.com の記事を翻訳・要約したものです。