Last time I showed how it can be detected using only one solution – the Cisco Stealthwatch Enterprise network anomaly analysis system. Then we recorded the interaction of the malicious client part with the command server using the DNS protocol, which served as an indicator if it was used on unauthorized nodes within the corporate network. In fact, we looked for anomalies in network traffic to look for signs of an incident. Now let’s see how to identify a DNSpionage campaign using more familiar malware activity indicators (IOCs)?
We can see the list of indicators in any Threat Intelligence bulletin. In this case, we will use the site of Cisco Talos, the largest non-governmental incident investigation group in the world, which first revealed the DNSpionage campaign (here and here)
In the newsletter we see a list of indicators – file hashes, IP and domain addresses of the command and phishing servers involved in the attack.
If we “drive” each of the indicators through appropriate means of protection, then it will take us too long. For example, in Cisco AMP for Endpoints, an EDR class solution, we enter one or several hashes of interest to us in the search bar (top right):
and we get the result we are interested in – a node is found on which the activity of a malicious program is detected, which has the desired hash.
By the way, I want to note that hash search can be used not only to detect malicious activity, but also to combat information leaks. Recall that one of the technologies for dealing with leaks (along with containers / tags and content analysis) is the use of digital fingerprints, which can be implemented using just the hashes that AMP4E will control (as well as other Cisco solutions, which may include implemented AMP engine – Cisco Firepower, Cisco Email Security Appliance, Cisco Web Security Appliance, Cisco Umbrella, etc.). True, such a mechanism works only for rarely modified files. If you are interested in what Cisco offers to deal with leaks, I can recommend record and presentation our latest webinar, which we dedicated to this topic.
But back to our story. If you try to track access to the domains of command or phishing servers, then Cisco Umbrella can help us.
Since the main vector of infection in most incidents is email, we also need to look for indicators of interest to us in e-mail. To do this, we indicate the hash of the corresponding indicator in the Cisco Security Management Appliance or Cisco E-mail Security Appliance:
and we find 5 mailboxes in which traces of the files we are looking for are found.
Finally, Cisco Firepower, the next-generation firewall with built-in intrusion prevention system, helps us track (and block) the IP addresses that the client part of the malicious campaign interacts with.
In this example, although we detect the signs of DNSpionage, we are not doing it as fast as we wanted. We are switching between consoles. We carry out many copy-past operations and 4 different products are looking for 4 different types of indicators of compromise, thereby increasing the time for investigation and response. Can this process be accelerated? Of course. You can use SIEM, which can be integrated with TI sources, or into which you can download indicators of compromise from external TI sources. But it is expensive if it is commercial, or requires high competencies, if it is from the category of open source. There is a simpler and all the more free solution – Cisco Threat Response, which is focused primarily on Cisco solutions, as well as on solutions of other vendors. Using the browser plug-in, we “pull” all indicators from the Cisco Talos blog page that describe the DNSpionage campaign.
To speed up the response process, we can block the relevant indicators directly through the plugin.
But we are interested in investigating the incident in an attempt to understand which of our nodes and users were compromised. And it is advisable to see everything on one screen. CTR just gives us this opportunity. In the upper left of the graphical interface, we see all our indicators. In the lower left – a map of our “infection”.
The purple color shows already affected targets in our infrastructure – PCs, mailboxes, subnets, etc. In the upper right part we see a timeline that displays the dates of the appearance (including the first) of indicators in our network environment. Finally, the lower right area allows us to get detailed information on each indicator, enriched and verified by external TI sources, for example, VirusTotal, or third-party protection tools.
Having understood the extent of the infection, we can begin to respond appropriately to the identified threat by blocking its manifestations through Cisco Umbrella, which blocks interaction with the domains of command servers:
or through Cisco AMP for Endpoints, which isolates the operation of a malicious file or process.
Immediately from the CTR interface we can see the result of blocking a file, domain or other indicator.
By integrating CTR with the Cisco E-mail Security Appliance or Cisco Firepower, we can also isolate infected mailboxes or compromised sites, respectively.
Is it possible to do the same thing, but without using the Cisco Threat Response interface? Sometimes you want to use your own, more familiar tools for this. Yes you can. For example, we can embed CTR functionality in any technology that supports a browser (for example, in our own portal), and due to the availability of APIs, CTR functions can be accessed from anywhere.
Suppose you prefer a command line interface and want to investigate and respond by entering all the commands from the keyboard. This is also easy to do. For example, here’s how CTR integration works with the Cisco Webex Teams teamwork system and the AskWill bot developed for it using the DNSpionage campaign as an example. Cisco Webex Teams is often used by our customers to organize the interaction of information security specialists. This example is all the more interesting because it shows how you can build a process of investigation and response when working remotely, when, the only thing that unites SOC specialists is a communication system.
For example, we want to get the status for the domain 0ffice36o.com, which was used by the command server as part of DNSpionage. We see that Cisco Umbrella returns us the status of “malicious”.
And here is how the team will look for information on whether there are several indicators of compromise for the DNSpionage campaign identified by Cisco Talos in our infrastructure at once.
Then we can block the malicious domain through Cisco Umbrella or Cisco Stealthwatch Cloud. In the latter case, the anomaly analysis system will block interaction with the command server for the Amazon AWS, MS Azure cloud infrastructures we use, etc.
Finally, if we mistakenly blocked an indicator, or over time it became known that it has ceased to pose a threat, we can remove it from the black list of protective solutions.
This is how the free Cisco Threat Response solution works, whose main task is to reduce the time to investigate and respond to incidents. And as our customers say, CTR allows them to significantly reduce it. 60% of users have a reduction of 50%; another 23% have at least 25%. Not bad for a free solution, huh ?!
- Integration of Cisco Threat Response and Cisco Stealthwatch Enterprise
- Interaction of Cisco solutions in GosSOPKoy and FinCERT
- Why doesn’t Cisco buy Splunk or a talk about how the Cisco platform works for threat hunting
- Threat Hunting with Cisco Visibility
- Case Studies for Using Network Anomaly Analysis Tools: DNSpionage Campaign Discovery