SQLインジェクションからOracle内JVMを悪用、ディスクフリーでSYSTEM奪取──“khunt”が映すEDRの死角

今日の深掘りポイント

• WebアプリのSQLインジェクション（SQLi）からDB内部のJava機能を悪用し、WindowsでSYSTEM権限のコード実行に到達する一気通貫の手口です。
• ツールをディスクに落とさず、データベースがソースコードを受け取り内部でコンパイル・実行するため、従来のEDR・AVの検知面が薄い経路を突いています。
• 攻撃者は複数のJavaオブジェクトとPL/SQLラッパーを作成し、コマンド実行や資格情報（ユーザー名・パスワードハッシュ）取得までをDBエンジン内で完結させています。
• Oracle依存の官公庁・基幹系での横展開可能性が高く、国家レベルのスパイ活動や破壊工作の足がかりになり得ます。
• SOCにとっては「oracle.exeの子プロセス」「DB内Java/スキーマオブジェクトの異常生成」「DBスケジューラ／DDLの異常イベント」といった新しいテレメトリ重視への転換が急務です。
• メトリクスが示すのは、新規性だけでなく“実用性と即時性の高さ”。封じ込め失敗時の影響半径が大きく、短期の検知運用と中期の権限設計見直しを二段で回す必要があります。

はじめに

「データベースはデータをしまっておく箱にすぎない」──その常識をひっくり返す事案です。攻撃者は公開WebアプリのSQLiを起点にOracle DBへ侵入し、DBエンジンが備えるJava機能でソースコードを“中で”コンパイル。OSコマンド実行をDB経由でたぐり寄せ、Windows上でSYSTEM権限を得ています。ディスクに落ちない、EDRが見にくい、DBは高権限で動く──この三拍子が、運用の綻びを鋭く突いています。

本稿では、公開情報で確認できる事実を整理しつつ、DBを“計算機”として扱う攻撃の本質と、SOC・CISOが今日から変えるべき視点を掘り下げます。読者の環境がOracleであれMySQL/PostgreSQLであれ、「DB＝実行環境」の視点は共通です。防御の更新を一足先に始めたいです。

深掘り詳細

事実関係（確認できたこと）

• 入口は公開WebアプリのSQLiで、Oracle DBに侵入した事実です。
• 攻撃者はJavaソースコードをDBに投入し、ストアド・スキーマオブジェクトとしてコンパイルさせ、DBエンジン内からOSコマンドを実行しています。
• 実行可能ファイルをディスクに書き込まず、ポストエクスプロイトの機能セット（Huntressが“khunt”と命名）をDB内部に展開しています。
• これによりWindowsサーバー上でSYSTEMレベルのコード実行に到達しています。
• 2026年7月27日に資格情報窃取の検知を契機に調査が開始され、悪意の通信元として178.162.151[.]229が観測されています。
• 複数のJavaオブジェクトとPL/SQLラッパーを作成し、コマンド実行やユーザー名・パスワードハッシュの取得まで行っています。
• 出典（オリジナルの技術詳細は二次情報経由）: The Hacker News

上記は公開記事に基づく事実です。以降は、確認可能な事実を土台にした分析と、仮説である旨を明示した考察を分けて示します。

インサイト：なぜ効くのか／何が新しいのか

• DBは“高権限の長期稼働プロセス”です。Windows環境でOracleサービスが高権限（多くはSYSTEM）で動作していれば、DB内部の機構でOSコマンドが呼べる時点で特権昇格の経路が開きます。これは設計上の権限境界の弱さを突くもので、脆弱性というより“パワフルすぎる正規機能”の乱用です。
• コンパイル後実行（Compile-after-delivery）は、エージェントやファイルベース検知の網をすり抜けます。ソースがDBに入り、バイトコードやネイティブに変換され、揮発的に使われるだけなら、EDRは“悪性バイナリ”の存在を前提にしたシグネチャを当てにくいです。
• 多くの組織はDBサーバーでパフォーマンス配慮からEDR除外やルール緩和を入れがちです。そこに「oracle.exeの子としてシェルやスクリプトが短時間だけ立ち上がる」という動態は、未調整のまま見逃されやすいです。
• 新規性は「実現可能性の実証」にあります。OracleのJava機構を使ったOSコマンド実行自体は昔から概念的に知られていますが、SQLiからの一気通貫・ディスクレス・資格情報窃取までを“実用のキット”として現場で回した点が、攻撃者側の意思と準備の更新を示します。

防御の盲点：DBは“データ”ではなく“実行環境”

• SOCの可視化がアプリ層とOS層に偏り、DB層の実行テレメトリが空白になりがちです。DDL（Java/PLSQLオブジェクトの作成・変更・削除）、DBスケジューラのジョブ生成、DBからの外向き接続といった“DB固有の動き”をSIEMに上げていない組織は珍しくないです。
• アイデンティティ境界の設計でも、アプリケーションアカウントがDB内で過剰権限（スキーマオブジェクト作成・スケジューラ実行）を持つ例は多く、SQLiが「ただの読み取り」では済まなくなります。
• 運用の都合で「DBサーバーはネットワーク的に何でも出られる」構成が残っている環境では、DBプロセス起点の外部C2やデータ持ち出しを阻止しにくいです。

脅威シナリオと影響

以下は、公開事実を踏まえたうえでの想定シナリオ（仮説を含む）とMITRE ATT&CKに沿った整理です。具体的なT番号は環境依存のため記しませんが、マッピングの観点を示します。

• 初期侵入（確定事実）
  • 公開WebアプリのSQLインジェクション悪用（Exploit Public-Facing Application）。
• 実行（確定事実）
  • OracleのDB内部Java機構を用いたコードのコンパイルと実行（Compile after delivery／Server-side execution）。
• 権限昇格（確定事実）
  • DBサービスの実行権限を継承し、WindowsでSYSTEM相当のコード実行に到達（Abuse of system service context）。
• 永続化（仮説）
  • Java/PLSQLオブジェクトやDBスケジューラのジョブ、DDLトリガー等を用いた持続化（Database-resident persistence）。
• 防御回避（確定事実＋仮説）
  • ディスクレス展開、DBエンジン内でのコンパイル、EDR除外の悪用、正規のDB機能に偽装（Living-off-the-land in DB）。
• 資格情報アクセス（確定事実）
  • DB内の認証情報・ハッシュの取得（Credential Access via DB functions）。
• 内部偵察（仮説）
  • DBAメタデータ照会、リンクDBやジョブの列挙（Discovery via system catalog）。
• 横移動（仮説）
  • SYSTEM権限を梃にしたリモートサービス悪用やAD連携の探索（Lateral movement via remote management tools）。
• C2・流出（仮説）
  • DBサーバーから外向きHTTP/HTTPS/DNS等でC2確立、データ段階的持ち出し（Application layer C2／Exfil via allowed egress）。

影響の勘所は二つです。第一に、DBが「組織の最上位特権」に接しているため、一度踏まれると復旧・監査・通報コストが跳ね上がること。第二に、業務継続計画（BCP）の中でDBは停止できない前提になりやすく、封じ込め時に手が鈍ることです。攻撃者にとっては“うるさくしないまま長く居座れる”地の利があり、国家・大規模犯罪双方が好む足場になり得ます。

セキュリティ担当者のアクション

“いますぐ”と“これから”を分けて、現実的に回せる順に並べます。攻撃手法の性質上、手順の詳細化は避け、高度に具体的な実装は各ベンダー手順書に委ねます。

• 0〜24時間：可視化と緊急遮断

  • ネットワーク
    • DBサーバーの外向き通信を原則遮断し、運用上必要な宛先だけに最小化します（プロキシ経由の明示許可制に移行するのが望ましいです）。
    • 観測IoC（178.162.151[.]229）を用いたフローの遡及検索とブロックを実施します。単発IoCに依存せず、類似AS／同一ホスティング帯のアクセスの異常も併せて確認します。
  • EDR/SIEM
    • oracle.exe（およびDB関連プロセス）の子プロセス生成、短寿命のシェル・スクリプト実行、外向き接続開始を高優先度アラート化します。DBサーバーに設定しているEDRの除外・抑制ルールを棚卸し、最小限に戻します。
  • DB監査
    • 直近30日の「Java/PLSQLオブジェクト作成・変更・削除」「スケジューラジョブ作成・実行」「外部プロシージャ／ライブラリ定義」等のDDLイベントを抜き出し、通常業務との乖離を確認します。
    • DDL／ログイン失敗の増加、権限昇格（ロール付与）のイベントを集約します。

• 24〜72時間：封じ込めとスコープ確定

  • 影響範囲の確定
    • 同一アプリケーションから到達可能な全DB、リンクDB、レプリカを範囲に含めます。影響DBのバックアップ整合性と保全計画を確立します。
  • アカウント・権限
    • 侵入経路となったアプリケーションアカウントのパスワードローテーション、不要権限（スキーマ作成、スケジューラ実行等）の剥奪を実施します。
  • アプリ側の一次対処
    • 当該Webアプリの脆弱入力点を仮修正（WAFの一時ルール、入力無効化）し、恒久修正のリードタイムを確保します。

• 7〜30日：恒久対策の設計と実装

  • アプリケーションセキュリティ
    • SQLi根絶のためのパラメータ化・入力検証・ORマッパー安全設定の標準化と、定常的なSAST/DASTの導入を進めます。
  • DBハードニング
    • 「DBを実行環境とみなした最小権限」へ再設計します。アプリアカウントに“オブジェクト作成・スケジューラ実行・外部呼び出し”を許さない原則を徹底します。
    • Java/外部呼び出しなど“OS境界を越える機能”は原則無効化、やむを得ず使う場合はスキーマ単位の厳格な許可・コードレビュー・監査ログ必須とします。
    • DBの統合監査をSIEMに連携し、DDL（特にJava/スケジューラ/外部ライブラリ）イベントと、DB内ネットワーク機能の使用を常時監視します。
  • OS・EDR
    • DBプロセスからの子プロセス生成・スクリプト実行をアラート／ブロックするポリシー（親プロセスベースの制御、アプリケーション制御）を検討します。
  • ネットワーク
    • DBサーバーのアウトバウンドをゼロトラスト前提に再設計し、明示許可先以外は遮断します。プロキシ／TLSインスペクションの対象に含め、例外は記録責任を伴う承認制にします。
  • 運用・体制
    • 「DBは計算機である」を前提に、DBA・アプリ・SOCの三者でプレイブックを再作成します。復旧と並行で監査の再現性を確保するため、証拠保全（ローテーション・バックアップからの再現手順）を整備します。

• 検知分析のヒント（ルール化に落としやすいもの）

  • 親プロセスがoracle.exeのプロセス生成（cmd、powershell、cscript、wscript、rundll32等）。短寿命・連続生成・外向きソケット開始の組み合わせは高リスクです。
  • DB内の異常なDDLイベント連鎖（CREATE JAVA/PLSQL → スケジューラ作成 → 即時実行 → DROP）。ライフサイクルが分単位の“使い捨て”は要注意です。
  • DBサーバーから新規の外向きドメイン・ASNへの通信開始。特にDBが通常は内部通信に限定されている場合は高スコアで扱います。
  • アプリケーションアカウントによる権限変更やスキーマ操作。通常はDBA専用のオペレーションがアプリ経由で出ていないかを機械学習よりもまずルールで押さえます。

• リスクコミュニケーション

  • CISOは「短期は監視強化と外向き遮断、中期はDB最小権限化・EDR除外の是正、長期はアプリの設計原則刷新」という三段ロケットで投資計画を引き直します。影響半径（基幹・省庁・二次接続先）を定量化し、優先順位の裏付けを示すことが重要です。

メトリクスの示唆（総合評価）

• 緊急度と成立確率の高さに比して、防御側の“既存資産で取れる手”が限られがちなのが今回の難所です。反面、検知のカギは“新規製品”ではなく、“既存ログの見方”と“権限のひきしめ”にあります。まずはDBを実行環境として観測し、EDRの除外とネットワークの外向き自由を見直す──これが現場で最も効果の出やすい一手です。

参考情報

• The Hacker News: Attackers Compile ‘khunt’ Inside Oracle to Elevate SQL Injection to Windows SYSTEM Access（2026-08-06）: https://thehackernews.com/2026/08/attackers-compile-khunt-inside-oracle.html

本稿は上記の公開情報を基に執筆し、推測・仮説は明記して区別しました。読者のみなさんの現場経験からのフィードバックも歓迎します。DBを“見える化”し、運用の知恵で攻撃の経路を一つずつ潰していきたいです。