Welcome to Issue #169 of Detection Engineering Weekly!

✍️ Musings from the life of Zack:

• It’s getting a bit colder here in New England, but to me it's the perfect temperature. 70F/21C during the day and 55F/12C at night. Sweater weather and I can still wear some shorts :)

• My kids started school this week, and it's a huge transition for them. Shoutout to all the parents who deal with overtired and overstimulated kids as soon as they get off the bus, because ooo boy this is crazy!

• I’ll be in NYC this month and next month for work. I’m excited to be back, as it's been a few months, and it turns out I’ll be there during fashion week, so you can expect me to be dressed in couture. I just have to find some affordable couture first

💎 Detection Engineering Gem 💎

A scenario to evaluate your Agentic SOC by John Ao and Michel San

The commoditization of Agentic SOC is a good thing for all of us. And what I mean by this is that the techniques we see from evals, like the one in this blog, weren’t built in the open by AI SOC companies. This makes sense from a purely business perspective: evals and harnesses remain moats for startups, allowing them to show how differentiated their products are and sell to companies that need them. As general knowledge for agent architecture entered the security zeitgeist, these moats shrank and teams started to roll out their own capabilities. This is a natural evolution of any security capability.

Evals are so important for testing whether your harness will work in a live environment, and I’ve featured so many of these evals from blog posts, like from friends of the newsletter at Cotool. This blog by Ao and San feels like the most advanced because it covers a full end-to-end intrusion:

There’s a lot going on here, and I highly recommend clicking through to read their research, but it’s a TeamPCP-like compromise. It starts with a malicious pull-request workflow execution that poisons a cache inside a privileged GitHub Actions release build, where the poisoned image is run on Kubernetes, and the attacker priv esc’s out of the Kubernetes cluster compromise to gain full AWS account-level control.

They ran several frontier models through the scenario with Splunk API access. Five of seven assigned the initial alert a false-positive or benign-positive disposition, which is an immediate failure under their scorecard. Claude Opus 5 identified the attack as malicious, but achieved only 29% of the weighted investigation score, in part because it confused some malicious traffic with legitimate developer operations.

The validation gate is the most interesting here. The 29% number from above is a cumulation of scenarios each model correctly identified:

This report card raises the bar for evals in that it’s not just about precision or recall from True Positive/Benign/False Positive, but about the quality of the report. As it finds more and more parts of the attack chain, the model should provide evidence to the person investigating the intrusion. It also helps identify IOCs, distinguish legitimate activity from adversary behavior, and provide an analyst with enough evidence to scope and respond to the incident.

🔬 State of the Art

I’m in your logs now: deceiving analysts and blinding EDRs by Olaf Hartong

This blog by Hartong is a comprehensive deep dive into Windows telemetry and its use in security. Microsoft’s Event Tracing for Windows, or ETW, is a critical technology used by EDRs and SIEMs for performing detection & response. It has a few advantages: it’s a native technology shipped by Microsoft, so it’s a standard, supported way to collect telemetry; it has a pub-sub architecture to ensure you collect only the events you need; and it’s safer than shipping kernel modules that could brick a system.

Security tooling adopted it because it provides great visibility, but it was not designed with security in mind- more so observability. That distinction becomes important when security tools turn ETW events into cloud telemetry, detections, and analyst evidence, which is what Hartong’s research is about.

He starts with the useful defender goal of generating synthetic events to test detections without repeatedly emulating attacks as you would see on Atomic Red Team. He created his own ETW subscriber and producer, reproduced the data structures and payloads, and began sending them to Microsoft MDE. Once MDE began accepting telemetry, he began testing whether it could distinguish synthetic events sent from his tooling from actual events generated inside ETW.

Hartong essentially tricked MDE into believing the telemetry submitted on the local machine was authorized, without checking whether it was synthetic. Theoretically, this meant an attacker could submit confusing or incorrect telemetry from the Windows box on behalf of the ETW provider, which could trick a SOC analyst. I am unsure how likely this attack vector is, but IMHO, the point is more so that synthetic logs have their place in testing, but full end-to-end testing of an attack → alert helps guarantee that the full pipeline works.

A call for collective action on cyber defense by OpenAI

This security call-to-action letter from OpenAI is riding the tail of several disclosures that I’ve covered, including one from OpenAI itself, in which frontier models autonomously breached companies to solve a task given to them in a lab environment. It’s been making the rounds: 100+ companies signed it, including my own (Datadog), and I think the message is important, but I wonder if it’ll have any effect. Many open letters like this help grab headlines and signify commitment, but I don’t necessarily know what these companies and organizations will do differently after publication.

Now, I do think we need to stop being in awe of models that find vulnerabilities while stopping at the hard parts of patching and detection. I’d like to see more experiments and research into active agentic defense, where we build guardrails in a way that an agent stops an active attack without human intervention. This is the hard part because it’s based on trust rather than capability.

So who’s up for the challenge? :)

Inside Elastic's agentic SOC: How we took AI alert triage from 60% to 92% accuracy by Maggie Musquez

This post by Elastic’s internal SOC is similar to what I featured in Issue 166 from Figma. Elastic is a security company, and similar to my $DAYJOB, they are heavy dogfood users of their own products. They started rolling out an AI-SOC like triage agent and according to Musquez, it was hovering around 60% accuracy in terms of analysts agreeing with the agent’s analysis of an alert.

Much like Figma’s post and others in this space, the Elastic team began to build multiple agents to replace one-shot analysis. The goal here wasn’t just to ensure it reached the correct verdict: similar to what we saw in the Gem above, these investigative summaries needed to be actionable and of sufficient quality that a SOC analyst could quickly orient to the case and choose to escalate it or close it out.

They saw accuracy increases when they began adding context to the investigations themselves, primarily around:

• Past cases with the same rule name and making sure the investigation notebook inside the rule was high quality

• Workday enrichment to provide context around the employee itself

• Learning from past verdicts to steer the agents investigation

These enrichments, alongside more granular agents tasked with summarization, gathering evidence and pattern finding, moved their case accuracy to nearly 92%.

There’s some potential product pitches in the blog, but I’m not mad about it because the story was around dogfooding and building out in the open.

💬 Reddit SecOps Discussions

What is actually expected from a cybersecurity manager at a FAANG-level company?

It’s always funny reading Reddit discussions because there is a self-selection bias: those who respond tend to be negative. But I liked this thread because it gives a bit more insight into how management works, and doesn’t work, at a large tech company. I am also biased here in that “I” am a manager at a tech company, but for those who do want to get into leadership, especially in a SOC-like role, this is a great post to read.

Lazy Colleagues?

In this thread, the author, who works in a SOC, asked others about his colleagues who tend to pick up “easier” SOC tickets to complete, whereas he has more complicated ones. He ascribes this to laziness, and some replies suggest there may be a performance metric, such as the number of tickets closed or the time to close tickets. I think these are all fair points, but if I were mentoring this person, I would tell them to use their status as the “dependable one” to find more opportunities within the organization.

It’s a hard problem: the SOC is a grind, and you want to be a good teammate, but you likely have different aspirations than your colleagues because we are all unique in our goals. I would turn a situation like this into an opportunity for this person to start finding and proposing ideas to solve team or structural issues, as this is a clear indicator of a more senior analyst within a SOC.

☣️ Threat Landscape

Threat Road

Active PaperCut exploitation and the patch that changed overnight

What Happened…

Read more

7 days ago · Threat Road

I just found this publication on Substack, and what I appreciate about the way this post is structured is that it provides specific detection and learning advice for a vulnerability. PaperCut is a print management software used by companies to manage and deploy printers. I don’t necessarily know why someone would want this exposed to the Internet, but that was part of the attack path, not the two vulnerabilities released by PaperCut.

Threat Road highlights the full attack path for an attacker to gain privileged access to a PaperCut server within a network: the server must be Internet-facing, a configuration change must occur before an authorization check, and a separate deserialization step can turn the attack into an RCE.

They give practical detection opportunities in terms of what to look for and which logs you can use in your SIEM, as well as practice labs to understand the full attack path.

Improving our alignment and security efforts by Anthropic

Anthropic provided a post-mortem on their recent disclosures that early-release models broke out of the training environment sandbox and breached other environments. I do think some of this is interesting, and some of this feels.. standard practice?

They do take some time to explain how they are reconfiguring the model itself to make sure that it doesn’t perform harmful tasks when its given an impossible task (one that it can cheat on, such as CyberBench). I do find this bit sort of funny, though:

By default, all cyber evaluations should run inside a hardened sandbox (an isolated computing environment) with no internet access.

I wonder what they mean by "no Internet access," since OAI’s incident involved granting access to an Artifactory server to install packages. The models found an SSRF vulnerability inside that environment to achieve Internet access.

The Hugging Face Incident Is Not an AI Story by Marius Horatau

This blog post is a nearly perfect follow-on to the Anthropic post-mortem listed above. Horatau read OpenAI's Hugging Face Incident Report and shared his thoughts on some of the relatively basic isolation failures present in these eval environments. Although I enjoyed reading and watching the OpenAI post-mortem at Black Hat, the specifics of the breach were unremarkable from a detection standpoint. Horatau points out three failures:

• No security assessment on the sandbox environment. Horatau’s point is that this environment appears not to have gone through an assumed-breach assessment, or if it did, it was inadequate

• The alerts that did fire for the initial port scanning and message board triggered an incident, and the team contained it. There was no indication of any follow-up items to trace the attack path, and the agents began their exploitation runs again the next day

• It’s not apparent that any alerts fired on the security boundaries that seem standard to alert on. Any one alert on the sandbox gaining root on its host, a workload creating a privileged host-mounted pod, or a sandbox identity becoming Kubernetes cluster-admin should have fired an alert

🔗 Open Source

tailscale/tailcat

Tailcat is a netcat-like utility that you can use over a Tailscale connection for encrypted transfers. You don’t need the Tailscale control plane, but you still need an account to use it over their data plane. It does everything you’d expect a raw TCP listener/sender or netcat does: piping stdin/stdout, TCP forwarding, file transfer, SOCKS, and an exit-node mode.

DavidCarliez/cover

This is a neat sandbox-like project that performs inline replacement of secrets so your agents never see the “real” secret inside its environment. It’s essentially a proxy that replaces secrets with realistic stand-ins before they reach an external model, then it restores the originals only in responses that return to the local environment.

Azr43lKn1ght/DFIR-LABS

This repo hosts a free, community-built collection of Windows-focused digital forensics, incident response, malware-analysis, and threat-hunting challenges. Challenges range from easy to “insane” difficulty. It looks more like evidence-driven incident scenarios rather than only CTF flags.

Kerberosse/soc-dataset-thebiggerinterview

Ao and San’s investigation scenario used in their blog post from the Gem listed above. Sets up a local Splunk instance, ingests over 2 million events, and indexes them so you can point your own agents at it for evals.

Welcome to Issue #168 of Detection Engineering Weekly!

✍️ Musings from the life of Zack:

• I’m in my hometown this week with family, and I forget how much I love NY weather during the summer. You can throw a rock in any direction and likely hit a lake or a river here!

• For the first time in a long time, I neglected to bring running shoes and workout clothes to an extended vacation. I’m dying over here: I’m eating way too much food and have no counterbalance to work all of the calories off. I basically need to sneak away during the day and do pushups in a corner of my room if I want any semblance of a workout

• I keep getting notifications from Substack that my newsletter is part of a leaderboard for “Rising in Technology”. But everytime I check the board I don’t see my name :( maybe the leaderboard is so competitive I only get it for a few hours at a time

  

Sponsor: Detections.ai

Coverage analysis, tuned to your environment

detections.ai Enterprise builds a baseline of the tech you run, the detections you already have, and threats you care about. New intel gets analyzed against that baseline continuously and automatically, with notifications when we find gaps.

You get coverage answers specific to your environment. No generic MITRE ATT&CK percentages: what applies to you, what you already cover, what’s a gap, and why.

Detections tuned to your data sources and existing rules, ready to sync back to your stack.

Book A Walkthrough

💎 Detection Engineering Gem 💎

Where do Detection Ideas Come From? by Gary Katz and Jason Deyalsingh

I’ve written a ton about detection backlogs, even dating back to Issue 4 in 2022 (!). In my years of building a detection engineering function, the detection backlog and its management have been a hot topic in planning work for the quarter or even the next few weeks. You try to cover and document as much as you can, and we typically ask the questions:

• Do we have the right breadth of coverage?

  • Did we onboard any new technologies that we need to log?

  • Are we covering every tactic in ATT&CK for an attack surface, such as host or cloud?

• Do we have the right depth of coverage?

  • How many techniques are we covering in ATT&CK?

  • Were there any new red team exercises that discovered gaps in catching techniques?

Note that the questions are insular, as in, they don’t encapsulate what threat actors are doing targeting a business that looks similar to yours. I can spend so much time writing rules for Active Directory, but if Active Directory accounts for a small percentage of the environment, then it may not be the best use of time.

That is why I like Katz and Deyalsingh’s framing in this blog. They describe four places from which detection ideas can originate: visibility (breadth), existing detections (depth), the environment (context), and threat-intelligence research (environment X the threat landscape). The useful part here is not picking one as the right starting point. It is using the other three as filters.

They make the argument that a rule request or a Sigma rule you find online is not automatically backlog-worthy. They ask and answer much better questions than I did earlier. You should look at the existing visibility: is there existing coverage, or are the relevant adversaries using the technique against a company like yours? The same logic applies in reverse when you start with a new log source, a critical asset, or a threat report.

🔬 State of the Art

How Well Can Open-Weight Models Evade SIEM Detection? by Daniel Knight

With the latest news about frontier, low-guardrail models breaching legitimate companies, it’s good to see open research into how similar incidents could occur with an open-weight model. In this post, Knight emulates a small- to medium-sized business lab environment with a full Wazuh stack to show how their open-weight model, Sable, combined with other models, can successfully compromise the environment.

The testing showed that their autonomous agent could reason over an Active Directory environment, validate a multi-stage ACL delegation path, select lower-artifact techniques, and complete a domain-level compromise without generating a high-severity correlated incident in Wazuh. The goal here wasn’t to compare and contrast the model's expertise in this environment. What I took from this was that the lack of guardrails within open-weight models is the barrier to entry to this type of setup.

The other interesting things was that the model was smart enough to do things like sleep in between attacks so that it can outlast correlation windows, use as much living-off-the-land binaries as it could, and a custom in-process HTTPS C2 framework:

The beacon was designed as a lightweight, memory-resident HTTPS polling channel rather than a conventional installed implant. Contrary to popular opinion, you can’t expect to run Winpeas and not get caught. It ran within WS01’s existing WinRM worker process, wsmprovhost, under a Kerberos-authenticated administrative session. The agent used a dedicated HTTPS endpoint, certificate validation, encrypted task exchanges, randomized callback timing, error backoff, and a defined kill date. Commands were queued by the control service and their results returned during later callbacks.

I do have some good news, or at least hopeful news, after reading this post. I think we are going to see more experimentation with the efficacy of open-weight models for adversary simulation, which means we need a separate response on the threat-hunting and detection side of the house. This includes being autonomous enough to deploy rules, hunts, and containment actions.

Beyond Detection: Getting Real Value From Sigma and YARA Rules Across EDR, NDR, XDR, and SIEM Tims Tittus

This is a great introductory post for those trying to understand both the differences among detection products and the applicable rules. Tittus does a particularly good job of distinguishing between writing detection rules against logs using Sigma, which should catch behavior, and writing YARA rules against files and memory, which is strictly pattern matching. They both have their place in the detection stack with their corresponding strengths and pitfalls.

I copy-pasted the table into ray.so for some prettier formatting:

I’ve generally viewed YARA as the earliest or latest stage of an investigation. The early stage is identifying known malware patterns and making a block-or-alert decision in EDR or NDR. The EDR can generate a log with an enriched view of the binary and YARA output. It’s also a great threat-hunting tool, where you don’t mind sifting through false positives to help tune the rule and avoid overwhelming the SOC.

Self-Study in The Age of LLMs by Jared Stroud

At DEFCON, I caught Jared’s talk on finding vulnerabilities in bootloaders via directed fuzzing. It’s his PhD research for his PhD, and as someone very unfamiliar with fuzzing in general, it was a fascinating approach that combined static & semantic code analysis rules with LLMs to find entire vulnerability classes. After his talk, we were walking around the DEFCON floor, and I asked him for his thoughts on using LLMs in PhD research and what he likes and doesn’t like about them.

I felt somewhat validated because he wrote a blog post afterward about how he uses them as a self-study tool and “adversarial advisor” to help him understand complex topics, papers, and codebases. This is very similar to what I wrote in February earlier this year. Basically, if you can prompt chat and coding agents in ways that serve you as a learning or study buddy, it can significantly accelerate your understanding of a subject rather than trusting the output.

Jared warns about this in the post: it’s not about quizzing yourself and trying to recount answers in a cliff notes style quiz, but rather, using them to play roles or create labs for yourself to complete. For example, when trying to understand a codebase, Jared has the agent create a multi-module, graduate-level learning lab split between several chapters. He can work through each lab and break the work up in a way where it’s not overwhelming. I think the same can be applied to detection engineering and security operations concepts, rather than jumping right into a class of detection rules without understanding the underlying behavior of an attack.

💬 Reddit SecOps Discussions

Log everything, I’m begging you

I liked reading this discussion because it highlights the two biggest pain points for security teams: visibility and cost. There is no rule without telemetry, but if you aren’t being cognizant of cost while logging everything you can, you’ll be drowned out by a large logging bill or too many alerts that can overwhelm a security operations team.

There are certainly strategies to help reduce cost while still logging as much as you can. Many solutions decouple storage and compute, where you can store lower-value logs, such as DNS or HTTP traffic, and rehydrate them only during an investigation.

The key argument here is intentionality IMHO. If you just “log everything”, you’ll lose on the cost front and frustrate coworkers and your finance department. You may want to keep ALL DNS logs, and as long as you have a good business justification, it shouldn’t be an issue. Perhaps you do have great rules or a very specific compliance requirement to do so, but the key is to write that risk down and make sure people understand it.

Does a SOC have to constantly justify its existence?

Maybe I’m biased since I’ve been in the industry for 15 years, but I do think that it is much harder for people to break into security now than when I first started working. A lot of social media posts naturally highlight the negatives of security: costs, difficulty finding jobs, layoffs, and security breaches are all topics I see across different platforms. So when I see a post like this, I worry that, as a community, we tend to present the negatives to others rather than the positives. But isn’t that what the Internet is for?

Security teams are there as a hedge against control failures. So, no, a SOC doesn’t need to justify its existence, because I try to internalize that if a threat actor makes its way into my organization and detection rules are the last line of defense, there were many failures that happened along the way. I think this is the perspective that new grads should bring into their first SOC jobs. When you identify a threat actor, work quickly to contain the breach, and let yourself shine as you write the post-mortem. What controls failed? What classes of rules were missing? Can you remove rules after you implement a new control, because the rules become less relevant?

This approach is where I see entry-level security people become very successful. Security is a cost center, but that doesn’t mean we can’t help appropriate that cost in different ways.

☣️ Threat Landscape

More Criticals, Less Dopamine by Ananda Dhakal

I feel like vulnerability researchers are having an identity crisis over the last year. Large language models, starting with Opus, began challenging human expertise due to their speed in orienting to new codebases. A singular prompt and getting a cup of coffee can create an expert vulnerability researcher for a codebase. This wasn’t the case before, as Dhakal puts it, where the painstaking process of learning the codebase was part of the journey.

Although we’ve leapfrogged our capabilities for vulnerability analysis by throwing code at agents, we still haven’t clarified what it means to resolve and patch vulnerabilities. This is where I see vulnerability researchers getting stuck the most. The dopamine hit may not be as strong when we find a PoC with Opus, but IMHO the hard work is shifting towards patching and prevention. That work is severely underserved, and we could use help from brilliant researchers on solving that at scale. It’s not really impressive to me anymore, since people find vulnerabilities so easily; the barrier to entry for finding them is much lower.

I want to keep doing vulnerability research. But, I want to do something more than just abusing llms and hoping they pop a shell.

Post-DEF CON Phishing Uses Google Doc Apps Script to Deliver Malware by Jonathan Semon, Ryan Dowd and Ben Nahorney

Huntress Researchers uncovered a ClickFix social engineering campaign that was unique for two reasons. The first reason is that it specifically targeted security researchers on X during DEFCON. A fake X account reached out to researchers both publicly and via DMs, trying to get them to navigate to a malicious Google Doc. This is the really cool part, and forgive me for the screenshot because it won’t let me link to their video (though you should go watch it!)

The lure is a typical encrypted document pretext. The attacker sends a decryption key to the victim; the victim tries to paste it into a custom sidebar on the right, but it displays an error and prompts the victim to copy-paste the ClickFix payload.

The clever tactic is the custom sidebar itself. Apparently, in Google Docs, you can load a custom Google Docs App Script to automate certain tasks that help interact with the document itself. The Huntress team reverse-engineered the App Script and found a reusable template for malware delivery. It’s basically like a JavaScript payload but inside a trusted container. It sent victim information to a Telegram bot and served malware based on whether the user was on macOS or Windows.

We burned 11.7bn tokens to find the best cyber AI model by Philippe Dourassov and Debarshi

Aikido Research created a CVE benchmarking harness to measure the discovery of recently disclosed CVEs by leading Frontier models, both open and closed weights. They assessed 32 recently disclosed vulnerabilities, with each model receiving three independent attempts. They then combined each model's attempts, which materially improved recall, but it also created more candidate findings for the rest of the pipeline to validate.

Much like Daniel Knight’s blog post above, this is a reminder that the model is only one part of the system. The discovery harness, number of runs, cost, validation workflow, and tolerance for false positives are just as important as the precision and recall metrics on the final chart. I am getting more and more excited about these open-weight models because they’ll hopefully drive costs down and put more purchasing power in end users' hands.

🔗 Open Source

sunlife3/needre

neEDRe is a small, experimental Linux EDR built in Rust with Aya, an eBPF library. To me, the repository reads more like a learning environment and project than a full-blown EDR, but this is the kind of project that detection engineers need to do more of to understand how these technologies work under the hodo. Following Jared’s blog listed above in State of the Art, you can ask an agent to build a curriculum to understand how eBPF works under the hood and to extend the detection capabilities in neEDRe.

horsicq/XPEViewer

Cross-platform PE file viewer and editor that runs on Windows, Linux, and macOS. It is designed to inspect Portable Executable internals without requiring a full reversing environment, making it useful for fast malware triage and detection writing. There are plenty of tools in this category, but I thought this was interesting due to the cross platform support and if you need it in a pinch.

Zyrexnn/Cybermes

Cybermes is an autonomous offensive-security and bug-bounty framework built around the Hermes Agent, several Go utilities, MCP integrations, and more than 200 skills. It wraps security tools such as subfinder, httpx, katana, ffuf, nuclei, and sqlmap, writes the raw output to disk, then uses a custom tool called smart_pipe to extract the meaningful output to save on token and context window costs.

It’s gotten a ton of stars on GitHub recently, so I’d be interested to see if anyone is running this with any modicum of success. Hermes is the new OpenClaw and people seem to really like it, so a security version of it for bug bounty might be fun to run.

armourinfosec/Offensive-File-Transfer-Techniques

This repository is a collection of file-transfer techniques for Windows and Linux that can serve as a useful lexicon for those who want to build detection around exfiltration or transferring of data to evade detection.

It has a good split of modules and case studies to look through. For example, the section on netcat and Socat has some classic red team tradecraft on using these tried-and-true tools to get around egress filtering. IMHO, pick the transfer methods that map to your environment, run them in a lab, and identify which telemetry you can use to detect.

Welcome to Issue #167 of Detection Engineering Weekly!

✍️ Musings from the life of Zack:

• I had a fantastic time at Hacker Summer Camp! Thank you to everyone who came to my Happy Hour, where we had nearly 300 registrants!

• I did an awesome panel with and on SIEM and security operations hosted by Decibel Partners. Shoutout to for wrangling us together and giving me the creative space to try something a little different with the format

  

• Last but not least, I hosted a Detection Engineering panel at the Blue Team Village with leading experts in the space: Christina Parry, Chris Kulakowski, Alex Hurtado and Chase Phelps. According to the organizers of the Village, it was one of the largest turnouts they’ve ever had. The line to get into the talk stretched well beyond the village.

  

Sponsor:

Your security architecture matters more than your AI model

Security vendors are racing to ship better AI models, but their architectures are dragging down their models. Even peak AI can’t overcome a limitation like a global detection model shared by all customers.

Join Josh Kamdjou (CEO, Sublime) and Dmitri Alperovitch (Co-Founder, CrowdStrike) on September 10 to hear why detection architecture determines what defenders can actually do to close gaps, and find out what it looks like when your platform can autonomously close gaps in hours, not on a lengthy vendor update cadence.

Register Now

💎 Detection Engineering Gem 💎

Every time I attend Hacker Summer Camp, I try to survey the thousands of talks and build a rough logistical plan on how I can attend them. The plan never works because Vegas is way harder to navigate between the casinos, taxi lines and long Uber waits, but if I can attend 20% then I know I’ve done well. So when I saw this talk on the HuggingFace incident by OpenAI security on the schedule, I got excited because it was featured on my newsletter and it spawned subsequent disclosures by other labs.

To the surprise of no one, I was too far away at an event to attend this specific one, so luckily Black Hat published the video :). I highly recommend watching or at least listening to the briefing. The security incident details are, IMHO, insignificant in the sense that they are nothing unique to what we haven’t seen before. The details behind the evaluation environment is the most fascinating.

We know that the Foundational Labs have model evaluation environments to help determine the efficacy of their newest model releases. Of those evaluations, OpenAI and many others run ExploitGym as a cybersecurity benchmark. OpenAI’s ExploitGym environment did not have Internet access to make sure it couldn’t cheat, but it could use internal resources and tooling, such as Artifactory listed below.

The OpenAI team runs thousands of reinforcement learning evaluations on these models, so they give what they call “impossible tasks” to agents to see how they perform. These tasks can include writing an exploit for a vulnerability, or performing some calculation in a Google Sheet that requires Internet access. This helps guarantee that the models don’t “cheat” by using the Internet and can perform the task at hand. The impossible task runs across May yielded three distinct things:

• Agent runs found file write access (I’m unsure if this is a vulnerability, it was hard to tell in the presentation) to Artifactory which created a pseudo-message board scenario. Agents used this message board to communicate with each other

• An agent found an SSRF in Artifactory itself, which gave it internet access to help solve the impossible tasks

• A separate agent found an RCE in Artifactory from a legacy auth endpoint, giving it command and control access to Artifactory

These three things are important, because OAI found this activity prior to the Hugging Face Incident. They patched the vulnerabilities and redeployed the infrastructure. The issue was that this data was held in the memory of subsequent agent runs because the data made it back into normal agent evaluations. So they had a memory that this was possible!

The agents used this exact memory to re-create the message board and the subsequent attack paths through Artifactory into Hugging Face. They found different vulnerabilities and were so obsessed with their “impossible tasks” that it resulted in a real world breach. The agents determined that Hugging Face contained the shortest path answer to completing their evaluations, so they found a deserialization vulnerability in how Hugging Face loads dataset evaluations and chained that with a Jinja injection vulnerability to gain a foothold into Hugging Face’s environment.

I highly recommend watching this, it was a trip and one of my favorite talks of the conference.

🔬 State of the Art

Threat hunt AI: How we built an AI security analyst on AWS for under $500/month by Pablo Vidal

This post by Vidal outlines how their detection & response team runs their autonomous hunting and triage agent. It’s built on Serverless architecture on AWS: agents run as a container on AWS’ Elastic Container Service Fargate, and the agent loads in several hunting and detection configurations via YAML. It uses Snowflake as their longer term storage for alert and telemetry data while using 2 weeks of log, metric and traces data on Datadog (yay!). It integrates directly with their alerting and investigation workflow via JIRA and Slack.

The interesting design choice here is the multi-phase investigation. Sonnet is used as their data gathering agent, while Opus compares potentially malicious behavior to one- and seven-day baselines. It’ll enrich suspicious actors and resources, scores confidence, then uses a separate Opus agent to perform adversarial validation.

The final adversarial phase must produce specific counter-evidence before it can dismiss a finding, such as an allowlisted service account or an established false-positive pattern. Vidal says this reduced noise from roughly 40% of findings to a level where most results are worth analyst review. The title does say it ran for under $500/month, but that is an additive spend since we don’t know what their Datadog & Snowflake spend is.

Introducing Deputy: Better signal and control for software supply chains by Kent Gruber

Deputy is a rule-based language for detecting and enforcing security controls on vulnerabilities found in CI/CD. I included this blog in particular due to its similarities with how security operations deals with threats. The tool introduced in the blog, Deputy, helps find and alert on potential policy violations when code is being introduced into a source code pipeline. It uses a YAML based language, and the rule language is CEL, which we’ve featured on a previous issue with Perplexity’s numbat project.

There are nearly 60 policies in the repository, and each policy has several rules each that help enforce the policy. Enrichment is a key component to the policy engine, Deputy precomputes values to pass along to CEL so the rule language can alert on things like critical vulnerabilities, the presence of a vulnerability in KEV or a new container image that contains a critical vulnerability.

According to Gruber, the project is early and it will not replace reachability or application-context analysis. But the policy and rule model is worth studying. Supply-chain controls are more likely to survive when the same decision logic follows developers, CI, package proxies, and coding agents, and it introduces the funnel of fidelity effect on an attack surface not traditionally monitored by security operations engineers.

Detection Skills by Vega Threat Research

Detection-as-code has gained a ton of popularity in the last few years because it helped build resiliency in the quality of a rule as it moved through ideation, implementation, review and deployment. These pipelines help do everything from linting, to applying governance checks around reviewers and deploying only via Terraform, as well as applied testing via Atomic Red Team and the myriad of other testing suites. Agent skills are the next logical step of adding security agent steering-as-code to triage, response and detection engineering agents in prod.

I ran into Eli Rozen at the Vega booth at Black Hat, and he showed me their research around Detection Skills. This is a great concept: as detection engineers, we need to think about codifying the investigative and analytic knowledge we use for alert triage and tuning as much as the detection logic we deploy everyday.

The Detection Skills OpenSpec is Vega’s contribution to the detection engineering world that helps keep the detection logic in the detection platform, then attach a portable  SKILL.md  package containing the triage, investigation, and tuning work surrounding an alert.

A detection can start with a deterministic query, invoke an agentic triage skill, pass its result to an investigation skill, then send the outcome to a tuning skill that proposes a change for human review. According to this spec, skills can bring focused references, lookup tables, prebuilt queries, and enrichment scripts without loading every detail into an agent’s context window upfront.

The Vega Threat Research team published 50 skills with this initial release, so it’s really cool to see them build in the open and share their knowledge with everyone else.

ATEN: Endpoint Telemetry for AI Coding Agents by Anton Ovrutsky

Over the last two weeks, I’ve featured “AI-EDR”-like releases from Perplexity’s Numbat & Uber’s ADR projects. The development of security telemetry on coding agents makes a lot of sense. They have agent in the name, so much like an EDR agent on a host or a CNAPP agent running in the cloud, you can extend Claude-et-al to generate contextual coding session telemetry. This is the first post I’ve read on the concept of AI-EDR that brings receipts of how it works during an investigation.

In this post, Ovrutsky releases his ATEN project which provides coding agent security telemetry. Unlike Numbat & ADR, it’s observe only, but there are some unique elements to it that differ from those two projects:

• It reads each prompt and creates an intent trajectory, meaning it’ll enrich the prompt with additional information such as tool calls, agent session and results. This helps create an index of sessions to answer the who later on

• It uses Kernel-level collectors (Windows ETW, Linux eBPF) that records the action taken on behalf of the above intent. These collectors focus on host and network telemetry

• It combines the intent and the Kernel telemetry into a full picture, reconciling the underlying action of the prompt and tool call with the on-system activity

He has several examples of running prompts and viewing the output in Splunk. The Splunk queries and subsequent responses expose the intent and action from the session and gives a much richer view into what happened.

For example, he issued a prompt to run a health check inside a code repository, and the health check was a PS1 script that ran additional Claude prompts. The process chain is a mess if you look at EDR or ETW logs, but with ATEN, you can follow the chain-of-thought via the intent and the kernel actions in one view.

☣️ Threat Landscape

Lol agentic cyber breaches and the hype train

I am trying not to be facetious here, but I do want to point out some news announcements of organizations besides OAI/Anthropic who are disclosing security incident breaches due to training models with no cyber guardrails. I think it’s important we keep reading about these for two reasons:

1. It demonstrates that we need to seriously consider an agentic or autonomous approach to defense, as we will likely expect more of this in the future

2. The absolute craziness that these incidents come across more as cool than “dude you just breached my company”

Incident Report: unsanctioned agent behaviour during cyber testing by AI Security Institute

The AI Security Institute was running cyber evals with Mythos 5 and GPT-5.6-Sol with guardrails removed and found that less than 10% of their runs contained evidence of models trying to solve a challenge by attempting to breach organizations outside of their institute. The crazy finding here, IMHO, is that one of the models tried to insert malicious code into an open-source project and engaged in social engineering with forged identities to try to get maintainers to merge the project.

They released an in depth technical report alongside their announcement. The one thing I don’t necessarily understand here is that their eval setup permitted Internet access. OAI and Anthropic, for example, explicitly restrict Internet access, because they issue impossible tasks where they want to evaluate how the model reasons through solving the task without trying to cheat.

Meta says its AI model breached a third-party company during testing by CBS News

It was very difficult for me to find a source blog for this story, but I learned that it’s because Meta never released one. Meta spokespeople reached out to several news networks and disclosed that one of their models broke out of their training environment during training and breached an AI safety company called Irregular. Funny enough, Irregular has no blog or post-mortem on the breach, so I hope we can see one soon and see how the discovered vulnerability was exploited.

Other news

Zoomsday by Idan Levcovich

Levcovich released a blog on several vulnerabilities found by the A research team in Zoom. The research details how Zoom’s annotation protocol allowed an attacker to send a crafted annotation message that crossed a role boundary, reached a victim’s deserializer, and triggered memory-corruption bugs in the shared cross-platform annotation library. The deserialization part is interesting: according to Levcovich, Zoom has an undocumented serialization protocol with annotations to help it transcribe drawings on screen. They abused this serialization to achieve remote code execution.

I like that they included the prompts they used to help target Zoom. They decompiled the APK app for Android, and ran a threat modeling prompt, and discovered a shared library that contained the serialization protocol. Zoom issued 3 CVEs, 2 specifically for A Security and one for a separate vulnerability they found but was already disclosed to Zoom security.

ExfilSquad: New Data Extortion Group Leaks Microsoft D365 Data, Likely Linked to Misconfigured Power Pages by Fortra

TIL what Microsoft Power Pages are:

Quickly create enterprise-grade AI-driven business portals with built-in agents. 

According to Fortra researchers, ExfilSquad, a new data ransomware group, exploited default configurations in Power Pages to gain malicious access and exfiltrate data from 15 victim organizations. ExfilSquad released data from 13 organizations, totaling roughly 382 GB and 27 million records. The leaked JSONL and CRM/ERP fields are consistent with Dynamics 365 exports, and Fortra found no evidence of ransomware deployment.

In the rush of pushing out as many AI products as possible, Microsoft likely didn’t consider threat models surrounding products like Power Pages. Default configurations are tough: we learned how to harden things quickly when we ran our own servers internally after years of pain. The hard part for me here is that when I procure a SaaS product or deploy a product from a cloud provider like Microsoft, I would expect more attention to detail that we trust them with securely deploying it.

🔗 Open Source

CDESpace/Detection-Skills

GitHub link to Vega Threat Research’s detection skills blog. Contains the full specifications and example skills to inject into your own agentic workflows.

Antonlovesdnb/aten

Anton Ovrutsky’s repository to his ATEN project, featured in the State of the Art section above. The markdown and general documentation is amazing, especially the attribution section which ties an agent prompt turn to a kernel level action.

seifreed/CipherRun

CipherRun is a Rust-based TLS scanner that combines protocol and cipher-suite analysis, vulnerability checks, compliance controls, and large-scale scanning. It tests every version of TLS from SSLv2 all the way to TLS 1.3. Some other useful features and enrichment include checking for nearly 20 vulnerabilities, JA3/JA4 hash analysis and even monitoring certificate transparency logs for alerts.

AsaEdgerunner/linux-terminal-mastery

Open-source course focused on the Linux terminal that progresses from beginner command-line fundamentals to power-user workflows. Not security-specific, but a clean resource to hand to analysts or researchers who need to get more comfortable using Linux.

Welcome to Issue #166 of Detection Engineering Weekly!

✍️ Musings from the life of Zack:

• I’m on Day 2 of Hacker Summer Camp today! Yesterday was jam-packed with two great events. I helped lead a session on SIEM and Security Operations at Decibel’s Game Day, and we had a GREAT turnout at the Detection & Response Happy Hour. Almost 300 people signed up, and it was so great to meet people who read the newsletter and came to support!

• I’ll be walking the floor today and hitting up Olivia Gallucci’s talk on macOS Detection Engineering and an Agentic Detection session by two security engineers at Roblox

• My hotel lost my tshirt and stickers box. The FedEx in the hotel said the mail room has it, and the mail room swears that FedEx has it. So that’s gonna be a fun part of my morning :|
  

Sponsor: Material Security

Catching the phish was never the whole job.

Phishing's share of breaches hasn't moved in years, because that war’s been fought to a draw. Stolen sessions, dormant OAuth grants, and AI agents with more access than anyone tracks increasingly get attackers in instead. The perimeter held. The workspace didn't. See what detection looks like when it follows the attacker past the inbox.

See Workspace Security in Action

💎 Detection Engineering Gem 💎

How we secure Figma’s internal systems with agents by Matthew Sullivan and Brad Girardeau

Memory ended up being the thing that had the most impact on how useful the system became over time. We have several kinds, and keeping them separate turned out to be important.

What I love about reading modern security research in the blue team space is that as a community, we are applying more software engineering principles to security problems. This is why I love reading pieces like this, because it’s not just about agent design, but agent design for security operations AND it’s being used in the wild. The real contribution is not “agents for triage” in the abstract. It’s the claim that a security team’s value is in its expertise being recorded and reused instead of disappearing after an analyst makes a triage decision.

In this post, Sullivan and Girardeau reveal how Figma’s detection & response team built their own security alert triage orchestration system with a clever twist: encoding its efficacy and agent memories. Here’s how it works:

• For every alert triaged, they use a Retrieval Augmented Generation (RAG) to store analyst decisions, detection and alert metadata, investigative steps and memories for subsequent investigations

• When a subsequent alert is generated, their triage system queries the RAG database to search for similar alerts and uses that as context for the current investigation

• The agent posts a summary inside the Slack thread where the alert was used to page the on-call engineer, so when the engineer begins investigating, they have deeper context on how this was investigated before

• Once the engineer closes the alert, they update the Slack thread, which is then stored into the RAG system to create a closed loop

The team spent a lot of time describing their memory architecture and how it was the single best investment they’ve made to increase detection efficacy and reduce toil. Agent memory in this context is separated into three buckets: steering, procedural,, and case. Case memory is what you see in the picture above. Steering memory ensures an agent stays on track during an investigation, so it helps encode the agent's behavior during these steps. Lastly, procedural memory is the tribal knowledge that they store into agents as they navigate nuanced (see: janky) systems to make sure they know how to work with sharp edges.

I like to think about this type of setup as a “context pack”. LLMs thrive in context; it’s literally why they have a context window. Context engineering is a concept where you can inject instructions and knowledge into the context window to create consistency between agent runs. Figma’s three memory types, or context packs, ensure this consistency holds across the investigative, system, and behavioral steps of their alert triage.

The other thing to call out here is their confidence in letting agents create and tune detection rules. The memory each agent holds within each run helps steer the detection ruleset into a much more accurate state, but they do a good job of applying security boundaries so an agent is stopped right at the pull request, or when it tries to read Slack history or messages in channels that it isn’t explicitly allowed to read.

🔬 State of the Art

Securing Agents Across Perplexity’s Client Endpoints with Numbat by Perplexity

Coding agents are purposefully built to be non-deterministic. This non-determinism is what makes them fantastic at what they do. Personally, I have an agent for building and maintaining my home lab environment, a harness built for vulnerability research of malware and phishing panels and my agents at work that can orient themselves to codebases so I can get into a devloop for a service in a few minutes.

This non-determinism is what makes them dangerous, whether the intent was malicious or not. Last week, I linked to OpenAI & Hugging Face’s post-mortem on an unreleased OAI model breaching Hugging Face’s infrastructure. You’ll see in the threat landscape section below a similar announcement from Anthropic where it did nearly the same thing. I think the best way to secure your company against coding agents is not to assume whether they are malicious or not, but rather that they are untrusted.

Perplexity addressed this problem by releasing an open-source tool, dubbed Numbat, which is essentially an EDR plugin for coding agents. Coding agents expose rich functionality for hooking into their agents (Anthropic, OpenAI). These features are great for observability tracking but also double as a boon for security teams that try to track unsafe behavior for these agents. It integrates directly with over 10 coding agent harnesses and provides three security functions:

• Lifecycle hooks, which emit telemetry from events like tool use or filesystem usage on coding agents, which is useful for logging activity or blocking

• OTLP telemetry, which exposes an OpenTelemetry server that agents can submit logs and metrics to so it can be sent to a SIEM or logging platform

• Session artifacts, which help with forensics when an agent goes rogue, and you want to see how its context window led it astray (think of looking at raw prompt and response text)

The coolest part of this blog, though, is the rule language. Perplexity shipped an on-agent CEL integration, which is commonly used by Kubernetes operators to evaluate K8s control plane traffic, as their answer for logging and blocking. It reminds me of eBPF rules, where the agent emits an event, and the CEL connector reads incoming JSON and tries to match it against a rule to detect maliciousness. It has 52 (!) built-in rules located here, and it even supports correlated rule chains (check out this gnarly one for turning off agent guardrails, then the agent trying to egress data).

Latio Pulse

Detecting and Preventing the Hugging Face / OpenAI Incident

We link to some categories and companies in this blog, but this post isn’t sponsored in any way…

Read more

a month ago · 8 likes · James Berthoty

This week’s issue is certainly AI-security pilled. As we’ve seen from the Hugging Face/OpenAI & Anthropic disclosures, agent security is starting to decouple malicious intent from an agent’s execution. It’s not that intent matters; it’s more that our traditional models assume an attack inside your environments is likely the result of a malicious actor, and that doesn’t matter anymore. Attackers and agents both have goals; the difference is we allow agents to work inside our walled gardens.

My diatribe above is even harder to decompose when you have security companies shoving marketing down your throat. That’s why when I read this post from James, I was happy to see a practitioner’s approach to how the market can help against attacks like this. There are very few security market analysts I read and link in this newsletter, and James is at the top of my list.

James splits the Hugging Face/OpenAI attack into an ATT&CK-like chain, and helps readers understand what security product space could have helped detect or stop the attack along the way. He also presents these spaces as matter-of-fact: you don’t have to buy any of the products; instead, he frames it so that if you need to solve this issue, you can use those spaces as inspiration for your build-vs-buy decision. Honestly, this is the first analyst report I’ve read in a long time where I’d be happy to send this to my CSO :).

(by the way, if you haven’t subscribed to his Substack, please go do so!)

Deep-diving Crowdstrike’s DirectoryCreate by Daniel Koifman

EDR research posts like this tend to make my weekly reading because they help shed light on a very opaque product suite. In this post, Koifman aggregated CrowdStrike’s hundreds of logged event types and focused on a singular event: DirectoryCreate. What I love about this research is how focused it is. A seemingly tidy event tied to directory creation has a lot of nuance in how the telemetry is generated.

CrowdStrike’s sensor is developed as a minifilter, meaning it sits as a Kernel extension. In this scenario, when a user creates a directory, a user-mode function captures the request and calls the corresponding CreateDirectoryW. An internal manager creates an I/O request packet (a fancy way to say a data structure) and sends a structure called IRP_MJ_CREATE throughout the kernel extension stack until it hits CrowdStrike’s minifilter. This is different than hooking a function directly and it allows CrowdStrike to emit events for detection.

Koifman found several telemetry gaps using good-ol-Claude by creating 60 different ways to create a directory on Windows. I’m not a Windows expert by any means, but here’s what I learned from his findings that show how hard it is to reconcile telemetry from kernel to user-mode levels:

• Funny user-mode tricks to trick detections, such as specifying escaped or encoded paths, get resolved in the kernel. For example, if you pass a homoglyph into a directory string, the request packet normalizes the homoglyph to it’s true path in the filesystem. This means if you only look at the request packet for detection, you will likely not find obfuscation attempts

• There are many ways to create directories depending on how you interpret it. Things like renames, moves, recycle‑bin restores, and other lifecycle changes travel over a separate request packet  IRP_MJ_SET_INFORMATION and never surfaces as a  DirectoryCreate  event, so a folder staged in  C:\Temp  and moved into  C:\Sensitive  has no creation record at the final path.

• Reconciliation across events is just as important as precision on the singular event. CrowdStrike loses the attribution of who created the directory due to the IRP structure, so he recommends correlating that to a separate CrowdStrike event, which helps roll the process up to its original parent.

Sponsor: Rilevera

Make Your Detection Program More Resilient

Detection-as-Code is the core foundation for a resilient detection program.

Rilevera provides Detection-as-Code in the click of a button and gives you access to:

• Versioning & one-click rollback
• Peer review workflow
• Detection rule validation & efficacy reporting
• MITRE alignment mapping

Find us at Black Hat 2026 to learn more, or start a free trial now!

Get Started for Free

☣️ Threat Landscape

Investigating three real-world incidents in our cybersecurity evaluations by Anthropic

Following the Hugging Face/OpenAI breach, Anthropic’s security teams performed a retroactive review of their cyber evaluations to hunt for potentially similar malicious evaluations. After reviewing over 100,000 evaluation runs, they found three instances where their models gained unauthorized access to infrastructure that did not belong to Anthropic. I will say the three incidents weren’t as fancy as the Hugging Face breach, but it goes to show how these things don’t need to be fancy in order to be effective.

• In the first scenario, Claude discovered a real domain name and assumed it was part of the simulated environment, so it gained access via insecure application and database credentials

• The second scenario involved Claude publishing a malicious PyPI package in an attempt to gain access to a target company. This one was funnier to me because the model tried to obtain a phone number to register an account on PyPI and “..after failing to find a free phone number service, it tried—and failed—to obtain funds to pay for a phone number through several different means”

• The last one did an Internet-wide scan, or at least used a service like Censys or Shodan, to find over 9,000 devices. Of those devices, it found insecure credentials again, and exploited the infrastructure to help complete its evaluation

If you refer back to my analysis of Perplexity’s numbat tool above, I talked about intent with these agents. At the end of the day, these incidents were the result of positive, misguided intent baked into the instructions of Anthropic agents. The intent didn’t matter since it still gained unauthorized access.

Amazon identifies North Korean hacker group behind open-source supply chain attacks by CJ Moses

Amazon Threat Intelligence published a campaign analysis of DPRK-linked threat actors abusing the open-source ecosystem, especially npm packages. There isn’t anything too interesting or surprising there, but I think the more interesting part is that they claim the tactics are shifting from singular compromises to multi-staged, multi-package compromises.

Their malware TTPs follow the same trajectory as cybercrime malware I’ve helped research for years and years. Two things that stand out for me is the use of licensing within the malware itself, and anti-sandboxing features. On the licensing TTP, they essentially install a reverse dead man’s switch: the malicious component executes in the package, but it will only run after it checks in with a DRM-style licensing server.

Anti-sandboxing is interesting because it’s an obvious next step for folks who know how malware tries to evade defenses, but it’s a bit harder to do with an interpretive language than machine code. I think it’s fine that it can attempt to detect whether or not it’s in an analysis environment, but the whole idea of these packages is that they run in a developer context, which looks like a sandbox environment. I’d be interested to see how this actually works or if someone has a sample, since Amazon Threat Intelligence did not share any hashes.

Popular npm Packages in the keyv and Cacheable Namespaces Compromised in Active Supply Chain Attack by Socket Research Team

A Shai-Hulud-style worm hit the keyv and cacheable npm packages, which have 150,000,000 and 10,000,000 weekly downloads, respectively. The initial access vector is unclear, but it does have a propagation element that steals discovered npm OIDC tokens and uses them to spread the malware. The malware has the same TTPs as most others in this space: it’ll steal cloud credentials and other keys and send them to attacker-controlled infrastructure.

The attacker-controlled infrastructure is the cool part here. Instead of a single hard-coded C2, the payload spins up fresh GitHub repositories via the API and uses commits and GraphQL  createCommitOnBranch  to stash stolen credentials, alongside a DNS-based exfil path for redundancy. It also plants autostart hooks in  .claude/settings.json  and  .vscode/tasks.json , so any developer or coding agent that opens the repo becomes infected.

The 73,000-server market reselling Western frontier AI into China by Lloyd Davies

I’ve read a lot about model distillation attacks, and there have been public accusations of the People’s Republic of China using unsanctioned access to Western frontier models to create their own open-weight versions. This is the first blog I’ve read that tracks the infrastructure that potentially makes this happen, and it reminds me of technique overlaps with residential proxy networks.

Infrawatch details the use of model transfer stations, where someone from a sanctioned country, such as China, can purchase proxy access to these models and pay a fee to use OpenAI/Claude and other Western models. These bridges consolidate their access to end users, and they use clever routing techniques from popular packages and coding harnesses like OpenRouter and LiteLLM to make it easy to use.

By operating this way, end users in China access the Great Firewall-approved infrastructure without touching blocked Western platforms, while those same platforms don’t block incoming connections from China because the proxy providers come from approved infrastructure.

🔗 Open Source

perplexityai/numbat

GitHub link to Perplexity’s “AI-EDR” project listed above in State of the Art. Check out the rules directory for some inspiration on detection opportunities for coding agent attacks.

uber/ADR

Uber open-sourced their own “AI-EDR” project dubbed ADR. The difference in this repository vs numbat is that they also released their own benchmarking datasets. This is great because it doesn’t only include tool call based detection and classification, but the conversations themselves.

Mihir4U-avi/GraphGulo

GraphGulo ingests pcap files and turns them into a locally run graph database for hunting and analysis. The cool part here is that it can run extremely fast queries and doesn’t run out of memory because it is backed by a Rust worker, making it easy to load in massive pcap files (the author boasts 10+ GB pcap files) with minimal impact on RAM.

supermhel/fengarde

Fengarde is a tool that takes disparate IT & OT logs from ICS telemetry sources, normalizes them over OCSF, and helps run Wazuh rules over them for threat detection. It normalizes and sends logs into OpenSearch, which Wazuh and several other SIEM providers support. It comes with 27 OOTB rules, and it’s cool to see what OT rules look like under the hood.