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.