Introducing Stealthwatch product updates for enhanced network detection and response

We are very excited to announce new features of Cisco Stealthwatch! With release 7.3.0, we are announcing significant enhancements for the Stealthwatch Administrator and the Security Analyst to detect and respond to threats faster and manage the tool more efficiently.

Automated Response updates

Release 7.3, introduces automated response capabilities to Stealthwatch, giving you new methods to share and respond to alarms through improvements to the Response Management module, and through SecureX threat response integration enhancements.

New methods for sharing and responding to alarms

Stealthwatch’s Response Management module has been moved to the web-based UI and modernized to facilitate data-sharing with 3rd party event gathering and ticketing systems. Streamline remediation operations and accelerate containment through numerous new ways to share and respond to alarms through a range of customizable action and rule options. New response actions include:

◉ Webhooks to enhance data-sharing with third-party tools that will provide unparalleled response management flexibility and save time

◉ The ability to specify which malware detections to send to SecureX threat response as well as associated response actions to accelerate incident investigation and remediation efforts

◉ The ability to automate limiting a compromised device’s network access when a detection occurs through customizable quarantine policies that leverage Cisco’s Identity Services Engine (ISE) and Adaptive Network Control (ANC)

Figure 1. Modernized Response Management module with new response action options

SecureX threat response integration enhancements

Get granular and be specific with flexible rule configurations that provide the ability to:

◉ Define which alarms from Stealthwatch are shared with SecureX threat response

◉ Base shared alarms off multiple parameters, such as alarm severity, alarm type, and host group

◉ Share alarms from mission critical services with the ability to define incident confidence levels, how target objects are formed, and rule conditions based off targets created for internal or external hosts

Figure 2. Customize which alarms are sent to SecureX threat response by severity

SecureX platform integration enhancements

Cisco’s SecureX platform unifies visibility, centralizes alerts, and enables automation across your entire security infrastructure on a single dashboard. Maximize operational efficiency, eliminate repetitive tasks, simplify business processes, and reduce human errors by:

1. Automating responses with pre-built workflows through SecureX’s orchestration capabilities

2. Creating playbooks with all your integrated security tools through SecureX’s intuitive interface

Figure 3. SecureX’s pre-built workflows and customizable playbooks

Enhanced security analytics

As threats continue to evolve, so do the analytical capabilities of Stealthwatch to deliver fast and high-fidelity threat detections. The cloud-based machine learning engine (Cognitive Intelligence) has been updated to include:

◉ New confirmed detections

◉ New machine learning classifiers for anomalous TLS fingerprint, URL superforest, and content spoofing detections

◉ Smart alert fusion in the new user interface (currently available in beta)

◉ New Stealthwatch use cases including Remote Access Trojan and Emotet malware detections

Figure 4. An example of the new content spoofing detector classifier in action.

Figure 5. Stealthwatch’s new GUI with smart alert fusion.

Easier management

Web UI improvements

Don’t let the setup process slow you down! Optimize installation with web UI enhancements that reduce deployment time and support full configuration of (both?) the appliance and vital services before the first reboot to save time.

Flow Sensor versatility and visibility enhancements

Get visibility into more places than ever before through ERSPAN (Encapsulated Remote Switch Port Analyzer) support now added to Flow Sensors. Benefits include:

◉ Visibility improvements through the ability to see within VMware’s NSX-T data centers to facilitate Flow Sensor deployment and network configuration

◉ Removed requirement of direct physical connectivity

◉ ACI traffic monitoring from Spine and Leaf nodes

Continue reading

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.

Continue reading

Buyers Beware: Scamming Is Rife, Especially In a Time of Crisis

For years, scammers have been using a combination of Blackhat SEO techniques, phishing sites and newsworthy events to either trick individuals into giving up personal information including credit card numbers or to install malware or both. Preying on an individual’s fears has always been a go to tactic for scammers.

Recently a friend texted me and asked if I could take a look at a website his wife used to try and buy some 3M N95 face masks from. He was concerned that the site did not appear to be legitimate. “Sure”, I said, “What is the domain?” He sent it over. mygoodmask[.]com. Having spent the last decade looking at malware, spammers and scammers, I responded immediately, “Yes, it’s very bad. Tell her to cancel her credit card as soon as possible.”

I figured I’d take a closer look at the domain to confirm if I was right. Dropping the domain into Cisco Threat Response – our platform that accelerates investigations by automating and aggregating threat intelligence and data across your security infrastructure. Threat Response didn’t return anything useful aside from the IP Addresses it resolved to. Since the platform is configured for my test organization at the office, it’s not going to show me any hosts that may have visited that domain, but it is still a great source of intelligence. It showed that Cisco was aware of the domain, but there was no additional information – not surprising for newly created and used domains. There is more than one way to determine if a domain is suspicious.

Enriching the two IP addresses, 50[.]97.189.190 and 66[.]147.244.168, returned everything I needed to decide that the original site was malicious. Nearly two hundred domains resolving to those two addresses, none of which looked like ones I’d like to end up on.

At this point I was curious about the website itself and wanted to take a closer look. I submitted the domain to Threat Grid, Cisco’s malware analysis tool. It immediately redirected to greatmasks[.]com which resolved to 37[.]72.184.5. Using Glovebox, a capability in Threat Grid that allows full interaction with the virtual machine, I attempted to buy some masks from the website. I used an expired card number to purchase my masks. They are using PayPal to collect payments and validate card numbers.

The results produced from the analysis highlighted further details on the website, indicating a high level of suspicious activity.

Drilling down on the IP address that the new domain resolved to, we found another related domain, safetysmask[.]com. At this point it would be easy to create a new Casebook and add these observables to the investigation.

For me, one of the most telling signs of an unknown domain is the lookup frequency and activity mapped to the domain creation date and DNS changes. A scammer may register domains and park them until they’re ready to use them. At that point they’ll set up a website and point that domain to an IP.

Looking at the timeline and domain lookup activity in Cisco Umbrella, our DNS-layer SaaS solution, it’s clear that this website has been up for less than a month which is unusual, especially in context of this investigation.

Using a combination of our platform capability and our DNS-layer security, I was able to validate that this domain, IP Addresses, and related domains were malicious. With investigations of this nature, the domain or IP might not always have a known disposition at a certain point in time but often, by following the breadcrumb trail of related information, it’s easy to make a determination and judgement about the original domain. Another path to determining the disposition of these domains is to drill down into the observables in Umbrella.

Cisco Security products not only integrate via Threat Response, there are multiple direct integrations between products as well. These integrations are used to share threat intelligence produced by individual products and to share capabilities across products through API integrations, data visualization and cross product capabilities such as Casebook’s browser plugin.

Umbrella, our cloud-delivered DNS- layer of protection, integrates with Threat Grid, our malware analysis tool, and this allows Umbrella to show information produced through dynamic analysis, mapping domains and IP addresses to samples seen in Threat Grid’s global database, providing another method of determining disposition.

By the end of my digging, I had found hundreds of scams related to sports events, fashion accessories, flu season and more. All easily searchable within your organization via Threat Response and just as easily blocked via Umbrella.

What began as just a way to help a friend one evening, became a quick but comprehensive investigation into how bad actors are trying to capitalize on a global health crisis. Hopefully this was helpful in showing how easy it can be to validate the disposition of a domain using related observables, and in doing so, build out a collection of new content to be leveraged in your environment for detection and prevention.

Continue reading

Stealthwatch Enterprise and Cisco Threat Response: Bringing machine-scale analysis to human-scale understanding

From zero-day malware to cryptojacking, from man-in-the-middle attacks to spear phishing, from ransomware to distributed denial of service attacks (DDoS) attempts – businesses of all sizes and industries are the constant target of these attacks. It’s perfectly normal to find this barrage of threats overwhelming – and then there’s constant pivot between multiple security solutions required to detect, investigate and remediate.

Now imagine a world where disparate solutions do not exist. A world where there is no need to manually correlate information from various sources to build a complete picture of each potential threat. Where two clicks are all it takes to get situational awareness of the threat impact and potential scope of compromise, and the context needed to formulate an adequate response strategy.

Two clicks and done, you say?

What if you could get insights into everything going on across the network, and you could quickly baseline your environment’s normal behavior, no matter what your organization’s size or type? And what if this knowledge could also be correlated with alerts across your endpoints, firewall, web, etc. to make it easier to identify something suspicious and kick it off your network? With Cisco Threat Response, you can now convert this vision into reality. It is a key pillar of Cisco’s integrated security platform and is designed to give you the contextual awareness you need so you can see, investigate, and act on threats fast. Our obsession with connecting the dots within your network has already made Threat Response the Incident Response workbench of choice for SOCs across the world.

Get Answers, Not Alerts

An investigation can involve dozens or even hundreds of discrete data elements, multiple sources of threat intelligence and an armor of security products providing telemetry. Before Cisco Threat Response, each observable had to be investigated against each threat intel source and each network and security products individually and manually, which takes even seasoned experts a long time to do. With Threat Response, they can either simply paste all of those observables into Cisco Threat Response and it does the work for them. It brings all of that knowledge back from intel sources and security products, displaying results in seconds. From there, SOC teams can take action immediately or continue their investigation with the tools provided.

Cross-platform visibility and response powered by analytics

We all know that security analytics has become something of a buzzword, but it continues to gain positive momentum and sustain relevance. Cisco’s network security analytics solution, Cisco Stealthwatch Enterprise integration with Threat Response brings the power of each to the other.

How does this work?

Stealthwatch provides agentless enterprise-wide visibility, across on-premises, as well as in all public cloud environments. Using the power of behavioral modeling, multilayered machine learning, and global threat intelligence, Stealthwatch Enterprise produces alarms on critical threats by monitoring both north-south and east-west traffic. Stealthwatch sends those alarms directly to Cisco Threat Response’s Incident Manager feature, allowing users to see those alarms alongside prioritized security alerts from other products such as Firepower devices. This communication is handled via a secure intermediary cloud service called Cisco Security Service Exchange (SSE). No internal data is bulk uploaded to the cloud; sightings and the associated metadata are sent only in response to specific queries. In this way, investigations on all IP addresses are enriched with Stealthwatch insight, regardless of the catalyst for the investigation, all delivered in seconds and in an easy to read graphical format that helps you both intuitively understand what happened and respond quickly and effectively across your entire portfolio. These incidents can then be investigated with additional context from your other threat response-enabled technologies, all in one console, with one click. This lowers the time required to perform triage and response to these alarms.

Figure1- Ability to pivot and drill-down into the Stealthwatch Management Console or choose to investigate a directly in Threat Response

Figure 2-Enrichment of Stealthwatch alarms with context from other security technologies. Block suspicious files, domains, and more–without having to log in to another product first.

The Stealthwatch -Threat Response integration bring together a number of unique differentiators for the SOC workflow. Our Cisco Security customers are able to:

◉ Streamline Investigation Workflow

◉ Enhance Collaboration with Case Book

The  casebook browser plug in allows a Stealthwatch users to leverage all the power of their configured threat response modules, right from the Stealthwatch interface via built-in pivot menus. For example, you can use it to pull IP addresses or domains from Stealthwatch interface where there’s an observable and the casebook feature of Threat response will allow you to kick off an investigation directly from your browser.

◉ Accelerate Response with Incident Reporting to Threat Response

Stealthwatch automatically shares critical and major Alarms with Cisco Threat Response as Incidents which are then further enriched. You are able to tie independent product data and events together to uncover threats by investigating multiple observables across multiple data sets and products. The integration gives you the power to investigate with automated enrichment and respond with confidence directly from the Threat Response interface using products such as AMP for endpoint and Umbrella.

◉ Access the Power of Analytics ( for existing Threat Response users)

With the integration, Threat Response users can now investigate entity security events sent over from Stealthwatch in cases where the potential host can be the source or target of an event. This provides granular visibility on internal network activity for suspected hosts under investigation.

Simplify to Amplify

Threat Response is designed to get you more from your Cisco Security investments by automating integrations directly out of the box. It’s also designed to dramatically cut the time and effort needed to detect, investigate, and remediate – making your SOC operations more efficient and effective.

More than 6,700 customers today are reducing the time it takes to both investigate and respond to threats across multiple security technologies with Cisco Threat Response. And it’s included as part of the Cisco Security product licenses and take under 10 minutes to get up and running in your SOC. There’s nothing more to buy.

Overwhelmed to Empowered

At every RSA conference, 600 security vendors vie for the CISO’s mindshare with no shortage of vendors offering point solutions that offer miracles for your SOC.The reality is that most organizations already have an abundance of point products designed to address specific challenges, but most of these products can’t be easily integrated to fulfill a larger and more effective security strategy. Isn’t it time for the security industry to do better? At Cisco, we think it is. We’re building a platform that redefines security powered by integrations. At the heart of our platform approach is a simple idea: security solutions should be designed to act as a team. We invite you to come with us on this journey that simplifies your experience and reduces complexity, paves the path for an integrated and open platform that strengthens operations, stays out of the way, and gives your team time back.

Continue reading

Remote Access Trojans

You’re working for a high-profile technology company, close to releasing a market-changing product to the public. It’s a highly contested space, with many competitors, both domestic and international. There’s also a lot of buzz in the media and online speculation on the scope and impact your new product will have. And it goes without question that customers are keen to know more about the upcoming game-changer.

Your goal is to keep the secrets under wraps until the public announcement. Unfortunately, your surprise is about to be spoiled. It happens sometimes, as much as we work to prevent it—from accidental embargo slips to insider leaks. But in this case, it’s arguably the worst-case scenario: Your company has been breached and information about the product was stolen.

It’s unfortunate, but such breaches are not an uncommon occurrence—it’s something security professionals are far too familiar with. They occur across sectors, yet the way the data is stolen often includes familiar patterns. There are plenty of possible suspects, and untangling their motives is difficult. But in this cybersecurity game of “Clue,” we’re less concerned if it were Mrs. Peacock or Professor Plum. We want to know what the weapon was and how to prevent future murders.

There are a variety of useful weapons in an attacker’s arsenal. Downloaders, administration tools, and infostealers all often play a part in such an attack. But the go-to tool in many scenarios like this today are remote access trojans, often referred to as a “RATs.”

The anatomy of a RAT

A RAT is a swiss army knife of sorts. Distributed through familiar vectors, such as malicious downloads and email attachments, many RATs include all the weapons mention above, and more, making it easier for an attacker to leverage each component when carrying out an attack. In short, a RAT consolidates a number of tools into one package.

There is a lot of variation from RAT to RAT. Some are generalist tools, meant to be used across a variety of attack scenarios. Others are highly tailored to a specific attack. Some RATs use predetermined proxies to help mask an attacker’s ultimate location. Other RATs may leverage command-and-control (C2) infrastructure to do the same.

While the functionality and infrastructure used by a given RAT will differ, what follows are common features found within many RATs. To illustrate an attack, let’s take it back to our tech company breach, showing how an attacker can leverage a RAT to gain access to, and steal, sensitive files on your upcoming product.

Gather system information

The attacker managed to breach the defenses in your company using a phishing email that included a link to the RAT. However, that doesn’t mean that they will immediately know where they are on the network. They’ll naturally want to learn more about the computer they compromised. Is it an administrative assistant’s desktop, a laptop belonging to finance, or a web server? Performing reconnaissance on the system helps the attacker learn how deep into an organization they have penetrated, if they need to move laterally, or if they’re reached their intended target. Some reconnaissance tools even allow an attacker to scan other systems, gathering information about them.

Steal usernames and passwords

The attacker got onto one machine, but it wasn’t the intended target. They’d compromised a computer belonging to someone in the engineering group, but the materials they were after resided on a shared server. To move laterally, they may want to try searching for login credentials on the system they’ve already compromised. Many RATs include the ability to scrape saved and cached passwords, and once the usernames and passwords are in hand, the attacker can attempt to log into the shared server.

Log keystrokes

The attacker scanned the compromised computer looking for the login credentials, but no luck. Good news? Yes, but it’s only a minor setback. Many RATs include information-stealing components like keyloggers, meaning all the attacker has to do is enable it, and wait for the user of the compromised system to log into the shared server. When they enter login credentials, the attacker can capture them, and later attempt to log into the server themselves.

Download further malware

The attacker was able to obtain login credentials; however, their attempt to log in failed. (Perhaps your company uses multi-factor authentication?) To get to that shared engineering server, the attacker is going to have to call in reinforcements. They’ve identified a vulnerability on the shared server, and they need an attack toolkit to exploit it and gain access. Given how networks vary widely, many RATS include the ability to download further tools to assist them in gaining further access. In this case, the RAT operates like a downloader, pulling down an attack toolkit that allows the attacker to progress.

Accessing and uploading files

The attacker managed to gain access to the shared server, traversed its directory structure, and located documents that outline your new product’s features. The next step is to exfiltrate those files. Most RATs contain the ability to upload files to a predetermined location. This is often done with help of a proxy or through a C2 infrastructure, thus covering the attacker’s tracks as they steal the documents in question.

Recording audio, video, and taking screenshots

There may be times that an attacker isn’t satisfied with simply stealing design docs. Perhaps they obtained a slide deck, but it lacks context in certain slides. In order to learn more, they might want to return their attention to the initially compromised computer and have the RAT to record audio and/or video. The RAT might overhear the engineer speaking to a coworker or capture a video of a presentation meeting that discusses the product. RATs can often take screenshots as well, capturing critical documents on display.

Other uses

This is just one scenario where a RAT could be used end-to-end in an attack. RATs can be used in other situations as well. For instance, what if an attacker is hoping to exfiltrate financial data? A RAT can be leveraged to scrape banking details from a compromised computer or collect credit card numbers using a keylogger.

What’s important to highlight is that most RATs provide command line access to the systems that have been compromised. If adequate administrative rights are gained on these computers, an attacker can use a RAT to do just about anything that he or she desires.

Notable RATs

RATs have been around for a long time, and many prominent RATs have come and gone. Some recent RATs that have been prevalent on the threat landscape include Orcus RAT and RevengeRAT, which have been used by a variety of threat actors. Another commonly seen RAT is ExileRAT, which has been used in attacks with possible espionage-related motives, and shares a C2 infrastructure with the LuckyCat family of threats.

Not all RATs are built from the ground up either. Some are semi-legitimate tools, repurposed or reconfigured for malicious use. Two such examples include Imminent RAT and Remcos.

There are a number of attack groups monitored by Talos Intelligence that use RATs in their malicious campaigns. The SWEED threat actor often used Agent Tesla, the Panda threat actor has been seen dropping Gh0st RAT, and the Tortoiseshell group, who was recently caught scamming veterans, uses a RAT called IvizTech.

To catch a RAT

So the attacker managed to get into your network and obtain your product plans this time. How do you prevent them from doing it next time?

Fortunately, there isn’t anything particularly special about the way a RAT gets onto a system. They’re distributed in much the same way as other types of malware: they’re sent by email, dropped by droppers, set up as the payloads for exploit kits, along with other common attack vectors. Consider the following:

• A good endpoint protection application is very useful in protecting against RATs. AMP for Endpoints blocks malware at point of entry, then detects, contains, and remediates advanced threats.
• Monitoring network traffic for unauthorized activity is also important. Cisco Stealthwatch is the most comprehensive visibility and network traffic security analytics solution that uses enterprise telemetry from the existing network infrastructure.
• Many RATs encrypt their traffic, as we discussed in last month’s Threat of the Month blog, so be sure you can monitor such traffic as well. Encrypted Traffic Analytics provides insight into threats in encrypted traffic, without the need for decryption, using network analytics and machine learning.
• Being able to connect to C2 domains is vital for many RATs to function. Blocking known malicious domains can go a long way in stopping a RAT in its tracks. Cisco Umbrella uses DNS to stop threats over all ports and protocols—even direct-to-IP connections—preventing connections to attacker’s servers.
• Multi-factor authentication products can prevent an attacker from logging into a system if they manage to obtain login credentials. Verify users’ identities with applications such as Cisco Duo.
• A good email security solution, as well as a strong network perimeter, will help to ensure that RATs are blocked outright. Cisco Email Security is your best defense against such attacks via email, while Cisco’s Next-Generation Firewall can stop attacks at the network boundaries.
• A web security appliance with data loss prevention (DLP) features will also assist in cases where a RAT gets in and is attempting to steal sensitive information through the network. The Cisco and Digital Guardian DLP solution is a high-performance, comprehensive security solution for data in motion.

Continue reading

Threats in encrypted traffic

There was a time when the web was open. Quite literally—communications taking place on the early web were not masked in any significant fashion. This meant that it was fairly trivial for a bad actor to intercept and read the data being transmitted between networked devices.

This was especially troublesome when it came to sensitive data, such as password authentication or credit card transactions. To address the risks of transmitting such data over the web, traffic encryption was invented, ushering in an era of protected communication.

Today more than half of all websites use HTTPS. In fact, according to data obtained from Cisco Cognitive Intelligence, the cloud-based machine learning engine behind Stealthwatch—Cisco’s network traffic analysis solution—82 percent of HTTP/HTTPS traffic is now encrypted.

The adoption of encrypted traffic has been a boon for security and privacy. By leveraging it, users can trust that sensitive transactions and communications are more secure. The downside to this increase in encrypted traffic is that it’s harder to separate the good from the bad. As adoption of encrypted traffic has grown, masking what’s being sent back and forth, it’s become easier for bad actors to hide their malicious activity in such traffic.

A brief history of encrypted traffic

The concerns around security and privacy in web traffic originally led Netscape to introduce the Secure Sockets Layer (SSL) protocol in 1995. After a few releases, the Internet Engineering Task Force (EITF) took over the protocol, which released future updates under then name “Transport Layer Security” (TLS). While the term SSL is often used informally to refer to both today, the SSL protocol has been depreciated and replaced by TLS.

TLS protocol works directly with existing protocols and encrypts the traffic. This is where protocols like HTTPS come from— the hypertext transfer protocol (HTTP) is transmitted over SSL/TLS. While HTTPS is by far the most common protocol secured by TLS, other popular protocols, such as SFTP and SMTPS can take advantage of the protocol. Even lower-level protocols like TCP and UDP can use TLS.

Threat actors follow suit

Attackers go to great pains to get their threats onto systems and networks. The last thing they want after successfully penetrating an organization is to have their traffic picked up by network-monitoring tools. Many threats are now encrypting their traffic to prevent this from happening.

Where standard network monitoring tools might be able to quickly identify and block unencrypted traffic in the past, TLS provides a mask for the communication threats utilize to operate. In fact, according to data taken from Cognitive Intelligence, 63 percent of all threat incidents discovered by Stealthwatch were discovered in encrypted traffic.

In terms of malicious functionality, there are a number of ways that threats use encryption. From command-and-control (C2) communications, to backdoors, to exfiltrating data, attackers consistently use encryption to hide their malicious traffic.

Botnets

By definition, a botnet is a group of Internet-connected, compromised systems. Generally, the systems in a botnet are connected in a client-server or a peer-to-peer configuration. Either way, the malicious actors usually leverage a C2 system to facilitate the passing of instructions to the compromised systems.

Common botnets such as Sality, Necurs, and Gamarue/Andromeda have all leveraged encryption in their C2 communications to remain hidden. The malicious activity carried out by botnets include downloading additional malicious payloads, spread to other systems, perform distributed-denial-of-service (DDoS) attacks, send spam, and other malicious activities.

Botnets mask C2 traffic with encryption.

RATs

The core purpose of a RAT is to allow an attacker to monitor and control a system remotely. Once a RAT manages to implant itself into a system, it needs to phone home for further instructions. RATs require regular or semi-regular connections to the internet, and often use a C2 infrastructure to perform their malicious activities.

RATs often attempt take administrative control of a computer and/or steal information from it, ranging from passwords, to screenshots, to browser histories. It then sends the stolen data back to the attacker.

Most of today’s RATs use encryption in order to mask what is being sent back and forth. Some examples include Orcus RAT, RevengeRat, and some variants of Gh0st RAT.

RATs use encryption when controlling a computer.

Cryptomining

Cryptocurrency miners establish a TCP connection between the computer it’s running on and a server. In this connection, the computer is regularly receiving work from the server, processing it, then sending it back to the server. Maintaining these connections is critical for cryptomining. Without it the computer would not be able to verify its work.

Given the length of these connections, their importance, and the chance that they can be identified, malicious cryptomining operations often ensure these connections are encrypted.

It’s worth noting that encryption here can apply to any type of cryptomining, both deliberate and malicious in nature. As we covered in our previous Threat of the Month entry on malicious cryptomining, the real difference between these two types of mining is consent.

Miners transfer work back and forth to a server.

Banking trojans

In order for a banking trojan to operate, it has to monitor web traffic on a compromised computer. To do that, some banking trojans siphon web traffic through a malicious proxy or exfiltrate data to a C2 server.

To keep this traffic from being discovered, some banking trojans have taken to encrypting this traffic. For instance, the banking trojan IcedID uses SSL/TLS to send stolen data. Another banking trojan called Vawtrak masks its POST data traffic by using a special encoding scheme that makes it harder to decrypt and identify.

Banking trojans encrypt the data they’re exfiltrating.

Ransomware

The best-known use of encryption in ransomware is obviously when it takes personal files hostage by encrypting them. However, ransomware threats often use encryption in their network communication as well. In particular, some ransomware families encrypt the distribution of decryption keys.

How to spot malicious encrypted traffic

One way to catch malicious encrypted traffic is through a technique called traffic fingerprinting. To leverage this technique, monitor the encrypted packets traveling across your network and look for patterns that match known malicious activity. For instance, the connection to a well-known C2 server can have a distinct pattern, or fingerprint. The same applies to cryptomining traffic or well-known banking trojans.

However, this doesn’t catch all malicious encrypted traffic, since bad actors can simply insert random or dummy packets into their traffic to mask the expected fingerprint. To identify malicious traffic in these cases, other detection techniques are required to identify the traffic, such as machine learning algorithms that can identify more complicated malicious connections. Threats may still manage to evade some machine learning detection methods, so implementing a layered approach, covering a wide variety of techniques, is recommended.

In addition, consider the following:

◈ Stealthwatch includes Encrypted Traffic Analytics. This technology collects network traffic and uses machine learning and behavioral modeling to detect a wide range of malicious encrypted traffic, without any decryption.

◈ The DNS protection technologies included in Cisco Umbrella can prevent connections to malicious domains, stopping threats before they’re even able to establish an encrypted connection.

◈ An effective endpoint protection solution, such as AMP for Endpoints, can also go a long way towards stopping a threat before it starts.

Continue reading

Cisco Threat Response Plugin: Defeat Threats With Just a Few Clicks

One of the best tools in your SOC’s arsenal is something you might already have access to and didn’t even have to pay for. If you already deploy Cisco Umbrella, AMP for Endpoints, Firepower devices, next-generation intrusion prevention system (NGIPS), Email Security, or Threat Grid, then you can immediately access Cisco Threat Response for FREE. As in no charge. Zero extra dollars. No strings attached.

With Cisco Threat Response, customers receive a powerful solution that can streamline and simplify detection, investigation, and remediation of threats. In addition, Threat Response offers a very easy, powerful tool in the new browser plugin (for Chrome and Firefox). By adding the plugin, security professionals now have instant access to threat intelligence and response capabilities directly from their browser. To prove the simplicity of this, let’s use a straightforward example.

For the threat, we will use the Karkoff malware, used in the DNSpionage campaign.

Ah, it seems that Talos has a full spotlight of Karkoff. Towards the bottom of the blog, Talos gives a full report on Indicators of Compromise for Karkoff.

Traditionally, you’d have to manually copy and paste  each file, IP address, etc. from the blog, editing them to remove the defanging “safety brackets”, searching for each one in turn, in each of your telemetry sources – a laborious, manual activity. Cisco Threat Response simplifies this entire process by bringing all of these capabilities to one central source. So, let’s open the Cisco Threat Response browser plugin.

Immediately, Cisco Threat Response identifies 16 observables from this threat intelligence blog. 1 clean. 9 malicious. 6 unknown.

By clicking the malicious and unknown observables, we can tailor our investigation. We will not worry at all about snort.org, because we know Snorty is never up to anything bad!

As an example of how quickly we can take response actions, even before pivoting into Threat Response to do a more complete investigation, let’s look at kuternull.com. It is listed as “unknown.” By clicking the dropdown menu next to it, and pivoting out to other trusted intelligence sources like the Talos database or Threat Grid, we could quickly gather more information to determine a course of action.

For the purposes of simply showing the ease of the plugin, let’s assume we investigated this domain and there is no legitimate business need for our organization to be contacting it. In order to prevent potential malware activity, we will proactively block it now as a first level stopgap while we continue our investigation. Threat Response directly integrates with Umbrella, so we can immediately block the domain across our entire network with one click within the plugin.

Within a few seconds, Threat Response will flash a green banner confirming the blocking of the domain with Umbrella.

Now, after blocking a few domains quickly, our network is certainly better protected from Karkoff, but there is more investigation to be done. A quick click of the “Investigate” button will launch Cisco Threat Response’s cloud-based dashboard.

Cisco Threat Response will automatically load the list of the observables and provide insights with relation graphs, file hashes, and others.

Previously, Security Operations Centers (SOCs) would hear about trending threats and wonder, “Is my network affected by this threat?” To answer that question, it would require a series of manual processes that required investigating observables hundreds of times across the network, and then, writing sufficient policy to defend against these threats. To make life even more difficult, these solutions were often from different vendors and require manual processes to implement across different parts of the next work.

With Cisco Threat Response, within minutes, your SOC can:

1. Identify a trending threat from your SIEM, Talos, other threat intel sources, or virtually any third party product that has a web based interface

2. Identify a list of observables with one click

3. Quickly block domains across the network

4. Launch Cisco Threat Response for further investigation

It is important to note that Cisco Threat Response is a FREE add-on to existing Cisco Security solutions. In the example above, the user has Threat Response integrated with their AMP For Endpoints, Cisco Threat Grid, and Umbrella solutions. In addition, every user of Threat Response automatically gets access to the Talos Intelligence and AMP File Reputation databases for use in Threat Response. While Cisco Threat Response provides significant value when integrated with only one product, it becomes even more useful with each additional Cisco Security solution integration. It offers unparalleled central-management for detection, investigation, and remediation – and the browser plugins bring all those capabilities into any type of web content. Whether it is a blog entry like in this example, any other intelligence source, or the browser-based management console of any Cisco or third-party security or networking product.

Continue reading