Det. Eng. Weekly #98 - Happy New Year!
Now get back to your corporate overlords, zug zug!
Welcome to Issue #98 of Detection Engineering Weekly!
It feels good to be back in the saddle. After Pasha passed away, I took a much needed (almost) 3 weeks of PTO. I started to get the itch late last week to start writing again. So much has happened!
I’ll be at Shmoocon in DC this weekend, if you see me or my Detection Engineering Weekly t-shirt, come say hi!
Find me on Socials!
One of my resolutions is to post a bit more on socials. I’m focusing on BlueSky and LinkedIn for now, I’d be grateful for a follow or a like!
BlueSky🦋 → Detection Engineering Pack (includes my profile) https://bsky.app/starter-pack-short/HenXJUR
LinkedIn → https://www.linkedin.com/in/zack-allen-12749a76/
💎 Detection Engineering Gem 💎
The (Anti-)EDR Compendium by Dobin Rutishauser
What is the architecture of an EDR, a massively effective security tool? Well, it’s hard to say. EDRs are kept trade secrets by the respective “big” EDR companies. Elastic is seemingly the only one where you can get documentation on architecture. Yet, I've always yearned for something like this compendium from Rutishauser: a massive deep-dive on Windows security concerning EDRs, with links and references to back up the research.
I won't lie: this is a massive post full of technical details. It took me coming back and reading 4 to 5 times over two days while taking notes and jumping back and forth to let the information soak in. But this is worth reading and bookmarking for Windows security.
There's lovely ASCII art accompanying most of the concepts. It reminds me of those old-school Operating System zines for Linux that I used to try to write crappy C code for Linux kernel rootkits.
The blog is split into three parts: Intro, EDR Detection and EDR attacks. EDR detection has fantastic, technical Operating Systems deep dive on how EDRs generally work, via the “Bubbles of Bane” model. Rutishauser introduces three different ways you can do EDR detection on Windows. It was nice seeing how loading an EXE into memory and where the EDR investigates the process via user-mode and kernel hooks, enriching via querying the kernel, and more intensive operations such as running tools like YARA over memory or the executable.
The last section focuses on EDR attacks, which I’ve documented several in this newsletter both in State of the Art & open-source repos. It ends with some tl;drs and advice for red teamers trying to avoid EDR detection, with yet another helpful visual :).
🔬 State of the Art
Recommendations on Naming Threat Actors by Alexandre Dulaunoy and Pauline Bourmeau
There are only two hard things in Computer Science: cache invalidation and naming things.
Phil Karlton
Security is hard, naming things is hard, but the hardest of all is using the same name for things based on the telemetry you have and you don’t have. If you want a parable, consider reading about the blind men touching an elephant. The tl;dr is that four blind men have never seen an elephant before, so they all feel the elephant and describe what they think it is based on their context. Naming threat actors runs into this exact problem.
Folks at MISP are trying to standardize around this problem, primarily due to the difficulty of clustering different actors' names around the same telemetry set. I like the idea in theory, but in practice, it may become much harder, and this RFC doesn't offer much in this interaction.
For example, Section 2.1 has this guidance:
Before creating a new threat actor name, you MUST consider a review of existing threat actor names from databases such as the threat actor MISP galaxy [MISP-G]. Proliferation of threat actor names is a significant challenge for day-to-day analyst work. If your defined threat actor matches an existing threat actor, you MUST reuse an existing threat actor name. If there is no matching threat actor name, you SHALL create a new threat actor name, following the best practices defined in this document.
Without the exact telemetry and investigative context, how do you know that “..your defined threat actor matches an existing threat actor?” What if your context has more evidence than some weird one-off name that a bunch of Twitter memers are using? Do all threat actors overlap 1-1, especially in a government or a criminal enterprise?
I'm interested in seeing how this is done in practice. Still, an interesting concept is attempting to anchor names to a singular source of truth. I don't know how marketing heads at Microsoft, Crowdstrike, or Mandiant would ever allow a research team to use threat actor names of competitors in a blog byline.
AttackRuleMap: Bridging Open-Source Detections and Atomic Tests by Burak Karaduman
This is a cool project that tries to extend detection logic in Sigma and Splunk ESCU and tie in Atomic Red Team tests to specific rules. Most modern software has associated tests: unit, integration, acceptance, and end-to-end tests, which all attempt to guarantee functionality before a piece of software hits production; why not do the same thing for detection rules? This post is Karaduman's launch of the AttackRuleMap, which tries to achieve this.
Drivers on macOS by Karol Mazurek
Imagine yourself playing Hacker Jeopardy, the final question, if you guess correctly you or your team wins. What is the name of the Kernel for MacOS?
If you didn't guess XNU, then you failed. Sorry :(. Since you failed, why not check out this in-depth blog post by Mazurek about MacOS drivers and kernel internals? I am pretty familiar with Linux kernel implementations and somewhat familiar with Windows, but I couldn't tell you anything about XNU. And since MacOS malware is on the rise, especially in the infostealer space, there will be more job opportunities for MacOS detection engineers. Although Apple is pushing folks to use IOKit, a user-space driver interaction framework, it's still good to see how other MacOS internals work with device drivers.
Announcing OPA 1.0: A New Standard for Policy as Code by Charlie Egan
Open Policy Agent (OPA) is a policy-as-code framework that leverages Rego to enforce policies on API actions in all environments. For example, you can write Rego rules to enforce OPA policies in Kubernetes admission controllers or evaluate cloud resources for secure reconfigurability.
It's a framework and language unknown to as many detection engineers as I would like, primarily because it focuses on secure configuration (a system state) rather than potentially malicious events. I'm excited to see they finally released OPA 1.0. I highly recommend checking out Rego and seeing how it can be used as a detection opportunity for your infrastructure.
Summiting the Pyramid: Bring the Pain with Robust and Accurate Detection by Michaela Adams, Roman Daszczyszak and Steve Luke
All I want to do after reading this title is listen to Method Man.
If you haven’t checked out MITRE’s release of Summiting the Pyramid, it’s an interesting take on determining the robustness of detections in the face of the Pyramid of Pain. Basically, how can a detection survive a changing threat actor environment, and catch adjustments that actors and the environment make to avoid the detection altogether?
My initial feedback for Summiting the Pyramid was around the hyper-focus on Windows hosts. In this post, the MITRE team launches a network detection model, which I am happy to see. You can overlay network detection on top of the host detection to get higher precision and recall, but there still seems to be a reliance on Windows rather than pure network or other mediums, such as Linux and Cloud. Still, this is a great direction!
☣️ Threat Landscape
BeyondTrust Remote Support SaaS Service Security Investigation by BeyondTrust
This post is Beyond Trust's disclosure of their recent security incident. This breach led to the downstream breach at the U.S. Department of Treasury via BeyondTrust's "Remote Support SaaS" product. I'm impressed by BeyondTrust's reporting here, there's several updates and what feels like a nice apology towards the end. These breach disclosures generally fall into legalese-speak, so it's cool to acknowledge customer's pain as a result of this incident.
EAGERBEE, with updated and novel components, targets the Middle East by Saurabh Sharma and Vasily Berdnikov
Kaspersky researchers reveal more information on the EAGERBEE backdoor. EAGERBEE was initially documented by Elastic Security and, according to Elastic, was most likely of Chinese-nexus origin. Kaspersky and Elastic say these malware families targeted ASEAN government entities, while Kaspersky claims they found targeting against ISPs. With the recent Volt and Salt Typhoon activity targeting U.S. ISPs, it's interesting to read about ISP victimology abroad from Chinese-nexus malware.
Astrill VPN and Remote Worker Fraud by Spur Engineering
Short-but-sweet blog by the good folks at Spur, documenting and releasing a dataset of Astrill VPN IP addresses. This is an important dataset for folks worried about DPRK IT Workers, as researchers have documented the use of Astrill VPN by the Democratic People's Republic.
Cyberhaven Extension Compromise by John Tuckner
This compromise couldn't have had worse timing with the holidays. A threat actor compromised an administrative account for the security firm Cyberhaven and leveraged it to backdoor a malicious version into their customer base. The extension acted as an infostealer and tried to exfiltrate sensitive information to their attacker-controlled domain, such as cookies and auth credentials.
John has a nice write-up here on what happened with tons of technical details, and he documented over a dozen more compromised extensions.
Hangro: Investigating North Korean VPN Infrastructure Part 1 by Nick / North Korean Internet Research
I love it when external threat hunting starts with 1 domain from a Reddit post! This website, North Korean Internet Research, seems to be dedicated to doing, well, North Korea’s Internet infrastructure. The author found a peculiar comment on a Reddit thread on obtaining a .kp TLD. A now-deleted user responded with their domain under hani.star-co.net[.]kp. This prompted Nick to uncover registration information, related infrastructure and Internet-history sleuthing to find out a potential VPN software called Hangro that allows folks from outside DPRK to access Internet on the inside.
🔗 Open Source
WhoYouCalling by H4NM
C# tool that can monitor a Windows process for network activity using ETW and do a full packet capture. According to H4NM, this solution is nice compared to ProcMon and Wireshark because ProcMon is more expensive to set up and doesn't capture DNS requests.
AttackRuleMap by krdmnbrk
An open-source repo of the Attack Rule Map post is above in State of the Art. Karaduman combines automated and manual processing of the attacks within the map and will update everything monthly.
copycat by vimpostor
Super clever use of the Seccomp Notifier API and BPF filters to "overwrite system calls of arbitrary binaries." This is a great abuse mechanism/red team methodology to evade detection on Linux-kernel-based systems.
CobaltStrike_OpenBeacon by ElJaviLuki
OpenBeacon is an “open-source implementation” of Cobalt Strike’s Beacon capability. For those who don’t know, Cobalt Strike is an adversary emulation framework (C2 server) with some incredible features to make post-exploitation easy-peasy. The problem for some folks is that it a) cost lots of money and b) is heavily restricted to Western customers.
OpenBeacon is an open-source implementation of this same concept, so it can open the doors for folks to use this if they don’t have the cash for Cobalt Strike.
YaraVM by milankovo
Security vendors (cough Microsoft) ship YARA rules in binary files. Maybe it’s a packaging thing to make it easy? Still, having access to those rules can be super helpful when hunting. YaraVM helps with this - it provides an IDA plugin to disassemble YARA rules inside a binary so you can extract out their selectors.
thanks for including my Hangro blog!