Skip to content

Cisco Secure Access - DNS

Overview

The Cisco Secure Access DNS logs show your organization's traffic through the Secure Access DNS resolvers.

  • Vendor: Cisco
  • Supported environment: Cloud
  • Detection based on: Telemetry

Warning

Important note - This format is currently in beta. We highly value your feedback to improve its performance.

Configure

This section will guide you through configuring Cisco Secure Access to forward logs to Sekoia.io using an Amazon S3 bucket, either managed by Cisco or owned by you.

Prerequisites

  • Full Admin user role in Cisco Secure Access. For more information, see the Manage Accounts documentation.
  • Access to Sekoia.io Intakes and Playbook pages with write permissions.
  • If you plan to use your own S3 bucket, administrator access to the Amazon console with permissions to create and manage S3 buckets, SQS queues, and IAM identities.

Step 1 — Configure the S3 Bucket

Cisco Secure Access can export your logs either to a Cisco-managed Amazon S3 bucket, or to an Amazon S3 bucket that you own and manage yourself.

Cisco configures all managed buckets to use Amazon Server-Side Encryption with S3-Managed Keys (SSE-S3, AES-256). Access is provided via AWS IAM credentials.

  1. In the Cisco Secure Access dashboard, navigate to Admin > Log Management.
  2. Click Set up cloud storage and select Cisco.

  3. Select a Region — choose the region closest to you to minimize latency when downloading logs.

    Warning

    The selected region cannot be changed later without deleting your current settings and starting over. Not all AWS regions are available.

  4. Select a Retention Duration — choose 7, 14, or 30 days.

    Note

    Beyond the selected time period, all data is purged and cannot be retrieved. A shorter duration is recommended if your ingestion cycle is frequent.

  5. Click Save. Cisco Secure Access activates log export to the S3 bucket. When activation is complete, the Amazon S3 Summary page appears.

  6. Copy the Access Key and Secret Key and store them in a safe place.

    Warning

    The Access Key and Secret Key are displayed only once. If you lose them, you must regenerate them by rotating the keys in Cisco Secure Access.

  7. Click Done.

Cisco Secure Access can also export logs to an Amazon S3 bucket that you own and manage. For more information, see the Enable Logging to Your Own S3 Bucket and Configure Your Own S3 Bucket Cisco documentation.

Create the S3 bucket

  1. Create a bucket in Amazon S3 to store your logs. For more information, see Amazon's S3 documentation.

    Important

    Periods (.) in the S3 bucket name and Object Lock on the S3 bucket are not supported.

  2. On the AWS console, go to your bucket, select the Permissions tab, and edit the Bucket Policy.

  3. Paste the following JSON policy, substituting bucketname with the name of your bucket, then click Save changes:

    {
  "Version": "2008-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::568526795995:user/logs"
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::bucketname/*"
    },
    {
      "Sid": "",
      "Effect": "Deny",
      "Principal": {
        "AWS": "arn:aws:iam::568526795995:user/logs"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::bucketname/*"
    },
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::568526795995:user/logs"
      },
      "Action": "s3:GetBucketLocation",
      "Resource": "arn:aws:s3:::bucketname"
    },
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::568526795995:user/logs"
      },
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::bucketname"
    }
  ]
}

Configure Cisco Secure Access

  1. In the Cisco Secure Access dashboard, navigate to Admin > Log Management > Set up cloud storage and click on the Amazon card.
  2. In the Amazon field, type or paste the exact name of the bucket you created and click Verify. Secure Access verifies your bucket, connects to it, and saves a README_FROM_UMBRELLA.txt file to your bucket.
  3. On the AWS console, open your bucket, open the README_FROM_UMBRELLA.txt file, and copy the token listed in it.
  4. Back in Cisco Secure Access, paste the token in the Token Number field and click Save.

  5. A summary page shows you the bucket name. Click Done.

    Note

    A pop-up window appears when verification is successful, confirming that your Amazon S3 bucket is now connected.

Create a SQS queue

Since you own and manage this bucket, the connector relies on S3 Event Notifications (SQS) to get new S3 objects.

  1. Create a queue in the SQS service by following this guide.

  2. In the Access Policy step, choose the advanced configuration and adapt this configuration sample with your own SQS Amazon Resource Name (ARN) (the main change is the Service directive allowing S3 bucket access):

    {
  "Version": "2008-10-17",
  "Id": "__default_policy_ID",
  "Statement": [
    {
      "Sid": "__owner_statement",
      "Effect": "Allow",
      "Principal": {
        "Service": "s3.amazonaws.com"
      },
      "Action": "SQS:SendMessage",
      "Resource": "arn:aws:sqs:XXX:XXX"
    }
  ]
}

  3. Configure an S3 Event Notification on your bucket for object creation events, using the SQS queue you just created as the destination.

    Important

    Keep in mind that you have to create the SQS queue in the same region as the S3 bucket you want to watch.

AWS Authentication Setup

Sekoia.io supports two authentication methods to access your AWS resources. Choose the one that best fits your security requirements:

Method Summary When to use
IAM Role with OIDC (Recommended) Sekoia.io assumes an IAM Role using short-lived credentials issued via OpenID Connect (OIDC). No long-lived access keys are stored. Preferred for new setups and security-conscious environments
Static Access Keys A dedicated IAM user authenticates with a static access key and secret. Existing setups or environments where OIDC federation is not available

This method uses OpenID Connect (OIDC) federation so that Sekoia.io can assume an AWS IAM Role and obtain short-lived credentials automatically. No long-lived access keys are stored in Sekoia.io.

Step 1 — Register Sekoia.io as an OIDC Identity Provider in AWS IAM

  1. Open the IAM console and navigate to Identity providers.
  2. Click Add provider and select OpenID Connect.
  3. Fill in the form:
    • Provider URL: https://app.sekoia.io/api/v1/symphony/oidc
    • Audience: sts.amazonaws.com
  4. Click Add provider to confirm.

Once created, note the Provider ARN (e.g. arn:aws:iam::XXXXXXXXXXXX:oidc-provider/app.sekoia.io/api/v1/symphony/oidc). You will need it in the steps below.

Step 2 — Create an IAM Role for Sekoia.io

  1. In the IAM console, navigate to Roles and click Create role.
  2. Select Web identity as the trusted entity type.
  3. Choose the app.sekoia.io/api/v1/symphony/oidc identity provider you just registered and set the audience to sts.amazonaws.com.

  4. Proceed to the Trust policy and replace its content with the following, substituting your AWS account ID, community UUID, and module configuration UUID:

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::XXXXXXXXXXXX:oidc-provider/app.sekoia.io/api/v1/symphony/oidc"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "app.sekoia.io/api/v1/symphony/oidc:aud": "sts.amazonaws.com"
                },
                "StringLike": {
                    "app.sekoia.io/api/v1/symphony/oidc:sub": "community:<COMMUNITY_UUID>:modconf:<MODULE_CONFIGURATION_UUID>"
                }
            }
        }
    ]
}

Step 3 — Attach a permission policy to the role

Attach an inline or managed policy granting the role read access to the SQS queue and S3 bucket:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": "arn:aws:s3:::NAME_HERE"
        },
        {
            "Effect": "Allow",
            "Action": [
                "sqs:GetQueueUrl",
                "sqs:ReceiveMessage",
                "sqs:DeleteMessage",
                "sqs:GetQueueAttributes"
            ],
            "Resource": "arn:aws:sqs:REGION_HERE:XXXXXXXXXXXX:NAME_HERE"
        }
    ]
}

Step 4 — Copy the Role ARN

After creating the role, note its ARN (e.g. arn:aws:iam::XXXXXXXXXXXX:role/ROLE_NAME). You will need it when configuring the connector in Sekoia.io.

Step 5 — Configure the Sekoia.io AWS module

In the Sekoia.io connector configuration, set the following fields:

  • AWS Region (aws_region_name): the AWS region where your resources are deployed (e.g. eu-west-1)
  • AWS Role ARN (aws_role_arn): the ARN of the role you created above

Leave the AWS Access Key and AWS Secret Access Key fields empty — they are not used with this method.

This method authenticates using a dedicated IAM user with a static AWS access key and AWS secret access key stored in Sekoia.io.

Step 1 — Create a dedicated IAM user

Create a dedicated IAM user in the IAM console and generate programmatic access credentials (AWS access key ID and AWS secret access key) for that user.

Step 2 — Attach a resource-based policy to your SQS queue and S3 bucket

Ensure that the IAM user has the following permissions on your SQS queue and S3 bucket:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sqs:ReceiveMessage", "sqs:DeleteMessage", "sqs:GetQueueUrl"
            ],
            "Principal": {
                "AWS": "arn:aws:iam::XXXXXXXXXXXX:user/USERNAME_HERE"
            },
            "Resource": "arn:aws:sqs:REGION_HERE:XXXXXXXXXXXX:NAME_HERE"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject"
            ],
            "Principal": {
                "AWS": "arn:aws:iam::XXXXXXXXXXXX:user/USERNAME_HERE"
            },
            "Resource": "arn:aws:s3:::NAME_HERE/*"
        }
    ]
}

Step 3 — Configure the Sekoia.io AWS module

In the Sekoia.io connector configuration, set the following fields:

  • AWS Region (aws_region_name): the AWS region where your resources are deployed (e.g. eu-west-1)
  • AWS Access Key (aws_access_key): the access key ID of your IAM user
  • AWS Secret Access Key (aws_secret_access_key): the secret access key of your IAM user

Leave the AWS Role ARN field empty — it is not used with this method.

Step 2 — Create the Intake

Configure Your Intake

This section will guide you through creating the intake object in Sekoia, which provides a unique identifier called the "Intake key." The Intake key is essential for later configuration, as it references the Community, Entity, and Parser (Intake Format) used when receiving raw events on Sekoia.

  1. Go to the Sekoia Intake page.
  2. Click on the + New Intake button at the top right of the page.
  3. Search for your Intake by the product name in the search bar.
  4. Give it a Name and associate it with an Entity (and a Community if using multi-tenant mode).
  5. Click on Create.

Note

For more details on how to use the Intake page and to find the Intake key you just created, refer to this documentation.

Step 3 — Configure the Connector

Configure Your Playbook

This section will assist you in pulling remote logs from Sekoia and sending them to the intake you previously created.

  1. Go to the Sekoia playbook page.
  2. Click on the + New playbook button at the top right of the page.
  3. Select Create a playbook from scratch, and click Next.
  4. Give it a Name and a Description, and click Next.
  5. Choose a trigger from the list by searching for the name of the product, and click Create.
  6. A new Playbook page will be displayed. Click on the module in the center of the page, then click on the Configure icon.
  7. On the right panel, click on the Configuration tab.
  8. Select an existing Trigger Configuration (from the account menu) or create a new one by clicking on + Create new configuration.
  9. Configure the Trigger based on the Actions Library (for instance, see here for AWS modules), then click Save.
  10. Click on Save at the top right of the playbook page.
  11. Activate the playbook by clicking on the "On / Off" toggle button at the top right corner of the page.

When selecting the trigger, choose Fetch new logs on S3 (without SQS).

Before configuring the connector, retrieve the Data path from the Cisco Secure Access Amazon S3 Summary page. It looks like this:

s3://cisco-managed-eu-central-1/1234567_a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0

From this path:

  • the bucket name is the first segment after s3:// — here, cisco-managed-eu-central-1.
  • the base prefix is the second segment — here, 1234567_a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0. Cisco stores each log type in a dedicated subfolder under this prefix.

In the connector configuration, set the following fields:

  • AWS Region (aws_region_name): the region you selected when configuring the S3 bucket in Cisco Secure Access (for example, eu-central-1).
  • AWS Access Key (aws_access_key): the Access Key copied from the Cisco Secure Access Amazon S3 Summary page.
  • AWS Secret Access Key (aws_secret_access_key): the Secret Key copied from the Cisco Secure Access Amazon S3 Summary page.
  • Bucket (bucket): the bucket name extracted from the Data path (for example, cisco-managed-eu-central-1).
  • Prefix filter (prefix_filter): the base prefix followed by the subfolder matching the log type you want to collect. Since the bucket holds several log types, this filter ensures the connector only ingests the logs for this intake.
  • Intake key (intake_key): the intake key generated when you created the intake in Step 2.

Cisco Secure Access stores each log type in a dedicated subfolder under the base prefix. Set the Prefix filter to <base_prefix>/<subfolder>, using the subfolder that matches the intake you are configuring:

Intake Subfolder Example prefix filter
Cisco Secure Access - DNS dnslogs 1234567_a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0/dnslogs
Cisco Secure Access - Web proxylogs 1234567_a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0/proxylogs
Cisco Secure Access - Cloud Firewall firewalllogs 1234567_a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0/firewalllogs
Cisco Secure Access - IPS intrusionlogs 1234567_a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0/intrusionlogs
Cisco Secure Access - File Events fileeventlogs 1234567_a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0/fileeventlogs

Note

Replace 1234567_a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0 with the base prefix extracted from your own Cisco Secure Access Data path.

When selecting the trigger, choose Fetch new logs on S3.

In the connector configuration, set the following fields:

  • AWS Region (aws_region_name): the AWS region where your S3 bucket and SQS queue are deployed.
  • AWS Role ARN (aws_role_arn) or AWS Access Key / AWS Secret Access Key: the credentials configured when you set up AWS authentication in Step 1.

In the trigger configuration, set the following fields:

  • AWS SQS queue name (queue_name): the name of the SQS queue you created in Step 1 to receive S3 object creation notifications.
  • Intake key (intake_key): the intake key generated when you created the intake in Step 2.
  • Prefix filter (prefix_filter): optional but recommended to restrict ingestion to one log type subfolder (for example dnslogs).

Cisco Secure Access stores each log type in a dedicated subfolder at the root of your bucket. Since your bucket may hold several log types, you can restrict the connector to a single one with a Prefix filter (prefix_filter) matching the subfolder of the intake you are configuring:

Intake Subfolder
Cisco Secure Access - DNS dnslogs
Cisco Secure Access - Web proxylogs
Cisco Secure Access - Cloud Firewall firewalllogs
Cisco Secure Access - IPS intrusionlogs
Cisco Secure Access - File Events fileeventlogs

Event Categories

The following table lists the data source offered by this integration.

Data Source Description
Network device logs None

In details, the following table denotes the type of events produced by this integration.

Name Values
Kind ``
Category network
Type connection, protocol

Transformed Events Samples after Ingestion

This section demonstrates how the raw logs will be transformed by our parsers. It shows the extracted fields that will be available for use in the built-in detection rules and hunting activities in the events page. Understanding these transformations is essential for analysts to create effective detection mechanisms with custom detection rules and to leverage the full potential of the collected data.

{
    "message": "\"2024-09-11 18:46:00\",\"Active Directory User (user1@example.net)\",\"Active Directory User (user1@example.net),WIN11-SNG01-Example\",\"1.1.1.1\",\"2.2.2.2\",\"Allowed\",\"1 (A)\",\"NOERROR\",\"example.com.\",\"Software/Technology,Business Services,Allow List,Infrastructure and Content Delivery Networks,SaaS and B2B,Application\",\"AD Users\",\"AD Users,Anyconnect Roaming Client\",\"\",\"506165\",\"\",\"REDACTED\"",
    "event": {
        "action": "allowed",
        "category": [
            "network"
        ],
        "dataset": "dns",
        "outcome": [
            "success"
        ],
        "type": [
            "connection",
            "protocol"
        ]
    },
    "@timestamp": "2024-09-11T18:46:00Z",
    "cisco_secure_access": {
        "dns": {
            "categories": [
                "Allow List",
                "Application",
                "Business Services",
                "Infrastructure and Content Delivery Networks",
                "SaaS and B2B",
                "Software/Technology"
            ],
            "identities": [
                "Active Directory User (user1@example.net)",
                "WIN11-SNG01-Example"
            ],
            "identity_types": [
                "AD Users",
                "Anyconnect Roaming Client"
            ],
            "most_granular_identity": "Active Directory User (user1@example.net)",
            "most_granular_identity_type": "AD Users"
        }
    },
    "dns": {
        "question": {
            "name": "example.com",
            "registered_domain": "example.com",
            "top_level_domain": "com",
            "type": "A"
        },
        "response_code": "NOERROR",
        "type": "query"
    },
    "observer": {
        "product": "Secure Access",
        "type": "dns",
        "vendor": "Cisco"
    },
    "organization": {
        "id": "REDACTED"
    },
    "related": {
        "hosts": [
            "example.com"
        ],
        "ip": [
            "1.1.1.1",
            "2.2.2.2"
        ]
    },
    "rule": {
        "id": "506165"
    },
    "source": {
        "address": "1.1.1.1",
        "ip": "1.1.1.1",
        "nat": {
            "ip": "2.2.2.2"
        }
    }
}

{
    "message": "\"2024-09-11 18:46:00\",\"Active Directory User (user1@example.net)\",\"Active Directory User (user1@example.net),WIN11-SNG01-Example\",\"1.1.1.1\",\"2.2.2.2\",\"Blocked\",\"1 (A)\",\"NOERROR\",\"example.com.\",\"Chat,Social Networking\",\"AD Users\",\"AD Users,Anyconnect Roaming Client\",\"Social Networking\",\"506165\",\"\",\"REDACTED\"",
    "event": {
        "action": "blocked",
        "category": [
            "network"
        ],
        "dataset": "dns",
        "outcome": [
            "failure"
        ],
        "type": [
            "connection",
            "protocol"
        ]
    },
    "@timestamp": "2024-09-11T18:46:00Z",
    "cisco_secure_access": {
        "dns": {
            "blocked_categories": [
                "Social Networking"
            ],
            "categories": [
                "Chat",
                "Social Networking"
            ],
            "identities": [
                "Active Directory User (user1@example.net)",
                "WIN11-SNG01-Example"
            ],
            "identity_types": [
                "AD Users",
                "Anyconnect Roaming Client"
            ],
            "most_granular_identity": "Active Directory User (user1@example.net)",
            "most_granular_identity_type": "AD Users"
        }
    },
    "dns": {
        "question": {
            "name": "example.com",
            "registered_domain": "example.com",
            "top_level_domain": "com",
            "type": "A"
        },
        "response_code": "NOERROR",
        "type": "query"
    },
    "observer": {
        "product": "Secure Access",
        "type": "dns",
        "vendor": "Cisco"
    },
    "organization": {
        "id": "REDACTED"
    },
    "related": {
        "hosts": [
            "example.com"
        ],
        "ip": [
            "1.1.1.1",
            "2.2.2.2"
        ]
    },
    "rule": {
        "id": "506165"
    },
    "source": {
        "address": "1.1.1.1",
        "ip": "1.1.1.1",
        "nat": {
            "ip": "2.2.2.2"
        }
    }
}

Extracted Fields

The following table lists the fields that are extracted, normalized under the ECS format, analyzed and indexed by the parser. It should be noted that infered fields are not listed.

Name Type Description
@timestamp date Date/time when the event originated.
cisco_secure_access.dns.blocked_categories keyword The categories that resulted in the destination being blocked.
cisco_secure_access.dns.categories keyword The security or content categories that the destination matches.
cisco_secure_access.dns.identities keyword All identities associated with this request.
cisco_secure_access.dns.identity_types keyword The type of identity that made the request.
cisco_secure_access.dns.most_granular_identity keyword The first identity matched with this request in order of granularity.
cisco_secure_access.dns.most_granular_identity_type keyword The first identity type matched with this request in order of granularity.
destination.geo.country_iso_code keyword Country ISO code.
dns.question.name keyword The name being queried.
dns.question.type keyword The type of record being queried.
dns.response_code keyword The DNS response code.
dns.type keyword The type of DNS event captured, query or answer.
event.action keyword The action captured by the event.
event.category keyword Event category. The second categorization field in the hierarchy.
event.dataset keyword Name of the dataset.
event.type keyword Event type. The third categorization field in the hierarchy.
observer.product keyword The product name of the observer.
observer.type keyword The type of the observer the data is coming from.
observer.vendor keyword Vendor name of the observer.
organization.id keyword Unique identifier for the organization.
rule.id keyword Rule ID
source.ip ip IP address of the source.
source.nat.ip ip Source NAT ip

For more information on the Intake Format, please find the code of the Parser, Smart Descriptions, and Supported Events here.

Detection section

The following section provides information for those who wish to learn more about the detection capabilities enabled by collecting this intake. It includes details about the built-in rule catalog, event categories, and ECS fields extracted from raw events. This is essential for users aiming to create custom detection rules, perform hunting activities, or pivot in the events page.

The following Sekoia.io built-in rules match the intake Cisco Secure Access - DNS. This documentation is updated automatically and is based solely on the fields used by the intake which are checked against our rules. This means that some rules will be listed but might not be relevant with the intake.

SEKOIA.IO x Cisco Secure Access - DNS on ATT&CK Navigator

Bazar Loader DGA (Domain Generation Algorithm)

Detects Bazar Loader domains based on the Bazar Loader DGA

  • Effort: elementary
Cobalt Strike DNS Beaconing

Detects suspicious DNS queries known from Cobalt Strike beacons. The threshold is more than 50 suspicious DNS requests to avoid false positives.

  • Effort: advanced
Correlation Potential DNS Tunnel

Detects domain name which is longer than 62 characters and requested at least 50 times in a 10 minutes range time. Long domain names are distinctive of DNS tunnels.

  • Effort: advanced
Cryptomining

Detection of domain names potentially related to cryptomining activities.

  • Effort: master
Dynamic DNS Contacted

Detect communication with dynamic dns domain. This kind of domain is often used by attackers. This rule can trigger false positive in non-controlled environment because dynamic dns is not always malicious.

  • Effort: master
EvilProxy Phishing Domain

Detects subdomains potentially generated by the EvilProxy adversary-in-the-middle phishing platform. Inspect the other subdomains of the domain to identify the landing page, and determine if the user submitted credentials. This rule has a small percentage of false positives on legitimate domains.

  • Effort: intermediate
Exfiltration Domain

Detects traffic toward a domain flagged as a possible exfiltration vector.

  • Effort: master
Potential DNS Tunnel

Detects domain name which is longer than 62 characters. Long domain names are distinctive of DNS tunnels.

  • Effort: advanced
Remote Access Tool Domain

Detects traffic toward a domain flagged as a Remote Administration Tool (RAT).

  • Effort: master
Remote Monitoring and Management Software - AnyDesk

Detect artifacts related to the installation or execution of the Remote Monitoring and Management tool AnyDesk.

  • Effort: master
Remote Monitoring and Management Software - Atera

Detect artifacts related to the installation or execution of the Remote Monitoring and Management tool Atera.

  • Effort: master
SEKOIA.IO Intelligence Feed

Detect threats based on indicators of compromise (IOCs) collected by SEKOIA's Threat and Detection Research team.

  • Effort: elementary
Sekoia.io Activity Logs Rule Deactivation Bulk

Detects a massive rule deactivation observed threw Sekoia.io activity logs.

  • Effort: master
Sekoia.io EICAR Detection

Detects observables in Sekoia.io CTI tagged as EICAR, which are fake samples meant to test detection.

  • Effort: master
Sliver DNS Beaconing

Detects suspicious DNS queries known from Sliver beaconing

  • Effort: intermediate
Suspicious TOR Gateway

Detects suspicious TOR gateways. Gateways are often used by the victim to pay and decrypt the encrypted files without installing TOR. Tor intercepts the network traffic from one or more apps on user’s computer, usually the user web browser, and shuffles it through a number of randomly-chosen computers before passing it on to its destination. This disguises user location, and makes it harder for servers to pick him/her out on repeat visits, or to tie together separate visits to different sites, this making tracking and surveillance more difficult. Before a network packet starts its journey, user’s computer chooses a random list of relays and repeatedly encrypts the data in multiple layers, like an onion. Each relay knows only enough to strip off the outermost layer of encryption, before passing what’s left on to the next relay in the list.

  • Effort: advanced
TOR Usage Generic Rule

Detects TOR usage globally, whether the IP is a destination or source. TOR is short for The Onion Router, and it gets its name from how it works. TOR intercepts the network traffic from one or more apps on user’s computer, usually the user web browser, and shuffles it through a number of randomly-chosen computers before passing it on to its destination. This disguises user location, and makes it harder for servers to pick him/her out on repeat visits, or to tie together separate visits to different sites, this making tracking and surveillance more difficult. Before a network packet starts its journey, user’s computer chooses a random list of relays and repeatedly encrypts the data in multiple layers, like an onion. Each relay knows only enough to strip off the outermost layer of encryption, before passing what’s left on to the next relay in the list.

  • Effort: master
Telegram Bot API Request

Detects suspicious DNS queries to api.telegram.org used by Telegram Bots of any kind

  • Effort: advanced