お問い合わせ
AIセキュリティ

User-Agentは身分証ではない - 金融機関へのAIハッキングとブラウザによるアクセス制限

·

事案の概要 - 突破されたのは勘定系ではなく周辺システム

2026年9月末から10月初めにかけて、韓国国内の金融業界で顧客・役職員情報の漏えい事案が相次いで確認されました。10月4日時点の報道によると、銀行4行、貯蓄銀行2行、ノンバンク（キャピタル会社）1社の計7社の金融機関で、個人約6万6千人分と法人最大約2,200件の情報が漏えいしました。

攻撃者が狙ったのは勘定系システムではありませんでした。攻撃は職員・ローン募集人向けの周辺システムに集中しました。ローン募集人（金融機関から委託を受けて融資の勧誘を行う外部の人員）向けの照会サービス、役職員向けの業務支援システム、営業支援システムのように、業務の利便性のために外部へ公開していた周辺システムです。韓国の金融委員会（FSC）も、ローン募集人・委託業者などの外部人員と役職員が使うシステムを今回の不正アクセス事案の原因に挙げました。

当局の要請も同じ方向を示しています。金融委員会は10月2日の緊急状況対応会議で、外部に露出したIT資産とアクセス制御状況の点検、認証なしで内部情報にアクセスできる経路の遮断、攻撃IPと手口の共有を要請しました。続く10月4日の全金融業界緊急点検会議では、必須の場合を除く外部アクセスを原則として一律に遮断し、外部アクセスが避けられない場合もアクセス権限と照会可能な情報を最小限に制限するよう求めました。韓国インターネット振興院（KISA）も10月3日の企業向けセキュリティ強化勧告で、外部露出資産の確認、ウェブ・APIの認可チェック、アカウントと認証情報の保護を優先課題に挙げました。

公開された報道を総合すると、攻撃は次の流れで進みました。

段階攻撃手口露呈した弱点
偵察インターネットに露出したローン募集人・役職員向けのウェブページとサーバーを自動で探索外部に露出した周辺システムの管理不備
認証回避顧客番号などの値を総当たりで入力し、認証手続きの回避を試行試行回数制限と強固な認証の未適用
情報収集顧客番号などの入力値を変えながら照会APIを繰り返し呼び出しサーバー側の認可制御の不備（IDOR）
遮断回避複数の国のIPを使い、遮断されると別の経路で照会を継続IP遮断リスト中心の対応の限界
自動化LLMベースのオープンソース侵入ツールARTEXを使用した形跡人の対応速度を上回る自動化攻撃

同じ時期に被害を免れた銀行の事例も報じられました。ある銀行はIDとパスワードだけでは業務システムにアクセスできないよう、追加の証明書と生体認証を求めていました。別の銀行は、ローン募集人に内部ネットワークへの接続経路そのものを与えていませんでした。アクセスする資格をアカウント一つではなく、別の証明で判定していた点が共通していました。

AI侵入ツールが残した痕跡、固定User-Agent

ARTEXは、中国語圏を中心にGitHubで公開されたオープンソースのAI自律型ペネトレーションテストツールです。大規模言語モデル（LLM）が標的を分析し、攻撃経路を計画したうえでセキュリティツールを実行します。報道によると、韓国の金融保安院（FSI）は、最初に届け出た銀行のログと攻撃元IPを追跡する過程でARTEXの使用痕跡を確認し、攻撃IPが変わってもツールが送るデータに共通の特徴が残っていたため攻撃者を特定できたと説明しました。

ARTEXの公開ソースコードには、攻撃対象のウェブシステムに送られうるUser-Agent文字列が固定値として定義されています。PLURAブログの分析は、これらの値をWAFで優先的に検索すべき侵害指標（IOC）の候補として整理しました。

User-Agent固定値ソースコード上の用途
artex-enrich/1.0ウェブ資産の情報を確認するリクエスト
Mozilla/5.0 (spa-api-recon)HTML・JavaScriptファイルを収集してAPIパスを探すスクリプト
Mozilla/5.0 (spa-api-recon spider)ウェブページを巡回してリンクと入力フォームを収集するスクリプト

解釈には注意が必要です。この三つの値は公開ソースコードで確認した候補であり、今回の事案の実際の攻撃ログで観測された値として検証されたものではありません。ARTEXには、実際のChromiumブラウザを起動してブラウザのリクエストヘッダーをそのまま使う収集経路もあります。三つの文字列を遮断しても、ツール全体を遮断したことにはなりません。

固定値の両面 - 検知の手がかりであり、回避の手段でもある

防御側にとっては一時的な検知の手がかり

攻撃ツールが固定User-Agentを使っていれば、WAFやアクセスログでその文字列を検索して過去のアクセス履歴を洗い出し、現在届いているリクエストを遮断できます。初動対応としては意味があります。

しかし、この値はコードを1行書き換えれば変わります。検知ルールが公開された瞬間、攻撃者もそれを知ります。IP遮断リストが、複数の国のIPアドレスを次々に切り替える手口に対応しきれなかったのと同じ構造です。攻撃者が決める値を基準にした遮断は、後手に回りやすくなります。

攻撃者にとってはコピー1回で済む文字列

逆方向の問題もあります。HTTP標準であるRFC 9110では、User-Agentはリクエストを送るソフトウェアが自らを名乗るヘッダーです。その名乗りが事実かどうかをサーバーが確認する手段は、標準には定められていません。ブラウザの開発者ツール、コマンドラインツール、スクリプトのどこからでも、任意の値を書いて送ることができます。

したがって、アクセスの可否をUser-Agentで判定しても、アクセス制御として機能しません。「専用アプリからのみアクセスを許可」や「セキュアブラウザからのみアクセスを許可」をUser-Agentに含まれる固定文字列で判別しているなら、攻撃者は正規端末のUser-Agentを一度確認してそのままコピーするだけで、その判別を通過します。自動化ツールは、こうしたヘッダーの組み合わせを休みなく変えながら試行します。

識別手段値を決める側変更に必要な労力今回の事案では適した用途
User-Agentクライアントが自ら記載コード1行ツールの固定値が候補指標として公開されたが、差し替え可能検知の補助指標
IPアドレス接続経路プロキシ・海外サーバーで差し替え遮断後に別の国のIPで再攻撃検知と事後の遮断
ID・パスワードユーザー漏えいした値・推測した値の入力総当たり入力による認証回避の試行他の要素と組み合わせる
クライアント証明書機関が発行し、秘密鍵は端末に保管秘密鍵がなければ接続不可被害を免れた銀行はアカウントに加えて証明書を要求アクセス判定の基準

必要な防御 - 文字列ではなく証明で

国民日報の報道のとおり、接続する機器と利用者の身元を実際に確認しなければ、外部の者のアクセスを防ぐことは困難です。原則は四つです。

  1. アクセスの判定は偽造できない身元で行います。 機関が発行したクライアント証明書と、端末の外に取り出せないよう保管した秘密鍵がその基準です。秘密鍵を持つ端末だけが接続を確立できるため、User-AgentやIPをどう変えても判定は変わりません。
  2. 判定はHTTPリクエストより前に行います。 相互TLS認証（mTLS）は、TLS標準（RFC 8446）のクライアント認証手順を利用し、暗号化接続を確立する段階でクライアント証明書を検証します。検証に失敗したクライアントのリクエストは、ウェブアプリケーションに到達しません。サーバーにまだ見つかっていない認可制御の不備が残っていても、外部の自動化ツールがその不備にたどり着く経路は断たれます。
  3. User-AgentとIPは検知指標として使います。 捨てる必要はありません。共有された侵害指標で過去の履歴を調査し、証明書の検証を通過した後にも残る異常の兆候を見つけるための補助シグナルとして活用します。
  4. サーバー側の認可チェックは別途修正します。 リクエストしたユーザーにその顧客番号を閲覧する権限があるかを、サーバーが毎回確認する必要があります。OWASP API Security Top 10は、この不備を一つ目のリスクであるオブジェクトレベル認可の不備（API1）に挙げています。大量・順次照会に対するレート制限も併せて設けます。

BrowZenで対応できる範囲

BrowZenは、職員のPCにインストールして使うChromiumベースのセキュアブラウザです。金融当局が求めた「外部アクセスは原則として遮断し、避けられない場合は最小限に」を、業務システムの入口で実現する方法の一つです。今回の事案に関係する機能は二つあります。業務システムへの入口をBrowZenに限定するアクセス元の限定と、入った後の作業をユーザーごとに統制するポリシー適用です。

1. クライアント証明書によるアクセス元の限定

BrowZenは、クライアント証明書（mTLS）を利用して、登録端末上のBrowZenにのみ業務システムへのアクセスを許可します。証明書の検証は暗号化接続を確立する段階で行われるため、判定にUser-Agent文字列は使われません。攻撃段階別に見ると次のとおりです。

攻撃段階アクセス元の限定を適用した場合
外部露出システムの偵察証明書を持たないスキャナーやスクリプトは接続段階で切断され、ページとAPIの構造を収集できません
User-Agentの偽装正規端末のUser-Agentをそのままコピーしても、証明書と秘密鍵がなければ接続できません
複数国のIPアドレスの切り替え判定基準がIPではないため、どの国のIPに変えても結果は同じです
アカウント・認証回避の試行アカウントが正しくても、登録端末のBrowZenでなければログイン画面に到達できません
入力値の差し替えによる照会（IDOR）外部ツールは照会APIに到達できません。ただし、不備そのものはサーバー側で修正する必要があります

2. アクセス後のポリシー適用

正規の端末から入ったユーザーであっても、統制は必要です。アカウントが乗っ取られた場合や、内部者が情報を集める場合です。

  • ユーザー・グループポリシー: ログインした人とその所属に応じたポリシーが自動で適用されます
  • アップロード・ダウンロードポリシー: サイトや部署ごとに、ファイルのアップロード・ダウンロードを許可または遮断します
  • キャプチャ・画面共有の遮断とユーザー透かし: 業務画面のキャプチャを防ぎ、画面にユーザーID・接続IP・時刻を透かしとして表示し、漏えい経路を追跡できるようにします

適用範囲と限界

  • 対象: 職員と協力会社がPCで使うウェブ業務システムです。ローン募集人や外部委託人員のように外部からアクセスする必要があるユーザーにも、登録端末を基準に同じ原則を適用できます
  • 対象外: 顧客向けの公開サービスとモバイルアプリです。顧客に特定のブラウザを求めることはできず、BrowZen v1.0はWindowsに対応しており、モバイルはロードマップに含まれています。今回の事案の標的にはモバイル業務システムも含まれていたため、モバイルには別途の統制が必要です
  • サーバーの不備はサーバーで: アクセス元の限定は攻撃対象領域を縮小しますが、認可制御の不備を修正するものではありません。正規ユーザーが同じ不備を悪用する経路は、サーバー側の検証で防ぐ必要があります

今すぐ点検すべきこと

  1. 外部に露出している職員・協力会社・ローン募集人向けシステムの一覧を漏れなく作成します
  2. アクセス判定のコードとWAFの設定から、User-AgentやIPの文字列比較で「専用アプリ」や「専用ブラウザ」を判定している箇所を探します
  3. 照会APIに、オブジェクトレベルの認可チェックと大量・順次照会の制限があるかを確認します
  4. 共有された攻撃IPと候補User-Agentで、9月下旬以降のアクセスログを調査します
  5. 外部からのアクセスが欠かせない業務システムは、証明書ベースの端末・ブラウザ確認に切り替えます

おわりに

今回の事案で、攻撃者はIPを変え、アカウントを変え、必要であればUser-Agentも変えることができました。変えられないのは、登録された端末にだけ存在する秘密鍵です。アクセス制御の基準を、攻撃者が変えられる値から、変えられない証明へと移すこと。それが、AIによって攻撃のスピードが引き上げられた時代に、防御が追いつくための方法です。

BrowZenの機能と構築環境はBrowZen製品ページで、セキュアブラウザの基本概念とVDI・RBIとの違いはセキュアブラウザ(SEB)とは何かでご確認いただけます。

参考資料

公的機関の発表と標準文書

報道

セキュリティ業界の分析

よくある質問

WAFにARTEXのUser-Agentを遮断するルールを入れれば十分ですか。

初動対応としては意味がありますが、十分ではありません。公表された三つの値は公開ソースコードに基づく候補であり、コード1行で変更でき、実際のChromiumブラウザを起動して正規のブラウザヘッダーを使う収集経路もあります。User-AgentとIPは過去のアクセス履歴の調査と異常検知に使い、アクセスを許可するかどうかは偽造できない証明書ベースの身元で判定するほうが安全です。

クライアント証明書を発行するだけで、セキュアブラウザがなくても済むのではありませんか。

証明書は登録された端末であることを証明しますが、その端末でどのプログラムがリクエストを送っているかまで保証するのは困難です。また、アクセス後の貼り付け、アップロード、画面キャプチャといった操作は証明書では統制できません。BrowZenは登録端末上のBrowZenにのみアクセスを許可し、アクセス後の操作までユーザーごとのポリシーで統制します。

金融機関のどのシステムにもBrowZenによるアクセス元の限定を適用できますか。

いいえ。顧客向けの公開サービスとモバイルアプリは対象外です。顧客に特定のブラウザを求めることはできず、BrowZen v1.0はWindowsに対応しており、モバイルはロードマップに含まれています。職員と協力会社がPCで使うウェブ業務システムが適用対象であり、顧客向けサービスはサーバー側の認可チェックと照会制限で保護する必要があります。

あわせて読みたい