Building Towards a Proactive Secure Future

Ingesting STIX2#

There are a lot of feeds for STIX2 that are publicly available. You can find a list in this Reddit post: https://www.reddit.com/r/cybersecurity/comments/q38qvz/looking_for_free_stixtaxii_threat_intelligence/.

For our example we’ll use one from The Computer Incident Response Center Luxembourg (CIRCL). The feed can be found here. For example, have a look at this feed.

You can copy the JSON data in ChatGPT and ask it to explain it to you.

Explain the STIX2 signature below:
[Signature pasted here]

Here’s the response:

This JSON object represents a STIX (Structured Threat Information eXpression) report within a MISP (Malware Information Sharing Platform) format. It provides structured information about an OSINT (Open Source Intelligence) event, detailing a specific attack involving BazarBackdoor, Ryuk ransomware, and Cobalt Strike. Here's a breakdown:
Event Metadata:

    Analysis Level (2): Indicates the level of confidence or assessment regarding the event (usually ranges from 0 to 3 in MISP).
    Date (2020-11-09): Date of the event report.
    Info: A brief description of the event, mentioning how the BazarBackdoor was used to deploy Ryuk ransomware, via Cobalt Strike.
    Threat Level ID (1): This likely maps to a scale indicating the severity or priority of the threat. In many cases, "1" represents a high-level threat.
    Orgc (CIRCL): CIRCL (Computer Incident Response Center Luxembourg) is the organization that reported this event.
    Tags:
        misp-galaxy
        ="Ryuk ransomware": This tag identifies Ryuk ransomware as part of the event.
        misp-galaxy
        ="Cobalt Strike": This tag indicates the use of Cobalt Strike, a known post-exploitation tool.
        type:OSINT: The event is based on open-source intelligence.
        osint
        ="perpetual": The information is valid indefinitely.
        osint
        ="50": Represents a 50% certainty about the provided information.
        tlp:white: Traffic Light Protocol tag specifying that the information is public and can be shared freely.

Attributes (Indicators of Compromise - IoCs):

    Domains (under Network Activity category): The listed domains (e.g., check1domains.com, sweetmonsterr.com) are associated with malicious activity related to the BazarBackdoor or Ryuk ransomware.
    Link (under External Analysis category): A reference to an external analysis on the attack: Advanced Intel.

Key Aspects:

    Purpose: The report helps cybersecurity professionals and organizations recognize malicious domains related to BazarBackdoor and the Ryuk ransomware attack vector.
    Indicators to Block: The domains mentioned should be considered for blocking or further investigation in network defense systems.

This signature aids in detecting and preventing attacks that may exploit similar infrastructure or tactics.

From there you have a choice to turn this into a Sigma rule.

Turn this into a Sigma rule yml

Here’s the response:

title: Detection of Malicious Domains Related to BazarBackdoor and Ryuk Ransomware
id: 0fadc113-6e22-4524-96b1-7b8fc98fa64c
description: |
  Detect network communication to domains associated with BazarBackdoor and Ryuk ransomware, as identified in OSINT report from CIRCL.
author: CIRCL
date: 2020-11-09
status: experimental
logsource:
  category: network
  product: any
detection:
  selection:
    dns_query:
      - 'check1domains.com'
      - 'sweetmonsterr.com'
      - 'qascker.com'
      - 'remotessa.com'
      - 'havemosts.com'
      - 'unlockwsa.com'
      - 'sobcase.com'
      - 'zhameharden.com'
      - 'mixunderax.com'
      - 'bugsbunnyy.com'
      - 'fastbloodhunter.com'
      - 'serviceboosterr.com'
      - 'servicewikii.com'
      - 'secondlivve.com'
      - 'luckyhunterrs.com'
      - 'wodemayaa.com'
      - 'hybriqdjs.com'
      - 'gunsdrag.com'
      - 'gungameon.com'
      - 'servicemount.com'
      - 'servicesupdater.com'
      - 'service-boosterr.com'
      - 'serviceupdatter.com'
      - 'dotmaingame.com'
  condition: selection
fields:
  - dns_query
  - src_ip
  - dest_ip
  - timestamp
level: high
tags:
  - attack.t1071.001
  - attack.t1071.004
  - ransomware.ryuk
  - cobaltstrike
  - osint
references:
  - https://www.advanced-intel.com/post/anatomy-of-attack-inside-bazarbackdoor-to-ryuk-ransomware-one-group-via-cobalt-strike
  - https://www.circl.lu/

You can save it and then import it into Opensearch Dashboards.

Creating custom alerts#

Sigma rules are great when a rule already exists. For a quick, targeted alert you can also write your own monitor. Here we’ll alert whenever a device on the network looks up one of the domains from the CIRCL report.

1. Go to OpenSearch Dashboards > Alerting.
2. Click Create monitor.
3. Set the name to “Malicious Domain DNS Query”.
4. Choose the monitor type “Per query monitor”.
5. For the defining method choose “Extraction query editor”. As an alternative you can use the “Visual editor”.
6. Select the index logstash*.
7. Write a query that matches DNS queries for any of the domains from the last 10 minutes, e.g.,:

{
  "size": 0,
  "query": {
    "bool": {
      "filter": [
        { "term": { "event_type.keyword": "dns" } },
        { "term": { "dns.type.keyword": "query" } },
        { "terms": { "dns.rrname.keyword": ["check1domains.com", "sweetmonsterr.com", "qascker.com"] } },
        {
          "range": {
            "@timestamp": {
              "gte": "{{period_end}}||-10m",
              "lte": "{{period_end}}",
              "format": "epoch_millis"
            }
          }
        }
      ]
    }
  }
}

Add the rest of the domains from the Sigma rule above to the list. A DNS record can only contain one domain, so the domains are alternatives to each other: terms matches any of them. 8. Click “Run” to make sure the query executes without errors. 9. Click “Add trigger” and set a name (e.g., “Malicious domain seen”) and a severity. 10. Set the trigger condition to fire when the query matches:

ctx.results[0].hits.total.value > 0

11. Save the monitor. We’ll attach a notification to it in the Setting up alerts section.

Alert correlation#

You know how you can filter records based on a bunch of criteria? Well what if you could filter on the basis of two or more records in order to get an alert. In other words, have criteria that apply across multiple records but within a time window. If I see SSH connections for an IP and also attempts to connect to port 80 (HTTP) within 5 minutes, I want an alert. This can be a useful alert in case someone is probing, for example, your router (from within usually).

1. Go to OpenSearch Dashboards > Alerting.
2. Click Correlations
3. Click Create correlation rule.
4. Name it: SSH and HTTP connection attempts.
5. Set “index” for “Data source 1” as logstash (you can use the alias for this, just click on any), and log type as “network”.
6. Then the field is dest_port with value 22, and dest_ip with value 192.168.0.1.
7. Set “index” for “Data source 2” as logstash (you can use the alias for this, just click on any), and log type as “network”.
8. Then the field is dest_port with value 80, and dest_ip with value 192.168.0.1.
9. Then, add alert trigger and give it a name.
10. Click on “Create correlation rule”.

To find out if it works (replace 192.168.0.1 with your own router’s IP if it differs), attempt to connect to the IP via http and even be explicit about the port http://192.168.0.1:80. Then open PuTTY or a terminal if you are on Linux or Mac, and attempt to connect to 192.168.0.1 via SSH.

ssh 192.168.0.1

It doesn’t matter if the IP has these services available. The NetFlow record will be created and the alert will be triggered.

Give it a minute and then you should see in the Overview under Security Analytics a new alert.

Anomaly detection#

While looking at time series to detect anomalies is useful, automating the process is even better.

1. Go to OpenSearch Dashboards > Anomaly Detection.
2. Click Create detector.
3. Give it a name (“AnomalyBytes”) and description: “Anomaly detection for total bytes”.
4. Set the index pattern to “logstash-*” or just the alias “logstash”.
5. Add filter: event_type.keyword:flow.
6. Set the time field to @timestamp.
7. Click “Next”.
8. Set feature name as: Bytes.
9. Set the field to flow.total_bytes.
10. Click “Next” and create the detector.

From there the detector will initialize. You have also the option to hit the “Historical Analysis” tab to have it run against the historical data to find anomalies. Notice that you have not setup any alerts for the anomaly detector. This means that you can see for anomalies in the dashboard but won’t be notified by them. To be notified you have to setup alerts.

Setting up alerts#

Monitors, correlation rules, and anomaly detectors only show their results inside OpenSearch Dashboards until you tell them where to send a notification. In this section you’ll create a notification channel and then connect it to everything you built in this chapter.

Creating a notification channel#

1. Go to OpenSearch Dashboards > Notifications.
2. Click on “Channels” and then “Create channel”.
3. Name the channel (e.g., “Security alerts”). Then, choose the type of channel you want to create, e.g., “Slack” or “Custom webhook” (which also works for Discord, Microsoft Teams, and similar services).
4. Paste the webhook URL that your chat service gave you.
5. Click “Send test message” and verify that the message arrives. Then click “Create”.

Email is also available but needs a little more work. You first have to create an SMTP sender under Notifications > Email senders (including adding its credentials to the OpenSearch keystore), and then a recipient group. For a home lab, a chat webhook is the quickest way to get started.

Notifications for monitors and correlation rules#

1. Open the monitor you created earlier (Alerting > Monitors > “Malicious Domain DNS Query”) and click “Edit”.
2. Scroll down to the trigger and, under “Actions”, click “Add action”.
3. Give the action a name and select the channel you created.
4. Keep the default message or edit it. It can use variables such as {{ctx.monitor.name}} and {{ctx.trigger.name}}.
5. Click “Update”.

For the correlation rule you built, add a notification the same way, from the alert trigger step of the rule.

To test the monitor, run a lookup for one of the domains from a device on your network. A DNS query is all that is needed, and your computer does not connect to the domain.

nslookup check1domains.com

Give it a minute or two. You should then see the alert in the Alerting dashboard and receive the message in your channel.

Notifications for anomaly detectors#

1. Go to OpenSearch Dashboards > Alerting and click “Create monitor”.
2. Set the name to “Anomalous traffic volume” and for the monitor defining method choose “Anomaly detector”.
3. Select the detector you created earlier (“AnomalyBytes”) and set how often the monitor should check it (e.g., every 10 minutes).
4. Add a trigger and give it a name and severity. You can leave the anomaly grade and confidence thresholds at their defaults (0.7) at first and adjust them if you get too many or too few alerts.
5. Under “Actions”, select the channel you created.
6. Click “Create”.

From now on you will be notified when the detector flags a spike in total bytes that does not match the usual pattern of your network.