何十年にもわたって知られているにもかかわらず、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コマンドを注入できる状態だったことが判明した。
脆弱なアプリケーションは、Java Database Connectivity（JDBC）接続を介してそれらのコマンドをOracleデータベースに直接渡しており、攻撃者に初期 footholdを与えた。
Oracle Javaを使った攻撃者によるツールキットの展開
この攻撃で注目すべき点は、初期侵害後に用いられた手法だ。
脅威アクターは、マルウェアをOSに直接展開するのではなく、OracleのCREATE JAVA SOURCE機能を使って、データベース内に常駐するkhuntというツールキットをアップロードした。
OracleデータベースにはJava Virtual Machine（JVM）が組み込まれており、開発者はJavaコードをデータベースオブジェクトとして保存できる。
このケースでは、攻撃者はその正規機能を悪用し、データベース内で悪意のあるJavaコードを直接コンパイルして実行した。これにより、従来のエンドポイントセキュリティツールが見落とす可能性のある、隠密な永続化メカニズムを作り出した。
このツールキットは、攻撃者の能力を拡張する複数の専門モジュールで構成されていた。
KhuntCmdにより、SQL文を通じて任意のWindows OSコマンドを実行できた。
KhuntHashはOracleのユーザー名とパスワード情報をファイルに抽出し、KhuntFSとKhuntFS2はファイルの閲覧、読み取り、検索機能を提供した。
その他のコンポーネントには、ツールキットが正常に機能していることを確認するKhuntTや、圧縮ファイルを展開するKhuntUnzipが含まれていた。
これらのモジュールにより、Oracleデータベースは実質的に、基盤となるOSと直接やり取りできる侵害後活動のプラットフォームへと変貌した。
Khuntツールキットがリモートコード実行（RCE）と認証情報窃取を可能にした仕組み
khuntツールキットにより、攻撃者はOracleデータベースと基盤となるWindows OSの間を橋渡しできるようになった。
ツールキットの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%エントリー、攻撃者が作成したレジストリハイブのアーティファクトなど、既知の侵害指標を探す。
- Oracleとアプリケーションの環境を強化し、不要なデータベース機能を制限し、データベースの認証情報を保護するとともに、データベースサーバーをインターネットに公開されたアプリケーションから分離する。
- ペネトレーションテスト評価をソフトウェア開発ライフサイクルに組み込み、デプロイ前に脆弱性を特定する。
- インシデント対応計画をテストし、攻撃シミュレーションツールを使って、SQLインジェクション攻撃やRCEを想定したシナリオを実施する。
これらの対策を総合的に講じることで、組織は全体的な攻撃対象領域を縮小し、侵害に成功された場合の被害範囲を抑え、長期的なレジリエンスを構築できる。
結論
戦略上のリスクはSQLインジェクションそのものではなく、その後に起きることだ。
攻撃者は足場を確立すると、Oracleデータベースを実行プラットフォームに変え、従来のエンドポイント監視の対象外にほぼとどまりながらRCEを可能にした。
攻撃者が確立された攻撃手法と正規のプラットフォーム機能を組み合わせ続ける中、セキュリティ責任者は、OS上で発生する活動だけでなく、データベース内に常駐する脅威も十分に可視化できる検知戦略になっているかを見直すべきだ。
このようなインシデントは、ゼロトラストアーキテクチャの価値も浮き彫りにする。これは暗黙の信頼を制限し、侵害に成功した場合の影響を封じ込めるよう設計されている。