2026年7月27日に検知されたこのインシデントは、セキュリティ対策が不十分な公開アプリケーションが、攻撃者にデータベースクエリの操作から基盤OSの完全掌握までの道を開いてしまうことを示しています。
最初のアラートは、OracleデータベースをホストするWindowsエンドポイントで発生した認証情報窃取の活動に関するものでした。セキュリティツールは、reg.exeがSAM、SECURITY、SYSTEMを含む機密性の高いレジストリハイブのコピーを作成していることを検知しました。
これらのファイルを入手すれば、攻撃者はパスワードハッシュを抽出し、ローカルアカウントへのアクセス権を得ることができます。
調査担当者は、この不審なreg.exeプロセスがoracle.exeによって起動されていたことを突き止めました。この異例の親子プロセス関係をきっかけに、Huntressは攻撃者がどのようにOracle環境へのアクセス権を得たのかを調査することになりました。
Apache Tomcatのアクセスログから、侵入の起点が判明しました。それは、JDBC経由でOracleに接続された公開Javaアプリケーションに対するSQLインジェクションでした。
この脆弱なアプリケーションは、入力フィールドを通じて送信されたSQLコマンドを、データの検証やパラメータ化を行うことなく受け入れていました。
SQLインジェクションは目新しい脆弱性の種類ではありません。通常は、アプリケーションがユーザー制御下の入力をそのままデータベースクエリに渡してしまうことで発生します。
例えば、ユーザー名検索フィールドは本来、SQL構文を拒否し、パラメータ化されたクエリを使用すべきです。こうした対策がなければ、攻撃者は通常のテキストの代わりにデータベースコマンドを埋め込むことができてしまいます。
SQLインジェクションによるアクセス権を獲得した後、脅威アクターはkhuntと呼ばれる、データベース常駐型の侵害後利用ツールキットをアップロードしました。
このツールキットは、OracleのJava仮想マシン組み込み機能を利用しています。これはCREATE JAVA SOURCE文を通じて、Javaのソースコードをデータベースオブジェクトとして保存・コンパイルできるようにする機能です。
攻撃者は、悪意のあるCREATE JAVA SOURCEコマンドを、TomcatアプリケーションからJDBC接続を経由してOracleに送信しました。Oracleはその後、提供されたJavaコードをデータベース内でコンパイルし、スキーマオブジェクトとして保存しました。
この手法により、攻撃者は従来型のマルウェアファイルをディスク上に直接配置することなく、自分たちのツールをOracleデータベース内に留めておくことができました。
この手口は、一般にoraexecなどと呼ばれるツールを含む、OracleのSQLインジェクションからRCEに至る手法に関するこれまでの研究と類似しています。
ただし、Huntressによれば、このデータベース常駐型の手法が実際に使用された事例が文書化されているケースは今のところ稀だということです。
この手法が特に懸念される理由は、従来型のエンドポイントセキュリティ製品が主にファイル、バイナリ、メモリ、プロセスを検査対象としている点にあります。
Oracleデータベース内に隠された悪意のあるJavaクラスやPL/SQLラッパーは、こうした検査の目をかいくぐりやすいとHuntressは指摘しています。
注: IPアドレスおよびドメインは、誤った名前解決やハイパーリンク化を防ぐため、意図的に無害化表記（例: [.]）にしています。再度有効な形式に戻す際は、MISP、VirusTotal、またはお使いのSIEMなど、管理された脅威インテリジェンスプラットフォーム内でのみ行ってください。
ANY.RUNのブラウザ内データ検査で、検知・調査・対応をより迅速に。フィッシングの完全な可視化を実現し、SOCを強化してMTTRを削減しましょう
翻訳元: https://cyberpress.org/oracle-sqli-achieves-system/
