Det. Eng. Weekly #121 - lol sharepoint
lmao
Welcome to Issue #121 of Detection Engineering Weekly!
I’m back writing weekly issues, and I hope you enjoyed the 2-part Gem series I posted in the last few weeks.
Why did I post these for two weeks? Well, my wife and I were busy in Peru trekking the Inca Trail to Machu Picchu!
It took a while to acclimate then do the 4-day trek, but it was so worth it. Tourism is such a massive business in Peru, and it sounds like the sheer amount of bus and foot traffic at the site will not last forever, as Machu Picchu is deteriorating due to it. I was happy to walk my way there just like the ancient Incas!
⏪ Did you miss the previous issues? I'm sure you wouldn't, but JUST in case:
💎 Detection Engineering Gem 💎
What Comes After Detection Rules? Smarter Detection Strategies in ATT&CK by Lex Crumpton
The MITRE ATT&CK team has been working diligently to update some of the structured detection fields in their Workbench product. As ATT&CK grew, it tried to capture all of the fantastic, crowdsourced knowledge on Tactics, Techniques and Procedures and stuff it into various objects.
Since we shared a common lexicon of these techniques, the ATT&CK team attempted to map detection opportunities to the techniques. However, things began to break down in conciseness, as most of these techniques contained lengthy text blocks. So, the team created three STIX Domain Object (SDO) to help capture concise detection opportunities.
The new setup is quite verbose but precise:
In the picture example above (also in the blog), you can find a Technique definition, and the “Detection Strategy” is linked as Analytic IDs. For each analytic ID, you define a platform source, such as Windows, and corresponding telemetry sources, such as Sysmon or Windows Event Log. It goes even deeper with the specific event IDs of the telemetry source (In Windows’ case) as well as the key/value field you should model your detection around.
I believe this type of development for ATT&CK will streamline detection sharing by capturing these new fields. That being said, I worry about incorrect, vague, missing, or inaccurate guidance, as this model may not necessarily fit every technique type under the sun. So, make sure to trust AND verify everything here :).
📒 Detection Field Manual
I released Issue 3 of the Detection Field Manual last Friday, check it out!
Detection Field Manual #3 - What is detection rule efficacy?
After Issue 2, you should understand that writing, maintaining, and deploying detection rules is a core value proposition for a Detection Engineering team. These rules encapsulate human and machine knowledge in a readable form to issue queries against a security log ingestion and indexing service, typically a SIEM.
🔬 State of the Art
Detection Engineering: Practicing Detection-as-Code – Introduction – Part 1 by Stamatis Chatzimangou
This is Part 1 of a multi-part series on how to practice detection-as-code (DaC) in Detection Engineering. I’ve read many different ways to get people started in DaC, but it was nice to see a blog that begins with concepts and gradually moves into implementation. I really enjoyed the high-level diagram on how to write detection code as Step 1 and then deploy it to production many steps later.
AWS Detection Engineering: Mastering Log Sources for Threat Detection by Muh. Fani (Rama) Akbar
There is no rule without telemetry, and this blog post shows why that matters from an AWS perspective. In this AWS detection deep dive, Fani Akbar shares a story about how their security team missed a persistent attacker account in their AWS environment for two weeks during a breach simulation. This prompted the detection team to reassess several gaps in their AWS setup. They attempted to answer the following questions: What log sources do we have access to? How relevant are they from a detection and investigative perspective? And what rule coverage do we have? Turns out, AWS logging is harder than you think:
It was nice to read about their team having an introspective moment on the gaps in their setup and how they can improve. Once Fani Akbar prioritized the best log sources for detection, they built our rules and began filling in those gaps. They include the rules in Python throughout the post, with some detection guidance along the way.
Evolving Detection: Why We’re Moving Beyond ADS to a New Engineering Template by Ondrej Nekovar and m3c4n1sm0
Nekovar and m3c4n1sm0 announce a new detection and response template built on the ideas behind Palantir’s ADS. ADS is almost 10 years old (!) at this point, and it was one of the pioneering open source projects that helped capture the knowledge of detection engineers way before there was a name for our field. But, according to the authors, there are some faults in the framework as our field accelerated over the last 10 years.
The new framework focuses on two critical pieces of information for detections: the capability abstraction (shoutout Jared Atkinson) and the MITRE CTID Summiting the Pyramid score. They removed freeform text from some of the fields (such as Technical Context and Response) to replace them with highly structured data and scores to pivot off of. I especially liked how they shipped this as a MISP integration that replaces ADS within MISP, to make it more queryable and shareable to the public.
How Tool Calling Works in LLMs by Sid (The Scalable Thread)
As AI SOC Analysts and Copilots take over the security marketing zeitgeist, it becomes challenging (at least for me) to discern what these tools actually do out of the box. For example, an AI SOC Analyst can be pre-trained to triage your alerts, but is it trained on your environmental context? What about external threat intelligence? Doesn’t this information change constantly, and if it does, how does it stay up to date?
The solution to these types of contextual training is through Tool Calling. Sid from The Scalable Thread gives an excellent breakdown of this design pattern using some real world examples, such as retrieving order statuses on an eCommerce website. You can teach an LLM to call a specific service or API or to issue a query when it encounters a prompt that semantically matches something like a threat intel lookup or asset inventory lookup request. The two places to load instructions are during training or during inference, and they both require a call out to an API and for the LLM to interpret the API response.
Death by a Thousand Slops by Daniel Stenberg
Stenberg, the core maintainer of cURL, has been publishing a ton of insightful content on what it means to be a security-aware open-source developer for a massive tool. The cURL project has been struggling with vulnerability reports from LLM-generated content, or as Stenberg puts it, “AI slop”. According to Stenberg, they report that 20% of security submissions to the cURL project are AI-generated.
This puts the cURL team in a tough spot. The idea behind a bug bounty is to encourage people to submit valid security issues and have them fixed for the public good. However, when you attach a monetary reward to some of these, it becomes a game of cost for AI vulnerability “researchers.” If they can submit 1,000 bad reports and a handful of them generate money, then it is worth it. It sounds like they aren’t closing down their program, but need to rethink the incentive structure because its wasting a ton of their team’s time and energy to triage “fake” vulnerability reports.
☣️ Threat Landscape
Disrupting active exploitation of on-premises SharePoint vulnerabilities by Microsoft Threat Intelligence
The big vulnerability news of this week is surprisingly not related to VPN or Server appliances, but publicly facing on-prem Microsoft Sharepoint servers. According to MSTIC, several Chinese-nexus threat actors have been scanning the Internet and probing for these vulnerable servers. The tech giant released patches for the exploited vulnerabilities, CVE-2025-53770, a 9.8 RCE, and CVE-2025-53771, a 7.1 path traversal vulnerability.
US National Guard unit was 'extensively' hacked by Salt Typhoon in 2024, memo says by Reuters (Raphael Satter)
*Archive.today link for a Reuters article on a leaked memo from U.S. Department of Homeland Security. Essentially, the memo stated that the national. guard network was “extensively compromised” by Salt Typhoon, and it claimed that had exfiltrated map and traffic data from “every other US State and at least 4 US territories.”*
Italian arrest of alleged Chinese hacker tests Rome’s geopolitical balancing by Gabriele Carrer
This was older news earlier this month, but I was off so I still think it’s important to post ;).
It’s rare that we’ve seen a government employee, in this case a Chinese national, be arrested for work they’ve done on behalf of their government. We’ve indicted nationals in China, Iran, Russia, and North Korea, but it’s interesting to see that we’ve moved beyond indictments, especially since we found the person in a Western country.
CryptoJacking is dead: long live CryptoJacking by Himanshu Anand
This was a fun finding by c/side’s Research team, where they flagged a malicious JavaScript file that looked and smelled like a browser cryptojacker, but operated much differently than the ones we have known to come and love in the past. The campaign Anand uncovered has an injected dropper script that had several environment checks, and making sure that the miners it spawned did not block any main threads within the browser application itself.
🔗 Open Source
soltanali0/CVE-2025-53770-Exploit
RCE PoC for Microsoft’s SharePoint 9.8 vulnerability mentioned in the MSTIC blog above.
Open-source case management tool for use in Incident Response engagements. Built in Python and as a desktop app, you can do all sorts of timeline views for the incident, threat intelligence provider lookups, wiki page creation, and several framework mappings.
tstromberg/supplychain-attack-data
Dataset of real-world supply chain incident examples. This isn’t something where someone intentionally creates a piece of malware and distributes it via OSS registry channels. It focuses on incidents that targeted real OSS packages where they were compromised.
Tmux-C2-as-a-service. This actually looks pretty awesome. It’s a Python script that calls socat and forks new C2 connections into separate tmux sessions. There are obsessed tmux fans out there who could navigate around the console way better than me and would love something like this as a simple yet effective C2 server.
Ondrej Nekovar and m3c4n1sm0’s GitHub repo that captures their ADS 2.0 framework. The completeness of this framework is super interesting and robust, though I imagine the startup cost is a lot more than “regular” ADS. Check out their example for LSASS Memory Dumps via ProcDump.
It’s definitely interesting timing for the release of this framework with the latest changes in ATT&CK listed in the gem above.
Sorry to burst thé métaphoric bubble, BUT official exploit disclosures only come after they've been patched. Hey, that's why we're paying big bounties for bugs, right Microsoft & Google ?
such a good one this week!