First steps: Agents in Control Pack

Provide the Control Pack server’s IPv4 address and port. This is where the agent will call back. You can customise these values to fit your environment, but we recommend starting with the defaults to validate connectivity quickly. Each agent also exposes a few runtime options; for example, the Java agent lets you choose the agent type. Review the per-agent options in the wizard and select what best matches your target and execution context.

When you finish, the wizard produces a ZIP bundle. Inside, you’ll find the precompiled binary you selected and a config.ep file containing the settings you chose during this step. Use that configuration as-is for a quick start, or edit it to refine endpoints, timing, or behavior.

For reference, the non-precompiled source is available from within the wizard so you can review capabilities and understand how the agent operates before deployment.

After generating the bundle, test it in a controlled environment first. Verify the agent can reach your Control Pack server, confirm Stage-1 check-in, and, if required, upgrade to Stage-2 to validate extended commands.

Keep the agent and config.ep under version control so you can track changes per campaign. If connectivity fails, double-check the IPv4/port, firewall rules, proxy settings, and (for runtime-specific agents) that required runtimes are present on the target.

When Control Pack receives a new agent connection, you’ll hear an audible alert, and the session will appear under Remote Shells. Each session is assigned a unique ID so you can track it at a glance and use autoexec to queue commands for all new agents or target a specific one, handy for repeatable workflows and APT-style simulations.

Each agent exposes a command set suited to its runtime. In most cases, you can open an interactive shell, capture a screenshot, upload and download files, and run a built-in host information routine. From the Remote Terminal, you can type help to list the agent’s commands, or invoke them directly. The screen on your upper right shows the commands available for each Agent and for each Stage.

Privilege-escalation checks are available for lab use. Run them only when you’re confident they’re appropriate for the environment, since security controls may flag or block those behaviors during exercises. Review results carefully and document any findings in your campaign notes.

Across agents, typical capabilities include remote shell interaction, file transfer, host and user enumeration, display capture, and optional input/telemetry collection depending on the build.

Control Pack supports multiple operating systems and runtimes, Java, .NET (Windows), native DLL injection (Windows), browser-context agents, Python, and others so you can match the agent to your target stack and testing goals.

As you operate, use session ID tags and notes to keep context, then stage your workflow: verify connectivity, run lightweight discovery, and only enable Stage-2 when you need extended commands. Queue common tasks with autoexec (for example, capture system info, list processes, and pull a targeted file), and monitor results live in the Remote Terminal while artifacts are saved to the campaign log. When working across multiple hosts, group sessions by tag, filter by platform/runtime, and fan out a small command set to selected agents to keep actions consistent. Tune transport settings per campaign endpoint path, interval, jitter, and retry policy to fit the network you’re testing, and confirm that any required runtimes (JVM, .NET/CLR, PowerShell) are present before you escalate features.

For investigations, capture screenshots or short runs of host telemetry, then export transcripts and artifacts for reporting. When you’re done with a session, cleanly shut it down from the toolbar or issue the agent’s removal command to tidy the environment.