Configuring Honeypot Tripwires

Introduction

Honeypot tripwires are bait files (or, on ECS, bait objects) placed in the file system that have no legitimate business purpose. Any interaction with them is treated as a strong ransomware signal — the Honeypot detector needs only a single signal to raise a security event, so placing tripwires in sensitive locations gives you faster detection times than behavior-only detectors, including for slow-attack variants that don't otherwise produce a recognizable IO pattern.

See Threat Detection and Severity Settings — Honeypot detector for how the Honeypot Activity detector fits into the overall detector set.

PowerScale — SMB share configuration

Place honeypot files at the base of every SMB share you want to protect, and in at least one subfolder, using this naming pattern:

• igls-honeypot-1
• igls-honeypot-2
• igls-honeypot-3

Base-of-share placement:

1. Mount the target SMB share to a drive letter (for example, Z:).
2. From a command prompt, navigate to the mount point.
3. Create the three files listed above directly at the share root.

Subfolder placement:

1. Mount the target SMB share to a drive letter.
2. Create a folder named igls-honeypot inside the share.
3. Create the same three files inside that subfolder.

Best practice

Always create honeypot files at both the base of the share and in at least one subfolder. A minimum of three files at the base of each share is required to reliably trip the detector.

Changing the honeypot file name pattern

By default, the detector matches the file pattern igls-honeypot-*. To use a different pattern:

1. On ECA node 1, edit /opt/superna/eca/docker-compose.overrides.yml and add the following, preserving the indentation exactly (2 spaces per level):

   version: '2.4'
   services:
     fastanalysis:
       environment:
         - ECA_RWD_HONEYPOT_DIR_PATTERN

2. Edit /opt/superna/eca/eca-env-common.conf and add the pattern to match — any file containing this string trips the detector:

   export ECA_RWD_HONEYPOT_DIR_PATTERN="file.docx"

3. Create honeypot files using the new pattern (for example, 1-file.docx, 2-file.docx) at the base of a share and in a subfolder, following the placement steps above.

4. Cycle the ECA cluster for the change to take effect:

   ecactl cluster down
   ecactl cluster up

ECS — object honeypot configuration

1. Before creating honeypot objects, temporarily disable the Honeypot detector to avoid a false-positive detection during setup: open Ransomware Defender → Settings → Threshold, select the Advanced radio button, and set THREAT_DETECTOR_11 to Disable. Click Submit.
2. Using an S3 browser tool (for example, Cyberduck), connect to the ECS S3 bucket and create three honeypot objects directly under the bucket root, using the same naming convention: igls-honeypot-1, igls-honeypot-2, igls-honeypot-3.
3. Repeat for every bucket you want to protect with a honeypot tripwire.
4. Re-enable the detector: return to Ransomware Defender → Settings → Threshold → Advanced and set THREAT_DETECTOR_11 back to Enable. Click Submit.

To test the ECS object honeypot: download the three honeypot objects to a local machine using your S3 browser tool, then verify a ransomware event appears in Active Events. Deleting the honeypot objects should likewise generate an event.

The Honeypot detector needs only one signal to raise a security event on ECS, the same as on PowerScale:

• In Enforcement mode (Critical mode off), one signal places the event at Major — Delayed Lockout.
• In Critical mode, one signal places the event directly at Critical for immediate lockout.

See also

• Threat Detection and Severity Settings — Detector types, Signal Strength, severity levels, and enforcement modes.
• Detection Controls and False Positive Management — Tuning detection and managing false positives.
• Health Check — Security Guard — Automated simulated attacks, distinct from honeypot tripwires.