Det. Eng. Weekly #118 - If a threat cluster falls in the woods and no one is there to hear it..
..do marketing teams still give it a silly name?
Welcome to Issue #118 of Detection Engineering Weekly!
I’m in full summer mode right now. I have some exciting personal news coming soon-ish that has everything and nothing to do with this newsletter, so I can’t wait to share it.
I’m dropping a new issue of the Field Manual this Thursday since Friday is a holiday. I hope y’all like it!
⏪ Did you miss the previous issues? I'm sure you wouldn't, but JUST in case:
💎 Detection Engineering Gem 💎
How we analyse, compare, and integrate multiple threat actor attribution assessments by Sierra Stanczyk and Jono Davis
I’ve been on a “threat actor attribution” kick lately. A lot of this stems from frustration around marketing, but the more I read about it, the more I realize that it’s a technique not limited only to the significant “threat intel” players. There’s a ton of resources out there to help teams build and maintain attribution clusters, and this blog from Stanczyk and Davis is an excellent example of one of those resources.
If you ever have wondered how the attribution sausage is made, then you can see how a PwC’s threat intelligence function does this at scale. Evidence collection, interpreting the sources and methodology of that evidence collection, and applying structured analysis techniques are key components in putting these elements together.
The blog follows each step of Stanczyk and Davis’ flowchart and also includes the reconciliation of internal and external attribution. I found the section on “Evaluating and analysing multiple attribution assessments” the most relevant for all the media hype around Salt Typhoon. As described in the issue last week, the reporting contains so many gaps in technical details that it doesn’t leave us much for defending.
I think this is where the beauty of this methodology shines. If you track activity observed in your own environment, you can compare and contrast with public reporting, and it might make it easier for firms to ignore poor technical reporting. Threat intelligence that says something isn’t worth your time is just as good as intelligence that says otherwise.
📒 Detection Field Manual
I’m starting a new series on Detection Engineering called the Detection Engineering Field Manual. I posted the first issue and my second issue is coming out this Thursday. Feel free to check it out!
🔬 State of the Art
Why You Should be Testing Your Detection Rules — Part 2 by Bill Mahony
This is a continuation post from Mahony’s Part 1 on Detection testing, also listed in my last issue. Now that readers have a good understanding of the “why” behind Detection testing, Mahony lays out an excellent lab scenario to practice synthetic test generation.
The blog is laid out to showcase the test environment, the specific Detection rules you are going to test, and the testing methodology with saved searches. Synthetic tests differ slightly here from their use in pure software engineering. This is a little different than an integration test in the software engineering world, where fixtures are contained inside a test runner, and the testing runner is fed a testing function to load the fixture and mock the response.
In this scenario, you have a JSON fixture that serves as the test event, and it’s marked and sent to a testing index to generate the alert on the saved search in your production instance. Alerts “fire” and are saved to the alerts index with specific tags to prevent real alerting, and you can see passes and failures through a dashboard. Cool setup!
Out-of-Band, Part 1: The new generation of IP KVMs and how to find them by HD Moore, Tod Bearsley and Matthew Kienow
Network-connected KVMs are the new hotness for APTs, especially DPRK IT Workers. Their functionality seems quite helpful; you hook a KVM up to a physical computer, and then using KVM software, you can remotely login to the device and use the mouse, keyboard and see the screen. For every cool feature, red teamers and threat actors find a way to abuse it, especially if you want to run a laptop farm to perform fraud and fund a nuclear weapons program.
This is a cool detection post because it’s about hunting keyboards on your network and on providers like Shodan. North Korean IT Workers have significantly changed how detection teams approach finding insider threat scenarios, where insider threat refers to a productive employee. So, finding KVMs is an excellent lead for hunting and detection teams to find potential fraudulent workers. The runZero team provides some great breakdowns on how to hunt for these devices and even assigns them grades (A-F) based on their security.
Your Plugins and Extensions Are (Probably) Fine. Hunt Them Anyway. by Sydney Marrone
Threat hunting GOAT Sydney Marrone came through with a timely post on hunting malicious plugins and extensions. These malicious extensions can perform a range of functions, from acting as infostealers to having a significant impact in a breach. The basic premise behind these extensions lies in developers' trust in the open-source software ecosystem, as well as the productivity gains they achieve in their IDE, which leads them to find, download, and install extensions.
Sydney conducts an example threat hunt using the P.E.A.K. framework. MITRE ATT&CK demonstrates its applicability through its table of hunt ideas, which includes some excellent data sources for hunting these extensions.
A Standard for Human-Centered Investigation Playbooks by Chris Sanders
This research by Sanders focuses on what happens after an alert is generated, rather than how to generate an alert. The “playbook” element of investigations is often ambiguous, and it depends on organizational standards, as well as the commitment to the boring aspect of security: documentation!
So the question Sanders and many of us try to answer is: how do we investigate an alert? How much of this is intuition versus a checklist? Does intuition play a role in this process, or should we follow the checklist line by line, like robots?
Well, according to Sanders, it’s a bit of both, but it MUST be structured the same across investigative workflows. He attempts to achieve this by establishing a standard for these Human-Centered Investigations, which is quite clever, given his extensive background research in cognitive skills as a function of attaining better investigative results.
My co-worker and cloud security aficionado Seth Art presented his research this week on attacks against Amazon AMIs. I love this work because it demonstrates the end-to-end impact of security research on a detection team. He adopts an attacker mindset, identifies vulnerabilities in the implementation of pulling AMI images, and then builds detection opportunities so we can all defend ourselves against this vector.
☣️ Threat Landscape
Serial Hacker “IntelBroker” Charged For Causing $25 Million In Damages To Victims by U.S. Department of Justice
Tangodown for IntelBroker. There are pictures floating around of Kai that I won’t post here, but he looks like a normal person (to me) that got way over his head and is now facing lots of serious charges. He made a good amount from his alleged breaches at places like Apple, Pandabuy and ZScaler.
Justice Department Announces Coordinated, Nationwide Actions to Combat North Korean Remote Information Technology Workers’ Illicit Revenue Generation Schemes by U.S. Department of Justice
The newsletter is 2/2 this week, featuring indictments and arrests of cybercriminals! This is an interesting one because it targeted facilitators for North Korean IT Worker schemes. The VERY interesting tidbit is that one of the facilitators flew to China to meet with the conspirators. Do you think they had a JIRA board, aligned expectations and synergized action items? I always wondered if nation-states used dumb business speak like we do.
Profiling TradeTraitor: Tactics, History & Defenses by Invictus IR
Cloud Incident Response GOATs Invictus IR gives an excellent breakdown of TraderTraitor TTPs and detection opportunities. What I love about reading their blogs is that they not only focus on rule coverage, but also on the readiness of your environment to collect the right telemetry, as well as the controls that should be in place to mitigate most of it.
Local Privilege Escalation via host option by Sudo.ws
Fun local privilege escalation bug in sudo that abused how the command parsed host options in the command line. Here’s a sectionfr om the blog that sums it up perfectly
The bug effectively makes the hostname portion of a sudoers rule irrelevant since the user can set the host to be used when evaluating the rules themselves. A user must still be listed in the sudoers file, but they do not needed to have an entry for the current host.
For example, given the sudoers rule:
alice cerebus = ALL
user alice would be able to run sudo -h cerebus id on any host, not just cerebus. For example:
alice@hades$ sudo -l
Sorry, user alice may not run sudo on hades.
alice@hades$ sudo -l -h cerebus
User alice may run the following commands on cerebus:
(root) ALL
alice@hades$ sudo -h cerebus id
uid=0(root) gid=0(root) groups=0(root)
CitrixBleed 2: Electric Boogaloo — CVE-2025–5777 by Kevin Beaumont
Welp, yet another CitrixBleed 2 years after the first one. This CVE was assigned on June 17 and the memory disclosure vulnerability was only affected by a management interface that should NOT be exposed on the Internet. It looks like Citrix corrected that interface to be the one that is ALSO supposed to be exposed on the Internet. So hold on to your butts, I’m sure exploitation is coming, and Beaumont provides receipts with Shodan searches and everything to get started.
Oh, don’t forget the hilarious vulnerability name and picture.
🔗 Open Source
Security-Onion-Solutions/securityonion-resources-playbooks
Repository storing all of Chris Sanders’ investigative playbooks for Security Onion. I linked his research above under “State of the Art”.
gyrospectre/splunk_synthtesting
Lab environment for Bill Mahony’s detection testing I listed above in “State of the Art.” You can run the synthetic testing and alerting directly from a Python script, as well as check out some MITRE ATT&CK heat maps inside Splunk.
cybersectroll/TrollBlacklistDLL
Anti-EDR tool that creates a “blacklist” of DLLs to prevent from loading into Windows. It patches LdrLoadDll, then waits for the syscall to check if the target DLL is within the blacklist, then returns not found.
DFIR tool for MacOS. You provide it a MacOS disk image and it’ll render and output artifacts for deeper investigation of potential MacOS intrusions. Has a plugin architecture so you can write your own collection plugins for additional functionality.
Advanced Rust-based memory obfuscation tool to help hide your malware from those pesky EDR vendors. The idea is you want to keep executing your shellcode without getting caught, so you can leverage several techniques with hypnus to do so.