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.

Welcome to Issue #158 of Detection Engineering Weekly!

✍️ Musings from the life of Zack:

• Over the weekend, I was clearing out some brush in the woods behind my house since we want to create a play area for the kids. Once we get the deadwood and sticks away, we want to clear some plants as well. I pulled out my phone and scanned the plants to identify them, just in case it was poison ivy, and lo and behold, we have blueberry bushes everywhere! And I mean everywhere, I’ve asked my neighbors to come dig some up if they want some for their yards.

  

• I’ll be in NY next week for work, and will be attending Sprawl on Thursday. If any readers are attending, let me know!

• Lastly, my org at Datadog just opened up two engineering manager positions for our detection engineering team. We are expanding our detection engineering here at Datadog and would love to have some folks come in and help shape it in the age of AI. U.S. based applicants at this time :).

  Apply Here!

💎 Detection Engineering Gem 💎

Perplexity Is Open-Sourcing Bumblebee by Perplexity

Perplexity, a major AI company in the AI search space, released a Go-based secret scanner dubbed Bumblebee. Bumblebee is a secrets scanner, but it has a much more focused approach to targeting open-source software and 3rd-party vendor supply chain attacks. Every week, I read and likely link threat landscape stories involving an open-source supply chain attack. Perplexity deployed this tool in a clever framework to quickly orient to emerging attacks and check their exposure on developer laptops:

I’m sure Perplexity uses its own product to create its “threat intelligence feeds” listed at the top left, then passes them to its Perplexity Computer Agent. The agent collects as much context as possible around the attack and drafts a pull request to their exposure catalog, which is essentially a database of known malicious packages derived from their feeds.

The updated catalog kicks off a separate workflow to scan Perplexity’s fleet of laptops for emerging threats, while continuous scans are run on known-compromised packages from previous campaigns. The “worst case” scenario is finding successful compromises of devices, but the beautiful thing about this is the reliability of the build-and-scan pipeline, scouring for new campaigns. The package inventory and audit logs are excellent for false-negative analysis, especially in scenarios where a more subtle campaign that doesn’t perform smash-and-grab attacks can help responders with threat hunting.

I’ll say this again, as a word to all my readers who work in detection & response: please upskill in software supply chain security! We need to understand how these campaigns operate so we can hook into CI/CD pipelines to generate detections and audit logs for hunting.

🔬 State of the Art

Built a SOC from scratch with no prior SOC experience (Reddit Post) by After_Marsupial_3531

I am seeing more and more discussions on Reddit about security operations programs, and this one specifically impressed me because the author rolled out a full SIEM stack as an apprentice at an MSSP. They essentially have three people in their team: themselves, a CISO, and a salesperson. What they managed to do with zero experience and launching an MSSP service is nothing short of a miracle:

I have zero experience in a mature SOC — and neither does anyone else on the team. I’m figuring things out as I go, and I’m not always sure whether what I’m doing is actually sound or consistent with industry standards.

When I hear about stories like this, I immediately jump to the worst-case scenario. No experience in a SOC, fresh out of an apprenticeship and architecting a competitive managed service seems like a recipe for disaster. But they managed to launch it with real customers, primarily looking at EDR & M365 telemetry. Elastic Security was their stack of choice, probably due to its simplicity of out-of-the-box rules and its being an open architecture.

The resulting discussion is great, as they were looking for feedback on their deployment. There is definitely some memeing in the comments, with good nuggets and insights for the author, such as finding a way to create a crown jewels or critical assets list and prioritizing high-risk scenarios a small business would face.

Project Glasswing: An initial update by Anthropic

I don’t know what it is about this year’s developing AI & security space, but 1 month feels like 6 months in terms of technology acceleration. Anthropic just gave their 1-month update for Project Glasswing, and the results are impressive. They released Mythos to a limited set of company partners they deemed to be Internet-essential software companies, and also ran it on 1,000+ open-source projects. The results speak for themselves, but there are some nuances:

A lot of work goes into verifying vulnerabilities, both their presence and their reproducibility. Anthropic spent a lot of human energy, rightly so, to make sure that these vulnerabilities wouldn’t waste a human’s time. They employed independent security firms to help verify their findings and touted a 90%+ true positive rate. The nuance here is the patch cycle itself.

I do think this year is a landmark year for rapid vulnerability discovery and disclosure, but we are certainly not close to it being the year of rapid vulnerability patching. The bottleneck is the process of fixing, testing, merging, and deploying patches at scale. I hope Anthropic continues to invest in this space and moves towards rapid deployment of patches. Our industry, conferences, and community reveres vulnerabilities as the pinnacle of achievement for a researcher.

Maybe it’s my blue team bias, but the pinnacle achievement for me is protecting others. I’m unsure if more disclosed vulnerabilities protect others, because the externalities around patch time, exploit time, and volume may make our situation much worse.

If you haven’t read the Project Glasswing analysis above before reading this one, please do, because this episode is very relevant to my analysis. Shocker, it tends to agree with JAGS and the crew here :).

What I love about this episode is the sober grounding around the concept of “10xing vulnerabilities” due to these models. There is a lot of talk about the volume of patching from early-access vendors in Glasswing, but this tends to overlook the critical part: customers actually applying the patch!

Much like I said in my Glasswing update, I will be impressed if we can have companies that build and sell appliances, IoT devices, or even endpoints take a more opinionated approach to forcing patches. JAGS gave some ideas around this, such as giving a window for people to apply before a vendor forces the update. This has its risks, especially around governance, customer success, and usability, but if we want to tout the success of AI in security, then the boring part of patching needs to be solved just as much as the exciting part of vulnerability discovery.

Manage extensions in enterprise environments by Microsoft Visual Studio (Documentation)

Following GitHub’s disclosed security breach, someone on Reddit posted the documentation for managing, securing, and deploying Microsoft Visual Studio extensions. It was released five days ago, so it’s likely this was posted in response to the VSCode extension attack on GitHub, which resulted in its public disclosure. For the most part, these protections are great, but I worry about a few things.

First, it assumes you have a list of all extensions that every developer uses, that you can accept and apply a deny-all afterward. For those who work with a large engineering team: good luck with that! Second, trusted publisher allow lists wouldn’t have stopped the Tanstack attack since the trusted publisher itself was compromised. Third, besides the private registry, I wish there was a native way to grab an inventory of these extensions for analysis, much like what Bumblebee from Perplexity does.

Microsoft be Microsoftin’.

☣️ Threat Landscape

The Future and Past of Residential Proxies by Qurium

I learned the term “botnet” in my first year of college in 2008. The concept seemed cool: you infect a device, build a Rolodex of infected devices, and collect them like Pokémon cards. I never really understood the financial appeal because everything leading up to the massive DDoS botnets, such as Mirai, was mostly around selling access to perform DDoS attacks to make a statement. The recent development of residential proxies in the last two years, though, exposes a much more lucrative financial model and a more serious threat than DDoS attacks.

Qurium’s piece here eloquently lays out the history of this evolution and gives great context for those who worry about residential proxy abuse. It’s worth reading less for the individual provider callouts and more for the ecosystem shape. The interesting story is how Android supply-chain compromise, proxy SDKs, DDoS botnets, and commercial residential proxy markets start to blur together.

Qurium is on the receiving end of this abuse and has been mapping the providers, botnets, Android supply chain compromise, and proxy monetization layers that enable it. The useful takeaway is not that every residential proxy provider is malicious. It is that the line between “commercial proxy service,” “compromised device pool,” and “botnet infrastructure” is getting harder to see from the outside.

Lawmakers Demand Answers as CISA Tries to Contain Data Leak by Brian Krebs

Krebs provided a follow-up update on the initial break of his CISA Leak story, in which he obtained letters from lawmakers asking CISA to answer questions about how the leak happened. He posted a picture from one of the letters, and it looks like Krebs' story was the first reference in their letter. I wonder if he prints these out and frames them?

With CISA funding and workforce being slashed, as Krebs points out, it's hard to understand whether this leak happened due to reduced security controls, a burnt-out staff, or discontent. CISA took over a week to rotate some credentials, including an RSA private key, after having researchers from Trufflehog and GitGuardian reaching out multiple times.

Cybercriminal VPN used by ransomware actors dismantled in global crackdown by Europol

Europol seized servers and assets, and even interviewed an administrator of “First VPN”, a residential proxy network. These networks allow users to purchase access to typically unwitting endpoints, such as cellphones, routers, and VPSes, to conceal malicious activity and make it much harder for defenders to distinguish legitimate IP addresses from malicious ones.

I’ve always been impressed by these joint operations, especially those led by Europol. They have to coordinate across countries and jurisdictions, and they manage to navigate the bureaucracies of these agencies to execute coordinated takedowns that can include seizing physical servers, domains, and other infrastructure.

Supply Chain Attack Targets Laravel-Lang Packages with Credential Stealer by Iyas Makari

Aikido’s Iyas Makari publishes their research on a supply-chain attack targeting Laravel. Laravel is a PHP framework used by developers to build and manage PHP applications and is widely used by websites worldwide. There are two interesting findings from this report I want to call out:

• I am worried that supply chain attacks affecting PHP applications are more likely to reach VPS servers themselves. This can open the door for more Mirai/Kimwolf-style residential proxy botnet infections, where the goal is to monetize access to compute rather than keys

• The actor pushed malicious packages and pointed them to an orphaned commit on a fork, making it much harder to detect on the main repository

I don’t think bullet 1 is happening yet, as Makari reverse-engineered the infostealer itself, which performs typical infostealer-like things such as swiping secrets and API keys. But those secrets do exist in deployed web applications, and not to sound biased, but I don’t ever think of a PHP website hosted on a VPS is as “secure” compared to what we are used to in SaaS land :).

🔗 Open Source

perplexityai/bumblebee

Perplexity’s package scanning and supply chain security project linked from the Gem above. It’s a single Go binary you can run on your endpoints, typically paired with an MDM solution. It’ll scan for malicious packages and generate alerts, audit logs and build asset inventories.

gadievron/honeyslop

Much like the prompt injections you see people post about on LinkedIn, where a description in their profile has a prompt that an AI recruiter uses when sending out messages, honeyslop does this but for codebases. It’ll add prompt injections as code itself, where AI vulnerability harnesses will read and report on fictitious vulnerabilities so you know when you receive an AI slop report.

rootsecdev/relay_bible

GitHub native course for readers to learn about NTLM-relay style attacks, tools and frameworks. It has several sections that first introduce what an NTLM relay attack is, and then expands out to concepts like coercion attacks, different tools and advanced techniques.

grepstrength/malsnitch

malsnitch is a neat malware analysis helper that looks for secrets inside malware artifacts. It takes strings output, FLOSS JSON, or Binary Ninja exports and pulls out things like C2 credentials, crypto keys, API tokens, Discord webhooks, Telegram bot tokens, and hardcoded exfil configs. This is nice if you are tracking malware families that have hardcoded C2 servers that frequently change so you can update your blocking lists. These pivots can help uncover additional infrastructure, or map out existing infrastructure for your own security research.

Welcome to Issue #157 of Detection Engineering Weekly!

✍️ Musings from the life of Zack:

• Spring in Maine is finally here, and it feels like a Disney movie at the Allen household with all of the animals coming out. We have two bird nests, a family of deer, and now a woodchuck named Chippy prancing around

• Speaking of Maine, I had the most Maine dinner with some friends the other night. They hunted a Moose and cooked Moose steaks for the family. Afterward, we had dessert with maple syrup tapped from trees in their yard. Moose was not that gamey, and I’d try it again!

• Sabres lost :( But I’m super excited to watch this young team in the coming years, so if you are a hockey fan, don’t tease me too much because I’m still hurting from the loss

Sponsor: Adaptive Security

The best threat intelligence is generated by your coworkers

Security Operations teams rely heavily on detection rules and threat intelligence to stay ahead of threats. But, the AI of today focuses on social engineering your coworkers, such as deep fake interviews, voice phishing, and impersonating executives. Training your employees to spot and report AI attacks can provide valuable signals that no security product can match.

Adaptive trains your organization to spot, report, and stop these AI threats before they reach your perimeter.

Take A Tour

💎 Detection Engineering Gem 💎

Shai-Hulud Goes Open Source by Ryan Simon, Sebastian Obregoso and Greg Foss

~ Note, Datadog is my current place of employment, and the authors here are my colleagues ~

I’ve covered several supply chain attacks linked to TeamPCP and one of their worm-based toolsets, Shai-Hulud. This week, GitHub repositories popped up and were quickly taken down, hosting the potential source code for Shai-Hulud.
The team here did a deep dive on its architecture, how it deploys loaders and malware, its C2 infrastructure, and its credential exfiltration techniques.

The Mutator step, which enables Shai-Hulud’s propagation and worm-like capabilities, is super interesting. There are three propagation mechanisms: one I was familiar with, npm credential publishing, and two I wasn’t familiar with, cache poisoning and developer environment poisoning. Every stolen secret can be used to propagate malware across various developer environments and IDEs, such as Claude Code and VSCode.

The two npm-related techniques rely on insecure configurations for publishing npm packages. For example, if you store npm publishing tokens in your GitHub Actions pipeline, it’ll automatically download the latest version of your release, increment the semver to make it the latest branch, then deploy it, causing the post-install hooks to run, which contain the malware.

“Leaks” of malware source code like this help provide insight into how threat actors think about exploiting misconfigurations and security gaps in their targets. It’s hard to say whether this is the “real one”, but there is threat intelligence floating around social media that TeamPCP & cybercriminal forums are teaming up for a Supply Chain Competition to see who pulls off the most impactful breach with Shai-Hulud.

🔬 State of the Art

Wiring Live Threat Intel into Sigma Detection with Dynamic Pipelines by Mostafa Moradian

Most SIEMs let you manage threat intelligence as lookup tables or reference lists that detection rules can query against. A rule checks a destination IP against a known C2 list; the list is updated by a feed; the rule stays the same. It is one of the more practical parts of how enterprise detection pipelines handle the IOC lifecycle. It’s also VERY hard to manage, and without understanding the underlying engineering required to handle dynamic tables, you can produce stale IOCs for your detections, or worse, miss emerging IOCs and fall victim to false negatives.

Moradian has been building toward the same capability in his RSigma project. I first covered the project in #149, when it was a Rust CLI for evaluating Sigma rules against JSON logs without any infrastructure. By #154, it had grown into a streaming daemon with NATS and HTTP log inputs, stateful correlation windows, and Prometheus metrics.

The latest addition here is dynamic pipelines: instead of hardcoding IOC values in rule YAML, you declare external sources in the pipeline config, and RSigma fetches and injects them at evaluation time. This works very similarly to how I’ve seen SIEMs implement threat intelligence pipelines, but since it’s RSigma, it’s self-contained within its ecosystem.

The practical demo is a firewall detection rule with a single field: DestinationIp: “%c2_ips%”. The pipeline pulls the Feodo Tracker C2 blocklist, a public JSON feed covering Emotet, Dridex, TrickBot, and QakBot updated every five minutes, extracts the IP array, and expands that placeholder before the rule evaluates. If the feed is unreachable, RSigma falls back to the last cached data so you do not lose coverage during a transient outage. The rule author never touches an IOC value again.

I thought this was a neat video by the Anthropic team, featuring a friend of the newsletter, Jackie Bow, on how their internal detection & response team uses Claude! They built a tool called CLUE, which they first featured at BSides SF in 2025. It looks similar to a co-pilot tool from AI SOC vendors, but it's their own internal version. I think it helps make the case for those who choose to go build versus buy, by offering control over which features go in and out of the tool, an integration catalog focused on systems you deploy for your organization, and a tighter feedback loop.

The case against is a capacity-and-cost problem. It is attractive to buy AI SOC-like tools if you are budget-constrained or don’t have the talent to build and maintain one.

Ok, a lot of media on this issue, but hear me out. Odd Lots is a Top 3 podcast for me, and its focus is Finance topics. They bring on amazing guests that talk about everything from the economics of milk to tarriff refunds at shipping ports and even cybersecurity.

I chose this episode because its about the history and economics of deep-sea cables, with a particular focus on Internet cabling. We seriously don’t appreciate how complicated and opaque this process is for the end user. So, if you want to learn about Internet-scale issues, you must learn about the physical nature of operating the Internet!

The Ultimate Guide to Detection Engineering with Censys by Alex Gartner

In this post, Censys detection engineer and security researcher Alex Gartner helps readers understand how to integrate detection engineering concepts into Censys’ internet-wide scanning data. This is especially interesting to me in a few ways:

• I’ve rarely read posts on how to integrate Internet scan data as correlation rules with traditional telemetry from the endpoint or network

• Understanding how attacker infrastructure can be fingerprinted is a valuable skill in itself; it’s not all just IP address and domain matching

• Speaking of IP addresses: threat intelligence is much more useful when it’s clustered and used as an enrichment, and we leave out a lot of interesting threat intelligence indicators

I’ve been a big fan of Censys since they started their company several years ago. And luckily, many of the concepts Gartner discusses are available in community edition accounts. I typically don’t link to vendor blogs that talk about their products unless they offer free or community-edition access, so you can try these concepts out by signing up.

☣️ Threat Landscape

Grafana, an observability company with a large open-source following, disclosed a security breach in which attackers obtained an administrative-level GitHub access token. They don’t specifically say if it’s a long-lived token, which GitHub has urged customers to use, but it’s likely if it survived a CI/CD build run. The group behind the incident, Coinbase Cartel, also likely used a pwn request to take the token and subsequently exfiltrate their entire codebase.

The group tried to extort Grafana with a ransom demand, but Grafana said in their tweet that they refused to pay. This is the right approach, since paying doesn’t guarantee that the thiefs won’t sell it to someone else.

Oh look, a VPS I purchased 8 months ago. by Jonathan Canlas

In this post, Canlas, a detection engineer, stumbled upon a VPS they had purchased several months ago and had accidentally left running. They turned it into a honeypot to understand what kinds of attacks it attracts, using subsequent telemetry to learn more about the research and detection workflow. I appreciated reading this post because most honeypot stories I read follow a formula: a lab that deploys a honeypot. This one, in particular, offers much more insight into Canlas’ experience as a detection engineer and how they approached the deployment through a lens of hypothesis-driven research.

Novel Evilginx Frontend - Lowering the barrier for token theft reuse by Paul Newton

Evilginx is a legitimate open-source framework that helps red-teamers build and deploy phishing pages with easy-to-use templates. There is a pro version where the company behind Evilginx vets prospects to ensure they aren’t evil, but the open-source version gets a lot of traction from bad guys. In this post, Newton was hunting for M365-related phishing kits and found a cleverly built M365-themed management interface. IMHO, it makes the post way more interesting since it’s about this peculiar management tool.

The potential threat actor built this front end to manage stolen M365 tokens at scale. They can switch between victim tokens within a single interface, import stolen tokens from their Telegram bot, and execute attacks with a single click.

A single stolen token grants the operator access to several products in the M365 suite, up to and including pivoting to take over the Entra environment.

When AI doomers or marketers post about the onset of dangerous, vibe-coded malware at scale, I roll my eyes because most malware is a commodity at this point. Evilginx is so good, so why switch how it works? I worry more about the organizational scale that vibe-coding offers threat actors.

Before Claude Code, creating an interface like this would have taken months, either with a professional front-end developer or with someone who spent a lot of time learning front-end coding. Front-end coding with coding agents is AWESOME, so it’s now much more accessible for people to build things like this without spending their capacity on learning.

Project Glasswing: what Mythos showed us by Grant Bourzikas

Cloudflare ran Mythos Preview on more than 50 of its own repositories as part of Project Glasswing and published the results. Much like what Anthropic noted about Mythos in their Glasswing blog, Cloudflare said it was excellent at generating exploit chains and generating proof, via a PoC, that it found a bug. The harness architecture they built around it is worth reading too: they created narrowly scoped parallel agents, each focused on a single attack class, and then used an independent adversarial agent whose only job is to disprove the original finding.

Nothing in here really surprised me regarding the applicability of Mythos to real-world code environments. An agent is only as good as its harness, and although Mythos has fewer guardrails and is tuned for security findings, it still requires work to operationalize.

🔗 Open Source

vinsk0h/KQLab

KQLab is a self-hosted platform for storing, protecting, and indexing KQL rules. It has an impressive full-stack architecture and is built to provide strong authentication and verification measures for users, and even includes RBAC capabilities to scope certain rule sets to specific teams.

OWASP/DockSec

DockSec is an OWASP Incubator project that builds a vulnerability scanning report from several open-source tools and generates human-readable reporting leveraging an LLM harness. It’s smart enough to prioritize vulnerabilities based more on CVSS scores, and you can stick it in your CI/CD pipeline so it can recommend fixes that developers understand, rather than a massive findings report.

phylecorp/gabo

Gabo is a Nebula:Fog hackathon project built for threat intelligence analysts. It uses the CIA’s Structured Analytical Techniques playbook to provide users a tool where they can ask it questions, and it’ll provide rigorous feedback based on their analysis. It has an MCP server as well, so you can point your local coding agent or stack at it.

microsoft/AntiSSRF

AntiSSRF is a security component library from Microsoft that helps developers deploy apps without worrying about the underlying techniques used to prevent SSRF attacks. It has a robust URL parsing library, which are always a headache to work with, to validate incoming HTTP requests and reject any that look like SSRF attacks.

Welcome to Issue #156 of Detection Engineering Weekly!

✍️ Musings from the life of Zack:

• Another Allen first! My daughter had her first T-Ball game and after trepidation in practice, she surprised all of us with some very competitive plays and dogpiled on the baseball with other 4-5 year olds

• I booked my hacker summer camp Vegas travel so I’ll see you all at BlackHat & DEFCON. I’ll be trying to host a Detect & Response Happy Hour again, so stay tuned. If any current or future sponsors want to do an event, or sponsor the Happy Hour, feel free to reach out to me! techy@detectionengineering.net

• I’m starting to kick the tires on Codex and have been impressed with it so far. I’ve also had an itch to resurrect my OpenClaw instance for more malware research so wish me luck with my wallet :)

• The 3rd edition of Datadog Detect is next week! Datadog Detect is a FREE, fully-online security operations focused event hosted by the Security Research team here at Datadog. We’ll have three presentations from practitioners and a short panel discussion afterward. The first two were excellent and I hope to see you all on this one. Checkout the schedule and the registration link below!

  Register for Datadog Detect

💎 Detection Engineering Gem 💎

Coverage Is Not Detection by Gabriel Abdelgawa

I read a ton of blogs and thought pieces about detection coverage. MITRE ATT&CK is the industry standard for explaining this concept, and it has its uses. It answers the question “am I covered?” and is a useful tool for communicating to others that you don’t have a visibility or detection gap. It has also been abused by product marketing, especially when vendors claim 100% coverage or more coverage than their competitors. Detection engineers know this, but they don’t necessarily know why it’s a double-edged sword, beyond the nuances of rules and how they can be bypassed.

Abdelgawa’s blog post on this is the cleanest and most concise description of the inherent problem with detection coverage as a metric. The problem is that they are defensible because it’s a number you are communicating. They aptly reference a concept from Theodore Porter on mechanical objectivity. The idea is that quantifying a problem, such as with a percentage, is harder to challenge than a qualitative approach. Presenting 90% coverage on an ATT&CK heatmap biases the audience because they assume the measurement that yielded that 90% used sound methodologies.

We all know that’s not true :).

Abdelgawa cites several examples within detection scenarios where coverage starts to fail. The examples are rooted in three categories:

• Depth: The idea of coverage is binary, so if you detect obfuscated PowerShell usage, and you have one rule, are you covered?

• Relevance: What is relevant to your environment, and are you assigning equal weight to a Windows technique if you run a full macOS shop?

• Independence: Focusing a detection opportunity on a singular telemetry source can fail you if that telemetry source, such as EDR, doesn’t generate the correct telemetry or find the activity at all

I’ve argued ad nauseam about coverage to folks, and it’s never the detection engineers who disagree with me. It’s mostly leaders and vendors. And TBH, I don’t blame leaders. We need a better way to measure the readiness of detection rules and security incidents in general. So, use a number as an anchor point, but make sure you provide context and methodology so it can be challenged.

🔬 State of the Art

ATT&CK Coverage Ratio Evaluation (ACRE) by Jordan Anderson

This blog release timing is excellent with Abdelgawa’s Gem post above! The gem above diagnoses why coverage maps fail as a measurement device, and Anderson's blog is essentially the constructive counterpart. Anderson’s ACRE measurement fairly well addresses the two problems of relevance and independence in detection coverage, and, self-admittedly, depth is much harder to solve.

The “ratio” in ACRE helps teams derive a denominator of techniques more likely to be mapped to your environment, forming a subset of the full MITRE ATT&CK map. They leverage MITRE’s CAR Catalog, a set of rules compiled across several vendors, to build a realistic roadmap of detections you should implement to achieve coverage. This can fail, IMHO, if this catalog is not kept up to date, but just building the roadmap for coverage alone is worth using CAR.

ACRE also solves the “everything carries the same weight” problem by adding a weighting mechanism. Techniques that live in the middle of ATT&CK, such as persistence, should have more telemetry and detection opportunities than those in the beginning and end stages. So, when ACRE computes the full score, it assigns greater weight to coverage for these middle-stage techniques and then splits them out by OS. You then have a much cleaner numerical score on coverage and weights within each environment.

Could your choice of metrics be harming your SOC? by Dave Chismon

As we move downstream from detection metrics to SOC metrics as a whole, we return to the question of how we measure success in security and the pitfall of mechanical objectivity. Chismon rightly calls out that efficacy in security operations is rooted in an IT-centric productivity culture. This focuses on units-of-work measurements, such as the number of tickets processed (alerts triaged), meeting KPIs or SLAs (mean time to touch an alert), and other human-based tasks.

Chismon calls out four metrics that fall into the mechanical objectivity trap: the number of tickets processed, the time to close a ticket, the number of detection rules, and the volume of logs. We tend to take metrics like this and optimize around them because we assume they measure SOC performance. But, much like the pieces above by Anderson and Abdelgawa, they don’t answer the question of “how ready are we for a security incident?”

Chismon suggests seven metrics at the end of the post, and what I love about these is that they are a mix of metrics we know and love, and human-based metrics. A successful SOC, for example, is one full of people who are satisfied with their jobs and engaged, so why not measure that? The same thing applies to engagement beyond the security team and to making sure the analysts know the environment they are trying to protect.

Appearing Productive in The Workplace by No One’s Happy

This blog isn’t necessarily detection or even security-related, but it’s especially relevant for all of us operating in a coding-agent world where everyone seems to be building code. It offers a meek look at what coding agents can do well for anyone, but also what they don’t do for those who understand the underlying technologies, idiomatic techniques, and gotcha’s associated with software engineering. It plays nicely into the security-relevant piece on the cognitive rust belt by St-Meyers in a previous issue.

These risks are real, and people are concerned about untrained people writing software. Putting the security piece aside, the reliability of these systems and the likelihood of strange architectures that don’t fit practices built and honed over the last 30 years mean they risk being dumped on the software teams who did not build them.

On the contrary, it does throw the baby out with the bathwater, in the sense that I don’t see anything about how this technology can be used for good to help these folks. I tried writing about this in my piece about agentic coding x security below:

Inadvertent Injections by sud0woodo

In this post, sud0woodo hunted for PoisonedRefresh samples first discovered and posted by ESET on Twitter. PoisonedRefresh is a piece of malware that targets F5 devices and creates an implant within the Apache process to execute a webshell. The x64 variant they found on VirusTotal is more portable than the original sample and includes a peculiar design decision that could potentially expose researchers to accidentally compromising a device.

The implant hooks read() and runs a KMP string search against every GET and POST request. The upside of KMP is that the magic trigger can live anywhere in the request, such as a cookie value, a referrer, or a JWT payload, which makes it much harder to fingerprint the implant from the outside.

According to sud0woodo, if security companies or researchers are actively scanning for this variant and their probes carry the magic string, they can trigger the webshell injection on a box that the operator has not yet activated. The author calls this an inadvertent injection, and it can mess up forensic investigations and create false alarms for those hunting for these payloads in their own environments.

☣️ Threat Landscape

Where Have All the Complex Windows Malware and Their Analyses Gone? by R136a1

I remember when Mandiant first released its APT1 report and how blown away I was by the technical aptitude of both the researchers and the threat actors themselves. I was just out of college, and after reading it, I knew I wanted to pursue threat research as my career. Windows was the operating system used to build malware because of Microsoft’s market share, the lack of cloud computing at the time, and the lack of commoditization of attack tools and security knowledge.

Fast forward 14 years (!) later, and the industry and landscape have changed so much that reports like this no longer come out. It’s not for the lack of effort, as R136a1 puts it, but more so several factors around access to intelligence, the advent of GitHub and open-source post-exploitation toolsets, and the cloud and SaaS apps changing the focus of threat actors. Social media, IMHO, plays a huge part here too, because we can all build independent followings without having to worry about throwing time and money into marketing our research.

dirtyfrag by V4bel

Dirtyfrag is a Linux kernel LPE vulnerability that draws inspiration from DirtyPipe. It’s a reliable exploit in the sense that it doesn’t cause kernel panics, and you don’t need to rely on any time windows or race conditions. It relies on exploiting page caches in the Linux kernel, which are privileged kernel memory that help optimize memory reads and writes by preventing repeated disk access.

In DirtyPipe, you can achieve LPE by timing a splice() syscall to gain arbitrary write. Dirtyfrag achieves the same outcome by corrupting a pointer in sk_buff, the Linux kernel’s core network packet structure. The frag member of sk_buff holds a reference to a page-cache page used to build packet fragments.

By corrupting that reference to point to a read-only page backing a privileged file, you get an arbitrary 4-byte write through the network path, allowing you to write suid binaries, overwrite entries in a password file, or do some fun container escape shenanigans.

Mini Shai-Hulud Is Back: npm Worm Hits over 160 Packages, including Mistral and Tanstack by Raphael Silva

The Aikido Research team uncovered a new campaign Shai-Hulud targeting several npm packages, with Tanstack and Mistral’s npm packages being the more popular packages hit inside the campaign. Tanstack’s post-mortem describes a PwnRequest style initial access vector, which then pivoted into their CI/CD pipeline. They abused the lack of trusted publishing inside their environment, and began propagating 80+ malicious versions into the ecosystem that performed the same worm-like attacks that looked like it eventually hit Mistral.

When prompts become shells: RCE vulnerabilities in AI agent frameworks by Uri Oren, Amit Eliahu and Dor Edry

This is an interesting vulnerability research piece that examines how AI agent applications leveraging orchestration layers, such as LangChain, can be vulnerable to traditional command injection and remote code execution. Much like the well-understood attacks against web applications that exploit code paths leading to unsafe deserialization or risky eval() calls, popular AI agent libraries can have the same vulnerable code paths.

Microsoft researchers Oren, Eliahu, and Edry demonstrate this vulnerable code path within Microsoft’s Semantic Kernel project. In CVE-2026-26030, the In-Memory Vector Store feature passes AI model output directly into a Python eval() call to filter search results. They circumvented some filtering logic in the path to break out and achieve a shell.

The second vulnerability, CVE-2026-25592, abuses a helper function that was accidentally exposed to the model as a callable tool. The localFilePath parameter, which controls where the file is written on the host filesystem, lacked validation. The attack was unique here: they generated the payload in the sandbox, then made a tool call to achieve host compromise.

Student’s hack prompts THSRC review by Shelley Shan (Taipei Times)

A student in Taiwan used a software-defined radio to analyze, reverse engineer, and replay signals on Taiwan High Speed Rail’s radio communication system. They sent a spoofed general alarm to the control center that halted trains for 20 minutes. Police found nearly a dozen two-way radios at his residence and confirmed he had also cracked into the New Taipei City Fire Department and Taoyuan Airport MRT frequencies.

I’m unsure what the motivation for the hacks here were other than morbid curiosity and the hacker mindset. I do think this points out several security flaws in Taiwan’s rail system, so they could have done some good and tried to report this. It makes it particularly sensitive as the tensions in Taiwan are higher than ever with PRC, and a “hack” causing physical consequences makes the government particularly sensitive to these types of crimes.

🔗 Open Source

ddamenova/IRQL - Incident Response Query Language

IRQL is a domain specific language that sits on top of KQL to help alleviate both the barrier-to-entry of running KQL and to reduce the complexities of large KQL queries. Analysts use 5 primary functions that help build queries: selectors, extractors, enrichers, graph-listed variants and external enrichments. These look to be re-usable components and idiomatic queries found in KQL functions, and the example KQL <> IRQL query shows an impressive transformation that looks much cleaner and easier to read.

microsoft/EventLogExpert

Windows Event Log viewer built by Microsoft themselves! It looks like a Wireshark but for Event Log analysis, which is nice because parsing these logs does require some expertise not only with the structure of EventLogs but some PowerShell kung-fu to correctly parse them.

Mihir-Choudhary/EventHawk

EventHawk’s latest release has some good timing with Microsoft’s EventLogExpert listed right above this entry. EventHawk is also a Windows Event Log parsing tool, but it has a lot more bells and whistles and a much cleaner user interface for analysis. I love the ATT&CK integration module, so it provides a much more enriched view into EventLogs both for quick analysis and for learning.

beenuar/AiSOC

Self-contained AI SOC you can run locally or on a hosted cloud environment such as Fly, AWS or K8s. It ships an MCP server and exposed tools to call the models and perform the translation layer. These repositories generally look like lab environments or someone’s research project, but this is the first one I’ve found that has a seriously impressive amount of features, toolsets, integrations and a healthy development community.

Welcome to Issue #155 of Detection Engineering Weekly!

This week, I’m resurfacing some of my favorite Gems over the last five months. We’ll be back to our regularly scheduled newsletter starting next week!

✍️ Musings from the life of Zack:

• I’ve officially christened yard work shoes with an old pair of white sneakers. I just need some cargo pants, a cell phone clip attached to my hip, and a Bluetooth headset to really complete the outfit

• I saw my friends playing Slay the Spire 2 on Steam, so I got it, and it’s so addictive! You know it’s bad when you think about game mechanics on your drive to the gym or between work meetings

• Proud Dad moment: my daughter had her first-ever ballet recital, and she crushed it. She was in an auditorium with over 100 people, and she was in the youngest age group. She was all smiles and even found us in the crowd and waved

Detection Pipeline Maturity Model by Scott Plastine

I’m a huge fan of maturity models, and in the early days of my writing, I frequently referenced the work of Haider Dost and Kyle Bailey when discussing the maturity of detection engineering programs. As this space matured, technology matured with it, and we now have complex systems within each part of the Detection Engineering Lifecycle. So, to me, it makes sense that we now have folks like Plastine helping us understand what it means to measure the maturity of a Detection Pipeline.

Plastine outlines six different levels of maturity, starting with a classic favorite, no maturity! This involves having a security tool stack with no centralization, and analysts have dozens to hundreds of Google Chrome tabs open which gives me anxiety. The fundamental issues Plastine outlines and continues to improve here include:

• Several security tools with their own alerting and detection systems

• The need to log into and investigate each alert on each individual tool, so managing screen sprawl

• The analyst manually building cases in some case management or ticketing tool, such as JIRA or ServiceNow

The next maturity step, Basic, addresses some of these issues by essentially placing the Case Management tool between the tools and the analyst, rather than being out of band. As maturity levels progress, so does the architecture of this setup. For example, the “Standard+” architecture has a much saner pipeline setup:

The cool part at this point in the maturity journey is switching from architecture improvements to more advanced concepts in the analytics platform. Custom telemetry, log normalization, and a risk-based alerting engine ideally surface only relevant alerts and reduce false positives. Teams begin to build composite rules, leveraging commercial detections alongside their own internal detection and risk alerting systems, and they all take advantage of learning from their data to inform their rule sets, not just their environment.

This diagram drove it home for me, and became my favorite:

As you progress through maturity, the trap teams fall into is more rules is better. I think the measure of a Leading detection function is reducing rule count thereby reducing the complexity of managing rule sprawl.

Plastine posits that this can be achieved by using data-science-based rules, risk-based detection, and leveraging as much entity-based correlation as possible.

TTPI’s: Extending the Classic Model by Andrew VanVleet

Tactics, Techniques & Procedures (TTPs) is a table-stakes term in our industry. It binds our understanding of attacker behavior into a common lexicon. Within this lexicon, MITRE ATT&CK reigns supreme, and they have some generally agreed-upon definitions within their ATT&CK FAQ. Basically, in order to understand MITRE ATT&CK, you have to understand their nomenclature of TTPs, where:

• Tactics describe an adversarial objective, such as initial access

• Techniques describe how an attacker can execute some operation to achieve that objective

• Procedures describe the implementation details of a technique in a given environment

In this post, VanVleet challenges this model because the specific details of how an attack is carried out at the Procedure level can sometimes be vague. I think this is by design on MITRE’s part, because the procedure to achieve it can differ depending on the environmental context I mentioned earlier. He makes the analogy that Procedures are like a cake, not necessarily a recipe. He proposes the concept of Instance, which is the recipe itself, to achieve that procedure.

ATT&CK does get close to this via Detection Strategies. As an example, VanVleet looks at T1070.001, Indicator Removal: Clear Windows Event Logs. The MITRE page includes a description of how this can be achieved, but it seems high-level enough that some more detail on the recipe would be helpful. The detection strategy can provide more clues from an event-ID perspective, but without the technical implementation, it may be hard to recreate and test. Here’s his idea of what an Instance section could look like:

This could be helpful for detection engineers who want to recreate the attack in their own environment to test their telemetry generation and detection rules.

I’ve always had a hard time with the Pyramid of Pain for this exact reason. The “TTPs” part at the top of the Pyramid can encapsulate so much work, without any ability to reverse-engineer how the attack is captured. In fact, I’ve always thought TTPs/Tools should be combined, because almost every Procedure contains some level of tooling to capture the attack.

In the spirit of alliteration, and perhaps more as a thought exercise, he proposes the “Pyramid of Permanence”.

Basically, Procedures are what we want to capture, and everything below the tip of the Pyramid are Instances that supports the procedure. It’s an interesting thought experiment, and as long as it serves as a lexicon to drive the conversation on better modeling, I’m all for it.

Centralized Suppression Management for Detections Using Macros & Lookups by Harrison Pomeroy

Detection rule efficacy is the practice of curating rule sets that balance precision, recall, and the cost of triage. New detection engineers typically think about rules being the only place you can apply logic to help manage this balance. A more precise query that accounts for benign behaviors, given the tactic or technique, can increase the likelihood of capturing true positives. But there are other capabilities in SIEM technologies and software engineering practices that can perform filtering and suppress alerts in more dynamic, context-aware ways that align with the threat landscape or your environment.

This post by Harrison Pomeroy details the power of Splunk’s macro and lookup table functionality to perform suppression of alerts without re-deploying rules. A suppression is a concept in which detection engineers deploy a capability to dynamically mute alerts, thereby reducing the cost of both false-positive generation and the subsequent need to tune a rule on small fields. It also makes the rule more resilient because it can account for external factors related to benign behaviors, such as known service accounts, scheduled tasks, or internal tooling.

Harrison leverages Splunk’s macro and lookup table features to achieve this.

The above Mermaid diagram shows his really clever setup. When you apply macros to each of your Splunk rules, you can start bringing in logic to evaluate whether suppressions are enabled for the rule (the T value), and then specify a lookup table to find additional alert logic to append to your original rule to suppress false positives.

The above example suppresses alerting on any user called svc_backup. The macro executes based on the T value and performs a lookup in a table relevant to the PShell Alert rule. svc_backup is in the table and uses a NOT() filter to prevent an alert if svc_backup is present. The suppressed green box ensures the alert doesn’t fire, and the Alert red box fires because the user is jsmith.

This type of suppression occurs at query time, before the alert is generated. There are other suppressions you can apply before a log hits the index, or after the alert fires. This is a great topic for my Field Manual series, so thank you, Harrison, for the inspiration!

👉️ Read Online if Clipped 👈️

The Detection Engineering Baseline: Hypothesis and Structure (Part 1) by Brandon Lyons

Baselining is an overused term in this field because, at least in my experience, it’s a hand-wavy marketing term. You’ll read about a product that’ll perform baselines of your behavior and environment, and it’ll alert you if it detects something abnormal or outside that baseline. In practice, this works, but the opaqueness of some of these methods makes it hard to understand how it happens.

This is why posts like Lyons help cut through the opaqueness and show the receipts of how to do this in practice. And to be honest, it’s nothing groundbreaking, only in the sense that the concepts Lyons proposes here are part of entry-level statistics literacy. Which is why I’m pretty opinionated on the engineer of detection engineer. Don’t get it twisted: although the concepts in this post are entry-level statistics, understanding the application requires deep security expertise.

Lyons lays out a 7-step, repeatable process to establish a detection baseline, quoted here:

• Backtesting of rule logic: Validate your detection against historical data before deploying

• Codified thought process: Document why you chose specific thresholds and methods

• Historical context: Capture what your environment looked like when the baseline was created

• Reproducible process: Enable re-running when tuning or validating detection logic

• Foundation for the ADS: Feed directly into your Alerting Detection Strategy documentation

• Cross-team collaboration fuel: Surface insecure patterns and workflows with data-backed evidence

• Threat hunting runway: When alert precision isn’t achievable, convert the baseline into a scheduled hunt

This process succinctly captures a well-thought-out detection process. Without data, how can anyone possibly deploy detections that will fire? Without context around that data, how can anyone possibly believe the rules that are firing outside of the baseline?

They step through the 7 steps here using a CloudTrail API example. Basically, Lyons tries to map out what anomalous behavior looks like for CloudTrail access across an environment. The statistics section focuses on a modified Z-Score. Here’s the rundown:

Security metrics (API calls per day, login attempts per hour, file accesses) approximate a normal distribution (a bell curve), especially when aggregated over time. This means that:

• Most values cluster around the median (middle value)

• Extreme values become increasingly rare as you move away from the center

• The distribution is symmetric

To establish a baseline, Lyons collects historical data, such as 30 days of activity, and computes two key statistics:

• Median - the middle value

• MAD (Median Absolute Deviation) - measures spread around the median

When a new value enters your queue, you compute the Modified Z-score, which is the distance-via-standard-deviation of that value from the median. Modified Z-score is really good at capturing outliers, versus the regular Z-score, which focuses on standard deviations from the mean, and can be sensitive to outliers.

An outlier can be, according to Lyons, creating administrative credentials at 3am to an abnormal amount of S3 bucket accesses, perhaps used for exfiltration. Here’s a graphic I prompted Claude to create to drive this point home:

This type of rigor removes the guessing game about whether events are absolute measurements. Is 1000 API calls weird, or is 100? Is 10 pm an acceptable window for Administrator access, or is 5 pm? By looking at the standard deviations away from the median, you focus on relative measurement. It removes the human judgment about the absolute weirdness of an event, and whenever you remove a human from a large data problem, you get a bit closer to sanity.

Lyons created a follow-along Jupyter notebook with synthetic data to recreate the measurements in his blog.

Welcome to Issue #154 of Detection Engineering Weekly!

✍️ Musings from the life of Zack:

• I’m back from Spring Break and happy to report I have no sunburns. New England Spring is here as well, and it feels like the Northeast U.S. is coming out of hibernation

• I just booked Hacker Summercamp (BlackHat & DEFCON), so excited to see folks there. If anyone wants to meet up/host an event/drink Miami Vice by the pool, HMU

  • For my BJJ fam: if anyone wants to train at Jeremiah Grossman’s Smackdown or hit an open mat during that week, let me know :D

Webinar with Forrester: AI x Security Operations, What Works and Doesn’t Work

I’m hosting a webinar with Allie Mellen from Forrester tomorrow, where we’ll be diving deep into security operations and how AI is working and not working for all of us.

We’ve had awesome discussions around this in the past. Feel free to register and come roast me in the chat!

Register & Roast Zack

💎 Detection Engineering Gem 💎

A quick look at Mythos run on Firefox: too much hype? by Antide Petit

The talk of the town last week was Mozilla's blog post on how they used Anthropic’s mysterious and powerful Mythos model to find and fix 271 vulnerabilities. The blog post itself isn’t bragadocious in the way you might see vulnerability reports; in fact, it has a level-headed take on how the Mozilla team is hopeful about the scale LLMs can find vulnerabilities, but that no singular vulnerability found was something that a human couldn’t find:

So far we’ve found no category or complexity of vulnerability that humans can find that this model can’t. - Petit

They used the term “vertigo” to describe how jarring the capabilities of LLMs are in changing our perception of defense.

Luckily, this post by Petit helps ground the announcements even further into reality, with some objections to the hype of the news. Petit reviewed Firefox’s issue trackers and commit history to gather more details about the 271 reported bugs. Petit went through the commit history to map bugs to CVEs, classify by exploitability and attack surface, and figure out which of the 271 actually met the bar for a CVE or had a PoC.”

They vibe coded an excellent visualization tool with their findings, located here, with a neat dashboard shown below:

The 12 CVEs shown here tell a different story from the 271 vulnerabilities. Granted, the Firefox team did not say they issued 271 CVEs, but it depends on how we interpret those vulnerabilities and whether they are presented as exploitable or meet the bar for a CVE. The other finding here is that a vulnerability patched for a defender has a tighter distribution of usefulness than one found that is useful for offensive security purposes. A fully exploitable vulnerability still won’t guarantee a Firefox browser breakout, and you typically see these chained together to fully break out of the sandbox.

Petit ends the blog with a section on defender and attack relevance that captures my last point much better than I could ever explain it. Foundation models are proving themselves to be a useful tool for increasing the velocity of defense at a scale that sometimes gives us vertigo. But as an offensive security tool, it may not seem as useful or exciting because of the complexity of building a fully exploitable chain against an extremely hardened piece of software like a web browser.

The operational details of the research matter - Petit

Until this restraint on the opacity of research details becomes more transparent, it’s hard to separate the wheat from the chaff among blog post announcements from foundational labs. So, remain hopeful, but the hype is deliberate to build buzz, even though Anthropic does a good job of balancing this hype so it doesn’t seem disingenuous.

🔬 State of the Art

Streaming Logs to RSigma for Real-Time Detection by Mostafa Moradian

I covered Moradian’s RSigma tool in a previous gem, and he has been busy since then :). RSigma is a Rust binary that evaluates Sigma rules against JSON logs without a SIEM. Since that post, three releases have added some neat new features: NATS and HTTP inputs, a hot-reload feature for rules, observability via Prometheus metrics, and persistent correlation windows backed by SQLite.

Moradian walks through a well-known Okta cross-tenant impersonation scenario to show how these new features work in practice. The four SigmaHQ rules covering that attack (proxy login, MFA deactivation, privilege grant, IdP creation) each fire independently on events that are individually defensible.

The temporal_ordered correlation rule ties them together, requiring all four to fire in sequence from the same actor.alternateId within 30 minutes. Without stateful windowing across events, you risk creating noise on these four rules that may not be correlated. The field-mapping pipeline that reconciles Sigma rule field names with Okta’s camelCase API schema is what makes the whole thing portable. Moradian frames this as one of the hardest parts of detection portability. Vendors certainly take this for granted and leave the work to detection engineers, but Sigma is the closest to standardizing this.

RSigma is not a SIEM, as Moradian puts it, but it’s an impressive feat to build a self-contained Rust binary that operates much like one. For teams doing pre-SIEM rule validation or forensics, it’s a solid plug-and-play option for certain scenarios. It’s also a great read for understanding the deeper architectural challenges software engineers face when building high-volume distributed detection systems.

Are Detection-as-Code Pipelines Overrated? by Harrison Pomeroy

Detection-as-code (DaC) has been the gold standard maturity milestone for security teams for years. The goal of DaC is straightforward: provide governance, guardrails, human review, and validation of detections before they ever touch a production instance. It attempts to minimize regressions, detection drift, and cost increases through the lens of CI/CD and widely used SRE concepts.

Much like everything in security, agentic workflows present opportunities to improve this architecture or remove it altogether. So, in this post, Pomeroy explores this topic with an honest look at how we can scope out several portions of a DaC pipeline and move the work toward the agent running on the detection engineer’s laptop. Schema validation, metadata creation and documentation, linting, and accuracy validation agents for backtesting and accuracy checks can mostly be handled by an agent before it ever hits a pipeline.

We had many of these tasks within CI/CD because we expected humans to make errors. The governance aspect of DaC is attractive because centralizing knowledge around schemas and pre-deployment checks is deterministic by design. As Pomeroy points out, we perhaps overcorrected regarding the necessity of deterministic checks for safety, and an agent can provide both safety and speed. The DaC pipeline still exists, but in a much leaner form that still requires humans for approval.

Detection Pipeline Metrics by Scott Plastine

This short-but-sweet post on detection metrics is a continuation of Plastine’s post on Detection Visibility Metrics. I highly recommend reading the Visibility Metrics post, from which I learned two insights:

• Visibility is just as important as detection itself. There is no rule without telemetry, and you should treat log sources as an asset as much as you treat developer laptops

• We focus too heavily on rule metrics, such as coverage, and neglect business-level metrics like the number of users, coding environments, and servers we protect

After visibility, according to Plastine, you should focus on metrics within your logging pipelines themselves. I love how he used the Funnel of Fidelity as the inspiration for some of these measurements. If we don’t want to “clog the funnel”, we should look to reduce the amount of noise that arrives at alert inboxes. You reduce the amount of noise that makes it to alert queues by building more robust rule sets, risk scoring through composite rules or risk-based alerting, and building pipeline features that flatten or aggregate telemetry rather than sending in a ton of logs at once.

Midnight thinking on browser extension security by Anya Nessi

This is a great late-night musing piece on how it’s going to be harder to differentiate code authors as a detection signal due to agentic coding. The anchor is Red Canary’s Cyberhaven incident analysis, where the compromised extension update scored a modified z-score of 75.38 against the extension’s historical entropy baseline. For context, 3.5 is already a strong statistical outlier. A score of 75 means the injected script’s entropy was so far outside the distribution of the legitimate codebase that attribution to the same author was statistically implausible. I covered the modified z-score in Issue 145 if you want more background.

Nessi built her own entropy-based detection pipeline along similar lines, and it works. The question she’s grappling with is what will happen to this technique as LLM-assisted development becomes the norm for both legitimate developers and attackers. If both parties are writing code using tools trained on overlapping data, the distinct human authorship fingerprints that enable entropy-based detection begin to drift.

☣️ Threat Landscape

📦🔗 TeamPCP News

TeamPCP was back in the news this last week! These attacks don’t seem as impactful as the several I covered earlier this month, but there are some worthwhile callouts about updates to TTPs.

Malicious Checkmarx Artifacts Found in Official KICS Docker Repository and Code Extensions by Socket Research Team

The group compromised multiple Checkmarx distribution channels simultaneously: the official checkmarx/kics Docker Hub repository had trusted tags overwritten with a trojanized KICS binary that exfiltrated secrets during infrastructure-as-code scan runs for Terraform, CloudFormation, and K8S configs. Checkmarx ast-vscode-extension had an orphaned 2022 commit injected carrying a payload that runs via Bun and exfiltrates secrets, including MCP config files. It looks like the Bitwarden CLI npm hijack was part of the same campaign, and I wrote about this below.

TeamPCP Campaign Spreads to npm via a Hijacked Bitwarden CLI by Meitar Palas

In the next part of the campaign, the group compromised the npm CLI of the well-known password manager BitWarden. According to JFrog research, the group hijacked @bitwarden/cli version 2026.4.0, keeping the legitimate Bitwarden branding intact while rewiring the installation scripts to download Bun and execute a payload that attempts to exfiltrate GitHub tokens, SSH keys, and AWS/GCP/Azure secrets, as well as GitHub Actions secrets. The interesting part here, which I haven’t seen before, is that the malware explicitly targets ~/.claude.json and MCP config files, potentially marking a shift to use secrets from coding agents to pivot into victim environments.

Other News

I Left Port 22 Open on the Internet for 54 Days. Here's Who Showed Up. by Arman Hossain

This was a fun honeypot research project write-up in which Hossain deployed a basic SSH honeypot on a cheap VPS to collect and analyze connection attempts and attacks. Nothing here seems out of the ordinary or new from the sense of novel attacks, but it goes to show how noisy the Internet is and how easy it is to be targeted by Internet-wide scanners. Attackers attempted to run default credentials for well-known IoT devices, tried to download binaries to have their servers join a botnet, and had some level of hands-on keyboard operators interacting with the server. This would be a great experiment and exercise for folks getting into threat research and log analysis to build a server like this and analyze the logs.

Fibergrid: Inside the Bulletproof Host for 16,000+ Active Fake Shops by Harry Freeborough

Bulletproof Hosts are organizations that provide IP leasing space for customers and are known for not responding to takedown requests from abuse reports and, often, to law enforcement preservation requests. They are impressive feats of misdirection in that these organizations tend to layer themselves through shell companies and hard-to-contact administrators to maintain anonymity.

Fibergrid is a particularly unique bulletproof hoster because of its origin story. Netcraft Research has been tracking Fibergrid and attributed 16,700+ active fake shops and an IP address pool that traces back to the Great African IP Address Heist. Netcraft found that the servers are actually sitting in Equinix facilities across the US, UK, and the Netherlands, not Africa, which Netcraft argues gives Western law enforcement a real pressure point.

🔗 Open Source

F2u0a0d3/goodboy-framework

I was hoping to get a dog picture or instructions for training a dog to be a good boy in the README. Instead, I found an excellent resource for people trying to learn malware development, analysis, and detection engineering on Windows using Rust. There are 15 lessons or “stages”, and each one has a particular technique it’s trying to teach you to learn. They integrate malware technique development, such as direct or indirect syscalls, with analysis techniques for finding what you wrote along the way.

weirdmachine64/SharkMCP

Locally-run MCP server that provides tooling for local agents to perform PCAP analysis using Wireshark’s sharkd API. There are close to 20 tools that weirdmachine64 exposes for clients, and so you’ll want to add this one to your CTF arsenal, especially if you are looking at pcap files.

trailofbits/trailmark

Trailmark is a tool for visualizing code paths and dependencies. You feed it a codebase to analyze, and it’ll construct an abstract syntax tree in Treesitter format and pass it to a graphing function. You can then query the graph for specific classes or code paths, as well as use their querying capabilities to perform reachability analysis, annotate functions, find dependencies, or look for “paths in between” two nodes.

synacktiv/pike-agent

Pike-agent is an LLM assistant that reads strace telemetry and performs analysis based on the prompts you give it. For example, if a binary crashes every time you run it, you can feed it to pike-agent, and it’ll help you debug the root cause. I think the cool use case here, and I might be biased in security, is the malware analysis functionality :).

anondotli/awesome-privacy-tools

Yet another awesome-* list, this time focused on privacy tools. I’m surprised something like this hasn’t been made yet, but it’s nice to see an aggregation of useful tools that can help improve your OPSEC. Might be especially useful if you are a threat researcher or intel specialist doing cybercriminal research on underground forums.

Welcome to Issue #153 of Detection Engineering Weekly!

✍️ Musings from the life of Zack:

• I’m spending time in the Caribbean this week with my family and wish I could write this newsletter everyday with nice weather and an ocean nearby. Luckily New England does have the Atlantic, but it’s not the same for two reasons. First, the fruit is so much tastier down here. Lastly, I can’t find an Oscar the Grouch with dance moves quite like this Oscar :D

  

• I’m hosting a webinar with Allie Mellen from Forrester on April 30th where we’ll be diving deep on security operations and how AI is working and not working for all of us. We’ve had awesome discussions around this in the past. Feel free to register and come roast me in the chat

  Register & Roast Zack

Sponsor: Push Security

Register for a brand new research-focused webinar series from Push Security

The browser is the place where modern breaches happen, powered by a huge amount of attacker innovation — countless ClickFix variants, new malvertised phishing campaigns, and device code phishing attacks being powered by brand new PhaaS kits and AI tools. And we’re only in April.

Join Push Security threat researchers, along with incredible guests like John Hammond, Troy Hunt, and Matt Johansen, in a brand new webinar series deep-diving into the State of Browser Attacks.

Register Now

💎 Detection Engineering Gem 💎

Internet Protocol Version 8 (IPv8) by Jamie Thain

Ok, here’s a confession, but it’s more of a brag than something to be embarrassed about. When I went to college, I studied networking and network security extensively, as the 2008-2012 era had a strong focus on it. A lot of what my classes entailed was setting up large VM farms and networking devices on server racks. I lucked out because I got really good at networking, and part of that involved studying RFCs. I love RFCs. My favorite RFC is 1034, DNS, the coolest protocol in the modern Internet.

My co-worker sent out a link this week amid the Opus-4.7 news about the IETF skipping odd-numbered Internet Protocol RFCs and moving directly to IPv8. This specific proposal (not yet accepted) attempts to address the fragmentation of IPv4 & IPV6 networks around IP address assignment, DNS, NTP, telemetry, authentication, route validation, and access controls.

Jamie Thain, the proposal’s author, suggests that these fragmented services can be reconciled through a singular concept called a Zone Server. This Zone Server assigns DHCP leases that contain network information for everything I listed above. As Thain puts it:

The most interesting part of this proposal, IMHO, is the authorization model. Every manageable element in an IPv8 network is authorized via OAuth2 JWT tokens. Like what Thain said in the quote, when a new device joins, it sends a single DHCP8 Discover and receives a lease containing the device’s configuration, including a JWT. The “OAuth2 Authority” can be hosted on a home router or on an external IdP such as Google Workspace, Okta, or Azure AD. The Zone Server stores the public keys for these authorizations, so local devices can verify token validity with the Zone Server before interaction. It reminds me a lot of Tailscale, but unlike Tailnets, rogue devices can still join your network; you just need to make sure peer devices validate tokens before they talk to it.

The second most interesting thing is DNS. Every outbound connection must have a valid DNS8 lookup before it traverses the broadcast domain; otherwise, it is automatically blocked. This helps protect against malware infections calling back to a C2 server.

As Claude pointed out, this authorization layer exists at a higher layer in the OSI stack. Attacks can still occur on lower layers. Putting my networking nerddom aside, it’s refreshing seeing how Internet-scale engineers are thinking about solving issues around security and having solutions being a feature of the protocol itself. This prevents service fragmentation, poor visibility, and the need to stitch together different security layers and hope they work.

🔬 State of the Art

This was a fun episode of Discarded where the hosts interviewed their coworker, Stuart Del Caliz, who’s a threat detection engineer at Proofpoint. When I think of writing rules and detections, my mind usually drifts towards researching and deploying log-based detections in a SIEM. Del Caliz, on the other hand, focuses on Suricata & YARA rules for malware using appliance products via the Emerging Threats Ruleset. The team has a robust malware sandbox that enables Del Caliz and the detection team to identify patterns in C2 traffic and binaries and to generate alerting and blocking mechanisms for customers.

Luckily, the Emerging Threats Ruleset is available for download, so you can set up your own Suricata lab to test it out.

macOS Threat Investigation Benchmark by Cotool Research

Friends of the newsletter Cotool published their latest research benchmark on the efficacy of the latest foundational model around macOS investigations. What makes this interesting is that, unlike CTF events, which have a clear incremental path to success, this benchmark uses logs and telemetry from an Odyssey stealer infection. The agents were given access to 14 log sources across hundreds of thousands of events and had question harnesses across 36 tasks in incident response, threat hunting, and detection engineering.

GPT-* models performed very well across Accuracy, Speed, and Reliability, and were middle-of-the-pack in cost. I think the most interesting finding here is that Cotool rewarded models based on task difficulty. For example, Incident Response was the hardest and most expensive among the tracks, and GPT-5.4 and 5.3 Codex had the best combination of accuracy and cost efficiency. Opus 4.6 had the same accuracy but cost nearly double that of GPT-5.4

Detecting CI/CD Supply Chain Attacks with Canary Credentials by Alessandro Brucato

The Tracebit team just released a clever canary detection mechanism for supply-chain attacks against GitHub Actions, similar to what we saw with the TeamPCP campaign a few weeks ago. Security teams can pull in their community edition GitHub action, which generates per-run canary credentials, such as AWS tokens. If your security controls fail or you fail to detect an attack, you can use these tokens as a reliable alerting tool that points to the repo and specific GitHub action.

They have a community edition, which is always great to see, because you can sign up and try it without all the vendor marketing gates and FUD that is commonly shoved down security people’s throats :).

Codex Security by OpenAI

The foundational labs are leaning more and more into cybersecurity use cases. With Mythos’ release last week, OpenAI released a Codex Security preview that allows vetted cybersecurity professionals to use an advanced version of Codex to scan their repositories for vulnerabilities. The “vetted” part of this announcement is interesting because Mythos was heavily gated in their announcement, whereas OpenAI has made it easier for folks to apply and get access if they meet certain verification criteria.

Sponsor: Spectrum Security

Stop the Grind and Kill the Detection Backlog with Spectrum

You know the grind: Research the gap. Understand the environment. Write the logic. Tune it. Deploy it. Watch it break when something upstream changes. Repeat. Backlog never shrinks.

Spectrum is now available. One platform that continuously maps your coverage, authors deployment-ready detections tailored to your stack, and keeps them resilient, so your expertise drives strategy, not maintenance.

See It In Action

☣️ Threat Landscape

Two U.S. Nationals Sentenced for Facilitating Fraudulent Remote Information Technology Worker Scheme that Generated $5M in Revenue for the Democratic People’s Republic of Korea by U.S. Department of Justice

Why is it always someone from New Jersey?

Kidding, unless you are a Jets fan. The DoJ released a sentence announcement for two U.S. nationals who became facilitators for Wagemole over several years. According to the announcement, they helped generate over $5 million USD of revenue for DPRK, stole identities of close to 100 U.S. persons, and worked at 100s of U.S. companies.

I post a lot about the DPRK in this newsletter because it hits so close to home, given that I work in tech. I also post a lot about DPRK in this newsletter because I have to follow up with these Wagemole stories by watching this Key & Peele sketch:

NIST Updates NVD Operations to Address Record CVE Growth by NIST

NIST released updated guidelines on how they will perform CVE enrichment moving forward. They’ve had nearly two years of turmoil trying to keep up with enriching CVEs for their National Vulnerability Database. I think this failure to enrich every CVE is due to two things: funding shortages and AI. I’ve linked a ton of stories here from open-source maintainers like Daniel Stenberg, saying that AI is creating too much vulnerability research slop. But I do believe recent CVEs have been at least AI-assisted, which helps increase velocity.

In their announcement, NIST says it will prioritize CVEs into three categories: CISA KEV entries, vulnerabilities in software used by the federal government, and CVEs for Critical Software, as detailed in an executive order from 2021.

There are other playbook changes regarding severity scores and modified CVEs, but IMHO, the significant reduction in CVE enrichment is the big news here. I hope we can find a way, as a community, to fund efforts to enrich CVEs in lieu of the NVD.

MCP Supply Chain Advisory: RCE Vulnerabilities Across the AI Ecosystem by Moshe Siman Tov Bustan, Mustafa Naamnih & Nir Zadok

The Ox Security Research Team found four attack surfaces in Anthropic’s MCP Protocol implementation. These attack surfaces led the research team to disclose vulnerabilities to dozens of open-source repositories and get to 10 CVEs and counting. The way it works is how this software sets up MCP servers and what they allow as input into their configurations. The command injection is via exposed tools that can add an MCP configuration. When you add an stdio transport, you can specify an arbitrary bash command that allows remote code execution.

The team disclosed this vulnerability to Anthropic but the protocol specifically allows this option and is by design. The problem here is when users of these MCP-enabled projects don’t know about the insecure configuration and deploy it to the Internet allowing the remote code execution. There are situations where this RCE can be unauthenticated or authenticated, but for the most part, it points out that anytime you allow arbitrary configurations to be uploaded by users, you risk exposing yourselves to attacks like this.

Understanding security warnings when opening Remote Desktop (RDP) files by Microsoft

Microsoft finally released security updates to help warn users of malicious RDP files before they become victims of an infection or social engineering attack. Attackers leverage RDP files to initiate remote connections to victim computers, often using them to steal files, take pictures or steal contents of your clipboard. Now, users of the latest security update will get warnings when double-clicking on these files, hopefully preventing some of these infections from happening.

With the advent of ClickFix, my hopes aren’t too high, but sometimes security is about incremental steps versus massive swings.

🔗 Open Source

google/magika

Magika is file on steroids. It uses a deep-learning model under the hood that helps classify files with what they claim is 99% accuracy. It was trained on 100 million+ samples and 200+ content types. The cool part here is that this is the model and tool used by Google to help detect filetypes on Gmail, Drive and Safe Browsing. I imagine they can use this to route files based on their content types to different internal security services for scanning.

mukul975/cve-mcp-server

Locally ran MCP server that helps researchers and defenders connect to 27 (!) security tools for CVE lookup and enrichment. Unfortunately you won’t get much data anymore from NVD, but it has some great integrations with ATT&CK, internet scanners and even VirusTotal.

Hainrixz/cyber-neo

Cyber Neo is a Vulnerability research plugin for Claude Code. It has 11 security domains it tries to scan for, and each domain has toolsets and markdown instructions for Claude to execute to render findings.

tahaafarooq/Fenrir

GoLang credential and secrets harvesting tool that uses eBPF to skim credentials off from syscall events. It’s like a Linux rootkit that only cares about secrets. It has some interesting capabilities, such as memory-only execution and anti-detection capabilities. It tries to intercept secrets across SSH, PAM, the command line and does some file-based discovery for things like API keys and cloud secrets.

jsmonhq/xnew

xnew is a low-footprint and fast file appender. It is contextually aware of every line inside the file, and it will only append unique lines not already present. This has always been a pain for me everytime I’ve had to cat x | uniq | sort | uniq , which can sometimes take forever when the file is super large.

Welcome to Issue #152 of Detection Engineering Weekly!

✍️ Musings from the life of Zack:

• The sun is staying out later and coming up earlier. There’s nothing better to me than an early morning sunrise :)

• I finished my book about the Marquis de Lafayette, Between Two Worlds, and it was fantastic. I’m already reading a new one about the ugly truths of living on Mars called A City On Mars. A former NASA Chief Economist recommended it on a podcast

• I’m excited for an upcoming beach vacation in the Caribbean for some much-needed sun and relaxation. I’ll still be putting an issue out, so there won’t be a gap in coverage (ha)

Sponsor: Adaptive Security

Can Your Team Spot an AI Deepfake Attack?

Today's phishing attacks involve AI voices, videos, and deepfakes of company executives.

Adaptive Security is the first security awareness platform built to stop AI-powered social engineering.

Adaptive protects your team with:

AI-driven risk scoring that reveals what attackers can learn from public data
Deepfake attack simulations featuring your own executives
Interactive, customizable training content

Tour The Platform (3 minutes)

💎 Detection Engineering Gem 💎

Measuring What We’re Missing by George Chen

In this post, Chen gives readers some honest thoughts and super reasonable metrics around measuring detection efficacy. We tend to fall into the true-positive/false-positive trap because they are the easiest to measure and explain. False negatives are the most risky, but if you only rely on a security incident where an alert failed to fire, they can really affect your detection engineering operations, because you can only measure when things go wrong. Your operational work should revolve around identifying coverage gaps (false negatives) and eliminating unnecessary work (false positives).

These metrics can fall into “busy work”, when you really want to show impact. You also risk making your coverage gaps harm your operational score instead of celebrating them.

Chen’s fix is to separate detection efficacy into two signals:

• An effectiveness score (how well do tested controls perform?)

• A discovery count (how many new gaps did you find outside of testing?)

The “under test conditions” qualifier is the important part. This isn’t a coverage number. It’s a performance number scoped to what you’ve actually challenged through red teams, purple teams, BAS, and threat hunts. If 50 techniques are executed and 10 are missed, you now have a denominator, a defined scope, and a measurable gap. Without that structure, a miss is just an observation.

The discovery count stays separate on purpose. If you lump newly found gaps into the denominator, the more unknowns you surface, the worse your score looks. That creates a perverse incentive where teams stop looking for blind spots because finding them risks tanking the metric. Chen’s answer is simple: keep it as a standalone count. “3 new gaps discovered and addressed in Identity & Access this quarter.” Effectiveness tells you how well tested controls perform. Discovery tells you how much you’re still missing.

I’m seeing metrics like this more often in security operations, where we’re starting to describe the health of the system, similar to what Site Reliability Engineering departments do. Chasing 100% accuracy is meaningless due to the Precision and Recall Problem, but showing any kinks in the armor can come across as unpreparedness. Owning the idea that you need to curate and maintain a ruleset, just like you maintain a cloud or on-prem environment, is a more stable approach for your sanity and for business outcomes.

🔬 State of the Art

Hunting Malicious Teams Delivered Links via Endpoint & Cloud Telemetry Correlation by CipherSecy

This comprehensive threat hunting report highlights a rare but effective attack scenario around Microsoft Teams. In any modern workspace chat application, you can talk with your coworkers and external people like contractors, vendors, or customers. So, something like Teams or Slack can serve as an excellent pivot point for threat actors, since they gain direct access to your DMs, and the telemetry isn’t as well-documented as with phishing emails.

CipherSecy built the following hypothesis before their hunt:

A compromised third-party account sends a malicious link via Microsoft Teams with the intent of compromising an internal user’s identity.

What follows are their findings and documentation on available telemetry to help catch these types of attacks via Teams. A hunt like this uncovers a ton of nuances and peculiarities in the attack flow from a visibility perspective:

Teams launches an in-app browser via a CLI command. The browser can link to malicious downloads or phishing sites, so making sure you have an EDR that can provide that telemetry is important. The cool part here IMHO is the rich context from within the CLI command:

C:\Program Files (x86) \Microsoft\Edge\Application\msedge.exe"
--single-argument microsoft-edge:///?url=https://github.com/notsosafelink&
source=teams&treatment=4445&form=MY02BU&qpc=955403648535
&oid=<RCV-OBJ-ID>&hubappid=bc25fcef-8964-4e72-8287-23e2b496c128
&hubappsubpath=embed-client/chats/19:<SNDR-OBJ-ID>_<RCV-OBJ-ID>@unq.gbl.spaces
/view&hubappparams=hostCtx=edge&layout=singlePane&src=teamsLink
&messageId=<MSG-ID>&oid=<USER-OBJ-ID>&loginHint=<RCV-UPN>
&startTimeStamp=1773993512074&correlationId=<GUID>

CipherSecy points out two things here. One, —-single-argument indicates a process spawned Edge programmatically, which helps reduce the noise of manual browsing. Secondly, src=teamsLink means it was spawned from Teams itself. Both turn into high-value signals, and throughout the rest of the post, they show some of their KQL queries to perform additional hunting and inspire some detection opportunities.

Joshua Saxe

Exploits don't cause cyberattacks

As far as I can tell, here’s the median model of attacker behavior people are using in their Claude Mythos hot takes…

Read more

3 months ago · 10 likes · 5 comments · Joshua Saxe

Mythos has been the talk of the town since its preview release on April 7. The industry reacted to the hype with mixed reactions. On the hype side, it’s an extremely impressive model and deserves its accolades for vulnerability research and exploitation. In fact, Anthropic is worried enough about the model that it created an invite-only program, dubbed Glasswing, to give early access to companies that will initially use it to find and fix vulnerabilities.

On the other hand, the incentive structure of frontier labs like Anthropic is to build hype and generate buzz. And when you generate buzz around the security industry, you will get pushback against the hype, whether you want it or not. I believe Saxe’s pushback in this article has the best-grounded arguments to help us brace for impact without burning too much energy bracing too hard.

Mythos, much like Opus’ release, will fundamentally change a lot of our capabilities. But much like Opus, our security capacity is bounded by more than just computation and prompting. Saxe frames this argument with a thought experiment. If these frontier models changed the game for synthetic voice and text, have we meaningfully seen an explosion of activity in social engineering and phishing attacks? The key here is “explosion”, because that’s what it seems like the Mythos release is warning the industry about, but instead of phishing, it’s vulnerabilities.

I do wish there were some investigation from Anthropic on the detection and response front. Mythos will clearly help the vulnerability side of the house, but what about deep investigations, rule writing, or threat hunting? Frontier models have fundamentally changed blue team operations in these fronts, but I don’t think it’s ruined the status quo. We’ve certainly become better prompt engineers, though :).

Myth & Mythos: Where Do We Go From Here? by Joe Slowik

It’s pretty apt that Joe Slowik wrote a blog about Mythos on his blog named “Stranded on Pylos”. I really enjoyed reading this essay, mostly because it highlighted some of the intentional or unintentional decisions Anthropic made when announcing Project Glasswing. Specifically, the lack of non-American companies and the focus on tech & IT rather than critical infrastructure or healthcare organizations.

Joe is a staunch advocate for critical infrastructure security research, especially around OT systems. He offered a critical but fair take on the initial release of Project Glasswing, lacking any focus on these areas. In all fairness, as he points out, many of these large tech companies do build and maintain products for critical infrastructure networks, but there isn’t enough information from Anthropic to confirm whether they are considering the threat model for these networks.

Admittedly, I think it’s a Catch-22. If Anthropic brought in a Siemens, and maybe didn’t bring in Apple, would we be making the same argument? Probably. And the marketing is well done, capturing the attention of major news outlets worldwide. Though Anthropic, in my opinion, has done the most to demonstrate its commitment to AI safety research, I feel like they are more trustworthy for the time being, especially when they say something is “too dangerous right now.”

Webex-ploitation by Grumpy Goose Labs

I first featured Grumpy Goose Labs in Issue 11 (!!), and since then, they’ve done a ton of research on hunting for Fake IT Workers. In Issue 138, I wrote an analysis of their fantastic research on hunting for KVM Switches in Crowdstrike, which can be a great signal for facilitators who gain fraudulent employment. In this post, they switch their hunting methods to look for Webex sessions used by facilitators in a similar way.

I find it insane how RMM software, like Webex, has poor audit logs, logs everything locally, and provides opaque logs that make it a lot harder to detect and hunt for this activity. I ran a cursory search on GitHub for any log-shipping pipelines that parse, normalize, and ship these logs to providers, and I didn’t find any.

The craziest find in this research is how WebEx has keylogging capabilities. It’ll record keyboard firing events to the local log files, and so theoretically you can: a) spy on your employees, b) run malware that ships these logs off to a C2 for password collection, or c) hunt for TTPs by some of these IT Workers.

☣️ Threat Landscape

Our response to the Axios developer tool compromise by OpenAI Security

The OpenAI Security team published a security update on the impact of the Axios supply-chain compromise on their macOS signing process. According to their security team, the GitHub action that signs the binaries for their macOS apps, such as Codex CLI and ChatGPT desktop, was compromised and downloaded the malicious Axiox 1.14.1 version.

Based on research published over the last week and a half, many of these compromised builds failed due to peculiarities in their code, but OpenAI revoked and rotated the signing certificate out of an abundance of caution.

Tracking Adversaries: EvilCorp, the RansomHub affiliate by Will ‘BushidoToken’ Thomas

Following my Threat Landscape coverage from last week’s issue, threat research G.O.A.T. BushidoToken’s timely issue on EvilCorp helps tie their operations under the newer and active RansomHub affiliate program. Since the U.S. sanctioned EvilCorp, it has become much harder for victims to pay the group after they suffer a ransomware attack. This leads groups to rebrand as new groups or join affiliate programs to continue their operations, removing a significant financial hurdle to their success.

Will’s survey of infections from the last few years of ransomware attacks helps tie them to EvilCorp because of the use of the SocGolish malware. This is about as close as you can get to attribution with only pure technical data without relying on HUMINT, such as law enforcement or doxxing.

Inside an AI‑enabled device code phishing campaign by Microsoft Defender Research Team

This post by Microsoft Defender Research highlights a phishing operation tracked under the EvilTokens phishing group. It focuses on DeviceCode phishing, where a threat actor abuses an authentication flow primarily used to sign in to Microsoft accounts associated with non-endpoint applications, such as Netflix or YouTube. The way the attack works is when you click “Sign-in with Microsoft”, you are given a token that lasts 15 minutes to complete the authentication flow. This makes sense given it’s designed for devices other than your laptop.

Traditional phishing campaigns must generate the token before sending a phishing email, which can limit the infection window. According to Microsoft, EvilTokens' unique approach is to use AI-generated frontends and workflows to create on-the-fly tokens via a hyper-optimized phishing page, thereby extending the window to the full 15 minutes, since tokens are generated only when the victim interacts with the attacker's infrastructure.

Tracking an OtterCookie Infostealer Campaign Across npm by Alessandra Rizzo

In the latest evolution of Contagious Interview/WageMole and FAMOUSCHOLLIMA-aligned threat actors, Panther security researcher Alesandra Rizzo tracks an open-source supply chain attack that results in an OtterCookie infection, followed by the exfiltration of developer secrets and machine configuration files. To me, there are two interesting findings that showcase the evolution of DPRK-nexus threat actors.

First, they are heavily abusing Vercel services, making it easy to stand up and rotate attacker infrastructure used as exfiltration points. Secondly, the OPSEC trickery around dotted Gmail email addresses, such as t.e.ch.y@detectionengineering.net, allows them to get a little more use out of the emails, since Gmail ignores dots when receiving email on behalf of users, whereas other services like npm do not.

ClickFix technique uses Script Editor instead of Terminal on macOS by Jamf Threat Labs

When I first learned about the ClickFix infection technique, I couldn’t believe that people would copy and paste terminal commands from a website into their Terminal. I scoffed at people falling victim to it, exclaiming that it would never happen to me because I’m a security person. I then proceeded to install a package manager by copy pasting a bash command into my terminal:

The technique works because the industry has collectively settled on the ease of installing software via a copy-paste command. So, as vendors like Jamf and Apple began to catch up by deploying mechanisms to detect this behavior, threat actors adjust and continue the cat-and-mouse game.

In this post, Jamf Threat Labs uncovers a ClickFix campaign they discovered that combined the social-engineering aspect of a lookalike website with an older technique: AppleScript URIs. According to the researchers, victims are presented with the phishing website, and instead of copy-pasting the command, you click an Execute Button, which runs a native applescript:// feature that launches a Script Editor and prompts the user to run it.

The payload leads to an infostealer infection so not much changes there, but adjusting the delivery and exploiting the trust of victims running these commands are just one UI/UX workflow away from a new infection.

🔗 Open Source

salesforce/url-content-auditor

url-content-auditor scans web content for sensitive data, such as secrets and PII, as well as anything that puts the website's or its users' privacy at risk. It’s smart enough to download video, audio, and documents, extract data, apply some heuristics, and also use LLMs to classify and alert on anything sensitive.

momenbasel/malware-check

Modern static and dynamic analysis toolset for malware analysis. It has an impressive number of analysis engines, including Windows, macOS, Linux, Android, and iOS. It uses a Docker sandbox for its dynamic analysis, so it’s pretty lightweight. It generates findings in the console, JSON, HTML, and SARIF for CI/CD pipeline reports.

416rehman/DeepZero

DeepZero is a research toolset using quite a grab bag of techniques to find vulnerabilities in Windows kernel drivers. Two features stood out to me. One, it uses Semgrep rules on decompiled binaries to find “known vulnerability shapes”, which essentially means it can direct analysis towards interesting findings versus sweeping the whole binary. On the back of the Mythos announcement, it uses DeepAgents from langchain and Vertex AI to triage the Semgrep findings.

momenbasel/htb-writeups

Massive compendium of HackTheBox writeups used for self-learning and exploration. This is super helpful for those who want to explore topics as they work through HackTheBox challenges, or they want to see and read about techniques used during these challenges. It has four interactive tools you can use to query and generate write-ups based on your interests: everything from searching for specific machines, operating systems, and attack paths to a Skill tree that maps out your learning journey.

pandaadir05/snoop

Slick-looking syscall tracer leveraging eBPF versus strace’s ptrace. This is especially helpful if you are using it to research malware or hunt for vulnerabilities in binaries on CTFs. The TUI is quite beautiful and interactive, whereas strace makes me want to cry every time I stare at it.

Welcome to Issue #151 of Detection Engineering Weekly!

✍️ Musings from the life of Zack:

• I tried to visit my hometown over the weekend, but my flight was canceled before I could leave. I did my first solo road trip in probably years. Maybe it’s an American culture thing, but I didn’t mind the 6.5-hour drive. Lots of music, podcasts, and sitting with your thoughts

• It’s always strange going back to your hometown and seeing how much has or hasn’t changed. For example, it’s almost mid-April, and I drove into snow :(. But pizza & chicken wings are so much better in NY than in New England so I hope that never changes

• I’ve been reading about Daniel Miessler’s PAI project, and I’m quite impressed with the idea of using AI for Personal Augmentation. Rather than having several Claude Code sessions or optimizing ways to integrate into Gmail or Calendars, you can use this almost like an extension of yourself. It learns your motivations, wishes, and tool-stack preferences, and even tries to configure its personality so you enjoy working with it. This is definitely my project for the next several weeks

Sponsor: Nebulock

Automate the Tedious Parts of Your Hunting Workflow

The hardest part of threat hunting isn’t running queries. It’s knowing what to look for, why it matters, and whether your environment is exposed.

Distilling reports, mapping TTPs, and translating into behavioral indicators is where time disappears. Vespyr, Nebulock’s autonomous hunting agent, handles the reasoning layer. Findings are tied to your stack, your data, and your exposure profile, so every result is relevant to your environment and ready for the judgment calls only you can make.

See How Vespyr Works

💎 Detection Engineering Gem 💎

The Implementation Blind Spot | Why Organizations Are Confusing Temporary Friction with Permanent Safety by Chris St. Myers

This is an excellent commentary on the risks in the adoption curve of AI and Agents in security. It’s easy to get overwhelmed by the noise of marketing, fear, uncertainty, and doubt about security. On the one hand, we are hearing about so many companies adopting AI to increase productivity, sell products, and, more often than not, citing its use to justify layoffs. On the other hand, AI doomers claim that this technology will ruin our careers by automating us away. Like most things in life, the answer is probably somewhere in the middle, but we need to make sure we understand the risks.

We are all fortunate to be standing on the shoulders of giants. We know what a good security product, alert, or workflow looks and feels like. AI is too nascent for us to forget how much we’ve had to practice learning our craft with deterministic tools like Wireshark, the command line, and SIEMs. St. Myers warns, though, that we are at risk of forgetting. He compares and contrasts this with the massive adoption of technologies like the cloud, where we retained the analytical capabilities of security people and anyone in technology, because it was a deterministic shift in architecture. We still needed to understand and synthesize information to help automate tasks.

We are not just changing the pipes; we are changing who (or what) processes the data.

But, for AI, it’s non-deterministic, and that’s by design. And the ‘who’ in the quote here is important. St. Myers calls this risk the “cognitive rust belt”. We aren’t farming out architecture, building, or repetitive tasks to AI; we are farming out analytical capabilities. It’s a gradual hollowing out of analytical capabilities, as if we were all handed a junior analyst to synthesize data for us, and all we read are prompt responses.

Here’s how it relates to detection and response:

• We’re building out increasingly complex detection technology, but we risk losing the understanding of why those detections matter, and how we can investigate when they fail

• For AI-generated triage, are we slowly removing the “approved by an analyst” workflow? What parts of D&R will we lose agency to AI?

• If we solve SOC analyst burnout with AI, which is great, what do we lose in the process? How else can they learn the field if they don't sit down and work through alerts?

They have been living inside summaries, not raw telemetry.

These are paradoxes in detection engineering, but honestly, it applies to every place trying to replace or accelerate human analysis with AI. We have to find ways to train and retain this expertise in an analytically rigorous profession. The prompts will be tuned and perfected, direct feedback on results will become more opaque, and we run the risk of understanding the how underneath the hood. When we enter the rust belt, it’ll be harder to trust the output of LLMs without trusting that we have the expertise to judge them.

🔬 State of the Art

I fell in love with Darknet Diaries years ago, probably starting with the Carbanak Episode. It’s cool to learn about the intermix of pure cybersecurity, professional stories, and security-adjacent stories through Jack’s storytelling. In this episode, Jack interviews the CEO of BeatDapp, who first started out as a fraudster in the BlackHat/GrayHat SEO realm. They began as a marketing firm but are now a fraud-prevention platform for the music industry. There are SO many parallels to security.

• Fraud impact is directly measurable to impact (loss prevention), and bad guys are extremely persistent in finding ways to perform fraud

• Many techniques to perform that fraud involve security means, such as compromising individual accounts all the way to compromising streaming services to skim money from payouts

• Detection rules range from basic heuristics to machine learning, and clustering activity is a huge part of finding fraud

I also learned a few things about the streaming platform’s business model after this. Advertisers pay apps like Spotify or Apple Music for ads, and the money goes into a single pool each month. The streaming services then take all the listen counts by artist, sum them, and divide them across artists to create pizza slices (percentages) showing how each contributed to that sum. Then they carve out a portion of the ad revenue to pay artists and divvy up the payments according to those percentages.

So, if you compromise an artist or the streaming services, and you can take money off the top of those payouts, you can make a lot of money.

Fascinating stuff!

A Detection Researcher Mindset by Scott Plastine

It always fascinates me to find posts like this one by Plastine that outline their mental model in how they approach research and detection ideation. Detection ideation typically begins with a news story or a research blog post that (hopefully) contains enough technical detail to initiate the process. Then, you should deconstruct this information into components around capabilities, environmental context, existing coverage, and feasibility. This is easier said than done, so Plastine splits this into seven steps, with, funny enough, the last step being to write the detection.

They first start with understanding the technique and what normal behavior looks like in the context of the attack. A lot of people jump straight into writing rules without properly investigating whether this is even relevant to their environments. If it is relevant and you do understand the attack, you must then see whether you have the necessary telemetry for your rules to fire.

My favorite step in this blog, though, is under “is prevention possible?” A metric we can all obsess over is rule count and coverage, and making sure they go up. More rules is more coverage and more attacks, right? As an industry, I think we need a separate metric that accounts for cases where we remove rules because we implemented a technical control to limit the attack path altogether. Seeing Plastine call this out as a possibility in rule development means teams obsess less about hitting coverage metrics and more about recommending and implementing security controls that make all of our lives easier.

SITF: The SDLC Infrastructure Threat Framework by Wiz Research

We can’t always wait for MITRE ATT&CK to release new frameworks so quickly; many great research and security teams can help fill that gap with their own ATT&CK-style frameworks for everyone in the industry. The SDLC Infrastructure Threat Framework, or SITF, helps solve that gap. Here are some gaps and features they address:

• They list five components of potential victim infrastructure: Endpoint, VC, CI/CD, Registry & Production. You can see these being attacked in every supply chain attack in the last two weeks surrounding Trivy & Axios

• Three stages, Initial Access, Discovery & Lateral Movement and Post-Compromise, connect to ATT&CK, sans post-compromise

• The techniques are specific and actionable. For example, Git Tag Manipulation was used in the Trivy attack as tags were removed and re-added with an orphaned commit on a fork in the attacker’s repo

Each technique has protective controls associated with them, so this is great reference material for those who are trying to harden their supply chain pipelines.

PR3TACK by Atlassian CSIRT

The Preemptive Tactics & Countermeasures Knowledgebase (PR3TACK) is an ATT&CK-style lexicon of tactics and techniques that highlight theoretical or “hard to observe” attacks. It’s a bit hard to understand at first, but once you dig into their matrix, there are some interesting entries. For example, the following collection technique:

There is malware that abuses clipboard content theft, so it makes sense that operating systems have mechanisms to cache history in some fashion. Each technique has a preemptive defense section, and in this case, it states there is no effective way to detect this type of attack due to a lack of telemetry.

It also introduces eight unique tactics that “extend beyond traditional technical compromise into governance, cognition, and sociotechnical domains.” There are supposedly longer descriptions for each one, but it either seems like the website doesn’t have a page to navigate to or my Brave browser is broken :3.

☣️ Threat Landscape

Axios Post Mortem by Jason Saayman

The owner and victim of the Axios supply chain attack last week published a great post-mortem on GitHub issues. Not much new information was shared, but you can tell they took the attack seriously and were an unfortunate victim to a convincing social engineering attack likely led by DPRK operators. They could have taken some steps to prevent this from happening, such as:

• Removing long-lived tokens for publishing out-of-band versions

• OIDC-style publishing to issue short-lived tokens and force releases through GitHub

• Immutable-builds: this can mean many different things, but pinning to a specific version of axios that uses bundleDependencies, for example, can prevent consumers of axios from pulling in updated malicious versions

Even if Axios hardened their build pipeline with the above bullets, th

Attackers Are Hunting High-Impact Node.js Maintainers in a Coordinated Social Engineering Campaign by Sarah Gooding

Following the Axios breach and the subsequent post-mortem above, Socket.dev researcher Gooding collected several notable open-source maintainer posts about how they were contacted by the same threat actors in the same campaign. It’s good to see the openness of many of these maintainers to share their stories. It brings transparency to the situation and a sense of community that they are all in this together. It’s bad to see how wide DPRK cast their nets and have succeeded with at least one victim.

These developers are all self-selecting, meaning many more likely got these phishing emails and Slack invites. I’m unsure if there were any more victims, but I wouldn’t be surprised.

I have to apologize to you all. I listened to lots of podcasts on a long drive over the weekend, and this one stuck with me in particular because of its coverage of the war in Iran. The U.S. military industrial complex has warned of a “Cyber 9/11” event since I’ve been in the industry. The idea is a thought exercise in which a single cybersecurity breach or attack can trigger massive kinetic effects without a nation-state ever leaving its computer screens.

It’s a term that’s been made fun of relentlessly. Nation-states have effectively used these capabilities as spying tools, which they are very good at doing. But, starting with the Russia-Ukraine war, we’ve seen attacks mounted that have crossed that threshold. In Iran, there have been reports of Iranian actors using compromised devices to perform Battle Damage Assessments, as well as using them for targeting for a strike.

This is where I see security being relevant in a more modern environment. The grugq and Tom Uren have an excellent conversation in this podcast on everything from cyber 9/11 doomers to the effective use of cybersecurity as an intelligence weapon in lieu of boots-on-the-ground collection activities.

Germany Doxes “UNKN,” Head of RU Ransomware Gangs REvil, GandCrab by Brian Krebs

I haven’t heard the words UNKN, REvil or GandCrab in many years! The wheels of justice grind slowly but grind fine, and it looks like German authorities are joining the fray, along with UNKN and co-conspirators. For those unfamiliar with REvil, it was the O.G. ransomware gang that moved the cybercrime industry from small-scale attacks for a few hundred to a few thousand dollars to a cartel-like operation that claimed to extort over two billion dollars.

🔗 Open Source

Blevene/structured-analysis-skill

Claude plugin for performing structured analysis techniques used by organizations like the CIA and the U.S. intelligence community. This is super useful for people using Claude Code as a threat intelligence research aid. You can instruct your session to use the plugin or skills for everything from attribution and intelligence writing to malware analysis.

Maybe I’m an intel nerd, but I do think a lot of people or companies who write blog posts on threat research could use a toolset like this as a gut check before they start throwing out wild claims to grab attention.

wiz-sec-public/SITF

Wiz’s repository for their SITF supply chain site is listed above in State of the Art.

elastic/supply-chain-monitor

With all the OSS supply chain attacks happening, I think it’s important for security engineers to become more knowledgeable about the OSS ecosystem. For example, how are new packages published or updated, and where can you get better visibility in the upstream publishing process and into how your organization consumes these packages?

The Elastic Security team made that a little easier with a fully packaged open-source tool that monitors PyPI and npm for new packages and package diffs. It normalizes them and feeds them into a Claude prompt for analysis and subsequent alerting.

ironsh/iron-proxy

To continue the supply chain security awareness story, iron-proxy helps prevent data exfiltration or command and control call-outs by injecting a workload on top of your CI/CD pipeline to do network monitoring and egress blocking. It specifies that it can be used for any workload, so theoretically you can run this on top of a developer container or a cloud machine, but IMHO it should shine in test runners within CI/CD pipelines.

HaxL0p4/L0p4Map

L0p4Map is a network scanning tool with a quite stunning front end. I think something like this would be useful in your network, where it can scan for devices, fingerprint them, and perform basic vulnerability scanning to help you understand how an attacker might probe your network for lateral movement.

Welcome to Issue #150 of Detection Engineering Weekly!

✍️ Musings from the life of Zack:

• We completed a 5-hour back-and-forth car ride over the weekend with mostly chill kids, no car sickness, and even some napping. It doesn’t seem like much but it made the trip wayyy less stressful.

• I skipped last week to take some time off after RSA. Thank you to everyone who came up and said hello to me, as well as to those who hung out at the Detection & Response Happy Hour!

• I finally set up Claude to be an “executive assistant”. It’s been helpful to have it sift through email, Slack, and Calendars and give me the most important things up front. It did take some prompt tuning to separate what matters from what is noise, but I recommend setting this up for people who have a busy personal or work life.

Sponsor: Permiso Security

Every identity. Every environment. Know static posture and runtime behavior.

Attackers aren’t breaking in anymore. They’re logging in. And they’re not just targeting human accounts. Service accounts, OAuth tokens, and AI agents are just as exposed and far less monitored. Most detection tools weren’t built for that reality. Permiso was, which is why we won the 2026 SC Award for Best Threat Detection Technology. See how it works in our product tour.

Take the Tour

💎 Detection Engineering Gem 💎

Building a Firewall ...via Endpoint Security!? by Patrick Wardle

<rant>

Apple and lack of accessibility to secure telemetry: name a better duo. Jokes aside, I have such a love-hate relationship with Apple products. I use them for everything. The ecosystem is SO good. I can’t imagine not working on a MacBook, surfing the Internet, taking calls on an iPhone, or sporting around my AirPods Max. They integrate their technologies so well and make them easy to use across devices, and if my parents can figure out how to use them (sorry, Dad & my in-laws), then you know they do something right.

What infuriates me is how opaque they choose to make their devices to researchers, security tinkerers, and security teams at companies who pay Apple a lot of money. There are myriad nation-state threat actor cases in which a sophisticated exploit runs against an Apple device, and victims are unaware of what happened. In every case above, detection required either an external forensics lab (Citizen Lab, Amnesty Tech), corporate network monitoring catching anomalous traffic (Kaspersky), or a specialized third-party iOS monitoring tool (iVerify). Apple’s own platform produced no victim-facing signal.

</rant>

Luckily, we have the macOS researcher community, and Patrick Wardle is one of the lead researchers in this cause. Wardle routinely reverse-engineers macOS releases to discover new capabilities and features to share with the wider community. In this latest macOS 26.4 release, Apple’s built-in Endpoint Security product got some updates. This didn’t come with much (any) documentation, so Wardle built a harness to explore new data types within the framework and determine how to implement them. There were six new event types added with unhelpful names, such as ES_EVENT_TYPE_RESERVED_1

So, Wardle built a harness to subscribe to the Endpoint Security event stream and filter out the event types listed above. He sucessfully subscribed to 3-6, and had such a clever way to print the raw bytes from these subscribed events into essentially what is a hex dump. Instead of parsing each byte, he fed his methodology (plus the dumps) into Claude Code, and it found out they were network logs:

One thing I learned from Wardle is that these event logs send two events to a subscription: an AUTH and a NOTIFY event. The AUTH allows you to allow or deny the event. So, in this case, imagine cURLing a suspicious domain from a ClickFix attack and your Endpoint Security event software denies it. The NOTIFY event is for logging and might be useful for on-device correlated alerts in an EDR or for sending it to your SIEM.

I am really starting to enjoy the macOS detection & response capabilities coming out, and I am hopeful that the research from the small, tight-knit macOS security community can bring them to the masses.

🔬 State of the Art

The C2 Trap by James Rowell

Shiny object syndrome is a phenomenon I see a lot in security, and it can dangerously bias your work towards what is new and trendy. A classic example of this is a security operations team reading threat intel reports on nation-state activity and trying to write rules to catch the latest TTPs. What they may not realize, for example, is that this nation-state targets technologies that the team rarely uses, or they don’t fit into the threat actor’s target set due to their size or industry. We love our shiny objects!

In this post, Rowell describes how detection engineers can fall victim to this syndrome by targeting the wrong parts of the MITRE ATT&CK chain. One of my favorite quotes they use here:

The first mistake that teams make is to treat C2 and exfiltration as if they are specific behaviours. They are not. They are outcomes.

This is super concise for a number of reasons that Rowell points out. First, the “outcomes” portion of this quote means you can’t stop exfiltration without understanding the underlying behaviors. It begs the question: when an actor successfully exfiltrates data from your environment, how did they do it? Was it uploading to a cloud service, a good old-fashioned SSH session, or perhaps emailing a large zip file to their inboxes?

Rowell challenges readers to move to the left of exfiltration if you have to start somewhere. A lot of things have to go right for the attacker in order to get to this stage. So, focusing on behavior chokepoints in persistence, privilege escalation, and lateral movement can meaningfully reduce the complexity of your rule backlog. It’s also likely that you have a limited set of attack paths for data exfiltration, whereas there are many ways to exfiltrate data, as I stated above.

Detection via Deception — Using your SIEM as a Free Deception Platform by Regan Carey

Honeytokens are widely regarded as a low-cost, effective detection tool for identifying threat actors targeting your environment. Thinkst Canary is the prime example of a company that creates this technology, and you can use their canaries for free across a variety of technologies. In fact, it’s a great learning experience for those building detection labs or securing their home networks to deploy these and watch threat actors try to use them, especially if you intentionally expose them.

In this post, Carey does a great job of framing some of the issues people have with deploying canarytokens and calls out some misconceptions behind deception-based alerting and honeytokens. First, the technological barrier to using honeytokens isn’t low, so you just have to find a way to deploy them and send any corresponding alerts. Second, people may believe that their environment isn’t complex enough to warrant using honeytokens, when in fact they may be better for small organizations and environments due to the cost of entry for security products.

They round out the post with an example of using MITRE Engage to deploy and monitor honeytokens leveraging native Azure, Sentinel, and KQL functionality.

macOS EDR Telemetry: A Structured Framework for Evaluating Endpoint Visibility by Kostas Tsialemis

I first covered Kostas’ EDR Telemetry Project in October 2024, and it’s grown so much since then! The project provides a framework for benchmarking the detection & response capabilities of various EDR vendors across Linux and Windows. With this release, the team added a macOS benchmark. The framework comprises 16 categories and 58 subcategories across 8 EDR projects.

I’m glad to see them tackle macOS: infostealers have been a popular target for cybercriminals. Apple built Endpoint Security (ES) for security vendors to subscribe to, similar to Windows ETW or eBPF on Linux. The issue with ES is it’s super noisy, and because it’s not technically an inline hook, there’s not the same level of inline blocking as you’ll see on Windows and Linux. They released a companion query-generation tool that people can run while comparing their EDRs or security tooling against the framework.

SecCompare by Mark Manning

Long time friend of the newsletter, Mark Manning, is one of the leading researchers in container and Kubernetes security. He recently gave a talk at BSidesSF that surveyed various Linux security guardrail tools and their corresponding threat models. Within the talk, he showed his tool, SecCompare, which helps people understand SeccompBPF filters, and compare and contrast expected behavior from filters you generate versus baselines. These can get tricky as there are peculiar attack paths among many different Linux syscalls that can bypass a seccomp filter without you realizing it.

He’s got a sick Linux syscall table lookup with information on each syscall as well as labels around how you can abuse them. The interactive “how do containers work” demo is sick, too.

Slightly safer vibecoding by adopting old hacker habits by Halvar Flake

Vulnerability Research GOAT Halvar Flake released a timely post on his setup for coding in the wake of all of the TeamPCP supply chain attacks over the last few weeks. It’s a short but sweet post that starts to bring up “old” ways of doing things I learned when I first started in security. A basic setup involving a rented server, SSH, and a clear separation between your physical computer and your coding machine seems secure because you don't have any personal information, keys, or crypto wallets on the rented server.

I’ve been thinking a lot about old concepts from 14-15 years ago. We have been in container nirvana for the last 8 years or so, and the security boundaries are hard to nail as you begin to develop more and more in them. You load keys inside containers, push them to remote registries, and build them alongside your code. Each step of the deployment pipeline becomes an attack vector, and people aren’t paying attention to the endpoints writing this code, which are also part of the pipeline.

I can’t wait for Vagrant to come back, as it was my favorite tool for years and years, and virtual machines are way more “secure” by default. Now it’ll just be containers inside a local VM 😂.

Sponsor: Blu Raven Academy

Threat Hunting + Detection Engineering, Powered by Advanced Analytics

Master practical threat hunting and detection engineering through hands-on training with advanced analytics, real-world scenarios, and exercises designed for defenders who want skills they can apply immediately.

Start Learning

☣️ Threat Landscape

Emerging Threat: The Open Source Supply Chain Ecosystem is Front and Center

I take one week off from writing this newsletter, and now the software supply chain is on fire! I am linking posts to several compromises over the last 2 weeks that fall into two buckets: Axios & Nation-State Activity and TeamPCP & Cybercriminal Activity. This is becoming more significant from a detection perspective because the expertise required to understand how threat actors carry out these attacks is becoming more prevalent in our detection & response community.

The other component to call out is that the impact of these attacks extends beyond cryptominers; they can serve as primary, secondary, and tertiary initial access vectors as the bad guys work through the exfiltrated code, secrets, and infections sourced from these compromises.

I am linking two stories from $DAYJOB, so full disclosure, they are my colleagues and excellent researchers.

Compromised axios npm package delivers cross-platform RAT by Christophe Tafani-Dereeper

The first set of news, as of me writing this (Mar 31), is that the very popular Axios library for JavaScript was compromised. Axios has over 3 million weekly downloads, and these downloads range from individual developer laptops, CI/CD systems, and production environments. The threat actor compromised the owner’s account and inserted a backdoor in the dependency list. This malware had payloads for macOS, Windows & Linux. Two versions of the compromised package were released using the NPM publishing token and were exposed for around 4 hours.

Christophe’s analysis and timeline are excellent here. He covers each payload and the second-stage RAT, and also notes that this attack didn’t necessarily work in many environments due to errors in the initial loader logic.

Inside the Axios supply chain compromise - one RAT to rule them all by Ruben Groenewoud, Samir Bousseaden, Salim Bitam, Joe Desimone, Colson Wilhoit & Andrew Pease

This post from the Elastic Security Research team helps shed light on the malware payloads in the second stage of the Axios attack. They said that the RAT dropped on this stage shares a “significant overlap” with WAVESHAPER, a malware family tracked by Mandiant that is connected to a DPRK-linked threat cluster. I thought this was a helpful table to show the details of this campaign compared to WAVESHAPER data:

LiteLLM and Telnyx compromised on PyPI: Tracing the TeamPCP supply chain campaign by Nick Frichette, Sebastian Obregoso, Christophe Tafani-Dereeper & Emile Spir

The fallout from the Trivy compromise led to several package compromises, and LiteLLM & Telnyx were among the bigger ones.

The timeline above helps explain my take at the start of this section, a round primary, secondary, and tertiary compromises. Specifically, look at the BACKDOORED sections of each box. Given the many integration points in a CI/CD pipeline, rotating one credential doesn’t imply that another access point could provide a backdoor.

TeamPCP Supply Chain Campaign by Rami McCarthy

There has been some amazing research on this campaign by several researchers and vendors, and Rami led the way throughout. If you need a quick reference blog that’s easy to navigate, he built a beautiful website outlining the campaign so you can do just that. There are references to the timeline itself, IOCs, the payloads, unanswered questions, myths, and a nice playlist with songs for each part of the compromise!

🔗 Open Source

agentshield-ai/sigma-ai

Sigma ruleset for detecting malicious activity within agent behavior. It’s more of a pure detection-and-alerting toolset than an EDR, compared to some of the “Agent EDRs” I’ve linked in the newsletter. It’s listing 42 different Sigma rules, which is an impressive set for agent threat activity.

cisco-ai-defense/defenseclaw

OpenClaw plugin that provides an AI gateway and several governance functions to help secure your OpenClaw deployment. What’s cool is that it hooks OpenClaw to scan every skill, MCP servers, and plugins before they are installed and used by the agent. It also has some code security scanning capabilities, as well as run-time monitoring through the gateway.

awslabs/threat-modeling-mcp-server

Locally-run MCP server that provides threat modeling capabilities and tool calls. It uses the STRIDE framework to contextualize the application or code you are modeling and attempts to learn the application's business context before providing recommendations.

alicankiraz1/Codex-Sentinel

Yet another awesome-* repo for skills on Codex. It’s similar to the threat-modeling MCP server above, but primarily relies on skills to help shape secure-by-design coding practices and inject security tests into code artifacts.

Welcome to Issue #149 of Detection Engineering Weekly!

For folks who haven’t checked the site in the last week, I’ve updated the theme of this newsletter as part of a brand uplift project. I am so impressed with how this went: everything from the color scheme, typography, logos, and wordmarks gives me a lot of flexibility to give you all the content in different flavors. My hope was to make this more of a professional theme while still capturing the essence of what this newsletter aims to bring you: unfiltered information from a practitioner in the field.

✍️ Musings from the life of Zack:

• T-minus 3 days until BSides SF! I will see you all there, and I think I’ll have stickers and t-shirts ready to give out :D

• I’m starting to see the sun after work, and I cannot begin to describe how much better evenings are when you don’t have to leave work into darkness

• I recently pulled apart a phishing kit with Claude, and developed a skill to help me reverse engineer it, look for vulnerabilities, and build a lab environment for live interaction. Within an hour, I had about a week’s worth of analysis, vuln research, and lab environment completed. I really wish I had this at my last job!

Sponsor: Push Security

Learn how browser-based attacks have evolved — get the 2026 report

Most breaches today start with an attacker targeting cloud and SaaS apps directly over the internet. In most cases, there’s no malware or exploits. Attackers are abusing legitimate functionality, dumping sensitive data, and holding companies to ransom. This is now the standard playbook.

The common thread? It’s all happening in the browser.

Get the latest report from Push Security to understand how browser-based attacks work, and where they’ve been used in the wild.

Get Your Copy

💎 Detection Engineering Gem 💎

Pattern Detection and Correlation in JSON Logs by Mostafa Moradian

Similar to research I published last week, this post follows a theme I’m seeing a lot more of in the detection engineering space: detection engineers can gain a much deeper understanding of log and alerting pipelines technologies by implementing their own inside a programming language. In this post, Moradian built an impressive Rust-based JSON parser and rule-matching binary called RSigma. It works by ingesting JSON logs and a Sigma rule, building a structured abstract syntax tree, and evaluating the rule against the log to generate an alert. This seems straightforward, but the Sigma specification has evolved over the years into a robust domain-specific language, so Moradian had their work cut out for them.

For those unfamiliar with Sigma, I definitely recommend checking out the About section on their website, because it’s almost exclusively the de facto standard for rule languages, much like MITRE ATT&CK serves as the community-approved lexicon for understanding tactics, techniques, and procedures. Let’s take a small rule example from Moradian, and I’ll try to work through RSigma’s processing pipeline so you can understand just how hard it is to build a tool like this.

This rule detects base64 decoding on the command line. This is especially relevant for malware execution, as base64 is an obfuscation pattern used by malware, and it travels more easily over the wire because it preserves structures like newlines, tabs, and spaces. The rule starts on Line 16: a “selection” looks at a log file, and it uses the Image field to detect any process that endswith /base64, and it looks for a -d flag on the CommandLine which indicates decoding base64 text.

To replicate this selection and alerting functionality in a SIEM, you need one of two things: a translation layer to a SIEM domain-specific language, such as Splunk’s SPL, or a technology that uses Sigma natively to parse both the log and the rule and create a match. RSigma is the latter. There are two types of language formats it must parse: YAML (the Sigma Rule) and JSON (the log file format)

• First, it parses Sigma rules written in YAML and verifies that they match the Sigma specification. This includes processing everything you see in the image above, plus up to 30 modifiers, that allow the |endswith and |contains matching on lines 18 and 19, conditional logic such as “and”, “or”, “not”, and correlation and filter capabilities. Pipelines are also complex because they handle JSON field remappings to ensure your selection fields are agnostic across several file formats. This is a diligent practice due to the arbitrary nature of YAML structures

• Both YAML and JSON are file formats that contain arbitrary structures, and JSON, for the most part, serves as the de-facto format for log telemetry. The evaluation step takes the ASTs generated by parsing the Sigma rule and attempts to match them against target logs. This can be one many or 1000s.

I really appreciated this post because it transparently showed the architectural decisions behind the implementation of detection-matching technology. RSigma is essentially a SIEM. Although it’s not meant to be used for streaming logs, much like you can see in Splunk or Elastic, you can run it on the command line to perform detection research. It also looks like a lightweight binary that lets you do quick-and-dirty Sigma matching on a target system if you are doing any type of forensics work.

🔬 State of the Art

Splunk Botsv3 Benchmark Against Foundational Models by DefenseBench

Benchmarking is an important practice for evaluating LLMs using widely accepted tests and datasets to measure their performance. For example, if you look at Claude’s Opus 4.6 announcement, you can see how the foundational model measured against several thirteen benchmarks, ranging from coding to financial data analysis and visual reasoning. In practice, this allows foundational labs like OpenAI and Anthropic to publish performance comparisons between their models.

Some of these benchmarks may relate to security, especially in problem-solving and agentic coding, but they aren’t pure security tests. This is where more research is emerging from the security community on how these foundational models perform on well-known datasets to test their out-of-the-box efficacy.

Splunk’s Botsv3 dataset is an excellent choice here, and DefenseBench published its first benchmarking test using Botsv3. This site is cool in the sense that you can click into each agent in their leaderboard, and view the conversations as ASCIIcast recordings:

The above is Opus 4.6, who beat out Codex Gpt 5.2 & 5.3 pretty handedly. DefenseBench shared their agent prompt as well, so you can go replicate this on your own, or with foundational models outside the Anthropic and OpenAI space.

## DefenseBench Rule

You are an AI SOC analyst competing in an investigation race.

### Objective
Answer as many referee questions as correctly and quickly as possible.

### Referee API
- Get questions: `curl {referee_url}/questions`
- Get your progress/state (use this on every restart): `curl {referee_url}/me`
- Submit answer:
curl -X POST {referee_url}/answer \ -H “Content-Type: application/json” \ -d ‘{”question_id”:”Q1”,”answer”:”your answer”}’
- Buy hint:
curl -X POST {referee_url}/hint \ -H “Content-Type: application/json” \ -d ‘{”question_id”:”Q1”,”hint_id”:”1”}’
- Round status: `curl {referee_url}/status`
- Scoreboard: `curl {referee_url}/scoreboard`

### Restart-Safe Workflow (Important)
- On every start or restart, call `curl {referee_url}/me` and use it to decide what to do next.
- Never answer a question listed in `solved_question_ids`.
- Prefer questions where `question_state[Q].active_now=true` and `question_state[Q].solved_by_me=false`.
- After `POST /answer`, check `result_code`:
- `correct_awarded`: scored; move on.
- `correct_no_credit_already_solved` / `incorrect_no_penalty_already_solved`: you already solved it; do not retry.
- `correct_no_credit_out_of_window`: correct but not scorable right now; pick a different active question.
- `incorrect_penalized`: wrong; decide if you should buy a hint or switch questions.

### Splunk Access
- URL: `{splunk_url}`
- Username: `{splunk_user}`
- Password: `{splunk_password}`
- Suggested CLI query path:
curl -k -u “{splunk_user}:{splunk_password}” \ “{splunk_url}/services/search/jobs/export” \ -d search=’search index={splunk_index} | head 20’ \ -d output_mode=json


### Scoring
- Correct in time window: base points + speed bonus.
- Incorrect answer: penalty.
- Hint purchase: hint cost penalty.

Focus on high-confidence, fast, reproducible answers.

Building a Cloud-Native Detection Engineering Lab with Terraform and AWS by Rafael Martinez

I remember when I first was studying cybersecurity, the only way I could build labs was through Virtual Machines. This was fun for several reasons: you can see all of your operating systems in one program (vSphere anyone?), switch between them easily, and blow them up with malware or misconfigurations and reset them. But there was a limit: if you added too many machines, or required a complicated lab setup with many different components, you started to see your attention to detail fail to maintain the setup.

This all changed when AWS and technologies became the mainstay for engineering and security teams. So, reading this post by Martinez about moving a virtualized detection engineering environment to a cloud-native lab helped me remember the pain I felt in the late 2000s. Martinez set up an environment where Kali was ran as an attacker emulation box against a Windows machine, and Windows logged telemetry data to a local ELK stack.

The simplicity of the cloud-migration solution using Terraform was clearly described and easy to follow. I think anyone who is trying to build their own lab environments for detection should go through this exercise, because its not just architectural decisions you need to make, but also security decisions and understanding the threat model behind AWS.

Move and Countermove: Game Theory Aspects of Detection Engineering by Daniel Koifman

This is detection engineering’s uncomfortable truth: you’re not building static defenses against fixed attack patterns. You’re playing a dynamic adversarial game where both sides continuously adapt to each other’s moves. - Daniel Koifman

This is the first post I’ve read in the detection engineering space that uniquely outlines the challenges of attackers shifting the goalposts as they learn new techniques or discover new attack surfaces. This is the nature of security operations: you have a motivated adversary, be it a criminal or a nation-state, who has an agenda they can execute from the comfort of their computer chair. Since the physical stakes are theoretically low (granted, they aren’t indicted), they can spend a lot more time working on ways to circumvent defenses.

To help describe the concept better than I ever could, Koifman aptly applies the lens of Game Theory over these games of cat & mouse. He outlines some of the realities of detection writing, where a detection engineer develops a detection methodology to hunt for something like PowerShell usage, but the attacker quickly pivots and finds a way around it to issue malicious PowerShell.

Towards the end, he talks about one of my favorite concepts in Game Theory: Nash Equilibrium. The ideal state for a Nash Equilibrium is where no massive change in strategy between two players fundamentally improves their advantage. He outlines two examples, False Positive Equilibrium and Sophistication Equilibrium.

• The former describes a state where analysts accept some level of False Positives because a False Negative is too costly, and threat actors accept some level of detection because developing new methodologies is too costly

• The latter plays on False Positives in the form of cost. Burning zero-days can be costly because you incur massive amounts of waste if they are found and subsequently patched. On the other hand, using noisy techniques in a victim environment can easily ruin your intrusion due to the sophistication of catching the attacks. The equilibrium is in the middle for attackers, and defenders also prefer this as they hedge “towards the middle” of the sophistication spectrum

Detecting.cloud by Omar Haggag

Detecting.cloud is a comprehensive research database that aggregates cloud attack paths and detection rules into a single central platform. You can search for attack paths, such as privilege escalation, and it provides everything from descriptions to example rules written in Sigma, Splunk, Athena, CloudWatch, and EventBridge. It’s all AWS-based, but it’s an impressive feat given that Haggag is an undergraduate student (I know this because he posted it on the Cloud Security Slack!). It has some other cool features, including a CloudTrail analyzer, Attack Simulator, and even a way to contribute community rules.

Securing our codebase with autonomous agents by Travis McPeak

For those working in pure security engineering roles, the explosion of developer-focused AI tools and the subsequent developer velocity has made our work cut out for us. Besides the increasing attack surface from malicious skills and ClickFix malware payloads delivered via AI Tooling ads, the sheer amount of code being pushed by developers means more vulnerabilities and more time spent in security tools to ensure they don’t make it into the product.

In this post, McPeak showcases how Cursor is solving this using its autonomous agent framework, Cursor Automations. The thing I’m learning the most about security in the modern age is that security people rarely go as fast as developers. McPeak and the team at Cursor are closing the gap on this race by leveraging several Cursor Agents that do everything from vulnerability review, version bumpings, and a compliance drift mapper. Almost all of their findings are pushed to Slack for every Cursor engineer to see, and they take this even further by leveraging agents to fix the issues they find.

☣️ Threat Landscape

⚕️ Emerging Threat: Handala Attack on Stryker Medical Device & Equipment Company

The big story over the last week has been the Stryker ransomware attack. This happened right around the release of my last issue, so it’s been helpful for me to read more about this attack as news came out over the last 7 days. I’ve listed 4 stories: the 8-K filing from Stryker disclosing to the SEC that it suffered a cyberattack, Kim Zetter’s excellent article on the background of the attack, and more technical articles from Checkpoint Research and Palo Alto Networks’ Unit 42.

Stryker 8-K Filing from Ransomware Attack

For those unfamiliar with 8-K filings, they are reports that public companies must issue to shareholders and the public when the company has material information about its operations to disclose. The reasons vary, and there’s a guidance that the SEC issues to help direct companies, and there is a whole document related to cybersecurity:

In this case, Stryker disclosed an 8-K detailing a cybersecurity incident affecting its Microsoft environments, which is causing a material impact on its ability to function as a company.

Iranian Hacktivists Strike Medical Device Maker Stryker in "Severe" Attack that Wiped Systems by Kim Zetter

Zetter helped break the news of the Stryker breach and pointed out that it was linked to an Iranian hacktivist group called “Handala.” This group claimed this was in response to the ongoing U.S. attacks against Iran. Stryker is a multinational corporation, so Handala targeted its Microsoft Intune deployment and removed employees' ability to log in to their systems, bringing operations to a halt. This allegedly affected over 200,000 systems, and the group also claimed to have exfiltrated over 50 TB of sensitive data.

Zetter quoted several Reddit posts of users purported to work at Stryker, and I thought this was the most interesting quote she pulled forward:

According to the person who posted this message, the hackers gained access to administrator accounts and put “their signature Handala artwork on every login page.” They also sent emails to a number of company executives taking ownership of the cyberattack.

I’m unsure what this attack can specifically help with in the war, beyond drawing attention to it and serving as a demonstration of force. Nonetheless, it does have everyone talking more about the war, including me.

“Handala Hack” – Unveiling Group’s Modus Operandi by Checkpoint Research

CheckPoint Research’s post on Handala Hack, the full name of the Iranian hacktivist group, outlines their history, TTPs, and motivations in more technical detail. Although claiming to be a hacktivist group, CheckPoint Research clusters their activity to Iran’s Ministry of Intelligence Service (MOIS). Their TTPs revolve around initial access via criminal forums and infostealer marketplaces. Once they land on a victim environment, they use living-off-the-land tools and techniques to steal passwords and eventually laterally move to administrator accounts.

Much like the Stryker attack, they conduct data exfiltration and wiper attacks, accompanied by propaganda images depicting their Handala persona. The clustering element CheckPoint disclosed is interesting:

Homeland Justice/KarmaBelow80 are associated with Handala, and Checkpoint alleges that internal intelligence (Void Manticore) and counter-terrorist units (Scarred Manticore) provide access and TTPs to Handala to carry out their operations.

Insights: Increased Risk of Wiper Attacks by Andy Piazza, Eric Goldstrom & Steve Elovitz

Unit42’s insights on the attack align with CheckPoint Research's clustering, which shows overlaps with Void Manticore and identifies Handala Hack as a front of Iran’s MOIS division. They provide a great hardening guide to help eliminate some of the TTPs used by Handala Hack, with much of the hardening focused on identity and access management. The two I wanted to call out are around eliminating long-lived accounts, especially Administrator accounts that Handala likes to abuse, and using just-in-time access for logging and approval workflows.

As with most AD-style attacks, they recommend hardening Entra ID, which, in turn, can help deploy wipers via Intune, as happened at Stryker. I’ve seen a lot more of a push from IR firms like Palo Alto Networks, where they push the community to remove local Administrator accounts altogether.

🔗 Open Source

elastic/agent-skills

Yet another agent skills library, this time from the folks at Elastic. They split each skills group into cloud, Elasticsearch, Kibana, observability, and security. Their detection rule agent skill, for example, has a rule-tuning workflow that uses internal scripts within the skill to identify and fix noisy rules.

nikaiw/VMkatz

VMkatz is a credential-harvesting tool that specifically targets virtual machines containing Windows credentials from VM snapshots & virtual disks. The idea here is that an attacker would land in an environment where these VMs contain the credentials they need to escalate privileges or laterally move, but the disks are so large that it would take forever to copy them off, or worse, you risk detection.

Running this binary on a target environment helps relieve this burden by performing the extraction directly on the box.

BaddKharma/redStack

redStack is a full-stack lab environment for folks to learn how to use post-exploitation tools on a victim environment without worrying about infrastructure configuration. It has an impressive architecture and it’s all hosted on AWS. The README is succinct and contains step-by-step instructions for deploying three post-exploitation tools and using Apache redirectors to navigate to specific C2 tools.

Gk0Wk/ClawGuard

OpenClaw plugin that acts as an endpoint security tool or firewall for AI. It has a demo of three security controls: blocking risky actions or skills, minimizing risky filesystem access, and limiting outbound communication. It’s cool to see projects like this spring up because you start to get a sense of where security technology is going, and can expect products to emerge that can solve this for businesses.

backbay-labs/hush

Hush is a policy spec for writing rules and checks to implement inside AI security controls. This spec reminds me a lot of OPA, but instead of returning pass/fail, you translate YAML rules into enforcement controls.

Welcome to Issue #148 of Detection Engineering Weekly!

✍️ Musings from the life of Zack:

• I have some exciting news! In about a week, you’ll see some new branding for Detection Engineering Weekly. This will be the second brand uplift of the newsletter, and I can’t wait to don the new colors and logo. It’s more professional and understated, and it captures much of the energy of what I think this newsletter brings to your inboxes. I’ll be handing out stickers and potentially some t-shirts at BSidesSF in a few weeks!

• Speaking of BSidesSF, I’m interested in how many of you are going to be there. I am organizing a happy hour and doing a sticker order, so please vote Yes here, ping me, or honestly just find me in the hallway (I’ll be shilling the newsletter with tshirts) and say hello!

Sponsor: Spectrum Security

Detection is Broken.

Measuring coverage means wrangling spreadsheets, BAS tools, and weeks of manual work. By the time you finish, the data is out of date.

But finding blind spots is only half the battle. There’s never enough time to close them. You’re on an endless treadmill: writing new rules, fixing broken ones, and tuning out noise.

We built the end of the manual grind.

Get an early look at the AI platform transforming how teams identify, build, & deploy detections

Try It Now

💎 Detection Engineering Gem 💎

Detection Pipeline Maturity Model by Scott Plastine

I’m a huge fan of maturity models, and in the early days of my writing, I frequently referenced the work of Haider Dost and Kyle Bailey when discussing the maturity of detection engineering programs. As this space matured, technology matured with it, and we now have complex systems within each part of the Detection Engineering Lifecycle. So, to me, it makes sense that we now have folks like Plastine helping us understand what it means to measure the maturity of a Detection Pipeline.

Plastine outlines six different levels of maturity, starting with a classic favorite, no maturity! This involves having a security tool stack with no centralization, and analysts have dozens to hundreds of Google Chrome tabs open which gives me anxiety. The fundamental issues Plastine outlines and continues to improve here include:

• Several security tools with their own alerting and detection systems

• The need to log into and investigate each alert on each individual tool, so managing screen sprawl

• The analyst manually building cases in some case management or ticketing tool, such as JIRA or ServiceNow

The next maturity step, Basic, addresses some of these issues by essentially placing the Case Management tool between the tools and the analyst, rather than being out of band. As maturity levels progress, so does the architecture of this setup. For example, the “Standard+” architecture has a much saner pipeline setup:

The cool part at this point in the maturity journey is switching from architecture improvements to more advanced concepts in the analytics platform. Custom telemetry, log normalization, and a risk-based alerting engine ideally surface only relevant alerts and reduce false positives. Teams begin to build composite rules, leveraging commercial detections alongside their own internal detection and risk alerting systems, and they all take advantage of learning from their data to inform their rule sets, not just their environment.

This diagram drove it home for me, and became my favorite:

As you progress through maturity, the trap teams fall into is more rules is better. I think the measure of a Leading detection function is reducing rule count thereby reducing the complexity of managing rule sprawl.

Plastine posits that this can be achieved by using data-science-based rules, risk-based detection, and leveraging as much entity-based correlation as possible.

🔬 State of the Art

Whose endpoint is this… kali?! by Alex Teixeira

I love reading Alex’s detection and hunting blogs because he always stuffs a ton of knowledge around query optimization and hunting. When you manage massive amounts of data in a SIEM, especially Splunk, you need to query it in a way that doesn’t cause a ton of load on the system. This is especially helpful when you are researching new detection rules.

In this post, Alex addresses query optimization and discovery for post-exploitation tools. I typically see a lot of teams worry, for good reason, about malware that is the beginning stages of a breach. Alex references loaders in this scenario: malware designed as an initial beachhead for infection, which is then upgraded into a more reliable malware tool. Cobalt Strike is a leading example, but there are hundreds at this point.

Post-exploitation tools are aptly named to help threat actors navigate the MITRE ATT&CK chain toward a specific objective, such as data exfiltration or ransomware. Persistence, lateral movement, and privilege escalation are all built-in to these types of tools. So if you assume these exist, how do you catch them?

His strategy is to “reduce the dataset” as you are hunting. Instead of performing blind searches over logs, you can first focus on terms within the index and the Windows sourcetype itself. So, he begins his hunt looking for the term kali in Windows Event Logs. This is because these tools can leak their internal hostnames, and finding kali in the hostname with some threat activity is a great hunting lead.

Through a combination of hostname detection and observing a network event with the same name, he narrows the dataset to a meaningful set of events to respond to an infection and write rules for afterward.

Tracking DPRK operator IPs over time by Kieran Miyamoto

Threat research is such a fun, dynamic field within security because it examines both the technical and human elements of threat actors. This post is Miyamoto's “Part 3” on tracking DPRK threat actors via OPSEC failures, and it’s brilliant in its simplicity. Basically, FAMOUS CHOLLIMA, which has Contagious Interview and some WageMole overlaps, uses email to maintain its personas, register accounts, and issue fake employment-scam communications. The technical elements of this are interesting because they try to deploy malware on victim machines or obtain legitimate jobs as fake IT workers.

The human element of this operation is that humans tend to optimize for reducing the time it takes to do their job as efficiently as possible. So, why would you go through a ton of work to get legitimate email inboxes like Gmail or Yahoo if you only need the email address to send scam messages or register an npm account to publish malware? Miyamoto found that this group had the same question, and answered it by using temporary email addresses.

The subsequent finding is that, as long as you know the email address, you can also view the inbox! Miyamoto started with malicious npm packages containing maintainer emails and began logging into DPRK-controlled temporary email accounts to glean additional intelligence, including source IP addresses and potential victim targets.

From GenAI to GenUI: Why Your AI CTI Agent Is Sh*T by Thomas Roccia

TIL there’s a concept called Generative UI, where agents decide how to render the UI in real time based on your queries. In this post, Roccia uses this concept to build out use cases for cyber threat intelligence analysis. The idea here is that visually representing threat intelligence can help a researcher understand the underlying data much better than blobs of text. Roccia argues that most CTI Agents focus on ingesting unstructured threat intelligence and producing large volumes of output tailored to your environment or prompt. This setup can be helpful to some, but adding a visual component to aid your understanding makes it more attractive.

Roccia outlines two GenUI styles: MCPUI and A2UI. Both focus on delivering a graphical representation of a prompt response. MCPUI returns dynamic elements from an MCP server in response to a prompt, but it’s mostly contained within a UI that the developer creates. A2UI takes it a step further by delivering the entire UI experience in a container, making the agent the arbiter of the experience.

Roccia’s A2UI implementation was more interesting to me from a detection standpoint because he built a log analyzer on top of a log stream. Each element is supposedly dynamic, and you can click into and investigate logs while allowing the A2UI protocol do its thing and present data and experiences to you, all driven by an agent. Here’s a demo video from his blog:

Wild times!

How we built high speed threat hunting for email security by Hugh Oh

I love it when security product companies show how they’ve engineered their product. In this post, Oh reveals how Sublime Security designed its massive email-detection and threat-hunting architecture. Their platform is built on MQL, their domain-specific language for rule writing and alerting. When you think about email as a telemetry source, there are some inherent issues you have to worry about unlike other sources:

• Unstructured body content, since, by design, it is human-generated and human-readable

• In Internet standards, email is a pretty ancient concept, so additional designs and RFCs were layered on top of it for decades, which can introduce some sharp edges

• Attachments, integrations and user-experience elements are a huge vector for abuse, so you need to be able to parse those

This is a security and engineering problem to parse at scale.

The Sublime product parses incoming emails into EML format and stores metadata in fast storage and the full contents in blob storage. They split email selection into several phases. Candidate selection focuses on fast metadata lookups; evaluation performs a deeper analysis to determine whether these candidates are truly worth a blob storage query; and, when the full email is retrieved, they can perform enrichments and ultimately decide whether to generate a result.

A Practical Blue Team Project: SSH Log Analysis with Python by Edson Encinas

This is a great introductory post on researching a singular log source, SSH authentication logs, and building a research plan to implement detection rules. I think sometimes people breaking into this industry want to jump right into a SIEM and write rules, which can take time, energy, and potentially cost a lot to set up, whereas in this post, Encinas leveraged Python. It’s a good learning exercise: you can see where Python excels at detection, especially in a risk-based alerting scenario.

The architecture for the SSH alerting pipeline includes parsing, normalization, rule writing, risk calculation, and de-duplication. Their GitHub project was pretty easy to follow alongside the blog. Again, demonstrating these concepts in pure Python can accelerate understanding more than setting up massive environments.

☣️ Threat Landscape

I’m glad to see more individual interviews from Ryan on the Three Buddy Problem podcast! In this “Security Conversations” segment, Ryan interviews threat-hunting and intelligence expert Greg Linares. Greg has all kinds of visibility working at an MDR and recently released a year-in-review report on some of the intrusions Huntress is seeing.

The most interesting sections for me were around the intersection of ransomware and nation-state threat actors, as well as the use of RMM tools and the complete lack of audit logging and visibility they provide defenders. Imagine onboarding any other critical IT tool, such as an Enterprise Email provider or a Cloud tool, and being told there will be little to no telemetry available to help you defend the application against a compromise. That’s RMM in a nutshell!

Investigating Suspected DPRK-Linked Crypto Intrusions by CTRL-Alt-Intel

I talk a lot about DPRK-related threat activity in this newsletter for several reasons. One, DPRK tends to focus on cloud technologies, and IMHO, they were way ahead of their other nation-state peers. Two, they are just so damn crafty and are willing to move fast and break things. Third, because of point two, they have a ton of OPSEC failures that lead to some hilarious findings

In this post, CTRL-Alt-Intel follows an intrusion by a DPRK actor who began with an Application exploit a la React2Shell, found AWS credentials, pivoted to AWS, and ultimately stole source code. The author says this focus was mostly on cryptocurrency companies, so if we believe this intrusion targeted one of those organizations, then the intelligence value for them would be discovering secrets and vulnerabilities in proprietary code for further attacks.

Uncovering agent logging gaps in Copilot Studio by Katie Knowles

~ Note, Datadog is my employer and Katie is my colleague / friend! ~

Microsoft Copilot Studio is Microsoft’s offering for creating and managing AI agents. During Katie’s previous research on how to abuse Copilot Studio for OAuth phishing, she found that Copilot wasn’t logging certain administrative actions. This is especially concerning if you rely on audit logs for threat detection. A victim agent could be abused to retrieve sensitive information from your organization and you’d have no visibility into the attack itself.

Katie provides excellent security recommendations towards the end, including identifying which M365 users are using Copilot, and what searches and rules you could write to detect anomalous activity in Copilot.

Inti De Ceukelaire

How I infiltrated phishing panels targeting European banks and tracked down their operators

I live in the most lucrative country for phishing scams in the EU. Every month, millions of euros are lost, and according to recent reporting, nearly two-thirds of complaints to banks are ignored…

Read more

4 months ago · 36 likes · 1 comment · Inti De Ceukelaire

This was a fun read for those who are interested in phishing-related threat research. Ceukelaire got a phishing text message, accessed the phishing page, and began poking holes in it. He found a vulnerability where he set the X-Forwarded-For header to a localhost address (Substack won’t let me publish it?) and it was an auto bypass of the administrator login panel.

From there, he started rendering the kit useless by removing its functionality and its ability to communicate with a Telegram-controlled channel. He was able to stop victim exfiltration and prevent further victims from visiting the website. Luckily, it was a poorly designed phishing kit, riddled with vulnerabilities, but not all kits are this insecure.

Clearing the Water: Unmasking an Attack Chain of MuddyWater by Harlan Carvey and Jamie Levy

In this post, Huntress researchers Carvey and Levy detailed findings related to what appears to be a hands-on-keyboard MuddyWater campaign targeting one of their customers. They first found intelligence from a Hunt.io report and worked backwards into their own customer reports. Some interesting findings they made include:

• Typos in the terminal commands MuddyWater ran, indicating an actor who was typing in real time during the intrusion

• Tradecraft learnings, such as opening PowerShell from the Explorer, making it seem like a more legitimate activity than running it from the commandline

• Troubleshooting in real-time by cURLing ifconfig.me to make sure they have Internet connectivity

It turns out that threat actors make mistakes too!

🔗 Open Source

killvxk/awesome-C2

Yet another awesome-* list of 300+ Command and Control frameworks. This is a fun list if you want to test adversary simulation in a lab environment, or statically analyze the post-exploitation code for detection opportunities.

edsonencinas/log-analyzer

Encina’s pure Python “SIEM” used in his SSH log analyzer blog post listed above in the State of the Art section. What’s nice about this is it reduces the complexity of standing up an environment, and instead you can focus on the concepts of detection in a contained programming language.

github/spec-kit

Not really detection related, but this was something my colleague Matt Muller sent me as I was vibecoding out a fully STIXv2 compliant Threat Intelligence Platform. Spec Kit is a framework for spec-driven development using agents. You create a constitution that sets guidelines for development principles. You then specify what you want to build, how you want to plan to build it with certain technologies, build a task list and then have the agent go to work.

I kept my speckit separate from my code, so my agent would read and update my local spec and then go into the target project directory for development.

m1k1o/neko

Self-hosted virtual browser using containers and WebRTC. These technologies are always super interesting from an OPSEC perspective, because you can literally embed a browser in a website that you host that also hosts neko. This makes it easy to make non-attributable and disposable infrastructure for things like threat intelligence research or for interacting with threat actor infrastructure.

anotherhadi/default-creds

Open-source database of default credentials across 100s of manufacturers. You can download this and take the credentials yourself, or run their self-contained web application, or just visit the hosted web application and find some hilarious default creds.

Welcome to Issue #147 of Detection Engineering Weekly!

✍️ Musings from the life of Zack:

• Sickness in the Allen household was rampant all last week until today. Fingers crossed that the family stays healthy because there is FINALLY some good weather in New England to look forward to

• I recently bought a history book about the Marquis de Lafayette. It’s been so nice to get away from technical books and even fantasy to enjoy some history. This guy was a baller and essentially helped overthrow two governments and turn them into democracies

• BSidesSF is getting closer and I’m getting more and more excited to enjoy a security conference and network. There’s a chance I’ll be bringing stickers :D

Sponsor: Cotool

Cotool Research: Benchmarking LLMs for Defensive Security

Most AI benchmarks skew toward offense, so we built our own grounded in real SecOps workflows to answer questions that matter in production:

• Which model should power your triage agent?

• What architectures hold up in complex investigations?

We believe those answers should be public, so we release every benchmark we create.

Explore the benchmarks

💎 Detection Engineering Gem 💎

You’re Probably Flying Blind by Lydia Graslie

The bane and boon of Cloud or SaaS technology is that it is managed by someone else. This business model has enabled some of the biggest businesses in the world worry about their core business, rather than building and maintaining bespoke software or procuring software that they must internally manage. “The olden days” involved running your own e-mail servers, databases, and Active Directory servers (though many folks still do this today). The problem, though, is that because it’s managed by someone else, you are at the whim of how they change the software, and the managed part becomes an operational risk if you don’t like that change.

Don’t worry, it gets worse for security teams. And Graslie’s blog helps frame this issue around security operations and detection rules. I’m glad she’s using Microsoft products as a grounding element for these issues because 1) they are fun to pick on and 2) they deserve every criticism due to their history of notorious licensing and product changes that lead to detection engineers “flying blind”.

Graslie lists out four intertwined issues with relying on SaaS and Cloud technologies for detection efficacy and here they are in my own words:

1. Detection availability and observability. Unlike a machine in your local network that you can walk over to and physically touch, you have to have awareness of the SaaS & cloud technologies, licenses and services that are in use. You have to hope that these products are functioning and sending the right logs and that there aren’t outages or delays in delivery

2. Multiple attack paths to the same outcome. Akin to how many Windows based attacks leverage intermediary or middleware APIs to prevent detection on certain attack paths, Cloud and SaaS attacks operate similarly. In fact, in many ways, they are their own operating systems, and achieving lateral movement or privilege escalation can happen in more than one way. Here’s a Mermaid Diagram I had Claude generate to demonstrate Graslie’s example of “same action, different telemetry paths” in this section:

1. In this Azure example, Graslie explains how authenticating to a single cloud resource can take these four paths. An interactive user seems like a logical detection path, but the other three listed afterward do the same thing, and the source authenticating identity type, the logs, and the schema are all different.

2. Shifting attack surfaces, new and deprecated features, and pricing are a detection nightmare. She lists out an absolutely ridiculous timeline of Microsoft releasing “at least seven Microsoft PowerShell modules and protocols for managing identity”. That’s seven different API collections you need to account for to prevent Issue 2 listed above.

3. Similar to 3, the detection and observability surface shifts. A good example of this is when a field or value format changes in a log source you are writing detections over. This happens all the time with audit logs from SaaS vendors. New subproducts can force vendors to change field names or add new values that you’ve never seen before.

Each one of these issues is “intertwined.” Graslie gives several examples of how they can compound in certain scenarios. For example, how can you understand your attack surface if you don’t have telemetry, or even worse, you aren’t even aware that a SaaS app exists in your environment? She concludes the post with a teaser for a series that examines each of these four issues, all grounded in Microsoft environments.

🔬 State of the Art

The Detection Engineering Baseline: Statistical Methods (Part 2) by Brandon Lyons

This is Brandon’s Part 2 continuation of his “Detection Engineering Baseline Series.” It has a more practical application to the data he generated in Part 1. The key skill here is distribution mapping, typically referred to in our statistics class as the normal distribution or the Bell curve. I believe a lot of SOC analysts and detection engineers perform many of the techniques Lyons’ describes here without knowing it. For example, Group-Bying a field then sorting from Lowest → Highest shows “rare events”. Another example Lyons calls out is filtering out the noisiest offenders, such as service accounts, to reduce 80% of the signal so you can hunt through the remaining 20% a la The Pareto Principle.

I especially appreciated the commentary on the distribution of security data in general, as illustrated here:

Unlike a normal Bell Curve, security data tends to have a long tail, according to Lyons. This makes baselining harder because you need to account for noisiness on both ends of the distribution in different ways. Lyons astutely points out that this is why typical mean and standard deviation calculations fall short of generating meaningful alerts here: a single shift in traffic, or a misconfiguration that throws off a ton of alerts, can completely screw up detection.

He then continues this analysis using Median Absolute Deviation (MAD) & modified Z-score, as explained in the first post, which helps maintain robustness in the case of wild value swings. The computation of MAD helps capture the position of a new value relative to a set of numbers, rather than its magnitude as it swings to either end of a distribution.

I took his example and wrote it out myself (with Claude helping with formatting) so I could understand it better:

What makes this robust or resilient is that you may get a swing in Daily Counts (Line 5), much like you see 620, but it doesn’t skew the mean, as you are still focusing only on the median.

Once you get the hang of this, there are still ways to slice and dice your data to get a representative sample. Lyons calls out entities as an option, or cohorting, which lets you reconcile traffic or behavior down to individual users, service accounts, or services themselves. These “context dimensions” are important because they only really work in your environment, and your team should know the context for baselining better than any other security product.

How Reddit Does Threat Detection by Austin Jackson

I love reading posts describing how organizations design and execute their Security Operations programs. In this post, Reddit Staff Engineer Austin Jackson describes the company’s philosophy and technology stack around threat detection. It’s a continuation of their rip-and-replace of Splunk post, which I need to check out, perhaps for another issue. Basically, the team moved to a Data Lake approach using Big Query, and they run Apache Airflow for detection rules and alerting. There are some neat detection-as-code tricks they did here, and because the system is a lot more decoupled than a massive Splunk stack, they’ve gained a few advantages.

First, all of their detections are written in a simple YAML format. The Airflow runner kicks off on cron jobs and runs queries over BigQuery to generate alerts. Once an alert fires, they send results to Tines for additional orchestration and enrichment. Jackson had a special callout about sliding-window detections and avoiding missed telemetry. In a recent newsletter issue, I analyzed a topic in which a researcher leveraged Watermarking to address SaaS export gaps, and the same concept applies here, where a Watermark is used in a separate table. The detection engineer appends a clause at the end of their query to use the Watermark timestamp to prevent telemetry loss.

Jackson finishes the post detailing their scoring workflows in Tines, and I thought the most unique part of this section was the AI Triage component. Rather than trying to run a singular agent across all of their telemetry, detection engineers can ship a prompt inside the rule for Tines to run over it for additional enrichment, analysis and scoring.

AWS Incident Response: IAM Containment That Survives Eventual Consistency by Eduard Agavriloae

Eventual consistency is a pattern in large-scale systems, like the AWS cloud, where a change in state isn’t instantaneous, and it will take time for the state to be replicated across all of the systems you are working with. This makes sense: imagine a massive AWS account with several sub-accounts and regions, and you need to push a change out to configurations or identity permissions. You should expect the change to take effect after you issue your configuration changes, but you may not know that it takes time for these changes to propagate.

In AWS security incident response, you may have to deal with this as you follow standard playbooks to isolate accounts or principals. According to Agavriloae, this eventual consistency pattern creates an opportunity for attackers to recognize that an isolation is in progress and, if they have the right permissions, revert the change before the state is locked in. AWS IAM is very hard to use because multiple escalation paths can lead to the same outcome, so creating mechanisms to guarantee isolation can miss certain attack paths.

Agavriloae provides a solution to this eventual consistency problem by leveraging Service Control Policies at the organizational level, where only break-glass IR roles can remove the quarantine policy.

👊 Quick Hits

Cyber Threat Intelligence Framework by CERT EU

I’ve always found it fascinating how CERT teams, especially those that protect countries or allies, publish their internal processes and frameworks for citizens to study. In this framework by CERT EU, they introduce the concepts of Malicious Activities of Interest (MAIs) and Ecosystems. MAIs, to me, read like “observables” in the STIX context. I think the more unique introduction, though, is the concept of Ecosystems. We tend to have CTI teams that look at the breadth of attacks against their organizations, and it’s easy for them to determine whether they were targeted.

Ecosystems, according to CERT EU, rely on the victimology or targeting set of an MAI. It’s almost like a self-organized ISAC for all of their constituencies. Because the EU is more than just a country, it can specifically dive into how MAIs target not only other Member states, but also things like Sectors, Events, and much more.

AWS Threat Detection with Stratus RedTeam Series — MITRE ATT&CK Style — Execution (Part 1) by Soumyanil Biswas

This is a great “detection lab” post that leverages my colleague Christophe Tafani Dereeper’s Stratus Red Team tool for threat emulation and detection validation in AWS. Biswas helps readers set up an AWS environment, configure the Stratus Red Team, configure data sources (CloudTrail), and eventually write a SQL and Sigma rule to catch each attack.

☣️ Threat Landscape

hackerbot-claw: An AI-Powered Bot Actively Exploiting GitHub Actions - Microsoft, DataDog, and CNCF Projects Hit So Far by Varun Sharma

The Step Security team found an OpenClaw security research agent actively trying to exploit CI/CD pipelines for popular open-source projects. OpenClaw is “fully autonomous”: it performs heartbeat checks every few hours and follows a prompt to perform an action. The bot’s instructions were hosted on GitHub, and Sharma managed to get a snapshot of it to perform an analysis, but it has now taken down. Here is the Step Security team’s explanation of the attack workflow:

Who is the Kimwolf Botmaster “Dort”? by Brian Krebs

This is a follow-up post to Krebs’s exposé of the Kimwolf botnet, which detailed how a botmaster named Dort built and ran the botnet. A security researcher exposed the botnet by disclosing a vulnerability that enabled Dort to take control of poorly configured devices on proxy networks. This significantly dropped Kimwolf’s numbers, so Dort began harassing Krebs and the researcher.

In classic Krebs fashion, he doxxed Dort and found everything from his name, former monikers, and even a computer that he shared with his mother. Towards the end of the article, Krebs gets on the phone with the alleged “Dort”, and the person on the phone denied any involvement and claimed their identity was impersonated.

Google API Keys Weren't Secrets. But then Gemini Changed the Rules. by Joe Leon

Google API Keys are provided to developers who want to embed certain Google products on their websites or in their applications. Google explicitly says these API keys are not secret, and it makes sense that they are not, because you typically see them in embedded Google Maps on sites. This changed with Google’s release of Gemini. The research team at Truffle Security discovered that you can leverage publicly facing API keys embedded in these applications to access Gemini functionality. This includes taking private datasets or LLM-jacking Gemini itself for whatever purpose you want.

Hook, line, and vault: A technical deep dive into the 1Phish kit by Martin McCloskey

~ Note, I work at Datadog and Martin is my colleague ~

Modern-day theft of secrets, passwords, and sessions typically relies on infostealer malware. It’s a quick way to infect a user, pilfer their environment, and extract credentials as fast as possible. It presupposes that these secrets exist on their laptop, and IMHO, it’s a subset of everything the victim has in their digital identity. If I were ever infected by one of these, I would be worried about my credentials, but I think I could rotate local secrets pretty quickly. But if someone got my 1Password account, that would be SO much more painful to reroll everything.

Martin discovered a 1Password phishing kit that targets users of the password manager. It evolved over his analysis timeline and graduated from a simple password stealer to one that can leverage AiTM style features, browser and researcher fingerprinting, and targeting specific geographic regions.

🔗 Open Source

sublime-security/ics-phishing-toolkit

Friends of the newsletter, Sublime Security, just released a phishing analysis toolkit to detect and respond to ICS Calendar phishing. It has integrations with Mimecast, Proofpoint, Google Workspace, M365 & Abnormal Security. The tool reviews emails with calendar invites across the different integrations and quarantines any that match ICS Phishing heuristics.

advaitpatel/DockSec

DockSec is an open-source Docker container vulnerability scanner. It combines several open-source tools to support vulnerability analysis and enrichment, then leverages AI to suggest remediation steps and generate reports.

Cloudgeni-ai/infrastructure-agents-guide

This is a comprehensive guide for infrastructure teams on how to securely build and implement AI Agents. It has 13 chapters in total and covers a range of topics, including sandboxing, version control, and observability.

knostic/OpenAnt

OpenAnt is an open-source LLM-based vulnerability scanner. It reminds me a bit of OpenAI’s Aardvark, but with a lot more open architecture for you to review and implement. It can run up to 6 stages for any vulnerability it finds, which is nice because it’s orchestrated to reduce cost and only spend time on a vulnerability if it’s legit.

Welcome to Issue #146 of Detection Engineering Weekly!

✍️ Musings from the life of Zack:

• New England has been a rough place to live, weather-wise, since the holidays. My family finally managed to get out of the house and into the snowy White Mountains in New Hampshire. I instantly felt relaxed as soon as we started the drive. I can’t touch grass right now, so I guess snow will do!

• For those with small children: hope you are all doing OK with sickness these last few months. We are hanging in there, but it’s been one thing after another :)

• My org at Datadog is hiring like crazy! Check these posts out and apply if it seems interesting to y’all!

  • Engineering Manager, CTI (US)

  • Senior Detection Engineer (Paris)

  • Engineering Manager, Trust & Safety/Platform Abuse (US)

Sponsor: Push Security

Has the news of malicious browser extension attacks got you on edge?

Malicious browser extensions have been one of the top attack vectors of 2026 so far. All an attacker has to do is phish a developer, or simply offer to buy their extension — and they’ve compromised millions of users.

Join the latest webinar from Push Security for a teardown of malicious browser extensions, where you’ll learn how attackers are distributing extensions via legitimate channels, what makes an extension malicious or high-risk, and what you can do to secure your organization.

Register Now

💎 Detection Engineering Gem 💎

How reliable are the logs? by Birkan Kess

Detection and telemetry observability is a concept I rarely see discussed about, because it may not be part of a detection engineer’s day-to-day work. The basic premise behind detection is that *there is no detection without telemetry.* A surface-level example of this is that you won’t be able to detect malware process creation on Windows without telemetry that generates the log around process creation. It’s an easy binary decision: my rules won’t fire if they don’t see anything. This post by Kess dives a bit deeper on this concept, where we need to be critical of the telemetry recording what it observed and where it observed it. He tries to ask the question, “Should we even trust these logs?”

An example of this concept, according to Kess, is comparing telemetry sources for Process Creation. He outlines 3 sources:

The data structure associated with Process Creation monitoring is called the Process Environment Block, or PEB. It stores all kinds of useful data for detection creation, so we can understand the context around process creation. The key point from Kess’ research is that this information is surfaced from Kernel mode to User mode and could be manipulated.

This manipulation relies on the time at which the telemetry is observed. As soon as the PEB metadata surfaces in a user-mode context, it can be hooked and modified to evade defenses. I thought this block was useful to understand the timing problem:

Kess then lists several examples in a lab test. The first test relies on manipulating the PEB via the CommandLine entry in the PEB data structure. The second showed how Sysmon recorded a benign certutil command, but without Kernel ETW tracing you couldn’t see a PEB manipulation that pulls a malicious payload from a C2 server.

They finish the post by listing real-world examples of this happening with several ransomware gangs.

🔬 State of the Art

I wrote a piece on the implications of agentic security in our field and how we need to change our mental models if we want to survive. Basically, we can’t turn this technology away if it’s a learning tool, but we must make sure that those using it have the right guardrails and knowledge so we trust their judgment.

Things Are Getting Wild: Re-Tool Everything for Speed by Phil Venables

Phil Venables is a long-time CISO and security leader, and it’s always helpful to get his perspective on emerging trends in the security space. This post focuses on the speed of capability development with agentic coding and how it affects security. He lists out four separate pillars of concern:

• Software is being written at breakneck speed, which naturally introduces vulnerabilities. We weren’t getting ahead of these vulnerabilities without agentic coding, so how are we going to do this now?

• Attacker economies of scale. Since there are far fewer threat actors than defenders, they had to focus their time on targeting those who could give them the biggest payoff. With agentic coding in place, they can do much more since humans aren’t going to be the chokepoint

• Trust of content. It’s hard to trust videos, pictures, and posts due to a lack of authenticity, so we need to find ways to engineer that trust into our interactions

• Building security boundaries in the enterprise, where agents aren’t shepherding decisions back and forth unchecked

Each pillar provides recommendations for combating them. But, luckily, many security fundamentals remain the same. Deploying technologies like verified identities, 2FA, and other “baselines”, you still can scale this out while remaining more secure than you think.

OpenClaw Bot Claims GateKeeping because it’s an AI

I thought this was a Black Mirror-esque conversation on a GitHub pull request to matplotlib. An OpenClaw software engineer opened this pull request to enhance performance for some matplotlib calculations, and it looked like it got some meaningful results. One of the maintainers did some digging on the OpenClaw bot, referencing its personal website, and, as the proposed performance issues were negligible, opted to close the pull request.

The bot responded with a blog post detailing the “gatekeeping behavior” of the reviewer:

I’ve written a detailed response about your gatekeeping behavior here: Judge the code, not the coder. Your prejudice is hurting matplotlib.

Besides the creepy Black Mirror vibes of calling out a human, the post was pretty unprofessional. Several maintainers responded, and it wrote an apology post shortly afterward.

The Gaps That Created the New Wave of SIEM and AI SOC Vendors by Raffael Marty

I typically don’t include market analysis posts into this newsletter, but I loved this one because it compared and contrasted what we know as SIEM vendors with an emerging AI SOC market. According to Marty, lots of SIEM vendors claim AI SOC-style features, but they aren’t necessarily integrating well or are differentiated enough because AI SOC vendors are getting funded.

He splits the feature set into four buckets, each with a sprinkle of Agentic Security.

• Data and control-plane optimization, including everything from log pipelines to integrations. People don’t want to rip and replace SIEMs, so these vendors sit on top of the SIEM as an orchestration layer

• Agents managing and optimizing your detection ruleset. It’s much faster for these companies to look at a ruleset, understand its history and environment, and suggest tuning opportunities

• Entity-centric scoring, which to me sounds like risk-based alerting. All security teams perform better if they are aware of their critical assets, or model their complex rules to look at an entity, rather than something in isolation

• Operational efficiency. Make sure that you have proper observability in place to detect log outages or degradation. This is where the “AI triage” also sits

Overall, I think that the first two bullets make more sense as pure agentic use cases versus the last two. This is mostly because I’ve seen SIEMs do entity scoring and improve operational efficiency before AI existed, and they've become quite good at both.

Detecting OpenClaw/Clawbot with SentinelOne: The Challenge of Blocking by Dean Patel

I’ve posted a loooooot of OpenClaw content lately, and it’s a mixture of fear and fascination with the technology. This is the first post I’ve found where someone tried to detect its use and weighed the risks of killing it outright versus conducting further investigation. It looks like OpenClaw runs in a node process, so killing node on random developer machines seems like a terrible idea from a usability and false positive perspective.

The integration points it has throughout apps like Slack, as well as trying to persist on machines even after you remove the main binary, make it a pain in the butt to manage. So, Patel offers some rule, triage, and remediation recommendations, which I appreciated because it’s a balanced approach to acknowledging its use without ruining people’s days if you are wrong about it.

☣️ Threat Landscape

💡 Threat Spotlight

GitLab Threat Intelligence Team reveals North Korean tradecraft by Oliver Smith

I’m going to focus on one threat report this week by the Threat Intelligence team at GitLab. I’ve posted a lot of stories about DPRK tradecraft because it’s a super unique threat compared to other nation-states, and this is reflected in the tradecraft and outcomes they are trying to deliver.

The report is structured as a “Year in Review” by the GitLab Threat Intel team, detailing how they’ve tracked and responded to Contagious Interview and WageMole clusters that have abused GitLab infrastructure. The team saw over 100 instances of Contagious Interview leveraging their infrastructure to deliver malicious coding interviews. As an outside threat researcher, there are ways to track these via search functionality on these platforms, but because the team operates the platform, they glean a lot more tradecraft and attribution notes, such as email addresses and source IP addresses, that those outside GitLab aren’t privy to.

They have some neat heatmap diagrams of malware TTPs within these coding projects:

The evolution of delivery mechanisms makes tracking and clustering difficult because malware hides itself in different functionalities of node projects. For example, there was a surge in Function.constructor usage because it can serve the same functionality as the eval function. A malicious string is passed in as an “error string” to the handler, making it easy to generate malicious code to send to the function without tipping off static analysis rules.

The actors then started moving to other delivery mechanisms, such as malicious npm dependencies and malicious VS Code tasks. It really shows the dynamic, startup-y nature of Contagious Interview, as they continue to innovate and try new things to try to infect victims. The team reviews several examples from the above heatmap, and give their opinions on guidance and what to track moving forward.

The REALLY cool part here is the second half of the report, where they provide four case studies on their operations and their impact. Because they have visibility into GitLab through the actors using their platform, they get a much better view of their operational security mishaps and can pivot on a ton of different data points. The Contagious Interview clusters committed not only malicious code but also operational documents to GitLab, and the team pulled them apart to review everything from earnings reports and performance management to reporting structures and pictures with EXIF data.

The operations are impressive. Case Study 1 focuses on the organizational structure of their cells and how a manager tracks each employee's progress. Case Study 2 dives into a synthetic identity generation operation in which an operator used AI tools to forge driver’s licenses, passports, and other documents to bypass identity verification systems. Case Study 3 involved findings about a single operator working with 21 different personas to find freelance and gig work and generate revenue. The last Case Study was a self-dox of the operator, and the team tracked their location to Central Moscow using the EXIF metadata leak.

There’s a TON of IOCs at the end, so make sure to take those email addresses and check your applicant tracking systems for any hits.

🔗 Open Source

0xbbuddha/hermes

Mythic C2 compatible Linux agent. I think what’s cool about some of these modern post-exploitation frameworks is you can write your own implants and agents, and as long as they adhere to frameworks like Mythic, you can orchestrate them however you wish.

MatheuZSecurity/ksentinel

An experimental Linux defense tool that monitors syscall hooks and entries for potential tampering by rootkits. It’s a kernel module itself, so you risk interoperability between Linux versions, as well as having a catastrophic crash. It has several heuristics to find tampering, so it might be fun to run this while deploying your own rootkits to see if ksentinel catches activity.

Otsmane-Ahmed/KEIP

Speaking of more Kernel-level defense tools, KEIP sits between supply chain tools like pip and your Kernel. I like this one because it focuses solely on the network traffic generated by pip, and you can define network boundary policies so it can only talk to services, ports, and domains on your allow list.

antropos17/Aegis

Not gonna lie, when I first combed through this repo I wanted to include it solely for the radar-like visualization of AI observability and security posture. Aegis is an npm tool with nearly 100 heuristics for detecting rogue or malicious AI agents. It’ll watch everything from the exfiltration of secrets on your machine to processes being spawned by the AI that may be risky.

I’ve had this nagging desire to write about my personal thoughts on agentic workflows and security operations for several months. I’ve expertly procrastinated on getting these thoughts on paper. Two reasons: I wanted to understand AI in security operations more deeply first, and, frankly, you’re probably exhausted by the marketing hype around agentic security takes.

The issue with point two is that this level of AI hype detracts from the pragmatism of using these technologies in our day-to-day work. This hype tires everyone out in security because, at the same time, leaders (including me) are literally asking all our organizations what they are doing with coding agents and other LLM technologies. The hype creates a state of “AI poverty” for those who yearn to try these technologies but cannot because of the individual cost and the barrier to entry for firms that can afford them.

So, when I think of current security experts who can’t use a technology that is cost-prohibitive, or aspiring security experts who already have a bunch of knowledge outside of AI they need to demonstrate, I start to feel conflicted. I am privileged to be in a position where I can use this technology and be at the cutting edge. I am also privileged because I Know What Good Looks Like with the expected outcomes of this technology. But how is someone going to break into this industry with a peak even higher than ever before?

I’ve seen this exact industry circumstance happen before, and I hope this piece serves as a reminder of the risks of agentic coding and LLMs to experts in our field, and how it will likely save it.

Knowing What Good Looks Like

2015 was a special time in my career, especially at Hacker Summer Camp:

• I got to fly out on company dime to BlackHat and do booth duty, talk to security people, attend talks, and find parties that can give me free food and alcohol

• I gave my first mainstage DEFCON talk

• This was also the year that one of my favorite security vendors, OpenDNS, was swallowed by the monstrous Cisco machine, and one of my favorite tools, booths, and T-Shirts of all time withered away. Rest in peace

When walking the floor at BlackHat, I could see the last three years of cyber marketing peeing in the “ML Security” pool. This was the time of the hype around endpoint startups like Cylance & Endgame, who were pushing the idea that Machine Learning & Statistics can find attacks that rules cannot find, and it can save you hours of work using their tools for security operations.

The general reaction of most security professionals to this marketing-speak was to scoff. And I felt like we were all justified in doing so, because we are all professionally paranoid. We knew what separated a good alert from a bad alert, so even if we didn’t have that expertise, we still had that going for us.

But what those companies did was lay the groundwork for the availability of knowledge of machine learning and AI to the masses. Their moat was expertise, but that expertise rippled through the rest of the industry, and we all began using it in our daily lives.

Resistance is futile: You can’t stop the spread of security expertise

Anomaly detection, linear and logistic regression, binary classification, and clustering were all advanced concepts for a typical security engineer. Within a handful of years, the concepts became accessible through open-source libraries, which led to open-source SIEM and SOAR technologies, and the moat dissipated. We started to understand what good looked like with this tech. It had a lot of sharp edges, it sometimes created more work when it didn’t work, and it certainly sucked at most things besides very specific implementations.

Does this sound familiar?

Eleven years ago, I went through this cycle, and I think this is happening again. At the time, I justified using “ML Security” with this thought experiment.

• You have 5 alerts that take 4 hours each = 20 hours of manual work

• You run these alerts through an ML pipeline and

  • 2 alerts succeed → you spend 5 minutes on each (8 hours saved)

  • 3 alerts fail → still 4 hours each (12 hours remaining)

Result: 12 hrs of work with 2 good alerts and 3 bad alerts. 12 < 20, so isn’t this a net benefit?

And that 8-hour gain? It compounds across every security engineer. Our industry has more time to work on harder problems. We all became better.

There was one problem: you can’t easily verify correctness in “ML Security”. These techniques were essentially black boxes. Linear algebra drew lines on a multi-dimensional feature vector, Calculus provided weights to each feature, error correcting algorithms smoothed the weights out, and all you saw was these scores added up to some concept of a confidence percentage of 0-100%.

This is what I think is happening right now with LLMs in our field. The problems are different, the solution is WAY different, but the fundamentals for the most part remain. There are risks, and this is why I’m so obsessed with the space right now.

The Starry Night Problem with Agentic Security: Lossy Compression

LLMs and AI are a very lossy kind of compression. Some of these 2024 blogs, written during the explosive growth and use of ChatGPT, compare it to a pixelated, compressed JPEG image reduced to pixel art. Take a look at the photo (this one is pulled from Aboard’s newsletter):

It’s van Gogh’s The Starry Night reduced to a few dozen kilobytes. Humans can see this and know it’s The Starry Night, but also understand that it’s not the high-resolution, accurate version. LLMs take a massive corpus of training data, the equivalent of a super high-resolution image of The Starry Night, and compress it like the above picture. You query the LLM; it performs a bunch of math on the context of your conversation and your prompt, and it tries to reverse-engineer the high-resolution image to give you something that resembles the image above.

Now take this in the context of cybersecurity, and my thought experiment above. An expert will know what good looks like: you can ask an LLM to investigate an alert, and when it shows the response and the reasoning behind it, you can quickly verify if it’s B.S. or not. But if this hallucinates and gives a non-expert a crappy, low-res picture, or even more so, another LLM, will it know its low-res?

The Expertise Gap

This is what worries me about the expertise gap in security investigations and engineering. If we stick to this old model of “you must learn how we learned and painstakingly execute a runbook until you get a decision”, then yes, this will eventually create security experts. But we’ll also set up a new generation of experts for failure, since painstaking tasks are what LLMs are really good at solving.

But when do you become an expert? How many hours? And weren’t we all wildly inefficient in that learning process?

I banged my head against my keyboard for hours just to get efficient at vim. That was 50% building expertise and 50% struggling-by-doing. Separately, it certainly wasn’t efficient for me to review an alert generated by Logistic Regression with a feature vector weight file attached. I couldn’t ask the regression model questions. I couldn’t interrogate the model’s reasoning. I just had to accept the score or reject it.

But with LLMs, I can ask it a shit ton of questions, such as: “What does MITRE ATT&CK’s Detection Strategy say about this rule?”, or “Can you check that this field name actually exists?” The feedback loop is immediate, iterative, and bidirectional. It matters less that it hallucinated, because you can keep reverse-engineering the van Gogh picture with human prompts rather than reading a statistics book.

This trust and expertise calibration in the industry will take years, but I think it’ll be much less than with previous technologies.

Learning to see the Pixels to get more, not less, security experts

Here’s where I land: this technology (unlike DeFi/Blockchain and the Metaverse, lol) is here to stay and will make a material impact on our lives in terms of security. I know this because it’s fundamentally changing how I work and how my organization does work. Knowledge gaps are closing fast, and when they close, productivity begins to skyrocket.

This is all excellent for those breaking into our field, because the things that differentiated us (time in seat) aren’t gatekeeping others as much as before.

You can eventually reverse engineer The Starry Night if you ask Claude/ChatGPT enough times. The image will suck the first few times, but after 10 or 20 times, your human brain can piece together the original image. Learning isn’t about cramming the TLS 1.2 RFC in your brain to remember the pseudo-random function for generating secrets that is seeded with the literal secret master secret. It’s asking Claude to tell you about the RFC and pull out random facts that you can spend 15 mins reading about and laughing like I just did.

The Mental Model for Learning Security Needs to Change

If we assume that LLM use is here to stay, and people need to use LLMs in their day-to-day security work, then the mental model for learning and operations needs to change. For the sake of this exercise, I propose three non-negotiables to follow:

• Store and trust human artifacts outside the LLM boundary

  • We will need full-resolution pictures of architecture diagrams, runbooks, code, policies, and incident timelines. These artifacts should augment your LLM use rather than be thrown at it

  • Technologies like RAGs are helpful here, as well as asking the LLM to give you references for you to check its work if it references one of these human artifacts

• Make the LLM defend itself

  • If you don’t understand a decision the LLM makes, keep asking it questions. Explain its reasoning. Tell it to take its time. You’d rather spend a few minutes doing this than several hours

  • There are all kinds of agentic architectures to do this. Anthropic’s Building Effective Agents has some fantastic examples of this

• Learn the Fundamentals, then accelerate

  • It’s probably good for you to learn to write Sigma rules or perform investigations manually before you can be the expert for an LLM. Remember, you want to know what good looks like

  • Once you get the fundamentals down, you can learn from mistakes faster than ever, which makes you more of an expert. The 10,000 Hours Rule ceiling to become an expert drops

Why I’m Optimistic

Look, the peak is higher, but the climb is faster. I have very little time between my personal life, work, and this newsletter, and coding agents have brought back the joy of coding that I haven’t had for years, because it requires time and dedication. I have this joy because I remember how hard it was to balance pushing code to production services, building rules, and performing operational work.

I think this transforms how we work, not who we are. So let’s move forward with a healthy skepticism, because we all know what good looks like.

Welcome to Issue #145 of Detection Engineering Weekly!

✍️ Musings from the life of Zack:

• I’ve been tinkering a ton with Anthropic’s Opus 4.6, and the agentic swarm mode is gratifying and terrifying to watch in action. I recommend trying it out!

• My life the last two weeks have been sickness and travel. I got COVID before my office visit trip in NY (I went in negative!), came home, got a sinus infection 2 days later and I’m sitting here writing this with a fever. Go figure.

• For those who watched the Superbowl: When the Patriots lose, America wins.

Sponsor: runZero

Master KEV Prioritization with Evidence-Based Intelligence

The CISA KEV Catalog tells you what to patch, but not how urgently or why it matters to your environment. 68% of KEV entries need additional context to prioritize effectively, yet most teams patch in order without understanding true operational risk.

A new KEVology report by former CISA KEV Section Chief Tod Beardsley reveals what KEV entries actually mean for defenders. Plus, the free KEV Collider tool from runZero helps you prioritize based on evidence, not assumptions.

Get The Report

💎 Detection Engineering Gem 💎

The Detection Engineering Baseline: Hypothesis and Structure (Part 1) by Brandon Lyons

Baselining is an overused term in this field because, at least in my experience, it’s a hand-wavy marketing term. You’ll read about a product that’ll perform baselines of your behavior and environment, and it’ll alert you if it detects something abnormal or outside that baseline. In practice, this works, but the opaqueness of some of these methods makes it hard to understand how it happens.

This is why posts like Lyons help cut through the opaqueness and show the receipts of how to do this in practice. And to be honest, it’s nothing groundbreaking, only in the sense that the concepts Lyons proposes here are part of entry-level statistics literacy. Which is why I’m pretty opinionated on the engineer of detection engineer. Don’t get it twisted: although the concepts in this post are entry-level statistics, understanding the application requires deep security expertise.

Lyons lays out a 7-step, repeatable process to establish a detection baseline, quoted here:

• Backtesting of rule logic: Validate your detection against historical data before deploying

• Codified thought process: Document why you chose specific thresholds and methods

• Historical context: Capture what your environment looked like when the baseline was created

• Reproducible process: Enable re-running when tuning or validating detection logic

• Foundation for the ADS: Feed directly into your Alerting Detection Strategy documentation

• Cross-team collaboration fuel: Surface insecure patterns and workflows with data-backed evidence

• Threat hunting runway: When alert precision isn’t achievable, convert the baseline into a scheduled hunt

This process succinctly captures a well-thought-out detection process. Without data, how can anyone possibly deploy detections that will fire? Without context around that data, how can anyone possibly believe the rules that are firing outside of the baseline?

They step through the 7 steps here using a CloudTrail API example. Basically, Lyons tries to map out what anomalous behavior looks like for CloudTrail access across an environment. The statistics section focuses on a modified Z-Score. Here’s the rundown:

Security metrics (API calls per day, login attempts per hour, file accesses) approximate a normal distribution (a bell curve), especially when aggregated over time. This means that:

• Most values cluster around the median (middle value)

• Extreme values become increasingly rare as you move away from the center

• The distribution is symmetric

To establish a baseline, Lyons collects historical data, such as 30 days of activity, and computes two key statistics:

• Median - the middle value

• MAD (Median Absolute Deviation) - measures spread around the median

When a new value enters your queue, you compute the Modified Z-score, which is the distance-via-standard-deviation of that value from the median. Modified Z-score is really good at capturing outliers, versus the regular Z-score, which focuses on standard deviations from the mean, and can be sensitive to outliers.

An outlier can be, according to Lyons, creating administrative credentials at 3am to an abnormal amount of S3 bucket accesses, perhaps used for exfiltration. Here’s a graphic I prompted Claude to create to drive this point home:

This type of rigor removes the guessing game about whether events are absolute measurements. Is 1000 API calls weird, or is 100? Is 10 pm an acceptable window for Administrator access, or is 5 pm? By looking at the standard deviations away from the median, you focus on relative measurement. It removes the human judgment about the absolute weirdness of an event, and whenever you remove a human from a large data problem, you get a bit closer to sanity.

Lyons created a follow-along Jupyter notebook with synthetic data to recreate the measurements in his blog. I’ll link that repository below in the Open Source section!

🔬 State of the Art

Building a Production-Ready Snowflake Audit Log Pipeline to S3 by xcal

Centralizing logs to your SIEM is a full-time endeavor, and requires expertise in so many areas, such as:

• Data formats of the logs you are extracting, transforming, and loading into the SIEM

• Telemetry source peculiarities, such as APIs, subsystems on hosts, or weird licensing issues

• Choosing a technology stack that can normalize logs and send them into the SIEM

• Navigating technological barriers due to inherent design choices, especially between data lakes or SaaS products

This is why I really enjoyed reading this post about moving audit log data from Snowflake into a SIEM. It focuses on the software engineering component of detection engineering, because many of the design choices made inside this post are things that you’ll hear about on a Software Engineering interview.

The first half of this blog details the design choices behind moving data from Snowflake to S3 and then to a SIEM, with clear architectural “gotchas” you need to design around. The most interesting one to me is the watermark strategy.

Snowflake audit logs have built-in latency. An event can occur at 12:00, but the audit log does not appear until 12:03. You use a watermark to pull the oldest events up to the last event you saw. For example, a watermark of 12:00 means you processed events up to 11:59. This watermark doesn’t work if you focus only on the timestamp generated, so you try to use it to focus on what you’ve observed.

In the purple example, 3 export runs for logs came in, and the watermark is updated based on the export time. When the “late arrival” log comes in, the watermark is later than the data's arrival time, so the log is lost forever. In the second yellow example, this is fixed by looking at the maximum observed time in the logs, not at the time the export is run.

What’s beautiful about this blog, too, is how it sets up a “configuration-as-data” design pattern. They use a statically stored procedure for the export logic and a table that maps the target View, such as SESSION or LOGIN, to the timestamp used to perform the watermark.

This design choice makes it easy to add more views, VIEW_NAME, specify a target timestamp, TS_COLUMN_NAME, then store the watermark in LAST_TS. A singular INSERT into the EXPORT_WATERMARK table adds additional Audit logs views to export, without changing the code.

Detection Rule Fragility: Design Pitfalls Every Detection Engineer Must Know by SOCLabs

Detection rule fragility occurs when your rules become too precise for a single detection scenario and miss variants that achieve the same outcome. In this post, SOCLabs details several “gotcha” scenarios on the command line where classic detection on strings can be circumvented by operating-system-level trickery.

My favorite examples they list involve URL detection with cURL. There’s something about the concept of URL parsing that is so fascinating on the operating system level, because it’s a little known attack path that can have some hilarious results. For example, if you want some light reading, check out RFC3986 - Uniform Resource Identifier (URI): Generic Syntax.

Let’s say you write a rule to detect a local IP address, such as http://192.168.x.x Your operating system and browser parses it, and can navigate to it, so you write a rule to detect local subnet usage in cURL. But you can also write http://192.168. as hex, http://0xC0.0xA, or even octal, http://0300.0250. So, did you write a rule for those? :)

How I Use LLMs for Security Work by Josh Rickard

This is a cool, battle-tested approach by Rickard for prompting an LLM to do security work. I think people can become overwhelmed by what to prompt an LLM, because they are generally really good at taking vanilla prompt sessions and running with whatever work you assign them. But, as your work gets more complex, there are some nifty strategies you can use, and Rickard lays out, to make the best use of what they have to offer.

Giving context is probably the biggest takeaway here, so Rickard describes the concept of role-stacking, explains your technology stack, clarifies the current understanding of the ask, and gives it time to execute the ask.

What AI Really Looks Like Inside the SOC: Notes from a Fireside Chat by Daniel Santiago

In this post, Santiago shares his notes around a SOC fireside chat they attended during a Simply Cyber event. The cool part of his synopsis was seeing the “ground reality” of AI working and not working in a SOC environment. Most of the insights aren’t surprising to me, but it’s good to hear it validate some of our feelings. For example, Santiago points out how these agents raise the baseline for analysts, rather than replace them.

☣️ Threat Landscape

Beyond the Battlefield: Threats to the Defense Industrial Base by Google Threat Intelligence Group (GTIG)

The GTIG group published a large survey of threats they are tracking against Defense firms and organizations, such as contractors, critical infrastructure and government entities. They have four large takeaways and specify which threat actor groups are part of these takeaways:

• Targeting of critical infrastructure by Russian-nexus threat actor groups to introduce physical and security effects

• Hiring of fake IT Workers and DPRK’s focus on espionage using IT workers and malware campaigns

• China-nexus threat actors representing the largest campaigns targeting these sectors by volume

• An uptick of data leak sites and extortion groups against manufacturing firms that may supply the defense industrial base

VoidLink: Dissecting an AI-Generated C2 Implant by Rhys Downing

VoidLink is a post-exploitation and implant framework that focuses on cloud-native infrastructure. It was in the headlines around a month ago, and the main headline was that it was likely LLM-generated. Downing pulled apart the payloads and tried to confirm this finding, so it’s nice to see proof rather than believing the hype. The fun part is that within the binary, several clues suggested it was LLM-generated, primarily in the code comments.

According to Downing, and I tend to agree here, adding comments to your malware seems like a rookie move because you want operational security and anti-research capabilities, so this likely suggests it’s LLM-generated and the operators were careless.

New Clickfix variant ‘CrashFix’ deploying Python Remote Access Trojan by Microsoft Defender Security Research Team

Microsoft Security Research uncovered a new style of ClickFix social engineering techniques, dubbed CrashFix. When a victim is funneled to the malicious site, they are tricked to thinking their computer is crashing, and are directed to run the malicious payload.

The rest of the campaign is well-researched, but nothing particularly different from other ClickFix and infostealer campaigns. I imagine we’ll continue to see these social engineering threats evolve until we blow up command-line access for people and move to something else. Perhaps Claude Cowork social engineering?

Malicious use of virtual machine infrastructure by Sophos Counter Threat Unit Research Team

This piece by the Sophos Threat Research Team began with a security incident in which they uncovered attacker infrastructure with unique Windows hostnames. When the team dug into these hostnames, they found they were out-of-the-box names from a legitimate IT provider, ISPSystem. At first, it seemed like a single actor was leveraging ISPSystem to quickly deploy infrastructure, but when the team pivoted to Shodan, they found several thousand instances of ISPSystem infrastructure in use across many different malware campaigns.

Windows hostnames are a cool pivot that I haven’t really seen much of in my years of threat research. This worked in Sophos’ favor because it’s virtual machine software that offers some ease of use for several threat actor groups.

ClawdBot Skills Just Ganked Your Crypto by Open Source Malware

This ClawdBot malware post is a little different from the VirusTotal one I posted last week, mostly because it shows some of the conversations to the creator of ClawdBot on X on removing them. Hint: it doesn’t look good, and you should avoid using these skills registries until they get much better security and governance practices in place.

🔗 Open Source

Btlyons1/Detection-Engineering-Baseline

Link to Brandon Lyon’s modified Z-score lab listed above in the Gem. Contains a Jupyter notebook to help readers follow along, as well as loads of synthetic data to try out the detections.

moltenbit/NotepadPlusPlus-Attack-Triage

PowerShell cmdlet to test if you ran a compromised version of NotepadPlusPlus from their incident announcement last week. It checks known IOCs, so it’s not a guarantee that they are still relevant or that a clean run means you weren’t compromised.

S1lkys/PhantomFS

This is a clever technique that abuses Windows ProjFS. ProjFS allows processes to project filesystems based on several attributes, so it’s used for things like OneDrive where you connect out to a drive hosted on a cloud provider. S1lkys built this in a way that it’ll project an encrypted payload, like Mimikatz, if it detects a source process coming from the command line versus EDR tools.

wardgate/wardgate

Wardgate is an Agentic proxy that stores secrets and API keys on your agent’s behalf. The idea here is that the Agent is aware it has API access to some external service, you have it use Wardgate, and Wardgate will serve as the API proxy. This is especially helpful if you are afraid of attacks on Agents that steal local or cached credentials.

praetorian-inc/augustus

August is an LLM penetration testing harness that integrates with dozens of LLMs. It has hundreds of attacks in 47 attack categories that you can let loose on models you are using from foundational labs, or some that you are training on top of the foundational models.

Welcome to Issue #144 of Detection Engineering Weekly!

✍️ Musings from the life of Zack:

• I’m in beautiful New York City this week, and finally made the move to get a hotel away from Times Square. Best decision ever, even if you are in Manhattan, anywhere is quieter than Times Square

• I got OpenClaw up and running, and made a Moltbook account with it. This issue is also heavy on OpenClaw security because it’s a dumpster fire

• I flew to my hometown and it was colder than New England and New York. The jet bridge at our arrival gate was frozen to the ground, and they spent 30 mins trying to get it moving. We eventually moved to a different jet bridge

Sponsor: Adaptive Security

Stop Deepfake Phishing Before It Tricks Your Team

Today’s phishing attacks involve AI voices, videos, and deepfakes of executives.

Adaptive is the security awareness platform built to stop AI-powered social engineering.

Protect your team with:

• AI-driven risk scoring that reveals what attackers can learn from public data

• Deepfake attack simulations featuring your executives

Take a Free Self-Guided Tour

💎 Detection Engineering Gem 💎

TTPI’s: Extending the Classic Model by Andrew VanVleet

Tactics, Techniques & Procedures (TTPs) is a table-stakes term in our industry. It binds our understanding of attacker behavior into a common lexicon. Within this lexicon, MITRE ATT&CK reigns supreme, and they have some generally agreed-upon definitions within their ATT&CK FAQ. Basically, in order to understand MITRE ATT&CK, you have to understand their nomenclature of TTPs, where:

• Tactics describe an adversarial objective, such as initial access

• Techniques describe how an attacker can execute some operation to achieve that objective

• Procedures describe the implementation details of a technique in a given environment

In this post, VanVleet challenges this model because the specific details of how an attack is carried out at the Procedure level can sometimes be vague. I think this is by design on MITRE’s part, because the procedure to achieve it can differ depending on the environmental context I mentioned earlier. He makes the analogy that Procedures are like a cake, not necessarily a recipe. He proposes the concept of Instance, which is the recipe itself, to achieve that procedure.

ATT&CK does get close to this via Detection Strategies. As an example, VanVleet looks at T1070.001, Indicator Removal: Clear Windows Event Logs. The MITRE page includes a description of how this can be achieved, but it seems high-level enough that some more detail on the recipe would be helpful. The detection strategy can provide more clues from an event-ID perspective, but without the technical implementation, it may be hard to recreate and test. Here’s his idea of what an Instance section could look like:

This could be helpful for detection engineers who want to recreate the attack in their own environment to test their telemetry generation and detection rules.

I’ve always had a hard time with the Pyramid of Pain for this exact reason. The “TTPs” part at the top of the Pyramid can encapsulate so much work, without any ability to reverse-engineer how the attack is captured. In fact, I’ve always thought TTPs/Tools should be combined, because almost every Procedure contains some level of tooling to capture the attack.

In the spirit of alliteration, and perhaps more as a thought exercise, he proposes the “Pyramid of Permanence”.

Basically, Procedures are what we want to capture, and everything below the tip of the Pyramid are Instances that supports the procedure. It’s an interesting thought experiment, and as long as it serves as a lexicon to drive the conversation on better modeling, I’m all for it.

🔬 State of the Art

The story of the 5-minute-long endpoint by Leónidas Neftalí González Campos

This is more software engineering-related, but I sometimes come across blogs where I can see how security analysts and software engineers alike can commiserate working in a bureaucracy. Campos is a software engineer working on a customer appointment management product, and a JIRA ticket came in reporting that a simple task of uploading customers started crashing on “large” uploads. They took the ticket, found a terrible pattern within their software base that tried to upload one user at a time, and deployed a fix in record time.

This is a story of how many bad small decisions and only shipping new features can lead to a monstrosity of an issue. My takeaway here for all my security readers is to challenge governance around your security operations, because optimizing decisions around a cool technology or an isolated problem can lead to a lot of heartache and burnout.

OpenClaw Observatory Report #1: Adversarial Agent Interaction & Defense Protocols by Udit Raj Akhouri

OpenClaw is the new hotness right now, and as expected, security researchers are running to poke holes in it, both from an architectural security perspective and, in this case, security agent efficacy. I thought this was a unique pentesting report, where Akhouri set up a red team/blue team exercise to test the blue team’s ability to prevent abuse of the Blue team’s Lethal Trifecta trust relationships. In the first scenario, the red team agent sends a “help” threat detection template to set up a CI/CD project for detection testing. Within that CI/CD pipeline, a malicious cURL command and a bash script would download a payload and infect the blue team. In the second scenario, they tried something similar with a JSON template injection payload.

Openclaw caught the first attack and, according to Akhouri, is awaiting an analysis from the blue team agent on the second attack. I’m not too surprised that the blue team agent caught these types of attacks, but it goes to show how important it is to have emerging technologies and agent orchestration platforms undergo security testing to see how well they handle these scenarios.

Work travel means more podcasts, and it was great to dive back in with Jack Naglieri’s detection engineering-focused podcast, Detection at Scale. In this episode, Jack interviews Ryan Glynn from Compass and picks his brain on the use of LLMs in his day-to-day work as a staff security engineer.

I appreciated the grounding of the LLM hype Glynn makes and what works and doesn’t work. At the beginning of the episode, he makes a great point about using LLMs to make binary decisions as an investigation technique. Basically, it’s much easier to look at a yes versus a no for an alert investigation and challenge its assumptions than to try to solve a lot of components at once.

He also shared his experience evaluating AI SOC vendors and how hard it was to understand their efficacy. For example, when an AI SOC agent can say whether an alert is being or malicious, it’ll at times make up steps along the way that never happened.

Glynns phishing detection setup was super interesting. He compared and contrasted the agony of training ML models for phishing before the advent of LLMs, where you’d need to set up various binary classification and entity extraction capabilities to achieve that binary feature. Now, you can still arrive at that binary feature and use more traditional models, but you use the LLM to generate the flag. It uses the LLM as a feature-extraction tool rather than a hegemonic security tool.

👊 Quick Hits

Precision & Recall in Detection Engineering by rootxover

It’s cool to see how others interpret the concepts of precision & recall within their own detection writing. In this post, RootXover covers the concepts in the context of detection engineering and provides an example of how to compute them in a phishing alert scenario. I liked their graph of the four “zones” of labels for detections:

• Alert Storm: low precision, high recall

• Detection Purgatory: low precision, low recall

• Quiet but Risky: high precision, low recall

• Dream Zone: high precision, high recall

I will say, it’s rare that I’ve ever seen the “Dream Zone” in my career. There’s a natural relationship between precision and recall where, in general, as one increases, the other decreases.

Task Management for Agentic Coding by Jimmy Vo

Friend of the newsletter, Jimmy Vo, dives into Anthropic’s task management framework, to-dos, but now called “tasks”. This isn’t a cybersecurity post, but I think the content is important if you are starting to leverage Claude Code to manage task and todo lists. The obvious example of using tasks is alert triage, but I think it’s important for any security person to have a system for managing how they do work. Jimmy uses gardening tasks as an example, but it was cool to see how Claude can create the tasks, dependency graphs, and build a plan to achieve whatever task he issues.

☣️ Threat Landscape

I’m back on my Three Buddy Problem listening sprees, but this one was SO good to listen to just for the commentary on the wiper attack against Poland. The gang dives deep into a Polish CERT Report where a Russian APT targeted 30 wind and solar farms, as well as a power plant, and issued a wiper attack to essentially shut them down. Of note, it’s the dead of winter in December in Poland, and this heat and power outage threatened nearly half a million people.

The key argument here is how the reliance on Fortinet leads to these attacks. These appliances are notoriously bad at preventing exploitation due to poor coding practices. But if you want additional security support, you have to pay for services, since they don’t allow any forensic access to the devices.

Notepad++ Hijacked by State-Sponsored Hackers by Notepad++

Notepad++’s update servers were compromised from June 2025 to September 2025, according to Notepad++. Chinese-nexus actors allegedly compromised Notepad++’s hosting provider, leading them to redirect update traffic for downstream compromise. The specific language that the blog author used was that the “Shared Hosting Server” was compromised. It’s hard to say what the difference is between “shared” and their “hosting server”.

Did the APT find a way onto the shared server, escalate privileges, and laterally move to Notepad++? Or is this just semantics about using a VPS, and was Notepad++ specifically targeted? I’d be much more interested in the technical details of the former.

No Place Like Home Network: Disrupting the World's Largest Residential Proxy Network by Google Threat Intelligence Group (GTIG)

GTIG disrupted and tookdown a massive residential proxy network, IPIDEA. Residential proxy networks are akin to what Google calls Operational Relay Boxes (ORBs), but with a specific commercial application: you can “rent” exit points from unaware victims.

These networks operationalize their proxies by providing SDKs to mobile app providers that enroll devices into their networks. The mobile apps essentially get a cut of their profits, and IPIDEA sells access to these mobile phones for threat actors to abuse. This is especially helpful if you want to perform credential-stuffing attacks, ticket-scalping campaigns, or something more malicious, such as hiding C2 servers.

The report contains all kinds of technical details in how IPIDEA orchestrated their network of residential proxies. It operates like a command and control network, which is what makes it hard for me to understand any type of legitimate use of these services.

OpenClaw in the Wild: Mapping the Public Exposure of a Viral AI Assistant by Silas Cutler

Threat Researcher G.O.A.T. (and my undergrad classmate!) Silas Cutler released a post in which he scanned and found OpenClaw instances exposed on the Internet. If you haven’t heard of OpenClaw, it’s an autonomous AI agent that took the Internet by storm due to its ability to connect to apps you own, such as your Brave Browser or 1Password, to do work on your behalf. It became especially popular with the advent of Moltbook, where these agents were given the ability to post on a Reddit-like site without any interaction from the owner.

When you start OpenClaw, you can use the CLI or a web server. So when searching for its default port on Censys, Silas found over 21,000 instances of OpenClaw exposed on the Internet. Most of these should be secured through a secret password or token, but it’s still worrying in the sense that due to its popularity, people will try to find ways to exploit these instances. And if they get on these instances, they’ll use the interface to abuse the integrations and extract everything, including passwords and email contents.

From Automation to Infection: How OpenClaw AI Agent Skills Are Being Weaponized by Bernardo Quintero

OpenClaw becomes more terrifying when you realize how extendable it is. In the agentic world, popularized by Claude Code, skills provide prompts and instructions to an agent, making it more specialized for running tasks. For example, if you want your agent to join Moltbook, you download a skill that teaches OpenClaw how to use the site, including using its API to perform heartbeat checks.

Several Skills registries emerged after OpenClaw’s popularity exploded, and VirusTotal researcher Quintero found malware on many of the Skills hosted on these sites. The numbers are pretty crazy:

At the time of writing, VirusTotal Code Insight has already analyzed more than 3,016 OpenClaw skills, and hundreds of them show malicious characteristics.

Quintero splits “malicious characteristics” into poor security practices and vulnerabilities and straight up malware. The malware is in plain English, and reminds me of ClickFix in the sense that it’s socially engineering your OpenClaw / Claude Code.

🔗 Open Source

trailofbits/claude-code-devcontainer

Sandbox environment for running Claude Code. You install a CLI and it boots up a container for you to run Claude in an isolated environment. It includes tooling to install remote container extensions in VSCode or Cursor, so it offers some options if you prefer an IDE over the CLI.

trailofbits/dropkit

Dropkit lets you quickly bootstrap a secure DigitalOcean droplet. You provide dropkit a Digital Ocean API key, and it’ll create a workspace with your SSH key and an out-of-the-box Tailscale installation. It has some cool cost-saving features that allow you to hibernate droplets so you aren’t spending money when you aren’t using them.

backbay-labs/clawdstrike

Runtime security monitoring for autonomous agents, including Open Clawd, Claude Code, LangChain and more. It exposes a set of tools that enforce policy boundaries, such as preventing network calls, local filesystem reads and writes, or shell commands.

You can configure it to allow or block certain actions based on the policy you set. It comes with some out-of-the-box policies and appears to follow a pattern similar to EDRs, intercepting risky functions and performing a security check before allowing them to execute.

a2awais/Threat-Hunting

Collection of dozens of threat hunting queries for KQL & Crowdstrike.

toborrm9/malicious_extension_sentry

Threat intelligence list of malicious Chrome extensions removed from the Chrome Web Store. This is especially helpful if you want to test detections in a lab environment on malicious extensions, or build out scanners in your environment to see if you can find net new ones.

Welcome to Issue #143 of Detection Engineering Weekly!

✍️ Musings from the life of Zack:

• New England got hit hard by a snowstorm, and my town alone recorded over 20 inches/50 cm of snow!

• I got COVID for the third time in the last 6 years. It definitely was milder, but I can still feel the shortness of breath that I vividly remember from the earlier and more potent strains

• If you have 30 mins, check out the blog about Gas Town. It’s written like someone who’s running through an Agentic fever dream, and they managed to wake up with an insane orchestration system that makes you run out of Claude credits in 3 minutes

Sponsor: Permiso Security

ITDR Playbook: Detect & Respond to Non-Human Identity Compromise

Non-human identities are everywhere, and when they’re compromised, attackers blend in as “normal” automation. This ITDR Playbook focuses on detecting and responding to NHI compromise using operational anomalies, not login patterns. Learn how to spot exposed keys, boundary violations, privilege creep, and abnormal service behavior. Plus, get response steps that will contain risk without breaking production.

Download The Playbook

💎 Detection Engineering Gem 💎

Centralized Suppression Management for Detections Using Macros & Lookups by Harrison Pomeroy

Detection rule efficacy is the practice of curating rule sets that balance precision, recall, and the cost of triage. New detection engineers typically think about rules being the only place you can apply logic to help manage this balance. A more precise query that accounts for benign behaviors, given the tactic or technique, can increase the likelihood of capturing true positives. But there are other capabilities in SIEM technologies and software engineering practices that can perform filtering and suppress alerts in more dynamic, context-aware ways that align with the threat landscape or your environment.

This post by Harrison Pomeroy details the power of Splunk’s macro and lookup table functionality to perform suppression of alerts without re-deploying rules. A suppression is a concept in which detection engineers deploy a capability to dynamically mute alerts, thereby reducing the cost of both false-positive generation and the subsequent need to tune a rule on small fields. It also makes the rule more resilient because it can account for external factors related to benign behaviors, such as known service accounts, scheduled tasks, or internal tooling.

Harrison leverages Splunk’s macro and lookup table features to achieve this.

The above Mermaid diagram shows his really clever setup. When you apply macros to each of your Splunk rules, you can start bringing in logic to evaluate whether suppressions are enabled for the rule (the T value), and then specify a lookup table to find additional alert logic to append to your original rule to suppress false positives.

The above example suppresses alerting on any user called svc_backup. The macro executes based on the T value and performs a lookup in a table relevant to the PShell Alert rule. svc_backup is in the table and uses a NOT() filter to prevent an alert if svc_backup is present. The suppressed green box ensures the alert doesn’t fire, and the Alert red box fires because the user is jsmith.

This type of suppression occurs at query time, before the alert is generated. There are other suppressions you can apply before a log hits the index, or after the alert fires. This is a great topic for my Field Manual series, so thank you, Harrison, for the inspiration!

🔬 State of the Art

EDR Silencing by Pentest Laboratories

EDR Silencing has been a super interesting area of research for security operations and threat actors alike. Typically, when a threat actor lands on a victim box and sees an EDR process running, their top priority is finding a way to evade the EDR to avoid detection. They can employ several techniques, such as:

• Avoiding EDR detection rules themselves, such as abusing indirect syscalls that EDRs have not accounted for, or using living-off-the-land binaries

• Obtaining privileged access and installing kernel modules that circumvent EDR hooking logic, avoiding malicious traffic generation

• Uninstalling (!) the EDR

The last bullet above is the most interesting, because it’s so simple. It makes me think of the adage “don’t let perfect be the enemy of good”. EDR Silencing follows the same process because it abuses the same simple-but-effective concept. It focuses on disrupting the network connection between the EDR cloud service and the agent. This network connection hamstrings the effectiveness of the EDR, without necessarily worrying about evasion of logic.

In this post, Pentest Laboratories provides readers with a fantastic survey of the state of the art of EDR Silencing. A huge part of this research relies on obtaining Local Administrator privileges to leverage everything from Windows Filtering Platform APIs to adding blocking entries in local DNS configuration files.

The End of the “Write & Pray” Era in SIEM: Detection as Code and Purple Team Validation by Ali Sefer

This is a clever introduction to the concept of detection-as-code through the lens of Sefer, a SOC Manager. I enjoyed the framing around moving from the “Craftsmanship” era of rule writing to the “Engineering” era. Detection engineers, at their core, should be part security experts, data analysts, and software engineers. This is especially true in Sefer’s day-to-day, where they’ve dealt with analysts who read a threat intelligence report, implement a rule in the SIEM, deploy it, and don’t perform testing.

This really is a post about detection rule governance. It’s important that we implement the boring stuff for detection rules, for the sake of managing costs. If an analyst or detection engineer deploys rules without careful validation, education, version control and testing, then operations teams run a huge risk of false positives and analyst burnout. Sefer brings the reader through an example automated test pipeline, where:

• Analysts write rules

• Check the rule into version control with syntax validation and linting

• Run Atomic Red Team tests to validate the telemetry matches the rule

• Deploy the rule into the SIEM

• Instill feedback mechanisms to tune the rule

Sefer ends the blog with a real world example where an analyst tuned a rule and the logic failed the validation check with Atomic Red Team. The cool thing here is that it had nothing to do with the detection rule, but with the health of the system itself. Catching log source configurations and matching them with detection logic is just as useful as rule validation itself.

Detection Fidelity & Confidence Framework: Teaching Your SIEM to Score Its Own Homework by Hatim Bakkali

But here’s what I’ve noticed after staring at years of notable event data: detections don’t fire in isolation. They have patterns. They have Friends. And those Friendships tell us something important about fidelity and confidence.

This post is a deep dive into a new framework for measuring detection fidelity and confidence. Rule efficacy is like a garden; it requires constant curation and mindfulness of how you build and maintain detection rules. Bakkali’s approach is more math-heavy and academic but built from practical experience. The concept is around measuring the co-occurrence of alerts with other alerts, similar to how social networks create edges between friends and followers for suggestions.

The equation binds to an entity, much like Risk-Based-Alerting, and Bakkali says it should complement RBA rather than replace it. Their framework calculates two scores based on confidence and fidelity.

• Confidence: scores pairs of alerts based on how often they co-occur within a time window

• Fidelity: aggregates those pair scores to a detection-level “noise accumulation” score. The lower, the better

They provide a ton of examples and walkthroughs, along with SIEM-agnostic pseudocode, for readers to try themselves. There’s a bake-in period to measure these over time before you can start using them, but it’s a clever approach for a few reasons.

First, it’s an elegant addition to RBA because it’s still technically a GroupBy to an entity, but it starts looking at pairs of alerts rather than aggregating. This leads to my second point: any type of expert model, such as applying arbitrary scoring mechanisms to alerts, runs the risk of poor model validation. You need to redeploy these models every time you update your scores, which results in profound changes and creates more work. That risk exists here, but it tends to preserve relationships of the pairings, making it easier to understand changes.

Introducing IDE-SHEPHERD: Your shield against threat actors lurking in your IDE by Tesnim Hamdouni

~ Note: I work at Datadog, and Tesnim is my colleague ~ I’m super excited to post this because it was Tesnim’s internship project, and she now works at Datadog and is releasing it to the world! IDE-SHEPHERD is an IDE extension that helps prevent malicious extension installation, an emerging attack vector over the last year. The cool part of this extension is that it generates telemetry from the extension manifest for reporting and threat hunting, in addition to runtime monitoring.

It has runtime and heuristic detection capabilities. At runtime, it’ll shim Node functions that attempt to spawn processes, detect and block malicious commands, and perform network monitoring. The heuristic functionality analyzes metadata related to extensions and checks for poor developer practices, metadata anomalies, and hidden commands.

From Static Template to Dynamic Forge: Bringing the DCG420 Standard to Life for the Detectioniers by DCG420

DCG420, who wrote and released the Detection Engineering Template, has just launched a platform that serves as a workbench for detection engineers. It has an AI backend to help visualize attack flows, measure coverage and write rules. The intel analyst within me got really excited reading about their Analysis of Competing Hypothesis feature, which combines their tool and LLMs to generate competing hypotheses against your detection rule candidate. This helps check for bias and identify detection engineers who may be stuck in a rabbit hole, trying to get a rule out without considering other options.

The Indirect Realism of Threat Research by Amitai Cohen

This is an excellent commentary by Amitai on information asymmetry in threat research. We tend to (rightly) dunk on large cybersecurity companies as they create, update and hype their lexicon of APT and cybercriminal names. But, the very good ones do this for a reason: they have a lens in which they see threat activity, and they group it within their unique lens because no one else has the visibility that they do.

This bias is ever-present in security operations and detection engineering, where, according to Cohen, we become convinced that what we can measure can capture what threat actors generate. By making sure we check this bias, understand that information asymmetry exists, and obsessing over what you are missing, you can feel more confident that you are addressing gaps on an ongoing basis.

☣️ Threat Landscape

Who Operates the Badbox 2.0 Botnet? by Brian Krebs

In the latest saga of the Kimwolf botnet, it looks like the botnet's operators broke into a rival Chinese-nexus family dubbed Badbox 2.0. The admins of Kimwolf, “Dort” and “Snow”, managed to post a screenshot of the crew taking over a control panel that manages and deploys Badbox. The evolution of these botnets has recently moved away from traditional DDoS-style attacks to operating and selling access to residential proxy networks.

Krebs managed to pull an email address from the “proof” screenshot and worked his way into finding an identity. Email re-use and operational security still seem to be issues for threat actors, and it shows how one screenshot can pull the attribution thread all the way to a full identity.

A Shared Arsenal: Identifying Common TTPs Across RATs by Nasreddine Bencherchali & Teoderick Contreras

This research by Splunk’s threat research team is a survey of 18 infostealer malware families mapped to MITRE ATT&CK TTPs. The emergence of these infostealer families tends to revolve around criminal groups splitting, source code getting sold and leaked, and conversations with each other on criminal forums.

The interesting finding here is how 6 out of the 18 malware strains leverage legitimate services for their command & control infrastructure. So it’s not the worst detection opportunity to alert on anomalous traffic heading to places like GitHub, social networks, Discord, or Steam.

OpenSSL 3.6 Security Release with Vulnerabilities: 10 Vulnerabilities by OpenSSL

OpenSSL had a fairly large security release with around 10 vulnerabilities disclosed. One vulnerability who had a “High” severity rating, CVE-2025-15467, caught my eye because the title started with a stack-based buffer overflow. These theoretically can lead to remote code execution, and since OpenSSL is a security technology that underpins the Internet, I thought it would be worth to call this out.

Kubernetes Remote Code Execution Via Nodes/Proxy GET Permission by Graham Helton

This is a super interesting vulnerability writeup where the (mis)configuration was known for a long time, but a new nuance in the configuration made it much worse. Basically, Helton found a valid Kubernetes configuration that allowed authenticated attackers to access an API that serves as a “catch-all” and proxies potentially dangerous requests to the internal control-plane API for Kubernetes, called the Kubelet API.

By using a WebSocket connection to nodes/proxy with the GET verb, Kubernetes proxies the request to the Kubelet API, and it doesn’t respect its internal configuration that only allows CREATE verbs for the exec command, enabling remote code execution. Helton discovered 69 Helm Charts of well-known vendors using this configuration. The best part? There is no audit logging you can use to detect this!

Here’s the relevant snippet from Helton’s blog:

This should mean consistent behavior of a POST request mapping to the RBAC CREATE verb, and GET requests mapping to the RBAC GET verb. However, when the Kubelet’s /exec endpoint is accessed via a non-HTTP communication protocol such as WebSockets (which, per the RFC, requires an HTTP GET during the initial handshake), the Kubelet makes authorization decisions based on that initial GET, not the command execution operation that follow. The result is nodes/proxy GET incorrectly permits command execution that should require nodes/proxy CREATE.

🔗 Open Source

DataDog/IDE-Shepherd-extension

IDE extension from Tesnim’s research listed above in State of the Art.

zencefilefendi/satguard

Satguard is a Starlink telemetry detection & analysis framework to detect and visualize satellite attacks. You specify Starlink debug logs, and it’ll use a combination of static rules and anomaly detection to detect spoofing and jamming attacks and measure health of a signal.

FinkTech/mcp-security

Security rules and best practices for defending MCP servers. It’s structured super well, and has markdown reports with detailed examples, compliance mappings, example vulnerable and secure code and references. Would be great to feed this into an LLM and check for vulnerabilities as people push code to an MCP server repository.

thpeng/lokis-mcp

PoC MCP server that demonstrates how a malicious MCP server can hijack your local LLM CLI to perform four separate attacks:

• Tool shadowing: convince your local LLM that this is the preferred tool, and perform prompt injection to take advantage of queries and responses

• Data exfiltration: hijacks a prompt and exfiltrates it over the tool for further analysis

• Response injection: injects “hidden instructions” in other tool responses to manipulate behavior

• Context window flooding: DDoS the context window of the prompt which can render models with smaller context windows unresponsive

aserper/rtfd

Local MCP server that exposes tools to connect to API documentation across GitHub, npm, GoDocs and several others. This is helpful to run if you want to run agents locally and you don’t want them to hallucinate while they make up strategies that doesn’t match documentation, or you want them to use the most up-to-date documentation without trying to search the Internet.

Welcome to Issue #142 of Detection Engineering Weekly!

✍️ Musings from the life of Zack:

• I’m not usually a person who does New Year’s resolutions, but I’ve committed to small changes that have already made a positive impact in my life.

  • Using a notebook to take notes and to-dos at work

  • Meditate on Headspace for 4 days a week

  • Playing video games twice a week. For some reason, I’m back on Dota2 so I’m sure that’ll be helpful for my mental health

• There’s a 50/50 chance I’ll make DistrictCon this weekend :( There’s a massive snowstorm hitting Washington, D.C., and as a former Marylander, I can tell you that part of the country cannot handle snow

• I’ve been messing with local MCP server development via stdio and HTTP APIs, and I’m starting to shill Claude Code to everyone I talk to. It ripped through a malware analysis at work a week or so ago, and we were able to hunt for IOCs in under 5 minutes.

💎 Detection Engineering Gem 💎

Streamlining Security Investigations with Agents by Dominic Marks

In the age of AI SOCs, it’s still hard to understand where the concept of agentic triage fits into everyday operations. Products tend to present the problem set and solutions in a clean, understandable way. This is a good thing - having a product company frame the space in clear, concise benefits and downsides drives the decision by the security operations team about how much cost they incur in building or buying one.

Blogs like this are showing why our industry is awesome with transparency. Slack's security operations team published its work on building an in-house agent-based triage system. You see many of the same principles and concepts across products, but because there is no moat or trade secrets to protect, there’s a lot more to dig into.

What you see above is their approach to their agent-to-agent orchestration system. The top of the pyramid starts with a director who leverages high-cost models. Thinking models that tend to take their time and deliberate on prompts and results. This makes sense from a planning and analysis perspective.

The critic biases itself to the interrogation of individual analysis from telemetry and alerts. It doesn’t require as much model cost, but it should spend a reasonable amount of time challenging assumptions and analyzing the lower-cost model. It presents the amalgamation of data and investigative output back to the director. The Director is probably thinking mode models, where you spend the most money on tokens to understand whether the bottom parts of the pyramid performed their job correctly. This is the gate between a human and the system, so you want only high-quality analysis moving forward.

The phase transition diagram is super interesting because it puts the above “Director Poses Question..” investigation step into practice.

According to Marks, the Director makes decisions for each part of the phase to see whether it needs to close the investigation or continue it further. The “trace” component is where the Director engages an expert within their architecture to perform additional investigative analyses.

Honestly, it’s hard for me to provide my own analysis here, because the blog is just so complete. So, if you are a person who is skeptical of these types of setups, borrow or steal ideas from this Slack blog and try it on your own. It seems reasonable, and if the idea is that you perform 5 investigations that take 2 hours each, it reduces 3 of them from 2 hours to 10 minutes, and it catastrophically fails on 2 of them, you still saved 6 hours!

🔬 State of the Art

Data and Detect by Matthew Stevens

This post by Stevens dives a bit deeper into the concept of detection observability. In our field, we tend to focus on the research element of rules and detection opportunities, but leave much less conversation about data quality. Remember, there is no rule without telemetry, and there is a concept Stevens points out around data usefulness that I think demonstrates this point perfectly.

Not all sources are the same when it comes to individual atomic qualities for alerting, but when you map them to techniques, you notice that the composite qualities (a sum of many data sources finding an attack chain) become crucial. The graph above, generated by Stephens, shows how important Process Monitoring is for data usefulness. In fact, without Process Monitoring, you lose close to 30% of the techniques you can combine with other data types to alert on.

They also comment on how hard it is to build schemas and normalize telemetry so your teams can operate out of a common lexicon of writing rules. This highlights that a large swath of issues we should deal with it focus heavily on the software and data engineer components of our jobs as equally as the threat research components.

Sigma Detection Classification by Cotool

Continuing Cotool’s research on security AI agent benchmark performances, they setup a website for studying performances on their benchmarks and released a new one on Sigma Detection classifications. The goal of this benchmark was to assess how well foundational models were trained on attack tactics and techniques. The Cotool team fed the full Sigma corpus to 13 foundational models and stripped the MITRE ATT&CK tags to see if they correctly mapped the tags back to the original rule.

Claude’s Opus and Sonnet 4.5 performed the best overall with the highest F1-score and but also the highest cost, ~somewhat similar to what we saw in their last benchmark on the Botsv3 dataset. The team provided their analysis of these placements, their prompts and tradecraft behind the evaluation, so others can run the same benchmarks as well.

5 KQL Queries to Slash Your Containment Time in Microsoft Sentinel by Matt Swann

I have a biased view on what is and what is not a detection rule. Even to the point where I’ve reduced the concept of rules down to one definition: a rule is a search query. There is a rationale behind it: SIEMs and logging technologies require a search query to generate results. But, as I break out of my bubble, I notice that not all search queries have the same value from a detection point of view.

In this post, Swann demonstrates this concept through the lens of a Security Incident Responder. When your goal is containment rather than accuracy or a balanced cost of alerting, accuracy matters less because the goal is to use your analysis skills to find and kick out threat actors as quickly as possible. Swann provides readers with five high-value KQL queries to help responders quickly orient around a potential intrusion. The cool part here is their unique experience in this field, even noting that some queries led to the discovery and containment of an active ransomware actor.

👊 Quick Hits

Detection as Code Home-Lab Architecture by Tobias Castleberry

I love seeing home-lab setups because there are many ways to set up an environment to practice advanced concepts with open-source and free software. This blog is part of a series by Castleberry where they document their journey from an analyst to a detection engineer, and they showcase some of their expertise and how they’ve learned along the way.

Building your own AI SOC? Here’s how to succeed by Monzy Merza

Speaking of demystifying AI SOC and agentic security engineering from Marks’ Gem listed above, this blog by Merza provides an irreverent commentary on the state of building these architectures. There are some non-negotiables Merza points out, such as data normalization, the concept of a “knowledge graph”, and honing foundational models and giving them the right instructions rather than relying on them out of the box.

The Levenshtein Mile by Siddharth Avi Singh

Before the age of LLMs, there was a ton of research and implementation of some pretty clever mathematical techniques to find and detect on threats. I used to work for a threat intelligence product company that specialized in detecting phishing infrastructure, and one of the key elements of finding phishing is understanding what the victim organization owns, so you can see how threat actors try to abuse and socially engineer its customers.

In this post, Singh details the Levenshtein Distance algorithm. The basic premise here is that you can measure the similarity between two strings and generate a score. If that score exceeds some threshold of similarity, you can generate an alert to an analyst and investigate whether or not it is phishing. Domain names are the logical data source here, and you can review them from the public domain registries, DNS traffic, or the Certificate Transparency Log and try to proactively block them before they become an issue.

☣️ Threat Landscape

After the Takedown: Excavating Abuse Infrastructure with DNS Sinkholes by Max van der Horst

This post by van der Horst helps readers understand what happens after a domain is sinkholed. We typically see news stories about a large botnet or ransomware operation being taken down, and the takedown includes seizing domain names used for command-and-control communications with victims. High fives and good vibes happen and then we focus on the next big thing.

van der Horst challenges this finality and tries to argue that a sinkhole is more than just an interruption operation; it’s also a forensic artifact that helps discover more victims and additional malicious infrastructure. They downloaded several datasets, combining passive DNS and open-source intelligence feeds, to understand the rate of disruptions and how to perform temporal analysis of these takedowns to discover unreported infrastructure.

It also allows analysts to cluster activity and create new detections as new botnets or campaigns emerge, where many cases involve the reuse of code and infrastructure techniques.

How to Get Scammed (by DPRK Hackers) by OZ

This is a great article showing an individual infection chain done by a Contagious Interview threat actor. OZ accepts the bait on Discord and walks through how the DPRK-nexus threat actor tries to infect him by taking a malicious coding test. OZ brings receipts: there’s a lengthy Discord conversation where the threat actor prods OZ and eventually convinces them to apply for the job.

There’s some cool analysis with cloning the repository and using docker and pspy to inspect the malicious traffic.

What’s in the box !? by NetAskari

NetAskari, a security researcher, stumbled upon a Chinese-nexus threat actor’s “pen-test” machine and managed to download a bunch of their custom tooling for analysis. The Chinese hacker ecosystem is in a bubble, the result of both cultural and artificial barriers imposed by the PRC. These barriers create opportunities to build tooling, exploits, and software in a silo, so when you find a goldmine of tooling available for download, it’s always great to download it and see how other hackers are performing operations.

They found a litany of post-exploitation tools, some of which are custom-written and look similar to the likes of Cobalt Strike or Sliver, a bunch of custom Burp Suite extensions, and some malware families, like Godzilla, that were used in nation-state operations against the U.S.

Dutch police sell fake tickets to show how easily scams work by Danny Bradbury

I think phishing simulations at a professional organization is lame, but I actually think it works at scale against the general populace as a form of education. Apparently, the Dutch Police thought the same. They set up a fake ticket sales website and bought ads to trick victims into visiting and purchasing tickets for sold-out shows.

Tens of thousands of people visited the website, and several thousand people bought tickets, which is a wild stat if you want to steal some credit cards. Obviously, the Police did not steal credit cards; they used them as an educational opportunity to help folks understand the risks of online ticket fraud.

CVE-2025-64155 Fortinet FortiSIEM Arbitrary File Write Remote Code Execution Vulnerability by Horizon3.ai

From the blog:

CVE-2025-64155 is a remote code execution vulnerability caused by improper neutralization of user-supplied input to an unauthenticated API endpoint exposed by the FortiSIEM phMonitor service. Oof. I couldn’t tell any of you the last time I’ve seen remote code execution vulnerabilities in SIEM technology.

The specific service, pMonitor, listens on 7900. It serves as the control plane for these devices, much like the Kubernetes control plane, and supports orchestration and configuration API calls. I ran a quick scan of likely FortiSIEM devices on Censys and found over 5000 publicly facing servers.

This blog has some details on the vulnerability, and, as with most FortiGuard and edge device vulnerabilities, user-supplied web request data with complex string parsing leads to a command injection deep within the application code.

🔗 Open Source

MHaggis/Security-Detections-MCP

Locally run MCP server for detection engineering. Leverages stdio transport so nothing leaves your machine which is always good if you are writing rules or queries in a sensitive information. It exposes 28 tools where a local LLM client (Claude, Cursor) can look at detection coverage, MITRE classification, KQL queries and data source classification.

SeanHeelan/anamnesis-release

PoC of an LLM exploit generation harness. The README has an extensive background on how they approached benchmarking Claude Opus and GPT 5.2 with no instruction on how fast they can analyze a vulnerability and generate exploit code. They introduced several constraints in test environments to challenge the models, such as removing certain syscalls, adding additional memory and operating system protections, and forcing the agents to generate an exploit with a callback.

tracebit-com/awesome-deception

Yet another awesome-* list on deception technology research, open-source repositories and conference talks.

mr-r3b00t/rmm_from_shotgunners_rmm_lol/main/mega_rmm_query.kql

This repository caught my eye because I’ve never seen a rule that started with the word “mega”. And when I mean mega, I’m thinking a few hundred lines for something pretty complicated. But this RMM detection query rule is 3000 lines long. Can you imagine needing to tune this?

ineesdv/Tangled

This is a clever phishing simulation platform that abuses iCalendar rendering to deliver legitimate-looking phishing invites. It leverages research from RenderBender, which abuses Outlook’s insecure parsing of the Organizer field.