Developing the perfect exfiltration technique

At SafeBreach, one of our major research areas is exfiltration (sending sensitive data out of the corporate network). In one of our research projects in late 2015, we set out to find the perfect exfiltration technique. At that time, we didn’t quite know what it would encompass, but we were determined to find out.

Now, when considering exfiltration data from an enterprise, it makes sense to look for covert channels. Otherwise the security policy (implemented through security products) is likely to detect/prevent the exfiltration. Our obvious move then was to start looking at the state of the art techniques in covert channels (for example, A survey of covert channels and countermeasures in computer network protocols, Covert Channels in TCP/IP Protocol Stack and Covert timing channels using http cache headers).

With each covert channel technique we reviewed, we found counter attacks, meaning, ways to detect the covert channel, and/or eliminate it. During this long phase of review and rejection, we slowly came up with a list of constraints which the perfect exfiltration technique must fulfill. This in itself was a very educational exercise. Below is an example.

The IP TOS (Type of Service) field

This field was suggested by some of the covert channel research works we reviewed as a covert channel. In the covert channel scheme, this 8-bit field can carry up to 8 bits of information. The sending party (inside the enterprise) thus needs to craft an IP packet (with the TOS field populated with the “payload” data) and send it to the destination IP address, where it is read by the receiving party. Since regular traffic monitoring solutions don’t look at the TOS field, the data exfiltration will go unnoticed.

There are several drawbacks to this scheme:

1. Once the scheme is known, a security solution that does look at the TOS field may be implemented. In addition, the anomaly in the TOS field values will be obvious in certain environments; for example, Windows desktops send IP packets with zero TOS.

2. A firewall (or a security gateway) may override the TOS field with e.g. 0, thus eliminating the channel.

3. If the enterprise incorporates IP reputation information, the (direct) traffic between an internal machine and an external IP address whose reputation is questionable (or at least, unknown) may trigger anomaly detection alert.

4. Modification of the TOS field requires special software to communicate with the outside world, which may jeopardize the sending party e.g. if DLP solutions are used.

From this example, we can extract several constraints that we impose on the perfect exfiltration solution:

A. From #1, we derive: A perfect exfiltration technique should adhere to Kerckhoffs’s principle (https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle, sometimes called Shannon’s maxim), which states that “A [crypto] system should be secure even if everything about the system, except the key, is public knowledge”. This is in contrast to the “security by obscurity” principle employed by so many attack (and defense) technologies.

B. From #2, we derive: The perfect exfiltration technique should be able to resist elimination (assuming such elimination can be easily deployed in a way that does not disrupt regular traffic, or disrupts it in a very minimal scope).

C. From #3, we derive: The enterprise (and its security solutions and services) should be assumed to have perfect knowledge of e.g. the Internet (IP ownership, reputation, use), its corporate users (profiles, typical network “habits”, etc.). Thus any direct connection with an IP not on, say, the Alexa top 1000/10000 sites may raise suspicion.

D. From #4, we derive: A perfect exfiltration solution should not require non-standard software (beyond a vanilla, popular browser) to perform the actual communication.

There are more constraints which we learned from other examples. Altogether we discovered 10 constraints and guidelines, and decided to aptly name them “the 10 commandments”:

1. A perfect exfiltration technique should adhere to Kerckhoffs’s principle (everything is known except the keys).

2. A perfect exfiltration should withstand active disruption by the enterprise

3. A perfect exfiltration technique should withstand robust network monitoring. What we mean by network monitoring is every packet is scrutinized at all protocol levels, every anomaly is detected (via machine learning or other analytics), reputation and statistics for all IPs/hosts are available, etc.

4. A perfect exfiltration should make use of standard software (e.g. native browser) for its communication with the external party

5. “Whenever there is any doubt, there is no doubt” – anything that may theoretically be perceived as passing info is forbidden. So no emails, no encrypted texts, no google docs, no forum posts, etc.

6. Only normal web (browsing) and web-derived traffic is allowed

7. Assume SSL termination at the enterprise level

8. Receiving party has no restrictions (e.g. network surveillance)

9. No nation-state monitoring or 3rd party site monitoring, although it’s assumed organizations will have some basic IDS/IPS/security, so flooding needs to be avoided

10. Time synchronization (seconds-resolution) between the communicating parties is allowed.

Interestingly enough, bandwidth is not a major requirement, since even small amount of sensitive information can oftentimes be enough to benefit the communicating parties (and jeopardize the enterprise). Think leaking of cryptographic keys, for example.

After some additional thinking, we even found a technique (or rather, a family of techniques) that fulfills all 10 commandments. We won’t spill the beans right here and now, but you’re more than welcome to attend our Hack In The Box session in Amsterdam on May 27, but we will say that the technique is based on regular (HTTP) browsing, and in some cases, caching is involved.