Indicators of compromise (IoC) vs. anomalies: How to detect attacks at an early stage?

Detecting cyber threats resembles detective work at a crime scene. Sometimes the evidence is obvious and tangible – a discarded tool, fingerprints on a doorknob or shoe tracks leading away from a broken window. In the world of cybersecurity, these hard evidence are Indicators of Compromise (IoC). These are known “bad” elements, such as the IP address of a hacker’s server or the hash of a malicious file. Finding them is unequivocal confirmation that an intrusion has occurred. Traditional defenses over the years have relied precisely on finding these known traces.

However, the best detectives know that the most dangerous criminals do not leave obvious traces of themselves. Instead, their presence is betrayed by subtle, small things that “don’t match” their surroundings – a chair rearranged by a few inches, documents on a desk in a different order, an open window in an office closed for the night. That’s what anomalies are. In cyber security, relying solely on the search for known IoCs is a strategy doomed to fail against advanced adversaries. Modern, mature defenses must evolve to detect anomalies – subtle deviations from the norm that are the first, silent signal that something bad is going on in our network.

What are indicators of compromise (IoCs) and why are they the foundation of traditional detection?

Indicators of Compromise (IoC) are digital artifacts or evidence that indicate with high probability that a security breach has occurred on a system or network. They are specific, measurable and unambiguous “footprints” left by an attacker or its malware. IoCs are the cornerstone of the traditional reactive approach to threat detection, as they identify known attacks based on their characteristics.

The mechanism behind IoC-based detection is simple. Security teams and analyst firms around the world, after analyzing a new attack, publish lists of indicators found. Then, administrators and security systems (such as antivirus, firewalls or SIEM) can search their environments for the exact same indicators. If a particular indicator is found, it is almost certain proof that the organization has also fallen victim to the same campaign. This approach is extremely valuable for detecting massive, well-studied threats.

What are the most common types of IoC indicators and where to look for them?

IoC indicators can take many forms, depending on the nature of the attack. Among the most common and used in the daily work of SOC analysts are:

• Malicious file hashes: Hash values (e.g. MD5, SHA-1, SHA-256) for known viruses, ransomware or backdoors. Analysts can scan file systems for files with matching hashes.
• IP addresses: IP addresses of Command & Control (C2) servers that malware connects to, or addresses used to carry out scans and attacks. These can be looked for in firewall, proxy or NDR system logs.
• Domain names: Internet domain names used by attackers to host malware, phishing sites or as endpoints for C2 communications.
• URLs: Full URL paths leading to malicious content, often found in phishing messages.
• Registry keys or file names: Characteristic Windows registry keys or file names created by specific malware families to ensure persistence.

The sources of these indicators are usually Threat Intelligence Platforms, public databases and reports published by government agencies (such as national CSIRTs) and cybersecurity companies.

What are the key limitations of an IoC-only defense strategy?

A defense strategy based solely on searching for known indicators of compromise has one fundamental limitation: it is inherently reactive. In order for a given IoC indicator to be used for detection, someone else must first fall victim to the attack, analyze it and publish its characteristics. This means that organizations relying only on IoC are only able to detect attacks that are already known, described and cataloged.

This approach is completely helpless against new, unknown threats (zero-day attacks) and attacks carried out by advanced, discrete groups (APTs). Sophisticated adversaries go to great lengths to make each of their campaigns unique. They use custom-created malware that has no known hash. They use newly registered domains and dedicated server infrastructure whose IP addresses are not on any blacklist.

Moreover, IoC indicators are very easy for an attacker to change. Changing the IP address of a C2 server or a minor modification of the virus code that completely changes its hash is a trivial task for a hacker. Relying solely on the IoC is like trying to catch a criminal who changes his car, clothes and appearance after every action. We will always be one step behind.

What is an anomaly in the context of cyber security and why is it important to detect it?

An anomaly is an event or pattern of behavior that significantly deviates from the established, “normal” operating pattern of a particular user, device or network. Unlike IoC, which is unequivocally “bad,” an anomaly is not in itself evidence of an intrusion. It is a signal that something abnormal has happened that requires further investigation. Anomaly detection is the foundation of a proactive approach to security.

Anomaly detection is so important because it identifies unknown and advanced threats that do not leave obvious, cataloged traces. An advanced attacker who has infiltrated a network may not be using known malware, but his actions will inevitably generate anomalies. An administrator logging on to a server at 3 a.m. while it normally runs from 9 a.m. to 5 p.m. is an anomaly. An HR workstation that suddenly starts scanning ports on development servers is an anomaly.

A strategy based on anomaly detection does not ask “do I see something I know to be wrong?” but asks “do I see something that deviates from the norm?”. This is a fundamental change that makes it possible to detect an attacker at a very early stage, often already during the reconnaissance or lateral movement phase, long before it has time to reach its target.

How do security systems learn what is “normal” network behavior?

The ability to detect anomalies is based on having a reliable model of what is “normal.” Modern security systems, such as NDR (Network Detection and Response) and UEBA (User and Entity Behavior Analytics) platforms, use advanced machine learning techniques to do this.

The process begins with a learning phase. Once deployed, the system passively observes and analyzes all activity in the monitored environment for a period of time (e.g., several weeks). It learns which users normally log into which systems, from which locations and at what times. It creates a baseline model of normal network traffic: what protocols are being used, what servers are communicating with each other, how large the data transfers are.

Once the learning phase is over, the system enters detection mode. From then on, each new activity is compared in real time with the learned model. The system does not need rigidly defined rules. It can notice on its own that a sudden increase in outgoing data transfer from a file server is a statistically significant deviation from the norm, or that trying to log in to 100 different accounts from one computer in a minute is behavior that has never happened before. It is this ability to dynamically learn and adapt to a company’s unique environment that is the strength of this technology.

From IoC to TTPs: why is understanding “how” the enemy attacks more important than “what”?

As security operations mature, SOC teams are undergoing an evolution in their thinking – from focusing on IoC indicators, to focusing on TTPs (Tactics, Techniques and Procedures). This model, popularized by the MITRE ATT&CK framework, describes the behavior of attackers, not just the tools they used.

• IoC (indicators) is the lowest and least valuable level of information. A file hash or IP address are trivial for an attacker to change. Blocking one IoC pointer stops only one specific instance of the attack.
• TTPs (behaviors) are a much higher level of abstraction. They describe how attackers achieve their goals, regardless of the tools used. For example, the technique “Stealing credentials from the LSASS process” is a TTP. An attacker can accomplish it with the Mimikatz tool, but he can also use dozens of other non-standard tools.

A mature security team, instead of asking “do I see in the logs the hash of the Mimikatz.exe file?”, asks “do I see in the logs any process that tries to access the memory of the LSASS process in an unusual way?”. TTPs-level detection is much more resistant to tool changes by attackers. It allows the creation of detection rules and threat-hunting hypotheses that will remain effective even when brand new, unknown malware emerges.