UnsplashのBranko Stancevicが撮影した写真
メールに添付されたHTMLファイルを開いただけで、いつの間にかマルウェアがダウンロードされていた――。その背景で使われている手口のひとつが「HTMLスマグリング」です。HTMLやJavaScriptの正規の機能を悪用し、ネットワーク上では一見「普通のHTML」にしか見えない形でマルウェアを配布するため、従来の境界防御だけでは検知が難しくなっています。本記事では、HTMLスマグリングの仕組みや脅威、代表的な攻撃シナリオ、技術的対策と運用のポイントを整理し、自社で何から着手すべきか判断できる状態を目指します。
HTMLスマグリングとは、HTMLファイルやウェブページ内のJavaScriptにマルウェアの「材料」を埋め込み、ユーザーのブラウザ上で最終的なペイロード(ZIPや実行ファイルなど)を生成・保存させる攻撃手法を指します。
攻撃者は、Base64などでエンコードしたバイナリデータや、ペイロードを取得するための情報をHTMLに埋め込み、ブラウザ標準の機能だけを使ってファイルを復元します。このとき、ネットワークを流れているのはあくまで「HTML」「テキストデータ」に過ぎないため、多くのメールゲートウェイやプロキシはマルウェアとして検知しづらくなります。
従来のマルウェア配布では、以下のような形が一般的でした。
こうした手法は、拡張子・ファイル形式・シグネチャなどで判別しやすいため、ゲートウェイ側でのフィルタリングやアンチウイルス製品による検査が比較的有効でした。
一方、HTMLスマグリングでは、
という特徴があり、「危険なファイルが境界を通過する」というイベント自体がログに現れにくい点が大きな違いです。
HTMLスマグリングが近年注目される背景には、次のような事情があります。
攻撃者側から見ると、既存のインフラ(ブラウザ・HTML)をそのまま利用しつつ、検知をすり抜けやすいという、コストパフォーマンスの高い手口と言えます。
代表的なHTMLスマグリング攻撃は、おおよそ次のような流れで進行します。
<a download> などの機能で、ユーザーにZIP/ISOファイル等をダウンロードさせるこの過程で、境界防御装置が観測するのは「HTMLファイルの受信/Webページの閲覧」にとどまり、マルウェアとして明らかなファイルは端末上で初めて姿を現すことになります。
HTMLスマグリングでは、以下のような標準機能が多用されます。
いずれも本来は正当な用途のために用意された機能ですが、攻撃者がこれらを組み合わせることで、ネットワーク上では「無害そうなHTML」に見える状態から、ローカル環境でマルウェアを復元できてしまいます。
HTMLスマグリング自体は、XSSやCSRFのような「アプリケーション脆弱性」を直接突く攻撃ではありません。しかし、以下のように他の攻撃手法と組み合わされるケースがあります。
そのため、HTMLスマグリング対策は、クライアント側(メール、ブラウザ、EDR)だけでなく、Webアプリケーション側の基本的なセキュリティ対策ともセットで考える必要があります。
HTMLスマグリングを起点にRATやインフォスティーラが導入されると、端末内のさまざまな情報が盗まれるリスクがあります。
盗まれた情報は、クラウドサービスや社内システムへのなりすまし、不正送金、顧客情報の持ち出しなどに悪用され、企業の信用失墜や法令違反につながる可能性があります。
近年の事例では、HTMLスマグリングを初期侵入のきっかけとし、その後に以下のようなマルウェアを段階的に投入する攻撃が報告されています。
ユーザーが一度HTMLファイルを開き、生成されたファイルを実行してしまうと、以降は攻撃者のペースで内部侵害が進んでしまうケースも少なくありません。
HTMLスマグリングには、監視・検知を難しくする要素がいくつも含まれています。
その結果、境界防御だけで「怪しい添付ファイル」を止める、といった従来型の方針では不十分になりつつある点に注意が必要です。
最も典型的なのが、HTMLファイルを添付したフィッシングメールです。メール本文では、次のような名目が用いられます。
ユーザーが添付HTMLを開くと、見かけ上は正規サイト風の画面が表示されつつ、背後でBlobやData URLを用いてZIP/ISOファイルが生成され、「内容を確認するには解凍してください」と促される、といった流れが典型です。
メール本文やチャット、SMS(いわゆるスミッシング)などに記載されたURLから、HTMLスマグリング用のページへ誘導するパターンもあります。リンク先では、
といった仕掛けが行われることがあります。ユーザーから見ると「ログインしようとしたら、なぜかファイルも落ちてきた」という程度の違和感にとどまり、危険性に気づきにくい点が問題です。
攻撃者が正規サイトの管理画面に侵入したり、XSS脆弱性を悪用したりして、HTMLスマグリング用のスクリプトを埋め込むケースも考えられます。また、不正な広告ネットワーク経由で、
といったシナリオもあり得ます。この場合、ユーザーがURLバーを見ても「よく知っているサイト」に見えるため、URLチェックだけでは防ぎきれない点に注意が必要です。
HTMLスマグリングに対抗するには、「メール・Webゲートウェイ」「エンドポイント」「Webアプリケーション」の3つのレイヤで、多層的に制御を行うことが重要です。
これらの対策に加え、外部送信者からのメールには警告ヘッダを付与するなど、利用者側の注意を喚起する工夫も有効です。
最終的なマルウェア実行はエンドポイント上で行われるため、端末側の対策も欠かせません。
ブラウザについても、最新バージョンへの更新や不要な拡張機能の削除など、攻撃面を減らす基本的な対策が重要です。
自社が提供するWebサービスが、HTMLスマグリングの配布拠点にされないよう、アプリケーション側の対策も必要です。
代表的なセキュリティヘッダの例を以下にまとめます。
| ヘッダ | 主な目的 |
|---|---|
| Content-Security-Policy | スクリプトや画像などの読み込み元を制限し、外部の悪意あるコンテンツを防ぐ |
| X-Frame-Options | クリックジャッキング攻撃を防ぐ(別サイトからの iframe 埋め込みの制御) |
| X-Content-Type-Options | MIMEタイプのスニッフィングを防ぎ、意図しないコンテンツ解釈を防止する |
さらに、Webサーバーやフレームワークに対する最新のセキュリティパッチ適用も、HTMLスマグリングを含む様々な攻撃の足がかりを減らすうえで重要です。
HTMLスマグリングは「機能の悪用」であり、単一の装置だけで完全に防ぐのは現実的ではありません。レイヤごとに役割を整理しておくと、対策の抜け漏れを把握しやすくなります。
これらを組み合わせ、境界・内部・端末のそれぞれで「おかしな挙動」を拾える状態を目指すことが重要です。
HTMLスマグリングが疑われる事象に素早く気づくためには、以下のようなログと運用フローが役立ちます。
併せて、インシデント対応手順として、
といった流れをあらかじめ整理しておくことで、被害を最小化しやすくなります。
HTMLスマグリングは、最終的にユーザーがHTMLファイルやダウンロードファイルを開くことがトリガーになります。そのため、技術的対策と同じくらい、ユーザー教育とルール整備が重要です。
こうしたポイントを、社内研修や啓発資料を通じて繰り返し伝え、「おかしいと思ったらすぐ報告する」文化を根付かせることが、HTMLスマグリングを含む多くのフィッシング攻撃対策に有効です。
HTMLスマグリングは、HTMLとJavaScriptの正規機能を悪用し、ネットワーク上では「無害なHTML」に見える形でマルウェアを配布する攻撃手法です。従来のように添付ファイルの拡張子やシグネチャだけで判別することが難しく、バンキングマルウェアやランサムウェア、RATなどの侵入経路として悪用されています。
完全な防御は難しいものの、
といった多角的な対策を組み合わせることで、リスクを大きく低減することが可能です。自社のメール運用やWeb利用の実態を踏まえつつ、影響が大きそうなポイントから優先順位を付けて対策を進めていきましょう。
HTMLスマグリングは、HTMLファイルやウェブページ内のJavaScriptにマルウェアの「材料」を埋め込み、ユーザーのブラウザ上で最終的なペイロードを生成・保存させる攻撃です。ネットワーク上では通常のHTMLに見えるため、境界防御をすり抜けやすい点が特徴です。
マルウェア本体のファイルがネットワーク上にそのまま流れず、エンコード済みデータを含むHTMLとして扱われるためです。危険な実行ファイルはユーザーのブラウザ内で初めて生成されるため、メールゲートウェイやプロキシだけでは検知しにくくなります。
主な経路は、HTMLファイルを添付したフィッシングメールと、メールやチャット、SMSに記載された不審なリンクです。リンク先のページでHTMLスマグリングが仕込まれているケースもあり、通常のブラウジングの中で被害に遭う可能性もあります。
バンキングマルウェア、インフォスティーラ、リモートアクセス型トロイ(RAT)、ランサムウェアのローダーなど、さまざまなマルウェアがHTMLスマグリングを通じて配布されています。多段階攻撃の「最初の入口」として利用されるケースが目立ちます。
はい、なります。HTMLとJavaScriptが動く環境であれば成立するため、企業規模に関係なく狙われる可能性があります。メールによる業務連絡やクラウドサービスを多用する中小企業も、フィッシングを起点とした攻撃のターゲットになりやすい状況です。
業務でHTML添付が不要であれば、原則禁止とする運用が安全です。必要な場合は送信元を限定する、サンドボックスで自動解析する、一時的な申請制にするなど、リスクを抑えたルール設計を行うことが推奨されます。
まずは、メール・WebゲートウェイでのHTML添付やURL制御、エンドポイントでの振る舞い検知、ブラウザとOSの最新化の3点から着手するのが効果的です。そのうえで、アプリケーション制御やSIEMによる相関分析など、自社環境に合わせて段階的に強化していくとよいでしょう。
HTML添付ファイルや心当たりのないZIP/ISOファイルに注意すること、ログイン画面を装ったページで謎のダウンロードが発生したらその場で操作を止めること、少しでも違和感があればすぐに管理部門へ相談することの3点を繰り返し伝えることが重要です。
WAFやIDSだけでHTMLスマグリングを完全に防ぐことはできませんが、正規サイトの改ざんやXSS悪用を防ぐ、難読化されたスクリプトを検知するなど、配布拠点化や一部の挙動を抑止するうえで有効です。EDRやゲートウェイ対策と組み合わせ、多層防御として活用することが重要です。
疑わしい端末をネットワークから切り離し、ダウンロードされたファイルや実行済みプロセスを特定することが最優先です。そのうえで、ログ収集と影響範囲の特定を行い、同様のメールやファイルが他ユーザーに届いていないか確認したうえで、必要に応じてメールの一括削除やパスワードリセットなどの対策を実施します。