IT用語集

HTMLスマグリングとは? 10分でわかりやすく解説

水色の背景に六角形が2つあるイラスト 水色の背景に六角形が2つあるイラスト
アイキャッチ
目次

UnsplashBranko Stancevicが撮影した写真      

メールに添付されたHTMLファイルを開いただけで、いつの間にかマルウェアがダウンロードされていた――。その背景で使われている手口のひとつが「HTMLスマグリング」です。HTMLやJavaScriptの正規の機能を悪用し、ネットワーク上では一見「普通のHTML」にしか見えない形でマルウェアを配布するため、従来の境界防御だけでは検知が難しくなっています。本記事では、HTMLスマグリングの仕組みや脅威、代表的な攻撃シナリオ、技術的対策と運用のポイントを整理し、自社で何から着手すべきか判断できる状態を目指します。

HTMLスマグリングとは

HTMLスマグリングの概要と定義

HTMLスマグリングとは、HTMLファイルやウェブページ内のJavaScriptにマルウェアの「材料」を埋め込み、ユーザーのブラウザ上で最終的なペイロード(ZIPや実行ファイルなど)を生成・保存させる攻撃手法を指します。

攻撃者は、Base64などでエンコードしたバイナリデータや、ペイロードを取得するための情報をHTMLに埋め込み、ブラウザ標準の機能だけを使ってファイルを復元します。このとき、ネットワークを流れているのはあくまで「HTML」「テキストデータ」に過ぎないため、多くのメールゲートウェイやプロキシはマルウェアとして検知しづらくなります。

従来のマルウェア配布との違い

従来のマルウェア配布では、以下のような形が一般的でした。

  • 実行ファイル(.exe、.scr など)をそのままメールに添付する
  • Officeマクロ付き文書やスクリプトファイル(.vbs、.js)を送る
  • 不正サイトから直接、実行ファイルをダウンロードさせる

こうした手法は、拡張子・ファイル形式・シグネチャなどで判別しやすいため、ゲートウェイ側でのフィルタリングやアンチウイルス製品による検査が比較的有効でした。

一方、HTMLスマグリングでは、

  • ネットワーク上を流れる段階では「HTML」「テキスト」として扱われる
  • 危険な実行ファイルは、ユーザーのブラウザ内で初めて組み立てられる

という特徴があり、「危険なファイルが境界を通過する」というイベント自体がログに現れにくい点が大きな違いです。

なぜ今、HTMLスマグリングが注目されているのか

HTMLスマグリングが近年注目される背景には、次のような事情があります。

  • Officeマクロ無効化など、従来の初期侵入手法に対する対策が進んだ
  • メール・Webを介した業務が標準化し、「HTMLファイル」「Webリンク」が日常的に使われている
  • HTMLとJavaScriptはほぼ全ての端末で利用できるため、ターゲットを選ばない

攻撃者側から見ると、既存のインフラ(ブラウザ・HTML)をそのまま利用しつつ、検知をすり抜けやすいという、コストパフォーマンスの高い手口と言えます。

HTMLスマグリングの仕組み

典型的な攻撃フロー

代表的なHTMLスマグリング攻撃は、おおよそ次のような流れで進行します。

  1. 攻撃者が悪意あるHTMLファイル(またはHTMLページ)を作成する
  2. HTML内に、Base64などでエンコードしたバイナリデータやペイロード取得用の情報を埋め込む
  3. JavaScriptでエンコード済みデータを復号し、BlobオブジェクトやData URLを生成する
  4. URL.createObjectURL() や <a download> などの機能で、ユーザーにZIP/ISOファイル等をダウンロードさせる
  5. ユーザーがダウンロードされたファイルを展開・実行すると、最終的なマルウェアが動作する

この過程で、境界防御装置が観測するのは「HTMLファイルの受信/Webページの閲覧」にとどまり、マルウェアとして明らかなファイルは端末上で初めて姿を現すことになります。

悪用されるブラウザ機能

HTMLスマグリングでは、以下のような標準機能が多用されます。

  • Blobオブジェクト:ブラウザ内でバイナリデータを扱うための仕組み
  • URL.createObjectURL():Blob から一時的なURLを生成するAPI
  • ダウンロード属性付きリンク:ユーザーにファイルをダウンロードさせる仕組み
  • Data URL(data:スキーム):HTML内にデータを直接埋め込むための仕組み

いずれも本来は正当な用途のために用意された機能ですが、攻撃者がこれらを組み合わせることで、ネットワーク上では「無害そうなHTML」に見える状態から、ローカル環境でマルウェアを復元できてしまいます。

他のWeb攻撃との関係と組み合わせ

HTMLスマグリング自体は、XSSやCSRFのような「アプリケーション脆弱性」を直接突く攻撃ではありません。しかし、以下のように他の攻撃手法と組み合わされるケースがあります。

  • 正規サイトのXSS脆弱性を悪用し、ページ内にHTMLスマグリング用スクリプトを埋め込む
  • CSRFを通じて、ユーザーにHTMLスマグリングページへのアクセスや操作を強制する
  • 不正な広告ネットワークやDNSリバインディングを用いて、攻撃者の用意したHTMLページへ誘導する

そのため、HTMLスマグリング対策は、クライアント側(メール、ブラウザ、EDR)だけでなく、Webアプリケーション側の基本的なセキュリティ対策ともセットで考える必要があります。

HTMLスマグリングがもたらす脅威

情報漏えいと認証情報の窃取

HTMLスマグリングを起点にRATやインフォスティーラが導入されると、端末内のさまざまな情報が盗まれるリスクがあります。

  • ブラウザに保存されたID・パスワード
  • VPNクライアントやリモートデスクトップの認証情報
  • ファイルサーバーやクラウドストレージ内の業務データ

盗まれた情報は、クラウドサービスや社内システムへのなりすまし、不正送金、顧客情報の持ち出しなどに悪用され、企業の信用失墜や法令違反につながる可能性があります。

ランサムウェア攻撃の入口としての利用

近年の事例では、HTMLスマグリングを初期侵入のきっかけとし、その後に以下のようなマルウェアを段階的に投入する攻撃が報告されています。

  • 環境情報を収集する調査用マルウェア
  • 横展開や権限昇格を行うツール類
  • 最終段階で実行されるランサムウェア本体

ユーザーが一度HTMLファイルを開き、生成されたファイルを実行してしまうと、以降は攻撃者のペースで内部侵害が進んでしまうケースも少なくありません。

検知回避と監視の難しさ

HTMLスマグリングには、監視・検知を難しくする要素がいくつも含まれています。

  • ネットワーク上に「.exe」や「.js」などの明示的なマルウェアファイルが流れない
  • エンコードや難読化により、静的解析だけでは意図を読み取りにくい
  • ユーザー操作(クリック・ファイル展開)を前提としているため、自動解析環境では再現されにくい

その結果、境界防御だけで「怪しい添付ファイル」を止める、といった従来型の方針では不十分になりつつある点に注意が必要です。

代表的な攻撃シナリオ

HTML添付ファイルを用いたフィッシングメール

最も典型的なのが、HTMLファイルを添付したフィッシングメールです。メール本文では、次のような名目が用いられます。

  • 「請求書の確認」「支払い通知」などの経理関連
  • 「パスワード有効期限の通知」「セキュリティ確認」などのアカウント関連
  • 「宅配便の不在通知」「会員登録の更新」など生活インフラを装うもの

ユーザーが添付HTMLを開くと、見かけ上は正規サイト風の画面が表示されつつ、背後でBlobやData URLを用いてZIP/ISOファイルが生成され、「内容を確認するには解凍してください」と促される、といった流れが典型です。

リンク型フィッシングとドライブ・バイ・ダウンロード

メール本文やチャット、SMS(いわゆるスミッシング)などに記載されたURLから、HTMLスマグリング用のページへ誘導するパターンもあります。リンク先では、

  • Office 365やクラウドストレージのログイン画面を模したページを表示しつつ
  • 同時にバックグラウンドでマルウェアファイルを生成・ダウンロードさせる

といった仕掛けが行われることがあります。ユーザーから見ると「ログインしようとしたら、なぜかファイルも落ちてきた」という程度の違和感にとどまり、危険性に気づきにくい点が問題です。

正規サイトの改ざんや広告ネットワークの悪用

攻撃者が正規サイトの管理画面に侵入したり、XSS脆弱性を悪用したりして、HTMLスマグリング用のスクリプトを埋め込むケースも考えられます。また、不正な広告ネットワーク経由で、

  • 普段利用しているニュースサイトやブログを閲覧しているだけで
  • 別タブやポップアップでHTMLスマグリングページが開かれる

といったシナリオもあり得ます。この場合、ユーザーがURLバーを見ても「よく知っているサイト」に見えるため、URLチェックだけでは防ぎきれない点に注意が必要です。

HTMLスマグリングへの技術的対策

HTMLスマグリングに対抗するには、「メール・Webゲートウェイ」「エンドポイント」「Webアプリケーション」の3つのレイヤで、多層的に制御を行うことが重要です。

メール/Webゲートウェイでの対策

  • HTML添付ファイルのポリシー化:業務上不要であれば原則禁止とし、必要な場合は送信元を限定するなどのルールを設ける
  • サンドボックス解析の活用:HTML添付や外部リンク先を仮想環境で実行し、不審なダウンロードやスクリプト挙動を判定する
  • URLフィルタリング/レピュテーション:既知の悪性ドメインや低評価サイトへのアクセスをブロックする

これらの対策に加え、外部送信者からのメールには警告ヘッダを付与するなど、利用者側の注意を喚起する工夫も有効です。

エンドポイント/ブラウザ側の対策

最終的なマルウェア実行はエンドポイント上で行われるため、端末側の対策も欠かせません。

  • EDRや次世代型アンチウイルスによる振る舞い検知(不審なプロセス生成、スクリプト実行、権限昇格の試みなど)
  • ダウンロードフォルダ配下での実行ファイル・スクリプトに対する厳格なスキャン
  • 業務で不要なスクリプトエンジンやツール(WScript、PowerShell の一部機能など)の利用制限
  • 日常利用アカウントは管理者権限を付与しない、アプリケーション制御で許可されていないプログラムの実行を防止する

ブラウザについても、最新バージョンへの更新や不要な拡張機能の削除など、攻撃面を減らす基本的な対策が重要です。

Webアプリケーション実装時の対策

自社が提供するWebサービスが、HTMLスマグリングの配布拠点にされないよう、アプリケーション側の対策も必要です。

  • 入力値のバリデーション/サニタイジング:ユーザー入力をそのままHTMLやJavaScriptとして解釈させない
  • ファイルアップロード機能の制御:アップロード可能な拡張子を限定し、HTML等をそのまま配布しない設計にする
  • セキュリティヘッダの設定:コンテンツの読み込み元やフレーミングを制限し、悪用されにくい環境を整える

代表的なセキュリティヘッダの例を以下にまとめます。

ヘッダ主な目的
Content-Security-Policyスクリプトや画像などの読み込み元を制限し、外部の悪意あるコンテンツを防ぐ
X-Frame-Optionsクリックジャッキング攻撃を防ぐ(別サイトからの iframe 埋め込みの制御)
X-Content-Type-OptionsMIMEタイプのスニッフィングを防ぎ、意図しないコンテンツ解釈を防止する

さらに、Webサーバーやフレームワークに対する最新のセキュリティパッチ適用も、HTMLスマグリングを含む様々な攻撃の足がかりを減らすうえで重要です。

検知と運用・監視のポイント

WAF/IDS/EDR の役割分担

HTMLスマグリングは「機能の悪用」であり、単一の装置だけで完全に防ぐのは現実的ではありません。レイヤごとに役割を整理しておくと、対策の抜け漏れを把握しやすくなります。

  • WAF(Web Application Firewall):XSS 等の脆弱性悪用を防ぎ、正規サイトが配布拠点になるリスクを抑える
  • IDS/IPS:難読化されたスクリプトや不審なパターンの通信を検知・遮断する
  • EDR:端末上での不審なプロセス生成やスクリプト実行を検知し、事後調査も含めて対応する

これらを組み合わせ、境界・内部・端末のそれぞれで「おかしな挙動」を拾える状態を目指すことが重要です。

ログ活用とインシデント対応手順

HTMLスマグリングが疑われる事象に素早く気づくためには、以下のようなログと運用フローが役立ちます。

  • メール/プロキシログ:外部からのHTML添付・不審なドメインへのアクセスを把握する
  • EDR/OSイベントログ:ダウンロードフォルダ配下での実行ファイル生成やスクリプト実行を監視する
  • SIEM:「外部からのHTML添付 → その端末での不審なプロセス起動」などの相関ルールを設定する

併せて、インシデント対応手順として、

  1. 疑わしい端末のネットワーク隔離
  2. ダウンロードされたファイルや実行済みプロセスの特定・保全
  3. 横展開の有無(他端末へのメール配布、認証情報悪用)の調査
  4. 必要に応じたパスワードリセットや端末初期化

といった流れをあらかじめ整理しておくことで、被害を最小化しやすくなります。

ユーザー教育とポリシー整備

HTMLスマグリングは、最終的にユーザーがHTMLファイルやダウンロードファイルを開くことがトリガーになります。そのため、技術的対策と同じくらい、ユーザー教育とルール整備が重要です。

  • 「HTML添付ファイル」「心当たりのないZIP/ISOファイル」は特に注意すること
  • ログイン画面を装ったページで謎のファイルがダウンロードされたら、その場で操作を止めること
  • 少しでも違和感があれば、自分で判断せず速やかに管理部門へ相談すること

こうしたポイントを、社内研修や啓発資料を通じて繰り返し伝え、「おかしいと思ったらすぐ報告する」文化を根付かせることが、HTMLスマグリングを含む多くのフィッシング攻撃対策に有効です。

まとめ

HTMLスマグリングは、HTMLとJavaScriptの正規機能を悪用し、ネットワーク上では「無害なHTML」に見える形でマルウェアを配布する攻撃手法です。従来のように添付ファイルの拡張子やシグネチャだけで判別することが難しく、バンキングマルウェアやランサムウェア、RATなどの侵入経路として悪用されています。

完全な防御は難しいものの、

  • メール/WebゲートウェイでのHTML添付やURLの制御
  • エンドポイントでの振る舞い検知とアプリケーション制御
  • Webアプリケーション側の脆弱性対策とセキュリティヘッダ設定
  • ログ活用とインシデント対応フローの整備
  • ユーザー教育による早期気づきと報告

といった多角的な対策を組み合わせることで、リスクを大きく低減することが可能です。自社のメール運用やWeb利用の実態を踏まえつつ、影響が大きそうなポイントから優先順位を付けて対策を進めていきましょう。

Q.HTMLスマグリングとはどのような攻撃ですか?

HTMLスマグリングは、HTMLファイルやウェブページ内のJavaScriptにマルウェアの「材料」を埋め込み、ユーザーのブラウザ上で最終的なペイロードを生成・保存させる攻撃です。ネットワーク上では通常のHTMLに見えるため、境界防御をすり抜けやすい点が特徴です。

Q.なぜHTMLスマグリングは検知が難しいのですか?

マルウェア本体のファイルがネットワーク上にそのまま流れず、エンコード済みデータを含むHTMLとして扱われるためです。危険な実行ファイルはユーザーのブラウザ内で初めて生成されるため、メールゲートウェイやプロキシだけでは検知しにくくなります。

Q.HTMLスマグリングはどのような経路で組織に侵入しますか?

主な経路は、HTMLファイルを添付したフィッシングメールと、メールやチャット、SMSに記載された不審なリンクです。リンク先のページでHTMLスマグリングが仕込まれているケースもあり、通常のブラウジングの中で被害に遭う可能性もあります。

Q.HTMLスマグリングで配布されるマルウェアには何がありますか?

バンキングマルウェア、インフォスティーラ、リモートアクセス型トロイ(RAT)、ランサムウェアのローダーなど、さまざまなマルウェアがHTMLスマグリングを通じて配布されています。多段階攻撃の「最初の入口」として利用されるケースが目立ちます。

Q.中小企業でもHTMLスマグリングの標的になりますか?

はい、なります。HTMLとJavaScriptが動く環境であれば成立するため、企業規模に関係なく狙われる可能性があります。メールによる業務連絡やクラウドサービスを多用する中小企業も、フィッシングを起点とした攻撃のターゲットになりやすい状況です。

Q.HTML添付ファイルはすべて禁止すべきでしょうか?

業務でHTML添付が不要であれば、原則禁止とする運用が安全です。必要な場合は送信元を限定する、サンドボックスで自動解析する、一時的な申請制にするなど、リスクを抑えたルール設計を行うことが推奨されます。

Q.技術的な対策はどこから始めるとよいですか?

まずは、メール・WebゲートウェイでのHTML添付やURL制御、エンドポイントでの振る舞い検知、ブラウザとOSの最新化の3点から着手するのが効果的です。そのうえで、アプリケーション制御やSIEMによる相関分析など、自社環境に合わせて段階的に強化していくとよいでしょう。

Q.ユーザー教育では何を重点的に伝えるべきですか?

HTML添付ファイルや心当たりのないZIP/ISOファイルに注意すること、ログイン画面を装ったページで謎のダウンロードが発生したらその場で操作を止めること、少しでも違和感があればすぐに管理部門へ相談することの3点を繰り返し伝えることが重要です。

Q.WAFやIDSはHTMLスマグリング対策に有効ですか?

WAFやIDSだけでHTMLスマグリングを完全に防ぐことはできませんが、正規サイトの改ざんやXSS悪用を防ぐ、難読化されたスクリプトを検知するなど、配布拠点化や一部の挙動を抑止するうえで有効です。EDRやゲートウェイ対策と組み合わせ、多層防御として活用することが重要です。

Q.HTMLスマグリングが疑われる場合、最初にすべきことは何ですか?

疑わしい端末をネットワークから切り離し、ダウンロードされたファイルや実行済みプロセスを特定することが最優先です。そのうえで、ログ収集と影響範囲の特定を行い、同様のメールやファイルが他ユーザーに届いていないか確認したうえで、必要に応じてメールの一括削除やパスワードリセットなどの対策を実施します。

記事を書いた人

ソリトンシステムズ・マーケティングチーム