Roll Your Own Deception

A common piece of security advice states: “do not roll your own crypto”. The logic behind it is simple: cryptography is extremely complicated and if you endeavour to write some code that does cryptography from scratch, you are bound to mess it up and introduce a vulnerability into your code. Instead, you probably should just rely on an open-source library that has been audited by some super-nerds who know their cryptography way better than you ever will(no offense ;) ).

While this advice generally makes sense, it shouldn’t be applied to everything. In fact, in some cases, you are better off doing the exact opposite. One such topic is deception-based techiques of detecting adversaries. In my opinion, you definetely should roll your own deception!.

deception 101

If you’d like a quick primer on deception in cybersecurity, look no further than the following definition: deception technology describes a broad range of security measures meant to help detect adversaries by tricking them into performing a specific kind of activity that can be easily detected.

Let’s take for example, canarytokens’ MS Excel feature. Canarytokens allows you to generate (for free!) an Excel file which upon being opened will connect back to their infrastructure and send you an alert. The idea is you pretend that the Excel file stores some important information and put it on an everyone-readable SMB share. Then you wait.

the saga continues

A potential attacker is bound to be intrigued by your file and will proceed to open it. The file will ping back to canarytokens which in turn will alert you of somebody trying to open your trapped file. You get a single alert with a very low FP rate that clearly shows something is afoot. This sort of stuff is blue team gold!

These sort of techniques have been growing in popularity. In fact, they have been so popular that some red teamers have even developed countermeasures! To rub it in ever further in some cases they have used blue team tooling to do it!

Take a look at this gist. This is yet another case of the red-blue arms race in action. Canarytokens could update their TTPs, but red teamers are bound to develop some countermeasures or bypasses for that too. While it would be fun to observe, it’s likely to not lead us very far. As long as the techniques used by the deception users remain public, this will unfortunately continue.

┌──(kali㉿kali)-[~/Downloads]
└─$ cat ./xl/drawings/_rels/drawing1.xml.rels
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships"><Relationship Id="rId1" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/image" Target="http://canarytokens.com/about/tags/feedback/[REDACTED]/payments.js" TargetMode="External"/></Relationships>

get creative!

How do you remedy this? Simple! Roll your own deception! For example, if you’re thinking about implementing a similar trap to the Excel spreadsheet, consider alerting on the file being retrieved rather than opened. This can be accomplished in many ways, but a good example would be to setup auditing on the SMB/samba share you place the file in. A user reading your passwords.xlsx file is as much of a smoking gun as your canarytoken inside the excel file triggering.

If you’re a blue teamer, the game is being played on your home field. You can bend the ‘rules’ however you wish. You can certainly afford to be creative with the traps you place. I’ll be fleshing out this blog with examples of practical traps you can set for different kinds of attackers in the following weeks :)

Until then, toodaloo!