Poison the well: Offensive ops for defenders

The old adage of “The best defense is a good offense” has started to gain traction amongst security operations center (SOC) and information security teams alike. But to many, consistent red teaming and penetration testing may seem like a lofty goal that feels secondary to investigating the deluge of alerts and alarms they face.

If you find yourself not able to dedicate the time and resources to fully developed mock attacks, you can always go on the offensive by trying to predict what an attacker might do and use it against them. And there’s a good chance that whomever the attacker is, they’ll be looking to exfiltrate data.

Seeding tainted files

In this post, we will explore the technique of seeding “tainted” files (i.e. files embedded with a payload) around a network in order to catch a malicious actor stealing valuable information. One of our tools of choice is an open-source post-exploitation tool, PowerShell Empire. It has robust exploitation capabilities and a nifty REST API that makes integration with Swimlane a snap.

Embed a payload

First, we’ll need to create the files we want to place around our network. For the purposes of this post, we’ll assume you know how to embed a payload into various media forms. If not, here are a few basics.

The key is to make them look good but not too good. We want the attackers to believe they have stumbled upon something valuable that we’d rather them not have. The files need to be consistent with items found throughout your network but named to catch the eye. Empire gives you many options for payloads, so mix it up. If you have development going on internally, sprinkle in more than just Word documents. ELF binaries are a great way to diversify.

While we’re talking about sowing a wide swath with these files, to maximize the chances that we pique an attacker’s interest we need numerous file types in multiple locations. User endpoints are great, but file servers are prime locations for data exfiltration. Unless an attacker is severely limited by time, they are often going to seek file shares as one of the main targets. Additionally, don’t stash the files on honeypots (fake servers) within your system and think that you’re going to misdirect attackers to those rather than legitimate servers. Make the tainted files look promising by adding them into production systems.

So, now we have embedded files waiting on an attacker to pull them down and open them up. But, what do we do once we catch a callback? Why seed files at all? Well, first off, if sensitive data is being stolen you probably need to know about it. More importantly there are only a handful of ways to stop attackers like this, and the answer is not to “hack back.” For true APTs, the only way to keep them at bay is to either expose their tools (exploits, payloads, etc.) or expose their infrastructure. Making either of those elements public will force them to make changes, which are often costly or severely impact their operations.

Oh, and look. We just caught a callback (of course, we normally won’t see this because we’re automating through Swimlane)…

We will treat ingestion into Swimlane like we would from any other source. We have an integration with Empire that does the following:

1. Checks every minute for the Status of our Empire Listeners
2. Checks every minute for Empire Agents
3. If an Agent session is established, Swimlane Workflow executes a series of actions depending on specific conditions.

We know that time is critical is here because an attacker may just be beginning their exfiltration. Or, they may become savvy to our endeavors, and we should gather as much intel about who they are and their tools as quickly as possible. We need to treat this as if we only get one look at an attackers’ machine.

Using Swimlane’s Workflow, we’ve already defined what actions need to be taken should we catch a callback from our “special” files.

Regardless of whether it’s an internal or external IP (either could be a possible pivot point for attackers), we decide to run some of our PowerShell DFIR commands and send notifications. These tasks include getting the arp cache, netstat, processes, checking for hollow processes (and retrieving a memory dump if we find any), screenshots, drive enumeration and more:

Just remember if it’s an external IP, there is a larger chance that whatever we task the agent to do on callback won’t get executed. That’s because most APTs will curtail the communications allowed in and out of their network. So, best practice is to get as much from the initial callback as possible. Luckily, with Empire you can modify the payload before you Base64 and embed it; so go wild with modifications.

Time to start a detailed investigation

Is that it? Of course not. We’ve got some of the attackers TTPs, which are probably being reused, and we’re ready to begin a more detailed investigation. But, we’ll deal with that in a separate post. For today, consider it a job well done to be able to use an open source tool and automation to track down malicious actors within the network and gather time-sensitive data.