Det. Eng. Weekly #117 - I only play the games that I win at
And stay the same with more alerts than theres ways to skin cats
Welcome to Issue #117 of Detection Engineering Weekly!
⏪ Did you miss the previous issues? I'm sure you wouldn't, but JUST in case:
💎 Detection Engineering Gem 💎
Attribution With A Pinch of Salt (Typhoon) by Joe Slowik
Everytime Joe Slowik posts a new blog, I make sure to sit down with a nice cup of coffee and a notepad to deconstruct and understand whatever the topic is.
Look, unfurling threat intel reporting, especially around clustering or attribution, can be frustrating. Opaque statements surrounding marketing jargon, such as naming a piece of malware "JUNKYJUICER" or a group "OBNOXIOUS CHIPOTLE” (these aren’t real names), generally serve the purpose of SEO rather than well-intentioned sharing. I don’t necessarily blame the analysts behind these blogs. I’m sure they are hamstrung between ~generating shareholder value~ and lawyer-speak. This does leave the rest of us plebeians to put the pieces together.
Using the recent news of Salt Typhoon, you can see what’s going on with some of this madness:
There’s vendor-speak to name something and ship it quickly
Due to above spotlight of Salt Typhoon, security companies and the media try to media-jack the share of voice
For the entities (Microsoft) who do want to publish more around the group, their lawyers redlined virtually anything that would be useful to people who aren’t customers
To help communicate the complexities of weaving attribution clusters together, Joe pulls the thread on overlaps of Salt Typhoon with other likely PRC-sponsored APT operations.
He attributes most of the overlaps with Chinese MSS and Salt Typhoon to media reporting and sanctions, rather than open technical disclosure from leading CTI vendors. The most glaring point, though, is that attribution confuses us even more due to the lack of technical details surrounding Salt Typhoon. We build these clusters based on techniques, public intrusions and IOCs, not from reporting, so how can we possibly defend against this group if we only know that they are connected to MSS?
📒 Detection Engineering Field Manual
I’m starting a new series on Detection Engineering called the Detection Engineering Field Manual. I posted the first issue last Friday and will be continuing posting every other week or so. Check it out below!
🔬 State of the Art
No Agent, No Problem: Discovering Remote EDR by Jonathan Johnson
This is a unique piece of research that combines attacker tradecraft and detection engineering in a clever way. While researching ways to improve the open-source ETWInspector tool, Johnson began reversing Microsoft’s logman tool. Logman allows Windows users to create and collect ETW session traces and logs for log analysis, security and debugging.
Johnson wanted to replicate some functionality here within the inspector tool and discovered that logman uses COM and DCOM methods to perform it’s log collection functionality. COM is a standard interface in Windows for processes to communicate with each other and call functions in DLLs, while DCOM is the remote version of this.
Logman had DCOM capabilities, meaning it could call remote COM objects. Through some trial and error, Johnson replicated this functionality to create and collect remote ETW sessions. This essentially means he had as close to a “Remote EDR” as possible. The Windows internals details on this post are pithy but worth a read if you want to see all the components of an EDR-thats-not-an-EDR.
Differentiating between IoC , IoA and indicators of fraud by Sergio Albea
If you have ever been confused by the terminology in threat intelligence space, especially around what an “indicator” is, it’s totally understandable. And it’s not in the sense that they are complicated and academic concepts; instead, it’s because they were designed and claimed by threat intelligence analysts as a way to describe artifacts versus behaviors, but they became convoluted in the process.
So, Albea comes to the rescue to help differentiate between three commonly used terms: indicators of compromise (IoC), indicators of attack (IoA), and indicators of fraud (IoF? Probably not.) You can think of IoAs and indicators of fraud as threat actor behaviors and IoCs as artifacts or evidence left by the threat actors. For each category, he includes several examples with accompanying KQL queries.
PoC Attack Targeting Atlassian’s Model Context Protocol (MCP) Introduces New “Living off AI” Risk by Guy Waizel, Dolev Moshe Attiya and Shlomo Bamberger
I usually dunk on AI security research since prompt injection attacks, at least the ones I have read, aren’t really that interesting for foundational models. You may break out of OpenAI 4o so you can get it to say a few more swear words, neat! The attack scenarios I’m seeing, which involve layers over foundational models such as MCP servers, are making this space significantly more interesting.
Cato researchers uncovered a prompt injection scenario with Atlassian products. By design, an anonymous user can submit a support ticket via an Atlassian portal. This support ticket could contain a prompt injection not to jailbreak the model, but to exploit how the MCP client interacts with Confluence MCP servers and disclose sensitive information.
Why You Should be Testing Your Detection Rules — Part 1 by Bill Mahony
I read numerous research posts about detection-as-code (DaC), where the focus is more on the code portion of the rule, such as its implementation in Python, rather than explaining the benefits of this paradigm from a DevOps perspective. I was pleased to read this post on DaC by Mahony, as it provided a great introduction for folks to understand testing methodologies within DaC.
IMHO, you aren’t doing DaC if you put your rules inside GitHub and deploy them after a merge to main. It’s the same vibe as someone who pushes to prod; it’s just an extra step with a pull request. DaC should focus on the strengths of CI/CD, specifically testing, validation, and auditing.
Mahony introduces three types of testing to compare and contrast with production code vs. detection code. The most interesting example to me is around end-to-end tests via “synthetic” logs. The idea here is you not only store the detection code, but you can inject synthetic logs into your pipelines to generate alerts when you deploy the rules.
☣️ Threat Landscape
What’s Inside the Massive Chinese Data Leak by Aurora Johnson, Kyla Cardona and Mike Dausin
I sometimes forget that data leaks happen outside the U.S. context. This ignorance stems more from being personally affected by it, as well as being deeply disappointed in the US’s state of security affairs. So, it’s interesting to see how citizens of other countries’ data gets abused and used in crime circles.
In this post, SpyCloud Labs researchers obtained a partial copy of one of the most significant data leaks to hit China. The team parsed and deduplicated the leak, noting some inconsistencies with its aggregation, which to me suggests that this is a combolist rather than a commercial database. The team notes that this likely stemmed from a Chinese “SGK” database, which Chinese doxxing criminals typically use to target victims.
Removal of unwanted drivers from Windows Update by Cymoki / Microsoft Hardware Dev Center
Microsoft unveiled the removal of previously signed legitimate drivers that threat actors use for BYOVD. You can see a list of them in loldrivers, but I wish this story was getting a little more attention because it’s a huge problem for evasion on Windows platforms.
Cyber threat bulletin: People's Republic of China cyber threat activity: PRC cyber actors target telecommunications companies as part of a global cyberespionage campaign by Canadian Centre for Cyber Security
Look! Another Salt Typhoon post! Maybe this time they’ll include technical information to help defenders, basically what Joe Slowik’s post (in the gem above) says!
Oh.. I guess not.
Dissecting Kimsuky’s Attacks on South Korea: In-Depth Analysis of GitHub-Based Malicious Infrastructure by Enki Whitehat
This post was interesting to me because the Kimsuky (DPRK-nexus) attack chain contained a new secondary payload flow I’ve never seen before. The attackers embedded a GitHub PAT inside their initial dropper malware to download additional malware in private repositories. The PAT had open permissions on it, so once the Enki researchers got ahold of it, they were able to enumerate the complete GitHub infrastructure behind this attacker.
5 security issues disclosed in libxml2 by Alan Coopersmith
In an interesting turn of events for libxml2, the maintainer opened up all reported security vulnerabilities to the public. The maintainer created an issue on GitLab, explaining their reasoning, which seems fair considering they are unpaid and the project is open source. It seems pretty messed up that big corporations put tons of pressure on OSS developers without supporting their projects monetarily.
I hope more open-source vendors adopt this approach because it removes the leverage from developers who use these libraries without improving their security posture.
🔗 Open Source
Open-source threat intelligence feed stored all in GitHub. It aggregates 30 separate feeds into one spot and normalizes the data. I like the “Wall of Shame” in the README, it looks to be updated daily :).
ugurkocde/DeviceOffboardingManager
Out-of-the-box onboarding/offboard tool into Intune/EntraID and a few other Microsoft products. It looks feature-rich, and I know tools like this can cost a company a lot of money for the same functionality.
Swiss-army knife bazooka for Active Directory pentesting. It’s a bash wrapper for all kinds of tools used to persist, laterally move and exploit Active Directory environments.
Certificate Transparency Log tail tool. You run it and it starts downloading the “append-only” logs from the CT databases, which serve as an excellent source of information for threat hunting. Be weary when you run this; you are gonna get a shit ton of output from the sheer size of these logs.
Self-propagating SSH pseudo-worm. I don’t think it does anything that generates impact, rather, it breaks into systems via SSH, steals potential credentials, and then breaks into more.
Instead of manually jumping between systems with SSH keys like it's a Super Mario game, let SSH-Snake do the work for you.
Ok that’s pretty funny.