Many an old sparring session has been witnessed on this subject here at Smokescreen. Buckle up, this is going to be a long read.
When someone asks “How many decoys do I need?”, what they’re really asking is how many decoys do I need to make sure that I can catch the adversary.
Deception has toed the industry line on this question. It seems natural to want comprehensive coverage. After all, you wouldn’t buy antivirus licenses for just 20% of your organisation. The technology, too, has been able to keep pace – you can literally place deception in every part of your environment. Notice I said, “you can”. Just because you can, doesn’t mean you should.
That deception everywhere thinking might have made sense five years ago when deception technology was just hitting the market but does it hold today? To answer that, we’re going to dive into our experience of 80+ deception deployments to see if there’s a case to be made to rethink how we size, scope, and deploy deception in the enterprise.
We’re dropping our vendor hat and will analyse this problem from the perspective of the entity we hope to thwart using deception – the attacker / adversary.
Colloquially, the APT. This is either an organised crime group or a nation-state grade attacker. They are targeted in their approach. They want something valuable you have – intel, a database, a transaction processing system, a formula, intellectual property, confidential non-public information, access to your CEOs email, etc. They will deploy specialised, customised malware, infrastructure, and tooling to achieve these means. They spend time understanding you and focus heavily on avoiding detection. If they do get detected, they count on the fact that you won’t do anything about it until they are already gone.
Definition of a decoy: Any fake machine, file, credential, account or lure placed in the network.
Let’s assume that you do not have the ability to do the following in your network:
- Deploy fake machines in every segment.
- Deploy endpoint deception to every single machine.
- Make drastic changes like adding decoy mapped drives or opening decoy ports on the endpoint without incurring significant operational pain.
Let’s also assume that the initial entry point and the subnet on which the entry point machine resides has no deception whatsoever. It means, you are running blind at the point of first infection.
With these constraints, what does an effective deception deployment look like, so you can detect the adversary?
Let’s say the crown jewel here is the production customer database.
For an adversary to be able to access the database (actually, any database), they will need:
- The IP address / hostname of the DB server
- Credentials to login to the server using OS / DB credentials
Let’s run a couple of scenarios to see how this plays out.
Scenario 1: The adversary has all pieces of information because they were leaked on the Internet
Does deception help in this scenario? The answer is no. In fact, you could cast reasonable doubt on whether any security product will be able to stop this.
Scenario 2: The adversary has the IP address but not the credentials
In such a scenario, the database server reconnaissance has already happened. The adversary would know exactly which set of account credentials are required to login to the server.
This scenario throws an interesting question. Where can one find the credentials? What are the options available?
- Guess OS passwords to the server (in windows, these can be local or domain accounts).
- Guess / brute force default account passwords configured on the database.
- Search the environment hoping someone has written down the passwords in an accessible file share.
- Find a way to backdoor the administrators of the server and steal their credentials to leverage access.
- Wait for an unauthenticated remote code execution zero-day to be released.
Unmanaged accounts like in #1 & #2 should be hardened, especially since we are talking about a business-critical system. #5 is also a hard sell in this scenario.
How many decoys do you need?
- A fake account that from the username is made to look like it can login to the database server (dbserveradmin?) and the database itself (sqlserveradmin).
- Endpoint deception on the DB and DB server OS administrator machines.
- A decoy file share with data that looks like it contains information about the DB server.
So, if you have 10 OS administrators and 10 DB administrators, you’ll need 2 fake AD accounts + 1 network decoy hosting a file share + 20 endpoint decoys.
Scenario 3: The adversary does not have the IP / Hostname of the DB server
How do you find the hostname or IP address of a database server?
- LDAP / Active Directory / DNS brute force: The phonebook of the internal network. The adversary could do something as simple as query the word “db” and build a list of potential databases. They could identify computers, groups, users, and a wealth of other information from Active Directory to at least build a potential list of targets (either DB admins, OS admins, or servers)
- Let’s say your database server isn’t linked to any directory service. In this case, the adversary would have to hunt on the network to find information like asset information stored in open file shares or intranet portals. You can get really creative with how you look for this information.
- Attack the users who are likely to have access to the database.
- Short of finding the hostname / IP address directly in the directory or using creative logic to attack likely locations where this information is stored, the only remaining option is to scan the entire private IP range for the DB server based on its port. Once you have that, you eliminate it one by one.
Considering the above, the following are the four deception possibilities:
- Add entries into your Active Directory that are likely to be triggered on searches for databases.
- Create file shares that seem to contain asset information about the database.
- Create fake accounts and drop endpoint deception on actual database administrators.
- Place a database decoy preceding and succeeding the IP address of the actual database server.
How many decoys do you need?
A couple of Active Directory entries for databases + A network decoy hosting a file share + 2 network decoys hosting decoy databases + the deception in Scenario 2.
All in all, at this point, you’ll add around 5 additional decoys.
How many Network Decoys do I need?
Network decoys require special consideration as they are the hottest topic of debate because the process of deploying them requires VLAN trunking. The questions are:
- Which VLANs do I trunk?
- How many VLANs do I trunk?
- I can’t trunk all VLANs, what do I do?
In our proposed strategy, it is possible for you to avoid trunking entirely. Just add a file share in the same subnet as your real file share. Place a database decoy preceding and succeeding the IP address of the actual database server.
If we consider only the “production” version in our database server scenario, we need a total of 3 network decoys (a decoy file share and two fake database servers) to achieve a reasonable strategy that covers the most likely outcomes.
If it makes you feel comfortable, you can double this up and it’s still only 6 network decoys.
If you want to cover your test and UAT environments for the database server, that’s 9 network decoys.
If you want to cover an additional scenario, that’s 18 network decoys.
There is a cogent case to be made here that it is certainly not necessary to deploy decoys everywhere and you can still achieve effectiveness. Our example scenario needed no more than 6 network decoys, a couple of fake accounts, fake computer entries in Active Directory, and endpoint deception deployed to a very targeted group.
With a focused deployment, you will understand exactly what tactics you are attempting to cover with deception and you can sleep well knowing you have achieved that outcome. If you find yourself attempting to blanket your network with deception, it is likely you are adopting the spray and pray approach which usually has little value. You’ll be chasing sheep when you have the opportunity to catch the wolves.
Open Source Honeypots That Detect Threats For Free
7 Ways to Fail At Implementing Deception Technology
10 Questions To Ask Deception Technology Vendors
- Detect zero-days, APTs, and insider threats
- 10x the detection capabilities with 1/2 the team
- Get started in minutes, fully functional in hours