Hacked WHMCS: Client Data, Billing and Server Access

By · Updated · 4 min read

Of the applications that get compromised, a client billing system is close to the worst case. It holds your customers' personal and payment details, it stores credentials for the servers and control panels it provisions, and it has an API with reach into your infrastructure. A compromise here is rarely contained to the application itself, and it should be treated as an emergency.

Why this is worse than a website hack

Think about what the system actually holds. Client records with names, addresses and contact details. Payment information, whether stored or tokenised. Support ticket history, which frequently contains credentials customers pasted in. And integration credentials for the servers, control panels, registrars and payment gateways it manages.

That last category is the one that turns a compromise into a cascade. Someone with your billing system's stored credentials may be able to reach every server it provisions, which means your clients' sites are exposed through your systems rather than their own. That is a materially different conversation to have with them than an ordinary outage.

How they get in

An outdated installation is the leading cause, and this is software where updating promptly genuinely matters because vulnerabilities in it are valuable and get attention. After that: a compromised administrator account, often through a reused password or stealer malware on a staff machine; a vulnerable third-party module or addon; and exposed configuration or installation directories left reachable after setup.

Also worth checking: whether the admin directory is at its default path, whether the installation directory was removed after setup, and whether configuration files are readable over the web. Those are basic deployment steps that are skipped surprisingly often.

What to do first

Preserve evidence before you change anything, as covered in preserving evidence, because you will need the activity log and the timeline for what follows. Then take the system offline or restrict it to known addresses while you work — an active intruder in a billing system is doing damage continuously.

Then assume compromise of everything it holds and start the rotation immediately, in parallel with the investigation. The credentials for servers, registrars and gateways matter more urgently than the application itself, because those reach outside your control.

The rotation list

The encryption key the application uses for stored credentials, plus the database password. Every administrator password, and every API credential the system issues or holds. Server and control panel credentials for everything it provisions. Registrar API credentials. Payment gateway API keys. Email and SMTP credentials. Licence and integration keys for addons.

Force a password reset for client accounts as well, since their records were in the database. My guide on rotating credentials after a hack covers the general order, and here the principle is to start with the credentials that reach other systems rather than the ones that only affect this one.

Working out what happened

The activity log is your most useful artefact — it records administrative actions with timestamps and is usually detailed enough to reconstruct what was done. Check for administrator accounts you did not create, API credentials you did not issue, and changes to payment or email configuration.

Then the file side: compare against a clean copy of your version, look for uploaded files in writable directories, check templates for injected code, and check for scheduled tasks. Read your web server logs for the entry point, using the log technique, and use file timestamps to date the earliest change.

The part you cannot avoid

Your clients' data was in that database and, depending on what the system stored, so were credentials to their servers. They need to be told, and they need to be told promptly enough to act — this is not a situation where waiting for complete information serves anybody.

That means a breach notification assessment, which my guide on breach notification obligations covers, and probably a payment card conversation covered in PCI compliance after a skimmer. My guide on telling customers after a hack covers how to write it. Handle the technical cleanup in parallel rather than sequentially — that is work I take on, and the platforms I clean covers what that looks like.

Common questions

Why is a WHMCS compromise more serious than a website hack?

Because of what it holds: client personal and payment data, support history that often contains pasted credentials, and integration credentials for the servers, registrars and gateways it manages. A compromise can therefore reach your clients' infrastructure through your systems rather than theirs.

What should I rotate first?

The credentials that reach outside the application — server and control panel logins it provisions, registrar API credentials and payment gateway keys — before the ones that only affect the billing system itself. Then the encryption key, database password, all admin passwords and every issued API credential.

How did they get in?

Most often an outdated installation, since vulnerabilities in billing software are valuable and attract attention. Otherwise a compromised admin account through a reused password or stealer malware, a vulnerable addon, or configuration and installation directories left reachable after setup.

Do I have to tell my clients?

Yes, and promptly. Their personal and payment data was in that database, and depending on what was stored, credentials to their own servers may have been too. They need enough time to act. There is also very likely a formal breach notification obligation depending on your jurisdiction.

Can I just restore from a backup?

Not on its own. A restore returns the application to an earlier state but does nothing about credentials already taken, and if the backup predates your knowledge of the compromise it may well contain the same vulnerability or backdoor. Rotate credentials regardless of whether you restore.