Reversing PebbleDash’s FakeTLS Protocol

So I was looking through the CISA’s recent publications regarding three tools named PebbleDash[1], Copperhedge[2] and Taintedscribe[3] which are believed to be used by the state-sponsored North Korean hacking group HiddenCobra/APT 38/Lazarus Group.

I started off with PebbleDash, because there was a functionality mentioned in the report that caught my eye:

source https://www.us-cert.gov/ncas/analysis-reports/ar20-133c

I wanted to know how such FakeTLS mechanism works and how it is implemented. I also want to mention beforehand, I did not check wether the code used by PebbleDash is reused from any Github Repository or any other various tools. This blog post focuses mainly on the mentioned functionality.

PebbleDash

PebbleDash is a RemoteAccessTool and is in my opinion, built rather simple but effective. For obfuscation, it implements routines to load libraries during execution and encrypts parts of its content with a custom algorithm. As always with RAT tools, it offers its controllers a variety of options to cause mayhem on a victim’s system:

Graph overview of PebbleDash’s jumptable

I will not go deeper into the functionalities of this tool this time. If you are interested in reading more, I recommend you to take a look at the CISA report I’ve linked above… or reverse it by yourself :-).

Faking the TLS Handshake

Transport Layer Security[4][5] is an encryption protocol used for securing data transfer via the internet and in order to establish a valid TLS communication, a TLS handshake must be processed. PebbleDash uses this protocol scheme to stay under the radar and hide the C2 communication.
The following graphic is a small reminder of how the TLS handshake is done and explains how this is accomplished:

In the first step, a simple connect is executed which sets up a TCP connection to the C2 server.
Instead of sending the the real server’s domain, the server name field in the TLS packet is adjusted to a popular domain you encounter pretty often in a company’s network.

Fake server name in TLS packet

The list of domains it can enter into this field is hardcoded into the binary and is selected randomly:

  • amazon.com
  • apple.com
  • avast.com
  • avira.com
  • baidu.com
  • bing.com
  • dell.com
  • linkedin.com
  • microsoft.com
  • paypal.com
  • uc.com
  • wikipedia.org
  • yahoo.com

The server certificate, as well as the other packets which are sent back to are not relevant for the sample.

Reversing the implementation

PebbleDash implements various checks wether it received valid TLS packet from the C2 server. I’ve identified at least the following:

  • TLS Record Content Type has to be valid for each step of the TLS handshake
  • TLS version has to be 1.0 (0x301)

Once the TLS handshake is done, the communication continues in the TLS format. Instead of using TRIPLE DES, DES or AES the malware uses the RC4 protocol for encrypting its messages. The RC4 is hardcoded into the binary and easily extractable.

Hardcoded RC4 found in binary

With all these information available, I was able to implement a python server which can fake the TLS handshake and decrypt received messages in my internal network. If anybody is interested in the source code, I am willing to share it. Just message me on Twitter.

PebbleDash C2 server reimplementation

Final Words

It was pretty interesting to see how this FakeTLS mechanism is implemented and it really sharpened my skills regarding network protocols. I think I’ve never went so deep into the single headers and features of the TLS protocol. Next time I might look into the other two families which were mentioned in the CISA report.

Icons made by Freepik from www.flaticon.com

Scroll to Top