I’m a big fan of Powershell Empire for penetration testing.   If you haven’t heard of it, it is a post-exploitation framework which uses powershell agents to run post-exploitation scripts on a target system.  This blog post is meant to address a small subset of the modules, in particular the persistence modules.

The purpose of persistence modules are so that you could keep access to the compromised host.  Some methods are able to persist through reboots, which can persist much longer than memory only methods.  The negative for attackers however is that in order to persist through a reboot some data must be written to disk. This leaves artifacts that defenders can find or security tools can detect.

I’ve created a simple tool to identify Powershell Empire persistence artifacts. It is called NorkNork, and it is available on my Github.  It currently searches for these methods:

• Scheduled Tasks
• Auto-run
• WMI subscriptions
• Security Support provider
• Ease of Access Center backdoors
• Machine account password disable

In this post we will go through each finding and explain how to disable it.

Userland

I will start with the userland persistence methods.  These methods can be executed on a target without administrative access.

Running NorkNork we get three important pieces of output.

NorkNork found a malicious scheduled task and provides information on the name and the command that is ran.  We can see that it is named “Updater” and it contains a command to execute a powershell command. We can verify this by running

schtasks /query /V

on the command line or or by opening up the Task Scheduler.  Using the GUI is likely the easiest way to remove this, so all you need to do is select the task and click the “Delete” button on the right-hand pane or by right clicking and selecting “delete”.

The next finding is evidence of run keys in the Windows registry.  If you are not familiar with these, a more detailed description is here.

Since this is an unprivileged key, we can find it at: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

To remove it, open regedit and drill down to the path where the run key is stored.

Right click on the key and click “Delete”.   You may have noticed the command in the powershell script and realized what it does. As you can see, it executes a command in powershell that is stored in a variable named “x”. The value of “x” is stored within a registry key.  The command gives us the location of the registry key.  NorkNork will automatically enumerate the default key location and decode to content of the payload as seen below.

This information has value to defenders as it exposes the IP of the Empire server. It also shows the user-agent of the stager.  Defenders can use this information to identify other agents throughout their network.  To remove the payload delete it in the same way you did the run key.

Elevated

The elevated modules assume that the attacker has obtained administrative privileges. Much like the userland version, run keys can be used to automatically start an Empire stager.  The difference is instead of storing the key under HKEY_CURRENT_USER, it is stored under HKEY_LOCAL_MACHINE.

You will also notice that the payload is stored under HKEY_LOCAL_MACHINE as well.  You can remove both of them using the same method as the userland version.

The scheduled task can also run with administrative permissions, and removal is the same as before.

The most troubling method is via WMI subscriptions.

This technique is newer than the others, and difficult to remove and detect.  For a detailed explanation of what WMI subscriptions are, I recommend reading this post.

To manually verify the results of NorkNork, you can run:

powershell Get-WMIObject -Namespace root\Subscription -Class __EventConsumer

in powershell.  Scrolling through the data, one event should stick out from the rest as it contains a very large blob of base64 data.  If you base64 decode it, you should see the same data that we saw before for the stager.  The important thing to isolate is the name.  In the case of this example, it is “evil”.

When the WMI subscription is created, a couple things are created.  Reviewing the source code of this module tells that a WMI Event Filter, an Event Consumer, and a binding are created.  We need to remove all three.

To remove the binding, run the below command substituting ‘evil’ for whatever the subscription is named.

Get-WmiObject __FilterToConsumerBinding -Namespace root\subscription | Where-Object { $_.filter -match 'evil'} | Remove-WmiObject;

To remove the Event Consumer run:

Get-WmiObject CommandLineEventConsumer -Namespace root\subscription -Filter "name='evil'" | Remove-WmiObject

Lastly you need to remove the Event Filter, and if you want to actually confirm that this is working you can use the -Verbose switch.

Get-WMIObject -Namespace root\Subscription -Class __EventFilter -Filter "Name='evil'" | Remove-WmiObject -Verbose

Debugger

This next section is going to cover the debugger methods. From the Powershell Empire documentation, “The persistence/debugger/* modules allow you to set the “Image File Execution Options” (aka the debugger) for various executables that are accessible pre-login on the RDP prompt. By default the debugger is set to cmd.exe, which allows you to trigger a command prompt running as SYSTEM through RDP, without having to actually log into the machine.”

Here is a screenshot of NorkNork enumerating these:

This probably looks familiar to you by now, and as you can see the payload is stored in different registry key than the others.  We can remove it using the same methods as described above.

The debugger command is stored in a registry key.   It is stored in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\[BINARY NAME]

The possible locations Empire supports are sethc.exe, Utilman.exe, Magnify.exe, Narrator.exe, and osk.exe.  Since these normally do not have a debugger the presence of one may be an indication of compromise.  To remove these delete them out of the registry.

Lastly there are a few oddball methods I’ve included as well.

Miscellaneous

When an attacker has compromised a system, they can use tools such as mimikatz to dump all of the passwords on the system.  One of those passwords is the machine password.  By default, this password periodically changes. There are not many legitimate reasons to turn this feature off.  If it is turned off, it may be an indication of compromise.  To turn it back on, got to KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Netlogon\Parameters\DisabledPasswordChange and set the vlaue to “0”.

The last module detects rouge Security Support Providers. As described here, “After a user logs on, a variety of credentials are generated and stored in the Local Security Authority Subsystem Service, LSASS, process in memory. This is meant to facilitate single sign-on (SSO) ensuring a user isn’t prompted each time resource access is requested.” Powershell Empire has a module to both load a mimikatz module to log all passwords and a module to load any SSP of the attackers choice.

NorkNork enumerates all SSPs against a white-list and lists any items not on the white list. If a rouge SSP is detected, you can find it under KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa as the “Security Packages” key.  Look for the name and find the associated SSP under System32 on the system.