Tried, Tested and Proven

Earlier this year some enterprising blaggers hit upon an excellent scheme. One bright spark noticed that there was a postal service concession in their local supermarket. Nothing terribly unusual about that right? Of late, postal companies have eschewed dedicated retail outlets in favour of lower-footprint concessions in larger stores. The problem (for the supermarket, at least) was that, not only did they sell groceries and pub-price-busting booze, but also envelopes and Blu-ray discs, games and all manner of other things.

I bet you can see where this is going, right? Well, just in case you can’t, I will take you through the whole scenario.

Scally walks into the supermarket, picks up a security-tagged, high-value item, walks over to the stationery section and pops it in a suitable envelope. Then it’s just a case of adding an address, walking over to the postal service concession and posting it; thereby bypassing the security gates at the entrance. All for the price of postage; they didn’t even need to pay for the envelope!

Pure genius. Pure, obvious genius.

What amused me most about this was the fact that this is almost a perfect, physical analogue of what can be one of the most important elements of a Red Team engagement: Data exfiltration.

One of the ultimate objectives of any self-respecting threat actor is not necessarily the compromise of, or access to, a system, but rather getting usable data off of the system and into a usable location, without being detected or blocked.

There are several approaches that a threat actor could choose to achieve exfiltration (each with varying risks of detection) which is where an excellent understanding of the target infrastructure is required.

Data exfiltration is rarely, if ever, a Hollywood-style affair, with holes being punched through firewalls and lots of bleeping and meaningless progress indicators. What an attacker desires is not to fly under the radar, or use exotic means to get the prize through the door, but rather to use the target systems against themselves by looking and appearing exactly like legitimate usage of these systems.

One of the challenges security teams (i.e. the Blue Teams) have is that networks are designed to make it easy for systems and users to move data about; not only internally, but to communicate data and information to external systems. This, of course, means that the number of approaches an attacker could take are broad and varied.

In a recent engagement, I was assessing data exfiltration possibilities as part of a Red-Teaming exercise. It turned out to be exceptionally trivial to achieve; Internet access was unchallenged. By this I mean that there was no proxy as such, just the default gateway with no content filtering or additional protection in place.

Even in locations with Data Loss Prevention solutions in place and rigid proxies, with content filtering there is usually a blindingly obvious route that attackers will choose which will effectively mask their swag as “normal” as far as security controls are concerned.

One such engagement exhibited excellent security and data controls. It was pretty hard to find a trivial exfiltration vector but, fortunately, we had a secret weapon: G (one of our Team members) came up with a beautiful and elegant solution. The client blocked most websites that weren’t directly involved with what could be deemed business activities and it was impossible to get to any form of upload site such as Dropbox, or webmail providers. However, they had overlooked one thing: they weren’t blocking dynamic DNS providers. Quick as you like, G had cooked up a DNS redirect to one of his web servers and, with some coding magic, he had encoded and chunked up our sample data to exfiltrate HTTP “GET” size requests. He also cooked up a script to take these small chunks of data and send them as requests to our server, which would then reassemble and decode them.

It was rate-limited; the DLP and the proxy didn’t stand a chance. Even if the Blue Team, in this instance, had been monitoring proxy logs for high volumes of requests to certain sites, we could have split the load across many servers or got our implanted remote access tool to do it in dribs and drabs so as not to raise suspicion.

These are just two scenarios; in reality, on every engagement I have been involved in, I have (or at least a Team member with a more creative mind than my own, has) found a means of getting data out of an environment. The trick for the Blue Team is not to prevent every possible way of exfiltrating data (that is an endless game of whack-a-mole) but rather to look at their systems and see how they can be turned against themselves, or carefully define what would constitute “normal” behaviour for their assets (people included) and be able to act on any suspicious activity.

This is where the “Kill Chain” comes in to play. For those not familiar with the concept, the Kill Chain is effectively a sequence of events describing an effective attack from beginning to end. The final link in this chain (the scenarios I have been describing) would be data exfiltration. To get to a point where I can achieve this (arguably the easiest, but most important element in the chain), what would I need to know or do?

An example of the steps to be taken could take this form:

I would need to identify an individual within the target company. I would also need to know what email client they were using, whether or not they use Microsoft Office, how egress to the Internet is facilitated to users. I would then need to craft a relevant and plausible clickbait email with a malicious attachment that we can convince the targeted user to click on. I would also have needed to create a remote access tool that would bypass AV and malware detection and potentially also be able to egress back to my server. Then I would need to identify and compromise the internal assets within the target company to gather the data and, finally, get it back to me.

That may seem like a lot to achieve, however, much of this can be assumptive knowledge. How many companies do you know that don’t use Microsoft IE and Word, for instance?

So what sorts of things could a Blue Team do or implement in order to disrupt my activities to ensure that the final step is not achievable?

  • Protect and evaluate information that is disseminated publicly – carry out Open-Source Intelligence Gathering.
  • Protect and evaluate information that is exposed in communications, such as emails and published documents – scrub your Word and PDF documents and make sure your email headers are clean, for instance.
  • Ensure that unsafe features are not enabled – for example no macros or no Microsoft PowerShell for normal users.
  • Segregate your internal resources – DMZ your servers and check your users’ abilities to connect to things which they do not have a reason to.
  • Harden your boxes – patch, patch, patch! Reduce the attack surface of your critical assets as far as possible.
  • Tighten your belts – reduce the points of egress to a minimum. None of this is definitive but should be food for thought.

Oh, and, most importantly: get your systems tested!

Find Information on our Red Teaming services here