| Internet-Draft | Safe-IOC Sharing | March 2026 |
| Grimminck | Expires 20 September 2026 | [Page] |
This document defines a consistent and reversible method for sharing potentially malicious indicators of compromise (IOCs), such as URLs, IP addresses, email addresses, and domain names. It introduces a safe obfuscation format to prevent accidental execution or activation when IOCs are displayed or transmitted. These techniques aim to standardize the safe dissemination of threat intelligence data. This specification uses the URI syntax defined in RFC 3986 and follows the key word conventions from RFC 2119.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 20 September 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The secure sharing of malicious artifacts is vital to threat intelligence, open-source intelligence (OSINT), and incident response efforts. However, sharing raw URLs, IP addresses, and email addresses associated with malware or threat actors poses a risk of accidental activation.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document defines a clear and reversible method for obfuscating and de-obfuscating IOCs to support safe sharing across various platforms, formats, and use cases. The requirements language (e.g., "MUST", "SHOULD") follows [RFC2119], and URI syntax adheres to [RFC3986].¶
Obfuscating: The process of altering an indicator so that it cannot be accidentally activated or clicked. This was previously referred to as "defanging".¶
De-obfuscating: The process of restoring an obfuscated indicator to its original, actionable form. This was previously referred to as "refanging".¶
IOC: Indicator of Compromise - data such as a URL, IP address, domain name, email address, or hash associated with malicious activity.¶
Inconsistent obfuscation practices hinder the reliable and automated exchange of threat intelligence. For example:¶
Such inconsistencies reduce the effectiveness of threat detection and response.¶
To prevent nested obfuscation (e.g., "hxxps://example[[.]]com") when an LLM or tool processes the same string twice or in the wrong order, implementations MUST apply transformations in the following strict order of operations. Implementations MUST treat already-obfuscated substrings (e.g., "[.]", "[@]") as opaque and MUST NOT apply transformations to them again; thus, the transformation is idempotent. Using encoded characters (such as %2e for ".") SHOULD be avoided to prevent ambiguity.¶
Identify and replace the scheme first. Replace "http" with "hxxp" and "https" with "hxxps". For other schemes (e.g., "ftp"), apply analogous obfuscation (e.g., "fxp").¶
Identify the "@" symbol in the userinfo subcomponent (per [RFC3986]) and replace it with "[@]". This applies to email addresses and URIs containing userinfo (e.g., "username:password@host").¶
Replace all "." (period) characters in the Host subcomponent with "[.]". This applies to domain names and IPv4 addresses, including standalone values (e.g., "evil.com" or "1.1.1.1" without a scheme). IPv6 addresses enclosed in square brackets (e.g., "[2001:db8::1]") MUST retain their colon-based syntax and brackets; do not alter colons or brackets within the IPv6 literal.¶
Do not process the Path, Query, or Fragment components unless they contain nested URIs that require separate obfuscation. Applying transformations beyond the Host in the primary URI may cause incorrect results.¶
The Safe-IOC format is defined using the Augmented BNF (ABNF) notation specified in [RFC5234]. This allows an LLM or tool to generate a parser that can validate whether a string is already obfuscated or needs processing.¶
; Safe-IOC obfuscation symbols safe-scheme = "hxxp" / "hxxps" safe-dot = "[" "." "]" safe-at = "[" "@" "]" ; Additional schemes (e.g., ftp -> fxp) safe-other-scheme = "fxp" / "fxxps" ; extensions for ftp, ftps
A compliant implementation MUST recognize strings containing safe-scheme, safe-dot, and safe-at as obfuscated. A string that requires obfuscation is one that contains literal "http", "https", "." in host/domain contexts, or "@" in userinfo/email contexts without the Safe-IOC bracketing.¶
Tools designed to ingest obfuscated data SHOULD automatically reverse these transformations in a deterministic manner:¶
The order of these replacements does not affect the result. De-obfuscation MUST maintain the original semantics of the data to avoid misinterpretation.¶
De-obfuscation MUST only be performed when the output is written to a non-executable buffer (e.g., a variable, string, or file) that cannot be automatically interpreted, executed, or rendered as a clickable link by the system or application. The tool MUST NOT de-obfuscate a string if it is currently being rendered in a "live" environment (e.g., a web browser preview, an active document viewer, or any context where the resulting string could be automatically executed, resolved, or displayed as a clickable link).¶
De-obfuscation SHOULD only occur in controlled contexts such as:¶
Accidental activation during the de-obfuscation process poses a security risk and MUST be prevented.¶
Common scenarios include:¶
While these obfuscation techniques reduce the risk of accidental activation of malicious indicators, obfuscated data SHOULD always be handled with caution.¶
A compliant tool MUST obfuscate both the scheme and the delimiters (periods, at-sign) to be considered Safe-IOC Compliant. Partial obfuscation - for example, replacing only "." with "[.]" while leaving "https" unchanged - creates a false sense of security. A user may incorrectly assume a URL is safe because the period is bracketed, when the scheme remains active and could still trigger automatic linkification or execution in some environments. Implementations MUST NOT produce partially obfuscated output when full obfuscation is intended.¶
Implementations that parse Safe-IOC strings may become confused by malformed or inconsistently obfuscated input. For example, "hxxps://example.com" (scheme obfuscated but dots not) or "https://example[.]com" (dots obfuscated but scheme not) are not valid Safe-IOC formats. Parsers SHOULD validate that obfuscated strings conform to the canonical transformation rule and the ABNF grammar before de-obfuscation. Rejecting or flagging ambiguous input reduces the risk of misinterpretation.¶
As stated in Section 6, de-obfuscation MUST only occur when the result is placed in a non-executable buffer. A non-executable buffer is one that cannot be automatically interpreted by the system (e.g., as a URI to fetch, a command to run, or a link to display). Writing de-obfuscated output into a live document, rich-text editor, or browser address bar before explicit user action creates an unacceptable risk of accidental activation.¶
Software designed to parse threat intelligence feeds should explicitly support these obfuscation and de-obfuscation standards. Implementations SHOULD verify correct obfuscation and de-obfuscation through unit tests and validation scripts using the test vectors in Section 12.¶
Internationalized Domain Names (IDNs): Obfuscate punycode domains similarly (e.g., "xn--n3h[.]example[.]com").¶
Non-Standard URI Schemes: For schemes like "ftp", apply analogous obfuscation (e.g., "fxp://example[.]com").¶
IPv6 Literals in URIs: Do not alter colon characters (":") or brackets ("[", "]") in IPv6 addresses. For example, "[2001:db8::1]" MUST remain unchanged. Only scheme names or domain elements surrounding them should be obfuscated.¶
This document has no IANA actions.¶
The following provides a "golden set" of inputs and expected outputs. Implementations SHOULD use these vectors to ensure correct behavior and to avoid under-obfuscation (e.g., missing email addresses) or over-obfuscation (e.g., obfuscating IPv6 colons).¶
Note: The IPv6 rows demonstrate that colons and brackets within the IPv6 literal MUST NOT be altered, including IPv4-mapped IPv6 (::ffff:192.0.2.1). The deep-link row shows that Path, Query, and Fragment (per Step 4) are not processed. The Punycode row shows that IDN labels in punycode form receive the same "[.]" treatment as regular domain labels.¶