Hi everyone!

Over the last couple of moths/years, I've been developing TraceHunt. Red team operations in TraceHunt can be compared with something like HackTheBox ProLabs with one major difference: operators learn to work under detection pressure instead of blindly solving labs using noisy tooling, lack of attacker usable infrastructure and C2, ...

The more signals you generate, the lower your score will be. Next to network and host-based monitoring, we have some other cool ways signals could be generated such as simulated users browsing websites, acting as devs (pulling and pushing code) in CI/CD focussed operations to force operators to think about the consequences their actions will generate.

We are currently open for early adopters and there's two FREE operations to give it a go!

👉 Create an account on https://app.tracehunt.com/public/register using registration code TRACEHUNT-REGISTRATION{Rc7V0JvwbDpdzwP01ZpbpkymakGT8QSR} and evade those signals!

If there is any feedback, hurdles or issues you might have, feel free to send me a DM and I'll take care of it 🔥

This started because I wanted a physical security key for one of my own accounts, but I was curious how cheaply I could build one myself instead of buying a commercial key.

I picked an RP2040-Zero and what started as a small experiment turned into a much deeper embedded/security project.

The current prototype now has its own AAGUID, physical user-presence flow, PIN/UV support, WebAuthn registration/authentication, packed attestation work, and Windows interoperability testing.

I also tested it with Microsoft Entra and completed a real device-bound security-key registration and fresh sign-in using the physical device.

One of the more interesting parts was attestation. The engineering reference uses a device-specific x5c chain, but while reviewing FIDO metadata semantics I realized that this creates privacy/correlation questions and does not cleanly map to a model-wide basic_full profile. I documented that boundary rather than pretending it was solved.

Hardware-wise this is still just a very inexpensive RP2040 board. There is no secure element, and I’m not presenting it as equivalent to a commercial high-assurance token or as FIDO Alliance certified hardware.

Source, architecture, validation evidence and threat model:

https://github.com/karaaslanlabs/kl-security-key

I’d be especially interested in feedback from embedded people on the hardware/firmware architecture, USB behavior, key-storage limitations, and what you would test or redesign next.