Hunting RATs by their own certificates 🕵️

Our colleagues at Censys published a breakdown of the AsyncRAT family, describing an entire genealogical tree: AsyncRAT → DCRAT (DarkCrystal RAT) → VenomRAT → dozens more forks all the way down to LMTeamRAT, Alfa Red Fox, EchoRAT, Gh0stRAT (not to be confused with the original Gh0st RAT from 2008), and so on. In total, they counted around 40 named variants, 13 of which had live C2 infrastructure at the time of the research.

The key takeaway of their research: forks almost never rewrite the TLS certificate of the server inherited from the parent. DCRAT brought into the family the structure O=<Name> By <author>, L=SH, C=CN, and this is inherited all the way down to the smallest descendants — even if the build itself is no longer branded in any other way. It is this pattern that Censys calls the most reliable signal for the entire lineage, regardless of the specific variant.

We, the network forensics department of the antivirus lab, already had experience detecting VenomRAT by its default certificate, and we even contributed a Suricata signature to the community as part of the PT Rules project.

That is exactly why this research, naturally, caught our attention — and we decided to run similar logic not against an internet scan, but against traffic from our own sandboxes: what if we missed something?

We took our favorite NTA and ran the following query in it (an equivalent hunt can be done anywhere, even in a database):

tls.server_cert.subject.value ~ "*RAT*" 
&& !tls.server_cert.subject.value ~ "*CORPORAT*" 
&& !tls.server_cert.subject.value ~ "*INTEGRAT*"

(the exclusions are needed because corporated, corporation, or integrator will also happily match on *RAT* — hello, false positives)

The result was genuinely interesting: besides the aforementioned VenomRAT, a bunch of other C2 servers literally sign themselves.

For example, the progenitor AsyncRAT is not shy about signing itself as AsyncRAT Server:

PureRAT pretends to be PureRAT Agent:

LiberiumRAT signed itself a certificate under the name Liberium RAT Authority:

A number of other, lesser-known samples all happily advertise their purpose right in the certificate.

How to detect in Suricata?

Similarly to our VenomRAT rule, you can key on the bytes |3082| — they appear at the start of the certificate, then |550403| — this is the encoded ASN.1 Object ID 2.5.4.3 (id-at-commonName), and finally — the target string, for example:

alert tls any any -> any any (msg: "REMOTE [PTsecurity] LiberiumRAT SSL certificate"; flow: established, from_server; content: "|3082|"; depth: 300; content: "|550403|"; depth: 600; content: "Liberium RAT"; distance: 2; within: 12; classtype: trojan-activity; sid: 1; rev: 1;)

And how to hunt, what to look at:

• Issuer/Subject of the form CN=.*RAT.* — as seen above, it works perfectly.
• The combination L=SH, C=CN + O=* By * on a non-standard port.
• Self-signed certificates in general — malware C2, unlike phishing sites, is not afraid of browser errors, so self-signing is used en masse.
• Signs of default generation — empty O/L/ST, CN duplicated in SAN or Issuer — CN=example.com, O=Acme.

From the history of the issue — a similar trick was pulled back in 2023 with Quasar RAT: there, the default certificate CN=Quasar Server CA via Shodan/Censys led researchers straight to 60+ live servers. Nuff said.

The moral: a TLS certificate, when present of course, is metadata that remains in the clear even when all the rest of the traffic is encrypted. For some reason, the authors of RAT builders regularly forget about this 🙂

Happy hunting!

#TI #malware #RAT #C2 #tls #detect #suricata
@ptescalator