Welcome to Issue #75 of Detection Engineering Weekly!
Happy 4th of July week to my fellow Americans and American-aligned threat actors. I hope everyone’s grill fires are hot, outrageous American t-shirts are clean and pressed, and pagers quiet for this year’s Independence Day.
⏪ Did you miss the previous issues? I'm sure you wouldn't, but JUST in case:
📣 Issue #75 Sponsor: The CloudSec Engineer
📙 The CloudSec Engineer is out now!
The CloudSec Engineer is a practical guide on how to enter, establish yourself, and thrive in the Cloud Security industry as an individual contributor.
You can head over to engineer.cloudsecbooks.com to find more information about the book, its contents, and where to buy it.
💎 Detection Engineering Gem 💎
Proving Non-Impact by Matt Linton
This post helps frame the frustrations of investigations based on the labeling of an alert, log, or just a question. When I say labeling, I mean false positive, false negative, true positive, and true negative. In a hierarchy of work to be done, the elusive “negative” is a massive source of frustration. You either did not alert, and nothing terrible is happening (excellent!), or you did not, and something bad IS happening (not so great!). So, what happens when you do not alert and need to prove that it’s okay you didn’t? This is solving for negatives.
Linton highlights the danger of these investigations for a detection and response team. I like the apt analogy of a Mayor trying to protect a city from crime and giving instructions to police officers. “Patrol for badness” versus “Oh my gosh, find people who have been robbed, and we have these weak locks on doors; surely someone abused them,” rung several alarm bells in my soul. My favorite paragraph from the reading talks about these types of “prove the negative” investigations:
“When an investigation is needed, we should provide our stakeholders with a complete list of hypotheses for what might have happened and our level of confidence that those things did or didn’t happen. For this reason, it helps to keep a hypothesis list as your investigative output for a prove-the-negative investigation. Each hypothesis can be described in advance, along with what data is available to investigate it, whether any certainty can be obtained (and how much), and what conclusions the stakeholder can draw.”
🔬 State of the Art
The Normalization of the Unacceptable by Joe Slowik
This nuanced post by Slowik helps ground some of the craziness of ransomware events back to reality. As a society, we can grow comfortable accepting the unacceptable, and in this case, ransomwaring hospital and medical system organizations mostly leads to a shrug and a “shit happens” response from a lot of people. Slowik then questions U.S. policymakers decision points to focus on future threats and not try to make meaningful changes to the threats happening right in front of us.
Also, can I point out that Slowik is an excellent writer? His work reads in a super articulate fashion, and I feel much smarter everytime I read his stuff :).
Detection Engineering Fundamentals: What makes a good alert? by br4dy5
This blog provides a ton of pithy and opinionated views on the ideal state of an alert for a detection engineer’s main customer: a SOC analyst. I read so much detection content that focuses solely on the fidelity of an alert. This is the best approach (IMHO) to meaningfully impact the cost of investigation. But what happens when an alert does get through? According to br4dy5, the next step is providing as much context to “investigative answers” as possible.
I love seeing more research into this area from the field because alert experience matters just as much as alert fidelity.
Reverse engineering eBPF programs by Amit Schendel
eBPF is getting much more attention these days, both from an observability and security standpoint.
In a previous gem, I linked a post about EDR across OSes (not just Windows) and the closest to an EDR on Linux-based systems are eBPF programs. Schendel takes eBPF analysis on a separate path by reverse engineering compiled eBPF programs without access to the underlying source code. They provide some intuitive information on the structure of a program, the syscalls it uses, and how it interacts with the Kernel, then they reverse a “malicious” eBPF rootkit to drive their blog home.
Evading Event Tracing for Windows (ETW)-Based Detections by Adrián Díaz
Windows ETW is reliably the first technology that many readers of this newsletter interacted with when they started detection engineering. If you want a deep dive into the operating system architecture behind ETW, how it interacts with the Windows Kernel, and, of course, how to bypass some of the sensors and providers. Díaz focuses on tampering and evading defenses by intercepting several ETW providers like ProcMon or straight-up flooding the providers to make them miss critical events like loading staging malware.
Detecting Linux Stealth Rootkits with Directory Link Errors by Sandfly Security
Rootkits spend a lot of time making sure they are hidden from userland. Many rootkit analyses I read about involve interrogating the Kernel using several tools that dive deep into Kernel internals. But what if you can use userland commands to catch inconsistencies in outputs and help identify leads for kernel detections? The team at Sandfly showcases some straightforward and practical techniques for doing this using basic Linux userland commands. Pretty clever!
🎙️ Detection Engineering Media
This podcast episode looks like a new format for Security Conversations. It's part news but part deep dive, which I really appreciate. The hosts perform a massive deep dive on Nation-State cybersecurity research and some ethical dilemmas behind burning" discovered exploits or infrastructure and how it can affect ANY nation-state operation, not just those we deem as the "bad guys."
I think this is a great DISCARDED episode if you come from a Computer Science or Software Engineering background and want to get into security, or even better, if you come from a security background and want to explore more what it looks like being a software engineer in a research organization.
☣️ Threat Landscape
TeamViewer IT security update by TeamViewer
Lots of supply chain and APT threat activity this past week! APT29, aka Midnight Blizzard, pwned TeamViewer, and according to the company, it did not manage to touch the product environment. According to the IT RMM software giant, the threat actor leveraged stolen employee credentials to gain access to their corporate IT environment and collected employee data and some encrypted passwords.
Understanding the Polyfill Attack (Polykill) by James Berthoty
Polyfills are convenient Javascript tools that help deliver modern browser functionality to much older browsers and ecosystems on a website. The big news story from last week involves a "supply-chain" attack on polyfill[.]io, which a company based in China acquired in the last year. According to several sources, the CDN delivering this popular Javascript library was redirecting users to malicious websites, making it a supply-chain attack.
Is the attack intentional or unintentional and mismanaged? But, it's good to see folks analyzing this and comparing whether or not a product would've stopped this.
Sustaining Digital Certificate Security - Entrust Certificate Distrust by Chrome Security Team
The certificate ecosystem is fascinating. You control millions upon millions of installs on an endpoint, and at any time you can influence how these users interact with the Internet. This is especially useful if you find organizations or companies that need to play fair or are doing naughty things. In this case, Entrust lost its seat at the Chrome table, and Chrome pulled its signed trust of the Entrust root certificates. And just like Thanos snapping his fingers: Entrust gets effectively nuked from the certificate orbit.
The Rise of Packet Rate Attacks: When Core Routers Turn Evil by Sebastien Meriot and Christophe Bacara
Packet rate attacks target a separate piece of infrastructure (other than your services): the edge device directly in front of your service. Think of load balancers, CDNs, and reverse proxies instead of the service or application logic itself. The goal is to overwhelm these servers with "a lot of small packets" since compute costs are higher.
I love DDoS research because it's still very real, threat-wise, but is talked about less than 10-15 years ago.
regreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems (CVE-2024-6387) by Qualys Threat Research Unit
Who doesn’t love an emerging vulnerability affecting a core Internet service on a Monday? The Qualys team found a peculiar signal handler race condition in OpenSSH that was re-introduced, yes re-introduced, back into the source code after being patched in 2006. Under the right conditions, an attacker can achieve RCE on a modern OpenSSH installation.
🔗 Open Source
sinon by referefref
This is a WILD project that leverages LLMs and deception tech to do something really useful. refrefref's tools have been featured in this newsletter before, and they seem to be doing a lot of work in the deception tech and honeypot space, which is great!
Sinon is a tool that “burns-in” deception hosts and content into your environment. It uses generative AI capabilities to randomize it’s interaction with the internet and with the honeytokens it generates, installs applications and browsers for you, logs into email inboxes, then generates lures to alert on anyone interacting with it.
1D-CNN-Anomaly-Detection-via-CASPER by hkayann
Detection engineering adjacent repo that does anomaly detection on industrial robotic arms. Maybe it will only find cyber threats if Skynet takes over Robotic arms.
ELFieScanner by JanielDary
A C++ project that performs process memory scanning to find malicious techniques used in malware. The README says it can find several techniques, including shellcode injection, process hollowing, API hooking, and more. They loaded some Kibana mappings to send data to an ELK stack easily.
APT_REPORT by blackorbird
Massive collection of APT reports, technical threat intelligence indicators, YARA rules and everything in between. There are also some threat-hunting playbooks to help you find all kinds of nastiness on a target network.