ユーザーアカウントとサービスアカウントのクレデンシャルが盗まれたため、攻撃者は安全なサービスデスクがなくても、インフラストラクチャをすばやく乗っ取ってデータを盗み出すことが容易になります。 強力なパスワード慣行と組み合わせた強力なユーザーフィッシング攻撃防止は、組織を保護するために不可欠です。
この記事では、盗まれたユーザーアカウントがKerberoasting攻撃でどのように使用されるかを示します。 Kerberoastingは、サービスアカウントのパスワードハッシュを取得する方法であり、クラックされて横方向の攻撃に使用されることを目的としています。
この投稿は親切に後援されています Specopsソフトウェア。
Kerberoastingのインとアウト
実際の攻撃に飛び込む前に、まず、Kerberoasting攻撃がどのように機能するかを理解することが役立ちます。 Active Directory（AD）は、クライアントとサーバーの両方の相互認証にKerberosプロトコルを利用します。 ユーザーまたはサービスアカウントのパスワードを繰り返し要求されないようにするために、認証メカニズムはサービスチケットを介して実装されます。
最初の認証要求が行われると、キー配布センター（KDC）は、正常に認証されたクライアントにチケット許可チケット（TGT）を発行します。 このTGTを使用すると、アカウントのパスワードを要求することなく、Ticket Granting Service（TGS）に対する将来の認証要求が可能になります。
これは使いやすさには優れていますが、結果として得られるメモリ内TGSチケットは、RC4_HMAC_MD5とNTLMハッシュで暗号化されます。 結果のハッシュ値は、パスワードが十分に複雑でない場合、ブルートフォースされ、クラックされる可能性があります。 さらに、認証されたドメインアカウントは、サービスプリンシパル名（SPN）を持つサービスアカウントのTGSチケットを要求できるため、安全性の低いハッシュを取得して、その後のクラッキングに使用できる可能性があります。
Kerberoasting攻撃の解剖学
Active Directory Kerberos認証がどのように機能するかを理解したところで、サービスアカウントのTGSチケットを要求するにはどうすればよいでしょうか。 実際のチケットを取得する前に、ターゲットアカウントのSPNを知る必要があります。 SPNは、HTTP（IISで一般的）などのサービスと、オプションのポートを備えたホスト名で構成されます。 例としては HTTP/client.domain.local。
しかし、待ってください、すべてのサービスアカウントにSPNがありますか？ デフォルトでは、IISなどのサービスに割り当てられていない限り、アカウントにはSPNがありません。 Kerberos認証を使用するサービスアカウントにはSPNが必要です。
この例では、IISの特定のアプリケーションプールがアカウントで実行されています domain.localIISAppPool01、以下のコマンドでSPNを設定します。
setspn -S HTTP/WIN10CLIENT.domain.local domain.localIISAppPool01
Active Directoryで、SPNが割り当てられているすべてのアカウントを検出するには、次のPowerShellコードを使用できます。 このコードは、ドメインアカウントをすばやく返します。 ServicePrincipalName を使用して設定された値 ActiveDirectory モジュールコマンド、 Get-ADUser。
Import-Module -Name 'ActiveDirectory'
Get-ADUser -Filter { ServicePrincipalName -Like "*" } -Properties ServicePrincipalName | Select-Object SamAccountName, ServicePrincipalName
The
krbtgtアカウントはTGSサービスアカウントです。 このアカウントが侵害された場合、これはゴールデンチケット攻撃につながる可能性があり、ADアカウントにチケットを付与することができます。
この攻撃では、私は IISAppPool01 アカウント。 多くの場合、サービスアカウントには非常に多くの特権があるか、アプリケーション間で再利用される可能性があります。 名前にもかかわらず、 IISAppPool01、これは複数のアプリケーションプールを制御する可能性があるため、それらのリソースにアクセスできます。
ターゲットアカウントが手元にあるので、パスワードクラッキングツールであるHashcatが利用できる形式でハッシュを取得してエクスポートする必要があります。 Mimikatzはハッシュを取得することもできますが、ネイティブに正しい形式で出力されません。 追加の手順を回避するために、 Invoke-Kerberoast 働き 以下に示すように、PowerShellの悪用後ツールキットのEmpireが使用されます。
.Invoke-Kerberoast.ps1
Invoke-Kerberoast -OutputFormat hashcat | Select-Object SamAccountName, ServicePrincipalName
Invoke-Kerberoast -OutputFormat hashcat | ForEach-Object { $PSItem.Hash } | Out-File -Encoding ASCII hash.txt
これはWindowsPowerShellで実行する必要があり、PowerShell7はこのコードを実行できません。 舞台裏では、これはTGSにチケットを要求するために次のコードを実行し、次のコードに示すようにWindowsPowerShellでのみ実行されます。
Add-Type -AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList 'HTTP/internaltools.site'
パスワードハッシュを正しい形式で保存すると、Hashcatはパスワードの解読に取り掛かることができます。 次の形式を使用する 13100、「Kerberos 5、etype 23、TGS-REP」、Hashcatは安全でないパスワードをすばやく処理します。 これは、以下に示すように、大規模なパスフレーズリスト（2,000万を超える既知のパスワードハッシュ）と組み合わせると特に当てはまります。
.hashcat.exe -m 13100 -O ..hash.txt passphrases.txt
カーベロアスト攻撃の検出と防止
攻撃者が侵害されたアカウントを介してネットワークに侵入した場合、攻撃者の調査と最終的には攻撃自体を検出できる必要があります。 以下のセクションでは、サービスアカウントのパスワードが解読されるのを防ぎ、最も重要なこととして、ユーザーアカウントが最初から侵害されるのを防ぐために実行できる手順を示します。
疑わしいアクティビティの検出
ネットワーク上でKerberoastingアクティビティが発生しているかどうかをどのようにして知ることができますか？ 1つの方法は、Kerberosサービスチケット要求監視グループポリシー設定「Kerberos認証サービスの監査」をオンにすることです。 このポリシーは、ドメインコントローラの 高度な監査ポリシー構成 グループポリシーオブジェクト（GPO）のセクション。
有効にすると、監査ログはKerberosサービスチケット要求でいっぱいになります。 ドメインコントローラでは、これは非常にノイズが多く、不要なエントリを除外する必要があります。 ログに含まれるノイズの量を減らすのに役立つ可能性のあるいくつかの一般的なルールを以下に示します。
- 監査失敗要求を除外し、監査成功のみを探します。
- ユーザーアカウントが侵害される可能性が高いため、既知のサービスアカウントを除外します。
- コンピューターアカウントとgMSA（グループマネージドサービスアカウント）は、プレフィックスが付いたアカウントを使用します
$、ほとんどの場合、侵害されないため、これらのアカウントは除外される可能性があります。
チケットを要求している疑わしいアカウントと、監査ログで過剰な4769イベントIDを探しています。
それでも誤検知が発生する可能性がありますが、悪意のあるアクティビティがどこから発生している可能性があるかを調査し始めることができます。 クライアントおよびサーバーシステムでWindowsPowerShellロギングを有効にすると、悪意のある可能性のあるコマンドを探すことができます。
PowerShell7ログも有効にする必要があることを忘れないでください。 これは、コマンドを介して実行できます cd "C:Program FilesPowerShell7"; .InstallPSCorePolicyDefinitions.ps1。 関連するグループポリシーは コンピューター管理用テンプレート 下 PowerShellコア セクション。 Windows PowerShellの場合、関連するグループポリシー設定は アプリケーション設定WindowsPowerShell セクション。
監査を有効にすると、一般的なスクリプトブロック攻撃パターンは次のようになります。 ServicePrincipalName -Like "*"、で使用されます Get-ADUser SPNを含むすべてのサービスアカウントを検索するコマンド。 PowerShellのもう1つの指標は、 KerberosRequestorSecurityToken メソッド。後でクラックされる可能性のあるメモリ内ストレージのKerberosチケットを要求するために使用されます。
カーベロアストとクレデンシャルの盗難の防止
ユーザーアカウントが侵害された場合でも、サービスアカウントSPNのアクティブなスキャンが発生し、パスワードハッシュの最終的な取得により、すべてが失われることを意味しますか？ 安全なサービスデスクを用意するだけでなく、実際のサービスアカウントが乗っ取られるのを防ぐための手順がいくつかあります。
残念ながら、サービスアカウントは忘れられがちで、パスワードが再利用され、特権が本来あるべきよりも広くなっています。 したがって、以下が攻撃の露出と有効性を制限するのに大いに役立つことは驚くべきことではありません。
- 25文字以上の長いパスワードを使用してサービスアカウントをプロビジョニングすると、ブルートフォースだけでクラックすることはほぼ不可能になります。
- 一般的な単語を使用した辞書攻撃を回避するために、さまざまな特殊文字を含むランダムで複雑なパスワードを利用します。
- サービスアカウントのパスワードを頻繁にローテーションします。 サービスアカウントのパスワードを定期的に変更するポリシーが必要です。 gMSAアカウントは30日ごとにパスワードを変更します。これは理想的ですが、すべてのサービスアカウントを停止せずに定期的に変更できるわけではありません。 それでも、すべてのアカウントをローテーションする計画を考慮に入れる必要があります。
- サービスアカウントの権限を、必要最小限のものに制限します。 たとえば、システムの管理者権限の代わりに、サービスアカウントが特定のディレクトリにアクセスするだけでよい場合があります。
- 複数のサービスにサービスアカウントを使用することは避けてください。 これにより、スコープとアクセスクリープが防止されるだけでなく、攻撃対象領域の増加も防止されます。
上記は、パスワードハッシュが取得された場合のサービスアカウントの保護をカバーしている可能性がありますが、そもそもアカウントの乗っ取りを防ぐのはどうでしょうか。 これを回避するには、フィッシングやソーシャルエンジニアリングによってアカウントが盗まれるのを防ぐことが最初に重要です。
パスワードリセットの正当な要求が何であるか、または電子メールが有効であるかどうかをユーザーが知るのは難しい場合があります。 フィッシングメールの一般的な兆候を探すようにユーザーをトレーニングし、メールシステムに制御とスパム管理を実装し、ソーシャルエンジニアリング攻撃についてユーザーに教えることはすべて、そもそもアカウントの乗っ取りを防ぐための重要なステップです。 安全なサービスデスクがどのようにあなたに利益をもたらすことができるかについてもっと学びましょう。
Specops SecureServiceDeskで侵害されたアカウントを回避する
アカウントを乗っ取る最も速い方法の1つは、不正なパスワードのリセットを使用することです。 攻撃者がパスワードのリセットを誤った、または悪意のある要求をするのを防ぐにはどうすればよいですか？
組織がユーザーを確認するために使用できる方法はたくさんあります。 これらの多要素認証メカニズムをヘルプデスクに組み込むことで、連絡先の個々の人が本人であることを確認できます。
Specopsセキュアサービスデスク これは、ヘルプデスクが連絡先の個人を迅速かつ安全に確認できるようにするための優れた方法です。 発信者が自分が誰であるかを確認する必要があるポリシーを設定できます。 多種多様な方法。 方法の網羅的ではないリストを以下に示しますが、よりユニークな製品のいくつかを強調してください！
- Specopsの指紋
- 秘密の質問
- 信頼できるネットワークの場所
- マネージャーの識別
- デュオセキュリティ
- オクタ
- フェイスブック
- グーグル
以下に示すように、インターフェイスはどの従業員にとっても使いやすいものです。 1つの場所で、複数の方法でユーザーを確認し、ユーザーの詳細を検索し、最終的には一般的なアクションを実行して、ユーザーをすばやく移動させることができます。
すべての検証方法は、詳細なレポート機能によって十分に補完されています。 たとえば、誰が登録されていないか、パスワードがリセットされた回数、誰がパスワードをリセットしたか、確認済みのユーザーに対してそれらのパスワードのリセットが行われたかどうかを確認します。
結論
私が示したように、Kerberoastingは依然として有効な攻撃であり、監査と監視を介して説明する必要があります。 攻撃者がインフラストラクチャを分解し始めるために必要なのは、1つの侵害された管理者以外のユーザーアカウントだけです。
長くて複雑で頻繁にローテーションされるサービスアカウントのパスワードを使用することから、潜在的な攻撃者の活動に関する詳細なログ記録とレポート作成まで、潜在的な問題を軽減する方法はたくさんあります。 しかし、そもそも侵害されたユーザーアカウントを回避することが、問題を完全に回避するための最良の方法であり、 Specopsセキュアサービスデスク それを実現するのに大いに役立ちます。
階層化できる多数の認証方法により、ヘルプデスクワーカーは、発信者が本人であることを安全に確認し、必要な支援を迅速に受けることができます。 インフラストラクチャとプロセスが安全であることを確認するために、今日次のステップを実行してください。
The post 安全なサービスデスクでKerberoasting攻撃を回避する appeared first on Gamingsym Japan.