Det. Eng. Weekly #101 - 01001000 01101001
01110101 01110010 00110001 00110011 00110011 00110111 :)
~ Quick note from the Chief screwer-upper-of-newsletters ~
I must’ve excluded the Gem link and lookback posts when I copy/pasted from Notion to Substack. This is a re-issue. Sorry for the spam!
Welcome to Issue #101 of Detection Engineering Weekly!
⏪ Did you miss the previous issues? I'm sure you wouldn't, but JUST in case:
💎 Detection Engineering Gem 💎
Reverse Engineering Call Of Duty Anti-Cheat by ssno
Whenever I see an anti-cheat research blog post, I must include it in an issue. There's so much back-and-forth between cheat developers and anti-cheat staff at gaming companies. I still believe that EDR vendors pay special attention to cheat developers and talk regularly to anti-cheat folks because new techniques that bypass anti-cheat almost always directly apply to EDR and malware development.
One clever part of this write-up is how anti-cheat software detects overlay visuals in the game. The tl;dr is that you can "see through a wall" by drawing an obvious green box on another player's model, giving you x-ray vision and an unfair advantage in the game. The hard part is differentiating graphics over games using legitimate Streaming or Voice Comms tools. The clever part of the anti-cheat is they detect overlay windows across Windows and save the process, memory, and all, to upload to the anti-cheat backend for further analysis.
The last part I'll call out here is how the anti-cheat engine monitors Network Traffic. A common approach cheat devs use to hack these games is to inject shellcode directly into the game process and start a TCP server to send and receive data. ssno did not get into too many details of why this is an approach; I’m guessing it's a lightweight way to obscure the cheating software outside the process or computer. The command center check loops over the Windows internal TCP table owned by the current process (the game) and checks each entry for a client/server connection to an IP port outside the process; it’ll then kill the process.
🔬 State of the Art
CVSS is dead to us by Daniel Stenberg
Most of the pain we feel in security is what to triage and solve first. Detection engineers try to solve that by generating alerts rich in context and precise enough to find things with reasonable accuracy. However, triage is a much more systemic problem on the vulnerability side. The systemic issues are deeply rooted in the vendor ecosystem and singular institutions that most if not all, security teams rely on to give us accurate data for CVSS.
How Google Does It: Modernizing threat detection | Google Cloud Blog by Anton Chuvakin and Tim Nguyen
This is a great overview of how internal detection and response work at Google. The concepts and features are descriptive and not as prescriptive as I would like, but each concept is interesting to explore if you want to scale your program.
Anton and I have had several conversations on these topics, especially the last one: "Security engineering is software engineering." If you want to scale a detection program, you can do any of these three things: hire more people, buy technology to help, or build it yourself. A team with a foundation in software engineering gives you the most flexibility since many of the tasks listed in this blog can be automated away using sound software engineering principles.
Helloooooooo thrunters 👋 by Sydney Marrone
I'm excited to see this sneak peek preview of Marrone and Lauren Proehl's threat-hunting workshop from DEATHCON. I've linked several of their pieces of work around the subject, especially the PEAK framework, but it's nice to see a series dedicated to the practical application of threat hunting. For a quick reminder, there are three types of threat hunting in PEAK: hypothesis-driven, baseline, and model-assisted. I hope Marrone can publish Part 2 soon!
LOLRMM by the lololfarm aka MagicSword-IO
The good folks at the lololfarm dropped another database of living-off-the-land intelligence, this time focused on Remote Monitoring and management (RMM) binaries. This software is essential for many IT helpdesk workers and makes a lot of sense. When you get a ticket from Alice and Bob that their computers aren't working, you can log in remotely to troubleshoot instead of running to their desks.
The issue with RMM is it's a fantastic command-and-control and persistence mechanism for ransomware operators and APTs. The traffic doesn't look as shady as a Cobalt Strike beacon, and if the RMM is part of the IT stack, they can evade detection even more.
nt-load-order Part 1: WinDbg'ing our way into the Windows bootloader by Colin Finck
This week's newsletter is full of detection-adjacent content! I love reading about the workflows of reverse engineers in other fields. It can clarify how you can get better at reverse engineering, analysis, and OS internals. Finck does just that in this post by setting up a debugging and analysis environment for the Windows bootloader. Their original motivation was building a complete Rust-based bootloader. I couldn't help thinking how this has applications for bootloader malware that are becoming more popular.
It's an information-dense read but well worth it if you want to learn how to set up an environment without access to the underlying OS. Finck built a WinDbg workflow where they connect to a Windows VM early in the boot process and have all kinds of ways to bring in symbols and analysis scripts to make things easier to read. I'll be reading Part 2 and will most likely post it next week!
🎙️ Detection Engineering Media
I joined Alex Hurtado on the Detection Engineering Dispatch podcast to talk about Detection Engineering! Our conversation revolved around green flags and beige flags, and what I’ve looked for when trying to build the detection engineering organization at Datadog. Please check it out and give the podcast a subscribe!
☣️ Threat Landscape
Datadog threat roundup: top insights for Q4 2024 by Matt Muir, Andy Giron, Adrian Korn, Greg Foss and Oren Margalit
~Note, my employer is Datadog, and all of these authors are my wonderful colleagues~
The Security Research & Detection Engineering team at Datadog sees many unique, cloud-native threats. This threat roundup is a new format for the team to round up all the campaigns we've tracked across our telemetry. We are seeing lots of criminal and nation-state activity now, so please check it out and let me or the team know if you have any feedback or questions!
Massive FortiGate Config Leak: Assessing the Impact by Censys Research
Another week, another appliance vulnerability and exploit campaign, this time with a database leaked to cybercriminals for free! According to Kevin Beaumont, this breach was the result of an authentication bypass tied to CVE-2022-40684. The Censys team did the community a solid and parsed the leaked data to find Fortinet devices that are still listening on the internet. They found close to 10,000 listening, with about 5,000 exposed login interfaces.
Hackers Actively Exploiting Fortinet Firewalls: Real-Time Insights from GreyNoise by Noah Stone
Continuing on Censys’ research above, Stone and the GreyNoise research team investigated internet traffic exploiting this list. They found 366 distinct IP addresses engaging in scanning the internet for vulnerable Fortigate appliances and attempting to exploit them.
Phishing for Refresh Tokens by Rik van Duijn
Long gone are the days of phishing sites looking for usernames and passwords. With the rise of AitM phishing kits, attackers can take 2FA prompts directly from the victim and, "steal" a session token and login as the victim. In this blog, van Duijn explores the OAuth 2.0 workflow and showcases how to insert an AitM phishing kit to steal access and refresh tokens. What's nice about this is a) the access token gets you into the service or tenant, and b) the refresh token gets you new access tokens once they expire. Persistence!
The J-Magic Show: Magic Packets and Where to find them by Black Lotus Labs
This is a unique threat writeup on attackers who are finding vulnerable, publicly facing Juniper routers. Much of the reporting on massive vulnerabilities is typically on security edge devices, such as pure firewalls and VPN appliances. In this scenario, the threat actor had a clever two-pronged approach to infection. First, they created an eBPF filter rootkit to look for specifically crafted "magic" packets. Once found, the infected device sent an encrypted challenge back to the C2 server, and if it got a correct response, set up a reverse shell.
🔗 Open Source
YaraMonitor by montysecurity
Super lightweight and stream-based YARA tool that can take in arbitrary sources of samples and run YARA rules on top. The out-of-the-box functionality polls MalwareBazaar to run rules, but you can extend the feed into whatever source you have.
EByte-Ransomware by EvilBytecode
A *** for educational use only *** Go-based ransomware project with some impressive encryption primitives. Also contains a web-panel for your infected hosts. If you go on Telegram and pay the author, you can unlock chat and source code! Totally for educational use only!
seccomp-diff by antitree
Analyze binaries and containers to build seccomp-bpf profiles. You can then compare and contrast layers of a container to get the actual seccomp filters implemented in the container, which can be fudged up if you have many layers while building the container.
ExtensionHound by arsolutioner
Interesting NDR-like Chrome extension that monitors DNS queries from your extensions and generates telemetry for additional pivoting and response.