The Cybersift-Admin-Passwords.txt Honeypot: Turning Deception Into Detection
Detection Through Deception: Building a High-Fidelity Honeyfile with Windows Security Events
Security Operations Centres are constantly balancing a difficult trade-off: maximising threat visibility while suppressing alert noise. This is made even harder by modern attacker behaviour, as threat actors rarely rely on noisy malware binaries during initial access or lateral movement. Instead, they "live off the land" by browsing network shares, hunting for plain-text credentials, and leveraging native administrative tools.
When attacker behaviour mirrors everyday corporate workflows, traditional signature-based detections reach their limits. To solve this, we at CyberSift decided to build a deception mechanism. But we didn't want to rely on the traditional, fragile method of embedding tracking scripts inside documents. Instead, we turned to native detection engineering.
Here is how we built a high-fidelity honeyfile detection using native Windows security event codes, and how you can replicate it in your own environment.
What is a Honeyfile?
The concept of using deception to trap adversaries is not new. A honeyfile (or decoy file) is a strategic digital trap planted exactly where a threat actor performing internal discovery is bound to look. By naming a decoy asset something enticing like Admin-Passwords.txt or Production_DB_Keys.xlsx and placing it on a sensitive share, defenders create a high-value target.
Because these files serve zero legitimate business function, there is no reason for an employee or automated process to open them. Therefore, any interaction with a honeyfile represents an immediate, high-confidence security signal that turns silent lateral movement into a blaring alarm.
The Problem with Traditional Honeyfiles
Historically, creating a honeyfile meant embedding a macro, a hidden script, or a tracking pixel (a "web bug") inside a Word document or PDF. When the attacker opened the file, the script would execute and send a beacon back to the security team.
This approach has major flaws:
It’s Fragile: Modern Endpoint Detection and Response (EDR) and Antivirus tools routinely block documents with embedded macros or hidden scripts, meaning your own security stack might quarantine your decoy.
Limited File Types: You cannot embed a beaconing script into a standard .txt or .csv file, severely limiting the types of decoys you can create.
Requires Outbound Access: If the attacker opens the file on an isolated or air-gapped machine, the beacon will fail to reach the security team.
To bypass these limitations, we engineered a honeyfile mechanism that relies entirely on native Windows OS auditing rather than embedded code.
Writing the Detection Rule
Now, Windows will generate an Event ID 4663 whenever anyone reads that file. However, modern OS environments are inherently noisy. Background utilities such as the native Windows Search indexer will routinely scan local drives and trigger false positives.
To ensure this remains a true high-fidelity alert, we must filter out routine system processes. We wrote a JMESPath detection rule that isolates true human/attacker intent by ensuring four conditions are met:
The event matches the exact target host.
The event code is 4663 (Object Access).
The specific object accessed is our configured decoy file.
The access type includes ReadData, and the accessing process is not a background indexer like SearchProtocolHost.exe.
CyberSift JMESPath Rule Logic:
Available on rules.cybersift.io
Investigating a Honeyfile Alert
When an alert triggers, standard Windows event telemetry provides immediate, actionable forensic context:
Confirm the Identity: Inspect agent.hostname and winlog.event_data.ObjectName to confirm which decoy asset was touched.
Identify the Actor: Extract winlog.event_data.SubjectUserName and the associated Security Identifier (SID) to pinpoint the account involved.
Process Lineage: Cross-reference process creation logs (Event ID 4688) around the same timestamp to extract winlog.event_data.ProcessName, the Process ID, and parent process execution paths.
Because honeyfiles carry zero business utility, an unapproved read operation serves as a strong indicator of compromise which allows SOC analysts to immediately isolate the host, revoke active user tokens, and halt potential lateral movement or data exfiltration.
Automating Deployment with CyberSift
CyberSift provides a Generate Honey Pot builder directly within the Rule Catalog:
Go to rules.cybersift.io and select Generate Honey Pot.
Enter your decoy file name and target host.
Click Generate rule to generate your JMESPath rule.
Key Takeaways
Native OS auditing eliminates the need for fragile document macros or tracking pixels.
Filtering background system processes ensures honeyfile alerts remain zero-noise tripwires.
Decoy files allow SOC teams to catch unauthorized internal discovery before lateral movement progresses.
-Written by: Francesca Nardelli
