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.
In the last blog post, we discussed the full authentication flow using Windows Hello for Business (WHfB) with face recognition to authenticate against an Active Directory with Kerberos and showcased existing and new vulnerabilities. In this blog post, we dive into the architectural challenges WHfB faces and explore how we can exploit them.
Many Linux hardening guides focus on well-known protections: full-disk encryption, Secure Boot, and password-protected bootloaders. While these measures are critical, they often overlook a subtle but serious attack vector: the ability to drop into a debug shell via the Initial RAM Filesystem (initramfs). This oversight can enable an attacker with brief physical access to bypass conventional boot protections and inject persistent malware into the system.
In this post, it is demonstrated how this attack works on modern Linux distributions, such as Ubuntu and Fedora, and explained why existing guidance often fails to mention it.
Important note: Some media coverage on this topic falsely or inaccurately depicts the attack conditions. To be clear: Any vulnerable device can be compromised if the attacker is in Bluetooth range. That is the only precondition.
During our research on Bluetooth headphones and earbuds, we identified several vulnerabilities in devices that incorporate Airoha Systems on a Chip (SoCs). In this blog post, we briefly want to describe the vulnerabilities, point out their impact and provide some context to currently running patch delivery processes as described at this year’s TROOPERS Conference.
Windows Hello for Business is a key component of Microsoft’s passwordless authentication strategy. It enables user authentication not only during system sign-in but also in conjunction with new and advanced features such as Personal Data Encryption, Administrator Protection, and Recall. Rather than depending on traditional passwords, Windows Hello leverages a PIN or biometric methods – such as fingerprint or facial recognition – to unlock cryptographic keys protected by the Trusted Platform Module (TPM).
The X11 Window System has been used since September 1987 for Unix desktop systems, allowing applications to display their windows. Today, one of the server implementations of the protocol is the X.Org X server and XWayland, which both use the same codebase. While reviewing the X server, several legacy security issues were identified. These appear to originate from earlier design stages when security considerations were less prominent. Despite the project’s maturity and widespread use, some of these issues have persisted.
During our recent research, we experimented with different Bluetooth USB dongles. There are tons of options, and sometimes, it’s challenging to determine what chipset a dongle actually contains, what Bluetooth features it supports, and whether it works on Linux. Inspired by the recent ESP32 Bluetooth research, we wondered whether we could turn our Raspberry Pi Pico Ws into a functioning Bluetooth dongle. We had a few lying around, and the advantage here is that we know exactly which Bluetooth controller it uses – the Infineon CYW43439. It’s also very easy to get one. You can just buy the Pico W for a few bucks, even cheaper than some Bluetooth dongles. You also have a controller family that has been researched quite a bit in the internalblue project. However, there was one disadvantage. We did not find any code that exposes the CYW43439’s HCI interface via USB. So we had to write that on our own.
In a recent customer project, we discovered vulnerabilities in Microsoft Bookings, an online appointment scheduling tool integrated into Microsoft 365, allowing companies to have customers book meetings in available times themselves. The findings originate from insufficient input validation on the public meeting scheduling endpoint. Although Microsoft has largely mitigated this vulnerability, our analysis provides important insights into potential risks and areas for improvement.