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 😉
Today we are releasing a new white paper that delivers a technical analysis of security weaknesses discovered in WinpMem, an open-source Windows memory acquisition driver widely used in digital forensics.
The VERTIV Avocent AutoView switches are analog keyboard, video, and mouse (KVM) switches used in data center servers. They also expose a web server in the network, which allows for some configuration.
During a penetration test for a customer, a device of this type was identified in the infrastructure and analyzed, revealing an authentication bypass in the web application.
With the rise of AI assistance features in an increasing number of products, we have begun to focus some of our research efforts on refining our internal detection and testing guidelines for LLMs by taking a brief look at the new AI integrations we discover.
Alongside the rise of applications with LLM integrations, an increasing number of customers come to ERNW to specifically assess AI applications. Our colleagues Florian Grunow and Hannes Mohr analyzed the novel attack vectors that emerged and presented the results at TROOPERS24 already.
In this blog post, written by my colleague Malte Heinzelmann and me, Florian Port, we will examine multiple interesting exploit chains that we identified in an exemplary application, highlighting the risks resulting from the combination of sensitive data exposure and excessive agency. The target application is an AI email client, which adds a ChatGPT-like assistant to your Google Mail account.
Ultimately, we discovered a prompt injection payload that can be concealed within HTML emails, which is still interpreted by the model even if the user does not directly interact with the malicious email.
The #TROOPERS25 ‘AD & Entra ID Security’ track was a blast – as was the whole conference 😉 – bringing together some of the smartest researchers in the field and a great audience of practitioners willing to share their experiences during the roundtable. The slides of the talks have been released in the interim on the TROOPERS website, but since many speakers published additional blogposts or released tools, we provide a compilation of resources from the track in the following.
The purpose of this blog post is to explain how Secure Boot works. In particular, we will explain where current implementations of Secure Boot by Linux distributors fall short compared to Microsoft Windows and Apple macOS.
Major distributors like Canonical, Debian, openSUSE, and Red Hat place a high priority on making their operating systems work out of the box. Given the current Linux landscape with out-of-tree drivers and incompatible licenses, providing the end user with all the drivers possibly needed to boot the system can be challenging.
In this post we will describe how to set up Secure Boot on Gentoo Linux. Gentoo Linux is sometimes described as a meta-distribution. It leaves many decisions up to its users—and with that, a fair amount of work. The upside is that users can decide exactly how to set up the boot chain without having to work “against” the distributor. For this reason, we chose Gentoo Linux to demonstrate the different ways to set up Secure Boot.
On a hardened system, Secure Boot should be deployed along with full disk encryption1.