Unmasking BitRAT's C2 over HTTPS

BitRAT is a potent and versatile Remote Access Trojan (RAT) commonly sold on underground forums. Its popularity stems from a robust feature set and an emphasis on stealth, allowing it to evade detection by hiding command-and-control (C2) communications over seemingly benign protocols. This makes traditional detection methods more challenging. By examining the subtle artifacts it leaves behind, even in encrypted traffic, defenders can expose these elusive threats.

This article explains how Corelight detects BitRAT's C2 activity by focusing on a common misconfiguration: its use of a default SSL certificate.

Background

Malware analysis sandboxes like ANY.RUN provide invaluable insights into attacker techniques. As seen in the PCAPs below, a recurring observation in analyses of BitRAT samples is the malware's reliance on HTTPS for C2 communications. While the traffic payload is encrypted, the SSL certificate used by the C2 server can often contain plaintext strings that betray its identity.

Attackers often use simple, default certificates generated by the malware itself, which are not trusted by legitimate certificate authorities. By analyzing several BitRAT samples, security researchers at Corelight Labs found that these certificates contain a distinct string in their subject and issuer fields. The presence of these specific strings allows us to identify the malicious server, even with encrypted communications.

This technique is a core component of the MITRE ATT&CK^® tactic for Application Layer Protocol (T1071), which adversaries use to communicate over standard protocols.

Some ANY.RUN samples we examined were:

• https://app.any.run/tasks/f3b96bf6-159d-4068-b9c1-5e09f506e273 (This is the PCAP used in the examples below)
• https://app.any.run/tasks/813f38cf-8434-4de7-8b56-46ad388e7355

By analyzing the x509.log, which records comprehensive details about authentication certificates, we observed that the malware's C2 server frequently uses a default SSL certificate. This certificate explicitly identifies the server as a BitRAT malware C2, making its malicious purpose evident. In the example x509.log below, generated from the PCAP you can download in the first ANY.RUN link above, you can see the server subject and issuer contain the string "CN=BitRAT". This lack of OPSEC is a critical error on the part of the attackers. The commoditized nature of the BitRAT framework means that attackers are often simply using the code without understanding its inner workings or taking steps to customize it, creating a high-fidelity detection opportunity.

% zeek -Cr f3b96bf6-159d-4068-b9c1-5e09f506e273.pcap
% cat x509.log
#separator \x09
#set_separator ,
#empty_field (empty)
#unset_field -
#path x509
#open 2025-08-27-15-12-24
#fields ts fingerprint certificate.version certificate.serial certificate.subject certificate.issuer certificate.not_valid_before certificate.not_valid_after certificate.key_alg certificate.sig_alg certificate.key_type certificate.key_length certificate.exponent certificate.curve san.dns san.uri san.email san.ip basic_constraints.ca basic_constraints.path_len host_cert client_cert
#types time string count string string string time time string string string count string string vector[string] vector[string] vector[string] vector[addr] bool count bool bool
1753421551.072256 fd66a63700dcafe347df4e517033797be0e1476cdf342f4bbb8cd1cfc079 1 2933085 E8A6E4ECEC3A44B380CA58F5D9B8AC CN=login.live.com,O=Microsoft Corporation,L=Redmond,ST=Washington,C=US CN=DigiCert SHA2 Secure Server CA,O=DigiCert Inc,C=US 1752642000.000000 1768629599.000000 rsaEncryption sha256WithRSAEncryption rsa 2048 65537 - login.live.com,*.login.live.com - - - F T F
1753421641.066168 b9140c6646de2bf2d7f818b67022cf3335bbaf11020e167b6f57b0766dac6f2d 3 E387C8D09042F5345AABBDE5E157C1 CN=BitRAT CN=BitRAT 1647064800.000000 4.7711988e+09 rsaEncryption sha256WithRSAEncryption rsa 2048 65537 - - - - - T T F
#close 2025-08-27-15-12-24

After examining multiple samples on ANY.RUN and reviewing the referenced source code, we identified the following two strings commonly associated with the default SSL certificates used by BitRAT's C2 servers:

• "BitRAT"
• "bitrat server"

We can leverage the use of the default SSL certificate on the C2 server as a key detection point to uncover BitRAT infections, despite the challenge of HTTPS-encrypted traffic.

Historical plaintext log searches

If you're a Zeek user, you can quickly search your historical logs for evidence of BitRAT by examining the x509.log and ssl.log files. The x509.log captures detailed information about every certificate observed on the network.

A simple way to detect suspicious certificate traffic is to look for connections where the certificate subject or issuer contains a known BitRAT-related string. The following command searches compressed Zeek logs for certificates containing the string "bitrat".

find /data/logs/ -name "x509*.gz" -exec zcat {} \; | zeek-cut -d 'ts' 'certificate.subject' 'certificate.issuer' 'fingerprint' | egrep -i "bitrat"

Once you find a match in the x509.logs, you can match the x509 certificate fingerprint to the fingerprints listed in the SSL logs to find the connection specifics. In the example PCAP above, we saw that the fingerprint is "b9140c664..", so we can search for this in the ssl.log as shown below:

% grep “b9140c664” 
ssl.log 
1753421641.017961 CCGdZm4OuMNdc74TWj 192.168.100.9 49834 45.134.225.90 7100 TLSv12 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - - F - - T CsxknGIi b9140c6646de2bf2d7f818b67022cf3335bbaf11020e167b6f57b0766dac6f2d (empty) - 

The log above tells us that the connection was 192.168.100.9:49834 ⟹ 45.134.225.90:7100

SIEM searches

If your logs are stored in a SIEM like CrowdStrike's LogScale, you can perform the same analysis with a simple query that looks for x509 events where the certificate subject or issuer contains one of the known strings:

#path=x509 and (  
 certificate.issuer = /BitRAT|bitrat Server/i or  
 certificate.subject = /BitRAT|bitrat Server/i  
 ) 

The following screenshot shows the Zeek logs identified by this SIEM query:

This query first filters for certificate logs, then checks for the BitRAT-related strings in a case-insensitive manner, highlighting the certificates that match our detection pattern.

Zeek code

For real-time detection, a custom Zeek script can monitor SSL/TLS traffic and generate a notice when a potential BitRAT C2 is identified. The following script uses the ssl_established event to inspect the SSL certificate and alert on any traffic that matches the predefined regular expression.

The code above handles the ssl_established event. You can find the regular expression used to match the SSL certificate issuer or subject on line 11:

global bitrat_re = /(bitrat Server|BitRAT)/i; 

If this regular expression is found in the SSL certificate issuer (line 19) or subject (line 20), Zeek will generate the appropriate notice on line 30. Putting this all together and running it on our example PCAP generates the following notice.log:

% zeek -Cr f3b96bf6-159d-4068-b9c1-5e09f506e273.pcap bitrat-detector 
 
% cat notice.log 
#separator \x09 
#set_separator , 
#empty_field (empty) 
#unset_field - 
#path notice 
#open 2025-08-27-15-12-24 
#fields ts uid id.orig_h id.orig_p id.resp_h id.resp_p fuid file_mime_type file_desc proto note msg sub src dst p n peer_descr actions email_dest suppress_for remote_location.country_code remote_location.region remote_location.city remote_location.latitude remote_location.longitude 
#types time string addr port addr port string string string enum enum string string addr addr port count string set[enum] set[string] interval string string string double double 
1753421641.124153 CCGdZm4OuMNdc74TWj 192.168.100.9 49834 45.134.225.90 7100 - - - tcp BitRAT::C2_Traffic_Observed Potential BitRAT C2 discovered via a default SSL certificate. Cert Fingerprints: [b9140c6646de2bf2d7f818b67022cf3335bbaf11020e167b6f57b0766dac6f2d] Issuer: CN=BitRAT 192.168.100.9 45.134.225.90 7100 - - Notice::ACTION_LOG (empty) 3600.000000 - - - - - 
#close 2025-08-27-15-12-24 

You can see that the regular expression was found in the SSL certificate's issuer for this PCAP.

Suricata^® rules

You can also use Suricata signatures to detect this type of activity. The following rule detects suspicious strings in the TLS certificate's subject and issuer fields.

## BitRAT 

# TLS certificate with CN=BitRAT in subject or issuer 

alert tls $EXTERNAL_NET any -> $HOME_NET any (msg:"CORELIGHT MALWARE BitRAT Style TLS Certificate Inbound"; flow:established,to_client; tls.cert_subject; content:"CN=BitRAT"; nocase; tls.cert_issuer;  content:"CN=BitRAT"; nocase; reference:url,any.run/malware-trends/bitrat; classtype:trojan-activity; sid:3000068; rev:1;) 

This rule is a great starting point for detecting BitRAT, as it's simple yet effective. It instructs Suricata to inspect both the subject and issuer fields of the TLS certificate for the string "CN=BitRAT". The nocase modifier makes the search case-insensitive.

Conclusion

When attackers employ commoditized frameworks without understanding their elements, they may fail to customize the components, resulting in the use of a default SSL certificate. This lack of customization is a key indicator. The server literally announces itself as a component of the BitRAT malware framework, a behavior security teams can leverage for high-fidelity detection.

For more insights into threat detection and mitigation, we recommend checking out Corelight's resources and the broader open-source security community.