Unleashing SecureX on a real Cyber Campaign

There’s so much excitement around the general availability (GA) for SecureX. Let’s take a look under the hood as the industry learns to define what we should all expect from a security platform. And while I have your attention, I am going to attempt to thoroughly explain how SecureX delivers simplicity, visibility and efficiency through a cloud-native, built-in platform with an emerging use case. Here is the problem statement – we want to investigate cyber/malware campaigns impacting your environment and if there are any identified targets by looking at historical events from your deployed security technologies. Every Cisco security customer is entitled to SecureX and I hope you find this use case walk-through helpful. I will also share a skeletal workflow – which you can either run as your own ‘playbook’ or modify to be as simple or complex as your needs merit.

Let’s set the background. Recently we have been made aware that certain Australian government owned entities and companies have been targeted by a sophisticated state-based actor. The Australian Cyber Security Centre (ACSC) has titled these events as “Copy-Paste Compromises” and have published a summary with links to detailed TTPs (tactics, techniques, procedures). The ACSC also published and is maintaining an evolving list of IOCs (indicators of compromise) which can be found here. As far as mitigations, ACSC recommends prioritizing prompt patching of all internet facing systems and the use of multi-factor authentication (MFA) across all remote access services. Also, the ACSC recommends implementing the remainder of the ASD Essential Eight controls. Cisco Security has a comprehensive portfolio of technologies that can provide advanced threat protection and mitigation at scale. My colleague Steve Moros talked about these in his recent blog. However, if you are curious like me, you would first want to understand the impact of the threat in your environment. Are these observables suspicious or malicious? Have we seen these observables? Which endpoints have the malicious files or have connected to the domain/URL? What can I do about it right now?

If you are not in Australia, don’t walk away just yet! The title ‘Copy-Paste Compromises’ is derived from the actor’s heavy use of proof of concept exploit code, web shells and other tools copied almost identically from open source. So you may see some of these in your environment even if you are not being specifically targeted by this campaign. Also you can replace the example above with any other malware/cyber campaign. Typically you will find blogs from Cisco (TALOS) or other vendors or community posts, detailing the TTPs and more importantly the IOCs. In other situations, you might receive IOCs over a threat feed or simply scrape them from a webpage/blog/post. Irrespective with minor tweaks the below process should still work for any of those sources as well. Let’s get started!

Step 1 – Threat Hunting & Response

In this step, I simply copied all the IOCs from the published csv file and put them into the enrichment search box in my SecureX ribbon. This uses SecureX threat response to parse any observables (domains, IPs, URLs, file hashes, etc) from plain text and assign a disposition to each observable. We can see there are 102 observables that have been tagged as clean (3), malicious (59), suspicious (1) and unknowns (39). The unknowns are of higher concern, as the malicious and suspicious observables would hopefully have been blocked, if my threat feeds are working in concert with my security controls. Nonetheless, unless they are of clean disposition, any sightings of these observables in an environment are worth investigating. Also the ACSC will keep adding new observables to their list, as this campaign evolves. That just shows the live nature of today’s cyber campaigns and how important it to stay on top of things! Or you can automate it all, using the workflow I describe in Step 2 a bit later in this blog.

Figure 1: Observables from Text in SecureX Dashboard

Let’s see if there are any sightings of these observables in my environment and identify any targets. I do this by clicking the “Investigate in Threat response” pivot menu option in the ‘Observables from Text’ pop-up. This brings all the observables into SecureX threat response which then queries integrated security controls (modules) from my environment. In my case, 5 modules including Umbrella and AMP, had responses. I can quickly see any historical sightings, both global, and local to my environment.

Figure 2: Threat Hunting with SecureX threat response

There are few things to take note of in the screenshot above. The horizontal bar on top breaks down the 102 observables from ACSC into 9 domains, 31 file hashes, 44 IP addresses, 6 URLs and email addresses. I can now expand to see dispositions of each of them. The Sightings section (top right) gives me a timeline snapshot of global sightings and most importantly the 262 local sightings of these observables in my environment over the last few weeks. And an important detail on the top left we have 3 targets. This means that 3 of my organization’s assets have been observed having some relationship with one or more of the observables in my investigation. I can also investigate each observable more deeply in the observables section (bottom right). The relations graph (bottom left) shows me any relationships between all the 102 observables and the 3 targets. This helps me identify ‘patient zero’ and how the threat vector infiltrated my environment and spread.

Let’s expand the relations graph to get a closer look. I can apply various filters (disposition, observable type, etc.) to figure out what is going on. I can also click on any observable or target, both in relations graph as well as anywhere else in the SecureX/Threat Response user interface‑to investigate it further using threat intelligence or pivot into related Cisco Security products for a deeper analysis. Once I have completed the analysis, I can start responding to the threat, from the same screen. With a few clicks in the SecureX/Threat Response user interface, I can block any of the observables in the respective Cisco Security products (files in Cisco AMP, domains in Cisco Umbrella, etc.) and even isolate infected hosts (in Cisco AMP) to prevent further spread. I can also go beyond the default options and trigger pre-configured workflows (explained in next section) to take action in any other security product (Cisco or 3rd party) using the power of APIs/adapters. This is the illustrated by the ‘SecureX Orchestration Perimeter Block’ workflow option in below screenshot amidst other analysis/response options.

Figure 3: Incident Response with a click

So far, using SecureX threat response, we have simplified the threat hunting and response process. We were able to take all the ACSC observables, run them through various threat feeds and historical events from our security controls, while avoiding the need to jump through each security product’s user interface. We have avoided “the swivel chair effect”, that plagues the security industry!

Step 2 – Orchestrating it all with a workflow

While we achieved a lot above using the power of APIs, what if we could further minimize the human intervention and make this an automated process. SecureX orchestrator enables you to create automated workflows to deliver further value. The workflow below can be modified for any IOC source, including the TALOS Blog RSS Feed, however in this case we are going to use the ACSC provided IOC csv file.

I’d like to credit my colleague Oxana who is deeply involved with our devnet security initiatives for the actual playbook I am about to share below. She is very comfortable with various Cisco Security APIs.

Here is the generic workflow:

Figure 4: the Workflow

The workflow itself is fairly straightforward. It uses SecureX threat response APIs for the bulk of the work. For notifications we chose Webex APIs and SMTP, but this can be replaced with any collaboration tool of choice. The steps involved are as follows:

1. Get Indicators – by making a generic http request to ACSC hosted IOC csv file (or any other source!), do some clean up and store the raw indicators as text

2. Parse IOCs – from raw text stored in step 1, using SecureX threat response Inspect API

3. Enrich Observables – with SecureX Threat Response Enrich API to find any global sightings (in my integrated threat feeds) and more importantly local sightings/targets (in my integrated security modules like Umbrella, AMP, etc.)

4. Notify – if any targets found (from local sightings). For each queried module, post the targets on Webex teams and/or send an email.

5. Case Management – by creating a new casebook the first time any targets are found. On subsequent runs keep updating the casebook if targets found.

Here are some screenshots of the workflow in SecureX orchestrator. It is a bit difficult to fit in one screen, so you get 3 screenshots!

Figure 5: Workflow in SecureX orchestrator

It is possible to further improve this workflow by adding a schedule, so that workflow runs every few hours or days. This may be useful as ACSC keeps updating the indicators regularly. Another option could be to build in response options (with or without approval) using the SecureX threat response API. These are just ideas and the possibilities are limitless. SecureX orchestrator can be used to modify this workflow to run any API action for notifications and responses, both on Cisco and 3rd party products. Simply use the built in API targets or create new ones (eg. for 3rd party products), add any variables and account keys and just drag and drop the modules to build logic into your workflow. Essentially, we have given you the power of workflow scripting in a drag and drop UI. Every environment is different and so we will leave it for the readers to improve and adapt this workflow to their individual needs. Lastly as mentioned before, you can also use this workflow for extracting observables from any other web sources and not just the ACSC Copy Paste Compromises IOC list. To achieve this just modify the “ACSC Advisory Target” under Targets.

Figure 6: Modifying the observables source

The above workflow is hosted on github here. You can import it into your own SecureX orchestrator instance as a json file. Before you go through the import process or when you run the workflow, you will need to provide and/or adjust variables like the Webex token, Webex teams room id and email account details.

Figure 7: Adding the notification variables

Lastly when you run the workflow, you can see it running live, the input and output of every module and every ‘for’ loop iteration. This allows easy troubleshooting of things from the same friendly graphical interface!

Figure 8: Running the workflow in SecureX orchestrator

After running the playbook, you should see email notifications or Webex Teams messages, indicating targets found (or not) for each queried module. You should also see a case by selecting “Casebook” on the SecureX ribbon on the SecureX dashboard.

Figure 9: Webex Teams notifications on local sightings and targets

Figure 10: Casebook in SecureX dashboard

If you are a Cisco Webex Teams customer, simply login and get your personal webex access token to use in the workflow from here. To get the room id for the Webex Teams room that will be used for notifications from the workflow, add roomid@webex.bot to the room and it will reply to you with a private message containing the room id. Oxana has documented everything needed to get the workflow going in the readme file.