Re-Think(st)ing Deception

Throughout history, deception has been an effective tactic in preventing one’s adversaries from achieving their aim. Long before cyber security (or even computers, for that matter) could be imaged, Hannibal Barca, a Carthaginian general who lived circa 247 – 182 B.C., was well known for throwing enemies off course using deception. During the Battle of Lake Trasimene, for example, Hannibal tricked the Roman army by having his men light fires in a location different from the one in which they were hiding. When the Roman troops advanced toward the fires, believing them to indicate the position of Hannibal’s troops, the Carthaginians pounced from their hiding spots, killing nearly the entire Roman army.

Even farther back in history, and perhaps better known to security practitioners, is Odysseus’ Trojan Horse deceit from 1200 B.C. In this ruse, Odysseus had his army craft a giant wooden horse which he presented to the enemy as a “peace offering.” The wooden horse, of course, was actually a hiding spot for his army. Once the horse was safely inside the city walls, the soldiers climbed out and massacred the city. Truly brutal.

The former example—“Hey look over here! I’ve got something juicy for you in this place!”—is the basic premise of cyber deception technology. While today’s Trojans, a.k.a., malware, are used in offensive strikes, the Hannibal illustration is more akin to how defenders can lure adversaries away from data-rich production systems (the “brightly burning fire”), giving themselves more time to mitigate the threat, identify the attacker, or deploy myriad breach prevention tactics. Enter, the honeypot.

Catching flies with honey(pots)

Honeypots are not unknown to cyber security practitioners. Arguably, the first honeypot was invented by Clifford Stoll in 1986 when he was asked by his supervisor to chase down the perpetrator of 9 seconds worth of stolen computer time. The first defined honeypot tool was the “Deception Toolkit,” released open source by Fred Cohen in 1998. Since the 1990s, security researchers have been extolling the virtues of honeypots to keep bad guys away from sensitive data. Very few practitioners would likely claim that honeypots aren’t a good conceptual idea. They might, however, complain about the complexity of implementing and using honeypots in today’s vast network environments which are noisy, distributed, and maintained by too few security professionals whose days are already stretched too thin. For their part, non-security IT staff aren't keen to implement anything on the network that creates more noise and could possibly disrupt their ability to keep the network functional and available.

Given these issues, it’s easy to see why lighting false fires inside the network hasn’t caught on—even with its huge potential to stop cyber attackers from accessing production systems—more readily.

Planting the (bird) seed

Back in the early 2000s, Haroon Meer, now-CEO of Thinkst Applied Research, and his fellow future co- founders were working as penetration testers, helping enterprises identify the weaknesses in their systems. During one such assessment, the team discovered that the client not only had several vulnerabilities, but that one of these vulnerabilities had been exploited and they were dealing with an active compromise. Meer and his team recommended the customer set up a honeypot to catch the criminals in action, but at that time, said Meer during a recent conversation, “honeypots were too clumsy and too much work for anyone trying to manage the network.” In other words, the juice wasn’t worth the squeeze. Typical thinking at the time was; if an attacker is already inside the network, the easiest thing to do is pour water on the fire. We’ll deal with the ashes later.

But this method didn’t do much to prevent compromise or breach—stop an attacker from getting to sensitive data and systems in the first place—and that frustrated Meer and Co. They knew there had to be a better way for enterprises to defend their networks using deception, i.e., sending up smoke signals where there were no fires. It would just take some retooling of the traditional honeypot. “[Security] People know that honeypots are a good idea,” explained Meer, “but no one gets around to them because they’re too much work.” With that mindset, Thinkst Canary was born in 2015.

New honeypot technology learns to fly

The premise behind Thinkst was to build a honeypot-like technology that was quick to deploy, easy to manage, and could still ensnare cyber intruders. This thinking and building led the company to its signature product, Canary.

Canaries are sensors that can be deployed on a network via a physical device, virtual machine, or cloud instance (though Meer says hardware deployments are, by far, the most common today). Via the customer console (a single tenant EC2 instance), Canaries are configured to look like legitimate network devices or services—a Windows file server, a Linux LAMP Server, a Cisco router, or an IBM Mainframe—and, when in live mode, communicate via a DNS overlay protocol (meaning: no cumbersome network changes) to report on suspicious activity.

Traffic between the Canary and console is authenticated and encrypted, meaning that, if an attacker is pinging a Canary, believing it to be a target system, they cannot see the event report being sent to the customer; they continue to believe they’re furthering their attack while the defender is given the opportunity to triage the alert. Information transmitted to the console includes source IP, source port, internal IP, reverse lookup of the host, a timestamp, and a description of the incident (e.g., “SSH login attempt”). Notably, to fulfill the promise of simplifying honeypots, Canary rolls up alerting information in one place, which means that operators don’t have to sift through duplicated or overlapping alerts, thereby reducing “alert fatigue” which is all too common in security and IT operations today. Further, Meer says Canary “is not trying to be one pane of glass” for its customers. Console information can be integrated with the other logging tools enterprises indubitably have deployed, which alleviates the not another console! objection posed by many operations pros.

If Canaries are honeypots which emulate entire machines, Canarytokens are tripwires that can be deployed on employees’ endpoints or inside SaaS applications. Canarytokens are deployed as web or DNS tokens, API keys or images and, when tripped by an attacker, report the offending IP address, geolocation, and browser details of the attacker.


Thinkst appears to have created an uncomplicated deception technology that truly allows defenders to lure cyber attackers away from legitimate targets, giving the company time to proactively prevent breach even if network compromise has been achieved. Based on customer quotes on social media and the company’s website, customers love the solution. Meer says Canaries should take only 4 minutes to deploy, which should be music to an administrator’s ears. Though defending the entirety of an enterprise’s network “battlefield” is complicated, the industry needs more solutions that are simple to deploy and manage. TAG Cyber recommends you take a look at what the team at Thinkst is offering and give it a try. Unbelievable as it sounds, you can try Canarytokens for free and build up from there, if you like what you see.