Det. Eng. Weekly #79 - is my ruleset brat enough?
TheNeedleDrop says its 10/10
Welcome to Issue #79 of Detection Engineering Weekly!
⏪ Did you miss the previous issues? I'm sure you wouldn't, but JUST in case:
💎 Detection Engineering Gem 💎
Preliminary Post Incident Review by Crowdstrike
This is a bit different of a gem: rather than ones that explore new topics or ideas, it's a "preliminary" post-incident review of Crowdstrike's IT outage that dominated the headlines for the last two weeks. I've gone back and forth on commenting on this other than "don't be a jerk," but this incident review does provide insight for us, as a community, to understand and form better opinions on the matter.
Post-mortems are among the most important learning opportunities for a company and, if made public, for the community. This one is particularly relevant to readers of this newsletter because it specifically focuses on the update mechanisms around Detection Content, a.k.a. the rules and filters shipped with the Crowdstrike agent.
Here's a visual representation of how I interpreted their report:
It's a good start for a post-mortem, but I have a lot more questions about their content validation pipelines and how content from userspace moves into kernel space with template types. Hopefully, they will provide more details in the coming days.
🔬 State of the Art
Windows Security best practices for integrating and managing security tools by David Weston
Speaking of post-mortems, this one is from Microsoft's side. They get into more details surrounding the bug while leveraging Microsoft error reporting toolsets. It's cool to see how Microsoft approaches analyzing these dumps while giving many interesting details on how security vendors use their operating systems to do EDR-like things. Here's a quote on the root cause:
As we can see from the above analysis, CrowdStrike loads four driver modules. One of those modules receives dynamic control and content updates frequently based on the CrowdStrike Preliminary Post-incident-review timeline.
I'm guessing the sensor detection engine is one of four modules referenced here. Why create a module and use kernel drivers in the first place? Weston gives thoughts on this in the last section and provides recommendations on what to put in kernel space, such as sensors and enforcement, while everything else should be run in user mode.
Anyone can Access Deleted and Private Repository Data on GitHub by Joe Leon
Truffle Security researcher Leon discovered a new type of vulnerability called Cross Fork Object Reference, or CFOR. According to Leon, GitHub has designed its ecosystem so that when you fork a repo, commit code to it, and then delete it, it can still be accessed.
This is done via their "repository" network design, which allows new root nodes to take over deleted nodes, such as upstream repositories, to preserve history. Leon has some fantastic videos and diagrams to showcase this vulnerability, but the impact is enormous: many leaked sensitive keys exist in deleted forks, and they found several.
Introducing Sigma Filters by Alex S.
Sigma now has filters! An important part of any detection strategy is the environment context. Allow lists and deny lists are one of many ways to ensure you focus on tuning false positives or false negatives. The good folks at SigmaHQ just shipped a better way to apply filtering to rules. Instead of doing a bunch of NOT statements in the search, the Sigma cli can take these filter statements and convert them to the corresponding search query.
Guide your SOC Leaders to More Engineering Wisdom for Detection(Part 9) by Anton Chuvakin and Amine Besson
Does your SOC implement your detection content in a lifecycle or ad hoc? Does it use rules from vendors, open-source, or internal rulesets? How do you manage all of that? Anton and Besson got you covered here - I appreciate the prescriptive nature of viewing detection as content and how content needs to be curated, cleaned, deployed, tuned, and decommissioned. I view content from any source as an upstream problem, and some level of filtering and tuning must happen before we deploy it to our systems. Anton and Besson both agree: they included a useful table with content models and recommendations to manage them.
Threat Hunting - Suspicious Named pipes by Mathieu Chot-Plassot
Did you know named pipes are an operating system primitive, not only native to Windows? They are all over Linux too! In this post, Chot-Plassot explores named pipes on both operating systems and provides detection and hunting opportunities for suspicious named pipes on both systems. NamedPipe on Windows is more feature-rich and can have specific applications communicate with each other locally and remotely in a client-server network communication model.
Lastly, Chot-Plassot hunted for potentially malicious named pipes and their properties throughout reports and tools and created a repo
🎙️ Detection Engineering Media
This podcast episode is somewhat of a continuation of last week's Security Conversations; the insights and conversations are too good not to post here. I don't want to spoil too much. Still, it's worth your time if you want to hear them compare the experiences of developing an EDR in another firm and developing kernel modules for these operating systems with the incident review above.
This is a super tactical and high-energy discussion about detection engineering at WP Engine. The guest, Christopher Watkins, has some amazing strategies for optimizing threat hunting and detection queries and managing a large cloud environment running one of the most targeted web technologies of all time: WordPress.
☣️ Threat Landscape
How a North Korean Fake IT Worker Tried to Infiltrate Us by Stu Sjouwerman
This is a WILD story on how KnowBe4 unknowingly (lol) hired a North Korean fake IT worker. In the theme of Ralph B.’s post last week on publicly documenting security incidents, it’s lovely to see someone showing everything that happened during an incident. KnowBe4 hired someone to do IT work and that person, posing as an individual authorized to work in the US, would collect the paychecks and send a bunch of it back to DPRK to help fund.. activities.
Onyx Sleet uses array of malware to gather intelligence for North Korea by Microsoft Threat Intelligence
Microsoft unveils new findings on Onyx Sleet, a DPRK-aligned threat actor group that originally focused on espionage but is now working on ransomware. The group leverages several N-day vulnerabilities for initial access and eventually uses its own ransomware strains to encrypt victim networks and extort them for monetary gain.
Security firm Guardio found a misconfiguration in several customer Proofpoint tenants that enabled attackers to leverage Proofpoint outgoing mail servers as a delivery mechanism. It basically comes down to some clever infrastructure analysis from the attackers: without validation of which O365 tenants can use Proofpoint, any O365 tenant can use it and spoof headers to deliver emails looking like they came from Proofpoint.
Matrix Cup: Cultivating Top Hacking Talent, Keeping Close Hold on Results by Eugenio Benincasa and Natto Team
The Matrix Cup is China's pwn2own combined with an attack and defense competition. This post discusses how China's "Honker" community (red hackers) participates in this competition, which serves as a point of pride for the community, a hiring pipeline, and a way to harvest 0-days without sending citizens to foreign countries where they are disclosed without the PRC's knowledge.
DigiCert Revocation Incident (CNAME-Based Domain Validation) by DigiCert
I like how they called this an incident. DigiCert, probably sweating bullets after the recent Entrust fiasco, found a bug in their CNAME-based validation process. Using an underscore in the CNAME record helps prevent name collisions during this validation process. Although the odds are low, non-compliance can mean the ban hammer from Chrome, so they sent a bunch of emails requesting folks to reroll certs with little time to prepare.
🔗 Open Source
diana by dwillowtree
D.I.A.N.A. is Dylan William’s project on leveraging LLMs to perform research and build high quality detection content for it’s users. Dylan’s research was featured as a gem on issue 71, and now the app is live! You can use several LLM backends, log sources you want to research and a target detection language and it’ll do the work for you.
suspicious_named_pipe_list.csv by mthcht
CSV list of suspicious named pipes from Chot-Plassot’s post above. Contains a ton of data and metadata on these named pipes to help with detection. Has all kind of pipe name strings and examples from a ton of C2s ranging from Cobalt Strike to Merlin.
CVE-2024-37085.yaml by Matt Green
Velociraptor configuration file to hunt for suspicious ESX Admin activity after the recent post-compromise CVE. Microsoft had a great writeup on it here.
BinaryNinja_shellcodehashes by PwCUK-CTO
Binary Ninja plugin to search for Shellcode API hashes. This is a port from the IDA plugin that finds shellcode hashes used by the FLARE team from Mandiant.
Sigma Filters Documentation by SigmaHQ
Documentation page for the Sigma Filter announcement listed above.