Welcome to Issue #110 of Detection Engineering Weekly!
I’ve been enjoying Holiday in Europe with my family, and we’ve loved staying in Paris. There’s lots of things to do, and we timed staying in the city when Spring temperatures started to hit. I’ve learned that you look and sound more Parisian at a bakery if you order a “tradition” when ordering a baguette.
My wife snapped a photo with two very important grocery items on a walk back to our AirBnB:
⏪ Did you miss the previous issues? I'm sure you wouldn't, but JUST in case:
💎 Detection Engineering Gem 💎
Inside Riot Vanguard’s Dispatch Table Hooks by Archie
Like most anti-cheat-related posts I post here, this one is dense and full of technical information on a Kernel-level anti-cheat system. Archie's blog focuses on Vanguard, Valorant's anti-cheat system. Unlike other posts I've linked with anti-cheat software, Vanguard is a Kernel mode driver, unlike a user mode driver, which means it's akin to a Windows rootkit or EDR. The difference between a Rootkit or an EDR is that it only runs when the Valorant process is started, so it's hyper-focused on catching cheats inside Valorant.
When you see rootkit-like functionality, you should ask yourself: What is it hooking? The idea behind function hooking is pretty simple: You can add, remove, inspect, or edit function parameters and data for analysis or evasion. Archie's research focuses on the Nt!SwapContext hook derived from Kernel device drivers.
Vanguard is loaded via a Kernel driver. It loads a Windows hardware abstraction layer (HAL) structure and sets itself as one of the first entries in that structure, called the HalPrivateDispatchTable
. Once the function entry is replaced, it points to a Vanguard-controlled function, specifically hooks Nt!SwapContext
calls are called anytime a thread context switches. It's a clever hook since it's frequently called on Windows.
I worked with ChatGPT for a more visual representation here: here:
+-----------------------------+
| Windows Kernel Space |
+-----------------------------+
|
v
+-----------------------------+
| HalPrivateDispatchTable |
| (Function pointers) |
+-----------------------------+
|
v
+-----------------------------+
| nt!SwapContext |
| (Context switch function) |
+-----------------------------+
|
v
+-----------------------------+
| Vanguard Hook |
| (Monitors thread switches) |
+-----------------------------+
[**] Thread switch happens via nt!SwapContext [**]
+-----------------------------+
| System Call Entry Points |
+-----------------------------+
|
v
+-----------------------------+
| KiDynamicTraceMask / |
| PerfGlobalGroupMask |
| (System call tracing) |
+-----------------------------+
|
v
+-----------------------------+
| Vanguard Monitoring |
| (Tracks system calls) |
+-----------------------------+
🔬 State of the Art
Docker Explained: Finally Understand Containers Without Losing Your Mind (Probably) by Marcos Dedeu
If you are unfamiliar with Docker, this is a great introductory blog post on how it works and how you can use it for your work. There's a software engineering and DevOps spin to this, but replace those concepts with security-focused use cases like building a reproducible, vulnerable app and PoC, detonating and testing your malware in a contained environment, or running attacks to generate telemetry and validate your rules.
Security and SRE: How Datadog's Combined Approach Aims to Tackle Security and Reliability Challenges by Bianca Lankford
~ Note, I work at Datadog, and Bianca is my brilliant colleague ~
Our Security Engineering team at Datadog was born to do, well, security stuff! But, as it scaled out, it became more akin to a powerful organization that keeps Datadog running: Site Reliability Engineering (SRE). After some alignment, my coworker, Bianca, combined the two to streamline security throughout the fabric of Ops and SRE, and the results have been super interesting.
I’ve always talked about how Security orgs tend to steal ideas and concepts from Developers and SRE, so it was cool to see this effort come to fruition.
The Heart of every Incident: Incident Coordination by Moritz Oettle
Picture this: an alert fires. It's a high-fidelity alert. You get a message on Slack from one of your workflows that a CRITICAL just fired on one of your crown jewels. Several other alerts fire off: malware was run, and data is being exfiltrated. You put on your response sunglasses while muttering "hell yeah" under your breath; you page your colleagues and put on Lofi Girl's Synthwave playlist.
Everyone jumps on a call, isolates the host, kicks the bad guy out, patches the host, and goes home. Smooth right?
Well, sorry to burst your bubbles but it's never that smooth. Incidents are chaotic due to the fog of war and sometimes panic, mainly if you aren't used to the chaos. This is where a great incident response team has an Incident Commander. And this is what Oettle talks about in his Incident Coordination piece. I particularly liked the "Building Blocks" section, not just because you are working the incident and kicking the bad guys out, but because there are FOLLOW UPs such as baseline hardening and lessons learned.
Cloud Incident Readiness: Key logs for cloud incidents by Invictus Incident Response
Are all cloud logs created equal? Well it depends on the Cloud Service Provider, but if it's Microsoft I'm sure they'll tell you all of them are important and will try to charge you one bajillion dollars for access.
In all seriousness, when it comes to cloud and SaaS incident response, logs aren't created equal. More is better from a forensics perspective, but it's cost-prohibitive.
Logs are typically bucketed into management events (control plane) and information events (data plane). A control plane log example is an administrator logged into a console and a data plane log example is an IP address accessed a file on blob storage from Greenland. So which ones should you get?
The Cloud IR GOATs, Invictus, have you covered there. I like reading Incident Response blogs because they jump into situations where they wish they had certain logs or telemetry for deeper forensics so they can help detection engineers prioritize which ones matter the most. They separate the logging types in Amazon, Azure, and GCP into control and data plane events and by product types, mark each by must haves, should haves, and nice-to-haves.
My SIEM-Agnostic Creative Process to Detection Engineering by Ryan G. Cox
This post answers a question that I don't see many people write about and try to answer: when writing a rule, how do you actually go about doing it? This isn't just about writing Sigma but the soup-to-nuts approach from ideation to implementation. How can you write a Sigma rule for CloudTrail if you don't understand how CloudTrail is structured? Even if you understand how it's structured, how do you know what legitimate traffic is versus known, observed threat activity?
These are the questions and steps you should take when building rules. Cox lays them out almost like swimlanes or columns in a JIRA board. So you can move your detection task along each phase as you progress through the process, and of course, you can context-switch if you need to work on other things and pick up right where you left off.
☣️ Threat Landscape
Operation Endgame follow-up leads to five detentions and interrogations as well as server takedowns by Europol
Europol and LE partners announced another iteration of Operation Endgame, targeting SmokeLoader. I like how law enforcement is "shifting left" of ransomware, going after initial access vectors, including malware like SmokeLoader, and arresting and charging people who set up the ecosystem that makes ransomware effective.
Sell Forum Accounts & Report Cybercrime Anonymously by ProDaft
Threat intelligence firm ProDaft announced a new program where threat actors can sell their criminal forum accounts to the company. This is a wild concept; they market it to people who have a change of heart or have "come across something unethical or against your values." I'm unsure what the legality of this is, but it's definitely a bold step.
Fortinet Releases Advisory on New Post-Exploitation Technique for Known Vulnerabilities by CISA
CISA released some guidance on a threat actor abusing three older Fortinet vulnerabilities. It's based on Fortinet's blog, which describes a cheeky technique in which the malicious file wasn't detected because it was on the user's filesystem on the device, not a system one, via a symbolic link.
Atomic Stealer: Dissecting 2024's Most Notorious macOS Infostealer by Sila Özeren
This is a good breakdown of Atomic Stealer split by MITRE ATT&CK technique. I definitely concur with the author here that the malware family was a top one for macOS infections last year. Its privilege escalation technique remains the same: using osascript to prompt a user for their administrative password.
🔗 Open Source
OpenAIPot by refrefref
This is a sweet OpenAI focused honeypot. It’s an intentionally exposed API service that connects to OpenAI and “lures” attackers to use it to find legitimate stolen keys, and fed false “lure” keys and prompts to capture would-be attackers.
attache by Datadog
Attache is a cloud-agnostic IMDS-like service that can sit on top of your cloud infrastructure as a replacement for instance metadata endpoints. It’s a pain in the butt to use identity services across each cloud service provider, so by building an agnostic layer that interacts with vault, you can write code that queries the service without having separate paths for IMDS on AWS, Azure and GCP.
linealert by anthonyedgar30000
This is an open-source detection and asset discovery for operational technology (OT) networks. When deployed, it passively monitors traffic and builds baselines to understand how certain OT devices operate, and they’ll send alerts out when it observes an anomaly. It also takes snapshots and uploads them to the cloud for offline analysis.
mcp-velociraptor by mgreen27
This is a pretty sick MCP server for Velociraptor. You grab an API key from the Velociraptor website, hook up Claude or whatever MCP server you need, and use an LLM to interact with Velociraptor directly.
dAWShund by FalconForceTeam
dAWShund is an open-source CIEM (Cloud Identity and Entitlements Management) tool for measuring permission relationships in AWS. You can see if permissions are too open and allow for all sorts of naughty things like write access or privilege escalation. It has a visualization component too since Cloud IAM is freaking impossible to comprehend without a picture.