Pass-the-Ticket 공격을 탐지하는 방법

시리즈의 첫 번째 게시물에서 Active Directory 도메인 내에서 NTLM 인증을 악용하는 pass-the-hash 공격을 탐지하는 방법을 살펴보았습니다. Pass-the-ticket은 Kerberos 인증을 활용해 수평 이동을 수행하는 관련 공격입니다.

이번 게시물에서는 pass-the-ticket 공격이 어떻게 작동하는지, 그리고 이를 탐지하기 위해 무엇을 할 수 있는지 자세히 살펴보겠습니다.

Pass-the-Ticket(티켓 전달) 공격이 작동하는 방식

Pass-the-ticket 공격에서는 공격자가 한 시스템의 LSASS 메모리에서 Kerberos Ticket Granting Ticket(TGT)을 추출한 다음, 이 유효한 티켓을 다른 시스템에 사용하여 Kerberos 서비스 티켓(TGS)을 요청함으로써 네트워크 리소스에 대한 액세스를 얻습니다.

가장 큰 차이점은 pass-the-hash와 pass-the-ticket 입니다. 즉, Kerberos TGT 티켓은 만료(기본값 10시간)되는 반면, NTLM 해시는 사용자가 비밀번호를 변경할 때만 변경됩니다. 따라서 TGT 티켓은 수명(유효 기간) 내에 사용해야 하며, 또는 더 긴 기간 동안(7일) 갱신할 수 있습니다.

Mimikatz는 pass-the-ticket을 수행하는 데 사용할 수 있지만, 이 글에서는 다른 도구인 Rubeus로 공격을 실행하는 방법을 보여드리고자 했습니다. Rubeus는 harmj0y가 작성한 C# 도구 모음이며, MimikatzKekeo

1단계. TGT를 추출합니다.

Rubeus로 pass-the-ticket 공격을 수행하려면 첫 번째 단계로 TGT를 확보해야 합니다. 보안 설정에 따라 사용자가 로그오프한 후에도 시스템에 TGT 및 NTLM 해시가 저장될 수도 있고 저장되지 않을 수도 있습니다. Rubeus의 흥미롭고도 무서운 기능 중 하나인 Monitor는 4624 로그온 이벤트를 찾아서, 시스템에서 새로 발생하는 모든 로그온 세션에 대해 TGT 데이터를 덤프합니다.

다음 명령을 사용하면 Rubeus가 30초마다 로그온 세션을 모니터링하기 시작합니다:

Rubeus.exe monitor /interval:30

이제 누군가 이 시스템에 로그온하면, 해당 사용자의 TGT를 얻게 됩니다. 이를 시뮬레이션하기 위해 사용자로서 다음 명령을 실행하겠습니다:

Runas /user:[domainusername] cmd.exe

30초 이내에 Rubeus가 이 로그온을 감지하고 이 사용자의 TGT를 확보한 다음, 이를 base64로 인코딩한 문자열로 출력합니다:

이 문자열을 텍스트 편집기에 복사한 다음 줄바꿈과 공백을 제거할 수 있습니다.

2단계. 티켓을 전달합니다.

이제 티켓을 훔쳤으니, 만료되기 전에 사용해 봅시다. 이를 위해 Rubeus는 그대로 사용하되, 이번에는 ptt 명령을 사용합니다:

Rubeus.exe ptt /ticket:[Base64 문자열을 여기에 입력]

손상된 사용자에 대한 TGT가 세션에 로드되어 있는 것을 확인할 수 있으며, 이제 이 TGT를 사용해 TGS 서비스 티켓을 요청함으로써 해당 사용자의 권한으로 네트워크 리소스에 접근할 수 있습니다.

탐지

엔드포인트 또는 도메인 컨트롤러에서 패스-더-티켓(pass-the-ticket)을 탐지할 수 있습니다.

엔드포인트에서 패스-더-티켓(pass-the-ticket) 탐지

패스-더-티켓(pass-the-ticket) 탐지에 대해 조사하던 중, Javelin Networks의 연구자 Eyal Neemany가 게시한 매우 흥미로운 접근 방식을 발견했습니다. 해당 접근 방식에서는 패스-더-티켓 활동을 조사하려면 환경의 모든 엔드포인트에서 다음 단계를 수행할 수 있다고 조언합니다:

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명당 이러한 이벤트가 1개씩 생성됩니다. 한 사용자 계정이 서로 다른 두 대의 워크스테이션에서 로그인하면, 각각에서 TGT를 요청하게 됩니다.

이 이벤트에서 가장 중요한 정보는 TGT를 요청한 사용자와, 요청이 전달된(요청이 이루어진) 컴퓨터입니다:

4769 – Kerberos 서비스 티켓이 요청되었습니다

Kerberos 인증의 다음 단계는 사용자가 해당 TGT를 사용하고 TGS 서비스 티켓을 요청하여 컴퓨터의 서비스(예: 파일 공유에 액세스하기 위한 CIFS)에 접근하는 것입니다. 이 역시 이벤트 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를 활용해 네트워크 리소스에 액세스하려면 반드시 가장 먼저 발생해야 하는 단계입니다. 도메인에 액세스하는 각 엔드포인트마다 사용자별로 이러한 이벤트가 하나씩 생성됩니다. 사용자 계정이 두 개의 서로 다른 워크스테이션에서 로그인하는 경우, 각 워크스테이션마다 TGT를 요청하게 됩니다.

이 이벤트에서 가장 중요한 정보는 TGT를 요청한 사용자와, 해당 요청을 보낸 컴퓨터입니다:

4769 – Kerberos 서비스 티켓이 요청되었습니다

Kerberos 인증의 다음 단계는 사용자가 해당 TGT를 사용해 TGS 서비스 티켓을 요청하고, CIFS처럼 파일 공유에 접근하기 위해 컴퓨터의 서비스에 접속하는 것입니다. 이 내용은 이벤트 4769 로그에도 표시되며, 티켓을 요청한 사용자와 소스 컴퓨터도 함께 나타납니다:

4770 – Kerberos 서비스 티켓이 갱신됨

TGT를 갱신하면 이벤트가 생성됩니다 4770. 기본적으로 TGT는 7일 동안 갱신할 수 있습니다. 이를 테스트하려면 Rubeus에 추출된 TGT를 갱신하는 명령 “renew”가 있습니다. 또한 갱신한 사용자와 갱신의 출처도 확인할 수 있습니다:

Pass-the-Ticket 공격을 나타내는 이벤트 찾기

그렇다면 pass-the-ticket 활동이 있을 때 이벤트 로그에는 무엇이 다를까요? 무엇을 확인해야 할까요? 공격자는 보통 TGT를 수집한 다음 다른 시스템에서 사용하므로, 특정 Account/Client 쌍과 관련된 TGT 요청이 그 Account/Client 쌍에서 발생하지 않았는데도 TGS 요청 또는 TGT 갱신이 있는지 확인할 수 있습니다. TGS 요청이나 TGT 갱신을 먼저 보고, 해당 사용자와 컴퓨터에 일치하는 TGT 요청이 이전 10시간 내에 있었는지 뒤로 스캔해야 합니다. 이는 pass-the-ticket에서 공격자는 TGT를 결코 요청하지 않고 항상 LSASS에서 TGT를 훔치기 때문입니다. 공격자는 이를 갱신할 수도 있으며, 확실히 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를 사용해 네트워크 리소스에 액세스하려면 반드시 가장 먼저 발생해야 하는 절차입니다. 사용자가 도메인에 액세스하는 각 엔드포인트마다 해당 이벤트가 사용자별로 하나씩 생성됩니다. 한 사용자가 두 개의 서로 다른 워크스테이션에서 로그인하는 경우, 각 워크스테이션에서 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 요청이 있었는지 확인해야 합니다. 패스-더-티켓에서 공격자는 TGT를 절대 요청하지 않기 때문입니다. 공격자는 항상 LSASS에서 TGT를 탈취합니다. 공격자는 TGT를 갱신할 수도 있고, 그리고 확실히 TGS 서비스 티켓을 요청하는 데 사용할 수도 있습니다.

이제 이런 탐지는 단순한 이벤트 로그 필터링을 넘어서는 수준이며, 대규모 환경에서 이를 수행하려면 아마 SIEM 또는 서드파티 제품이 필요할 것입니다. 이 방법을 탐지하는 방법을 찾고 있다면 Netwrix Threat Manager 를 확인하고, 예를 들어 Golden Ticket, Pass the Hash 및 Kerberoasting 같은 다른 Active Directory 공격에 대해서도 어떻게 도움이 될 수 있는지 살펴보세요.