{"id":557,"date":"2023-09-07T18:56:41","date_gmt":"2023-09-07T16:56:41","guid":{"rendered":"https:\/\/lendl.priv.at\/blog\/?p=557"},"modified":"2026-01-13T22:32:40","modified_gmt":"2026-01-13T21:32:40","slug":"a-classification-of-cti-data-feeds","status":"publish","type":"post","link":"https:\/\/lendl.priv.at\/blog\/2023\/09\/07\/a-classification-of-cti-data-feeds\/","title":{"rendered":"A classification of CTI Data feeds"},"content":{"rendered":"\n<p>(Crossposted on the <a href=\"https:\/\/cert.at\/en\/blog\/2023\/9\/cti-data-feeds\">CERT.at blog<\/a>.)<\/p>\n\n\n\n<p>I was recently involved in discussions about the procurement of Cyber Threat Intelligence (CTI) feeds. This lead to discussions on the nature of CTI and what to do with it. Here is how I see this topic.<\/p>\n\n\n\n<p>One way to structure and classify CTI feeds is to look at the abstraction level at which they operate. As <a href=\"https:\/\/en.wikipedia.org\/wiki\/Cyber_threat_intelligence\">Wikipedia<\/a> puts it:&nbsp;<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Tactical<\/strong>: Typically used to help  identify threat actors (TAs). Indicators of compromise (such as IP  addresses, Internet domains or hashes) are used and the analysis of  tactics, techniques and procedures (TTP) used by cybercriminals is  beginning to be deepened. Insights generated at the tactical level will  help security teams predict upcoming attacks and identify them at the  earliest possible stages.<\/li>\n\n\n\n<li><strong>Operational<\/strong>: This is the most  technical level of threat intelligence. It shares hard and specific  details about attacks, motivation, threat actor capabilities, and  individual campaigns. Insights provided by threat intelligence experts  at this level include the nature, intent, and timing of emerging  threats. This type of information is more difficult to obtain and is  most often collected through deep, obscure web forums that internal  teams cannot access. Security and attack response teams are the ones  that use this type of operational intelligence.<\/li>\n\n\n\n<li><strong>Strategic<\/strong>: Usually tailored to  non-technical audiences, intelligence on general risks associated with  cyberthreats. The goal is to deliver, in the form of white papers and  reports, a detailed analysis of current and projected future risks to  the business, as well as the potential consequences of threats to help  leaders prioritize their responses.<\/li>\n<\/ul>\n\n\n\n<!--more-->\n\n\n\n<p>With tactical CTI, there a reasonable chance that it  can shared on a machine-to-machine basis with full semantic information  that makes it possible to automate the processing for detection and  prevention purposes. Many commercial security devices are sold with a  subscription to the vendor&#8217;s own data-feeds. This ranges from simple  anti-spam solutions, over filters for web proxies to rules for SIEMs.<\/p>\n\n\n\n<p>While it is possible to encode operational CTI in  standardized data exchange formats like STIX2, it is much harder for  automated systems to operationalize this information. For example, what  automated technical reaction is possible to &#8220;threat actor X is now using  compromised CPEs in the country of its targets for C2 communication&#8221;?  Yes, one can store that kind of information in OpenCTI (or a similar  Threat Intelligence Platform (TIP)) and map it to the ATT@CK framework.  That can be valuable for the human expert to plan defenses or to react  better during incidents, but it is not detailed enough automated  defense.<\/p>\n\n\n\n<p>With strategic CTI, we are on the human management layer. This is never designed for automated processing by machines.<\/p>\n\n\n\n<h1 class=\"wp-block-heading\"><strong>Types of IOCs<\/strong><\/h1>\n\n\n\n<p>Focusing on the <strong>technical layer<\/strong>, we find that there are a number of different types of information encoded in the data feeds. One way to look at this is the <a href=\"https:\/\/www.activeresponse.org\/wp-content\/uploads\/2013\/07\/diamond.pdf\">Diamond Model of intrusion analysis<\/a>  which is built around information on adversary, capability,  infrastructure, and victim. While this is a very valuable model for  intrusion analysis, it is too complex for a simple categorization of CTI  feeds.<\/p>\n\n\n\n<p>I propose the following three basic types:<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Type 1: Attack Surface Information<\/strong><\/h2>\n\n\n\n<p>Many of the feeds from Shadowserver fall in this category. Shodan data can also be a good example. There is now a&nbsp;<a href=\"https:\/\/en.wikipedia.org\/wiki\/Cybersecurity_rating#Security_Rating_Services\">bunch of companies<\/a> focusing on &#8220;cyber risk rating&#8221;, which all try to evaluate the internet-visible infrastructure of organizations.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Examples:<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>&#8220;On IP-address A.B.C.D, at time X, we detected a  Microsoft Exchange server running a version that is vulnerable to  CVE-202X-XXXX&#8221;.<\/li>\n\n\n\n<li>&#8220;The time-server at IP addres Y can be abused as ddos-reflector.&#8221;<\/li>\n\n\n\n<li>&#8220;On IP address Z, there is an unprotected MongoDB reachable from the Internet.&#8221;<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Notable points are:<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>This is very specific information about a concrete system. Usually, it is very clear who is responsible for it.<\/li>\n\n\n\n<li>There is no information about an actual compromise of  the listed system. The system might be untouched or there may already be  a number of webshells deployed on it.<\/li>\n\n\n\n<li>There is no information about an attacker.<\/li>\n\n\n\n<li>This is sensitive (potentially even GDPR-relevant) information.<\/li>\n\n\n\n<li>This information is (almost) useless to anybody but the owners of the system.<\/li>\n\n\n\n<li>Thus, the coordinating CSIRT should pass this  information on to the maintainers of this system and to nobody else.  CERT.at is usually tagging these events with &#8220;vulnerable \/ vulnerable  system&#8221; or &#8220;vulnerable \/ potentially unwanted accessible service&#8221;.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Expected response from system owner:&nbsp;<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Mitigate the threat by patching \/ upgrading \/ removing  the system or maybe even accept the risk (e.g. &#8220;yes, we really want to  run telnet enable on that server&#8221;).<\/li>\n\n\n\n<li>Verify that the system has not been breached yet.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Type 2: Threat Actor IOCs<\/h2>\n\n\n\n<p>This is the opposite: the information is solely about  the threat actor and the resources this group is using, but there is no  clear information on the targets. Typical information contained in these IOCs is:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The domain-name of a command &amp; control (C2) server of the TA<\/li>\n\n\n\n<li>An IP address of a C2 server<\/li>\n\n\n\n<li>Filename and\/or hash of malware used by the TA<\/li>\n\n\n\n<li>Email subject, sender and sending IP address of a phishing mail<\/li>\n\n\n\n<li>Mutex names, registry-keys or similar artefacts of an infection<\/li>\n\n\n\n<li>URL-pattern of C2 connections<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example:<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A RAT Remcos campaign was detected 2023-06-14 to use\n<ul class=\"wp-block-list\">\n<li>Mutex: Rmc-MQTCB0URI: \/json.gp<\/li>\n\n\n\n<li>Email-attachment: Shipment_order83736383_document_file9387339.7z<\/li>\n\n\n\n<li>MD5: 2832aa7272b0e578cd4eda5b9a1f1b12<\/li>\n\n\n\n<li>Filename: Shipment_order837363.exe <\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Notable points are:<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>This is detailed information about a threat actor infrastructure, tools and procedures.<\/li>\n\n\n\n<li>There is often no information about targets of these attacks. Sometimes, some targeting information is known, like &#8220;This TA  usually attacks high-tech companies&#8221;.<\/li>\n\n\n\n<li>This information is potentially useful for everybody who that actor might target.<\/li>\n\n\n\n<li>Unless one thinks that attacker IP-addresses deserve GDPR-protection, this data has no privacy implication.<\/li>\n\n\n\n<li>Thus, the coordinating CSIRT should pass this  information on to all constituents who are capable of operationalizing  such CTI. CERT.at is usually not sending this kind of information  pro-actively to all constituents, instead we operate a MISP instance  which holds these IOCs. Security automation on the side of the  constituent is welcome to use the MISP APIs to fetch and process the  IOCs.<\/li>\n\n\n\n<li>If the targeting of the TA is sufficiently well known  and specific, CERT.at will pass on the IOCs directly to the constituent&#8217;s security team.<\/li>\n\n\n\n<li>In rare cases, the TA is abusing infrastructure of one  of our constituents. In that case, we have a mix with the next type of  CTI.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Expected response from system owner:<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Add the IOCs to any sort of incident prevention system, e.g., filter lists in proxies, EDR or AV software.<\/li>\n\n\n\n<li>Add the IOCs to the incident detection system, e.g., create suitable rules in SIEMs.<\/li>\n\n\n\n<li>Ideally, also perform a search in old logs for the newly acquired IOCs.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Type 3: Infection data<\/h2>\n\n\n\n<p>Sometimes we receive cyber threat information that is very specific and concerns a live incident inside a constituent&#8217;s network.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Examples are:<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>&#8220;We detected at timestamp X a webshell placed on a  Citrix server. IP-address = A.B.C.D, path =  \/logon\/LogonPoint\/uiareas\/mac\/vkb.php&#8221;<\/li>\n\n\n\n<li>&#8220;Our darknet monitoring detected that someone is selling VPN credentials for user@example.com on the platform X&#8221;<\/li>\n\n\n\n<li>&#8220;After a takedown of botnet X we are monitoring botnet  drone connections to the former C2 servers. On [timestamp], the IP  address A.B.C.D connected to our sinkhole.&#8221;<\/li>\n\n\n\n<li>&#8220;We managed to get access to the infrastructure of  threat actor X. According to the data we found there, your constituent Y  is compromised.&#8221;<\/li>\n\n\n\n<li>&#8220;Please find below information on IPs geolocated in  your country which are most likely hosting a system infected by SystemBC  malware. [\u2026] Timestamp, IP-address, hostname, c2 ip-address&#8221;<\/li>\n\n\n\n<li>&#8220;There are signs of malicious manipulations on the  Website of domain X, there is a phishing page at  \/images\/ino\/95788910935578\/login.php&#8221;<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Notable points are:<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>This is usually very specific information about a live incident involving a concrete system.<\/li>\n\n\n\n<li>In the best case, the information is good enough to trigger a successful investigation and remediation.<\/li>\n\n\n\n<li>The threat actor is often, but not always, named.<\/li>\n\n\n\n<li>This is sensitive (potentially even GDPR-relevant) information.<\/li>\n\n\n\n<li>This information is (almost) useless to anybody but the owners of the system.<\/li>\n\n\n\n<li>This information can be very time-sensitive: a quick reaction can sometimes prevent a ransomware incident.<\/li>\n\n\n\n<li>Thus, the coordinating CSIRT should pass this  information quickly on to the maintainers of this system and to nobody else. CERT.at is usually tagging these events with &#8220;intrusions \/  system-compromise&#8221; or &#8220;fraud \/ phishing&#8221;<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Expected response from system owner:<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Start the local incident response process.<\/li>\n\n\n\n<li>Clean up the known infection and investigate the  possibility of additional compromises in the affected network (lateral  movement?).<\/li>\n<\/ul>\n\n\n\n<h1 class=\"wp-block-heading\">Tooling<\/h1>\n\n\n\n<p>CERT.at is using IntelMQ to process feeds of type 1 and 3. CTI feeds of type 2 are handled by our MISP installation. <\/p>\n","protected":false},"excerpt":{"rendered":"<p>(Crossposted on the CERT.at blog.) I was recently involved in discussions about the procurement of Cyber Threat Intelligence (CTI) feeds. This lead to discussions on the nature of CTI and what to do with it. Here is how I see this topic. One way to structure and classify CTI feeds is to look at the [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[],"class_list":["post-557","post","type-post","status-publish","format-standard","hentry","category-cert"],"_links":{"self":[{"href":"https:\/\/lendl.priv.at\/blog\/wp-json\/wp\/v2\/posts\/557","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/lendl.priv.at\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/lendl.priv.at\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/lendl.priv.at\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/lendl.priv.at\/blog\/wp-json\/wp\/v2\/comments?post=557"}],"version-history":[{"count":2,"href":"https:\/\/lendl.priv.at\/blog\/wp-json\/wp\/v2\/posts\/557\/revisions"}],"predecessor-version":[{"id":831,"href":"https:\/\/lendl.priv.at\/blog\/wp-json\/wp\/v2\/posts\/557\/revisions\/831"}],"wp:attachment":[{"href":"https:\/\/lendl.priv.at\/blog\/wp-json\/wp\/v2\/media?parent=557"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lendl.priv.at\/blog\/wp-json\/wp\/v2\/categories?post=557"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lendl.priv.at\/blog\/wp-json\/wp\/v2\/tags?post=557"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}