A regional bank's SOC watched BeyondTrust Remote Support and FortiGate VPN probes climb for three nights after Unit 42 published its September 2026 initial-access summary. Live appliances showed connection attempts and little else. The team stood up low-interaction listeners that spoke enough of the same protocols to record banners, verbs, User-Agents, and retry timing. Within forty-eight hours those decoys produced reusable campaign fingerprints that perimeter logs alone never exposed.
That pattern sits at the center of honeypot work for threat intelligence. You place controlled targets where scanners and operators already expect edge services, then turn interaction detail into hunts, blocks, and upstream packages while CVE and implant advisories are still catching up.
Why edge-shaped decoys matter right now
September 2026 kept pushing attention toward appliance and remote-access surfaces. Unit 42's PEERSTITCH reporting showed how a stealth FortiGate implant can hide in legitimate management traffic. The BeyondTrust remote-support zero-day continued the run of exploited edge bugs. Unit 42's top initial-access vectors for the month clustered around the same family of entry points: VPN portals, remote support, and exposed management listeners.
Mass internet scanners still dominate raw volume. Targeted operators reuse scanner tooling, then deepen only on hosts that answer like real products. A honeypot that returns plausible FortiGate, ScreenConnect-style, or generic HTTPS admin responses captures that second stage. Your TI queue needs that depth more than another undifferentiated deny-list hit.
Place decoys where scanners already expect answers
Start with a short inventory of protocols your production edge already exposes: HTTPS admin and VPN, RDP if you still allow it from the internet, SSH on jump hosts, and any remote-support product you run. Clone the ports and TLS fingerprints on isolated addresses that never hold real credentials or production routes.
Keep interaction shallow enough that you stay safe, deep enough that tools continue. Practical baseline:
- TLS certificates that look aged and organizational, with SANs matching decoy hostnames
- Login pages or banners that mirror vendor strings without shipping real auth backends
- HTTP status and redirect chains that match your live portal quirks
- Session cookies issued on failed logins so credential-stuffing kits keep talking
Segment decoys on a dedicated VLAN or cloud project with default-deny egress. Allow only the outbound paths you need for telemetry shipping. Log full request lines, TLS JA3/JA4-style fingerprints where your stack supports them, source ASN, and precise timestamps.
Detection steps that turn captures into intelligence
1. Score sources by interaction depth, not hit count
Tag every source IP with a stage: banner grab, credential attempt, exploit payload, and post-auth command probe. Promote sources that climb stages within a short window into a high-priority queue. Volume-only ranking buries the PEERSTITCH-style operators who probe carefully after public edge advisories.
2. Join decoy hits to live edge telemetry within one hour
When a honeypot records a distinctive User-Agent, URI path, or SSL handshake family, search the same window on real VPN, remote-support, and firewall logs. Matching ASN plus timing plus fingerprint is stronger than IP alone, especially behind residential proxies and shared cloud ranges.
3. Build peer sets from retry cadence
Group sources that share payload templates and retry intervals even when IPs rotate. Those peer graphs become overnight hunt seeds: same TLS fingerprint on a different /24, same POST body against a different decoy hostname. Your hunt board should list peer sets beside individual indicators.
4. Map captures to current advisory themes
Label sessions against the week's edge story. A FortiGate-shaped decoy that receives implant-style beacon probes belongs next to PEERSTITCH hunts. Remote-support console probes belong next to BeyondTrust and similar remote-admin waves. That labeling keeps TI packages useful for defenders who already have thin breach notices and need campaign context.
Concrete capture examples worth keeping
Record and retain these fields for every meaningful session:
- Exact request URI and method sequences over the first five minutes
- Password spray dictionaries versus unique high-entropy secrets
- Exploit strings that reference specific CVE paths or product build IDs
- Callback destinations requested after a fake successful login
- DNS and certificate lookups the attacker triggers against your decoy hostname
Example workflow: overnight, three ASNs hit your decoy VPN portal with the same multipart login body and a fixed three-second retry. Morning join shows two of those ASNs also touched your real FortiGate VIP with incomplete handshakes. You raise a peer-set indicator, add temporary ASN-aware monitoring on auth ingress, and push the multipart body hash to your ISAC with TLP:AMBER and a one-paragraph context note.
Response actions after the decoy speaks
Move from capture to control with a fixed order so exploit weeks stay coherent.
- Contain the decoy side. Confirm egress still blocks real callbacks. Snapshot packet captures for the high-stage sessions before rotation wipes them.
- Hunt the live estate. Replay peer sets against VPN, remote support, mail gateway, and identity logs. Look for successful auth near the same timestamps, new local accounts, and unexpected outbound peers from management planes.
- Tune perimeter carefully. Prefer short-lived controls keyed to fingerprint and ASN peer sets over permanent per-IP denies when the source sits in shared cloud space. Retire those controls when the peer graph goes quiet for your agreed window.
- Publish partial packages early. Ship URI sequences, JA3/JA4 hashes, and staging notes upstream while attribution remains open. Waiting for perfect actor naming ages the signal past the exploit wave.
- Feed detections back into decoy design. If live appliances see a new verb or path that decoys missed, add that response surface in the next change window.
Operational checklist for IT admins
Treat honeypots as instrumentation, not trophies. Owners, retention, and promotion rules matter as much as the software.
- Assign an owner for each decoy and each indicator class it produces
- Keep interaction logs for at least thirty days in an immutable store
- Require a live-log join before autodropping a honeypot IP from shared cloud ASNs
- Time-box every temporary allow created while you analyze a decoy hit
- Review decoy TLS and banner fidelity whenever you patch the real edge products
Pair this program with your broader September-style posture work: inventory remote-support exposure, verify FortiGate and VPN patch state after implant advisories, and keep identity telemetry close enough to edge logs that a decoy hit can pivot into account review in the same shift window your runbooks already define.
Takeaways you can apply this week
Stand up at least one decoy that mirrors your highest-risk edge protocol. Score sessions by depth. Join those hits to live appliance logs within an hour. Promote peer sets and request fingerprints into hunts before you mass-block shared hosting ranges. Publish partial campaign notes while signatures and vendor write-ups are still catching the wave.
Honeypots earn their keep when they convert the same scanners that fluff your deny lists into structured initial-access intelligence your SOC can act on while edge bugs and implants are still dominating the news cycle.
