Free IOC extractor tool. Extract IP addresses, domains, URLs, file hashes, and email addresses from security logs and threat reports.
The raw material of incident work is prose. A vendor threat report, a customer's forwarded email, a SIEM alert body, a Slack thread, a PDF you pasted into a text box — the indicators you need are in there, scattered through paragraphs, half of them defanged so nobody clicks them by accident. Copying them out by hand is slow and it is where mistakes enter: a transposed character in a hash, a missed C2 domain in the fourth bullet, an IP you blocked that turned out to be a version number.
Paste the text here and the tool extracts every indicator it recognises, refangs the defanged ones, deduplicates them with an occurrence count, filters out the internal noise, and exports the result in the format your next system wants — plain text, CSV, JSON, STIX 2.1, OpenIOC or a YARA rule. Everything runs in your browser tab. The pasted text is never sent anywhere, which is the only acceptable arrangement for material that is usually TLP:AMBER at best.
| Type | How it is recognised |
|---|---|
| IPv4 | Dotted quad with each octet validated 0–255, plus a version-number heuristic |
| IPv6 | Full and compressed forms, including IPv4-mapped addresses |
| Domains | Labelled hostname whose TLD is on an allowlist of 40 common TLDs |
| URLs | http, https and ftp schemes, with optional port and path |
| Email addresses | Local part plus a domain that passes the same domain check |
| MD5 | 32 hex characters on word boundaries |
| SHA-1 | 40 hex characters |
| SHA-256 | 64 hex characters |
| SHA-512 | 128 hex characters |
| CVE identifiers | CVE-YYYY-NNNN with 4 to 7 digits, year sanity-checked against the CVE programme's 1999 start |
Each indicator is deduplicated case-insensitively and carries a count of how many times it appeared, so the address mentioned nine times in a report sorts above the one mentioned once. That ordering is genuinely useful when you are deciding what to block first.
Nobody publishes a live malicious URL in a report. They break it so that mail clients, chat apps and ticketing systems will not turn it into a clickable link, and so that a hurried reader cannot fat-finger their way onto a payload host. The conventions are informal but widespread: the scheme becomes hxxp or hxxps, dots are wrapped as [.], and an at-sign becomes [@] or [at]. A defanged indicator looks like hxxps://cdn-update[.]evil-c2[.]com/gate.php or 203.0.113[.]42.
Refanging — putting them back — is the first thing this tool does, before any pattern matching runs, so defanged indicators are extracted exactly like live ones. The substitutions applied are:
hxxp → http and hxxps → https (case-insensitive)[.] → .[dot] and (dot) → .[@] → @[at] and (at) → @That covers the overwhelming majority of what appears in real reports. It does not cover every variant in circulation. Escaped dots written as \., a defanged scheme separator written as [://], meow://, spaced-out dots (evil . com), or curly-quote artefacts from a PDF copy–paste will not be refanged and the indicator will be missed. If a report uses an unusual convention, one find-and-replace before pasting fixes the whole document at once.
Note the direction: this tool refangs on the way in. Its exports contain live, clickable indicators. That is what a blocklist or a SIEM import needs, but it means an exported file should be treated as hazardous material — do not paste it into a chat client that will linkify it. If you need to publish indicators in a document meant for humans, defang them again first with the URL defanger.
Every regex-based extractor over-matches, because the syntax of an indicator is not unique to indicators. Four filters run here to keep the noise down, and it is worth knowing exactly what each one does and does not catch.
Private and reserved addresses are excluded by default. RFC 1918 ranges — 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 — are dropped, as are loopback (127.0.0.0/8), 0.0.0.0/8, link-local (169.254.0.0/16), multicast (224.0.0.0/4) and the reserved 240.0.0.0/4 block. Two checkboxes turn each group back on, which you want when the interesting part of the story is lateral movement between internal hosts.
Version numbers that look like IPs are partly filtered. The heuristic rejects a dotted quad whose first octet is a year in 2000–2099, and any quad containing two or more octets equal to zero. So 2024.1.0.0 and 1.0.0.0 are correctly dropped. But 1.2.3.4 is a perfectly valid public address as well as a perfectly common version string, and it is extracted. Software versions in the 1.x–9.x range with four components will come through as IPv4 indicators. Scan the low-numbered results before you push them into a blocklist.
Domains are filtered by a TLD allowlist. Only 40 TLDs are accepted: com net org edu gov mil int io co ai dev app tech cloud info biz name pro xyz online us uk ca au de fr jp cn ru br nl es it in kr mx se no dk fi. This is what stops file names from becoming indicators — invoice.pdf, payload.exe and setup.dll match the shape of a domain but their extensions are not on the list. The cost is real: abuse-heavy TLDs that are not on the list, including .top, .zip, .su, .cc, .click and most newer gTLDs, will be silently skipped. If a report's C2 domains use one of those, pull them out by hand. Multi-part suffixes work correctly as long as the final label is on the list, so example.co.uk extracts. localhost and the RFC 2606 documentation domains (example.com, example.org, example.net, test.com) are always rejected.
Domains already inside a URL or an email address are suppressed. Without this you would get three overlapping indicators from one string. If the text contains https://cdn.evil-c2.com/gate.php, you get the URL and not a separate cdn.evil-c2.com domain entry; if it contains billing@evil-c2.com, you get the email address and not the bare domain. This keeps the output clean, but it is worth remembering when you expected a domain to appear and it did not — check whether it is already represented as a URL or an address.
One more class of false positive is not filtered at all: hexadecimal strings that are not file hashes. A 40-character hex string is indistinguishable from a SHA-1 by pattern alone, so git commit SHAs, database row hashes and cryptographic material in a log excerpt will all be reported as hash indicators. If you are unsure what a hex string is, the hash type identifier tells you which algorithms produce that length.
Paste this fragment, which mixes defanged and live indicators the way a real report does:
Beacon to hxxps://cdn-update[.]evil-c2[.]com/gate.php from 203.0.113.42
Second stage hosted at 198[.]51[.]100[.]7, C2 fallback backup[.]evil-c2[.]net
Dropper SHA-256 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
Phish sender billing(at)evil-c2[dot]com, exploited CVE-2023-23397
Internal host 10.4.2.19 was first to beacon. Agent version 1.2.3.4.
With default settings that yields eight unique indicators: three IPv4 (203.0.113.42, 198.51.100.7 and — a false positive — 1.2.3.4), one URL (https://cdn-update.evil-c2.com/gate.php), one domain (backup.evil-c2.net), one email address (billing@evil-c2.com), one SHA-256, and CVE-2023-23397. The internal host 10.4.2.19 is filtered as RFC 1918 until you tick "include private IPs". cdn-update.evil-c2.com does not appear as a separate domain because it is already inside the URL, and evil-c2.com does not appear because it is already inside the email address. Every defanged form — hxxps, [.], (at), [dot] — resolved correctly.
Above the results you can filter by indicator type and search within the values, and every export respects the current filter — so "export only the hashes" is a type filter followed by a download, not a manual edit afterwards.
Before exporting, you can attach analyst metadata to the set: a TLP marking (WHITE, GREEN, AMBER or RED), a confidence value from 0 to 100, a free-text description, comma-separated tags, a source, and an analyst name. This metadata is what turns a list of strings into something another platform will accept.
| Format | What it is for |
|---|---|
| Plain text | One indicator per line — blocklist imports, grep, a firewall paste |
| CSV | Value, type and count — a spreadsheet or a ticket attachment |
| JSON | The full result object including per-type statistics |
| Enhanced CSV / JSON | The same, with TLP, confidence, description, tags, source and analyst on every row |
| STIX 2.1 | A bundle of indicator objects with proper STIX patterns ([ipv4-addr:value = '…'], [file:hashes.'SHA-256' = '…']) and the correct TLP marking-definition reference — for MISP, OpenCTI and most TIPs |
| OpenIOC 1.1 | XML with an OR-joined indicator list, mapping each type to its Network, Email, FileItem or System context |
| YARA | A single rule whose strings are the extracted hashes, with your metadata in the meta block. Hashes only — if the set contains no hashes you get a comment saying so |
A caveat on the YARA export: it emits the hash strings, which matches files that contain the hash as text (a report, a log, a config), not files whose content hashes to that value. It is a hunting rule for documents and telemetry, not a file-identification rule. For the latter you want a rule built on content signatures.
2001:db8::1 may be captured as 2001:db8::. Verify IPv6 indicators against the source text before acting on them.An IOC (Indicator of Compromise) extractor automatically identifies and extracts security-relevant artifacts from unstructured text such as threat intelligence reports, email headers, log files, and incident notes. IOCs include IP addresses, domain names, URLs, file hashes, email addresses, CVE identifiers, and other observable data that indicate malicious activity or compromise.
Security analysts spend significant time manually copying IOCs from PDF reports, threat advisories, and internal communications. An automated extractor uses pattern matching and validation to pull these indicators in seconds, reducing manual effort and ensuring no critical indicators are missed. Extracted IOCs can then be fed into SIEMs, firewalls, threat intelligence platforms, and blocklists for automated detection and response.
IOC extractors use regular expressions and validation logic to identify specific patterns in text:
| IOC Type | Pattern | Example |
|---|---|---|
| IPv4 address | Dotted decimal notation | 192.168.1.100 |
| IPv6 address | Colon-separated hexadecimal | 2001:db8::1 |
| Domain | Hostname with TLD | malware.evil.com |
| URL | Full URI with scheme | https://evil.com/payload.exe |
| MD5 hash | 32 hex characters | d41d8cd98f00b204e9800998ecf8427e |
| SHA-1 hash | 40 hex characters | da39a3ee5e6b4b0d3255bfef95601890afd80709 |
| SHA-256 hash | 64 hex characters | e3b0c44298fc1c149afbf4c8996fb924... |
| Email address | user@domain format | attacker@evil.com |
| CVE ID | CVE-YYYY-NNNNN | CVE-2024-12345 |
| MITRE ATT&CK | Tactic/technique IDs | T1059.001 |
Defanged IOC handling: Threat reports often "defang" IOCs to prevent accidental clicks—writing hxxps://evil[.]com instead of https://evil.com. Quality extractors recognize and automatically refang these patterns for direct use in security tools.
Indicators of Compromise (IOCs) are forensic artifacts indicating potential security breach. Types: IP addresses (C2 servers), domains (phishing sites), URLs (malware downloads), file hashes (malware samples), email addresses (attackers), file paths, registry keys, mutexes. Used in: threat intelligence sharing (STIX/TAXII), SIEM rules, IDS/IPS signatures, threat hunting. Extract IOCs from: security logs, incident reports, malware analysis, threat feeds.
Use regex patterns or specialized tools to identify IOCs in unstructured text. Common patterns: IPv4 (192.0.2.1), IPv6, domains (example.com), URLs, MD5/SHA hashes, email addresses. Challenges: defanged IOCs (hxxp://example[.]com), false positives (version numbers as IPs), context. Our tool: automatically detects patterns, handles defanged format, removes duplicates, exports to CSV/JSON. Use for: parsing threat reports, analyzing logs, enriching SIEM data.
Defanged IOCs are intentionally modified to prevent accidental clicks or DNS lookups. Common modifications: hxxp:// (instead of http://), example[.]com (brackets), 192[.]0[.]2[.]1 (brackets), @ replaced with [at]. Used in: threat reports, email communication, documentation. Prevents: accidental malware execution, DNS queries to C2 servers, analyst mistakes. Refanging: convert back to original format for analysis. Our tool automatically detects and refangs IOCs.
Validation prevents false positives. Steps: 1) Check format (valid IP ranges, domain TLDs, hash lengths). 2) Remove private IPs (10.x, 172.16-31.x, 192.168.x). 3) Exclude loopback (127.x). 4) Verify hash algorithms (MD5=32 chars, SHA-1=40, SHA-256=64). 5) Check domain reputation (VirusTotal, AbuseIPDB). 6) Context analysis (log timestamps, related IOCs). 7) Remove CDN/legitimate services (cloudflare, google). Use threat intelligence platforms for enrichment.
Common formats: IPv4 (192.0.2.1), IPv6 (2001:db8::1), domains (example.com, sub.example.co.uk), URLs (https://example.com/path), MD5 hashes (32 hex), SHA-1 (40 hex), SHA-256 (64 hex), email addresses (user@domain.com), CVE IDs (CVE-2024-1234). Defanged variants: hxxp://, example[.]com, 192[.]0[.]2[.]1. Output: CSV (spreadsheet analysis), JSON (SIEM integration), STIX (threat sharing), OpenIOC (standardized). Our tool auto-detects all common formats.
IOC-based hunting workflow: 1) Collect IOCs from threat intel feeds, reports, sandboxes. 2) Enrich with context (malware family, campaign, TTP). 3) Search SIEM/EDR logs for matches (firewall blocks, DNS queries, file hashes). 4) Investigate matches (timeline analysis, lateral movement, data exfiltration). 5) Expand IOCs (pivot to related artifacts). 6) Update detection rules. Tools: Splunk, ELK, Sentinel, CrowdStrike. Limitation: IOC-based detection misses zero-days.
False positives occur when legitimate indicators misidentified as malicious. Common causes: public DNS servers (8.8.8.8), CDN IPs (Cloudflare, Akamai), popular domains (google.com in logs), version numbers as IPs (10.0.1.2 in software), test/example domains. Reduce false positives: whitelist known-good IOCs, check reputation scores, require multiple IOC matches, add context (user behavior, timeline), validate with threat intel. Balance sensitivity vs accuracy.
Share IOCs using standardized formats: STIX/TAXII (structured threat intelligence), MISP (sharing platform), OpenIOC (open format), CSV/JSON (simple). Best practices: 1) Defang before sharing (prevent accidental access). 2) Include context (malware family, confidence score, source). 3) Use TLP (Traffic Light Protocol) for sensitivity: TLP:CLEAR (public), TLP:GREEN (community), TLP:AMBER (limited), TLP:RED (eyes only). 4) Anonymize victim data. 5) Verify accuracy before sharing.