When Frontier Models Say No: What the Hugging Face Breach Teaches Us About Local LLMs

On July 16, Hugging Face published an article on an intrusion they suffered on their production infrastructure (read it here). The article points out several interesting things worth discussing in regard to AI:

1. The attack was conducted, or the threat actor was assisted, by AI.
2. The attack was detected with the help of AI.
3. The attack was investigated with the help of AI.

Points 1 and 2 are interesting, but as a digital forensics and incident response (DFIR) practitioner and instructor, I want to focus on point 3: how AI was leveraged to assist with the investigation.

Throughout my career in DFIR I have always been a proponent of open source, including releasing some of my own tools for parsing artifacts. I also know that sometimes the best tool for the job is a paid one. Many SANS classes take that same "right tool for the job" approach. The class I author and teach, FOR563, focuses on using open-weight, local large language models (LLMs). There are some very compelling reasons to do so. Probably one of the biggest is that running a local LLM lets you keep your data private, since it never leaves your environment. It can also help reduce costs when you're processing a large volume of data, which DFIR practitioners commonly do. It also means you're not subject to the content restrictions and rate limits that commercial providers put in place, restrictions that are built for the average user, not analysts digging through massive amounts of data and logs.

The Hugging Face article reinforces some of these reasons. Frontier models are usually best in class, but they do impose limitations, and sometimes it makes more sense to use a local model instead. After the intrusion was detected, Hugging Face's team attempted to use frontier models as part of its log analysis, but it didn't work. Its requests were blocked by the providers:

"...the analysis requires submitting large volumes of real attack commands, exploit payloads, and C2 artifacts, and these requests were blocked by the providers' safety guardrails, which cannot distinguish an incident responder from an attacker."

To that end, the team turned to an open-weight model (GLM 5.2), running on its own infrastructure, which didn't have that limitation. Because it stayed on their own infrastructure, it also had the added benefit of not leaking data or the credentials that were compromised during the attack, out to a third party.

This real-life incident clearly highlights the benefits of having your own local model to assist with investigations. Open-weight models being released right now are highly capable and can assist examiners in plenty of situations.

Threat actors are likely already using them to bypass the restrictions commercial providers put in place, similar to what Hugging Face ran into from the defender's side. Defenders need to keep up, and know how to leverage them too. Hugging Face's own recommendation reinforces this: Have a capable model you can run on your own infrastructure, vetted and ready before an incident hits, both to avoid guardrail lockout and to keep attacker data and credentials from leaving your environment.

There are thousands of open-source models available that can help examiners with numerous tasks. You can build a local agent to help with your analysis pipeline, use one to help review malicious code, and lots more.

Does this mean you should use only local models? No. Just like the rest of our workflows, sometimes it makes sense to go open source, and sometimes it makes sense to reach for a commercial tool. What's nice is that many of these workflows can shift between the two seamlessly, depending on what the job in front of you needs.

This is the core focus of FOR563: leveraging local LLMs for digital forensics and incident response. In the course, we focus on:

• Deploying and configuring local LLMs, both through a GUI and programmatically
• Building custom AI agents for forensic and incident response use cases
• Analyzing structured data, including logs, text messages, and databases, using natural language instead of writing one-off parsers
• Fine-tuning models on your own datasets for specialized DFIR tasks

If you're interested in learning more about FOR563, check it out.