Ищем RAT'ов по их же сертификатам 🕵️

Коллеги из Censys выкатили разбор семейства AsyncRAT, описав целое генеалогическое древо: AsyncRAT → DCRAT (DarkCrystal RAT) → VenomRAT → еще десятки форков вплоть до LMTeamRAT, Alfa Red Fox, EchoRAT, Gh0stRAT (не путать с оригинальным Gh0st RAT 2008 года) и т. д. Всего насчитали около 40 именованных вариантов, 13 из них — с живой C2-инфраструктурой на момент исследования.

Ключевая мысль их исследования: форки почти никогда не переписывают TLS-сертификат сервера, доставшийся от родителя. DCRAT принес в семью структуру O=<Name> By <author>, L=SH, C=CN, и это наследуется вплоть до самых мелких потомков — даже если сам билд больше никак не забрендирован. Именно этот паттерн Censys называет самым надежным сигналом для всей линейки, независимо от конкретного варианта.

У нас, отдела сетевой экспертизы антивирусной лаборатории, уже был опыт детектирования VenomRAT по его дефолтовому сертификату, и мы даже отдали в сообщество сигнатуру для Suricata в рамках проекта PT Rules.

Именно поэтому нас это исследование, само собой, зацепило — и мы решили прогнать похожую логику не по интернет-скану, а по трафику из собственных песочниц: а вдруг мы что-то упустили?

Взяли любимый NTA и сделали в нем следующий запрос (аналогичный хант можно сделать где угодно, хоть в базе данных):




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

(исключения нужны, потому что corporated, corporation или integrator тоже с радостью матчатся на *RAT* — привет, ложные срабатывания)

Результат — реально интересный: помимо вышеупомянутого VenomRAT куча других C2-серверов буквально сами себя подписывают.

Вот например прародитель AsyncRAT не стесняется подписываться как AsyncRAT Server (скриншот 1), PureRAT притворяется PureRAT Agent (скриншот 2), LiberiumRAT подписал сам себе сертификат под именем Liberium RAT Authority (скриншот 3).

Еще ряд менее известных семплов — все радостно светят своим назначением прямо в сертификате.

Как детектить в Suricata?

Аналогично нашему правилу на VenomRAT можно зацепиться за байты |3082| — встречаются в начале сертификата, далее |550403| — это закодированный ASN.1 Object ID 2.5.4.3 (id-at-commonName), и в завершение — искомая строка, например:





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;)

А как хантить, на что смотреть:

• Issuer/Subject вида CN=.*RAT.* — как видно выше, срабатывает идеально.

• Комбинация L=SH, C=CN + O=* By * на нестандартном порту.

• Самоподписанные сертификаты в целом — malware-C2, в отличие от фишинговых сайтов, не боится браузерных ошибок, поэтому самоподпись используется массово.

• Признаки дефолтной генерации — пустые O/L/ST, CN продублирован в SAN или Issuer — CN=example[.]com, O=Acme.

Из истории вопроса — похожий трюк еще в 2023 году проворачивали с Quasar RAT: там дефолтный сертификат CN=Quasar Server CA через Shodan/Censys вывел исследователей сразу на 60+ живых серверов. Nuff said.

Мораль: TLS-сертификат, при наличии, конечно, — это метаданные, которые остаются в открытом виде, даже когда весь остальной трафик зашифрован. Авторы билдеров RAT'ов почему-то регулярно об этом забывают 🙂

Happy hunting!

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