What are cyber decoys?

The idea behind them

Most detection works by describing normal and looking for departures from it. That is difficult, because normal is enormous, changes weekly, and looks a lot like an attacker who is being careful.

Decoys invert the problem. Instead of asking whether an event is suspicious, you create assets that only an intruder would ever touch, then wait. There is no baseline to model and no threshold to tune. The signal is binary: it was touched, or it was not.

What can be a decoy

• Credentials. An account that exists in the directory and nowhere else — never used, never assigned. Any authentication attempt against it means someone is working through a credential dump or a harvested set.
• Documents. A file with an inviting name on a share, which calls home when opened.
• Hosts and services. A machine or service that answers on the network but serves nothing real, so a scan reaches it.
• Keys and tokens. An API key or token left where a scraper would find it, valid enough to be tried and instrumented so the attempt is recorded.

How SphereTI distinguishes decoys from honeypots

The terms are often used interchangeably, and there is no universal boundary between them. SphereTI uses honeypot for a fuller fake system, often placed outside the perimeter and built to be interacted with at length so researchers can study what an attacker does. It is a research instrument, and it takes real effort to run safely.

MITRE D3FEND uses the broader term Decoy Object for an object deployed to deceive attackers, with subclasses including decoy files, credentials, session tokens, and network resources.

A decoy is deliberately smaller. It lives inside the real environment, alongside genuine assets, and its entire job is to be touched once. It does not need to hold an attacker's attention or convince them for long — the alert has already fired.

What they catch that other controls miss

Decoys are positioned for the part of an intrusion that happens after prevention has already failed:

• Lateral movement. An intruder with one foothold enumerating shares, hosts, and accounts to find the next step.
• Credential replay. Someone working through a set of credentials — from a stealer log, for instance — to see which still work.
• Insider activity. Someone with legitimate access reaching for things their role has no reason to reach for.
• Reconnaissance. Scanning and discovery that precedes a targeted action.

None of these look like malware. All of them look like ordinary authenticated activity — which is exactly why an asset that nobody should be touching is such a useful thing to own.

Placing them without creating noise

A decoy is only as good as its position and its plausibility. Two practical constraints:

• Put them where an attacker enumerates, not where staff work. A decoy on a busy share that colleagues open by accident stops being a high-confidence signal.
• Make them indistinguishable from the real thing — naming, location, and metadata consistent with everything around them. A decoy that announces itself is one an attacker learns to route around.

Document them internally, too. Legitimate scans, backup jobs, misconfiguration, or an undocumented use can create noise; the alert is high-confidence only when the team has verified that no legitimate workflow should touch the asset.

How SphereTI approaches it

Cyber decoys are one of five modules in the platform, positioned as early warning: catching attacker movement before real systems are touched. Signals from the decoys feed the same alerting as the rest of the platform, so an interaction arrives with an explanation of what was found, why it matters, and what to do next — in context with what SphereTI already knows about your exposed credentials and external footprint. Decoys are the one module the product tour does not picture — the other four are there in full, and a walkthrough covers this one live.