Sleeping With the Phishes

PHISHING SCHOOL

Hiding C2 With Stealthy Callback Channels

Write a custom command and control (C2) implant — Check ✅

Test it on your system — Check ✅

Test it in a lab against your client’s endpoint detection and response (EDR) product — Check ✅

Convince a target to download the payload — Check ✅

Get your hard earned shell… — Nada! Nil! Goose Egg! ❌

What happened?

If we’ve written a custom implant, and even taken precautions to test it against the same EDR, then we can be reasonably assured that the payload executed. The only remaining explanation as to why you didn’t receive a callback is that the outbound communication must have been blocked. Your poor shell is alive and well, but it’s crying out for help and can’t find its way home.

How can we avoid such a tragedy?

What is Stealthy, Anyway?

When it comes to network traffic, the best approach we can take to remain “stealthy” is to try to blend in with existing traffic. By far, HTTP(S) is the most popular callback method for beaconing malware for three reasons:

  1. It’s easy to implement — Simple, text-based, flexible protocol with many available libraries
  2. It’s likely to be open outbound — Browser-based workflows necessitate HTTP(S) outbound
  3. There is a ton of existing traffic — Our traffic will be a needle in a haystack

As long as the contents of our HTTP(S) messages look similar to real web traffic (a.k.a., our “C2 profile”) then we should be able to blend in and remain “stealthy”. But, there is a catch:

“Everything is stealthy until someone is looking for it.”— @tifkin_

However you chose to structure your messages, there may be telltales that could give away your particular brand of malware in the future. If you don’t write your own C2 profile and just use an open-source one, then it is likely that some security products have already fingerprinted your malware’s communication style.

In addition to fingerprinting C2 profiles, network defenders have a few more ways to block a lot of unknown malicious traffic, and cause a headache for red teams:

  1. Blocking traffic to new or uncategorized domains
  2. Blo

    […]
    Content was cut in order to protect the source.Please visit the source for the rest of the article.

    This article has been indexed from Security Boulevard

    Read the original article: