Cyber Security Quiz: Indicators Of Compromise Iocs

10 questions · exam conditions

0:00

Indicators Of Compromise IocsQuestion 1 of 10

A threat-intelligence feed identifies an IP address as command-and-control infrastructure. A proxy search shows that 40 employee devices connected to the address during the previous week. The address belongs to a large cloud-hosting provider that uses shared front-end infrastructure.

Which additional finding would provide the strongest evidence that one of the devices is compromised?

The device transferred more data to the address than the other employee devices did.

The device contacted the address outside the organization's normal business hours.

An unusual process contacted a threat-linked domain resolved to the address at that time.

A user on the device had previously visited another site hosted by the provider.

← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Indicators Of Compromise Iocs

Practice Indicators Of Compromise Iocs in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Indicators Of Compromise Iocs, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

Which additional finding would provide the strongest evidence that one of the devices is compromised?

The device transferred more data to the address than the other employee devices did.
The device contacted the address outside the organization's normal business hours.
An unusual process contacted a threat-linked domain resolved to the address at that time. (correct answer)
A user on the device had previously visited another site hosted by the provider.

Explanation: When investigating a potential compromise, you need to distinguish between behavioral anomalies and true indicators of compromise (IoCs). The challenge here is the shared infrastructure — because a large cloud provider hosts thousands of customers at that IP, a device connecting to it doesn't automatically mean it's reaching malicious infrastructure. You need evidence that ties a specific device to the malicious portion of that shared address space. That's exactly what C provides. An unusual process contacting a threat-linked domain that resolved to that IP at that time is highly specific: it identifies the actual application making the connection, flags it as suspicious (unusual process), and links it directly to the known malicious domain — not just the shared IP. This is corroborating host-level forensic evidence that strongly suggests compromise, because legitimate software wouldn't be reaching a flagged C2 domain. A is tempting but weak. Higher data volume could indicate exfiltration, but it could also mean a legitimate application simply used the service more heavily. Volume alone isn't attribution. B is similarly inconclusive — after-hours activity is a soft anomaly that many legitimate automated processes (backups, software updates) produce. It warrants investigation but proves nothing. D is essentially irrelevant; visiting another site on the same hosting provider has no meaningful relationship to whether a device is communicating with C2 infrastructure. The strategy here: when a question involves shared infrastructure, single-point behavioral anomalies (timing, volume) are weak evidence. The strongest evidence always combines a specific malicious artifact (domain, process, signature) with contextual corroboration — that's what C delivers.

Question 2

Network monitoring identifies a workstation making one short encrypted connection every 60 seconds. The organization uses several legitimate agents that also communicate on fixed schedules.

Which additional observation would most strongly distinguish command-and-control beaconing from normal agent traffic?

The connections use a common destination port that is permitted by the outbound firewall.
The traffic continues while the workstation is idle and no user is locally signed in.
An unsigned process makes the connections to a newly registered domain rarely seen in the organization. (correct answer)
The connection intervals vary by several seconds when the workstation experiences heavy processor usage.

Explanation: When analyzing suspicious network traffic, you need to think about indicator stacking — a single observation rarely proves malicious intent, but combining multiple suspicious traits (unsigned code + unknown destination + new domain) creates a profile that legitimate tools almost never match. C is the strongest distinguishing factor because it layers three independent red flags simultaneously: an unsigned process (legitimate enterprise agents are code-signed), connecting to a newly registered domain (threat actors frequently register fresh domains to avoid reputation blocklists), and a destination rarely seen in the organization (legitimate agents communicate with known, recurring infrastructure). No legitimate monitoring agent should exhibit all three of these traits together, which is precisely why this combination points so decisively toward malicious beaconing rather than normal agent behavior. Option A actually weakens the malicious hypothesis — attackers commonly abuse permitted ports (443, 80) to blend in, but so does every legitimate agent. A permitted port tells you almost nothing about intent either way. Option B is tempting because malware that phones home while a user is logged out does sound suspicious. However, many legitimate agents — patch managers, endpoint detection tools, backup clients — run as system services and beacon continuously regardless of user login state. This alone doesn't distinguish anything. Option D describes normal, expected behavior for legitimate agents. Fixed-interval beaconing from malware often does jitter slightly, but so does any scheduled process on a loaded system. Interval variance on a busy CPU is a sign of a normal scheduler, not evidence of anything malicious. Your study tip: when a question asks what most strongly distinguishes malware from legitimate traffic, favor answers that combine multiple independent indicators — no single data point is as powerful as several converging anomalies.

Question 3

An employee receives an email displaying the name of the company's chief financial officer. The message requests an urgent wire transfer. It passed sender-policy checks for the domain that actually sent it, but the Reply-To address uses a one-day-old lookalike domain. No attachment is present.

Which feature is the most meaningful IOC in this scenario?

The message uses the chief financial officer's display name in the From field.
The message contains no attachment despite requesting an urgent financial action.
The sending domain passed authentication checks for the domain it claimed to represent.
The Reply-To address redirects responses to a newly created lookalike domain. (correct answer)

Explanation: When evaluating phishing scenarios, your job is to identify the most meaningful indicator of compromise (IOC) — the one that most clearly signals malicious intent rather than something ambiguous or normal. The standout IOC here is captured in D. A Reply-To address pointing to a one-day-old lookalike domain is a textbook business email compromise (BEC) signal. Attackers use this technique precisely to bypass authentication: they send from a legitimate or passable domain (so SPF/DKIM checks pass), but redirect replies to an attacker-controlled domain. The domain's age — just one day old — is a strong technical red flag, since threat actors register throwaway domains immediately before campaigns and abandon them quickly. This combination of lookalike spoofing plus brand-new registration makes D a high-confidence, specific IOC. A is a distractor because display names in the From field are trivially spoofed and carry no authentication weight whatsoever. Seeing an executive's name there is expected in BEC attacks but isn't itself an IOC — it's just how email works. B actually argues against malicious activity by normal heuristics. Many security filters flag attachments; attackers often deliberately omit them to avoid detection. The absence of an attachment is not an IOC. C is the sneakiest trap. Passing SPF authentication means the sending domain authenticated correctly — but that domain may still be attacker-controlled or unrelated to the real CFO's organization. Authentication passing is neutral, not exculpatory. Study tip: On security exams, when multiple features seem suspicious, prioritize IOCs that are specific, verifiable, and technically meaningful — domain age and lookalike registration fit that criteria far better than display-name tricks or the absence of expected malicious elements.

Question 4

Malware found on several endpoints has a different cryptographic file hash on each host because the attacker recompiles the payload for every deployment. Despite the hash changes, each sample is launched by a document editor, creates the same scheduled task, and contacts a domain with a newly generated subdomain every five minutes.

Which detection approach is most likely to remain useful across future variants?

Block only the cryptographic hashes collected from the currently infected endpoints.
Alert on the recurring process chain, persistence action, and network pattern together. (correct answer)
Block every document that has a creation time matching an infected file.
Alert whenever any endpoint establishes an outbound connection every five minutes.

Explanation: When analyzing malware detection strategies, you should always ask yourself: what stays constant across variants? Attackers frequently change surface-level indicators — like file hashes — to evade signature-based detection. The more durable detection targets are behaviors: how the malware runs, what it does to the system, and how it communicates. This scenario describes a polymorphic-style threat where the hash changes every deployment, but three behavioral patterns remain stable: the process chain (document editor spawning the payload), the persistence mechanism (a scheduled task), and the network pattern (domain generation with periodic beaconing). Combining all three into a single behavioral detection rule, as B describes, creates a high-fidelity alert that survives recompilation entirely — because the attacker would have to redesign their entire operation, not just recompile, to evade it. A is a classic trap: blocking only the known hashes is reactive and immediately obsolete. The next variant has a new hash, and your block does nothing. This is why hash-only detection fails against polymorphic malware. C is a logical stretch — file creation timestamps are easily manipulated and don't reliably identify malicious files; this would produce enormous false positives and miss most variants anyway. D sounds behavioral but is dangerously over-broad: countless legitimate applications (backup tools, monitoring agents, sync clients) make outbound connections on regular intervals. This rule would flood analysts with noise and quickly get disabled. The study tip here: on exam questions about malware detection, behavior-based indicators outlast artifact-based indicators. If an answer relies on a static artifact (hash, timestamp, filename), it's almost always inferior to one targeting consistent behavioral patterns.

Question 5

A security team receives an alert that a public IP address associated with the organization contacted a known malicious server. Thousands of internal devices share that public address through network address translation.

What is the most appropriate next step for identifying the potentially compromised device?

Quarantine every device that used the public address during the alert date.
Search translation and flow records using the timestamp, ports, and destination details. (correct answer)
Assign the alert to the device that generated the most outbound traffic that day.
Treat the public source address as sufficient proof that the perimeter firewall is compromised.

Explanation: When a public IP is shared by thousands of devices through NAT, the public address alone tells you almost nothing about which internal device initiated a suspicious connection. This question tests your understanding of how to trace activity back through NAT infrastructure using available logging data. The right move is B — searching translation and flow records using the timestamp, destination IP, destination port, and source port from the alert. NAT devices (firewalls, routers) maintain state tables that map each internal private IP and ephemeral port to the corresponding public-facing connection. By cross-referencing the alert's exact connection details against those logs, you can pinpoint the specific internal host responsible. This is precise, evidence-driven, and non-disruptive. A is an overreaction that violates proportionality. Quarantining thousands of devices based on shared address use would cause massive operational damage with no investigative basis — you'd be punishing devices that may have had completely unrelated traffic through that public IP at the same time. C introduces a flawed assumption: high outbound traffic volume has no established correlation with contacting a specific malicious server. The offending device could have sent a single small beacon and gone quiet, while a legitimate backup server generated the most traffic that day. D confuses source attribution with perimeter compromise. A device behind the firewall initiated the connection; the firewall translated it outward. That's normal NAT behavior, not evidence the firewall itself is breached. Study tip: On incident response questions involving NAT environments, always think "timestamp + ports + destination = identity." Those three data points are your key to cutting through shared address ambiguity.

Question 6

Responders remove an unauthorized startup entry from a server and confirm that it no longer appears in the configuration. Two hours later, an identically named entry returns and points to a newly created executable with a different file hash.

What does the reappearance most strongly indicate?

The original startup entry was a false positive because its file hash has changed.
A legitimate update replaced the file because startup entries commonly regenerate themselves.
An active persistence mechanism or uncompromised component is recreating the removed artifact. (correct answer)
The server is fully remediated because the exact executable originally identified is gone.

Explanation: When malware persists on a system, it rarely relies on a single artifact. Sophisticated threats deploy persistence mechanisms — background processes, scheduled tasks, registry watchers, or secondary implants — whose sole job is to monitor for removed components and silently reinstall them. This scenario is a textbook example of that behavior, and recognizing it is fundamental to incident response. The reappearance of an identically named entry pointing to a different hash is the critical detail. The original file is gone, but something on the system detected that removal and deployed a fresh executable. This is precisely what C describes: an active, unremoved component is recreating the artifact. The threat actor anticipated remediation and built in a self-healing mechanism, meaning the server is not fully cleaned — the dropper, scheduler, or watcher process is still running. A has the logic backwards — a changing hash doesn't make the original a false positive; it actually confirms malicious behavior, since legitimate software doesn't regenerate itself with new binaries after deletion. B is tempting if you're unfamiliar with malware persistence, but legitimate software updates don't covertly recreate startup entries with new file hashes two hours after manual removal — that's not how patching works. D is dangerously wrong and represents exactly the kind of premature closure that leaves organizations re-compromised; the absence of the original file does not mean the threat is gone. A useful rule of thumb for incident response questions: if a removed artifact returns, the root cause was never addressed. Always ask what dropped the artifact, not just whether the artifact itself is gone.

Question 7

Six months ago, a domain was used to distribute malware. It was later seized, allowed to expire, and registered by a security research organization. An analyst now finds the domain in a workstation's DNS cache.

Which conclusion is best supported by this finding?

The cache entry is historical evidence that should be validated against timing and current domain ownership. (correct answer)
The workstation is actively compromised because malicious domains remain definitive IOCs after reassignment.
The security research organization is distributing the same malware through the newly registered domain.
The cache entry is harmless because DNS information can never indicate endpoint compromise by itself.

Explanation: When you encounter IOC (Indicator of Compromise) analysis questions, the key skill being tested is your ability to evaluate context and currency — an IOC is only meaningful when interpreted alongside timing, ownership history, and current threat intelligence. Here, the domain has a layered history: malicious origin, seizure, expiration, and legitimate re-registration. A DNS cache entry simply records that a lookup occurred — it doesn't tell you when it happened or who currently owns the domain. The responsible analyst move is to cross-reference the cache timestamp against the malware campaign's active window and confirm current ownership before drawing conclusions. That's exactly what A describes, making it the best-supported conclusion: treat the finding as a lead requiring validation, not a verdict. B is dangerously overconfident. Domains are reassigned routinely — a domain that was malicious six months ago is not a "definitive IOC" after it changes hands. Treating reassigned domains as permanently tainted would generate massive false positives and erode trust in your threat intel. C makes an unsupported leap. There is zero evidence the research organization is distributing malware; they commonly register expired malicious domains specifically to prevent continued abuse or to conduct sinkholing research. D swings to the opposite extreme. While a single DNS cache entry isn't conclusive proof of compromise, dismissing it entirely is poor security practice — DNS anomalies are a recognized detection vector and absolutely warrant investigation. The broader study tip: on cybersecurity exams, watch for answers that treat intelligence artifacts as either always definitive or completely meaningless. The correct answer almost always involves contextual validation.

Question 8

Identity monitoring reports that an employee successfully authenticated from Germany and then from Canada 12 minutes later. Both authentications used multifactor authentication. The employee confirms using a corporate VPN whose traffic may exit from either country.

How should the geographic login pattern be interpreted?

It proves credential theft because physical travel between the countries is impossible in 12 minutes.
It proves the VPN is compromised because multifactor authentication succeeded from both countries.
It should be ignored because geographic indicators cannot apply when a VPN is in use.
It is a low-confidence anomaly that requires corroboration from device, session, or account activity. (correct answer)

Explanation: When you encounter anomaly detection questions on a security exam, the key concept to apply is confidence calibration — distinguishing between indicators that prove malicious activity versus indicators that suggest it and warrant further investigation. This question tests whether you understand how contextual factors (like VPN use) affect the evidentiary weight of a security signal. The geographic impossibility — Germany to Canada in 12 minutes — would normally be a strong indicator of credential theft. However, the employee has provided a legitimate technical explanation: a corporate VPN whose exit nodes span multiple countries. A single authentication session can appear to originate from Germany while the next exits through Canada, with no physical travel required. This doesn't clear the alert; it simply reduces its confidence level. The right response is to treat it as a low-confidence anomaly requiring corroboration from other signals — unusual device fingerprints, abnormal session behavior, privilege escalation attempts, or account changes. That's exactly what D describes. A commits the trap of treating a geographic anomaly as conclusive proof despite a credible technical explanation. Impossible travel can indicate credential theft, but it doesn't prove it when a VPN is in play. B makes an unsupported logical leap — MFA succeeding from two locations doesn't implicate the VPN infrastructure itself; it could simply reflect normal VPN behavior. C goes too far in the opposite direction, suggesting geographic signals should be discarded entirely when a VPN is involved. Anomalies still matter; they just carry less weight without corroboration. Your study tip: watch for questions that present anomalies alongside legitimate technical explanations — the correct answer will almost always involve investigation, not conclusion.

Question 9

During triage, analysts review four endpoints. Endpoint 1 queried a threat-listed domain once, but the domain now hosts legitimate content. Endpoint 2 ran an unsigned utility installed by an administrator. Endpoint 3 had repeated failed logins followed by a normal password reset. Endpoint 4 launched a rare archiving process, created a large encrypted archive, and then uploaded it to a newly registered external domain.

Which endpoint should receive the highest investigation priority based on IOC strength and correlation?

Endpoint 1, because any historical domain-list match is sufficient to establish current compromise.
Endpoint 2, because unsigned software is inherently malicious even when administratively installed.
Endpoint 3, because failed authentications followed by a password reset prove account takeover.
Endpoint 4, because host and network indicators combine into a plausible exfiltration sequence. (correct answer)

Explanation: When triaging multiple endpoints, your goal isn't to flag anything unusual — it's to identify which activity forms a coherent, high-confidence attack narrative. Single indicators are weak; correlated indicators that tell a logical story are what demand immediate attention. Endpoint 4 is the clear priority because three independent indicators — a rare process execution, large encrypted archive creation, and upload to a newly registered domain — chain together into a textbook data exfiltration sequence. Each step reinforces the others: attackers commonly compress and encrypt stolen data to obscure content, then exfiltrate to infrastructure they freshly registered to avoid blocklists. This correlation dramatically raises confidence that a real incident is underway, not a coincidence. The distractors each represent a common analytical trap. A commits the mistake of treating historical threat-intelligence matches as proof of current compromise. A domain leaving a blocklist and hosting legitimate content weakens that IOC considerably — context matters. B confuses "unsigned" with "malicious." Unsigned software is a weak IOC on its own, and the scenario explicitly notes administrative installation, which provides legitimate context. Flagging every unsigned binary would flood analysts with false positives. C is perhaps the trickiest distractor: failed logins followed by a password reset can indicate account takeover, but it also perfectly describes a user forgetting their password. Without additional post-reset suspicious activity, you cannot conclude compromise. The key study takeaway: on triage and prioritization questions, always look for indicator correlation and narrative coherence. A single weak IOC rarely justifies high priority. When multiple host and network indicators combine into a logical attack sequence, that correlation is your strongest signal.

Question 10

A cloud-account alert shows a successful sign-in from a device not previously associated with the user. Minutes later, the account creates an inbox rule that hides security notifications and grants a third-party application permission to read email. Endpoint monitoring finds no suspicious activity on the user's laptop.

Which interpretation best fits the combined indicators?

The account is likely compromised, but the evidence does not by itself establish endpoint malware. (correct answer)
The laptop is necessarily compromised because cloud-account misuse must originate from its endpoint.
The activity is likely benign because no known-malware hash was detected on the laptop.
The inbox rule is conclusive evidence that the third-party application's server is compromised.

Explanation: When analyzing cloud-account compromise scenarios, you need to separate what the evidence proves from what it suggests. Security indicators rarely give you certainty — they give you probability, and a good analyst reasons accordingly. Here, three indicators converge: an unfamiliar sign-in device, an inbox rule suppressing security alerts, and a third-party app granted email-read permissions — all within minutes. This combination is a classic Business Email Compromise (BEC) or OAuth abuse pattern. The attacker authenticated directly to the cloud service (likely through stolen credentials or a phishing token), then immediately blinded the victim and established persistence via an OAuth grant. Crucially, none of this required touching the user's laptop, because cloud identity attacks operate at the identity layer, not the endpoint layer. This confirms why A is correct: the cloud-side evidence strongly implies account compromise, but the clean endpoint telemetry is entirely consistent — it doesn't contradict the compromise, it just confirms the vector wasn't the laptop. B is wrong because it assumes cloud-account misuse must originate from a local device. Attackers routinely authenticate to cloud services from their own infrastructure using stolen tokens or credentials — the victim's laptop may never be involved. C is wrong because absence of a known-malware hash tells you nothing about cloud-layer attacks. No endpoint malware is needed to abuse stolen credentials or OAuth tokens. D is wrong because the inbox rule demonstrates attacker-controlled account behavior, not a compromise of the third-party application's servers. Granting an app permission is an account action, not evidence the app itself was breached. Study tip: On questions mixing cloud and endpoint evidence, always ask: which layer was actually attacked? Cloud identity attacks leave no endpoint footprint by design.