Det. Eng. Weekly #116 - Immaculate newsletter aura 👌👌👌
good vibes frfr
Welcome to Issue #116 of Detection Engineering Weekly!
I’m in NYC this week for Datadog’s DASH user conference! I spent Day 1 manning the “Ask the Researcher” booth, did some lightning talks, and tomorrow I’m doing a larger talk on vulnerability prioritization. I love this city :)
Shameless Plug - LinkedIn Group
Thanks everyone who’s joined my LinkedIn Group for the newsletter. We are in the 100s of followers at this point! If you have a LinkedIn and want to see more short-form posts and engagement from myself, or you want to post stories or your own research, follow and hang out by clicking the button below!
⏪ Did you miss the previous issues? I'm sure you wouldn't, but JUST in case:
💎 Detection Engineering Gem 💎
Do you know your Detection Surface? by Regan Carey
If a log source stops sending telemetry and no one is around to fix it, does it actually matter?
The best part of this job, IMHO, is the diversity of technologies you can work across. You could be building rules one day for Windows, responding to an alert on Email the next day, and building out a new integration for a SaaS app the day after. You can level up rather quickly in terms of your technical chops of the attack surface you are trying to protect. But who maintains the "detection surface," as Carey calls it when these sources do indeed go down?
Even further, how can you be certain that you have or don't have a log source that you need to worry about? This is where detection surface mapping comes in. It's not the sexiest part of the job, but I always tell my org that the boring parts of your job are generally the most critical. Carey explores the idea of documenting a registry of log sources for detection teams, as you may not be aware of everything happening in your environment unless you are actively investigating it.
Carey gives a template for readers to use for their log source documentation. A few things seemed obvious to me, such as the ingestion method and relevant log-forwarding infrastructure, but I took notes on some of his other suggestions. For example, documenting the exhaustive log categories generated from the data sources. This task seems tedious, but this is probably where the most critical portion of the documentation and it sets you up for everything from ATT&CK mapping and threat hunting later on.
🔬 State of the Art
Lift me up to Ring 0: what are the most vulnerable Windows drivers by Artem Baranov
Vulnerability disclosure for Windows is quite an endeavor to study. Microsoft formalized the program in October 2003, and since then, researchers (and sometimes threat actors) disclosed thousands of vulnerabilities to the operating system ecosystem. The program has evolved to accommodate various vulnerability types as well. With more security hardening technologies being implemented to prevent classic attacks, such as buffer or heap overflows, recent research suggests that vulnerabilities may be found in Windows Drivers.
The above graphic and blog post were the result of Baranov's 3 year lookback study of disclosed Windows vulnerabilities (since January 2022). The crazy part about this whole ecosystem is that it's extremely hard to find out the technical details for these patches. Not due to the expertise required to understand them but rather because Microsoft intentionally makes patch notes vague. Luckily, Baranov links a video at the bottom of his post that details how to use Ghidra to identify patch diffs and obtain more details on the vulnerabilities.
YARA-X is stable! by Victor M. Alvarez
The Rust rewrite of YARA, YARA-X, hit 1.0 and is now marked "stable." This means that the core team recommends using YARA-X for production environments moving forward, and they've moved YARA into maintenance mode. It's been quite the journey since YARA's inception, so I'll pour a 40 oz. out to pay my respects, but definitely check out why YARA-X is better here and switch over when you can!
Infostealers Crash Course: A Tradecraft Tuesday Recap by Lindsey O'Donnell-Welch
This is a recap blog of a monthly webinar from Huntress on Infostealers, and it's much higher quality than I've seen from other recaps. It essentially reads like a paleontology study for Infostealers, detailing their origins, evolution over the years, and future direction.
O'Donnell-Welch provides a thorough breakdown of what these malware families do once they claim a victim, where the logs are stored, and which marketplaces sell logs from specific infections. I find it hard to keep track of the family trees malware and ransomware, so this is one of the better posts that help highlight how these groups react to researchers, leaks, and law enforcement.
Day 62: Detection Engineering - How to Build Alarms Without Crying by Adarsh Pandey
I don't want any of my alerts to cause me to cry, but sometimes they do! In Day 62 of Pandey's SOC Analyst 100 days of Learning Challenge, he tackles our favorite topic: Detection Engineering! I always try to read and link intro posts like this, because our field is still nascent in the grand scheme of security. I am also very interested in seeing how SOC analysts who transition to Detection Engineering think about the best approach.
I quite like the section on the "Detection Feedback Loop." I always see the Detection Engineering Lifecycle start with ideation and end with deployment. In contrast, when you put on your SOC analyst hat, this loop starts with an alert firing. Know your customers!
Thoughts on the Impact of Generative AI on Security Engineering Careers by Scott Ponte
This brutally honest blog by Scott cuts right into the core of a difficult conversation we've all had in security in the last two years: is AI going to replace us? The short answer, according to the blog, is no, but things are changing, and we should adapt to the times.
I thought it was interesting to compare Scott's predictions that the "removal of a SOC analyst" is a zero-sum game, as in marketers telling people that SOC is no longer relevant and AI will replace it all. Instead, the SOC transforms into higher-skilled workers where the new normal is they are incident response engineers handling a much higher triage queue due to AI.
How to Build a WAF Detection System: ModSecurity + NGINX + ELK MONITORING (Detection Engineering Series #1) by Zyad Waleed Elzyat
I rarely get to read a post about detection engineering that focuses on setting up a lab for WAF rules! I cut my teeth on ModSecurity/Core Ruleset as my foray into detection engineering. In this post, Elzyat guides readers through a lab scenario where they build an NGINX web server, add the ModSecurity module to load WAF rules, and forward those rules to an Elastic Stack for parsing and alerting on attacks.
If you haven't had a chance to play around with the OWASP Core Ruleset, set this project up and see how much different web security rules are versus traditional endpoint or Cloud rules.
☣️ Threat Landscape
DanaBleed: DanaBot C2 Server Memory Leak Bug by ZScaler
Following the Operation Endgame takedown of DanaBot, ZScaler researchers released a blog post detailing a massive vulnerability in DanaBot's C2 protocol. Following a DanaBot update in 2022, the developers of the MaaS family began padding seemingly random data at the end of their C2 communications. Upon further inspection by Zscaler, they realized that the developer was leaking internal process memory in this 1,792-byte stream and that memory contained all kinds of sensitive information on victims and customers of the malware.
Two Botnets, One Flaw: Mirai Spreads Through Wazuh Vulnerability by Kyle Lefton and Daniel Messing
When was the last time you saw an RCE in a SIEM? Akamai researchers Lefton and Messing caught two separate Mirai-style botnets exploiting a critical RCE disclosed to Wazuh. The vulnerability reads like an RCE-as-a-service, where an attacker sends a crafted POST payload to /Wazuh with an arbitrary Python argument that the victim server executes. The interesting aspect of this vulnerability is that it's present in a SIEM/XDR product; the less interesting aspect is that it's being exploited by Mirai-style botnets.
Follow the Smoke | China-nexus Threat Actors Hammer At the Doors of Top Tier Targets by Aleksandar Milenkoski & Tom Hegel
SentinelOne researchers Milenkoski and Hegal pulled the thread on ShadowPad and Chinese-nexus threat actors that attempted to compromise SentinelOne themselves. Once these intrusions were detected, the researchers mapped out the C2 servers associated with these actors, and their research scope expanded to nearly 100 victim organizations within the malware cluster. These intrusions exhibit all the signs of Chinese threat activity, including the use of the ShadowPad modular C2 framework, Operational Relay Boxes, and a heavy reliance on open-source exploitation frameworks within these intrusion timelines.
OtterCookie: Analysis of Lazarus Group Malware Targeting Finance and Tech Professionals by Mauro Eldritch
OtterCookie is Contagious Interview's latest foray into stealing information from victim laptops before they are added to the DPRK-nexus threat actor's botnet infrastructure. This technical analysis of an OtterCookie sample is embedded within a fake interview coding test. The victim runs the application, OtterCookie is fetched through a clever error handling function, and the victim executes the malware. You can check out the any.run and follow the infection chain here.
🔗 Open Source
Apple released their own native tooling to launch OCI-complaint containers on Silicon-based Macs. It’s cool to see them go down this route and contribute to the open source ecosystem, but in spectacular Apple fashion, the backwards compatibility of the capability is limited. MacOS 15 can run it but it’ll have network performance issues, so everything MacOS26+ (they skipped 11 versions if you didn’t watch WWDC) will be better supported.
FAIR is a registry-agnostic protocol for vendors and open source contributors to host their packages in a decentralized fashion. It uses the concept of “DIDs” as a metadata construct, and connecting to a registry and pulling this metadata means you don’t necessarily have to host the code on the registry itself.
Yet another EDR-killing open source project. I couldn’t find an associated blog post describing the technique, but the project purports it uses a technique “Process Creation Blocking Kernel Callback Routine” to kill the EDR and block the process from starting back up. It also says it’s usermode but I see a driver, so I’m unsure about the efficacy of this compared to other techniques.
wazuh/wazuh/security/advisories/GHSA-hcrc-79hj-m3qh
Link to Wazuh’s GHSA explaining the RCE vulnerability that I linked in the Akamai post above under Threat Landscape.
MuhammadWaseem29/CVE-2025-24016
PoC for the same Wazuh vulnerability I linked in Threat Landscape and the associated GHSA. The researchers at Akamai claimed this code (which really is just a Burp code block) was copied into Mirai payloads and used as the entry point to infect publicly accessible Wazuh boxes.