DEW #130 - God-mode Azure vulnerability, Composite Detections & Detection Observability
power overwhelming
Welcome to Issue #130 of Detection Engineering Weekly!
✍️ Musings from the life of Zack in the last week
I am putting together an Uplift desk and woo let me tell you there are a lot of pieces (electronics)
Had a fantastic time in NY for $DAYJOB and managed to spill pasta on my jeans at a team dinner, in front of my boss and CISO
Brought the family to an organic farm fair and watched a demonstration with a Border Collie gathering sheep. Made me miss my dog Pasha a lot :(
Vibe coded some infra for the newsletter to make news collection easier. Post to Discord → auto add to new issues in Notion
⏪ Check out last week’s issue if you’ve missed it!
This Week’s Sponsor: detections.ai
Community Inspired. AI Enhanced. Better Detections.
detections.ai uses AI to transform threat intel into detection rules across any security platform. Join 7,500 detection engineers leveraging AI-powered detection engineering to stay ahead of attackers.
Our AI analyzes the latest CTI to create rules in SIGMA, SPL, YARA-L, KQL, and YARA and translates them into more languages. Community rules for PowerShell execution, lateral movement, service installations, and hundreds of threat scenarios.
Use invite code "DEW" to get started
💎 Detection Engineering Gem 💎
One Token to rule them all - obtaining Global Admin in every Entra ID tenant via Actor tokens by Dirk-jan Mollema
I’ve rarely included vulnerability writeups in previous Gems, but this one was just way too good not to do so. For those not in the cloud space, the foundation of cloud security lies in hyperscalers’ shared responsibility models. Since the cloud involves running your stuff on someone else’s computer, there needs to be some guarantees that they are doing so in a secure manner. The keyword here is “shared”, as in, you are responsible for the security of your cloud deployment, but AWS, Azure, and GCP are accountable for the underlying technology, making it possible to run your apps on their services.
If you are a bug bounty hunter targeting Azure, for example, you have your target list above. You could pursue cloud customer deployments and hopefully receive some substantial bug bounty payouts. But the holy grail here is the boxes labeled “Microsoft”. Bragging rights aside, the infrastructure that they manage is opaque, both as a security control and probably because they don’t know everything they have turned on and off.
This is where Mollema’s vulnerability comes into play. Based on their post, I believe Mollema identified one of the most critical cloud vulnerabilities ever disclosed, located under Microsoft’s “Identity and directory infrastructure” category in the SaaS column. The vulnerability, CVE-2025-55241, involved combining three separate flaws in Azure, and then employing brute force once these flaws were combined.
While researching hybrid Exchange setups, Mollema uncovered an undocumented service called “Access Control Service”. This was used for intercommunication between services in the backend of Azure, and it issued what he called were impersonation tokens.
The first flaw was this service could create unsigned impersonation tokens and you could specify any user, as in, Entra ID wasn’t required to issue the token. The second flaw was that Azure AD Graph API, a legacy API, would accept these unsigned tokens as valid. Mollema could then issue Graph API requests to ANY AZURE TENANT GLOBALLY without the Graph API checking if he owned the target tenant.
This is impressive because it breaks the fundamental trust boundary you see in the shared responsibility model, and he could theoretically “hop” into any Tenant that he wanted. Most of this wasn’t generating any telemetry until you started creating or modifying resources in a victim account, so luckily, Mollema includes a KQL rule to detect this activity.
🔬 State of the Art
Threat-agnostic detection of co-occurring MITRE ATT&CK® events using Composite Detections by Ryan Tomcik
Composite detection rules are an evolution of atomic rules, where the presence of techniques across different pieces of telemetry can show threat actor activity within a sea of noise. The idea here is to mitigate the precision versus recall tradeoff by simultaneously using two or more rules for the alerting scenario. This provides flexibility in several dimensions, such as identifying activity presence using one strategy, like a string match, versus another, like a windowed threshold.
In this piece, Tomcik leverages the Google SecOps platform to show examples of composite detections via the lens of MITRE ATT&CK. Co-occurrence is another alerting technique that attempts to identify an intrusion through a sequence of events. Tomcik’s example of detecting co-occurring MITRE techniques alongside composite rules is a fitting illustration of composite rules in action. Discovery techniques are potentially the noisiest of techniques to catch in a live environment because they yield a lot of legitimate activity.
However, as Tomcik points out here, if you reconcile this telemetry with a singular source and find multiple discovery attempt techniques from one host, you achieve a high-fidelity alerting situation. The assumption here is that one host or log source shouldn’t be using several discovery mechanisms at once, so it could indicate a threat actor landing on a box and discovering their environment to collect information on where to pivot to next.
Resource Gathering by Amitai Cohen
This may not be a purely technical post, but I believe it’s highly relevant for anyone in detection engineering or security, especially as you begin your career. Amitai, a friend of the newsletter, describes situations in the workplace where we are bombarded with messages, emails, and requests to do stuff. And this is especially worse if you have meetings on top of your requests. So how do you manage all of that?
He draws the analogy of resource gathering from none other than Real-Time Strategy (RTS) games. It ultimately comes down to the question of return on investment. It’s good to notice when you see lengthy Slack DMs or channels, documents, or emails and see whether it’s worth your investment to generate what you want to impact in your day job.
In management land, a useful tool for this is the Eisenhower Box:
Granted, individual contributor folks don’t have the ability to delegate, but it’s still a useful mental model to focus on what matters.
Zero-Log Checker: Automating Log Absence Detection in Wazuh by Hanif Kurniawan A.
I’ve pontificated throughout this newsletter about how security tends to steal of concepts from other software engineering disciplines and rebrands them into something cool or sexy. Regression testing? THREAT EMULATION PEW PEW. Monitoring for weird or malicious logs? THREAT DETECTION BANG.
In all seriousness, it’s nice to see when concepts from software engineering enter our space and how we use them to solve real security problems. I’ve been shilling the idea of “observability for security” at my $DAYJOB, and every time I see a new post like Kurniawan’s here, it’s a good indicator that the health of your detection systems matters just as much as your rules. So, in this post, Kurniawan shows their system on how to detect when a log source goes down in Wazuh and how you can respond to it.
It’s a neat lab to me because I haven’t seen a lot of Wazuh content in the mix of Splunk, ELK and Sigma. The basic premise is you write a Python script to read in nd.json files on the local lab environment, compare them to historical files from the log source, check if it falls outside a window, and generate its own alert. Once alerted, you can review the log source health and ensure that forwarders are working, starting from the agent to the network setup.
🥊 Quick Hits
How I Built My First SIEM Detections by Garv Kamra
This is a neat “beginner” post on Kamra’s adventures in writing their first detection rules. It’s a lab environment where they set up a basic ELK stack, and focused on creating correlation rules, which are definitely a challenge if it’s the first time they’ve written rules!
Kamra wrote three correlation rules for credential stuffing, DNS tunneling and suspicious firewall usage. Kama wrote their assumptions, findings and lessons learned in each subsection. This is a great way for folks who are also trying this type of lab environment for the first time to learn.
Hunting Ideas in AWS Part 1 by Jake Valesky
This is Valesky’s first blog post ever, so I was excited to see how they wrote about a topic near and dear to my heart: threat hunting in the cloud. The blog explores effective log strategies, the various types of access keys that interact with your environment, and how to monitor unauthorized changes. I’ve linked to and written about AWS threat detection in detail in this newsletter. Blogs like this demonstrate the complexity of the environment and how it should be treated as its own operating system.
☣️ Threat Landscape
Microsoft seizes 338 websites to disrupt rapidly growing ‘RaccoonO365’ phishing service by Steven Masada/Microsoft Digital Crimes Unit (DCU)
I’ve always found DCU posts where they’ve legally seized actor infrastructure fascinating. When I think of legal action against threat actors, my brain immediately goes to law enforcement actions. This is logical, considering the numerous takedowns and arrests of criminals worldwide. But a private company doing this is on a whole other level!
The DCU team seized approximately 338 websites associated with an emerging phishing-as-a-service kit, RaccoonO365. It’s a subscription model, meaning you pay monthly, and according to the tech giant, it has accrued nearly $100,000 in payments paid directly to the creator. They’ve also allegedly identified the creator itself, a Nigerian man, and issued a “criminal referral”, which I’m guessing means they dropped the doxxing info to someone here in the FBI or to the Nigerian government.
Two teenagers charged over Transport for London cyber attack by Joe Tidy and Graham Fraser
UK police charged two teenagers, whom they believe were responsible for the months of disruption to Transport for London’s information systems. There were some shutdowns of the transit vehicles themselves, but most of the damage was in relation to their online services. According to the report, these two individuals were already in trouble for other cybersecurity-related crimes, with one having evidence on their machine that they were targeting U.S. healthcare companies. Smells like Scattered Spider to me!
SystemBC – Bringing the Noise by Black Lotus Labs
Detecting command-and-control (C2) servers and traffic is a pastime of mine. There’s something exciting about dissecting a piece of malware, analyzing its traffic, and then trying to identify where the bad guys host their command-and-control (C2) server so you can fingerprint it and gather additional threat intelligence as they move the C2 around the Internet.
This becomes much more challenging when the C2 server you are communicating with isn’t the actual C2 server. According to Black Lotus Labs, proxy networks are becoming increasingly popular among malware families, and proxy malware, such as SystemBC, helps facilitate this type of activity. The basic idea here is that an infection can route its traffic to the C2 server via an infected proxy to help masquerade the origin IP address. The Black Lotus team uncovered an extensive network of SystemBC Linux variant infections, attributed them to several grayware proxy providers, and blocked traffic to affected users.
Tech Note - BeaverTail variant distributed via malicious repositories and ClickFix lure by Oliver Smith
GitLab threat intelligence researcher Smith outlines some notable TTPs in DPRK’s BeaverTail malware. BeaverTail was first detected via Contagious Interview attacks, which relied on victims to clone a repository to perform a coding test and execute a backdoor embedded within the code.
According to Smith, they’ve pivoted towards ClickFix-style attacks, and my tinfoil hat says it’s because platforms like GitLab/GitHub are getting much better at squashing this malicious repository. They outline the chain and how the campaign is smart enough to differentiate between operating systems, making sure to maximize their victims who visit their ClickFix websites.
🔗 Open Source
Cyb3r-Monk/Microsoft-Vulnerable-Driver-Block-Lists
Cyb3r-Monk, a.k.a. Mehmet Ergene, whom I’ve featured extensively in this newsletter, has dropped a great resource for Windows Security administrators to help block vulnerable drivers. Microsoft apparently removed the webpage that lists these drivers and instead publishes a ZIP file with some XML data, making it more challenging for users to ingest and implement controls. Ergene automates this process with this repository and exposes some great metadata, allowing people to understand what they are loading into their Windows environments.
Yet another anti-EDR repository for tampering with security tools that you don’t want turned on :). The methodology here is that obex spawns itself as a process, and it attaches a debugger. The debugger hooks the LdrLoadDll function, patches a specific pointer, and uses it to catch DLLs being loaded and subsequently block them.
With the number of open-source supply chain attacks occurring over the last few weeks, it’s encouraging to see open-source projects like this one come into play to help individuals understand the impact of malicious packages in their environment.
WireGuard-based, zero-trust networking project that allows users to deploy gateways and a management server for secure access. I love WireGuard, so I was already excited to read about this. The control plane/management server is written in Elixir, and all the gateways run in Rust, so you can expect this to be performant. They went the extra mile and created client applications for iOS, Android, Linux, Windows, and macOS.