Stealthy Targeted Implant Loaders Addendum

A few weeks ago I published a blog post titled Stealthy & Targeted Implant Loaders. There are a couple of caveats to the aforementioned points that I would like to address in this brief addendum, in addition to introducing a few new ideas.

On-Target Analysis

In the last post we discussed a number of target-specific conditions that can be used as cryptographic key material input. The result of these conditions is a payload that will only successfully decrypt only on the intended target(s). Naturally, this behavior also implies that if someone was able to reverse engineer the implant loader on the target (or an accurate simulation of), we lose any affective means of payload protection.

How can we bolster payload protection when it resides on the intended target?

Off-Target Key Material

In addition to leveraging local host conditions, we can leverage key material that resides outside of the target environment. The following diagram illustrates logical flow of a potential implementation.

Note that in the above example, our destination for off-target key material retrieval is not decrypted until we have validated that we are on the correct target. This is beneficial in that reverse engineering this value on non-targeted assets should be non-trivial.

Retrieval Mechanisms

When implementing the retrieval mechanism, it would be ideal to leverage something that is unlikely to be blocked or otherwise filtered by perimeter controls. The following are some high-level examples for consideration.

HTTP(S)

Overview The implant loader can issue an HTTP request to a server under our control. The request should have some kind of token value for identification and rudimentary authentication. The server responds with some data that is used as input to the key generation material.

Limitations While we are likely to find HTTP(S) protocols to be allowed outbound, we have to contend with other possible perimeter controls such as URL filtering, SSL/TLS decapsulation, and layer 7 inspection. Our communication structure and patterning could be, depending on implementation, easy to signature.

DNS

Overview The implant loader can issue an DNS resolution request to a DNS server under out control. The implant loader can leverage pseudo-random sub-domains as our mechanism of identification and rudimentary authentication. The server responds with key generation material input through, for example, the DNS response’s Answers section.

Limitations This approach will require standing up and configuring a DNS server to facilitate the required responses.

Incidental Benefits of Using Off-Target Key Material

Whenever we leverage off-target key material we gain incidental benefits in addition to on-disk payload protection. For example, we could configure our server side to only emit the key material once. This will ensure that any subsequent attempts to load the implant will fail. Such an implementation would be beneficial for implants that are intended for single-use scenarios.

Additionally, the key material can act as a kill-switch for the implant loader. Whenever the key material is unavailable, the payload will not be deployed. Of course this behavior may be used to prevent payload’s from executing; for this reason it is strongly suggested to use unique domain names per instance.