Security

I finally started using Molly to send and receive messages via Signal. Molly is a hardened fork of Signal for Android, offering features such as an encrypted message database, automatic locking, shredding no longer needed secrets from RAM, notifications via UnifiedPush, and Tor / SOCKS proxy support. This is by no means an alternative to Signal itself, but rather an alternative (and hardened) Android client for Signal. While these extra security features are great, my main motivation to use Molly was battery saving, actually. I’m on GrapheneOS, which does offer sandboxed Google Play (opt-in), yet I’ve chosen not to use it. This means I’m not using Google’s Firebase Cloud Messaging (FCM) for notifications either, which Signal by default heavily relies on. However, it continues to make me very glad I can still use a secure and open source mobile operating system (GrapheneOS) in 2025, without needing to rely on proprietary and privacy-impairing functionality. ...

This machine was retired yesterday, so I decided to publish my writeup the day after. CodePartTwo is an easy machine, which runs a Flask web app vulnerable to RCE due to an outdated and vulnerable library it uses. Once exploited we can dump and crack the registered users' passwords hashes (MD5). That gives us a SSH access, along with the User Flag. Retrieving the Root Flag exploits a weakness in a backup utility the user has root access over (via sudo). ...

This is my second writeup, after my first one covering the Conversor machine (machine not yet retired, therefore writeup not yet published). I fell into a few rabbit holes trying to pwn this one, I’m sad to say. We’ll get to that part as well, but first: enum. mairon $ nmap -Pn -n -v --open --top 5000 10.129.7.105 Starting Nmap 7.98 ( https://nmap.org ) at 2026-01-26 21:12 +0100 Initiating Connect Scan at 21:12 Scanning 10.129.7.105 [5000 ports] Discovered open port 80/tcp on 10.129.7.105 Discovered open port 22/tcp on 10.129.7.105 Completed Connect Scan at 21:12, 1.28s elapsed (5000 total ports) Nmap scan report for 10.129.7.105 Host is up (0.017s latency). Not shown: 4998 closed tcp ports (conn-refused) PORT STATE SERVICE 22/tcp open ssh 80/tcp open http Read data files from: /usr/bin/../share/nmap Nmap done: 1 IP address (1 host up) scanned in 1.29 seconds ...

These are some notes describing how to build a deliberately vulnerable Active Directory test lab to test some well-known misconfigurations or exploits. I might expand on this later…​ ℹ️ This is nothing new, most of this stuff can be easily found on the Internet. This is just for my own reference. Please excuse my brevity. This article assumes a Windows Server 2022 system (VM), and a non domain joined Linux system (VM) with pentesting tools such as impacket and certipy. ...

OpenWrt is an open source Linux project aimed at embedded devices to route network traffic (e.g. routers). I’ve consistently run OpenWrt on my home routers for over a decade now (I still remember the brief LEDE split), and it has since been my preferred home router OS. While I’ve also wanted to experiment with OPNsense (and pfSense before), I’ve never had a real reason to thus far, but I digress…​ It might be interesting to add some network security such as intrusion prevention to your residential gateway directly. You might of old be familiar with Fail2Ban, and I’ve happily used Fail2Ban for years. CrowdSec is a similar solution, albeit more community-driven. Klaus Agnoletti, then (still?) head of community at CrowdSec, summarised the similarities and differences between the two: ...

Some time ago I documented how I configured WireGuard on my OpenWrt router at home, to connect securely to my home network (and the Internet, really) from wherever I am. I feel safer connecting to public Wi-Fi this way, also abroad when it allows me to save extra roaming costs. However, during my travels I sometimes come across networks which seem to block VPN connections, sometimes including my own personal WireGuard tunnel. For such cases I managed to tunnel my WireGuard connection over HTTPS, which is typically (far) less often blocked. ...

These are some scribbles if I ever need to look up how to forge my own Kerberos Tickets, such as Silver, Golden, Diamond or Sapphire Tickets. I might expand on this later…​ ℹ️ This is nothing new, most of this stuff can be easily found on the Internet. This is just for my own reference. Please excuse my brevity. Environment Previously, I’ve documented (also for myself) how to Kerberoast and ASREProast. For this article, we’re assuming we’ve already compromised the domain and have gotten our hands on the KRBTGT secrets (NTHash, AES keys). In other words, we’ve already got DA. ...

My previous post discussed the introduction of a Module-Lattice Key Encapsulation Mechanism (ML-KEM) post-quantum key exchange algorithm implementation in OpenSSH, and how to specify it in your SSH configurations. ML-KEM is the new FIPS 203 standard, previously known as Kyber, which was standardized by NIST on 2024-08-13. OpenSSH’s implementation of ML-KEM is a PQ/T hybrid approach that combines the post-quantum ML-KEM with the traditional X25519 key exchange algorithm. This post will cover the ML-KEM implementation in Caddy, the popular web server and reverse proxy. ...

OpenSSH 9.9, released on 2024-09-19, first introduced support for the new FIPS 203 Module-Lattice Key Encapsulation Mechanism (ML-KEM) post-quantum key exchange algorithm, previously known as Kyber. ML-KEM was formally standardized by NIST on 2024-08-13, and is designed to be secure against quantum attacks, making it a suitable choice for future-proofing cryptographic systems. The OpenSSH implementation of supporting ML-KEM, specifically the mlkem768x25519-sha256 key exchange algorithm, is a hybrid approach that combines the post-quantum ML-KEM with the standard X25519 key exchange algorithm. The benefit of a hybrid approach is that in the event that, after further cryptanalysis, the ML-KEM algorithm ends up being broken, the X25519 key exchange algorithm will still provide a secure fallback. At least for now, while we don’t yet have a Cryptographically Relevant Quantum Computer (CRQC) that can break X25519. There is currently an IETF draft for Post-Quantum Traditional (PQ/T) hybrid key exchange methods based on ML-KEM and Elliptic Curve Diffie-Hellman (ECDH) algorithms (also including X25519) for use in SSH. OpenSSH’s mlkem768x25519-sha256 key exchange is exactly such an example thereof, and is being described there. ...

I finally got hashcat running on Docker, with GPU support for NVIDIA cards. First, I needed to install Docker and NVIDIA Container Toolkit on my system, and add my user to the docker group. root $ pacman -S --needed docker nvidia-container-toolkit root $ systemctl enable --now docker.service root $ usermod -aG docker user Then I created a Dockerfile to set up the hashcat environment with NVIDIA support (using a BlackArch image): FROM blackarchlinux/blackarch:latest RUN pacman -Syu --noconfirm && \ pacman -S --noconfirm \ blackarch/cracken \ blackarch/pack \ blackarch/pipal \ extra/hashcat \ extra/hashcat-utils RUN mkdir -p /etc/OpenCL/vendors && \ echo "libnvidia-opencl.so.1" > /etc/OpenCL/vendors/nvidia.icd RUN mkdir /cracking...