by OBJECTIVES COVERED
Explain the importance of threat data and intelligence.
Given a scenario, utilize threat intelligence to support organizational security.
While classifying threat actor types provides basic insights into adversary motivations and capabilities, the diversity of threat actors in the modern security landscape requires more sophisticated tools to provide actionable threat intelligence. In this topic you will use different frameworks as a basis for identifying and analyzing indicators of compromise (IoC) that provide evidence of attack/intrusion events.
THREAT RESEARCH
Historically, security tools have depended on identification of malware signatures. This type of signature-based detection is unlikely to work against sophisticated adversary tactics because the tools used by the attacker are less likely to be identifiable from a database of known file-based malware. Consequently, threat research has moved beyond the identification of “static” malware signatures (though they still have their place) to identify and correlate indicators of compromise (IoCs). Multiple IoCs can be linked to identify a pattern adversary behavior, and this behavioral analysis can be used to model threats and perform proactive threat hunting.
Reputational Threat Research
One means of identifying a threat is to associate indicators that you discover in your logs with reputation data. A reputation threat research source identifies IP address ranges and DNS domains that are associated with malicious activity, such as sending spam or participating in DDoS attacks. One example is the Talos Reputation Center (talosintelligence.com/reputation_center). This tracks activity and rates each source with a granular reputation score metric, plus a basic indicator—good, neutral, or poor. There are similar systems for file reputation that work based on a file’s digital signature, computed using a cryptographic hash sum, such as SHA256.
Indicator of Compromise (IoC)
An indicator of compromise (IoC) is a residual sign that an asset or network has been successfully attacked or is continuing to be attacked. An IoC can be definite and objectively identifiable, like a malware signature, but many IoCs require subjective judgment calls based on the analyst’s experience and knowledge of organizational systems. Because these IoCs are often identified through anomalous activity rather than overt incidents, they can be open to interpretation. Therefore, it’s important, whenever possible, to correlate multiple IoCs to produce a more complete and accurate narrative of events.
As there are many different targets and vectors of an attack, so too are there many different potential IoCs. The following is a list of some of the most common or major IoCs that you may encounter:
- Unauthorized software and files
- Suspicious emails
- Suspicious Registry and file system changes
- Unknown port and protocol usage
- Excessive bandwidth usage
- Rogue hardware
- Service disruption and defacement
- Suspicious or unauthorized account usage
** As the name suggests, an IoC is evidence of an attack that was successful. The term Indicator of Attack (IoA) is sometimes also used for evidence of an intrusion attempt in progress. **
Behavioral Threat Research
Most threat sources cannot be identified from a single indicator. Behavioral threat research correlates IoCs into attack patterns. For example, analysis of previous hacks and intrusions produces definitions of the tactics, techniques, and procedures (TTP) used to perform attacks. Some typical TTP behaviors might be as follows:
- DDoS—A traffic surge might be an indicator of a distributed denial of service (DDoS) attack. Typically, the attacker will leverage a botnet. As well as elevated traffic levels, you are likely to notice unusual geographic distribution of source IP addresses.
- Viruses/worms—High CPU or memory usage could be a sign of malware infecting a host.
- Network reconnaissance—If not performed sparsely, scans against multiple ports or across numerous IP addresses will be highly visible and provide an early warning of adversary behavior.
- Advanced persistent threats (APTs)—The attacker needs to use some sort of command and control (C2 or C&C) mechanism to communicate with the controller host on the Internet and this traffic will be present on the network, if you know what to look for. Some adversary techniques for communicating with the C2 server include:
- Port hopping—The C2 application might use any port to communicate and may “hop” between different ports. A modern firewall will be able to detect the use of unknown TCP or UDP applications, passing over ports that must be left open such as 80/443 (HTTP), 25 (SMTP), or 53 (DNS).
- Fast flux DNS—This technique rapidly changes the IP address associated with a domain. It allows the adversary to defeat IP-based blacklists, but the communication patterns established by the changes might be detectable.
- Data exfiltration—Spikes in database reads and/or high-volume network transfers might be an indicator of a data exfiltration event, especially if the endpoints involved do not typically see high-traffic levels. Exfiltration might also use file types and compression or encryption algorithms not typical of regular network users.
** Recorded Future published an article discussing how to turn observation of IoCs into analysis of TTPs (go.recordedfuture.com/hubfs/white-papers/identifying-ttps.pdf). **
KILL CHAIN
There are several models for describing the general process of an attack on systems security. These steps are often referred to as a kill chain, following the influential white paper Intelligence-Driven Computer Network Defense commissioned by Lockheed Martin (lockheedmartin.com/content/dam/lockheed-martin/rms/documents/cyber/LM-White-Paper-Intel-Driven-Defense.pdf).
The Lockheed Martin kill chain identifies the following phases:
- Reconnaissance—In this stage the attacker determines what methods to use to complete the phases of the attack. One significant issue here is that the attacker will not want to draw attention to him- or herself so will try to identify stealthy methods to proceed. The attacker discovers what they can about how the target is organized and what security systems it has in place. This phase may use both passive information gathering and active scanning of the target network. The outcome of the phase, if successful, will be one or more potential exploits. The attacker also needs to establish resources to launch the attack. To evade detection, this will normally mean a botnet of compromised hosts, which can be used as unwitting zombies to facilitate scans, DDoS attacks, and exploits, and then mask their origin.
- Weaponization—The attacker couples payload code that will enable access with exploit code that will use a vulnerability to execute on the target system.
- Delivery—The attacker identifies a vector by which to transmit the weaponized code to the target environment, such as via an email attachment or on a USB drive.
- Exploitation—The weaponized code is executed on the target system by this mechanism. For example, a phishing email may trick the user into running the code, while a drive-by-download would execute on a vulnerable system without user intervention.
- Installation—This mechanism enables the weaponized code to run a remote access tool and achieve persistence on the target system.
- Command and control (C2 or C&C)—The weaponized code establishes an outbound channel to a remote server that can then be used to control the remote access tool and possibly download additional tools to progress the attack.
- Actions on objectives—In this phase, the attacker typically uses the access he has achieved to covertly collect information from target systems and transfer it to a remote system (data exfiltration). An attacker may have other goals or motives, however.
Kill chain analysis can be used to identify a defensive course-of-action matrix to counter the progress of an attack at each stage, using security controls that detect, deny, disrupt, degrade, deceive, or destroy the attacker’s capabilities. For example, when considering an attempt to compromise a web server, reconnaissance attempts could be detected by analyzing website traffic statistics, delivery could be denied by a web application firewall (WAF), and installation could be degraded by properly configured permissions on the website’s directories.
THE MITRE ATT&CK FRAMEWORK
As an early model, the Lockheed Martin model does not accurately reflect the chain of events in modern attack campaigns. It is often criticized for focusing too much on perimeter security, where much of the modern attack life cycle happens within the network, or within the cloud. Modified models, such as ones by AlienVault (alienvault.com/blogs/security-essentials/the-internal-cyber-kill-chain-model) and Sean Malone (blackhat.com/docs/us-16/materials/us-16-Malone-Using-An-Expanded-Cyber-Kill-Chain-Model-To-Increase-Attack-Resiliency.pdf), conflate some of the weaponization, delivery, exploitation, installation, and C2 phases, and introduce iterative internal reconnaissance, lateral movement, privilege escalation, and data collection phases within Actions on Objectives. You should also consider the possibility of a retreat phase. Once the attacker has achieved his or her initial aims without being detected, he or she may either maintain an APT or seek to withdraw from the network, removing any trace of his or her presence to frustrate any subsequent attempt to identify the source of the attack (anti-forensics).
As an alternative to the life-cycle analysis implied by a kill chain, the MITRE Corporation’s Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK) matrices provide access to a database of known tactics, techniques, and procedures (TTPs). This freely available resource (attack.mitre.org) tags each technique with a unique ID and places it in one or more tactic categories, such as initial access, persistence, lateral movement, or command and control. The sequence in which attackers may deploy any given tactic category is not made explicit. This means analysts must interpret each attack life cycle from local evidence. The framework makes TTPs used by different adversary groups directly comparable, without assuming how any particular adversary will run a campaign at a strategic level.
There is a matrix for enterprise, which can also be viewed as TTPs directed against Linux, macOS, and Windows hosts, and a second matrix for mobile. For example, Drive by Compromise is given the ID T1189 and categorized as an Initial Access tactic that can target Windows, Linux, and macOS hosts. Clicking through to the page accesses information about detection methods, mitigation methods, and examples of historic uses and analysis.
** There is an equivalent TTP for mobile with ID T1456. **
There is a third matrix for pre-ATT&CK tactics, such as target selection and information gathering, mapping roughly to the reconnaissance and weaponization phases of a traditional kill chain.
THE DIAMOND MODEL OF INTRUSION ANALYSIS
The Diamond Model of Intrusion Analysis is set out in a paper by Sergio Caltagirone, Andrew Pendergast, and Christopher Betz (activeresponse.org/wp-content/uploads/2013/07/diamond.pdf). There are also summaries of the model’s features and usage at activeresponse.org/wp-content/uploads/2013/07/diamonill chd_summary.pdf and digital-forensics.sans.org/summit-archives/cti_summit2014/The_Diamond_Model_for_Intrusion_Analysis_A_Primer_Andy_Pendergast.pdf. The Diamond Model suggests a framework to analyze an intrusion event (E) by exploring the relationships between four core features: adversary, capability, infrastructure, and victim. These four features are represented by the four vertices of a diamond shape. Each event may also be described by meta-features, such as date/time, kill chain phase, result, and so on. Each feature is also assigned a confidence level (C), indicating data accuracy or the reliability of a conclusion or assumption assigned to the value by analysis.
Each event is then defined by tuples, and additional information about each feature can be nested using the following format:
E = { {Adversary,Cadversary},
{Capability,Ccapability},
{Infrastructure,Cinfrastructure},
{Victim,Cvictim} = {
{IP,Cip},
{Port,Cport},
{Process,Cprocess}
},
{Timestamp,Ctimestamp},
{ ... }
}The power of the model lies in the ability to pivot along the vertices of the diamond to produce a complete analysis and correlation of the IoCs that represent the event.
Events can be linked into attack graphs and activity threads, graphed along each vertex, representing the paths an adversary could take (if analyzing an attack in progress) and those that were taken (if analyzing past activity).
Also, threads can be assigned to activity groups, which can be used to represent campaigns by particular adversaries.
While the Diamond Model is difficult to apply to manual “pen and paper” analysis, it has been used to develop automated threat intelligence analysis engines. For example, consider the Diamond Dashboard app developed to integrate ThreatConnect’s threat intelligence platform with the Splunk SIEM platform (threatconnect.com/blog/tag/diamond-model-of-intrusion-analysis).
STRUCTURED THREAT INFORMATION EXPRESSION (STIX)
Threat research can be delivered as narrative reports or as automated feeds designed to correlate local security information with cyber threat intelligence (CTI). The OASIS CTI framework (oasis-open.github.io/cti-documentation) is designed to provide a format for this type of automated feed so that organizations can share CTI. The Structured Threat Information eXpression (STIX) part of the framework describes standard terminology for IoCs and ways of indicating relationships between them. There are two versions of STIX. Version 2 is described here.
Data in STIX is expressed in JavaScript Object Notation (JSON). JSON consists of attribute:value pairs. JSON strings can be nested with one another. For example:
{
"type": "observed-data",
"id": "some-unique-string",
"created": "2019-10-01T10:03:16",
"number_observed": 5,
"objects": {
"0": {
"type": "domain-name",
"value": "some.malicious.actor.domain.net"
"resolves_to_refs": [
"1"] },
"1": {
"type: "ipv4-addr",
"value": "192.168.1.1"
},
... } }The STIX architecture is built from high-level STIX domain objects (SDO). The attributes of SDOs and the terminology and format for attribute values are defined in the STIX patterning language. Some of the SDOs are as follows:
- Observed Data—A stateful property of the computer system or network or an event occurring within it. Examples of observables include an IP address, a change in an executable file property or signature, an HTTP request, or a firewall blocking a connection attempt. Observables would be generated by the logging and monitoring system.
- Indicator—A pattern of observables that are “of interest,” or worthy of cybersecurity analysis. Ideally, software would automate the discovery of correlations between observables based on a knowledge of past incidents and TTPs.
- Attack Pattern—Known adversary behaviors, starting with the overall goal and asset target (tactic), and elaborated over specific techniques and procedures. This information is used to identify potential indicators and intrusion sets.
- Campaign and Threat Actors—The adversaries launching cyberattacks are referred to in this framework as Threat Actors. The actions of Threat Actors utilizing multiple TTPs against the same target or the same TTP against multiple targets may be characterized as a campaign.
- Course of Action (CoA)—Mitigating actions or use of security controls to reduce risk from attacks or to resolve an incident.
SDOs are connected by relationship objects. A relationship object can be one of several types, such as indicates, targets, or attributed to. There are also sighting objects, which are used for relationships that have been observed but that cannot confidently be correlated.
** Note that STIX v1.x uses a completely different format (XML-based) and different organizational principles for objects and relationships. **
TRUSTED AUTOMATED EXCHANGE OF INDICATOR INFORMATION (TAXII)
Where STIX provides the syntax for describing CTI, the Trusted Automated eXchange of Indicator Information (TAXII) protocol provides a means for transmitting CTI data between servers and clients over HTTPS and a REST API (REpresentational State Transfer Application Programming Interface). For example, a CTI service provider would maintain a repository of CTI data. Subscribers to the service obtain updates to the data to load into analysis tools over TAXII. This data can be requested by the client (referred to as a collection), or the data can be pushed to subscribers (referred to as a channel).
OPENIOC AND MISP
MITRE’s schema is not the only means of threat data sharing. The company Mandiant was instrumental in developing some of the language of threat classification and sponsored the OpenIOC (github.com/mandiant/OpenIOC_1.1) framework. OpenIOC uses XML-formatted documents. Each entry comprises metainformation such as author, category information, confidence level, and usage license, plus a description and a definition. The definition is built from logical statements defining detection rules, such as DNS host name or a string pattern for a filename.
Another example of threat data sharing is the Malware Information Sharing Project (MISP) (misp-project.org). MISP provides a server platform for CTI sharing as well as a file format. MISP servers can import and export STIX SDOs over TAXII. It also supports OpenIOC definitions. There is also IBM’s X-Force Exchange cloud platform (exchange.xforce.ibmcloud.com), which supports STIX and TAXII.
Front of Flashcard 1 of 4
What type of threat research is best suited to configuring effective firewall rules?
Back of Flashcard 1 of 4
A reputational threat feed can be used to block known bad IP address ranges and domains.
Front of Flashcard 2 of 4
What distinguishes an attack framework from an indicator management tool?
Back of Flashcard 2 of 4
An attack framework, such as the kill chain, MITRE ATT&CK, or the Diamond Model, is a way of relating the events observed in an attack to a pattern or sequence. An indicator management tool, such as Structured Threat Information Exchange (STIX) or OpenIOC, is a way of packaging threat data so that it can be consumed by automated detection and analysis tools and shared as cyber threat intelligence (CTI) by cooperating organizations.
Front of Flashcard 3 of 4
What elements of an event do the vertices in the Diamond Model represent?
Back of Flashcard 3 of 4
Adversary, capability, victim, and infrastructure.
Front of Flashcard 4 of 4
What role does TAXII play in indicator management?
Back of Flashcard 4 of 4
Where Structured Threat Information Exchange (STIX) provides the syntax for describing indicators and other attack elements, the Trusted Automated eXchange of Indicator Information defines a protocol for transmitting STIX data between CTI producers and consumers.