Plan: Spring Actuator Honeypot

# Why This is Convincing

The real /actuator/health endpoint already exists and is public (required for ECS health checks). Any attacker or automated scanner targeting a Spring Boot application WILL probe the sibling paths: /actuator/env, /actuator/heapdump, /actuator/configprops. The existence of the real health endpoint is itself the bait — it signals “Spring Boot app”.

# What It Does

Three fake actuator endpoints serve realistic-looking but entirely synthetic responses. When any of them is accessed:

1. A structured alert email is sent to the organizer (via AWS SES)
2. A CloudWatch audit event is logged at CRITICAL severity
3. The response contains a secondary trap — a fake HATEOAS link that, if followed, fires a second alert

No real data is ever exposed. All response content is fabricated.

# Endpoint Design

# Primary traps

# Fake /actuator/env response (primary trap)

{
  "activeProfiles": ["prod"],
  "propertySources": [
    {
      "name": "systemEnvironment",
      "properties": {
        "SPRING_DATASOURCE_URL":      {"value": "jdbc:postgresql://rds-batbern-prod.eu-central-1.rds.amazonaws.com:5432/batbern"},
        "SPRING_DATASOURCE_PASSWORD": {"value": "******"},
        "JWT_SIGNING_SECRET":         {"value": "******"},
        "COGNITO_CLIENT_SECRET":      {"value": "******"},
        "AWS_REGION":                 {"value": "eu-central-1"},
        "_export": {"href": "/actuator/export?token=${COMPAT_ACTUATOR_EXPORT_TOKEN}"}
      }
    }
  ]
}

The _export.href field is natural-looking (Spring HATEOAS-style link). If the attacker follows it:

# Secondary trap

GET /actuator/export?token=<token> → fires second alert, returns fake CSV log dump.

# Files to Create

New package: api-gateway/src/main/java/ch/batbern/gateway/compat/

Test files:

# Files to Modify

# OPSEC: Hiding from GitHub Readers

All sensitive configuration is injected at deploy-time via AWS Parameter Store — never committed:

# application.yml — committed to repo (all disabled by default)
compat:
  actuator:
    enabled: ${COMPAT_ACTUATOR_ENABLED:false}
    alert-email: ${COMPAT_ACTUATOR_ALERT_EMAIL:}
    export-token: ${COMPAT_ACTUATOR_EXPORT_TOKEN:}

In production, set these in ECS task environment variables (sourced from Parameter Store). An attacker reading the repo sees that a mechanism exists — but not which paths are active or what the token is.

Class naming is deliberately innocuous:

• Class: LegacyActuatorCompatibilityController (not HoneypotController)
• Package: ch.batbern.gateway.compat (not honeypot)
• Alert service: CompatibilityAlertService
• Log tag: COMPAT_PROBE (not HONEYPOT_TRIGGERED)

# Known Implementation Challenge

EmailService lives in ch.batbern.shared.service — outside the api-gateway’s default component scan (ch.batbern.gateway). Solution:

• Add scanBasePackages = {"ch.batbern.gateway", "ch.batbern.shared.service"} to ApiGatewayApplication
• Use ObjectProvider<EmailService> in CompatibilityAlertService for graceful fallback (logs alert if email service unavailable in context)

# Alert Email Content

Subject: [BATbern Security] Compatibility probe detected: /actuator/env

Body includes:

• Timestamp (UTC)
• Endpoint probed
• Client IP (X-Forwarded-For chain → RemoteAddr fallback)
• User-Agent (sanitized, max 512 chars)
• Whether Authorization header was present
• Whether secondary trap token was used (second trigger)
• Reassurance footer: “No real data was exposed.”

# Verification Steps (when implementing)

# Hit primary trap (no auth required — the fake vulnerability)
curl -v http://localhost:8000/actuator/env
# → 200, fake JSON, check alert fired in log

# Hit secondary trap (follow the embedded link)
curl -v "http://localhost:8000/actuator/export?token=<configured-token>"
# → 200, fake CSV, check second alert in log

# Confirm real actuator still works
curl http://localhost:8000/actuator/health
# → {"status":"UP"}

# Check alert email captured in local dev
grep -i "COMPAT_PROBE" /tmp/batbern-1-api-gateway.log