CySA+ CS0-004 Threat Intelligence and Threat Hunting: ATT&CK, Pyramid of Pain, IoCs, STRIDE and Deception

Threat intelligence is evaluated information about adversaries (who they are, what they want and how they operate) that a defender can act on; threat hunting is the proactive, analyst-led search of your own telemetry for an adversary that has not triggered any alert. Intelligence tells you what to look for; hunting looks for it before an alert does. The rest of CS0-004 objective 1.4 is the vocabulary that connects the two: actors, TTPs, confidence, sources, indicators, threat modeling, threat mapping and deception.

Hunting starts from a hypothesis

A hunt is not "look around and see what turns up". It begins with a hypothesis: a specific, testable statement about adversary behaviour in your environment, with a scope and a time window. For example: "a service account logged on interactively to workstations it never normally uses in the last 30 days", or "a trusted service loaded an unsigned DLL from a user-writable folder this quarter". A usable hypothesis has three properties:

• It is grounded in intelligence about behaviour: a technique that actors relevant to your sector are reported to use. Indicator values (hashes, addresses) make poor hunt starting points because actors rotate them.
• It is falsifiable with data you actually hold. Before writing it, check which telemetry you retain and for how long. A claim about command-line arguments needs process-creation logging; a claim about lateral logons needs authentication events. If the evidence would only exist in a source you do not collect, the hunt cannot answer it.
• It is specific. A vague worry with no observable claim, no scope and no time window cannot be proved or disproved.

The analyst then queries the retained telemetry (EDR, DNS, proxy, authentication logs), investigates hits, and escalates to incident response only when there is evidence of compromise.

What a hunt produces

Every hunt produces output, whether or not it finds the adversary:

• A conclusion with an honest scope. A hunt can only clear the systems whose data it actually searched. Systems with missing or partial telemetry remain unknown, and that blind spot is a finding in its own right, to be fixed so the next hunt can cover it.
• Detection engineering. A query that reliably separates the malicious behaviour from normal activity is a candidate for an automated rule, so future occurrences no longer depend on someone hunting.
• Feedback to intelligence and threat models: new procedures, logging gaps, and techniques to add to the coverage heat map.

Hunting answers "are they already here?" when nothing has alerted. Blocklists and new alert rules only act on activity from now on.

You recognise a threat actor by its objective, targeting and behaviour, not by any single technical artefact. CS0-004 names two actor types: the advanced persistent threat (APT) and the insider threat.

Advanced persistent threat

An APT is a well-resourced actor, often state-sponsored or state-aligned, that pursues a specific organisation and specific data over a long period. Its distinguishing traits are:

• Targeted objectives: collection limited to one team, project or data set (design files, merger documents) rather than whatever is valuable.
• Persistence and determination: multiple footholds, spare backdoors, and access rebuilt within days after eviction.
• Custom or tailored tooling and careful operational security.
• Low-and-slow behaviour: long dwell time, small encrypted exfiltration chunks timed to blend with business traffic.

Many traits are shared with financially motivated crime and do not identify an APT on their own: spear-phishing, living-off-the-land tools such as PowerShell, freely available admin and credential utilities, encrypted command and control, and even a quiet stay of several months are all routine for ransomware crews and access brokers. What points to an APT is what the actor wants and how it reacts: a narrow, deliberate collection focus, and determination to keep or regain access to that particular target.

Insider threat

An insider threat comes from someone with legitimate, authorised access: employees, contractors or partners.

Insider classification depends on who is acting, not whose account was used. Ask whether the evidence ties the activity to the person or only to their credentials: device, location, session and the person's own whereabouts decide it. Because insiders use legitimate access, detection relies on behaviour and data-movement monitoring (DLP, UEBA) rather than malware detection.

MITRE ATT&CK is a public knowledge base of adversary behaviour organised as tactics, techniques and procedures (TTPs): the tactic is why (the adversary's goal at that stage), the technique is how in general, and the procedure is the specific implementation a group or tool used.

Technique IDs follow one pattern: a parent technique such as Command and Scripting Interpreter (T1059) or Remote Services (T1021) has numbered sub-techniques for each variant, so a scenario can be recorded at the parent or the sub-technique level depending on how much detail you have. Other common examples are Valid Accounts (T1078), Brute Force: Password Spraying (T1110.003), Ingress Tool Transfer (T1105) and Data Encrypted for Impact (T1486). A procedure is the most specific level, so it is where the actor's particular tools, binaries and parameters belong. A file hash or IP address is an indicator, not part of the TTP hierarchy.

When one technique sits under several tactics

Some techniques appear under more than one tactic; Scheduled Task/Job (T1053) and Valid Accounts (T1078) are well-known examples. The technique alone does not decide the tactic: you record the tactic that matches what the actor gained from that step. Take Valid Accounts: stolen remote-access credentials used to get into the network serve Initial Access; a dormant account kept as a spare way back in serves Persistence; an administrator account used to obtain rights the actor did not already have serves Privilege Escalation. A tactic only fits if the step actually achieved that goal for the actor.

Why map to ATT&CK

Mapping intrusions and intelligence reports to ATT&CK gives a common language across teams and vendors, lets you compare actors, and shows which behaviours your detections cover. It is also the basis for heat maps and threat mapping.

Heat maps and threat mapping both turn intelligence about relevant actors into priorities: a heat map shows which techniques matter and are undetected, and threat mapping ties those techniques to your own assets. An ATT&CK heat map colours techniques in the matrix by a score so that priorities stand out; you use it by finding techniques that are both widely used by the actors relevant to you and not yet detected. Heat maps are usually built as layers in the ATT&CK Navigator.

Common layers are:

• Threat (usage) layer: each technique scored by how many of the groups that target your sector use it.
• Coverage layer: which techniques your current detections or controls address.
• Combined layer: usage and coverage overlaid, so uncovered high-usage techniques stand out.

Prioritisation needs both dimensions at once, what adversaries do and what you can see, so read them together:

The same visual works for leadership: one combined layer answers "where are we blind to what our adversaries actually do?"

Threat mapping

Threat mapping is overlaying the techniques of the actors likely to target you onto your own environment (internet-facing systems, identity services, network paths and existing controls) to see where you are exposed and what to fix or hunt first. It starts from who attacks your sector and how, and ends with specific assets.

Several activities sound similar; what separates them is where each starts and what it produces:

To prioritise from a threat map, weigh exposure (internet-facing assets are reachable before any foothold), prevalence (how many relevant groups use the technique) and control strength (for example, password-only remote access versus MFA, or patched with and without a WAF). No single column decides. The asset to act on first is the one that scores badly on all three at once; a strong compensating control or a lack of exposure can push even a very common technique down the list.

The Pyramid of Pain, introduced by David Bianco, ranks indicator types by how much it costs the adversary to change them once defenders detect or block them. The higher you detect, the more pain you cause, so mature programmes invest at the top.

Lower-level indicators are still useful: they are quick to deploy and block known copies of an attack immediately. But an actor that recompiles its payload per victim and registers fresh infrastructure per intrusion defeats hash, IP and domain blocking with little effort. Detecting the behaviour (for example, a burst of failed logons spread across many accounts from one source, followed by a success: password spraying) forces the actor to change technique, which is expensive. When choosing where to spend one detection effort for lasting value, go up the pyramid. Note that the artifacts level sits on a boundary: a single mutex name or user-agent string matched exactly behaves like an atomic value, while a pattern (any random-looking mutex created by a document viewer) behaves more like behaviour.

Intelligence is worth acting on only when it is timely, relevant and accurate; a failure on any one of the three lowers confidence and should lower its priority, however good the other two look.

Two points decide many scenarios. First, atomic indicators age quickly: infrastructure is rented, abandoned and reassigned, so record when an indicator was observed and give it an expiry. Second, corroboration counts only when it is independent: two reports that trace back to the same original claim are one source, not two, however many places repeat it. When ranking items, an item must pass all three factors before source reliability separates the rest; a strong score on two cannot make up for a failure on the third.

Attribution

Attribution is the judgement of which actor is behind an intrusion; it is always stated with a confidence level (low, moderate, high) that reflects how many independent, hard-to-fake lines of evidence support it.

Some evidence is weak because it is easy to fake or widely shared:

• Language strings, keyboard layouts and compile-timestamp time zones can be planted as false flags or simply reflect the tools used.
• A single IP address or server can be shared, rented, compromised or reused by unrelated actors.
• Public tools are used by many groups.

Stronger evidence is consistent TTPs and procedures across several intrusions, infrastructure registration and hosting patterns over time, unique custom tooling, and corroboration from independent sources. Confidence comes from the quality and independence of the evidence, not the number of items: a pile of artefacts that are each easy to plant is still weak evidence.

Analysts use estimative language ("we assess with low confidence that...") so decision-makers get a useful judgement early, with the uncertainty stated, and the assessment is revised as corroboration arrives. Overstating confidence and withholding any judgement are both failures of the same discipline. For most defenders, attribution matters less than the TTPs: you defend against the behaviour whoever is behind it.

Intelligence is collected from open sources, closed sources and sharing communities, and it is shared under handling rules (TLP) in standard formats (STIX over TAXII).

OSINT versus closed-source intelligence

What makes a source open is that anyone may lawfully access it, not that it is on the internet: a public registry or log is OSINT, while a forum that requires vetting or an invitation is closed. When the coverage you need sits behind access your organisation cannot or will not obtain itself (for legal, ethical or skills reasons), buying it from a provider that already holds that access is the usual answer. Analysts also distinguish other collection disciplines, such as human intelligence (HUMINT, gathered from people) and the organisation's own internal telemetry and incident data; neither counts as OSINT.

Traffic Light Protocol 2.0

The Traffic Light Protocol (TLP), maintained by FIRST, tells recipients how far they may share a piece of intelligence.

The difference between AMBER and AMBER+STRICT is exactly whether you may pass it to clients. To share beyond what the label allows, ask the source first.

STIX and TAXII

STIX 2.1 (Structured Threat Information Expression, OASIS) is the format: JSON objects such as Indicator, Malware, Threat Actor, Attack Pattern (an ATT&CK technique), Campaign, Relationship and Sighting, grouped in bundles. TAXII 2.1 (Trusted Automated Exchange of Intelligence Information) is the transport: an HTTPS API whose servers expose collections that clients pull new objects from and, where the collection allows it, push objects to. Together they let ISACs and partner groups exchange intelligence automatically, including the links between indicators, actors and techniques; a spreadsheet or email list of indicators carries the values but loses that context.

Each STIX object type has one job. Relationship objects connect two other objects with a named type (an Indicator indicates a Malware; a Threat Actor uses an Attack Pattern). Observed Data holds raw observations such as log-derived network or file details. A Sighting records that something was seen: it points to the object seen through sighting_of_ref and can carry count, first_seen, last_seen and, optionally, references to supporting Observed Data. Sightings are how community members feed back what they observed, so the original producer learns which indicators are active.

An indicator of compromise (IoC) is an observable artefact that suggests malicious activity; it goes through collection, analysis and application, and it is either atomic or behavioral.

Atomic versus behavioral indicators

Anything an actor can choose freely for each intrusion (file names, task names, infrastructure, the bytes of its payload) works like an atomic value even when you find it on a host, and stops matching once the actor changes it. What repeats across intrusions is the sequence of actions, so behavioral indicators are the ones that carry over to the next one. Some models, such as Lockheed Martin's intelligence-driven defense paper, add a third class, computed indicators (hashes and regular expressions derived from data); CS0-004 uses the two-way split, with hashes treated as atomic.

Collection and analysis

IoCs are collected from your own incidents, sandbox runs, threat feeds, ISACs and vendor reports. Before using them, analyse them:

• Deconflict against known-good infrastructure your business relies on: CDNs, shared cloud ranges, SaaS providers. An address flagged as malicious in a shared hosting range may also front a service your own staff or customers depend on.
• Corroborate with independent sources and check age and relevance.
• Set an expiry (time to live) so stale indicators age out instead of blocking reassigned addresses for years.
• Enrich with context: which campaign, actor and technique the indicator belongs to.

Application: forward and backward

• Forward (preventive and detective): blocklists at DNS, proxy, firewall or EDR, and SIEM rules that alert on new matches. These only act on future activity.
• Backward (retrospective): hunting through retained DNS, proxy and EDR telemetry to answer "were we already compromised?", which matters most for campaigns with long dwell times.

Decide block or alert per indicator, not per feed, from two questions: how confident are we that it is malicious and current, and what legitimate traffic breaks if we are wrong? High confidence with no legitimate business use points to blocking; shared infrastructure or lower confidence points to detection and hunting instead. One uniform policy for a whole feed is usually wrong in one direction or the other.

STRIDE is a threat-modeling mnemonic, originally from Microsoft, for classifying design threats into six categories, each of which violates one security property and is addressed by a matching type of control. It is used at design time to ask "what can go wrong with this system?"

Two habits settle most STRIDE questions. First, classify by the property the stated threat attacks right now, not by what it might lead to or by which data is involved: exposed secrets are information disclosure even if they could later enable escalation, and a threat framed as someone credibly denying their own action is repudiation even when records being changeable is part of the cause. Second, check that the control fixes that property. Ordinary (server-side) TLS lets the client verify the server and encrypts the channel, but it proves nothing about who the client is; authenticating callers needs a credential the caller presents, such as a client certificate in mutual TLS or a signed token. A control from a different row, however useful, does not address the category in question.

Cyber deception plants decoy assets that legitimate users and systems have no reason to touch, so any interaction is a high-fidelity alert. It is especially good at catching attackers who are already inside and performing discovery, credential use or lateral movement.

Choose the decoy that matches the attacker behaviour you want to catch, and put it where that behaviour happens: a fake cloud access key in a code repository catches credential theft from source code; a canary document in a finance share catches someone opening files they should not; a decoy service on an internal subnet catches network discovery. Honeytokens are the lightest option because they ride on existing systems. Generic auditing of real resources also records legitimate activity, so it cannot match a decoy's signal-to-noise.

Placement and exclusion decide alert quality. Decoys belong where attackers go (internal segments for discovery and lateral movement, credential stores, sensitive shares). Then every automated process that legitimately sweeps hosts or data must be configured to skip them, whether it is security tooling, IT operations tooling, backup or search indexing. A decoy that any legitimate process touches generates benign alerts and loses the "every touch is suspicious" property that makes deception worth running.