Intro to Cyber Threat Intel

Cyber Threat Intelligence for SOC L1 Analysts

The modern Security Operations Centre (SOC) is a noisy place. Dashboards blink, telemetry streams in by the gigabyte, and the clock always ticks toward the subsequent potential breach. At the front of this controlled chaos sits the Level 1 analyst - the first human touchpoint for every suspicious ping, pop‑up, or packet. This room seeks to translate the sometimes abstract discipline of Cyber Threat Intelligence (CTI) into everyday tasks: enriching indicators, triaging alerts, and turning raw data into the stories that matter.

The goal is to move learners from "I recognise an IP address" to "I recognise why this IP address spells trouble—and I can prove it" by achieving the following objectives:

• Understand what threat intelligence is and why it matters to SOC analysts.
• Know about the threat intelligence lifecycle and the indicators to look for.
• Familiarise yourself with intelligence sharing using feeds and platforms.

Prerequisites

Before we begin, it is advisable to complete the following path:

Cyber Security 101

A junior analyst logs in for their shift and finds two hundred fresh alerts waiting—everything from benign network scans to a PowerShell beacon that feels out of place. The ticket queue does not politely pace itself; it demands quick, confident decisions. This is where CTI earns its keep.

Threat intelligence provides the context that helps an analyst decide which of those two hundred alerts represents genuine danger. With reliable context, the SOC spends energy on the right issues and sleeps better when the dashboards are finally calm.

In concrete terms, CTI seeks to answer three essential questions:

1. Who, or what, is on the other end of this alert indicator?
2. What was their behaviour in the past?
3. How does my organisation respond, and what should I do about it right now?

When these questions are addressed early—preferably within minutes—an L1 analyst buys precious time downstream for the incident‑response (IR) team. CTI is therefore not the exclusive domain of intel specialists; it is a front‑line tool that elevates SOC triage from guesswork to calculated action.

From Raw Data to Usable Intelligence

Information security literature distinguishes data, information, and intelligence, yet the three terms often blur in daily conversation. Making them explicit clarifies an analyst's objective.

A Level 1 analyst is responsible for making the artefacts usable and enriching them until they qualify as intelligence, or demonstrating that they never will. That push is enacted through enrichment: rapid, methodical lookups of public, commercial, and internal sources that shed light on origin, behaviour, and relevance.

During the ascent of data to intelligence, three more labels become paramount for analysts to know.

• Indicator of Compromise (IOC): Evidence of a breach, such as a C2 address in the logs.
• Indicator of Attack (IOA): A malicious action, such as PowerShell launching an unknown service, is underway.
• Tactics, Techniques, and Procedures (TTP): An adversary's detailed methodologies expressed in MITRE ATT&CK IDs and descriptions.

Indicator Types Essential to First-Line Triage

Every artefact demands a tailored enrichment path. Memorising tools is less important than recognising what kind of indicator the alert supplies and knowing where to look. Below, we have a table showing the types of indicators we need to be aware of, with examples:

Actionable tip. Maintain a browser bookmark folder or a SIEM launcher panel that opens your preferred look-ups with the highlighted indicator pre-populated. The thirty seconds saved per alert compound into hours over a month.

Feeds, Platforms, and Why the Distinction Matters

Most SOCs do not build or have intelligence in-house. The insights must be integrated and ingested from reliable sources.

Feed: A scheduled stream of indicators, usually delivered in various formats such as CSV, JSON, STIX, or through TAXII. Over-ingesting feeds without curation drowns analysts in false positives and erodes trust in the programme.

Platform: A structured repository that stores indicators, tracks enrichment, maps relationships, and enforces sharing permissions. MISP and OpenCTI are leading open-source examples.

Sound CTI practice introduces feeds gradually, confirms they align with the organisation's threat model, and promotes them into the platform only after measuring actionability. The platform then becomes the single source of truth—an analyst queries it first, ensuring biographies of indicators evolve rather than fork.

Sources of Cyber Threat Intelligence

Intelligence is only as trustworthy as its source, for it drives credibility and steers legal review if an IOC later triggers business disruption. As an analyst, you must know and note where each indicator originated.

There are four broad sources that you will come across in your practice:

• Internal telemetry: SIEM logs, EDR detections, phishing-mailbox submissions provide the highest immediate relevance.
• Commercial services: Vendor premium feeds, paid sandboxes**,** and closed-source analytics. These provide high fidelity, but may have export and sharing limits based on licensing.
• Open-source intelligence (OSINT): AbuseIPDB, URLhaus, public blogs with IOCs, and academic research. Before applying, information from these sources will need to be cross-confirmed.
• Communities & ISACs: Sector-specific lists marked with labels and rich context (e.g., FS-ISAC)

Threat Intelligence Classifications

Threat intelligence is geared towards understanding the relationship between your operational environment and your adversary. With this in mind, we can break down threat intel into the following classifications:

• Strategic intel: High-level intelligence that looks into the organisation's threat landscape and maps out the risk areas based on trends, patterns and emerging threats that may impact business decisions. An example is an annual ransomware trends report predicting a shift to data-wiping extortion in healthcare.

• Tactical intel: Assessments of adversaries' behaviours through analysis of tactics, techniques, and procedures (TTPs). This can be in the form of Advisory notes, such as detailing new T1059.005 (Visual Basic) abuse in malspam.

• Operational intel: Campaign-specific details about the motives and intent to perform an attack. This is useful for understanding the critical assets available in the organisation (people, processes, and technologies) that may be targeted.

• Technical intel: Atomic indicators and artefacts such as IPs and hashes related to an attack.

L1 analysts will escalate many Technical IOCs, observe and document Tactical IOAs, and identify patterns that feed Operational reporting.

Cyber Threat Intelligence follows a six-phase intelligence lifecycle that transforms raw data into contextualised and action-oriented insights geared towards triaging security incidents. We shall look at this lifecycle as a narrative that follows a single SOC Level 1 analyst, Alex, as they weave CTI into a routine defence objective: protecting TryHatMe's production database.

Before we look into the lifecycle, various concepts are helpful to understand when working with threat intelligence.

Traffic Light Protocol (TLP)—A Primer for Proper Sharing

The Traffic Light Protocol is a four-colour labelling scheme defined by FIRST.org that governs how widely intel may be shared. These labels can be summarised in the following table:

While investigating breaches, a Level 1 analyst ensures that an IOC's TLP label—if provided—travels with the indicator into any platform or triage note. Violating the label can breach contractual obligations and erode trust with intelligence partners.

Intel Formats

Analysts encounter intelligence in various formats or protocols. Once they have gathered intel, they are responsible for sharing and updating other analysts on new findings about attack techniques. One format in which threat intel can be found is Structured Threat Information Expression (STIX). This JSON schema was developed to describe and specify threat indicators, relationships, and context in a machine-readable form.

We can now look into the CTI lifecycle with a real-world scenario.

Scenario Premise

TryHatMe Corp holds sensitive customer data in a PostgreSQL server in a segmented subnet. The server is fronted by a next-generation firewall (NGFW) and monitored on-host by an Endpoint Detection and Response (EDR) agent. Senior management has asked the SOC to "bring in cyber-threat intelligence" so that the controls react rapidly to emerging threats. The morning-shift L1 analyst, Alex, is assigned to build and exercise that workflow.

Step 1: Direction – Defining the Mission

Alex begins in a brief planning meeting with the CTI lead and the database administrator. Together, they translate the broad mandate into an intelligence requirement:

1. Primary asset. The PostgreSQL production database.

2. Business risk. Data breach fines under GDPR and loss of customer trust.

3. Available controls. NGFW is capable of IP- and domain-based blocking; EDR can quarantine files by hash.

4. Initial CTI goal. Use threat-feed indicators to:

   • Block or alert on suspicious IP addresses at the firewall, and
   • Detect known malicious file hashes at the EDR layer.

Alex constructs two measurable questions that will steer subsequent collection and analysis:

Q1 Which external IP addresses and domains are currently used to exploit PostgreSQL services or exfiltrate database records?

Q2 Which malware families targeting PostgreSQL drivers or credentials are active this week, and what are their file hashes?

The answers to Q1 and Q2 will become success criteria in later feedback.

Step 2: Collection – Assembling the Raw Material

Guided by the questions, Alex gathers intelligence from four sources:

Alex exports each feed in STIX or CSV, then stores a dated copy in the SOC's "raw-intel" S3 bucket, ensuring reproducibility.

Step 3: Processing – Normalising and Correlating the Data

Raw feeds never align perfectly, and artefacts may arrive in mixed formats. To correct this, threat intel will need to be normalised and correlated. Normalising ensures threat data from various sources is standardised into a standard format for consistent analysis. Correlation involves identifying connections and links between data from different sources and threats. It can also help identify contradictions, such as having a benign tag in one's history versus a malicious label in new data today.

For Alex, processing threat intel will involve executing scheduled Python scripts that:

1. Normalises indicator syntax such as having IPv6 addresses compressed, domains in lowercase or stripping off IP subnet masks.

2. Correlates and deduplicates against the platform's existing indicator table.

3. Tag each entry with source, date, and TLP label.

4. Converts the final set of intel into two action files, such as:

   • firewall_blocklist.csv, a firewall-ready CSV that covers the indicator, action, and comments
   • edr_hash_rules.yar, an EDR YARA-rule file for hash blocking.

During processing, Alex spots a collision: one IP address appears in the NGFW feed labelled as TLP: AMBER and AbuseIPDB labels it as TLP: CLEAR. Because the stricter TLP prevails, the combined record inherits TLP: AMBER. This prevents inadvertent disclosure if the list is later shared.

Step 4: Analysis – Turning Information Into Judgement

Blocking every indicator or artefact suspected of being malicious may create room for false positives. Alex would need to evaluate the relevance and matching between the intel gathered and the current status of the investigation. This results in providing answers to the questions in Phase 1:

• Firewall indicators (Q1).
  Cross-check: A Splunk query over the previous 30 days shows one of the NGFW IPs attempting but failing to open TCP 5432 against the production subnet. That event validates the indicator's applicability.
• Hash indicators (Q2).
  Reverse-search: OpenCTI links the new hash to the PgSteal malware family; Any.Run sandbox analysis demonstrates credential-dump behaviour. Because the organisation uses exactly the named ODBC driver, the hash is marked as high priority, and relevance is confirmed.

Alex grades each indicator:

Seven IP addresses and one hash meet the high bar; the rest are queued as medium and set for monitoring.

Step 5: Dissemination – Getting Intelligence to the Right Consumers

Unused threat intelligence becomes shelfware. Alex delivers tailored output:

By tailoring depth to the audience, Alex ensures that each consumer receives only the detail required to act, nothing more and nothing less.

Step 6: Feedback – Measuring and Refining the Cycle

Two weeks later, metrics and reports from the firewall and EDR reports show the progress of establishing an effective threat intelligence workflow:

Because the outcome meets the initial direction objectives, management approves expansion: the next sprint will add other threat parameters, such as DNS tunnelling IOCs for the same asset group. Alex updates the direction document, closes the feedback loop, and schedules the second iteration.

Standards and frameworks provide structures to rationalise the distribution and use of threat intel across industries. They also allow for common terminology, which helps in collaboration and communication. Here, we briefly look at some essential standards and frameworks commonly used.

MITRE ATT&CK

A malicious PowerShell command may look obvious, but your ticket needs a label everyone else recognises. MITRE's ATT&CK framework supplies that label. Each technique—T1059.001 PowerShell, T1048.003 DNS tunnel, and so on—acts as a Rosetta Stone between vendors, teammates, and auditors, providing knowledge about adversarial behaviour.

As an L1 analyst, you can use the matrix during an investigation in the following way:

1. Match the behaviour in the alert to a tactic/technique pair.
2. Write the ID in your triage note: "Observed T1071.001 (web-based C2) against FINANCE-TRYHATME-00".
3. Hand the note to Level 2 or Incident Response; they instantly know which mitigations and threat-actor profiles apply.

MITRE D3FEND

If ATT&CK catalogues how adversaries attack, D3FEND catalogues how defenders respond. Each entry maps to defensive tactics such as Credential Hardening or Data Obfuscation_._

A case for this would look similar to this:

• Your proxy raises a T1048.003 DNS tunnel alert.
• Search D3FEND for the matching defensive technique: D3—NTDN DNS—request analysis. The page lists practical controls: block extensive TXT records and alert on uncommon query entropy.
• Add the most feasible control to your "next actions" field; you have just supplied a mitigation, not only a diagnosis.

Cyber Kill Chain

The Cyber Kill Chain, developed by Lockheed Martin, breaks down adversary actions into steps. This breakdown helps analysts and defenders identify which stage-specific activities occurred when investigating an attack. The phases defined are shown in the image below.

Over time, the kill chain has been expanded using other frameworks, such as ATT&CK, and a new Unified Kill Chain has been formulated.

CVEs, CVSS, and the NVD

A SOC queue contains almost as many vulnerability notifications as malware alerts. As an SOC L1 analyst, you must understand how to identify and organise vulnerability notifications.

• CVE (Common Vulnerabilities and Exposures) — provides a catalogue number for discovered vulnerabilities, e.g., CVE-2023-4863.
• CVSS (Common Vulnerability Scoring System) — a 0–10 severity scale with temporal and environmental modifiers for vulnerabilities.
• NVD (National Vulnerability Database) — the canonical repository that links CVE numbers to CVSS scores, exploits, and affected products.

Sharing and Processing Intel

We previously discussed platforms and feeds from which threat intelligence can be retrieved. When organisations publish fresh indicators, every peer that consumes and validates them strengthens the collective defence and feeds back improvements. This information looks to hinge on two standards: STIX and TAXII.

• STIX: We mentioned STIX previously as the structured JSON schema for describing threat information.
• TAXII: The Trusted Automated eXchange of Indicator Information is a set of secure APIs used to exchange threat intelligence in near real-time for detection, prevention, and mitigation of threats.
  It supports two sharing models: Collection, which ensures threat intel is collected and hosted by a producer, and Channel, which publishes threat intel to users from a central server.

Sharing threat intelligence has its benefits, with near-real-time feeds shortening the gap between another organisation's incident and one's preventive procedures. Additionally, community contributions earn organisations reciprocal trust as valuable intelligence sources.

That said, not every indicator should be shared. Privacy laws, customer NDAs or internal competitive information may forbid disclosure, and sharing specific IOCs early can tip off adversaries that their campaign has been detected.

As part of the dissemination phase of the lifecycle, CTI is also distributed to organisations using published threat reports. These reports come from technology and security companies researching emerging and actively used threat vectors. They are valuable for consolidating information presented to all suitable stakeholders. Some notable threat reports come from Mandiant (opens in new tab), Recorded Future (opens in new tab) and Palo Alto Unit42 (opens in new tab).

All the things we have discussed come together when mapping out an adversary based on threat intel. To better understand this, we will analyse a simplified engagement example. Click on the green "View Site" button in this task to open the Static Site Lab and navigate through the security monitoring tool on the right panel, and fill in the threat details.