b2KIT

IOC (Indicator of Compromise) Extractor

Extract IOCs from threat reports: IP addresses, domains, URLs, file hashes, email addresses, and Bitcoin wallets.

Tested tool guide Tested browser tools Checked August 16, 2026

What IOC (Indicator of Compromise) Extractor does and how it behaves

Paste a threat report, alert narrative, or analyst note, and the IOC Extractor pulls out strings that look like IP addresses, domain names, URLs, file hashes, email addresses, and Bitcoin wallet addresses. It separates the matches by indicator type, turning narrative reporting into a reviewable set of observables. Processing stays in the browser, which matters when reports contain sensitive incident details. The important limitation is that extraction is not threat validation: a matched address or hash is only a candidate IOC, not proof that it is malicious.

How the result is produced

1

From prose to indicators

The input is unstructured text rather than a fixed IOC schema. The tool examines the pasted material for recognizable values in its supported categories and presents those matches as extracted indicators. Surrounding prose is not part of an IOC. A single report can therefore yield network locations, file identifiers, contact addresses, and cryptocurrency addresses in one pass.

2

Meaning of each category

Read each result according to its category. A URL is a complete resource locator, while a domain or IP address identifies a host or network endpoint. A file hash is a digest-shaped identifier, an email address identifies a mailbox, and a Bitcoin address is a payment identifier. These labels do not retain the report's allegation, confidence, attribution, or time context.

Good uses

  • Pull command-and-control domains, IP addresses, payload URLs, and file hashes from a malware report before investigating them in security systems.
  • Convert incident notes or copied alert text into a compact IOC list for searches across logs, endpoint telemetry, and network records.
  • Collect hashes, contact emails, and Bitcoin addresses from ransomware reporting while keeping the surrounding report available for contextual review.

Limits and checks

  • Review every match against its source sentence. Version numbers, hexadecimal identifiers, example domains, cited email addresses, and other benign text can resemble IOCs.
  • Do not assume that values appearing together share an owner or campaign. A report may mention attacker infrastructure, victims, researchers, vendors, and harmless examples.
  • Treat the assigned category as a description of the string, not external verification. A hash does not reveal what was hashed, and a Bitcoin address does not establish ownership or transaction history.

Common questions

Does the extractor determine whether an IOC is malicious or still active?

No. It collects candidate indicators from the supplied text; extraction alone cannot establish reputation, ownership, reachability, or current activity. Confirm each value using the report's context and appropriate investigative sources. This is especially important for shared hosting, public email services, legitimate domains abused temporarily, and indicators copied from historical reporting.

Can I paste the extracted values directly into a blocklist?

Not without review. The output can include references that should not be blocked, such as researcher addresses, victim infrastructure, example values, or legitimate services mentioned in the report. Blocking a full URL, domain, or IP address also has different operational consequences. Validate scope, context, freshness, and likely collateral impact before using any extracted value as an enforcement rule.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools