Throwback Thursday – A Guide to Configuring Throwback

It’s not Thursday, but today we’re going back to DEF CON 22 where we released Throwback. Throwback is an extremely effective beaconing backdoor. We use it with great success all the time. It’s comprised of two primary components:

  1. Throwback (the beaconing backdoor written in C++)
  2. ThrowbackLP (the C2 server written in PHP/MySQL)

While useful and stealthy, there hasn’t been a simple method to install and configure Throwback or ThrowbackLP…until now! With CCDC season coming up, we thought it’d be appropriate to provide a Throwback refresh, and release an automated installer script. Much of this installation procedure is included in our training course, Dark Side Ops: Custom Penetration Testing, where we teach how to develop custom backdoors to bypass the latest offensive countermeasures. If that sounds awesome (it does!), then you should check out our course. We conduct private trainings and work with BlackHat to provide the course all over the world. Enough of that, let’s run through the install process.

Installing ThrowbackLP

The first thing to do setup is ThrowbackLP. ThrowbackLP consists of one or more Apache HTTP servers hosting PHP files that collect the callback data from the various Throwback agents. There can be one or more ThrowbackLP servers to improve the opsec of outbound beaconing traffic. In our red teaming exercises, we’ll often use up to 8. This means that Throwback will callback to any one of the 8 ThrowbackLP servers at the configured callback period. In this demo, we’ll use a very short callback period, but we typically recommend at least an hour when the Throwback agent isn’t in use.

  1. Get a Linux operating system (preferably Debian or Ubuntu) up and running. There are no prerequisites, the install script will take care of all necessary dependencies.
  2. Download the install script from GitHub to the soon-to-be ThrowbackLP server. Make it executable and run it.
wget chmod +x ./ ./
  1. The script will first install dependencies including PHP5, Apache 2, and Git. Be patient, this may take a while.
  2. From there, it will ask if you’d like to enable SSL and generate self-signed certificates.
  3. The script will then prompt for the root WWW directory, which typically is /var/www/html/.
  4. The next question deals with naming the PHP file for the Throwback callbacks. An obvious is ‘index.php, but this can be anything you’d like. Note the name of the file! Later, we’ll have to compile the callback URL\file into Throwback.
  5. As previously mentioned, ThrowbackLP can be configured to manage multiple C2 servers. No matter how many ThrowbackLPs you have, only one (central) MySQL server is necessary. The remaining ThrowbackLP servers connect back to the primary LP to send/receive callback and tasking data. If you only want one ThrowbackLP, then it must be the primary. If you’d like multiple, setup the primary first and then add additional LPs. For the same of this walkthrough, we’re going to answer ‘yes’ to the primary LP question, and add another LP later.
  6. At this point, the installer script installs MySQL, creates a new user (i.e. tblp), and imports the database schema. If you’re going to add another LP, make note of the generated password for the ‘tblp’ database user. You’ll need it so the other ThrowbackLP servers can connect to the primary.
  7. Next, the script will help you create at least one user for the ThrowbackLP interface.
  8. Finally, the script wraps things up by copying the installation files to their appropriate locations. Below is a screenshot of the installation process in our lab. Pretty straight forward stuff
  1. One of the cool things about Throwback is the ability to separate stealthy beaconing persistence from more noisy RATs that provide interactive shell access. Throwback is not Meterpreter or Beacon, and is not intended to be. Just like real attackers often do, separating persistence from shell access provides quite a few benefits from a risk and opsec perspective. For example, our RAT (Slingshot) used for interactive ops is much more fully featured than Throwback. Why risk combining all functionality into one tool? We always talk about risk from a compliance and defensive perspective, but attackers need to be smart about risk management too when it comes to tools and operations. Sure, persistence has to touch disk, but we can limit our risk through lightweight, stealthy beaconing persistence.
  2. Ok, enough of the soapbox :). The last step of the script will prompt you to install the Metasploit framework. ThrowbackLP can interface with Metasploit (via MSGRPC) to generate payloads that Throwback injects into memory.
  3. In this walkthrough we’re going to install Metasploit. The script will also install additional dependencies (Msgpack for PHP, kernel headers, etc.) and configure ThrowbackLP to interface with Metasploit. A big thanks to Bryce Kunz, who wrote the PHP class for the MSGRPC API.
  1. The installer will then download and install the commercial Metasploit bundle. You’re on your own for registration.
  2. At the end of the installation, a Metasploit resource file is generated for you. It’s located at /root/msgrpc.rc.
load msgrpc Pass=EM8IoxLR7a
  1. You can see it’s pretty basic stuff. It simply loads the MSGRPC interface in Metasploit and sets a password for access, which is also set in “/var/www/html/cp/include/conf.php” (if you use the default Ubuntu directory).
  2. Once the primary ThrowbackLP is configured, fire up Metasploit and get the MSGRPC API up. That’s where that resource file we just created comes in handy. It’s handy to run the command below in a screen session so you can always return to the Metasploit console.
msfconsole -r /root/msgrpc.rc
  1. In our setup, we wanted two ThrowbackLPs so we installed another Ubuntu server and ran the installation script again.
    1. For secondary ThrowbackLPs, answer “no” to the “Is this server the primary ThrowbackLP?” question.
    2. Since all secondary LPs connect to the primary’s database, the script will ask for the “tblp” database user’s password, which the installer script from the primary ThrowbackLP generates and outputs.
  2. Ok, let’s login to the ThrowbackLP interface to make sure it’s working. Open a web browser and navigate to https://[IP of ThrowbackLP]/cp/index.php. Login with the account you created using the install script.
  1. Great! It’s working. Of course, there aren’t any targets showing up…yet, but we’ll get there. First, let’s review the interface.
    1. Action – This is a drop-down with tasks that you can assign to one or more Throwback targets.
    2. Command – This is the first parameter that corresponds with the selected “Action” task. For example, an “Action” of “Change Callback Timeout” requires the new callback timeout period, which is an integer in minutes.
    3. Arguments – This is for any additional parameters necessary for the “Action” task. For example, some applications might need command line arguments. We’ll explore this further toward the end of the walkthrough.
  2. And that’s it for ThrowbackLP! We’ll test it out more in a bit. First, let’s get Throwback compiled.

Compiling Throwback

  1. We’re not going to spend much time on this topic. Throwback is pretty easy to configure and compile. Download the latest version from Github and extract the zip file.
  2. Load the project file (Throwback.sln) into Visual Studio. Find the file “Throwback.cpp” within Visual Studio and open it.
  3. There are a few configurable items we’ll touch on. First, the variable “DNSARRAY” represents how many ThrowbackLPs you’re going to compile into Throwback. In this case, we have 2.
  1. Next, the variable “DNSCODE” represents the callback URLs of the ThrowbackLPs. This is a basic obfuscation technique so defenders can’t identify all our ThrowbackLPs by simply viewing strings in our binary. This is a multi-dimensional array and is usually where mistakes mess things up. We’ve provided the “” script to perform the conversion for you. In this example, our two ThrowbackLP IPs are “”, and “”. Do you remember what you named the PHP callback file from the install script? Here’s where you need it. Also, yes we’re using IPs in the URL, but you should be probably using domain names in ops!
  1. After running “”, copy the output and paste it in a text editor. Add a “-1” to the end of each array. This is VERY important. It lets the demangling function in Throwback find the end of the string.
  1. Combine arrays into the multi-dimensional array “DNSCODE”. It should look similar the screenshot below. Remember, we’re using two ThrowbackLPs in this case so they both need to be inserted.
  1. By default, Throwback runs as “dwmss.exe”. You can change this in the “main.cpp” file. Look for the “SVCEXE” and “SVCID” variables. The “SVCEXE” is the name of the executable Throwback runs as on disk. The “SVCID” is the service Throwback installs itself as if permissions are sufficient. Using “” you can encode a different filename if you like. For example, we can change the file and service name to “legit” and “legit.exe” with the code below.
legit -> {61,52,54,56,37}
legit.exe -> {61,52,54,56,37,127,52,41,52}
  1. Replace the output from above with the “SVCID” and “SVCEXE” arrays respectively. Note that we don’t include a “-1” at the end of the array. Remember, that is only necessary for URL callback arrays!
  2. In Visual Studio select the appropriate architecture (Win32 or x64) for your target from the dropdown at the top. Press “F7” to compile the project and find the goodies in the \bin folder. We’ll be using “throwback_x64.exe” for our demo.

Bringin’ it all together!

  1. Now comes the fun part of putting it all together for post-exploitation pwnage. Copy the Throwback executable to the target workstation and execute it. In our lab, we executed it with administrator privileges.
  2. The executable will soon disappear and eventually we’ll see “dwmss.exe” (or whatever you named it) running in the process list. That is because Throwback copies itself to a permanent location, installs persistence, and deletes the original file. With administrator privileges, Throwback installs itself to “C:\Program Files\Common Files\Services\dwmss.exe”.
  1. Now let’s login again to the ThrowbackLP and verify we have a callback from our new implant. If everything went well, you should see something similar to the screenshot below.
  1. Great! By default the callback period is 10 minutes, this is configurable in the “/var/www/html/cp/includes/conf.php” file. Let’s the callback for our new target to 1 minute. Obviously this isn’t the best idea for opsec, but it’s a good exercise. Select “Change CB Timeout” from the “Action” dropdown, and enter “1” into the “Command” textbox. Highlight the target (one or more) you want to apply the task to and click “Submit”. Notice the color of the target changes when tasking is currently queued. The next time that target calls back it will complete all assigned tasking. View the output of the tasking by clicking the “History” button.
  2. So we have our target implanted and callbacks are working. Now what? In normal operations, an attacker often needs interactive shell access to more easily pivotescalate privilegesexfil data, and access sensitive resources. We call this interactive operations. A couple examples of interactive shells are Metasploit’s Meterpreter and Cobalt Strike’s Beacon. In our Dark Side Ops: Custom Penetration Testing training course, we build out another interactive shell called Slingshot.
  3. The installer script installed Metasploit for us, so we’re going to use the ThrowbackLP interface to generate and deploy a Metasploit payload. Click “MetCreator” in the upper right corner. Here’s a brief overview of the options.
    1. Type – This is the output type of the payload being generated. The options are EXE, DLL, and RAW (i.e. shellcode). RAW is especially useful when combined with Throwback’s shellcode injection functionality.
    2. Payload – This is the type of payload to generate. Of course, the Metasploit handler has to match this.
    3. Filename – The filename for the generated payload. This is stored in the /var/www/html/down folder, unless you changed the root WWW directory in the install script.
    4. IP Address – This is the IP address for the reverse Meterpreter shell. Obviously this isn’t necessary for bind shells.
    5. Port – This is the port for the Meterpreter reverse or bind shell.
  4. In this case, we want a reverse Meterpreter callback to, which is also our ThrowbackLP. When conducting ops, it is a horrible idea to use the same infrastructure for interactive and beaconing access. It’s a great way to get caught and burn your infrastructure. For the purposes of this demo, it’ll work just fine.
  5. Complete the fields, and click “Create Payload”. You should see something similar to the screenshot below. Make note of the filename being generated!
  1. As shown in the screenshot, ThrowbackLP generates the Metasploit commands necessary to setup the handler for the callback. Copy and paste the commands into the “msfconsole” window and ensure the handler is running.
  1. We want to inject our shellcode payload into memory, but we first need to know which process we want to inject into. To do this we’ll need to first get a process list to obtain the PID of the target process.
  2. Find “Get Process List” from the drop-down and queue the task for the target. After the next callback, the output from “tasklist.exe” will be provided. Remember this is viewable by clicking the “History” button. Find the PID of a target process for shellcode injection. In our case, we used “spoolsv.exe” with a PID of “1032”
  1. With a valid PID, base64 encoded payload, Meterpreter handler listening, and target calling back, we’re ready to inject our shellcode.
  2. Return to the ThrowbackLP interface and select “Download and Execute Shellcode”. In the “Command” textbox enter the URL of the encoded HTML payload file. In the “Arguments” textbox enter the PID of the target process. Click on the target and then click “Submit” to queue the tasking.
  1. Wait the longest 1 minute of your life until you get the Meterpreter shell! Notice we’re running as SYSTEM and within the process ID we specified (1032).

Hopefully this post helps make an awesome tool a bit easier to use, and you’ll be able to incorporate it into your toolkit and ops methodology. Feel free to submit bugs on Github.


NetSPI’s Top Password Masks for 2015

Over the course of the last year, we’ve cracked a lot of NTLM domain password hashes. During many of our internal penetration tests, we grab the password hashes for all of the domain users and attempt to crack them. Throughout the year, we keep track of the hashes that we’ve cracked and try to gain some insight into how people are choosing passwords, and what we can do to identify some common weaknesses.

At the end of the last year, we took a look at the breakdown of lengths, common words, and number of duplicates. Since we captured more than double the number of hashes this year compared to 2014, it got to be a pain to track each and every domain hash cracking job.  Going forward, I’m looking to implement some better metrics in our cracking process to better tally these numbers and trends throughout the year.

I’ve compiled a list of our top password masks for the year. This was pretty easy to do, as we keep a running list of the cracked passwords for the year to reuse in other password cracking attempts. I have a handy Perl script  that I feed the cracked list into to determine the masks.

Below is the top 10 list of password masks for 2015’s cracked NTLM passwords.

The Top 10

#MaskExample Password% of Matching Cracked Passwords

?u = Uppercase letter
?l = Lowercase letter
?d = Decimal number (0-9)

Given that we see some combination of month, day, season, and/or year in every domain that we encounter, I figured I would do all of our examples in that format. For what it’s worth, all of the example passwords here were found in the cracked list.

The top 10 patterns listed above account for 28.66% of the cracked password list.

The top 40 patterns (Download Links Below) for the year account for 50.83% of the passwords that we cracked for the year (not 50% of the hashes gathered for the year). Now please keep in mind that these are just for the cracked passwords. This is a uniqued list. It does not account for duplicates and that means it does not truly reflect the real mileage that you could get with using these on a typical domain. Running the top 10 masks against a recent domain dump allowed us to crack 29% of the hashes in seven and a half minutes. So this does give pretty decent coverage.

Hypothetically, if we cracked 80% of the unique hashes for the year, this list of 40 masks could crack about 40% of the unique domain passwords. Statistics are fun, but since I don’t have solid numbers for every NTLM domain hash that we attempted to crack this year, I can’t really give you this info.

Interesting things to note

  1. Not a single one of our top ten masks has a special character in it.
    1. We actually don’t hit a special character in a mask until #12 on the list. In fact, 63% of the passwords that were cracked did not contain a special character. This was only slightly surprising, as you can still have a password that hits (most) Windows GPO complexity requirements without having special characters.
  2. Of the top 40 patterns, all of the masks are between 8 and 12 characters.
    1. Again, not a big surprise as most domain password length requirements are set at 8 characters.
  3. People really like capitalized words for their passwords.
    1. Only four of the top 40 masks don’t follow a dictionary word appended with something. I’d like to say that this is just skewed based off our cracking methodology, but most of the passwords that we’re running into contain a dictionary word .

So what do I do with these?

OCLHashcat has support for these mask files. Just use the attack mode 3 (brute force) option and provide the list of masks to use in a text file.
./oclHashcat64.bin -m 1000 hashes.txt -o output.txt -a 3 2015-Top40-Time-Sort.hcmask

When should I use these?

Personally, I would use these after I’ve gone through some dictionaries and rules. Since this is a brute force attack (on a limited key-space) this is not always as efficient as the dictionary and rule-based attacks. However, I have found that this works well for passwords that are not using dictionary words. For example, a dictionary and rule would catch Spring15, but it would be less likely to catch Gralwu94. However, Gralwu94 would be caught by a mask attack in this situation.

How long would this take?

That depends. We have a couple of GPU cracking boxes that we can distribute this against, but if we just ran it on our main cracking system, it would take about three and a half days to complete. That’s a really long time. There’s a few weird ones in the list that were easy to crack with word lists and rules (resulting in lots of mask hits), but they take a long time to brute force the key space (?u?l?l?l?l?l?l?l?l?l?d?d – Springtime15). I went through and time stamped each of the top 40 and created a time sorted list that you can quit using when you start hitting your own time limits.

2015 – Top 40 Masks List

2015 – Time Sorted Top 40 Masks List


Building an Application Security Program from Scratch: Part 1

So You Want to Build an Application Security Program

It’s the start of a new year, which means it might be time to take a look at where your current security program stands and how you would like to see it grow. When considering a comprehensive security policy portfolio, many enterprises briefly mention, or even entirely neglect, application security as an important piece to their InfoSec realm. In this blog series, I will outline the stages of starting an application security program from scratch. I will discuss drafting supporting policies, designing a program to support those policies, gathering buy-in, growing the service, and measuring progress. As each enterprise’s culture is different, this series should act as a guideline rather than a set of immutable rules, although the intent remains.

Expanding Your Current Portfolio

In order to design and implement a successful program, necessary work must be done to create a solid foundation on which you will be basing your decisions. Without appropriate policies, standards, and procedures, you will lack consistency, accountability, and auditability. Before even considering a tool-set, policies and standards must be created which will help guide the direction of a growing application security portfolio.

Most new security standards should fall easily into your current security policy portfolio without much need for modification. However, a more specific Application Security Policy should be considered down the line as the program matures in order to more easily expand the portfolio. Below is an example of where new application security standards might fit into an established security portfolio:

Data Protection Policy

  • Data Classification Standard
  • Encryption Standard
    • Data-at-Rest Encryption Procedures
    • Data-in-Transit Encryption Procedures

Access Control Policy

  • Password Construction and Management Standard

Logging, Monitoring, and Auditing Policy

  • Audits and Review Standard
    • Static Code Analysis Procedure
    • Dynamic Analysis Procedure
    • Penetration Testing Procedure

Infrastructure Hardening and Vulnerability Patching (Operations) Policy

  • Secure Configuration for Network Appliances Standard
    • WAF Configuration Procedure
  • Application Secure Coding Standard
    • Language-specific Coding Procedures
  • Application Testing Standard
    • Static Code Analysis Procedure
    • Dynamic Analysis Procedure
    • Penetration Testing Procedure

Fitting it In

Data Classification Standard

In the context of application security, classification should help developers determine how to handle data throughout their application. For example, the Application Security Standard may reference the Data Classification Standard by stating that no Personally Identifiable Information may be cached within the browser. Additionally, the standard should address how certain pieces of data may be displayed, masked, transmitted, or omitted from the application entirely.

Encryption Standard

Referencing the Encryption Standard goes hand-in-hand with the Data Classification Standard. For each level of data classification, there should be language describing how that data should be stored, if storing is allowed. Where this standard is extended is in the realm of application-specific data such as passwords. The Encryption Standard should contain approved hashing algorithms which can be pointed to by the Application Security Standard when discussing password salting, hashing, and storage.

The Application Security Standard should also address how data should be handled in-transit. Considering the Data Classification Standard, for example, all pages behind authentication should be transmitted via HTTPS using an approved encryption cipher. Further, this part of the standard should outline how traffic is to be sent between the application and other backend services such as databases or web-services.

Password Construction and Management Standard

Although password expiration requirements most likely won’t exist within a web application, much of the Password Construction and Management Standard should be applicable to application security. Requirements for construction and history should follow the approved standard, but the Application Security Standard may extend this by providing guidance for password reset procedures. Consider addressing such procedures concerning secret question/answer pairs or the use of email as a means of communicating temporary passwords or reset links. Additionally, this standard should address initial or temporary password generation as well as the lifetime of validity for either.

Audits and Review Standard

This standard should be concerned with the “when” and not the “how” of scanning. Depending on the development environment, internal requirements, compliance obligations, or other factors, some methods of vulnerability testing may be more important than others and should be prioritized accordingly. Additionally, frequency and remediation SLAs of each audit should be outlined within this standard. For example, a standard which determines the frequency of penetration testing may depend on whether or not the application is publically accessible or interacts with sensitive data.

Secure Configuration of Network Appliances Standard

If a web application firewall is utilized in your enterprise, its configuration should be addressed within a procedure underneath the Secure Configuration of Network Appliances Standard. This procedure should include what rules must be enabled by the WAF as well as how developers may submit deviations for that ruleset. Additionally, the process with which the development- and production-level rulesets are synchronized should be outlined here.

Application Secure Coding Standard

A standard which outlines how applications are to be developed securely must be established and integrated into the portfolio. Further, a procedure for each relevant development language should be created which outlines how the standard is to be achieved. For example, the standard may state that all user-supplied input must be sanitized. A corresponding procedure would outline, in technical terms, how sanitization is to be accomplished in Java, for example. Without concrete guidelines as to how code is to be written, it becomes difficult to enforce vulnerability remediation SLAs outlined in the Auditing Standard.

Application Testing Standard

Unlike the Auditing Standard, the Application Testing Standard provides guidelines on how each type of test is to be performed. Where the Auditing Standard is used to determine what applications are assessed at what frequency, this standard outlines the method with which these assessments are to follow. For example, the Auditing Standard may dictate that a web-facing application which processes credit cards must be pen-tested annually. The Application Testing Standard would then outline who is responsible for the testing and with what level of rigor or scope. Each corresponding procedure should then outline how these tests are to be carried out, such as application-specific functionality to be tested.

Wrapping Up

By designing standards which apply specifically to application development and maintenance, you are laying the groundwork for a successful application security program. Rather than starting with a brand new portfolio, finding ways to integrate application security into current standards may help reduce friction and potential roadblocks. This post outlined the general structure and explanation of important new standards, but it is by no means set in stone; your organization may dictate more or less. What is important is that you start thinking about how a new program can work hand-in-hand with the work you’ve already done. Part II of this series will discuss the standards in greater detail and provide further examples of language and format.

Discover why security operations teams choose NetSPI.