Post-exploitation¶

The first callback is the infrastructure paying off. The beacon traverses the redirector, the frontend, and whatever bounce chain sits between, and a session appears in the C2 operator console. Everything built in the preceding sections collapses to this moment: the payload executed, the chain held, and a foothold exists inside the target environment.

The session and the chain¶

The session is live as long as the beacon can reach its callback address. The redirector is now the single point of failure for that connection. If the redirector’s IP is blocked or the domain is sinkholed, the beacon goes quiet. The protocol rotator handles this by falling back to a secondary transport; without one, the redirector needs to be rotated before the beacon’s retry window closes.

Keep the redirector rotation window shorter than the beacon’s sleep interval. A beacon sleeping 60 minutes gives the operator an hour to spin up a new redirector and update DNS before the beacon notices. A beacon sleeping 30 seconds is unforgiving.

Initial enumeration¶

The first actions inside the session establish context: who the implant is running as, what the host is, and where it sits in the network. Standard checks in Sliver:

sliver (session) > getuid
sliver (session) > sysinfo
sliver (session) > ifconfig
sliver (session) > netstat

This information determines whether the foothold is worth persisting and what the next objective looks like. A low-privilege session on a hardened endpoint in a segmented VLAN is a different starting point from a SYSTEM session on a domain-joined server with routable access.

Persistence¶

Persistence keeps the session alive across reboots and avoids having to re-deliver the payload. The mechanism is host-specific; common options include scheduled tasks, registry run keys, and service installation on Windows, and systemd units or cron on Linux. Each leaves artefacts detectable by an endpoint product or a forensic examiner, so the persistence mechanism is part of the engagement scope discussion, not a default.

Infrastructure decisions¶

Post-exploitation generates more traffic than the initial beacon. Lateral movement, file transfers, and interactive use all increase the volume and pattern of the C2 channel. A redirector provisioned for a slow beacon may need updating or replacing as the operation intensifies.

If the foothold host is long-lived, consider whether the redirector it connects to is short-lived by design. An implant that survives several redirector rotations accumulates session history in the C2’s database; that database is on the backend host, which is also the host that matters most to protect. Back up session data to the encrypted volume on the bouncer before tearing down a backend.

Cleanup¶

At the end of the operation, remove persistence mechanisms before tearing down the infrastructure. An implant that beacons to a defunct redirector after the engagement closes may generate alerts days later, which is an avoidable handover problem. Close sessions from the C2 side, remove scheduled tasks and registry keys, and confirm the implant process has exited before destroying the backend.

Infrastructure teardown order: redirectors first (stops inbound traffic), frontend next, backend last (after confirming no sessions are live). The ephemeral automation handles the timing if the TTL is set appropriately.