Views on AI & the Anthropic Report

There's been a lot of chatter over the use of AI in various fields, and because it's my professional focus, I'm most interested in how it's used in cybersecurity. Now, that doesn't mean that I'm not aware of how it's used...or more appropriately, misused...in other fields, as well. For example, how it's been misused in the legal field has been around for more than 2 years now, and just last year, we saw the term "AI slop" be adopted in the software dev/cybersecurity field.

Something we also saw in 2025 was the release of the Anthropic report regarding how AI was used by threat actors, in a cyber espionage campaign. The report is 14 pages long, with the title page, table of contents, and a 2-pg Executive Summary; the contents of the report itself starts on pg 6. 

The "TL;DR" of the report, if you need it, is that nation-state threat actors used Claude to target 30 organizations, and "...to execute 80-90% of tactical operations independently at physically impossible request rates." 

That's right...they used AI to run up to an estimated 90% of their attack chain autonomously. 

So, what does this mean? It means that "low and slow" was out the window, and that the attack chains were automated a "physically impossible request rates". 

That's it. Everything was faster. Reading through the report, it becomes clear that tools and techniques employed were akin to those commonly observed in human-operated attacks, but the OODA loop was much smaller, much tighter, and iterated through much faster than humanly possible. On the defender's side, this means that artifacts were generated (and hopefully, alerts fired) much closer together than what would've been observed earlier in the year. 

In response to the report, Matthew shared his thoughts, in which he shared the following:

That report, fascinating as it was, also left some cybersecurity pros with a bad taste in their mouth. Specifically: They wanted Anthropic to share some real threat intelligence. Get into the IOCs. The specific prompts. The real nitty-gritty details that defenders can use, that are a staple of the threat-sharing genre.

I have to say, and I did say in the comments, that I'm not sure that based on my aperture, I agree with Matthew. For example, I'm not sure what value the prompts used by the threat actors would have for defenders. While it's clear that using AI increases the velocity and volume of attacks, there was nothing obvious shared in the Anthropic report that says any of the tools or techniques used by the AI was any different from what a human would do, only that it was faster. Anthropic has clearly addressed issues that they've found as a result of their investigation, and the prompts would be of little value to defenders, and at this point, maybe provide indications (for the offensive side) of what worked, at one point in time, with Claude.

Okay, to level set...we're at a place where AI has been used in offensive cybersecurity, but let's be clear as to how it's been used, rather than freaking out about...we don't know what. According to Anthropic's report, their product was used to attack 30 or so organizations, with up to (estimated) 90% of the tactical operations handled autonomously by Claude, making the overall attacks much faster, moving away from the "low and slow" that some of us are used to seeing. What any individual, targeted organization likely saw was probably fast and loud.

And before you go thinking that using AI to autonomously run attacks is "all that", Figure 1 illustrates an excerpt from the report's Executive Summary.

Fig. 1: Report excerpt

Now, whether you call these "hallucinations" or coding errors, it does illustrate issues with running with whatever AI says, as others have found.

Finally, consider this...threat actors used Anthropic's Claude, which apparently is known to log prompts. In the Executive Summary of the report, it states, "...while we only have visibility into Claude usage...". I'll just leave that right there for you to consider, in terms of operational security.

On the Blue Side
So what does, or would, use of AI on the blue side, during DF, SOC, or CTI work look like?

On 15 Jan 2026, I saw this LinkedIn post from Rob Lee (of SANS fame) that announced the release of "Protocol SIFT", described as "Claude Code integrated with SIFT Workstation, using MCP". Figure 2 illustrates an excerpt of the LinkedIn post that describes how this all works together.

Fig. 2: LinkedIn post excerpt

Are users really going to use "find evil" as a prompt? I hope not, but I can also see that Rob is likely being a bit "light" in this instance. My concern would be that, if you're unable to articulate the goals of your examination, then how are you going to get Claude to do it for you?

Recently, Chiara Gallese shared this post on LinkedIn, in which she described an MIT lecturer who used ChatGPT in an attempt to understand the Riemann Hypothesis, a math problem that hasn't been solved in 160 years. I think what stood out to me most of all in Chiara's post was the following two statements:

And in the end, he did not understand the problem.
He just understood ChatGPT’s simplifications of his own confusion.

If we don't understand that problem, how do we know if AI (Claude, ChatGPT, whatever) is doing a better job, or just getting us to failure faster? 

Something SOC and DF/IR analysts have moved to over the years is triage collections, acquiring minimal data from endpoints in order to answer investigation goals in as timely a manner as possible. After all, why acquire a full image (which can take hours) when the data you need (during a breach investigation) is often limited to a few megabytes. Could you use something like Protocol SIFT to conduct analysis? Sure, but what happens if the AI hallucinates something not supported by the data, such as an endpoint being configured to not record successful logins (saw just such an endpoint today)? What happens if the AI hallucinates that source of the login activity, and then performs attribution (because you asked it to) based on that hallucination? How would you know that the findings provided are incorrect, if you don't understand the goals of the investigation and the data retrieved to support that investigation?

About half a dozen years ago, I was supporting a DF/IR team that was addressing a fair number of ransomware incidents when Microsoft published their first iteration of the human-operated ransomware attacks blog post. In that blog post, where the Doppelpaymer ransomware is discussed, the authors mention that the ransomware operators may have relied on WMI persistence mechanisms, so I asked our team if they'd seen any. The response was "no". 

However, while the front-end data collection did include the WMI repository, the middleware used to parse the data did not include a parser for the WMI repository, so the question became, how can you say "no" if the WMI repository wasn't parsed? 

This may sound like a one-off, but I saw the same mentality years before, and I've seen it since then, as well. Given everything else we're facing in 2026, I'm going to state, emphatically, that using AI on the blue side for no other reason than that the bad guys are using it is not a good reason, and that if you can't clearly articulate your analysis goals, then AI should not be used at all. 

Look at it this way...

Addendum, 20 Jan
Recently, Thomas Roccia shared his thoughts on running AI/Claude coding assistants blindly. I saw this just this morning, but it appears to have been published 3 days ago; it's worth a read when considering the use of AI, and especially Claude, for blue side activities.

What's on your clipboard?

One of the fascinating aspects of Windows systems, from a DF/IR perspective, for me has been the clipboard. Notice I said, "one of", rather than "the"...that's because there are a lot of fascinating aspects of Windows systems when it comes to DF/IR work. I include the clipboard in this mostly because there is various malware...infostealers, etc...that will dump the contents of the clipboard as part of their functionality. Also, there's malware that will place a malicious bitcoin wallet address on the clipboard, in hopes that the user simply pastes that address when they're enabling a transaction. I mention malware that modifies the clipboard in this 2008 blog post.

I'll admit that early on in my DF/IR career, this isn't something that I thought about collecting as part of an IR engagement. Even when we were using batch files to run native tools from a USB stick or CD-ROM drive, I don't remember including the capability to dump the clipboard, nor even having the discussion to do so. This may be because we weren't seeing anything...any data, or malware analysis...that would indicate that this was something we needed to be concerned about. Even back as far as 2007 or 2008-ish, I don't remember seeing any malware on PCI engagements, for example, that showed any signs of interacting with the clipboard. 

However, now, there's even a MITRE ATT&CK technique, T1115, to address clipboard data. The MITRE ATT&CK page for the technique lists more than a few examples of malware and groups that target the Windows clipboard for data. 

I recently ran across a reference to a tool that's been around for a while named ClipboardHistoryThief. According to the Github site for the tool, it's been around for about 3 yrs. After reading a bit about the ClipboardHistoryThief app, I decided to take a look at what I might have on my clipboard, so I hit the Windows logo key + V key combo, and the image seen in Figure 1 appeared on my desktop. 

Fig. 1: Clipboard History

My first thought was, whoa, what the...? I hadn't enabled the  clipboard history on my system...or had I? Opening the Registry Editor, I tried to navigate to the first key at the above StackOverflow link, but I couldn't complete the key path. Navigating to the HKCU key path, I saw what is shown in Figure 2.

Fig. 2: Registry Editor

Running the ClipboardHistoryThief tool on my system, I got what you see in Figure 3, which is essentially a replica of what I saw using the key combo above. 

Fig. 3: Tool output

Okay, wow. The tool works great...but why is there a history of data on my clipboard? I went to Settings on my system, searched for "Clipboard" and got what you see in Figure 4. These are the same settings seen in this 2022 blog post.

Fig. 4: Clipboard settings

So, if ClipboardHistoryThief is able to dump the contents of your clipboard, and not just the last item pasted to the clipboard, but the entire history. If the history is enabled, can you imagine how the attack surface changes and expands? Consider this...bad guy gets in via some means, but it really doesn't matter how. This could be entirely automated...get some code on the endpoint that enables the clipboard history if it isn't already, and then on a regular basis, it dumps and clears the contents of the clipboard, shipping the contents off to a C2 server. This is just a regular feed of data, consisting of whatever appears on the clipboard. What exactly is that? Well, I know I copy-paste contents of emails and documents all the time. For work, as well as on my personal system, I'll copy swaths of text content and paste it to another location in a file, or in another window or document all together. This might include customer-specific information that I'm tracking, or something I'll be redacting prior to inclusion into a blog post. 

Overall, this is something I'd be concerned about, from an endpoint auditing perspective. In this 2022 blog post, I mention several Registry locations that you might want to include in system audits, or as part of your incident analysis, that are associated with means of data collection. These locations, which include the clipboard, provide a means for data collection that we don't usually see in incident write-ups or descriptions, and can be used ahead of data staging and exfiltration.

Something else is that within Figure 4, there's an option to "Sync across devices". I can't say that I'm aware of what sort of devices, nor how the devices are connected (Microsoft Live account??), but seeing this setting enabled, particularly if it's against corporate policy to do so, would be concerning. 

For example, consider insider threat cases, and how data might be exfiltrated, if all someone has to do is copy content to their clipboard, and the data is sync'd to another device. In such cases, I'd want to look for not only the "Sync" setting, but also for indications of other connected devices. 

Questions I've Been Asked

Sometimes I'll get questions via different routes...webinars or podcasts, via social media, DM, or even email. Getting questions is good, because it keeps me aware that I'm in somewhat of a bubble, given the work I do and the environment in which I do it. Given the nature of "social" media (hint: it's rarely "social"), it's tough to draw a bead on where you are at any given moment, so questions can be invaluable.

Here's an interesting question I got from Brian Carrier during a webinar he invited me to...

If you have the entire Registry and limited time, what do you do?

The Cyber Triage LinkedIn post has 9 pages, and as you can see from the first one, my answer to the above question is:

I cheat.

For me, it's pretty simple. Beginning with the second slide from that LinkedIn post, I explain what I mean by "I cheat". I have my parsing tools (which I've shared), and I enrich or "decorate" the output based on what I've seen on previous engagements, or gathered from write-ups and information shared online. 

For example, this recent blog post references a write up that describes how Valley RAT stores configuration information and plugins with a specific Registry path. Rather than parsing the entire Registry and looking through that massive amount of information, hoping that I'll remember the Registry path mentioned, I write a plugin that searches for it specifically, and alerts me if it's found. That way, not only do I not have to remember a ton of paths, keys and values, I now have a documented plugin with a publish (and update) date, links/URLs pointing to online references, etc. As many who use RegRipper are aware, I've including Analysis Notes in plugins, describing what to look for, and how the output of the plugin can be used.

In addition, almost 2 1/2 yrs ago, I got Yara running via RegRipper, as well, significantly expanding the capabilities of both tool sets. So, in a way, I'm "cheating" by leveraging a unique capability.

Here's a question I received via email recently, from someone who was reading Investigating Windows Systems:

How does your methodology change when you are investigating a domain controller or server versus a typical workstation?

My answer was, for the the most part...it doesn't. Yes, artifacts may vary depending upon the nature of the endpoint (i.e., server vs workstation, Windows 11, etc.) and what's installed, but the methodology generally doesn't change, unless my analysis goals change. And I've used the same essential methodology for almost 2 decades now, expanding and developing it along the way.

Another question:

When will you write a book on Linux forensics?

Yes, I actually received this question, and not just recently. And I've received it before. Look, there's nothing to indicate, anywhere, that I know enough about performing forensics on Linux systems to write a book, let alone a blog post. I did just talk to someone yesterday (I was serving as a greeter at church) about a Xenix firewall I examined years ago; I was able to image the hard drive, and then open the image in EnCase, but I had no idea where to begin with analysis, particularly given that logging appeared to have been disabled.

Also, there are a LOT of books available on the topic already, so why would I want to put in the effort and expense to just become part of the background noise?

Here's another question I've received a number of times over the years:

Where can I find a list of free images from real incidents?

This one is easy. First, it's unlikely that you're going to find images...disk, memory, triage...from "real" incidents anywhere online. If you do, please let me know. I've been aware of images shared for some time that are contrived scenarios and/or part of CTFs, but I can't image someone would share an image, even a triage collection, from a real, live incident. If you know of someone who did, and the link is still valid, I'd love it if you could share it.

Second, I've posted lists of available images multiple times in this blog, the most recent of which can be found here. 

Windows Defender Support Logs

I ran across a LinkedIn post the other day that  mentioned using Windows Defender Support Logs (actually, I think the post referred to them as "diagnostic" logs). These logs are found in the following folder:

C:\ProgramData\Microsoft\Windows Defender\Support\ 

...and follow the naming convention:

MpWppTracing-YYYYMMDD-HHMMSS-00000003-fffffffeffffffff.bin

The post mentions using strings to parse the files, but I was wondering if there was a parser available, and like Deadpool, I figured I'd go looking...and I found something called mplog_parser. I've had a few opportunities to pull down some of these files from endpoints, but nothing has popped out as being related to the incident in question. 

That's okay, though...I'll keep this one in my kit, and I'll have to give the parser from Github a shot.

Grab Bag

This started out as a bit of an end-of-the-year grab bag of posts, but I don't like simply linking to things, dropping links with no explanation as to why; instead, I'd rather share the why behind what I found interesting about the post or article.

And don't worry...I know after 2025, there are folks out there expecting a flaming bag full of dog poop dropped off on their doorstep, but rest assured...this isn't that. 

Anyway, as I was working on this post, it just sort of rolled into 2026, so I'll start off my first post of the year with a grab bag of things I found interesting right there at the end of 2025. 

What's in your Registry?

CloudSEK recently shared this write-up on Silver Fox; what I found most interesting was from "Stage 4 - Valley RAT", "Stage 2". Apparently, Valley RAT maintains configuration information in the following Registry path:

HKCU\Console

In addition, downloaded plugins are stored in the following path:

HKCU\Console\0\d33f351a4aeea5e608853d1a56661059

All of this means that not only can you get a great deal of info, and develop a great deal of intel from the entries themselves, but they're also tied to a specific user account. When creating a timeline, paths like those used by the Valley RAT should really stand out. 

Speaking of Registry and persistence, DeceptIQ shared this write-up on Registry persistence on 27 Dec 2025. As long as I've been working with Windows systems...going back to about 1995, much further if we're talking about "using"...this isn't something that I've ever heard of, nor have I run across anything like this. 

Interestingly enough, the authors didn't just talk about the technique and reference it, but they also linked to a means for creating an NTUSER.MAN file, and even shared how the whole process might look. 

Information Sharing

If you're interested in how shellcode is "used" on Windows systems, Valli-Nayagam Chokkalingam over at Adversary Craft shared this "101" write-up that you might find useful. I can't say that the write-up leads to viable detection methodologies, as ultimately, finding the shellcode amounts to seeing the bytes in Explorer.exe process memory. However, it is a good "101" level write-up for folks to start developing familiarity with the topic. 

A bit of "saving the best for last", but keeping up the "info sharing" theme, Brett shared a look back to the early days of DF/IR, and how it was built on PDFs and coffee. I remember those days, because at one point I was writing some of those PDFs, and reading many others. I was reading a lot of the docs that got shared not only to get the information from them, but also to help develop my writing style so that what I wrote up would be entertaining and useful to others.

One of the thoughts that Brett's post brought to mind is how we consume information has changed over time. Like Brett said, it used to be PDFs, and in some cases, meeting for coffee (or beer/adult beverages). I started blogging in 2004 because at the time, it seemed like a great way to share information, in one easy-to-reach, easy-to-find location. I know that even since then, there have been folks who've been really successful with YouTube channels, some even getting to the point where they're sponsored. Also, training courses, even those that are self-paced and available online, have been available for some time. 

In his book Call Sign Chaos, Mattis said that "our own personal experiences are not enough to sustain us." While this statement was directed at warfighters, it remains true for other endeavors, as well, and in particular, the various aspects of cybersecurity. Mattis talked about reading thousands of books, and even described his own reading to expand his knowledge ahead of a campaign. Brett taled about PDFs as a means of sharing knowledge and experiences. In both cases, it's incumbent upon someone to write, to document their experiences and share that knowledge.