Blog
-

7 min read

C2 Server Hunting: Empowering Threat Intelligence with Nuclei Templates

Nuclei & Templates
C2 Server Hunting: Empowering Threat Intelligence with Nuclei Templates

Authors

Prithiv
Prithiv

Share

Introduction

We are excited to announce the release of Nuclei Templates v9.5.8, which brings with it a comprehensive collection of C2 server detection templates. In this blog, we will delve into the world of C2 server detection over the internet. C2 servers, also known as Command and Control servers, play a pivotal role in the command and control infrastructure utilized in cyber attacks, including botnets. Acting as a centralized communication hub, C2 servers facilitate communication between attackers and compromised devices, commonly referred to as "bots" or "zombies."

By exploring various methodologies and leveraging threat hunting techniques, we aim to provide insights into the detection of C2 servers. Our focus lies on developing Nuclei templates to enhance the threat hunting process.

Detecting C2 servers is a challenge due to the ever-evolving techniques employed by attackers. However, security professionals and researchers utilize various approaches to identify these malicious servers. Here are some common methods:

  1. Network Traffic Analysis: Analyzing network traffic patterns for suspicious communication and anomalies.
  2. Signature-based Detection: Utilizing known signatures or patterns associated with C2 activity.
  3. DNS Monitoring: Monitoring DNS queries and responses to identify potential C2 server connections.
  4. Behavioral Analysis: Examining abnormal behaviors and communication patterns to detect C2 activity.
  5. Malware Analysis: Analyzing malware samples to identify indicators of C2 server communication.

These are all important and valid ways of detecting C2 servers. We hope to be able to add to your security arsenal and help you explore enhancing your threat hunting process by including Nuclei templates in your workflow.

Detecting C2 Servers with Nuclei

We'll cover three ways of identifying C2 servers with Nuclei:

  1. Default SSL Certificates: Identifying C2 servers through default SSL certificates
  2. Body Hash: Calculating cryptographic hashes of response bodies to detect known C2 server signatures.
  3. JARM: Analyzing server fingerprints generated during the TLS handshake to uncover C2 servers.

Default SSL Certificates:

Default SSL certificates are commonly used in scenarios where devices or software need to initiate secure communication immediately without requiring users to obtain and install their own SSL certificates. These certificates are often found in various network devices such as routers, firewalls, load balancers, and web servers.

There are various methods used to identify C2 servers. They include using default SSL certificates, including self-signed certificates and SSL serial numbers.

Detecting a Cobalt Strike C2 server using a default SSL certificate:

Cobalt Strike servers come with a default certificate that displays specific values for the serial number, the issuer, the subject, and the certificate validity. We can use Nuclei templates to find these specific values. If the SSL Certificate Serial is 146473198 it is likely a Cobalt Strike Server. We can use tlsx to get the SSL serial number of a server.

Target: 110.40.184.247

Next, the DSL helper function contains() can be used here to match serial numbers

Matcher Syntax:

yaml

1
matchers:
2
      - type: dsl
3
        dsl:
4
          - 'contains(serial,"08:BB:00:EE")'

Final Template:

yaml

1
id: cobalt-strike-c2
2


3
info:
4
  name: Cobalt Strike C2 - Detect
5
  author: pussycat0x
6
  severity: info
7
  description: |
8
     Cobalt Strike gives you a post-exploitation agent and covert channels to emulate a quiet long-term embedded actor in your customer's network.
9
  reference:
10
    - https://blog.sekoia.io/hunting-and-detecting-cobalt-strike/
11
  metadata:
12
    max-request: 1
13
    verified: "true"
14
    shodan-query: ssl.cert.serial:146473198
15
  tags: ssl,c2,ir,osint
16


17
ssl:
18
  - address: "{{Host}}:{{Port}}"
19


20
    matchers:
21
      - type: dsl
22
        dsl:
23
          - 'contains(serial,"08:BB:00:EE")'
24


25
    extractors:
26
      - type: json
27
        json:
28
          - ".serial"

Detecting Asyncrat C2 with CNAME

Here is another example template to Detect Asyncrat C2 using Common Name (CNAME). Asyncrat is a malware remote access tool. You can confirm a server is using Asyncrat if the SSL Certificate Issuer CN (part: issuer_cn) contains the phrase AsyncRAT Server.

Let’s use tlsx again for getting issuer_cn

Command: echo 85.206.172.156:444 | ./tlsx -cn -j

Target: 85.206.172.156:444

Matcher Syntax:

yaml

1
matchers:
2
      - type: word
3
        part: issuer_cn
4
        words:
5
          - "AsyncRAT Server"

Final Template:

yaml

1
id: asyncrat-c2
2


3
info:
4
  name: AsyncRAT C2 - Detect
5
  author: johnk3r
6
  severity: info
7
  description: |
8
    AsyncRAT is a Remote Access Tool (RAT) designed to remotely monitor and control other computers through a secure encrypted connection. It is an open source remote administration tool, however, it could also be used maliciously because it provides functionality such as keylogger, remote desktop control, and many other functions that may cause harm to the victim’s computer. In addition, AsyncRAT can be delivered via various methods such as spear-phishing, malvertising, exploit kit and other techniques.
9
  reference: |
10
    https://malpedia.caad.fkie.fraunhofer.de/details/win.asyncrat
11
  metadata:
12
    max-request: 1
13
    verified: "true"
14
    shodan-query: ssl:"AsyncRAT Server"
15
    censys-query: services.tls.certificates.leaf_data.issuer.common_name:AsyncRat
16
  tags: c2,ir,osint,malware
17


18
ssl:
19
  - address: "{{Host}}:{{Port}}"
20


21
    matchers:
22
      - type: word
23
        part: issuer_cn
24
        words:
25
          - "AsyncRAT Server"
26


27
    extractors:
28
      - type: json
29
        json:
30
          - " .issuer_cn"

Body Hashes:

Hashing the response body involves calculating a cryptographic hash value from the content of the server's response before it is sent back to the client. By comparing these hashed response bodies, we can detect potential C2 servers. We can use httpx to generate a response body hashed with different algorithms.

We can use -hash argument to generate a body response from host. Here we generated a sha1 body response.

We can use the DSL helper function sha1() with the body element to match the response body hash.

Matchers Syntax:

yaml

1
matchers:
2
      - type: dsl
3
        dsl:
4
          - "("XXXXXXX" == sha1(body))"

We can use this in the detection of Brute Ratel 4 servers. Let’s insert this matcher into a template.

Final Template:

yaml

1
id: brute-ratel-c4
2


3
info:
4
  name: Brute Ratel C4 - Detect
5
  author: pussycat0x
6
  severity: info
7
  description: |
8
    Brute Ratel C4 (BRc4) is a legit red-teaming tool designed from the ground up with evasion capabilities in mind, but in the wrong hands can cause significant damage. Learn how to protect your organization with our Brute Ratel C4 Spotlight.
9
  reference:
10
    - https://bruteratel.com/
11
  metadata:
12
    verified: "true"
13
    shodan-query: http.html_hash:-1957161625
14
  tags: c2,bruteratel,c4
15


16
http:
17
  - method: GET
18
    path:
19
      - "{{BaseURL}}"
20


21
    matchers-condition: and
22
    matchers:
23
      - type: dsl
24
        dsl:
25
          - "(\"1a279f5df4103743b823ec2a6a08436fdf63fe30\" == sha1(body))"
26
        condition: and

JARM:

JARM is a technique that analyzes the server's TLS handshake process, focusing on various aspects such as cipher suite ordering, extensions, and their values to generate a fingerprint for the server. By comparing these fingerprints, we can identify potential C2 servers. Tlsx’s JARM argument can be used to get the JARM fingerprint for a target.

In this template, the jarm() - helper can be used to fetch JARM hashes from target host.

Jarm uses lots of probes, hence it might be implemented as a helper function like jarm() to minimize the execution time, and the result should be stored in some internal kv cache to avoid recalculating it multiple times.

The jarm helper will calculate the TLS finger print value of Hostname and it’s condition with our predefined JARM Value.

Matchers Syntax:

yaml

1
matchers:
2
      - type: dsl
3
        dsl:
4
          - "jarm(Hostname) == 'xxxxxxxx'"

To prevent false positives, we've opted for the TCP protocol over HTTP when utilizing JARM. To achieve this, we'll be transmitting placeholder data to the remote host. Meanwhile, the engine will process and store the hash results, which will later be cross-referenced with our template for validation. Finally, we convert the data into a hex value.

yaml

1
- inputs:
2
      - data: 2E
3
        type: hex

JARM being used to detect a Cobalt Strike C2 server.

Final Template:

yaml

1
id: cobalt-strike-c2-jarm
2


3
info:
4
  name: Cobalt Strike C2 JARM - Detect
5
  author: pussycat0x
6
  severity: info
7
  description: |
8
     Cobalt Strike gives you a post-exploitation agent and covert channels to emulate a quiet long-term embedded actor in your customer's network.
9
  reference:
10
    - https://blog.sekoia.io/hunting-and-detecting-cobalt-strike/
11
  metadata:
12
    verified: true
13
    shodan-query: ssl.jarm:07d14d16d21d21d07c42d41d00041d24a458a375eef0c576d23a7bab9a9fb1+port:443
14
  tags: jarm,c2,ir,osint
15


16
tcp:
17
  - inputs:
18
      - data: 2E
19
        type: hex
20


21
    host:
22
      - "{{Hostname}}"
23


24
    matchers:
25
      - type: dsl
26
        dsl:
27
          - "jarm(Hostname) == '07d14d16d21d21d07c42d41d00041d24a458a375eef0c576d23a7bab9a9fb1'"

Conclusion

C2 server detection is crucial for identifying and mitigating cyber threats. Nuclei templates offer a powerful and flexible framework to enhance the threat hunting process. By using various detection techniques like default SSL certificates, body hashes, and JARM, security professionals can efficiently identify potential C2 servers and take appropriate actions to protect their systems and networks.

We encourage the community to actively contribute to the Nuclei templates repository (https://github.com/projectdiscovery/nuclei-templates/tree/main/ssl/c2). Encouraging open collaboration ensures that the community benefits from diverse perspectives and expertise, leading to more effective and innovative solutions. By sharing new and updated templates, we can collectively strengthen threat intelligence and improve the overall security posture against C2 servers. Let's collaborate and make the internet a safer place for everyone. Happy hunting!

We are excited to announce the release of Nuclei Templates v9.5.8