I didn't start out in threat intel. I didn't start my career in cybersecurity in DF/IR work. I started doing vulnerability assessments using commercial tools (ISS's Internet Scanner) and well as freely-available tools (i.e., ToneLoc and THCScan, for war dialing).
Around 2000, I transitioned to DF/IR work, largely as part of an internal, FTE role. We really didn't have "threat intelligence" at the time; in fact, while I heard the term and saw folks pointing at things they called "threat intel" or "CTI", I didn't really start engaging more directly with "threat intelligence" until about 2013 or so.
I don't have an intel background from the military, nor from LE, but I've been ancillary to and a consumer of "cyber threat intel" long enough to know what I find to be "of value", and truly actionable. I've been actively engaged with customers during incident response, when they've received "threat intel" either prior to or during the incident, and seen their reaction. If I hadn't actually seen the reaction on their face or heard their responses, I've seen what action they've taken. Often, it's been nothing, because the "threat intel" is delivered with a wink and nod, and the customer/recipient has no idea what to do with it. For them, it's not actionable.
Not long ago, I was engaged in a conversation regarding several IOCs from an incident, and as is often the case, we got to the point where we began discussing going public with our findings. Then came a comment about "burning" the IOCs, with the speaker feeling that once the IOCs were exposed publicly, the threat actor would change their tactics to avoid detection. As part of research I was doing with respect to the incident, I'd found online documentation that included the IOCs going back 2, and even 3 years.
This was not "new", not at all. Almost a decade and a half ago, I'd been working an investigation where we found a really interesting use of the DLL search order issue in Windows, one that allowed a threat actor have their malware actively running on the endpoint. Once we unraveled this, those of us working the investigation thought, "Wow, this is pretty cool!" and wanted to share it publicly. We took it to our manager, who asked if we'd told anyone, to which we replied, "no". We were seeking permission to do just that, and were told to not say anything to anyone. We were rather disappointed when, just a few weeks later, one of our competitors posted publicly about the very thing we'd investigated.
What the above discussion showed was that, even after the IOCs had been publicly exposed several years ago, here we were seeing the very same IOCs during a current incident. Even though the common belief is that once IOCs are shared in the public arena, threat actors will make changes and shift tactics to avoid future detection, the data was showing us something completely different.
"Burning" an indicator may be true for low-level IOCs such as IP addresses and domain names, but for some of the less-frequently discussed IOCs, those that are further up David Bianco's Pyramid of Pain, may be more difficult or costly for a threat actor to change/modify, particularly if doing so requires a fundamental change in how they do things.
A factor that may lead to the IOCs continuing to appear over time is that the IOCs themselves aren't socialized widely, or detecting those IOCs requires significant change to the impacted infrastructure. Some IOCs may require modifications to audit configuration, or even logs being enabled, and depending upon the maturity of the organization, these modifications may seem out of reach.
Another factor may be that the IOCs can be detected, but those that detect them but don't have an appropriate means for response.
After all, it's 2026, and we still see infrastructures compromised because RDP or MSSQL is open and accessible to the public Internet, or there's an input validation issue in a web page that leads to SQL injection, or there's a 2 or 3 yr old vulnerability to a public-facing application that still hasn't been patched.
Read the original article: