多くの組織が「何十年も前から知られている、仕組みも解明済みの脅威」とみなしがちなSQLインジェクション脆弱性が、はるかに高度な攻撃の侵入口として悪用されていたことが明らかになりました。脅威アクターが、Oracleデータベース内部に常駐する形でカスタム構築されたツールキットを仕込んでいたことが確認されています。
セキュリティ企業のHuntressによると、同社は2026年7月27日、Oracleデータベースサーバーをホストするエンドポイントで不審な活動があるとの警告を受けました。攻撃者がSAM、SECURITY、SYSTEMというWindowsレジストリハイブをコピーしようと試みているのを検知したことがきっかけです。これらは、保存されている認証情報を抽出・解読しようとする攻撃者が典型的に狙うファイルです。
さらに調査を進めた結果、侵入の起点はOracleデータベースに接続された公開Webアプリケーションに存在するSQLインジェクション脆弱性であることが判明しました。同アプリケーション内のあるフォームフィールドがユーザー入力を適切に検証していなかったため、攻撃者は悪意あるSQL文を送信でき、アプリケーション側はそれを疑うことなく実行してしまっていました。
このインシデントを典型的なSQLインジェクション事案から際立たせているのは、その後に起きたことです。攻撃者は単にデータを照会・改ざんするのではなく、この権限を使ってCREATE JAVA SOURCEコマンドを発行しました。これは、開発者がJavaコードをオブジェクトとしてデータベース内部に保存・コンパイルできる、Oracleデータベースの正規機能です。攻撃者はこの機能を悪用し、「khunt」と名付けられた侵入後活動用の本格的なツールキット一式を、データベースエンジン内に直接アップロード・コンパイルしていました。
Huntressは、この基盤となる手法(「oraexec」と呼ばれることもある)自体はセキュリティ研究者の間で何年も前から議論されてきたものの、実際の攻撃で使用された事例が文書化されることはこれまでほとんどなかったと指摘しています。
データベース層向けに構築されたツールキット
Huntressによると、khuntツールキットはスキーマオブジェクトとしてコンパイル・保存された複数の専用モジュールで構成されていました。その中には、データベース内部から任意のOSコマンドを実行できるツールや、Oracleの内部ユーザーテーブルから直接ユーザー名とパスワードデータを抜き出すツールが含まれます。さらに、ファイルシステムの閲覧、ツールキットへの到達性確認、ファイルの展開を可能にする追加コンポーネントもあり、複数のPL/SQLラッパーが背後のJavaメソッドを呼び出すために使われていました。
攻撃者はこのコマンド実行モジュールを使ってデータベースから背後のWindowsサーバーへと侵入範囲を広げ、whoamiを実行してSYSTEMレベルの権限を持っていることを確認しました。これにより、データベース層を起点とした完全なリモートコード実行を実質的に達成していたことになります。そこから攻撃者はPowerShellや、レジストリツール、Extensible Storage Engineユーティリティといったネイティブなwindowsユーティリティを使い、SAM、SECURITY、SYSTEMの各レジストリハイブをコピーし、稼働中のサービスを列挙して、その結果を侵害されたホスト上のディレクトリに保存していました。
従来型の防御策の死角
Huntressは、悪意あるコードを従来型のファイルやメモリ上のプロセスとしてではなく、データベースオブジェクトとして保存するこの手口が、多くの組織の既存セキュリティツールにとって大きな死角となっていると警告しています。従来型のエンドポイント検知・対応(EDR)製品やアンチウイルス製品は、一般的にOSレベルのプロセス、バイナリ、ファイルを監視するよう設計されており、データベースエンジン内で動作するJavaクラスやPL/SQLオブジェクトを検査することは通常想定されていません。
同社は、今回のインシデントが、データベースを単にデータを保存・返送するだけのシステムから、さらなる攻撃の足がかりへと転用できてしまう実例を示していると述べています。また、これを実現するために目新しい脆弱性や未パッチの脆弱性は一切必要なかった点も強調しています。最初の侵入口は、Webフォームにおけるユーザー入力検証の基本的な不備にすぎませんでした。
同様の攻撃を防ぐため、Huntressは、公開フォームに対して入力サニタイズとクエリのパラメータ化によるインジェクション対策をきちんと施すこと、そしてデータベースアカウントに過剰な権限を付与しないことを組織に推奨しています。同社によれば、たとえSQLインジェクションに成功したとしても、侵害されたアカウントにJavaソースの作成やストアドプロシージャの実行に必要な権限が与えられていなければ、被害を防げるとしています。
今回の調査結果は、SQLインジェクションのような使い古された攻撃手法であっても、あまり知られていないプラットフォーム機能と組み合わされることで深刻な結果を招きかねないこと、そしてデータベースサーバーもエンドポイントやネットワークインフラと同レベルの精査に値することを改めて示しています。
