Oracle内にJavaコードを埋め込みWindows最高権限を奪取、データベースを足場にするサイバー攻撃の詳細が判明

要点

• 外部向けのWebアプリケーションに存在する「SQLインジェクション」の脆弱性を悪用し、組織のOracleデータベースに侵入するサイバー攻撃が確認された。

• 攻撃者は実行ファイルを直接ディスクに保存せず、データベース内部でJavaソースコードをコンパイルして実行する「khunt」と呼ばれるツールキットを構築していた。

• 侵入後、攻撃者はデータベースエンジンからWindowsサーバーの最高特権である「SYSTEM」権限でのコマンド実行に成功していた。

• この手法はデータベース内にプログラムとして潜むため、一般的なエンドポイント検出・応答（EDR）製品では検知が困難とされる。

• 抜本的な対策として、アプリケーションでの入力値検証の徹底と、データベースアカウントへの権限付与を最小限に抑える運用の見直しが推奨されている。

• セキュリティ企業のHuntressは2026年8月6日、Oracleデータベースに標準で組み込まれているJavaの実行環境を悪用し、Windowsサーバーの最高管理者権限（SYSTEM権限）を奪取する新たな攻撃手法と、そこで使用されたツールキット「khunt（クハント）」に関する詳細な調査結果を公表した。この攻撃は、Webアプリケーションの脆弱性を突いてデータベースに潜入し、ディスクにファイルを書き込むことなく内部でプログラムを完結させる「ファイルレス」の手法がとられていたという。

• Huntressがこの攻撃を検知したのは2026年7月27日のことだった。サーバー内での不審な資格情報窃盗の動きを検知したことをきっかけに調査を開始したところ、外部公開されているWebアプリケーションの検索自動補完（オートコンプリート）フィールドに存在する「SQLインジェクション」の脆弱性が悪用されていたことが判明した。SQLインジェクションとは、データベースへの入力値を悪用して意図しないデータベース命令を実行させる攻撃手法である。この脆弱性により、検証されていない入力値がJavaとデータベースを接続する仕組みである「JDBC」を介してOracleデータベースに送信され、攻撃の足がかりを与えていた。

• この攻撃で特徴的なのは、攻撃者がオペレーティングシステム（OS）のディスク上に実行ファイルを一切作成していない点である。Oracleデータベースには、Javaプログラムを実行するための環境である「Java Virtual Machine（JVM）」が標準で搭載されている。攻撃者はこれに目をつけ、「CREATE JAVA SOURCE」と呼ばれるSQL文を実行してJavaのソースコードを直接データベースに送り込み、データベース内で自動的にコンパイルさせて「スキーマオブジェクト（データベース内のプログラム部品）」として保存していた。

• 通常、自分の領域内であれば、一般的な「CREATE PROCEDURE」という権限が1つあるだけでJavaコードの作成が可能である。ただし、そこからOSのプログラムを起動するには個別のファイル実行権限が必要であり、通常は管理者が意図して付与しなければならない。Huntressは、今回悪用されたアカウントが元からそれらの権限を持っていたのか、あるいは攻撃者が何らかの方法で権限を追加したのかについては言及していないが、攻撃チェーン全体が成功していることから、実行に必要な権限がすべて揃っていたことは確実とみられている。

• このようにしてデータベース内部に配置されたJavaクラスは、OS側からはプロセスや独立したバイナリファイルとして認識されない。そのため、端末内の挙動を監視する一般的なセキュリティ製品（EDR）ではOracleの内部データを走査できないことが多く、検知をすり抜けてしまう。Huntressは「データベースはもはや単なるクエリ（問い合わせ）を受ける対象ではなく、攻撃者が活動を開始するための足場（ビーチヘッド）となっている」と指摘している。

• 実は、このようなデータベースのJava環境を悪用してOSコマンドを実行する手法は、少なくとも20年前から知られている。2006年には、セキュリティ研究者のMarco Ivaldi氏が「raptor_oraexec.sql」というスクリプトを公開し、PL/SQL（Oracle独自の拡張言語）を用いて同様のコマンド実行を行う仕組みを実証していた。しかし、Huntressによれば、実際のサイバー攻撃においてこの技術が使われ、詳細に記録された事例はこれまでほとんどなかったという。

• 今回の攻撃で使われたツールキット「khunt」は、6つのJavaオブジェクトと、これらをSQLから動かすための複数のPL/SQLラッパーで構成されていた。それぞれの主な機能は以下の通りである。

• KhuntCmd: Windowsのコマンド実行環境（cmd.exe）を起動し、SQL経由で送られた任意のOSコマンドを実行する。

• KhuntHash: Oracleの内部ユーザーテーブルからユーザー名と暗号化されたパスワード（パスワードハッシュ）を読み取り、ファイルへ書き出す。

• KhuntFS および KhuntFS2: サーバー上のファイルを一覧表示、読み取り、検索し、ファイルサイズを確認する。

• KhuntT: ツールキットが正しく機能し、外部からアクセスできるかを検証する。

• KhuntUnzip: 圧縮されたファイルを展開する。

• 攻撃者は「KhuntCmd」を使い、Windowsの管理者権限を確認するコマンド「cmd.exe /c whoami」を実行して、自身が最高権限である「SYSTEM」であることを確かめていた。その後、PowerShellやレジストリ操作ツールを用い、Windowsの設定や暗号化されたパスワード情報が格納されている重要な設定データ（レジストリハイブ）をOracleの作業ディレクトリへとコピーした。さらに、現在実行中のタスク一覧をテキストファイルに書き出したほか、Windows標準のデータベースユーティリティ（esentutl.exe）を使ってさらなる認証情報の抽出を図っていた。

• Huntressは、これらの盗み出されたデータがローカルのディスク上に整理・保存（ステージング）されたところまでは観測したものの、最終的に外部へと持ち出された（エクスフィルトレーション）かどうかは確認できなかったとしている。また、攻撃を実行したアクターの特定には至っていないが、悪意あるリクエストの送信元として「178.162.151[.]229」というIPアドレスが確認されている。

• この「khunt」を検知するには、Oracleデータベース内で「Khunt」で始まるオブジェクト名が存在するかを確認するか、SQLログから「KHUNT%」というパターンを検索する必要がある。しかし、これらは特定のツールキットに対する個別対処に過ぎず、他の名称や手法を用いた同様の攻撃を防ぐことはできない。また、この問題に対するOracle側からの直接的な修正パッチは存在しない。脆弱性そのものはアプリケーションの設計やデータベースの権限管理といった運用上の不備に起因するためである。

• Huntressは根本的な防御策として、Webアプリケーション側で入力値を適切に処理する「パラメータ化クエリ（安全に命令を組み立てる手法）」を導入してSQLインジェクションを防ぐこと、そしてデータベースアカウントに「最小権限の原則」を適用し、外部向けのアプリ用アカウントにはJavaソースの作成や不要なプログラムの実行権限を一切与えないようにすることを強く推奨している。