Fake documents, credentials and honeypots can expose even an attacker who is moving through the network under a valid identity and blending into normal activity. How do deception tools work, and why do they generate highly accurate, high-confidence alerts?
Deception tools place fake accounts, documents and services inside an organisation’s infrastructure – assets that legitimate users have no reason to touch. If somebody else interacts with them, the SOC receives a strong signal that something malicious is likely taking place. It is often the first trace of an attack that had previously remained hidden in operational noise.
How deception tools complement EDR and SIEM in attacker detection
EDR, SIEM a ďalšie monitorovacie technológie sú základom modernej obrany. Zbierajú obrovské množstvo telemetrie, hľadajú známe indikátory a spájajú udalosti do podozrivých vzorcov. Ani ony však nevidia všetko.
“EDR is an essential tool, but an attacker does not necessarily need to use anything that looks like malware at first glance. They can move through the environment using native Windows tools and hide in operational noise,” explains Ján „Honza“ Linhart, SOC manager v Binary Confidence.
An advanced attacker may use legitimate operating-system components. They perform reconnaissance, map accounts and services, move between devices or work with valid credentials. Such living-off-the-land activity can disappear among thousands of routine operations. Attackers may also use techniques that weaken or partially blind security telemetry.
Deception does not replace existing protection; it supplements it with a fundamentally different approach. Instead of searching for everything suspicious, it creates something a legitimate user does not need but an attacker is likely to find attractive.
Cyber decoys: phishing turned against the attacker
Fake documents, accounts, credentials, web links, servers and even complete host systems can be distributed throughout the infrastructure. Ordinary users do not work with them and production processes do not require them. An attacker mapping the environment and looking for a path to valuable data, however, may see them as an opportunity.
“It is social engineering in reverse. It works much like phishing, except that this time we prepare the lure for the attacker. When they move through a network and discover something that appears unusually valuable, they naturally want to investigate it,” says Ján.
Honey tokens, honey credentials, honey services
Honey tokens are fake documents, files or links that send a signal when opened. A token can also be embedded in a real website. If somebody clones the site to create a phishing copy, they reveal themselves as soon as they display the fake page.
Honey credentials are planted login details and secrets. An alert is generated the moment somebody attempts to use them.
Honey services imitate services such as RDP, SSH or a web service. They appear credible and record every interaction.
Honeypots are complete decoy devices or systems. Depending on their level of interactivity, they can capture a longer sequence of actions and reveal what the attacker is trying to achieve.
How to configure a credible honeypot: the See–Think–Do framework
Binary Confidence uses the See–Think–Do framework when designing deception environments. An effective decoy must meet three conditions: the attacker must be able to see it, believe it and do something with it.
First, the decoy is placed where an attacker is likely to find it during reconnaissance: account lists, password managers, shared folders or services visible during network scanning. It must then fit naturally into the client’s environment. A fake account, document or server cannot look like a generic trap downloaded from the internet. Finally, it must be interactive enough to capture the action, its source and the attacker’s intent.
Sophisticated attackers are familiar with honeypots. They examine typical names, service responses, default settings and technical fingerprints. If an organisation simply deploys an unchanged open-source honeypot, an experienced adversary may identify and bypass it.
“The foundation can be built on open-source technology and still deliver major impact at a low cost. But the honeypot itself is not where the value lies. What matters is analysing the infrastructure, deciding what we want to protect, making the decoys credible and connecting them to the security team’s response,” Ján emphasises.
This is why decoy elements are modelled on the client’s real assets and distributed across Active Directory, endpoints, file stores, RDP and SSH environments, websites and cloud infrastructure. The decoy may be a fake AD user, planted credentials in device memory or a convincing document placed on an administrator’s desktop.
Why decoy alerts generate very few false positives
The greatest advantage of a deception layer is its extremely low false-positive rate. A legitimate employee has no reason to sign in with a fake account, open a decoy file in an administrator’s folder or use a planted API key. An interaction with a decoy is therefore a high-confidence event.
Not every alert automatically confirms a cyberattack. An administrator may enter the wrong IP address or attempt to connect to the wrong virtual machine. Even then, the event reveals a mistake worth investigating.
“If someone attempts to use an account they should not know about, either an administrator has made a mistake – which is also important information – or the decoy has been touched by somebody who has no reason to be in that part of the environment,” says Honza Linhart
Deception can also help detect insider threats. Not every administrator therefore needs to know about the decoys, and the full strategy is shared only with a small group of responsible people. “To some extent, it is counterintelligence inside your own infrastructure,” Ján adds.
Deploying deception tools in two to four weeks
Triggering a decoy is not the end of the process; it is the beginning. Honey services, tokens and credentials send logs to the SIEM, where they can be correlated with other telemetry. Honey documents and tokens can trigger a webhook directly into a SOAR platform, ticketing system or communication channel. A SOC analyst investigates the event, enriches it with context and launches the appropriate response playbook.
Deployment does not have to mean months of work or an agent on every production server. Organisations can begin with a two- to four-week proof of functionality using several decoys. Once real alerts have been validated, the project can move to a broader pilot, SIEM and SOAR integration, and tuned response scenarios. The result can be a fully operational deception layer monitored by a SOC around the clock.
An attacker who has already gained access will try not to look like an attacker. We cannot rely on them making a noisy mistake every time. We can, however, arrange for them to find something in the places they explore that no legitimate user would ever need to touch. At that moment, they expose themselves.
This activity is supported by the European Cybersecurity Competence Centre (ECCC) as part of the project under grant code 101145856, and by the Ministry of Investments, Regional Development and Informatization as part of the state programme of the Recovery and Resilience Plan of the Slovak Republic under project grant code 17I04-04-V02-00001.
