“Cooking” deception. The right way

I wrote my first article about using deception in enterprise networks almost 5 years ago. At that time, it was a pretty new approach and we had to explain it to everybody. A lot of things have changed since that time. Now deception is on hype. We know it for sure as it’s a part of our business. If you don’t believe me, ask Gartner;) Hundreds of companies are now using it. Many of them with our help. Almost every security specialist knows what deceptions is. But… I hear the same on each new project: “Let’s deploy traps in DMZ and server vlans first”, “We don’t need tokens”, “A couple of traps in each vlan is enough” And it makes me sad.

The fact is that now a lot of people know what deception is, but very few of them really understand how to make use of it in real world.

I will try to fill this gap based on my personal experience of dozens TrapX deception projects in different countries.

A bit of theory first

“Distributed Deception Platforms (DDP) are systems that are designed to simulate a variety of computing assets and environments for the purposes of drawing in would-be attackers to clearly alert IT security teams to the presence of attackers, drawing attackers away from real assets, and allowing IT security teams to study the TTPs of attackers to better defend against current and future attacks…

By design, DDPs have a far lower false positive rate than IDS/IPS, SIEMs, and some other tools, which can improve efficiency in SOCs. This is not to say that other detection tools and security data repositories are obsolete; rather, DDPs can be good adjuncts to the standard security suites.”

(John Tolbert, Kuppingercole).

Typical modern DDP consists of three major deception elements:

Emulation Traps – medium interaction honeypots

Fake network devices, emulating real devices on TCP stack level and responding to attackers as though they were real devices typical of the organization. Multiple emulation traps can be connected to each existing organizational network VLAN, each configured as an organizationally relevant device type. For trap realism, you can configure the traps in different ways. Various services as appropriate to emulation type respond realistically to attackers (medium interaction); you can upload fake but realistic data to the traps for exposure to attackers over these services. Additionally, you can specify basic monitoring (low interaction) of any custom port.

Full OS traps – high interaction honeypots

Classic honeypots based on real Windows / Linux system. Full OS traps provide a high level of realism and full attack monitoring. The host computer can be installed from your corporate image and configured with any software, data, and settings. Deception agent will monitor and record not only inbound connections but also outbound activity (for example, if an attacker attempts to connect from full OS trap to another endpoint or to the Internet).

Deception Tokens

Deception tokens ("breadcrumbs", "baits") are lures that are deployed across actual organizational endpoints, inside and outside the organizational network - Windows and Linux, servers and workstations. The tokens are various data items and configuration entries that point to traps inside your network, causing attackers that encounter the tokens to then attempt to connect to those services, triggering an alert.

Let’s start from the very beginning. The first and the most important question you should ask “Why do I need deception?”

Main deception use-cases in enterprise:

1.??????Detection of attacker’s presence on internal reconnaissance stage. Especially in OT and other specialized environments where you are very limited in using agent-based solutions (EDR/XDR).

2.??????Security research and proactive threat hunting.

3.??????Breach detection

?All your next steps depend on your answer. Let’s talk about each use-case. ?

Detection of perimeter penetration and attacks on internal reconnaissance stage.

It’s the most important and problematic use case with a lot of space for mistakes.

Mistake #1. “Let’s place traps in our critical vlans (servers, databases, etc)”

I understand the reason for this. Historically we got used to protect the most critical assists first. But don’t do this with deception. Yes, it’s nice to have deception elements everywhere. But in real world we have limited resources (time, money) and must choose.

Yes, it’s nice if you can detect attacks in server / DB segments. But it means that you already failed before.

Deception allows you to detect attack on very early stages with near zero false positives. The most used attack vector today is social engineering, e.g., attacking end users. It means that end-user vlans are entry gates for attackers in most cases. Put deception there first. The sooner you can detect and stop attack there, in user vlans, the less money and time you will spend to clean up your infrastructure and close the incident.

Mistake #2. “We need only a couple of Full OS traps in each vlan”

No way. Hackers are scanning network, ransomware and any other kind of self-spreading malware is scanning network and doing vulnerability probing. There are a lot of ways how to scan and stay undetected in many cases: use fragmentation, arp scans, idle scans, just staying “low and slow”. It often works and helps to stay “under the radar” of your SIEM or NTA. But It’s all easily detected by deception.

Statistics is on your side. The more traps you create, the more chances to detect the threat. You are limited only by available free address space. It costs nothing for you to allocate half of it for deception. If you need some addresses back – just turn off several traps.

Yes, it can be cumbersome to create and support hundreds or thousands of traps. But no warry. First, use medium interaction traps. They are lightweight and don’t require additional HW, licensing and regular support. It’s a perfect weapon against all active network recon tactics. At this stage you don’t need the detailed information from FullOS honeypots. You need to get an alert and enough information to decide if it’s attack or not. Medium interaction traps are completely OK to do this job.?

The following are recommended high-level best practices for planning and designing the deployment of deception and emulation throughout your organization. Trap deployment should be planned specifically for each of your existing network assets: server segments and workstation segments

• Deploy 5-7 emulation traps per server network segment, 10-15 emulation traps in each standard /24 user network with a variety of emulation types and services typical for this segment. These may include emulated servers, network switches, Windows (various versions), Mac workstations, printers and other IoT devices as relevant.
• Pay attention to trap naming. In general, traps' names should follow the network's hostname convention. Some should have names or name parts representing asset types that are attractive to attackers, such as those that are typically not well protected, and so would be easy to penetrate. Or such as those that would be likely to contain credentials to other assets: host023_dev, test_server456, backup_srv02, IT-Admin, HelpDesk, DBA_PC are nice examples.
• Make sure to enable NBNS on all Windows emulations, to create realistic network traffic.
• To enhance realism, configure any of the emulation traps' Web, MSSQL, RDP and Active Directory services as proxies to real services with fake or obfuscated data.
• To emulate a file server, configure a server emulation with SMB service but don’t leave it empty. Create a directory structure reflecting your organization's file server(s). Upload public, non-sensitive but real or realistic data. Put there some photos from the last year Ney Year party, several saved email messages containing fake credentials, Excel files, network diagrams, fake instructions for connection to “valuable” corporate services, etc. It is recommended to password-protect files, to occupy attackers.
• For some emulated services (such as SMB, FTP, and Linux SSH), configure authentication to slow down attackers; leave others with no authentication.
• For FTP and SSH emulations, make sure to configure the FTP/SSH banners as relevant for your organization. Upload a list of credential sets to authorize for connections to the emulation, making the trap appear more realistic to attackers and causing them to divulge the credentials they have.
• In emulated workstations' SMB services, configure the C$ drive to reflect typical user directory structure, and upload fake personal files such as credentials to IT systems and family pictures.
• On a workstation emulation, create a shared network drive with unrestricted access, emulating an employee who bypassed organizational policy and exposed their disk drive. Don’t forget to put a bogus data on it.
• DO use SMB signing in your production AND deception. SMB is a common communication protocol between endpoints and servers that an attacker may use to try to connect from a compromised endpoint to the emulated SMB service of a Windows emulation trap. SMB is secured by SMB signing; on properly-patched endpoints, SMB signing is enforced. This is recommended by Microsoft. So, if you are using SMB v2/3 and SMB signing, make sure that it is supported by your deception solution. For traps to be able to properly authenticate and respond to these signed connections, and to improve traps' ability to report additional information on attackers, integrate your deception appliances with your organizational domain controller (DC). Otherwise, an attacker will easily spot your traps. In case of TrapX which has SMB signing support, it will allow you to automatically add all your Windows-like honeypots in your Active Directory as well.
• Be creative! If you have in-house applications or specific hardware which can be attacked, create your own custom traps. Any DDP vendor can create them for you. If you use TrapX, you can do it by yourself right from the web console. Just go to BYOT tab (Bring Your Own Trap), “point and shoot” and TrapX will create a realistic emulation including the native web-management / login pages inside.

All this may look cumbersome at the first glance. Deception landscape planning, trap creation, tuning, etc. Automation is here to help you! All modern deception platforms offer various tools for trap deployment automation. You can easily deploy thousands of traps using several methods for large-scale deployment:

• Range-based mass deployment. Just define address ranges to create specified or random emulated traps on it.
• CSV-based deployment. Edit and upload a CSV file with interfaces and traps configuration.
• Programmatic range-based mass deployment. Create JSON configuration of entire interface and trap configuration, including stepped ip ranges and specified or random emulations.

?

Mistake #3 “We don’t believe in emulated traps and will use only FullOS traps”

FullOS is cool. It provides the highest level of realism and full attack monitoring because it is actually a real dedicated Windows/Linux based PC or VM. The host computer can be configured with any software, data, and settings, and deception software will monitor and record all network activity, file system and registry operations. As a result, an attacker will spend more time in this real, but controlled environment and leave more information and tracks to investigate.

But each FullOS consumes resources, needs valid Microsoft license (if you run MS-based full OS), it requires regular support and administration.

Let’s assume that you are SME with 10 vlans and want at least 5 traps in each vlan (which is not enough). If you want to use FullOS only, it means that you must deploy and keep 50 new computers/VMs. It will be pretty costly not only in CAPEX, but in OPEX as well.

Yes, again, you can use emulated traps to overcome it. But they are not so realistic like FullOS and collect less telemetry. ?So, you need to choose between coverage and full details and TTPs.

Fortunately, modern deception solutions have workarounds. For example, in TrapX it’s enough to have only a couple of FullOS traps to get the full telemetry about attacks.?You can use a Full OS trap to transparently provide a real service to respond to attackers of emulation traps, and full monitoring of those attacks. This is achieved by proxying emulation traps' services to a Full OS trap. For example, you can have multiple emulation traps proxy Remote Desktop (RDP) or WMI / SSH / whatever sessions to a full Windows Server trap. Attackers who connect to any of those targets will be provided with full real desktop or shell experiences, and their activity will be fully recorded by the Full OS trap.

Thus you can achieve full coverage with emulated traps and full telemetry by proxying requests to FullOS traps.

Mistake #4. “Traps are enough for us. We will not use deception tokens”

Deception tokens deployment is the hardest part in every deception project. Here we are interrogating with real users’ environments with all their restrictions, group policies, AV/EDRs, etc. I don’t remember a project where we had no problems with it. You need a lot of planning and testing to make it right. But it worth it for sure.

Deception tokens significantly add to the deception power of the traps, reducing the time it takes to detect attacks and defend against them. Tokens can be designed and distributed so that multiple tokens across disparate endpoints create the illusion of the target traps being real and significant organizational assets.

The following are some general high-level recommendations for deploying deception tokens.

• Deception tokens point to specific server emulations. So, tokens should be configured and deployed separately for each organizational location or unit that interacts with a specific set of servers. Simply said, use different sets of tokens for different departments.
• Deploy the following token types to all relevant endpoints, for each relevant server trap:

SMB Network Share: To traps with SMB service.

ODBC/Oracle tokens: To traps with MS SQL Server or face Oracle DB.

RDP: To traps with RDP service.

Cached Credentials (with tracking by SIEM)

SSH keys / PuTTY sessions / WinSCP sessions: deploy it in IT dep only.

To users' endpoints that access critical web applications, deploy Browser History / Credentials / Bookmark tokens.

On organizational domain controllers, deploy Active Directory tokens for traps (or use SMB signing if it is supported by your DDP to make it automatically).

• Test, test, and test again each token set before mass deployment. First time – 1 PC in lab, second time – one PC in target unit, third time – limited group of PCs in target unit. A lot of things can go wrong, so it’s nice to have automated tools to track token deployment.

Mistake #5. “We want to place traps in DMZ to protect our public facing services”

You will not be bored if you do like this. You will get hundreds or even thousands of alerts daily. But what will you do with all this? What can you do with Shodan/Censys scanners and hundreds of script-kiddies from China, Korea, Brazil, Russia scanning your network? You don’t have too much choice. You can grab all source IPs and add them to block lists on your firewalls to offload a bit your public infrastructure. That’s it. Generally, all this information is not actionable. Thus, if to think about intrusion detection, deception deployment in DMZ/public segments is the waste of money. But!

There are three use cases when you can and should place deceptive traps in DMZ or public network.

1.??????Remote workforce protection.

Today in COVID time we are working from home like a lot of our partners and customers. We are using personal devices, which may be not enough protected and monitored. We are using untrusted networks (home or public Wi-Fi) to connect to our corporate stuff. We store or enter our corporate credentials on these devices. That’s why remote a worker is the “juicy” target for any attacker. She’s not enough protected but have everything attacker needs to get into a corporate network.

Deception can help you with this use-case as well. You can deploy special deceptions tokens on remote users’ notebooks (VPN Credentials and profiles, saved RDP creds, etc) and place the corresponding traps in DMZ.

Any attacker will not miss a chance to get into the corporate network if he finds a corporate VPN profile and credentials. But now you will be ready and waiting for it. When it happens you will immediately and exactly know who from your remote users is compromised.

TrapX has special tokens and traps for this use-case available “out of the box”: FortiGate VPN emulations, public Windows server emulations, etc.

2.??????Security research and proactive threat hunting.

Another nice use case for deception. Historically, honeypots were used like this for 20 years. You may create FullOS traps, based on your real public facing hosts, but with fake data inside. Put them in DMZ and start collecting IoC and studying attacker’s tactic and tools there. You can use the collected information to search for the same indicators in your production, tune your Yara/Sigma rules, firewall policies, etc. Bur be prepared for A LOT of events;)

3.??????Breach detection

CHECK WITH YOUR LEGAL TEAM FIRST! IT MAY BE ILLEGAL IN YOUR COUNTRY.?

You can inject a special implant to your office documents, which can “call back” upon opening this file. So, you can prepare several files, distribute them across your file storages and fire up a special listener in DMZ (public trap in terms of TrapX).

If your files are leaked and opened somewhere outside, you will have a notification in your console after someone opens such files.

You can use special tracking services to do the same if you have no plans to deploy a full-featured deception platform like TrapX.

Mistake #6. “We don’t want another console/screen in our SOC. Integrate deception with our SIEM/SOAR and that’s’ it”

Don’t underestimate the importance of integration. Deception planform as a low false positive monitoring and alert system can add a lot to any 3rd party security solution. For example:

• NAC (Network Access Control Integration) integration will allow you to automatically divert the attacker to quarantine network, out from production. It’s crucial especially when you are faced with ransomware and other types of self-spreading malware. They are really fast;(
• “Sandbox” integration will allow you to automatically send captured malware binary samples for analysis and get the report with IoCs and sandbox verdict.
• SIEM integration will allow to centralize your security monitoring, avoid security islands and gaps, apply more sophisticated logic and rules to security events.
• EDR integration will allow you to stop an attack on host level and immediately populate detected IoC across all your enterprise.
• NGFW integration will help you to block or additionally monitor detected suspicious network sessions.

There are hundreds of IT security vendors on the market so deception solution should have not only many “out of the box” connectors, but be able to integrate with virtually anything via API/SDK/CLI, like TrapX;)

Also, I wouldn’t advise you to rely solely on SIEM dashboards and reports. Typical SIEM has hundreds of data sources and is connected to production systems. Even when you are clean and safe you may have thousands of events in your SIEM daily. It’s very easy to miss the early stage of attack in this production noise.

Deception platform is not a part of production by design. So, there is no production noise there and all attacks are immediately become visible, and you will have more time to react. Time of detection and reaction is essential because it may take only 20 minutes for attacker to escalate to Domain Admin. Ransomware works even faster.

TrapX has very convenient interactive, filterable map of event sources, with summaries and drill-down to the Event Analyzer. The visualization enables security operations teams to rapidly understand attacker activities throughout network assets and over time from intrusion to final containment.

Also it helps you to detect “low and slow” malware and attackers who are not in hurry and stay “under the radar”

You can set up triggers to speed up reaction as well. Triggers are like reports, but event-driven. For example, you may want to get an email alert immediately after suspicious activity discovery in your most critical network segments. Just set up a trigger

General recommendations

Secure your DDP

All modern DDPs have more or less similar distributed architecture with central management console and trap servers/appliances. Compromising your deception management console will not only give an attacker information about your traps, but the ability to turn them off and blind you.

Trap servers or deception appliances act like virtual switches. Thus, compromising this host will give to attacker an access to all connected subnets and vlans.

That’s why your DDP should be additionally secured, despite it is not a part of production.

General security recommendations:

• Use the least privileges principle leveraging built-in RBAC model
• Disable unneeded network services
• Change default passwords and use strong ones instead
• Use LDAP accounts, SSO and MFA to access your DDP management console
• Set up a fixed list of hosts which can access your DDP management console
• Use idle timeouts to log out users in case of inactivity
• Check updates weekly and keep your DDP updated
• DO! backups before each update and major reconfiguration using built-in DDP capabilities of VM snapshots.

Keep your DDP clean.

Zero false positive approach is the strongest side of deception concept. Any deception solution is binary and deterministic by design. No “security scores”, ratings, probabilities, etc.

But the real world is not so simple. You will find for sure some “noisy” systems in every infrastructure. For example, vulnerability scanners, inventory and backup systems, configuration management and monitoring systems like MS SCCM, Ivanti, Zabbix, etc. These systems should be excluded from monitoring and added to exceptions so you will not get any false alerts in your DDP from them.

The problem is if this excluded system gets compromised, you will not detect it. That’s why these exclusions should be far smarter than just adding IP to exception list.

For example, in TrapX you can configure exceptions defined by specified values of various parameters. Depending on trap type, these parameters may include network connection, host, port, files, registry settings and processes.

Keep everything around clean

Deception is a “double edged sword”. By crafting traps you create a minefield for attackers. At the same time, it may negatively impact your other systems like vulnerability scanners, CMDB, etc. One day suddenly they will see a lot of new vulnerable assets, and nobody will be happy because it’s often the matter of compliance.?To avoid false-positive alerts in these 3rd party systems you have to somehow make all your deception elements invisible for them. ?In TrapX it’s enough to add them to exceptions and check just one check-box - enable “Dark mode”. Emulation traps will not respond at all to TCP connections from these excluded IP addresses after this.

Conclusion

I will be happy if you can share with me your experience, use cases and ideas about using deception. If you don't have it yet, feel free to ping me and we will arrange PoC;)