AD Relay Attack：攻撃手法の分析および対応方法

‍

2022 年 10 月、CyCraft のシニア情報セキュリティリスクの研究者姜尚徳 (John Jiang)  と情報セキュリティ・ソフトウェアエンジニア孫維崗 (Gary Sun)  は、米国で開催された SANS Blue Team Summit に参加し、「Don’t Relay Me: Empirically Diagnose Privilege Escalation via Active Directory Account Sighting」と題する講演を行いました。

SANS Blue Team Summit は一年に一度、ブルーチームの関連技術の情報交換を中心として開かれるサミットです。「SANS」は、システム管理、監査、ネットワーク、セキュリティ(SysAdmin、 Audit、 Network、 Security) の頭文字からきており、業界をリードするブルーチーム専門家がそれぞれの見解や実務における経験などを発表します。

講演では、Active Directory の本人認証のリレーアタック技術と原因について検討し、 CyCraft による AD 調査の経験に基づき PsExec 、 RDP などのリモート管理ツールを使って、より高いレベルのセキュリティを確保する方法について説明し、講演の最後には、企業の経営活動で利用するための、運用に関するアドバイスなども説明しました。

‍

この記事では、その講演で発表した研究内容と、攻撃で利用された技術を紹介します。

‍

Active Directory (AD)とは

Active Directory (AD) はマイクロソフト社が開発した一元管理サービスで、主に管理ネットワークのリソースとユーザ情報の管理に用いられます。AD がネットワーク上で持つ役割は、巨大な電話帳や地図に似ています。企業内のコンピュータ、サーバ、ユーザがそれぞれを認識するのを助け、どのユーザがどのリソースにアクセスできるかを制御します。例えば、社員 A にフォルダー X へのアクセス権利を与えるなどが挙げられます。

AD には強大な機能を持つ「グループポリシーオブジェクト」(Group Policy Object,  GPO) があります。 GPO は管理ユーザとコンピュータ設定を管理するためのメカニズムです。システム管理者は GPO を使用して、ソフトウェアのインストール、セキュリティ対策、ネットワーク設定など、複数のコンピュータを一度に設定できます。つまり、企業の IT スタッフは、各コンピュータそれぞれにファイアウォール設定やソフトウェア更新する必要がなくなり、AD で GPO を一度設定するだけで社内の複数の機器に適用されるのです。

Active Directory や GPO は、非常に多くの設定や権限を一元管理できるため、情報セキュリティにおいて非常に重要な役割を担っています。AD や GPO が適切に設定されていないと、脆弱性が生じ、攻撃者が通常ではアクセスできないアクセス権を取得したり、設定の弱点を利用して攻撃やエクスプロイトを仕掛けたりする可能性があります。そのため、 AD や GPO を適切に設定・管理することは、業務の効率化を図るだけでなく、ネットワークセキュリティの基盤を確保することにもつながります。

‍

Active Directory の Logon Signing 機能

‍

‍

CyCraft は独自に開発した攻撃パスシミュレーションアセスメント技術を用い、様々な顧客のネットワーク環境のセキュリティの調査を行ってきました。その中でも、よく見られる AD セキュリティの問題は、設定の誤りと権限設定の問題です。これら設定上の問題のほとんどは静的データですが、人為的な操作は資格情報漏洩に繋が場合もあり、そのような動的データは非常に重要です。

今回の Blue Team Summit の講演の中で、私たちは図 1 を使って説明しました。赤の点はユーザまたはコンピュータです。台湾の最北部から最南端に移動するには、東部または西部の 2 本の既知の経路を利用するしかありませんが、中央山脈を貫通するルートを開設するなら話は別です。AD オブジェクトも同様です。ユーザはドメインコントローラにアクセスするために様々な権限を利用し、最短ルートを探すのです。私たちは、注意が最も必要となるのは最初の2本のルートだと考えています。

ユーザの資格情報は、窃取されることもあれば NTLM Relay 攻撃に遭うこともあり、ユーザが異なるアクセスポイントにログオンすることで、より多くの攻撃経路が生まれることもあります。上の図 1 にもあるように、ログオン情報 (Logon Signing) が増加すると、潜在的攻撃パスも幾何学的に増加します。ドメインコントローラがどこかのコンピュータ 1 台にログオンしたことがあると、攻撃パスに新たなアクセスポイントが発生します。このアクセスポイントは静的なパス分析の際には見つかりません。そのため、防御側が守るべき防御境界が知らず知らずのうちに増えることになります。

‍

資格情報の窃取と防御戦略

攻撃者による認証情報の取得と利用には、4 種類の攻撃ツールがよく用いられます：

‍

実際の防御では、これらの攻撃パターンに対応する必要があります。下図 3 は攻撃技術と防御技術の対応表です。私たちは攻撃の手法を Cached Credentials と Relay Auth という 2 種類のタイプに分け、さらにそれを細分化し、それぞれに対応する緩和策を示しました。しかしこの中の緩和策を利用しても完全に問題を解決できるわけではなく、問題の一部を改善できるに過ぎません。これは防御側のセキュリティスタッフが頭を痛めている点です。

‍

‍

Cached Credentials による緩和については別の機会に譲ることにして、この記事では、Relay Auth に特化して、その攻撃手法とそれに対する防御技術について理解を深めていきたいと思います。

Relay Auth の特徴は、 Computer Account に対して実行可能な攻撃が数多くあることです。一般的に、認証情報を盗む場合、ユーザログイン情報に焦点を当て、それを盗もうとすることがほとんどですが、 Relay Auth の場合、コンピュータログイン情報が盗まれ、他のサービスに転送される可能性があるのです。

さらにもう一歩進み NTLM Relay の後の緩和方法である「 Use Kerberos 」について考察してみます。 NTLM Relay を良く知る人の多くは、Kerberos 認証を使用すれば NTLM 攻撃を回避できると考えています。しかし、ユーザが自分は Kerberos 認証を行っていると思っていても、実際には認証プロセスが攻撃者によって NTLM にダウングレードされてしまっている可能性があるのです。これが今回この文章で特に考察したい点です。

NTLM Relay 攻撃についてよくご存じない方は、まず Pixis による NTLM Relay についての説明を一読ください：https://en.hackndo.com/ntlm-relay/。

‍

Windows の認証フロー

攻撃者がどのように Kerberos 認証をダウングレードして NTLM 人署うにするかの方法を討議するには、まず、 NTLM 認証を使用するか、あるいは Kerberos 認証を使用するかを Windows Authentication Process がどのように決定するかについて理解する必要があります。

2 つのプロトコルのうちどちらを選ぶかは、主にソフトウェアの実装にかかっています。ソフトウェアで NTLM 認証を使用する場合は、SSP (Security Support Provider) Layer の msv1.0.dll を使用し、ソフトウェアで Kerberos 認証を使用する場合は、 spengo.dll を使用することになります。

spengo.dll には、、 Kerberos 認証をサポートするだけでなく、 Kerberos 認証が接続を確立できなかった際に、 spengo.dll を使用することでアプリケーションを NTLM 認証に切り替えることができるという利点があります。

‍

‍

SPENGO (Simple and Protected GSS-API Negotiation)

認証に関する段落で、 GSS-API に代わって提供されるネゴシエーションメカニズムである spengo.dll を使用する必要性について述べました。 SPNEGO は、認証に関わる双方がネゴシエーションし、双方が受け入れられる認証方法を選択するためのフレームワークを提供しています。

下の図 6 が示すとおり、クライアント側がサーバに接続する際、まず NegoTokenInit を送信し、自分がサポートする認証方法を優先順位の高い順に並べたリストを提示します。サーバはこの認証方法サポートの優先順位リストから、自分もサポートでき、優先順位が上の認証方法を選び NegoTokenResponse を通してサポートする認証方法を返信します。このネゴシエーションのプロセスが終了すると、クライアントは双方が合意した認証方法で認証情報をサーバに送信します。

‍

‍

この説明からわかるとおり、接続したサーバが攻撃に遭い Compromise された場合、攻撃者は次の接続から Kerberos 認証を使うか、それとも NTLM 認証を使うかをコントロールする機会を得ることになります。これが攻撃者の狙いです。このようにして攻撃者はクライアントの資格情報を窃取できるようになるのです。

‍

攻撃ツール

次に、攻撃ツールとその構造について説明します。説明の前に、まず@_EthicalChaosに感謝したいと思います。この攻撃の検証が可能になったのは、彼が開発した PoC ツール Lsarelayx によるところが大きいからです。

Lsarelayx は、 msv1.0.dll 、lsasrv.dll 、 spnego.dll を hook することで、認証パケットをブロックし、すべての接続に対して強制的に NTLM 認証を優先させます。 hook msv1.0.dll は、 NTLM 認証の内容を取得するために用いられます。例えば、 NTLM Relay において、署名を削除したり、パケットを RAW サーバ（ ntlmrelayx ）に転送したりしたい場合などです。 ntlmrelayx は impacket の下の攻撃ツールで、基本的に NTLM relay 以降の全ての攻撃に対応しています。

‍

‍

NTLM Relay の攻撃シナリオ

次に、攻撃シナリオについて考察します。下表は、 Relay される可能性のあるサービスを整理したものです。 NTLM Relay の記事などでよく見られる、 PSEXEC または CIFS などネットワーク共有リソースで Relay する方法とは異なり、私たちが下表で整理したものは、実際の環境で発見されたサービスに関するものです。この記事では、そのうち比較的特殊な SCCM、 Microsoft SQL 、サードパーティ脆弱性検査ツールの 3 事例を検討します。また、上記のツールを利用する場合、どのような点に注意すべきかについても説明します。

‍

SCCM

マイクロソフト・システムセンター・コンフィギュレーション・マネージャー（ Microsoft System Center Configuration Manager, SCCM ）は、 Microsoft が開発したシステム管理ソフトウェアです。システム管理者が OS を効果的に管理できるようにするためのもので、 Active Directory と結合し、リモートインストール Agent、遠隔制御、システム更新、ソフトウェアのデプロイメントなどを行うことができます。私たちの実測によると、認証は実際に 2 種類に分けることができます：

‍

１，アクセスポイントを SCCM の管理対象とすると、Agent のコミュニケーションチャネルを利用します。例えば、ある企業が SCCM で新しいソフトウェアを指定コンピューターにデプロイすると、指定コンピューターは定期的に SCCM Server とコミュニケーションを取り、能動的に SCCM Server と接続します。この接続プロセスは NTLM Relay されることはなく、もし Relay するとすれば、まず SCCM Server を攻撃することが必要になります。

２，SCCM が能動的に情報をアクセスポイントにプッシュするという方法です。よくあるモデルは、企業が定期的に環境をスキャンし、コンピューターを更新して SCCM Agent をインストールするというものです。この段階で、Agent がインストールされたアクセスポイントにハッカーが侵入すると、ハッカーはここで説明した手法で NTLM Relay を行い、SCCM が用いる高権限のアカウントを窃取します。

‍

‍

Microsoft SQL (MSSQL)

MSSQL はマイクロソフトのデータベースシステムで、広く採用されているリレーショナルデータベース（ RDB ）の一つです。 SMB リソースへのリモート・アクセスをサポートしているため、基本的には CIFS を経由しており、 MSSQL を利用するプロセスを Relay することが可能です。このシナリオに加え、さらに重要な問題は、 SQL Server が Compromised されると、ハッカーが管理スタッフのログオン情報に Relay できるのかという問題です。その答えは、可能です。

以下は、MSSQL が認証を実行する際に、どのように Kerberos 認証か NTLM 認証かを決定するかを示したフロー図です。 MSSQL のバージョンによっては多少の違いがあるかもしれません。 MSSQL は Kerberos ログオン認証の際に SPNEGO を採用しますが、この点でソフトウェアの設計はとても優れていると言えます。なぜなら、 MSSQL はここでは Kerberos 認証しかサポートしないからです。

一方、リモート接続があり、かつ MSSQL に Active Directory のService Principal Name（ SPN ）が存在しない時には NTLM 認証が選択されます。しかし、私たちの攻撃シナリオでの前提は、 SQL Server が既に Compromised されているので、 MSSQL の SPN を削除するのは容易です。管理スタッフが SQL に接続する時にもその変化に気づかない可能性が高いです。

‍

‍

脆弱性検査ツール

最後の攻撃シナリオは、ある著名なサードパーティ脆弱性検査ツールですが、ここではソフトウェアの名前には触れないでおきます。私たちの理解によれば、この攻撃手法は類似のコンセプトを持つすべての製品に共通しています。そのためここに挙げるのは一例にすぎません。多くの企業では、定期的にアクセスポイントに対して自動の脆弱性スキャンをしていますが、脆弱性スキャンを自動化する、またはアクセスポイントに未更新のソフトウェアがないか検査するためのツールはどれも、いわゆる「エージェントなし」のモデルをサポートしています。このモデルを利用するには、どうしてもアクセスポイントにログオンできる高権限のアカウントを提供する必要があります。また使用されるのは往々にして共通の高権限アカウントなので、1 回取得するだけで、複数のコンピュータにログオンできてしまいます。

私たちが脆弱性検査ツールを検査したところ、こうしたツールの高権限アカウントの実装方法は安全であるとは言えない状況でした。下図 11 が示すとおり、高権限アカウントを提供する際には、 Kerberos 、 NTLM 、 Password のうちから認証方法を選択できますが、実際に選択されるのは、検査ツールがターゲットエンドポイントに接続する際に提供する認証サポートリストの順序です。つまり、脆弱性検査ツールで Kerberos を選択したとしても Relay される可能性があるということです。さらに、 Comproised されたエンドポイントに接続してしまうと、高権限アカウントが NTLM Relay されるリスクが一層高まります。

‍

‍

‍

緩和措置

この記事では、様々な攻撃の可能性を紹介しましたが、防御側は、どのようにこれらの攻撃を阻止し、損失からその身を防ぐことができるのでしょうか。実際のところ、Active Directory で NTLM 認証の利用を完全に禁止する方法はありません。そのため、次のような緩和措置を提案します：

• 高い権限を持つ Tier-0 ユーザ／コンピュータアカウントを制限し、それが Kerberos 認証しか使用できないようにし、これらの重要なアカウントを Protected Accounts グループに所属させる。
  • こうすることである程度の保護を得ることができます。詳細は、Microsoft社 が発表した次の文書をご参照ください: https://learn.microsoft.com/en-us/windows-server/security/windows-authentication/how-to-configure-protected-accounts。

• 上の「資格情報の窃取と防御戦略」で示した図 3 各種の攻撃の緩和方法 を参考に、可能な限り対応する緩和措置を実施する。
  • 文章中で述べたとおり、どの緩和方法も攻撃を完全に阻止することはできませんが、防御側は攻撃者の攻撃コストを上げることができます。

• ご使用のサービスが Kerberos 認証をサポートできることを確認し、 Kerberos 認証だけを使用するように設定する。
• 使用環境における認証情報を再確認し、Active Directory 攻撃パスシミュレーション評価サービスを利用して、潜在的な影響範囲を分析する。

‍

結論

NTLM Relay のリスクは至るところに存在します。 NTLM Relay は環境への対応性とソフトウェアとの互換性が高いため、多くの環境でこの種の攻撃を受けやすくなっています。これは無視できない潜在的リスクです。また、Exchange のテーマも、近年では脆弱性と  NTLM Relay に関するものが増えています。この事からも NTLM Relay に類似した実装の問題が、単にサードパーティのソフトウェア開発者の不注意により発生したものだけではなく、危険な実装によるものもあることがわかります。企業はこの事態に留意し、慎重に対応する必要があります。