I have two stories to tell you. The first is about a software developer at a big financial corporation. The second is about the security team at the same company. We will go through the same cyber incident, from these two perspectives, to get a good understand of how a malicious actor might try to infiltrate a banking application through an admin user, and how the company can detect this malicious behavior – using automation as much as possible.
The wrong link
Let’s start by looking at how an attacker might try to infiltrate a banking application from the inside. What is the easiest way? Unfortunately, the answer is almost always through a user that has access to the infrastructure and code repositories: an administrator or a developer.
Usually, an attack consists of a couple of phases, popularly known as the “kill chain” model:
- Reconnaissance: An attacker selects a target, for example our bank, and specifically a developer who is working on a specific component of the banking application that is of interest. The attacker might find out that he is using Gmail as personal email (through a LinkedIn post). Also, he knows that GitHub is being used to commit code, and AWS EKS is used to deploy the code in production.
- Weaponization: The attacker designs a malware file, which will take over the laptop of the developer.
- Delivery: Everyone has a weakness. The attacker designs an email, with a specific attachment, which will trick the developer into opening the file.
- Exploitation: The malware executes upon the developer opening the attachment.
- Installation: The malware installs a backdoor, usable by the attacker.
- Command and Control: The malware enables attacker to have “hands on the keyboard” persistent access to target network.
- Actions on Objective: The attacker gets access to the backend of the banking application, since the developer has admin privileges.
Phase 7 is obviously the payoff. Before that calamity, there are several defenses that should be in place:
- Detect: Determine whether an attacker is present.
- Deny: Prevent information disclosure and unauthorized access.
- Disrupt: Stop or change outbound traffic (to attacker).
- Degrade: Counter-attack command and control.
- Deceive: Interfere with command and control.
- Contain: Network segmentation changes
Now looking at the above, you can probably imagine that we want to detect whether an attacker is present as soon as possible. If we don’t know the attacker is there, that is when we are most vulnerable. There are many prevention and detection solutions out there that you can use to protect your users and applications, however none will be 100% effective. This is in large part why the computer security industry exists. And this is why it is important to use good sources of threat intelligence and skilled threat hunters. Let’s dive a bit deeper.
What is threat intelligence?
Cyber threat intelligence is what cyber threat information becomes once it has been collected, evaluated in the context of its source and reliability, and analyzed through rigorous and structured tradecraft techniques by those with substantive expertise and access to all-source information. Basically, any information can become threat intelligence, and there are many ways to model this information as data structure. One of the more famous methods is STIX (Structured Threat Information Expression), which is a structured language for describing cyber threat information so it can be shared, stored, and analyzed in a consistent manner. Why is all of this important? We will cover that next!
What is threat hunting?
Threat hunting is the process of proactively and iteratively searching through environments to detect and isolate advanced threats that evaded existing security solutions. Threat Hunting is a continuous process, not a one-off task that you do every now and then. The process basically entails making a hypothesis over a potential cyber incident, investigating this, uncovering patterns, and finally enriching your investigation. The hypothesis can be either confirmed or denied, and the process starts over again with a new or similar hypothesis.
There are three different types of threat hunting: Intelligence-Driven, TTP-Driven (Tactics, Techniques and Procedures), and Anomaly-driven (in which you look for outlier behavior on networks and hosts). The first is based on atomic indicators (also called observables), like an IP address, domain name, file hash, etc. These are relatively simple to hunt for, since all you have to search is your logging and internal monitoring systems for a specific indicator. TTP- or anomaly-driven are more difficult, since you are hunting for a specific or outlying pattern of behavior. This is obviously more complex than just searching your logging for a specific indicator. Let’s focus on intelligence-driven threat hunts for now.
Since Threat Hunting is all about gathering data from local/internal monitoring systems and cross-referencing this with global threat intelligence, it is of upmost importance that you can combine different sets of information sources, whether you are on the lookout for an SHA256 file hash or a behavior pattern. There are many tools, like Cisco SecureX, that can help with this. For example, SecureX integrates with many Cisco and third-party security tools, and translates returned data into a coherent data model called Cisco Threat Intelligence Model (CTIM). CTIM is a simplified version of the earlier-mentioned STIX (there is also a CTIM-STIX converter available). This translation component is crucial in the rapid investigation of incidents, or when threat hunting. SecureX offers a built-in tool, Threat Response, to do this in a graphical way, but it also offers rich APIs which can automate parts of the threat hunting process.
Finding fresh indicators of compromise for your hypotheses
The internet contains many free sources of threat intelligence that can be used, in addition to Cisco’s threat intelligence research group, Talos. There is a big community out there that shares new indicators related to new cyber attacks and malware campaigns. There’s a lot out there, and it’s important to keep up to date with this intelligence. But how?
One way is to use the SecureX API (Inspect and Enrichment). It can “harvest” fresh indicators, and also discover internal security events from many sources – like Twitter. Over on Twitter, the #opendir Twitter hashtag is used by many threat intelligence researchers to post their findings on new threats. This is a perfect example of one of those free sources of threat intelligence that can be found on the internet.
Since no one has the time to read all of these Tweets, check all of their security tools for hits, and take action on them, I want to show you an automated way of doing this, using SecureX Orchestration. But first, let’s get back to our story of the developer at the banking corporation.
Suppose that our developer indeed fell for the email that was crafted by the attacker, and accidentally executed malware on his laptop. The file seemed to be harmless, and the developer did not see this as anything malicious and continues with his day. Meanwhile, the attacker is now inside, and is waiting for the right moment to jump over from the laptop into the application infrastructure of the banking application. When the developer connects to their AWS EKS cluster, this is where the infection happens. The attacker connects to his command and control server and starts to exfiltrate data, or other malicious activities. Now since his command and control server is not known yet as being a malicious destination, no security controls are blocking this connection. Luckily a security researcher just found out about this through an investigation and tweets about it. This is where our automations kick in!
Automating your threat hunts
Using the Twitter Search API we can actually retrieve the latest tweets that use the #opendir hashtag. Using this, in combination with the SecureX API to extract and enrich observables, we can find out if we have sightings of this in our environments. Below is an overview of this automation workflow in a flow diagram:
As you can see, we are now completely automating our threat hunting, by automatically ingesting interesting tweets, parsing them and checking our environment. Based on this, the security team of the financial corporation gets an alert that one of their services made a connection to an observable which is mentioned in a tweet. What to do next to nip this in the bud, though? That we will find out in Part 2 of this story, coming soon!
We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!
LinkedIn | Twitter @CiscoDevNet | Facebook | Developer Video Channel
CONNECT WITH US