DECEPTION, BREACHES, AND GOING ON THE OFFENSE TO SEED THE HUNT

This post was originally published here by Matthew Hosburgh.

In my previous blog, I explored the areas where certain areas of Active Defense could be used to help seed a hunt.These techniques allow the Threat Hunter to go on the offense (in terms of more proactive defense). This is increasingly more important to reduce the time it takes to detect a breach and potentially, to prevent one. The Active Defense (AD) technique of attribution can be used to identify areas that require more scrutiny. The misnomer is that attribution is too hard or not effective for smaller, non-government organizations. The way this will be used for a Threat Hunt isn’t necessarily about implicating an attacker or insider by IP from a call-back. It’s more about getting an early indicator that can be used to further hunt for unwanted actions on your network. Where the AD attribution shines brightest, for me as a Threat Hunter, is the ability to help detect anomalous behavior around data leaks, both from insiders and advanced adversaries who have breached your network.

Canary Tokens and Web-Bugs

When talking about attribution in terms of Active Defense, there are two go-to systems that allow for the seeding of a hunt. The first tool is bundled in the Active Defense Harbinger Distribution (ADHD), called the Web-Bug-Server. In the most fundamental terms, this server is the “call back” server for your bugged documents. How it works:

1. Create several bugged documents with unique IDs that may be of interest to an attacker
2. Map the document ID / name to a location where it is to be staged (ideally some near sensitive data, and some in other innocuous locations)
3. Stage the documents
4. Alert on any callbacks received (document when opened sends a beacon back to the Web-Bug-Server, noting IP, user-agent string, ID and time)
5. Note the calling IP address i.e. is it internal or external. If external you’ve got a real problem, continue on. If internal continue on
6. Hunt on activities around the callbacks (use a temporal or time-slice analysis)

For a visual, the diagram in figure 1 is a simple representation of the Web-Bug-Server infrastructure as it might relate to an organization’s infrastructure.

Figure 1. Example Web-Bug-Server InfrastructureAnother, and arguably, more Hunter friendly is Thinkst’s Canary Tokens. Canary Tokens expand the concept of web-bugs to another level. Basically, they afford a more diverse set of files and options for setting the trap. With a web interface to work with, setting up Canary Tokens is a breeze. Additionally, there is a cloud version, or you have the option of rolling your own—and even in Docker. The various types of tokens can be seen in figure 2.

The Campaign

Now that the documents and other tokens have been scattered throughout key points within the environment, alerts start to roll in. What can be learned from the call-back? There are two main points:

1. If the call-back is from a local IP, or a NAT’d IP of your organization, then the bugged document more than likely was triggered from within, which does not necessarily mean that all is well—it just means the data has not left the organization –yet.
2. If the callback is from an external IP, the bugged document has left the building! This is more precarious because now the question is, “how did it leave?”. Was it copied to a thumb drive? Did it get attached to an email and sent out?  Was it uploaded to a cloud storage provider? What if it was none of the above? That’s where more hunting is warranted.

Leveraging Canary Tokens, when a bugged document is triggered, the incident details can be seen in figure 3.

Logs and Pivot Points

Because the system receiving the call-back traffic is a webserver, a log is generated. Based on your organization’s logging and monitoring, this should be an easy way to get the log out of the system to generate an alert. In this case, the log for this traffic is sent via JSON or syslog to the respective logging server and easily ingested into the Sqrrl platform. Once in the platform, an alert can be generated with ease.

With an alert, or early indicator, the following would be next steps:

1. Determined who accessed the document
2. When and how many times it was accessed
3. If found outside the environment determine how it got there
4. Examine additional behavior:
   1. Lateral movement
   2. Data exfiltration
   3. Covert channels

A lot more

As is with most hunts, an alert or indicator will probably only get you in the ballpark. Further hunt activities will need to be conducted to determine the entire scope.

Conclusion

Active Defense techniques can be a force multiplier for a Hunter. In this example the goal would be to reduce the time it takes for an organization to know that something is awry, which may point to data staging or exfiltration. Several tools and techniques exist that can be easily deployed to assist in seeding the hunt with this data source. Alerting on bugged data before any real data is lost could mean that a massive breach is prevented, or minimized. Attribution doesn’t need to be absolute for this example to work. It is simply a way, or simple set of tools, to understand who is accessing your bugged documents. From that knowledge, subsequent hunting activities can be conducted.