h1

How I tunnel Meterpreter through Beacon

January 28, 2015

I write so many blog posts about Beacon, I should just give up and call this the Beacon blog. Beacon is Cobalt Strike’s post-exploitation agent that focuses on communication flexibility and added covert channels.

It’s also possible to tunnel Meterpreter through Beacon with the meterpreter command. In this blog post, I’ll explain how this feature works.

a3

Beacon exposes a SOCKS proxy server to allow the Metasploit Framework and third-party tools to pivot through a Beacon. Each time Beacon checks in, data to write to and data read from ongoing connections is exchanged.

When you type ‘meterpreter’ in a Beacon, two things happen. First I generate a task to make the Beacon check-in multiple times each second. I call this interactive mode. Next, I issue a task that injects a bind_tcp stager into memory on the target. This stager binds to a random high port on 127.0.0.1. A lot of host-based firewalls ignore activity to services bound to localhost.

Once the above steps are complete, Cobalt Strike’s C2 server gets a response from the Beacon stating it’s ready to stage the Meterpreter payload. I stand up a one-time-use SOCKS-compatible port forward. This port forward ignores the client’s specification about which host to connect to. It always connects to 127.0.0.1. I do this because I want the Metasploit Framework to associate the Meterpreter session with the hosts IP, but I want it to stage to localhost.

I then start exploit/multi/handler for windows/meterpreter/bind_tcp. I configure this module to use my SOCKS-compatible port forward with the Proxies option. The Proxies option in the Metasploit Framework allows me to force an outbound Metasploit module through an arbitrary SOCKS proxy. I set RHOST to the IP address of my target.

The handler for Meterpreter bounces through my port forward to hit the bind_tcp stager I put into memory earlier. The payload stages over this connection and then the stager passes control to the Meterpreter payload with the same socket in the EDI register [a detail managed by the stager and the stage].

At this point, I have a Meterpreter session that tunnels through Beacon. Better, I have this session without interference from a host-based firewall (if there is one).

h1

Cobalt Strike 2.3 – I’ve always wanted runas

January 22, 2015

Cobalt Strike 2.3 is now available. This release adds a runas command to Beacon. This command allows you to specify a username and password for any user and run a command as them. Useful for situations where you know credentials for an admin and want to use them to elevate. Care to know the alternative? Shell Escalation using VBS (pg. 31, Red Team Field Manual) is what I used to do.

This release also adds a Cobalt Strike version of the PowerShell Web Delivery tool. This tool hosts a PowerShell script on Cobalt Strike’s web server that injects a Cobalt Strike listener into memory. This feature also generates a PowerShell one-liner that you may run on a target to get a session.

Finally, this release addresses an incompatibility that affected DNS Beacon users. Updates to the Metasploit Framework affected Cobalt Strike’s process to encode a stage to deliver over DNS. Cobalt Strike now includes its own encoder to build the DNS Beacon stage.

For a full list of changes, please consult the release notes. Licensed users may get the latest with the built-in update program. A 21-day trial of Cobalt Strike is available too.

h1

Indecent (Penetration Testing) Proposal

January 14, 2015

A customer reaches out to you. They’ve spent the money. They have a network defense team that innovates and actively hunts for adversary activity. They own the different blinky boxes. They have a highly-rated endpoint protection in their environment. They’re worried about these cyber attacks they see in the news. Despite this investment, they don’t know how well it works. The CEO thinks they’re invincible. The CISO has his doubts and the authority and resources to act on these doubts. They want to know where their program is at. They call you.

You run through the options. You dismiss the idea of looking at their vulnerability management program. They have this and they receive penetration testers on a semi-regular basis. They’re comfortable that someone’s looking at their attack surface. They’re still worried. What about something very targeted? What if someone finds a way that they and the myriad of vendors they worked with didn’t know about.

After discussion, you get to the heart of it. They want to know how effective their network defense team is at detecting and mitigating a successful breach. The gears start to turn in your mind. You know this isn’t the time to use netcat to simulate exfiltration of data. You can download some known malicious software and run it. Or, better, you could go to one of the underground forums and pay $20 for one of the offensive showpieces available for sale. Your minded quickly flashes to a what-if scenario. What happens if you go this way and introduce a backdoor into your customer’s environment. You shake your head and promise yourself that you will look at other options later.

Wisely, you ask a few clarifying questions. You ask, what type of breach are they worried about? Of the recent high-profile breaches, what’s the one that makes them think, “could that be us?” Before you know it you’re on a plane to New York with a diverse team. You bring an offensive expert from your team, she is a cross between operator and developer. You also bring a new hire who used to work as a cyber threat analyst within the US intelligence community. You engage with the customer’s team, which includes trusted agents from the network defense team who will not tell their peers about the upcoming engagement. The meeting is spent productively developing a threat model and a timeline for a hypothetical breach.

Your customer introduces you to another player in this engagement. Your customer pays for analyst services from a well known threat intelligence company. This company is known for working intrusion response for high-profile breaches. A lesser known service is the strategic guidance, analysis support, and reports they provide their customers on a subscription basis. This analyst briefs you on a real actor with capability and intent to target a company like your customer. The hypothetical breach scenario you made with your customer is amiable to this actor’s process. The analyst briefs your team on this actor’s capabilities and unique ways of doing business. Your customer doesn’t know what they want here, but they ask if there’s a way you can use this information to make your activity more realistic, please do so.

You and your team leave the customer’s site and discuss today’s meetings with a fast energy. The customer wants to hire you to play out that hypothetical breach in their environment, but they want to do this in a cost effective way. A trusted insider will assist you with the initial access. It’s up to you to evade their blinky boxes and to work slowly. Paradoxically, the customer wants you to work slow, but they want to put a time limit on the activity as well. They’re confident that with unlimited time, you could log the right keystrokes, and locate the key resources and systems in their network. To keep the engagement tractable, they offer to assign a trusted agent to your team. This agent will white card information to allow you to move forward with the breach storyline.

The customer’s interest is the hypothetical breach and the timeline of your activity. They don’t expect their network defense team to catch every step. But, they want to know every step you took. After the engagement, they plan to analyze everything you did and look at their process and tools. They’ll ask the tough questions. How did they do? What did they see, but dismiss as benign? What didn’t they see and why? Sometimes it’s acceptable that an activity is too far below a noise threshold to catch. That’s OK. But, sometimes, there’s a detection or action opportunity they miss. It’s important to identify these and look at how to do better next time.

You look at this tall order. It’s a lot. This isn’t something your team normally does. You know you can’t just go in and execute. Your new hire with the intel background smiles. This is a big opportunity. Your developer and analyst work together to make a plan to meet the customer’s needs. Your intent is to execute the breach timeline but introduce tradecraft of the actor the threat intelligence company briefed you on. These few tricks you plan to borrow from the actor will show the customer’s team something they haven’t seen before. It will make for a good debrief later.

This engagement will require some upfront investment from your team and it may require a little retooling. You’ll need to analyze each piece of your kit and make sure it can work with the constraints of your customer’s defensive posture. You verify that you have artifacts that don’t trigger their anti-virus product. Some of the cloud anti-virus products have made trouble for your team in the past. You look at your remote access tool options. You need a payload that’s invisible to the blinky boxes and their automatic detection. If you get caught, you want to know ingenuity and analysis made it happen. You won’t give yourself up easily. At least, not in the beginning.

You also want to know that you can operate slowly. Your favorite penetration testing tools aren’t built for this. Big questions come up. How will you exfiltrate gigabytes of data, slowly and without raising alarms? You know you’ll need to build something or buy it. You also work to plan the infrastructure you’ll need to support each phase of the breach timeline. You know, for this particular engagement, it makes no sense to have all compromised systems call home to the one Kali box your company keeps in a DMZ.

As all of this planning takes place, you pause and reflect. You got into this business to make your customers better. You built a team and you convinced your management to pay them what they’re worth. You carry the weight of making sure that team is constantly engaged. Sometimes this means taking the less sexy work. Unfortunately, your competitors are on a race to the bottom. Everyone sells the same scans and vulnerability verification as penetration tests. It keeps getting worse. You know you’ll lose your best people if you try to compete with this way. This engagement brings new energy to your team.

This mature customer is willing to pay for this service. The value to them is clear. They want to know how well their security operations stands up to a real world attack. They understand that this is a task that requires expertise. They’ll pay, but they can’t and won’t pay for a long timeline. The white carding is the compromise.

You’re excited. This is something that will use the expertise you’ve collected into a cohesive team. Your customer appreciates how real the threat is. You make plans. Big plans. You wonder who else might pay for this service. You go to your sales person and brief them on the customer and this engagement. Your sales person nods in agreement. “Yes, I see it too”.

h1

Pass-the-(Golden)-Ticket with WMIC

January 7, 2015

One of my favorite blog posts from last year was the Adversary Tricks and Treats post from CrowdStrike. They showed how one of the actors they track changed their tactics to cope with a more alert defender.

This actor, DEEP PANDA, sometimes injects a Golden Ticket onto their local Kerberos tray. To move laterally, this actor uses this trust to enable the RDP sticky keys backdoor on target systems. The actor then RDPs to the target and uses this backdoor to get a SYSTEM level command shell. Nothing to it.

When I read about interesting tradecraft, I like to reproduce it in a lab. According to CrowdStrike, this actor uses wmic to pass the Golden Ticket and execute their commands on the target systems.

I stood up a test system and used kerberos_ticket_use in Beacon to ingest a Golden Ticket. I then tried to execute a command on a Windows 8 system with WMIC:

wmic /node:WIN8WORKSTATION process call create “stuff I want to run”

This command failed with an access denied. Picture a Sad DEEP PANDA face here. After some digging, I found that there’s a flag I need to specify. To pass a Kerberos ticket with WMIC, use /authority:”kerberos:DOMAIN\TARGET” on your WMIC command line. So in this case:

wmic /authority:”kerberos:CORP\WIN8WORKSTATION” /node:WIN8WORKSTATION process call create “stuff”

That’s how you pass a Golden Ticket with WMIC.

h1

How did your hacking-style change in 2014?

December 30, 2014

The end of the year is always a good time for reflection. As you close out your year, I encourage you to ask: how did your style of hacking change and evolve in 2014? I suspect most of us have some answer to this question. We’re always learning and becoming informed by new tricks.

Here’s how my personal hacking-style has changed in 2014.

PowerShell for Post Exploitation

There’s a lot of enthusiasm for PowerShell in the offensive community. I feel that these enthusiasts are split into two camps though. One camp advocates PowerShell as a tool to bootstrap a payload without worrying about anti-virus. Another camp develops all of their post-exploitation tools in PowerShell and operates through these tools.

This year, I came into the second camp. I would always acknowledge that there was great capability in PowerShell. But, the difficulty using these scripts with the tools I know [Meterpreter, Beacon] prevented me from experiencing it first hand.

This year, I took the time to integrate PowerShell into Cobalt Strike’s Beacon payload and remove this hurdle. Immediately, my eyes were opened to a whole universe of post-exploitation tools I didn’t have before.

Veil PowerUp has changed how I elevate my privileges. Now, one of my standard items is to use PowerUp to find misconfigurations on the compromised target before I look at other options.

Veil PowerView has changed how I interrogate a network, enumerate trusts, and look for targets I can jump to laterally.

And, PowerSploit combined with Beacon provides a very respectable post-exploitation toolkit.

Almost all of my post-exploitation is asynchronous now. I go interactive only when I need to tunnel another tool through a Beacon.

Lateral Movement without PsExec

My tools tend to expose the Metasploit Framework’s workflow for lateral movement. Dump hashes and use the psexec module to get a session on a host. Or, steal a token and use current_user_psexec to get to that host. If current_user_psexec fails [it will], know how to run an artifact on a remote system the manual way.

The workflow for lateral movement I use today is much different. Late 2013, I introduced the named pipe communication channel into Beacon. I saw some interesting possibilities for this channel, but during use, I could tell the supporting features were missing. These came in February 2014. I added the ability to generate artifacts that contain the entire Beacon payload and Beacon gained tools to elevate privileges and steal tokens.

The above was enough to move my lateral movement workflow away from Metasploit’s workflows. I now capture a trust through Beacon [net use, steal a token, import a kerb ticket] and use wmic, at, sc, or schtasks to run an artifact I copy to the remote target. This artifact is almost always an SMB Beacon. This is the Beacon variant that waits for me to link to it over a named pipe. This is very stealthy and it’s a very powerful way to use Beacon. Almost all of my lateral movement is asynchronous now.

Persistence without Malware

Another big change to my process came from Mimikatz and the Golden Ticket technique. This technique allows me to use the krbtgt hash taken from a domain controller to generate valid Kerberos tickets for any user I like. These tickets are not tied to the user’s password at all. This technique has changed how I do persistence. Now, I tend to pull the information I need to generate tickets at will and store it in an attacker-accessible Wiki. When I need access to a server or some other key asset, I generate a ticket, import it into Beacon, take the server, and then pull off of it when I’m done.

For defenders used to finding malware and cleaning it up, this is a big mental shift. They can’t just delete a bad binary and assume their network is clean. They have to think about which trusts the attacker had access to and how that might allow the attacker to reclaim control of their network at will. It’s an interesting problem.

I’ve always appreciated living on hosts without malware. In exercises, the sticky keys backdoor is useful. Periodically using Mimikatz to pull credentials to (re)use later is also a way to hold access. These techniques are fine but they carry risk [the RDP backdoor is easy to find, vigilant admins change their passwords]. The Golden Ticket allowed me to have confidence in and rely on malware-free persistence in a way that I just couldn’t before.

In terms of my tradecraft and thinking about how I “hack”, these are the three things that changed for me in 2014. What changed for you?

h1

Course Review: Dark Side Ops

December 22, 2014

“Dark Side Ops (DSO) is a course on targeted attacks, evasion, and advanced post exploitation… with a twist. The thesis of DSO is this: if you want to credibly simulate a real world attacker, you need advanced capability. You can’t do this with unmodified open source tools. This course teaches students how to build and modify advanced capabilities. Let’s take a closer look.”

Recently, I spent a few days in a course that combines malware development and advanced tradecraft into one package. I thought the course was so good, I wrote a review on it. You can check out the review over at ethicalhacker.net.

h1

What’s the go-to phishing technique or exploit?

December 17, 2014

This blog post is inspired by a question sent to a local mailing list. The original poster asks, what’s the go-to phishing technique or exploit in a blackbox situation? Here’s my response:

I’ve had to do this before, I sell tools to do it now, and I’ve seen how others teach and go about this particular process. First, I recommend that you read MetaPhish. No other paper or talk has influenced how I think about this process more:

You’ll notice I said the word process. Before you dig into a toolset, you’ll want to figure out the process you’re going to use. Here’s what I used and it has parallels with the processes I see others use now [regardless of toolset]:

0. Information Gathering

Find out about your target, harvest email addresses, etc. etc. etc.

1. Reconnaissance

This is the phase where you sample the target’s client-side attack surface. I used to send a few fake LinkedIn invitations across an org and direct those folks to a web app that profiles their browser. Similar information to what you see here: http://browserspy.dk/

I’ve seen some organizations use BeEF for this purpose and Black Squirrel does this as well.

2. Stand up a Test Environment

Next, I recommend that you create a virtual machine to mirror their environment as closely as possible. Install patches and other tweaks you think may be present. This isn’t the place to underestimate their posture. I’d also recommend trying out the different A/V products you expect to see at this point. Use the information from the reconnaissance step to make this as exact as possible.

3. Choose your attack

Now, you will need to select an attack to use against your target. I really recommend that you stay away from the memory corruption exploits in the Metasploit Framework. You can tweak them to get around some anti-virus products. But, you really need to pay attention to the exploit’s needs. For example, let’s say the target profile reveals a vulnerable version of IE and Metasploit has an exploit for it. What are the dependencies of that exploit? Does it also require Java 1.6 to help it get past some of Windows’ protections? You could play this game. Or, you could skip it altogether.

Many folks who execute these kinds of engagements regularly use user-driven attacks. A user-driven attack is an attack that relies on functionality and fooling the user into taking some detrimental action. The Java Applet attack is an example of a very popular user-driven attack. I’m surprised it still works today, but *shrug*. Embedding a macro into a Word or Excel spreadsheet is also effective.

The stock vba macro you can get out of MSF is also pretty good [it injects straight into memory]. I understand that BeEF has some options in this area too, but I haven’t played with them.

4. Pair your attack with a payload

Don’t take it for granted that you’ll walk out of your target’s network with a Metasploit Framework payload. I see egress as one of the toughest problems when working with a harder target. If you have to use a Metasploit Framework payload, windows/meterpreter/reverse_https is your best bet here. I recommend that you look for and consider other options though. A lot of organizations who do this kind of work have a custom payload or they buy one. If I were in a hurry to cobble up a process and didn’t have a budget, I’d look at building something in PowerShell. The main things you care about:

a. Is the payload proxy aware? Will it take the same actions that the user’s browser would take to get out to the internet?

b. Can I match the payload’s characteristics to the target environment? For example, making its User-Agent match something legitimate?

bb. If I opt to go SSL, can I use a legitimate certificate? If not, does the payload at least try to look like legitimate traffic if I communicate without SSL?

c. Is the payload asynchronous? You really want something reliable that doesn’t stand out while you figure out what to do next on your target’s network.

d. Can I pair this payload with my attack? This is an important consideration. If you have a great piece of custom malware but *can’t* pair it with your chosen attack, it’s not useful to you for this phase of your engagement.

Your custom payload [bought/built] does not need to be fully functional. Its main goal is to defeat egress restrictions and act as a lifeline while you figure out the best steps to fortify your access [if that’s what your customer wants]. The main thing it needs to be able to do is spawn another payload.

Here’s one of my favorite talks on how to pull something like this together, quickly:

I also recommend that you setup infrastructure for each piece of this attack. You should send phishes from different places. You should host your recon app on its own server. The server your user-driven stages your payload from should differ from the server the payload actually communicates with [if your payload is delivered in stages]. Ideally, your asynchronous lifeline payload should call home to multiple hosts in case one of them becomes blocked.

5. Deliver the package

The final phase is to send the package on to your target. I don’t recommend that you spray every email you found. If your goal is to demonstrate a targeted attack, be targeted.

Personally, I’m a stickler for pixel perfect phishing emails and I’m not a fan of crafting an HTML email in a hacker tool to achieve this. If in doubt, I recommend that you use the same email client that your legend [the person you’re pretending to be] would use to send the email. If your target is someone in HR and your legend is someone applying for a job, use Gmail to send your phish. Preferably, the same Gmail account noted in the resume.doc you embedded a macro inside of.

Before you phish, I recommend that you send your package to yourself, through infrastructure that mirrors your target environment as closely as possible. If your target uses a cloud email service, try to get an account on the free or low-tier paid version of this service and send your package to yourself there. If your target uses a more traditional Exchange+Outlook setup, see if you can build a lab with those pieces or rely on a friend who has access to something similar. The main point here is to make sure your lovingly crafted bundle of good isn’t going to the spam folder. It’d be a shame to go through all of this work to get stopped by that.

Even if you have a favorite “go to” user-driven attack, I recommend executing this process anyways. You don’t want to fire an attack package crafted for a Windows environment only to find that your target is a MacOS X shop.

Tradecraft parts 3, 4, and 8 cover these topics.

Follow

Get every new post delivered to your Inbox.

Join 14,458 other followers