CTI good practices with hyperlinks

Written by the Cybersecurity and Privacy Protection Research Group (GiCP)

Encountering an Oxyuranus microlepidotus by chance can have many results, including death. This is because it bites and is one of the most venomous snakes in the world. While it’s true that you are very unlikely to come across a taipan in your home, at work or at the cinema, it is also true that potentially (very) harmful links can virtually be found (and clicked) at any time on any application, more so if you work with threat intelligence.

In both situations, although seemingly distant at first, one should proceed in a similar manner: with caution, aware of the potential threat we are facing, taking nothing for granted and not underestimating the repercussions.

In this post, we will discuss some of the good practices when working with Cyber Threat Intelligence (CTI), such as defanging, the use of secure communication channels, OPSEC considerations, malware sample handling, and sandboxing.

Removing a snake’s fangs or, in our context, completely disabling a link in any possible scenario is known as defanging, and will allow us to work safely with hyperlinks, preventing the investigator from accidentally clicking on them, or from previewing or auto-fetching them from the messaging application.

There is a draft in the IETF for the defanging action with the purpose of making it reversible (refang)

• URLs and IPs: hxxp://example[.]com/path or 192[.]0[.]2[.]123. Avoid pasting live URLs.
• Email addresses: user[@]example[.]com
• Attachments: see their section Keep them in plain text; disable linkification in the editor/client
• Prohibit hover-to-preview and automatic DNS resolutions in note-taking tools
• When “refanging,” do it only within a safe environment (next sections)

There are many tools, scripts, and plugins for the automation of the defanging process. Here are some of them, defanged to maintain the coherence of this post:

• IOC Defanging Tool: hxxps://defang[.]me/index[.]php
• IOC Fang: Indicator of Compromise (De)Fanging Project: hxxps://ioc-fang[.]github[.]io
• URL Defang/Refang Tool: hxxps://chromewebstore[.]google[.]com/detail/url-defangrefang-tool/ndenmnlnbnkkplpgbnodikhgampegbjj

Maintaining secure communication requires more than just encrypting content; it also demands careful handling of metadata. Even when messages are encrypted, metadata -such as who communicates with whom, when, from where, message size, or email subjects- can reveal sensitive behavioral patterns.

Technically, organizations should leverage services that minimize logging and avoid persistent records, like Signal’s sealed sender feature, which obscures the origin of messages. Storage should be limited on platforms prone to public indexing or automated crawling, and files should be sanitized to remove unnecessary metadata, including EXIF information from images or document properties from PDFs and Office files. Organizationally, policies should be established for anonymization and minimizing digital footprints, accompanied by training for staff and users to recognize that even the choice of communication channels can leave correlatable traces.

End-to-end encryption is a critical tool for protecting communication against intermediaries, mass surveillance, and server breaches. Messaging applications with default E2EE, such as Signal, not only encrypt message content but also reduce metadata exposure and avoid persistent server-side storage. Best practices include verifying peer keys through fingerprints or QR codes, disabling cloud backups that do not maintain E2EE, and keeping client applications up-to-date to patch potential cryptographic vulnerabilities. Adopting these practices ensures that communications remain confidential and resistant to interception or unauthorized access.

Regular email protocols, like SMTP with STARTTLS, only protect messages while they’re being sent, which means they can still be vulnerable once they reach the recipient. PGP (Pretty Good Privacy) solves this by providing end-to-end encryption and allowing messages to be digitally signed for authenticity. To make PGP work well, you need careful key management—ideally using hardware tokens or smartcards—and secure ways to share public keys, whether through official repositories, direct exchanges, or DNSSEC/DANE. In practice, it’s best to use email clients that have built-in PGP support, such as Thunderbird with Enigmail or ProtonMail Bridge.

Data handling must align with applicable European regulatory frameworks, such as GDPR, NIS2, and DORA, depending on the sector. Special attention is required for sensitive data categories, including health, biometrics, or political orientation, which demand stronger safeguards. The Traffic Light Protocol (TLP) further refines data sharing: TLP:RED is strictly limited to direct recipients, TLP:AMBER to internal or necessary circles, TLP:GREEN to a defined community, and TLP:WHITE for unrestricted public sharing. Implementation involves mandatory labeling of all documents and emails, enforcing strict access controls on a need-to-know basis, and maintaining audit trails to track access and redistribution.

Operational security should start from a default position of distrust, assuming that artifacts, links, or senders may be compromised. Threat modeling must be realistic, considering adversaries with substantial resources, such as advanced persistent threats (APTs). Domain separation is essential: investigation, production, and personal activities should be strictly isolated across hardware, accounts, and networks to minimize cross-contamination.

When dealing with potentially malicious files, caution is key to avoid accidental execution or spreading. These files should never touch your personal or production machines. Instead, use dedicated virtual machines with snapshots, keeping them isolated -avoid conveniences like shared folders, clipboards, or drag-and-drop. It’s a good idea to compress the files with a standard password, like “infected,” and provide external hash verification for safety. Always label files clearly, using prefixes such as “MALWARE_SAMPLE_,” along with the date, known family name, and appropriate TLP classification.

For analysis, avoid uploading sensitive files to public services, such as VirusTotal, as this risks exposure of internal data, instead, search by hash when feasible. Local sandbox solutions, such as Cuckoo or CAPE, should be deployed on-premises within controlled networks, with default egress disabled, to safely analyze malicious files without risk of uncontrolled dissemination.