Threat Landscape Trends: Endpoint Security, Part 2

Part 2: LOLBins, operating systems, and threat types

Being aware of what’s occurring on the threat landscape can be a valuable tool when it comes to defending your organization. If you’re well informed, that puts you in a good position to decide how best to protect your assets and allocate resources accordingly. While it’s important to stay up to date with the latest ground-breaking attack techniques and new threats, it’s equally important to keep abreast of the overall trends.

The fact is that, for every novel technique discovered, there are countless attacks taking place in the same time frame that use well-known and well-trodden tactics. For every attack carried out by a nation state, there’s a dozen million-dollar ransomware attacks that started with a simple phishing email.

This is why watching the trends is so important: it provides a view of what you’re most likely to encounter. This is the purpose of this new blog series, Threat Landscape Trends. In it, we’ll be taking a look at activity in the threat landscape and sharing the latest trends we see. By doing so, we hope to shed light on areas where you can quickly have an impact in defending your assets, especially if dealing with limited security resources.

In Part 1, we took a look at critical severity threats and MITRE ATT&CK tactics that were spotted by the Indication of Compromise (IoC) feature in Cisco’s Endpoint Security solution. In this second part, we’re going to step back and look at a larger swath of the IoC alerts to see what’s most frequently encountered.

The methodology remains the same as in Part 1, which we provide again at the end of this blog. In a nutshell, the data presented here is similar to alerts you would see within the dashboard of Cisco’s Endpoint Security solution, only aggregated across organizations. This time we rank the IoCs that organizations have encountered grouped by particular topics. The data set covers the first half of 2020, from January 1st through June 30th.

Signal from Noise

According to Cisco’s 2020 CISO Benchmark Report, one of the biggest issues IT folks face is alert fatigue. Of the respondents that claim they suffer from such fatigue, 93 percent said they receive at least 5,000 alerts per day. In circumstances like this, it’s absolutely critical to be able to derive what’s important from what can be discarded.

As we showed in Part 1, the vast majority of alerts fall into the low and medium severity categories (35 and 51 percent, respectively). It may be tempting to discount lower severities outright. Indeed, in some circumstances, this may be the correct course of action.

For instance, some of the more common low severity IoCs, like running PsExec as an administrator or stopping the firewall with NetSh, may on occasion trigger on activities carried out by IT administration—whether or not these are considered best practices. While not an attack, these sorts of alerts may be worth having a conversation about with the IT department, when time allots.

However, the significance of an alert shouldn’t be based on the severity alone. Under some circumstances, low severity alerts can be just as concerning as a critical severity alert. The trick is to figure out the context surrounding them. What happened before and after an alert? Are there other lower-severity alerts in the same time frame? Stringing together a series of suspicious alerts can give a much clearer picture of potential attacks that may only alert on lower severity IoCs.

For example, let’s say an attacker sends a phishing email to your organization. If the recipient opens the Word attachment, a macro contained within launches a script (triggering the IoC W32.WinWord.Powershell.ioc). The script in turn runs encoded PowerShell commands (W32.PowershellEncodedBuffer.ioc) to set the stage to download further malicious code (W32.PowershellDownloadString.ioc).

This scenario is comprised entirely of low- and medium-severity IoCs. Each of these by themselves do not necessarily point to an attack, but when viewed as a string of IoCs, it’s very unlikely that these would be associated with anything but malicious activity. At the end of the day, the idea with the lower IoC categories is that they indicate activity within your environment that should be investigated, especially if IT says they didn’t do it.

With this in mind, in the metrics that follow we’ll look at medium, high, and critical-severity IoCs. This is because, while low-severity IoCs are critical when looking at a series of alerts appearing in sequence, individually they can muddy the waters when analyzing larger malicious trends across organizations. Filtering out these IoCs ensures that the activity that we’re focusing on is actual malicious activity, as opposed to a round-about administrative solution.

So, without further ado, let’s have a look at more threat landscape trends, covering LOLBins, OSes, and other threats.

LOLBins

Utilizing the tools built into operating systems is a very common attack tactic these days. Leveraging such readily available binaries decreases the chances that an attacker will be discovered, compared to custom-tailored malicious tools that can stand out. Using readily available tools for malicious activity is generally referred to as “living off the land,” and the binaries utilized are called LOLBins. 

The use of LOLBins appears to be quite common for malicious activity, based on alerts seen during the first half of 2020. In our research, 20-27 percent of the IoC alerts organizations encountered at least once in a given month were related to suspicious LOLBin activity.

Percentage of IoC alerts organizations encountered related to suspicious LOLBins.

What’s notable is the five percent jump witnessed in April. This is primarily due to activity related to an adware application called Browser Assistant. This adware generally injects JavaScript into web browsers to display advertisements. During April, Browser Assistant was seen using PowerShell to load itself into memory without launching files (using reflective DLL injection, to be specific). This is highly suspect, being a technique often used by fileless malware.

Two LOLBins in particular appear to dominate the top LOLBin IoCs seen: PowerShell and the Windows Scripting Host (covering both WScript and CScript). Both of these LOLBins facilitate the execution of scripts within the Windows operating system.

Top LOLBin IoCs

Overall, PowerShell is involved in five of the top ten IoCs seen relating to LOLBins, comprising around 59 percent of all LOLBin alerts. In many cases, PowerShell is used to download malicious code into memory or download further executables. The Windows Scripting Host is often leveraged to launch malicious files, perform reconnaissance, move throughout the network, or contact remote locations. The Windows Scripting Host made up 23 percent of all LOLBin alerts.

What’s interesting in looking at the malicious use of these native binaries is that bad actors often leverage one LOLBin to launch another. This is clear with the eighth and tenth entries in our list and can be seen in other IoCs beyond the top ten. Malicious actors likely swap LOLBins during an attack in order to hide their tracks.

Top OS IoCs

Let’s take a look at the two primary desktop operating systems, Windows and macOS, to see how attackers are targeting them.

Windows

Naturally, PowerShell makes its presence known, with appearances in three IoCs in the top ten. The Windows Scripting Host appears twice as well, showing just how prevalent LOLBins are in the Windows environment. In all, half of the top 10 IoCs on Windows use LOLBins.

Top Windows IoCs

Adware also appears quite prominently on Windows, with three adware installers and ad-injecting IoCs making the top 10. However, these IoCs should not be taken lightly for being adware. These instances are some of the more egregious adware installers, often going well beyond what is considered a legitimate install process.

Other activities of note include:

◉ The presence of The Onion Router (TOR) connections ranks highly. TOR can feasibly be used to allow encrypted traffic through firewalls, at best to get around IT policies, and worst for data exfiltration.

◉ Quietly disabling UAC via the registry is something an attacker might do in order to run malicious code that requires elevated privileges.

◉ Using NSlookup to send DNS TXT queries is a technique often used by bad actors for C2 communication.

MacOS

Adware appears quite frequently on macOS as well, comprising four of the top ten IoCs seen. What’s interesting is that LOLBins don’t appear as frequently here as they do on Windows. Instead, attackers are likely to hide their presence by disabling the security programs, excluding their files from quarantine, clearing command histories, and hiding files.

Top macOS IoCs

Threat categories

Finally, let’s home in on some specific threat types. Here is a closer look at four key types of threats currently seen on the threat landscape.

Ransomware

The most common IoC alert seen relating to ransomware is the deletion of shadow copies, which are snapshots of the file system used by the Windows operating system for backups. Ransomware threats often delete these files to prevent encrypted files from being restored from local backups. This particular IoC comprised 66 percent of all ransomware-related IoC alerts.

Top Ransomware IoCs

It’s also worth noting that ransomware often uses the Windows Scripting Host to execute a .zip file that contains malicious JavaScript. This is a technique used by malicious actors that install ransomware, such as WastedLocker. However, since such zipped JavaScript files are also used in other malicious attacks outside of ransomware, such as email campaigns for Emotet, it is not included in the list above.

Credential Stealing

The most commonly encountered credential stealing tool, Mimikatz, was featured in Part 1 of our look at Endpoint Security related trends. At 28 percent, this critical-severity, credential-dumping tool topped other regularly used techniques, likely for the all-in-one approach that the tool offers.

Apart from Mimikatz, malicious actors were seen utilizing the Findstr utility on files, digging through LSASS, and combing through the registry in order to find credentials.

Top Credential Stealing IoCs

Adware

Adware features heavily on both Windows and macOS operating systems. Adware appearing in the top five generally behave in a manner closer to malware than a simple annoyance of showing you an unexpected advertisement.

Top Adware IoCs

Cryptomining

While cryptomining doesn’t currently feature heavily in overall IoC lists, the most common activities seen include regular activity associated with cryptomining, such as submitting and requesting work from a cryptomining server or wallet-related activity. However, instances of fileless cryptominers and attempts to stop other miners feature in the top five as well.

Top Cryptomining IoCs

How to defend

While no doubt interesting, the information in this blog can also double as a blueprint for a plan of defense. This is especially important if working with limited resources, when prioritizing defensive actions where they’re most needed is critical. If you’re going to do one thing with this new information to protect your organization, focus your efforts on what consistently crops up in these lists: LOLBins.

Of course, this may be easier said than done, not only because these binaries are baked into the OS, but because many IT organizations utilize them in their daily operations. So how do you differentiate between normal operations and malicious activity? While it’s fairly obvious when some actions are being carried out by bad actors, others are not so clear.

First and foremost, it’s important to ensure you enable adequate logging on systems. The fact is you can’t pinpoint malicious activity if there’s no record of it.

It’s also important to have a clear understanding of the types of commands and activity that you can expect within these logs. Filtering out what you know is being carried out through automation or IT activities will clear out much of the noise, making it easier to drill down into what should be there.

It’s also important look for patterns. Individual activities and commands may not appear malicious on their own, but in the context of a series of commands, ran before and after, a malicious pattern may emerge. Create playbooks that address these patterns and use automation to detect when they trigger.

When it comes to what commands and activities are expected, every organization is different. Establishing your approach often requires the involvement a variety of people from different teams. Establishing those communications will not only help when building out a defensive plan, but can be critical in quickly resolving an incident if one arises.

Methodology

We’ve organized the data set in such a way as to obtain more meaningful trends. First, we’ve aggregated the data by the number of organizations that have received an alert about a particular activity, as opposed to the total number of detections in the given time frame. Charts are broken down by months. This means that an organization can be counted in each month, if they see the activity. Tables cover the full six-month period (January 1, 2020 through June 30, 2020), and organizations encountering an IoC are only counted once in these cases.

A word on privacy

Cisco takes customer privacy very seriously. While Cisco Security products can report telemetry back to us, this is an opt-in feature within our products. To further this end, we’ve gone to great lengths to ensure the data used for this blog series is anonymized and aggregated before any analysis is performed on it.

Continue reading

Migrating PnP API from APIC-EM to Cisco DNA Center

I have had a number of questions about the best way to migrate from APIC-EM to DNA Center for Plug and Play (PnP) provisioning of devices.  The PnP API was very popular in APIC-EM and both the PnP functionality as well as API have been enhanced in DNA Center. While the older workflow style API still exist in DNAC, they are relatively complex and have no UI component.

Transition approaches

I used to have two answers to the “how do I migrate” question. One approach was to transition (just use the workflow API), and the other was to transform (move to the new “site base” API).

If you had static configuration files for devices (e.g. some other tool to generate them) you would typically choose the first option.  If you were more interested in templates with variables, you would choose the second.

There is now a hybrid option, using the new site-claim API, with a “fixed” configuration template.

PnP API

First a look at the PnP API and how they work.  There are two steps, 1) Add a device and 2) Claim a device.

Step one adds the device to the PnP device table.  This can happen in two ways, unplanned (where the device discovers DNA Center), or pre-planned (where the device is inserted into DNA Center).  This step is unchanged from APIC-EM and uses the /import API endpoint.  All that is required is the model of the device and the serial number.

Once the device is part of the PnP table, it can then be claimed.   In the past, the workflow based API used the /claim API endpoint.  The newer /site-claim API endpoint is now recommended.   This requires a device (from step1) and a site.  There are optional attributes for image upgrade and configuration template.

These steps are seen in the UI.  The first device (“pre-planned”) has been added to DNA Center, but not claimed. The second device was added and claimed to a site.  The source of both devices was “User” which indicates they were pre-planned as opposed to “Network” which indicates an un-planned device.

Using the Scripts

These scripts are available on github. The readme has instructions on installing them. The scripts use the dnacentersdk I described in this post.

The first step is to upload the configuration files as templates.  These should be stored in the “Onboarding Configuration” folder.

$ ./00load_config_files.py --dir work_files/configs

Processing:switch1.cfg: adding NEW:Commiting e156e9e6-653d-4016-85bd-f142ba0659f8

Processing:switch3.cfg: adding NEW:Commiting 9ae1a187-422d-41b9-a363-aafa8724a5b2

Second step is to edit a CSV file contain the devices to be uploaded, and the configuration file. This file deliberately contains some errors (missing config file and missing image) as examples.

$ cat work_files/devices.csv 

name,serial,pid,siteName,template,image

adam123,12345678902,c9300,Global/AUS/SYD5,switch1.cfg,cat3k_caa-universalk9.16.09.05.SPA.bin

adam124,12345678902,c9300,Global/AUS/SYD5,switch2.cfg,cat3k_caa-universalk9.16.09.05.SPA.bin

adam_bad_image,12345678902,c9300,Global/AUS/SYD5,switch2.cfg,cat3k_caa-universalk9.16.09.10.SPA.bin

Third step is to use the script to upload the devices into DNA Center. The missing configuration and missing image are flagged.

$ ./10_add_and_claim.py --file work_files/devices.csv 

Device:12345678902 name:adam123 siteName:Global/AUS/SYD5 Status:PLANNED

##ERROR adam124,12345678902: Cannot find template:switch2.cfg

##ERROR adam_bad_image,12345678902: Cannot find image:cat3k_caa-universalk9.16.09.10.SPA.bin

adam_bad_image,12345678902,c9300,Global/AUS/SYD5,switch2.cfg,cat3k_caa-universalk9.16.09.10.SPA.bin

This will be reflected in the PnP page in DNA Center.

Under the Covers

Using the SDK abstracts the API.  For those that want to understand the payloads in more detail, here is a deeper dive into the payloads.

Templates

The following API call will get the projectId for the “Onboarding Configuration” folder.

GET dna/intent/api/v1/template-programmer/project?name=Onboarding%20Configuration

The result will provide the UUID of the project. It also provides a list of the templates, so could be used to find the template.   A different call is required to get the template body, as templates are versioned.  The “id” below is  the master template “id”

[

    {

        "name": "Onboarding Configuration",

        "id": "bfbb6134-8b1a-4629-9f5a-435a13dba75a",

        "templates": [

            {

                "name": "switch1.cfg",

                "composite": false,

                "id": "e156e9e6-653d-4016-85bd-f142ba0659f8"

            },

A better way to get the template is to call the template API with a projectId as a query parameter. It is not possible to lookup a template by name, the only option is to iterate through the list of results.

GET dna/intent/api/v1/template-programmer/template?projectId=bfbb6134-8b1a-4629-9f5a-435a13dba75a

Templates have versions. There is the master template Id, as well as an Id for each version. The example below only has one version “id”: “bd7cfeb9-3722-41ee-bf2d-a16a8ea6f23a”

{

        "name": "switch1.cfg",

        "projectName": "Onboarding Configuration",

        "projectId": "bfbb6134-8b1a-4629-9f5a-435a13dba75a",

        "templateId": "e156e9e6-653d-4016-85bd-f142ba0659f8",

        "versionsInfo": [ 

            {

                "id": "bd7cfeb9-3722-41ee-bf2d-a16a8ea6f23a", 

                "author": "admin",

                "version": "1",

                "versionTime": 1590451734078

            }

        ],

        "composite": false

    }

To get the body of the template (to compare SHA hash), use the template API call, for the specific version.

GET dna/intent/api/v1/template-programmer/template/bd7cfeb9-3722-41ee-bf2d-a16a8ea6f23a

Will return the body. Templates apply to a productFamily and softwareType. These will be used when creating or updating templates.

{

    "name": "switch1.cfg",

    "tags": [],

    "author": "admin",

    "deviceTypes": [

        {

            "productFamily": "Switches and Hubs"

        }

    ],

    "softwareType": "IOS-XE",

    "softwareVariant": "XE",

    "templateContent": "hostname switch1\nint g2/0/1\ndescr nice  one\n",

    "templateParams": [],

    "rollbackTemplateParams": [],

    "composite": false,

    "containingTemplates": [],

    "id": "bd7cfeb9-3722-41ee-bf2d-a16a8ea6f23a",

    "createTime": 1590451731775,

    "lastUpdateTime": 1590451731775,

    "parentTemplateId": "e156e9e6-653d-4016-85bd-f142ba0659f8"

}

To add a new template, there are two steps. The template has to be created, then committed. The second step is the same as updating an existing template, which creates a new version. Notice the deviceTypes and softwareType are required.

POST dna/intent/api/v1/template-programmer/project/bfbb6134-8b1a-4629-9f5a-435a13dba75a/template

{

     "deviceTypes": [{"productFamily": "Switches and Hubs"}],

     "name": "switch4.cfg",

     "softwareType": "IOS-XE",

     "templateContent": "hostname switch4\nint g2/0/1\ndescr nice  four\n"

}

This will return a task, which needs to be polled.

{

       "response": {

                 "taskId": "f616ef87-5174-4215-b5c3-71f50197fe72",

                 "url": "/api/v1/task/f616ef87-5174-4215-b5c3-71f50197fe72"

        },

        "version": "1.0"

}

Polling the task

GET dna/intent/api/v1/task/f616ef87-5174-4215-b5c3-71f50197fe72

The status is successful and the templateId is “57371b95-917b-42bd-b700-0d42ba3cdcc2”

{

  "version": "1.0", 

  "response": {

    "username": "admin", 

    "rootId": "f616ef87-5174-4215-b5c3-71f50197fe72", 

    "serviceType": "NCTP", 

    "id": "f616ef87-5174-4215-b5c3-71f50197fe72", 

    "version": 1590468626572, 

    "startTime": 1590468626572, 

    "progress": "Successfully created template with name switch4.cfg", 

    "instanceTenantId": "5d817bf369136f00c74cb23b", 

    "endTime": 1590468626670, 

    "data": "57371b95-917b-42bd-b700-0d42ba3cdcc2", 

    "isError": false

  }

}

The final step is to commit the change to the template.

POST dna/intent/api/v1/template-programmer/template/version

{

  "templateId": "57371b95-917b-42bd-b700-0d42ba3cdcc2"

}

To update an existing template, it is a PUT rather than POST. Again, the deviceTypes and softwareType are required.

PUT dna/intent/api/v1/template-programmer/template

{

 "deviceTypes": [ { "productFamily": "Switches and Hubs" } ],

 "id": "57371b95-917b-42bd-b700-0d42ba3cdcc2",

 "name": "switch4.cfg",

 "softwareType": "IOS-XE",

 "templateContent": "hostname switch4\nint g2/0/1\ndescr nice four **\n"

}

Again, a task is returned, which needs to be polled.

{

  "version": "1.0", 

  "response": {

    "username": "admin", 

    "rootId": "52689b1e-e9b8-4a60-8ae9-a574bb6b451c", 

    "serviceType": "NCTP", 

    "id": "52689b1e-e9b8-4a60-8ae9-a574bb6b451c", 

    "version": 1590470080172, 

    "startTime": 1590470080172, 

    "progress": "Successfully updated template with name switch4.cfg", 

    "instanceTenantId": "5d817bf369136f00c74cb23b", 

    "endTime": 1590470080675, 

    "data": "57371b95-917b-42bd-b700-0d42ba3cdcc2", 

    "isError": false

  }

}

The final step is to commit the change, as when first creating the template.  The UI will show two versions of this template.

Site

To find the siteId, a simple lookup is used, with the name as a query parameter.  This is the fully qualified name of the site.

GET dna/intent/api/v1/site?name=Global/AUS/SYD5

This will return the siteId.

{

  "response" : [ {

    "parentId" : "ace74caf-6d83-425f-b0b6-05faccb29c06",

    "systemGroup" : false,

    "additionalInfo" : [ {

      "nameSpace" : "Location",

      "attributes" : {

        "country" : "Australia",

        "address" : "177 Pacific Highway, North Sydney New South Wales 2060, Australia",

        "latitude" : "-33.837053",

        "addressInheritedFrom" : "d7941b24-72a7-4daf-a433-0cdfc80569bb",

        "type" : "building",

        "longitude" : "151.206266"

      }

    }, {

      "nameSpace" : "ETA",

      "attributes" : {

        "member.etaCapable.direct" : "2",

        "member.etaReady.direct" : "0",

        "member.etaNotReady.direct" : "2",

        "member.etaReadyNotEnabled.direct" : "0",

        "member.etaEnabled.direct" : "0"

      }

    } ],

    "groupTypeList" : [ "SITE" ],

    "name" : "SYD5",

    "instanceTenantId" : "5d817bf369136f00c74cb23b",

    "id" : "d7941b24-72a7-4daf-a433-0cdfc80569bb",

    "siteHierarchy" : "80e81504-0deb-4bfd-8c0c-ea96bb958805/ace74caf-6d83-425f-b0b6-05faccb29c06/d7941b24-72a7-4daf-a433-0cdfc80569bb",

    "siteNameHierarchy" : "Global/AUS/SYD5"

  } ]

}

Image

To find the imageid, for upgrading software, search for the image by imageName. NOTE, on some platforms this is different to name.

GET dna/intent/api/v1/image/importation?imageName=cat3k_caa-universalk9.16.09.05.SPA.bin

Returns the imageUuid, and a lot of other information about the image, including model numbers etc.

{

    "response": [

        {

            "imageUuid": "04d69fe0-d826-42e9-82c0-45363a2b6fc7",

            "name": "cat3k_caa-universalk9.16.09.05.SPA.bin",

            "family": "CAT3K_CAA",

            "version": "16.9.5",

            "md5Checksum": "559bda2a74c0a2a52b3aebd7341ff96b",

            "shaCheckSum": "a01d8ab7121e50dc688b9a2a03bca187aab5272516c0df3cb7e261f16a1c8ac355880939fd0c24cc9a79e854985af786c430d9b704925e17808353d70bf923f4",

            "createdTime": "2020-05-26 04:20:42.904",

            "imageType": "SYSTEM_SW",

            "fileSize": "450283034 bytes",

            "imageName": "cat3k_caa-universalk9.16.09.05.SPA.bin",

            "applicationType": "",

            "feature": "",

            "fileServiceId": "94eccf65-a1dd-47ca-b7c4-f5dd1a8cdeb7",

            "isTaggedGolden": false,

            "imageSeries": [

                "Switches and Hubs/Cisco Catalyst 3850 Series Ethernet Stackable Switch",

                "Switches and Hubs/Cisco Catalyst 3650 Series Switches"

            ],

            

Add Device

To add the device, supply a serialNumber, and pid. The name is optional. The aaa parameters are not used prior to DNAC 1.3.3.7. They are used to solve an issue with “aaa command authorization”.

POST dna/intent/api/v1/onboarding/pnp-device/import

[

  {

    "deviceInfo": {

      "serialNumber": "12345678902", 

      "aaaCredentials": {

        "username": "", 

        "password": ""

      }, 

      "userSudiSerialNos": [], 

      "hostname": "adam123", 

      "pid": "c9300", 

      "sudiRequired": false, 

      "stack": false

    }

  }

]

The response contains the deviceId, other attributes have been removed for brevity. At this point the device appears in PnP, but is unclaimed.

{

                 "successList": [

                     {

                         "version": 2,

                         "deviceInfo": {

                             "serialNumber": "12345678902",

                             "name": "12345678902",

                             "pid": "c9300",

                             "lastSyncTime": 0,

                             "addedOn": 1590471982430,

                             "lastUpdateOn": 1590471982430,

                             "firstContact": 0,

                             "lastContact": 0,

                             "state": "Unclaimed",

                         "tenantId": "5d817bf369136f00c74cb23b",

                         "id": "5eccad2e29da7c0008613b69"

                     }

Site-Claim

To claim the device to a site, use the siteId, imageId, templateId(configId) from earlier steps. Notice the master templateId is used, rather than a specific version. The master gets the latest version of the template by default. The type should be “Default”. If you are using a stack, then the type would be “StackSwitch”. Wireless Access points will set the type field to “AccessPoint”.

POST dna/intent/api/v1/onboarding/pnp-device/site-claim

{

  "configInfo": {

    "configId": "e156e9e6-653d-4016-85bd-f142ba0659f8", 

    "configParameters": []

  }, 

  "type": "Default", 

  "siteId": "d7941b24-72a7-4daf-a433-0cdfc80569bb", 

   "deviceId": "5eccad2e29da7c0008613b69", 

  "imageInfo": {

    "skip": false, 

    "imageId": "04d69fe0-d826-42e9-82c0-45363a2b6fc7"

  }

}

The response shows success, and this is reflected in the PnP UI.

{

      "response": "Device Claimed",

      "version": "1.0"

}

More on Stacks

One major innovation in DNAC PnP is support for stack renumbering. Prior to this, it was recommended that stack members be powered on two minutes apart, from top to bottom. This was to ensure a deterministic interface numbering. Stack renumbering is a much better solution to this problem. One of two stack cabling methods can be used, and the serial number of the top-of-stack switch is required.

There are two implications for API calls for the pre-planned workflow. The first is for the add device call. The stack parameter needs to be set to True.

POST dna/intent/api/v1/onboarding/pnp-device/import

[

  {

    "deviceInfo": {

      "serialNumber": "12345678902", 

      "aaaCredentials": {

        "username": "", 

        "password": ""

      }, 

      "userSudiSerialNos": [], 

      "hostname": "adam123", 

      "pid": "c9300", 

      "sudiRequired": false, 

      "stack": true 

    }

  }

]

The second is the site-claim. The type needs to be changed to “StackSwitch” and two extra attributes are required.

Note: The topOfStackSerialNumber has to be the same as the serial number used to add the device. In other words, add the device with the serial number you intend to use for the top of stack. It does not matter which switch in the stack initiates contact, as the stack will provide all serial numbers to DNAC.

POST dna/intent/api/v1/onboarding/pnp-device/site-claim

{

  "configInfo": {

    "configId": "e156e9e6-653d-4016-85bd-f142ba0659f8", 

    "configParameters": []

  }, 

  "type": "StackSwitch",

  "topOfStackSerialNumber":"12345678902",

  "cablingScheme":"1A", 

 

  "siteId": "d7941b24-72a7-4daf-a433-0cdfc80569bb", 

  "deviceId": "5eccad2e29da7c0008613b69", 

  "imageInfo": {

    "skip": false, 

    "imageId": "04d69fe0-d826-42e9-82c0-45363a2b6fc7"

  }

}

Continue reading

Threat Trends: DNS Security, Part 1

Part 1: Top threat categories

When it comes to security, deciding where to dedicate resources is vital. To do so, it’s important to know what security issues are most likely to crop up within your organization, and their potential impact. The challenge is that the most active threats change over time, as the prevalence of different attacks ebb and flows.

This is where it becomes helpful to know about the larger trends on the threat landscape. Reading up on these trends can inform you as to what types of attacks are currently active. That way, you’ll be better positioned to determine where to dedicate resources.

Our Threat Trends blog series takes a look at the activity that we see in the threat landscape and reports on those trends. After examining topics such as the MITRE ATT&CK framework, LOLBins, and others, this release will look at DNS traffic to malicious sites. This data comes from Cisco Umbrella, our cloud-native security service.

We’ll briefly look at organizations as a whole, before drilling down into the number of endpoints connecting to malicious sites. We’ll also look at malicious DNS activity—the number of queries malicious sites receive.

Overall, this can provide insight into how many malicious email links users are clicking on, how much communication RATs are performing, or if cryptomining activity is up or down. Such information can inform on where to dedicate resources, such as topics requiring security training or areas to build threat hunting playbooks.

Overview of analysis

We’ll look at DNS queries to domains that fall into certain categories of malicious activity, and in some cases specific threats, between January and December of 2020. While performing this analysis we looked at a wide variety of threat trends. We’ve chosen to highlight those that an organization is most likely to encounter, with a focus on the categories that are most active.

It’s worth noting that we’re deliberately not making comprehensive comparisons across categories based on DNS activity alone. The fact is that different threat types require varying amounts of internet connectivity in order to carry out their malicious activities. Instead, we’ll look at individual categories, with an eye on how they rise and fall over time. Then we’ll drill further into the data, looking at trends for particular threats that are known to work together.

Organizations and malicious DNS activity

To start off, let’s look at organizations and how frequently they see traffic going to sites involved in different types of malicious DNS activity. The following chart shows the percentage of Cisco Umbrella customers that encountered each of these categories.

To be clear, this does not indicate that 86 percent of organizations received phishing emails. Rather, 86 percent of organizations had at least one user attempt to connect to a phishing site, likely by clicking on a link in a phishing email.

Similar stories present themselves in other categories:

◉ 70 percent of organizations had users that were served malicious browser ads.

◉ 51 percent of organizations encountered ransomware-related activity.

◉ 48 percent found information-stealing malware activity.

Let’s take a closer look at some of the more prevalent categories in further detail, focusing on two metrics: the number of endpoints alerting to malicious activity (depicted by line graphs in the following charts), and the amount of DNS traffic seen for each type of threat (shown by bar graphs in the charts).

Cryptomining

It’s not surprising that cryptomining generated the most DNS traffic out of any individual category. While cryptomining is often favored by bad actors for low-key revenue generation, it’s relatively noisy on the DNS side, as it regularly pings mining servers for more work.

Cryptomining was most active early in the year, before declining until summer. This, and the gradual recovery seen in the later part of the year, largely tracks with the value of popular cryptocurrencies. As currency values increased, so too did the rate of activity. For example,  researchers in Cisco Talos noticed an increase in activity from the Lemon Duck threat starting in late August.

It’s also worth noting that there’s little difference there is between “legitimate” and illicit cryptomining traffic. Some of the activity in the chart could be blocks based on policy violations, where end users attempted to mine digital currencies using company resources. In cases like this, administrators would have good reason for blocking such DNS activity.

Phishing

The amount of phishing-related DNS activity was fairly stable throughout the year, with the exception of December, which saw a 52 percent increase around the holidays. In terms of the number of endpoints visiting phishing sites, there were significant increases during August and September.

This is due to a very large phishing campaign, where we see a 102 percentage-point shift between July and September. More on this later, but for now, take note of the point that dramatically more endpoints began clicking on links in phishing emails.

Trojans

Similar to cryptomining, Trojans started the year strong. The incredibly high number of endpoints connecting to Trojan sites was largely due to Ursnif/Gozi and IcedID—two threats known to work in tandem to deliver ransomware. These two threats alone comprised 82 percent of Trojans seen on endpoints in January.

However, the above-average numbers from January were likely tied to a holiday-season campaign by attackers, and declined and stabilized as the year progressed.

In late July, Emotet emerged from its slumber once again, comprising a massive amount of traffic that grew through September. This threat alone is responsible for the large increase in DNS activity from August through September. In all, 45 percent of organizations encountered Emotet.

Ransomware

For most of the year, two key ransomware threats dominated—one in breadth, the other in depth.

Beginning in April, the number of computers compromised by Sodinokibi (a.k.a. REvil) increased significantly and continued to rise into autumn. The increase was significant enough that 46 percent of organizations encountered the threat. In September, overall queries from this particular ransomware family shot up to five times that of August, likely indicating that the ransomware payload was being executed across many of the impacted systems.

However, this is a drop in the bucket compared to the DNS activity of Ryuk, which is largely responsible for the November-December spike in activity. (It was so high that it skewed overall activity for the rest of the year, resulting in below-average numbers when it wasn’t active.) Yet the number of endpoints connecting to Ryuk-associated domains remained relatively small and consistent throughout the year, only showing modest increases before query activity skyrocketed.

So, while one threat corrals more endpoints, the other is much busier. Interestingly, this contrast between the two ransomware threats correlates with the amount of money that each threat reportedly attempts to extort from victims. Sodinokibi tends to hit a large number of endpoints, demanding a smaller ransom. Ryuk compromises far fewer systems, demanding a significantly larger payment.

Tying it all together

In today’s threat landscape, the idea that ‘no one is an island’ holds true for threats. The most prevalent attacks these days leverage a variety of threats at different stages. For example, let’s look at how Emotet is often delivered by phishing in order to deploy Ryuk as a payload. While the data below covers all phishing, Emotet, and Ryuk activity, as opposed to specific campaigns, a clear pattern emerges.

Remember the 102 percentage-point shift in phishing between July and September? This lines up with a 216 percentage-point jump in Emotet DNS activity. Activity drops off in October, followed by an eye-watering 480 percentage-point increase in Ryuk activity.

Emotet’s operations were significantly disrupted in January 2021, which will likely lead to a drop-off in activity for this particular threat chain. Nevertheless, the relationship presented here is worth considering, as other threat actors follow similar patterns.

If you find one threat within your network, it’s wise to investigate what threats have been observed working in tandem with it and take precautionary measures to prevent them from causing further havoc.

For example, if you find evidence of Ryuk, but not Emotet, it might be worth looking for Trickbot as well. Both Emotet and Trickbot have been seen deploying Ryuk in attacks, at times in coordination, and other times separately.

Sure enough, Trickbot follows a similar pattern in terms of DNS activity—lower in the first half of the year, busy in August and September, then quiet in October. However, Trickbot was active between November and December, when Emotet was not, likely contributing to the phenomenal increase in Ryuk activity during these two months.

Preventing successful attacks

As mentioned earlier, the data used to show these trends comes from Cisco Umbrella, our cloud delivered security service that includes DNS security, secure web gateway, firewall, and cloud access security broker (CASB) functionality, and threat intelligence. In each of these cases, the malicious activity was stopped in its tracks by Umbrella. The user who clicked on a phishing email was unable to connect to the malicious site. The RAT attempting to talk to its C2 server was unable to phone home. The illicit cryptominer couldn’t get work to mine.

Umbrella combines multiple security functions into one solution, so you can extend protection to devices, remote users, and distributed locations anywhere. Umbrella is the easiest way to effectively protect your users everywhere in minutes.

Also, if you’re looking to get more information on the malicious domains that your organization encounters, Umbrella Investigate gives the most complete view of the relationships and evolution of internet domains, IPs, and files — helping to pinpoint attackers’ infrastructures and predict future threats. No other vendor offers the same level of interactive threat intelligence — exposing current and developing threats. Umbrella delivers the context you need for faster incident investigation and response.

Up next

In this blog we looked at the most active threat categories seen in DNS traffic, as well as how evidence of one threat can lead to uncovering others. In part two, we’ll break the data down further to examine which industries are targeted by these threats. Stay tuned to learn more about the impact on your industry!

Methodology

We’ve organized the data set to obtain overall percentages and month-on-month trends. We’ve aggregated the data by the number of endpoints that have attempted to visit certain websites that have been flagged as malicious. We’ve also aggregated the total number of times websites flagged as malicious have been visited. These numbers have been grouped into meaningful threat categories and, when possible, have been marked as being associated with a particular threat.

We’ve also applied filtering to remove certain data anomalies that can appear when looking at malicious DNS traffic. For example, when a C2 infrastructure is taken down, compromised endpoints attempting to call back to a sinkholed domain can generate large amounts of traffic as they unsuccessfully attempt to connect. In cases like these, we have filtered out such data from the data set.

The charts use a variation of the Z-score method of statistical measurement, which describes a value’s relationship to the mean. In this case, instead of using the number of standard deviations for comparison, we’ve shown the percent increase or decrease from the mean. We feel this presents a more digestible comparison for the average reader.

Source: cisco.com

Continue reading

How to Balance IT Stability and Strong Security

Remember the old days of deploying Anti-Virus (AV) across your organization? Most often, it was a “set it and forget it” approach. It worked back then. Until it didn’t.

This leaves us with a perplexing dichotomy. On the one hand, the mindset of the old AV days still persists, where many companies are reluctant to update, upgrade, or even touch their existing security technology. On the other hand, we found in our recent 2021 Security Outcomes Study that most practitioners believe a technical refresh is the most prudent approach to staying ahead of existing and emerging threats.

So where is the problem? What is it that causes organizations to resist upgrading?

Instability as a Source of Insecurity 

The problem is one of stability. After all the configurations have been tweaked to make a deployed product behave as a finely tuned engine, there is nothing more uncertain than having a vendor announce a new product that has the potential to disrupt your harmonious tech orchestration. To state it more bluntly, people have been burned too many times with the promise of the latest and greatest software that ultimately interrupts their workflow and, in some cases, entirely halts production.

This is the classic struggle between operations and security; they do not always line up. Everything might be flowing smoothly, but when an exploit emerges that an attacker could use to compromise the organization, the security team is viewed by the organization as overly paranoid if they want to make changes, threatening the stability of a perfectly functioning environment. In other instances, the security team may not even have the time to stay on top of necessary updates, leading to “upgrade resistance” even among the security ranks.

Why Is Stability Threatened When a New Product Is Introduced?  

According to our Security Outcomes Study, it would seem that the inability to retain skilled security professionals may be part of the problem. Another factor is that even with a staff of skilled professionals, they are often stretched beyond their capabilities and are expected to do too many tasks in the course of a normal workday. Unfortunately, short staffing and an overworked security team can lead to a lack of testing, which can create issues when it comes to effectively implementing software updates.

How to Ensure Success

Proper training

When we think about the tools needed to succeed, one of the best tools for any staff is training. If you offer training to the staff, you end up not only with a stronger, more skilled team but also a team that feels valued and appreciated. As shown below, role-specific training is one of the top success factors that can help a security team keep up with business demands.

Top security success factors for keeping up with the business

I am often reminded of a joke that I heard where a manager asks, “What happens if we spend money on training and the staff then leaves?” To which the other person responds, “What happens if you don’t train them and they stay?”

It is all about instilling confidence in the team and empowering them to make the correct choices when it comes to what’s best for an organization’s overall infrastructure. For example, testing prior to deployment is an absolute necessity towards the success of any project.

Reliable vendors

Another key to ensuring success is to work with reliable and trustworthy vendors. The vendor relationship is important from a technology standpoint as well as a business standpoint.

How can you combat the fear of new security technology in an organization? You can do so by imparting stability into project plans, which can be achieved by elevating your staff’s qualifications and by working with reputable vendors. As shown below, properly managing vendor security is one of the top success factors for creating a strong security culture within an organization.

Top success factors for creating a strong security culture

Automated, integrated technology

Last but certainly not least, technology itself can help with maintaining a stable and secure environment, while not letting software get out-of-date. In addition to protecting an organization’s infrastructure, security technology should ideally empower teams as well. It should provide security professionals with a boost, not a burden.

Seek out security technology that is streamlined, integrated, and automated. Unfortunately, the culture of procuring a new point product for every new security threat has left us with crushing complexity in many cases. Vendors today must simplify their security offerings by making them work together to reduce the manual processes that often slow down security teams.

By lessening the tedious, time-consuming tasks that stand in the way of fast, effective security, an integrated, automated tool set can help security teams more confidently stay on top of technology updates – and implement them more safely and securely. In time, this confidence can extend over to other parts of the organization and lessen overall resistance to change. After all, you cannot properly secure an organization with stagnant technology.

How Cisco can help

Cisco has been on a mission for several years to simplify and streamline its security capabilities. With the launch of Cisco SecureX, we introduced an integrated platform that incorporates greater visibility, efficiency, and automation into security processes. It brings together our entire Cisco Secure portfolio, as well as many third-party technologies, to streamline and strengthen operations not just for security teams, but for IT and networking groups as well.

With SecureX, these various teams can more easily collaborate – viewing and responding to the same data in the same place – to more quickly and effectively identify and troubleshoot potential issues. Additionally, since SecureX is delivered via the cloud, it is easy to add or update security capabilities as needed, further lessening the burden of proactive tech refreshes.

While there are many steps that can be taken to strengthen security, our Security Outcomes Study suggests that proactive tech refreshes, training, strong vendor relationships, and integration and automation can all go a long way.

Source: cisco.com

Continue reading

Meet the Enchanted Virtual Classroom

Cisco Networking Academy enables distance learning

The COVID-19 pandemic has disrupted the traditional education model for millions of students and teachers around the world, including the nearly 12,000 learning institutions worldwide that participate as Cisco Networking Academy schools. 

The Networking Academy curriculum has been delivered via a hybrid model of in-person and online teaching. So when the pandemic hit, and while many schools, teachers, and students experienced widespread disruption and challenges in making the move to a 100 percent online model, the Networking Academy transition was manageable, and students and teachers were already equipped to operate exclusively online effectively.

Beyond the move to a fully online model, the events of 2020 pushed our engineering teams at Cisco to look for new ways to offer both students and teachers more immersive experiences and better learning engagement opportunities.  

Working hand in hand with Networking Academy instructors, our engineers delivered significant enhancements to Cisco Packet Tracer’s physical mode. Combined with significant increases in the availability of our Cisco Webex collaboration suite, our teams have created what we like to think of as an “Enchanted Virtual Classroom.” 

Welcome to a world of enchantment

The concept of enchantment in the digital world – and specifically the notion of “Enchanted Objects” – has been introduced by David Rose, product designer and lecturer at the MIT Media Lab. According to Rose, Enchanted Objects can be brought to life thanks to specific design guidelines for immersive Internet of Things (IoT) environments that align with fundamental human desires including “omniscience, telepathy, safekeeping, immortality, teleportation, and expression.” 

Rose believes that IoT sensors and actuators embedded in our physical environments can lead to enchanting experiences. 

Within Cisco Networking Academy, we are applying this design philosophy to distance learning. 

Fusing Packet Tracer – which invokes senses of safekeeping (a safe place to make mistakes), omniscience (creating networks from scratch), and expression (telling networking stories relevant to their lives), with Webex – which invokes senses of telepathy (insight into how others think) and teleportation (video collaboration as if we were sharing the same physical space doing labs together) enables useful, purpose-driven, even enchanting distance learning experiences. 

We seek to help address issues that arise from the loss of physically co-located instructors, students, and equipment. A simulation-based microworld, like Packet Tracer 8.0, with enhanced physical mode representations, used in tandem with collaboration software such as Webex, may have synergies that lead to effective and delightful experiences. 

The Charm of Packet Tracer

The new version of Packet Tracer (PT 8.0), released last month, approximates the experiences of the real-world job and classroom lab interactions as shown in Figure 1. 

Using the “Geo” mode (Figure 2) students can explore floor plans, maps, and other background images that help provide context heat maps showing Wi-Fi, cellular, and Bluetooth signals, as well as manipulable cables. This representation encourages tracing a packet across various physical locations. 

With the new Packet Tracer capabilities, students can build “What-if” models, following their own inquiry, using Packet Tracer as a “virtual Lego kit.” Students can also be assigned structured design, configuration, and troubleshooting challenges, using activities that were authored via Packet Tracer’s Activity Wizard and which are automatically graded (as shown in Figure 3). 

Students can interact with a shelf (inventory system) at right, having to choose amongst devices. They can also interact with a pegboard, having to choose among cables, place devices at specific locations on tables (centre) and equipment racks (left), as well as power devices and read status LEDs.

The magic of learning through Webex 

Webex is now integrated within the NetAcad.com platform, making relevant features for teaching more readily available to Networking Academy instructors, including:

◉ Whole-class, lecture-style interaction via video and audio

◉ Breakout lab-group style interaction

◉ Screen sharing with remote annotation, desktop mouse and keyboard sharing, and whiteboarding

◉ Attendance, chat, polling, and notes

We believe Webex can enable interactions like “over the shoulder” coaching and peer-to-peer group collaboration within Packet Tracer labs, creating powerful synchronous and asynchronous distance learning experiences.

We know that human-to-human relationships are central to learning. Cisco Networking Academy is pioneering better distance learning by making enchanted virtual classrooms with playful, simulation-based, collaborative educational interactions a reality. And this is just the beginning.

Source: cisco.com

Continue reading