A Standard for Safe and Reversible Sharing of Malicious URLs and Indicators

Internet-Draft	A Standard for Safe and Reversible Shari	April 2025
Grimminck	Expires 11 October 2025	[Page]

Abstract

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 defanging 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.¶

Status of This Memo

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 11 October 2025.¶

Copyright Notice

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.¶

1. Introduction

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 defanging and refanging 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].¶

2. Terminology

Defanging: The process of altering an indicator so that it cannot be accidentally activated or clicked.¶

Refanging: The process of restoring a defanged indicator to its original, actionable form.¶

IOC: Indicator of Compromise - data such as a URL, IP address, domain name, email address, or hash associated with malicious activity.¶

3. Problem Statement

Inconsistent defanging practices hinder the reliable and automated exchange of threat intelligence. For example:¶

A URL defanged as "h**p://example[.]com" cannot be reliably parsed by tools expecting "hxxp://example[.]com".¶
An IP address defanged with parentheses (e.g., "192.0.2(.)1") may fail to refang in systems expecting "[.]".¶

Such inconsistencies reduce the effectiveness of threat detection and response.¶

4. Defanging Techniques

The following transformations MUST be consistently applied:¶

Replace "http" and "https" schemes with "hxxp" and "hxxps" respectively.¶
Replace every period (".") in domain names and IP addresses with "[.]".¶
Replace the "@" character in email addresses or credentials with "[@]".¶
Original: http://[2001:db8::1]:8080 Defanged: hxxp://[2001:db8::1]:8080¶

Using encoded characters (such as %2e for ".") SHOULD be avoided to prevent ambiguity.¶

Examples:¶

Original: https://evil.example.com/path
Defanged: hxxps://evil[.]example[.]com/path¶
Original: http://username:password@attacker.com
Defanged: hxxp://username:password[@]attacker[.]com¶
Original: user@phishing.example.com
Defanged: user[@]phishing[.]example[.]com¶

Note: Credentials in URIs (e.g., username:password) are included here for illustrative purposes only. Sharing credentials, even in defanged form, is strongly discouraged in operational contexts.¶

Note: IPv6 addresses enclosed in square brackets MUST retain their colon-based syntax (e.g., "::") and brackets. These characters are essential to URI parsing and MUST NOT be altered. Defanging should apply only to components such as the scheme ("http") or domains, not to the IPv6 address syntax.¶

5. Refanging Techniques

Tools designed to ingest defanged data SHOULD automatically reverse these transformations in a deterministic manner:¶

Convert "hxxp" and "hxxps" back to "http" and "https" respectively.¶
Convert "[.]" back to ".".¶
Convert "[@]" back to "@".¶

Refanging MUST maintain the original semantics of the data to avoid misinterpretation. Examples:¶

Defanged: hxxps://evil[.]example[.]com/path
Refanged: https://evil.example.com/path¶
Defanged: user[@]phishing[.]example[.]com
Refanged: user@phishing.example.com¶

6. Example Use Cases

Common scenarios include:¶

**OSINT Sharing**: A report lists defanged URLs (e.g., "hxxp://malware[.]com/payload") to prevent accidental clicks.¶
**Email Communication**: Security teams share defanged IOCs like "attacker[@]example[.]com" in email threads.¶
**Threat Intelligence Platforms**: Automated ingestion of defanged IPs (e.g., "192[.]0[.]2[.]1") for blocklist updates.¶

7. Security Considerations

While these defanging techniques reduce the risk of accidental activation of malicious indicators, defanged data SHOULD always be handled with caution. For example:¶

Defanged URLs in PDFs may still be rendered as hyperlinks; use plain-text formatting.¶
Systems processing defanged indicators MUST treat them as potentially harmful data, applying sandboxing or isolated environments for analysis.¶
Credentials (e.g., username:password) SHOULD NOT be shared, even in defanged form, due to inherent security risks.¶

8. Implementation Guidance

Software designed to parse threat intelligence feeds should explicitly support these defanging and refanging standards. Implementations SHOULD verify correct refanging through unit tests and validation scripts. Example test case:¶

        Test Input: "hxxp://192[.]0[.]2[.]1"
        Expected Output: "http://192.0.2.1"

9. Edge Cases and Special Handling

**Internationalized Domain Names (IDNs)**: Defang punycode domains similarly (e.g., "xn--example[.]com").¶

**Non-Standard URI Schemes**: For schemes like "ftp", apply analogous defanging (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 defanged.¶

11. Normative References

[RFC3986]: Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005, <https://www.rfc-editor.org/rfc/rfc3986>.
[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.