Kerberoastingとは何か。サービスアカウントの弱いパスワードが狙われる仕組みと対策

Kerberoastingは、Active Directoryの正規のKerberos機能だけでサービスチケットを集め、サービスアカウントのパスワードを手元で解析する手口です。脆弱性を突くわけでも管理者権限を奪うわけでもなく、通常のActive Directory構成であれば、ドメイン利用者の資格情報があるだけで要求そのものは通ります。対象読者は、Active Directoryの運用やSOCで検知と対策にあたる実務担当者です。記述はMITRE ATT&CKのT1558.003とMicrosoft公式ドキュメント、JPCERT/CCの公開資料にもとづき、事実は執筆時点(2026年8月1日)で確認できた範囲に限ります。攻撃ツールの実行手順は書きません。動作確認は、自組織が管理する、またはその管理者から許可を得た検証環境でのみ行ってください。許可のないドメインでチケットを収集したり解析を試みたりする行為は、不正アクセス禁止法など関連法令に触れるおそれがあります。

Kerberos認証とサービスプリンシパル名の基礎#

Active Directoryドメインでは、ドメインコントローラー上のKDC(鍵配布センター)がAD DSをアカウント情報の格納先として使い、Kerberos v5による認証をまかないます。利用者がサインオンすると、まず認証サービスとのやり取りでチケット許可チケット(TGT)を受け取ります。個別のサービスへアクセスする段では、クライアントがTGTと認証子、接続先を表すサービスプリンシパル名(SPN)をKDCへ提示し、そのサービス向けのサービスチケットを受け取ります。これがチケット許可サービス交換(KRB_TGS_REQとKRB_TGS_REP)です。

SPNはサービスのインスタンスを一意に指し示す名前で、サービスがドメインアカウントとして動作する場合はそのアカウントの属性としてActive Directoryに登録されます。どのアカウントがどのサービスを提供しているかは、ディレクトリを検索できれば把握できます。

Microsoft Learnは、サービスチケットがKDCと対象サービスで共有される長期鍵(サービス鍵)で暗号化され、チケットを持つクライアント自身は中身を読めないと説明しています。あわせて、サービスはログオンに使うアカウントのパスワードにもとづく鍵を用いると記載しています。

この「サービスチケットはサービスアカウントのパスワード由来の鍵で暗号化される」という仕様が、そのままKerberoastingの土台になります。

Kerberoastingが成立する仕組み#

MITRE ATT&CKのT1558.003は、有効なTGTを持つ攻撃者がSPNを指定してサービスチケットを要求し、得られたチケットに総当たり解析をかける手口としてKerberoastingを定義しています。KDCは、そのSPNに紐づくアカウントの鍵でチケットを暗号化して返します。要求した側は平文を読めませんが、手元の暗号文に対して「パスワード候補から鍵を導出し、復号を試し、正しく復号できたかを判定する」試行を好きなだけ繰り返せます。候補が当たれば平文パスワードが判明します。

防御側にとって扱いにくいのは、3点が重なるためです。第1に、通常のActive Directory構成では、有効なTGTを持つ利用者が、認証ポリシーなどのアクセス制御で制限されていない登録済みSPNに対して要求でき、権限昇格を必要としません。認証ポリシーや認証ポリシーサイロを構成し、KDCがサービスチケットの発行を拒否するようにしている環境では、この前提が変わります。第2に、解析はドメインコントローラーと通信せずに進むため、認証失敗もアカウントロックも発生しません。第3に、SPNの一覧はディレクトリ検索で得られるため、狙う相手の選定にも特別な権限が要りません。

MITRE ATT&CKはT1558.003を戦術Credential Access(TA0006)に分類しています。チケットの一部がRC4-HMAC(etype 23)で暗号化される場合、サービスアカウントのパスワードから導出されるNTパスワードハッシュが長期共通鍵として使われるため、パスワード候補をオフラインで検証できます。緩和策はM1041(強い暗号化アルゴリズムの利用)、M1027(パスワードポリシー)、M1026(特権アカウント管理)です。悪用例としてFIN7やWizard Spider、APT29が記録されています。

RC4とAESで解析コストが変わる理由#

チケットの暗号化タイプによって、パスワード候補1つあたりの計算量が変わります。RC4-HMACの鍵導出は、RFC 4757がString2Key(password) = MD4(UNICODE(password))と定義しているとおり、ソルトも反復もない単純なハッシュ1回です。事前計算した表を使い回せますし、1回の試行にかかる計算量も小さいままです。一方、AESの鍵導出はRFC 3962がPBKDF2にソルトと反復回数を与える形で定義しており、パラメータが与えられない場合の反復回数は4096回とされています。試行1回あたりの負担が桁違いに重くなります。

ただしAESへ切り替えても、チケットがパスワード由来の鍵で暗号化される構造は変わりません。AESへの移行だけでは、短いパスワードや推測されやすいパスワードを補えないということです。逆に、十分にランダムで長い資格情報であれば、暗号化タイプにかかわらずオフラインでの推測を現実的に困難にできます。MITRE ATT&CKも、25文字以上の強力なパスワードと、gMSAなどの管理されたサービスアカウントを、それぞれ独立した緩和策として挙げています。

なぜサービスアカウントが狙われるのか#

SPNが登録されていればコンピューターアカウントも対象になり得ますが、実務で問題になりやすいのは人が作ったドメインユーザーのサービスアカウントです。パスワードを変えるとアプリケーションの停止や設定変更を伴うため長期間そのままにされがちで、手順書に平文で書かれる都合上、人が入力しやすい文字列が選ばれることもあります。導入時の作業を簡単にするためDomain Adminsなどの特権グループへ入れられ、見直されていない例も珍しくありません。

解析された場合の影響は、そのアカウントが持つ権限の広さで決まります。MITRE ATT&CKのM1026は、サービスアカウントの権限を必要最小限にとどめ、Domain Adminsのような特権グループへの所属を避けるよう求めています。SPNが付いたアカウントを減らすことは、狙える的そのものを減らす作業にあたります。

イベントID 4769から兆候を読み取る#

Kerberoastingの痕跡は、イベントID 4769(A Kerberos service ticket was requested)から読み取ります。このイベントはドメインコントローラー上でのみ記録され、監査サブカテゴリAudit Kerberos Service Ticket Operationsの成功監査が有効で、攻撃者がKDCへ新たなTGS要求を送った場合に、4769へ要求の記録が残ります。MITRE ATT&CKはネットワーク上のトラフィックから取得済みのサービスチケットを解析する場合があるとも説明しており、すでに手元にあるチケットをオフラインで解析するだけの場合は新たな要求が発生しないため、4769だけでは検知できません。

見るべきフィールドは、要求元のAccount NameとClient Address、Service Name、Ticket Encryption Typeです。Ticket Encryption Typeは発行されたサービスチケットに使われた暗号スイートを示し、0x17がRC4-HMAC、0x11がAES128-CTS-HMAC-SHA1-96、0x12がAES256-CTS-HMAC-SHA1-96に対応します。

Service Nameの読み方には注意が要ります。Microsoft Learnの定義では、Service Nameはサービスチケットの対象となったアカウントまたはコンピューターの名前であり、要求された完全なSPN文字列そのものとは限りません。1つのアカウントに複数のSPNが登録されていても、Service Nameだけではどのサービスが要求されたのかを区別できないため、この値をSPN単位の識別子として扱うと集計を読み違えます。

Microsoft Learnは、Windows VistaとWindows Server 2008以降ではTicket Encryption Typeの0x11と0x12を期待値とし、それ以外の値を監視するよう推奨しています。失敗コード0x20はチケットの有効期限切れを意味する情報レベルの記録だと説明しています。

記録されるイベントの版はOSと適用済みの更新プログラムによって異なります。Microsoft Learnによれば、Windows Server 2016以降では2025年1月14日以降のセキュリティ累積更新を適用すると更新版のイベント4769が記録され、ServiceSupportedEncryptionTypesやServiceAvailableKeys、DCSupportedEncryptionTypes、DCAvailableKeys、ClientAdvertizedEncryptionTypes、SessionKeyEncryptionType、RequestTicketHash、ResponseTicketHashといったフィールドが加わります。

追加フィールドは、RC4の要因を切り分けるときに効きます。Ticket Encryption Typeが0x17だったという事実だけでは、クライアントがAESを提示しなかったのか、対象アカウントにAESの鍵が無いのか、そのアカウントでRC4が明示的に許可されているのかを切り分けられません。更新版であれば、対象アカウントが対応する暗号化タイプ(ServiceSupportedEncryptionTypes)と実際に保持している鍵(ServiceAvailableKeys)、クライアントが提示した暗号化タイプ(ClientAdvertizedEncryptionTypes)、セッションキーに使われた暗号スイート(SessionKeyEncryptionType)を併せて見ることで、どこがRC4の要因なのかを判別できます。SessionKeyEncryptionTypeはセッションキーの暗号スイートであり、チケット本体のTicket Encryption Typeとは別のフィールドです。自組織のドメインコントローラーでどちらの版が出ているかを先に確かめてから、検知ルールのフィールド設計へ進んでください。

検知は、単発のイベントではなくアカウント単位で集約し、平常時との差を見る形になります。1つのアカウントが短時間に多数の異なる対象アカウントへサービスチケットを要求している、業務と関係のないサービスのチケットが要求されている、AESが使える環境なのにRC4のチケットが発行され続けている、といった偏りが手がかりです。イベント4769は正常運用でも大量に出るため、SIEMなどで集約して基準線を持たない限り目視での発見は現実的ではありません。RC4の利用状況そのものは、Microsoftがオープンソースで公開しているPowerShellスクリプト(List-AccountKeys.ps1とGet-KerbEncryptionUsage.ps1)でイベント4768と4769から集計できます。攻撃検知ではありませんが、AES化の進捗を測る材料になります。

対策の進め方#

影響範囲の小さいものから順に積み上げます。

gMSAは、パスワード管理をWindowsに任せる仕組みです。Microsoftの資料によれば、gMSAのパスワードは240バイトのランダム生成で、OSが30日ごとに変更します。人が決めた文字列ではなくなるため、長くランダムな資格情報の生成と定期変更をシステム側に任せられます。AESへの移行と併せて適用すると、多層的な防御になります。

dMSAはWindows Server 2025で導入されたアカウント種別で、従来のサービスアカウントから、管理された完全にランダムな鍵を持つマシンアカウントへ移行しつつ元のパスワードを無効化します。認証がデバイスIDに結び付けられ、Active Directory上で対応付けられたマシンIDだけがアカウントを利用できます。Microsoft Learnは、dMSAが侵害されたアカウントによる資格情報の収集(Kerberoasting)の防止に役立つと記載しています。

暗号化タイプの現行ガイダンス#

暗号化タイプの既定値は動いている最中です。整理するときは、サービスチケット本体の暗号化タイプ、チケット内のセッションキーの暗号化タイプ、アカウントのmsDS-SupportedEncryptionTypesに明示設定された値、明示設定が無いときにKDCが仮定する既定値の4つを分けて考えると混乱しません。

CVE-2022-37966への対応であるKB5021131が2022年11月に変更したのは、暗号化タイプが明示設定されていないアカウントについて、チケットのセッションキーに使う暗号化タイプでした。当時のDefaultDomainSupportedEncTypesの既定値は0x27でRC4を含んでおり、サービスチケット本体のRC4利用がこの時点で既定として縮小されたわけではありません。

CVE-2026-20833に関連する変更はKB5073381にまとまっています。2026年1月13日以降の更新では監査フェーズが始まり、イベントID 201から209の警告イベントが記録されます。この更新を適用しただけでは、ドメインコントローラーについてCVE-2026-20833が既定で対処されるわけではなく、レジストリ値RC4DefaultDisablementPhaseを2に設定することで管理者が手動で強制モードを先行して有効にできます。2026年4月14日の更新で強制フェーズに入り、明示的な構成が指定されていない場合にKDCが仮定する既定値が0x18(AES-SHA1のみ)になります。2026年7月以降の更新ではRC4DefaultDisablementPhaseのサポートが削除され、強制が必須になります。

これはRC4の全面的な無効化ではありません。KB5073381は、2026年4月以降もRC4を利用する必要がある場合は、RC4を受け付ける必要のあるサービスのmsDS-SupportedEncryptionTypesビットマスクへ明示的にRC4を設定するよう案内しており、明示設定は引き続き尊重されます。変わるのは、何も設定されていないアカウントに対してKDCが何を仮定するかという既定値です。なおWindows Server 2025のドメインコントローラーはRC4のTGTを発行しません。

Microsoft Learnは、KerberosのRC4既定暗号化タイプがKerberoastingに悪用され得ること、既定をAES-SHA1へ変更することが保護に役立つことを説明しています。あわせて、RC4の利用状況の監査にイベントID 4768と4769を用いる方法と、グループポリシーやレジストリ値DefaultDomainSupportedEncTypesでRC4を制限する手順を示しています。

先に確認したいのは、AES-SHA1に対応していない機器やアプリケーションが残っていないかという点です。RC4しか扱えないアカウントが明示設定の無いまま残っている状態で既定値が変わると認証に失敗するおそれがあるため、監査イベントで洗い出し、残す必要があるものだけ明示設定してから制限へ進む順序が扱いやすくなります。許可する暗号化タイプはグループポリシーで制御します。

運用に組み込むためのチェックリスト#

まとめ#

Kerberoastingは仕様どおりの動きを利用するため、修正プログラムを当てて終わりにできる問題ではありません。サービスチケットがパスワード由来の鍵で暗号化される限り、チケットを入手できる相手にはオフライン解析の余地が残ります。対策は、現実的なオフライン推測が困難な、管理された高エントロピーの鍵にすること(gMSAやdMSAへの移行)、解析コストを引き上げること(AESへの移行)、被害範囲を狭めること(SPNの棚卸しと権限の縮小)、兆候に気づくこと(イベント4769の監視)を並行して進める形になります。JPCERT/CCもActive Directoryに対する攻撃の検知と対策やWindowsイベントログ分析のトレーニング資料を公開しており、自組織のログでどこまで追えるかを試す出発点になります。