A Trap in the Shadows: Red Team Thoughts on Modern Deception Technologies

Recently I had an engagement baselining a security stack within an organization, one of which was a product I was unfamiliar with, called Shadow. This is Proofpoint's agentless detection platform that came out of their acquisition of Illusive Networks. Coming from my early career days in the SOC and Threat Intelligence, I was familiar with conventional honeypot projects and canary tokens hidden in documents. I can confidently count on one hand the number of clients who used even these methods internally over the last five years of offensive security. Digging in and doing hands-on testing with these more modern offerings led me to rethink how I approach mature environments on adversarial engagements.

What is Deception Technology?

Deception technology platforms are modern-day solutions for cybersecurity teams looking to enhance detection through the use of artifacts designed to entice interaction by attackers while remaining untouched by normal business users. There are several big name players in this space, including top-tier EDR vendors such as Microsoft and CrowdStrike, who employ this type of technology to some degree within their products. The detection portion works by generating fake items such as documents, credentials, and connection files across enterprise assets, each of which can be correlated to user interaction, alerting defenders to potential compromises or suspicious activity. Using Shadow as the example, the general operating model is as follows:

Profiles each endpoint's landscape.
Generates deceptions tailored per machine.
Deploys via a push process, then ages and rotates them over time.
On interaction, pulls real-time forensics from the source host and sends alerts to the centralized dashboard for defenders to act on, or sets up ingestion to other SIEM systems.

Artifacts are designed to look natural on the target host and blend into the environment. They can consist of far more than just file-based items, instead potentially being data in the Windows credential vault or planted data in browsers. This is not limited to hosts either, as cloud-based artifacts are supported by most vendors.

The mechanics are worth stating plainly. Reading most artifacts is safe. Opening a document-type artifact, a PDF or Office file, can fire a callback through an embedded canary token. Authenticating with a discovered credential or connecting to a planted host is the main trigger. You have to operate under the premise of evading defenses to gain initial access. Your mindset now has to include the idea that you may burn yourself by succeeding at harvesting and then using that too-good-to-be-true loot. The question you must now ask: how do you, the red team operator, identify these artifacts and remain under the radar?

Operation Options

If you are lucky, you may have a client that discloses the security stack prior to the engagement. This is common with purple teams, an assumed breach, or more time-gated engagements. If you know they use deception software, then you can go into the engagement with the mentality that everything needs to be approached with caution. As the saying goes, if it looks too good to be true, it probably is. As covered above, reading most artifacts is safe, but treat document types like PDFs and Office files with extra care, since they can carry canary tokens that alert defenders on open. Every option below is built around keeping your actions on the safe side of that line until you have a reason to trust what you found.

Here is how I weigh the choices, roughly in the order I reach for them.

1. Assume deception, validate before use

The default posture in a mature environment is guilty until proven innocent. Every credential from the vault, every saved PuTTY session, every mapped drive is a hypothesis, not a fact. Pay attention to details in metadata and naming schemes. Does the .rdp connection match the naming scheme on the host you are on, or ones you know to be valid? Are there plaintext credentials sitting in a Temp folder that just look enticing? Are there only a few files with similar creation dates, or does this look like a legitimately used drive or folder?

Before any authentication attempt, validate the target host and the principal against Active Directory and DNS in your current context, using LDAP BOFs if possible. The point is to confirm without ever exercising the discovered credential. The default for base deception artifacts is to not add these to AD, as it could cause operational issues or confusion. This, of course, is configurable, so it is not a smoking gun if you do find the host in AD. What are the groups, creation date, and login count? If the host does not resolve and has no computer object, or the account has never logged on yet looks privileged, you have your most likely answer without touching the sensor.

2. Stay passive on the endpoint

Local enumeration of credential stores, RDP history, SSH client sessions, cloud token files, and mapped drives is read activity, which will generally not trigger high or critical alerts, as this would cause more noise than value. The idea is to harvest broadly, then step back and analyze rather than pivoting on the first find that looks too good. The mistake that burned me before was momentum, grabbing an enticing plaintext credential and firing it at Apache or SQL Server in the same breath. Collect first, decide later.

3. Corroborate against the directory, then weight the signals

This is where the endpoint focus and the directory checks connect. Endpoint-planted credentials usually point to identities or hosts with no real backing in the directory, which is why AD and DNS lookups are what separate real from fake. One host that fails to resolve, one account with a zero logon count, both of these show up constantly in production. Deception reveals itself when the flags stack up together. You can generally get away with a ping or single port connection but, be warned that the target deception servers do monitor ports along with hosting fake services like MSSQL, SSH, FTP, and Mongo with the idea of enticing attackers to probe these hosts. Keep it light until you gain further context to validate the remote host.

Examples of signals worth scoring:

The referenced host does not resolve and has no computer object in the directory but is live on the network with various services.
The AD account has no lastLogonTimestamp and a logonCount of zero, yet presents as privileged.
A privileged-sounding name like svc_sql or backup_adm carries no group membership and no SPNs to back it up.
An SPN tied to a service account with a password last set a decade ago, while every other SPN account is on a recent rotation. Allowing RC4 requests is another strong indicator when the rest are restricted to AES.
A saved session points into a subnet with no live machine accounts or documented business sector.
A credential entry references a realm that does not exist.
A credential entry references a user you already hold credentials for, but the password does not match, despite being in the same realm.
A DACL that makes no logical business sense, such as Domain Users holding GenericAll over a single computer account.
A Doc or Excel file with an enticing name sitting on the one public drive or SharePoint site with no other context around it. Take it offline, review the metadata, and ensure no outbound connections before taking the risk.

Weight all the data collected together to paint a picture of suspicious items. Something that lights up on four of them is almost certainly planted. Something with one is probably just a normal artifact in a normal, disorganized network, but it is your call to make. Use your gut instinct and go slow. A properly configured deception setup is not going to hide artifacts so deep that even attackers won't find them. The idea is to plant them somewhere a normal user poking around probably won't interact with, while being just close enough to the surface that an attacker enumerating will.

4. Look for the bulk-plant fingerprint

Deception platforms deploy artifacts in waves and tend to rotate them on a schedule. Real user artifacts accumulate over months and years of organic work. That difference leaves a timestamp signature. When a cluster of credential files or connection profiles shares a creation window down to the minute, that is not how humans generate clutter. Group your findings by creation time and let the outliers surface. This can be a strong tell, since faking it convincingly means either staggering deployment heavily or aging every artifact by hand. AI has greatly enhanced the capability for some vendors to create more realistic artifacts and adapt them in real time, so account for that.

Naming and grouping are the sibling tells. Human-generated artifacts are inconsistent, abbreviated, and occasionally misspelled. Planted sets can often appear too clean and too uniform. A user might put a plaintext password in OneNote along with notes for the project they are working on. A base artifact is going to just plant a credential in a file and move on. More advanced configurations do a better job of disguising the planted data, but it often still looks slightly out of place compared to the live user account. This is where your collection comes into play. If you know how the live user operates and speaks, planted objects will stand out far more than if you go in blind.

Detail the deliverable

The client gains far more from knowing how well their deployment actually performs than from a brag that it was all bypassed. If you are able to bypass artifacts because of unrealistic configuration or because they are obvious outliers, tell your client. Tell them how realistic the planted objects look under directory scrutiny, and whether an operator with a scoring method can separate real from fake in an afternoon. If it was difficult and greatly slowed the operation, then let them know! This is valuable information for clients who spend a great deal of money on these security products. This plays honestly with the fact that these products are well built, but can be lacking if left in default or misconfigured states.

Conclusion

Vendors in this space love to tout an undefeated record against red teams. Sometimes that is earned, but often the operator simply never walked past the trap, or glanced at an account named something like Admin_RC4_Legacy and moved on after finding another path. Both outcomes still strengthen the client's posture, which is the whole point. The evasion problem here is inverted. You do not beat the defense by hiding your tooling, because the defense is not watching your tooling like an EDR agent. It is waiting for you to take the bait. The only durable answer is to not take it.

Till next time, farewell and happy hacking!