Skip to content

Cisco Catalyst SD-WAN

Overview

Cisco Catalyst SD-WAN is a cloud-managed solution that delivers secure, high-performance SD-WAN connectivity across campuses, branches and multi-cloud environments.

  • Vendor: Cisco
  • Supported environment: On Premise
  • Version compatibility: 17.4.1 and above
  • Detection based on: Telemetry
  • Supported application or feature: Network traffic monitoring

Warning

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

Specification

Prerequisites

  • Resource:
    • Sekoia.io netflow forwarder
  • Network:
    • Outbound traffic allowed
  • Permissions:
    • Administrator or Root access to the Cisco Catalyst SD-WAN device
    • Root access to the Linux server with the netflow forwarder

Transport Protocol/Method

  • Indirect Netflow

Logs details

  • Supported functionalities: See section Overview
  • Supported type(s) of structure: IPFIX
  • Supported verbosity level: Informational

Step-by-Step Configuration Procedure

Instructions on the 3rd Party Solution

Forward Cisco Catalyst SD-WAN netflows

This setup guide will show you how to provide an integration between Cisco Catalyst SD-WAN traffic monitoring and Sekoia.io.

Create the Centralized policy:

  • Log on your Catalyst SD‑WAN Manager
  • Go to Configuration > Policies
  • Select Centralized Policy
  • Click Add Policy
  • At the Create Group of Interest step, click items on the left panel to create your group of interest.
  • For example:
    • To add a list of VPNs:
      • On the left panel, go to VPN
      • Click New VPN List
      • Type a VPN List Name
      • Type the VPNs to add in Add VPN
    • To add a list of sites:
      • On the left panel, go to Site
      • Click New Site List
      • Type a Site List Name
      • Type the sites to add in Add Site
  • When done, click Next
  • At the Configure Topology and VPN Membership step, add topology and VPN Membership as you wish
  • Click Next
  • At the Configure Traffic Rules, go to Cflowd
  • Click Add Policy > Create New
  • Type a name and a description for the Policy
  • In the Cflowd Template section, set the properties at your convenience
  • Go to the Collector List section
  • Click New Collector
  • Type the VPN ID
  • Type the address of the netflow collector as IP address
  • Type the listen port of the netflow collector as Port
  • Select UDP as Transport Protocol
  • Type the name of the interface to use to send flows to the collector as Source interface
  • Click Add
  • Click Next
  • At Apply Policies to Sites and VPNs, type a Policy Name and a Policy Description
  • Click the CFlowd tab
  • Select sites to add in the Site List
  • Click Save Policy
  • In the Centralized Policy view, click ... at the right of your policy
  • Click Activate menu
  • In the confirmation box, Click Activate

See documentation

Create the Localized policy:

  • Log on your Catalyst SD‑WAN Manager
  • Go to Configuration > Policies
  • Select Localized Policy
  • Click Add Policy
  • Click Next until reaching the Policy Overview
  • Type a Policy Name
  • Type a Policy Description
  • Check Netflow for IPv4 traffic
  • Check Netflow IPv6 for IPv6 traffic
  • Click Save Policy

See documentation

Apply the localized policy:

  • Go to Configuration > Templates
  • Click Device Templates
  • Select a template and click ... at the right of the template
  • Click Edit menu
  • Go to Additional Templates
  • Select the localized policy as Policy
  • Click Save

Instruction on Sekoia

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.

Configure a forwarder

To forward netflow events to Sekoia, use the Sekoia.io Netflow forwarder which is the official supported way to collect netflow events. In charge of centralizing data coming from many equipments/sources and forwarding them to Sekoia.io with the appropriate format, it is a prepackaged option. You only have to provide your intake key as parameter.

Raw Events Samples

In this section, you will find examples of raw logs as generated natively by the source. These examples are provided to help integrators understand the data format before ingestion into Sekoia.io. It is crucial for setting up the correct parsing stages and ensuring that all relevant information is captured.

{
    "flowStartSysUpTime": 61588,
    "destinationIPv4Address": "5.6.7.8",
    "flowEndSysUpTime": 62004,
    "protocolIdentifier": 6,
    "tcpControlBits": 27,
    "ipVersion": 4,
    "egressInterface": 0,
    "sourceTransportPort": 443,
    "octetDeltaCount": 6561,
    "ingressInterface": 0,
    "packetDeltaCount": 12,
    "ipClassOfService": 0,
    "sourceIPv4Address": "1.2.3.4",
    "destinationTransportPort": 37500
}

{
    "IPV4_SRC_ADDR": "1.2.3.4",
    "IPV4_DST_ADDR": "5.6.7.8",
    "NEXT_HOP": 0,
    "INPUT": 0,
    "OUTPUT": 0,
    "IN_PACKETS": 17,
    "IN_OCTETS": 1732,
    "FIRST_SWITCHED": 1096510,
    "LAST_SWITCHED": 1096623,
    "SRC_PORT": 54840,
    "DST_PORT": 443,
    "TCP_FLAGS": 27,
    "PROTO": 6,
    "TOS": 0,
    "SRC_AS": 0,
    "DST_AS": 0,
    "SRC_MASK": 0,
    "DST_MASK": 0
}

{
    "IPV4_SRC_ADDR": "1.2.3.4",
    "IPV4_DST_ADDR": "5.6.7.8",
    "FIRST_SWITCHED": 662235,
    "LAST_SWITCHED": 662335,
    "IN_BYTES": 76,
    "IN_PKTS": 1,
    "INPUT_SNMP": 0,
    "OUTPUT_SNMP": 0,
    "L4_SRC_PORT": 38005,
    "L4_DST_PORT": 123,
    "PROTOCOL": 17,
    "TCP_FLAGS": 0,
    "IP_PROTOCOL_VERSION": 4,
    "SRC_TOS": 0
}

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 Catalyst SD-WAN [BETA]. 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 Catalyst SD-WAN [BETA] on ATT&CK Navigator

Bazar Loader DGA (Domain Generation Algorithm)

Detects Bazar Loader domains based on the Bazar Loader DGA

  • Effort: elementary
Covenant Default HTTP Beaconing

Detects potential Covenant communications through the user-agent and specific urls

  • Effort: intermediate
Cryptomining

Detection of domain names potentially related to cryptomining activities.

  • Effort: master
Discord Suspicious Download

Discord is a messaging application. It allows users to create their own communities to share messages and attachments. Those attachments have little to no overview and can be downloaded by almost anyone, which has been abused by attackers to host malicious payloads.

  • Effort: advanced
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
Koadic MSHTML Command

Detects Koadic payload using MSHTML module

  • Effort: intermediate
Nimbo-C2 User Agent

Nimbo-C2 Uses an unusual User-Agent format in its implants.

  • Effort: intermediate
Potential Azure AD Phishing Page (Adversary-in-the-Middle)

Detects an HTTP request to an URL typical of the Azure AD authentication flow, but towards a domain that is not one the legitimate Microsoft domains used for Azure AD authentication.

  • Effort: intermediate
Potential Bazar Loader User-Agents

Detects potential Bazar loader communications through the user-agent

  • Effort: elementary
Potential Lemon Duck User-Agent

Detects LemonDuck user agent. The format used two sets of alphabetical characters separated by dashes, for example "User-Agent: Lemon-Duck-[A-Z]-[A-Z]".

  • Effort: elementary
Potential LokiBot User-Agent

Detects potential LokiBot communications through the user-agent

  • Effort: intermediate
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
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 EICAR Detection

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

  • Effort: master
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

Event Categories

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

Data Source Description
Network device logs Cisco SD-WAN aggregates traffic packets into flow.
Network protocol analysis Cisco SD-WAN analyzes traffic at physical/data/transport layers

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": "{\"flowStartSysUpTime\":61588,\"destinationIPv4Address\":\"5.6.7.8\",\"flowEndSysUpTime\":62004,\"protocolIdentifier\":6,\"tcpControlBits\":27,\"ipVersion\":4,\"egressInterface\":0,\"sourceTransportPort\":443,\"octetDeltaCount\":6561,\"ingressInterface\":0,\"packetDeltaCount\":12,\"ipClassOfService\":0,\"sourceIPv4Address\":\"1.2.3.4\",\"destinationTransportPort\":37500}",
    "event": {
        "duration": 416000000
    },
    "cisco": {
        "sd_wan": {
            "tcp": {
                "flags": 27
            }
        }
    },
    "destination": {
        "address": "5.6.7.8",
        "ip": "5.6.7.8",
        "port": 37500
    },
    "network": {
        "bytes": 6561,
        "iana_number": "6",
        "packets": 12,
        "transport": "tcp",
        "type": "ipv4"
    },
    "related": {
        "ip": [
            "1.2.3.4",
            "5.6.7.8"
        ]
    },
    "source": {
        "address": "1.2.3.4",
        "ip": "1.2.3.4",
        "port": 443
    }
}

{
    "message": "{\"IPV4_SRC_ADDR\":\"1.2.3.4\",\"IPV4_DST_ADDR\":\"5.6.7.8\",\"NEXT_HOP\":0,\"INPUT\":0,\"OUTPUT\":0,\"IN_PACKETS\":17,\"IN_OCTETS\":1732,\"FIRST_SWITCHED\":1096510,\"LAST_SWITCHED\":1096623,\"SRC_PORT\":54840,\"DST_PORT\":443,\"TCP_FLAGS\":27,\"PROTO\":6,\"TOS\":0,\"SRC_AS\":0,\"DST_AS\":0,\"SRC_MASK\":0,\"DST_MASK\":0}",
    "event": {
        "duration": 113000000
    },
    "cisco": {
        "sd_wan": {
            "tcp": {
                "flags": 27
            }
        }
    },
    "destination": {
        "address": "5.6.7.8",
        "ip": "5.6.7.8",
        "port": 443
    },
    "network": {
        "bytes": 1732,
        "iana_number": "6",
        "packets": 17,
        "transport": "tcp",
        "type": "ipv4"
    },
    "related": {
        "ip": [
            "1.2.3.4",
            "5.6.7.8"
        ]
    },
    "source": {
        "address": "1.2.3.4",
        "ip": "1.2.3.4",
        "port": 54840
    }
}

{
    "message": "{\"IPV4_SRC_ADDR\":\"1.2.3.4\",\"IPV4_DST_ADDR\":\"5.6.7.8\",\"FIRST_SWITCHED\":662235,\"LAST_SWITCHED\":662335,\"IN_BYTES\":76,\"IN_PKTS\":1,\"INPUT_SNMP\":0,\"OUTPUT_SNMP\":0,\"L4_SRC_PORT\":38005,\"L4_DST_PORT\":123,\"PROTOCOL\":17,\"TCP_FLAGS\":0,\"IP_PROTOCOL_VERSION\":4,\"SRC_TOS\":0}",
    "event": {
        "duration": 100000000
    },
    "destination": {
        "address": "5.6.7.8",
        "ip": "5.6.7.8",
        "port": 123
    },
    "network": {
        "bytes": 76,
        "iana_number": "17",
        "packets": 1,
        "transport": "udp",
        "type": "ipv4"
    },
    "related": {
        "ip": [
            "1.2.3.4",
            "5.6.7.8"
        ]
    },
    "source": {
        "address": "1.2.3.4",
        "ip": "1.2.3.4",
        "port": 38005
    }
}

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
cisco.sd_wan.bgp.next_hop keyword Address of next-hop router in the BGP domain
cisco.sd_wan.next_hop keyword Address of next-hop router
cisco.sd_wan.tcp.flags number Cumulative of all the TCP flags seen for this flow
destination.as.number long Unique number allocated to the autonomous system.
destination.ip ip IP address of the destination.
destination.mac keyword MAC address of the destination.
destination.port long Port of the destination.
event.duration long Duration of the event in nanoseconds.
event.end date event.end contains the date when the event ended or when the activity was last observed.
event.start date event.start contains the date when the event started or when the activity was first observed.
http.request.method keyword HTTP request method.
http.response.mime_type keyword Mime type of the body of the response.
http.response.status_code long HTTP response status code.
http.version keyword HTTP version.
network.application keyword Application level protocol name.
network.bytes long Total bytes transferred in both directions.
network.iana_number keyword IANA Protocol Number.
network.packets long Total packets transferred in both directions.
observer.egress.interface.id keyword Interface ID
observer.ingress.interface.id keyword Interface ID
observer.ingress.interface.name keyword Interface name
source.as.number long Unique number allocated to the autonomous system.
source.ip ip IP address of the source.
source.mac keyword MAC address of the source.
source.port long Port of the source.
url.domain keyword Domain of the url.
url.path wildcard Path of the request, such as "/search".
user_agent.original keyword Unparsed user_agent string.

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

Further readings