RECOGNISE THE SIGNALCommon IOC examples
A malicious file hash identifies a specific file's contents. A domain or IP address may identify infrastructure used in an attack. Suspicious persistence entries, unexpected executable paths or unusual account changes can also be valuable clues. Each indicator needs a source, an observation time and a clear reason for being considered suspicious.
Indicators have different limitations. Changing a file changes its hash. An IP address can host unrelated customers or later belong to somebody else. A once-malicious domain can change ownership. Record when an indicator was observed, check its relevance to your environment and avoid treating an old threat-intelligence entry as permanent proof.
CONNECT THE EVIDENCEEvidence correlation and timelines
Correlation connects relevant observations across systems. For example, an unexpected sign-in, a suspicious process on the same user's device and a connection to attacker infrastructure may support one investigation. Match the account, device and time window, not just a similar-looking label. Verify that the clocks and event timestamps make sense before building a timeline.
Endpoint logs can show process execution and file activity. Identity logs can show authentication and access changes. DNS, proxy and firewall records can describe network destinations. Cloud audit logs can show changes to resources and permissions. Missing telemetry is a visibility gap, not proof that nothing happened. Preserve the original records and distinguish direct observations from assumptions.
BEHAVIOUR MATTERSIOCs, behaviours and threat hunting
Exact indicators help find known artefacts. Behaviour-based detections look at what an actor does, such as a sequence of suspicious process execution, credential access and unusual outbound connections. MITRE ATT&CK describes adversary tactics and techniques that help teams organise these observations. A technique match still requires investigation; it is not an automatic attribution to a particular attacker.
Threat hunting starts with a defensible question and checks the available evidence. A hunter might ask whether an account's new privileges were followed by unexpected access to sensitive data. Define the scope, compare with normal activity and document both supporting and contradictory evidence. Explore the Threat Hunter game for another defensive learning theme.
CHECK THE CONTEXTFalse positives are not harmless noise
A false positive flags legitimate activity as malicious. An administrator may use the same remote-management tool as an attacker. A shared hosting address may appear in both safe and malicious connections. Check the owner, approved change records, business purpose and surrounding events before deciding whether an alert needs containment or can be closed.
Reducing noise should not mean switching off inconvenient detections. Document why a finding was benign, tune the rule narrowly and keep a way to review unexpected changes. False negatives are the opposite problem: malicious activity goes undetected. No single indicator feed or matching rule provides complete coverage.
RESPOND WITH EVIDENCEFrom suspicious clue to incident response
Validate the signal, identify affected accounts and systems, assess impact and follow the organisation's incident-response procedure. Preserve useful evidence before making changes where practical. Containment decisions need appropriate authority and an understanding of operational impact. Blocking a destination alone may not remove persistence or recover a compromised account.
After containment, address the cause, restore trustworthy operations and review how the incident was detected. Useful lessons might include better logging, narrower permissions or improved monitoring. For accessible explanations of alert triage and investigation, read the DirtyPhish cybersecurity articles.
PUZZLE, NOT A SCANNERWhat the game represents
Indicator Factory uses original 3D locks, shields, servers, keys and bugs as recognisable symbols. Matching three is a puzzle rule, not a real-world investigation threshold. The game does not scan files, inspect traffic or detect compromise on your device. It is not a certification exam or a replacement for security tools.
Tap exposed objects, complete triples and clear twelve shifts before your limited tray fills. Rotate the camera to inspect the board and use Undo, Shuffle or Hint when needed. The educational connection is deliberate observation and planning. Real investigations require evidence quality and context, not simply matching three symbols.
ORIGINAL LEARNING SCENARIO // FICTIONAL IOC WALKTHROUGHOne destination hit, two possible explanations
A fictional threat feed flags a destination contacted by laptop L-7 at 10:04 UTC. The destination uses shared hosting. A match establishes that the logged connection occurred, not that the laptop was compromised.
Check the chain: preserve the DNS and connection records, identify the process that initiated the connection and compare the account and timestamps with endpoint events. Confirm what the feed actually observed and how recently.
Explanation A: the browser opened an approved supplier website on shared infrastructure. Matching proxy history and the user’s work task support that explanation. The shared address alone is insufficient grounds to label the device infected.
Explanation B: an unexpected executable in a temporary directory made repeated connections after an unapproved account change. Correlating those events raises the priority, but the analyst must still check the executable and account activity before declaring the cause.
Document the evidence for and against each explanation and any missing logs. Escalate under the organisation’s procedure when the risk warrants it. There is no real-world rule that three matching objects prove an incident. For a fuller synthetic queue, read the worked SOC triage example.
