CS0-004 · Security Operations

Develop evidence-based threat intelligence and hunting hypotheses

Objective 1.4 · Develop evidence-based threat intelligence and hunting hypotheses.

6 learning blocksNext unfinished block 1 · about 15 minutes19 key conceptsOriginal practice · Review pending
ProgressNot started0/6 blocks learned and checked
Learn

Start your lesson

Study the required lesson for each block, then take its short check. Guided exercises are optional. Required case practice within the blocks counts toward the readiness checklist, not lesson completion.

0/6blocks complete
Your notesPrivate to you
Up to 1,000 characters. Active writing time is recorded; idle time is excluded.
Block 1 of 6

Threat indicator · Intelligence confidence · STIX · Indicator expiration

Next · 15 min

No provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.

Required ITForMe lesson

Concept notes

Threat indicator

Represents an observable pattern associated with suspected malicious activity and needs source, time, confidence, and scope before operational use.

Intelligence confidence

Expresses how strongly a producer supports an intelligence judgment, without replacing the consumer's local relevance and validation assessment.

STIX

Defines structured cyber-threat intelligence objects and relationships so producers and consumers can exchange machine-readable context consistently.

Indicator expiration

Sets a review or removal time so aging infrastructure and changing context do not create permanent low-value detection or blocking rules.

Required block check · Block 1

Required for course progress · Pass with 3 of 4 correct

This records your study. Passing the check is still required for course progress.
Block 2 of 6

Threat-hunt hypothesis · ATT&CK data component · Hunt coverage · Hunt reproducibility

15 min

No provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.

Required ITForMe lesson

Concept notes

Threat-hunt hypothesis

States a behavior, population, time window, and observable evidence that can support or reject a bounded investigation.

ATT&CK data component

Names a specific observable event or property, such as process creation, that detection analytics collect through log sources to expose technique-related behavior.

Hunt coverage

Measures whether the necessary systems, sources, fields, and time intervals were available before interpreting positive or negative hunt results.

Hunt reproducibility

Preserves the hypothesis, query version, data sources, interval, exclusions, and results so another analyst can repeat and assess the hunt.

Required block check · Block 2

Required for course progress · Pass with 3 of 4 correct

This records your study. Passing the check is still required for course progress.
Block 3 of 6

Evaluate threat intelligence before operational use

8 min

No provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.

Required ITForMe lesson
Concept brief · about 8 minutes with practice

Evaluate threat intelligence before operational use

By the end, you can
  • Analyze supplied evidence for threat-intelligence operationalization.
  • Analyze supplied evidence for structured-intelligence limit.

Threat intelligence should record source, observation time, confidence, scope, and handling constraints. An indicator can age quickly: shared hosting changes, certificates rotate, and domains are repurposed. Validate that an indicator is relevant to the environment and decide whether it supports alerting, hunting, blocking, or context only.

STIX represents threat objects and relationships; TAXII can exchange collections. Structured format improves transport but does not make a claim trustworthy. Preserve producer confidence and markings, then apply local validation and expiration rather than turning every feed item into a permanent deny rule.

Optional support
Worked example
Situation

A feed labels an IP malicious with low confidence, first seen 14 months ago, and notes that it belonged to shared hosting.

Evidence
  • Feed: indicator 203.0.113.45 confidence 25/100
  • Observed 2025-07-12; valid_until omitted
  • Asset logs: no connections to the IP in 90 days
Reason it through

Low confidence, old observation, shared infrastructure, and no local sightings support a time-bounded hunt, not an immediate permanent block.

Expected result

Search retained telemetry, record no sightings if confirmed, and set a review/expiry before any alert rule is added.

Optional practice
Reasoning self-check

A feed labels an IP malicious with low confidence, first seen 14 months ago, and notes that it belonged to shared hosting.

  • Feed: indicator 203.0.113.45 confidence 25/100
  • Observed 2025-07-12; valid_until omitted
  • Asset logs: no connections to the IP in 90 days
  1. Record a timestamped fact table from the supplied evidence.
  2. Test the two most plausible explanations against every observation.
  3. Choose a bounded defensive action and state the result that would confirm it worked.
Compare your reasoning
Expected answers
  • Search retained telemetry, record no sightings if confirmed, and set a review/expiry before any alert rule is added.
  • The conclusion cites at least two supplied observations and names one remaining uncertainty.
If you got stuck
  • If the evidence conflicts, preserve both records and check clock, scope, and collection gaps before deciding.
  • If no conclusion is supportable, request one specific log, capture, inventory fact, or controlled retest.

Compare your reasoning with the revealed answers if helpful. The block check below is required for course progress.

Technical references

Required block check · Block 3

Required for course progress · Pass with 2 of 2 correct

This records your study. Passing the check is still required for course progress.
Block 4 of 6

Run a falsifiable threat hunt

18 min

No provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.

Required ITForMe lesson
Concept brief · about 18 minutes with practice

Run a falsifiable threat hunt

By the end, you can
  • Analyze supplied evidence for falsifiable hunt hypothesis.
  • Analyze supplied evidence for hunt coverage qualification.

A hunt starts with a hypothesis that names a behavior, population, time window, and evidence capable of supporting or rejecting it. 'Look for bad things' cannot be falsified. ATT&CK can help describe behavior, but the hunt must translate a technique into local data components and expected records.

Document collection coverage before interpreting zero results. If command-line logging began yesterday, a thirty-day hunt cannot claim absence. Track query version, data sources, exclusions, and findings so another analyst can reproduce the result and convert useful logic into a monitored detection.

Optional support
Worked example
Situation

After a vendor advisory about abused remote-support tools, a hunt team reviews finance endpoints for unapproved persistence.

Evidence
  • Service-create events retained 30 days on 98% of finance endpoints
  • Query: new service binary outside approved paths, grouped by signer and host
  • Three unsigned binaries found; two hosts lacked telemetry for 18 hours
Reason it through

The query tests a specific persistence behavior. Findings require validation, and the coverage gap prevents an unqualified statement about both hosts.

Expected result

Escalate the three binaries for validation, repair the two collection gaps, and rerun the saved query over the restored interval.

Optional practice
Reasoning self-check

After a vendor advisory about abused remote-support tools, a hunt team reviews finance endpoints for unapproved persistence.

  • Service-create events retained 30 days on 98% of finance endpoints
  • Query: new service binary outside approved paths, grouped by signer and host
  • Three unsigned binaries found; two hosts lacked telemetry for 18 hours
  1. Record a timestamped fact table from the supplied evidence.
  2. Test the two most plausible explanations against every observation.
  3. Choose a bounded defensive action and state the result that would confirm it worked.
Compare your reasoning
Expected answers
  • Escalate the three binaries for validation, repair the two collection gaps, and rerun the saved query over the restored interval.
  • The conclusion cites at least two supplied observations and names one remaining uncertainty.
If you got stuck
  • If the evidence conflicts, preserve both records and check clock, scope, and collection gaps before deciding.
  • If no conclusion is supportable, request one specific log, capture, inventory fact, or controlled retest.

Compare your reasoning with the revealed answers if helpful. The block check below is required for course progress.

Hands-on lesson practice

Work through the scenario

Practice simulation

Use the case evidence to complete the tasks, then check objectives.

Practice limits and saved work

Guided practice is optional. You can start required case practice directly; it counts toward the readiness checklist. Neither exercise completes the lesson or its checkpoint. Checks evaluate the supplied scenario and modeled configuration, not live systems or traffic. Work is saved in this browser session. Human technical review is pending.

Optional guided practice

Guided: Test a remote-service hunt

Threat reporting describes remote service abuse after credential theft. Form a falsifiable local hunt from supplied telemetry.

  • Threat hunteractor
  • Logon and service-install telemetrycontrol
  • Server fleetresource
Objectives
  1. Interpret the supplied evidence without overclaimingpending
  2. Choose the bounded evidence-supported actionpending
  3. Select evidence that verifies security and operational outcomepending
CySA+ defensive evidence workbench
Evidence 1

Threat report: valid accounts followed by remote service creation.

Evidence 2

Local logs retain successful logons, service installs, and source hosts.

Evidence 3

Known admin jump hosts are inventoried and can be excluded explicitly.

Read full options
  • Treat one isolated clue as conclusive without correlation.
  • Assume missing telemetry proves the activity did not occur.
  • Hunt for non-jump-host logons followed by new service installation on the same target.
Read full options
  • Query the sequence and compare sources with the approved jump-host baseline.
  • Apply an organization-wide disruptive change beyond the stated scope.
  • Close the case without retaining the supplied evidence.
Read full options
  • Matched sequences are reviewed and coverage gaps are listed separately.
  • Declare success without retesting the affected behavior.
  • Confirm only that a configuration value was entered.

Fictional, disposable SOC evidence. No production system or external service is contacted.

Report an issue with this exercise

Your report is private to you and the review team because lesson exercises can contain answers.

Required case practice

Required for the readiness checklist · Pass at 100%

Required case practice

Test a cloud-key hunt

A report describes dormant access keys becoming active from new infrastructure. Translate it into a bounded cloud hunt.

  • Cloud hunteractor
  • Cloud audit and key inventorycontrol
  • Cloud accountsresource
Objectives
  1. Interpret the supplied evidence without overclaimingpending
  2. Choose the bounded evidence-supported actionpending
  3. Select evidence that verifies security and operational outcomepending
CySA+ defensive evidence workbench
Evidence 1

Cloud audit retains key ID, API action, source ASN, and timestamp.

Evidence 2

Inventory identifies keys unused for 60 days and their owners.

Evidence 3

Travel and vendor egress ranges are documented.

Read full options
  • Hunt for previously dormant keys used from sources outside documented owner patterns.
  • Treat one isolated clue as conclusive without correlation.
  • Assume missing telemetry proves the activity did not occur.
Read full options
  • Apply an organization-wide disruptive change beyond the stated scope.
  • Join key age, source, action, and owner context before escalating.
  • Close the case without retaining the supplied evidence.
Read full options
  • Declare success without retesting the affected behavior.
  • Confirm only that a configuration value was entered.
  • Owners confirm expected use or affected keys are revoked with events preserved.

Fictional, disposable SOC evidence. No production system or external service is contacted.

Report an issue with this exercise

Your report is private to you and the review team because lesson exercises can contain answers.

Technical references

Required block check · Block 4

Required for course progress · Pass with 2 of 2 correct

This records your study. Passing the check is still required for course progress.
Block 5 of 6

Assess actors, TTPs, confidence, and sources

10 min

No provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.

Required ITForMe lesson
Concept brief · about 10 minutes with practice

Assess actors, TTPs, confidence, and sources

By the end, you can
  • Explain and apply actor hypothesis.
  • Explain and apply ttp evidence layer.
  • Explain and apply time-scoped confidence.
  • Explain and apply intelligence source class.

APT and insider are hypotheses about capability, access, intent, and persistence. Common tools and techniques are reused, so ATT&CK mappings or a heat map do not identify an actor. The Pyramid of Pain suggests that behavior-based detections are often costlier for an adversary to change than hashes or addresses, but operational cost and false positives still matter.

Confidence is not a permanent property. Ask when the intelligence was collected, whether it applies to this environment, and how accurate the producer has been for similar claims. OSINT is publicly obtainable; closed sources have access restrictions; sharing communities impose markings and handling rules that must follow the data.

The Pyramid of Pain ranks indicator types by how much it costs an adversary when defenders deny them. From bottom to top: hash values (trivial to change), IP addresses (easy), domain names (simple), network and host artifacts (annoying), tools (challenging), and TTPs (tough). A threat heat map colors a matrix, commonly the ATT&CK techniques, by how often each is sighted or how well it is detected, so concentrations and coverage gaps stand out.

Optional support
Worked example
Situation

A restricted report attributes a PowerShell sequence to an APT, while an administrator used a similar sequence during an approved migration.

Evidence
  • Report: medium confidence; 10 months old; TLP-restricted
  • ATT&CK mapping: command and scripting interpreter
  • Change record: administrator window overlaps two of four events
Reason it through

The technique is real but reused; two events may be authorized and two need investigation. The report cannot by itself attribute either sequence.

Expected result

Separate the events by account, host, command, and change window; honor sharing markings and report attribution as unresolved.

Optional practice
Reasoning self-check

A recent OSINT report and an older restricted report map the same behavior but name different actors.

  • OSINT: current hash and low-confidence actor claim
  • Closed report: behavior detail, medium confidence, sharing restricted
  • Local telemetry: technique match, no unique infrastructure
  1. Build a short evidence table that separates observations, supported conclusions, and remaining unknowns.
  2. Choose the authorized action that tests the leading conclusion with the least operational impact.
  3. Compare your decision and reopen condition with the expected results before continuing.
Compare your reasoning
Expected answers
  • Use the behavior for hunting, retain source/markings/timeliness, and keep attribution unresolved because ATT&CK, heat maps, and indicator repetition do not identify an actor.
  • Reopen attribution only when locally corroborated infrastructure, access, or procedure distinguishes the competing actor hypotheses.
If you got stuck
  • If the answer depends on a product name alone, return to the actual evidence it produced.
  • If no option can be falsified, name the missing record before choosing.

Compare your reasoning with the revealed answers if helpful. The block check below is required for course progress.

Technical references

Required block check · Block 5

Required for course progress · Pass with 3 of 4 correct

This records your study. Passing the check is still required for course progress.
Block 6 of 6

Operationalize indicators, threat models, and deception

9 min

No provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.

Required ITForMe lesson
Concept brief · about 9 minutes with practice

Operationalize indicators, threat models, and deception

By the end, you can
  • Explain and apply indicator lifecycle.
  • Explain and apply stride question set.
  • Explain and apply threat mapping and deception.

Atomic indicators such as a hash or address are easy to match and often easy to change. Behavioral indicators describe a sequence or relationship and may be more durable, but require more context. Every indicator needs source, collection time, confidence, scope, deployment owner, performance review, and retirement conditions.

STRIDE prompts design review questions; it does not prove a threat exists or provide likelihood. Threat mapping connects assets, trust boundaries, actors, behaviors, and controls. Deception adds monitored artifacts such as canary credentials or decoy shares; it must avoid collecting unrelated user data or automatically taking high-impact action from one touch.

Optional support
Worked example
Situation

A canary credential placed in a decoy share is used from a build server after its hash indicator has expired.

Evidence
  • Indicator register: old file hash expired yesterday
  • Canary: no legitimate workflow uses the credential
  • Build server: service account accessed decoy, then requested a privileged token
Reason it through

The expired hash should not drive the decision, but the high-fidelity canary sequence supports containment and token scoping.

Expected result

Disable the exposed token path, preserve service-account and decoy logs, and investigate how the build server reached the share.

Optional practice
Reasoning self-check

A decoy API key is used to alter another tenant's record after an old malware hash expires.

  • Hash: no current sightings
  • Canary key: no legitimate owner; access logged
  • API: tenant identifier changed and audit actor preserved
  1. Build a short evidence table that separates observations, supported conclusions, and remaining unknowns.
  2. Choose the authorized action that tests the leading conclusion with the least operational impact.
  3. Compare your decision and reopen condition with the expected results before continuing.
Compare your reasoning
Expected answers
  • Prefer the behavioral canary sequence over the stale atomic hash, classify the modification as tampering, and use the authorized deception event to map assets and controls.
  • Reopen if the key had a legitimate workflow or if the API record shows a testing identity approved for the tenant.
If you got stuck
  • If the answer depends on a product name alone, return to the actual evidence it produced.
  • If no option can be falsified, name the missing record before choosing.

Compare your reasoning with the revealed answers if helpful. The block check below is required for course progress.

Technical references

Required block check · Block 6

Required for course progress · Pass with 3 of 3 correct

This records your study. Passing the check is still required for course progress.
Optional recap

Review this lesson

Use only this lesson's worked example and key concepts for a quick self-check.

  1. Restate the worked example in your own words.
  2. Name the lesson concepts that explain the result.
  3. Explain why the closest alternative does not fit.
Your next milestone

Check the whole objective

This unlocks objective 1.4 for recall. The latest checkpoint needs 70% or higher; a lower result puts the lesson back near the front of your timeline.

Complete the lesson checks first.A score of 70% or higher advances the course. Today shows the remaining requirements for your daily goal.
Official blueprint references
CompTIA CySA+ CS0-004 V4 exam objectives, version 2.0CompTIA ↗CompTIA CySA+ V4 official exam overview and parent objectivesCompTIA ↗
Report an issue with this lesson

Your report is private to you and the review team because lesson exercises can contain answers.