Your FiveM server was backdoored — an incident response runbook
In short
When a FiveM server is compromised, work in this order: contain by taking the server offline and cutting its outbound access, preserve evidence by copying the resources directory and logs before touching anything, then rotate every credential the server process could read — database passwords, API keys, Steam and licence keys, webhook URLs and any password reused elsewhere. Only then hunt for the entry point by diffing your resources against known-good copies and scanning every archive. Rebuild from clean sources rather than deleting the file you found, because a backdoor that granted console access has almost certainly left a second way in. Do not skip the credential rotation because you removed the resource; the credentials leaked while it was running.
Key takeaways
- Contain first, investigate second. Every minute the process runs is another minute of exfiltration.
- Copy the resources folder and logs before you delete anything — that copy is your only evidence.
- Assume every secret the server process could read is public. Rotate all of them, not just the obvious ones.
- Finding the malicious file is not the end. Anything with console access could have added persistence elsewhere.
- Rebuild from known-good sources. Cleaning a compromised tree in place is guesswork.
This is a runbook, not an essay. If you are reading it during an incident, start at the top and work down. If you are reading it beforehand — better — read it once now and keep it somewhere your whole team can reach at three in the morning.
Phase 1 — Contain (first ten minutes)
- 1
Stop the server process
Not a restart. Stop it. A backdoor with persistence will happily come back up with the server, and every additional minute is more data leaving.
- 2
Cut outbound network access at the host
If you can, firewall outbound traffic from the machine rather than only stopping FXServer. This blocks anything that installed itself outside the FiveM process.
- 3
Do not reinstall the operating system yet
That destroys the evidence you need to know what was taken. Containment first, forensics second, rebuild third.
- 4
Tell your admin team, quietly
Use a channel that does not run through the compromised host or a bot on it. If your alerting webhook lives in the server config, treat it as attacker-readable.
Phase 2 — Preserve evidence (next fifteen minutes)
Everything you do from here modifies the scene. Take a copy first, and take it off the machine.
- Archive the entire resources/ directory, the server.cfg, and any cache or logs directory, and copy it somewhere else.
- Save the FXServer console log, the system auth log, and your web server or panel logs for the same window.
- Note the timeline: when the behaviour started, what changed shortly before, which resources were installed or updated in the last two weeks.
- Export a database dump before any cleanup, especially if money, items or account data were manipulated — you will want the before state.
Phase 3 — Rotate every credential (this is the part people skip)
Assume that anything readable by the server process is now public. Server-side Lua could read your configuration, environment and database. Rotating only what looks related is how servers get taken twice.
| Credential | Why it is exposed | Action |
|---|---|---|
| Database password | Server scripts hold the connection string | Change it and update every service that used it |
| FiveM licence key | Present in server.cfg | Regenerate in the Cfx.re portal |
| Steam / third-party API keys | Read from convars | Revoke and reissue |
| Discord bot tokens & webhooks | Frequently stored in configs | Regenerate; delete old webhooks |
| Panel / SSH / FTP passwords | Often reused or stored on the host | Change, and move to key-based SSH |
| Payment or shop integrations | Server-side keys | Rotate and review recent transactions |
| Anything reused elsewhere | Password reuse is the norm, not the exception | Change it there too |
Phase 4 — Find the entry point
You need to know how it got in, or you will reinstall it during the rebuild. Work from the copy you made, not from the live server.
- 1
Diff against known-good copies
For every resource you have an original archive or repository for, compare file by file. Unexpected differences are your first candidates.
- 2
Sort by modification time
List every file in resources/ by mtime. A file changed at an hour nobody deploys is worth reading in full.
- 3
Scan every archive you still have
Run each resource archive through static analysis. You are looking for the loader chain, hardcoded identifiers and exfiltration endpoints described in our backdoor patterns article.
- 4
Check what was added, not only what was modified
Look for resources in the directory that are not in server.cfg, extra files inside otherwise legitimate resources, and any file whose name mimics a framework file.
- 5
Review permissions state
Read your ACE configuration and any principals added at runtime. A grant made by a backdoor persists in config even after the resource is gone.
Phase 5 — Rebuild rather than clean
Deleting the file you found is tempting and usually wrong. If the backdoor had console access it could add principals, write new files, schedule tasks or install something outside FiveM entirely. Cleaning in place means betting that you found everything on the first pass.
- 1Provision a fresh host, or at minimum a fresh FXServer installation directory.
- 2Reinstall resources only from sources you can verify: your own repository, the original vendor download, or a re-reviewed archive.
- 3Re-review anything you cannot re-download. If you cannot establish provenance, do not carry it over.
- 4Restore data from a database backup taken before the compromise window where practical, and reconcile carefully if not.
- 5Bring the server up with outbound access still restricted and watch it before reopening to players.
Phase 6 — Close the loop
- Write down what happened, what you rotated and what you changed. The next incident is much cheaper when this document exists.
- Report the malicious resource — to the marketplace it came from, to the framework community, and to us if it helps others.
- Tell your players plainly if their data was involved. Under Czech and EU law, personal data breaches carry notification duties; vagueness helps nobody.
- Introduce the control that would have caught it: review before install, and re-scanning on every update.
That last line is the whole point of the exercise. Incident response restores service; only the process change stops the second incident. If reviewing every resource by hand is not realistic for your team, automate the re-check — continuous scanning exists so the boring part happens without anyone remembering to do it.
Frequently asked questions
What should I do first if my FiveM server has a backdoor?
Stop the server process — not restart it — and cut outbound network access from the host. Every minute the process runs is more data leaving and more opportunity for the attacker to reinstall persistence. Only after containment should you copy the resources directory and logs for evidence, then begin rotating credentials.
Do I need to change my database password after a FiveM compromise?
Yes, along with every other secret the server process could read: the FiveM licence key, API keys stored in convars, Discord bot tokens and webhooks, panel and SSH credentials, and any password reused elsewhere. Server-side Lua runs with full access to your configuration and database connection, so all of it should be treated as public from the moment the backdoor started running.
Is deleting the malicious resource enough to clean a FiveM server?
Usually not. A backdoor with console access can add principals to your ACE configuration, write files elsewhere in the tree, or install persistence outside FiveM entirely. Rebuilding from verified sources is more reliable than cleaning in place, because cleaning assumes you found everything on the first pass.
Should I tell my players about a FiveM server breach?
Yes, once you have contained the incident and rotated credentials. If personal data was involved, EU and Czech data protection law imposes notification duties on the operator, and a clear, factual account does far less reputational damage than the rumours that fill the gap. Announce after rotation, not before — an early announcement tells whoever holds your credentials to use them now.