...stuff I do and things I like...

This blog post is to provide some more details about my idea that was mentioned on Risky Business #463 by Haroon Meer.

What are Canary Tokens (from Thinkst).

You'll be familiar with web bugs, the transparent images which track when someone opens an email. They work by embedding a unique URL in a page's image tag, and monitoring incoming GET requests.

Imagine doing that, but for file reads, database queries, process executions, patterns in log files, Bitcoin transactions or even Linkedin Profile views. Canarytokens does all this and more, letting you implant traps in your production systems rather than setting up separate honeypots.
...
Canary tokens are a free, quick, painless way to help defenders discover they've been breached (by having attackers announce themselves.)

The idea: Embed Canary Tokens into binaries (or application data) to help identify reverse engineering of your software.

Every reverse engineer looks for unique information (often just strings) in the target binary to help understand it. The strings are thrown into Google (or other search engines) with the hope to get additional information. The returned information can be extremely helpful to determine what the software is, what other code is linked in, what versions, etc. Everybody who reverse engineers stuff does this! I personally don't reverse engineer for a living so I asked around to confirm that professionals actually do this (I already knew the answer anyway!).

The plan:

• Embed unique looking strings into the binary
• Stand-up web page that contains the string, log access to that page (alert on access)
• Make Google crawl that page (various tools for that)
• Ship software

This is pretty straight forward, right? But do you care about somebody who just ran strings on your binary? Likely not! So what's next?

Many applications protect their code and other assets that come with it through different kinds of methods (called obfuscation techniques for this article - even not all of it will be actual obfuscation). The next step for the RE-canaries is to generate canaries and embed them into each obfuscation layer. If someone accesses a more obfuscated canary you know that a certain level of effort was put into reversing your app. This part is really where the creativity of the RE-canary deployment comes into play. This will be highly depended on the specific software, on the protection mechanisms used, the language and framework that app is written in and so on. Mobile apps (I'm a mobile app guy, yeah!) contain API endpoints and URLs and maybe some hardcoded credentials (tokens of course). The URLs have the advantage that you wouldn't need to put up a website. You just make them accessible and add logging and alerting.

The final part of this is automation. You want to automate canary creation and embedding into your built process, so that you can generate unique canaries with each built or major release or whatever fits your software.

In the end it will likely happen that advanced REs are going to use an anonymization service such as TOR when searching for strings or trying out URLs (specifically for URLs!). In this case at least you will know that someone is looking at your stuff and passed a certain skill/time/effort threshold, which I guess in most cases is enough information.

That's it! This idea was inspired heavily by Haroon Meer's Canarytokens a great free service that I use once in awhile!

Comments and feedback is welcome via the usual channels.