A SOC analyst gets a single line from a threat feed: one file hash, one IP address, one domain. Those three strings turn into a hunt across ten thousand endpoints, and within an hour the analyst can say which machines touched the malware, where it called home, and what it dropped on disk. The whole discipline of detection runs on small, concrete facts like these, and knowing what each one proves, and what it doesn't, is the difference between catching an intrusion and chasing noise.
These concrete facts are indicators of compromise, or IoCs. On the CompTIA Security+ SY0-801 exam this sits under objective 2.5, which asks you to analyze indicators of malicious activity given a scenario. This lesson covers the atomic indicators, the ones that are a single observable artifact: file hashes, IP addresses, domains, malicious processes, file-system artifacts, timestamps and plaintext strings, plus the Linux commands that surface them on a live host. It ends with a worked triage of a suspect host so you can see how several weak indicators combine into a strong conclusion. The behavioral indicators, lockouts, impossible travel, concurrent sessions and log tampering, are the next lesson.
An indicator of compromise is an observable fact that an intrusion happened
An indicator of compromise is a piece of evidence that a system has been breached: something you can observe, record and search for. Analysts distinguish indicators by how specific and how durable they are. A file hash is extremely specific but brittle: it identifies one exact file and nothing else, and it changes the moment the file changes. An IP address or domain is less specific and easy for an attacker to swap. A behavior, such as a process beaconing on a fixed interval, is the hardest for an attacker to change but also the fuzziest to pin down. Good detection uses all three levels, because each covers the others' weaknesses.
Two cautions matter for the exam and the job. First, an indicator is evidence, not proof: one IoC can be a false positive, and a benign program can trip a weak indicator. Confidence comes from correlation, several independent indicators pointing the same way. Second, indicators expire. A hash is good until the attacker recompiles, a domain until they register a new one. That is why organizations consume threat intelligence continuously rather than once. With those cautions in mind, work through the atomic indicators one at a time.
A file hash is the most precise indicator, but it breaks with one changed byte
A hash is a fixed-length fingerprint of a file's exact bytes. Run a known malware sample through SHA-256 and you get a value that identifies that file and only that file. Share the hash and anyone can search their environment for a byte-for-byte copy without exchanging the malware itself. That precision is the hash's strength: a match is nearly certain to be the same file, with essentially no false positives.
The same precision is its weakness. Change one byte, recompile with a different option, or repack the file, and the hash changes completely. This is why a hunt for a specific hash can come back empty even though the same malware family is present as a slightly different build. Attackers exploit this deliberately, producing many variants so no single hash catches them all. Use SHA-256 (MD5 and SHA-1 are still seen in older feeds but are broken for collision resistance, so treat them as identifiers of convenience, not trust anchors). Here is the everyday check, comparing a suspect file's hash against a feed:
PS> Get-FileHash -Algorithm SHA256 C:\Users\Public\u.tmp
Algorithm Hash
SHA256 3F1C9A7E4B...B72D9C
If that value appears on a trusted malicious-hash list, the file is confirmed malware. If it doesn't, you have not cleared the host; you have only ruled out that exact build. The limitation is the brittleness, not the algorithm, and the answer to it is to combine hashes with less brittle indicators.
IP addresses and domains reveal where malware calls home, but they are cheap to change
Malware usually needs to reach infrastructure: a command-and-control (C2) server for instructions, a drop site for stolen data, or a host serving the next payload. The IP addresses and domains it contacts are indicators you can block and hunt for. A known-bad IP in firewall or proxy logs, or a DNS query for a known-bad domain, places the malware's communication in your environment.
Both are easy for an attacker to rotate, so analysts watch for patterns, not just named-bad values. A domain registered days before it was used is suspicious on its own, because legitimate services rarely appear and start receiving traffic the same week. Algorithmically generated domains, long random-looking names that change daily, are a sign of malware using a domain generation algorithm to stay ahead of blocklists. Fast flux, where one domain resolves to a constantly changing set of IPs, is another. And traffic to a region or hosting provider your organization has no business with is worth a second look. DNS logs are especially valuable here, because even fileless malware usually resolves a name before it connects, unless it uses a hardcoded IP address, so the query is recorded even when little else is.
For the exam, remember the trade-off. Blocking a bad IP or domain is fast and useful, but an attacker can move to new infrastructure quickly, so these indicators age out. Reputation feeds, DNS monitoring, proxy logs and newly-registered-domain detection are the tools. Treat a hit as a strong lead to investigate the host behind it, not as the end of the story.