Extracting Indicators from Messy Reports: IPs, Hashes, URLs and More

A security report rarely arrives as a tidy list. It arrives as paragraphs of prose, log lines, email headers and ticket comments, with indicators buried inside sentences. Pulling those indicators out by hand is slow and error-prone: a 32-character hash is easy to mistype, and a domain hidden in a long URL is easy to miss entirely. The IOC Extractor scans text you paste in and pulls out the pieces shaped like indicators, such as IP addresses, domains, URLs, email addresses and file hashes. It works on pasted text only, in your browser, and it does not fetch anything, look anything up, or decide whether an extracted item is malicious. That last point matters: extraction is a mechanical step, and judgement comes afterwards.

The value of extraction is speed plus completeness. A human reader skims and remembers the dramatic indicators, while an extractor catches every occurrence, including the quiet ones in footnotes and log fragments. It also normalises the output into a list you can sort, count and feed into the next step, whether that is deduplication, enrichment or a detection rule. But an extractor can only find shapes it recognises. A deliberately obfuscated indicator, such as a domain with spaces between its letters, may slip past it, and a benign string that happens to look like an indicator, such as a software version number, may be picked up by mistake. The output is a candidate list, not a verdict.

How it works

Most extractors work by pattern matching. An IPv4 pattern looks for four groups of digits separated by dots, a hash pattern looks for long runs of hexadecimal characters of the standard lengths, and a URL pattern looks for a scheme followed by a host and a path. Email and domain patterns are similar. Good extractors also handle defanged input, recognising bracketed dots and hxxp schemes so that indicators from shared reports are still found. After extraction, the useful tools let you filter by type, so you can export only hashes for one system and only domains for another, and they show the context around each match, which helps you judge whether a match is genuine or a false positive.

Context is the part people skip, and it is the part that prevents bad rules. A domain found in a sentence that says "the attacker used evil-example.com" deserves a different response from the same domain found in a sentence that says "we blocked evil-example.com at the firewall", and both differ from a domain mentioned as a legitimate reference. Read the surrounding words before acting on any extracted indicator, especially before adding one to a block list, where a false positive can break legitimate traffic.

Where it goes wrong

False positives are the most common extraction fault. Version numbers can look like short IP addresses, long hex strings in crash dumps can look like hashes, and internal hostnames can be swept up alongside attacker domains. A second fault is the opposite: missing indicators because the report used defanging the extractor was not set to handle, or because an indicator was split across a line break. A third fault is exporting without deduplication, so a detection rule ends up with the same indicator hundreds of times, which is wasteful and harder to maintain. Finally, never paste a report containing passwords, private keys or customer data into an extraction tool. The extractor only needs the indicator text, and secrets should be removed before the text leaves its home system.

Worked example

Worked example with sample values. Suppose you paste a sample report of 600 words containing 14 candidate indicators: 4 IP addresses, 3 domains, 2 URLs, 3 hashes and 2 email addresses. That adds up as 4 plus 3 plus 2 plus 3 plus 2, which is 14. On review you find that 1 of the IP addresses is actually a software version number, and 1 of the domains is your own company's domain mentioned as a reference, so 2 of the 14 are false positives. Removing them leaves 12 genuine candidates. Two of the hashes are duplicates of each other, so deduplication removes 1 more, leaving 11 unique indicators. The final export is therefore 11 indicators from 14 candidates, a reduction of 3, or about 21 percent, and every removal is a documented decision rather than a guess. These are sample values for illustration, not findings from a real incident, and the arithmetic shows why review and deduplication belong in the workflow rather than after it.

Mistakes to avoid

One mistake is pushing extracted indicators straight into blocking without any review, which turns every false positive into an outage risk. Another is keeping extracted lists forever without expiry dates, so stale indicators accumulate and nobody knows which are still relevant. A third is mixing indicators from different incidents into one undated list, which makes it impossible to retire one incident's indicators without touching another's. Also avoid sharing an extracted list outside your team without checking it for internal hostnames and employee addresses, which are not threat intelligence and should not travel with it.

Putting it into practice

Use the extractor as the first step of a short pipeline: paste the report text, extract, filter by type, review each candidate in context, remove false positives, deduplicate, and only then export. Save the cleaned list with the incident name and date, so it can be retired later, and keep the raw extraction alongside it for audit. If you run the same report twice, the two extractions should match; if they do not, something changed in the input or the settings, and that difference is worth understanding before you trust either output. That discipline turns a quick extraction into evidence you can defend.

Related tools and reading: the Hash Generator and the URL Encoder and Decoder cover neighbouring checks that pair naturally with this one, and the guide at [/blog/complete-email-security-checker-guide/] extends the same topic with further background and examples for readers who want to go deeper.

Key points

• An extractor finds indicator-shaped text, it does not judge it malicious
• Hashes, IPs, domains, URLs and emails need different validation
• Always deduplicate and strip false positives before exporting
• Never paste secrets or private data into an extraction job

In short: Extraction finds indicator-shaped text quickly and completely, but it does not judge malice. Review every candidate in context, remove false positives, deduplicate, and date the export. Never paste secrets into the input text.

One habit ties all of this together: re-check after every change. A result is only as current as the input it was run on, so a fix, a redesign, or a new version of the underlying material deserves a fresh run rather than reliance on an old report. Keep the previous result alongside the new one, note what changed between them, and treat any new finding as a question to investigate rather than a verdict to accept or dismiss. That loop of checking, fixing, re-checking and recording is what turns a one-off test into a reliable routine, and it costs far less time than debugging a problem that a second check would have caught early.