Defanging and Refanging IOCs: A Practical Guide

Every analyst meets defanged IOCs on day one: hxxp://bad[.]example, 8[.]8[.]8[.]8, evil(dot)com. Understanding why they exist — and how to safely reverse them — is a small skill that prevents real accidents.

Why IOCs get defanged

Defanging deliberately breaks an IOC so it cannot be accidentally clicked, auto-linked, or fetched by a mail client, chat app, or ticketing system. It is a safety convention for sharing indicators in reports, emails, and tickets without turning them into live, clickable hazards.

Common defang styles

• Dots wrapped in brackets: 1[.]2[.]3[.]4 or bad[.]example
• The word "dot" spelled out: evil(dot)com or evil[dot]com
• Protocols mangled: hxxp:// and hxxps:// instead of http/https
• At-signs neutralised: user[at]example[.]com

Refang carefully

Refanging is simply reversing those transformations to get a usable IOC back — replacing [.] with ., hxxp with http, and so on. The risk is doing it by hand in a place where the result becomes live: paste a freshly refanged URL into a browser bar out of habit and you have just requested a malicious resource from your own machine.

Refang for lookups, not for clicks. The refanged form should feed a threat-intel query, not your address bar.

Automate the mechanical part

Refanging is deterministic and repetitive, which makes it perfect to automate and dangerous to do manually under time pressure. Deep Detect refangs automatically the moment you select an IOC — [.] to ., hxxp to http, spelled-out "dot" and more — then detects the IOC type and runs the lookup, so you never paste a live malicious link anywhere it can do harm.