Agent Setup Wizard

3-Step Installation Flow

The Agent Setup page provides a guided installation wizard. You must be signed in and belong to at least one organization.

Step 1: Create a Registration Token & Download Installer

Organization admins can create scoped, revocable registration tokens
Click + New Token, give it a name, optional max-agent limit, and expiry
Click Download next to the token to get a pre-configured installer — a single .exe with your token embedded
Optionally check Allow Public Download Link during creation to generate a shareable URL that anyone can use to download the installer without signing in — ideal for sending to end users or embedding in deployment scripts
Check Sign for Production Use to EV code-sign the installer with the ET Ducky certificate. Signed installers show the verified publisher name (“ET Ducky LLC”) in the Windows UAC prompt and are trusted by SmartScreen. Each organization can have up to 4 signed production tokens at a time.
You can re-download at any time for any active token. The token itself is shown once at creation for manual/scripted use
If you belong to multiple organizations, a dropdown lets you select which org to deploy into

Security: Tokens are scoped to a single organization and can be revoked at any time. Use separate tokens for different environments.

Step 2: Run the Installer

Double-click the downloaded .exe on the target Windows machine. The installer runs silently — it will install the .NET 9.0 runtime if needed, register the agent with your organization using the embedded token, and start the ET Ducky Agent service. No command-line arguments or manual token entry required.

Step 3: Verify

sc query ETDuckyAgent

The agent should appear on your Agents page within seconds.

Manual Install (Advanced)

For scripted or bulk deployments, download the standalone installer from the Agent Setup page and provide the token on the command line:

.\ETDuckyAgentSetup.exe /SILENT /REG_TOKEN="etd_your_token_here"

This approach is recommended for MECM/SCCM, Intune, GPO, or PowerShell remoting deployments.

Bulk Deployment

For deploying to multiple machines, use the standalone installer with the /SILENT /REG_TOKEN flags. Download ETDuckyAgentSetup.exe from the Advanced section of the Agent Setup page, or directly from etducky.com/downloads.

Public Download Link (Simplest)

Enable Allow Public Download Link when creating a token to get a shareable URL. No sign-in required — send the link to end users or use it in scripts. The dashboard generates a ready-to-go CMD one-liner:

cmd /c "mkdir C:\Temp 2>NUL & curl.exe -L "https://etducky.com/api/agent-tokens/{id}/installer/public" -o C:\Temp\ETDucky_Setup.exe & C:\Temp\ETDucky_Setup.exe /VERYSILENT /NORESTART"

The public link respects all token controls: it stops working if the token is revoked, expired, or has reached its agent limit.

PowerShell Remoting with Active Directory

$computers = Get-ADComputer -Filter * -SearchBase "OU=Servers,DC=corp,DC=local" | Select -ExpandProperty Name
$token = "etd_your_token_here"

foreach ($computer in $computers) {
    Invoke-Command -ComputerName $computer -ScriptBlock {
        param($t)
        Start-Process "C:\Temp\ETDuckyAgentSetup.exe" -ArgumentList "/SILENT /REG_TOKEN=`"$t`"" -Wait
    } -ArgumentList $token
}

Enterprise Deployment Tools

The silent installer works with any deployment tool that supports command-line execution:

MECM / SCCM: Create an Application or Package with the silent install command. Use a Device Collection to target machines. The /SILENT flag ensures no user interaction is required.
Intune: Upload the installer as a Win32 app (.intunewin). Use the silent install command as the install command string. Set detection rules based on the ETDuckyAgent service or install directory.
Group Policy (GPO): Deploy via a Startup Script targeting computer accounts. Place the installer on a network share accessible by machine accounts.

Tip: Create a dedicated registration token with a high max-agent limit for bulk deployments. Use separate tokens per deployment wave for tracking and revocation control.

Linux: enabling journald & auditd capture

The Linux agent installs with eBPF capture only by default. To turn on the additional capture sources (Linux.Journald, Linux.Auditd) for richer Inflection RCA prompts, edit /etc/etducky/agent/AgentConfig.json after install and set:

{
  "EnableJournaldCapture": true,
  "JournaldMinPriority": 4,
  "EnableAuditdCapture": true
}

Then restart the agent: systemctl restart etducky-agent. Auditd capture also needs AmbientCapabilities=CAP_AUDIT_READ in the systemd unit, which the .deb and .rpm packages set automatically. See Remote Configuration for the full flag reference and tuning guidance.

Linux: upgrading the agent

Automatic self-update is not yet available on Linux. The Windows agent updates itself when the cloud advertises a new build; the Linux equivalent is on the roadmap (it requires a signed package repository). Until then, Linux agents are upgraded manually using the steps below — an agent simply stays on its installed version until you upgrade it.

Download the new package for the target version from your ET Ducky downloads location, then install it over the existing one. The package's post-install step restarts the service automatically.

Debian / Ubuntu (.deb):

sudo DEBIAN_FRONTEND=noninteractive apt-get install -y --reinstall ./etducky-agent_<version>_amd64.deb

RHEL / Rocky / Fedora (.rpm):

sudo dnf install -y ./etducky-agent-<version>-1.x86_64.rpm

Universal installer (.run): re-run the new .run file with sudo ./etducky-agent-<version>.run.

Your configuration is preserved across the upgrade. /etc/etducky/agent/AgentConfig.json is deliberately not a dpkg conffile and is never shipped inside the package, so an upgrade leaves it untouched — the agent keeps its identity, bearer token, and all settings.

Do not re-run install.sh to upgrade. The install one-liner redeems an enrollment token and mints a new agent identity, so re-running it would register the host as a second, separate agent. Use install.sh only for first-time enrollment; use the package commands above to upgrade an already-enrolled host.

Verify the upgrade:

systemctl status etducky-agent
journalctl -u etducky-agent -n 20 --no-pager | grep -i version

The host's reported agent version also refreshes in the dashboard within one heartbeat (about a minute).

Linux: sudoers configuration for self-update and isolation

The Linux agent runs as the unprivileged etducky system user. Two features need narrowly-scoped NOPASSWD sudo entries to function: self-update (package-manager hooks reserved for the forthcoming Linux auto-update path — see Linux: upgrading the agent above for the current manual procedure) and network isolation (the agent calling nft/iptables to apply quarantine firewall rules on a high-confidence ransomware detection). Without these entries, both features fail safely — the agent logs a clear "sudo required" warning and falls back to manual operator action — but the features will not work end-to-end.

The .deb and .rpm packages ship a sudoers drop-in at /etc/sudoers.d/etducky-rmm with all required entries. Package upgrades replace this file with the current canonical version, so an agent that successfully upgrades automatically picks up new entries. If you've upgraded from a pre-M37 agent (which had a narrower sudoers file without the apt-get or nft entries) or installed from the .run universal installer (which does not write to /etc/sudoers.d/), you may need to apply the file manually once — after that, the auto-update path keeps it in sync.

How to know if your host is missing entries: the agent runs a sudoers self-test at startup and every 30 minutes. If anything is missing it logs ERROR-level lines to journald with the stable prefix ETDucky sudoers self-test FAILED:. Grep for it:

sudo journalctl -u etducky-agent --since '1 hour ago' | grep -E 'sudoers self-test|Self-update is broken|isolation is broken'

If the self-test passes you'll see Sudoers self-test OK (N NOPASSWD entries cover self-update, isolation, and approval prompt) instead.

Verify it's in place:

sudo cat /etc/sudoers.d/etducky-rmm

If the file is missing or you see only the read-only diagnostic entries (no apt-get, no nft), create or replace it with the following content. The file must be owned root:root with mode 0440; visudo -c validates the syntax before any commit.

# /etc/sudoers.d/etducky-rmm
# Required for ET Ducky Linux agent self-update + network isolation.

# Read-only diagnostics (existing — required by health-metrics collectors)
etducky ALL=(root) NOPASSWD: /usr/sbin/smartctl, /sbin/smartctl
etducky ALL=(root) NOPASSWD: /usr/sbin/dmidecode, /sbin/dmidecode
etducky ALL=(root) NOPASSWD: /usr/bin/lshw, /usr/sbin/lshw
etducky ALL=(root) NOPASSWD: /usr/sbin/lspci, /sbin/lspci
etducky ALL=(root) NOPASSWD: /usr/sbin/lsusb, /usr/bin/lsusb
etducky ALL=(root) NOPASSWD: /usr/bin/journalctl, /bin/journalctl
etducky ALL=(root) NOPASSWD: /usr/sbin/dmesg, /bin/dmesg

# Self-management — restart the agent service after an in-place upgrade
etducky ALL=(root) NOPASSWD: /usr/bin/systemctl restart etducky-agent
etducky ALL=(root) NOPASSWD: /bin/systemctl restart etducky-agent
etducky ALL=(root) NOPASSWD: /usr/bin/systemctl restart etducky-agent.service
etducky ALL=(root) NOPASSWD: /bin/systemctl restart etducky-agent.service

# Self-update via package manager (LinuxAgentUpdateService)
etducky ALL=(root) NOPASSWD: /usr/bin/apt-get install --only-upgrade -y etducky-agent
etducky ALL=(root) NOPASSWD: /usr/bin/dnf install -y etducky-agent
etducky ALL=(root) NOPASSWD: /usr/bin/zypper install -y etducky-agent

# Network isolation — nftables path
etducky ALL=(root) NOPASSWD: /usr/sbin/nft -f /tmp/etducky-isolation-*.nft
etducky ALL=(root) NOPASSWD: /usr/sbin/nft delete table inet etducky_isolation
etducky ALL=(root) NOPASSWD: /usr/sbin/nft list table inet etducky_isolation

# Network isolation — iptables fallback path (only used if nft missing)
etducky ALL=(root) NOPASSWD: /usr/sbin/iptables
etducky ALL=(root) NOPASSWD: /sbin/iptables

# On-device approval prompt (zenity/kdialog/xmessage) — needed for the
# unisolate flow's dual-party consent. Required on graphical Linux hosts;
# unused on headless servers (which fall through to the offline lift code).
# Runs the prompt as the console user; (ALL, !root) ensures it can never
# run as root, and the command is pinned to env + a GUI dialog binary.
etducky ALL=(ALL, !root) NOPASSWD: /usr/bin/env * /usr/bin/zenity *, \
                                   /usr/bin/env * /usr/bin/kdialog *, \
                                   /usr/bin/env * /usr/bin/xmessage *

Save as /etc/sudoers.d/etducky-rmm with chmod 0440, chown root:root, then validate:

sudo visudo -c -f /etc/sudoers.d/etducky-rmm

If validation fails, do not save the file — a malformed entry in /etc/sudoers.d/ blocks all sudo on the host until repaired. Use visudo -f /etc/sudoers.d/etducky-rmm to edit safely if you want to make changes.

Linux: network isolation prerequisites

Beyond the sudoers entries above, network isolation needs two host-level prerequisites:

A firewall backend. Either nftables (preferred — present on all modern distros) or iptables (fallback). On a fresh Ubuntu 22.04+/Debian 12+/RHEL 9+/Fedora 36+ host, nftables is the default and no action is needed. Verify with which nft. If absent, install with sudo apt install nftables or sudo dnf install nftables.
For workstations with a logged-in user: a GUI prompt tool (zenity, kdialog, or xmessage). The on-device approval popup spawned by the unisolate flow uses one of these to display the consent dialog. zenity is preferred (GTK; widely available); on Debian/Ubuntu install with sudo apt install zenity. Most full desktop installs already include it.
For headless servers: no GUI prompt tool needed. The agent detects the absence of an active graphical session and immediately reports a "no interactive user session" rejection back to the cloud. Operators recover via the offline lift code path (see §Headless server lift flow below).

Linux: headless server lift flow

On a Linux server with no graphical user session, the standard remote lift flow (dashboard click → on-device popup → user clicks Approve) cannot complete because there's no logged-in graphical user to consent. Two options:

Offline lift code (preferred). An org admin generates an 8-character lift code in the dashboard's Agent Details modal. A technician with SSH or physical access to the server runs the agent's lift-code command (or POSTs to the local agent listener):
```
# SSH to the isolated server (this works — etducky.com is in the allow list,
# but ALL other inbound is blocked, so this requires either local access or
# an existing SSH session opened before isolation)
ssh user@isolated-server

# Submit the lift code to the local agent listener
curl -X POST http://127.0.0.1:51902/api/isolation/lift-code \
  -H 'Content-Type: application/json' \
  -d '{"code":"XXXXXXXX"}'
```
The code is HMAC-derived from the agent's bearer token, valid within a 10-minute window, single-use. Verified entirely on-device; no internet connectivity required to authenticate.
Delete + reinstall. If the server is unreachable and no lift code is available, delete the agent from the org dashboard (which clears the cloud-side isolation state for that agent) and reinstall the .deb/.rpm on the device after restoring physical access. The reinstall creates a new agent identity; the old one is permanently retired.

Note: The lift code's HTTP listener binds to 127.0.0.1 only — it cannot be reached from outside the host, even if isolation isn't active. This is the same dual-party model as Windows: the dashboard generates the code; the user/technician must be locally present (SSH counts as "locally present" for headless servers) to submit it.