Showing posts from 2021

Building WireGate: A WireGuard front to detect compromised keys

Earlier this year we released our WireGuard Canarytoken . This allows you to add a “fake” wireguard VPN endpoint on your device in seconds. The idea is that if your device is compromised, a knowledgeable attacker is likely to enumerate VPN configurations and try connect to them. Our Canarytoken means that if this happens, you receive an alert. This can be useful at moments like national border crossings when devices can be seized and inspected out of sight. Using the WireGuard Canarytoken If all you want is to scatter a million of these WireGuard VPN configs across all devices you care about, there's no need to read this further: they’re now freely available from for anyone to grab! (Paying Canary customers will already have seen these on your private Canary Consoles). But! If you’re interested in how we built these tokens and how they manage to work reliably and safely at scale, then this post is for you. Along the way we’ll cover some of our design choices and w

A Kubeconfig Canarytoken

 Introducing the new Kubeconfig Canarytoken A while back we asked:  “What will an attacker do if they find an AWS API key on your server? ” (We are pretty convinced they will try to use it, and when they do, you get a reliable message that badness is going on). Last month we asked: “What will an attacker do if they find a large MySQLDump file on your machine? ” (We think there’s a good chance they will load it into a temp MySQL db, and when they do, you get a reliable message that badness is going on). This month, a similar question comes to the container world: “What will an attacker do if they find a good looking kubeconfig file on one of your servers?” If the answer is: “They will try to use it to access your kubernetes cluster”, then again, you will receive a high-fidelity alert that badness is happening. This quick post presents our shiny new Kubeconfig Token (which emulates a kubeconfig file, the configuration text file that ordinarily contains credentials to interact with a Kube

Good attacks make good detections make good attacks make..

 (The making of a MySQL Canarytoken) tl;dr Consider this scenario:  An industrious attacker lands on one of your servers and finds a 5MB MySQL dump file (say, called prod_primary.dump ). What do they do next? Typically, they would load this dump-file into a temporary database to rummage through the data. As soon as they do, you get an email/SMS/alert letting you know: Eds note: You can create and deploy these by visiting (completely free; no registration needed) There are obvious benefits to these sorts of booby-traps, but some rise above the rest: They can be deployed in seconds; They aren’t prone to high false-positives; An attacker who suspects you are using these is no better off for knowing this (if nothing else, they now have to second-guess everything they touch); It's such a pure illustration of attack-minded defense. In this post I'm going to write about the process of discovering and building our new MySQL dump-file token. It Begins... While working

RDP, cmdkey, Canary (and thee)

Last month Florian Roth (cyb3rops) reacted to the news of Mimikatz dumping RDP credentials by asking how we could easily inject fake credentials into machines. Markus Neis pointed out that on Windows, cmdkey allows you to do this: This is pretty awesome. Mimikatz is used by attackers the world over and having control of the data a Mimikatzer will see is a powerful tool to have. One route to looking for Mimikatz usage is injecting false credentials into lsass and watch for their usage in Active Directory, but tracking that credential usage will require some work on your domain controllers (or your SIEM). With the RDP service back on version 3 Canaries, we can use cmdkey to point attackers at our Canaries, and not have to worry about Active Directory integration. Let’s start by setting up a Canary as a Windows Server (called \\02-FINANCE-02 ). This will take all of 1 minut

Would you know if your phone was hacked?

Would you know if your phone was hacked? Even the most powerful people in the world ( if you use wealth as a proxy for power ) don’t. The problem is that much like your networks there are an almost unlimited number of ways for attackers to break into them, so this problem seems intractable at first blush.  But (just like when they break into your networks) attackers who break into your phones are looking to achieve certain objectives, and you can use these objectives to reliably detect them. Today we released our new version of Canary , and with it, customers also get the shiny new WireGuard Canarytoken appearing on their consoles. What’s a WireGuard? WireGuard is the incredible VPN built by Jason Donenfeld. We love it. We use it. People smarter than us think you should too. What’s a WireGuard Canarytoken? Once a serious attacker gets onto your device, they have a certain set of objectives. Grab salacious data; Grab access to other services; Ensure repeat access or spread their compro

We bootstrapped to $11 million in ARR

This year Thinkst Canary crossed the line to $11M in ARR. That number is reasonably significant in the startup world, where Lemkin refers to it as “initial scale” . For us; it’s a happy reminder of Canary's spread into the market. $11M ARR certainly isn’t our end goal, but it provides the fuel for us to keep building the company we want to work at. We got here without raising a dime in capital, shipping a hardware/SaaS hybrid, sitting way outside Silicon Valley. That’s different enough from many startups that we figured it was worth a post with some thoughts on how we got here¹. Bootstrapping To be clear, we’re not anti-VCs. From the beginning though, we wanted to try bootstrapping. In the past we’ve spoken on how founder ego can nudge you towards building VC-backed companies (and why you might not need to), but that’s less focused on VCs and more aimed at founders. ( Bootstrapping, ego, and the path less travelled: 13m48s ) Launch Canary launched in mid-2015, after we worked on i