KHuntツールキット、Oracle SQLインジェクションをSYSTEM権限でのRCEおよび認証情報窃取へと変貌させる

KHuntは、Oracleを利用したWebアプリケーションに対する「よくある」SQLインジェクションが、データベースエンジン内部で完全な侵入後活動用ツールキットをコンパイルすることで、SYSTEM権限でのリモートコード実行と認証情報窃取へと武器化され得ることを示しています。

今回のインシデントは、Oracleに対する脅威モデルを大きく転換させるものです。データベース自体が単なるデータストアではなく、攻撃者のインフラとなってしまうのです。

Securedata storage

その後の分析により、この攻撃活動はSQLインジェクションの脆弱性に起因することが判明しました。対象は、JDBC経由でOracleを利用する公開Java/Tomcatアプリケーションでした。

脆弱なオートコンプリート検索機能はユーザー入力を無検証のままSQLクエリに渡しており、攻撃者はWebフロントエンド経由で任意のSQL文を発行できる状態でした。

Oracle自体のCVEは不要でした。古典的な入力処理の不備だけで、アプリケーションのバグがデータベースホストの侵害へとつながったのです。

攻撃者はSQLレベルのアクセス権を得た後、データアクセスからコード配備へと戦術を転換しました。Oracleに組み込まれたJVMとCREATE JAVA SOURCE文を悪用したのです。

攻撃者はTomcatのJDBC接続を通じてJavaソースコードを送り込み、Oracleにそれをスキーマ常駐のJavaオブジェクトとしてデータベース内でコンパイルさせました。

「khunt」として追跡されているこの結果生成されたツールキットは、Javaクラスとkhunt_*というPL/SQLラッパー群としてOracle内部にのみ存在し、従来型マルウェアのバイナリのようにファイルシステムに触れることは一切ありませんでした。このデータベース常駐型の設計により、プロセス・ファイル・メモリ内の痕跡に注目するエンドポイント中心のEDRやAVからの可視性が大幅に低下します。

KHuntの各モジュールは、侵入後の制御と認証情報操作を目的として作られていました。KhuntCmdはcmd.exeを読み込み、SQL文に含まれる任意のOSコマンドを実行することで、SQLからWindowsコマンドシェルへの直接的な橋渡し役を果たしました。

KhuntHashはOracle内部のユーザーテーブルを調べ上げ、ユーザー名とパスワードデータをディスクにダンプしました。

KhuntFSおよびKhuntFS2はファイルエクスプローラーとして機能し、ホスト全体にわたる再帰的なファイル一覧表示、読み取り、検索、サイズ取得を可能にしました。

KhuntTはツールキットの到達可能性を確認する「ping」チェックとして動作し、KhuntUnzipはアーカイブの展開を担いました。これらはすべてkhunt_*というPL/SQLラッパーを通じて呼び出されるため、SQL層だけを見ると、悪意ある機能が通常のストアドプロシージャ呼び出しのように見えてしまいます。

ツールキットが導入された後、攻撃者たちはOSレベルでの完全な制御を実証してみせました。KhuntCmdを通じてcmd.exe /c whoamiを実行し、Oracleから起動されたコマンドがWindowsサーバー上でSYSTEM権限で動作していることを確認したのです。これにより、データベース層からオペレーティングシステムに至る、明確なリモートコード実行が成立していることが裏付けられました。

2026年7月27日、Huntressは認証情報窃取活動を、Oracle Databaseをホストする一台のWindowsエンドポイント上で検知しました。同社のテレメトリが、oracle.exeを親プロセスとするreg.exeによるレジストリハイブのコピー操作を検出したことがきっかけでした。

その後、攻撃者はPowerShellやreg.exe、esentutl.exeといったWindows標準ユーティリティを使い、SAM、SECURITY、SYSTEMの各レジストリハイブをF:\Oracle\配下のパスにコピーしました。さらにtasklist /svcを実行して稼働中のサービスを一覧化し、その出力をkhunttasks.txtとして保存しています。

これらのハイブのコピーは、後にオフラインでローカルアカウントのパスワードハッシュを抽出・解析する上で格好の材料であり、明確な認証情報窃取を目的としたものであることがうかがえます。

KHuntが認証情報を露呈させる

Huntressは、調査ではハイブの持ち出しそのものを最終的に確認するには至らなかったものの、これらのハイブは持ち出し(外部流出)の準備段階として置かれた可能性が高いと評価しています。今回の攻撃はまた、多くのOracle環境に潜む危険な権限設計上の問題を浮き彫りにしています。

Oracleのドキュメントによれば、ユーザー自身のスキーマ内でCREATE JAVA SOURCEによりJavaスキーマオブジェクトを作成するには、CREATE PROCEDUREやCREATE JAVAといったシステム権限が必要とされています。また、DBAが意図的に制限しない限り、JavaのRuntime.execはOracleのサービスアカウント権限で実行される仕組みになっています。

今回のケースでは、アプリケーションが使用するデータベースアカウントが過剰な権限を持っていたとみられます。SQLインジェクションが、Javaソースの作成やそれをPL/SQL経由で公開する権限を持つIDにまで到達してしまっていたのです。さらに、背後のOracleサービスの設定により、そこから生成されたプロセスはWindows上でSYSTEM権限で実行される状態になっていました。

防御側にとって、今回のKHuntのインシデントはいくつもの厳しい教訓を残しています。第一に、公開アプリケーションが未検証の入力をクエリに連結し続ける限り、「レガシーな」SQLインジェクションは今なお有効な侵入経路であり続けるということです。堅牢な入力検証とパラメータ化クエリの導入は、もはや選択の余地がありません。

第二に、最小権限の原則は、インターネットに公開されたアプリケーションが使用するデータベースアカウントにも徹底されなければなりません。それらのアカウントは、Javaソースの作成、任意のストアドプロシージャの実行、あるいは管理用スキーマへのアクセスができるべきではないのです。

最後に、Oracle自体をマルウェアの潜在的な足がかりとして扱う必要があります。検知と対応の一環として、データディクショナリ内に見慣れないJavaソース/クラスオブジェクトやkhuntに類似した命名パターンがないか検索し、DDLおよびJavaポリシーの変更を監査する取り組みが求められます。

Malwareremoval service

Huntressは、IOCのパスやモジュールの挙動、緩和策のガイダンスを含む、今回の侵入に関する詳細な技術解説を公開しており、調査および公開レポートへの貢献についてLindsey O’Donnell-Welch氏に謝意を表しています。

Java/Tomcatをフロントエンドに据えてOracleを運用している組織にとって、今回のケースは時宜を得た警鐘と言えます。もしSQLインジェクションがJava機能を備えた特権的なデータベースアカウントにまで到達し得るのであれば、あなたの「データベース層」は、気づかぬうちに攻撃者にとってのRCEの踏み台になってしまう可能性があるのです。

侵害指標(IOC)

なぜ2026 Agentic SOC Buyer’s Guideを使うべきか? 主要8プラットフォームを徹底比較 – 2026 Buyer’s Guideをダウンロード