Decoy files

Unlike decoy machines discussed in the last post, decoy files cannot always be created as primitive decoys. Cloud native decoy files, like Google Docs, can be primitive decoys. Decoy files made with offline text editing software, like Microsoft Word, cannot be; in order to alert a security team that an attacker has opened an offline decoy file, the file must contain a primitive decoy like a domain name or an internet-hosted image. If a security team believes that most attackers who compromise its file hosting service will open documents in that service, it is best to use the native file format with its scripting capabilities as decoys. If the team believes that attackers will download files and inspect them offline, it is better to create decoy files in the file editing software of choice and store them in the hosting service. This post will examine the two scenarios, explain how to create the different types of decoys, and demonstrate how they work.

A Google Doc decoy

Many file hosting services - for example, Google Drive - have custom file types that closely mimic the types of files users are familiar with from their own computers. In Google Drive’s case, a Google Doc is similar to a Microsoft Word document, Google Sheets is similar to Microsoft Excel spreadsheets, and Google Slides is similar to Microsoft Powerpoint slide decks. Although files can often be seamlessly converted from one to the other and back, the two are different, and therefore work differently behind the scenes. One of the many differences between a Google Doc and a Microsoft Word document is the way scripts (or in the Microsoft dialect, “macros”) work. A document can have an associated Apps Script, written in Javascript, that runs a program. To create a sample decoy using Google’s Apps Script, open a new Google Doc, then:

• Click “Extensions” » “Apps Script”
• Enter the following code and save the script

function onOpen(e) {
    var active_user = Session.getActiveUser().getEmail();
    DocumentApp.getUi().alert(`The file was opened by ${active_user}`);
}

Decoy Google Doc designed for protecting an organization would need modified code that can send any generated alerts to the Security Operations Center (SOC). Opening the example document created above results in the proof-of-concept alert shown below.

While Google Apps Scripts are associated with a file, they are not actually part of a file. This means that if a user downloads the file, they will be able to open the file without the Apps Script running. Deception designers need a different approach in order to address the need for alerts when a file is opened on a workstation.

A Word document decoy

Microsoft Word documents have a feature similar to Google Docs Apps Script that can run a program when the document is opened. However, because attackers have a long and storied history of abusing this feature in order to compromise legitimate users, it is often disabled or restricted in ways that make it unsuitable for creating decoys. Instead, local files can insert an image hosted on the internet in the file. Access logs for the image should be monitored to alert a security team that the document has been opened. In this setup, the image serves as the primitive decoy; the file it is stored in is the image’s delivery method.

A decoy image in a Word document can be disguised as a corporate watermark. To create one, open a Word document, then:

• Double click the top of the document to bring up the “Header & Footer” menu
• Click “Quick Parts” » “Field”
• Scroll down in the options and select “IncludedPicture”
• Enter the link to an image whose access logs can be monitored in the “Filename or URL” box
• Check the “Data not stored with document” box
• Click “OK”
• Select “Picture Format” » “Wrap Text” » “Behind Text”
• Resize the image so that it roughly fits the size of the page
• Click “Recolor” » “Washout”

When the file is opened, the document will request the decoy image from wherever it is hosted, resulting in an alert for the SOC team to investigate.

Putting it all together

Whether it is best to deploy Google Docs (or the equivalent file hosting version) or Microsoft Word (or equivalent word editing software version) depends on which action an attacker is expected to take. Decoy documents designed for one medium may not send alerts if opened in the other medium. The information that a SOC receives when alerts do trigger will also vary depending on what kind of decoy it is. This information will determine what actions they are able to take to protect the organization.

If a decoy Google Doc alert triggers as shown above, the SOC will know that either the alert is a true positive and the email address associated with the alert has been compromised, or the alert is a benign positive and the user stumbled across the decoy by accident. On the other hand, a decoy Microsoft Word alert triggers, the SOC will only know the IP address of the person who opened the document; any person who had access to that document could be compromised. If the document is shared widely it may be difficult to narrow down who opened it.

It may make sense to deploy a mix of hosting service decoy documents and offline word editor decoy documents (stored in the hosting service or on user’s workstations). Regardless, it is also important to choose filenames that will entice an attacker to interact with the decoys. Filenames that indicate the file contains passwords, financial information, or other sensitive data should convince attackers to open the decoy files. While files with realistic names are important to attract attacker attention, it is important to choose names that strike a balance between drawing in attackers, generating true positive alerts and fooling unsuspecting employees, resulting in benign positive alerts.