AS-REP Roasting 攻撃—仕組みと防御戦略

AS-REP Roasting とは？

Kerberos は通常、事前認証（pre-authentication）を要求します。つまり、KDC が Ticket Granting Ticket（TGT）を発行する前に、クライアントは Key Distribution Center（KDC）に対して自分の身元を証明する必要があります。アカウントが事前認証をスキップするように設定されている場合（「Do not require Kerberos pre-authentication」設定）、攻撃者はそのアカウント宛てに AS-REQ を送信でき、KDC は、アカウントの長期鍵（パスワードから派生）で暗号化されたデータを含む AS-REP を返します。攻撃者はその暗号化されたデータを抽出し、それに対してオフラインでパスワードのクラックを実行します。パスワードが弱ければ攻撃者は復元でき、その後、そのアカウントとして認証できるようになります。この手法は AS-REP Roasting として知られています。

AS-REP Roasting はどのように機能しますか？

以下は、典型的な AS-REP Roasting 攻撃を段階ごとに分解した説明です。

1. 偵察 — 事前認証が無効になっているアカウントを探す

攻撃者はディレクトリのアカウントを列挙して、Kerberos の事前認証が無効になっているユーザーまたはサービスプリンシパル（"Do not require Kerberos pre-authentication"）を見つけます。これらはしばしばレガシーなサービスアカウント、コンピューターアカウント、または設定が誤っているユーザーアカウントです。列挙は、LDAP/AD のクエリや偵察ツールを使って実施されます。

2. 対象アカウントに対して AS-REP を要求する

発見した各アカウントについて、攻撃者はそのユーザー名のドメイン KDC に AS-REQ を送信します。事前認証（pre-authentication）が無効になっているため、KDC はアカウントのパスワードから導出されたキーで暗号化されたデータを含む AS-REP を返します。

3. 暗号化された blob を抽出する

攻撃者は AS-REP 応答の暗号化部分（暗号化されたタイムスタンプ、またはチケットの暗号化された部分）を抽出し、オフラインでのクラック用に整形します。

4. キーをオフラインでクラックする

攻撃者はオフラインのパスワード解読ツール（GPU による高速化や分散型の解読）を使用し、総当たり（brute force）、辞書、または特定の候補リストによってパスワードを復元しようとします。弱い、または固定（静的）されたパスワードは脆弱です。

5. 復元した認証情報を使って横方向への移動と永続化を行う

パスワードが復元されると、攻撃者はそのアカウントとして認証し、横方向へ移動してサービスにアクセスしたり、権限を昇格したりできます。サービスアカウントやマシンアカウントは多くの場合広い権限を持つため、被害の影響が大きくなります。

✱ バリエーション：マシン／サービスのプリンシパルと長期間有効なアカウントを狙う

AS-REP Roasting は、互換性のために事前認証（pre-authentication）なしで構成された非対話型アカウント（サービスのプリンシパル、コンピューターアカウント）を頻繁に狙います。これらのアカウントは多くの場合、長くて固定されたパスワードと幅広いアクセス権を持つため、高価値なターゲットになります。

攻撃フロー図

例：組織の観点

攻撃者は Contoso の AD をスキャンし、古いアプライアンスとの互換性のために「no pre-auth」としてマークされた複数のレガシーなバックアップサービスアカウントを見つけます。攻撃者はそれらのアカウントに対して AS-REPs を要求し、暗号化された応答を抽出したうえで、オフラインで弱いパスワードを解読します。回収した認証情報を使って、攻撃者はバックアップ共有やドメインのリソースにアクセスし、その後、設定ミスのあるグループメンバーシップを悪用してさらに権限を昇格させます。

例と現場で見られるパターン

AS-REP Roasting の影響

AS-REP Roasting は、侵害されたアカウントに特権アクセス権限や機密データへのアクセス権限がある場合、広範な影響をもたらす可能性があります。

経済的な影響

サービスアカウントが侵害されると、IP（知的財産）、顧客データ、または財務記録が盗まれ、罰金、是正（復旧）コスト、あるいは身代金の要求につながる可能性があります。

業務の中断

サービスの認証情報を使う攻撃者は、バックアップにアクセスしたり、スケジュールされたタスクを改ざんしたり、重要なサービスを妨害したりできます。その結果、停止（アウトেজ）や復旧コストにつながります。

風評被害

ドメイン侵害が公になった場合（特に顧客データや可用性に影響が出た場合）は、信頼を損ない、パートナーシップの障害となり得ます。

法的および規制上の影響

規制対象データが露出すると、GDPR、HIPAA、PCI、またはその他のコンプライアンス調査や罰金につながる可能性があります。

よく狙われる対象：誰がリスクにさらされるのか？

事前認証が無効になっているアカウント

レガシーのサービスアカウント、古いアプライアンス向けの互換アカウント

非対話型のサービスプリンシパル

固定パスワードと長寿命の認証情報

脆弱なパスワード、またはローテーションされていないパスワードを使用しているアカウント

解読（クラック）リスクが高い

アカウント運用（衛生状態）が不十分な大規模環境

レガシーシステムが多く、誤った設定がある

リスク評価

AS-REP Roastingを防ぐ方法

防止は概念的にはシンプルですが、一貫したアカウントの衛生管理と設定の制御が必要です。

Kerberos の事前認証を強制する

レガシー機能のためにどうしても必要な場合を除き、すべてのアカウントで Kerberos の事前認証を有効にしてください。事前認証をスキップするように設定されたアカウントは最小限にし、その理由を明確にします。

アカウントのパスワードとライフサイクルを強化する

サービスアカウントおよびマシンアカウントには、長くランダムに生成されたパスワードを使用し、定期的にパスワードをローテーションしてください（可能であれば gMSA）。また、秘密情報をプレーンテキストで保存することは避けます。

レガシーパターンを置き換える

レガシーアプリケーションを、最新の認証に対応できるように移行するか、アクセスを制限し、頻繁にローテーションする専用で隔離されたサービスアカウントを使用してください。適用可能な場合は Kerberos constrained delegation（制約付き委任）を優先してください。

最小権限とセグメンテーションを適用する

サービスアカウントの権限を制限し、ネットワークのセグメンテーションによってレガシーシステムを隔離する。

MFA と条件付きアクセスを使用する

対話型の管理者ワークフローでは MFA と条件付きアクセスを必須にしてください。AS-REP は非対話型アカウントを対象とするため、MFA はすべてのケースに対する直接的な軽減策というより、深層防御の一部です。

Netwrix が AS-REP Roasting への防御に役立つ方法

Netwrix Identity Threat Detection & Response (ITDR) は、AS-REP Roasting に対して脆弱なものを含むリスクのあるアカウント設定を、Active Directory と Microsoft Entra ID で継続的に監視することで防御を強化します。疑わしい Kerberos アクティビティ、LDAP 認識（reconnaissance）、または異常な認証試行に関するリアルタイム アラートにより、ITDR は攻撃者がサービス アカウントの資格情報を解読する前にセキュリティ チームが行動できるようにします。先回りの検知と自動化されたレスポンス ワークフローを組み合わせることで、Netwrix は組織が横方向への移動機会を最小限に抑え、攻撃者が悪用するアイデンティティ上のギャップを埋めるのに役立ちます。

検知、軽減、対応の戦略

検知

• AD クエリと LDAP 列挙を監視し、アカウントのフラグを列挙する、または pre-auth（事前認証）で無効になっている属性を問い合わせるスキャンを検知します。
• 通常は異常な送信元から要求されるべきでないアカウントについて、AS-REQ／AS-REP のやり取りが過剰になっている場合はログを記録し、アラートを出します。
• pre-auth（事前認証）が無効になっているアカウントを棚卸しし、予期しない変更をフラグ付けします。基準値（ベースライン）を維持してください。
• ハニーポット／ハニーアカウント：デコイとなる no-preauth アカウントを作成し、AS-REP リクエストを監視します。
• クラック（解読）後にクレデンシャルが使用されている兆候を確認します。例：不審なログイン、リソースへのアクセス、または lateral auth のパターン。

対応

1. 疑わしい AS-REP の活動を検出した場合は、直ちに露出したアカウントのパスワードをローテーションするか無効化してください。
2. 事前認証（pre-authentication）を有効にし、パスワードをローテーションし、可能な場合はマネージド ID に置き換えてください。
3. 回収された認証情報（credential）が使用されている兆候を確認するために認証情報ハントを実施し、スコープ／影響の評価を行ってください。
4. 攻撃者のインフラが特定でき、かつ実行可能であれば、ネットワークレベルでブロックしてください。

緩和

• 可能であれば、事前認証（pre-auth）が不要なアカウントを排除するか、分離して強化してください。
• LDAP 列挙、AS-REQ の急増、そして誘導（デコイ）アカウントに対する AS-REP ヒットについて、自動検知（SIEM ルール）を導入してください。
• CI/CD にシークレットスキャンを統合し、誤って資格情報（credentials）が漏えいするのを防ぎます。

業界別の影響

攻撃の進化と今後のトレンド

• GPU の高速化とクラウドでのクラックにより、オフラインのパスワード復旧がより速く、より低コストになっています。
• 自動化された偵察では、AD の列挙と AS-REP リクエストをマルチステージのキャンペーンに統合します。
• マネージド ID への移行は、実装済みの領域での露出を減らすため、攻撃者はレガシー／高価値のターゲットへと向かいます。
• AI を使ってクラックの優先順位を決める——攻撃者は機械学習（ML）を適用して、最有力の候補パスワードを選ぶことがあります。

主要な統計とインフォグラフィック（推奨されるテレメトリ）

• 環境内で事前認証（pre-authentication）が無効になっているアカウントの割合。
• サービスアカウントの平均パスワード有効期間。
• (リスクモデリングのために) 利用可能なクラック用ハードウェアで一般的なパスワードのクラスを解読するまでの時間。

最終的な考察

AS-REP Roasting は効果的で低ノイズな手法であり、設定の隙や弱い認証情報（credential hygiene）を狙い撃ちします。事前認証（pre-auth）を無効化しているアカウントの排除、managed secrets の強制適用、そして Kerberos/AD の列挙（enumeration）を監視することが、最も効果的な防御策です。

よくある質問（FAQs）