Respond to a Suspected Rust Server Compromise

If you suspect your Rust server was compromised, contain access first, preserve what may explain the activity, and rebuild only after you have a trustworthy recovery path. A strange structure, missing items, an unexpected admin or an unfamiliar file is a lead to investigate, not proof by itself. This PC Rust runbook helps you make a careful response without confusing a clean server start with a clean incident. Allow about 45 minutes to organize the first response; investigation and restoration can take longer. It does not replace your host’s incident process or a qualified responder when accounts or personal data may be exposed.

Treat an alert as a lead, not proof#

Write down what you saw before changing the server: the time and time zone, the affected server identity, who reported it, and the exact behavior or file that raised concern. Capture an error or screenshot without exposing passwords, recovery codes, player IPs or unrelated personal information. Keep the original file or report unchanged and make a separate working copy if you need to annotate it.

Compare the observation with recent legitimate changes. A new plugin, administrator, config edit, scheduled wipe or server update can explain unexpected behavior. Ask a second trusted operator to check the same evidence independently. Preserve disagreements in the record; do not turn “we cannot explain this yet” into “the server was hacked.”

Use a small incident record so later actions can be reconstructed:

Incident reference:
Server identity and build, if known:
Observed at (time and timezone):
Reported by and original evidence location:
What was directly observed:
What is still an inference:
Containment action and time:
Accounts and secrets reviewed:
Recovery source and acceptance checks:
Reopening decision and reviewer:

Limit this record to people who need it. If the report points to a compromised hosting account, payment method or personal data, contact your host and follow the relevant account or breach-response process. The Rust server administration guide explains why player reports and normal console output are not a complete audit trail of every privileged action.

Contain the server without destroying evidence#

If active access or damage may be continuing, use the hosting panel or provider support to stop or isolate the affected server. If you self-host, restrict its public network access at the firewall or network layer. Keep a separate trusted way to contact the host and your other operators. CISA’s general incident guidance recommends isolating affected systems and preserving evidence with short retention; it does not prescribe a Rust-specific forensic method.

Before reinstalling, deleting plugins or restoring an old world, ask your host how to preserve the current server files, console output, access logs and relevant panel events. Keep any snapshot or archive private and read-only where your tools allow. Record who collected it, when, and where it is stored. If you cannot safely collect evidence yourself, stop and ask the provider or an incident responder to guide the collection.

These are investigation leads, not a substitute for a forensic image. Do not post archives, config files or logs publicly: they may contain credentials, player identifiers or infrastructure details.

Map and revoke the suspected access#

Treat the server, host account and connected tools as separate access surfaces. Facepunch documents Rust’s server identity, users.cfg, startup arguments and RCON; your hosting provider controls a different account and different recovery features. A changed in-game role does not secure a compromised panel login, and replacing the world does not invalidate a stolen RCON secret.

From a separate trusted device, review the account that controls hosting first if that account may be involved. Follow your provider’s process to revoke unfamiliar sessions or users and rotate its password and recovery methods. Then inventory the surfaces that apply to your setup:

• Hosting panel users, recovery email, API keys and active sessions.
• Operating-system or file-transfer accounts if you self-host or use them.
• Rust owner and moderator records in users.cfg and any administrative plugins.
• RCON password, clients, saved browser profiles and automation that use it.
• Steam account or shared account that can change server files or startup.

Revoke unknown access and rotate each affected shared secret using that system’s supported procedure. Do not reuse the same new password across accounts. Update approved clients and automation only after the owner has regained control, then verify the new access works and the suspected old path no longer does. If a panel offers no session review, audit history or independent recovery account, ask support what they can revoke and document what remains unknown.

Rebuild server software from a trusted source#

Once evidence is preserved and the likely entry path is contained, rebuild the server runtime from an official or otherwise trusted source. Do not copy an unknown executable, startup script or plugin back into the replacement simply because it was present in the old folder. Record the Rust build, framework and extensions you deliberately reinstall; check each plugin against its maintainer’s current source and remove anything you cannot identify.

Keep the affected files separate from the clean installation. Compare them with a known-good backup or package where possible, and ask a qualified responder to review suspicious binaries or scripts instead of opening or executing them. If the same host account or operating system remains suspect, recreating only the Rust server directory may leave the access path intact. Have your provider confirm what was isolated or rebuilt at its layer.

The Facepunch dedicated-server instructions document the normal installation and configuration surfaces. Use the current procedure for your operating system and build; an old tutorial’s startup command is not evidence that your replacement is clean. Do not reinstall from files taken from the affected server unless they have been reviewed and are intentionally restored data rather than executable software.

Restore the world separately and test access#

Treat world recovery and access recovery as two different jobs. Start from a backup made before the suspected activity, if you have one, and choose what player progress you are willing to lose. Restore into an isolated destination where practical. Keep it private while you check the expected server identity, map and save, then test with an authorized operator before reconnecting the community.

For example, our separate Rust data-management test copied a stopped same-build world into an isolated identity. The 27 files totaled 2,250,699 bytes and matched by SHA-256; the restored server started and loaded 310 entities. That test did not involve an intrusion, a player client, plugins, Linux or a provider panel, so it proves only file-copy integrity and a same-build save load. Your own recovery still needs the acceptance checks that matter to your server.

Do not reuse a live Rust+ companion identity for a concurrent test server. Facepunch’s Rust+ server documentation warns that companion.id represents server identity, should be kept with its server and backups, and must not be shared across servers; the page is dated, so confirm current behavior before changing that file. If you are unsure which identity or files belong together, use the detailed Rust data-management recovery record before restoring.

Reopen only against recorded checks#

Do not use “the process started” as the sole go-live signal. Before opening public access, have another responsible operator review the incident record and confirm each check relevant to the suspected path:

1. Confirm the entry path is closed

   Verify the affected panel or system accounts, sessions, roles and shared secrets were reviewed or revoked. Record any provider-controlled items you could not verify and get an owner for follow-up.

2. Check the replacement and restored state

   Confirm the intended Rust build, startup source, identity, map and save are present. Review the installed plugins and configuration against your approved list; do not treat unfamiliar files as cleared because they load.

3. Test access privately

   Connect with an authorized PC Rust client or operator tool in the isolated environment. Check that expected admin access works, unknown access is absent, and the world state is acceptable before enabling public traffic.

4. Approve and record reopening

   Have a second operator sign off on the remaining risks, the expected progress loss and the communication to players. If a check fails, keep the server isolated and return to the relevant step.

These checks reduce uncertainty; they do not certify that no attacker ever had access. Keep a short watch on the records available to you after reopening, and close the incident only when outstanding questions have an owner and a review date.

Communicate confirmed facts and unresolved risk#

Tell players what changed, what progress may be missing and when you expect to reopen. Separate confirmed events from the investigation’s working theories. Do not share exploit details, credentials, private logs or another player’s personal information in a public update. If you do not yet know whether data or accounts were exposed, say that the review is ongoing and name the next update point rather than promising a clean bill of health.

Keep a private timeline of actions, contacts and decisions, including provider ticket numbers and the person who approved each step. Revisit the record after a later alert or a failed access check; a recurrence may change what you believe about the first event. Once stable, use the preventive sections in the Rust server administration guide to tighten routine access, logging expectations and backup custody.