Welcome to Issue #160 of Detection Engineering Weekly!

✍️ Musings from the life of Zack:

• I swear to God, maybe it’s because I’m in my 30s, but I am noticing so much more plant and flower life everywhere! I saw a huge bunch of flowers on the side of my yard, and when I asked Seek to classify them, they turned out to be blackberry bushes! Now I have blueberries and blackberries to pick when they start to produce :D

• I am taking the next week off for much-needed PTO, so the next DEW issue will go out on July 1!

• I am gauging interest for a Detection & Response Happy Hour during Black Hat week. Something lowkey, on the strip, where folks in D&R can meet without being barraged by vendors. If you are interested, hit the “Yes” option on the poll below so I can figure out seat count. I’m aiming for Tuesday night before the craziness starts!

  Every week, I read, watch and listen to all the Detection Engineering content so you can consume it all in 10 minutes. Subscribe and get a weekly digest of the latest and greatest in threat detection engineering!

💎 Detection Engineering Gem 💎

Detection Engineering’s Quant Era by Gabriel Abdelgawad

For those unfamiliar with the term Quant, it’s short for Quantitative Analyst. These analysts apply rigorous statistical methodologies to financial trading and sit at the intersection of business, mathematics, and market uncertainty. I’ve met several throughout my career, especially during my MBA. They enable massive trading firms on Wall Street to manage large trading portfolios that account for all kinds of risk. And, as we know about risk in security, they try to understand the uncertainty of events in the world, such as the Iran War, to find arbitrage opportunities or hedge against risks to minimize loss when a disaster happens. Sound familiar?

In this post, Abdelgawad surveys the history of quantitative analysis as it evolved from paper to computer spreadsheets, and now high-frequency trading. He compares and contrasts this evolution with that of security operations, especially given current AI capabilities. According to Abdelgaward, the cost of both writing results and triage is being reduced from a human capital perspective. A well-harnessed LLM can perform research, learn your detection stack, and build rules at a faster velocity than a human can. That same agentic system can triage alerts, analyze the event, and present a D&R engineer with its decision and reasoning.

So the question becomes: what do we do when the expensive parts are no longer typing rules or grinding through every alert by hand? Abdelgawad’s answer is that we are not being replaced, but we are being pushed up a layer. The work starts to look less like hand‑building each detection and more like portfolio management: deciding which rules belong in the book, which are brittle, which really work in your environment, and where the blind spots in the overall method are. He compares and contrasts this “squeeze” to an analogy of the front, middle and back offices in finance.

Once the front office (authoring) and the back office (false-positive minimization and risk acceptance) become cheap, the middle office becomes the constraint you optimize to achieve success in detection and response. So your “book” is your ruleset, detection pipeline, incident response playbooks, and your knowledge bases. To draw another comparison, the ship has sailed for writing most of your code by hand, as Claude Code has taken over. The same logic applies to detection: if agents can draft rules and triage alerts, the valuable human work is not clinging to manual authoring; it is managing the portfolio and the risk it represents.

I want to keep reiterating that the cost has shifted, and I’m hopeful because it frees up more time for detection engineers to focus on the important research and engineering parts of our job. Here are some ways I’ve seen this implemented already at my day job, where I run an org with dozens of security engineers doing detection & response:

• Teams move more into the threat hunting space, where they spend more time discovering gaps in coverage, telemetry, and infrastructure

• Projects emerge that help monitor drift in pipelines and telemetry and will flag when a rule or log source becomes unreliable

• Detection & response engineers spend more time with threat intelligence teams to help understand the world outside of the company

This has been one of my favorite posts to read in months. I highly recommend taking time to read and comprehend Abdelgawad’s narrative around this topic because we are going to be expected to take on more with the help of agentic tooling.

🔬 State of the Art

Statement on the US government directive to suspend access to Fable 5 and Mythos 5 by Anthropic

About a week after Anthropic’s release of the “Mythos-class” model Fable and Mythos 5, they pulled access to the model from all customers as well as non-U.S. citizens inside Anthropic. This blog post explains why they pulled access: the U.S. Government issued an export control directive requiring Anthropic to remove access for non-U.S. citizens.

A lot of work goes into releasing these models, including extensive internal and external red teaming to battle-test the jailbreak-prevention defenses that Foundational Labs add to them. According to Anthropic, they followed their normal operating testing procedures and added even more to make sure that the guardrails held up against adversarial prompts. They announced on their blog the intent behind the testing, since Mythos has been touted as an advanced, cybersecurity-capable model.

The blog reads as if they disagree with the directive altogether. According to the post, the government’s explanation was a singular report of a jailbreak as their evidence. This isn’t Anthropic’s first clash with the current Administration, in which the Secretary of Defense threatened to label them a supply chain risk.

My personal opinion is that this is likely a stretch of an argument by the U.S. and that I think this ban will be lifted in the coming months. That being said, Anthropic has leaned into the marketing of their Mythos model as being something that should be regulated, so I hope they aren’t too surprised that something like this happened.

Detecting Misuse with the Claude Compliance API: The Threat Is in the Content by Andrew Byford

I’m excited to see investment from detection engineers and researchers investigating how audit logs and compliance APIs work for AI tools like Claude & OpenAI. The problem with this particular threat surface, as Byford writes in this blog, is separating the threat model into SaaS detections and prompt-and-response detections. These APIs contain audit events similar to what we see across the industry: permissions or API keys being added to an account, MFA devices registered or removed and suspicious logins. But, if the value of these tools is token usage, how do you find threats in unstructured data?

Byford’s solution to this, which he also open-sourced, is a pipeline that splits control plane events under “Activity Feed” and content events. SIEMs, which are built on structured matching on structured data, perform poorly when matching on unstructured, non-deterministic data. These situations are when the problem (unstructured token usage) and the solution (unstructured token usage) are identical. Byford’s content pipeline uses a combination of prefiltering tools and an LLM judge to filter out interesting or malicious prompts before they ever hit a SIEM.

I do see some scale issues with this, but only in the sense that we will all likely face tradeoffs on volume vs precision:

• The cost of indexing prompts is shifted from the SIEM to the LLM judge. For every prompt your company generates, you need to use another prompt to evaluate its content

• Byford calls out the Judge being susceptible to attacks itself, so it’s important to engineer additional guardrails

• Privacy concerns around inspecting content in the prompt and uploaded documents themselves. Depending on your jurisdiction and compliance requirements, you may not get 100% visibility on every prompt and response. (Unless you are American, lol privacy)

Detecting and removing dangerous secrets on dev workstations before Shai-Hulud does by Guillaume Ross

This blog by Ross presents a practical pattern for secrets on dev workstations before infostealers or open-source supply chain attacks from groups like TeamPCP. They vibe-coded a proof-of-concept architecture that combines a secrets scanning tool, bagel, with Fleet and osquery. You can deploy the scan to run periodically via a LaunchAgent on macOS that runs bagel, which creates a findings JSON file.

Fleet then launches an osquery rule to detect secrets in the user’s home directory, sends alerts to Slack, and even instruments a response action to isolate the user’s access to your IdP. There’s a good defense-in-depth story here: you enforce controls before a developer gets infected, and you hope your EDR catches the infection before it’s too late.

☣️ Threat Landscape

Ransomware Tool Matrix Project Updates: Three Groups To Track by Will ‘BushidoToken’ Thomas

Threat research G.O.A.T. BushidoToken released an update to his ransomware tool and vulnerability matrix dataset. He added three emerging groups: TheGentlemen, Dragonforce and WarLock. It’s always difficult for me to stay abreast of TTPs in these groups since they tend to move fast, disappear and re-emerge. The coolest part of this post, IMHO, is the callout on the leaked chats from TheGentlemen and how they helped researchers understand the group's inner workings.

Phishing for Lobsters: How We Tricked OpenClaw into Spilling Secrets by Itay Yashar

In this post, Varonis Security Researcher Itay Yashar set up a simulated enterprise environment on Google Workspace and gave access to an OpenClaw agent. The clever idea here was to test the difference between an agent inadvertently executing malicious instructions via prompt injection versus what Yashar calls “agent phishing.” I think this is an important callout because it challenges the guardrails of a legitimate request with no hidden artifacts from a malicious source. Whereas in prompt injection, they are generally malicious requests with a hidden artifact.

They ran four scenarios, and the results were interesting: they tended to favor resolving issues over verifying the sender's identity and security. They implemented a “strict” verification profile for the agent that explicitly required it to verify identities. In multiple scenarios, a fake email was enough to get cloud credentials, secrets, and CRM exports. It just goes to show that guardrails are more than just prompts, and you should treat prompts and instructions as a security boundary in themselves.

Caught a ClickFix attack today. The domain name alone made me do a double take. (Reddit post) by MoneySaxena

I’ve been checking out Reddit posts more lately for raw analysis and commentary on detection and the threat landscape, and this one on ClickFix struck a good balance between technical depth and a conversational tone. Microsoft Defender fired an alert about a potential ClickFix compromise, and MoneySaxena wrote about their experience triaging the alert and containing the host.

They called the user and tried to understand how they managed to visit a site, copy and paste a malicious command, and then execute it. She said she was “just browsing normally”. This is something I see so many security teams deal with in their day-to-day, so it’s not too surprising that the user was browsing in a benign way and got infected.

This was my favorite quote from their write-up:

The thing that gets me about ClickFix attacks is how simple the social engineering is. There’s no phishing email to analyse, no malicious attachment to sandbox. The user is just browsing a normal website and something on the page tells them to paste a command. The command itself looks like gibberish. Most people have no reason to know what rundll32 is or why a website would need them to run it.

ipcrawl

Kind of creepy OSINT-based IP camera crawler. It has 8k+ publicly facing IP cameras that display images and/or video feeds. You can filter across countries, ISP, keywords, and console mode, which looks like Omegle.

🔗 Open Source

BushidoUK/Ransomware-Tool-Matrix & BushidoUK/Ransomware-Vulnerability-Matrix

BushidoToken’s updated Ransomware Tool & Vulnerability matrices from the blog post featured in Threat Landscape above. These are fantastic resources for detection research and creation, especially if you feed your environmental context, ruleset and enrichment from these matrices into an LLM.

atomiczsec/Noradrenaline

Noradrenaline is a set of small offensive shared‑library modules for macOS and Linux meant to be plugged into Poseidon and other post-exploitation agent frameworks. IMHO, this is a great set of capabilities for a detection engineer to test their EDR and detection rules on macOS. I hope someone does Atomic Red Team for macOS soon so this becomes easier and easier!

PaperMtn/claude-enterprise-detections

Andrew Byford’s detection ruleset for their Claude Compliance API research is listed in State of the Art above. It contains the full architecture of detection rules, pipelines, judge integration, and pre-filtering.

assafkip/kipi

Kipi is a self-hosted OSINT platform that uses Claude as its analysis backbone. It’s similar to SpiderFoot in many ways, but I don’t see as many one-off modules or scripts, since it lets Claude make tool calls like API or HTTP requests. The cool part here is how Claude builds relationships via a graph and presents it to you while performing its analysis.

Welcome to Issue #159 of Detection Engineering Weekly!

✍️ Musings from the life of Zack:

• I just got back from a work trip to NY and got to hang out with people in my org who traveled from all over the world (Europe, Asia, and around the US!) Sorry for not putting out an issue last week, but I definitely needed to maximize my time to spend with folks in the office :D

• I hosted an internal security fireside chat where Ayoub Fandi, who runs the GRC Engineer Newsletter, and he crushed it. It was great to hear his perspective on modernizing GRC functions and on the emergence of amazing tech applied to age-old security problems

• It’s almost summer here in New England! I know it’s close because every week, I walk outside with my kids and pick wildflowers. There is almost always a new type of flower blooming every week that we get to bring back home

Sponsor: runZero

Are You Writing Detections for an Attack Surface You Can’t See?

Your detections are only as good as your asset coverage. If runZero isn't in your stack, you're writing rules for an attack surface you can't fully see… and AI-generated exploits are built to find exactly those gaps.

Know every asset, every exposure, every attack path—across IT, OT, IoT, cloud, and mobile. Validate your segmentation before the exploit drops. No agents. No authentication. No appliances.

Try It Free Today

💎 Detection Engineering Gem 💎

Introducing EvidenceForge: Synthetic security logs that don’t look (as) fake by David Bianco

I’ve worked in security product startups for years and have procured vendors and software related to security. The single biggest problem with the procurement process, IMHO, is evaluating the theoretical scenarios in a demo environment to see how accurate they would be in a real scenario. In the ideal state, you turn a product on, and it starts finding the bad stuff, but in my experience, it rarely happens.

The same thing happens with detection rules and capturing a truly malicious, compelling event to guarantee the alert will fire. As a community, we helped alleviate this pain with excellent Purple Teaming tools such as Stratus Red Team and Atomic Red Team, as well as attack-range data, including the Botsv3 dataset. The problem at its core is realism: isolated attack chains work well for sequenced rules, but they don’t take into account the legitimate traffic that can harden the necessary vs sufficient assumptions you need to deploy a rule before it hits prod.

This is where Talos’ EvidenceForge project fills that niche. It’s an LLM-backed synthetic telemetry generation platform that preserves the causal relationships that detection engineers should expect to see during an attack chain. Through realistic scenario generation via prompting, it tries to build scenarios and telemetry that you’d expect to see in a live environment.

EvidenceForge first creates a shared event model to guide synthetic log generation without forcing the user to reason about every downstream format up front. Once generation occurs, it ties scenarios together across host and network telemetry, introduces benign traffic and prerequisite events for the attack, and adds a timing layer. Detection engineers can then use the resulting dataset to validate rule efficacy, and Bianco notes that it can also support threat hunting, analyst training, and incident response exercises.

Projects like this are where I am bullish on agentic technology because they focus on harnessing and acknowledging what does and doesn’t work in model prompting at specific steps. Adding guardrails around the model, such as the Shared Event Model and the realism layer, helps scope the task for the agents, ensuring they don’t make assumptions beyond the prompt's bounds.

🔬 State of the Art

The pressure by Daniel Stenberg

I’ve included a ton of Stenberg’s blog posts on how the cURL team has dealt with surges of vulnerability reports due to LLM use. Many of these posts have shed light for me on how tiring open-source software maintenance work is, just to fix vulnerabilities. The problem in cURL’s case, and I’m sure many others, is the tension between popularity, attention and capacity. The project is already popular and gets lots of attention from software engineers and vulnerability researchers alike, so the volume of bug fixes and vulnerability reports puts a lot of strain on their day-to-day. Add LLMs on top of this; it reads as if it’s unbearable.

This is a sobering and, in my opinion, sad quote from Stenberg. It highlights how underwater he feels while maintaining the cURL project. If I had to relate this, it’s very similar to what we deal with in the security industry. Don’t get it twisted: I think building and maintaining cURL is way more important than my day-to-day in many ways, but the pressure of delivering security initiatives is so much higher than it’s ever been in my career.

Be careful of burnout and take care of yourselves and your loved ones. I think OSS development and security are altruistic in so many ways, but it shouldn’t interfere with your health. I’ll put the cURL donation page link below if you all want to help out a great project.

Donate to cURL

Detecting Tycoon 2FA AiTM attacks across Entra ID and Google Workspace by Samir Bousseaden & Terrance DeJesus

The evolution of phishing has been fascinating to stay on top of since my days of first catching phishing threat actors in 2014. Typically, I’ve associated phishing kits with targeting users to steal passwords and credit cards for fraud. I’m sure most of your friends and family have asked you about spam texts for unpaid tolls, missing packages or a crypto company “threatening” to turn off their accounts. These target the everyday person.

Advanced “attacker-in-the-middle” kits, like Tycoon, target enterprise and cloud accounts. In this post, DeJesus and Bousseaden showcase opportunities for post-phish detection in Tycoon 2FA. Tycoon 2FA is a prolific phishing framework that targets cloud accounts, especially Entra ID and Google Workspace, to provide operators with post-compromise access to sensitive corporate environments. It moves the question from “how do we detect phishing attacks” to “how do we find identity compromise in cloud environments?” Check out the flow below:

It looks eerily similar to how authentication flows, both for OAuth apps and individual users, because the attackers understand the identity model. Hunting for phishing pages and infrastructure is a strong indicator, but when paired with control plane logs from Entra ID and Google Workspace, you can generate high-fidelity alerts.

Device Code Lab (DCL) — Deep Dive into a Device Code Phishing Toolkit by Paul Newton

Continuing the phishing kit theme from Elastic’s post above, Newton dissects the Device Code Lab (DCL) phishing kit to demonstrate its functionality. This is a great piece for comparing and contrasting with other phishing kits. DCL, for example, has unique properties that make it more of a full-service offering, including integration with residential proxy networks, expired domain hunting, and an operator/post-operator model similar to a Cobalt Strike Team Server.

For the most part, the phishing workflow is the same, but uses some Cloudflare Worker shenanigans instead of Socket.io:

There are three interesting features that I listed above:

• Residential proxy integration lets operators route device-code traffic through consumer ISPs rather than obvious cloud ASNs, making sign‑in patterns look much more like real users.

• The expired domain hunting feature continuously discovers and recycles aged domains, so links land on infrastructure with an existing reputational history rather than freshly registered junk.

• The operator / post‑operator model separates the initial phish from the later tenant abuse, giving you two distinct activity phases to hunt for in identity logs, similar to how you’d reason about beacons and operators in Cobalt Strike

Look for post-exploitation activity similar to what Elastic recommended above. These seem to be noisy when they gain access to a tenant and perform enumeration. Look for rogue registered devices as well, because invalidating refresh or persistent tokens can only stop immediate access.

After The GitHub VSCode Supply Chain Attack: Is Your Extension Block Actually Working? by Aman Khurana

This post-incident analysis of the VSCode incident in GitHub by TeamPCP is a clear example of why we need to understand how supply chain tools actually install.

Khurana shows that VS Code uses  marketplace.visualstudio.com  only to resolve extension metadata, then pulls the real VSIX from  gallerycdn.vsassets.io  , Microsoft’s CDN, from which the poisoned Nx Console payload originated. Blocking the Marketplace API felt like an immediate win, but it left the CDN “warehouse” untouched, so anyone who knows the deterministic URL pattern can still fetch and install the extension directly. This is the same pattern for pypi (https://pythonhosted.org) and npm (registry.npmjs.org  and popular 3rd parties like jsdelivr).

This is the pattern you should expect everywhere supply chain software meets cloud: app frontends, APIs, and CDNs can all be different domains, which can mess up detection opportunities if attackers start using legitimate cloud hosting services to blend in.

I’ve joked about this before, but detection engineers are now becoming supply chain security experts. We now need to understand how to map the full software installation flow: which domains resolve metadata, which domains deliver binaries, and which local directories auto‑load content without a visible installer. Otherwise, you are tuning detections against the storefront rather than the delivery path that attackers actually use.

☣️ Threat Landscape

Claude Fable 5 and Claude Mythos 5 by Anthropic

Anthropic released a Mythos-class frontier model dubbed Fable 5. It has extensive capabilities across its usual benchmarks and enhanced capabilities in cybersecurity tasks. The cool thing here is that it’ll route certain prompts to Opus if it deems them unsafe for use. The most random (but most important) benchmark is that it beat Pokémon FireRed only using vision. It’s an 18-second video, so I’m unsure if they just accelerated the playthrough or if it actually went so fast pressing buttons that it did everything in 18 seconds.

Cool down before you install: give new gems a few days to be vetted by Hiroshi Shibata

The RubyGems ecosystem just released a “cooldown” feature for its bundle tool. Effective supply chain attacks, such as those carried out by TeamPCP or DPRK, rely on publishing a malicious package after a CI/CD pipeline or a user has been compromised. Once that package is pushed out, people start installing it, and both the open-source and security communities begin flagging it as malicious.

Cooldowns help combat this type of attack by allowing users to specify a cooldown period during which the package version must remain in the ecosystem before it can be installed. The premise here is that, for example, if you set a cooldown timer for 24 hours, you won’t install new compromised packages.

It’s a great governance control for engineering teams, but given the hyper-configurability that open-source software tools offer teams, it will be harder to pull off in practice. This, IMHO, will work in controlled CI/CD environments, but will likely be bypassed on developer laptops.

21 Zero-Days in FFmpeg by Zhenpeng (Leo) Lin

This blog by the Depthfirst research team shows how much latent risk lies within “plumbing” style open source software. Kind of like what I called out in Stenberg’s cURL blog above, the thankless work that goes into these pieces of software that literally touch our everyday lives is astronomical. So, helping the ecosystem become more secure by performing vulnerability research on these projects is overall helpful, but it still raises questions about the toil on maintainers.

That being said, this blog is a great demonstration on the scale and velocity of vulnerability analysis using agents. Their security agent rescanned a heavily audited FFmpeg tree and still found 21 new zero-days, including heap and stack overflows that had been quietly reachable for 10–20 years in demuxers, depacketizers, and RTP paths.

There’s a great explanation of a vulnerable code path in RTSP processing that potentially leads to remote code execution. All the Depthfirst team needs to do is set up a rogue stream of a period piece movie and/or series, and they can totally pwn me.

Incident Notification to the Maine Attorney General by Meta AI

Meta suffered an AI-related incident in which its “high-touch support” chat agent was abused to grant attackers unauthorized access to social media accounts via password resets. But, my analysis isn’t just about this incident; it’s about how awesome Maine (the state I live in) should be your early warning system.

Basically, when a security breach occurs at companies like Meta AI, they go through a notification process to make sure affected users are aware of the incident. This is especially important when trying to comply with federal and state laws. Maine has some of the strictest requirements for breach notification if any Mainer (yep, that's what we call ourselves) is affected by a breach.

Here’s what Perplexity cooked up as it did some research on this for me:

• Companies must notify affected Maine residents and the Attorney General “as expediently as possible and without unreasonable delay,” which in practice means they cannot sit on a breach for months while they polish a narrative.

• If more than 1,000 people are notified, they also have to notify consumer reporting agencies and file a detailed notice with the AG that becomes part of a public record, even if only a handful of those people actually live in Maine.

• Notice has to go out as soon as law enforcement says it will not compromise an investigation, with guidance converging on roughly a 30‑day outer bound from discovery, so Maine filings often appear before a company’s national comms and investor disclosures are fully baked.

If you want a live view of the feed, here’s the “Breach Portal” for Maine:

https://www.maine.gov/agviewer/content/ag/985235c7-cb95-4be2-8792-a1252b4f8318/list.html

🔗 Open Source

Cisco-Talos/EvidenceForge

GitHub link to Bianco’s EvidenceForge project listed in the Gem above. Check out the AGENTS.md file since this is run as a skill within Claude / Codex.

tjnull/cygor

Open-source, Python-based asset discovery framework. It handles host discovery, port scanning, service fingerprinting, and enrichment in a single path, then organizes the results into a single web app. Good fit for attack surface inventory, lab mapping, and quick scoping when you need a clean picture of a subnet or environment.

cjpais/Handy

Handy is essentially a push-to-talk assistant for transcribing your speech into text. It uses local models for the transcription itself. Good for note-taking, but might be super interesting for prompting your coding agent so you can be totally hands-off keyboard.

CarterPerez-dev/exs-cyberjob-scraper

Elixir-based scraper that pulls cybersecurity job postings, filters out the generic “IT” noise, and surfaces which certs show up most often in real roles. If you mentor juniors or run hiring, this is a handy way to sanity‑check which certification signals actually appear in current job ads instead of guessing based on vendor marketing.