LSA Secrets, Service Account Password Extraction, NT/SYSTEM Privilege Account, gMSAs

In this article we talk about one of the most common vulnerability exist in modern  enterprise windows network infrastructure. We demonstrate how an attacker elevate privilege from administrator account to NT/ SYSTEM Authority privilege which is highest privilege in local windows system. The idea is to use NT authority system privilege to interact with LSA secrets and extract passwords from services account. Often these services accounts misconfigured in modern windows enterprise, which likely enable low privilege user to gain higher privileges.

Technical assumptions:

  • Attacker has an elevated privilege (Local Admin)
  • Attacker identified a service account AwesomeService.exe installed locally and runs under the local administrator privilege

 

Regedit Registry editor permission with SAM hive file requires NT/Authority SYSTEM Privilege, we  can not access the SAM File hive with windows local administrative permission.

SYSTEMPerm

Figure 1 SAM Hive set to full control permission

 

We Launch registry editor under the local administrative privilege – we are not able to read/write and modify SAM files.

4

Figure 2 Regedit under the windows administrator privilege account.

 

We elevate the local administrator privilege to NT/Authority SYSTEM privilege using the SysInternals PsExec Mark Russinovich copy of the PsExec Here   with the -i interactive, -s run remote process in the system account and -d  dot wait for process to terminate.

1

Figure 3 PsExec elevated privilege from local admin to NT/Authority SYSTEM

 

NT Authority\SYSTEM has access to SAM hive files

NT-Authority-Sam-file-5

Figure 4 Corroborates the SAM hive access via SYSTEM privilege

 

We not really interested in SAM/SYSTEM contents – We are after LSA Secrets and Service Account password extraction, however we need to create and compile a windows 10 compatible service and install it locally on our windows 10.

2

Figure 5 –  We created AwesomeService.exe with DisplayName “Windows Update” using SC Service Control to install and set the run time to auto start.

 

Display Name set as Windows Update

3

Figure 6 AwesomeService.exe runs as service under the local administrator privilege.

 

AwesomeService current value is in binary mode

currentValue

Figure 7  AwesomeService in binary value

 

lsasecret.exe /service AwesomeService command to dump clear text password from the registry.

AwesomeService-OpenSSHd

Figure 8   extracted openSSHd and AwesomeService accounts from registry.

Link to github lsasecre.exe the original source code from “Timothy D.Morgan”

 

Mitigation:

There are couple of solutions to mitigate against this particular vulnerability – the easiest and Microsoft recommended approach is the use of native windows feature,  Managed Service Account (MSA) and Group Managed Service Account (gMSA) .

Switch to your Server 2012 domain controller generate KDS root key for use with managed MSA and Group Managed Service Accounts (gMSA)   New-KdsRootKey Powershell cmdlet to initialize the key. The reason that we need to generate this once because this will be used in generating passwords for the Group Managed Service Accounts.

Add-KdsRootKey –EffectiveImmediately

Run this under the windows administrator Powershell console; The  -EffectiveImmeditely takes 10 hours from the time of creation to allow all domain controllers to replicate before allowing the creation of a gMSA. The idea behind 10 hours delay is a safety measure to prevent password generation from occurring before all domain controller are capable of responding to gMSA requests.

Perhaps yo may want to run this over the weekend over the night in production environment?

 

Service Account Creation

It’s straightforward to create gMSAs (Group Managed Service Account) Switch to the server you want to add service account, you need active directory Powershell module part of the RSAT for this to work.

New-ADServiceAccount -Name svc_Secure -DNSHostName cryptoambient.local -PrincipalsAllowedToRetriveManagedPassword  WIN-12-AV$

Command Breakdown :

-Name    service name of your choice

-DNSHostName   –  FQDN for our domain controller that holds KDS root key in my case ambientcrypto.local

PrincipalsAllowedToRetriveManagedPassword     –  This parameter allows you to specify the server(s) that you are going to be running particular (gMSA) on.

 

That’s it, simple and extremely reliable to manage service accounts. Good luck 🙂

 

 

 

 

 

Windows Task Scheduler Privilege Escalation ALPC exploit

Quick Description:

Hacker goes by name SandboxEscaper decide to upload 0day exploit in the windows 10 32-64 bit & Server 2016 x64 task scheduler, SchRpcSetSecurity API contains a privilege escalation vulnerability which can allow authenticated low privilege user to overwrite content of certain files protected by ACLs in filesystem. This is big, a local user authenticated can elevate their privilege to NT Authority /SYSTEM, which is highest privilege in windows operating system.

Maybe this new trend to release 0days ?

Hey I link to the code here,hopefully SanboxEscaper doesn’t mind me doing that.

Exploit prerequisite:

-Windows 10 32/64 or server 2016 system
-Exploit code link here
-CFF PE resource editor link here
-Your own malicious dll e.g msfvenom or empire powershell post exploitation framework etc

Process explore tool to see existing/new running process.Cmd.exe then launched notepad.exe to create a new process id PID  so that we can use PID to call hijack DDL as system privilege.

lpp1

Figure 1  notepad process associated with PID 1356 run under the cmd.exe.

Windows CFF explore  to edit ALPC_Tasksched-LPE.dll  then  RCData 101, Click right to Replace Resource Raw  then poc.dll which we used empire C2 for dll generation . CFF

Figure 2 CFF explore edit the ALPC_Tasksched-LPE.dll and replaced the existing dll with our empire C2 for reverse during execution.

 

InjectDll.exe 3508 notepad PID and our modified ALP-TaskSched-LPE.PoC.dll

F

Figure 3  we execute InjectDll.exe with modified empire dll

Local copy of empire agent call back “whoami” command shows session runs under the NT Authority\SYTEM

NT-Authority-lpe-access

Figure 4  Agent runs under the NT AUTHORITY\SYSTEM privilege context

 

Quick Video session here to demonstrate steps taken to corroborate the  ALPC privilege escalation  https://youtu.be/t50v8zGIwWE

Remediation

Wait for Microsoft to release security patch next few weeks…