What is an IoC and why is it important in cybersecurity?

In cybersecurity, it is not always easy to tell whether something is malicious at first glance.

An external IP address, an unusual domain, an unknown file, a strange process or an unexpected connection can look like isolated events among all the activity that analysts review every day.

In some cases, however, those small signals are the clue that helps detect a threat, understand what happened and block malicious activity before it affects more systems.

That is where Indicators of Compromise, also known as IoCs, come in.

An IoC is a technical trace that may indicate that a system, network or account has been compromised. It is not necessarily the attack itself, but an observable piece of evidence that can help identify malicious or suspicious activity.

What is an IoC used for?

IoCs help security teams detect, investigate and respond to potential threats.

When activity matches a known IoC, the security team can use that information to:

• Identify potentially affected systems.
• Block connections to malicious infrastructure.
• Create detection rules in security tools.
• Investigate the scope of an incident.
• Document evidence for future investigations.
• Enrich alerts with Threat Intelligence context.

For example, if an organization detects connections to a domain associated with malware, that domain can be treated as an IoC. From there, the SOC can review which endpoints contacted that domain, block it and check whether related activity exists across other systems.

An IoC does not mean a confirmed attack

An important point is that an IoC does not always confirm an attack by itself.

An indicator must be analyzed in context.

For example, an IP address may appear as malicious in a public source, but that does not automatically mean every connection to it is a critical incident. The analyst should review other elements such as:

• Which endpoint made the connection.
• When it happened.
• Which user was authenticated.
• Which process generated the connection.
• Whether files were downloaded or executed.
• Whether similar events exist on other systems.
• Whether the IP is linked to known campaigns or malware.

The key is not just finding a strange IP, domain or hash. The key is understanding whether that trace is really connected to malicious activity.

Types of IoCs

IoCs can be classified by the kind of trace left by the attacker.

Open image zoom

Network IoCs

These are indicators related to communication between systems.

Examples include:

• Suspicious IP addresses.
• Malicious domains.
• Phishing URLs.
• Connections to unusual countries.
• Unusual ports.
• Anomalous traffic patterns.
• Communication with Command and Control servers.

Example:

185.XXX.XXX.XXX
malicious-domain[.]com
hxxp://example[.]com/payload.exe

File IoCs

These are indicators related to suspicious or malicious files.

Examples include:

• MD5, SHA1 or SHA256 hashes.
• Strange file names.
• Suspicious extensions.
• Unusual paths.
• Malware signatures.
• Files executed from temporary directories.

Example:

SHA256: 5f2d7c1b9a0e8f4c6d3b2a1e...
C:\Users\Public\update.exe
C:\Users\AppData\Local\Temp\invoice.scr

Hashes are especially useful because they identify a specific file. If the same hash appears on other endpoints, it may indicate that the same sample was executed or downloaded on several systems.

System IoCs

These are indicators that can be observed inside the operating system.

Examples include:

• Unknown processes.
• Services created without authorization.
• Suspicious scheduled tasks.
• Registry key changes.
• Persistence through unusual paths.
• Unauthorized user creation.
• Changes to critical configurations.

Example:

Process: update.exe
Path: C:\Users\Public\update.exe
Persistence: HKCU\Software\Microsoft\Windows\CurrentVersion\Run

Authentication IoCs

These are related to logins, credentials and user behavior.

Examples include:

• Multiple failed login attempts.
• Access from unusual locations.
• Credential use at unusual hours.
• Login from unexpected countries.
• Impossible travel activity.
• Abnormal use of privileged accounts.
• Compromised accounts.

Example:

User: admin.corp
Event: multiple failed authentication attempts
Source: unusual external IP
Time: 03:42 AM

This type of IoC is very important in corporate environments, especially when investigating brute force attacks, password spraying, credential theft or unauthorized access.

Email IoCs

These are indicators associated with phishing or malware campaigns delivered by email.

Examples include:

• Spoofed senders.
• Domains that imitate legitimate ones.
• Malicious attachments.
• Phishing links.
• Suspicious subjects.
• Manipulated email headers.
• Shortened URLs or redirects.

Example:

Sender: soporte@micros0ft-security[.]com
Subject: Urgent password update
Attachment: factura_enero.xlsm
URL: hxxps://login-microsoft-secure[.]com

Behavioral IoCs

These are indicators related to suspicious actions inside an environment.

Examples include:

• Unusual command execution.
• Lateral movement.
• Privilege escalation.
• Data exfiltration.
• Administrative tools used for malicious purposes.
• Payload downloads.
• Repeated connections to external infrastructure.

Example:

powershell.exe -ExecutionPolicy Bypass -NoProfile -EncodedCommand ...

Behavioral IoCs are often harder to detect, but they are very valuable because they can reveal attacker actions beyond a simple hash or domain.

IoCs in logs

Logs are a fundamental source for finding indicators during an investigation.

Examples include:

• Repeated events.
• Anomalous errors.
• Activity outside business hours.
• Access from unknown IPs.
• Unexpected configuration changes.
• Command execution.
• Suspicious process creation.

Example:

Event ID: 4625
Description: Failed logon
Source IP: 203.0.113.50
User: administrator

How are new IoCs detected?

New IoCs are usually discovered during a security investigation.

When an alert reaches the SOC, the analyst starts reviewing different sources to understand what happened:

• System logs.
• Network connections.
• Executed processes.
• Created or modified files.
• EDR events.
• SIEM alerts.
• Email headers.
• Reputation of IPs, domains or hashes.
• Behavior of the affected endpoint.

The key is finding evidence that can be reused to detect the same threat on other systems.

An IoC is created when suspicious activity becomes a useful technical trace.

Use case: from an alert to an IoC

Imagine a common scenario inside a SOC.

An alert arrives about a suspicious email containing an attachment. The user opened the file and, shortly after, the EDR detected the execution of an unusual process.

The analyst decides to review the sample in a sandbox such as ANY.RUN to observe its behavior in a controlled environment.

During the analysis, the file is observed to:

• Launch unexpected processes.
• Create files in temporary paths.
• Attempt to connect to an external IP.
• Execute suspicious commands.
• Communicate with an unusual domain.

Open image zoom

The analyst then checks the IP in a source such as AbuseIPDB and sees that it has been reported for malicious activity.

From the investigation, several IoCs can be extracted:

These indicators can be used to search for the same activity across other systems in the organization.

Open image zoom

What does a SOC do with IoCs?

When an IoC is confirmed, it is not just a technical data point. The SOC can use it to improve detection and response.

Open image zoom

Search for affected systems

The first step is usually to check whether other systems have activity related to the same indicator.

For example:

Have other endpoints connected to the same IP?
Does the same hash appear on more endpoints?
Has the suspicious domain been resolved by other users?
Has the process executed on more machines?

This helps measure the scope of the incident.

Create detection rules

Once the IoC has been validated, the team can create rules to detect whether it appears again.

These rules can be applied in:

• SIEM.
• EDR.
• Firewall.
• Proxy.
• IDS/IPS.
• DNS filtering.
• SOAR platforms.

Simple detection logic example:

IF destination_ip == "185.XXX.XXX.XXX"
THEN generate alert "Connection to known malicious IP"

A rule could also be created to detect a specific hash:

IF file.sha256 == "5f2d7c1b9a0e8f4c6d3b2a1e..."
THEN generate alert "Malicious file detected"

Block threats

If the indicator is confirmed as malicious, it can be blocked to reduce risk.

Possible actions include:

• Blocking an IP in the firewall.
• Blocking a domain in DNS filtering.
• Blocking a URL in the proxy.
• Isolating an endpoint from the EDR.
• Removing a malicious file.
• Blocking a hash.
• Revoking compromised credentials.

The goal is to prevent the threat from spreading or other systems from communicating with the same malicious infrastructure.

Enrich alerts

IoCs can also be enriched with additional Threat Intelligence.

For example:

• Indicator reputation.
• Country of origin.
• ASN.
• Associated malware.
• Related campaigns.
• First and last seen dates.
• Confidence level.
• Relationship with other indicators.

This helps the analyst prioritize and understand the threat better.

Document the incident

Documentation is a fundamental part of SOC work.

When an IoC is confirmed, it is important to record:

• Which indicator was found.
• Where it appeared.
• Which systems were affected.
• Which evidence supports it.
• Which actions were performed.
• Which rules were created.
• Which blocks were applied.
• Which recommendations should be followed.

Good documentation makes future investigations faster and helps other analysts understand the context of the incident.

Public sources for checking IoCs

Analysts do not rely only on internal tools. They can also consult public Threat Intelligence sources to validate indicators and obtain more context.

Some useful platforms are:

Example of IoC documentation

A basic IoC record could look like this:

Documenting an IoC correctly gives the team traceability and allows the information to be reused in future investigations.

Best practices when working with IoCs

Working with IoCs requires judgment. It is not enough to copy a list of indicators and block them without analysis.

1. Validate before acting

Not all indicators are equally reliable. Before blocking an IP, domain or hash, it is important to review its context.

2. Avoid false positives

A domain may be suspicious, but it could also belong to a legitimate service that was temporarily compromised. That is why additional evidence matters.

3. Prioritize by impact

Not every IoC has the same severity. An IP reported once does not have the same weight as a hash linked to an active malware family.

4. Enrich with multiple sources

Checking different Threat Intelligence sources helps build a more complete view.

5. Perform retrospective searches

When a new IoC is discovered, it is useful to check whether it had already appeared in the organization.

6. Always document

Documentation supports tracking, traceability and team learning.

7. Update detection rules

IoCs should be used to improve the defensive capabilities of the environment.

Conclusion

An IoC is not just a suspicious IP, domain, hash or URL.

It is a piece of information that, when analyzed and contextualized properly, can help understand what happened, detect other affected systems and improve the response to threats.

Inside a SOC, Indicators of Compromise are essential because they transform a technical trace into a defensive action: search, detect, block, enrich and document.

In cybersecurity, something that looks insignificant can become the key to understanding an entire incident.

Downloadable resource

If you want to keep the material as a reference, you can download the full PDF here:

Download PDF: What is an IoC?Abrir PDF / Open PDF