Det. Eng. Weekly #84 - I'm baaaaaaaaack
Det. Eng. Weekly #84 - I'm baaaaaaaaack
Did you miss me?
Welcome to Issue #84 of Detection Engineering Weekly!
I had a busy week of PTO with some travel and some staycationing. Being a “responsible parent” during a staycation mostly involves cleaning, fixing things or finishing random house projects, but I did manage to get some coding and video games in there.
This is your reminder to BOOK PTO (after reading this issue). DO IT!
⏪ Did you miss the previous issues? I'm sure you wouldn't, but JUST in case:
💎 Detection Engineering Gem 💎
Lessons Learned in Detection Engineering by Ryan McGeehan
This is a pithy post of detection axioms and lessons learned built by McGeehan through his time in threat detection roles. It’s pithy because many fantastic sections could be blog posts on their own, and I love how opinionated it is. The greatest part? It was written SEVEN years ago. SEVEN. And these axioms still hold true today. I can’t believe this is the first time I’ve read this!
He first lays out a detection infrastructure model, which is peppered throughout the post. It starts with data sources and moves through a series of engineering-focused layers until it arrives at employee or on-call alerts rather than a SOC. In fact, McGeehan rejects the idea of a SOC and recognizes it as a “declaration of failure” in putting the engineering in detection engineering. This thread of being more like engineers than analysts weaves each section together nicely via a concept known as a working lever.
He uses several examples, but the vulnerability analogy resonated with me. It’s much easier to discover a vulnerability, issue a ticket for a team to fix it, and pat yourself on the back than create a ton of downstream work for IT or engineering teams. So, by recognizing the detriment of creating more downstream work, detection engineers should balance the lever and engineer work away.
This post is essential for aspiring detection engineers, so I hope y’all read it!
🔬 State of the Art
Where do Detections come from? by Tim MalcomVetter
If you want a history of the SIEM market, detection content generation, and the evolution from the 2000s to today, MalcomVetter has you covered. Akin to Phil Venable’s post on Artisanal to Industrial security solutions, there is always a cost associated with how you run a detection program.
What products you have, your talent, and where you want to spend your time all factor into a unique calculus for every firm. The biggest takeaway I got from this post is the emergence of purpose-built detection products (and I work at one of those companies), where you get large enterprises focusing a ton of time on this content at a scale, and even large enterprises or MSSPs can’t even touch, spend-wise.
Telemetry on Linux vs. Windows: A Comparative Analysis by Kostas Tsialemis
This post covers critical differences between Windows and Linux logging and detection capabilities. I’m surprised I’ve never seen an analysis like this before because I get a lot of questions about my opinion between the two. I usually laugh at Windows folks about how easy they have everything due to the monoculture of their ecosystem, but 99% of malware targets Windows, and there are some crazy internals that make my eyes bleed as much as Linux logging facilities.
Kostas also brings his expertise in incident response and compares and contrasts different attack scenarios on the two operating systems, highlighting the benefits and pain points of each.
RansomGuard : an anti-ransomware filter driver by Windy Bug
I’ve been reading a lot about Windows filter managers in the Kernel, especially after the Crowdstrike outage. So, it’s cool to take the knowledge from that massive outage and use it to read on tooling that Windows filters can help with, such as preventing ransomware. In this post, Windy Bug walks through the Windows kernel filter ecosystem and sets up a PoC to detect when a process is potentially encrypting files, with ways to block it.
It was fantastic to see how they applied detection opportunities, such as Shannon Entropy, and the view of the operations graph of that process to stop ransomware.
Detection Engineering and Threat Hunting: 🤝🏼 by Danny Zendejas
This is a great post that helps differentiate detection engineering from threat hunting. It is super useful for those trying to build these functions out or folks who want to learn more while they enter this field. In a pure sense, detection engineers develop and maintain detections via a process that looks eerily similar to the software development life cycle.
Threat hunters leverage datasets they can access to generate hypotheses, hunt for potential threats, and identify gaps. Depending on the organization, they can work together in separate teams, be part of the same team, or be the same person.
Compound Probability: You Don’t Need 100% Coverage to Win by Andrew VanVleet
Andrew VanVleet is the only person I’ve read about in the detection engineering field who drinks the statistics Kool-Aid (other than myself!) and applies it to rules and alerts. In this post, he provides readers an explanation of a fundamental tenet of probability: compound probability.
Basically, if you flip a coin, it’s a 50% chance to be heads or tails. But what is the probability of getting heads every time? It’d be 1/2 * 1/2 * 1/2, which is a 1/8 chance. This same principle can apply to detection engineering in terms of coverage.
The post mathematically resists the boring adage that “red teamers only need to be right once.” If someone ever says that to you, send them this post and a video of you rolling a dice or flipping coins a bunch of times. I’m sure you’ll get the point across, and maybe lose a friend.
🎙️ Detection Engineering Media
In this episode of DISCARDED, hosts Selena Larson and Sarah Sabotka talk with Proofpoint’s APT threat research team members Greg Lesnewich and Joshua Miller. They provide an excellent update on the goings-on with the big APT groups that Western nations worry about. I’m always surprised by these two's technical cyber AND policy knowledge. If you can, search YouTube for some of their talks to get even more content on anything APT.
It's APT week for podcasts! Hosts Juan Andres Guerrero-Saade, Costin Raiu, and Ryan Naraine discuss the latest news about nation-state cyber activity. The big news from last week, the CISA advisory on GRU Unit 29155 doing cyber-y stuff, was a mainstay topic for the episode. They criticized CISA's report, and rightly so, because it was very hard for me to read, and it seems like they stuffed a lot of information into one report without a central thread running through it.
☣️ Threat Landscape
Russian Military Cyber Actors Target US and Global Critical Infrastructure by CISA
CISA’s report on Unit 29155 from Russia’s General Staff Main Intelligence Directorate (the infamous GRU group) is a mishmash of all kinds of TTPs, indicators of compromise, and analysis. The crazy part about this finding is this unit has been linked to all kinds of espionage activities you see in movies, such as poisonings, various assassinations, and blowing up ammunition warehouses.
Peach Sandstorm deploys new custom Tickler malware in long-running intelligence gathering operations by Microsoft Threat Intelligence
I can't imagine the poor soul deep in the U.S. intelligence committee who has to explain to their boss how malware named Tickler is deployed by a nation-state group with Peach in their name. According to MSTIC, Peach Sandstorm operates on behalf of Iran's IRGC. It focuses on initial access via password spray or social engineering to target education and defense firms. The cool part here is the group uses VPNs to buy Azure infrastructure for post-infection command and control.
ghmlwr: Malware on GitHub by David Miller
Neat project that tracks and stores potentially malicious GitHub repositories. The detection opportunity Miller uses here is looking at artificially boosted GitHub repos, based on their star and fork activity, to see if the malware authors are trying to inflate their popularity to look more legitimate.
Chinese APT Abuses VSCode to Target Government in Asia by Tom Fakterman
Chinese-aligned threat actors, such as Stately Taurus, used some super clever targeting of Visual Studio code to gain entry into target networks. The observed technique was first published in 2023 by a researcher, and to see it used in the wild must be an achievement and a travesty at the same time.
The malware used in this campaign is a living-off-the-land technique, where the Visual Studio Code binary establishes a devtunnel to a web environment that the attacker controls, which can execute commands on the remote machine. Shadowpad also rears its ugly head inside the infection chain. If you listened to the podcast episodes above, you would note that Fakterman has done a great job of analyzing whether this is the same threat cluster or a coordinated campaign between two clusters.
Threat Assessment: North Korean Threat Groups by Unit42
PAN/Unit42 has been hot these two weeks! This blog post serves as an up-to-date expose of the DPRK's cyber capabilities, specifically their Reconnaissance General Bureau. The blog highlights each of the tracked APT groups and their associated malware and links them to this year's MITRE ATT&CK enterprise evaluation for EDRs.
As Lesnewich and Miller said in their DISCARDED episode this week (linked above), these different groups are mandated to be like a startup with their ops: move fast and break things.
🔗 Open Source
fibratus by rabbitstack
Windows-based Golang detection engine all in the command line. You can write rules over it, as well as run YARA for memory detection, and it outputs to RabbitMQ/Elasticsearch and anything that takes JSON. It’s extendable with a built-in python engine via their “filaments” feature.
RansomGuard by 0mWindyBug
Anti-ransomware Kernel minifilter written by Windy Bug and linked above in the State of the Art section.
openbas by OpenBAS-Platform
OpenBAS is a project by the OpenCTI team that lets you build and deploy attack simulations. Great for detection emulation and can be integrated into your rule release or regression testing process.
ChromeKatz by Meckazin
Open-source Chrome cookie and sensitive information scraper. Similar setup to how infostealers look for secrets and sessions inside Chrome, hopefully when Google ships their new App-Bound Encryption primitives this technique goes away.