Betteridge’s law of headlines is an adage that explains that “Any headline that ends in a question mark can be answered by the word no.”1 Back in March 2017, I asked “Will Deception as a Defense Become Mainstream?” No, deception hasn’t become mainstream yet. But, here and there, deception does poke its fingers into the mainstream. A few months after I wrote that blog, the French used deceptive cyber-defenses to neuter Russian election tampering attempts.2 In fact, I’ve mentioned before that deception is a useful countermeasure to advanced persistent threats that can overwhelm traditional defenses. Gartner has predicted that by the end of this year, 1 in 10 enterprises will be using deception against cyber-attackers.3
It’s a simple matter: our systems are under a constant state of attack, while our options to strike back are extremely limited. We can only react to defend ourselves as the attacks rain in. Only the government is allowed to strike back at our attackers and, frankly, some of their biggest successes involved deception. In any case, it often takes law enforcement months or years before making an arrest. In the meantime, our systems are pummeled relentlessly. As Stewart Baker, former General Counsel of the National Security Agency, said:
“The hard fact is that we can’t defend our way out of the current security crisis, any more than we can end street crime by requiring pedestrians to wear better and better body armor.”4
We cannot be forever playing defense. A workable, legally defensible active defense is using deception. Deception has been part of warfare since the beginning, it should be part of cyber-warfare.
A majority of our cyber technical defenses are binary: allow or block based on some testable condition. If we block the attacker, then they either go away or try again. For the advanced persistent threat, it’s likely they will try again. What if we tried something else? What if we could delay, divert, or deceive our attackers to waste their time and study their tactics?
Delaying with Deception
Secretly slowing down attack traffic might be a minor deception, but it can be quite effective. This idea has been around for decades as an application service—the network tarpit5—that deliberately responds slowly. The concept is to slow down attackers while sounding an alarm for incident responders to track and analyze the attack. With newer, reprogrammable network security devices, we can do this in real time as soon as network traffic is identified as suspicious. This kind of tactic works best on automated vulnerability scans and exploit attempts involving TCP connections, such as credential stuffing attacks or SQL injection attacks. Specifically, attacks can be covertly delayed by:
- Slowing down packet response times in network connections
- Killing large transfers just before they’re done
- Making random (sending or response) packet modifications to confuse the attack tool
- Offering up huge data streams of random gibberish as responses to queries
- Inserting randomly misleading error messages into the return stream
- Taking the previous idea one step further to make it appear that an attack succeeded but didn’t (sending an HTTP 200 instead of a 404 to a URL scan)6
These tactics work very well on automated tools and bots, which often waste their time either retrying or attempting to exploit non-existent vulnerabilities. Nothing like having your network defenses give the impression that your site is slowing down under a DDoS bot attack while it really is just fine! It’s harder to fool attackers working interactively with their tools (as opposed to purely automated attacks) since the attacker quickly realizes what’s going on and shifts tactics. Although in some cases, an attacker may spend time tinkering with their tool to see if it has a bug rather than thinking a victim is toying with them.
Diverting with Deception
There are times when you want to secretly redirect a potential attacker away from your important resources to a site where any impacts are diminished. Again, programmable network security devices can do this. A device that can load-balance or do dynamic DNS redirection can be triggered to move an in-progress attack to a site that looks like the original site. Think of how hybrid DDoS systems work, moving traffic from your local presence to an offsite-hosted network cleaning service. Same idea, but you’re moving to a false site for deception activities.
A quick and dirty location to divert attacks into is a QA/test or development version of the main site. It’ll look real but won’t have valid data or users running on it. The bonus is that test/dev sites are often heavily instrumented to record user interactions and traffic load, making it easier to study attack traffic. Just remember to warn the testers/developers when you do this.
You can also add diversion services on an existing site to draw attacker fire away from the primary application. For example, add a “/admin” to a web app, especially if an admin console doesn’t exist already. Even better, rename the admin console something other than the obvious name and place the fake “admin” in its location. Attacker scanners will seek it out while legitimate users won’t. If someone hits that page, you know their intentions are hostile, and you can fire off an alert while they waste time on a dummy page. You can create other URL targets based on analysis of threat intelligence or attack traffic. Hint: Read your webserver logs and look for long patterns of scans for non-existent pages from apparently random IP addresses. These are probably bot-based scans.
These are basic diversions, but you can easily take it a step further and really get creative with more interactive diversion sites. I call those “Potemkin” apps, and I’ll describe them in part 2 of this blog series.
