Oracleへのシステムコマンド攻撃、SQLインジェクションからリモートコード実行に発展

何十年も前から知られている手法であるにもかかわらず、SQLインジェクション(SQLi)は今なおサイバー犯罪者にとって有効な攻撃手法であり続けています。 

Huntressが最近公表した調査報告では、一見ありふれたSQLインジェクション攻撃が、Oracleデータベースの機能を悪用することでOS(オペレーティングシステム)全体の侵害にまで発展した経緯が明らかにされています。 

今回のSQLインジェクション攻撃の要点

• インターネットに公開されたJava/TomcatアプリケーションのSQLインジェクション脆弱性により、攻撃者はOracleデータベースへの初期アクセスを獲得し、最終的には基盤となるWindowsサーバー上でリモートコード実行を達成しました。
• 攻撃者はOracleの「CREATE JAVA SOURCE」機能を悪用し、khuntツールキットを展開しました。これは、正規のデータベース機能が武器化され、永続化の確立や従来型のエンドポイントセキュリティツールの回避に利用され得ることを示しています。
• 脅威アクターはkhuntツールキットを使用してOSコマンドを実行し、OracleおよびWindowsから認証情報を窃取したほか、権限昇格や情報窃取に悪用可能なレジストリハイブを収集しました。
• 組織は、セキュアコーディングの実践、データベースアクセスの最小権限化、Oracle監視の強化、定期的なペネトレーションテスト、そして検証済みのインシデント対応計画を組み合わせることで、同様の攻撃のリスクを低減できます。

OracleへのSQLインジェクション攻撃はどのように始まったのか 

Huntressによると、この事案は2026年7月27日、OracleデータベースサーバーをホストするWindowsエンドポイントで認証情報窃取の活動が検知されたことから発覚しました。 

調査の結果、インターネットに公開されたJava/Tomcatアプリケーションがユーザー入力を適切に検証していなかったため、攻撃者が悪意のあるSQLコマンドを注入できる状態にあったことが判明しました。 

この脆弱なアプリケーションは、JDBC(Java Database Connectivity)接続を通じてそれらのコマンドをOracleデータベースに直接渡していたため、攻撃者に初期の足掛かりを与える結果となりました。

この攻撃で特筆すべきなのは、初期侵害後に用いられた手法です。 

脅威アクターは、マルウェアをオペレーティングシステムに直接展開するのではなく、Oracleの「CREATE JAVA SOURCE」機能を使って、khuntという名のデータベース常駐型ツールキットをアップロードしました。 

Oracleデータベースには組み込みのJVM(Java仮想マシン)が搭載されており、開発者はJavaコードをデータベースオブジェクトとして格納できます。

今回のケースでは、攻撃者はこの正規機能を悪用し、悪意のあるJavaコードをデータベース内で直接コンパイル・実行することで、従来型のエンドポイントセキュリティツールでは見落とされかねないステルス性の高い永続化メカニズムを構築しました。

このツールキットは、攻撃者の能力を拡張するいくつかの専用モジュールで構成されていました。 

KhuntCmdはSQL文を通じて任意のWindows OSコマンドを実行できるようにするものでした。 

KhuntHashはOracleのユーザー名とパスワード情報をファイルに抽出し、KhuntFSおよびKhuntFS2はファイルの閲覧・読み取り・検索機能を提供しました。 

その他の構成要素として、ツールキットが正常に機能しているかを確認するKhuntTと、圧縮ファイルを展開するKhuntUnzipがありました。 

これらのモジュールにより、Oracleデータベースは事実上、基盤となるオペレーティングシステムと直接やり取りできる侵害後活動用のプラットフォームへと変貌しました。

khuntツールキットにより、攻撃者はOracleデータベースと基盤のWindowsオペレーティングシステムとの間のギャップを埋めることができるようになりました。 

そのKhuntCmdモジュールを通じて、ツールキットはSQL文をデータベースに送信することで任意のOSコマンドを実行できるようにし、事実上データベースをリモートコード実行のためのプラットフォームへと変えてしまいました。

ツールキットを展開した後、攻撃者はKhuntCmdを使ってwhoamiコマンドを実行し、SYSTEM権限を保有していることを確認しました。これは、Oracleデータベースを起点としてWindows OSに至るリモートコード実行が成功したことを示しています。 

続いて攻撃者はPowerShellおよびWindowsのユーティリティを使用し、パスワードハッシュを含むSAM、SYSTEM、SECURITYの各レジストリハイブをコピーしました。これらは認証情報の窃取や権限昇格のために抽出され得るものです。 

データを持ち出す準備を進める前段階として、攻撃者は「tasklist /svc」を用いて実行中のサービスの列挙も行っていました。

SQLインジェクション攻撃のリスクを低減する方法

今回のHuntressの調査は、基本的なセキュリティ対策が疎かにされていた場合、何十年も前からある攻撃手法であっても壊滅的な結果を招き得ることを示しています。

このケースでは、SQLインジェクションの脆弱性により、攻撃者はデータベースの枠を超え、Oracleの正規機能を悪用してリモートコード実行を達成することができました。 

組織は、Oracle環境全体にわたる防止・検知・対応の各段階を強化する多層的なセキュリティ対策を導入することで、同様の攻撃のリスクを低減できます。 

• パラメータ化クエリの実装と適切な入力検証により、SQLインジェクションの脆弱性が悪用される前に防御します。
• 最小権限の原則を徹底し、データベースアカウントがJavaソースオブジェクトを作成したり、ストアドプロシージャを実行したり、管理者権限の操作を行ったりする能力を制限します。
• 監視範囲をエンドポイント検知の枠を超えて拡大し、Oracleデータベースオブジェクト、SQLログ、想定外のJavaソース作成などを監査して悪意ある活動の兆候を捉えます。
• Oracle環境を定期的に精査し、不審なJavaオブジェクト、SQLログ内の「KHUNT%」という文字列、攻撃者が作成したレジストリハイブの痕跡など、既知の侵害の兆候(IOC)がないか確認します。
• OracleおよびアプリケーションのOracleおよびアプリケーション環境を堅牢化し、不要なデータベース機能を制限し、データベースの認証情報を保護し、データベースサーバーをインターネットに公開されたアプリケーションから分離します。
• ペネトレーションテストによる評価をソフトウェア開発ライフサイクルに組み込み、展開前に脆弱性を洗い出します。
• インシデント対応計画をテストし、SQLインジェクション攻撃やRCEを想定したシナリオで攻撃シミュレーションツールを活用します。

これらの対策を総合的に講じることで、組織は全体的な攻撃対象領域を縮小し、侵害が成功した場合の被害範囲を限定し、長期的なレジリエンスを構築することができます。 

結論

今回の事案における戦略的なリスクは、SQLインジェクション自体にあるのではなく、その後に何が起きるかにあります。 

攻撃者は一度足掛かりを築くと、Oracleデータベースを実行基盤へと変貌させ、従来型のエンドポイント監視の範囲外にほぼとどまったまま、リモートコード実行を可能にしました。 

敵対者が正規のプラットフォーム機能と既存の攻撃手法を組み合わせ続ける中、セキュリティ責任者は、自社の検知戦略がオペレーティングシステム上の活動だけでなく、データベース内に潜む脅威に対しても十分な可視性を提供できているかどうか、改めて見直す必要があります。 

今回のような事案は、暗黙の信頼を制限し、侵害が成功した際の影響を封じ込めるよう設計されたゼロトラストアーキテクチャの価値も改めて浮き彫りにしています。