When to release threat intel freely vs. info-share quietly

General
1

Seeking some feedback and thoughts here from folks, as this issue continues to nag at the back of my brain.

Let’s say through original ongoing research, I have a list of clearly malicious domains from a known threat actor who moves fast. These domains are identifiable much earlier than other efforts I’ve seen, which provides a boon to both investigators and defenders, but not necessarily both at once.

If I go loud early, I essentially show my hand. Threat actors often pay attention to socials/etc. So publishing early also may let them know their domain is already burned. That will lead to them varying up their operational profile, and also just moving to another permutation of the domain they’re using, which is more or less infinite.

At that point you’re probably just in a whack-a-mole situation with decoy and real attack domains pretty quick, and no one has time for that.

If I go loud late, domains I’m in possession of and have only passed quietly (let’s say to threat working groups) could have contributed to enterprise defense, and it’s possible companies could have avoided being compromised or limited blast radius.

When is the right time with a list like that to hold back, versus blast it out everywhere?

2

I’ll start by saying that I approach this topic humbly, knowing many people with more experience in this realm may differ widely with my interpretation.

Is the domain list itself the thing most valued here? What about the methodology that resulted in the list? Can they be separated? Seems to me that the atomics, following the ol’ Pyramid of Pain, should be low-cost to share but also, yes, low-cost to change. That doesn’t diminish the advantage to the defenders in the moment of having the observables to block, forcing the change.

And sharing those widely helps the most folks. But maybe you don’t want to tip off the adversary as to how the domain list was identified, the pivot that made the list possible. That’s of higher value to you and to the adversary, who would change a higher tier of the operation if they discovered, for example, their infrastructure selection methodology were burned. Or something else, but you get the idea.

I also wonder what attackers glean from private sharing resulting in higher fail rates (or lower capture rates) for their deployed infra. It’s possible that even trust-circle-only sharing lets the baddies know the jig is up. But I’m not sure about that.

It’s also worth noting that there’s an asymmetry of certainty here. After disclosing indicators through open feeds, ingesters are defended with reasonable certainty. When and whether attackers change up those indicators is at least less certain, or on a delay.

So I guess yeah, split the concerns: share broadly the result of the investigation, but not the methodology that let you pivot.

And riffing on that: could the list be split in such a way that confounds the adversary but still results in wide defense? That’s just spitballing, but you could imagine some kind of observable “laundering” that gets the info out, but not all from one source or even all at once. That might be wacky.

3

A very depreciated two pennies.

Posting on wide socials just seems like showing cards that are better held close. Even if it’s low subscriber and distributed ‘sources’, I worry about AI clankers doing correlation and brute forcing back to methods and sources – which are the most important bits to hide from threat actors.

Is there a (reasonably) reliable way to perturb the results to protect sources & methods without destroying the value of the original Intel? Maybe adding still malicious (or at least dodgy) unrelated IoCs? This does lower our Admiralty score for reliability – if published as IFIN.

Is there a way to possibly vet recipients? Maybe only people/orgs who’ve done an IFIN training? I tried to pass Fortibleed info to multiple municipalities and realized there was no one on the receiving end who could actually process and act on the fact that their VPN had been pwned. Giving them Intel was less rewarding than giving carrots to my cats…the cats will at least bat the carrot around for a while.

I want to get intel & knowledge to groups that can use it. I’m particularly concerned about small to medium critical infra providers who don’t have an ISAC subscription. There’s got to be a way to fix the disconnect: getting useful intel to CI providers, with ways to act on it, without burning the upstream.

[Comma splices are my friend]

4

Hmm, if this is true, and for the most common operations I’m not so sure, it would seem to call into question the TLP:CLEAR policy of IFIN itself. I am quite possibly mis- or over-interpreting this. I’m definitely more instinctively an information sharer, but I do understand that’s not always the best move, and other schools of thought exist.

Nevertheless, I think it’s really possible to game theory your way into a corner on this one. There will always be a another turn, but if we have observables that can can benefit defenders now, I would gently suggest that the burden should be arguing the case against disclosure, not for. Especially since all the things attackers might do are speculative, but the exigent threat in question is not.

5

It’s not an easy problem.

6

What I hear in this is that at the core we’re trying to protect information and share it on the right channels without signaling too loud, where adversaries could make benefit.

There are two parts to my response, one is methods I have found useful in answering this question in my own experiences. The second half I share an opinion about getting data in to systems.

Data has a flow - and when it stops then we have an issue.

There are some considerations in that video the important ones I am sharing below.

Expectation of Flow: Users might have an expectation of how their information should be shared or kept private.
Legitimacy of Flow: The legitimate flow of information should be based on actual, practical considerations and societal norms.

Meaning Information is contained in or revealed by,

Meaning each document or digital creation has information that could, if put together convey something else.

Some examples of this:
A document with lists of addresses contains the information.

An article mentioning the list reveals the information.

The lists were revealed by the article that was written.

What I try to think of:

What are the sources, and what is the length that this data or information will still be useful?

I try to focus on the longest time that a piece of information will be useful, I have found that README with instructions about the data retention period, or defining the data retention period in the files creation (there are programmatic and system considerations to apply ).

So new derivative documents I write, then can mention or exclude the source, when it makes sense based on the audience and trust levels inside that space.

  • What do I want to protect?
  • Who do I want to protect it from?
  • How bad are the consequences?
  • How likely is it that I will need to protect it?
  • How much trouble am I willing to go through to try to prevent potential consequences?

I think that in terms of information that should get ingested in to systems, that the lists should be opinionated and in TSV format, TSV is different than CSV by disallowing TABs and newlines in the data.

The escape syntax enables CSV to fully represent common written text, great for humans and spreadsheets. But this comes at a cost, reading it requires programs to parse the escape syntax.
Unix tools like cut, sort, awk, and diff do not process CSV escapes

TSV data is simple. Records can be read using the typical readline this is found in MOST programming languages. Fields in each record can be found using split routines.

awk -F "\t", sort -t $'\t' NO SPECIAL PARSER needed. :slight_smile: And it’s faster, we are not spending CPU time parsing the escape syntax.

TSV also allows increased speed for record counts, deduplication, file splitting and shuffling and new line search routines like memchr

7

The domain in which we operate is a big factor. A lot of the good threat intel teams at larger IT companies and security orgs actively work with law enforcement.

They toe-the-line of tipping-their-hand and collecting as much infrastructure as possible to burn-it-down, creating a higher financial impact, and collecting evidence about the identity of the actors. And I greatly appreciate the work they do.

Much of my focus as a front-line defender is living-off-the-land. The techniques are rarely novel, but the abused software and services are. Between bulletproof SaaS, black-holed abuse reports, and poor security vendor categories, my frustration became BS Lists.

Could someone use BS Lists to select obscure trusted services for abuse, sure. But that’s why I make them public for everyone. It’s also my hope entities on BS lists take accountability; as organization’s risk models increasingly favor blocking their service, there’s real impact and incentive to change.

If there’s a mechanism in which a vendor’s feature is very broken or novel abuse, I’ll submit a report to their security team. Unfortunately abuse of intended features often fall outside the scope of bug bounty programs. And many ignore or quietly fix the thing without further communication.

So my particular workstream favors quick publication. And bonus if I can Wu-Tang theme it.