Exploiting JBoss with Empire and PowerShell

When Empire was initially launched by @harmj0y and @sixdub at BSidesLV, I was immediately excited about the possibilities that a pure PowerShell RAT would bring to the offensive community. With what little free time I have, I’ve been working to add a few modules that have been inspired by recent engagements I’ve been on. This post will cover how to enumerate and exploit an internal web service through a deployed Empire agent without port scanning.

In this demonstration, I have an empire agent running on a Windows 7 host. The plan is to quietly enumerate the network for vulnerable web services and exploit one to move laterally.


First, I load the recon/find_fruit module and set the required options. The find_fruit module accepts CIDR ranges as well as single hosts. The module is also multi-threaded with a default setting of ten threads. One thing that makes this module great for red teaming or quieter penetration testing, is that unlike port-scanning, it uses legitimate web requests to check for web services that we commonly target such as Apache Tomcat, JBoss, Cold Fusion and more. The module will also accept a custom dictionary if desired. Kicking off the module I quickly find some “low hanging fruit” on a host in my target range.


Next, I want to create a payload and exploit the JMX-Console. Thanks to a stager by @ch33kyf3ll0w, Empire has the ability to generate java .war files for deploying agents. If you’re doing this outside of Empire, you can also generate a .war file using another @harmj0y script at https://gist.github.com/HarmJ0y/aecabdc30f4c4ef1fad3


Here I host the .war file with the python SimpleHTTPServer module. This is necessary as the jmx-console exploit will reach out to grab this file and deploy it on the target server.


Finally, I load the exploitation/exploit_jboss module and set the required options. I start by setting the JMXConsole switch to “true”. Next, The AppName needs to match the AppName I used when generating the .war file. I point the WarFile to my Python hosted file. Since I am tunnelling this exploit through an already deployed agent, I need to set the Agent option to deploy the exploit from. Empire will also let you know if this module is “opsec safe”, meaning it drops a file to disk.


Once the exploit is launched, I first see the HTTP request from the target server to grab the hosted .war file. After a few seconds, I am greeted by a new Empire agent!

If you’re looking for a way to enumerate and exploit internal web services without the noise of port-scanning, give this a try. The standalone Find-Fruit and Exploit-JBoss PowerShell scripts may be found on my github repository as well.

Scripts: https://github.com/rvrsh3ll/Misc-Powershell-Scripts

Empire http://www.powershellempire.com/

Leveraging Adobe LiveCycle

Adobe LiveCycle is an enterprise document and form platform that is being widely adopted by businesses and government agencies who are looking to centralize processes and document management capabilities. As with many web-based applications that connect to back-end systems, this provides additional attack surface that may be leveraged to gain a foothold into the target network. For defenders, this means ensuring LiveCycle administrators are exercising good security practices across the LiveCycle surface, which can be quite large as you’ll see in this post. LiveCycle works across many platforms as seen here and installations may vary. In this post, I’ll point out the areas of LiveCycle ES4 that may provide fruitful attack vectors to leverage on your next engagement.

LiveCycle has several access portals setup during the default installation that may provide access with default credentials. My experience has shown that Administrators have a tendency to change the main “adminui portal” password and overlook changing the OSGI administrative console password. Adobe was even kind enough to leave the OSGI console out of the “Next Steps” to perform after installation!

“OSGI provides developers with a way to create applications at a modular level, allowing the development and management of individual components that work together to form that larger puzzle as an adaptive and dynamic system.” – Source http://www.icidigital.com/osgi-with-cq5/

This console provides a very useful scripting console which we can leverage to further attack the system and possibly gain a system shell. Let’s run through an example of this attack path.

OSGI Attack Path:

The OSGI login uses Basic Authentication and can be typically accessed at “http[s]://[hostname]:[port]/lc/system/console”. The default credentials for this portal are admin:admin.

OSGI - Login1

Next, select “Script Console” under the main menu tab as shown.

OSGI - Menu

Now we are prompted with the scripting console where depending on the target setup, we can run various scripting languages.

Now, we use this script found at http://groovy.codehaus.org

def command = “””executable arg1 arg2 arg3″””
def proc = command.execute()

println “return code: ${ proc.exitValue()}”
println “stderr: ${proc.err.text}”
println “stdout: ${proc.in.text}”

For example, we’ll call a simple directory command. Make sure you correctly escape as shown in the example and provide an absolute path for a Windows target. Linux targets will not require absolute paths.

OSGI - Win-Dir-CMD

In Linux you’ll most likely be an un-privileged user and need to escalate privileges. In Windows, we’re lucky enough that Adobe LiveCycle requires that the Administrator disable UAC during install and as you see next, should be running as system.

For this example, I decide to utilize PowerSploit to inject a reverse payload. Don’t forget to escape any additional quotes!

I had trouble with WP posting this as a code block so it’s an image.


OSGI - Win-Meterpreter

Workspace Attack Path:

On a recent engagement I found the client had a custom application built that was accessible via the workspace path. Using the default credentials of atanaka:password, I was able to access the application that was obviously still being built. The application utilized the MYSQL database and was vulnerable to SQL Injection. It may be worth enumerating any custom-built LiveCycle applications that you run across. The default credentials I used are listed below from the sample setup utility.

Default URLS and Logins

To access the Correspondence Management Solution, you can access the solution template by using the following URL and login information:
URL from another computer: http://[host name]:8080/lc/cm/
URL from another computer if SSL was enabled: https://[host name]:8443/lc/cm/

Default user name: administrator
Default password: password

To access Administration Console, use the following URL and login information:

URL from another computer: http://[host name]:8080/adminui
URL from another computer if SSL was enabled: https://[host name]:8443/adminui

Default user name: administrator
Default password: password

To access the CRX Package Manager, use the following URL and login information:

URL from another computer: http://[host name]:8080/lc/crx/packmgr/index.jsp
URL from another computer if SSL was enabled: https://[host name]:8443/lc/crx/packmgr/index.jsp
Default user name: administrator
Default password: password

To access Mobile Forms Installation Verification Sample (IVS) application, use the following information:

URL from another computer: http://[host name]:8080/mobileformsivs
URL from another computer if SSL was enabled: https://[host name]:8443/mobileformsivs

If you have installed and deployed Reader Extensions, access the web application as follows:

URL from another computer: http://[host name]:8080/ReaderExtensions
URL from another computer if SSL was enabled: https://[host name]:8443/ReaderExtensions

Default user name: administrator
Default password: password

If you have installed and deployed Process Management, access the Workspace web application as follows:

Flex Workspace:

URL from another computer: http://[host name]:8080/workspace
URL from another computer if SSL was enabled:https://[host name]:8443/workspace

HTML Workspace:
URL from this computer: http://localhost:8080/lc/content/ws
URL from another computer: http://[host name]:8080/lc/content/ws
URL from another computer if SSL was enabled:https://[host name]:8443/lc/content/ws

Default user name: administrator
Default password: password

Additional default credentials that may be installed. These credentials are available if the administrator utilized the Adobe Sample Setup Utility.


User Name
atanaka password atanaka@sampleorganization.com LiveCycle Application Administrator
LiveCycle Workspace User
LiveCycle Contentspace Administrator
LiveCycle Contentspace User
jjacobs password jjacobs@sampleorganization.com LiveCycle Workspace User
LiveCycle Contentspace User
srose password srose@sampleorganization.com LiveCycle Workspace User
LiveCycle Contentspace User
kbowman password kbowman@sampleorganization.com LiveCycle Workspace User
LiveCycle Contentspace User


Powershell tools have become a must-have for security professionals in recent years. A few notable tools to mention are PowerSploit, Veil-PowerView, PowerUp and Nishang among others. These tools have each provided value to the Penetration Tester’s arsenal but, they require the tester to utilize some manual practices to employ them on target systems. It is one of my goals make Powershell tools a bit more automated and easier to use during penetration tests by utilizing the power of Cortana and Metasploit. As a result, I have created POSH-Commander to start bringing Powershell tools into the Armitage/Cobalt-Strike interface to improve speed and efficiency on engagements. There is an included Metasploit module remote_powershell.rb that may also be run independently to execute your remotely-hosted Powershell scripts.

In this scenario we are targeting a Windows 7 client connected to a Windows Server 2008 domain controller running Active Directory. The user is a standard domain user with no Administrative privileges. Once we have popped a Meterpreter shell, right-clicking on the host will present a POSH-Commander menu to select Veil-PowerView, PowerUp or a custom script.


For this demonstration, I am going to select PowerUp to see if we have any available options for privilege escalation.


With all modules, you will be presented with a text prompt if you would like to add additional arguments to the command. Please consult the directions in each script for possible arguments to use with each function. Here, I have selected to run the “Invoke-AllChecks” function with no additional arguments.


Once the results return, we see that we have permissions to write to the service-binary of the VMTools service. With this information, I can utilize the “Invoke-ServiceUserAdd” function in PowerUp to manipulate the service to add a local user in the Administrative group for us. This function stops the service, modifies it to create a user, starts the modified service to create our user, stops it again and restores it back to original. Pretty sweet huh?



We right-click the host again and select the PowerUp menu. You’ll notice, you’re provided a new tab for these results so that your previous results stay in their own tab. This time I opt to add arguments to the command as I need to specify the service to manipulate and click “OK” to run the module.


Success! The module has returned “True” telling me that the command has completed successfully and added the script’s default user “John” to the local Administrator’s group. Let’s check.


Interacting with a shell prompt, I run “net user” to check the local users on the target. You can see that “john” has been added to the local users.


This is just one of many possibilities utilizing Cortana/Metasploit and some very handy Powershell scripts. For more information on the scripts mentioned in this post, please visit the links below.