There is a growing landscape of security products promising to protect an organization’s IT infrastructure from attacks. Solutions referred to as EDR, and sometimes also as XDR, are designed to protect endpoints from all malicious activity. The ever-increasing cases of breaches and the associated costs, especially in the realm of ransomware attacks, raise the question of whether there is more that can be done to add an additional layer to traditional endpoint protection concepts. That is why a customer of ours commissioned us to evaluate whether EDR supplementing solutions provide extended protection against ever-evolving threats, as well as to shine a light on the performance overheads those solutions might introduce.
This blog post describes the methodology we use to evaluate and compare different EDR solutions for our customers. Given the growing number of sophisticated attacks, it is important not only to look at detection rates in isolation but to assess how these solutions perform under realistic conditions.
During a customer project, we identified privilege escalation vulnerabilities in Broadcom VMware Aria Operations. It is possible to escalate the privileges of an administrative vCenter user to an Aria administrator and take over systems integrated in Aria. Meaning, the vCenter user can gain privileged access to systems they have no access to. While both users might sound similarly privileged, this is not true in most environments – especially not in complex corporate environments: An insignificant vCenter user in a development environment can take over all other vCenters in a complex corporate environment.
The issue is exploitable in Aria’s default configuration. While the user is not an administrator, Aria maps the vCenter users to the PowerUser role, which is a privileged role in Aria and can be used to escalate its privileges to administrative users of other vCenters and connected VMware components.
In this blog post, we provide a brief background on VMware Aria Operations and vCenters, show what we found, and how we exploited this vulnerability in multiple ways to escalate privileges! Later, we talk about the disclosure process and Broadcom’s mitigation of the issue.
This blog post describes the journey of how we discovered an interesting Bluetooth SoC within the Datong NP330, a Printer Server IoT device. Our initial goal was to reverse-engineer and analyze the Bluetooth controller that is included in the device. So we wanted to be able to dump the firmware or, if possible, get shell access on the printer server. During that journey we found a few vulnerabilities that ultimately let an attacker fully compromise the device. This is possible over Bluetooth or network via unauthenticated remote code execution with root privileges.
AI agents are here, there, and everywhere. Smarter, faster, and more skilled, they gain greater autonomy and trust. We trust their capabilities to do many tasks much faster and sometimes better than we can. We trust them as they usually demonstrate their eagerness to please us and fulfill our commands. Isn’t that too good to be true, and we might be dealing with a double-edged sword here? Can attackers use the same capabilities of the AI agents to attack their own users? Can they exploit their eagerness to please their users to fulfill the attackers’ intentions? And most importantly: what’s the worst that could happen if you fully trust some random AI Agent?
In this blog post, I present the results of my research on an extension for Visual Studio Code, which has one of the highest installation counts in AI agents category. I demonstrate several techniques of prompt injection, further exploitation, and even human emotional manipulation to achieve maximum impact on its users.
During a customer project we identified an issue with the validation of JWT tokens that allowed us to bypass the authentication by using unsigned tokens with arbitrary payloads. During analysis we found out that this is caused by a vulnerability within the library OpenID Connect Authenticator for Tomcat.
After seven years, we’re publishing a new macOS hardening guide. Fully updated, modernized, and now publicly available on GitHub as Markdown and on our website as PDF.
The previous guide, written for macOS Mojave (10.14), reflected a very different macOS security model. At the time, hardening often meant working around the operating system, manually enforcing controls, and compensating for missing platform guarantees. That guide served its purpose, but the platform has fundamentally changed since then.
When conducting pentests of Bluetooth devices or whilst working on Bluetooth related research, we often use Bumble. In this Blogpost I will present a solution to capture a live stream of Bumble Bluetooth traffic in Wireshark.
We are regularly offering a GCP Incident Response and Analysis training. In this training, we analyze resources in GCP cloud together with our trainees that were successfully compromised by attackers, e.g., GCE instances and Cloud Build projects. Therefore, we need tooling that quickly detects misconfiguration of resources that helped the attacker during the compromise. During the analysis of different tools and different kinds of misconfiguration we realized that GCE instance access scopes are a blind spot of many (in fact all that we tested) security audit tools. In this blog post, we want to elaborate on the problems that arise from this behavior.
About six months ago we released a security advisory on this blog about vulnerabilities in Airoha-based Bluetooth headphones and earbuds. Back then, we didn’t release all technical details to give vendors more time to release updates and users time to patch their devices. Around the time of the initial partial disclosure in the beginning of June, Airoha put out an SDK release for their customers that mitigates the vulnerabilities. Now, half a year later, we finally want to publish the technical details and release a tool for researchers and users to continue researching and check whether their devices are vulnerable.
This blog post is about CVE-2025-20700, CVE-2025-20701, and CVE-2025-20702.
Alongside this blog post, we also released a white paper. It contains some more technical details, as well as information on how to check whether your device might be affected.
Three weeks ago, I attended MCTTP 2025 in Munich, organized by Vogel IT and curated by the fine folks Florian Hansemann, Dr. Marc Maisch, and Florian Oelmaier. Awesome event with some very cool talks, and great conversations over dinner and most notably at the Oktoberfest on Saturday (thanks again for that special trip, Flo!). I had the pleasure and honor to give the keynote on the 2nd day. The goal was to make it a bit entertaining and enlightening for the international audience, so I covered some German literature, too ;-). The slides can be found here, and the transcript here. Looking forward to meeting some folks again next year, maybe even at TROOPERS26 😉