Cyber Threat Intelligence

Table of Contents

3 Minutes summary

Are you an executive or just looking for a 3 minutes summary? Check out this video from the good folks at MITRE corporation.

This pretty much sums up all the major points you can absorb within such a short timespan.

Introduction

As a specie, the way we as humans deal with risks is simple and quite hard-wired within our instinct and psychology: we identify them and we avoid them. This practice is extremely effective in nature where threatening conditions rarely change: poking a sleeping bear, diving with open wounds next to sharks, pick and open an hive or eat something that doesn’t smell right are few examples of probably bad ideas which are quite unlikely to change in the result should we decide to go for them. In time, evolution eventually took care of increasing the ratio of those capable of identifying risks through natural selection. On the other hand, whatever in nature works quite well is likely to work again, at least within the time frame in which the environment and external conditions do not change (e.g., edible berries today will still be edible tomorrow).

In cyber security as an industry, we historically replicated the same behaviour we tend to expose in nature: anti-viruses, firewalls and blacklisting are basically examples of automations for identifying and blocking dangerous conditions from happening. In other words, traditional security controls and most of the technology leveraged in cyber security consist in technical means to apply static knowledge in some form (e.g., configuration) to react to events and possibly automate performing actions in support of the controls’ objectives. While this approach is completely fine and the solutions adopting it are fundamental blocks of any mature security infrastructure, a problem arise in comparison with the success of such approach in nature. In the cyber space in facts, things change much faster leading to the need for a much closer learning loop to be able to identify what can lead to harm; on top of this, the complex of systems each organisation uses everyday makes the number of events claiming attention to identify potential breaches dramatically higher than how much the average defense staff can handle. This can be otherwise outlined into the following two issues, that makes the above mentioned approach developed in nature obsolete in cyber space:

  • The environment is constantly changing and a reactive approach, eventually leading to the update of security controls, can hardly keep up with its changing speed. Let alone when the changes into the environment should be addressed with something more than updating the security controls with new data to crunch.
  • The number of potentially interesting events to investigate for CND staff (Computer Network Defense) is overwhelming, leading inevitably to a best effort approach and prioritisation based on unclear criteria, non necessary reflecting the actual current environment which might not necessarily be known at any time.

Traditionally, these issues have been dealt with attempting to optimise the incident response function. However, conventional incident response alone might not just always be effective against all types of adversaries because it operates under the assumptions that response after the point in time of compromise is effective and that the compromise is a result of a fixable flaw. Needless to say, these assumptions do not always hold. This is where Cyber Threat Intelligence (CTI) comes in. Different definitions of CTI have been considered over the years and by different organisations or researchers. For the purpose of this research we will use the following, which apparently most of the existing literature and practitioners agree on:

Definition

Cyber Threat Intelligence (CTI)Actionable results of the analysis of information related to cyber adversaries that constitute a threat.

Cyber Threat Intelligence (CTI) is an emerging area in cyber security, which is receiving more and more attention as the space for implementation of protective controls saturates. The purpose of CTI is to provide actionable information to drive and support a wide range of activities, from cyber security operations to high level decision making, as well as to feed and enhance the effectiveness of security controls. CTI addresses the two issues mentioned as follows:

  • Provides actionable information that can be used to continuously update the knowledge according to which security controls operate, thus making them more effective based on the quality, relevance and timing in which such information is delivered. When such information is not just technical data to feed security controls, can timely call for wider scale decisions and provide data to support them.
  • Correlate technical information with context and cross-references to drive prioritisation and decision making at different levels, from operators during, e.g., threat hunting or incident response, to executives, e.g., in deciding how much and where to invest in countermeasures.

Definitions and classification

Common Intelligence terminology

The term Intelligence comes from the subject treated by civilian or military agencies that collect and analyse information to develop behavioural forecast or suggested courses to action for their leadership. Many references are available about how a typical cycle or process looks like for those entities, e.g., see Intelligence Cycle or Intelligence Cycle Management. A first classification of interest, from which terminology is reused in the context of CTI, is the one related to the source of the information treated as intelligence. The main categories are as follows:

  • Human Intelligence (HUMINT) - Intelligence gathered through personal contacts, or in other words from human sources (most often called, when collaborative, “assets” in intelligence wording). In general intelligence jargon HUMINT includes also information from untrusted or semi-trusted sources and is therefore historically one of the most subject to counterintelligence. HUMINT can be first-handed or come from Covert Human Intelligence Sources (CHIS), i.e., assets capable of handling other knowingly or unknowingly sources under cover.
  • Signals Intelligence (SIGINT) - Intelligence gathered through interception of communication signals. Measurement and Signature Intelligence (MASINT) - Intelligence gathered through measurement or identification of signatures. The bottom line is that the source of MASINT is the environment itself (or its perception).
  • Open Source Intelligence (OSINT) - Intelligence gathered from open (public) sources. The term comes from the intelligence jargon Overt (=public) as opposed to Covert (borrowed from old french language “to cover”, i.e., kept secret and not accessible). Note that in the CTI context, OSINT also refers to intelligence elaborated through analysis of publicly available data or measurement of relevant infrastructure elements (e.g., BGP advertisement records, data made available by search engines, DNS system monitoring data, Tor network monitoring data, etc).
  • Technical Intelligence (TECHINT) - Intelligence related to technology at disposal of the adversary. The term comes from military environments where it is precisely related to the weapons the enemy has access to. As a partial derivation, in CTI the term “Technical CTI” is referred mostly to IOCs (Indicator of Compromise), which are most often structured information usable to identify known adversarial capabilities (e.g., hashes of malware binaries, domain names, IP addresses, etc.)
  • Imagery Intelligence (IMINT) - Intelligence collected through equipment of visual acquisition such as cameras. In conventional intelligence jargon it mostly refers to pictures taken from recognition drones, planes and satellites.
  • Financial Intelligence (FININT) - Intelligence elaborated over information about the financial affairs of entities of interest.

When it comes to CTI, the most relevant of the above mentioned categories of sources are HUMINT, OSINT and TECHINT. This is because SIGINT, IMINT and FININT have deep intersections with privacy regulations (over to espionage in a business context) and are therefore restricted to the domain of compliance inspections or surveillance programs by government-sponsored agencies in related countries (i.e., gathering SIGINT and IMINT is most commonly illegal for civilian agencies. FININT is a potential source of legal intelligence if the data it is based on is publicly available or otherwise obtained through legitimate means). MASINT on the other hand does not belong to the cyber realm. It is interesting also how general intelligence programs have themselves standardised topics for their own security such as OPSEC, COMSEC, INFOSEC, and Counter Intelligence (CI). This is however out of scope for this research.

Cyber Threat Intelligence naming breakdown

image_1.jpeg

Cyber Threat Intelligence sounds like a fancy combination of words but it’s worth understanding each detail of its name to establish the potential of related development. Let’s start by breaking down the wording: Cyber - Related to the cyber-realm or cyber space, i.e., to actors and events in the environment expressed by the operation of ICT systems. For the sake of completeness, the Cyber Space is defined as an interactive domain made up of digital networks used to store, modify and communicate information, including the Internet and other information systems in support of businesses and services. In military terms, the cyber space is an overlay structure to the well known spaces that exist naturally (land, maritime, air, space and electromagnetic spectrum (EMS)), which is entirely man-made. Threat - Related to adversaries that have intent, opportunity and capability to cause harm. The definition is further expanded below. Intelligence - Generally speaking, the shortest summary to define Intelligence in this context is “relevant information”. The term comes from the subject treated by civilian or military agencies briefly mentioned in the previous section. The concept of threat in this context is worth additional elaboration. Given the definition, note that to be classified as a threat all three of its components (intent, opportunity and capability) need to co-exist in time. Deductively, a threat can be thwarted by nullifying even just one of its components. However, while such result would cause the threat to cease to exist in that moment, it doesn’t mean that the adversary will desist in time. While for most organisations eliminating the immediate threat by tactically preventing it from causing harm is probably the only one concern, some might actually go a step further and tackle the more complex problem of how to defeat adversary on a larger time scale. The high-level perspective presented so far can be further broken down to get a better understanding of the meaning of each component and, for now by intuition, of the data involved. It is also worth noting that in the industry each sub-component is addressed in a slightly different way, which understanding is essential to grasp the full extent of inner workings for a successful leverage of CTI. Intent - The intent is the motive of the adversary. To understand which threat actors should be considered, guided by a set of possible intents, the following questions are typically addressed. image_2.jpeg Who has to gain from a cyber security breach? Which value will it gain? Alternatively, how much harm will it cause? (i.e., value by hurting competition) Which will be the immediate goal he will go after? Opportunity - The opportunity is a concept that can span from vulnerabilities affecting exposed systems to some privileged (not necessarily expected) position of the adversary. The concept does not have strict formality and many best practices in cyber security have the sole purpose to reduce potential opportunities for the adversaries in order to reduce the number of potential threats. Typical questions asked to evaluate existing opportunities for adversaries: Who has knowledge of our assets? Who has access to our assets? Which is the attack surface of our assets? Which are the vulnerabilities of our assets? How often is the status of our assets being assessed? How long is the average remediation cycle? Capability - Capabilities represent the means at disposal of the adversaries. The concept include some wide range from physical or economical resources to possession or access to skills and expertise. The purpose of considering capabilities within the threat definition is to exclude for instance conditions of theoretical threat but practically non threatening due for instance to the lack of required capabilities for the threat actors having the intent and the opportunity identified (e.g., an internal disgruntled employee might have intent and opportunity to cause harm to her organisation, but does she have the capability to do that in terms of skill or resources? Does she have access to someone that can guide her through or support her adversarial behavior?) Who has the resources to exploit the identify opportunity? Who has the proper skillset to perform a relevant attack? Who might be acting on behalf of those having the actual capabilities?

Other kinds of security intelligence

It is worth noting that in Cyber Security there are different kinds of other information by some referred as Security Intelligence that have their place in most mature organisations, and while almost none of them belong to the CTI category according to its definition, most of them closely relate to the components that make a threat exist, most often specifically when it comes to the opportunity. For instance: Vendors’ advisories / bulletins - These are streams of information published by structured software vendors and service providers such as Microsoft, Google (Android, Kubernetes), AWS, IBM, Juniper, Mozilla, etc. through which they timely inform the public about latest patches for known vulnerabilities. Usually those are published on the web but also have other delivery formats accessible by their clients somewhat in advance. This is because once a patch is published publicly, it’s possible (likely) to be reverse engineered to uncover the vulnerability it was supposed to fix, and given that the patch management cycle might take some time for their clients the vendors sometimes disclose the information in advance (at least about the vulnerability if a patch is not yet available, to enable their clients to plan containment countermeasures). Open Source organisations advisories / bulletins - These are the equivalent of the previous point in the open source world, curated by the organisations that fund and maintains large open source projects, such as Debian or Ubuntu. Public advisories / bulletins - These are usually summary of vulnerabilities that became known (regardless of related patches being provided from software vendors) publicly provided in an effort to foster good security practices by public entities of some countries, such as the U.S. CERT (government) or CMU CERT (academic). Publicly available data leaks - These are not intended to be used as security intelligence, but certainly find their place in organisations highly mature from a security perspective. Most notable example is the usage of leaked credentials lists / databases (example) to cross check with an organisation’s users credentials to invalidate reused ones that are by that time publicly known and possibly correlated with their users. A practical way to do this is for instance using the HIBP service which collects and aggregates leaked credentials and allows to check if they have been compromised. Note that given the widespread of BYOD policies, this is sometimes also advised for employee personal credentials. Security Vulnerabilities disclosure channels - Security researchers adopt different models to disclose uncovered security vulnerabilities. Since not all of them follow responsible disclosure, vulnerabilities can as well become public before patches are available or even related vendors have any idea about them. Therefore monitoring the channels where these get disclosed can generate early warning to timely implement containment measures. Examples of such channels are typically mailing lists such as the popular Full Disclosure ([FD]), or exploits repositories such as ExploitDB. Outcomes of testing and assessments - These information are typically already relevant given that they are generated as product of targeted activities and highlight open vulnerabilities and usually their qualitative severity, providing a practical picture of technical opportunities for adversaries relevant to the involved assets. If vulnerabilities are known, the most common format to track and communicate them is by using CVE or CWE codes. Note that while the above-mentioned information does not qualify as CTI, they represent a great way to have a complete picture of the opportunities available to the adversaries, which might turn into threats given adversary having also intent and capability to exploit them. Also notably, given the volume of the information flowing through the mentioned channels, it is essential for most of them to become Intelligence to be filtered and correlated with other information highlighting what is relevant and what is not, e.g., by selecting those information related to actual practices or assets of the organisation (e.g., used software versions) by correlation with a CMDB and/or a threat and vulnerability management system for prioritisation and to refine severity assignments.

Different types of Cyber Threat Intelligence

The overall purpose of CTI is to provide information and context for decision support at different levels. Depending on the level where such decisions take place, here is a first most common theoretical classification based on the level of the objective from a CTI consumer perspective and with examples of what one can expect on each level. Technical CTI - Examples: IP addresses, domains, hash values. All of these are commonly referred as Indicators of Compromise (IOC). This CTI is used to feed security controls to keep up with the ever-changing and evolving landscape. Examples include updating firewall/UTM rules and or filters/gateway and/or anti virus (AV) signatures, YARA rules but also creating new correlation rules and alerts on SIEM platforms to enhance detection (more on this in the following section “Generation and Consumption”). Sometimes this is also incorrectly referred as “Raw Intelligence”, which instead correctly refers to raw data collected during an intelligence operation. The reason for this common mistake is that people tend to think that technical intelligence is produced automatically by advanced detection systems without the need for analysis, which theoretically should not be the case otherwise such technical intelligence will have very low precision (as in significant probability of false positives). Tactical CTI - Examples: Exploits, tools, procedures (sometimes aggregated as TTPs). This CTI is used mainly on two fronts. The first is threat hunting activities and to fine-tune next generation security controls that include automation for similar activities at scale. On the other hand, this CTI is also supposed so be leveraged by incident handlers to correctly identify threats associated with incidents, and as a consequence properly scope potential impact, potentials threat actors and what they are after, and therefore which are the best tactics to perform containment and response operations. To some extent, this kind of CTI is also considered by some as IOC, given that to be recognised they must be detailed at the same level besides the indicators aggregation. For this reason, many consider both Technical CTI and Tactical CTI as simply one category most ofter referred as Tactical CTI. Operational CTI - Examples: HUMINT-based warnings on tips on threat actors, campaigns or incoming attacks or operations This CTI is used mostly for short term prediction and early warning. It’s also one of the least senseless input for attribution (see related Attribution section below). This CTI overlap in purpose with the second usage mentioned for for tactical CTI, as constitute one of the best shot at cross checking IOCs against known threat actors and what they are after. Again this information constitute input for containment and response procedures. Strategic CTI - Examples: long term threat vectors, geopolitical-driven attacks in similar industries, nation state actors analysis, collateral damage estimation. This CTI is mostly used for security architectural planning, countermeasures deployment and overall as an input for decision support at the highest level in an organisation. Note that this also include input to business decisions such as selection (or exclusion) of suppliers or planning for logistics and organisation along the supply chain. E.g., an organisation will have to decide which vendors are qualifies to be evaluate in its supply chain, which security controls to be set in place, which security vendors to consider based on the kind of experience and resources they have, and which kind of contracts to put in place with their security vendors and so on. Sadly, those choices are mostly addressed from a short term or immediate impact on costs, reputation and relationship perspective, when CTI if considered might just suggest otherwise. Regardless of the classification, the most commonly perceived way CTI is distributed (either as OSINT or as commercial offering) is through the so called Threat Intelligence Feeds. A threat intelligence feed is usually an online service that distributes mostly technical and tactical intelligence, which can be automatically or machine-assisted imported into security controls. More on this in the CTI sharing section. Operational and strategic CTI on the other hand is mostly distributed in human-consumable formats (e.g., as documents or presentations). This is mostly carried out either through mailing lists or through dedicated professional services CTI generators or consulting company offer to end users (usually the latter have wide-breadth contracts with the first and provide a service to the end users by filtering and enhancing through addition of further contextualisation and specific suggestions, severity and impact analysis for their clients).

Generation and Consumption

There are two practical streams of activities related to CTI in security operations: generation and consumption. It is generally agreed that the two should be kept separated because they generally have different goals and require different teams with specific skills to be carried out. For most organisations, CTI is exclusively consumed. This is expected for a variety of reasons including that most organisations do not have either enough visibility or capabilities in terms of personnel, skills and contacts to take on the generation process, as well it is not part of their business and they’d rather rely on security vendors to feed them the relevant information to feed their security controls. In this section, the two different perspective of CTI generation and consumption are further elaborated.

CTI Generation

image_3.png Christian Doerr, Principal Investigator of the CTI Lab TU Delft, explains Cyber Threat Intelligence as a path from uncertainty to knowledge of facts and their correct interpretation for one’s purpose. The picture on the right shows at a glance the path that CTI enable across the dimensions of available data and possible understanding of their meaning. From a high level perspective this path, and therefore the CTI generation process, can be broken down into the following steps. Note that these are aligned also with the generic Intelligence Lifecycle employed by military and civilian intelligence agencies, and extends the simple and intuitive 1. Collect information ➡️ 2. Add knowledge*➡️ 3. Produce intelligence *possibly in a reproducible form, e.g., through a structured assisted or automated approach 1. Definition of the goal This is mostly referred as Determine the intelligence requirements and boils down to what the organisation wants to ultimately achieve through the consumption of the CTI to be generated. Examples of possible goals are (i) relevant IOC and adversaries’TTPs to enhance IR and DF; (ii) realistic understanding of the threat landscape to guide executive decisions, e.g., about contractors or solutions to be adopted; (iii) operational knowledge of threat actors campaigns for timely containment or early warning. Each of these examples can be considered organisation-wise or in relevance for specific targets (as in data or systems). Determine intelligence requirements is crucial to implement an effective generation process since the goal influence all of the subsequent phases, from data collection (which data are relevant? which sources should we consider?) to analysis (which model is relevant? what correlations we want to look for and what do we expect them to mean?) to dissemination (what will be the final result of the analysis? how will we use it?). This is the equivalent of the Direction step of the Intelligence Lifecycle. image_4.png

  1. Data Collection Based on the identified requirements, data collection should be performed according to a defined data collection strategy. Two sort of opposite approaches are typically employed depending on the requirements: breadth vs depth, as in from a variety of sources and formats but with shallow level of detail vs from a narrow set of sources which can however provide an higher degree of detail and higher confidence in terms of relevance. Data collection strategy is also expected to define monitoring frequency (e.g., periodic log collection vs event driven alerts, or a combination of both depending on the identified requirements) and data retention (time after collection during which data is kept stored and correlated during the enriching and analysis process. After such time, collected data is typically deleted and only the results of the analysis is retained). Depending on the collection strategy, data can be collected from a variety of sources, including system alerts from endpoint protection solutions (e.g., AV), logs from structured deployments components (e.g., Domain Controllers of Windows domains), host based logs of endpoints and other devices, networking components (e.g., logs from DHCP, DNS, captive portals), network monitoring solutions (e.g., logs from security related equipment such as firewalls, IDS/IPS, WAF, UTM, honeypots; logs of network monitoring solutions such as NetFlow). Note that in mature security architecture most of these data are already collected and correlated by SIEM systems for security monitoring purposes. Data collected from IT systems however is not the limitation of the scope for a proper data collection strategy. Additional data sources typically include HUMINT, which is further detailed in the Analysis phase where it is most often accounted, monitoring of external sources including the so called dark web (i.e., content available on hidden services part of the Tor network) and data from third parties (see CTI Sharing and CTI Consumption). While most of the collected data comes from operational systems and is therefore likely to be related to legitimate activities and include potentially many false positives for common detection rules, of particular interest is the data collected from deception technologies like honeypots, which should provide near-zero level of false positives. Different studies are available in literature about data collection for CTI purposes from honeypots, including those by Urias et.al., or the Nomadic concept from Liebergeld et.al. for honeypot mobile devices.
  2. Processing Data collection output will result in most cases in a wide collection of huge sets of data, which cannot be analysed timely by analysts in such raw form. This step of the process is therefore dedicated to parsing, filtering, deduplication, collation, aggregation and correlation with the goal to reach an analysable state for the collected data. This step also features the enrichment of the collected data with additional content for those data which are relevant for the defined requirements. In the general intelligence lifecycle this is the stage where HUMINT is subject to translation and prioritisation, which for the sake of cohesion is detailed in the analysis stage.
  3. Analysis and Validation (a.k.a. Production) The analysis and validation stage is the stage in which data is observed and actionable information are produced by deduction and analytics techniques. A most simple instance can be thought as the analysis of an observable and its transformation into an IOC after confirmation that, e.g., a domain is part of the C2 infrastructure of a known malware family. The analysis process may vary on many degrees of complexity and can include extraction of patterns, trends, clusters or sequencing of events. Relevant events (e.g., associated with known security incidents handled by the defense staff) can be represented according to different cognitive models that enable correlation with other events, or mapping to specific phases of known attack patterns (e.g., cyber kill chain phases). The analysis can leverage different techniques, depending on what it is supposed to abstract from the data, e.g.: image_5.jpeg Extraction of known knowns - Mostly performed by analysis via definition of rules to recognise data relevant to known threats Extraction of known unknowns (as input for known knowns) - Machine assisted techniques including hard matching, fuzzy matching, geo-matching or social media analysis (i.e., correlation through graph-like relationships with known entities) or Extraction of unknown unknowns (as input for known knowns) - Machine based analysis, through either supervised or unsupervised learning algorithms. Most of the techniques used require a mix of machine and human analysis: human analysts make hypothesis on adversary behavioural models that are specified by data-matching rules; collected data is matched against such rules to identify observables that can be compared with different forms of prior knowledge to validate the initial hypothesis made by the analysts. Another factor in play is timing: defined rules take into account causal dependencies between events and compare them in a temporal view to point to sequences of events that can be abstracted as patterns and used to recognise similar behavior in other sets of events. The diamond model for instance, support this kind of analysis (see related section) and can be employed in different modes, e.g., with a victim-centric approach (most likely when collected data are highly likely to already represent malicious activity, such is the case when it is collected through honeypots) or capability-centric (e.g., when data is collected via detection solutions based on pattern recognition and signatures). Generally speaking, many techniques make use of graph-based representations, which are considered by most easier to use for analysis purpose in comparison with plain lists of processed data. Another example besides the diamond model is the tool Maltego from Paterva, which has been used for forensic analysis long before CTI became popular in security operations; the tool employed a graph-like structure in which vertexes represents entities (the equivalent of observables in CTI jargon) and edges represent relationships between them, with many possibilities to expand the graph through transformations, i.e., services that correlates entities to other ones and expand the graph by inserting those and the related relationships to current entities. To give an idea, transformations available in Maltego are provided by significant CTI players such as Recorded Future, CrowdStrike, ThreatConnect, Kaspersky, Cisco ThreatGrid, VirusTotal, ShadowDragon and FireEye. The number of techniques and tools used by CTI analysts is too wide for them to be listed here; the reader is referred to the following two resources for many example of these: IntelTechniques and the OSINT Framework. Note that beside the techniques and tools leveraged, the analysis phase can be carried on from different angles depending on the intelligence requirements: from strictly technical analysis (e.g., extraction of IOC by tracing system calls such as file system operations, memory access, processes management patterns, etc. from forensic artefacts or by reverse engineer malware samples), to more high level activities (e.g., to uncover and confirm operational CTI by monitoring publishing on the dark web in public and private channels, or participate under false identities to discussion groups where potential adversaries with significant capabilities may decide to initiate offensive operations, basically the cyber version of HUMINT). The latter requires skills in humanities other than computer science, which brings the needs for CTI analysts with somewhat unusual background such as languages and knowledge of the culture of countries and communities to which adversaries might belong. A very good example of this is described by Mitchell Edwards from CrowdStrike in his talk at SANS CTI Summit 2019, where he describes the challenges of accessing sources in highly decentralised groups in China meeting and discussing on QQ or WeChat, which presents a variety of difficulties including the need to bypass the country-enforced censorship which not only attempts to keep the locals from accessing online resources from outside the country but the opposite as well. If such obstacles are overcome, the output of this kind on intelligence gathering and analysis is usually different from the technical intelligence of IOCs, but rather consists in timely knowledge of threat actors’ initiatives in space and time as well as their operational and strategic objectives. This is usually referred as a campaign or operation. Operational CTI on campaigns can also be produced as the aftermath of analysis on a technical level, correlating technical CTI with other IOCs and findings. If campaigns are known from HUMINT or external sources, they can be tied to technical CTI / IOC in the analysis phase (e.g., through correlation with TTPs or capabilities used by the same threat actors in the past). On the other hand, campaigns also might involve either different threat actor operators or different intrusion attempts with the same end goal, thus going after a range of targets with potentially different TTPs but still sharing some common elements; they can then theoretically also be identified by recurrence of IOCs across different intrusions attempts with different behavioural patterns, e.g., different actions detected along the cyber kill chain. But a similar situation can presents also in case of different threat actors using the same capabilities (e.g., exploit kit, malware family or C2 traffic encryption key). How to differentiate these situations and validate the hypothesis made is part of the goal of the analysis stage. To complicate this step further, the outcome of the analysis also needs to take into account the biases of those making the hypothesis as another form of validation, i.e., use the model of choice to check if the conjectures made still hold if assumptions that could be based on analysts’ biases (e.g., depending on their environment, country, culture, etc.) are neglected. This is often a controversial point given that most global-scale producers of CTI are U.S. based.
  4. Share (a.k.a. Dissemination) - The share and dissemination stage also depends on the identified requirements: based on the given goal, the validated intelligence is put into the proper format and communicated through the proper channels. Different criteria apply depending on the type of intelligence produced, but generally speaking they revolve around three factors: context, presentation and timing. Presentation in particular must be concise and understandable for the recipient (being human or machine depending on the type of intelligence gathered). Timing must enable the produced intelligence to be actionable (i.e., intelligence related to events already occurred in the past that are not going to repeat ever again is hardly useful). If we consider the types of intelligence produced (strategic, operational, tactical, technical), the presentation can take form of reports, alerts or machine-to-machine integration such as data feeds or API calls. For the latter, relevant formats and standards are described in the section CTI Sharing -> Standards, taxonomies, formats and exchange protocols. Given that the distribution channels can involve different parts of the organisation as well as third parties (e.g., CTI sharing communities), another relevant aspect at this stage is the classification for the produced intelligence (as in data classification, i.e., a label based on which permissions are granted to different entities to access the data based on an assigned level). Modern representation formats for CTI such as STIX are already designed to accommodate the need for such definition (i.e., in STIX, the MDO can hold data marking defining the sharing requirements and constraints). The other side of machine-to-machine sharing, such as the integration of IOCs into the detection rules of the SIEM or the production and check through YARA rules, will depend on the security controls leveraging the produced intelligence and is not detailed here.
  5. Feedback - In the classic intelligence cycle, the feedback step closes the loop in that some authoritative entity takes decision based on the disseminated intelligence and defines a course of action, which in turn may imply modifications to the intelligence requirements for the next iteration. In CTI, this step is strongly dependant on the type of intelligence produced as well on the overall organisational model including the consumers of the produced intelligence. The concept of a feedback loop still holds, e.g., in case of technical intelligence, in that based on the produced intelligence both detection solutions and incident response or threat hunting functions will uncover or match intrusions attempts and provide feedback to refine the intelligence requirements. As well, strategic and operational intelligence will influence executives and decision makers in terms of possible changes to the security architecture of their responsibility, which might include different intelligence requirements.

The Diamond Model

The diamond model is a cognitive model used by many analysts working in CTI and DFIR (Digital Forensics and Incident Response). Practical usage of the model include structured collection and analysis of data for intelligence generation purpose as well as post-validation of the intrusion analysis results. In between, data collected in the structured way provided by the model can be used to characterise threats, track them and their evolution during analysis, sort one from another and figure out how to counter them. This specific model is relevant because it represents the foundational concepts for the most common cyber ontologies and de-facto standardised protocols STIX, as well as provides a basis for the usage of analysis techniques proper of graph-theory or game theory employed by popular CTI providers. The model outlines a diamond-shaped data structure for every event collected during intrusion analysis, i.e., it models atomic elements for reasoning purposes. Ideally, humans analysts or machines populates single elements (events), which are then correlated in a graph to document and intrusion. In the diamond model, each element is composed by four features visually placed on its vertexes. Features are connected via relationships (edges) forming the diamond-shaped structure. Each feature can be labeled itself by the analyst (the model does not prescribe a specific ontology) and/or be specified by their characteristics, which are more similar to structured information (IOC/indicators common of technical CTI). Each feature is coupled with a confidence value (Cv) that represent the belief for the information to be true rather than a guess. Such value is not necessarily a single value but can be represented as a tuple if confidence values are relevant and might differ within different feature’s specifications.. The four features are Adversary - Personas, possibly identified by, e.g., email address, phone number, handle, network equipment, profiles. A common further specification is to label the Adversary with multiple sub-entities part of the feature, i.e., the Adversary operator (i.e., the actual human being that performs the action that generates the described event) and the Adversary customer (the one who benefits from the result of the event) Infrastructure - The immediate impacted entity in the event, typically either a physical or a logical delivery channel or mean to maintain control capabilities or effect results. Examples include (hosts identified by) ip addresses, domains, mail accounts, but also morse code through led, usb sticks, etc. There are two distinguished types of infrastructure, defined as follows. It is worth noting that in this context, many service providers can be seen, from an intrusion analysis perspective, as organisations that wittingly or unwittingly provide services critical for the availability of type 1 or type 2 infrastructure leveraged by adversaries. Type 1: fully controlled or owned by adversary or to which they are physically close Type 2: controlled by witting or unwitting intermediary. This includes including zombies, malware staging servers, hop-through-points, compromised email accounts etc. Capability - A mean to an end, e.g., a malware, exploit, tool, digital assets such as digital certificates, operational systems such as C2. It is also defined Capacity all that an adversary can address (regardless of victim) with a given capability. The overall set of capabilities an adversary has at its disposal is defined as Arsenal. Victim - The target of the adversary in the event. Can be a persona, as in organisation or actual human being, or an asset, as networks, hosts, email address, accounts, storage drives, etc. Note that a victim can be the target in one event and the infrastructure in the other (e.g., a host can be victim of an event and without the need for much imagination become the infrastructure in another). Vulnerabilities in this context can be sub-items or further specifications of the victim feature; their set is defined as Susceptibilities. Theoretically, the abstract implementation of an element represents an event such as: Single Event (abstract version) “an adversary (CvA) deploys a capability (CvC) over some infrastructure (CvI) against a victim (CvV)”. Each elements has then a set of meta-features that specify details of the event. Meta-features are essential to order events in activity threats during intrusion analysis. Timestamp - time record of the event. Each event is either instantaneous or time-bounded. Phase - a single intrusion is composed at least by two events with different phases of identification and action-on-objective. The phases label depend on the ontology used, e.g., consider the phases of the cyber kill chain. Result - the post-condition of the event. Depending on the ontology used can be success|failure|unknown or C|I|A compromised or documented in more extensive way (information gathered, access gained, time maintaining access, credentials exfiltrated, etc.). Direction - the literal direction of the detected interaction that generated the event, such as Victim2Infra, Infra2Victim, Adversary2Infra, Infra2Adversary, bidirectional. Can easily be unknown in absence of direct telemetry evidences. Methodology - common name of the technique of which the event is partial or complete evidence, e.g., spear phishing, content delivery attack, syn flood, portscan, Several taxonomies exist, the model does not create a new one or mandate the usage of a specific instance. Resources - Any descriptor of relevant resources involved that do not fall within the definition of other features or meta-features, such as hardware, OS, frameworks or virtualisation platforms, required knowledge or information, funds, facilities, prior access (of any kind, physical, virtual, etc.). This set of meta-features is not exclusive, as in additional meta-features are possible and viable to add to the model. Examples include data source, author/analyst, detection method (as in tool or technique or capability), detection signature, victim-adversary relationship (i.e., the social-political as in a class for pairs victim-adversary) and technology (a combination of infrastructure and capability). The model is generic enough so that each observable event can fall within such abstract description. The model also does not, for any observable, assume a given number of known features or meta-features (e.g., the Adversary feature is most often unknown for the majority of the represented events); a structure containing only a subset of features is an acceptable representation of an event, although probably less likely to be useful during intrusion analysis the more features are unknown or unspecified. If the element represents an event relevant to the analysis of an intrusion, the missing features or meta-features can be established as result or byproduct of the analysis. The uncovering of such previously unknown features (or change of perspective in a single event from a feature to another) is also known in intrusion analysis as pivoting. Note that the opposite vertexes of the diamond represent the two main contexts in which the event is located: the pair Adversary-Victim is the social-political context while the Infrastructure-Capability is the purely technological context.

| Features and Meta-Features | Social-Political features VS Technology features | Pivoting - Change of perspective from a feature to another. | | — | — | — |

For intrusion analysis purposes, diamond-like data structure can be then clustered by Victim-Adversary pairs, correlated (e.g., by enablement, such as a victim host becoming infrastructure) and phase-ordered (according to the combination of Timestamp and  Phase meta-features) to turn into Activity Threads. Activity threads represents sequences of events presumably by the same adversary (depending on confidence values) or, in simpler words, adversary operations. From Adversary Threads, Adversary Processes can be extracted as more general cases to deal with when un-specifically aiming for detection enhancement. Activity threads themselves can then be coalesced into Activity Groups by features similarities (e.g., keep in mind that the adversary can often be an unknown thus a large number of activity threads can be generated when considering wide or exposed attack surfaces). The creation of activity groups boils down to the formalisation of features similarities, i.e., to the definition of an Activity Group Creation Function (AGC). Once the AGC is defined, continuous observation of the events and direct classification into the activity group they belong or becomes possible (See figure 9 and 10 from the paper, included below in lower-left corner for the sake of completeness). Activity groups denote common behavior or characteristics observed by many activity threads and therefore represent a threat to be dealt with. This is usually done by populating a course of action matrix with security controls capable of disrupting the identified adversary operation in the different phases (see as an example the picture in the lower-right corner below). The process to identify activity groups is well detailed in the paper and exemplified in the pictures below. Either as a proactive exercise or as a result of long time observation, an Attack Graph can be also built with the same model to see which paths the detected activity threads actually cover (and if are there steps missing, thus possibilities to enhance detection). Also, whereas the attack graph is built only upon observed events, it also constitutes a useful tool for vulnerabilities prioritisation since a vulnerability fix implies pruning the graph (i.e., there is a clear picture of the paths that become no longer viable for an adversary to take towards action on objectives).

Activity Threads Red edges = links between events with related confidence values Dashed edges = Alternative hypothesis Gaps in phases = Potential for improving detection Adversary Process An Adversary Process is a subgraph of the activity thread containing a subset of its features. In simple words, it’s an abstraction of the detected adversary operation. Attack Graph An attack graph is a representation of the same concept addressed by attack trees as it would be if each leaf-root path walk in the tree was encoded in diamond events and those were correlated as per intrusion analysis practice according to the model.
     
Series of pictures to explain the details of The Diamond Model. Pictures from the paper [2013 Caltagirone et al] Series of pictures to explain the details of The Diamond Model. Pictures from the paper [2013 Caltagirone et al] Series of pictures to explain the details of The Diamond Model. Pictures from the paper [2013 Caltagirone et al]

It is worth noting that the process to analyse collected data and identify common features to build a probable model for adversarial behavior is not a new concept; for instance, the same abstract process was used by Mandiant in uncovering the activity of the so called APT1 and its likely attribution. However, the diamond model provides a structured approach that can be replicated and used at scale.

Threat Profiling

image_6.jpeg The definition of Threat in CTI identifies three characteristics of cyber adversaries sometimes also referred as Threat Actors. Threat actors are in most cases unknown prior to security incidents and most often also not identifiable after these take place (see the Attribution section). To deal with them in this constant condition of uncertainty, the common practice is to profile threats and threat actors in broad categories for which estimations in terms of intent, opportunity and capabilities can be reasonably made. This serves the basic purpose to properly plan cyber defense and incident response based on the likely threats for the organisation or entity to defend. The most common categories of threat actors typically considered go as follows: Script kiddies - I.e., unexperienced adversaries with limited capabilities (i.e., mostly taking advantage of public knowledge and easy to access capabilities) and weak intent. Lone adversaries - E.g., disgruntled employees, malicious insiders, lone cyber criminal seeking personal gain or reputation. Might have distinctive knowledge or level of prior access coupled with significant intent, but are still limited in terms of capabilities especially when it comes to resources. Hacktivists - Lone or arbitrarily large groups potentially with advanced skills but limited capabilities except for their numbers. The intent of this category of threat actors is usually to defend or demonstrate their principles, e.g., by rendering a technology provider unable to provide its services as a form of protest or to steal classified information to be publicly exposed in order to influence public opinion. Organised crime or crime groups - Criminal groups including or with access to experienced operators and significant capabilities. Their intent is focused on theft (e.g., of personal data or IP, financial gain or other valuable interference potentially on behalf of a 3rd party. Cyber Terrorists - A threat actor profile combining an intent based on the action-on-principle with potentially significant capabilities. They are not expected to act for financial gain but rather to cause damage and discomfort as a form of intimidation and influencing condition to support their cause. Sponsored adversaries - Threat actors with advanced capabilities and resources. They act on behalf of a third party, as mercenaries, e.g., in industrial espionage oriented activities. Nation State Actors or State Sponsored Attackers - Groups either within or acting with the support of a nation state government. Assumed to have access to the highest level of capabilities in terms of resources and to some extent to most experienced personnel, depending on the technological advancement of the relevant nation state. Additionally, a most disturbing category is also well known as the Advanced Persistent Threats (APT), which overlaps with some of the above-mentioned categories in some instances (e.g., a state sponsored actor wither part-of or financed-by one of the world’s superpowers, or a criminal group acting as a sponsored adversary backed by a resourceful corporation or government). APTs are additionally discussed in the next section. It’s worth noting that threat profiling constitutes a fundamental block of CTI because based on the profile and frequency of associated activities it is possible, e.g., to identify trails of targeted activities, which are most common by few of the above mentioned categories including state-sponsored organisations stealing military, government or commercial intellectual property,  organised criminal groups committing theft, fraud and money laundering they perceive as low risk and high return, non-profit hacktivists and for-profit mercenary organisations attempting to disrupt or destroy their own or their client’s perceived enemies. When planning security controls, these categories are evaluated for likelihood of involvement in malicious activities targeting the organisation and countermeasures are planned accordingly. CTI provides actual information rather than theoretical estimation of threats and can be leveraged to continuously both improve profiling and dynamically prioritise accordingly.

Advanced Persistent Threats (APTs)

As the name suggests, an Advanced Persistent Threat (APT) is an adversary that posses advanced skills and poses a threat which is persistent in its intent. This category gained significant hype and attention in the media lately (how almost any security vendor has a web page or blog post called “What Is an Advanced Persistent Threat (APT)?”, e.g.: CarbonBlack, Cisco, MalwareBytes, Forcepoint, TrendMicro, BitDefender, FireEye, Kaspersky) and has the tendency to be perceived as the name for those groups holding technological superpowers, which might be close to true in some cases but still APT have been observed to use still simple but effective techniques as long as their actions on objectives were within reach. With reference to the diamond model (see related section) an APT is identified by an adversary-victim relationship in which adversary carries on continuous, recurring or escalating activity over time through significant resources and capabilities. Nevertheless, APTs also have been observed to target both victims of opportunity as well as victims of interest, mostly due to two recurring conditions: either the threat actor profile is uncovered over time or victims of opportunity become infrastructure for the adversary operations. The first example of documented APT is the allegedly Chinese group part of the People’s Liberation Army (PLA’s) unit 61398, supposedly identified by identified by Mandiant as the group “APT1”. Ever since, a variety of (supposedly different) threat actors have been identified as APTs. A slightly more recent example is the PLATINUM cybercrime group code-named by Microsoft in one of its security intelligence reports in 2015, identified for targeting organisations in south and south-east Asia, and allegedly recently re-surfaced. Most of the related dissemination however is performed by organisation (either private or publicly funded) that have a west-centric perspective and most often are based in the U.S. For instance: MITRE corporation maintains a list of APTs identified from their research work here. CrowdStrike (a private U.S. based security vendor) often publishes strategic intelligence reports related to APTs. They are also known for the related naming convention they use to name them (See below). Netlify (a U.S. tech company) provides a nice visualisation of known APTs activity based on data collected by the MISP project (an Open Source TI Platform & Open Standards for CTI Sharing) APTs are identified by different naming conventions depending on the different companies whose analysts identify their activities. This is not only to differentiate but also because they might have different visibility and partial knowledge of their M.O. So collectively the intelligence community find itself asking questions like Is CozyBear APT29?. See the diamond model section and related activity groups for common methods to compare results of different intrusion analysis.

Example of APT naming convention (mostly by CrowdStrike) Example of APT naming convention (mostly by CrowdStrike) Example of APT naming convention (mostly by CrowdStrike)
Animal Allegedly Threat actors From Visual Representation
Kittens Iran  
Pandas China  
Bears Russia  
Buffalos Vietnam  
Chollima North Korea  
Leopards Pakistan  
Tigers India  
Spiders Organised crime groups  
Jackals Hacktivist or Terrorist groups  

Attribution

Attribution is one of the most controversial topics in cyber security. In simplest terms, the topic boils down to the question “Who is behind this (cyber attack)?”. To answer such question, even just through hypothesis and differential analysis, is a critical part of the intrusion analysis process, because it can drive or disprove the reasoning on the motives (intent) of the related threats. However, there is a good reason for which attribution is such a controversial topic in this context and it’s because in the cyber realm almost any evidence can be at least theoretically forged, and therefore most hypothesis are bound to remain allegedly or inconclusive; when this is not the case, the reasonable doubts are most often removed by exclusion through evidences outside of the cyber realm, or by narrowing down the space for the attribution given the necessary resources to support observed capabilities. Experts in the field claim that there are four paths that can contribute to the attribution but none of these are really conclusive themselves. A combination of coherent results however could be weighted against the effort required to forge the conditions for such results to align and who could be willing to put such effort in place (i.e., would be capable of invest the required resources and in the mean time gain a superior benefit). Such four paths are: Admission - Condition which will hold most relevance, although cases have been historically observed in which people and organisations just claimed responsibility to gain another sort of advantage. Leaks - “Leaked” evidences are as well hard to validate if the involved adversaries have proper resources to handle them. Also, leaks can be primary target of disinformation or counter-intelligence campaigns. Direct Access - Intended as in “the presence of direct witness(es)” or direct evidence collection (as in SIGINT / communications interception). Here as well, witnesses can be unreliable, lack credibility or just get it wrong e.g., due to their personal lack of context or otherwise relevant information. Direct evidence collection on the other hand is still subject to counter-intelligence / planting of tampered or purposely crafted evidences. Intrusion Analysis (byproducts) - It’s the main  path for the production of CTI, which however base most of its activities on the analysis of digital artefacts that could have been forged by the adversary to disguise themselves as some other entity. Moreover, Intrusion Analysis is not exempt by biases, i.e., attribution related conclusions can be (and often are) driven by social/cultural/political background of the analysts Due to the controversial nature of the topic, attribution is most often limited to the profiling of the threat in terms of classifying the adversary within the perceived category. This still represent a valuable goal in that it allows to cluster malicious activity belonging to a single allegedly threat actor and its relevance in the reference context (e.g., industry, geography, etc.); the effect is clearly multiplied in the context of CTI being shared across different organisations. The practice of taking further steps falls typically within one of two paths, which are either: Escalating security incidents to law enforcement - This is because in most country only law enforcement have the legal means to access data from different organisations to correlate technical intelligence to actual personas. If enough evidence can point to an actionable target (such as intervention to have an adversary cease and desist), this path can be taken under the reasonable assumption that the adversary profile is within the reach of law enforcement themselves. Collecting and correlating evidences to uncover an APT - This kind of activity require specialised means and resources and is typically carried on only by organisations that have large experience in the field such as AV vendors or large scale security services providers. For an example of the outcome of these activities, check out the Advanced Persistent Threats (APT) section.

CTI Consumption

The U.S. DoD, in Joint Intelligence Preparation of the Operational Environment (JIPOE), defines how to use intelligence to develop course of action on a general intelligence basis. They state that a strategy will fail if solely based on the nullification of adversary infrastructure and capabilities, since those can be fairly easily replaced. In the field of CTI this also makes sense, since disruption of adversary capabilities (e.g., by blacklisting a malicious host and providing EDR with new signatures) can be easily overcome (e.g., by using another compromised host and morphing a malware to be undetected by the latest signatures). JIPOE prescribes instead the identification of the adversaries, of the centre of gravity of their operations and of adversary responses and courses of action. This approach aims to identify optimal deployment strategy for countermeasures in order to thwart the adversary capacity to rebuild the capabilities and infrastructure once mitigated. In CTI, the diamond model supports such reasoning by identifying points on the critical path to implement it, including adversary behaviour definition and likely course of action as well as identification of resources. However, there are most often limited options for resolutive actions against adversaries due to national boundaries and necessity to involve law enforcement, and at the same time it is necessary to timely contain intrusion attempts before adversaries reach their objectives, therefore the generally employed approach in the industry is to enforce short term mitigations and have a separate longer process for proportional response. image_7.jpeg In The sliding scale of cyber security, Robert M. Lee poses Intelligence towards the right hand side of the scale, implying it builds and leverages active defense and poses foundation for the most advanced capabilities. Note that intelligence consumption is part of the Active Defense category of the scale, while generating intelligence (i.e., collecting data, exploiting those for information by applying knowledge (possibly through automation) and producing assessments that ratify previously identified knowledge gap) fall within the next category (the one actually named Intelligence).Active Defense is short for the so called Active Cyber Defense Cycle, as one of the four steps for a Blue team strategy that does not exclusively rely on passive protective security controls. The cycle itself defines four phases: CTI consumption - CTI disseminated from producers is fed into security controls and used by SOC personnel for threat hunting purposes and during incident response Security Monitoring - Received IOCs and TTPs are leveraged to identify intrusion attempts and compromised hosts or networks through automated solutions such as EDR, threat hunting tools and SIEM systems. Incident Response - When responding to an incident, scoping of the impact of the threat and related prioritisation is enabled by the received CTI and the contextual information provided (e.g., what a detected malware is, in which context was it observed before, how dangerous it is, which are the know-to-work containment actions, etc.) Environment Manipulation - Based on the response to actual threats in the organisations, enabled by the received CTI, modifications to the environment can be suggested and prioritised (e.g., patching of specific vulnerabilities, architectural changes, introduction of different security controls, etc.) As for the dual nature of immediate need for containment and ultimate goal of resolution, the Active Cyber Defense Cycle places the incident response practice as first step and the application of changes to the environment as second. However, the latter does not constitute the obliteration of the adversaries’ ability to rebuild capabilities and not desist in their offensive operations. A specific note is worth for the practice of artefact submission, most commonly part either of the Incident Response or Environment Manipulation phases: malware samples or traffic dumps collected during incident response are typically shared with security vendors such as AV/EDR providers. The receivers analyse the artefacts with the goal to confirm its malicious nature and extract IOCs (hashes, signatures) or define detection routines (e.g., YARA rules) to be distributed to their solutions for their customers. Even in presence of a significant security staff, many organisation operates like this due to the fact that security vendors can perform the analysis and generation in a more timely manner. There is however a caveat with this modus operandi, which is that once the security vendor gets it, that artefact is considered “burnt” (i.e., it is now soon-to-be detected by that vendor solutions) and the attacker is therefore forced to change its vector or TTP, however difficult that might be, potentially switching to a non-detectable technique in contrast with the previous one (which despite not being recognised already by the vendor solution was still identified in the incident response process). Besides its place in the active defense cycle, CTI consumption is documented in literature to have similar purposes to those typical of business intelligence. Interestingly, those maps quite well with the types of CTI mentioned above, as well as with the different timing and MO of the functions involved in their consumption (from reactive, to responsive to proactive). image_8.jpeg Report - Document what happened for the sake of comprehension and input for decision making. Consuming this form of CTI provides evidence of events that took place and how they happened. Diagnose - Answer specific questions related to how something happened down to the most specific detail. Consuming this form of CTI provides knowledge of TTPs used by adversaries, possible attribution and insights on adversaries’ motivation (mostly either criminal or geopolitical insights). Predict - Attempt to predict future events based on predictive models fed with historical data. Consuming this form of CTI provides (most likely strategic CTI) serves as input for responsive strategic planning. Operationalise - Enable immediate action driven by current events timely observed and reported. Coming this form of CTI enable for responsive tactical initiatives (e.g., put in place of hardening or temporary preventive containment). Activate - Trigger machine-speed reaction (e.g., confluence of IOC turned into detection rules into a SIEM or EDR platform). As for humans, this raises the question of what one wants to happen in an if-then fashion. This represents a proactive approach with tactical (i.e., short term) temporal view.

CTI Sharing

Successful use cases for CTI, being generation, consumption or a combination of both, require some effective and meaningful way to represent and communicate the outcome of the CTI generation process. That being said, if relationships between organisations would be only of the generator → consumer type, little value could be obtained from CTI due to the limited visibility that most generators have and the most likely wide in comparison landscape of possible adversaries for most organisations. CTI Sharing is therefore an essential part of leveraging CTI. Besides vendor → client relationships, many initiatives have been established over the years to share, either publicly or within closed groups, CTI information. This type of sharing also has the benefit to improve shared knowledge with cross-organisations, cross-industries, cross-countries correlations otherwise extremely unlikely to figure out. This section therefore focuses on CTI sharing. First, a closer look to the concept of IOC is provided; as follows,  current standards, taxonomies, formats and exchange protocols are enumerated and briefly described.

Indicator of Compromise (IOC)

An Indicator of Compromise (IOC) is a form of technical intelligence and is defined as a distinctive characteristic of an artefact identified over networks or systems that indicates with high confidence value the presence of a cyber intrusion. IOCs can be either volatile, i.e., they maintain temporary presence in a system such as volatile memory as the name suggest, or persistent, as in they can remain on a system indefinitely if the adversary does not take dedicated steps to remove them and clean her trail. In literature, IOCs have a set of desirable qualities, as in they are most of use being specific - I.e., related to a well understood compromise modus operandi - Complete / Complex - I.e., include enough details to make hard for the adversary to evade detection based on the IOC, simple to elaborate - Ideally, simple enough to be automatically processed by security controls for detection purposes and also, depending on the type of IOC, fresh - i.e., recently observed in the context of an intrusion analysis or otherwise identified malicious activity. The freshness quality for an IOC is desired due to to the fact that in the cyber realm most elements are subject to sudden and very fast change in their nature. For instance, IP addresses or domains observed as hosting C2 (command & control) can turn out to be false positives at the moment of consumption of such intelligence due to the fact that the observed C2 is no longer hosted on the host at that IP address. Same goes for domain verification, which can give false negatives because the C2 on the related host has just become very recently active and the verifier has not yet received the related intel. This is for instance quite common in phishing-driven malware distribution or in modern malware C2 communications. To avoid blacklisting of a malware distribution host or C2, different techniques are used, such as dynamic domain generation or fast flux, which can have for instance the malware changing the expected communication endpoint for C2 traffic every few minutes or even seconds. In Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains, Hutchins et. al. also establish the following wide-range categories IOCs can fall into: Atomic - as in they cannot be broken down to multiple indicators (such as IP addresses, email addresses, CVE) image_9.png Computed - derived from data gathered during response procedures, e.g., hashes or strings (signatures) / regex Behavioural - collections of atomic and/or computed, as either multiple occurrences or sequences / frequency over time From defenders perspective, the IOCs serve two main purposes: Being deployed in the configuration of security controls to enable / enhance detection of malicious activity (i.e., identify compromised hosts or malicious network flows) Support investigation and intrusion analysis during incident response and forensic analysis (i.e., tie pieces together and identify threats and related previously unknown IOCs. Possibly attribution) The number of security controls that can be fed IOCs to enhance their detection capabilities is significant, but main examples are firewalls, user and entities behavior analytics solutions (UEBA), Network- or Host-based- intrusion detection / prevention systems (NIDS / NIPS), AV and new generation anti-malware solutions or Endpoint Detection and Response (EDR), DNS (for redirect or sink-holing of C2 and malware distribution domains), automated jailing controls (either host-based or network based as in remediation networks) and honeypots (which despite being collectors of IOCs can also be enhanced by them, e.g., by using client honeypots to gather further IOCs by interacting with well known compromised hosts or domains). IOCs are typically a byproduct of incident response and forensic analysis (See the picture “Malware Investigation Lifecycle”). Alternatively, they can be identified and recorded by technology purposely deployed to identify malicious activity indicators, such as honeypots and other deception technologies. The most common types are identified as follows. Note that there is a well known representation of these types of IOCs, also known as the Pyramid of Pain (see picture on the right). The pyramid serves as a representation that the lower IOCs in the pyramid are, the easier it is both for defenders to identify through security controls as well as easier for the adversaries to change in order to evade such controls and avoid detection. On the other hand, the higher the IOCs are in the pyramid, the more useful they are since they are hard for the adversary to change but also they are harder to identify and formalise upon first observation for further detection. Hash values - Mostly of files, typically executables or macro-enabled documents image_10.png IP addresses - Of endpoints to/from which malicious activity has been observed. Note that these do not map to threat actors, since could belong to a compromised machine used as a jump or to a service provider that performs network address translation (NAT) for its customers, and might not be in a cooperative country and/or willing (or legally bound) to participate in investigations and/or take action accordingly. Domain names or URLs - Same as above. Latest trends however showed an that this entry might be misplaced on the pyramid since in modern ecosystem of service providers it is quite easy to implement automated domain registration and continuous changes in domains used for interaction (C2) through domain generation algorithms on board of distributed malware. Other network or host based artefacts - These might range between registry values, system paths, memory locations, or malformed traffic streams or packets Tools - Indicators left on target systems due to the usage of specific tools. While it’s mostly true that tooling is hard to change for the adversaries because doing so require either learning to use a new one or have development capabilities and time to implement a new one, recent trends show the tendency of adversaries to use whenever possible tools and means that are already available on target systems to minimise the odds of being detected by hiding their activity within legitimate ones. This is commonly referred as living off the land. Tactics, Techniques and Procedures (TTP) - These are complex behavioural IOCs, most often composed of different atomic IOCs with a given sequence in time. They are meant to represent the modus operandi of the adversary (or the equivalent effect on the intrusion targets caused by its possibly automated process), such as attack vectors used, steps taken to propagate the compromise and move laterally, etc. TTPs can be extracted and formalised in various forms, from high-level description requiring HUMINT and human operators during the analysis to be useful, to more structured representations such as patterns and indicators recognisable by next generation AV solutions which performs, for instance, process inspection on the hosts where they are installed, thus being able to detect TTPs such as processes migration or intended for privilege escalation. These are generally the hardest IOCs to change for an adversary since they require either learn or discover new TTPs entirely (and probably implementing or learning also the means to use them), which in turn is both time consuming and requires specific technical expertise. This doesn’t mean that adversaries cannot change TTPs, just that doing so continuously will be hard and in most cases hardly worth. A great picture of most commonly used TTPs in the wild is provided for instance by the ATT&CK framework. IOCs can also be considered in a view across the typical phases an adversary will undertake when carrying on an intrusion. For instance, with reference to the phases of the cyber kill chain, further divided in pre/during/post compromise: Pre-compromise Reconnaissance - Which is the attack surface? Which hosts or employee were targeted (IP Addresses, digital identities and associated credentials) Weapoinization - Which attack vector was used? (tools, artefacts, infrastructure (IP addresses, domains), TTPs) Delivery - How was the payload delivered? (hosts or network artefacts/traffic dumps, delivery endpoint, TTPs) During-compromise Exploitation - Which vulnerabilities were used? (CVE, software versions, configuration references) Installation - What system resources were modified? How can the persistence be detected? (system paths, registry keys, filenames, hashes and other malware related IOCs) Post-compromise Command & Control (C2) - Who did the compromised attempt to contact? (IP addresses, domains) Actions on Objectives - What actions was the compromised resource forced to perform? (network traffic patterns or artefacts (e.g., exfiltration attempts or internal recon), actions on filesystem, TTPs)

Standards, taxonomies, formats and exchange protocols

This section outlines the relevant standards and formats to represent CTI and their exchange protocols.

IODEF

The Incident Object Description Exchange Format (IODEF) is an IETF specification initially defined in RFC 5070 (2007), updated in RFC 6685 (2012), then again updated in RFC 7203 (2014), then superseded by RFC 7970 (2016) which defines the second version of the format (IODEF2). The specification “defines a data representation for security incident reports and indicators commonly exchanged by operational security teams for mitigation and watch and warning”. To make implementations of the specification easier, IETF also published RFC 8274 (2017) in which guidelines for the implementation are provided. A reference implementation of the data model is also provided as an XML DTD along with classes specifications in RFC 7970. The format is designed to be human-readable rather that for machine consumption, has an object-oriented structure with 47 pre-defined classes and is compatible with the Intrusion Detection Message Exchange Format (IDMEf) defined in RFCs 4765, 4766 and 4767. The related transfer format and protocol suggested in the RFCs is Real-time Inter-network Defense (RID) detailed in RFC6545 and RFC6546 for RID over HTTPS/TLS.

OpenIOC

OpenIOC is an open framework for sharing CTI, created by Mandiant (OpenIOC website on the wayback machine) to establishes a standard for recording, defining and sharing information both internally and externally in a machine readable format. OpenIOC used to be shipped with a base set of curated IOC by Mandiant, which benefit from collection and aggregation of multiple sources from their network of CTI sharing. After the acquisition of Mandiant by FireEye, OpenIOC did not receive further development besides its assets being kept maintained by FireEye as part of their freeware products such as Redline. This is therefore document just for the sake of completeness. OpenIOC format was defined as an extensible XML schema revolving around definitions, references and metadata of IOC artefacts. The specifications of version 1.1 are still available on Mandiant GitHub. The framework also provided an application to import, edit and analyse IOCs defined in the given format, i.e., IOC Editor, still available as provided by FireEye.

MMDEF

The Malware Metadata Exchange Format (MMDEF) is a format defined by IEEE standards association Industry Connections Security Group (ICSG) to enable sharing of malware-related metadata along with malware sample, mostly in the context of interactions with AV vendors. The format is also XML-based and defined by this XSD schema (version 1.2, 2011). Some examples are available here. The group also defined a behavior focused version of the format to enable the structured representation of the results of dynamic analysis (i.e., running, a.k.a. detonation, of malware in controlled environment to observe and record its behavior and artefact); such effort resulted into the definition of MMDEF-B v1.0 (2015). This format is complemented by the Clean Metadata eXchange (CMX) format from the same group, which is meant for sharing of metadata of non-malicious files from software vendors to security companies (again, mostly AV vendors) for whitelisting purposes. Related references here.

YARA

YARA is a tool created by Victor M. Alvarez (@plusvic) of VirusTotal, to identify and classify malware samples. The purpose of YARA is to define how to generate descriptions of samples (i.e., mostly binary as in PE and ELF) based on textual or binary patterns; such descriptions take the name of YARA rules, and consist in a set of strings or boolean expression that determines the matching of the rule against a binary. Unsurprisingly, the tag line for the YARA project is ”The pattern matching Swiss knife for malware researchers (and everyone else)”. According to the author, “YARA is an acronym for: YARA: Another Recursive Ancronym, or Yet Another Ridiculous Acronym. Pick your choice”. Many malware analysis tools have modules capable to extract or generate YARA rules from the results of their analysis, such as the cuckoo platform. YARA has a variety of usages, e.g., from command line or python code. Some additional references as follows: YARA code - YARA Documentation Awesome YARA - A curated collection-of-collections of YARA rules for detection purposes YaraRules - another aggregator of YARA rules for detection purposes YaraEditor - An automated / assited tool to generate YARA rules

CME and MAEC

Common Malware Enumeration (CME) and its successor Malware Attribute Enumeration and Characterisation (MAEC) are community-developed initiatives led by MITRE corporation to define a structured language for encoding and sharing high-fidelity information about malware based upon attributes such as behavior, artefact, and relationships between malware samples. CME web page states that “In late 2006 the malware threat changed away from the pandemic, widespread threats CME was developed to address to more localised, targeted threats, which significantly reduced the need for common malware identifiers to mitigate user confusion in the general public. Therefore, all CME-related efforts transitioned into support to MITRE’s MAEC effort”. The latest specification of MAEC (v.5.0, 2017) are available here. MAEC considers some top level characteristics and the correlations between them, such as: Family - Derivation or inheritance of the malware instance by other instances sharing parts of code, either in their executed routines or their structure such as in their dropper. Instance - Details related to the specific malware instance, such as where has it been observed before, which was its transport source, if is it part of a chain of multiple malware, etc. Behavior - How does the malware instance operare, what is its lifecycle, etc. Actions - Which are the actions performed by the malware against systems where it runs MAEC is also in a close relation with STIX, in that the characteristics are detailed through observable objects in the STIX format. While MAEC has its own vocabulary, many of the expected definitions in MAEC are equivalent and detailed in MITRE Encyclopedia of Malware Attributes (EMA). MAEC JSON schema is available here.

ETT

The European Union Agency for Cybersecurity (formerly European Network and Information Security Agency (ENISA)) defined its own taxonomy of threats. The definition is part of the EU Open Data initiative. ETT is not however widely used due to lack of clarity and consistency in relation with other taxonomies. The latest version at the time of writing is from 2016 in form of an excel spreadsheet, with recent updates in 2019.

OTT

Open Threat Taxonomy (OTT) was released as an open source tool in 2015 by James Tarala and Kelli K. Tarala of Enclave Security and is now part of the bigger AuditScripts initiative. The taxonomy provides a consistent although high-level coverage of threat actions from physical, to resources, personnel and technical threats, also assigning priority ranks on a 1-to-5 scale depending on which threat actions are most likely to cause damage with greater impact. Despite being quite generic and lacking details besides the general descriptions, the taxonomy has been adopted in different cases as a sort of check list for risk management and countermeasures planning. Latest version is available here.

CybOX

CybOX (standing for Cyber Observable eXpression) was an effort by MITRE corporation to define a language for describing observables, as in artefacts recognisable for malicious activity detection purposes, such as IP addresses, hashes, registry keys, URLs, HTTP sessions data etc. (more simply put, IOCs). After version 2.1, CybOX has been integrated into STIX 2.0. Latest doc reference, for historical purposes here.

VERIS

The Vocabulary for Event Recording and Incident Sharing (VERIS) is an effort from Verizon launched in 2010 as a schema for collecting and sharing intelligence related to security incidents. Its purpose is to share strategical information, and has a limited coverage in terms of representing and sharing IOCs. From its documentation: Veris is a set of metrics designed to provide a common language for describing security incidents in a structured and repeatable manner. VERIS is a response to one of the most critical and persistent challenges in the security industry - a lack of quality information. VERIS targets this problem by helping organizations to collect useful incident-related information and to share that information - anonymously and responsibly - with others. The latest version of the VERIS schema (1.3.2 at the time of writing) is available here. Data provided by organisations adopting VERIS is publicly available here; note that the same data is used to extract the statistics part of the Verizon’s Data Breach Investigations Reports (DBIR), which latest version is available here.

CAPEC

Common Attack Pattern Enumeration and Classification (CAPEC) is an initiative initially released in 2007 by U.S. DHS and currently maintained by MITRE corporation. CAPEC provides a publicly available comprehensive dictionary of known patterns of attacks employed by adversaries to exploit known weaknesses in cyber-enabled capabilities. From its documentation: The Common Attack Pattern Enumeration and Classification (CAPEC™) effort provides a publicly available catalog of common attack patterns that helps users understand how adversaries exploit weaknesses in applications and other cyber-enabled capabilities. ”Attack Patterns” are descriptions of the common attributes and approaches employed by adversaries to exploit known weaknesses in cyber-enabled capabilities. Attack patterns define the challenges that an adversary may face and how they go about solving it. They derive from the concept of design patterns applied in a destructive rather than constructive context and are generated from in-depth analysis of specific real-world exploit examples. Each attack pattern captures knowledge about how specific parts of an attack are designed and executed, and gives guidance on ways to mitigate the attack’s effectiveness. Attack patterns help those developing applications, or administrating cyber-enabled capabilities to better understand the specific elements of an attack and how to stop them from succeeding. CAPEC has a strong relevancy in current efforts to standardise formats for CTI sharing because the entries of its library of attack patterns can be used as references in CTI sharing formats or languages, thus enabling correlation of CTI generated by multiple heterogeneous parties. The laters version of CAPEC library is browsable here. Download links for the whole library are also provided (different platforms directly use these data); e.g., STIX uses CAPEC for structured characterisation of TTPs by leveraging its references in the “attack-pattern” SDO (in STIX 1.X this was by populating the AttackPatternType according to its XML extension schema). The CAPEC library, along with the content of the MITRE ATT&CK framework, is available in STIX2.0 JSON here.

STIX

Structured Threat Information eXpression (STIX) is a structured language and serialisation format to exchange CTI, enabling organisations to share in a consistent and machine-readable manner. Initially developed as a collaborative effort led by MITRE corporation to develop a standardised, structured language to represent cyber threat information, it is now maintained (as from STIX 2.0) by the OASIS Cyber Threat Intelligence Technical Committee (OASIS CTI TC). STIX 2 introduced notable changes both in the objects definition as in the format (which moved from XML to JSON). As follows, with “STIX” we will be referring to STIX2. STIX defines a format to create IOCs, enrich them with contextual information and share them through some transfer protocol (i.e., the concept define by TAXII). In comparison with other formats, it is currently the more complete and comprehensive, allowing the representation e.g., of C2 activity, data exfiltration, compromised credentials and more. Ideally, STIX format can be used by a wide range of figures in a mature computer and network defense staff, from Cyber Threat Analysts for the definition of threats and related capabilities/observables, to SOC operators for handling threats (prevention, detection, response) to sharing with communities (most likely based on pre-defined sharing policies). STIX defines a number of objects to be used as base entities and relationships in the representation. From the documentation: image_11.png STIX Domain Objects (SDO) - Typical domain concepts used in CTI. In graph-like views, SDOs are vertexes. Attack Pattern - A type of Tactics, Techniques, and Procedures (TTP) that describes ways threat actors attempt to compromise targets. Campaign - A grouping of adversarial behavior that describes a set of malicious activities or attacks that occur over a period of time against a specific set of targets. Course of Action - An action taken to either prevent an attack or respond to an attack. Identity - Individuals, organisations, or groups, as well as classes of individuals, organisation, or groups. Indicator - Contains a pattern that can be used to detect suspicious or malicious cyber activity. Intrusion Set - A grouped set of adversarial behavior and resources with common properties believed to be orchestrated by a single threat actor. Malware - A type of TTP, also known as malicious code and malicious software, used to compromise the confidentiality, integrity, or availability of a victim’s data or system. Observed Data - Conveys information observed on a system or network (e.g., an IP address). Report - Collections of threat intelligence focused on one or more topics, such as a description of a threat actor, malware, or attack technique, including contextual details. Threat Actor - Individuals, groups, or organisations believed to be operating with malicious intent. Tool - Legitimate software that can be used by threat actors to perform attacks. Vulnerability - A mistake in software that can be directly used by a hacker to gain access to a system or network. STIX Relationship Objects (SRO) - SROs are used to correlate couples of SDO. In graph-like views, SDOs are edges. Relationship - Used to link two SDOs and to describe how they are related to each other. This object is general purposes. Sighting - Denotes the belief that an element of CTI was seen (e.g., indicator, malware). Marking definition Object - Contain data marking, which represent handling or sharing requirements for data. Are applied to SDOs and SROs. Bundle - Collections of arbitrary STIX objects and marking definitions. Note that bundles are not STIX objects and objects grouped in bundles do not have necessarily relationships to each other. I.e., bundles are semantically meaningless and are used mostly for sharing purposes. Each object in STIX has a set of predefined properties, some applicable to all SDOs and SROs. A set of standardised labels are also defined by the format, for a variety of aspects to be included into CTI entities, such as attack motivation, industry sectors, threat actor sophistication or adversary resource level. Deeper analysis of the STIX language/format is beyond the scope of this research and the reader is referred to the following documentation. Note that STIX2 is currently the most common format used to share CTI and is supported by the most mature CTI platforms. [ STIX&TAXII Homepage ] [ Full STIX documentation ] [ Official STIX JSON Schema ] [ Python Library to handle STIX2 Objects ] [ OASIS TC Github Account ] PDF-Exported Full STIX Documentation (as of July 2019, check the link above for possible updates): image_12.png image_13.png image_14.png image_15.png image_16.png

TAXII

Trusted Automated Exchange of Indicator Information (TAXII) defines a set of services and message exchanges that, when implemented, enable sharing of actionable cyber threat information across organisationals, product line and service boundaries. Basically, TAXII is a transport protocol for for STIX. Note that TAXII is not an information sharing program itself and does not define trust agreements, governance, or other non-technical aspects of collaboration. Instead, TAXII empowers organisation to share the information they choose with the partners they choose. As the companion effort to STIX, TAXII was also initially developed by MITRE corporation and is now maintained by the OASIS Cyber Threat Intelligence Technical Committee (OASIS CTI TC). TAXII is de-facto a transport vehicle for STIX-structured information and a key component in sharing CTI. Note that TAXII does not handle security of communication channels, but rather relies on TLS for that. Inside TLS, TAXI is an application protocol defined by an interface (specifically and HTTP RESTful API) and a set of requirements for its architectural components (TAXII clients and TAXII servers). TAXII servers, according to the specifications, support two models: Collection = request → response; Channels → publisher/subscriber; however, in version 2.0 (the current one at the time of writing) only the specifications for collections are provided, and therefore TAXII currently supports only push/pull interactions. Each instance of TAXII server can handle different logical collections of stored CTI exposing the same API ad different URLs (aka API Roots). The model is quite simple but enables a wide range of combinations of sharing models. Deeper analysis of the TAXII protocol is beyond the scope of this research and the reader is referred to the following documentation. [ Introduction to TAXII ] [ TAXII2.0 Specifications ] [ Training Material on STIX and TAXII from OASIS TC ] PDF-Exported TAXII 2.0 Documentation (as of July 2019, check the link above for possible updates): image_17.png A number of implementations are available for TAXII servers and clients, such as: Medallion - A minimal implementation of a TAXII 2.0 Server in Python (OASIS TC project). The companion client, still as an OASIS TC project, is cti-taxii-client libtaxii - A Python library for handling TAXII Messages and invoking TAXII Services. OpenTAXII - TAXII server implementation in Python from EclecticIQ. The related TAXII client implementation, still from EclecticIQ is Cabby node-taxii - A Node.js based implementation of TAXII server from the unfettered initiative Note that major threat intelligence platform already support TAXII as an exchange protocol, such as ThreatConnect, IBM X-Force, many industry vertical ISAC, EclecticIQ, Anomali STAXX/Limo, etc.

Industry organisation, sources and technology

In practice, the scenario of CTI in the security industry goes pretty much as follows: A number of public, private and volunteering organisations do generate cyber threat intelligence and disseminate it either freely or as a commercial service. Public and volunteer organisations typically disseminate their output for free. Many of these organisations are part of one or more exchange networks, in which participants make their threat intelligence feed available to others as well as consuming a selected list of feeds provided by others. Private organisations generating CTI are mostly either: Security vendors with significant visibility over threats behavior across the globe due to handling of their services for their customers. In some cases, these organisations have advanced CTI capabilities including HUMINT teams operating similarly to those of nation states intelligence organisations. These organisations either leverage the generated intelligence to improve their services for their customers or distribute it as part of additional services. Other private organisations with advanced security operations and capability to generate CTI relevant for their specific requirements. These organisations typically store and use the generated intelligence to enhance their own security controls and in some cases participate as a provider to sharing networks mentioned above. A much greater number of organisations limit their involvement to CTI consumption, either just leveraging intel produced by third parties to enhance their security controls or to perform, in more advanced scenarios, support for security incident response and forensic analysis activities. Curated list and more details on CTI sources, both freely available and as commercial services, is collected in the dedicated page Cyber Threat Intelligence - Sources. The generation and consumption processes described in this page, including leverage of standardised protocols and formats, usually leverage (to different extents depending on the purpose) technological means generically known as Threat Intelligence Platforms (TIP). TIPs are further discussed in the dedicated page Cyber Threat Intelligence - Platforms Survey.

References

Papers & publications

Cyber Threat Intelligence Model: An Evaluation of Taxonomies, Sharing Standards, and Ontologies within Cyber Threat Intelligence - Vasileios Mavroeidis and Siri Bromander - 2017 Gathering threat intelligence through computer network deception - Vincent E. Urias, William M. S. Stout, Han W. Lin - 2016 Cyber Threat Intelligence from Honeypot Data Using Elasticsearch - Hamad Almohannadi, Irfan Awan, Jassim Al Hamar, Andrea Cullen, Jules Pagan Disso, Lorna Armitage - 2018 Analysing Indicator of Compromises for Ransomware: Leveraging IOCs with Machine Learning Techniques - Mayank Verma, Ponnurangam Kumarguru, Shuva Brata Deb, Anuradha Gupta - 2018 Security operations centre: Situation awareness, threat intelligence and cybercrime - Cyril Onwubiko - 2017 The diamond model of intrusion analysis - Caltagirone, Pendergast and Betx - 2011 The diamond model of intrusion analysis: a summary - Caltagirone - 2013 The diamond model for intrusion analysis: a primer - Andy Pendergast - 2014 Applying Threat Intelligence to the Diamond Model of Intrusion Analysis - Cris Carreon (RecordedFuture) - 2018 Artificial Intelligence in Cyber Threats Intelligence - Roumen Trifonov, Ognyan Nakov and Valeri Mladenov - 2018 Nomadic Honeypots: A Novel Concept for Smartphone Honeypots - Liebergeld, Lange, and Mulliner - 2013 Meet The Advanced Persistent Threats: List of Cyber Threat Adversaries - Crowdstrike 2019 SANS - Cyber Threat Intelligence Consumption Poster - Robert M. Lee - 2019 SANS - Using IOC (Indicators of Compromise) in Malware Forensics - Hun-Ya Lock 2013 Sophisticated Indicators for the Modern Threat Landscape - An Introduction to OpenIOC - 2013 A Framework for Cyber Threat Hunting Part 1: The Pyramid of Pain - David Bianco - 2015 Cyber Threat Modeling: An Evaluation of Three Methods - Forrester Shull (CMU) 2016 CBEST Intelligence-Led Testing - Understanding Cyber Threat Intelligence Operations (version 2) - Bank of England - 2016 Cyber Threat Modeling: Survey, Assessment, and Representative Framework - HSSEDI (U.S. Homeland Security Systems Engineering and Development Institute) - 2018 ADAM: Active Defense Algorithm and Model - Caltagirone & Frincke - 2005 Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains - Eric Michael Hutchins, Michael J. Cloppert, Rohan M. Amin - 2010 Prioritizing Cyber Threats With Real-Time Threat Intelligence - Recorded Future Blog - 2017 Evaluation of Comprehensive Taxonomies for Information Technology Threats - Steven Launius - 2018 Finding Cyber Threats with ATT&CK-Based Analytics - MITRE Technical Report - 2017 RFC 5070 - The Incident Object Description Exchange Format - IETF 2007 5 Phases of the Threat Intelligence Lifecycle - Recorded Future Blog - 2018 APT1: Exposing One of China’s Cyber Espionage Units - Mandiant (now part of Fireeye) 2013 Microsoft Security Intelligence Report - Vol.20 - 2015 Dictionary of Military and Associated Terms - DoD (U.S. Department of Defense) - 2019 (U.S.) Intelligence - Field Manual 2-0 - U.S. Army - 2004 British Intelligence Explained - SIS (MI6) Open Threat Taxonomy - Auditscripts 2015 The pyramid of pain - David J. Bianco - 2013 Psychology of intelligence analysis - Richards J Heuer Jr. - 1999 The Sliding Scale of Cyber Security - Robert M. Lee - 2015 The 10 Commandments of Intrusion Analysis - C. Sanders - 2011 Attack Trees - Bruce Schneier - 1999 A guide to Cyber Attribution - US ODNI 2018 MITRE ATT&CK - APT Groups - 2019 Definitive Guide to Cyber Threat Intelligence - iSIGHT Partners (acquired by FireEye in 2016) 2015 ENISA Threat Landscape Report - 2018

Relevant Talks

SANS CTI Summit 2019 - Language and Culture in Threat Intelligence SANS CTI Summit 2019 - Lessons in CTI Psychology from TV’s Favorite Serial Killer SANS DFIR 2018 - Threat Intelligence Naming Conventions: Threat Actors, & Other Ways of Tracking Threats SANS CTI Summit 2018 - ElasticIntel: Building an Open-Source Threat Intel Aggregation Platform SANS CTI Summit 2017 - Threat Intelligence At Microsoft: A Look Inside SANS CTI Summit 2017 - Keynote by Cliff Stoll - (Still) Stalking the Wily Hacker Decepticon - Deceptive techniques to derail OSINT attempts - Joe Gray - 2018 BSides Tampa 2018 - Advanced Social Engineering and OSINT for Penetration Testing Threat Hunting Summit 2016 - Using Open Tools to Convert Threat Intelligence into Practical Defenses SANS DFIR Summit 2016 - Leveraging Cyber Threat Intelligence in an Active Cyber Defense Derbycon 2016 - Open Source Intelligence What I learned by being an OSINT creeper Cambridge Intelligence 2016 - Smarter Cyber Threat Intelligence with Graphs (EclecticIQ) How to use Threat Intelligence - Black Hills Webcast APT1: Exposing One of China’s Cyber Espionage Units - Mandiant 2013 Cyber Threat Intelligence Starts Here - Anomali - August 2019 MITRE ATT&CK Con talks - Day 1 - 2019 MITRE ATT&CK Con talks - Day 2 - 2019 Easter egg - If you came reading this far, here is a prize for you: a list of global cyber attack maps. These are maintained as a show-off effort from security vendors, and are meant to convey the fact that they do monitor adversarial activities on a global scale. They are just eye candy, but they make quite a scene. Some of them (most of them?) run on fake / old data.

APT reports and articles

A curated collection of reports and articles about APT activities is publicly available.

2008-10-01 - How China Will Use Cyber Warfare (by Jason Fritz) 2008-11-11 - Russian Cyberwar On Georgia (by Georgia Gov) 2009-01-18 - Impact Of Alleged Russian Cyber Attack (by William C. Ashmore) 2009-03-29 - Tracking Ghostnet: Investigating A Cyber Espionage Network (by Information Warfare Monitor) 2010-01-01 - Case Study: Operation Aurora (by Triumfant) 2010-01-13 - The Command Structure Of The Aurora Botnet (by Damballa) 2010-01-20 - Combating Aurora (by McAfee) 2010-01-27 - Operation Aurora: Detect, Diagnose, Respond (by HBGary) 2010-02-10 - Operation Aurora (by HBGary) 2010-02-24 - How Can I Tell If I Was Infected By Aurora? (by McAfee) 2010-03-14 - In-Depth Analysis Of Hydraq: The Face Of Cyberwar Enemies Unfolds (by CA) 2010-04-06 - Shadows In The Cloud: Investigating Cyber Espionage 2.0 (by Shadowserver, Information warfare monitor) 2010-08-24 - Defense official discloses cyberattack (by Washington Post) 2010-09-03 - The Msupdater Trojan And Ongoing Targeted Attacks (by Seculert, Zscaler) 2011-02-01 - W32.Stuxnet Dossier (by Symantec) 2011-02-10 - Global Energy Cyberattacks: Night Dragon (by McAfee) 2011-02-18 - Night Dragon: Specific Protection Measures For Consideration (by NERC) 2011-04-20 - Stuxnet Under The Microscope (by ESET) 2011-06-01 - Advanced Persistent Threats: A Decade In Review (by Command Five Pty Ltd) 2011-08-02 - Operation Shady Rat: Unprecedented Cyber-Espionage Campaign And Intellectual-Property Bonanza (by Vanity Fair) 2011-08-03 - Htran And The Advanced Persistent Threat (by Dell Secureworks) 2011-08-04 - Revealed: Operation Shady Rat (by McAfee) 2011-08-22 - The Lurid Downloader (by Trend Micro) 2011-09-11 - Sk Hack By An Advanced Persistent Threat (by Command Five Pty Ltd) 2011-10-12 - Alleged Apt Intrusion Set: 1.Php Group (by Zscaler, ThreatLabz) 2011-10-26 - Duqu Trojan Questions And Answers (by Dell Secureworks) 2011-10-31 - The Nitro Attacks: Stealing Secrets From The Chemical Industry (by Symantec) 2011-12-08 - Palebot Trojan Harvests Palestinian Online Credentials (by Norman) 2011-12-08 - Cyber-intruder sparks response, debate (by Washington Post) 2011-12-28 - Stuxnet/Duqu: The Evolution Of Drivers (by Kaspersky) 2012-01-03 - The Heartbeat Apt Campaign (by Trend Micro) 2012-02-29 - The Sin Digoo Affair (by Dell Secureworks) 2012-03-12 - Crouching Tiger, Hidden Dragon, Stolen Data (by Contextis) 2012-03-13 - It’S Not The End Of The World: Darkcomet Misses By A Mile (by Arbor Networks) 2012-03-26 - Luckycat Redux: Inside An Apt Campaign With Multiple Targets In India And Japan (by Trend Micro) 2012-04-03 - The Luckycat Hackers (by Symantec) 2012-04-16 - New Version Of Osx.Sabpub & Confirmed Mac Apt Attacks (by Kaspersky) 2012-05-18 - Have I Got Newsforyou: Analysis Of Flamer C&C Server (by Symantec) 2012-05-22 - Ixeshe An Apt Campaign (by Trend Micro) 2012-05-31 - Skywiper (A.K.A. Flame A.K.A. Flamer): A Complex Malware For Targeted Attacks (by CrySyS, BME) 2012-06-13 - Pest Control: Taming The Rats (by Matasano) 2012-07-10 - Recent Observations In Tibet-Related Information Operations: Advanced Social Engineering For The Distribution Of Lurk Malware (by Citizen Lab) 2012-07-25 - From Bahrain With Love: Finfisher Spy Kit Exposed? (by Citizen Lab) 2012-07-27 - The ‘Madi’ Infostealers - A Detailed Analysis (by Kaspersky) 2012-08-09 - Gauss: Abnormal Distribution (by Kaspersky) 2012-08-12 - The Voho Campaign: An In Depth Analysis (by RSA) 2012-08-18 - The Mirage Campaign (by Dell Secureworks) 2012-09-06 - The Elderwood Project (by Symantec) 2012-09-07 - Iexpl0Re Rat (by Citizen Lab) 2012-10-27 - Trojan.Taidoor: Targeting Think Tanks (by Symantec) 2012-11-01 - “Wicked Rose” And The Ncph Hacking Group (by iDefense) 2012-11-01 - Recovering From Shamoon (by Fidelis) 2012-11-03 - Systematic Cyber Attacks Against Israeli And Palestinian Targets Going On For A Year (by Norman) 2012-11-30 - The Many Faces Of Gh0St Rat: Plotting The Connections Between Malware Attacks (by Norman) 2013-01-14 - The “Red October” Campaign - An Advanced Cyber Espionage Network Targeting Diplomatic And Government Agencies (by Kaspersky) 2013-01-14 - “Red October” Diplomatic Cyber Attacks Investigation (by Kaspersky) 2013-01-14 - The Icefog Apt: A Tale Of Cloak And Three Daggers (by Kaspersky) 2013-01-18 - Operation Red October (by McAfee) 2013-02-01 - Operation Beebus (by FireEye) 2013-02-03 - Command And Control In The Fifth Domain (by Command Five Pty Ltd) 2013-02-12 - Targeted Cyber Attacks: Examples And Challenges Ahead (by CrySyS) 2013-02-18 - Apt1 Exposing One Of China’s Cyber Espionage Units (by Mandiant) 2013-02-22 - Comment Crew: Indicators Of Compromise (by Symantec) 2013-02-26 - Stuxnet 0.5: The Missing Link (by Symantec) 2013-02-27 - The Miniduke Mystery: Pdf 0-Day Government Spy Assembler 0X29A Micro Backdoor (by Kaspersky) 2013-02-27 - Miniduke: Indicators (by CrySyS, BME) 2013-03-13 - You Only Click Twice: Finfisher’s Global Proliferation (by Citizen Lab) 2013-03-17 - Safe A Targeted Threat (by Trend Micro) 2013-03-20 - The Teamspy Story - Abusing Teamviewer In Cyberespionage Campaigns (by Kaspersky) 2013-03-20 - Dissecting Operation Troy: Cyberespionage In South Korea (by McAfee) 2013-03-27 - Apt1: Technical Backstage (by Malware.lu, itrust) 2013-03-28 - Analysis Of A Plugx Variant (Plugx Version 7.0) (by CIRCL) 2013-04-01 - Trojan.Apt.Banechant: In-Memory Trojan That Observes For Multiple Mouse Clicks (by FireEye) 2013-04-03 - A Closer Look At Miniduke (by Bitdefender) 2013-04-13 - Winnti: More Than Just A Game (by Kaspersky) 2013-04-17 - The Mutter Backdoor: Operation Beebus with New Targets (by Fireeye) 2013-05-03 - Deep Panda (by Crowdstrike) 2013-05-20 - Operation Hangover - Unveiling An Indian Cyberattack Infrastructure (by Norman, Shadowserver) 2013-05-20 - Operation Hangover |Executive Summary (by Norman) 2013-05-30 - Analysis Of A Stage 3 Miniduke Sample (by CIRCL) 2013-06-01 - The Chinese Malware Complexes: The Maudi Surveillance Operation (by Norman) 2013-06-01 - Crude Faux: An Analysis Of Cyber Conflict Within The Oil & Gas Industries (by CERIAS) 2013-06-04 - The Nettraveler (Aka Travnet) (by Kaspersky) 2013-06-07 - Keyboy, Targeted Attacks Against Vietnam And India (by Rapid7) 2013-06-18 - Trojan.Apt.Seinup Hitting Asean (by FireEye) 2013-06-21 - A Call To Harm: New Malware Attacks Target The Syrian Opposition (by Citizen Lab) 2013-06-28 - Njrat Uncovered (by Fidelis) 2013-07-01 - Hunting The Shadows: In Depth Analysis Of Escalated Apt Attacks (by Xecure, Academia Sinica) 2013-07-09 - Dark Seoul Cyber Attack: Could It Be Worse? (by Dongseo University) 2013-07-15 - The Plugx Malware Revisited: Introducing Smoaler (by Sophos) 2013-07-31 - Secrets Of The Comfoo Masters (by Dell Secureworks) 2013-08-01 - Operation Hangover - Unveiling An Indian Cyberattack Infrastructure (Appendix) (by Norman) 2013-08-01 - Inside Report Apt Attacks On Indian Cyber Space (by Infosec Consortium) 2013-08-02 - Surtr: Malware Family Targeting The Tibetan Community (by Citizen Lab) 2013-08-02 - Where There Is Smoke, There Is Fire: South Asian Cyber Espionage Heats Up (by ThreatConnect) 2013-08-07 - The Little Malware That Could: Detecting And Defeating The China Chopper Web Shell (by FireEye) 2013-08-12 - Survival Of The Fittest: New York Times Attackers Evolve Quickly (by FireEye) 2013-08-19 - Byebye Shell And The Targeting Of Pakistan (by Rapid7) 2013-08-21 - Poison Ivy: Assessing Damage And Extracting Intelligence (by FireEye) 2013-08-23 - Operation Molerats (by FireEye) 2013-09-10 - Operation Ephemeral Hydra: Ie Zero-Day Linked To Deputydog Uses Diskless Method (by FireEye) 2013-09-11 - The “Kimsuky” Operation: A North Korean Apt? (by Kaspersky) 2013-09-13 - Operation Deputydog: Zero-Day (Cve-2013-3893) Attack Against Japanese Targets (by FireEye) 2013-09-17 - Hidden Lynx: Professional Hackers For Hire (by Symantec) 2013-09-19 - 2Q Report On Targeted Attack Campaigns (by Trend Micro) 2013-09-30 - World War C: Understanding Nation-State Motives Behind Today’s Advanced Cyber Attacks (by FireEye) 2013-10-24 - Fakem Rat: Malware Disguised As Windows Messenger And Yahoo! Messenger (by Trend Micro) 2013-10-24 - Evasive Tactics: Terminator Rat (by FireEye) 2013-11-11 - Supply Chain Analysis: From Quartermaster To Sunshopfireeye (by FireEye) 2013-12-02 - “Njrat”, The Saga Continues (by Fidelis) 2013-12-11 - Operation Ke3Chang Targeted Attacks Against Ministries Of Foreign Affairs (by FireEye) 2013-12-20 - Etso Apt Attacks Analysis (by AhnLab) 2013-12-31 - Energy At Risk: A Study Of It Security In The Energy And Natural Resources Industry (by KPMG) 2014-01-13 - Targeted Attacks Against The Energy Sector (by Symantec) 2014-01-15 - New Cdto: A Sneakernet Trojan Solution (by Fidelis) 2014-01-21 - Emerging Threat Profile Shell_Crew (by RSA) 2014-01-31 - Intruder File Report- Sneakernet Trojan (by Fidelis) 2014-02-11 - Unveiling Careto - The Masked Apt (by Kaspersky) 2014-02-13 - Operation Snowman: Deputydog Actor Compromises Us Veterans Of Foreign Wars Website (by FireEye) 2014-02-19 - Xtremerat: Nuisance Or Threat? (by FireEye) 2014-02-19 - The Monju Incident (by Context) 2014-02-20 - Operation Greedywonk: Multiple Economic And Foreign Policy Sites Compromised, Serving Up Flash Zero-Day Exploit (by FireEye) 2014-02-20 - Mo’ Shells Mo’ Problems - Deep Panda Web Shells (by Crowdstrike) 2014-02-23 - Gathering In The Middle East, Operation Stteam (by Fidelis) 2014-02-25 - The French Connection: French Aerospace-Focused CVE-2014-0322 Attack Shares Similarities with 2012 Capstone Turbine Activity (by Crowdstrike) 2014-02-28 - Uroburos Highly Complex Espionage Software With Russian Roots (by Gdata) 2014-03-06 - The Siesta Campaign: A New Cybercrime Operation Awakens (by Trend Micro) 2014-03-07 - Snake Campaign & Cyber Espionage Toolkit (by BAE Systems) 2014-03-08 - Suspected Russian Spyware Turla Targets Europe, United States (by Reuters) 2014-04-26 - New Zero-Day Exploit Targeting Internet Explorer Versions 9 Through 11 Identified In Targeted Attacks (by FireEye) 2014-05-13 - Operation Saffron Rose (by FireEye) 2014-05-13 - Cat Scratch Fever: Crowdstrike Tracks Newly Reported Iranian Actor As Flying Kitten (by Crowdstrike) 2014-05-20 - Miniduke Still Duking It Out (by ESET) 2014-05-21 - Rat In A Jar: A Phishing Campaign Using Unrecom (by Fidelis) 2014-06-06 - Illuminating The Etumbot Apt Backdoor (by Arbor Networks) 2014-06-09 - Putter Panda (by Crowdstrike) 2014-06-10 - Anatomy Of The Attack: Zombie Zero (by Trapx) 2014-06-10 - Snake In The Grass: Python-based Malware Used For Targeted Attacks (by Bluecoat) 2014-06-20 - #9 Blitzanalysis: Embassy Of Greece Beijing - Compromise (by R136a1) 2014-06-30 - Dragonfly: Cyberespionage Attacks Against Energy Suppliers (by Symantec) 2014-07-10 - Tr-25 Analysis - Turla / PNet / Snake/ Uroburos (by CIRCL) 2014-07-11 - The Eye Of The Tiger (Pitty Tiger) (by Airbus) 2014-07-20 - Sayad (Flying Kitten) Infostealer: Is This The Work Of The Iranian Ajax Security Team? (by Vinsula) 2014-07-31 - Crouching Yeti: Appendixes (by Kaspersky) 2014-07-31 - Energetic Bear _Crouching Yeti (by Kaspersky) 2014-08-01 - Syrian Malware, The Ever-Evolving Threat (by Kaspersky) 2014-08-04 - Gholee Protective Edge Themed Spear Phishing Campaign (by Clearsky) 2014-08-04 - Sidewinder Targeted Attack Against Android In The Golden Age Of Ad Libraries (by FireEye) 2014-08-05 - Operation Arachnophobia Caught In The Spider’s Web (by ThreatConnect) 2014-08-06 - Operation Poisoned Hurricane (by FireEye) 2014-08-07 - The Epic Turla Operation: Solving Some Of The Mysteries Of Snake/Uroboros (by Kaspersky) 2014-08-20 - El Machete (by Kaspersky) 2014-08-27 - Nettraveler Apt Gets A Makeover For 10Th Birthday (by Kaspersky) 2014-08-27 - Profiling An Enigma: The Mystery Of North Korea’s Cyber Threat Landscape (by HP) 2014-08-28 - Scanbox: A Reconnaissance Framework Used With Watering Hole Attacks (by Alienvault) 2014-08-29 - Connecting The Dots: Syrian Malware Team Uses Blackworm For Attacks (by FireEye) 2014-09-03 - Darwin’s Favorite Apt Group (by FireEye) 2014-09-04 - Forced To Adapt: Xslcmd Backdoor Now On Os X (by FireEye) 2014-09-04 - Analysis Of Chinese Mitm On Google (by Netresec) 2014-09-08 - When Governments Hack Opponents: A Look At Actors And Technology (by Usenix Conference) 2014-09-08 - Targeted Threat Index: Characterizing And Quantifying Politically-Motivated Targeted Malware (by Usenix Conference) 2014-09-10 - Operation Quantum Entanglement (by FireEye) 2014-09-18 - Cosmicduke Cosmu With A Twist Of Miniduke (by F-Secure) 2014-09-19 - Recent Watering Hole Attacks Attributed To Apt Group Th3Bug Using Poison Ivy (by Palo Alto) 2014-09-26 - Blackenergy & Quedagh: The Convergence Of Crimeware And Apt Attacks (by F-Secure) 2014-09-26 - Aided Frame, Aided Direction (Because It’s A Redirect) (by FireEye) 2014-10-03 - New Indicators Of Compromise For Apt Group Nitro Uncovered (by Palo Alto) 2014-10-09 - Democracy In Hong Kong Under Attack (by Volexity) 2014-10-14 - Zoxpng Analysis (by Novetta) 2014-10-14 - Russian Cyber Espionage Campaign - Sandworm Team (by iSight Partners) 2014-10-14 - Hikit Analysis (by Novetta) 2014-10-14 - Threat Spotlight: Group 72 (by Cisco) 2014-10-20 - Orcarat - A Whale Of A Tale (by PWC) 2014-10-22 - Tactical Intelligence Bulletin Sofacy Phishing (by PWC) 2014-10-23 - Operation Pawn Storm Using Decoys To Evade Detection (by Trend Micro) 2014-10-23 - Modified Binaries Tor (by Joshua Pitts) 2014-10-24 - Leouncia And Orcarat (by Airbus) 2014-10-24 - Operation SMN (by Novetta) 2014-10-27 - Scanbox Framework: Who’s Affected, And Who’s Using It? (by PWC) 2014-10-27 - Micro-Targeted Malvertising Via Real-Time Ad Bidding (by Invincea) 2014-10-27 - Full Disclosure Of Havex Trojans (by Netresec) 2014-10-28 - Threat Spotlight: Group 72, Opening The Zxshell (by Cisco) 2014-10-28 - Apt28: A Window Into Russia’s Cyber Espionage Operations (by FireEye) 2014-10-30 - The Rotten Tomato Campaign (by Sophos) 2014-10-31 - Operation Toohash How Targeted Attacks Work (by Gdata) 2014-11-03 - Operation Poisoned Handover: Unveiling Ties Between Apt Activity In Hong Kong’s Pro-Democracy Movement (by FireEye) 2014-11-03 - Be2 Custom Plugins, Router Abuse, And Target Profiles (by Kaspersky) 2014-11-10 - Darkhotel Indicators Of Compromise (by Kaspersky) 2014-11-10 - The Darkhotel Apt A Story Of Unusual Hospitality v1.0 (by Kaspersky) 2014-11-10 - The Darkhotel APT A Story of Unusual Hospitality v1.1 (by Kaspersky) 2014-11-11 - The Uroburos Case: New Sophisticated Rat Identified (by Gdata) 2014-11-12 - Korplug Military Targeted Attacks: Afghanistan & Tajikistan (by ESET) 2014-11-13 - Operation Cloudyomega: Ichitaro Zero-Day And Ongoing Cyberespionage Campaign Targeting Japan (by Symantec) 2014-11-14 - Roaming Tiger (by ESET) 2014-11-14 - Onionduke: Apt Attacks Via The Tor Network - F-Secure Weblog : News From The Lab (by F-Secure) 2014-11-14 - Derusbi (Server Variant) Analysis (by Novetta) 2014-11-20 - Evil Bunny: Suspect #4 (by Marion Marschalek) 2014-11-21 - Operation Double Tap (by FireEye) 2014-11-23 - Regin: Top-Tier Espionage Tool Enables Stealthy Surveillance (by Symantec) 2014-11-24 - Secret Malware In European Union Attack Linked To U.S. And British Intelligence (by The Intercept) 2014-11-24 - The Regin Platform Nation-State Ownership Of Gsm Networks (by Kaspersky) 2014-11-24 - I Am Ironman: Deep Panda Uses Sakula Malware To Target Organizations In Multiple Sectors (by Crowdstrike) 2014-12-01 - Hacking The Street? Fin4 Likely Playing The Market (by FireEye) 2014-12-03 - Operation Cleaver: The Notepad Files (by Cylance) 2014-12-08 - The ‘Penquin’ Turla (by Kaspersky) 2014-12-09 - The Inception Framework: Cloud-Hosted Apt (by Bluecoat) 2014-12-10 - W64/Regin, Stage #1 (by F-Secure) 2014-12-10 - W32/Regin, Stage #1 (by F-Secure) 2014-12-10 - Vulnerability, Malicious Code Appeared In The Mbr Destruction Function Using Hangul File (by AhnLab) 2014-12-10 - Cloud Atlas: Redoctober Apt Is Back In Style (by Kaspersky) 2014-12-12 - Vinself Now With Steganography (by Airbus) 2014-12-12 - Bots, Machines, And The Matrix (by Fidelis) 2014-12-17 - Wiper Malware A Detection Deep Dive (by Cisco) 2014-12-18 - Malware Attack Targeting Syrian Isis Critics (by Citizen Lab, Cyber Arabs) 2014-12-19 - Alert (Ta14-353A) Targeted Destructive Malware (by US-CERT) 2014-12-21 - Operation Poisoned Helmand (by ThreatConnect) 2014-12-22 - Anunak: Apt Against Financial Institutions (by Group-IB, FOX-IT) 2015-01-12 - Skeleton Key Malware Analysis (by Dell Secureworks) 2015-01-12 - Insight In To A Strategic Web Compromise And Attack Campaign Against Hong Kong Infrastructure (by Dragon Threat Labs) 2015-01-15 - Evolution Of Sophisticated Spyware: From Agent.Btz To Comrat (by Gdata) 2015-01-20 - Analysis Of Project Cobra (by Gdata) 2015-01-20 - Reversing The Inception APT Malware (by Bluecoat) 2015-01-22 - The Waterbug Attack Group (by Symantec) 2015-01-22 - Scarab Attackers Took Aim At Select Russian Targets Since 2012 (by Symantec) 2015-01-22 - An Analysis Of Regin’s Hopscotch And Legspin (by Kaspersky) 2015-01-29 - Analysis Of A Recent Plugx Variant - P2P Plugx (by JPCERT) 2015-01-29 - Backdoor.Winnti Attackers Have A Skeleton In Their Closet? (by Symantec) 2015-02-02 - Behind The Syrian Conflict’s Digital Front Lines (by FireEye) 2015-02-04 - Pawn Storm Update: Ios Espionage App Found (by Trend Micro) 2015-02-10 - Global Threat Intel Report (by Crowdstrike) 2015-02-16 - Operation Arid Viper: Bypassing The Iron Dome (by Trend Micro) 2015-02-16 - Equation Group: Questions And Answers (by Kaspersky) 2015-02-16 - Carbanak APT The Great Bank Robbery (by Kaspersky) 2015-02-17 - The Desert Falcons Targeted Attacks (by Kaspersky) 2015-02-18 - Shooting Elephants (by Netzpolitik) 2015-02-24 - Scanbox Ii (by PWC) 2015-02-25 - Southeast Asia: An Evolving Cyber Threat Landscape (by FireEye, Singtel) 2015-02-25 - Plugx Goes To The Registry (And India) (by Sophos) 2015-02-27 - The Anthem Hack: All Roads Lead To China (by ThreatConnect) 2015-03-10 - Tibetan Uprising Day Malware Attacks (by Citizen Lab) 2015-03-11 - Inside The Equationdrug Espionage Platform (by Kaspersky) 2015-03-19 - Operation Woolen-Goldfish When Kittens Go Phishing (by Trend Micro) 2015-03-31 - Volatile Cedar Threat Intelligence And Research (by Checkpoint) 2015-04-07 - WINNTI Analysis (by Novetta) 2015-04-08 - RSA Incident Response: An APT Case Study (by RSA) 2015-04-12 - APT30 And The Mechanics Of A Long-Running Cyber Espionage Operation (by FireEye) 2015-04-15 - The Chronicles Of The Hellsing APT: The Empire Strikes Back (by Kaspersky) 2015-04-15 - Hellsing Indicators Of Compromise (by Kaspersky) 2015-04-18 - Operation Russiandoll: Adobe & Windows ZeroDay Exploits Likely leveraged By Russia’s APT28 (by FireEye) 2015-04-20 - Sofacy II_Same Sofacy, Different Day (by PWC) 2015-04-21 - The Cozyduke APT (by Kaspersky) 2015-04-22 - Cozyduke (by F-Secure) 2015-04-26 - Operation Clandestine Wolf_ Adobe Flash Zero-Day In APT3 Phishing Campaign (by FireEye) 2015-04-27 - Attacks Against Israeli & Palestinian Interests (by PWC) 2015-05-05 - Targeted Attack on France’s TV5Monde (by Ahnlab) 2015-05-07 - Dissecting The Kraken (by Gdata) 2015-05-10 - APT28 Targets Financial Markets: Zero Day Hashes Released (by root9b) 2015-05-13 - Cylance Spear Team: A Threat Actor Resurfaces (by Cylance) 2015-05-14 - Operation Tropic Trooper: Relying On Tried-And-Tested Flaws To Infiltrate Secret Keepers (by Trend Micro) 2015-05-18 - Cmstar Downloader: Lurid And Enfal’s New Cousin (by Palo Alto) 2015-05-19 - Operation Oil Tanker: The Phantom Menace (by Pandalabs) 2015-05-21 - The Msnmm Campaigns: The Earliest Naikon APT Campaigns (by Kaspersky) 2015-05-26 - Dissecting Linux/Moose: The Analysis Of A Linux Router-Based Worm Hungry For Social Networks (by ESET) 2015-05-27 - Analysis On APT-To-Be Attack That Focusing On China’s Government Agency (by Antiy CERT) 2015-05-28 - Grabit And The Rats (by Kaspersky) 2015-05-29 - Oceanlotus (by SkyEye) 2015-06-03 - An Iranian Cyber-Attack Campaign Against Targets In The Middle East (by Clearsky) 2015-06-04 - Blue Termite (Internet Watch) (by Kaspersky) 2015-06-10 - Duqu 2.0: A Comparison To Duqu (by CrySyS Lab) 2015-06-10 - Duqu 2.0: Reemergence of an aggressive cyberespionage threat (by Symantec) 2015-06-11 - The Duqu 2.0 Technical Details (by Kaspersky) 2015-06-15 - The Naikon APT: Tracking Down Geo-Political Intelligence Across APAC, One Nation At A Time (by Kaspersky) 2015-06-15 - Target Attacks Against Tibetan And Hong Kong Groups Exploiting CVE-2014-4114 (by Citizen Lab) 2015-06-16 - Operation Lotusblossom (by Palo Alto) 2015-06-22 - Games Are Over: Winnti Is Now Targeting Pharmaceutical Companies (by Kaspersky) 2015-06-24 - Unfin4Ished Business (by PWC) 2015-06-30 - Dino: The Latest Spying Malware From An Allegedly French Espionage Group Analyzed (by ESET) 2015-07-08 - Wild Neutron _ Economic Espionage Threat Actor Returns With New Tricks (by Kaspersky) 2015-07-09 - Butterfly: Corporate Spies Out For Financial Gain (by Symantec) 2015-07-13 - “Forkmeiamfamous”: Seaduke, Latest Weapon In The Duke Armory (by Symantec) 2015-07-14 - Tracking Minidionis: Cozycar’s New Ride Is Related To Seaduke (by Palo Alto) 2015-07-20 - Watering Hole Attack On Aerospace Firm Exploits CVE-2015-5122 To Install Isspace Backdoor (by Palo Alto) 2015-07-20 - China Hacks The Peace Palace: All Your Eez’s Are Belong To Us (by ThreatConnect) 2015-07-22 - Duke APT Group’s Latest Tools: Cloud Services And Linux Support (by F-Secure) 2015-07-27 - Hammertoss: Stealthy Tactics Define A Russian Cyber Threat Group (by FireEye) 2015-07-28 - The Black Vine Cyberespionage Group (by Symantec) 2015-07-31 - Operation Potao Express: Analysis Of A Cyber-Espionage Toolkit (by ESET) 2015-08-03 - Cyber war in perspective: Russian aggression against Ukraine (by NATO) 2015-08-04 - RSA Research Terracotta VPN: Enabler Of Advanced Threat Anonymity (by RSA) 2015-08-05 - Threat Group-3390 Targets Organizations For Cyberespionage (by Dell Secureworks) 2015-08-10 - Darkhotel’s attacks in 2015 (by Kaspersky) 2015-09-08 - Carbanak is packing new guns (by ESET) 2015-09-17 - THE DUKES: 7 years of Russian cyberespionage (by F-Secure) 2015-10-07 - Hacker Group Creates Network of Fake LinkedIn Profiles (by Secureworks) 2015-10-15 - Pay No Attention to the Server Behind the Proxy: Mapping FinFisher’s Continuing Proliferation (by Citizen Lab) 2015-11-09 - Rocket Kitten: A Campaign With 9 Lives (by Checkpoint) 2015-11-16 - Microsoft Security Intelligence Report (Volume 19) (by Microsoft) 2015-11-23 - PEERING INTO GLASSRAT: A Zero Detection Trojan from China (by RSA) 2015-12-07 - Iran-based attackers use back door threats to spy on Middle Eastern targets (by Symantec) 2015-12-10 - Evolution of Cyber Threats in the Corporate Sector (by Kaspersky) 2015-12-16 - Dissecting the Malware Involved in the INOCNATION Campaign (by Fidelis) 2015-12-22 - BBSRAT Attacks Targeting Russian Organizations Linked to Roaming Tiger (by Palo Alto) 2015-12-23 - ELISE: Security Through Obesity (by PWC) 2016-01-03 - BlackEnergy by the SSHBearDoor: attacks against Ukrainian news media and electric industry (by ESET) 2016-01-07 - Operation Dusty Sky (by Clearsky) 2016-01-07 - Operation Dusty Sky (indicators) (by Clearsky) 2016-01-11 - Uncovering the Seven Pointed Dagger (by Arbor Networks) 2016-01-14 - RESEARCH SPOTLIGHT: NEEDLES IN A HAYSTACK (by Cisco) 2016-01-20 - New wave of cyberattacks against Ukrainian power industry (by ESET) 2016-01-24 - Scarlet Mimic (by Palo Alto) 2016-01-28 - BlackEnergy APT Attacks in Ukraine employ spearphishing with Word documents (by Kaspersky) 2016-02-03 - Emissary Trojan Changelog: Did Operation Lotus Blossom Cause It To Evolve (by Palo Alto) 2016-02-04 - T9000: Advanced Modular Backdoor Uses Complex Anti Analysis Techniques (by Palo Alto) 2016-02-08 - Attack On French Diplomat Linked To Operation Lotus Blossom (by Palo Alto) 2016-02-08 - Know Your Enemies 2.0: A Primer on Advanced Persistent Threat Groups (by ICIT) 2016-02-09 - Poseidon Group (by Kaspersky) 2016-02-12 - A Look Into Fysbis: Sofacy’s Linux Backdoor (by Palo Alto) 2016-02-23 - Operation Duststorm (by Cylance) 2016-02-24 - Operation Blockbuster (by Novetta) 2016-02-24 - FROM SEOUL TO SONY: THE HISTORY OF THE DARKSEOUL GROUP AND THE SONY INTRUSION MALWARE DESTOVER (by Bluecoat) 2016-03-01 - Operation Transparent Tribe (by Proofpoint) 2016-03-10 - Shifting Tactics Tracking Changes In Years Long Espionage Campaign Against Tibetans (by Citizen Lab) 2016-03-15 - Suckfly: Revealing the secret life of your code signing certificates (by Symantec) 2016-03-17 - Taiwan Presidential Election: A Case Study on Thematic Targeting (by PWC) 2016-03-29 - Taiwan targeted with new cyberespionage back door Trojan (by Symantec) 2016-04-13 - The Four Element Sword Engagement (by Arbor) 2016-04-18 - Between Hong Kong and Burma: Tracking UP007 and SLServer Espionage Campaign (by Citizen Lab) 2016-04-21 - Looking Into a Cyber-Attack Facilitator in the Netherlands (by Trend Micro) 2016-04-21 - Looking Into a Cyber-Attack Facilitator in the Netherlands (Appendix) (by Trend Micro) 2016-04-22 - The Ghost Dragon (by Cylance) 2016-04-25 - Two Bytes to $951M (by BAE Systems) 2016-04-26 - PLATINUM Targeted attacks in South and Southeast Asia (by Microsoft) 2016-05-02 - Turbo Twist: Two 64-bit Derusbi Strains Converge (by Fidelis) 2016-05-02 - Prince of Persia: Infy Malware Active In Decade of Targeted Attacks (by Palo Alto) 2016-05-06 - Exploring CVE-2015-2545 and its users (by PWC) 2016-05-17 - Mofang: A politically motivated information stealing adversary (by Fox-IT) 2016-05-17 - Operation Groundbait:Analysis of a surveillance toolkit (by ESET) 2016-05-17 - Indian organizations targeted in Suckfly attacks (by Symantec) 2016-05-18 - Operation C-Major Actors Also Used Android BlackBerry Mobile Spyware Against Targets (by Trend Micro) 2016-05-23 - Targeted Attacks against Banks in the Middle East (by FireEye) 2016-05-23 - APT Case RUAG Technical Report (by GovCERT.ch) 2016-05-23 - Operation Ke3chang Resurfaces With New TidePool Malware (by Palo Alto) 2016-05-24 - New Wekby Attacks Use DNS Requests As Command and Control Mechanism (by Palo Alto) 2016-05-25 - CVE-2015-2545: overview of current threats (by Kaspersky) 2016-05-26 - SWIFT attackers’ malware linked to more financial attacks (by Symantec) 2016-05-27 - IXESHE Derivative IHEATE Targets Users in America (by Trend Micro) 2016-05-29 - Stealth Falcon (by Citizen Lab) 2016-06-02 - IRONGATE ICS Malware: Nothing to See Here…Masking Malicious Activity on SCADA Systems (by FireEye) 2016-06-03 - APT Group Sends Spear Phishing Emails to Indian Government Officials (by FireEye) 2016-06-03 - Apt Group Sends Spear Phishing Emails To Indian Government Officials (by FireEye) 2016-06-04 - Bears in the Midst: Intrusion into the Democratic National Committee (by Crowdstrike) 2016-06-09 - Operation DustySky Part 2 (by Clearsky) 2016-06-09 - Operation DustySky Part 2 Indicators (by Clearsky) 2016-06-09 - Reverse-engineering DUBNIUM (by Microsoft) 2016-06-14 - New Sofacy Attacks Against US Government Agency (by Palo Alto) 2016-06-14 - Group5: Syria and the Iranian Connection (by Citizen Lab) 2016-06-16 - Threat Group-4127 Targets Hillary Clinton Presidential Campaign (by Secureworks) 2016-06-16 - Threat Group 4127 Targets Hillary Clinton Presidential Campaign (by Dell Secureworks) 2016-06-17 - Flash zero-day exploit deployed by the ScarCruft APT Group (by Kaspersky) 2016-06-17 - Operation Daybreak (by Kaspersky) 2016-06-20 - Reverse-engineering DUBNIUM’s Flash-targeting exploit (by Microsoft) 2016-06-20 - Findings from Analysis of DNC Intrusion Malware (by Fidelis) 2016-06-20 - Red Line Drawn: China Recalculates Its Use Of Cyber Espionage (by FireEye) 2016-06-21 - Visiting The Bear Den A Journey in the Land of (Cyber-)Espionage (by ESET) 2016-06-23 - Tracking Elirks Variants in Japan: Similarities to Previous Attacks (by Palo Alto) 2016-06-26 - Threat Group-4127 Targets Google Accounts (by Secureworks) 2016-06-28 - Prince of Persia Game Over (by Palo Alto) 2016-06-30 - Asruex: Malware Infecting through Shortcut Files (by JPCERT) 2016-07-01 - Pacifier APT (by Bitdefender) 2016-07-01 - Espionage toolkit targeting Central and Eastern Europe uncovered (by ESET) 2016-07-07 - Unveiling Patchwork the Copy Paste APT (by Cymmetria) 2016-07-07 - NetTraveler APT Targets Russian, European Interests (by ProofPoint) 2016-07-08 - The Dropping Elephant - aggressive cyber-espionage in the Asian region (by Kaspersky) 2016-07-25 - Patchwork cyberespionage group expands targets from governments to wide range of industries (by Symantec) 2016-08-03 - Operation Manul (by EFF) 2016-08-06 - Moonsoon - Analysis of an APT Campaign (by Forcepoint) 2016-08-07 - Strider: Cyberespionage group turns eye of Sauron on targets (by Symantec) 2016-08-08 - The ProjectSauron APT (by Kaspersky) 2016-08-08 - Carbanak Oracle Breach (by Visa) 2016-08-13 - Visa Alert and Update on the Oracle Breach (by Brian Krebs) 2016-08-24 - The Million Dollar Dissident: NSO Group’s iPhone Zero-Days used against a UAE Human Rights Defender (by Citizen Lab) 2016-09-06 - Buckeye cyberespionage group shifts gaze from US to Hong Kong (by Symantec) 2016-09-18 - Hunting Libyan Scorpions (by Cyberkov Security) 2016-09-26 - Sofacy’s Komplex OS X Trojan (by Palo Alto) 2016-09-28 - Belling the BEAR (by ThreatConnect) 2016-10-03 - On the StrongPity Waterhole Attacks Targeting Italian and Belgian Encryption Users (by Kaspersky) 2016-10-05 - Wave your false flags! Deception tactics muddying attribution in targeted attacks (by Kaspersky) 2016-10-05 - Apt Reports And Opsec Evolution, Or: These Are Not The Apt Reports You Are Looking For (by Virus Bulletin) 2016-10-20 - En Route with Sednit Part 1: Approaching the Target (by ESET) 2016-10-25 - En Route with Sednit Part 2: Observing the Comings and Goings (by ESET) 2016-10-25 - Houdini’s Magic Reappearance (by Palo Alto Networks) 2016-10-26 - Moonlight - Targeted attacks in the Middle East (by Vectra Networks) 2016-10-26 - BITTER: A Targeted attack against Pakistan (by Forcepoint) 2016-10-27 - En Route with Sednit Part 3: A Mysterious Downloader (by ESET) 2016-10-27 - BLACKGEAR Espionage Campaign Evolves, Adds Japan To Target List (by Trend Micro) 2016-11-03 - When The Lights Went Out: Ukraine Cybersecurity Threat Briefing (by Booz Allen) 2016-11-09 - PowerDuke: Widespread Post-Election Spear Phishing Campaigns Targeting Think Tanks and NGOs (by Volexity) 2016-11-14 - New Carbanak / Anunak Attack Methodology (by Trustwave) 2016-11-17 - It’s Parliamentary: KeyBoy and the targeting of the Tibetan Community (by Citizen Lab) 2016-11-30 - Malware Actors Using Nic Cyber Security Themed Spear Phishing To Target Indian Government Organizations (by Cysinfo) 2016-12-14 - PROMETHIUM and NEODYMIUM: Parallel zero-day attacks targeting individuals in Europe (by Microsoft) 2016-12-15 - Let It Ride: The Sofacy Group’s DealersChoice Attacks Continue (by Palo Alto Networks) 2016-12-21 - Danger Close: Fancy Bear Tracking of Ukrainian Field Artillery Units (by Crowdstrike) 2016-12-22 - Use of Fancy Bear Android Malware tracking of Ukrainian Artillery Units (by Crowdstrike) 2016-12-28 - Bear Hunting Season: Tracking APT28 (by tr1adx) 2016-12-29 - GRIZZLY STEPPE - Russian Malicious Cyber Activity (by US-CERT) 2017-01-01 - The Digital Plagiarist Campaign: TelePorting the Carbanak Crew to a New Dimension (by tr1adx) 2017-01-05 - Iranian Threat Agent OilRig Delivers Digitally Signed Malware, Impersonates University of Oxford (by Clearsky) 2017-01-05 - DragonOK Updates Toolset and Targets Multiple Geographic Regions (by Palo Alto Networks) 2017-01-05 - Mm Core In-Memory Backdoor Returns As Bigboss And Sillygoose (by Forcepoint) 2017-01-05 - Foreign Cyber Threats to the United States (by US Senate Committee on Armed Services) 2017-01-11 - At the Center of the Storm: Russia’s APT28 Strategically Evolves its Cyber Operations (by FireEye) 2017-01-14 - A Pretty Dope Story About Bears: Early Indicators of Continued World Anti-Doping Agency (WADA) Targeting (by tr1adx) 2017-01-15 - Bear Spotting Vol. 1: Russian Nation State Targeting of Government and Military Interests (by tr1adx) 2017-01-19 - URI Terror Attack & Kashmir Protest Themed Spear Phishing Emails Targeting Indian Embassies And Indian Ministry Of External Affairs (by Cysinfo) 2017-02-02 - Nile Phish: Large-Scale Phishing Campaign Targeting Egyptian Civil Society (by Citizen Lab) 2017-02-03 - Several Polish banks hacked, information stolen by unknown attackers (by Badcyber) 2017-02-03 - KingSlayer A Supply chain attack (by RSA) 2017-02-10 - Enhanced Analysis of GRIZZLY STEPPE Activity (by US-CERT) 2017-02-10 - Cyber Attack Targeting Indian Navy’s Submarine And Warship Manufacturer (by Cysinfo) 2017-02-12 - Lazarus & Watering-Hole Attacks (by BAE Systems) 2017-02-15 - Magic Hound Campaign Attacks Saudi Targets (by Palo Alto Networks) 2017-02-15 - Iranian PupyRAT Bites Middle Eastern Organizations (by Secureworks) 2017-02-15 - The Full Shamoon: How the Devastating Malware Was Inserted Into Networks (by IBM) 2017-02-15 - Operation Bugdrop: Cyberx Discovers Large-Scale Cyber-Reconnaissance Operation Targeting Ukrainian Organizations (by CyberX) 2017-02-16 - ViperRAT: The mobile APT targeting the Israeli Defense Force that should be on your radar (by Lookout) 2017-02-16 - Breaking The Weakest Link Of The Strongest Chain (by Kaspersky) 2017-02-17 - ChChes - Malware that Communicates with C&C Servers Using Cookie Headers (by JPCERT) 2017-02-20 - Lazarus’ False Flag Malware (by BAE Systems) 2017-02-21 - Additional Insights on Shamoon2 (by Arbor Networks) 2017-02-22 - Spear Phishing Techniques Used in Attacks Targeting the Mongolian Government (by FireEye) 2017-02-23 - Dissecting the APT28 Mac OS X Payload (by Bitdefender) 2017-02-27 - The Gamaredon Group Toolset Evolution (by Palo Alto Networks) 2017-02-27 - The Deception Project: A New Japanese-Centric Threat (by Cylance) 2017-03-06 - From Shamoon to StoneDrill (by Kaspersky) 2017-03-07 - FIN7 Spear Phishing Campaign Targets Personnel Involved in SEC Filings (by FireEye) 2017-03-14 - Operation Electric Powder - Who is targeting Israel Electric Company? (by Clearsky) 2017-03-27 - APT29 Domain Fronting With TOR (by FireEye) 2017-03-28 - Dimnie: Hiding in Plain Sight (by Palo Alto Networks) 2017-03-30 - Carbon Paper: Peering into Turla second stage backdoor (by ESET) 2017-04-03 - Operation Cloud Hopper (by PWC) 2017-04-03 - Lazarus Under The Hood (by Kaspersky) 2017-04-07 - The Blockbuster Sequel (by Palo Alto Networks) 2017-04-10 - Longhorn: Tools used by cyberespionage group (by Symantec) 2017-04-27 - APT Targets Financial Analysts with CVE-2017-0199 (by Proofpoint) 2017-05-11 - Cyber Attack Impersonating Identity Of Indian Think Tank To Target Central Bureau Of Investigation (cbi) And Possibly Indian Army Officials (by Cysinfo) 2017-05-14 - Cyber Espionage is Alive and Well: APT32 and the Threat to Global Corporations (by FireEye) 2017-05-17 - Recorded Future Research Concludes Chinese Ministry of State Security Behind APT3 (by Recorded Future) 2017-05-24 - Operation Cobalt Kitty: A large-scale APT in Asia carried out by the OceanLotus Group (by Cybereason) 2017-05-24 - Operation Cobalt Kitty Threat Actor Profile & IOC (by Cybereason) 2017-05-25 - TAINTED LEAKS Disinformation and Phishing With a Russian Nexus (by Citizen Lab) 2017-06-06 - Privileges and Credentials: Phished at the Request of Counsel (by FireEye) 2017-06-07 - PLATINUM continues to evolve, find ways to maintain invisibility (by Microsoft) 2017-06-12 - WIN32/INDUSTROYER A new threat for industrial control systems (by ESET) 2017-06-12 - CRASHOVERRIDE Analysis of the Threat to Electric Grid Operations (by Dragos) 2017-06-14 - KASPERAGENT Malware Campaign resurfaces in May Election (by ThreatConnect) 2017-06-15 - North Korea Is Not Crazy (by Recorded Future) 2017-06-23 - Bronze Butler (by Dell Secureworks) 2017-06-30 - From BlackEnergy to ExPetr (by Kaspersky) 2017-06-30 - TeleBots are back: supply-chain attacks against Ukraine (by ESET) 2017-07-05 - An intrusion campaign targeting Chinese language news sites (by Citizen Lab) 2017-07-18 - Inexsmar: An unusual DarkHotel campaig (by Bitdefender) 2017-07-18 - Cyberattacks Against Ukrainian ICS (by Sentryo) 2017-07-25 - Operation Wilted Tulip (by Clearsky) 2017-07-27 - ChessMaster Makes its Move: A Look into the Campaign’s Cyberespionage Arsenal (by Trend Micro) 2017-08-18 - Russian Bank Offices Hit with Broad Phishing Wave (by RSA) 2017-08-30 - Introducing WhiteBear (by Kaspersky) 2017-08-30 - Gazing at Gazer (by ESET) 2017-09-06 - Dragonfly: Western energy sector targeted by sophisticated attack group (by Symantec) 2017-09-12 - CVE-2017-8759: Zero-Day Used in the Wild to Distribute FINSPY (by FireEye) 2017-09-20 - Evidence Aurora Operation Still Active: Supply Chain Attack Through CCleaner (by Intezer) 2017-09-28 - Threat Actors Target Government of Belarus Using CMSTAR Trojan (by Palo Alto Networks) 2017-10-02 - Evidence Aurora Operation Still Active: Supply Chain Attack Through CCleaner part2 (by Intezer) 2017-10-16 - Taiwan Heist: Lazarus Tools And Ransomware (by BAE Systems) 2017-10-16 - BlackOasis APT and new targeted attacks leveraging zero-day exploit (by Kaspersky) 2017-10-22 - Cyber Conflict Decoy Document Used In Real Cyber Conflict (by Cisco) 2017-10-24 - Iranian Threat Agent Greenbug Impersonates Israeli High-Tech and Cyber Security Companies (by Clearsky) 2017-10-26 - Remote Control Interloper: Analyzing New Chinese htpRAT Attacks Against ASEAN (by RiskIQ) 2017-10-27 - Tracking Subaat: Targeted Phishing Attack Leads to Threat Actor’s Repository (by Palo Alto Networks) 2017-10-27 - Investigation: WannaCry cyber attack and the NHS (by NAO UK) 2017-11-02 - The KeyBoys are back in town (by PWC) 2017-11-06 - ChessMaster’s New Strategy: Evolving Tools and Tactics (by Trend Micro) 2017-11-06 - OceanLotus Blossoms: Mass Digital Surveillance and Attacks Targeting ASEAN (by Volexity) 2017-11-07 - Threat Group APT28 Slips Office Malware into Doc Citing NYC Terror Attack (by McAfee) 2017-11-08 - OilRig Deploys “ALMA Communicator” - DNS Tunneling Trojan (by Palo Alto Networks) 2017-11-22 - The Carbanak/Fin7 syndicate (by RSA) 2017-11-22 - Turla group using Neuron and Nautilus tools alongside Snake malware (by NCSC) 2017-11-30 - Inside the Response of a Unique CARBANAK Intrusion (by RSA) 2017-12-05 - Charming Kitten: Iranian Cyber Espionage Against Human Rights Activists (by Clearsky) 2017-12-05 - Charming Kitten: CSV Data (by Clearsky) 2017-12-14 - TRISIS Malware (by Dragos) 2017-12-14 - Attackers Deploy New ICS Attack Framework “TRITON” and Cause Operational Disruption to Critical Infrastructure (by FireEye) 2017-12-19 - North Korea Bitten by Bitcoin Bug (by Proofpoint) 2018-01-12 - Update on Pawn Storm: New Targets and Politically Motivated Campaigns (by Trend Micro) 2018-01-18 - Dark Caracal Cyber-espionage at a Global Scale (by Lookout) 2018-01-18 - Turla group update Neuron malware (by NCSC) 2018-02-20 - APT37 (Reaper): The Overlooked North Korean Actor (by FireEye) 2018-03-01 - Industrial Control System Threats (by Dragos) 2018-03-10 - APT15 is alive and strong: An analysis of RoyalCli and RoyalDNS (by NCC Group) 2018-03-28 - Lazarus Group Targets More Cryptocurrency Exchanges and FinTech Companies (by Intezer) 2018-04-05 - M-TRENDS2018 (by FireEye) 2018-04-20 - Follow The Money: Dissecting the Operations of the Cyber Crime Group FIN (by FireEye) 2018-05-04 - Burning Umbrella (by 401TRG) 2018-05-09 - Iran’s Hacker Hierarchy Exposed (by Recorded Future) 2018-05-22 - The destruction of APT3 (by Intrusiontruth) 2018-06-19 - Olympic Destroyer is still alive (by Kaspersky) Another good collection of resources related to APT campaigns, also somehow more recently updated, is located here.

me

My name is Adam Lichonvsky and I'm proud father and researcher.