Det. Eng. Weekly #83 - My alert queue: very demure, very mindful
My handoffs only show a little chichi, no chocho
Welcome to Issue #83 of Detection Engineering Weekly!
Happy end of summer! I will be taking some much needed time off next week so Issue 84 will come out on Sept. 11.
📣 Conference plug: MSSN CTRL, Security Automation & Engineering Conference
Oct 2 - 4th, 2024 - Arlington, VA
MSSN CTRL is an immersive three-day event designed to equip you with cutting-edge practices and innovative tools that will change the way you think about how you defend your organization or customers. Security engineers and leaders will dive deep into cutting-edge automation techniques, explore innovative tools (with no vendor pitches), and collaborate with like-minded peers to solve complex security challenges and fortify their organization's defenses.
Join some of the industry's most progressive minds at MSSN CTRL and be a part of shaping the future of cybersecurity. You can learn more at mssnctrl.org
~ this is not a sponsored callout ~
⏪ Did you miss the previous issues? I'm sure you wouldn't, but JUST in case:
💎 Detection Engineering Gem 💎
Ok if it isn’t super clear. That’s me ^ and that’s a recently published video of my talk at SLEUTHCON. I’m super proud of this one because it’s a bucket list conference to speak at, as well as I wanted to really nail my subject matter. If you want a talk about detection and intelligence with a cybercrime focus, please check it out!
🔬 State of the Art
Beyond the CVE: Analyzing the Depth of GitHub Security Advisories by Kyle Kelly
Secondary sources for vulnerability data, especially after the collapse of NVD's program earlier this year, are great for the security operations ecosystem. GitHub publishes its own advisories database, which primarily focuses on packages inside various developer registry ecosystems, such as Go (go.dev), Node (npm), and Python (pip), to name a few.
Throughout this post, Kelly reviews GitHub's Security Advisory Database and compares and contrasts it with other vulnerability sources. The "unreviewed" advisory table is daunting, with over 220,000 unreviewed vulnerabilities, and around 6,600 of them belonging to the Linux kernel. You can do some pivoting on this table, such as sorting by critical severity (19,600 ish as of writing this analysis).
Security Operations Framework by Julian Cohen
Modern security operations teams are responsible for much more than alerts and investigations
What a great quote to start this blog post! Cohen provides readers with several capabilities that have made him successful in building security operations frameworks as a security leader. I love seeing detection engineering inside this list, but it was cool to see not-often-mentioned capabilities that a security operations team should have. Legal, internal communications, external communications, and team relationships matter just as much as a detection or response practice.
Cohen also separates "threat feeds and information sharing" from "threat intelligence," which is a nuanced but correct take that I'll happily argue with anyone on :).
My Methodology to AWS Detection Engineering (Part 2: Risk Assignment) by Chester Le Bron
There are a lot of "Part 2" posts in this week's issue! In Le Bron's Part 1 post, he demonstrated how he performs risk-based alerting on AWS objects inside Splunk with plenty of examples. In Part 2, you can see the methodology in action with his querying methodology. Once you send alerts to your alert index, you can collate all the risk objects inside the index, map them to an entity, and then sort on the risk_score.
I appreciate the section on deduplication of events because they can conflate the risk score, and because AWS has a small API compared to event types in Windows or system calls from eBPF in Linux, you can create tables with a cryptographic hash and remove duplicates from your search.
Graphing Credit Card Fraud Using STIX 2.1 by David Greenwood
This is a different style of detection and investigation post I put on the newsletter, but still super interesting nonetheless. Have you ever thought of a credit card number as technical threat intelligence? Maybe if you work on fraud teams in financial services; otherwise, it's not part of the investigation curriculum for most threat intel courses (as far as I know!)
Greenwood built out a credit card to STIX 2.1 object converter to visualize credit card dumps from criminal marketplaces. After building these relationships, he then dumps it into ArangoDB to query in a graph format, and gives some helpful query examples for investigators to action on cards.
Bob and Alice in Kernel-land - Part 2 by Matt Suiche
Suiche continues his exploration into the EDR ecosystem by exploring how Microsoft enables EDR vendors to leverage minifilters to write their kernel access tools. What’s interesting about this exploration is he overlays it with some recently released vulnerability data on these filters, which can lead to privilege escalation or full RCE. After obtaining the list of drivers from Microsoft’s documentation, Suiche built a list of files that request this driver access, alongside the company, in a publicly available spreadsheet. This was the most surprising tidbit from his analysis:
At least 1,608 out of 2,069 drivers are associated with security products, including at least 1,152 drivers (Activity Monitor + Anti-Virus) used for endpoint security from a staggering 637 endpoint security vendors.
Building a Detection Engine Part 2 — Collecting Our Data by Nathan Burns
Continuing on Burns' Part 1 of this series, he sets up readers to build out the telemetry collection portion of his detection engine project. This is an AWS-heavy environment, so if you are unfamiliar with some of these technologies, dive into this post because he does a great job explaining everything. After launching the collection infrastructure, Burns leverages osquery as the endpoint agent, which allows direct integration into Firehose, which he launched via Terraform.
🎙️ Detection Engineering Media
Josh Liburdi and Dan 'The Salary Transparency Man' Cao join the Detection at Scale podcast to discuss all kinds of detection and response topics. My favorite section of the episode involved an honest discussion between "build" versus "buy" of security tools, and how everything comes down to shifting cost to a product versus in-house. They reminded me of Phil Venables blog on "artisinal" vs "industrial" security solutions.
If you are ever interested in APT research and the ecosystem of government-level threat actors, this is a great podcast episode to listen to. Ryan, Corsin and Juan dive deep into topics surrounding attribution, the responsibility of investigating APTs regardless of your nation-alignment, and publishing research on APTs.
☣️ Threat Landscape
The gift that keeps on giving: A new opportunistic Log4j campaign by Andy Giron, Frederic Baguelin, Eslam Salem and Matt Mills
~ Note, I am an employee at Datadog and Andy, Fred, Eslam and Matt are my colleagues ~
The Datadog Security Research team sees a lot of stuff, both in our telemetry and honeypots, and it was peculiar seeing Log4shell still being thrown at our honeypots. Once we dug in, the team found some interesting post-exploitation techniques we hadn't seen before, so they put together a great blog post detailing our findings.
Bling Libra’s Tactical Evolution: The Threat Actor Group Behind ShinyHunters Ransomware by Margaret Zimmermann and Chandni Vaya
Besides having a sick threat actor name (how did they manage to get "Bling"?), the group behind large breaches such as GitHub and Tokopedia (and I worked with Lil Hay Newman on WIRED for Tokopedia) is still kicking around. I love how Zimmermann and Vaya leverage lay out these threat actor posts mapped to ATT&CK. Notice it's all cloud-focused, which I discussed in my SLEUTHCON talk above.
Double Trouble: Ransomware & Hacktivism Collaboration, Fact or Fiction? by Anastasia Sentsova
I got into infosec during the height of Anonymous and hacktivism in the 2010s. It's weird seeing this term back in the media mix, but as Sentsova points out, these emergent "Hacktivist-like" groups align with state interests and are likely influenced by the state itself. Sentsova also points out the close ties to hacktivist-like groups in Russia with ransomware operations.
Unveiling sedexp: A Stealthy Linux Malware Exploiting udev Rules by Zachary Reichert
Sedexp is a Linux malware cluster uncovered by Reichert that leverages some novel persistence techniques with udev. This subsystem manages devices being plugged into the system, like USB devices, and the OS runs different drivers or scripts when the device is plugged in. The authors of sedexp figured out a udev rule that when /dev/random
is loaded into the system, the malware executes its persistence mechanism (a program), and since /dev/random
is loaded _all the time_, it's pretty reliable.
🔗 Open Source
GitHub-Actions-Attack-Diagram by jstawinski
Super detailed attack graph for all kinds of bad stuff you can do to GitHub actions. I like how rooted in the real world this diagram is: it’s based on research published during hacker summer camp this year, as well as attacks seen in the wild.
linkedIn_auto_jobs_applier_with_AI by feder-cr
Auto-applier for jobs on LinkedIn with python and OpenAI. I know the platform has spent a lot of time making sure it can prevent automation from scraping and bots, so we will see how long this lasts. It also auto formats your application based on the job description.
windows-api-function-cheatsheets by 7etsuo
Massive cheatsheet on Windows API functions for malware developers detection engineers.
USP by grahamhelton
Very recent GitHub repo leveraging the udev persistence mechanism linked in the Reichert blog post above.
sectemplates/bug-bounty by securitytemplates
Prescriptive template on setting up a full bug bounty program. I like how it focuses on working with vendors and stakeholders, and even contains metrics you can use to justify it to others in your firm.