Pass-the-Ticket 攻撃を検出する方法

最初の投稿では 、 pass-the-hash 攻撃を検知する方法を見てきました。これは Active Directory ドメイン内の NTLM 認証 を悪用する攻撃です。Pass-the-ticket は関連する攻撃で、Kerberos 認証を利用して横方向への移動を行います。

この投稿では、pass-the-ticket 攻撃がどのように機能するのか、そしてそれを検出するために何ができるのかを詳しく解説します。

Pass-the-Ticket（チケット渡し）が機能する仕組み

パス・ザ・チケット（pass-the-ticket）攻撃では、攻撃者があるシステム上の LSASS メモリから Kerberos のチケット授与チケット（TGT）を抽出し、その有効なチケットを別のシステムで使用して、Kerberos のサービスチケット（TGS）を要求することで、ネットワーク リソースへのアクセスを取得します。

主な違いは、pass-the-hash と pass-the-ticket のどちらかという点です。Kerberos の TGT チケットは期限切れになります（デフォルトで 10 時間）。一方、NTLM ハッシュはユーザーがパスワードを変更したときにだけ変わります。そのため、TGT チケットは有効期限内に使用する必要があります。あるいは、より長い期間（7 日間）で更新（更新延長）することもできます。

Mimikatz は pass-the-ticket を実行するのに使用できますが、この投稿では、別のツールRubeus を使って攻撃を実行する方法を紹介したいと思いました。Rubeus は Kerberos ベースの攻撃を実行できるツールです。Kekeo は harmj0y プロジェクトに基づいています。

ステップ 1。TGT を抽出します。

Rubeus で pass-the-ticket 攻撃を実行するには、最初に TGT を取得する必要があります。セキュリティ設定によっては、ユーザーがログオフした後にシステムへ TGT と NTLM ハッシュが保存される場合もあれば、保存されない場合もあります。Rubeus の面白くも怖い機能の 1 つが Monitor です。これは 4624 のログオン イベントを探し、システム上で新しく発生したログオン セッションごとに TGT データをダンプします。

以下のコマンドを使用すると、Rubeus は 30 秒ごとにログオン セッションの監視を開始します:

Rubeus.exe monitor /interval:30

そして、このシステムに誰かがログオンした場合、そのユーザーの TGT を取得します。これをシミュレートするために、ユーザーとして次のコマンドを実行します:

Runas /user:[domainusername] cmd.exe

30 秒以内に、Rubeus はこの logon を検出し、このユーザーの TGT を取得して、base64 でエンコードされた文字列として出力します:

この文字列をテキストエディターにコピーし、改行とスペースを削除できます。

ステップ 2：チケットを受け渡します（Pass the ticket）。

チケットを盗んだので、失効する前に使いましょう。そのために引き続き Rubeus を使用しますが、今回は ptt コマンドを使います:

Rubeus.exe ptt /ticket:[ここに base64 文字列を入力]

侵害されたユーザーの TGT がセッションに読み込まれていることが分かります。これを使って TGS サービスチケットを要求し、このユーザーとしてネットワーク リソースにアクセスできるようになります。

検知

pass-the-ticket は、エンドポイントまたはドメイン コントローラーで検知できます。

エンドポイントで Pass-the-Ticket を検知する

pass-the-ticket の検知を調査していたところ、非常に興味深い、Javelin Networks の研究者 Eyal Neemany によって投稿されたアプローチに出会いました。その内容では、pass-the-ticket のアクティビティを調査したい場合は、環境内の任意のエンドポイントで次の手順を実行できるとしています：

1. そのシステム上の現在のログオンセッションを確認してください。
2. klist コマンドを使用して、セッションに関連付けられている Kerberos チケットを確認してください。
3. セッションに関連付けられているユーザーと一致しない Kerberos チケットを探してください。これは、それらがメモリに注入されており、パス・ザ・チケット（pass-the-ticket）攻撃が進行している可能性を意味します。

これらの手順をもう少し詳しく見ていきましょう。

ステップ 1。すべてのログオン セッションを出力するには、GitHub の Get-LoggedOnUsers 関数を元にして調整したこのスクリプトを使用できます:

              $regexa = '.+Domain="(.+)",Name="(.+)"
      

ステップ 2。 ここで klist –li コマンドを使用し、セッション ID を渡して、そのセッションに関連付けられたチケットを確認できます。

ステップ 3。 ユーザー Michael のセッションを調査しましたが、ユーザー Gene の Kerberos TGT が確認できました。Pass-the-ticket を検出しました！

この方法はテスト環境で誤検知なしに確実に機能しましたが、pass-the-ticket 以外の活動によってこのような挙動が引き起こされる可能性がある手段を知っている場合は、コメントを残してください。

ドメインコントローラーで Pass-the-Ticket を検出する

ドメインコントローラーで pass-the-ticket の挙動を探す方法もあります。以前の方法ほど信頼性が高くないかもしれませんが、DC のログから得られる検知があると常に安心です。

正当な Kerberos 認証のためのイベント ログ

何を確認すべきかを理解するために、ネットワーク上で通常の Kerberos 認証が行われた場合に表示されるイベント ログを見ていきましょう。

4768 – Kerberos 認証チケット（TGT）が要求されました

最初に確認すべきイベントは 4768 イベントです。これは TGT（チケット）要求であり、ユーザーが Kerberos を使ってネットワーク リソースにアクセスするために、最初に必ず起こる必要があることです。あなたのドメインにアクセスする各エンドポイントごとに、各ユーザーについてこの種のイベントが1件発生します。ユーザー アカウントが別々の2台のワークステーションからログインする場合、それぞれのワークステーションから TGT を要求します。

このイベントで最も関連性の高い情報は、TGT を要求したユーザーと、その要求元のコンピューターです。:

4769 – Kerberos のサービスチケットが要求されました

Kerberos 認証の次の手順は、ユーザーがその TGT を使用し、コンピューター上のサービス（たとえばファイル共有にアクセスするための CIFS）に接続するために TGS のサービスチケットを要求することです。これもイベント 4769 のログに表示され、チケットを要求したユーザーと送信元のコンピューターが示されます:

4770 – Kerberos のサービスチケットが更新されました

TGT の更新を行うと、イベント 4770 が生成されます。デフォルトでは、TGT は 7 日間更新できます。これをテストしたい場合は、Rubeus に抽出済みの TGT を更新するコマンド「renew」があります。更新したユーザーや更新元も確認できます:

Pass-the-Ticket 攻撃を示すイベントを見つける

では、pass-the-ticket の動作があるとき、イベントログでは何がどう違うのでしょうか？注目すべきポイントは何でしょうか。一般的には、攻撃者が TGT を収集して別のシステムでそれを使用するため、特定の Account/Client の組み合わせを使った TGS 要求や TGT 更新があるにもかかわらず、その Account/Client の組み合わせからの関連する TGT 要求が存在しないケースを探せます。TGS 要求または TGT 更新を確認したうえで、直近の 10 時間をさかのぼり、そのユーザーとコンピューターに一致する TGT 要求があったかどうかを調べる必要があります。pass-the-ticket では攻撃者は TGT を要求することは決してなく、常に LSASS からそれを盗み取るためです。攻撃者はそれを更新することがあるかもしれませんし、そして確実にそれを使って TGS のサービスチケットを要求する可能性があります。

そして、この検出は単なるイベントログのフィルタリングを超えるものであり、規模をもって実施するにはおそらく SIEM やサードパーティ製品が必要になるでしょう。これを検知する方法を探しているなら、Netwrix Threat Manager を確認して、このほか Golden Ticket、 Pass the Hash、 Kerberoasting のような Active Directory 攻撃にも、どのように役立てられるかを見てください。

              $regexd = '.+LogonId="(d+)"
      

ステップ 2。 次に klist –li コマンドを使用し、セッション ID を渡して、そのセッションに関連付けられたチケットを確認します。

ステップ 3。ユーザー Michael のセッションを確認しましたが、ユーザー Gene の Kerberos TGT が表示されました。Pass-the-ticket を検知しました！

この方法はテスト ラボで誤検知なしに確実に機能しましたが、pass-the-ticket 以外の活動によってこの動作が引き起こされる可能性がある方法をご存じでしたら、コメントを残してください。

ドメイン コントローラーで Pass-the-Ticket を検出する

ドメイン コントローラーで pass-the-ticket の振る舞いを探す方法もあります。これはそれほど信頼性が高くない可能性がありますが、DC のログから得られる検出手段があると常に役に立ちます。

正当な Kerberos 認証のイベント ログ

何を確認すべきかを理解するために、ネットワーク上で通常の Kerberos 認証が行われたときに見られるイベント ログを確認してみましょう。

4768 – Kerberos 認証チケット（TGT）が要求されました

最初に確認すべきイベントは 4768 イベントです。これは TGT の要求であり、ユーザーが Kerberos を使ってネットワーク リソースにアクセスするために、最初に必ず発生しなければならない処理です。ドメインにアクセスする各エンドポイントごとに、ユーザーごとにこのイベントが 1 件ずつ表示されます。ユーザー アカウントが 2 台の別々のワークステーションからログインする場合、それぞれのワークステーションから TGT を要求します。

このイベントで最も重要な情報は、TGT を要求したユーザーと、要求元となったコンピューターです。:

4769 – Kerberos サービス チケットが要求されました

Kerberos 認証の次のステップは、ユーザーがその TGT を使用して、コンピューター上のサービス（たとえばファイル共有にアクセスするための CIFS）に接続するための TGS サービス チケットを要求することです。 これはイベント 4769 のログにも表示され、チケットを要求したユーザーと送信元のコンピューターが示されます:

4770 – Kerberos のサービス チケットが更新されました

TGT を更新するとイベントが生成されます 4770。 既定では、TGT は 7 日間更新できます。 これをテストしたい場合は、Rubeus に「renew」というコマンドがあり、抽出した TGT を更新できます。 また、更新したユーザーや更新元も確認できます：

Pass-the-Ticket 攻撃を示すイベントの見つけ方

では、pass-the-ticket の活動がある場合、イベント ログでは何が違うのでしょうか。何に注目すべきでしょうか？ おそらく攻撃者は TGT を収集してから別のシステムで利用するため、特定の Account/Client の組み合わせで TGS リクエストや TGT 更新が行われているのに、その Account/Client の組み合わせに紐づく TGT リクエストが存在しないケースを探せます。 TGS リクエストまたは TGT 更新を確認したうえで、直近 10 時間前までさかのぼり、そのユーザーとコンピューターに一致する TGT リクエストがあったかどうかを確認する必要があります。 pass-the-ticket では、攻撃者は TGT を決して要求しません。常に LSASS から盗みます。 それを更新する場合もあり、さらに確実に TGS のサービス チケットを要求する際に使用します。

なお、この検知はイベント ログのフィルタリングを超えた内容であり、大規模に実施するにはおそらく SIEM やサードパーティ製品が必要になります。 これを検知する方法を探しているなら、Netwrix Threat Manager をチェックし、Golden Ticket、 Pass the Hash、 Kerberoasting などの他の Active Directory 攻撃にもどのように役立つかをご覧ください。

              $logon_users = @(Get-WmiObject win32_loggedonuser -ComputerName 'localhost')

        $session_user = @{}
        $logon_users |% {
            $_.antecedent -match $regexa > $nul
            $username = $matches[1] + "" + $matches[2]
            $_.dependent -match $regexd > $nul
            $session = $matches[1]
            $sessionHex = ('0x{0:X}' -f [int]$session)
            $session_user[$sessionHex] += $username
               
        }
        $session_user
      

ステップ 2。 これで klist –li コマンドを使い、セッション ID を渡して、そのセッションに関連付けられているチケットを確認できます。

ステップ 3。 ユーザー Michael のセッションを確認しましたが、ユーザー Gene の Kerberos TGT が表示されています。Pass-the-ticket を検出しました！

この方法はテスト環境で誤検知なしに確実に動作しましたが、pass-the-ticket 以外の活動によってこの動作が引き起こされる可能性がある手段をご存じであれば、コメントを残してください。

ドメイン コントローラーで Pass-the-Ticket を検出する

ドメイン コントローラーで pass-the-ticket の挙動を探す方法もあります。こちらはそれほど信頼できないかもしれませんが、DC のログから得られる検出手段を用意しておくのは常に良いことです。

正当な Kerberos 認証のためのイベント ログ

何を確認すべきかを理解するために、ネットワーク上で通常の Kerberos 認証を行う場合に表示されるイベント ログを見ていきましょう。

4768 – Kerberos 認証チケット（TGT）が要求されました

最初に確認すべきイベントは 4768 イベントです。これは TGT の要求であり、ユーザーが Kerberos を利用してネットワーク リソースにアクセスするために、まず最初に必ず発生する必要があります。ユーザーがドメインにアクセスする各エンドポイントごとに、この種のイベントが 1 件ずつ記録されます。ユーザー アカウントが 2 台の別々のワークステーションからログインする場合、それぞれのワークステーションから TGT を要求します。

このイベントで最も重要な情報は、TGT を要求したユーザーと、要求元のコンピューターです。:

4769 – Kerberos のサービスチケットが要求されました

Kerberos 認証の次のステップは、ユーザーがその TGT を使用し、たとえばファイル共有にアクセスするための CIFS のように、コンピューター上のサービスにアクセスする目的で TGS のサービスチケットを要求することです。 これはイベント 4769 のログにも表示され、チケットを要求したユーザーと送信元のコンピューターが示されます:

4770 – Kerberos のサービスチケットが更新されました

TGT を更新するとイベント 4770 が生成されます。デフォルトでは、TGT は 7 日間更新できます。これをテストしたい場合、Rubeus には抽出済みの TGT を更新するコマンド「renew」があります。更新したユーザーと更新元も確認できます：

Pass-the-Ticket 攻撃を示すイベントの見つけ方

では、pass-the-ticket（パス・ザ・チケット）の活動がある場合、イベントログには何が違って見えるのでしょうか？何を確認すべきでしょうか。 おそらく攻撃者は TGT を収集し、それを別のシステムで使用します。したがって、特定の Account/Client の組み合わせを使った TGS 要求、または TGT 更新がある一方で、その Account/Client の組み合わせに紐づく TGT 要求が存在しないケースを探すとよいでしょう。 まず TGS 要求、または TGT 更新を確認し、その後直前の 10 時間をさかのぼって、そのユーザーとコンピューターに一致する TGT 要求があったかどうかを調べる必要があります。 これは、pass-the-ticket では攻撃者が TGT を要求することが決してないためです。攻撃者は常に LSASS からそれを盗みます。 攻撃者はそれを更新する可能性もあり、また確実にそれを使って TGS のサービスチケットを要求することがあります。

また、この検出はイベントログのフィルタリングを超えた内容であり、規模を持って実施するには、SIEM やサードパーティ製品が必要になる可能性があります。 これを検出する方法を探しているなら、Netwrix Threat Manager を確認して、この点や、Golden Ticket、Pass the Hash、Kerberoasting のようなその他の Active Directory 攻撃において、どのように役立つかを見てください。