Thinkst Blog

Background One of our most popular Canarytokens is one we call the "Cloned-Site Token". Essentially, we give you a tiny piece of JavaScript to add to your public webpage. If this JS is ever loaded on a server that doesn't belong to you, it fires an alert. You can be alerted at an email address or webhook in the free version , or to your SIEM, slack channel or a bunch of other alternatives in the paid version . The Cloned-Site Token is super useful at catching Phishers who duplicate your website as a pre-cursor to an actual phishing attack. A notification that the website from http://thinkst.com was now running on http://fake-thinkst.com The Issue Recently, a financial services customer was periodically getting alerts where the Cloned-Site domain matched their actual domain. This was unexpected, as the token explicitly should only trigger if the domains are different.  In other words, the token for http://domain.com should only fire if the page is loaded at a different ...

We like solving problems. Sometimes, we make up new ones so we can solve them . Skyball Pyramids are one such case! Last year we discovered these amazing Skyballs and decided to make them a regular feature at our conference booths.  Canary Skyballs They have just the right amount of heft and weight to make them genuinely fun to play with. Of course, this leaves us with the devilish problem of how to display them... At Infosec Europe 2018, some of our team attempted to stack them in a pyramid shape. The problem : Skyballs do not like to be stacked. In fact, they like to roll all over the place uncontrollably, frustrating the person that is attempting to stack them. Exhibit A Exhibit B Note the use of Canary-green duct tape in an attempt to keep them in place.  So, as RSAC 2019 was approaching we needed a better solution; something that was simple, yet effective. (We could have simply taken a bowl, but have you ever tried to fly with a bowl in your carry-on?) Last year we purcha...

I’ve sometimes bumped into people who bemoan their broken company cultures with varying degrees of self-awareness. Around 2007, a then-customer heard we were heading to Vegas to speak at BlackHat and said: You guys are so lucky.. my company won’t let us go to anything like that At the time I bristled. We worked for months on that research, dedicating many nights and burnt family time before we could stand up and talk. For sure our company celebrated those wins, but it irked me that someone who spent his free time tearing up backroads in a 4x4 felt we were gifted access to BlackHat. In the intervening decade+, we’ve encountered genuinely broken work cultures. I’ve looked at some of the brokenness and wondered how on earth those environments would ever lead to awesomeness in the face of all of the obvious impediments? And then, fortunately, I started reading “ Skunk Works ” by Ben Rich. (I'm not quite finished but so far it's been excellent.) (Awesome on Audible too) The book is...

Two weeks ago we ran the second edition of our internal HackWeek, and it was fantastic. Last year’s event was great fun and produced projects we still use; going into this year’s HackWeek we anticipated a leveling up, and weren’t disappointed. We figured we’d talk a little bit about the week, and discuss some of the “hacks”. Our HackWeek parameters are simple: We downtools on all but the most essential work (primarily anything customer-facing) and instead scope and build something. The project absolutely does not have to be work-related, and people can work individually or in teams. The key deadline is a 10-minute demo on the Friday afternoon. The demos are in front of the rest of the team, and results count more than intentions. Everyone participated and everyone presented at the Friday demo, including sales, dev, support, back office and yours truly. We strive to keep Thinkst a learning organisation and this HackWeek is one way that we do it. For example, it’s great to see a salesper...

Dan Geer famously declared that security is “ the absence of unmitigatable surprise ”. He said it while discussing how dependence is the root source of risk, where increasing system dependencies change the nature of surprises that emanate from composed systems.  Recently, two of our servers “surprised” us due to an unexpected dependence, and we thought this incident was worth talking about. (We also discuss how to mitigate such surprises going forward). Background : Every Canary deployment is made up of at least two pieces. Canaries (hardware, VM or Cloud) that then report in to the customer’s dedicated console hosted in EC2. We’ve gone to great lengths to make sure that the code and infrastructure we run is secure , and we ensure that any activity on these servers that isn’t expected, is raised in the form of an alert . A few weeks ago, this real-time auditing activity tripped an alert on a development server. Servers are either built as production servers, which have been tested ...

aka: You know it’s supposed to hurt, you just don’t know which kind of hurt is the good kind One of the common problems when people start lifting weights (or doing CrossFit) is that they inadvertently overdo it. Why don’t they stop when it hurts? Because everyone knows it’s supposed to hurt. Hypertrophy is the goal, so the pain is part of the deal... right? Pain, Guaranteed In an old interview on the rise of Twitter, Ev Williams said something really interesting: in pursuit of the fabled startup we’ve gotten so used to praising the entrepreneurial struggle, and so often repeat the myth of the starving entrepreneur, that people tolerate the pain of a bad/unviable idea longer than they should. He said that seeing Twitter go viral, made it clearer how Odeo hadn’t. When Twitter took off, he just about said: “So this is what traction feels like.” This is an interesting problem. The cult of entrepreneurship is strong and there’s no shortage of glib one-liners pumping people up to worship the...

Moving backward is a feature too! We go through a lot of pain to make sure that Canary deployments are quick and painless. It’s worth remembering that even though the deployment happened in minutes, a bunch of stuff has happened in the background. (Your bird created a crypto key-pair, exchanged the public key with your console, and registered itself as one of your birds). From that point on, all communication between your bird and your console is encrypted (with a per-device key) and goes out via valid DNS requests. This makes sure that deployments are quick and simple, even on complex networks. Once your bird is successfully deployed, it’s completely configurable via your Canary Console. So with a few clicks, a user is able to change a deployed Canary from a Cisco Router, to a Windows Server However mistakes happen and, as anyone who has remotely configured network interfaces over SSH can attest, remote network changes aren’t kind to missteps. How does your Canary react if yo...