Det. Eng. Weekly #77 - Seventy times 7
🎵 So is that what you call a getaway? 🎵
Welcome to Issue #77 of Detection Engineering Weekly!
I hope I didn’t age myself too much with this week’s title. I really miss the emo and scene days.
I’ll be in the greatest city in the world next week to do some Datadog things. Issue 78 is coming out as scheduled, but with probably a few pictures from Datadog HQ which has an incredible view of the city.
⏪ Did you miss the previous issues? I'm sure you wouldn't, but JUST in case:
💎 Detection Engineering Gem 💎
A Five Year Retrospective on Detection as Code by David Burkett
It's hard for me to pinpoint exactly when the terms "Detection Engineering" and "Detection as Code" originated and started getting popular. In my circles in the threat space, the last four years have easily been the most I've seen people exchange ideas and build software to create these concepts for their organizations.
I can reliably say David is one of the earliest proponents of adopting engineering and DevOps practices for security. He wrote a 5-year lookback on the well-known/first-of-its-kind blog on the subject: Detectors as Code. When I pitch Detection Engineering/As-Code to others, I pitch it very similar to how David lays it out here: it's not about writing detections in a coding language; instead, it's managing the rule writing, testing, and deployment (and rollback!) of detections out into an environment. I like how David talks about this concept with examples here.
He also offers some predictions I am also observing an appetite for in the field: test-driven detections. It's an amalgamation of regression testing and some integration testing of your detections before they hit prod. Of course, we security practitioners rename things into something sweet like "threat emulation," but it's all just testing!
Lastly, he offers commentary on LLMs for Detections. Again, I love his thinking about this. Summarizing and explainability are much more helpful for a large corpus of nuanced text-like detections than having something write and deploy your stuff.
🔬 State of the Art
Charting the IOCs by John F
In this post, John F helps readers understand some of the technical nuances of technical indicators of compromise. Specifically, what does it mean to build detection, pivot, enrich, and visualize the relationship of IPs in Command & Control circumstances? But there's more to technical indicators of compromise and external threat hunting than IP:port combos. There's context: is it a server on a hosting service with awful anti-abuse policies? What if it's hacked infrastructure? What if the service knows exactly what they are doing and uses lame excuses like "freedom of speech" to ignore takedown requests?
They also released a really interesting tool called IOC-Cartographer, which helps visualize malicious infrastructure and gives you a better understanding of who's on the naughty list.
Introducing the REx: Rule Explorer Project by Justin Ibarra
Have you ever had 50 Chrome/Firefox tabs open while researching new rulesets or writing detection code? It's hard to do research: we suffer this paradox where we have so much good data that the data sprawl is so painful when trying to maintain it.
Well, REx looks to be the antidote to Chrome tab sprawl for detection engineers. Using the Elastic stack, Justin normalized data from the biggest open-source detection rule repos, plus hundreds of others, and made it available for everyone to query everything from these rulesets.
PySkyWiFi: completely free, unbelievably stupid wi-fi on long-haul flights by Robert Heaton
Covert channel post! This is a hilarious and self-deprecating post where Heaton found a way to proxy traffic from a limited WiFi connection on a flight to a server they controlled. It's one of those blogs where, while you are reading this, you keep asking the author: "But why? why do this?!" The most obvious answer, which is why I love security so much, is: "Why not?" I won't spoil it with too much detail; it's worth the read.
A hard look at GuardDuty shortcomings by Rami McCarthy
I've worked in the security product space for years. The problem with some security product selling strategies is that they try to sell you an idea, sometimes surrounded by fear, uncertainty, and doubt, hoping that's enough demonstration of value for you to sign a check. Doing sales correctly, IMHO, involves showing, not telling. A great avenue to do this with threat detection products is threat emulation.
In this blog, Rami explores using threat emulation to test AWS' GuardDuty product. He leveraged Stratus Red Team, AWS' amazon-guardduty-tester to look at findings inside GuardDuty, and a home-grown S3 ransomware & exfiltration tool. What's cool about emulation tools is that they are about as close to an authorized pentest as possible, where you can compare the inputs and expected outputs. The S3 results were most concerning, especially with the cost of data plane logging.
Building a Detection Engine Part 1 — What is a Detection Engine? by Nathan Burns
In this post, Burns describes their interpretation of a detection engine and the different detection engine types. The explanation was well thought out and easy to follow, especially given that Burns says they've been a detection engineer, "..[for a] relatively short time. It goes over some concepts I've taken for granted: on-host vs off-host engines, rules versus heuristics, and how EDRs operate at a high level.
It's part 1 of a many-part series where Burns builds a detection engine from scratch, so I'm excited to see what the next few posts entail!
🎙️ Detection Engineering Media
** Note, I am uh.. on this podcast! **
My podcast episode with Google's Cloud Security Podcast is live! Readers will hopefully hear some recurring themes in original content I've posted or linked to from some of the best in the business. Thank you all for helping me become an expert at detection and for letting me talk about this subject on such a great podcast!
The fun part about evasion techniques is that they generate telemetry, which is the exact thing threat actors try to prevent when they get on a system. In this podcast, the DISCARDED team interviews researchers and detection engineers at Proofpoint who specialize in evasion technique detection, both from a reverse-engineering perspective and writing detections for them.
☣️ Threat Landscape
AT&T INC. 8-K Breach Filling by AT&T
Nothing like an 8-K about a cyber breach to read in the morning! This is interesting because it's the first filing I've read where AT&T quoted the DoJ directive to hold off on filing so the FBI can go knock some doors down. According to the filing, that probably happened.
NullBulge | Threat Actor Masquerades as Hacktivist Group Rebelling Against AI by Jim Walter
It's been a while since I've seen a hacktivism threat post! NullBulge is a new actor on the scene that specifically targets AI & Gaming companies, and as of this week, claimed to have hacked Disney's Internal Slack communications. They claim noble causes, but many of their communications documented by Walter show them a group familiar with the infostealer log scene. Interestingly, they are overtly using software supply chain attacks to target victims.
Why CONTI has changed incident response — and why it’s not over by Simone Kraus
Detection and threat research guru Simone Kraus profiles the CONTI gang and some of their psychological techniques to pressure victims to pay. This is a prolific gang, and if you still need to read some of the Conti Leaks, you should. The leaks are a pretty incredible view into the day-to-day of an extremely organized crime syndicate, and they show how they approach breaking into firms' infrastructure. Simone will explore the split and the subsequent Cy-X gangs in another post, which I am really excited to read about!
Hunting Lazarus: Expanding Indicators with Historic DNS by Kenneth Kinion
The super fun part about being in threat research is the ability to take openly reported information, like this Lazarus domain, from a tweet and pivot to find more infrastructure. I have yet to play with Validin, but I'm posting this product because they have a community edition, which passes my sniff test of a good product.
It's always great to see more research being done on tracking threat actor infrastructure, and this is an excellent lesson in uncovering potentially more infrastructure from a singular domain.
This Meeting Should Have Been an Email by Patrick Wardle
I love reading Patrick Wardle threat writeups! In this post, Wardle takes a recent BeaverTail sample shared by MalwareHunterTeam and walks through his reverse-engineering process. BeaverTail is a DPRK malware set that tries to steal as much data as possible from victims. It is typically used in a social engineering attack against victims.
🔗 Open Source
Graphpython by mlcsec
All-inclusive Microsoft Graph API exploitation toolkit. Has lots of functionality to attack not only Entra and O365, but Microsoft Intune too!
IOC-Cartographer_TLP-CLEAR by Abjuri5t
Heatmap tool for visualizing IPv4 address spaces. Take your threat intel list, run this tool, and see which ASNs/IP spaces you should really focus on.
amazon-guardduty-tester by awslabs
Open-source threat emulation tool to generate GuardDuty findings. This was referenced in Rami’s post above!
barevisor by tandasat
A hypervisor written in Rust. Covers both AMD/Intel processors and Windows drivers. Pretty incredible way to learn how this all works under the hood.
BlockBlock by objective-see
Source code for Patrick Wardle’s BlockBlock project that he referenced in the Beavertail post above.